如何实现持续、主动、长效的数据治理？主动元数据或是最佳答案

元数据是数据治理的关键要素。长久以来，企业的元数据采集、管理与服务停留在“被动模式”，管理范围以表为主，采集与更新方式由人工完成，数据解析方式单一且无法保证准确率，更缺乏智能挖掘能力，应用场景有限。基于被动元数据的运动式数据治理历时久、人力消耗大且效果难以长效积累。

如何让元数据变“被动”为“主动”，走向场景化、自动化和智能化，是企业实现链路保障自动化、架构治理长效化的关键。

01 数智化时代，数据治理面临新挑战

随着数字化持续深入，数据管道日益复杂，“多源异构”数据增多，包括数据库、Log 日志和非结构化数据等。这些数据通过 ETL 加工入仓、入湖，随后经多层数据建模，转化为结构化的宽表或数据看板，最终应用于各类业务看数或数据分析场景，辅助业务决策。在此背景下，传统的人工 ETL 作业已经难以应对复杂的数据治理需求，急需升级到“自动化治理”。

一、数据加工链路愈发复杂。数据加工链路层级不断增长，数据交叉依赖日益加深，使得用户元数据管理，或者数据盘点和加工逻辑理解越来越困难，需要花费更多的时间去厘清数据链路。

二、数据变更协同不及时。企业内部，跨部门数据融合越来越多，上下游数据协同时效性难以保证。上游数据发生变更，无法及时准确地同步下游，也无法清晰判断对下游有哪些影响，导致链路末端报表、指标等应用出现数据延迟、数据错误。这就要求具备高效的数据监控和预警机制，实时追踪数据变更，自动触发通知，保证数据协同。

三、重复资产冗余浪费。数据需求量急剧增加，烟囱式开发模式不断涌现。A 部门和 B 部门即便基于相同底表，也可能独立开发并维护专属的应用表，以快速响应业务特定需求。尽管该策略短期内加快业务需求速度，但对于大型公司而言，不可避免地产生大量冗余表，占用存储资源，计算成本不断增加，进而影响到整体的运营效率和成本效益。

为此，我们认为，企业需要主动元数据的能力，来重构数据治理模式。

02 主动元数据，重构数据治理模式

那什么是主动元数据呢？我们认为它是一种动态、智能化的元数据管理技术，主要包含三个方面的能力：

一、全面。传统的元数据管理，主要聚焦于表、列等基础数据及数仓内任务的监管。今天，我们需要全面管理更为广泛的元数据范畴，包括脚本、模型、指标、报表以及数据使用行为等与数据相关的所有元数据。

二、精准。主动元数据能够通过自动化实时采集、动态更新，结合多样化的 SQL 和 PLSQL 语言解析，自动构建全面、准确、实时、精细的算子级血缘图谱，实现解析精准度大幅提升，清晰反应数据之间的依赖关系和流转路径。

三、智能。能够实时监控数据变更，预测数据质量问题和合规风险，提供智能化的建议。比如，通过实时监测调度运行延迟情况，智能评估对整个基线链路的潜在影响，进而为各个场景提供智能化建议，以保障业务稳定运行。

关于主动元数据跟被动元数据的区别，我们认为包括以下几点：

• 管理范围：被动元数据以表为主，主动元数据包括表、脚本、模型、指标等一切与数据相关的元数据；
• 采集方式：被动元数据以手工录入为主，主动元数据通过自动化采集方式；
• 更新方式：被动元数据偏静态，人工触发，主动元数据自动化，动态更新；
• 解析方式：被动元数据通过单一化方式完成，且准确率无法保证，主动元数据有多种方式，并能够保证解析准确率；
• 智能挖掘：被动元数据不支持，主动元数据支持精准打标、智能扩散、自动口径提取、相似资产识别等；
• 服务方式：被动元数据偏被动等待，主动元数据实时在线服务，主动触发；
• 应用场景：被动元数据应用于数据理解、调度依赖配置等少数场景，主动元数据覆盖增强数据发现与理解、溯源盘点、影响分析、数据分类分级、质量监控等全部数据治理场景。

通过主动元数据平台，我们可以构建出一张全面、精细、准确、实时的血缘图谱，为用户提供更深刻的数据理解和智能化决策建议，而非只是简单的数据展示。通过这一能力，相当于为用户提供了一个 7x24h 在线的数据助手，能够实时管控数据动态情况，进而推动数据治理走向自动化和智能化，重构数据治理模式。

03 主动元数据关键技术突破——算子级血缘

要实现前面所提及的能力，主动元数据最关键的技术在于算子级血缘。那么，何为算子级血缘呢？

众所周知，数据血缘已经历两代的发展变革，第一代是表级血缘，第二代是字段级血缘。表级血缘和字段级血缘，主要依赖于脚本解析技术去构建表与表之间、字段与字段之间的血缘图谱。然而，现在绝大部分情况是，当前市场中的许多开源组件或商业化血缘产品，并不能实现数据血缘的自动化解析，也无法保证解析的准确性。

第三代算子级血缘解析技术，是我们全球首创的一个技术，能够帮助用户真正实现主动元数据。

具体来说，算子级血缘解析技术能够深入作业脚本核心，实现白盒化解析，精确捕捉如 A 字段和 B 字段之间的复杂运算逻辑，包括是否经过临时表加工处理、是否存在 Join 操作以及具体的过滤条件等细节。通过算子级血缘解析，结合对脚本内部代码的抽取、改写、合并，我们能够清晰勾勒出当前任务输出表中字段与输入表字段之间的完整加工关系，确保数据流转的透明化和可追溯性，让用户洞悉作业脚本的每一个细微环节。

实现算子级血缘解析，是基于我们自主研发的多平台 SQL 语言解析器。它具备强大的语言兼容能力，能够精准解析各类 SQL 语言，深入剖析复杂的计算逻辑，还可以准确、精细刻画出字段之间错综复杂的加工关系，并提供代码改写能力，实现字段加工口径的提取和转换，最终构建出一张完整的血缘图谱，清晰地展示出数据上下游的列级交互关系，以及行级的影响关系。

行级影响关系是指数据在流转过程中，通过特定汇总表中类型字段进行汇总合并和衍生加工，最终影响到汇总表或消费端的具体表现。以银行领域的十大主题域为例，其中常设有汇总表，这些表通过特定的 Type 字段作为区分不同数据源或业务场景的标识符。在此场景下，Type 字段上游可能连接着数十张乃止上百张输入表，它们的数据通过复杂的汇总逻辑汇聚在该汇总表下，形成数据集。若缺乏算子级血缘解析，这样的汇总表上下游血缘关系极易扩散成数十个乃止数百个分支，使得数据流向与影响分析变得极为困难。

而通过行级影响关系，结合字段间加工关系的精细刻画，我们不仅能够展现出数据在字段层面的流转与加工，更深入到了行级层面，揭示出特定行或记录如何在不同环节中被筛选、处理与汇总。基于此，用户可以高效地开展影响面分析与溯源工作，迅速厘清上下游数据的复杂关系，为数据治理、业务决策及问题排查提供有力支持。

总的来说，算子级血缘主要有“三大突破”。

一、具备对整个数据链路中的各类 SQL 语言的全面理解和分析能力，能够深入解析 SQL 操作语句中的核心组件，包括 Select、Where、Having、Order by、Group by 等各类操作符，能够进行抽取、合并，详细追踪并可视化数据的流转和转换路径。正因为我们解析粒度能细化到 SQL 操作符层面，所以能提供更加精确和深入的数据血缘信息。

二、在时效性上，我们能够做到在数小时内高效完成数十万张表及 DML 代码任务的深度解析和构建，快速生成全局数据血缘图谱。这张图谱不仅是数据关系的视觉化映射，更能够支持用户进行影响面分析、溯源追踪、口径盘点等工作。

三、支持不同场景的元数据查询方案，支持超 10 亿以上的点边关系的元数据图谱实时查询，并提供自定义行级裁剪功能，确保根据业务需求精准过滤数据，秒级返回经过精细剪裁、高度相关的查询结果，提升数据查询效率和准确性。

那该如何衡量算子级血缘技术的好与坏呢？我们认为主要是有以下三个指标。

一、解析成功率。准确性，是元数据平台或某个血缘产品的核心指标，重要性不言而喻，很大一部分业务人员不敢用，或业务部门服务的用户不敢用，原因就在于准确性不达标。只有当元数据解析准确性高于 99%，甚至达到 100%，用户才敢用。

二、分析召回率。主要要求元数据血缘图谱的完整性，没有数据缺失，没有血缘路径断联，在溯源盘点和影响分析时搜索返回结果无数据漏失，因此数据血缘影响分析的召回率要高于 99%，只有不漏才可用。

三、分析打扰率。在分析完成后，要主动进行监控告知。在告知用户环节里，如果能避免泛化性通知，保证通知准确的，打扰率更低，用户便会更加认真地对待每一次的分析报告，并完整地通知到更多的人。通常，打扰率要低于 5% 为好。

整体来说，就是我们通过算子级血缘解析技术，能做到数据治理“看得清、管得住、治得动”，最终实现真正的“敏捷数据协同”和“主动智能的数据治理”。

04 Aloudata BIG：全球首个算子级血缘主动元数据平台

Aloudata BIG 作为全球首个算子级血缘主动元数据平台，其核心能力便是是算子级血缘。在这个能力之上，叠加构建元数据知识图谱，通过这个图谱，企业可以进行打标扩散、基线定义等。同时，Aloudata BIG 作为企业数据治理运营助手，支持反向元数据输出，比如进行血缘页面集成，或者服务 API 调用，通过 Kafka 的方式进行消息实时推送等。Aloudata 还能够提供增强元数据智能服务，为企业 DataOps 数据研发平台、数据资产平台、数据质量管控平台建设提供支持。

在元数据采集进来之后，并不只是存储在 Aloudata BIG 平台之中，而是与实际业务场景深度融合，如数据治理、数据应用的各个场景。例如，在数据开发过程中，当开发人员准备提交新脚本或修改后的脚本时，可借助主动元数据平台的能力进行智能评估，判断这段脚本写得是否合理，是否存在穿过中间层直接访问源端数据的风险，同时检查企业内部是否已存在与新脚本输出表逻辑重复的现有模型。通过这一系列事前管控措施，可有效预防风险发生，确保数据处理的合规性与高效性。

关于相似性识别，我们的方法是深入细致地分析每张表内的每个字段，比如新脚本中的输出表加工字段，我们会密切关注脚本修改所直接影响的具体字段，以及这些字段后续如何参与加工。为此，我们不仅解析脚本本身，还会穿透脚本，追溯至源端，剖析生成这些字段的原始加工逻辑，确保能够全面理解字段间的相互关系和变化影响，从而准确地进行相似性识别。

除了对研发场景的支持外，Aloudata BIG 在用户找数、理解数据、用数的过程中也提供了强有力的支持。面对数据维护与理解的需求，虽然存在一些模型规范，但在实际业务操作中，开发人员往往难以全面遵循，而企业内部强制性的管控手段也往往力不从心。而通过过算子级血缘，我们能够进行业务理解的深度扩散，例如，当上游 A 字段的业务语义被标注为“电话”，在数据加工过程中，如果是一比一的直接映射或者简单的处理变换，该业务语义都能迅速且准确地传递至下游。这一过程不仅简化了数据模型的业务语义补全工作，还极大地提升了数据在跨部门、跨系统流转过程中的一致性与可理解性。

针对质量相关的场景，Aloudata BIG 同样提供了高效的支持方案。在报警预测与规则配置等任务中，传统方法常需将规则直接绑定至特定字段，这一过程高度依赖人工操作，并往往需要业务部门的深度介入。而借助 Aloudata BIG 平台，业务端可以在数据链的终端节点，如报表输出的字段上，直接配置所需的 DQC（数据质量规范）规则。随后，利用算子级加工推断能力，自动向上追溯至上游相关字段，并智能判断其 DQC 规则的配置方式。若上游字段的加工逻辑为简单的一比一映射，则 DQC 规则可直接复用，极大地简化了配置流程。

对于复杂加工逻辑的字段，Aloudata BIG 不仅能够深入解析加工逻辑，还支持代码级别的改写与调整，确保 DQC 规则准确无误地应用于数据处理的各个环节，降低人工配置负担，显著提升数据质量的监控与管理效率。

而针对 Aloudata BIG 的接入能力，能够无缝集成传统数据库（如 Hive、MySQL、Oracle），实现这些系统数据的自动化采集与深度解析。同时，对于计算平台（如 Presto、Spark）以及 AI 模型报表、看板等，也提供了标准化接入方式，确保在各类数据源端都能高效、准确地采集元数据。采集到的元数据将被集中至 Aloudata BIG，实现全面的数据纳管。在此基础上，通过算子级血缘解析技术，我们能够深入挖掘数据间的关联与依赖，优化数据处理流程，赋能业务智能化决策。

05 Aloudata BIG 主动元数据平台多场景应用

场景一：数据分类分级与打标扩散，精准圈定保障范围。

众所周知，企业要遵循国家层面的安全合规相关的法律及监管要求，因此需要对企业内部所有的数据进行治理，以及对数据的业务语义进行明确确认和标注。传统方法，依赖于对具体字段内数据的直接理解和繁琐的数据抽样过程来判断其是否属于防控范畴，不仅计算量大、能耗高，还常常导致业务部门需频繁向运维团队申请资源，甚至可能需要在非工作时间运行数据处理任务，极大地影响了工作效率和实时性。

通过算子级血缘解析技术，我们能够高效实现数据分类分级与标签的自动化扩散。首先，用户无需对全域数据进行全面分析，只需聚焦于链路中的关键节点，如源端或末端，进行具体的分类分级，并给这些节点打上标签，随后即可基于血缘图谱自动实现标签的智能扩散，从而清晰地揭示并确认企业数据的业务含义。假设我们在贴源层定义了一个“身份证”的字段，当识别到某个字段属于“身份证”字段，我们即可迅速且准确地为该 ID 字段打上相应的标签，并将这一标签自动向下级扩散。

那如何去扩散？关键在于精细化地配置扩散规则。针对那些直接复用数据的情况，比如当前加工语句中的 Service ID 直接映射到另一个名为 Chrome 的字段中，尽管命名上缺乏一致性，但若从加工逻辑语义上判断两者具有相同的含义，则我们同样会将该 Chrome 字段视为应打上相同分类分级标签。

为了实现更广泛而精准的数据分类与标签扩散，我们还内置了先进的数据分类算法。这些算法能够智能分析数据内容、结构及其上下文信息，结合用户自定义的标签扩散规则，确保标签能够准确无误地覆盖到整个数据系统。通过这种方式，我们不仅能够提升数据管理的效率与准确性，还能为企业构建起一套更加完善、高效的数据分类与管理体系。

另外，在重点指标保障上，如末端节点的 KPI 报表或监管报送指标，确保其产出时效与准确性的精准控制至关重要。然而，上游数据或模型的变更往往难以及时、透明地传达至下游，导致任务调度异常，甚至需要非工作时间介入处理。为应对这一难题，我们依托打标扩散，构建了一套高效的保障机制。首先，明确需要保障的末端节点，随后利用血缘图谱的追溯能力，精准框定出需要重点保障的数据链路范围，既帮助我们快速识别出潜在的依赖关系变更，还能在变更发生时立即触发预警，从而确保相关人员能够提前介入，避免任务调度异常的发生。通过这样的保障策略，我们不仅能够有效提升重点指标的产出时效与准确性，还能大幅降低因数据或模型变更带来的运营风险，为企业数据的稳健运行提供有力支持。

场景二：指标溯源以及口径的标准化，监管报送业务基本要求。

当前，金融监管部门及业务部门的零售部门等，都面临着相似的数据管理挑战与需求。从监管视角来看，金融机构需严格遵循监管要求，如梳理监管 1104 指标及监管报送的具体指标口径，确保数据能按日、月、季度等周期准确报送。这一过程中，频繁梳理字段口径并向监管提交清晰、一致的报告成为常态。

同时，企业内部还面临着多源报表指标整合统一的难题。由于这些指标可能源自同一上游系统，但在业务语义处理上存在差异与关联，因此在最终报送前，必须进行数据集合与校验，以确保各项指标间的数据关联性准确无误。例如，同一数据源在经历不同加工处理后，可能服务于不同的报送指标，若发现数据差异，则需迅速定位问题并进行修复，以保障报送的准确性。

另一方面，业务部门内部也形成了独特的数据管理文化——“小抄本”制度。这些“小抄本”记录了部门内部长期积累的数据表字段加工逻辑，是数据分析与加工的重要参考。它们不仅帮助老员工高效工作，还作为知识传承的载体，为新入职员工及后续使用者提供指导与支持。

传统表列血缘在这个场景中有着很大的局限性。首要问题在于，它很容易拉取上游泛化级别的大表，如包含百万级字段的表，极大地增加了口径梳理与盘点的难度，使得人工操作变得异常繁重，耗时可达数周乃至一个月之久。如此庞大的工作量，不仅拖慢了数据处理速度，还严重阻碍了文件的实时更新能力，难以满足监管报送及企业内部对数据时效性的高要求。

更为关键的是，企业内部的数据链路是动态变化的。上游的任何细微变更都可能对下游使用的表产生影响，导致数据问题或不一致性。若未能及时协同这些变更，直接依赖旧表进行数据处理，最终产出的数据很可能与业务实际需求脱节，甚至误导决策。此时，往往需要跨部门沟通，追溯上游变更原因，整个流程繁琐且效率低下。

再就是差异性的对比。因为企业内部很多数据都需要进行集合校验，在报送以及各个业务场景中，针对一些无法通过集合校验的指标，该如何判断差异性，如何修正加工逻辑的异常，整个流程非常损耗人力。

通过算子级血缘技术，我们能够构建出一张高精度血缘图谱，实现全链路溯源分析的一键化操作。用户仅需指定最终监管报送的目标指标，系统便能自动追溯并分析上游的口径信息。通过行级裁剪功能，系统还能精准提取与指定字段直接相关的口径代码信息，迅速生成口径报告，极大地提升了工作效率与准确性。

此外，我们还具备实时监控能力。依托实时采集技术，系统能在采集端即时捕获 DDL 和 DML 信息，并详细记录元数据的版本变化。通过持续监控数据链路中的变更情况和精细化影响分析判断，一旦检测到任何可能影响监控链路的数据变动，系统将立即触发通知机制，确保用户能够第一时间获取变更信息，从而保持整体口径文档的时效性与准确性，实现“保鲜”效果。

场景三：全链路数据保障，实现业务基线风险治理。

基线，就是我们对整个业务的理解，比如说末端输出的一个任务，它定义了一条基线，并定义了基线的预警时间和保障时间。在实践中，面对诸如上游模型变更未及时通知下游、模型产出数据异常，以及调度层面出现的节点破线、预警风险等挑战，全链路保障机制能够迅速响应，通过实时监控、快速响应与精准治理，有效降低了此类风险的发生概率，确保了业务基线的稳定性与业务开展的连续性。

当前，在杭州银行，通过 Aloudata BIG 实现了对监管报送链路的主动式保障策略，有效将风险防控前置。具体而言，在用户预先对需保障的数据链路进行明确标记与定义的基础上，我们主动感知并监控整个链路上的关键环节，随后基于这些链路信息，能够深入洞察其运行状况，包括元数据的任何变动，如 DDL 和 DML 变更、任务调度异常情况、开始与结束时间等。通过全方位、自动化的采集与感知机制，确保了监管报送链路的稳定运行，为用户提供了坚实的数据安全保障。

而在平台内部，我们会对采集到的数据进行深度整合与分析，以精准判断上游数据表的任何变动，如字段删除或字段类型变更，是否会对下游产生实质性影响。例如，当 A 字段的类型由数值型转变为文本型时，我们会判断下游脚本中是否存在依赖数值型处理的加工逻辑。通过精细化分析脚本内容，若确认该字段在脚本中仅被直接引用而未涉及数值型特定处理，则判定此变更对整体链路无直接影响。

所以，每一次变更事件，我们都可以自动监测，并精确评估其对下游可能带来的风险，最终生成完整的链路风险报告，及时、准确地通知下游业务方。而一旦监测到上游存在潜在风险，如调度延迟等异常情况，我们会立即向下游业务方通报当前的风险节点与异常详情，并阐述这些异常对下游的影响范围及具体链路，进而帮助业务方迅速定位问题根源，高效采取应对措施，以减轻或消除潜在影响。

06 QA

Q1：通过算子级血缘，在生产中具体产生了哪些收益？

最直观的一点就是通过算子级血缘，极大地简化了脚本内部字段口径的理解过程。对于开发人员而言，面对动辄几十、几百乃至几千行代码的复杂脚本，传统方式往往需要耗时费力地逐行阅读，不仅效率低下，还容易遗忘之前的阅读内容。而借助算子级血缘，能够精准压缩庞大的代码量，让开发者能够迅速聚焦于特定字段的生成逻辑，帮助快速理解。具体而言，通过算子级血缘，可以智能提取并可视化展示某字段在脚本内的完整加工链路，同时整合并展示相关口径信息，使开发者一目了然地理解字段的加工过程，直观且高效。此外，算子级血缘还能够支持多种实际业务场景，如相似度判断、影响面分析以及溯源口径盘点等，为企业的数据资产管理和业务决策提供了技术支持。

Q2：对于多层级的物理表产出，比如从 ODS 到 ADS 的加工逻辑，能否通过算子级血缘穿透出去？包括如何去做口径合并？

当然可以。假设 ODS 到 ADS 层共存在 15 层加工层级，那我们会全面整合这 15 层中的所有信息。这样即便您主要关注本部门内部的 5 层加工层级，我们也能够帮助您深入理解这张表在跨部门应用中的加工逻辑，追溯其源头是通过哪张表或哪些特定的加工逻辑所得。同时，我们支持用户自定义指定分析层级，让您能够灵活指定层级范围，并据此生成字段合并口径，快速理解该表的全貌。

在层级合并过程中，我们采用了精细化的字段抽取策略，包括直接口径抽取和间接口径抽取两种方式。直接口径抽取主要聚焦于 Select 语句中的直接字段引用，直接将这些字段及其相关信息合并入报告中。而对于间接口径抽取，我们则运用一系列策略性分析方法，深入剖析字段间的间接关联与转换逻辑，最终产出一份既全面又准确的口径盘点报告。

Q3：算子级血缘对 SQL 有标准要求吗？比如像 Hive 的语法会比较灵活。以及如何去验证覆盖度、准确度和标准？对于几十万的 SQL 的话，如何去判断它的结果是 99% 以上？

首先回答第一个。针对 SQL 的抽取，我们主要是基于公司自研的 SQL 语言解析引擎，它具有强大的分析和理解能力。只要输入的 SQL 语法是符合标准规范，像 MySQL、Oracle、Hive，它其实都有自己的官方文档去说明它的语法性是什么，我们都是严格遵循官方文档的标准规范进行编写与解析。也就是，只要 SQL 语句能在对应数据库环境中成功执行，我们的解析引擎就能实现自动化、准确无误的解析。

关于覆盖度和准确性，我理解主要是有几方面。第一块是说如果我们提供了几十万个脚本，我们会首先看一下脚本的解析情况，通过脚本的覆盖情况去粗粒度看一下是不是都解析了。第二块是看脚本里面是不是解析的 OK。我们内部也会有一些方案去做，比如说会去抽取脚本里面所使用的表和字段，然后通过解析引擎解析出来最终所产生的输入表、输出表、临时表的字段，进行字段级别和表级别的比对，去看解析的成功率如何。最后的话就是字段级别的口径理解，我们也会通过多种解析方式进行覆盖交错的对比分析，然后保证我们的解析情况的准确性。

综上所述，在数据治理领域，Aloudata BIG 能够主动采集各类元数据信息，自动构建全链路、精细、准确且实时的完整血缘图谱，并基于这一图谱，为各类数据治理场景提供相应的能力支持，帮助用户优化数据治理流程，强化元数据管理能力，真正实现数据治理的自动化和智能化。如对 Aloudata BIG 感兴趣，欢迎访问 Aloudata 官网，了解更多。

原创作者: u_15879876 转载于: https://blog.51cto.com/u_15879876/11853217