导读 在 2025 年面向 Data+AI 的数据治理峰会的元数据与数据血缘论坛中，杭州奥零数据科技创始人兼 CTO 巫林壕老师，以“AllData 数据中台集成开源项目 OpenMetadata 破局工业数据孤岛”为题，深入探讨了在企业级数字化解决方案中，奥零数据团队自主研发的 AllData 数据中台商业版是如何成功赋能金融、制造等领域的数字化转型的设计实践。
1. 工业制造业务血缘沿袭
2. 常见问题与解决方案
3. 解决方案
4. 用户Q&A
分享嘉宾｜巫林壕 杭州奥零数据科技有限公司 创始人兼CTO、AllData数据中台开源作者
编辑整理｜王震南
内容校对｜郭慧敏
出品社区｜DataFun
01
工业制造业务血缘沿袭
数据治理过程包含数据质量及元数据管理，尤其在工业制造项目中具有具体应用。
在工业场景下，涉及工厂、设备及传感器产生的生产制造数据，以及各类业务库的存储与管理。当前讨论聚焦于生产制造领域特有的系统（如 MES、PLM 等系统）所使用数据的存储方式，及其从传统单体应用架构向微服务架构的转型过程。这些系统在数据管理方面需应对多源异构数据存储需求，并伴随技术架构从集中式单体向分布式微服务的演进。
1. 技术迭代场景
该场景描述了企业在数据管理平台迭代过程中面临的问题与需求。企业通过总数据管理平台汇聚多源数据，实现统一的分发与共享能力，并已完成阶段性目标。然而，由于元数据在跨部门、跨系统中存在分散和未统一归集的问题，导致开发人员在数据加工时面临以下挑战：
数据血缘缺失：开发人员无法快速定位表的上下游依赖关系，难以通过业务逻辑公式高效完成数据加工；
分层加工受限：例如在数仓 ODS 层到 DWD 层的分层处理中，因缺乏清晰的血缘图，开发人员无法安全地进行数据加工操作。
这些问题直接影响了开发效率与风险控制，而数据血缘图的缺失正是导致效率低下和不敢随意修改逻辑的核心原因。通过构建清晰的血缘关系图，可为开发提供技术支撑，实现降本增效的目标。
2. 技术依赖标准
测试团队通过数据血缘关系图展示不同业务部门、库表字段间的依赖关系，例如 A 表与 B 表间的关联路径。当开发加工公式（如 A+B+2C 计算出结果 101）时，若后续数据映射（如将 A 复制给 B/C）未遵循预期的数学逻辑，则可通过血缘关系验证其合理性。这种依赖关系需在数据开发过程中，通过明确表与字段间的关联性，确保数据加工公式及数据流动的准确性，从而实现数据资产开发与挖掘的规范性管理。
02
业务问题与解决思路
1. 数据资产不透明
本次讨论聚焦于资产透明性不足的问题，并围绕当前集成的开源项目"OpenMetadata"展开分析。此前我们曾采用 Apache Atlas 项目，并对多个同类开源方案进行调研，包括 DataHub、Gravitino 等项目。这些项目在技术实现上各有特点，其背后依托的开发者社区及适用场景存在显著差异，这种多元化特性为技术选型提供了多维度的参考价值，值得进一步探讨不同方案在社区维护能力和实际应用场景中的适配性。
（1）架构支撑
工业领域的数据分析应用主要聚焦于 KPI 管理、应用分析理念及数据资产洞察，其底层架构设计通常采用元数据存储层以支持这些功能。例如，Atlan 和 OpenMetadata 等系统便体现了这一架构特点：
Atlan 的元数据管理包含两部分核心存储技术：
基于 Elasticsearch（ES）的搜索与发现功能，用于高效查询和分析元数据；
基于 JanusGraph 的图数据库组件，用于处理复杂关系（如数据血缘、实体依赖）的建模与管理。
OpenMetadata 则通过整合 Elasticsearch 及其他存储资源，构建其元数据管理层，以实现数据资产的分析与管理。
这些架构设计通过元数据存储与多样化数据技术的结合，为工业领域的数据应用提供了底层支撑，确保数据分析与 KPI 管理的高效执行。
（2）降低成本
当前业务系统基于 MySQL 运行，通过元数据治理手段优化数据资产使用效率以实现降本目标。具体而言，工厂 MES 系统产生的报表每月需承担约 30 万美元的资源成本，但经治理发现：部分数据资产存在使用不足问题。例如，某些表虽持续占用存储计算资源并触发上下游业务逻辑运行，但实际未被访问或调用（如未提交申请审核）。通过识别此类未被有效利用的表（约占 30%），可动态减少资源申请，使原本需持续消耗的集群资源得到释放。最终实现资源成本降低 30%（从 30 万美元降至 20 万美元），节省约 10 万美元的冗余支出。该优化核心在于通过元数据治理精准定位低效数据资产，避免无谓的资源浪费。
2. 数据资产洞察
（1）工作流血缘任务
在数字化工厂的数字化程度较高的场景下，元数据洞察的应用尤为贴切。其核心依托于现代数据仓库架构的建设，该架构必然涉及对数据资源的深度分析与挖掘。
技术实现层面，系统通常以不同数据库表作为实体类的基础单元，包括实体、熟悉、基本约束等，并通过图构建多层级的数据血缘关系网络。知识图谱在此过程中承担关键作用，通过节点（实体）、边（关系）及属性数组的组合，形成结构化的数据表达，并最终将这些层级化的数据结构存储至图数据库中。
（2）自定义血缘任务
具体技术路径包括：将实体关系网络中的节点、边及属性数组分门别类存储，例如采用 OpenMetadata 等工具结合 Elasticsearch 进行数据管理。此类存储方案不仅支持图数据库的高效查询，还允许通过手动编辑设计源对数据进行灵活调整。整体流程体现了从实体建模到知识图谱构建，再到存储与应用的完整技术闭环，为制造业的数字化转型提供底层数据支撑。
（3）数据血缘导出
该功能主要支持通过导出 CSV 格式的数据血缘，帮助业务部门快速了解数据关联关系。导出后的 CSV 文件可进一步注册到数据服务平台，通过该平台实现多层级共享流通。同时系统还整合了元数据资产管理能力，提供元数据检索和提取功能，形成从血缘导出、数据共享到元数据管理的完整链路。
3. 数据拾取服务
（1）拾取 Mysql 数据库
拾取服务主要通过两种方式实现：推与拉。推方式指由业务库或数据源端主动将元数据推送至治理平台（如 OpenMetadata）。
拉方式则是通过持续订阅数据源，定期将元数据从源端拉取至治理平台。两种方式分别通过主动推送和被动拉取的机制完成元数据采集。
（2）数据库自定义血缘
该平台实现了对 MySQL 最新元数据库的元数据提取功能，支持通过不同层级的数据提取策略获取底层元数据。具体实现方式为：通过在系统中配置具体的元数据提取规则，依赖 Airflow 调度工具将相关任务（包括 PySpark 等数据源任务）部署至 Airflow 集群执行。当前，Airflow 已被集成至平台架构中，整个系统已具备运行能力并投入实际使用。
（3）新增元数据提取
在工业制造场景中使用 OpenMetadata 等元数据治理工具时，其应用效果表现稳定，未出现显著生产问题。该类工具通过页面化操作显著降低了技术门槛，例如通过解析 DDL 语句可快速构建表间血缘关系：当大表与维度表（如 A 表关联 B 表）进行数据关联时，系统能直接解析出两者间的依赖关系。而未采用第三代元数据治理架构（如基于图数据库的动态血缘追踪）时，需依赖手动解析多源 SQL 语句：若需追踪 B 表 ID 字段在 C 表中的聚合结果（如 GROUP BY ID 的总和），需手动解析 B 表与 C 表的 SQL 任务，提取其中的关联逻辑。相较之下，OpenMetadata 等框架通过自动化解析方式，有效简化了跨表血缘关系的识别与维护流程。
调度周期是指定期执行血缘关系的提取工作。当上游数据源或业务数据库中的表结构、字段之间的依赖关系发生变更时，系统能够通过周期性调度机制自动更新血缘信息，确保业务系统在无需主动感知或干预的情况下，可实时获取到最新的血缘关系数据。
03
解决方案
1. 元数据资产
（1）数据平台差异
该数据资产以库表字段级别为切入点，其核心优势在于能够跨业务系统挖掘数据资产价值。相较于其他同类项目（如 Atlas），其显著区别在于创新性地融入了 KPI（关键绩效指标）概念，而现有方案在数据资产管理中尚未实现这一关键特性。该体系通过聚焦业务数据的深度挖掘，构建了区别于传统数据资产管理工具的技术差异化特征。
（2）组织价值闭环
在第二个固有的发展模式下，组织通过关键健康指标评估团队价值，例如以数据库中的报表数量、主题库规模及元数据任务完成情况为核心目标，并将这些指标下沉到各业务团队。
不同层级的团队承担差异化的 KPI：业务部门关注数据溯源，例如要求明确 100 万条数据的具体来源表及其血缘关系；开发团队则需快速响应此类需求，通过元数据分析快速定位数据构造路径（如展示某表数据如何通过 ID 关联、过滤等操作从 200 万条数据中生成），并以可视化图谱呈现结果。这种协作方式增强了业务部门对数据团队的信任，同时也减少了责任推诿现象，使数据开发、架构设计与组织管理形成闭环。
（3）数据管理效能
数据团队在应对业务需求时，常面临效率瓶颈。
当缺乏高效工具时，即使简单如数据提取或元数据获取的需求，也会使团队陷入被动：从基层到高级研发人员均需耗费 2-7 天处理，导致业务方等待时间过长。若深入理解数据治理与数据体系，可将响应时间缩短至小时甚至分钟级，快速满足业务需求。例如，客户提出取数请求时，往往无法明确具体数据范围，而数据团队需追溯数据源头，如证券持仓需跨地域（港股、美股）或系统（公安行业多系统跳转）整合数据，过程复杂耗时。
通过建立数据标准与分类分级机制，将字段、表、库按统一规范映射，团队可快速定位数据归属与关联，实现高效查询与响应，从而解决跨系统、跨地域的数据整合难题，提升整体数据管理效能。
（4）数据治理平台
OpenMetadata 是一个开源的元数据治理平台，其核心能力如下：
①数据集成与调度能力
支持 Flink 作为数据源，通过 Airflow 调度执行 fra 作业（如数据集成任务），将元数据输出至目标端（metadata 存储层）
提供跨平台调度支持：原生兼容 Airflow 调度框架，同时兼容 Ark 等调度系统，并支持第三方血缘工具（如 Tion、Atlassian 社区插件）
②多源异构系统对接
数据库层：通过 JDBC 协议对接数十种关系型数据库
消息队列层：支持 Kafka、Kinesis 等流式数据处理
API 层：提供标准化接口实现系统间互联
③数据血缘追踪应用
实现全链路数据沿袭管理：从机器学习平台的模型训练，到传统数据管道的处理过程，均可提取完整的数据血缘关系
支持原生血缘提取与第三方工具集成双重模式
④典型应用场景
通过 Flink-Airflow-metadata 的典型数据管道配置，演示元数据治理的落地实践
在机器学习领域，可对模型训练数据、特征工程等环节进行血缘追踪
构建跨系统的统一元数据目录，实现数据资产的可视化管理
该平台通过模块化设计，将数据集成、血缘分析、元数据存储等功能解耦，形成可扩展的治理框架，适用于企业级数据资产管理的多种复杂场景。
2. 产品视频演示
04
用户Q&A
Q1：数据血缘是怎么处理的？
A1：数据血缘的实现主要基于元数据提取，其流程分为数据库端和代理服务端两个核心环节。在元数据处理层面，数据库端与代理服务端通过特定机制协作，底层源码中涉及数据库的服务监听以及代理服务的调度功能。
数据存储时，系统支持集成十余种预置数据库（其中一种未提供演示），通过代理服务端调度完成元数据提取。
数据处理流程中，系统将数据拆解为节点、边、关系（relations）及图实体（graph entity）等结构化元素，最终将这些数据结构存储至数据库或索引引擎中。
处理完成后，系统向前端返回包含血缘关系的数组数据，前端依据这些数据渲染出可视化血缘图。整个过程的核心逻辑围绕元数据提取、结构化解析、存储调度及前端可视化展示展开，形成完整的数据血缘追踪链路。
Q2：开源项目的构建
A2：关于开源项目社区共建：
1. 资源获取策略
首选依赖国内外英文站点获取开源资料
结合国内实用资源（如公众号内容）进行二次整理
2. 核心建设方向
需聚焦实际使用者群体：
收集用户使用反馈与经验分享
重点关注已部署应用的项目，通过用户实践验证项目可靠性
关注用户在使用过程中发现的缺陷（如部署问题、链路设计等）
通过用户提交的 PR（补丁请求）发现潜在问题
3. 项目筛选标准
选择元数据治理框架类开源项目时，应优先考察：
项目实际应用情况
用户使用效果与成果
是否具备基于真实场景形成的方法论体系
4. 文档建设原则
社区文档应基于一线使用者的真实经验构建
后续可逐步共建完善官方手册或中文版本说明文档
分享嘉宾
INTRODUCTION
巫林壕
杭州奥零数据科技有限公司
创始人兼CTO、AllData数据中台开源作者
大家好，我是巫林壕，AllData 数据中台开源项目的作者。作为杭州奥零数据科技创始人兼 CTO，我带领团队深耕企业级数字化解决方案领域，自主研发的 AllData 数据中台商业版已成功赋能金融、制造等领域的数字化转型，累计处理数据量级达到数十亿。
往期推荐
点个在看你最好看
SPRING HAS ARRIVED
