回顾·大数据平台从0到1以后

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

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

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

面对这些问题咱们作了一次架构调整，数据平台分为三层，第一层就是集群层（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解决的问题。

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

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

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

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

咱们是需求驱动，天天都会遇到不少需求，数据开发人员就是取出须要的数据。利用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就能使用。

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

Rolap查询时首先将数据扫描出来，而后进行聚合，经过聚合结果将多个节点数据整合到一个节点上而后返回。优点是支持任何sql查询，由于数据是硬算，使用明细数据，没有数据冗余，一致性很是好，缺点是大数据量或复杂数据量返回慢，由于你是基于明细数据，一条一条数据计算不管如何优化仍是会出现瓶颈，并发性不好。

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

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

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

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

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

透明压缩设计实现思路是：（1）界定要作数据冷处理隔离的主要内容。须要将一部分数据存储到ZFS文件系统作一个透明压缩来知足减小成本的需求，这样须要把冷数据界定出来；（2）生成特定的经过获取特定的冷数据列表，并标记其冷数据率；而后，按期从冷数据表中取出为完成冷数据迁移的行，进行移动。经过HDFS目录把界定出来的冷数据移动到ZFS压缩之上，把不须要的移除到Ext4上。这样一部分数据存储在ZFS上，一部分存储在EXT4上。

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

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

透明压缩将来展望，透明压缩是对cpu是有损耗的，咱们但愿将透明压缩计算提取出来，经过QAT卡进行压缩，但愿将所有数据进行透明压缩，这样更节省成本；另外一个就是EC码与透明压缩结合，采用EC码能够进行两备份或1.5备份；第三个数据智能回暖，压缩访问仍是影响性能，比较热的数据放到比较热的存储设备上，放在SSD上作智能加速；第四个整合大存储设备、作冷数据存储。

最后就是总结:

（1）前期作好需求分析和技术选型，不要盲目的看网上的文章；

（2）面对业务需求多变，如何保证技术稳定迭代；

（3）监控先行，把整个的运营数据拿出来先作监控；

（4）优化在线，须要持续的优化。

——END

本文由DataFun社区首发，公众号ID：datafuntalk