OpenMetadata 连接器审计实战元数据覆盖度与摄取完整度Prompt 1 全解【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata本篇指南以 OpenMetadata 仓库内skills/connector-audit/prompts/01-metadata-ingestion.md为骨架系统讲解如何对任意连接器connector执行第一项深度可靠性审计元数据覆盖度Metadata Coverage与摄取完整度Ingestion Completeness。你将掌握审计的五大源码检查位置、Tier 1–3 元数据分层评估方法、分页/静默丢失/生成器等摄取完整度核查要点以及一套可校准的评级规则与结构化报告输出流程。文中所有检查点均可在 connector-audit skill 与 ingestion 源码目录 中找到一一对应的实现证据。一、审计定位P1 在整个 connector-audit 流程中的角色OpenMetadata 的 connector-audit 是一套由 7 个提示词Prompt组成的连接器可靠性审计流水线Setup → P1–P5并行调查→ P6综合→ P7实施。P1 即01-metadata-ingestion.md聚焦「元数据覆盖度」与「摄取完整度」两个维度对应标准为Metadata Tiers 1–3与Standard 1Ingestion Completeness见 SKILL.md 中的 Prompt 对照表。执行前需要先完成两项准备SetupPrompt 0确认待审计连接器名称与服务类型定位其源码目录并写出上下文文件.claude/connector-audit.json其内容结构如下见 00-setup.md{ connector_name: name, service_type: type, source_path: ingestion/src/metadata/ingestion/source/type/name/ }加载连接器标准通过/connector-standards加载共享标准位于 skills/connector-review/standards/与按服务类型区分的标准source_types/。审计期间各提示词的输出统一遵循 templates/audit-report.md 报告模板P1 的报告固定保存为.claude/audit-results/01-metadata-ingestion.mdPrompt 6 会读取该文件做综合。建议先用静态分析器skills/connector-review/scripts/analyze_connector.py跑一遍机械检查作为基线再进入 P1 的深度调查。二、五大「必查」源码位置原文档强调一个连接器的元数据抽取代码分散在多个位置审计时必须全部检查任何遗漏都会导致误判。1. 连接器专属代码连接器自身的元数据/模型/查询实现ingestion/src/metadata/ingestion/source/[SERVICE_TYPE]/[CONNECTOR_NAME]/下的metadata.py、models.py、queries.py同目录service_spec.py— 注册各类管线pipeline类型对应的类以 MySQL 连接器为例真实目录结构为 ingestion/src/metadata/ingestion/source/database/mysql/包含metadata.py、models.py、queries.py、service_spec.py、lineage.py、usage.py等文件其中 queries.py 中可见带LIMIT {result_limit};的查询模板——这正是后续「分页核查」要盯住的典型模式。2. 连接ConnectionSchemaopenmetadata-spec/src/main/resources/json/schema/entity/services/connections/[SERVICE_TYPE]/[connector]Connection.json顺着其中的$ref链接继续追踪可以完整了解该连接器支持哪些配置项与元数据类型。3. 服务类型基类关键大量元数据能力在此每个服务类型都有一个共享基类提供核心抽取模式审计时务必核对与你连接器匹配的那个服务类型基类文件核心抽取方法数据库common_db_source.pyCommonDbSourceService表/视图抽取、列元数据、描述、属主、标签、yield 模式Dashboarddashboard_service.pyDashboardServiceSourceyield_dashboard、yield_dashboard_chart、数据模型列Pipelinepipeline_service.pyPipelineServiceSourceyield_pipeline、yield_pipeline_status、任务抽取Storagestorage_service.pyStorageServiceSourceyield_create_container_requestsMessagingmessaging_service.pyMessagingServiceSourceyield_topic、yield_topic_sample_dataSearchsearch_service.pySearchServiceSourceyield_search_indexML Modelmlmodel_service.pyMlModelServiceSourceyield_mlmodelAPIapi_service.pyApiServiceSourceyield_api_collection、yield_api_endpoint以数据库为例common_db_source.py 中存在yield_table方法、第 813 行存在yield_table_constraints——连接器若未覆写这些基类方法则相关元数据能力由基类提供评级时要明确归因到「继承自基类」。4. Profiler / SamplerTier 3 元数据所在地不在 metadata ingestion 中ingestion/src/metadata/sampler/sqlalchemy/[CONNECTOR_NAME]/— 连接器专属采样器。仓库中实际存在 sampler/sqlalchemy/ 目录内含sampler.py及 azuresql、bigquery、databricks、mssql、postgres、snowflake、timescale、trino、unitycatalog 等子目录ingestion/src/metadata/profiler/— profiler 框架5. 共享工具ingestion/src/metadata/utils/filters.py— schema/table/topic 过滤ingestion/src/metadata/ingestion/models/topology.py— TopologyRunnerMixin 实体迭代三、Part 1按 Tier 评估元数据覆盖度对每一种元数据类型都需要依次回答五个问题并记录到报告中是否被抽取是/否在哪里被抽取文件:行号来源是(a) 连接器专属代码 / (b) 继承自基类 / (c) 独立管线 / (d) 不支持完整度抽取是否捕获了源系统的全部可用元数据局限或缺口Tier 1 — 核心不可妥协实体层级databases → schemas → tables、dashboards → charts、pipelines → tasks 等实体类型表、视图、物化视图、外部表等——连接器是否区分了源系统支持的所有类型列/字段元数据名称、数据类型、约束、默认值数据模型列仅 dashboard 连接器是否抽取数据模型的列元数据描述实体级 列级必须来自源系统而非用户手动添加运行状态仅 pipeline 连接器任务成功/失败/耗时表级血缘数据库基于查询日志dashboard/pipeline 连接器跨服务列级血缘连接器专属代码与共享血缘框架两者都要查关键提示原文档重点强调连接器必须摄取源系统提供的全部实体类型。如果源系统区分表、视图、物化视图、外部表、存储过程等连接器必须逐一抽取并正确分类。缺失实体类型意味着用户看到的数据资产全景是不完整的。审计时应查阅源系统的 API 文档确认完整实体类型集合不要假设现有代码已经覆盖了一切。Tier 2 — 预期客户默认认为可用属主Ownership连接器是否从源系统抽取属主信息标签/分类Tags/Classifications源系统是否有标签我们是否抽取了Tier 3 — 差异化能力使用统计查询次数、用户、访问模式Profiling列统计min、max、mean、null 数、distinct 数数据质量测试结果、断言样本数据Sample datasampler 管线是否支持该连接器四、Part 2摄取完整度Standard 1的五项核查对连接器抽取的每种实体类型逐一验证以下五点1. 分页Pagination所有列表操作是否都分页重点排查不带分页 token 的列表 API 调用有LIMIT但没有 offset 循环的 SQL 查询硬性上限如SHOW TABLES LIMIT 10000且无溢出检测从源码可见MySQL 的 queries.py 中LIMIT {result_limit}模板即是此类核查的典型对象——需要继续确认上层是否配合 offset 循环。2. 静默丢失Silent drops连接器是否静默跳过实体典型反模式无日志的continueexcept: pass或except: continue无警告日志的过滤条件3. 生成器Generators是否使用 yield 模式典型反模式返回前在内存中收集全部实体的列表实体迭代方法中缺少yield4. 过滤器Filters用户配置的过滤器是否正确生效Schema/table/topic 过滤模式include/exclude 逻辑正确性5. 增量抽取Incremental extraction是否检查markDeletedEntities配置软删除soft delete处理是否正确五、评级校准如何给出可信的 ✅ / ⚠️ / ❌ / N/A元数据覆盖度按 Tier 分别评级✅Compliant 该层级全部元数据类型都被完整抽取且来源归属正确⚠️Partial 大部分被抽取但存在缺口如只有实体级描述、没有列级描述❌Gaps 该层级主要元数据类型缺失如没有列类型、没有实体层级N/A 源系统本身不提供该元数据类型如 MySQL 没有原生标签/分类。不要按缺口评级应标 N/A 并附简短说明摄取完整度✅Compliant 所有列表操作都分页、全程使用生成器、无静默丢失、过滤器工作正常。能处理 10,000 实体而不丢任何一条⚠️Partial 主实体已分页但次要操作有限制如标签、描述获取未分页边缘情况下存在部分静默丢失❌Gaps 主要实体类型可能被静默截断或丢弃主列表操作无分页列表在内存中收集乐观陷阱Optimism traps——必须主动识破「有分页」——是否覆盖了所有操作标签、描述、属主、存储过程、视图不只是表「基类处理了」——检查连接器是否覆写了基类方法从而丢失了分页或实体抽取「有 LIMIT」——没有 offset 循环的 LIMIT 意味着超限实体被静默丢失应归类为「未分页—硬上限」而不是「已分页」评级硬规则任何列表操作使用硬上限LIMIT 无分页/offset 循环且默认值在生产环境可能被超过摄取完整度评级不能是 ✅至少 ⚠️给某元数据类型评 ✅ 前必须验证功能真的正确工作而不只是「代码存在」。代码存在 ≠ 完整正确抽取。若正确性需要更深测试评 ⚠️ 并注明应由专项提示词进一步验证工作示例原文档案例LIMIT 1000应用于每天接收 5 万条记录的查询日志表意味着默认设置下 98% 的查询被静默丢弃。这不是「已分页」也不是「可配置所以没关系」——大多数用户从不修改默认值。摄取完整度至少评 ⚠️并在发现中标记。六、结构化报告与「展示—确认—保存」流程报告输出内容调查完成后按以下 5 项结构化输出元数据覆盖度表格tier × 元数据类型 × 状态 × 来源位置摄取完整度评级及证据具体问题及 file:line 引用与源系统实际能力的差距哪些是源系统提供但我们没抽取的源系统约束清单列出因源系统不提供而评为 N/A 的元数据类型——让读者清楚区分「连接器缺口」与「源系统限制」展示与验证Present Validate保存前先向用户展示摘要评级每个 tier/标准一行带评级 emojiTop findings3–5 个最重要的问题每个含严重级别与一句话描述源系统约束评为 N/A 的项目不确定项标记你对严重度或根因信心不足的发现然后询问Ready to save to.claude/audit-results/01-metadata-ingestion.md? Any findings to adjust?用户确认后保存完整报告到该路径目录不存在则创建。若需调整修订后重新展示。报告模板结构P1 报告遵循 templates/audit-report.md核心章节包括报告头连接器名、服务类型、源码路径、评级、带 file:line 引用的发现表、评级依据做得好的/需要修复的、问题汇总表、按客户影响排序的修复建议P0/P1、源系统约束清单。七、审计实操建议与常见误区给审计者的可执行清单从.claude/connector-audit.json读取连接器名、服务类型、源码路径全局检索所有相关文件不要只看metadata.py先对照基类方法清单再逐文件确认连接器是否覆写——覆写是丢失分页/抽取能力的高发区对每个列表操作逐一追问分页上限溢出检测——分页核查要覆盖所有实体类型而非只查主表Tier 3 元数据profiling、sample data去sampler/与profiler/目录核查而不是在 metadata ingestion 目录里找评级时区分「代码存在」与「工作正确」对不确定项标注 ⚠️ 并交给专项提示词验证输出报告时始终带上 file:line 证据让结论可复核、可追踪遵循上述方法P1 产出的报告就能为 P6 的综合分析与 P7 的修复实施提供坚实、可追溯的输入真正把连接器的元数据覆盖与摄取完整度问题在进入生产前暴露出来。【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenMetadata 连接器审计实战：元数据覆盖度与摄取完整度（Prompt 1 全解）
OpenMetadata 连接器审计实战元数据覆盖度与摄取完整度Prompt 1 全解【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata本篇指南以 OpenMetadata 仓库内skills/connector-audit/prompts/01-metadata-ingestion.md为骨架系统讲解如何对任意连接器connector执行第一项深度可靠性审计元数据覆盖度Metadata Coverage与摄取完整度Ingestion Completeness。你将掌握审计的五大源码检查位置、Tier 1–3 元数据分层评估方法、分页/静默丢失/生成器等摄取完整度核查要点以及一套可校准的评级规则与结构化报告输出流程。文中所有检查点均可在 connector-audit skill 与 ingestion 源码目录 中找到一一对应的实现证据。一、审计定位P1 在整个 connector-audit 流程中的角色OpenMetadata 的 connector-audit 是一套由 7 个提示词Prompt组成的连接器可靠性审计流水线Setup → P1–P5并行调查→ P6综合→ P7实施。P1 即01-metadata-ingestion.md聚焦「元数据覆盖度」与「摄取完整度」两个维度对应标准为Metadata Tiers 1–3与Standard 1Ingestion Completeness见 SKILL.md 中的 Prompt 对照表。执行前需要先完成两项准备SetupPrompt 0确认待审计连接器名称与服务类型定位其源码目录并写出上下文文件.claude/connector-audit.json其内容结构如下见 00-setup.md{ connector_name: name, service_type: type, source_path: ingestion/src/metadata/ingestion/source/type/name/ }加载连接器标准通过/connector-standards加载共享标准位于 skills/connector-review/standards/与按服务类型区分的标准source_types/。审计期间各提示词的输出统一遵循 templates/audit-report.md 报告模板P1 的报告固定保存为.claude/audit-results/01-metadata-ingestion.mdPrompt 6 会读取该文件做综合。建议先用静态分析器skills/connector-review/scripts/analyze_connector.py跑一遍机械检查作为基线再进入 P1 的深度调查。二、五大「必查」源码位置原文档强调一个连接器的元数据抽取代码分散在多个位置审计时必须全部检查任何遗漏都会导致误判。1. 连接器专属代码连接器自身的元数据/模型/查询实现ingestion/src/metadata/ingestion/source/[SERVICE_TYPE]/[CONNECTOR_NAME]/下的metadata.py、models.py、queries.py同目录service_spec.py— 注册各类管线pipeline类型对应的类以 MySQL 连接器为例真实目录结构为 ingestion/src/metadata/ingestion/source/database/mysql/包含metadata.py、models.py、queries.py、service_spec.py、lineage.py、usage.py等文件其中 queries.py 中可见带LIMIT {result_limit};的查询模板——这正是后续「分页核查」要盯住的典型模式。2. 连接ConnectionSchemaopenmetadata-spec/src/main/resources/json/schema/entity/services/connections/[SERVICE_TYPE]/[connector]Connection.json顺着其中的$ref链接继续追踪可以完整了解该连接器支持哪些配置项与元数据类型。3. 服务类型基类关键大量元数据能力在此每个服务类型都有一个共享基类提供核心抽取模式审计时务必核对与你连接器匹配的那个服务类型基类文件核心抽取方法数据库common_db_source.pyCommonDbSourceService表/视图抽取、列元数据、描述、属主、标签、yield 模式Dashboarddashboard_service.pyDashboardServiceSourceyield_dashboard、yield_dashboard_chart、数据模型列Pipelinepipeline_service.pyPipelineServiceSourceyield_pipeline、yield_pipeline_status、任务抽取Storagestorage_service.pyStorageServiceSourceyield_create_container_requestsMessagingmessaging_service.pyMessagingServiceSourceyield_topic、yield_topic_sample_dataSearchsearch_service.pySearchServiceSourceyield_search_indexML Modelmlmodel_service.pyMlModelServiceSourceyield_mlmodelAPIapi_service.pyApiServiceSourceyield_api_collection、yield_api_endpoint以数据库为例common_db_source.py 中存在yield_table方法、第 813 行存在yield_table_constraints——连接器若未覆写这些基类方法则相关元数据能力由基类提供评级时要明确归因到「继承自基类」。4. Profiler / SamplerTier 3 元数据所在地不在 metadata ingestion 中ingestion/src/metadata/sampler/sqlalchemy/[CONNECTOR_NAME]/— 连接器专属采样器。仓库中实际存在 sampler/sqlalchemy/ 目录内含sampler.py及 azuresql、bigquery、databricks、mssql、postgres、snowflake、timescale、trino、unitycatalog 等子目录ingestion/src/metadata/profiler/— profiler 框架5. 共享工具ingestion/src/metadata/utils/filters.py— schema/table/topic 过滤ingestion/src/metadata/ingestion/models/topology.py— TopologyRunnerMixin 实体迭代三、Part 1按 Tier 评估元数据覆盖度对每一种元数据类型都需要依次回答五个问题并记录到报告中是否被抽取是/否在哪里被抽取文件:行号来源是(a) 连接器专属代码 / (b) 继承自基类 / (c) 独立管线 / (d) 不支持完整度抽取是否捕获了源系统的全部可用元数据局限或缺口Tier 1 — 核心不可妥协实体层级databases → schemas → tables、dashboards → charts、pipelines → tasks 等实体类型表、视图、物化视图、外部表等——连接器是否区分了源系统支持的所有类型列/字段元数据名称、数据类型、约束、默认值数据模型列仅 dashboard 连接器是否抽取数据模型的列元数据描述实体级 列级必须来自源系统而非用户手动添加运行状态仅 pipeline 连接器任务成功/失败/耗时表级血缘数据库基于查询日志dashboard/pipeline 连接器跨服务列级血缘连接器专属代码与共享血缘框架两者都要查关键提示原文档重点强调连接器必须摄取源系统提供的全部实体类型。如果源系统区分表、视图、物化视图、外部表、存储过程等连接器必须逐一抽取并正确分类。缺失实体类型意味着用户看到的数据资产全景是不完整的。审计时应查阅源系统的 API 文档确认完整实体类型集合不要假设现有代码已经覆盖了一切。Tier 2 — 预期客户默认认为可用属主Ownership连接器是否从源系统抽取属主信息标签/分类Tags/Classifications源系统是否有标签我们是否抽取了Tier 3 — 差异化能力使用统计查询次数、用户、访问模式Profiling列统计min、max、mean、null 数、distinct 数数据质量测试结果、断言样本数据Sample datasampler 管线是否支持该连接器四、Part 2摄取完整度Standard 1的五项核查对连接器抽取的每种实体类型逐一验证以下五点1. 分页Pagination所有列表操作是否都分页重点排查不带分页 token 的列表 API 调用有LIMIT但没有 offset 循环的 SQL 查询硬性上限如SHOW TABLES LIMIT 10000且无溢出检测从源码可见MySQL 的 queries.py 中LIMIT {result_limit}模板即是此类核查的典型对象——需要继续确认上层是否配合 offset 循环。2. 静默丢失Silent drops连接器是否静默跳过实体典型反模式无日志的continueexcept: pass或except: continue无警告日志的过滤条件3. 生成器Generators是否使用 yield 模式典型反模式返回前在内存中收集全部实体的列表实体迭代方法中缺少yield4. 过滤器Filters用户配置的过滤器是否正确生效Schema/table/topic 过滤模式include/exclude 逻辑正确性5. 增量抽取Incremental extraction是否检查markDeletedEntities配置软删除soft delete处理是否正确五、评级校准如何给出可信的 ✅ / ⚠️ / ❌ / N/A元数据覆盖度按 Tier 分别评级✅Compliant 该层级全部元数据类型都被完整抽取且来源归属正确⚠️Partial 大部分被抽取但存在缺口如只有实体级描述、没有列级描述❌Gaps 该层级主要元数据类型缺失如没有列类型、没有实体层级N/A 源系统本身不提供该元数据类型如 MySQL 没有原生标签/分类。不要按缺口评级应标 N/A 并附简短说明摄取完整度✅Compliant 所有列表操作都分页、全程使用生成器、无静默丢失、过滤器工作正常。能处理 10,000 实体而不丢任何一条⚠️Partial 主实体已分页但次要操作有限制如标签、描述获取未分页边缘情况下存在部分静默丢失❌Gaps 主要实体类型可能被静默截断或丢弃主列表操作无分页列表在内存中收集乐观陷阱Optimism traps——必须主动识破「有分页」——是否覆盖了所有操作标签、描述、属主、存储过程、视图不只是表「基类处理了」——检查连接器是否覆写了基类方法从而丢失了分页或实体抽取「有 LIMIT」——没有 offset 循环的 LIMIT 意味着超限实体被静默丢失应归类为「未分页—硬上限」而不是「已分页」评级硬规则任何列表操作使用硬上限LIMIT 无分页/offset 循环且默认值在生产环境可能被超过摄取完整度评级不能是 ✅至少 ⚠️给某元数据类型评 ✅ 前必须验证功能真的正确工作而不只是「代码存在」。代码存在 ≠ 完整正确抽取。若正确性需要更深测试评 ⚠️ 并注明应由专项提示词进一步验证工作示例原文档案例LIMIT 1000应用于每天接收 5 万条记录的查询日志表意味着默认设置下 98% 的查询被静默丢弃。这不是「已分页」也不是「可配置所以没关系」——大多数用户从不修改默认值。摄取完整度至少评 ⚠️并在发现中标记。六、结构化报告与「展示—确认—保存」流程报告输出内容调查完成后按以下 5 项结构化输出元数据覆盖度表格tier × 元数据类型 × 状态 × 来源位置摄取完整度评级及证据具体问题及 file:line 引用与源系统实际能力的差距哪些是源系统提供但我们没抽取的源系统约束清单列出因源系统不提供而评为 N/A 的元数据类型——让读者清楚区分「连接器缺口」与「源系统限制」展示与验证Present Validate保存前先向用户展示摘要评级每个 tier/标准一行带评级 emojiTop findings3–5 个最重要的问题每个含严重级别与一句话描述源系统约束评为 N/A 的项目不确定项标记你对严重度或根因信心不足的发现然后询问Ready to save to.claude/audit-results/01-metadata-ingestion.md? Any findings to adjust?用户确认后保存完整报告到该路径目录不存在则创建。若需调整修订后重新展示。报告模板结构P1 报告遵循 templates/audit-report.md核心章节包括报告头连接器名、服务类型、源码路径、评级、带 file:line 引用的发现表、评级依据做得好的/需要修复的、问题汇总表、按客户影响排序的修复建议P0/P1、源系统约束清单。七、审计实操建议与常见误区给审计者的可执行清单从.claude/connector-audit.json读取连接器名、服务类型、源码路径全局检索所有相关文件不要只看metadata.py先对照基类方法清单再逐文件确认连接器是否覆写——覆写是丢失分页/抽取能力的高发区对每个列表操作逐一追问分页上限溢出检测——分页核查要覆盖所有实体类型而非只查主表Tier 3 元数据profiling、sample data去sampler/与profiler/目录核查而不是在 metadata ingestion 目录里找评级时区分「代码存在」与「工作正确」对不确定项标注 ⚠️ 并交给专项提示词验证输出报告时始终带上 file:line 证据让结论可复核、可追踪遵循上述方法P1 产出的报告就能为 P6 的综合分析与 P7 的修复实施提供坚实、可追溯的输入真正把连接器的元数据覆盖与摄取完整度问题在进入生产前暴露出来。【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考