回顾·大数据平台从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