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

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

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

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

原文首发：亿欧

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

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

进入第二个时代，敏捷数据中台 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 时代，从开发到上线到现在大规模应用，有一年多的时间，基本能力都已具备。到了第三个时代，我们更关注数据资产能力和数据治理能力建设，没有数据资产就谈不上数据中台，而数据治理是确保数据资产有效沉淀和赋能业务的重要保障。

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

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

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

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

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

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

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

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

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

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

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

本文转载自宜信技术学院网站。

原文链接：http://college.creditease.cn/detail/325