​火山引擎DataLeap一站式数据治理平台架构

在字节跳动内部,DataLeap数据平台数据治理团队致力于建立一站式、全链路的数据治理解决方案平台。

整体架构

首先在整体的架构部分,这是治理平台内整体的架构图。

其中灰色的部分是在平台透出给用户的产品能力,包括治理全景。治理全景对应于刚才在一站式的视图层能够告诉用户,有哪些资产,这些资产的情况是怎么样的。然后是治理的工作台。工作台的部分是针对于治理的实施者,他能够快速定位或者跳跃到相关一些治理的方案和平台去进行治理。这个是一些包括待办项和这些资产的分析等等。之后是一些诊断规划的部分。也就是服务于主动式规划这条路径的一个模块。它会对我们这些资产进行一些规则式的组合,来进行一个最终的诊断。还有一些资源的优化,报警与订阅和SLA保障等几个垂直类的治理场景。最后有一个复盘管理部分,是做经验总结和沉淀的一个模块,以系统的方式进行记录。

中间的部分是基于全规则的思想,将存储规则、计算规则、质量规则和报警规则,呈现在平台里,让用户来进行自由圈选,达到灵活、全面的目的。

下面绿色层是系统组件层面的一些抽象服务,我们会针对数据治理的典型场景,在底层的基础设计上做一些抽象,达到灵活适新的规则或者治理场景的目的。

元数据建设

在数据治理里面,我们认为元数据其实是治理的核心,治理其实是需要元数据来去驱动的。在我们治理工作里面,元数据建设治理主要有以下五个方面:

第一,元数据的采集。我们会采集底层组件架构的一些数据,yarn队列,Hive、Spark、Flink等各种组件的数据,以及一些平台级的元数据采集,包括调度系统,数据地图、血缘、权限、任务、存储、数据应用等平台的一些元数据,在采集之后,会进行一些系统化的加工,我们遵循于数据仓的层级规范的建设来提升数据的应用性。同时,在加工的过程中也完全遵循于数据治理理念保障数据都是高质可靠。

第二,元数据应用。在元数据应用部分我们会通过元数据仓库为基础,给上游的产品平台提供更多应用的能力支持。

第三,分析部分。我们会制定很多业务的核心指标和一些内部指标,通过一些治理场景用户的行为分析来发掘一些潜在的数据问题。另外就是会在各个维度去建设各类分析看板。

第四,挖掘部分。这个是在数据上更高一层的应用,我们会推动一些挖掘算法和机制,去发现一些可治理的问题,比如我们可能会对于一些数据资产的相似性进行挖掘。基于历史数据对未来的一些预测,比如说一些数据表行数的不动值预测,一些提效的推荐类挖掘。

最后是元数据的开放部分。我们会和字节跳动内部各个数据团队来去合作共建按需开放,提供元数据能力。

产品模块

下面介绍平台侧的产品模块,同样也可以在火山引擎DataLeap产品中看到。

第一、治理全景。解决有哪些资产问题。目前在平台上有一些大盘,包括数据的SLA大盘、存储大盘、计算大盘、报警大盘等等,这些大盘针对于不同的治理场景会有一些不同维度的展示,包括一些数据趋势,一些占比列表,或者是一些聚合明细等数据。支撑治理全景的是我们底层的元数据仓库以及刚才说的数据应用的部分,对数据进行一些加工。

第二、健康分。我们希望健康分能够衡量资产的健康度,让资产持续健康。在健康分的建设里面,我们遵循几个步骤。第一是首先在健康分的建设里面,通过元数据仓库提供健康分的各维度的分析建设,包括一些成员排名。第二个部分是有了这些健康分之后提供更多的维度分析,以及扣分项分析,成本分析,能够将健康分拆解,拆分成可治理的这样的项目,有了这些可治理的项目之后,具体关联到一些数据治理的操作和方案的设计。比如,我们可以针对于一些健康分的扣分项,来跳转到一些垂直治理的场景界面来去进行一些操作设置或者是做一些规划式治理方案的关联。这个是健康分的一些思路。

在健康分的设计方面,我们遵循了一个三层架构的思路。首先第一层是比较大宏观的资产层。包括存储的健康分,计算健康分,数据质量等等。第二层是针对于这一类自办的一些聚合类指标,包括比如说存储健康分里面的无效数据,或者是高效存储的问题。计算健康分里面无效任务和高效计算的问题。数据质量方面的SLA或者是监控保障的问题。最后一层是比较详细的规则层。包括存储里面TTL设置,或者是无查询的一些资产。比如说计算里面的连续失败任务或者是资源利用率比较低的一些任务。数据质量里面的一些SLA的事故数或者是一些监控的缺失、无效报警等等。

在有了资产全景和看板之后,我们其实可以进行一些治理操作,对应于一站式里面的第二层治理操作的部分。前面介绍到我们其实有两种路径,第一类是规划类的路径,可能是从一个比较高的视角来去拆解治理的问题。这个路径里面,我们是要目标明确,过程可拆解,收益可量化,结果可验收。

系统设计

最后我们来说一下系统是如何来支撑规划式的架构呢?

规划式架构:

在底层的基础架构设计方面主要有几个模块。

首先在后端是一个主逻辑的操作部分,包括了刚才所说的规则,治理规则、治理域,一些圈选的能力,资产的查询和收益的统计,治理目标的制定,治理结果的查看,治理的催办和具体的治理操作。

支撑于后端逻辑的部分,有几个抽象的服务模块。第一个模块是数据查询服务,主要解决的一个问题是底层不同存储异构的适配。将这些原数据经过一些上层应用的加工,放到不同应用的存储里面来适应不同的查询类型。通过这个服务来进行一些解耦。这个服务里面数据的来源就是事件的收集服务,我们会做一些格式的转换,消息的处理,包括一些底层组件的关联和系统回调和数据采集等等。

同时与这个服务有关联的就是治理具体实施的模块,这个和系统里面治理的操作有关。

举个例子,比如进行一些表的生命周期设置,或者是删除表等等操作。这些操作都会以消息的形式,经由执行模块去进行一些任务的下发和底层的组件进行调用。通过一些状态来把治理是否得到一些收益,消息是否成功,也由刚才的事件收集服务来放到查询服务里面,形成收益可查询的数据。

最后在治理规则和治理域的部分,提供了全规则能力,这部分我们提供了一些规则引擎的服务,包括对规则进行一些解析、查询转换,查询提交以及结果汇总,这个是底层架构对于上述功能的一些支持。

响应式架构:

接下来是响应式的流程,这个和主动式的流程非常像。包括消息触发,问题分析,推进治理,问题登记,总结复盘等等流程。响应式流程的框架和规划其实也是非常像。

主要有几个不同的部分。第一是左侧有个消息服务,因为我们这个路径其实是以消息来处发的,我们会打通与研发平台,质量平台,自然平台等很多处发消息和报警的一些平台,将他们的消息和报警统一收归到我们这个服务里面进行下发。下发的渠道可以有,比如说字节跳动用的飞书,或者邮件、电话、短信等等。这些消息形成的一些数据也会经由数据的收集放到查询服务里面,去做一些报警的展示。另外在消息这里,我们会和复盘模块进行强关联,对问题进行登记核准复盘。

最后是工作台,主要为了提效,解决待治理项,比如说现在有一些待治理的部分需要去处理,能够尽快去发起这个治理或者说我个人的一些资产情况,这个是工作台的核心思想。

治理场景的部分主要有质量、数据SLA、资源和报警的部分。

在资源优化场景上的目标主要是能够提供自主分析和低门槛优化能力。

现在主要集中在存储和计算两个方面,并提供了很多的垂直治理的能力。比如,可以在平台里面直接设置一些这种温存、降副本、TTL设置。计算方面,可以直接跳转任务详情做分析,任务下线和参数调整建议等等。

最后也谈谈我们的未来工作展望,如图所示:

第一个方面是继续加强工具闭环能力。

第二个方面是从通用数据治理的问题解决到更精细化的一些治理,包括自定义的指标、方案,以业务的视角来看待实际的问题。

最后是增强型的数据治理,我们希望是能够在数据侧通过一些统计类、挖掘类,上升为一些算法和智能型的这种平台。