宋洪鑫：美团点评数据仓库开发模式演进

本文根据【2016 第七届中国数据库技术大会】现场演讲嘉宾宋洪鑫老师分享内容整理而成。录音整理及文字编辑IT168@田晓旭@老鱼。

嘉宾介绍：

宋洪鑫，美团美团点评高级工程师2014年加入美团数据平台，专注数据仓库开发解决方案领域。2011毕业于北京邮电大学计算机系，曾加入阿里巴巴北京商家数据部，从事数据实时计算工作。

正文：

大家好，我今天的演讲主题是美团点评数据仓库开发模式演进，将美团从零开始一点一滴去建设数据仓库的全部过程展现出来。

近几年，美团团购业务在飞速发展，已经向外卖、电影等多个业务领域实现了横向拓展，之前由单一的数据组统一构建数据仓库的开发模式已经不能满足业务的快速发展需求了，所以我们数据仓库的开发模式由数据组主导转变到了业务方自治。在这个转变过程中我们遇到了诸多问题，比如数据资源隔离、权限控制、数据治理、开发平台等等，我想分享一下我们是如何解决这些问题的，为后来的公司提供一些参考经验。

我叫宋洪鑫，我毕业于北京邮电大学，曾加入阿里巴巴，一直从事数据实时计算领域方面的工作，2014年加入到美团点评，一直活跃在美团点评的数据平台，从事数据仓库开发，数据治理，资源管理与权限控制，目前主要专注在任务例行执行解决方案的方向。

美团数据仓库支撑的业务有餐饮、旅游、电影、外卖、配送、广告、风控等四十多个业务场景，接下来我将从数据仓库开发模式的视角为大家介绍我们美团数据仓库是如何建支撑这么多业务的。

我先对开发模式这个概念做一个解释，它主要是想表达的是数据仓库开发过程中，数据需求方分析师，业务方数据RD，以及数据平台RD是之间是如何协作的，角色定位是怎样的，以及这个过程中平台机制上是如何支持的

按照这个视角对美团数据仓库的在演进过程进行划分，大致可以划分为四个阶段，第一个阶段是史前模式，是从2010年到2012年，我们业务刚上线的时候使用的模式，接着是近代模式和现代模式，最后是2015年3月后，我们完成并一直采用的当代模式。这是四种模式都有各自的特点和问题。

第一个模式是史前模式，刚成立的公司更关注的是本身业务的发展，因为只有业务发展了，企业的数据量才会不断增加，数据价值才会更多的体现出来。所以一开始我们没有做系统性的规划，数据分析师和数据组RD之间基本上没有协作，因为这个阶段数据量小、业务需求也比较少，所以技术也是非常简陋的，一般是数据组RD用手写的脚本工具从业务上抽取数据，然后在服务器内存上进行计算，把结果以报表的形式推算给业务方。在公司成立之初，这样的方式是最快的，也是最能满足业务需求的。

随着业务量的不断发展，这种简单粗暴的模式暴露了一些问题。这些问题主要集中在两个方面，一个是数据方面，没有集成，脚本工具都是直接从业务源抽取到内存当中，没有进行统一的存放，这样做会导致关联计算难度非常大;难以复用，没有对一些基础数据做简单统一的加工和处理，每一个需求都要重新算一遍;第二个是工具层面，重复开发的情况比较严重，每个需求RD都要重写一些通用的逻辑，比如数据库的连接导入等功能没有进行统一的抽象;管理混乱，元数据，业务元数据和ETL之间没有进行统一的管理，都是由数据RD自己管理的，所以时间长了就会非常混乱。直接反映的是随着后面业务量的发展，支持业务需求的效率非常低，不符合美团团购业务的场景。

为了解决数据集成和复用的问题，我们对数据进行了集成，集成之后我们就开始有了建设数据仓库的想法，把业务数据和流量日志集成到ODS层，然后数据RD针对性的进行数据仓库的建设，对基础数据进行加工。在业务需求方面，会根据业务场景阐述主题表，业务方数据需求分析师可以通过自由查询来查询这些主题表，定制化自己所需要的报表，我们发现这时数据RD和分析师之间有了协作;在工具层面上引进了ETL系统，对ETL进行统一管理，在ETL计算过程中，我们抽象了一些通用逻辑，提高了计算效率，同时也能够根据系统继续管理元数据之间的关系，

用一句话来概括近代模式那就是由RD包办开始转向RD和数据分析师的协作。

这样的模式我们持续使用了一段时间后遇到了一些问题。我们选用了MySQL数据库，所以数据存储不易扩展;在对接业务需求的时候数据结构效率非常低，因为是由统一数据来对接需求，所以我们不得不为每种类型的业务配备专属数据RD对接，同时新业务的理解时间也会很长;后期维护成本高，专属RD转岗之后就要进行工作交接，这样就会有产生一个问题，交接的人要对之前的业务重新理解一遍，这时候如果业务需求有什么变更或者新增的话，交接的人处理需求的压力会非常大，因为他不知道交接之后对业务的理解程度是否符合要求。

为了解决接入效率和后期维护的问题，我们对之前的模式进行了进一步的演进。业务上不再是由数据组RD统一主导，而是和业务方协作构建数据仓库。之前在数据结构的流程上是由数据组RD包办，对接所有数据需求，但是业务方要更加了解业务，所以在现代模式中数据组RD更多的是对接业务方RD和产品，帮他们进行需求分析、仓库建模。在ETL开发上方面，数据组RD主要是负责仓库统一规范的制订和业务方协作共建仓库层上的数据，在此基础上可以自由的建设每个业务方的数据级次。为了保证数据质量，数据组RD要进行统一把关，在每个ETL开发好上线之前，数据组要统一的审批任务是否符合性能要求。

现代模式的数据仓库模型是比较标准的自上而下模型，也就是DW到DM的仓库构建方式。业务方有自己的DM，可以提供数据应用，美团每一个公司的数据仓库层次虽然都类似，但是都不同。美团数据仓库2.0模式出现了一些数据应用，例如指标提取工具，可以解决数据指标计算口径的一致性问题。

上图是一个美团数据平台的数据构建图，它是从数据生产流程图的流程去描述的，最上面的是业务系统，负责产出数据;数据收集层统一搜集数据，然后到数据存储层存储，然后经过加工计算展现给数据需求方。

这里面我们主要采用了一些新技术，引入Hadoop系统进行了分布式仓库的建设，解决了数据存储不宜扩展的问题。在数据收集层，进行了实时统一收集管理，提高了数据源接入效率，并且为需要实时计算业务场景提供了实时的数据源。在业务计算引擎上引入了Hive、Spark这些现在比较主流的引擎，提高任务执行效率。

即便如此，我们还是面临着很多的挑战。挑战的直接原因来自于我们的业务增长，刚开始我们只有一个数据组，对接所有的业务方，和他们协作构建数据仓库。但是餐饮、酒店、电影这些业务一直在高速发展，占据了一定的行业市场份额。还有一些新增业务，外卖、配送、广告等等发展的也非常迅猛。

业务的高速发展给数据仓库带来的影响第一个就是数据仓库要支持的业务场景变多，目前我们已经达到了二十几个业务场景。

第二是平台服务的业务RD的人数猛增，现在我们已经增加到了两百多人，半年就翻了一倍。

第三个就是ETL任务数增多，现在已经达到了三千八百多个，而且还在随着业务的增长而成倍增长。

平台本身也遇到了三个挑战，第一个是ETL开发和数据存储管理出现了混乱，本质的原因是没有做好一个全套的权限控制方案，无论是数据组RD，还是业务方RD，他们都可以随意的写入到DW层和DM层。随着任务量的逐渐增加，管理就会非常困难。

第二个挑战是ETL任务间的计算相互影响。因为所有的任务都是数据组主导的，这些数据都是使用平台资源，拆分起来也比较困难。所以，大家只能用一个公共队列，在生产的时候可能会有一些ETL任务使用资源不合理，这样就可能会影响其它关键的ETL任务的数据产出时间。

第三个挑战是ETL开发效率不能满足业务增长。刚才提到最后环节是要由数据组RD统一审批，那么为什么要统一审批因为资源没有做好隔离，权限没有做好控制，只能靠数据组RD人肉把关，尽可能的让任务在性能上更好。

但是，这样的模式也已经不能满足业务增长的需求了，我们当时面临的窘境是平台人力资源消耗严重，基本上每一个平台RD都要花30%的时间进行任务上线审批。除此之外，任务管理和业务对接也是十分损耗人力的。

除了我们平台自身的窘境外，我们还面临着业务方的不断吐槽。任务开发之后，提交给RD，如果不符合规范就要打回去重新开发，导致了开发效率低。还有就是任务执行慢，每一个业务方都说自己ETL没有问题，但是他们相互之间影响，排查问题的难度非常大。

我们觉得是时候要做出改变了，我们在寻找解决方案时候的思路有三点。

第一点是提升效率，业务方经常吐槽ETL审批效率低，我们就从提升效率入手，大体思路是我们把审批的权限下放给业务方，让业务方自己审批自己的业务。

第二点是要做好安全可控，如果我们把权利下放了，但是不进行安全控制的话，那么后果比之前的开发模式更严重。开放之后就意味着平台各个业务方可以随意的使用我们数据平台的存储和计算资源，长时间下去的话，ETL管理会变得更加混乱，

第三点要做到管理透明，每一个业务方对自己的ETL管理都是非常清晰的，他可以看到他们的业务下有哪些ETL，每个ETL使用了多少资源，这样也可以为后续的评估资源成本做依据。

基于这三点我们最后对开发结果做了一个权衡。开放后数据仓库的建设会变成什么样，对突发情况是否做好了应对措施。最后决定开发与否的判断依据是满足业务需求才是第一位的。

针对之前的思路，我们的解决方案主要分为四个步骤，第一个步骤是ETL任务分组，第二步是进行资源隔离，第三步是权限控制，最后是开发ETL审批工作。

下面我们详细介绍一下每个步骤。

第一个ETL按业务进行分组，目的是要把ETL划分给各个业务方，让他们自己管理，同时分组后各个业务方可以对平台资源使用、分组信息和自己的ETL业务分组信息进行调节。基于这两点，我们的分组方案是这样的，首先对每个数据源先进行分组，看数据源是属于哪个业务方，有了这个分组之后，用户创建ETL的时候就可以用这个分组作为ETL分组的依据了，ETL创建之后我们根据ETL的owner属性关联到业务方RD进行开发，ETL本身和从数据源获得的所属组属性会和Hadoop任务实体关联，这样就解决了分组信息和平台资源使用的桥接问题。

上图是我们在权限控制上的一个权限模型，虽然这个模型不是最好的，但是它能够第一时间解决问题。这个模型大概分为五个层次，应用权限控制和系统层权限控制让这五层的权限控制相互协调。第一层是用户验证层，主要进行任务登陆和任务提交，任务通过Kerbaros提交到集群结点，资源使用层使用yarn自带的权限控制功能，开发层和执行层通过文件系统和UPM联合控制，UPM是美团的一个权限控制系统，基于RBAC模型，有了这样的权限模型之后就能保证ETL开放后的安全可控性。

ETL分组之后再做资源隔离就非常容易了，每个业务组分配一个资源队列，任务组就按照各个资源队列的资源使用，相互之间不干扰了，同时业务方还可以根据自己业务量的增长去申请资源队列的配额，使用资源量也透明了。

存储层的权限控制非常清晰，每一个业务方只能写到自己的数据中去。如果业务方之间有协作，我们也支持互相审批。

在正式开放审批之前我们会对各个组的负责人进行统一培训，传授我们仓库建设的经验，同时在平台上开发保障机制，之前我们是通过数据RD来控制数据仓库的建设规范，现在我们要在开发平台上开发相关的机制来保证仓库建设的基本规范。这里举个简单的例子，比如开发者在开发的时候会遇到这样的问题，他会从ODS层抽取数据写到DW层，再写到DM层，依赖于DM层的表又会写回到ODS层，但是我们的开发保障机制就会避免这样的情况出现。开放之后每个业务方审批自己的ETL任务，因其业务理解比我们更深刻，所以效率是非常高的。

下面来看一下变革后的开发流程图，业务来了要进行数据接入，首先要看它有没有ETL分组，如果没有ETL分组，就要去申请环境，分配资源，同时要提供一位负责人进行培训管理。这些都申请好之后就可以进入正式的开发环境了，在开发过程中会访问其它业务方的数据资源，这时候我们会判断它是否有访问资源的权限，如果没有，就到权限控制系统申请权限，申请成功后才可以进行开发和测试，测试之后就可以提交给每个组的审批人进行审批，如果通过的话就可以部署上线了，如果没有通过的话就打回继续修改。

这是美团数据开发平台数据RD开发ETL的示例，在进行开发之前，要先选择数据源，选择了数据源之后就确定了分组，就可以开始后续的开发流程了。

我们来看一下分组之后取得的收益，其中非常重要的一点是保证了ETL业务的同比增长趋势，这是我们每年任务的统计，红框的地方是当代模式，2015年3月是我们开发的时间点，短短的一年时间，ETL任务数量由3800增长到了17000，接近四倍的增长。

我们借着这个图再来简单回顾一下仓库开发模式演进过程中都有哪些技术第一个是史前模式，是RD手写报表工具的时代，第二个时代我们引入了ETL系统，第三时代是我们的分布式数据仓库，当代模式主要是ETL分组开放。

除了上述收益，我们在其它的方面上也获得了很多收益，第一个是提高工作效率，在Review请求数量增加1.5倍的情况下，响应时间降低了40%;其次是解放了数据平台的生产力，可以投入更多的资源到平台的建设当中，最后一点我们在这个过程中完成了业务分组，我们目前有四十多个业务场景，确定了各组的对接人和资源配额，规范了数据仓库的建设。

最后我们针对过程中遇到的问题进行总结，同时展望一下未来。