文章主题：关键词: 数据智能知识地图, DataLeap, 大数据研发治理, 治理全链路
17位高级专家共同打造，涉及15个领域，133个体系框架，1000个细分知识点！
关注公众号“大话数智”，免费下载这份《数据智能知识地图》⬇️
📊🚀DataLeap，VeDI火山引擎的数智平台瑰宝，专为大数据建台而生。它以卓越效能助力，一键集成数据，开发运维无缝，治理资产全面，安全防护周密。无论是数据集成的速度，还是降低运营成本，或是深度挖掘价值，DataLeap都是您的得力助手。为企业决策提供坚实的智慧支持，让数据的力量触手可及。🌍💼
本篇文章主要围绕火山引擎 DataLeap 一站式数据治理实践展开分享，具体包括以下四个方面内容：
机遇与挑战数据治理思路技术架构演进未来展望
分享嘉宾｜王慧祥 火山引擎 DataLeap资深大数据工程师
编辑整理｜小宁 滴滴
出品社区｜DataFun
01/机遇与挑战
数据治理工作有很多挑战，最主要的一点是落地比较困难。
首先，治理工作中与业务有一定的矛盾。
第二，治理涉及的组织和管理难度大。
🌟在第三步中，管理”人”的动作变得极具挑战性。在这个环节，人力的推动与执行至关重要，然而团队成员的能力水平参差不齐，组织架构中的文化差异及目标不一致问题也不容忽视。🚀
🌟在数字化转型的浪潮中，一个关键挑战是未能拥有高度适应的工具💡。治理工作涵盖众多领域，从端到端的流程优化，需要一个强大的产品生态系统来支撑，它能够有效地链接各部门，跨越系统边界，实现目标的一致与协同。🚫现有的产品平台往往无法满足这种复杂性和需求深度，成为制约效率提升的一大瓶颈。
下面结合字节的特点，介绍数据治理工作的机遇和挑战。
字节文化
首先，字节业务多，多业务齐头并进发展，需要快速响应业务需求。
🌟了解了吗？💡字节跳动的OKR文化是其独特魅力之一，它赋予每个员工权力，参与到数据治理的全局构想中，从战略到执行，每个人都是推动者。🎯通过这种方式，大家积极主动地寻求解决方案，迅速与公司的目标保持一致，形成了一股强大的团队执行力。🌈这种开放且高效的机制，不仅增强了员工的参与感，也让数据治理工作更加顺畅和高效。SEO优化提示：#字节跳动OKR文化 #数据治理参与 #团队执行力
第三，为追求高效治理，没有设立统一的数据治理委员会，而是各个部门根据各自的业务情况进行治理。
业务第一
字节业务规模大，并且以数据作为驱动构建闭环的产品较多，导致数据质量对业务的影响非常大。
综上所述，数据治理在字节是挑战机遇与并存的工作。
—
02/数据治理思路
1. 新型数据治理——分布式数据自洽
🔥📊大数据挑战面前，DataLeap 火山引擎独辟蹊径，创新性地提出了一套分布式数据自治的理念。我们专注于最大化治理效益与最小化业务干扰，同时确保执行效能的高效运转。🎯💡通过深度分析和策略优化，让数据在复杂网络中自由流动，释放其真正的力量。🌍🌐无论数据规模多大，都能从容应对，实现数据价值的最大化。🌟🏆让我们一起，用智慧驾驭数据，引领未来趋势！联系方式：[隐藏]
🌟在业务层面，为了实现最小化干扰，我们采取了按业务单元的策略来进行数据治理。每个单元可能是微型企业或单一项目，成为了我们关注与优化的目标领域。🛡️
第二，需要沉淀各业务线的治理经验，提升治理效率；通过产品辅助业务自驱，实现规则化、策略化、自动化治理。通过工具等平台能力，降低治理门槛。并且支持灵活的治理方式，如管理者视角，自上而下规划性治理，和一线执行者视角，自下而上推动治理。
第三，需要适配性强，建设产品来覆盖治理全链路。
实现多种场景中，产品都有能力覆盖，多个模块可以独立使用，按需组合；并且提供完整的开发能力，支持业务根据自身特点和发展阶段，自行接入。
2. 集中式 VS 分布式
与传统集中式治理相比，分布式治理有很多优势：
集中式治理，需要制定制度进行大范围组织，划分权责，定期抽查考核，建设周期长，适配能力弱，并且组织投入多。分布式自治，业务影响小；周期短，见效快；效率高，节省人力；便于算清对业务的收益，降低成本。
—
03/技术架构演进
针对上述思路，平台工具如何支撑数据治理？
1. 解决方案——一站式
DataLeap 一站式数据解决方案，主要划分为三层。
① 第一层 视图层
从资产视角、管理者视角 、实施者视角，纵览数据治理的情况。
② 第二层 方案层
针对治理过程，提出了双路径。
路径一，【主动规划】规划式流程
主要解决的问题是：确定目标后，如何推进执行。将治理目标，拆解成治理规则，进行诊断，根据诊断结果，执行治理。治理结束后，通过收益统计、改进计划等进行总结。
路径二，【系统发现】响应式流程
由系统发现的问题，通过高警等形式，通知到资产责任人，进行处理。通过根因分析等，进行总结。
③ 第三层 工具层
为上述两层，提供完备的治理工具。覆盖质量、安全、成本、稳定性、报警与起夜等场景，通过打通基础服务，赋能上述两条治理路径。
2. 平台建设——治理方案——规划式流程
接下来将为大家介绍，在治理过程中，我们两条路径的具体建设过程。
（1）路径一，规划式治理
目标是资产清晰，规则丰富，动线完整，收益准确。
首先需要制定目标，包括健康分目标，以及降低存储、计算资源的目标。针对目标，建立治理方案，包括划分治理域，以及在治理域内通过规则，发现有问题的资产。建立方案后，由系统找到有存储、计算等问题的明细。对上述找到的问题进行分析，通过消息催办等方式，将问题下发到责任人，进行治理。系统会对治理的效果进行采集，反馈目标达成情况，并对一段时间内的治理结果进行验收和统计。
以上是规划式流程的主线思路 。
下面介绍如何实现规划式流程的几个目标。
① 资产清晰
主要从治理全景和健康分两个方面对资产进行描述。
第一，治理全景。从各个维度，通过明细、统计量，对团队或个人资产的具体情况进行描述。如各个表占了多少存储空间，计算资源使用情况，任务报警率、起夜率，数据及时性和质量等。
第二，对资产健康度进行衡量。根据三个层级建立了健康分体系。第一层是根据治理的垂直方向划分，包括：存储健康分、计算健康分、质量健康分等。第二层在第一层的维度下，细化了问题大类。如存储方面，包括：无效存储、异常存储等；质量方面，包括：及时性、报警、元信息配置规范等。
在第二层的划分下，将具体问题通过标签定义，得到了第三层。比如无效存储方面，涉及了 TTL 不合理、热度方面信息（xx 天无查询）等。
综上，主要通过健康度和治理全景将资产清晰地表述出来。通过元数据仓库，进行底层数据的建设。
② 规则丰富
目前平台具备了完备的治理规则，涵盖了存储、计算、质量、报警 4 大维度，50 多个规则。
其中包括全局规则，如：生命周期永久、近 7 天产出为空、暴力扫描任务等；也包括一些自定义的规则，如生命周期 xxxt 天，近 xxx 天产出为空等。同时还兼具了一些挖掘类规则，包括基于统计信息进行聚合后形成的规则，以及基于资产（包括库、表等）相似性，通过关联、排序来发现问题。
规则部分以及能力建设方面分为以下几部分：首先通过底层与平台基础组件打通，将数据收集上来，形成数据仓库的基础层；基于基础层对数据资产进行画像描述，进一步形成特征域，做特征挖掘和关联分析；然后将应用的数据，放到数据服务中，对外提供灵活的数据查询能力。
最上层为组合在线的规则引擎，将数据和规则进行联动，应用于规则建设。
③ 动线完整
标出有问题的资产后，如何尽快完成治理，减少和业务的冲突，提高效率非常重要。
基于治理平台的能力，在各个垂直场景中，我们建设了比较完善的治理动线。
大致的思路是，把能力划分为几类：
任务治理方面，和任务开发、任务运维平台打通，支持任务的关闭、调整、调参，链路优化。库表规范方面，和元数据平台联动，实现表管理、库管理、资产移交、属性修改等；生命周期方面，通过治理平台，和底层的存储（包括 hdfs, hive 等组件）打通，形成闭环式的治理；在数据质量方面，包括 sla 的及时性，离线、实时数据的监控，会和具体的质量规则平台进行强联动，互相登记数据、进行 sla 的签署、和强跳转交互等。
以上是动线完整的部分，能够使用户在平台中，通过很低的操作成本，完成一站式的闭环治理。
④ 收益准确
第四个是收益的准确部分。
我们做了治理后，付出的人里成本、精力、怎么知道是有效或者达标呢？如何衡量这一阶段的工作是有价值的，治理是有收益的？这就需要在平台建设上，准确度量收益。目前统一建设了基于事件中心的底层框架。总体来说，就是定义数据的消费模型，通过上面的一些消息通道，来定时收集各个平台操作的消息；同时定义了事件的 SDK, 并兼容 API 的方式，灵活对接上游不同的平台。
目前来说，我们和研发平台、元数据平台、质量平台等，大部分都是通过消息订阅和消费的方式，将治理的事件，接入到事件中心里，并将事件中心的离线数据 dump 到数据仓库，进行离线加工，同时我们会将最新的事件，注入在线的元数据服务中，来及时完成治理收益的计算。
⑤ 技术架构
在规划式流程的技术方面，遵循的原则是：统一的数据查询、各种规则灵活组合，操作结耦，治理收益准确。
整体的平台后端，会负责分发和转换治理的各种逻辑，包括查数、设置目标、健康分的展示和透出，治理的操作等。
后端平台拿到消息后，会做具体事件的拆分。比如说看板类查数的部分，统一将需求发送到查询服务里，数据查询服务会对底层存储做适配，通过点查、list、聚合类的查询，根据底层选取的存储引擎的特点，解析后，选取不同的底层存储。
规则引擎服务部分，可以与数据查询服务联动。通过数据查询服务取到数据后，通过规则的定义形成标签，这个过程可以抽象成一个服务。这个服务对外可以提供对资产标签的描述，作为通用的能力。
在治理的具体实施部分，我们统一抽象成一个后台的模块。具体的实施，如设置消息、设置 ddl、进行删除等，统一由这个模块下发到组件层，进行操作，在组件层或其他平台进行了有效操作后，由事件的收集服务，将事件收集上来，写回到数据查询服务，形成治理收益的汇总。
3. 平台建设——治理方案——响应式流程
第二条路径是响应式路径。主要做事后治理、问题总结、经验沉淀。
在这条路径里，大致分了几个部分，首先以报警、消息作为源头。包括sla破线告警，数据质量任务的报警，计算任务的报警等。
系统会将上述消息进行汇总，展示在治理平台中。治理平台可以对消息进行搜索，对问题进行归因，并做根因打标，把问题定位到组件、平台等问题上；再通过一些组织方式，比如通过系统来去找到组件方面的对接人，或通过组织会议，将问题提给相关的责任方，推动他们做一些有针对性的保障。做了以上推进后，我们会将系统中的问题描述、改进计划列出来，有针对性地对问题进行定义，以及分析该怎么做达到事后治理的目的。最后，在问题解决后，推动方案的分享、沉淀和复用。
技术架构
响应式治理的架构，和规划式治理类似，区别是里面消息服务的部分。这部分作为基础的能力，将大数据平台的各种产品，包括研发平台、质量平台等所有的消息，接到统一的服务中，所有消息的发出，都通过服务对外。这个消息服务成为所有报警消息的入口。通过它可以做一些升级策略，如消息聚合、加急等。此外，和规划式治理类似，后端平台控制响应式路径的逻辑，包括消息订阅、问题登记、总结复盘模块等。其他部分和规划式路径类似。
4. 平台建设——开放接入
讲完两条路径，下面是一些实践中的解决思路。因为业务有各自发展的阶段，以及不同的治理目标。比如说，比较新兴的业务，现在主要关注的是 sla 的能力；一些成熟的业务，现在做的已经比较好了，要去做规范性。不同业务有不同的诉求。如何避免一刀切，让不同的业务用平台进行治理，开放能力非常重要。开放能力是说，要构建治理生态，业务可以自定义地接入治理规则，实施治理。
当前阶段，将治理分为了四个象限，横坐标为元数据部分，纵坐标为规则的部分。规则包括表达式和算法包等形式。系统提供的能力，主要在一象限：定义的标准的元数据，和统一的表达式，通过规则引擎直接适配。如果业务方有第三方元数据，来接入我们已定义好的规则，如图中第二象限的部分，需要定义第三方元数据的接入。接入的第三方元数据需要遵循接入的标准，通过规则引擎进行适配。规则部分如果要做升级，比如进行相似度计算等，不是在一维上对资产打标，不是纯表达式可以描述的规则，这种情况下将其定义为算法包或者逻辑单元。需要定义好输入输出的标准，通过调用包或者插件的方式，执行逻辑。第三方元数据和算法包的结合同理，定义好输入输出，并关注包的执行效率、时间等，就能满足整体的接入。
整体来说，将平台能力开放出去，让业务接入自己的规则和数据，需要定义好标准的元数据格式，比如：可以定义行是具体的资产，列是具体的 profile。业务方负责加工自己的接入部分，完成配置和数据映射，通过表达式或者算法包的计算后，定义统一的输出，就可以对接到系统。目前，系统支持对单资产打标（pointwise）和两个资产关联打标（pairwise）。目前，上图的开放接入能力正在开发当中，未来将对外提供服务。
5. 平台建设——智能化能力
接下来是近期在做的事情。平台工具侧做了很多能力上的建设，通过智能化的方式，进一步降低治理成本，提高治理效率。下面介绍几个有代表性的落地。
① 任务 SLA 签署推荐
在做 SLA 签署时候，任务上下游，可能存在几百上千个节点，怎样估计出应该在什么时间产出呢？我们目前是通过血缘关系，找到节点所在的关键路径，基于运行时间，进行权重的分配，来确保节点有相对合理的 SLA buffer。
推荐签署部分，目前已经有了专利，并有了一定的效果。现在在做第二期，基于运行失败概率分布的情况，来调整上游 buffer 压缩，下游 buffer 宽松的问题。
② 动态阈值监控
解决的问题是：数据量正常分布，但看起来异常化的情况。比如流量日志在假期或活动日，出现正常突增或突降的情况。
平时做质量监控时候，会用绝对值阈值来限定作报警范围，比如参考历史7天波动率等。这样，容易造成假期或活动日误报警，给值班人员造成不必要的打扰。动态阈值就是为了解决这个问题。主要思路是：基于数据的历史情况，归纳为几种分布。针对不同的分布，提供不同的预测方法，预测整个表在某一天应该是在什么量级，然后基于数据量级设置上下阈值，超出阈值再进行报警或者消息通知。
在数据分布方面，针对我们自己的业务，划分了几种典型的分布：数据量单调不减的，大部分为快照表或者全量表；日志类的表，长时间观察时，假期或活动日可能出现数据量突增或突降；维度表，数据量比较稳定，维度发生变化时，会反应出一定的问题；以及与维度表类似的一些波动比较小的分布。
基于不同的数据分布，目前采取了四种不同的预测方法：移动平均法、指数平滑法、自回归法、同期检测法。针对不同的波动做拟合，目前得到了一定的验证。
③ 有相似任务识别
由于业务庞大、开发人员多、任务量大，在开发任务时，并不知道是否线上已有类似的任务，跨团队情况更明显，因此详细任务的检测很有必要。
基本思路是将目标源代码和待检测源代码 sql 的 ast 序列化，然后进行向量化，对特征向量做余弦相似度计算，结果通过产品进行透出，再由业务进行标注，经过人工的确认分析，对任务进行合并或下线。
以上是我们在智能化方面的一些探索。
6. 平台建设——架构总结
总结一下，平台总体架构分为三层。
产品层，将管理者视角和执行者视角做了区分。具体治理时候，通过双路径的方式：做规划式治理时候，从目标制定、规则圈选、治理实施、到收益统计、经验总结；第二条路径是响应式治理。通过订阅消息、发现问题、实施治理、登记问题、复盘总结几个步骤进行治理。服务层，提供了整体的服务逻辑层，在下面拆分了不同的模块，特别是接入服务，提供了开放的能力。通过对任务执行、事件中心等不同模块进行拆解，方面我们针对各种不同的场景，提供灵活服务。数据组件层，作为基础建设层，包括元数据仓库的建设、大数据组件的适配。
—
04/未来展望
未来展望主要由三个部分。
体验打磨
平台建设阶段，已经建立了比较完善的能力，在内部得到了有效的使用。进一步，会更加贯彻双路径的建设，规划式路径上，使资产更清晰、规则更丰富，进一步打磨动线，并提高收益准确性。
响应式路径上，除了问题登记、归因、总结外，后面会主要针对总结归纳、经验沉淀进行建设，使经验更好地复用到其他业务方。
开放能力
基于分布式自治的理念，目前没有采取一刀切的策略进行治理。大家可以自定义自己的目标，对齐自己的 SLA 等。后续会支持自定义健康分，不同业务可以自己定义健康分的组织形式和描述。
第二点是自定义方案。我们会进一步打磨自定义规则的接入流程，并将规则能力进一步开放化，支持业务调用。业务拿到打标后的信息，可以做自己的资产分析。
第三点是打通业务，进一步以业务视角看待问题，针对业务问题，做好平台建设。
增强型数据治理
目前大部分是基于统计类规则，正在建设部分挖掘类规则。
后续会在智能化模型建设方面，做一些预测分析。
以上介绍的一站式数据治理能力和实践，目前大部分已通过火山引擎 DataLeap 对外提供服务，欢迎大家体验。
—
05/问答环节
Q1：数据倾斜任务的判断规则是什么？是分析 spark 的运行日志么？
A1：根据每个任务运行时输入的数据量、运行时长进行计算，结合 spark 的 metrics，定义倾斜率的阈值。比如某个 task 在特定数据量下，在一定时间内没有运行完成，就定义为倾斜。
Q2：归因分析是否可理解为知识库的应用？
A2：（1）归因分析主要解决这类问题：出现问题（如数据波动）时，帮助工程师排查是哪一环节的问题，是采集侧、埋点侧还是逻辑侧。
（2）另一方面在于解决上述问题后，对问题进行总结分析。
目前主要精力在第一块，第二块是是目前正在规划要做的事情。
今天的分享就到这里，谢谢大家。
分享嘉宾
王慧祥｜火山引擎 DataLeap资深大数据工程师
负责字节跳动数据质量、资源优化等大数据领域的数据治理平台的研发工作，在海量数据场景下的存储资源治理、任务资源治理、数据SLA保障、离线及流式数据监控等场景上拥有较多的平台化、系统化解决经验。
DataFun新媒体矩阵
关于DataFun
专注于大数据、人工智能技术应用的分享与交流。发起于2017年，在北京、上海、深圳、杭州等城市举办超过100+线下和100+线上沙龙、论坛及峰会，已邀请超过2000位专家和学者参与分享。其公众号 DataFunTalk 累计生产原创文章900+，百万+阅读，近16万精准粉丝。
Related posts
