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

时间 2019-11-06

原文原文链接

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

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

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

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

分享大纲：算法

1、导语数据库

2、宜信数据中台顶层设计安全

3、从中间件工具到平台架构

4、典型案例分析框架

5、总结运维

6、Q&A

视频回放地址：v.qq.com/x/page/r087…

PPT下载地址：pan.baidu.com/s/1jRumFMj_…

1、导语

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

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

本次分享分为三个部分：

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

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

2.1 特色和需求

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

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

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

2.2 定位

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

前文提到宜信业务线不少，且在众多业务中没有一个主体业务，这就至关于全部业务线都是主体。基于这样的背景，咱们须要一个平台化的数据中台，来支撑全部业务线的需求和运做。

图1 定位

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

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

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

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

2.3 价值

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

图2 价值

存在的问题	敏捷数据中台之“快”
定制化需求形成重复开发	平台化，透明封装复用技术组件
内包实施团队需排期	自助化，简单配置，月=>天
T+1延时知足不了实时及精细化运营	实时化，驱动业务增加，天=>分

存在的问题	敏捷数据中台之“准”
数据存储各异，取数方式各异，清洗逻辑各异	统一化，统一数据湖归集和出口
数据孤岛未打通整合	管理化，元数据、数据地图、血缘
需求驱动实施，没法沉淀数据资产	资产化，模型管理让数据可信赖，标准化模型加工促使数据资产沉淀

存在的问题	敏捷数据中台之“省”
时间成本，需求排期和重复开发	自助化，节省时间就是节省成本
人力成本，重复开发和缺乏复用	平台化，成熟技术组件高复用度
硬件成本，集群资源滥用形成浪费	精细化，集群资源可估可查可量化

2.4 模块架构维度

图3 模块架构维度

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

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

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

2.5 数据能力维度

图4 数据能力维度

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

3、从中间件工具到平台

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可充当数仓平台、大数据分析平台、实时报表和实时营销等业务的数据源。

开源地址：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的业务开发方式，屏蔽底层技术实现细节，极大的下降了开发门槛，使得大数据流式处理项目的开发和管理变得更加轻量敏捷、可控可靠。

开源地址： github.com/edp963/worm…

图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还提供数据服务、数据管理、数据工具、数据开发等基础支持，可支撑更加敏捷和灵活的数据应用架构和逻辑数仓实践。

开源地址： github.com/edp963/moon…

图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上简单配置便可服务多种数据可视化应用，并支持高级交互/行业分析/模式探索/社交智能等可视化功能。

开源地址：github.com/edp963/davi…

图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、典型案例分析

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

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 数据安全管理工做流程

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

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

5、总结

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

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、DB二、日志、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中台：一种敏捷的智能业务支持方案