字节跳动一站式数据治理思考及实践

动手点关注

干货不迷路

导读：今天的分享主要分四个部分：机遇与挑战、数据治理思路、技术架构演进以及未来展望

1. 机遇与挑战

数据治理工作有很多挑战，最主要的一点是落地比较困难。

首先，治理工作中与业务有一定的矛盾。

第二，治理涉及的组织和管理难度大。

第三，规范“人”的动作难度大，治理过程中，需要依靠人来推进和执行，人员能力参差不起，组织文化、目标也存在不对齐的情况。

第四，缺乏适配性强的产品工具。因为治理工作范围广，链路长，并且涉及跨部门、跨系统的目标对齐，需要一个完备的产品平台。

下面结合字节的特点，介绍数据治理工作的机遇和挑战。

• 字节文化

首先，字节业务多，多业务齐头并进发展，需要快速响应业务需求；

第二，字节的 OKR 文化，使得每个人都可以参与数据治理的规划和策略的制定，并且主动寻找实现路径，快速对齐；

第三，为追求高效治理，没有设立统一的数据治理委员会，而是各个部门根据各自的业务情况进行治理。

• 业务第一

字节业务规模大，并且以数据作为驱动构建闭环的产品较多，导致数据质量对业务的影响非常大。

综上所述，数据治理在字节是挑战机遇与并存的工作。

2. 数据治理思路

2.1  新型数据治理 - 分布式数据自洽

针对上述问题，提出了分布式数据自治的思路, 综合考虑治理收益、业务影响，执行效率。

首先，业务影响方面，为保证影响小，治理工作按照业务单元进行。一个业务单元可能是一个小团队或者小项目，作为数据治理的范围和目标。

第二，需要沉淀各业务线的治理经验，提升治理效率；通过产品辅助业务自驱，实现规则化、策略化、自动化治理。通过工具等平台能力，降低治理门槛。并且支持灵活的治理方式，如管理者视角，自上而下规划性治理，和一线执行者视角，自下而上推动治理。

第三，需要适配性强，建设产品来覆盖治理全链路。

实现多种场景中，产品都有能力覆盖，多个模块可以独立使用，按需组合；并且提供完整的开发能力，支持业务根据自身特点和发展阶段，自行接入。

2.2  集中式 VS 分布式

分布式治理，与传统集中式治理相比，有很多优势。

• 集中式治理，需要制定制度进行大范围组织，划分权责，定期抽查考核，建设周期长，适配能力弱，并且组织投入多。

• 分布式自治，业务影响小；周期短，见效快；效率高，节省人力；便于算清对业务的收益，降低成本。

3. 技术架构演进

针对上述思路，平台工具如何支撑数据治理？

3.1  解决方案 - 一站式

首先提出了一站式的解决方案。将治理划分为三层。

• 第一层 - 视图层

从资产视角、管理者视角 、实施者视角 纵览数据治理的情况。

• 第二层 - 方案层

• 针对治理过程，提出了双路径。

  • 路径一【主动规划】规划式流程

• 主要解决的问题是：确定目标后，如何推进执行。将治理目标，拆解成治理规则，进行诊断，根据诊断结果，执行治理。治理结束后，通过收益统计、改进计划等进行总结。

  • 路径二【系统发现】响应式流程

由系统发现的问题，通过高警等形式，通知到资产责任人，进行处理。通过根因分析等，进行总结。

• 第三层 - 工具层

为上述两层，提供完备的治理工具。覆盖质量、安全、成本、稳定性、报警与起夜等场景，通过打通基础服务，赋能上述两条治理路径。

3.2  平台建设 - 治理方案 - 规划式流程

接下来将为大家介绍，在治理过程中，我们两条路径的具体建设过程。

路径一：规划式治理

目标是资产清晰，规则丰富，动线完整，收益准确。

首先需要制定目标，包括健康分目标，以及降低存储、计算资源的目标。针对目标，建立治理方案，包括划分治理域，以及在治理域内通过规则，发现有问题的资产。建立方案后，由系统找到有存储、计算等问题的明细。对上述找到的问题进行分析，通过消息催办等方式，将问题下发到责任人，进行治理。系统会对治理的效果进行采集，反馈目标达成情况，并对一段时间内的治理结果进行验收和统计。

以上是规划式流程的主线思路 。

下面介绍如何实现规划式流程的几个目标。

3.2.1 资产清晰

主要从治理全景和健康分两个方面对资产进行描述。

第一，治理全景。 从各个维度，通过明细、统计量，对团队或个人资产的具体情况进行描述。如各个表占了多少存储空间，计算资源使用情况，任务报警率、起夜率，数据及时性和质量等。

第二，对资产健康度进行衡量。 根据三个层级建立了健康分体系。第一层是根据治理的垂直方向划分，包括：存储健康分、计算健康分、质量健康分等。第二层在第一层的维度下，细化了问题大类。如存储方面，包括：无效存储、异常存储等；质量方面，包括：及时性、报警、元信息配置规范等。

在第二层的划分下，将具体问题通过标签定义，得到了第三层。比如无效存储方面，涉及了 TT 不合理、热度方面信息(xx 天无查询)等。

综上，主要通过健康度和治理全景将资产清晰地表述出来。通过元数据仓库，进行底层数据的建设。

3.2.2 规则丰富

目前平台具备了完备的治理规则，涵盖了存储、计算、质量、报警 4 大维度，50 多个规则。

其中包括全局规则，如：生命周期永久、近 7 天产出为空、暴力扫描任务等；也包括一些自定义的规则，如生命周期 xxxt 天，近 xxx 天产出为空等。同时还兼具了一些挖掘类规则，包括基于统计信息进行聚合后形成的规则，以及基于资产（包括库、表等）相似性，通过关联、排序来发现问题。

规则部分以及能力建设方面分为以下几部分：首先通过底层与平台基础组件打通，将数据收集上来，形成数据仓库的基础层；基于基础层对数据资产进行画像描述，进一步形成特征域，做特征挖掘和关联分析；然后将应用的数据，放到数据服务中，对外提供灵活的数据查询能力。

最上层为组合在线的规则引擎，将数据和规则进行联动，应用于规则建设。

3.2.3 动线完整

标出有问题的资产后，如何尽快完成治理，减少和业务的冲突，提高效率非常重要。

基于治理平台的能力，在各个垂直场景中，我们建设了比较完善的治理动线。

大致的思路是，把能力划分为几类：

• 任务治理方面，和任务开发、任务运维平台打通，支持任务的关闭、调整、调参，链路优化等；

• 库表规范方面，和元数据平台联动，实现表管理、库管理、资产移交、属性修改等；

• 生命周期方面，通过治理平台，和底层的存储（包括 hdfs, hive 等组件）打通，形成闭环式的治理；

• 在数据质量方面，包括 sla 的及时性，离线、实时数据的监控，会和具体的质量规则平台进行强联动，互相登记数据、进行 sla 的签署、和强跳转交互等。

以上是动线完整的部分，能够使用户在平台中，通过很低的操作成本，完成一站式的闭环治理。

3.2.4 收益准确

第四个是收益的准确部分。

我们做了治理后，付出的人里成本、精力、怎么知道是有效或者达标呢？如何衡量这一阶段的工作是有价值的，治理是有收益的？这就需要在平台建设上，准确度量收益。目前统一建设了基于事件中心的底层框架。总体来说，就是定义数据的消费模型，通过上面的一些消息通道，来定时收集各个平台操作的消息；同时定义了事件的 SDK, 并兼容 API 的方式，灵活对接上游不同的平台。

目前来说，我们和研发平台、元数据平台、质量平台等，大部分都是通过消息订阅和消费的方式，将治理的事件，接入到事件中心里，并将事件中心的离线数据 dump 到数据仓库，进行离线加工，同时我们会将最新的事件，注入在线的元数据服务中，来及时完成治理收益的计算。

3.2.5 技术架构

在规划式流程的技术方面，遵循的原则是：统一的数据查询、各种规则灵活组合，操作结耦，治理收益准确。

整体的平台后端，会负责分发和转换治理的各种逻辑，包括查数、设置目标、健康分的展示和透出，治理的操作等。

后端平台拿到消息后，会做具体事件的拆分。比如说看板类查数的部分，统一将需求发送到查询服务里，数据查询服务会对底层存储做适配，通过点查、list、聚合类的查询，根据底层选取的存储引擎的特点，解析后，选取不同的底层存储。

规则引擎服务部分，可以与数据查询服务联动。通过数据查询服务取到数据后，通过规则的定义形成标签，这个过程可以抽象成一个服务。这个服务对外可以提供对资产标签的描述，作为通用的能力。

在治理的具体实施部分，我们统一抽象成一个后台的模块。具体的实施，如设置消息、设置 ddl、进行删除等，统一由这个模块下发到组件层，进行操作，在组件层或其他平台进行了有效操作后，由事件的收集服务，将事件收集上来，写回到数据查询服务，形成治理收益的汇总。

3.3 平台建设 - 治理方案 - 响应式流程

第二条路径是响应式路径。主要做事后治理、问题总结、经验沉淀。

在这条路径里，大致分了几个部分，首先以报警、消息作为源头。包括 sla 破线告警，数据质量任务的报警，计算任务的报警等。

系统会将上述消息进行汇总，展示在治理平台中。治理平台可以对消息进行搜索，对问题进行归因，并做根因打标，把问题定位到组件、平台等问题上；再通过一些组织方式，比如通过系统来去找到组件方面的对接人，或通过组织会议，将问题提给相关的责任方，推动他们做一些有针对性的保障。做了以上推进后，我们会将系统中的问题描述、改进计划列出来，有针对性地对问题进行定义，以及分析该怎么做达到事后治理的目的。最后，在问题解决后，推动方案的分享、沉淀和复用。

3.3.1 技术架构

响应式治理的架构，和规划式治理类似，区别是里面消息服务的部分。这部分作为基础的能力，将大数据平台的各种产品，包括研发平台、质量平台等所有的消息，接到统一的服务中，所有消息的发出，都通过服务对外。这个消息服务成为所有报警消息的入口。通过它可以做一些升级策略，如消息聚合、加急等。此外，和规划式治理类似，后端平台控制响应式路径的逻辑，包括消息订阅、问题登记、总结复盘模块等。其他部分和规划式路径类似。

3.4 平台建设 - 开放接入

讲完两条路径，下面是一些实践中的解决思路。因为业务有各自发展的阶段，以及不同的治理目标。比如说，比较新兴的业务，现在主要关注的是sla的能力；一些成熟的业务，现在做的已经比较好了，要去做规范性。不同业务有不同的诉求。如何避免一刀切，让不同的业务用平台进行治理，开放能力非常重要。开放能力是说，要构建治理生态，业务可以自定义地接入治理规则，实施治理。

当前阶段，将治理分为了四个象限，横坐标为元数据部分，纵坐标为规则的部分。规则包括表达式和算法包等形式。系统提供的能力，主要在一象限：定义的标准的元数据，和统一的表达式，通过规则引擎直接适配。如果业务方有第三方元数据，来接入我们已定义好的规则，如图中第二象限的部分，需要定义第三方元数据的接入。接入的第三方元数据需要遵循接入的标准，通过规则引擎进行适配。规则部分如果要做升级，比如进行相似度计算等，不是在一维上对资产打标，不是纯表达式可以描述的规则，这种情况下将其定义为算法包或者逻辑单元。需要定义好输入输出的标准，通过调用包或者插件的方式，执行逻辑。第三方元数据和算法包的结合同理，定义好输入输出，并关注包的执行效率、时间等，就能满足整体的接入。

整体来说，将平台能力开放出去，让业务接入自己的规则和数据，需要定义好标准的元数据格式，比如：可以定义行是具体的资产，列是具体的 profile。业务方负责加工自己的接入部分，完成配置和数据映射，通过表达式或者算法包的计算后，定义统一的输出，就可以对接到系统。目前，系统支持对单资产打标（pointwise）和两个资产关联打标（pairwise）。

3.5 平台建设 - 智能化能力

接下来是近期在做的事情。平台工具侧做了很多能力上的建设，通过智能化的方式，进一步降低治理成本，提高治理效率。下面介绍几个有代表性的落地。

3.5.1 任务 SLA 签署推荐

在做 SLA 签署时候，任务上下游，可能存在几百上千个节点，怎样估计出应该在什么时间产出呢？我们目前是通过血缘关系，找到节点所在的关键路径，基于运行时间，进行权重的分配，来确保节点有相对合理的 SLA buffer。

推荐签署部分，目前已经有了专利，并有了一定的效果。现在在做第二期，基于运行失败概率分布的情况，来调整上游 buffer 压缩，下游 buffer 宽松的问题。

3.5.2 动态阈值监控

解决的问题是：数据量正常分布，但看起来异常化的情况。比如流量日志在假期或活动日，出现正常突增或突降的情况。

平时做质量监控时候，会用绝对值阈值来限定作报警范围，比如参考历史7天波动率等。这样，容易造成假期或活动日误报警，给值班人员造成不必要的打扰。动态阈值就是为了解决这个问题。主要思路是：基于数据的历史情况，归纳为几种分布。针对不同的分布，提供不同的预测方法，预测整个表在某一天应该是在什么量级，然后基于数据量级设置上下阈值，超出阈值再进行报警或者消息通知。

在数据分布方面，针对我们自己的业务，划分了几种典型的分布：数据量单调不减的，大部分为快照表或者全量表；日志类的表，长时间观察时，假期或活动日可能出现数据量突增或突降；维度表，数据量比较稳定，维度发生变化时，会反应出一定的问题；以及与维度表类似的一些波动比较小的分布。

基于不同的数据分布，目前采取了四种不同的预测方法：

移动平均法、指数平滑法、自回归法、同期检测法。针对不同的波动做拟合，目前得到了一定的验证。

3.5.3 有相似任务识别

由于业务庞大、开发人员多、任务量大，在开发任务时，并不知道是否线上已有类似的任务，跨团队情况更明显，因此详细任务的检测很有必要。

基本思路是将目标源代码和待检测源代码 sql 的 ast 序列化，然后进行向量化，对特征向量做余弦相似度计算，结果通过产品进行透出，再由业务进行标注，经过人工的确认分析，对任务进行合并或下线。

以上是我们在智能化方面的一些探索。

3.6 平台建设 - 架构总结

总结一下，平台总体架构分为三层：

• 产品层，将管理者视角和执行者视角做了区分。具体治理时候，通过双路径的方式：做规划式治理时候，从目标制定、规则圈选、治理实施、到收益统计、经验总结；第二条路径是响应式治理。通过订阅消息、发现问题、实施治理、登记问题、复盘总结几个步骤进行治理。

• 服务层，提供了整体的服务逻辑层，在下面拆分了不同的模块，特别是接入服务，提供了开放的能力。通过对任务执行、事件中心等不同模块进行拆解，方面我们针对各种不同的场景，提供灵活服务。

• 数据组件层，作为基础建设层，包括元数据仓库的建设、大数据组件的适配。

4. 未来展望

未来展望主要由三个部分。

• 体验打磨

平台建设阶段，已经建立了比较完善的能力，在内部得到了有效的使用。进一步，会更加贯彻双路径的建设，规划式路径上，使资产更清晰、规则更丰富，进一步打磨动线，并提高收益准确性。

响应式路径上，除了问题登记、归因、总结外，后面会主要针对总结归纳、经验沉淀进行建设，使经验更好地复用到其他业务方。

• 开放能力

基于分布式自治的理念，目前没有采取一刀切的策略进行治理。大家可以自定义自己的目标，对齐自己的 SLA 等。后续会支持自定义健康分，不同业务可以自己定义健康分的组织形式和描述。第二点是自定义方案。我们会进一步打磨自定义规则的接入流程，并将规则能力进一步开放化，支持业务调用。业务拿到打标后的信息，可以做自己的资产分析。第三点是打通业务，进一步以业务视角看待问题，针对业务问题，做好平台建设。

• 增强型数据治理

目前大部分是基于统计类规则，正在建设部分挖掘类规则。

后续会在智能化模型建设方面，做一些预测分析。

5. 活动推荐

12 月 20 日 19:00，《 火山引擎 VeDI 数据中台架构剖析与方案分享》

本期直播分享将聚焦字节跳动数据中台建设经验，在存算分离、湖仓一体、ServerLess 等技术发展趋势下，从企业数仓架构选择、数据湖解决方案与应用实践，以及一站式数据治理等角度，为企业构建自身数据中台提供思路和启发。

扫码进群、观看直播、赢取好礼！

● 性能提升 2.5 倍！字节开源高性能 C++ JSON 库 sonic-cpp

● 优先级反转那些事儿

● 火山引擎 RTC 助力抖音百万并发“云侃球”

● 一文读懂火山引擎云数据库产品及选型

 戳“阅读原文”，进群看直播，赢取好礼！