数据中台：宜信敏捷数据中台建设实践

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

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

一、导语

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

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

本次分享分为三个部分：

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

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

1. 特点和需求

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

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

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

2. 定位

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

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

图1 定位

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

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

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

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

3.  价值

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

图2 价值

4.  模块架构维度

图3 模块架构维度

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

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

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

5.  数据能力维度

图4 数据能力维度

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

三、从中间件工具到平台

1.  ABD总览

图5 ABD总览

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

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

(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有具体介绍，此处不作展开。)

(2) ABD-Wormhole

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

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

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

图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) ABD-Moonbox

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

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

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

图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整个服务端是一个分布式的架构，所以它也是高可用的。

(4) ABD-Davinci

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

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

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

图12 Davinci功能及定位

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

图13 Davinci架构

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

图14 Davinci富客户端应用

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

2.  ABD架构

图15 ABD架构

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

收。比如采集、架构、流转、注入、计算服务查询等功能，需要收敛集合成一个平台。

放。面对复杂的业务环境，数据源也是各种各样的无法统一，很难有一个存储或数据系统可以满足所有的需求，使得大家不再需要选型。因此这一块的实践是开放的，大家可以自主选择开源工具和组件来适配和兼容。

3. ADX总览

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

图16 ADX 总览

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

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

(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使用，同时它又依赖中台管理、数据管理来满足其需求。

(2) ADX-DataLake实时数据湖

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

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

图19 DataLake

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

(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也是通过不同的模块来支持各种不同的功能。关于这部分内容以后会有更多的文章和分享，此处不详细介绍。

(4) ADX-DataStar数据模型

图22 DataStar工作流程

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

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

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

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

(5) ADXMgt/DataMgt中台管理/数据管理

图23 ADXMgt/DataMgt

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

4.  ADX架构

图24 ADX架构

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

四、典型案例分析

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

1. 案例1 — 自助实时报表

【场景】

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

【挑战】

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

【方案】

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

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

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

【总结】

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

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

2.  案例2 — 协作模型指标

【场景】

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

【挑战】

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

【方案】

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

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

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

【总结】

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

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

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 — 情景多屏联动

【场景】

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

【挑战】

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

【方案】

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

图29 Davinci的Display编辑页面

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

图30 Davinci配置大屏

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

图31 Davinci配置小屏

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

图32 智屏

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

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

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

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

数据安全团队需要管理安全策略、扫描敏感字段、审批数据资源申请等。宜信敏捷数据中台提供自动扫描功能，及时将扫描结果返回给安全团队人员确认。安全团队也可以定义几层不同的安全策略、查看审计日志、调查数据流转链路等。

数据委员会需要做数据调研、数据地图查看、血缘分析、制定标准化和流程化的清洗规则等。他们同样可以登录数据中台，完成这些工作。

五、总结

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

【本文是51CTO专栏机构宜信技术学院的原创文章，微信公众号“宜信技术学院( id: CE_TECH)”】

戳这里，看该作者更多好文