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签署推荐
动态阈值监控
-
问题： 数据量正常分布，但短期异常化的情况。如流量日志在假期或活动日，出现正常突增或突降的情况。
-
解决思路：常规的数据 质量监控通常限定绝对值阈值，如历史7天波动率等，容易造成假期或活动日误报警，给值班人员造成不必要的打扰。 DataLeap 提出了动态阈值的思路：基于数据历史情况，归纳出不同分布情况，并提供不同的预测方法。例如，动态阈值预测整个表在某一天的量级情况，然后基于数据量级设置上下阈值，超出阈值再进行报警或消息通知。
有相似任务识别
以上是 DataLeap 在智能化方面的一些探索。
架构总结与未来展望
架构总结
最后总结一下，平台总体架构分为三层。
-
产品层，从管理者视角和执行者视角做出区分。在具体治理过程中，遵循双路径方式：
-
服务层，也称为整体服务逻辑层，拆分了数据服务、任务执行、消息服务、 事件中心 等不同模块，特别是接入服务模块，能够提供开放能力。
-
数据组件层，作为基础建设层，包括 元数据 仓库建设、 大数据 组件适配等。
未来展望
未来展望主要包括三个部分。
在平台建设阶段， DataLeap 已经建立比较完善的能力，并在内部有效应用。接下来，我们会继续贯彻双路径的建设方式。在规划式路径上，使资产更清晰、规则更丰富，进一步打磨 动线 ，提高收益准确性。在响应式路径上，除了问题登记、归因外，后续将主要针对总结归纳、经验沉淀进行建设，使字节内部治理经验更好地复用到其他业务方。
分布式自治的理念，保证业务可以自定义目标，并对齐 SLA 。后续，我们将从三个方面持续开放能力：
-
自定义指标，比如自定义健康分、自定义组织，使不同业务可以自身情况定义健康分的组织形式和描述。
-
自定义方案，进一步打磨自定义规则的接入流程，并将规则能力开放，支持业务调用，并完成自身资产分析。
-
打通业务，以业务视角看待问题，针对业务问题和需求，完善平台建设。
目前 DataLeap 大部分都是统计类规则，正在建设挖掘类规则。后续会在智能化模型建设方面，做更多预测分析。
以上介绍的一站式数据治理能力和实践，目前大部分已通过火山引擎DataLeap对外提供服务，欢迎大家体验。
