[转帖]回顾·大数据平台从0到1之后_Hadoop,ERP及大数据讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  Hadoop,ERP及大数据讨论区 »
总帖数
1
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 3601 | 回复: 0   主题: [转帖]回顾·大数据平台从0到1之后        上一篇   下一篇 
liuliying930406
注册用户
等级:中校
经验:2027
发帖:210
精华:0
注册:2018-10-9
状态:离线
发送短消息息给liuliying930406 加好友    发送短消息息给liuliying930406 发消息
发表于: IP:您无权察看 2018-10-22 16:33:31 | [全部帖] [楼主帖] 楼主


转自公众号Datafuntalk


本文根据链家赵国贤老师在DataFun Talk数据架构系列活动“海量数据下数据引擎的选择及应用”中所分享的《大数据平台架构从0到1之后》编辑整理而成,在未改变原意的基础上稍做修改。

大数据平台构建方法大同小异,但是平台构建以后也面临很多挑战,在面临这些挑战我们如何去克服、修复它,让平台更好满足用户需求,这就是本次主题的重点。下面是本次分享的内容章节,首先讲一下架构1.0与2.0,两者分别是怎么样的,从1.0到2.0遇到了哪些问题;第二部分讲一下数据平台,都有哪些数据平台,这些数据平台都解决什么问题;第三个介绍下当前比较重要的项目“olap引擎的选型与效果”以及遇到的一些问题;第四个简单讲一下在透明压缩方面的研究。

image.png

架构1.0阶段,底层是Hadoop,用来存储数据和分析数据。需要把log数据和事务数据传输到Hadoop平台上,我们使用的是kafka和sqoop进行数据传输。然后在Hadoop平台基础上,通过一个开源的Hive和oozie做一个调度,开发者写Hql来完成业务需求,然后将数据mysql集群或redis集群,上层承接的是一个报表系统。这个需求基本跑了一年,也解决了一些问题。但存在的问题有:(1)架构简单,不易解耦,结合太紧密出现问题需要从底层一直查到上面;(2)平台架构是需求驱动,面临一个需求后需要两周时间来解决问题,有时开发出来运营已经不需要;(3)将大数据工程师做成一个取数工程师,大量时间在获取怎样数据;(4)故障频发,比如Hql跑失败了或者网络延迟没成功,oozie是通过xml配置发布任务,我们解决需要从数据仓库最底层跑到数据仓库最高层,还要重刷msl,花费时间。

image.png

面对这些问题我们做了一次架构调整,数据平台分为三层,第一层就是集群层(Cluster),主要是一些开源产品,Hadoop实现分布式存储,资源调度Yarn,计算引擎MapReduce、spark、Presto等,在这些基础上构建数据仓库Hive。还有一些分布式实时数据库HBase还有oozie、sqoop等,这些作用就是做数据存储、计算和调度,另外还有一个数据安全。第二层就是工具链,这一层是一个自研发调度平台,架构1.0用的oozie。基本满足需求有调度分发,监控报警,还有智能调度、依赖触发,后续会详细介绍。出问题后会有一个依赖关系可视化,数据出问题可以很快定位与修复。然后就是Meta(元数据管理平台),数据仓库目前有3万多张表,通过元数据管理平台实现数据仓库数据可视化。还有一个AdHoc,将数据仓库中的表暴露出去,通过平台需求方就可以自主查找自己需要的数据,我只需要优化查询引擎、记录维护、权限控制、限速和分流。最上层将整个大数据的数据抽象为API,分为三个,面向大数据内部的API,面向公司业务API,通用API。大数据内部API可以满足数据平台一些需求,如可视化平台、数据管理平台等,里面有专有API来管理这些API。面向公司业务API,我们是为业务服务的,通过我们的技术让业务产生更多产出,将用户需要的数据API化,通过API获取数据就行。通用API,数据仓库内部的报表都产生一些API,业务需求方根据自己的需求自动组装就OK了。架构2.0基本解决了我们架构1.0解决的问题。

image.png

第二部分就简单介绍下平台,第一个是存储层-集群层,解决运维工作,我们基于开源做了一个presto。实习人员经过一两周能适应这个工作,释放了运维的压力,数据量目前有18PB,每天的任务有9万+,平均3-4任务/分钟;第二个就是元数据管理平台,这种表抽象为各个层,分析数据、基础细节数据等抽象,提供一个类似百度的搜索框,通过搜索获得所需数据,这样业务人员能够非常方便的使用我们的数据。它能实现数据地图(数据长怎样,关联关系是怎么样都可以显示出来),数据仓库可视化,管理运维数据,数据资产非常好的管理和运维,将数据开发的工作便捷化、简易化。

image.png


image.png

第三个数据平台调度系统,数据仓库中的各个层需要流转,数据出现问题后如何去恢复数据。数据调度系统主要的工作有:(1)数据流转调度,可以非常简易的配置出数据的流转调度。(2)依赖触发,充分利用资源,能够让调度任务非常紧凑,能够尽可能快的产出我们的数据。(3)对接多个数据源,需要将多种多样的数据源集成到数据仓库中,如何将sql server数据、Oracle数据等数据导入到数据仓库中,系统能够对接多种数据源,因此我们财务人员、运营人员、业务人员都可以自主将数据接入到数据仓库,然后分析和调度。(4)依赖关系可视化。比如我们有100个任务是关联的,最底层std层有50个任务,中间层有20个任务,如果中间ODS层出问题了,会影响上层依赖层任务,通过可视化就能很方便定位。

image.png

除了前面三个平台,还需要一个平台来展示我们的数据,才能向我们的用户显示数据的价值。我们的指标平台支持上卷下钻、多维分析、自助配置报表,统一公司的各个指标。说一下统一公司的各个指标,比如链家场景,比如说一个业绩(一周卖出十套房子,需要提佣),16年我们发现有多个口径,因此通过指标系统将指标统一化,指标都从这里出,可以去做自己的可视化。还有各种财务人员、区长或店长也可以自主从指标平台上配置自己的数据,做自己的desktop,指标系统的后端使用后续讲Kylin的一个多维分析引擎支撑的。

image.png

指标平台架构,一个应用的可视化平台肯定需要底层能力的支撑,这次主题也是数据引擎,链家使用的是一个叫kylin的开源数据引擎,可以把数据仓库中的数据通过集群调度写入到HBase中做一个预计算。这样就可以支持指标系统千亿级数据亚秒级的查询,不支持明细查询因为做过预计算。还引入了百度开源的palo,经过优化,通过这样一个架构就满足上层的地动仪、指标平台和权限系统。运营、市场、老板都在用这个指标平台,能够实现多维分析、sql查询接口、超大规模数据集、释放数据的能力以及数据可视化。

image.png

我们是需求驱动,每天都会遇到很多需求,数据开发人员就是取出需要的数据。利用adhoc平台将数据从数据仓库中取出,基于这个我们做了一个智能搜索引擎,架构在adhoc上的搜索引擎有很多,比如presto、hive、spark等。用户也不知道该选择那种引擎,他的需求就是尽可能取出自己所需的数据,因此开发智能选择引擎、权限控制,并且能够支撑各种接口、自助查询,这样就基本解决了数据开发的工作。我们自研发了一个queryengine,在底层有presto、sparksql、hive等,queryengine特点就是能够发挥各自引擎的特性,如presto查询快,但是sql支撑能力不强,sparksql同样,在某些特殊sql查询不如hive快,hive就是稳但是慢。queryengine就是智能选择各种引擎,用户把sql提交过来,queryengine判断哪个引擎适合你。如何做的简单介绍下,对sql进行解析成使用的函数、使用的表、需要返回的字段结构,根据各个引擎的能力判断哪个合适。目前还在开发功能就是计费,因为资源是有限的。queryengine支持mysql协议,因为有些用户需要BI能力,需要对返回的数据进行聚合,我们不能开各种各样的BI能力,我们只需满足mysql协议将数据暴露出去,用户只需用其他BI就能使用。

image.png

通过架构1.0到架构2.0衍生出很多平台,大架构已经有了,但是遇到的一些问题如何解决。这里分享两个案例,一个是olap引擎的选型与效果,第二个就是为什么要做透明压缩,是如何做的。Rolap引擎基本是基于关系型数据库,基于关系模型实时进行聚合运算,主要通过传统数据库或spqrk sql和presto,spqrk sql和presto是根据数据实时计算;Molap是基于一个预定义模型,预先进行聚合计算,存储汇总结果。先计算好一个立方体,基于立方体做上传下钻,实现由Kylin/Druid,Druid主要是实时接入(Kylin没有),实时将kafka数据用Spark sql做一次计算然后将数据上传上去,可以支持秒级查询;还有一个比较流行的是叫olap,混合多引擎,不同场景路由到不同引擎。

image.png

Rolap查询时首先将数据扫描出来,然后进行聚合,通过聚合结果将多个节点数据整合到一个节点上然后返回。优势是支持任何sql查询,因为数据是硬算,使用明细数据,没有数据冗余,一致性非常好,缺点是大数据量或复杂数据量返回慢,因为你是基于明细数据,一条一条数据计算无论如何优化还是会出现瓶颈,并发性很差。

image.png

Molap中间会有一个中心立方体cube,在数据仓库通过预计算将数据存储到cube中,通过预聚合存储支持少量计算汇总,为什么少量计算,因为数据都已经预计算好了。优点就是支持超大数据集,快速返回并发高,缺点是不支持明细,需要预先定义维度和指标,适用场景就是能预知查询模式,并发有要求的场景,固化场景可以使用molap。

image.png

对于技术选型,当时面临的需求,基本上开源组件有很多,为什么选择kylin,因为支持较高的并发,面对百亿级数据能够支持亚秒级查询,以离线为主,具有一定的灵活性,最好有sql接口,而这些需求刚好kylin能满足。Apache Kylin™是一个开源的分布式分析引擎,提供Hadoop之上的SQL查询接口及多维分析能力,以支持超大规模数据,最初由e Bay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的Hive表。其解决方案就是预先定义维度和指标,预计算cube,存储到hbase中,查询时解析sql路由到hbase中获取结果。

image.png

现在讲一下链家olap架构,HBase集群,数据仓库计算和预处理在这块,还有一个为了满足kylin需求而做的HBase集群。Kylin需要做预计算,因此有个build集群,将数据写入到基于kylin的Hadoop集群中,然后利用nginx做一个负载均衡,还有一个query集群,然后就是面向线上的一个查询,还有一个kylin中间件,解决查询、cube任务执行、数据管理、统计。指标平台大部分是查询kylin,但是kylin不能满足明细查询,这个就通过queryengine智能匹配,通过spark集群或presto集群,还有alluxio做压缩,然后将明细查询结果返回指标平台,最终返回其他业务的产品。在横向还做了一个权限管理、监控预警、元数据管理、调度系统,来实现整体平台支撑。

image.png

接下来讲一下链家kylin能力拓展,基本大同小异,遇到的问题主要有:分布式构建,cube增长很快,build集群无法承载,因此做了分布式优化能够满足500cube在规定时间跑完;优化构建时字典下载策略,kylin构建时需要将所有元数据字典全部下载下来,因此从Hadoop将元数据字典下载都得好几分钟,每次build都去下载元数据字典会很耗时,优化后只需要下载一次就可以;优化全局字典锁,build时需要锁住整个build集群,完成后锁才释放,源码发现并不需要全局锁只需要锁住所需要的字段就可以,优化将锁设置到字段级别上;Kylin 的query查询机器使用G1垃圾回收器。我们自研发了一个中间件基本可以容纳一个无限容量的队列,针对特定cube的预先调度,以及权限的管控、实现任务的并发控制。架构有外面的调度系统,有一个kylin中间件,所有的查询和build都经过kylin中间件。还做了一个任务队列、统计、优先级调度、监控报警、cube平分、以及可视化配置和展示。

image.png

架构从0到1.0遇到了另一个问题-集群,存储链家所有数据,数据量大、数据增长快(0-1PB两年时间,1PB-16PB不到一年时间,面临成本问题)、冷数据预期,针对这些问题提出透明压缩项目。就是分层存储(Hadoop特性),根据不同数据分不同级别存储,比如把一部分数据存储在ssd,把另一部分数据存储到磁盘之上。Hot策略将数据全部存储到磁盘之上,warm策略就是一部分数据存储在磁盘上,一部分存储archive(比较廉价,转数小)。第二个就是ZFS文件系统,它具有存储池、 自我修复功能、压缩与可变块大小、 写时拷贝/校验和/快照、ARC(自适应内存缓存)与L2ARC(SSD做二级缓存)。

image.png

透明压缩设计实现思路是:(1)界定要做数据冷处理隔离的主要内容。需要将一部分数据存储到ZFS文件系统做一个透明压缩来满足减少成本的需求,这样需要把冷数据界定出来;(2)生成特定的通过获取特定的冷数据列表,并标记其冷数据率;然后,定期从冷数据表中取出为完成冷数据迁移的行,进行移动。通过HDFS目录把界定出来的冷数据移动到ZFS压缩之上,把不需要的移除到Ext4上。这样一部分数据存储在ZFS上,一部分存储在EXT4上。

image.png

透明压缩优化工作有:第一个Hadoop冷热数据分离优化。涉及有异构存储策略选择、HDFS冷热数据移动优化;第二个就是ZFS文件系统优化。ZFS支持很多压缩算法,经过测试发现Gz压缩效率最好,下图是各种算法效率对比。随着压缩数据越来越大,CPU占用越来越高。海量数据集群不光是存储还有计算。Datanode对压缩数据的加载时间,直接关系到访问此部分数据时的效率,从表可知,ZFS的gz压缩在datanode加载数据上对LZ4有部分优势。较为接近EXT4。综合考虑压缩率,读取,写入速度,datanode加载速度等,选定gz作为ZFS文件系统的压缩算法。

image.png

透明压缩前数据增长是非常快的,接近30%的增长速率,逻辑数据有3PB,3备份后总空间:9.3PB实际总空间:7PB,就目前简单预估节省成本有300万。压缩后虽然实际数据再增长,但真实数据是缓慢下降的。

image.png

透明压缩未来展望,透明压缩是对cpu是有损耗的,我们希望将透明压缩计算提取出来,通过QAT卡进行压缩,希望将全部数据进行透明压缩,这样更节省成本;另一个就是EC码与透明压缩结合,采用EC码可以进行两备份或1.5备份;第三个数据智能回暖,压缩访问还是影响性能,比较热的数据放到比较热的存储设备上,放在SSD上做智能加速;第四个整合大存储设备、做冷数据存储。

image.png

最后就是总结:

(1)前期做好需求分析和技术选型,不要盲目的看网上的文章;

(2)面对业务需求多变,如何保证技术稳定迭代;

(3)监控先行,把整个的运营数据拿出来先做监控;

(4)优化在线,需要持续的优化。





赞(0)    操作        顶端 
总帖数
1
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论