您现在的位置是：首页 > 文章详情

火山引擎DataLeap：3个关键步骤，复制字节跳动一站式数据治理经验

日期：2023-02-10点击：231收藏

DataLeap 是火山引擎数智平台 VeDI 旗下的大数据研发治理套件产品，帮助用户快速完成数据集成、开发、运维、治理、资产、安全等全套数据中台建设，降低工作成本和数据维护成本、挖掘数据价值、为企业决策提供数据支撑。

本篇文章主要围绕火山引擎 DataLeap 一站式数据治理实践展开分享，从数据治理思路、平台建设以及能力升级三个步骤出发，带你全面复制字节跳动数据治理经验。

▌机遇与挑战

数据治理存在落地困难的问题，体现在：

首先，治理效益与业务影响存在矛盾。数据治理需要对业务系统、生产流程改造，由此对业务造成影响。

第二，治理涉及的组织和管理难度大。数据治理涉及的角色多、范围广、链路长，且治理目标对齐、管理和跟进难度大。

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

第四，缺乏适配性强、全局视角且灵活的数据治理工具。

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

字节文化

首先，字节业务多、发展快、敏捷迭代，要求能快速响应业务需求；

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

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

业务第一

字节业务规模大，且强调数据驱动，导致数据质量对业务的影响非常大。

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

▌3个关键步骤，复制字节跳动数据治理经验

步骤一：创新数据治理思路——分布式数据自治

什么是分布式自治？

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

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

第二，沉淀各业务线治理经验，提升治理效率。

通过产品辅助业务自驱，实现规则化、策略化、自动化治理。
通过低门槛、算法推荐等平台能力，降低治理门槛。
支持灵活的治理方式，如管理者视角，自上而下规划性治理；如一线执行者视角，自下而上推动治理。

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

产品能力覆盖稳定性、质量、安全、成本、报警等多场景。
各模块可以独立使用、按需组合。
产品提供完整的开发能力，支持业务根据自身特点和发展阶段自行接入。

与集中式治理的区别

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

集中式治理：要求制定制度，并进行大范围组织推广；要求划分权责，定期抽查考核；建设周期长，适配能力弱，且组织投入多。
分布式自治：业务影响小；周期短，见效快；效率高，节省人力；便于算清业务收益，降低成本。

步骤二：构建一站式平台，引入数据治理双路径

一站式数据治理平台架构

DataLeap 一站式数据解决方案，主要划分为三层。

第一层视图层

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

第二层方案层

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

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

主要解决的问题是确定目标后，如何推进执行的问题。主动规划路径还支持治理目标拆解成治理规则进行诊断，并根据诊断结果，执行治理。最后，通过收益统计、改进计划等进行总结复盘。

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

先由系统发现问题，再通过告警等形式通知资产责任人，并进行处理。最后通过根因分析等完成总结。

第三层工具层

工具层主要为视图层、方案层提供完备的治理工具，覆盖质量、安全、成本、稳定性、报警与起夜等场景。工具层还通过打通基础服务，赋能主动规划和系统发现两条治理路径。

适用于业务驱动的规划式流程

接下来为大家介绍规划式路径的具体建设过程。

特点： 资产清晰，规则丰富，动线完整，收益准确。
思路：
- 制定目标，包括健康分目标，以及降低存储、计算资源等。
- 根据目标制定治理方案，明确治理域、圈选治理规则。
- 制定方案后，由系统自动查询存储、计算等问题的明细，经过分析后，通过消息催办等方式，将问题下发到责任人，推动数据治理。
- 系统自动对治理效果进行采集，反馈目标达成情况，并对一段时间内的治理结果进行验收和统计。

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

下面介绍如何实现规划式路径的主要实现手段。

资产清晰

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

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

第二，健康分。 主要根据治理的垂直方向划分为存储健康分、计算健康分、质量健康分三个层级。在第一层的维度下，第二层细化问题大类，如存储方面，包括：无效存储、异常存储等；质量方面，包括：及时性、报警、元信息配置规范等。第三层则将具体问题通过标签定义，如无效存储涉及 TTL 不合理、热度方面信息(xx天无查询)等。

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

规则丰富

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

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

DataLeap 治理规则主要通过以下流程建设起来。

首先，通过底层与平台基础组件打通，完成数据收集，形成数据仓库的基础层；
其次，基于基础层对数据资产进行画像描述，进一步形成特征域，做特征挖掘和关联分析；再将应用数据放到数据服务中，对外提供灵活的数据查询能力。
最后，通过最上层的规则引擎，将数据和规则进行联动，应用于规则建设。

动线完整

明确出问题的资产后，如何尽快完成治理，减少和业务的冲突，对于提高效率至关重要。

基于治理平台的能力，结合各个垂直场景， DataLeap 建设完善的治理动线。大致的思路如下：

任务治理方面，与任务开发、任务运维平台打通，支持任务关闭、调整、调参，链路优化等；
库表规范方面，和元数据平台进行联动，实现表管理、库管理、资产移交、属性修改等；
生命周期方面，通过治理平台将底层存储（包括 hdfs 、 hive 等组件）打通，形成闭环式治理；
在数据质量方面，涉及 sla 及时性，离线、实时数据监控等，通过与质量规则平台强联动，互相登记数据，进行sla签署以及强跳转交互等。

完整的动线能使用户在平台中，以低操作成本完成一站式闭环治理。

收益准确

完成治理后，如何判断治理收益？

目前 DataLeap 建设了基于事件中心的底层框架。通过定义数据的消费模型，由消息通道来定时收集各个平台操作的消息；同时，通过定义事件 SDK ,兼容 API 的方式，来灵活对接上游不同平台。

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

技术架构

在技术架构层面，遵循以下原则：统一数据查询、规则灵活组合、操作解耦、治理收益准确。

平台后端负责分发和转换治理逻辑，包括查数、设置目标、健康分展示与透出，治理操作等；
根据获取的消息后，后端平台进行具体事件拆分。举个例子，在看板类查数的部分，需求将统一发送到查询服务完成底层存储做适配，通过点查、list、聚合类查询，并在解析后选取不同的底层存储。
规则引擎服务可与数据查询服务联动。通过数据查询服务获取数据，再通过规则定义成标签，并抽象成服务。该服务可以对外提供对资产标签描述，并成为通用能力。
数据治理具体实施被统一抽象成后台模块，包括设置消息、设置ddl、进行删除等。由该模块下发到组件层进行操作，再通过事件收集服务，并返回数据查询服务，完成治理收益汇总。

适用于经验沉淀的响应式流程

特点：事后治理、问题总结、经验沉淀。
思路：
- 首先，接到报警和消息，包括 sla 破线、数据质量报警、计算任务报警等；
- 其次，系统将上述消息汇总，并展示在治理平台中。数据开发人员通过治理平台进行消息检索、问题归因，并完成根因打标，把问题具体定位到组件、平台等颗粒度；
- 再次，通过公司组织方式找到组件侧对接人，或通过组织会议将问题提交给相关责任方，推动对方完成保障；
- 最后，列出系统中的问题描述、改进计划，定义问题并分析治理效果，并在问题解决后，推动方案分享、沉淀和复用。

响应式治理架构与规划式治理大部分类似，最大区别在于消息服务部分。作为基础能力，消息服务将大数据平台相关产品中的消息，接入统一服务中，成为所有报警消息入口。并且消息服务还可以做升级策略，如消息聚合、消息加急等。

步骤三：开放接入、智能化数据治理能力升级

开放接入

业务有各自发展阶段以及不同治理目标。例如，新兴业务核心关注 sla 的能力；而成熟业务，则更重视规范性。如何避免一刀切，让不同业务需求都能通过同一个治理平台满足？开放能力很重要。也就是说，要构建数据治理生态，让业务可以自定义接入治理规则，并实施治理。

当前阶段，我们将数据治理分为四个象限，横坐标为元数据（三方元数据、标准元数据），纵坐标为规则（表达式、算法包）。

第一象限&第二象限：第一象限主要为定义标准元数据和统一表达式，通过规则引擎直接适配。如果业务方存在第三方元数据接入已定义规则，则如第二象限所示，接入的第三方元数据需要遵循接入标准，并通过规则引擎完成适配。
第三象限&第四象限：如果规则部分要进行相似度计算，且不是表达式可以描述的规则，则被定义为算法包或逻辑单元。如第三象限&第四象限所示，要求定义输入、输出标准，通过调用包或插件方式，执行逻辑。

整体而言，将平台能力开放，让业务接入自身的规则和数据，基础是治理平台有完善的元数据格式和接入标准。业务方只需负责加工自身接入部分，完成配置和数据映射，通过表达式或算法包计算后，完成统一输出。

目前，上图的开放接入能力正在开发当中，未来将对外提供服务。

智能化能力

接下来介绍智能化能力，该能力可以进一步降低治理成本，提高治理效率。代表性落地场景如下：

任务SLA签署推荐

问题： 在 SLA 签署中，任务上下游可能存在上千个节点，如何估计产出时间？
解决思路： 目前主要通过血缘关系找到节点的关键路径，基于运行时间进行权重分配，确保节点有相对合理的 SLA buffer。在推荐签署环节， DataLeap 目前已经申请专利，并在生产中产生一定效果。第二期将基于运行失败概率分布情况来调整上游buffer压缩，下游buffer宽松的问题。

动态阈值监控

问题： 数据量正常分布，但短期异常化的情况。如流量日志在假期或活动日，出现正常突增或突降的情况。
解决思路：常规的数据质量监控通常限定绝对值阈值，如历史7天波动率等，容易造成假期或活动日误报警，给值班人员造成不必要的打扰。 DataLeap 提出了动态阈值的思路：基于数据历史情况，归纳出不同分布情况，并提供不同的预测方法。例如，动态阈值预测整个表在某一天的量级情况，然后基于数据量级设置上下阈值，超出阈值再进行报警或消息通知。
- 数据分布：数据量单调不减，大部分为快照表或全量表；假期或活动日可能出现数据量突增或突降，往往为日志类表时；数据量比较稳定，维度发生变化时，能反应出一定问题，往往是维度表。
- 预测方法：移动平均法、指数平滑法、自回归法、同期检测法。

有相似任务识别

问题： 由于业务庞大、开发人员多、任务量大，在开发过程中，存在不知道线上是否存在类似任务的问题，在跨团队情况下更明显，因此任务检测非常必要。
解决思路 ： DataLeap 的基本思路是将目标源代码和待检测源代码 sql 的 ast 序列化和向量化，对特征向量做余弦相似度计算，通过产品进行计算结果透出，再由业务完成标注，经过人工确认分析，对任务进行合并或下线。

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

架构总结与未来展望

架构总结

最后总结一下，平台总体架构分为三层。

产品层，从管理者视角和执行者视角做出区分。在具体治理过程中，遵循双路径方式：
- 规划式治理：目标制定、规则圈选、治理实施、收益统计、经验总结
- 响应式治理：订阅消息、发现问题、实施治理、登记问题、复盘总结
服务层，也称为整体服务逻辑层，拆分了数据服务、任务执行、消息服务、事件中心等不同模块，特别是接入服务模块，能够提供开放能力。
数据组件层，作为基础建设层，包括元数据仓库建设、大数据组件适配等。

未来展望

未来展望主要包括三个部分。

体验打磨

在平台建设阶段， DataLeap 已经建立比较完善的能力，并在内部有效应用。接下来，我们会继续贯彻双路径的建设方式。在规划式路径上，使资产更清晰、规则更丰富，进一步打磨动线，提高收益准确性。在响应式路径上，除了问题登记、归因外，后续将主要针对总结归纳、经验沉淀进行建设，使字节内部治理经验更好地复用到其他业务方。