数据中台:宜信敏捷数据中台建设实践(下)

阅读数:1 2020 年 2 月 10 日 21:01

数据中台:宜信敏捷数据中台建设实践(下)

四、典型案例分析

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

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 里,这也是工具化到平台化的价值所在。

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

原文链接:

评论

发布