中台，我理解是能力的下沉，数据处理能力下沉为加工平台，数据处理结果下沉为数据资产。那么数据治理能否下沉？可以下沉出什么东西？

——宜信数据中台负责人 卢山巍

本文来源：宜信数据中台负责人卢山巍在亿欧产业互联网频道“数字中台创新”沙龙的分享实录

原文首发：亿欧

亿欧产业互联网频道10月24日在上海InnoSpace落地“数字中台创新”沙龙，活动汇聚了良品铺子电商技术中心总监罗轶群、爱驰汽车科技信息总监杭瑜峰、宜信数据中台负责人卢山巍、ThoughtWorks首席咨询师及极客时间《说透中台》专栏作者王健、亿欧华东负责人缪国成、亿欧产业互联网频道副主编黄志磊、亿欧产业互联网频道作者龚晨霞参与分享，就数字中台话题展开深度讨论。

宜信是一家成立于2006年从事普惠金融和财富管理业务的金融科技企业，2018年基于四大开源平台和中间件等技术，开始研发数据中台，并在宜信内部推广使用。目前，宜信的中台部门一共分为两大板块：数据中台和AI中台。 

以下是卢山巍演讲观点梳理：

1、宜信数据中台指导思维：统一建设、敏捷开发

2、从开源到中台，关键词是自助化

3、数据治理，更依赖人治还是自治？ 

以下是演讲速记实录，经亿欧产业互联网频道整理，供行业人士参考。

大家下午好，我叫卢山巍，来自宜信。刚才听罗总高屋建瓴地介绍了中台的概念和应用，受益匪浅。我的分享会不太一样：第一，我有一个限定词是“数据”。罗总的分享对业务中台、组织中台、技术中台都有探讨，而我本身是做数据的，所以我只介绍数据中台。第二，我个人是从纯粹技术路线走上来的，分享的内容会比较具体而微 。

我今天分享的话题是《宜信数据中台建设三部曲》，内容将按照时间发展故事线来展开。分别是：「敏捷使者」— ABD时代（2015年-2018年） ；「自助奇兵」— ADX时代（2018年-2019年）； 「自治归来」— ADG时代（2019年-）。

2015年加入宜信之前，我在上海张江的eBay研发中心工作，当时的主要方向是大数据架构和研发，在付费广告组做大数据相关的事情。由于我个人的关注点比较下沉，对平台技术更感兴趣，因此总想在技术领域中做出一些框架和平台类的东西。 

1、宜信数据中台指导思维：统一建设、敏捷开发

2015年宜信找到我，说公司内部没有数据平台，希望我能够去带领建设数据平台，于是我加入了宜信。

其实说“公司没有数据平台”是不准确的，更准确地说应该是“公司没有统一的数据平台”，因为公司很多业务线都有自己所谓的数据平台，有的做得好一点，有的是纯粹的定制化，谈不上平台化，因为公司规模很大，很多是自下而上地建设，不像银行是自上而下去推动做这个事情。当时也没有数据中台这个概念，只是说要做一个好的数据平台，感觉有点无从下手，很有挑战，因此着手做了很多公司内部的调研和访谈，用几张图来展现当时的现状。

左上角的图表达的是业务的竖井，从前台到业务开发端，到数据端，甚至有的数据库都没打通。通常好的数据中台，要有好的业务中台配合，在业务竖井严重的现状下，想在数据层融合打通是挺难的事。

左下角表达的是在2015年的时候，很多企业都面临的两个慢的问题，即：时效慢、实施慢。

一方面，那时比较主流的还是T+1批处理，很多企业没有完善的流式处理平台，不像现在有很多成熟的选择。一般来讲都是只能满足T+1时效的数据需求。

另一方面，因为没有很好的自助平台给大家使用，就变成了需求提给特定的BI团队，BI团队接了这个需求，需求多了忙不过来，就开始排期，可能要1-2个月甚至以上的时间才能响应和处理这个需求。

有的业务部门比较有实力，拥有不少大数据工程师，使用了很多技术选型，比如MongoDB、ES、HBase、Cassandra、Phoenix、Presto、Spark、Hive、Impala等等各种技术选型都有，没有统一的技术选型标准。而公司需求又是多样化的，像上图右边的自助查询、360全景分析、实时处理、多维分析、数据湖等等，使得大数据架构变得越来越复杂和臃肿，越来越难以建设和维护，再加上图下方的数据治理、数据质量、数据安全等切面课题，当时面临的就是这样一个比较复杂的现状。

在这样的现状之下思考整个问题，找寻解决方案。本身我个人是比较倡导敏捷开发思想的，敏捷开发更多是在业务开发方面的实践经验，大数据比较笨重，怎么才能让大象奔跑起来？我认为要用敏捷化思想去建设数据平台。经过调研和思考，形成了一系列大数据敏捷思想框架、实践和方法论，更重要的是我们要落地一些中间件去驱动敏捷化实践。

接下来我们先后自研了四个中间件平台：DBus、Wormhole、Moonbox、Davinci。既然用了这么多的技术选型，又很难快速将它们统一到一套技术选型，还要能够去统一收口管控关键节点，最好的办法就是利用中间件思想去适配已有的选型，然后再去简化整个架构。

下面这个图就比较技术视角了，展示了整个数据处理的链路，从左到右，分为数据源层、数据集成层、数据总线层、数据处理层、数据存储层、数据服务层和数据应用层 。其中数据源层，天然有各种各样的选型，这是业务需要；数据存储层，出于不同目的有了众多技术选型，这个也没法很快统一，而且本身也很难找到一个大数据存储选型，能够解决所有的存储问题和计算问题，所以不得不面对多个存储和计算的整合问题。

在应用端，需求场景驱动也是很难整合统一的。能够整合收口的是数据集成层、数据总线层、数据处理层和数据服务层 。整个数据链路梳理完之后，是一种“开放+统一”的架构，有些层面是开放包容的，而有些层面是要统一收口管控的。

当然，上图灰色的切面课题也是应该关注和支持的，因为我们当时的策略是做四个中间件工具DBus、Wormhole、Moonbox、Davinci，因此没有太关注这些切面课题 。

下面分别介绍这些中间件工具：

• DBus，能够实时将数据抽取出来，可以对接多个数据库和日志，既可以实时抽取增量数据，也支持抽取全量数据，并与增量数据保持一致性id体系，以支持后续幂等入库。
• Wormhole，负责流式作业开发和管理，可以不用编写代码，只通过配置和SQL方式即可支持实时同步和流上处理逻辑。这也体现出敏捷性：一是中间件统一了通用技术实现，不用重复开发；二是不断地降低数据项目实施成本，实施人员尽量关注业务逻辑本身，简单培训即可自助完成项目，这些都是敏捷思想的体现。举个例子，从使用体验上看，比如增量数据从Oracle实时出来，希望实时写到MySQL里去，只要简单配置一下就可以了，如果还需要有一些实时处理逻辑，比如流上增量数据去Lookup外面的Redis，只要写一个SQL即可 。另外，因为我们做中间件而不重造引擎，所以Wormhole是基于主流流式计算引擎Spark和Flink开发的，用户可以自行选择希望的计算引擎。Flink还支持CEP操作，所以Wormhole也支持CEP规则配置。
• Moonbox，异构系统混算服务，假设数据因为各种原因存放在各个不同的地方，但又希望能够混算这些数据，你可以当Moonbox是一个“虚拟数据库”来使用。比如A表在Oracle里，B表在MongoDB里，C表在ES里，一个完整的SQL发给Moonbox，会自动将结果混算出来并返回结果数据；同时，Moonbox还能有效利用各个存储的计算优势，将更多算子下推计算，以整体提高运算性能。
• Davinci，可视化平台，一般可视化平台具备的功能Davinci基本都具备，并且支持丰富的可视化应用和系统整合能力，力图解决“大数据最后十公里问题”。

这些中间件做出来后带来了什么效果？比如某条业务线2-3个数据相关人员，对业务非常了解，但没有大数据技术开发背景，经过一两周的培训，就可以自助地、快速地完成各种实时数仓、实时报表、实时应用的端到端项目。这在以前是不可想象的，以前要做一个实时项目，需要有大数据技术开发背景的团队来支持，而现在哪怕不是IT背景的人，培训一下就可以做这个事情了，这就是敏捷中间件工具带来的效率提升和成本减低。 

接下来更深入地介绍一下Wormhole。

除了上面说到的配置化和SQL化开发流式应用这些好处，从内部技术实现角度来看，很多流式开发要注意的典型问题也都被中间件屏蔽了，这些对用户来说是透明支持的。 

• 幂等Sink，流上的增量数据不保证强有序，但是落Sink的时候要做到最终一致性。Wormhole已经内置了这个处理逻辑，用户只管写好流上逻辑SQL就可以 。
• HDFS小文件，做大数据大家都知道这个问题，Wormhole也内置了解决方案。
• 多Flow支持，这是我们独创的功能，如果做过Spark开发，会知道写一个Spark程序，它起来后会一直占固定内存跑一个作业，而我们认为Spark streaming应该是物理资源管道，里面的流上逻辑应该和物理资源解藕，所以我们设计开发了Flow的概念。Flow的定义就是从哪儿来，到哪儿去，在流上做什么处理逻辑。解耦带来的效果是一个Spark streaming物理管道可以跑多个逻辑Flow，比如说公司有1万张表，需要同步到2万个目标端，可能在以前开发需要起两万个Spark streaming作业，现在只需要起一个Spark streaming作业就可以了，比如设置50G内存，在里面跑2万个同步Flow工作，相当于做了逻辑层管道支持，这个还是比较独创的，目前只有我们在这么做。
• 动态指令，这个是和运维相关的，我不希望每次改流式处理逻辑的时候都要去重启这个流，而是能够在线更改、实时生效。
• 业务时间策略，以前Spark streaming是默认基于Process time去做计算的，现在流式引擎很成熟了，引擎内部支持基于Event time计算，但当时Spark streaming还没有支持，所以这块我们也做了相应的支持。
• Flow漂移，这个也是运维相关，比如说，我们起了5个物理的Spark streaming管道，每个里面跑10个Flow，某天某个业务线增量数据量激增，某个Stream资源不够用了，Flow漂移能力就可以将这个逻辑Flow漂到其他空闲的Spark streaming物理管道里。这就是在不断地降低流式处理运维开发的门槛，尽量做到敏捷化，也就是说我可以写一个自动化小程序，定时检测哪一个Spark streaming资源不够，哪一个闲置，然后自动漂一个Flow，这样可以做到流式处理的自动化运维。这个课题大家也在探索，批量作业相对很好运维，出了问题自动重启就可以了，但流式处理的话就比较难运维了，包括资源大小、重启Offset等等，我们在上面都做了很多的工作。所以我们不是简单地包装Spark，而是做了很多深入的东西的。

关于开源，我以前就职于eBay，eBay出了几个Apache顶级开源项目，对我们也是很有影响的，所以我在宜信设计做这四个工具的时候，一开始就是朝着通用化开源工具的方向进行的。不知道在座大家有没有听说过这几个工具，其中Davinci在社区是很火的，很多公司都有在用。

至此，第一阶段工作趋于稳定，解决了公司内部很多的问题，开源的几个工具不光是在公司内部得到很好的应用，在技术社区也赋能了很多其他企业。

第二阶段是从去年下半年开始的。2017年我参加了杭州云栖大会，听过阿里分享的数据中台，那时“中台”这个词还没有流行起来。到了2018年初，我就在思考，认为数据中台是当下公司需要做的东西，于是跟CTO建议，他也很支持我们，之后没几个月，数据中台开始流行起来，所以我们也相当于赶上风口了。

2、从开源到中台，关键词是自助化

ABD时代已经做得不错了，为什么还要再往上做数据中台？除了前面提到的业务线多、技术选型多、需求多等这些大家都知道的问题之外，从数据管理层面来看，如数据治理、数据资产等都还没有涉及，还有很多切面上的课题也没有过多考虑。之前因为开源也和一些社区、公司做过线下交流，都表示“你们的开源工具做得很好，但是离我们业务需求想要的中间感觉还差一块”，其实差的就是一个类似数据中台的东西。

不管数据中台如何定义，企业需要一个能够更加直接赋能业务的平台，因此我们可以在业务需求和中间件工具之间再提升一个层次，构建一个一体化、标准化、一站式的自助平台。