|
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 1.5px;color: rgb(0, 0, 0);font-size: 14px;text-align: justify;visibility: visible;line-height: 2em;">导读在人工智能与大模型技术爆发式发展的背景下，数据治理正经历从静态管控向智能协同的范式跃迁。传统数据治理模式面临数据孤岛、数据质量参差不齐、安全合规隐患不断等核心痛点。面向 Data+AI 的深度融合正驱动数据治理体系向智能化、自动化、实时化演进。大模型通过自然语言理解、动态血缘分析等技术，实现元数据自动补全与质量实时监控，显著提升治理效率。同时数据治理智能体的崛起，重构了人机协同的模式，通过自然语言交互降低分析门槛，推动治理从幕后管控走向前台赋能。但这一转型仍需突破三大核心的挑战，分别是：质量陷阱、安全合规的压力、价值转换等瓶颈。本次将由行业一线的数据治理专家，带来数据治理在 Data+AI Agent 元数据数据血缘方法论最佳实践的最新实践成果，助力企业数字化转型的进一步能力提升。ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 1.5px;line-height: 2em;visibility: visible;">1.多云与 AI 时代的数据治理挑战 2.Apache Gravitino 统一元数据架构和场景 3.统一数据血缘的价值 ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 1.5px;line-height: 2em;">4.如何实现统一血缘ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 1.5px;line-height: 2em;">5. 未来展望ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 17px;font-style: normal;font-variant-ligatures: normal;font-variant-caps: normal;font-weight: 400;letter-spacing: normal;orphans: 2;text-indent: 0px;text-transform: none;widows: 2;word-spacing: 0px;-webkit-text-stroke-width: 0px;white-space: normal;text-decoration-thickness: initial;text-decoration-style: initial;text-decoration-color: initial;text-align: left;line-height: 1.75em;">分享嘉宾｜史少锋DatastratoVP of engineering
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 17px;font-style: normal;font-variant-ligatures: normal;font-variant-caps: normal;font-weight: 400;letter-spacing: normal;orphans: 2;text-indent: 0px;text-transform: none;widows: 2;word-spacing: 0px;-webkit-text-stroke-width: 0px;white-space: normal;text-decoration-thickness: initial;text-decoration-style: initial;text-decoration-color: initial;text-align: left;line-height: 1.75em;">编辑整理｜孙蒙新ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 17px;font-style: normal;font-variant-ligatures: normal;font-variant-caps: normal;font-weight: 400;letter-spacing: normal;orphans: 2;text-indent: 0px;text-transform: none;widows: 2;word-spacing: 0px;-webkit-text-stroke-width: 0px;white-space: normal;text-decoration-thickness: initial;text-decoration-style: initial;text-decoration-color: initial;text-align: left;line-height: 1.75em;">内容校对｜郭慧敏ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 17px;font-style: normal;font-variant-ligatures: normal;font-variant-caps: normal;font-weight: 400;letter-spacing: normal;orphans: 2;text-indent: 0px;text-transform: none;widows: 2;word-spacing: 0px;-webkit-text-stroke-width: 0px;white-space: normal;text-decoration-thickness: initial;text-decoration-style: initial;text-decoration-color: initial;text-align: left;line-height: 1.75em;">出品社区｜DataFun
✅ 对分享有疑问？群里问！ ✅ 老师在线解除疑惑！ ✅有心得体会想分享？群里聊！
01
多云与AI时代的数据治理挑战
企业面临的核心痛点主要体现在三个维度：
1.数据孤岛问题
首先，基于企业采取的多云架构策略（私有云+多公有云）数据以多种形态散落在云上，天然导致了数据割裂问题的存在。此外，由于各个国家对数据的安全保护以及私有数据跨境传输的合规要求，进一步加剧了数据孤岛问题。
多云导致数据孤岛
2.数据源类型多样化
从企业内部来讲，数据源同时存在传统数据库、数据仓库、离线/实时数据湖、AI非结构化数据（文本/图片/音视频）等多种形态，对统一发现、管理和治理提出严峻挑战：
多样化数据源
3.被忽略的元数据信息
如果把我们使用的数据看作是海上漂浮的冰山，那么在海平面之下隐藏的元数据往往被忽视，它们包括有：数据连接信息、数据属主信息、数据发现、数据权限信息、数据分类分级以及数据的生命周期等，这些元数据对数据的使用起着重要作用。
元数据管理框架
✅ 对分享有疑问？群里问！ ✅ 老师在线解除疑惑！ ✅有心得体会想分享？群里聊！
02
Apache Gravitino 统一元数据架构和背景
针对以上问题，我们来介绍一下Apache Gravitino这个项目。Apache Gravitino定位为统一的支持多源异构元数据湖（Metadata Lake）。底层支持包括Hive、Iceberg、Hudi、Paimon这样的数据湖、主流数据仓库(Doris、StarRocks、OceanBase)和Kafka这种分布式消息队列。也支持非结构化数据和AI模型通过Fileset Catalog和Model Catalog进行管理。在统一元数据之上提供RESTful API、SDK和多种connector，通过各种引擎和AI生态（pytorch、ray、tensorflow等）接入进来访问元数据，从而帮助企业统一元数据的管理，帮助企业掌握整个数据和AI的全貌，做更多数据治理的事情。
Gravitino定位
从Gravitino内部来讲，将多种数据源挂载进来形成联邦的数据目录，这些目录组成了Metalake。在上层Gravitino提供了RESTful API，在此之上进一步提供了SDK与connector，帮助用户进行统一访问和统一治理。此外Gravitino也率先为现今流行使用的Iceberg湖格式提供了一套标准Iceberg RESTful API的实现，支持Iceberg生态用户的无缝迁移。
Gravitino架构图
在形成统一元数据之后，用户可以进一步通过他们的引擎来访问表格数据与非表格数据。对于表格类型数据，用户可以使用SQL来操作、修改、删除元数据，还包括对数据的增删改查。对于非表格数据，主要是针对文件的操作，Gravitino支持主流的存储系统如：S3、HDFS、OSS、ADLS、GCS。用户可以将物理存储目录映射成逻辑目录，这个逻辑目录被称为Fileset Catalog。用户在访问时，可以通过Gravitino的虚拟文件系统（GVFS），以逻辑目录的方式访问数据，从而为用户屏蔽了底层不同物理存储的差异。在Python的生态中，提供基于fsspec的标准python文件系统，用户也可以很方便的访问这些数据。
因此Gravitino统一了结构化与非结构化的数据访问，对数据资产提供了标准化管理，为每个数据资产提供全局唯一的数据坐标：<catalog.schema.asset>，用户不用关注物理连接信息，降低了出错概率、提升了沟通和使用的效率。
数据访问示例
进一步的，Gravitino在基于统一目录和统一元数据的基础上实现了统一数据的授权和鉴权，可以在一个层面上实现数据的管控，满足数据治理方面合规性的要求。
✅ 对分享有疑问？群里问！ ✅ 老师在线解除疑惑！ ✅有心得体会想分享？群里聊！
03
统一数据血缘的价值
Gravitino统一元数据之后，自然会有统一数据血缘的要求。数据血缘本身就是描述数据从产品、加工、流转到最终应用的全生命周期链路关系。统一数据血缘对于企业有至少三个方面的价值，分别为：
统一数据血缘能完整追溯数据从产生、加工、流转到最终应用的全链路，清晰展示每个数据节点的来源、处理规则及影响范围。当数据出现异常时， 企业可快速定位问题根源（如某份报表数据错误，能追溯到原始数据源的采集问题或中间ETL处理的逻辑漏洞），从而高效改进数据生产过程，提升数据质量和业务部门对数据的信任度。
在数据隐私保护（如GDPR、 个人信息保护法）等合规要求日益严格的背景下，统一数据血缘可明确记录敏感数据的流转路径—包括哪些系统使用了敏感数据、数据经过了哪些加工环节、最终被哪些业务场景所引用等。这使得企业能精准识别敏感数据的分布和使用情况，确保数据处理符合法规要求；同时，当发生数据安全事件或合规审计时，可快速提供完整的追溯证据，降低合规风险和处罚概率。
统一数据血缘让企业内各业务部门能清晰理解数据的含义、来源和关联关系，减少因 “数据孤岛”导致的理解偏差和重复劳动。 此外，数据开发团队也能基于血缘关系，更高效地进行数据模型优化、系统升级等工作，提升数据资产的复用率和业务响应速度。
✅ 对分享有疑问？群里问！ ✅ 老师在线解除疑惑！ ✅有心得体会想分享？群里聊！
04
如何实现数据血缘
OpenLineage这个开源项目的目标是打造数据血缘行业标准，让大家都基于一个标准实现数据血缘的采集和存储，从而减少多平台之间的重复工作。
OpenLineage 架构
OpenLineage作为标准化方案，核心是引入了统一的数据Schema来描述数据血缘。它的核心概念分别包括：
同时OpenLineage通过Facet机制支持元数据扩展，扩展的信息能够解析出来，就相当于完成了血缘整个链路过程。
事件机制本身是用来传递血缘信息，因此包含了触发的Job、对应的Run、读/写的Dataset以及Facet信息。以OpenLineage事件上报记录为例，可以更容易理解以上核心概念的实际内容。整个事件上报包含了两个Event，即：start event和complete event。可以看到event下有个run包含了runid，有个job包含了相应的namespace和job的name，input和output都是dataset。当收到start事件时，OpenLineage并不会立刻构建血缘关系，而是在收到complete事件后，才会完成数据血缘的成功构建。
血缘事件消息被采集和记录后，如何把消息发送到后端，这个OpenLineage是开放的。目前主要支持Kafka和Http协议。
至此Gravitino与OpenLineage形成互补架构，同时OpenLineage在存储方面并没有绑定，给予后端灵活的实现方案。MARQUEZ作为参考，完整实现OpenLineage的协议和方案，因此可以将三者结合实现统一数据血缘。
在相应的系统设计中，Gravitino提供Lineage API接收OpenLineage Event，内部提供processor扩展机制，可对血缘信息进行自定义处理；之后通过sink接口转到下游存储，如Marquez。
通过如此的系统架构与系统设计，我们可以清晰看到一个统一血缘的实现。如图所示，可以直观看到左侧OpenLineage采集的血缘信息，经过Gravitino进行了统一标准化。
针对多引擎多数据源血缘采集的支持目标，目前Gravitino已经支持了Spark引擎的血缘采集自动化。Spark引擎（使用Gravitino connector）支持Hive, Iceberg, MySQL, Fileset, Model等元数据的自动识别，映射到OpenLineage Dataset。未使用Gravitino connector的场景，可自己实现processor，实现对Dataset facet内容的识别和匹配，转成统一元数据的命名。针对Flink、Trino等引擎的支持正在下一步规划中。
以下示例：从fileset到icberg再到mysql的可以从血缘效果图，以及字段级血缘的情况
血缘效果图 （从fileset到iceberg再到mysql等）
字段级血缘
总结下来，Gravitino统一数据血缘方案的核心价值有：
标准化采集：通过OpenLineage插件采集多引擎血缘信息
统一命名空间：将物理数据源映射为逻辑名称，解决血缘图中物理连接信息混乱问题
灵活处理管道：提供Processor机制自定义血缘转换规则
| 
