用途
当元数据与血缘需要通过 OpenMetadata、DataHub 或 OpenLineage 等开放工具落地运营时，可使用本技能。它帮助智能体让数据生产方与目录预期保持一致，确保血缘准确，并使数据发现真正可信，而非流于形式。
适用场景包括：将元数据平台集成到交付工作流；改善数据集发现与信任信号；跨管道捕获并验证血缘；将受治理数据集发布到开放目录生态；把来自 Spark、Airflow 或 dbt 的 OpenLineage 事件连接到目录；为多团队环境定义元数据治理策略。
当团队没有共享目录需求，或血缘完全在封闭平台（如 Unity Catalog、Purview）内处理且无开放集成需求时，不应使用本技能。
主要能力与工作流
1. 定义元数据所有权与最小必填字段
需要明确：每个数据集元数据由谁负责（生产团队、平台团队或数据管家）；最小必填字段包括所有者、描述、分类、新鲜度、粒度；哪些字段由血缘自动填充、哪些需人工维护；元数据质量如何衡量与执行；数据集要被视为“可发现”需要满足什么“完整”标准。
2. 将血缘采集连接到实际执行面
包括：OpenLineage 与编排器（Airflow、Dagster）集成；OpenLineage 与处理引擎（Spark、dbt、Flink）集成；验证血缘事件在作业启动、完成和失败时是否正确触发；测试列级血缘能否穿过转换层传播；监控缺口，即作业运行但未产生血缘事件的情况。
3. 通过质量信号让发现可信
需要呈现信任指标：最后验证时间、新鲜度、质量评分、所有者响应度；区分生产受治理数据集与实验性或已弃用数据集；为数据集打上分类级别标签（公开、内部、受限、敏感）；确保搜索相关性，通过描述、标签和使用信号提升可发现性；淘汰陈旧资产，目录中的死数据集会侵蚀信任。
4. 将元数据发布集成到管道生命周期
元数据应在管道部署时更新，而非在单独的手动工作流中维护；使用 CI/CD 钩子在发布前验证元数据完整性；通过血缘事件自动将模式变更发布到目录；当元数据新鲜度落后于实际数据新鲜度时触发告警；把元数据作为发布门禁要求：没有目录条目，就没有生产访问权限。
5. 规划多团队治理与联邦所有权
定义角色：数据生产方、数据管家、平台管理员、消费者；建立谁可以修改共享数据集元数据的策略；为常见数据集类型创建模板，让团队从良好默认值开始；定义发现元数据质量问题时的升级路径；定期审计元数据覆盖率并按团队报告缺口。
6. 处理血缘准确性与漂移
管道变更而未更新集成时，血缘可能变得陈旧；安排血缘验证，比较目录血缘与实际管道结构；当预期血缘事件停止触发时告警；为复杂场景规划血缘，如动态表、视图、物化 CTE；记录血缘局限，即系统能捕获什么、不能捕获什么。
常见合理化借口与事实
“等管道稳定后再加元数据”——后期添加的元数据往往因上下文丢失而出错，开发期间捕获更便宜也更准确。
“血缘是自动的，只需安装集成”——集成只从受支持的执行路径捕获血缘，自定义代码、动态 SQL 和未插桩工具会造成缺口，需要显式关注。
“目录只用于发现，不需要准确”——不准确的目录比没有目录更糟，团队会失去信任并停止使用，使投入变得毫无价值。
“元数据治理对小团队是负担”——小团队最受益于元数据纪律，因为当有人离开时，可依赖的机构知识更少。
危险信号
目录中存在无所有者、无描述或新鲜度指标陈旧的数据集；主要管道或转换层的血缘图存在缺口；元数据在平台之外的电子表格中手动维护；没有流程从目录中淘汰已弃用或陈旧数据集；安装了血缘集成但无人验证其输出；团队发布数据时没有任何目录条目或元数据要求；声称有列级血缘但从未测试其准确性；元数据质量从未被衡量或报告。
验证清单
元数据所有权已定义，最小必填字段已强制执行；血缘事件从编排器和处理引擎正确触发；关键转换路径的列级血缘已验证；发现信任信号（新鲜度、质量、分类）已呈现；元数据发布已集成到管道 CI/CD 生命周期；陈旧和已弃用资产定期从目录中淘汰；血缘准确性已审计，缺口按管道跟踪。