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已经建立比较完善的能力，并在内部有效应用。接下来，我们会继续贯彻双路径的建设方式。在规划式路径上，使资产更清晰、规则更丰富，进一步打磨动线，提高收益准确性。在响应式路径上，除了问题登记、归因外，后续将主要针对总结归纳、经验沉淀进行建设，使字节内部治理经验更好地复用到其他业务方。
- 开放能力
分布式自治的理念，保证业务可以自定义目标，并对齐SLA。后续，我们将从三个方面持续开放能力：
- 自定义指标，比如自定义健康分、自定义组织，使不同业务可以自身情况定义健康分的组织形式和描述。
- 自定义方案，进一步打磨自定义规则的接入流程，并将规则能力开放，支持业务调用，并完成自身资产分析。
- 打通业务，以业务视角看待问题，针对业务问题和需求，完善平台建设。
- 增强型数据治理
目前DataLeap大部分都是统计类规则，正在建设挖掘类规则。后续会在智能化模型建设方面，做更多预测分析。
以上介绍的一站式数据治理能力和实践，目前大部分已通过火山引擎DataLeap对外提供服务，欢迎大家点击「阅读原文」体验。
产品介绍
火山引擎大数据研发治理套件DataLeap
一站式数据中台套件，帮助用户快速完成数据集成、开发、运维、治理、资产、安全等全套数据中台建设，帮助数据团队有效的降低工作成本和数据维护成本、挖掘数据价值、为企业决策提供数据支撑。 后台回复数字“2”了解产品。
字节跳动数据平台开发套件团队火热招人中！
后台回复“招聘”，获取岗位信息。
点击 阅读原文
进入官网
， 了解DataLeap更多产品信息
