干货 | 字节跳动一站式数据治理解决方案及平台架构

原创开发套件团队字节跳动数据平台

扫码进入官方交流群

群内定期进行干货分享

技术交流、福利放送

字节跳动数据平台

在字节跳动内部，数据平台数据治理团队致力于建立一站式、全链路的数据治理解决方案平台。本文是字节跳动数据平台开发套件团队王慧祥参与的“数智有为第二期”在线分享的部分摘录。关注字节跳动数据平台微信公众号，回复【PPT】获得本次分享材料。

文 | 王慧祥 来自字节跳动数据平台开发套件团队

“一站式数据治理解决方案及平台架构”的分享会分为四个部分展开：

首先，明确数据治理的概念，从平台视角出发，介绍在字节跳动内部数据治理所服务的目标；
其次，介绍字节跳动内部数据治理的现状与我们需要解决的问题；
第三，介绍当前我们的解决方案；
最后分享一站式数据治理的平台架构。

数据治理的概念

数据治理是一种数据管理的概念，确保组织能在数据的全生命周期中具有高质量的数据质量能力，并且实现对数据的完全管理，以支持业务的目标。

在这里面有些关键词：在一些组织、一些公司内部关注的是数据全生命周期，希望它有一个较高的质量，目标则是用来支持业务。

所以数据治理的目标主要由以下几点构成：

第一，最大化数据价值。
第二，管理数据的风险。
第三，降低数据的成本。

数据治理是一个比较大的概念。它包括政策、规则、组织结构、治理过程，以及一些技术的支持。领域包括数据质量、数据成本、数据可用性以及数据安全等方面。

所以，在影响数据治理计划的驱动因素是多样的，比如说数据法规、隐私政策的限制，数据质量良莠不齐、数据治理成本高，或者是资源受限等等。此外，治理实施的方式和范围也不同，比如：有可能是由统一的组织，诸如数据治理委员会在整个企业或者公司的范围内发起一些治理目标与计划，来推动整个组织的数据治理；也可能是在一些部门、团队内部去进行有限范围内的治理。数据治理计划的目标实现必须得用适当的工具来解决，数据治理的方式也越来越倾向于朝着系统化和工具化的方向来发展。

字节跳动数据治理背景

在字节跳动内部，作为统一的数据治理平台方，我们的目标是：“建立一站式、全链路的数据治理解决方案平台”，治理平台肩负了四个使命：

第一，让数据价值最大化。这里面包括全生命周期数据质量的保障，既要做到高价值，又能实现低成本。

第二，提供全链路解决方案。数据治理在实际过程中会由多个不同角色共同参与，包括了管理者视角和执行者视角。我们希望不同的角色在我们的平台里，都能够运用一些工具、手段来推进治理的执行。

第三，工具和方法论的结合。字节跳动内部数据治理平台的建设是以方法论来引导建设，希望工具能够提供非常完备的治理能力。

第四，提供增强型的治理能力。在系统的能力上可以主动发现一些隐患问题，做一些推荐或者建议的策略来提升治理效率。

在字节内部，不同角色对数据治理的视角不同。比如，管理者或者是责任者的视角，他们可能会考虑如何去制定一些治理的目标，如何能够让组织、团队来去完成这些治理的指标；他们可能会关注于这个目标什么时候能够完成、进度如何；他们也会思考，当他们真得去做了这些治理之后，些数据或者资产是否能够持续健康。

而从执行者的视角上，则要考虑有数据治理目标下达之后，我该如何去做；我自己有哪些资产，资产有什么问题；我去做治理的时候，怎么样能够提高治理效率；我能不能及时发现数据资产的问题，并快速治理。

数据治理流程链路

因此在整个数据治理的流程中，遵循如下几个步骤：

第一：我有什么？比如我的计算任务，资产的存储，质量的一些规则，SLA的承诺或者一些异常报警，哪些是属于我的。

第二，清晰知晓治理目标。要知道我要去治理什么，从哪些开始下手，哪些资产是有问题的，我的一些规则是否是设置的合理的。

第三，怎么治理。比如在面临一个具体的治理问题，别人是如何治理的，他们是不是有一些相关的经验可以借鉴；在具体的实施过程里，如何去提效治理。

第四，衡量治理效果。也就是我们的治理是否达到了一些目标，或者获得了哪些收益。

最后，总结与复盘。做完了整个治理链路流程之后的总结，如经验总结、问题归纳等等。

数据治理解决方案

基于上述是数据治理流程链路中涉及到的方方面面，在平台侧我们是如何解决每个流程中对应的问题呢？整体从思路上，划分为三个维度：

一站式

在建立一站式解决方案里，我们细分了三层。

第一层：视图层。这个视图层就是来满足我们能够知道，我们有哪些资产，我们有什么，我们的目标是什么，该怎么制定，这个我们称之为治理全景层。

第二层：方案层。也就是真正实施去推动这个治理过程的这一层。在这一层里面我们提出了两种治理的路径，一种是主动式的规划路径，另二种是系统发现式的路径。

系统规划式路径：契合于从上而下的视角来去满足于治理的目标，针对它做一些规划，做了一些规划之后对相应的资产进行诊断。诊断之后诊断出资产的问题来进行相应的一些问题推进执行，最后到一些收益的统计和总结。这是一个主动规划的部分。

系统发现式路径：系统发现这个路径其实主要解决的是，我怎么能够日常的去将我这些资产或者治理问题，能够持续的进行。日常化治理而不是一个运动式治理方式。这个是基于我们平台里面的一些全局规则来定义，通过系统来去订阅，定期在系统里面去进行运行扫描，发现一些资产的问题，通过一些消息的方式推送到这些资产的责任人，进行一些比如说根因的登记，问题的登记，事故的复盘，最后进行一些总结和经验的共享等等；

第三层：工具能力层。即为了满足于上面的视图层和方案层，我们在工具侧提供的一些能力，包括一些垂直的治理场景和质量，安全成本，稳定性，报警起夜等等方面。还有一些基础服务来支撑这些我们工具的建设。比如我们会抽出一些消息的中心，云数据的中心，规则引擎或者数据服务等等。

上述是我们一站式的思路。

全链路

全链路是指我们希望治理能够达到一个闭环的状态。

在整个链路里面，可能针对于不同的角色，会有一些不同的使用方式，或者是一些运行方式。在整个的路径里面会有从资产的视图来看我们有哪些东西。在这些资产视图基础之上去定一些目标和规划。比如说有些外部驱动的指标，业务驱动的一些指标或者是一些合规或者是政策类的指标等等，来制定我们治理的目标。

针对这些目标，我们去做一些方案的制定。

举个例子，比如去做一些存储资产的降低，可能通过一些规则来去圈选出来资产有问题的部分。之后推进这个治理的实施，可能在一些治理决策者或者一些团队的负责人方面，他可能会去进行一些拉群的督办，或者是一些定时的订阅提醒等等。在推进治理方案过程中，还希望资产的责任人，也就是治理的实施者在我们这个平台工具里面能够具体去实施治理的动作，如一些基于SLA的申报、参数的优化、存储规则的设置、规则的调优等等。

进行了一系列治理之后，我们肯定要有一个验收的环节，可能会是一个整体指标的验收，业务是否达标了，指标是否合理，最后进行一些经验的总结，这个是全链路的部分。

当然在全链路里面也包括了刚才所说的这种系统式、扫描式的路径。这个也是通过一些规则的制定，在系统里面去发起规则的定义和订阅。通过系统的扫描去发现一些问题，发现问题之后经过一些实施的治理，可能再反哺到我们具体的一些规则的制定上面去。比如说更进一步配置一些监控规则，来预防治理的一些问题。

这个是全链路的部分。

全规则

全规则目标是提供比较完备的治理规则能力，能够服务于刚才所说的这种规划式资产组合与响应式资产扫描。这个是在平台的能力完备性方面的一些考虑。目前我们提供了存储计算、质量报警等四个维度，现在有数十个这种治理的规则可供任意的圈选和组合。其中包括一些全局的规则和自定义的规则。

比如全局规则，比如近7天的产出为空的任务，是否有暴力扫描的任务。或者是一些定义，比如生命周期可以任意选择一个时间段来去进行扫描或者近xxx天任务为空，把这些任务圈选出来，这些是自定义的部分。

同时还有一些统计类和挖掘类。统计类就是基于数据建设对元数据的应用和加工。举个例子，比如近90天无访问表，或者是数据倾斜任务的圈选。挖掘类其实是在元数据的基础上进行一些更深层次的挖掘，去找到一些数据的问题，比如相似的库表，相似的任务等。

一站式数据治理平台架构

上面介绍了我们应对数据治理的解决方案，包括全规则、全链路和一站式。接下来，介绍具体的平台架构。

整体架构

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

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

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

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

元数据建设

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

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

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

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

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

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

产品模块

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

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

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

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

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

系统设计

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

规划式架构：

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

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

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

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

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

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

响应式架构：

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

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