极客星球丨字节跳动一站式数据治理解决方案及平台架构

2022 年 7 月 21 日
本文字数：5980 字
阅读完需：约 20 分钟

编者按：

由 MobTech 袤博科技主办的【CoderPark】第二季数智有为第 2 期直播活动圆满落幕。活动现场精彩纷呈，来自字节跳动的数据治理平台研发负责人王慧祥老师出席分享。在字节跳动内部，数据平台数据治理团队致力于建立一站式、全链路的数据治理解决方案平台，以下是本次演讲内容部分摘录：

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

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

数据治理的概念

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

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

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

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

数据治理是一个比较大的概念，它包括政策、规则、组织结构、治理过程，以及一些技术的支持。它的领域包括数据质量、数据成本、数据可用性以及数据安全等方面。所以，影响数据治理计划的驱动因素是多样的，如数据法规、隐私政策的限制、数据质量良莠不齐、数据治理成本高、资源受限等。

此外，治理实施的方式和范围也不同，比如：有可能是由统一的组织，诸如数据治理委员会在整个企业或者公司的范围内发起一些治理目标与计划，来推动整个组织的数据治理；也可能是在一些部门、团队内部去进行有限范围内的治理。数据治理计划的目标实现必须得用适当的工具来解决，数据治理的方式也越来越倾向于朝着系统化和工具化的方向来发展。

字节跳动数据治理背景

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

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

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

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

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

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

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

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

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

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

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

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

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

数据治理解决方案

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

▌一站式解决方案

一站式解决方案架构图

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

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

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

系统规划式路径：契合于从上而下的视角以满足治理的目标，针对它做一些规划，然后对相应的资产进行诊断。进行资产诊断后，需要对发现的问题进行相应的推进执行。最后，需要统计和总结数据治理收益。这是一个主动规划的过程。
系统发现式路径：该路径其实主要解决的是，我怎么能够在日常工作中，将资产或者数据治理问题持续进行下去，实现日常化治理，而不是运动式治理。为实现日常化治理，我们需要基于平台内的一些全局规则来定义、通过系统来订阅、定期在系统里运行扫描，以发现资产的问题，并通过消息推动将资产问题告知这些资产的责任人，进行根因和问题的登记、事故的复盘，以及一些总结和经验的共享等等；

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

▌全链路解决方案

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

全链路解决方案架构图

在整个链路里，针对于不同的角色，存在不同的平台使用方式和运行方式。在全链路中，我们会通过资产视图来观察资产内容，在此基础上制定治理目标和规划。比如说通过一些外部驱动、业务驱动、合规或政策类的指标等，来制定我们治理的目标，并针对这些目标去做一些方案的制定。

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

进行了一系列治理之后，我们肯定要有一个验收环节，如对整体指标的验收，判断业务是否达标、指标是否合理，最后进行经验总结，这就是全链路的整个过程。全链路解决方案也包括了第一部分介绍的系统式、扫描式的路径。这个也是通过一些规则的制定，在系统里面去发起规则的定义和订阅。通过系统地扫描去发现一些问题。当问题经过一些治理实施动作后，它可能会再次反哺到我们具体的规则制定，如对监控规则的进一步配置，来预防可能出现的治理问题。

▌全规则解决方案

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

全规则解决方案

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

一站式数据治理平台架构

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

▌整体架构

平台建设整理架构模块

如上图所示，在整体架构部分中，灰色的部分是在平台透出，给到用户的产品能力，包括治理全景。治理全景对应一站式的视图层，能够告诉用户资产的情况如何。治理的工作台部分主要针对治理的实施者，让其能够快速定位或者跳跃到一些相关的治理方案和平台去进行数据治理，包括待办项和资产分析等。数据诊断规划部分是服务于主动式规划路径的一个模块。它会对我们所有的资产进行规则式地组合，出具最终诊断。除此之外还有一些资源的优化、报警与订阅、SLA 保障等几个垂直类的治理场景。最后，复盘管理部分是进行经验总结和沉淀的模块，它以系统的方式进行记录。

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

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

▌元数据建设

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

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

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

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

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

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

▌产品模块

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

平台建设全景治理视图

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

平台建设健康分视图

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

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

在有了资产全景和看板之后，我们可以进行一些治理操作，这些操作对应于一站式解决方案中的第二层治理操作。上文介绍到，规划类路径是从较高的视角去拆解治理的问题，而在当前路径中，我们要实现目标明确、过程可拆解、收益可量化、结果可验收。

▌系统设计

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

规划式架构

治理方案规划式架构

底层的基础架构设计主要有一下模块。

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

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

除此以外，与该服务有关联的是数据治理具体实施的模块，它和系统中关于治理的操作有关。比如在进行一些表的生命周期设置，或是删除表等操作时，这些操作都会以消息的形式，经由执行模块去实现任务下发和底层组件调用。同时，通过一些状态把治理是否获得收益、消息是否成功等内容，也由刚才的事件收集服务纳入查询服务中，形成收益可查询的数据。

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

响应式架构

治理方案响应式架构

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

但它们有几大区别。第一是响应式流程左侧提供消息服务。该路径是通过消息触发的，因此我们会打通与研发平台、质量平台、自然平台等多处发送消息和报警的平台，将他们的消息和报警统一收归到我方服务中进行下发。下发的渠道包括飞书、邮件、电话、短信等。这些消息形成的数据也会经由数据的收集存放到查询服务中，作为一些报警的展示。另外在消息模块，我们会和复盘模块进行强关联，对问题进行登记、核准、复盘。