数据中台宜信敏捷数据中台建设实践分享实录

内容来源：宜信技术学院第 2 期技术沙龙 - 线上直播 | 宜信敏捷数据中台建设实践

分享嘉宾：宜信数据中台平台团队负责人 卢山巍

导读：宜信于 2017 年推出了一系列大数据开源工具，包括大家熟悉的 DBus、Wormhole、Moonbox、Davinci 等，在技术社区内得到了广泛关注和好评。这些工具是如何在宜信内部应用的？它们和宜信数据中台是怎样的关系？又是如何驱动各种日常数据业务场景的？

本次分享对这些问题进行了回答，同时重点分享了宜信敏捷数据中台的设计、架构以及应用场景，提出一种敏捷数据中台的建设思路，以供参考和探讨。以下是本次分享的实录。

分享大纲：

一、导语

二、宜信数据中台顶层设计

三、从中间件工具到平台

四、典型案例分析

五、总结

六、Q&A

视频回放地址：https://v.qq.com/x/page/r0874…

PPT 下载地址：https://pan.baidu.com/s/1jRum…

一、导语

目前“中台”的概念很火，包括数据中台、AI 中台、业务中台、技术中台等。宜信技术学院第一期技术沙龙，井玉欣博士分享了宜信的 AI 中台，本期技术沙龙，由我来为大家分享《宜信敏捷数据中台建设实践》。

为什么我们要在数据中台前加上“敏捷”呢？了解我们的朋友都知道我所在的团队是宜信敏捷大数据团队，我们倡导“敏捷平民化”，把敏捷思想融入到系统建设中，并且研发了四个开源平台：DBus、Wormhole、Moonbox、Davinci。宜信的数据中台是由我们敏捷大数据团队基于四大开源平台开发建设的，因此我们将宜信的数据中台称之为“敏捷数据中台”。

本次分享分为三个部分：

• 宜信敏捷数据中台的顶层设计。数据中台是一个公司级的平台系统，所以不能只从技术层面去设计，还要考虑包括流程、标准化等在内的顶层设计。
• 从中间件工具到平台介绍宜信是如何设计建设敏捷数据中台的。
• 结合典型案例介绍宜信敏捷数据中台支持哪些数据方面的应用和实践。

二、宜信敏捷数据中台的顶层设计

2.1 特点和需求

关于数据中台的建设，目前并没有一个标准的解决方案，也没有一个数据中台能适用于所有的公司，每个公司都应该结合自己的业务规模及数据需求现状来研发适合自己公司的数据中台。

在介绍宜信敏捷数据中台的顶层设计之前，我们先来了解其背景：

• 业务板块和业务条线众多。宜信的业务大体可分为四大板块：普惠金融板块、财富管理板块、资产管理板块、金融科技板块，拥有近百条业务线和产品线。
• 技术选型众多。不同业务方有不同的数据需求，技术选型时依据这些客观需求及主观偏好，会选择不同的数据组件，包括：MySQL、Oracle、HBase、KUDU、Cassandra、Elasticsearch、MongoDB、Hive、Spark、Presto、Impala、Clickhouse 等。
• 数据需求多样。业务线多样，导致数据需求多样，包括：报表、可视化、服务、推送、迁移、同步、数据应用等。
• 数据需求多变。为顺应互联网的快速变化，业务方的数据需求也是多变的，经常有周级产出数据需求和数据应用。
• 数据管理考虑。要求数据元信息可查，数据定义和流程标准化，数据管理可控等。
• 数据安全考虑。宜信作为一家同时拥有互联网属性和金融属性的公司，对数据安全和权限的要求很高，我们在数据安全方面做了很多工作，包括：多级数据安全策略、数据链路可追溯、敏感数据不可泄露等。
• 数据权限考虑。在数据权限方面的工作包括：表级、列级、行级数据权限，组织架构、角色、权限策略自动化。
• 数据成本考虑。包括集群成本、运维成本、人力成本、时间成本、风险成本等。

2.2 定位

关于数据中台的定位，每个公司都不太一样。有的公司业务比较专注，只有一条业务线，那它在建设数据中台的时候，可能需要一个垂直的平台，直达前线，更好地支持前线的运作。

前文提到宜信业务线很多，且在众多业务中没有一个主体业务，这就相当于所有业务线都是主体。基于这样的背景，我们需要一个平台化的数据中台，来支撑所有业务线的需求和运作。

图 1 定位

如上图所示，绿色的部分是宜信敏捷数据中台，我们称之为“ADX 数据中台平台”，“A”即“Agile（敏捷）”，之所以称为“平台”，是因为我们希望将其打造成一个服务于全业务线的平台系统，助力业务发展。

敏捷数据中台处于中间位置，最底下是各种数据集群，最上端是各个业务领域数据团队。数据中台通过整合处理数据集群的数据，为业务领域数据团队提供自助化、实时化、统一化、服务化、管理化、可溯化的数据服务。

右边三个蓝色的板块分别是数据管理委员会、数据运维团队和数据安全团队。前文提到宜信对数据安全的要求非常高，所以设置了专门的数据安全团队来规划公司数据安全的流程和策略；数据管理委员会负责数据的标准化、流程化，补齐技术型驱动的数据中台的推动效率，保证有效沉淀和呈现数据资产。

我们对 宜信敏捷数据中台的定位 是：从数据技术和计算能力复用，到数据资产和数据服务复用，敏捷数据中台会以更大价值带宽，快、准、精让数据直接赋能业务。

2.3 价值

宜信敏捷数据中台的价值集中表现为三个方面：快、准、省。

图 2 价值

2.4 模块架构维度

图 3 模块架构维度

如图所示，宜信敏捷数据中台的建设也是基于“小前台，大中台”的共识。整个中间部分都属于敏捷数据中台包含的内容，左边绿色部分是基于数据维度来看整个中台，右边蓝色部分则是基于平台维度来看中台。

• 数据维度。各种内部数据、外部数据先归集到数据源层，再以统一化、实时化、标准化、安全化等方式存储起来形成数据湖层，数据湖对这些原始数据进行处理和体系化归类，转化为数据资产；数据资产层包括数仓体系、指标体系、标签体系、特征体系、主数据等；最后将沉淀的这些可复用的数据资产提供给数据应用层，供 BI、AI、数据产品应用。
• 平台维度。每个蓝色的方框都代表一个技术模块，整个宜信敏捷数据中台就是由这些技术模块组合而成。其中 DataHub 数据枢纽，可以帮助用户完成自助数据申请、发布、脱敏、清洗和服务等；DataWorks 数据工坊，可以对数据进行自助查询、作业、可视化等处理；还有 DataStar 数据模型、DataTag 数据标签、DataMgt 数据管理、ADXMgt 中台管理等。

值得一提的是，这些模块都不是从 0 开发的，而是基于我们已有的开源工具。首先，基于成熟的中间件工具来进行开发，可以节约开发的时间和成本；其次，开源工具成为引擎，可以共同合力支撑更大的一站式平台。

2.5 数据能力维度

图 4 数据能力维度

将上述架构模块重新按照能力维度划分，可以分成若干层，每一层都包含若干能力。如图所示，可以清晰地看到建设数据中台需要具备哪些数据能力，这些能力都对应哪些功能模块，分别能解决什么问题。此处不再展开赘述。

三、从中间件工具到平台

3.1 ABD 总览

图 5 ABD 总览

中间件工具指 DBus、Wormhole、Moonbox、Davinci 四大开源平台，它们从敏捷大数据（ABD，Agile BigData）理念中抽象而出，组成 ABD 平台栈，敏捷数据中台则被我们称为 ADX（Agile Data X Platform）。也就是说我们经历了从 ABD 到 ADX 的过程。

一开始，基于对业务需求共性的抽象和总结，我们孵化出若干个通用的中间件，去解决各种各样的问题。当出现更为复杂的需求，我们尝试将这些通用的中间件进行组合运用。实践中，我们发现经常会使用到某些特定的组合，同时，从用户角度来看，他们更希望能实现自助化，直接拿过来就能用，而不是每次都要自己去选择和组合。基于这两点，我们对这几个开源工具进行了封装。

3.1.1 ABD-DBus

DBus（数据总线平台），是一个 DBaaS（Data Bus as a Service）平台解决方案。

DBus 面向大数据项目开发和管理运维人员，致力于提供数据实时采集和分发解决方案。平台采用高可用流式计算框架，提供海量数据实时传输，可靠多路消息订阅分发，通过简单灵活的配置，无侵入接入源端数据，对各个 IT 系统在业务流程中产生的数据进行汇集，并统一处理转换成通过 JSON 描述的 UMS 格式，提供给不同下游客户订阅和消费。DBus 可充当数仓平台、大数据分析平台、实时报表和实时营销等业务的数据源。

开源地址：https://github.com/BriData

图 6 DBus 功能及定位

如图所示，DBus 可以无侵入地对接各种数据库的数据源，实时抽取增量数据，做统一清洗和处理，并以 UMS 的格式存储到 Kafka 中。

DBus 的功能还包括批量抽取、监控、分发、多租户，以及配置清晰规则等，具体功能特性如图所示。

上图右下角展示的是 DBus 的一个截图，用户在 DBus 上可以通过一个可视化页面，拉取增量数据，配置日志和清洗方式，完成实时数据抽取等工作。

图 7 DBus 架构

从如上架构图可以看到 DBus 包括若干不同的处理模块，支持不同的功能。（GitHub 有具体介绍，此处不作展开。）

3.1.2 ABD-Wormhole

Wormhole（流式处理平台），是一个 SPaaS（Stream Processing as a Service）平台解决方案。

Wormhole 面向大数据项目开发和管理运维人员，致力于提供数据流式化处理解决方案。平台专注于简化和统一开发管理流程，提供可视化的操作界面，基于配置和 SQL 的业务开发方式，屏蔽底层技术实现细节，极大的降低了开发门槛，使得大数据流式处理项目的开发和管理变得更加轻量敏捷、可控可靠。

开源地址：https://github.com/edp963/wor…

图 8 Wormhole 功能及定位

DBus 将实时数据以 UMS 的格式存储到 Kafka 中，我们要使用这些实时的流式数据，就要用到 Wormhole 这个工具。

Wormhole 支持配置流式化的处理逻辑，同时可以把处理完之后的数据写到不同的数据存储中。上图中展示了很多 Wormhole 的功能特性，我们还在开发更多新的功能。

上图右下角是 Wormhole 的一个工作截图，Wormhole 作为流式平台，自己不重新开发流式处理引擎，它主要依赖 Spark Streaming 和 Flink Streaming 这两种流式计算引擎。用户可以选择其中一个流式计算引擎，比如 Spark，配置流式处理逻辑，确定 Lookup 库的方式，并通过写 SQL 来表达这个逻辑。如果涉及 CEP，当然就是基于 Flink。

由此可以看出，使用 Wormhole 的门槛就是配置加上 SQL。这也符合我们一直秉承的理念，即用敏捷化的方式支持用户自助玩转大数据。

图 9 Wormhole 架构

上图展示的是 Wormhole 的架构图，包含很多功能模块。介绍其中的几个功能：

• Wormhole 支持异构 Sink 幂等，能帮助用户解决数据一致性的问题。
• 用过 Spark Streaming 的人都知道，发起一个 Spark Streaming 可能只做一件事情。Wormhole 在 Spark Streaming 的物理计算管道中抽象出一层“逻辑的 Flow”的概念，就是从什么地方到什么地方、中间做什么事，这是一个“逻辑的 Flow”。做了这种解耦和抽象之后，Wormhole 支持在一个物理的 Spark Streaming 管道中同时跑多个不同业务逻辑的 Flow。所以理论上讲，比如有 1000 个不同的 Source 表，经过 1000 个不同的流式处理，最后要得出 1000 个不同的结果表，可以只在 Wormhole 中发起一个 Spark Streaming，在里面跑 1000 个逻辑的 Flow 来实现。当然这样做的话可能会导致每个 Flow 延迟加大，因为都挤在同一个管道里，但这里的设置是很灵活的，我可以让某一个 Flow 独占一个 VIP 的 Stream，如果有些 Flow 流量很小，或者延迟对其影响不那么大的话，可以让它们共享一个 Stream。灵活性是 Wormhole 一个很大的特点。
• Wormhole 有自己的一套指令和反馈体系，用户不用重启或停止流，就可以动态地在线更改逻辑，并且实时拿到作业和反馈结果等。

3.1.3 ABD-Moonbox

Moonbox（计算服务平台），是一个 DVtaaS（Data Virtualization as a Service）平台解决方案。

Moonbox 面向数据仓库工程师 / 数据分析师 / 数据科学家等，基于数据虚拟化设计思想，致力于提供批量计算服务解决方案。Moonbox 负责屏蔽底层数据源的物理和使用细节，为用户带来虚拟数据库般使用体验，用户只需通过统一 SQL 语言，即可透明实现跨异构数据系统混算和写出。此外 Moonbox 还提供数据服务、数据管理、数据工具、数据开发等基础支持，可支撑更加敏捷和灵活的数据应用架构和逻辑数仓实践。

开源地址：https://github.com/edp963/moo…

图 10 Moonbox 功能及定位

数据从 DBus 过来，经过 Wormhole 的流式处理，可能落到不同的数据存储中，我们需要对这些数据进行混算，Moonbox 支持多源异构系统无缝混算。上图展示了 Moonbox 的功能特性。

平时所说的即席查询并没有真正做到“即席”，因为需要用户先手工地把数据导到 Hive 再做计算，这是一个预置的工作。Moonbox 不需要事先把数据导到一个地方去，做到了真正的即席查询。数据可以散落到不同的存储中，当用户有需求时，只需写一个 SQL，Moonbox 可以自动拆分这个 SQL，从而得知哪些表在哪里，然后规划 SQL 的执行计划，最终拿到结果。

Moonbox 对外提供标准的 REST、API、JDBC、ODBC 等，因此也可以将之看成一个虚拟数据库。

图 11 Moonbox 架构

上图展示的是 Moonbox 的架构图。可以看到 Moonbox 的计算引擎部分也是基于 Spark 引擎做的，并没有自研。Moonbox 对 Spark 进行扩展和优化，增加了很多企业级的数据库能力，比如用户、租户、权限、类存储过程等。

从上图看，Moonbox 整个服务端是一个分布式的架构，所以它也是高可用的。

3.1.4 ABD-Davinci

Davinci（可视应用平台），是一个 DVaaS（Data Visualization as a Service）平台解决方案。

Davinci 面向业务人员 / 数据工程师 / 数据分析师 / 数据科学家，致力于提供一站式数据可视化解决方案。既可作为公有云 / 私有云独立部署使用，也可作为可视化插件集成到三方系统。用户只需在可视化 UI 上简单配置即可服务多种数据可视化应用，并支持高级交互 / 行业分析 / 模式探索 / 社交智能等可视化功能。

开源地址：https://github.com/edp963/dav…

图 12 Davinci 功能及定位

Davinci 是一个可视化工具，所具备的功能特性如图所示。

图 13 Davinci 架构

从设计层面来看，Davinci 有自己的完备和一致性的内在逻辑。包括 Source、View、Widget，支持各种数据可视化应用。

图 14 Davinci 富客户端应用

Davinci 是一个富客户端的应用，所以主要还是看它前端的使用体验、丰富性和易用性等。Davinci 支持图表驱动和透视驱动两种模式编辑 Widget。上图是一个透视驱动的效果样例，可以看到横纵坐标都是透视的，它们会将整个图切成不同的单元格，每个单元格里可以选择不同的图。

3.2 ABD 架构

图 15 ABD 架构

在 ABD 时代，我们通过 DIY 组合四个开源工具来支持各种各样的数据应用需求。如上图所示，将整个端到端的流程串起来，这个架构图展示了我们“有收有放把整个链路打通”的理念。

• 收。比如采集、架构、流转、注入、计算服务查询等功能，需要收敛集合成一个平台。
• 放。面对复杂的业务环境，数据源也是各种各样的无法统一，很难有一个存储或数据系统可以满足所有的需求，使得大家不再需要选型。因此这一块的实践是开放的，大家可以自主选择开源工具和组件来适配和兼容。

3.3 ADX 总览

发展到一定阶段时，我们需要一个一站式的平台，把基础组件封装起来，使得用户可以在这个平台上更简单地完成数据相关的工作，于是进入了 ADX 数据中台建设阶段。

图 16 ADX 总览

上图是 ADX 总览，相当于一个一级功能菜单。用户登录到平台，可以做以下事情：

• 项目看板：可以看到所在项目的看板，包括健康情况等各方面的统计情况。
• 项目管理：可以做项目相关的管理，包括资产管理、权限管理、审批管理等。
• 数据管理：可以做数据方面的管理，比如查看元数据，查看数据血缘等。
• 数据申请：项目配置好了，数据也了解了，可以做实际工作了。基于安全和权限考虑，并不是谁都可以去用放在里面的数据，因此首先要做数据申请。右边蓝色模块是本次分享将重点介绍的 ADX 数据中台的五大功能模块。数据申请更多是由 DataHub 数据枢纽来实现的，它支持自助申请、发布、标准化、清洗、脱敏等。
• 即席查询、批量作业、流式作业是基于 DataWorks 数据工坊实现的。
• 数据模型是基于 DataStar 这个模型管理平台来实现的。
• 应用市场包括数据可视化（数据加工完之后可以配置最终展现样式为图或仪表板等，这里可能用到 Davinci）；标签画像、行为分析等常见分析方法；智能工具箱（帮助数据科学家更好地做数据集分析、挖掘和算法模型的工作）以及智能服务、智能对话（比如智能聊天机器人）等。

3.3.1 ADX-DataHub 数据枢纽

图 17 DataHub 工作流程

上图蓝色虚线框显示的是 DataHub 的流程架构，橙色方块是我们的开源工具，其中“tria”代表 Triangle，是宜信另一个团队研发的作业调度工具。
DataHub 不是简单地封装了链路，而是使得用户可以在一个更高的 level 上得到更好的服务。比如用户需要某一历史时刻精确到秒的快照，或者希望拿到一个实时增量数据去做流式处理，DataHub 都可以提供。

它是怎么做到的呢？通过将开源工具引擎化，然后进行整合。举个例子：不同数据源，通过 DBus 实时抽取出来，经过 Wormhole 流式处理后落到 HDFS Log 数据湖中，我们把所有实时增量数据都存储在这里面，这就意味着我们可以从中拿到所有的历史变更数据，而且这些数据还是实时同步的。再通过 Moonbox 在上面定义一些逻辑，当用户提出想要某一历史时刻的快照或者增量数据，就可以即时计算并提供。如果想做实时报表，需要把数据实时快照维护到一个存储里，这里我们选择 Kudu。

流式处理有很多好处，同时也有短板，比如运维成本较高、稳定性较差等。考虑到这些问题，我们在 DataHub 中设置了 Sqoop 作为 Plan B。如果实时这条线晚上出现问题，可以自动切换到 Plan B，通过传统的 Sqoop 去支持第二天 T + 1 的报表。等我们找到并解决问题之后，Plan B 就会切换到暂停状态。

假设用户自己有数据源，放在 Elasticsearch 或者 Mongo 里，也希望通过 DataHub 发布出去共享给其他人使用。我们不应该把 Elasticsearch 数据或 Mongo 数据物理地拷贝到一个地方，因为首先这些数据是 NoSQL 的，数据量比较大；其次用户可能希望别人通过模糊查询的方式去使用 Elasticsearch 数据，那可能继续将数据放在 Elasticsearch 里更好。这时我们做的是通过 Moonbox 进行一个逻辑的发布，但用户不感知这个过程。

综上可以看出，DataHub 是在内部把几个开源平台常用的模式进行有机整合和封装，对外提供一致性、便捷的数据获取、发布等服务。其使用方也可以是各种不同的角色：

• 数据拥有方可以在这里做数据审批；
• 数据工程师可以申请数据，申请完后可以在这里对数据进行加工；
• APP 用户可以查看 Davinci 报表；
• 数据分析师可以直接用自己的工具去接 DataHub 出来的数据，然后做数据分析；
• 数据用户可能希望自己做一个数据产品，DataHub 可以为他提供接口。

图 18 DataHub 架构

如图，将 DataHub 打开，来看其架构设计。从功能模块角度来看，DataHub 基于不同开源组件，实现不同功能。包括批量采集、流式采集、脱敏、标准化等，还可以基于不同的协议输出订阅。

DataHub 与其他几个组件之间的关系也是非常紧密的。它输出的数据给 DataWorks 使用，同时它又依赖中台管理、数据管理来满足其需求。

3.3.2 ADX-DataLake 实时数据湖

广义的数据湖，就是把所有数据都放在一起，先以存储和归集为主，使用的时候再根据不同数据提供不同使用方式。

我们这里提到的是一个狭义的数据湖，只支持结构化数据源和自然语言文本这两种类型的数据归集，并且有统一的方式存储。

图 19 DataLake

也就是说我们的实时数据湖加了限制，公司所有结构化数据源和自然语言文本会统一实时汇总为 UbiLog，并由 ADX-DataHub 统一对外提供访问。UbiLog 的访问和使用只能通过 ADX 提供的能力输出，因此确保了多租户、安全、权限管控。

3.3.3 ADX-DataWorks 数据工坊

主要的数据加工都是在 DataWorks 自助完成的。

图 20 DataWorks 工作流程

如图来看 DataWorks 的工作流程。首先 DataHub 数据出来之后，DataWorks 必须去接 DataHub 的数据。DataWorks 支持实时报表，我们内部使用的是 Kudu，所以把这个模式固化下来，用户就不用自己去选型，直接在上面写自己的逻辑就可以了。比如有一个实时 DM 或批量 DM，我们觉得这是一个很好的数据资产，有复用价值，希望别的业务能复用这个数据，我们就可以通过 DataHub 把它发布出去，别的业务就可以申请使用。

所以 DataHub 和 DataWorks 等组件封装而成的数据中台可以达到数据共享和数据运营的效果。中台内部包含 Kudu、Kafka、Hive、MySQL 等数据库组件，但是用户不需要自己去选型，我们已经做出了最佳选择，并将其封装成一个可直接使用的平台。

上图左侧有一个数据建模师的角色，他在 DataStar 中做模型管理和开发建设，在 DataWorks 中主要是负责逻辑和模型的创建；数据工程师不用多说，是最常见的使用 DataWorks 的角色；终端用户可以直接使用 Davinci。

图 21 DataWorks 架构

如图，将 DataWorks 打开来看它的架构，同样 DataWorks 也是通过不同的模块来支持各种不同的功能。关于这部分内容以后会有更多的文章和分享，此处不详细介绍。

3.3.4 ADX-DataStar 数据模型

图 22 DataStar 工作流程

DataStar 跟数据指标模型或数据资产相关，每个公司都有自己内部的数据建模流程和工具。DataStar 可以分为两个部分：

• 模型设计、管理创建。对模型生命周期的管理和工艺流程的沉淀。
• 从 DW（数仓）层到 DM（数据集市）层，支持配置化的方式，自动在底下生成对应 SQL 逻辑，而不需要用户自己去写。

DataStar 是 DW 层的事实和维度表组成的星型模型，可以最后沉淀下来。但我们认为，从 DW 层到 DM 层或 APP 层，不需要写 SQL 开发了，只需要通过选维度和配置指标的方式，就可以自动可视化配置出来。

这样的话对使用人的要求就发生了改变，需要一个建模师或者业务人员来做这个事情，给他一个基础数据层，他根据自己的需求来配置想要的指标。整个过程，数据实施人员只需要关注 ODS 层到 DW 层就可以了。

3.3.5 ADXMgt/DataMgt 中台管理 / 数据管理

图 23 ADXMgt/DataMgt

中台管理模块主要关注租户管理、项目管理、资源管理、权限管理、审批管理等。数据管理模块主要关注数据管理层或数据治理层的话题。这两个模块从不同的维度对中间的三个主要组件提供支持和产生规则制约。

3.4 ADX 架构

图 24 ADX 架构

ADX 数据中台平台几个模块之间的关联如图所示。最底下是五个开源工具，每个模块都是对这五个开源工具的有机整合和封装。从图中可以看出各组件之间的关联非常紧密，其中黑色虚线代表的是依赖关系，绿色线条代表的是数据流转的关系。

四、典型案例分析

如上所述，我们基于开源工具进行有机整合和封装，打造了一个更加现代化、自助化、完备的一站式数据中台平台。那这个平台是如何发挥其作用，为业务提供服务的呢？本节将列举五个典型案例。

4.1 案例 1 — 自助实时报表

【场景】

业务领域组数据团队需要紧急制作一批报表，不希望排期，希望可以自助完成，并且部分报表需要 T + 0 时效性。

【挑战】

• 业务组数据团队工程能力有限，只会简单 SQL，之前要么转给 BI 排期，要么通过工具直连业务备库制作报表，要么通过 Excel 制作。
• 数据来源可能来自异构数据库，没有很好的平台支持自助导数。
• 对数据时效性要求很高，需要流上做数据处理逻辑。

【方案】

图 25 自助实时报表工作流程

用 ADX 数据中台解决自助实时报表的问题。

• 数据工程师登录平台，创建新的项目，申请数据资源。
• 数据工程师通过元数据查找选出表，选择 DataWorks 方式使用，填写其他信息，申请这些需要用到的表。比如我需要用到 100 张表，其中 70 张是通过 T + 1 的方式使用，30 张是通过实时方式使用。
• 默认中台会做标准化脱敏加密策略，收到这些申请之后，中台管理员会按策略依次进行审批。
• 审批通过后，中台会自动准备和输出所申请的数据资源，数据工程师可以运用拿到的数据资源进行自助查询、开发、配置、SQL 编排、批量或流式处理、配置 DV 等。
• 最后将自助报表或仪表板提交给用户使用。

【总结】

• 各个角色通过一站式数据中台交互，统一流程，所有动作都记录在案，可查询。
• 平台全自助能力，大大提高了业务数字化驱动进程，无需排期等待，经过短暂培训，人均 3- 5 日可以自助完成一张实时报表，实时报表不再求人。
• 平台支持人员也无需过多参与，不再成为进度瓶颈。

【能力】

这个场景需要用到很多数据能力，包括：即席查询能力、批量处理能力、实时处理能力、报表看板能力、数据权限能力、数据安全能力、数据管理能力、租户管理能力、项目管理能力、作业管理能力、资源管理能力。

4.2 案例 2 — 协作模型指标

【场景】

业务线需要打造自己的基础数据集市，以共享给其他业务或者前线系统使用。

【挑战】

• 如何有效建设数据模型和管理数据模型。
• 如何既支持自己领域内数据模型建设，同时也支持数据模型的共享。
• 数据的共享发布如何从流程上固化、并实现技术安全统一管控。
• 如何运营数据以确保有效数据资产沉淀和管理。

【方案】

图 26 协作模型指标工作流程

用 ADX 数据中台解决协作模型指标的问题。

• 数据建模师登录平台，创建新项目，申请资源。然后查找选出表，设计一个或若干个维度表的 DW 模型，推送到 DataWorks 项目。
• 数据工程师选择需要的 Source 表，基于 DataStar 项目完成从 ODS 到 DW 之前的 ETL 开发，然后提交作业，发布到 DataHub 跑起来。
• 数据建模师持续可视化配置维护和管理 DW/APP 层指标集，包括维度的聚合、计算等。

【总结】

• 这是一个典型的数据资产管理、数据资产运营的案例，通过统一的协作化的模型指标管理，确保了模型可维护、指标可配置、质量可追溯。
• DataStar 也支持一致性维度共享、数据词典标准化、业务线梳理等，可以进一步柔性支持公司统一数据基础层的建设和沉淀。

【能力】
本案例需要的能力包括：数据服务能力、即席查询能力、批量处理能力、数据权限能力、数据安全能力、数据管理能力、数据资产能力、租户管理能力、项目管理能力、作业管理能力、资源管理能力。

4.3 案例 3 — 敏捷分析挖掘

【场景】

业务领域组数据分析团队需要自助的进行快速数据分析挖掘。

【挑战】

• 分析团队使用工具各异，如 SAS、R、Python、SQL 等。
• 分析团队往往需要原始数据进行分析（非脱敏），并且需要全历史数据。
• 分析团队希望可以快速拿到所需数据（往往并不知道需要什么数据），并敏捷高效专注于数据分析本身。

【方案】

图 27 敏捷分析挖掘工作流程

用 ADX 数据中台解决敏捷分析挖掘的问题。

• 数据分析师登录平台，创建新项目，申请资源。根据需求查找选出表，选择习惯的工具使用方法，填写其他信息，申请使用。
• 各方按照策略依次审批。
• 审批通过后，数据分析师获得资源，利用工具进行自助分析。

【总结】

• Moonbox 本身是数据虚拟化解决方案，很适合进行各种异构数据源的即席数据读取和计算，可以节省数据分析师很多数据工程方面的工作。
• Datahub/DataLake 提供了实时同步的全增量数据湖，还可以进行配置化脱敏加密等安全策略，为数据分析场景提供了安全可靠全面的数据支持。
• Moonbox 还专门提供了 mbpy（Moonbox Python）库，以支持 Python 用户更容易的在安全管控下进行快速无缝地数据查看、即席计算和常用算法运算工作。

图 28 敏捷分析挖掘示例

举个例子，一个用户打开 Jupyter，import 一个 mbpy 的库包，并以用户身份登录 Moonbox，就可以查看管理员授权给他的表。他可以运用拿到的数据和表进行分析、计算等，而不需要关注这些数据来自哪里，这对用户来说是一个无缝的体验。

如上图，有两张表，一张表是 5000 多万条数据，存储在 Kudu 里；另一张表是 600 万多条数据，存储在 Oracle 里。数据存储在异构的系统中，且 kudu 本身不支持 SQL。我们通过 Moonbox 制定逻辑，认为数据都在一个虚拟数据库中，只用了 1 分 40 秒就计算出结果。

【能力】

本案例需要的能力包括：分析钻取能力、数据服务能力、算法模型能力、即席查询能力、多维分析能力、数据权限能力、数据安全能力、数据管理能力、租户管理能力、项目管理能力、资源管理能力。

4.4 案例 4 — 情景多屏联动

【场景】

为了支持全方位的场景化和数字化驱动，有时会需要大中小智多屏联动，大屏即为放映大屏，中屏即为电脑屏幕，小屏即为手机屏幕，智屏即为聊天客户端屏幕。

【挑战】

• 多屏由于定位不同，展示大小不同，操作不同，可以要求不同程度的可视化和定制化，带来一定开发量。
• 多屏也需要在数据权限层面保持高度一致。
• 其中智屏更需要 NLP、聊天机器人和任务机器人等智能能力，还需要有动态生成图表能力。

【方案】

• 通过 Davinci 的 Display 功能，可以很好支持配置化满足大小屏定制化需求。
• 通过 Davinci 统一数据权限体系，可以在多屏之间保持一致的数据权限条件。
• 通过 ConvoAI 的 Chatbot/NLP 能力，可以支持智能微 BI 能力，即为智屏。

图 29 Davinci 的 Display 编辑页面

上图展示的是 Davinci 的 Display 编辑页面，可以通过挑选不同的组件、调整透明度、任意摆放位置、调前景背景、颜色缩放比例等，自由地定义想要的展示样式。

图 30 Davinci 配置大屏

上图是 Davinci 配置大屏的例子，（图片来源于 Davinci 开源社区网友的实践，数据经过处理），可以看到通过 Davinci 可以自己配置大屏，不需要开发。

图 31 Davinci 配置小屏

上图展示的是 Davinci 配置小屏的示例。图片来源于宜信的尊享年会。现场工作人员通过手机查看实时数据，了解现场情况。

图 32 智屏

上图展示的是智屏的示例。我们公司内部有一个基于 ConvoAI 的聊天机器人，可以通过一个聊天窗口，跟用户互动，针对用户需求返回结果，包括图表等。

4.5 案例 5 — 数据安全、管理

图 33 数据安全管理工作流程

这个案例比较简单，一个完备的数据中台，不仅有应用客户场景，还有管理客户场景，管理客户典型的比如数据安全团队和数据委员会。

• 数据安全团队需要管理安全策略、扫描敏感字段、审批数据资源申请等。宜信敏捷数据中台提供自动扫描功能，及时将扫描结果返回给安全团队人员确认。安全团队也可以定义几层不同的安全策略、查看审计日志、调查数据流转链路等。
• 数据委员会需要做数据调研、数据地图查看、血缘分析、制定标准化和流程化的清洗规则等。他们同样可以登录数据中台，完成这些工作。

五、总结

本次分享主要介绍了宜信敏捷数据中台的顶层设计和定位、内部的模块架构和功能、以及典型应用场景与案例。我们立足于宜信业务需求现状与数据平台发展背景，基于五大开源工具进行有机组合和封装，结合敏捷大数据的理念，打造适合宜信自己业务的一站式敏捷数据中台，并在业务及管理中得以应用与落地，希望能为大家带来启发和借鉴。

Q&A：

Q：企业能纯粹依靠开源社区的开源工具来搭建数据中台吗？

A：数据中台是要切合企业实际情况和目标去建设的，有些好的开源工具本身已经很成熟，不需要重复造轮子，同时也有一些企业根据自身环境和需求，需要定制化开发。所以一般数据中台都会既有开源工具选型，也会有结合自身情况的企业内通用组件的开发。

Q：数据中台建设中，需要避免哪些弯路、哪些坑？

A：数据中台比纯技术平台要求更多直接赋能业务的能力建设，如数据资产沉淀、数据服务建设、数据加工流程工艺抽象、企业数据标准化安全化管理等，这些可能都无法依靠纯技术驱动自下而上地推动，而是需要公司层面和业务层面达成一致认识和支持，并且由业务实际需求驱动数据中台迭代建设的。这样的自上而下和自下而上相结合的迭代方式，可以有效避免不必要的短视和过度设计。

Q：数据中台建设完毕，其成熟度和效果如何评估？

A：数据中台的价值由驱动的业务目标来衡量。定性来说，就是是否真正做到了快、准、省的效果；定量来说，可以通过平台组件复用度、数据资产复用度、数据服务复用度等指标来评估成熟度。

Q：平台的元数据是怎样管理的？

A：元数据是一个独立的大话题，从元数据类目划分，到如何采集维护各种元数据，再到如何基于元数据信息打造各种元数据应用等，是可以单独拿出一个完整的分享来探讨的。具体到宜信 ADX 的元数据管理，我们也是按照上述思路进行，先是整理出全景元数据类目划分，然后很重要的一点是“业务痛点驱动元数据体系建设“，我们会根据目前公司对元数据最迫切的需求圈定优先级，然后在技术层面可以通过 Moonbox 进行各种数据源的基础技术元数据采集，基于 Moonbox 的 SQL 解析能力来生成执行血缘关系等，最后根据业务的实际痛点，比如上游源数据表结构变更会如何影响下游数据应用（血缘影响度分析），下游数据问题如何追溯上游数据流转链路（数据质量诊断分析）等，迭代的开发一个个元数据应用模块。

Q：数据建模师建模的方法论是什么？和数仓的维度建模有什么区别？

A：我们的建模方法论也是基于著名的《数据仓库工具箱》来指导建设的，并且根据宜信实际情况，对 Kimball 的维度建模进行了一定的简化、标准化、通用化设计，同时也参考了阿里的 OneData 体系的经验，这块我们并无太多独创性。DataStar 更重要的目标，还是如何易用、有效的吸引和帮到数据建模师，从流程上能够让模型建设统一化、线上化、管理化，同时力求减少 ETL 开发人员负担，将 DW 到 DM/APP 层的个性化指标工作通过配置化下放给非数据开发人员自助完成。所以 DataStar 整体上还是以管理和提效为主要目标的。

Q：Triangle 任务调度系统是开源的么？

A：Triangle 是另一个团队研发维护的，他们有开源计划，具体何时开源我们还太确定。

Q：Davinci 何时发版？

A：这是个永恒的问题，感谢大家对 Davinci 的持续关注和认可，我们有计划将 Davinci 推到 Apache 孵化，所以希望大家可以一如既往地支持 Davinci，让 Davinci 成为最好的开源可视化工具选择。

Q：数据服务是管控了所有的数据读取写入吗？最好的情况是所有业务方都可通过数据服务访问数据，这样的话数据管理、链路、地图就比较容易做。问题是很多情况下知道连接信息的话，业务方是可以直连的，怎么避免业务方自己使用 API 直连？

A：是的，DataHub 的目标就是统一收口数据归集、数据申请、数据发布、数据服务，这样像数据安全管理、链路管理、标准化管理等都更容易实现了。如何避免业务方绕过 DataHub 直连源库，这个恐怕要在管理流程上管控了，对于 DataHub 本身，由于 DataHub 封装了实时数据湖，使得 DataHub 拥有了直连业务备库所有不具备的能力特性，加上持续提升 DataHub 使用体验和功能，相信业务方会更加愿意从 DataHub 对接数据的。

Q：DBus 支持 Postgres 数据源吗?

A：DBus 目前支持 MySQL、Oracle、DB2、日志、Mongo 数据源，其中 Mongo 由于本身日志的特点使得 DBus 只能接出非完整增量日志（只有更新的列会输出），这样对强顺序消费就提出了很高要求，内部来说没有太多 DBus 接 Mongo 的场景。社区有提出 DBus 对接 PostgreSQL 和 SQLServer 的需求，理论上都是可以扩展对接的，但目前团队都投入在数据中台建设上，更多数据源类型的对接，如果有需要的话，可以直接联系我们团队讨论。

Q：Moonbox 的底层是用 Spark SQL 实现的这种混合计算，需要消耗很多资源，是怎么优化的呢？

A：Moonbox 的混算引擎是基于 Spark 的，并对 Spark 做了一些优化工作，其中最大的一块优化就是支持了更多计算下推（Pushdown），Spark 本身也具备数据联邦混算能力，但 Spark 只支持部分算子下推，如 Projection 和 Predict，Moonbox 对 Spark 做了旁路扩展，支持更多如 Aggregation、Join、Union 等算子下推，并且在解析 SQL 时会根据数据源计算特点进行有策略的下推执行计划，尽量让数据源做更适合的计算工作，减少在 Spark 里混算的计算成本。

Moonbox 还支持如果 SQL 本身没有混算逻辑，且数据源适合整个 SQL 计算，Moonbox 可以绕过 Spark 直接将全 SQL 做整体下推到数据源。另外，Moonbox 支持 Batch 计算、分布式 Interactive 计算和 Local Interactive 计算模式，每种都做了不同的优化和策略。

Q：离线计算和实时计算是怎么配合的，离线计算可以做分层存储，实时计算怎么实现分层存储？  

A：实时计算分层，有一种做法是通过 Kafka 来做，当然如果对实时分层数据的时效性要求不太高（如分钟级）的话，也可以选择一些实时 NoSQL 存储，如 Kudu。“离线计算和实时计算怎么配合“，有了 Moonbox，其实不管批量计算和流式计算的数据存储在哪里，都可以通过 Moonbox 做无缝混算的，可以说 Moonbox 简化并抹平了很多数据流转架构的复杂性。

Q：中台的定位是什么，会不会又是一个 buzzword？在宜信内部，数据中台跟传统后台的关系是怎样的？

A：宜信数据中台的定位在演讲开头已经谈到了，简单来说就是对下层做统一化管理化透明化，对中层做通用化标准化流程化，对上层做资产化服务化自助化。Buzzword 这个也是要一分为二的看，有些浪潮留下的更多是教训，有些浪潮带来的更多是进步。“数据中台跟传统后台的关系“，这里传统后台我理解是指业务后台吧，好的业务后台可以更好配合和支持数据中台，不好的业务后台会把更多数据层面的挑战留待数据中台去面对和解决。

Q：数据异构存储在如此多的存储组件中，如何保证个性化查询的效率？

A：这个问题应该是指 Moonbox 这种体系架构，如何保证即席查询效率。纯即席查询（源数据直接计算出结果），查询效率怎样都不会拼过内存型 MPP 查询引擎的。对于我们来讲，Moonbox 主要用于统一批量计算入口、统一即席查询入口、统一数据服务、统一元数据归集、统一数据权限、统一血缘关系生成、统一数据工具箱等。如果追求毫秒级 / 秒级查询效率，要么采用预计算引擎如 Kylin、Druid 等、要么 ES、Clickhouse 等，但这些都有个前提，就是基础数据都已经准备好。因此我们的数据中台链路，是支持 ETL 之后将 DW/DM 数据物理写入 ES、Clickhouse 并统一 DataHub 发布的，这样可以一定程度上保证“个性化“查询效率。单纯从 Moonbox 角度而言，在异构存储上进行分钟级 / 小时级的预计算并将结果写入 Clickhouse，可以支持分钟级 / 小时级数据延迟，毫秒级 / 秒级查询延迟。

Q：如果有新的数据进入系统，整个数据采集到进入存储的过程是由开发人员控制，还是专门的数据管理人员通过界面组合各个组件 Pattern 来控制？

A：如果新数据源来自业务数据库备库，DBus 已经对接了此备库前提下，会有专门的数据中台管理员在数据中台管理界面上配置发布新的 ODS，以供下游使用方在 DataHub 上申请并使用；如果新数据源来自业务自有 NoSQL 库，业务人员可以自助地在 DataHub 上发起发布数据流程，然后下游使用方可以在元数据上看到并在 DataHub 上申请并使用。

所谓“数据采集到存储“，也是分为实时采集、批量采集、逻辑采集等的，这些常用数据源类型、数据对接方式、用户使用方式等都被 DataHub 封装整合在内，不管是数据拥有方还是数据使用方面对的都是一站式的 DataHub 用户界面，所有的数据链路 Pattern、自动化流程和最佳技术选型和实践都被透明化封装在 DataHub 里，这也是工具化到平台化的价值所在。

来源：宜信技术学院

拓展阅读：【宜信技术沙龙 01 期】AI 中台：一种敏捷的智能业务支持方案