宜信卢山巍：数据中台的“自动化数据治理”时代已来

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

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

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

原文首发：亿欧

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

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

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

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

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

三、数据治理，更依赖人治仍是自治？

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

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

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

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

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

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建议，他也很支持咱们，以后没几个月，数据中台开始流行起来，因此咱们也至关于遇上风口了。

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

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

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

进入第二个时代，敏捷数据中台ADX。下图大三角中的蓝色三角，数据平台引擎，从技术层面来说，咱们首先要基于以前的开源工具建设一个好用的自助平台。可是单单一个好的自助数据平台，不等同于数据中台。参考了不少数据中台文章和定义后，咱们总结出数据中台还应该包括其余三块。

• 一块是数据资产体系，数据资产是好的数据信息的沉淀和复用，数据中台必定要将数据资产建设归入其中，具体方式好比将数据模型方法论固化并下沉系统化，这样可以更加规范化、标准化地支持沉淀数据资产。
• 有了数据资产，有了好的平台，但若是壶很大、口很小，数据价值赋能业务带宽不足，业务部门可能直观感觉会以为好像只能看报表，会形成数据赋能能力不够。因此对接前台业务不光要能提供报表，还须要可以提供数据产品、数据API、自助分析等，这些均可以更好地赋能业务。
• 有了这些，数据中台能不能真正运转起来，还要看公司的流程制度和运营机制。好比我有好的数据资产，却没有数据运营机制保障，其余业务团队也不会敢用，若是要复用的话我要对其负责，这些都是数据运营的考虑范畴。这些方面都作好以后，才有可能把数据中台作好并运做好。

数据中台的价值体现，在上图右侧也有展现，简单来讲就是“更省更快更准”，或者换个说法是“降本增效提质”，这就是数据中台的价值本质。

下面这张图是ADX上一个大体的使用体验，在自助化数据中台上，整个数据中台研发团队就成为在其背后的IT团队了。用户没必要和咱们直接打交道，在平台上能够自助地申请资源、申请库表，自助开发、自助运维、查看监控 、设置报警、诊断问题、上线下线等，咱们只要作好平台设计、研发和运维，这是咱们想达到的效果，更加全面完全的自助化、平民化。

数据中台是基于模块化思想建设的，拆分为众多子模块，之间关系是分层和联合的。好比统一的数据归集、数据加工、数据模型、监控预警等，这些和其余公司思路都差很少；右侧的数据管理、中台管理，都是在解决切面的课题；上面部分是贴近业务使用的模块。模块不少这里不一一展开介绍。

值得一提的是，主要核心模块都不是从零开发，而是基于ABD开源工具整合打通构建的，因此ADX不是推翻了之前的ABD，而是基于ABD更加抽象、更模式化、更面向业务去作上层建筑。

如今处于ADX时代，下图就有所变化了。DataHub整合了数据集成和数据总线层，之前DBus只支持流式归集和分发，而DataHub无论是流式仍是批量均可以支持。DataWorks之于Wormhole也是如此，至关于ABD功能的扩展外延。

下层的切面课题，也都有相应的模块对应解决。因此说ADX更加平台化，不像之前咱们作了几个比较好的开源工具，而后你们本身DIY组合去解决各类场景项目，如今是基于一站式自助平台，用户能够在其上完成各类各样的平常数据处理工做。

再提一下DataHub，这个模块当时作的时候没以为怎样，作出来之后你们都以为真的很方便，很强大。

下图从DataHub这个模块外面站在黑盒的角度去看，能够想要什么数据就能获得什么数据：好比我想要某张表的天天T+1快照，它会返给我；我想要这张表的任何一个历史时刻的精确快照，它也能返给我；我想要这张表的实时流数据，它还能返给我。之因此能作到这点，由于咱们把全部表的全量+增量数据都实时落入数据湖，并基于ABD开源工具的整合模式提供各类各样的所需数据形态，所以从数据层面来看，理论上你想要什么，DataHub均可以提供。咱们也了解了社区一些相似的数据整合方案，大部分都是提供单纯工具层面的功能，而没有内置实时数据湖。DataHub包含了一个数据湖，全公司全部的数据均可以实时地统一地归集和维护进来，全部的数据使用方，想要什么就能够返回什么，这是很是方便和完全的使用体验。

第二个时代ADX时代，从开发到上线到如今大规模应用，有一年多的时间，基本能力都已具有。到了第三个时代，咱们更关注数据资产能力和数据治理能力建设，没有数据资产就谈不上数据中台，而数据治理是确保数据资产有效沉淀和赋能业务的重要保障。

数据治理这个课题，在数据链路每一层都有对应可能存在的问题，这些问题有些能够在系统层面解决，但更多的是依赖于人去治、依赖于组织去治，且依然不容易获得完美的解决。在这个课题上咱们也在思考和摸索中，如下仅限于探讨。

三、数据治理，更依赖人治仍是自治？

下面是咱们的一些思考。“自治”包含两层含义：自动化治理和自助化治理。

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

一类是下沉出一些平台工具，好比元数据管理、数据质量管理，这些能够作得很通用化、工具化；一类是下沉出一些方法论的系统化，好比阿里的OneData，是一套内部打磨出来的本地化的方法论，落地为一套系统体系，这套体系和方法论不必定适合于每家公司，但我以为这个思路每家公司均可以借鉴，打磨适合本企业业务体系的方法论，而后将之系统化，更好地约束和规范化企业内的数据治理管理和数据资产建设。

对于“自动化”数据治理，以上两类依然不能覆盖全部问题，好比企业有不少遗留系统、遗留流程，没法在短期内进行大规模的、统一的改造和迁移，那么怎样去管控它、治理它？这依然是一个难题。RPA是一个比较新兴的思路，能够很好地处理遗留系统的问题，这一点和数据治理也许能够找到很好的交叉点，好比能够利用流程编排、自动执行的思想，应对一些遗留系统、遗留环境的数据治理问题。

关于“自助化”数据治理，数据治理和数据处理不太同样，好比流式处理，这是一个业务可以直观感觉到的刚需，无论什么业务都会有很强的需求。而数据治理不一样，从业务角度来看，数据治理虽然就长期而言能够为整个企业和业务发展带来坚实的正面影响，但短时间内可能会限制业务快速发展的速度，因此业务方可能不会有特别大的动力去主动支持和配合数据治理。

有些企业会自上而下强制推行数据治理的管理和实践，这是须要管理层有这个意识和决心的。咱们公司不太同样，数据治理须要向业务快速迭代和需求快速变动妥协，没法作到自上而下强推，但又不能不治，所以咱们考虑能不能自助化地作数据治理。好比业务线能够创建本身的私有数据资产，若是但愿升级成公有数据资产，能够进行申请审核，固然这要能够为业务线带来好处，要和KPI绑定，这样一来，数据资产的运营能力能够下放，让你们主动共同参与到数据治理中来，这种柔性数据治理推广方式可能会更有效，这也是咱们在尝试的工做。

上图只是一个粗略的概念架构图，还不是特别成熟，这也是咱们如今在思考的一些思路。若是能够把公司全部的元数据归集起来，造成一个企业级元数据全景图谱的话，咱们就具有了数据知识；由于咱们有Moonbox，咱们就具有了各类数据操做能力；基于数据知识能力和数据操做能力，就能够根据数据治理的经验、规则和现状的流程梳理，进行数据治理动做的可视化编排，最终造成一个自动化数据治理的体系和框架。

数据治理纯靠人的话，不肯定性因素太大，相对来讲我更相信工具，相信经过不断的抽象、下沉和验证，能够找到一套更系统化的流程方式和配套工具去作得更好。

以上就是咱们四年来数据中台建设的三个时代走过的历程，前路依然任重道远，还需继续摸索沉淀，但愿能够和你们多多交流探讨，感谢你们的聆听！