更多技术交流、求职机会，欢迎关注字节跳动数据平台微信公众号，回复【1】进入官方交流群
在7月22日举行的 ArchSummit 全球架构师峰会（深圳站）上，来自火山引擎DataLeap的技术专家为大家带来了字节跳动基于火山引擎DataLeap的全域数据治理方案分享。
本次分享共分为机遇挑战、字节数据治理理念、分布式数据治理架构及实践、数据驱动治理、智能化治理探索、总结及未来展望等五个板块，内容皆来自于字节跳动业务实战经验，希望可以帮助企业更高效地管理和处理大量的数据，提高数据资产的价值和利用率，助力企业抓稳数字化机遇，建立数据驱动的决策机制。
机遇与挑战
在字节内部，系统化、平台化的进行数据治理的时间并不算长，也遇到了很多普遍意义上的治理挑战。如治理效益与业务影响有一定的矛盾、治理涉及的组织和管理难度大、规范"人"的动作难度大、缺乏适配性强的产品工具等
字节跳动的数据治理问题
而对于字节跳动快速发展的庞大业务体量来说，数据治理还会遇到一些特殊的挑战。
- 挑战一：业务要求
字节跳动的业务多，增长速度快，且为自驱发展的模式。每个业务的不同特点，意味着每个业务的治理目标也是不一样的，数据治理平台需要做到快速响应不同的业务需求。
- 挑战二：OKR文化
字节非常崇尚OKR的文化，OKR的意思是设定一个大的目标，比如说某个业务线现在面临成本和质量问题。然后需要将这个目标拆解，分配给每个团队和每个人，让大家思考如何去解决这个问题。这种方法通常被称为自底向上的方式来解决目标，这种方式比较分散和自驱。
- 挑战三：高效治理
对于业务来说，数据治理的第一目标肯定是更高效地解决业务问题。而在字节内部，并没有设立一个专门的数据治理委员会或部门来推进整个集团的数据治理工作，相反，是否进行数据治理更依赖于各个业务线的自行判断，并独立决定如何去做。
- 挑战四：规模大
字节的业务场景十分丰富，传统的互娱数据，比如抖音和TikTok，包括这些平台上电商的快速发展以及很多成熟的商业化产品，使得字节所拥有的数据量非常庞大。
- 挑战五：数据驱动
在字节公司的各个业务线中，每个业务都有其独特的特点和问题。为了解决这些问题，需要通过数据分析来驱动人员的决策和行动，这一环节后面会详细阐述。
- 挑战六：影响大
数据治理的优劣对业务的影响非常大。如果做得好，它可以解决成本和质量等问题；如果做得不好，则可能会误删业务核心数据，导致数据延迟，从而给业务带来巨大损失。
字节跳动数据治理理念
分布式数据自治概念
基于这些挑战，字节跳动火山引擎提出了分布式治理的概念。
传统的数据治理模式，治理目标通常是一致的，自上而下地在组织中推进，以运动式的方式发起治理。它非常依赖于组织和制度，再来协调下面各个部门的职责，划清边界，梳理现有问题，最后制定目标并推进。完成后，还需要定期评估治理效果。
而分布式治理更灵活，更贴近业务本身，能够做到业务自决策，各级业务/个人都可自驱治理，且工具灵活，治理周期短，见效快，可以迅速确认核心数据问题，聚焦投入，并非"一刀切"。
在治理完成后，治理经验、规则及策略的沉淀也更方便复用和多业务共享。
分布式治理特点
- 目标多元化：
对于某些团队的业务发展状况来说，成本是一个很大的问题，所以该团队可能会去做一些成本治理；而对于某些新兴业务线，最大的问题数据的及时性无法保障，所以该团队可能会将数据的 SLA 作为治理的核心关键。分布式治理可以很好的满足这些业务的不同治理需求。
- 灵活自治：
在不同的业务场景中，比如电商或短视频，数据质量的要求是不同的，目标也是不同的，分布式治理可以将治理目标和动作泛化，更加灵活自如。
- 常态化推进：
分布式治理更容易常态化地推进，保证长期的数据治理效果。
分布式数据自治平台落地
基于这样的治理理念，可以再进一步的通过分布式数据自治平台进行工具化落地，它有着以下多点优势。
- 优势一：业务影响小，灵活的自治模式
首先，由于治理是分阶段、分目标进行的，对业务影响较小，且平台会将业务单元分为多个层次，例如存储库级别、计算资源队列级别、组织架构团队级别等，以便灵活制定目标。
- 优势二：沉淀各业务治理经验，提升治理效率
由于每个业务的治理目标不同，每一个发展较快的业务面临的数据治理问题，在今后，可能是其他业务也会面临的问题，所以这种治理经验的复用是非常必要的，这也是分布式数据自治平台的理念。
比如，电商场景对于数据质量要求很高，现在可能对数据分布有严格要求，而在一些小的业务中，现在可能并不关注数据质量，当电商场景的数据质量经验沉淀下来，其他业务后续想要使用的时候，可以大大提升治理效率。
- 优势三：适配性强，产品建设覆盖治理全链路
分布式数据自治平台具备高度适配性，能够满足多种治理场景。在平台中集成了多种治理场景，如数据稳定性、数据 SLA、数据内容质量、数据规则质量监控、数据整体安全、成本控制等。这些场景可以按照模块化进行拆分，独立输出能力。
平台逻辑架构
分布式数据自治平台的逻辑结构可以整体分为四层。
- 治理用户层
最上面是治理用户层，这一层可以分为三个重要角色。首先是管理角色，管理角色的特点是对治理非常关心，但他不参与具体的治理行动，只看最终目标的实现结果；然后是治理推动角色，一般是在业务线下面具体负责数据治理的人员，他对管理角色所制定的治理目标进行拆解。形成具体的治理方案；再往下去推动，有专门执行人员去具体地推动这个治理工作。
- 治理评估层
治理评估层，其中包括健康分体系和多个大盘能力，这些能力可以帮助我们评估治理水平，并制定具体的治理目标。
- 治理方案层
对资产和问题进行评估后，明确需要治理的范围，制定治理方案，推动方案落地。
- 流程框架层
在流程框架层，整体分成了三个动线流程。
第一条动线是健康分驱动。平台会明确整个团队或某个范围内的健康分是多少，然后对这些分进行分析，定位问题并实施治理，治理完毕之后，健康分的收益将达到目标分数。
第二条动线是规划驱动，团队通过平台对治理目标进行规划，先确定范围，设定好目标后选取规则，执行诊断，然后推进治理行为，这是目前比较核心的一条链路。
第三条动线是基于被动式的响应驱动，比如说数据质量有问题，数据延迟有问题，当这些问题已经出现后，再将这些问题的治理方案流程化地串接起来。
- 基础能力层
最下层是用来支撑上游的所有能力的基础能力层。在基础数据建设方面，平台通过沉淀大量元数据模型来支持数据驱动能力。在此基础上，构建了治理规则引擎层，并沉淀了许多治理规则，用于筛选资产。同时，通过优化工具，形成了治理的单点能力，这些能力会渗透到流程层中，以实现治理流程。最后，收益核算也是重要能力之一，可以有效的控制各项资源成本。
分布式数据治理架构及实践
- 治理体系建设
以小规模打扰业务，高效治理的原则，分布式数据自治平台体系整体分为治理分析、规则式治理、平台级治理三个部分。在治理分析中，用户可以使用大盘来摸清资产现状，并通过评估体系对资产现状进行打分，然后通过下面的看板来推进或晾晒资产问题。在规则式治理中，用户可以使用规则池和自定义规则来制定方案，然后进行扫描和治理操作，并追踪治理效果。最后，在平台级治理中，用户可以划定一个非常大的组织范围，制定如 TTL 或成本规则。
- 推动者 动线
在治理动线上，平台会在前端中提炼治理全景、业务目标、资产和运营信息等方面的问题，然后使用规划诊断的能力将问题具体化，并使用平台工具将目标具体落地。接着，通过治理的明细和中间过程的推进，来观察治理实施的效果，并最终完成方案的总结。
在实施部分，有三个角色，即推动者、执行者和管理评估者。在推动层，可以举一个具体的例子，比如一个用户现在作为某一业务线的治理POC，治理目标是将成本从100PB降到 50PB，用户就可以会通过平台找到一些库，选择存储可节省的方案，并制定策略。这些策略会在平台里面周期性地每天扫描，看现在的资产是不是已经达标。如果进一步发现 50PB 还有一些空间，可以再调整规则，将其沉淀为常态化的治理和跟踪的一部分。
- 实施者 动线
推动者制定治理目标，并将任务分配给实施者，实施者则负责完成这些任务，实施者可以通过系统中的个人工作台获取任务，并通过平台给予的建议和推荐措施来完成任务，最终达成治理目标。
- 创建方案&目标
用户可以通过数据治理平台创建方案和目标，并使用系统中的规则和自定义规则，来实现资产治理的自动化。
第一步是创建方案和目标。在系统中，用户可以根据沉淀数据，为各种资产建立宽特征表，并对其特征进行打标。例如，数据的 TTL 是多少，资产的存数是多少，是否命中了一些治理规则。在圈选到资产后，可以采取几种动作来达成目标，例如，可以同时对这张表进行 TTL 设置和操作，也可以进行温存降级。
这两种方法的收益如何，需要综合考虑，以便在资产治理中实现最大化收益，这个过程由平台负责计算，并会参考其他人已经做过的资产治理分析，进行相似度计算。
- 治理实施&操作（开放性建设）
第二步是实施和操作，平台系统中目前沉淀了 80 多个系统默认规则，包括存储、计算、质量和安全等各种场景。如果用户在使用时感觉不太适配，也可以自定义规则。
例如用户可以通过 TTL 设置一个划定范围来进行治理，但如果用户觉得 TTL 的范围太宽泛，希望能够在资产上打一个业务标，也可以通过自定义规则的方式将其接入系统，以便实现更精细化的资产自动治理。
- 收益统计&结果验收
治理收益的统计是非常重要的，以便业务人员更好地评估治理效果。为此，治理平台也进行了一系列建设，包括将治理平台和三方平台的数据进行整合，形成操作明细；通过离线数仓，精细计算治理收益，形成收益明细，最终治理结果会在平台进行整体展示。
- 平台技术架构
最后，在整体的平台技术架构方面，平台还沉淀了一些公共服务模块，如大盘健康分查询服务，以及规则引擎等。研发团队还为平台设计了任务下发状态，以及具体的原子能力治理工作箱。这些组件和底层引擎架构联动打通，形成了治理平台的技术能力。
数据驱动治理
字节跳动的数据治理工作提倡数据闭环，即首先建立数据资产体系，然后建立评估体系和规则体系，最后实现经验复用。
- 整体数据架构
平台的数据架构是围绕元数据仓库建设的， 9 个治理领域的主题域已经建设落地，并进行了规范的模型构建。在上面，研发团队建设了包括特征、标签、规则等各种数据加工能力，并将这些数据通过入仓、入湖和 OLAP 查询的方式提供给上层平台。
- 资产体系建设
资产体系建设包括数据全景、数仓、采集和组件平台，采用金字塔型的构建方式。研发团队在数据采集和组件打标方面进行了大量优化，以确保源数据的准确性。
- 评估体系建设
评估体系方面，最重要的一点是健康分。平台包括五个维度的健康分，其中列出了三个通用的存储、计算和质量部分。通过各个健康分项的计算，可以形成最终的分数评估，对整个平台、个人、项目等各个维度的资产进行评估。
- 规则体系建设
在规则体系方面，平台有很多全局规则，也可以接入自定义规则，比如生命周期永久扫描规则、生命周期大于多少天的扫描，以及任务产出表近多少天为空的规则。这些规则可以形成多种组合，比如单一性和二异性，比如生命周期永久和生命周期大于等于小于 XX 的值类规则。
- 数据驱动-智能提效
在数据智能提效方面，平台也在不断尝试和应用一些智能提效技术。以下是几个应用比较多的点：
第一， TTL 推荐。 在之前， TTL 推荐可能会指定一些具体的规则值，但现在平台会基于用户在各个业务线中设置的 TTL 的分布情况，进行分布式数据分析，并对不同的数仓层访问热度和表类型进行数据 TTL 的推荐。
第二，温存推荐。 结合 TTL 的能力，可以进行数据分层的推荐，如得分、源数据目录等，这些都可能成为我们数据分层推荐的规则。
第三，治理目标推荐。 通过数据支撑和算法引擎支撑预测治理收益，实现降本增效的目的。
智能化治理探索案例
在字节跳动，也有着许多典型的智能化数据治理案例。
案例一： 在进行存储治理时，由于缺乏一个中心化的平台，数据血缘和数据访问可能不准确，因此不敢轻易删除表。
针对这个问题，字节跳动采用了一种实践方法，通过 HDFS 和引擎侧的深度合作，对数据进行打标，从而将各种数据的引擎来源和表的映射关系进行聚合，最终在 HDS 的审计层上，能够获得各种存储的访问来源，从而实现精细化和准确化的治理判断。
治理团队还使用 Spark engine 和一些弱沉淀规则，对每天运行的任务参数进行不同的调优。在Engine部分，采用了shuffle 类的 OM 自适应策略，以及 Spark 中的 blank list 策略问题，根据历史表现来设置参数。同时，通过各种 event log 来采集数据，形成具体规则，在命中规则后设置参数，使任务运行得越来越好。
目前，字节跳动的几百万个任务中，已经有80%开启了自动调优，效果良好。同时，平台还在进行其他算法的探索，如 SLA 数据质量问题，通过运行时间来保障下游任务的可用性，并进行关键链路的数据分析，形成基于缓冲机制的数据完成时间预测。
案例二： 这个案例是数据内容质量的动态阈值。用户可以通过治理平台使用一些预测方法来分析数据的分布，并根据数据的分布，检测到数据的波动。
案例三： 这个案例是冗余任务探测。平台使用 SQL 的 ST 来计算任务的相似度，并确定是否存在与其他任务相似的任务。如果存在，则将认为该任务是冗余的，其产出的数据也是冗余的，因此没有必要存在。这一方法已经在电商和短视频领域得到广泛应用。
总结及未来展望
火山引擎DataLeap是火山引擎数智平台VeDI旗下的大数据研发治理套件产品，可以帮助企业快速完成数据集成、开发、运维、治理、资产、安全等全套数据中台建设，提升数据研发效率、降低管理成本。
自2022年推出至今，DataLeap提供的数据研发治理能力已陆续被多个行业企业所采用。
未来发展方向
火山引擎DataLeap数据治理平台未来的发展方向主要有三个：
-
方向一： 沉淀更多的行业模板和治理经验，并将其沉淀在平台上，为更多的业务线提供借鉴。这将有助于业务线更好地适应我们的平台，实现数据圈选的目的。
-
方向二： 打造更加完善的生态系统，让业务能够更好地接入我们的平台，通过数据配置、语言、规则和收益等方面的整体优化，实现这一目标。
-
方向三： 进一步提升大模型的加持能力。通过治理建议、一键治理和自动治理等方式，让大模型更好地适应治理领域的要求。同时，积累更多的元数据，为大模型提供更加丰富和准确的信息，以实现更好的总结和推断能力。
除了数据治理平台外，火山引擎DataLeap大数据研发治理套件还可帮助用户快速完成数据集成、开发、运维、、资产、安全等全套数据中台建设，降低工作成本和数据维护成本、挖掘数据价值、为企业决策提供数据支撑。
点击跳转火山引擎DataLeap了解更多