字节跳动基于火山引擎DataLeap的一站式数据治理架构实践

在7月22日举行的 ArchSummit 全球架构师峰会（深圳站）上，来自火山引擎DataLeap的技术专家为大家带来了字节跳动基于火山引擎DataLeap的全域数据治理方案分享。

本次分享共分为机遇挑战、字节数据治理理念、分布式数据治理架构及实践、数据驱动治理、智能化治理探索、总结及未来展望等五个板块，内容皆来自于字节跳动业务实战经验，希望可以帮助企业更高效地管理和处理大量的数据，提高数据资产的价值和利用率，助力企业抓稳数字化机遇，建立数据驱动的决策机制。

机遇与挑战
在字节内部，系统化、平台化的进行数据治理的时间并不算长，也遇到了很多普遍意义上的治理挑战。如治理效益与业务影响有一定的矛盾、治理涉及的组织和管理难度大、规范“人”的动作难度大、缺乏适配性强的产品工具等

字节跳动的数据治理问题
而对于字节跳动快速发展的庞大业务体量来说，数据治理还会遇到一些特殊的挑战。

挑战一：业务要求
字节跳动的业务多，增长速度快，且为自驱发展的模式。每个业务的不同特点，意味着每个业务的治理目标也是不一样的，数据治理平台需要做到快速响应不同的业务需求。

挑战二：OKR文化
字节非常崇尚OKR的文化，OKR的意思是设定一个大的目标，比如说某个业务线现在面临成本和质量问题。然后需要将这个目标拆解，分配给每个团队和每个人，让大家思考如何去解决这个问题。这种方法通常被称为自底向上的方式来解决目标，这种方式比较分散和自驱。

挑战三：高效治理
对于业务来说，数据治理的第一目标肯定是更高效地解决业务问题。而在字节内部，并没有设立一个专门的数据治理委员会或部门来推进整个集团的数据治理工作，相反，是否进行数据治理更依赖于各个业务线的自行判断，并独立决定如何去做。

挑战四：规模大
字节的业务场景十分丰富，传统的互娱数据，比如抖音和TikTok，包括这些平台上电商的快速发展以及很多成熟的商业化产品，使得字节所拥有的数据量非常庞大。

挑战五：数据驱动
在字节公司的各个业务线中，每个业务都有其独特的特点和问题。为了解决这些问题，需要通过数据分析来驱动人员的决策和行动，这一环节后面会详细阐述。

挑战六：影响大
数据治理的优劣对业务的影响非常大。如果做得好，它可以解决成本和质量等问题；如果做得不好，则可能会误删业务核心数据，导致数据延迟，从而给业务带来巨大损失。

字节跳动数据治理理念
分布式数据自治概念
基于这些挑战，字节跳动火山引擎提出了分布式治理的概念。

传统的数据治理模式，治理目标通常是一致的，自上而下地在组织中推进，以运动式的方式发起治理。它非常依赖于组织和制度，再来协调下面各个部门的职责，划清边界，梳理现有问题，最后制定目标并推进。完成后，还需要定期评估治理效果。

而分布式治理更灵活，更贴近业务本身，能够做到业务自决策，各级业务/个人都可自驱治理，且工具灵活，治理周期短，见效快，可以迅速确认核心数据问题，聚焦投入，并非“一刀切”。

在治理完成后，治理经验、规则及策略的沉淀也更方便复用和多业务共享。

分布式治理特点
目标多元化：
对于某些团队的业务发展状况来说，成本是一个很大的问题，所以该团队可能会去做一些成本治理；而对于某些新兴业务线，最大的问题数据的及时性无法保障，所以该团队可能会将数据的 SLA 作为治理的核心关键。分布式治理可以很好的满足这些业务的不同治理需求。

灵活自治：
在不同的业务场景中，比如电商或短视频，数据质量的要求是不同的，目标也是不同的，分布式治理可以将治理目标和动作泛化，更加灵活自如。

常态化推进：
分布式治理更容易常态化地推进，保证长期的数据治理效果。

分布式数据自治平台落地
基于这样的治理理念，可以再进一步的通过分布式数据自治平台进行工具化落地，它有着以下多点优势。

优势一：业务影响小，灵活的自治模式
首先，由于治理是分阶段、分目标进行的，对业务影响较小，且平台会将业务单元分为多个层次，例如存储库级别、计算资源队列级别、组织架构团队级别等，以便灵活制定目标。

优势二：沉淀各业务治理经验，提升治理效率
由于每个业务的治理目标不同，每一个发展较快的业务面临的数据治理问题，在今后，可能是其他业务也会面临的问题，所以这种治理经验的复用是非常必要的，这也是分布式数据自治平台的理念。

比如，电商场景对于数据质量要求很高，现在可能对数据分布有严格要求，而在一些小的业务中，现在可能并不关注数据质量，当电商场景的数据质量经验沉淀下来，其他业务后续想要使用的时候，可以大大提升治理效率。

优势三：适配性强，产品建设覆盖治理全链路
分布式数据自治平台具备高度适配性，能够满足多种治理场景。在平台中集成了多种治理场景，如数据稳定性、数据 SLA、数据内容质量、数据规则质量监控、数据整体安全、成本控制等。这些场景可以按照模块化进行拆分，独立输出能力。

平台逻辑架构
分布式数据自治平台的逻辑结构可以整体分为四层。

治理用户层
最上面是治理用户层，这一层可以分为三个重要角色。首先是管理角色，管理角色的特点是对治理非常关心，但他不参与具体的治理行动，只看最终目标的实现结果；然后是治理推动角色，一般是在业务线下面具体负责数据治理的人员，他对管理角色所制定的治理目标进行拆解。形成具体的治理方案；再往下去推动，有专门执行人员去具体地推动这个治理工作。

治理评估层
治理评估层，其中包括健康分体系和多个大盘能力，这些能力可以帮助我们评估治理水平，并制定具体的治理目标。

治理方案层
对资产和问题进行评估后，明确需要治理的范围，制定治理方案，推动方案落地。

流程框架层
在流程框架层，整体分成了三个动线流程。

第一条动线是健康分驱动。平台会明确整个团队或某个范围内的健康分是多少，然后对这些分进行分析，定位问题并实施治理，治理完毕之后，健康分的收益将达到目标分数。

第二条动线是规划驱动，团队通过平台对治理目标进行规划，先确定范围，设定好目标后选取规则，执行诊断，然后推进治理行为，这是目前比较核心的一条链路。

第三条动线是基于被动式的响应驱动，比如说数据质量有问题，数据延迟有问题，当这些问题已经出现后，再将这些问题的治理方案流程化地串接起来。

基础能力层
最下层是用来支撑上游的所有能力的基础能力层。在基础数据建设方面，平台通过沉淀大量元数据模型来支持数据驱动能力。在此基础上，构建了治理规则引擎层，并沉淀了许多治理规则，用于筛选资产。同时，通过优化工具，形成了治理的单点能力，这些能力会渗透到流程层中，以实现治理流程。最后，收益核算也是重要能力之一，可以有效的控制各项资源成本。

分布式数据治理架构及实践
治理体系建设
以小规模打扰业务，高效治理的原则，分布式数据自治平台体系整体分为治理分析、规则式治理、平台级治理三个部分。在治理分析中，用户可以使用大盘来摸清资产现状，并通过评估体系对资产现状进行打分，然后通过下面的看板来推进或晾晒资产问题。在规则式治理中，用户可以使用规则池和自定义规则来制定方案，然后进行扫描和治理操作，并追踪治理效果。最后，在平台级治理中，用户可以划定一个非常大的组织范围，制定如 TTL 或成本规则。

推动者动线
在治理动线上，平台会在前端中提炼治理全景、业务目标、资产和运营信息等方面的问题，然后使用规划诊断的能力将问题具体化，并使用平台工具将目标具体落地。接着，通过治理的明细和中间过程的推进，来观察治理实施的效果，并最终完成方案的总结。

在实施部分，有三个角色，即推动者、执行者和管理评估者。在推动层，可以举一个具体的例子，比如一个用户现在作为某一业务线的治理POC，治理目标是将成本从100PB降到 50PB，用户就可以会通过平台找到一些库，选择存储可节省的方案，并制定策略。这些策略会在平台里面周期性地每天扫描，看现在的资产是不是已经达标。如果进一步发现 50PB 还有一些空间，可以再调整规则，将其沉淀为常态化的治理和跟踪的一部分。

实施者动线
推动者制定治理目标，并将任务分配给实施者，实施者则负责完成这些任务，实施者可以通过系统中的个人工作台获取任务，并通过平台给予的建议和推荐措施来完成任务，最终达成治理目标。

创建方案&目标
用户可以通过数据治理平台创建方案和目标，并使用系统中的规则和自定义规则，来实现资产治理的自动化。

第一步是创建方案和目标。在系统中，用户可以根据沉淀数据，为各种资产建立宽特征表，并对其特征进行打标。例如，数据的 TTL 是多少，资产的存数是多少，是否命中了一些治理规则。在圈选到资产后，可以采取几种动作来达成目标，例如，可以同时对这张表进行 TTL 设置和操作，也可以进行温存降级。

这两种方法的收益如何，需要综合考虑，以便在资产治理中实现最大化收益，这个过程由平台负责计算，并会参考其他人已经做过的资产治理分析，进行相似度计算。

治理实施&操作（开放性建设）
第二步是实施和操作，平台系统中目前沉淀了 80 多个系统默认规则，包括存储、计算、质量和安全等各种场景。如果用户在使用时感觉不太适配，也可以自定义规则。

例如用户可以通过 TTL 设置一个划定范围来进行治理，但如果用户觉得 TTL 的范围太宽泛，希望能够在资产上打一个业务标，也可以通过自定义规则的方式将其接入系统，以便实现更精细化的资产自动治理。