看大数据平台从0到一的回顾

大数据平台构建方法大同小异，但是平台构建以后也面临很多挑战，在面临这些挑战我们如何去克服、修复它，让平台更好满足用户需求，这就是本次主题的重点。下面是本次分享的内容章节，首先讲一下架构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，混合多引擎，不同场景路由到不同引擎。