OpenMetadata Metabase 仪表盘连接器配置指南连接参数、认证方式与血缘匹配详解【免费下载链接】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 仓库中的 Metabase 连接器说明文档为主体系统讲解如何将 Metabase 实例接入 OpenMetadata完成仪表盘Dashboard、图表Chart元数据与血缘的自动化提取。你将掌握 Username、Password、Host Port 三个核心连接参数的配置方法理解 Database Service PrefixesdbServicePrefixes在血缘匹配中的作用机制并学会通过完整的工作流 YAML 在本地运行元数据摄取。文中所有说明均结合本仓库的 Schema 定义、Python 实现源码与单元测试给出可验证依据可直接对照仓库路径深入阅读。关联文档openmetadata-ui/src/main/resources/ui/public/locales/en-US/Dashboard/Metabase.md该文档同时是 UI 界面中 Metabase 服务连接表单的字段说明来源。前置要求通过 Metabase API 提取元数据Metabase 连接器的元数据提取完全基于 Metabase API 完成因此在配置连接之前需要确认Metabase 实例已部署并可通过 HTTP/HTTPS 访问拥有可用的 Metabase 用户账号用户名 密码或已生成的 API Key该用户对需要摄取的相关仪表盘和图表具备访问权限文档原文要求This user should have access to relevant dashboards and charts in Metabase to fetch the metadata。从仓库源码 client.py 可以看到连接器实际调用的 API 端点包括端点用途POST /api/session/通过用户名/密码换取会话 TokenGET /api/collection获取全部集合Collection列表GET /api/collection/{id}/items?modelsdashboard按集合分页获取仪表盘列表GET /api/card获取全部图表Card数据GET /api/dashboard/{id}获取单个仪表盘详情含 dashcardsGET /api/database/{id}获取数据库信息用于血缘解析GET /api/table/{id}获取表信息用于血缘解析GET /api/user/{id}获取用户信息用于解析 Owner连接详情Connection Details以下字段对应 Metabase 服务在 OpenMetadata UI 中添加服务时的连接表单同时也对应连接配置 JSON Schema metabaseConnection.json 中的属性定义。Username用户名用于连接 Metabase 的用户名示例格式为userorganization.com。该用户需要有权限访问 Metabase 中相关的仪表盘和图表才能正常抓取元数据Schema 中注明其仅在基本认证basic authentication下为必填项Required for basic authentication。Password密码对应连接用户账号的密码Schema 中该字段的format为password在实际存储与日志输出中会被脱敏处理源码中通过password.get_secret_value()取值见 client.py。Host Port主机与端口Metabase 实例的主机地址与端口必须使用 URI 格式的字符串格式http://hostname:port或https://hostname:port示例https://org.metabase.com:3000Schema 中该字段的format为uri并且是连接配置中唯一强制必填required: [hostPort]的字段。在源码中hostPort还会被进一步处理通过clean_uri()去掉末尾多余的/作为所有 API 调用的base_url见 client.py在生成仪表盘、图表的sourceUrl时以{clean_uri(hostPort)}/dashboard/{id}-{name}或{clean_uri(hostPort)}/question/{id}-{name}的形式拼接跳转链接见 metadata.py。提示如果你使用的是 Metabase 云端托管实例需要确保当前运行 OpenMetadata 摄取任务的环境能够直接访问该地址网络策略、防火墙需放行。Database Service Prefixes数据库服务前缀这是血缘匹配的关键配置项对应摄取管线 Schema dashboardServiceMetadataPipeline.json 中lineageInformation.dbServicePrefixes字段。背景在摄取仪表盘和图表时连接器可以提取出创建这些仪表盘/图表所使用的表。为了在 Dashboard 与其来源表之间建立血缘需要知道去 OpenMetadata 中的哪些服务、数据库、Schema、表里查找这些表——dbServicePrefixes正是提供这个查找范围的配置。支持的前缀格式Schema 原文DBServiceName—— 仅指定数据库服务名DBServiceName.DatabaseName—— 服务名 数据库名DBServiceName.DatabaseName.SchemaName—— 服务名 数据库名 Schema 名DBServiceName.DatabaseName.SchemaName.TableName—— 服务名 数据库名 Schema 名 表名配置类型为字符串数组例如lineageInformation: dbServicePrefixes: - my_mysql_service - my_postgres_service.analytics匹配逻辑的源码印证在 metadata.py 中连接器先通过parse_db_service_prefix()将每个前缀解析为service, database, schema, table四元组然后在血缘解析时逐级校验若前缀指定了 database但 Metabase 端解析出的库名与之前缀不一致则跳过_yield_lineage_from_query中prefix_database_name.lower() ! database_name.lower()若前缀指定了 schema 或 table同理逐级比对最终通过build_es_fqn_search_string()构造 FQN 搜索串调用metadata.search_in_any_service()在 OpenMetadata 中模糊匹配目标表实体。也就是说前缀层级越完整血缘匹配越精确只写DBServiceName时连接器会在该服务下按数据库名与表名进行搜索匹配。认证方式会话认证与 API Key 二选一虽然 UI 表单与文档正文只列出了 Username / Password但仓库 Schema 与客户端实现实际上支持两种认证方式理解这一点有助于排查连接问题。在 client.py 的_get_metabase_session()与__init__中可以看到完整逻辑用户名/密码会话认证默认向{hostPort}/api/session/发起 POST携带{username: ..., password: ...}从响应中取出会话id之后所有请求通过请求头X-Metabase-Session携带会话 TokenAPI Key 认证若配置了apiKey字段对应 Schema metabaseConnection.json 中的apiKeyformat: password则跳过会话创建直接通过请求头X-API-KEY携带 Token。两种方式的代码分支如下节选自 client.pyif self.config.apiKey: # Use API token authentication extra_headers{METABASE_API_HEADER: self.config.apiKey.get_secret_value()} else: # Use session-based authentication session_token self._get_metabase_session() extra_headers{METABASE_SESSION_HEADER: session_token}从源码结构看apiKey是用户名/密码之外的另一种更推荐的认证方式尤其适合对服务账号做细粒度权限管理在 UI 表单中未展示该字段时可通过手工编辑服务连接配置或直接修改 YAML 工作流来启用。完整摄取工作流 YAML 示例仓库提供了可直接参考的示例工作流 metabase.yaml完整内容如下source: type: metabase serviceName: test serviceConnection: config: type: Metabase username: username password: password hostPort: http://hostPort # apiKey: api_key sourceConfig: config: type: DashboardMetadata dashboardFilterPattern: {} chartFilterPattern: {} projectFilterPattern: {} sink: type: metadata-rest config: {} workflowConfig: openMetadataServerConfig: hostPort: http://localhost:8585/api authProvider: openmetadata securityConfig: jwtToken: your-jwt-token要点说明serviceConnection.config.type固定为Metabase见 Schema 中metabaseType枚举唯一取值MetabasesourceConfig.config.type固定为DashboardMetadata见 dashboardServiceMetadataPipeline.json 中dashboardMetadataConfigType枚举dashboardFilterPattern/chartFilterPattern为正则过滤器用于排除或包含指定仪表盘/图表留空{}表示全量摄取projectFilterPattern在 Metabase 场景下对应集合Collection维度若需要配置血缘前缀在sourceConfig.config下追加lineageInformation.dbServicePrefixes数组见上文若使用 API Key 认证将username/password替换为apiKey: your_api_key工作流中还支持loggerLevel: INFO # DEBUG, INFO, WARN or ERROR日志级别控制。运行方式仓库只读以下为本地运行摄取的标准方式# 在 ingestion 目录下将上述内容保存为 metabase.yaml 后执行 python -m metadata.workflow.metadata --yaml-file metabase.yaml元数据提取与血缘生成的底层原理摄取流程拓扑连接器的入口类是 metadata.py 中的MetabaseSource继承自DashboardServiceSource。其摄取流程由prepare()与各yield_*方法构成如下prepare()批量拉取全部集合列表get_collections_list与全部图表字典get_charts_dict以 chart id 为键get_dashboards_list()遍历每个集合通过GET /collection/{id}/items?modelsdashboard汇总仪表盘列表get_dashboard_details()逐个获取仪表盘详情解析其dashcards兼容 Metabase 0.48 之前版本的ordered_cards字段见 client.py 中的兼容处理得到每个仪表盘包含的图表 id 列表yield_dashboard()生成CreateDashboardRequest包含 displayName、描述、sourceUrl、所属集合project、图表引用、Owneryield_dashboard_chart()为每个图表生成CreateChartRequest包含名称、描述、图表类型通过get_standard_chart_type()将 Metabase 的 display 类型映射为 OpenMetadata 标准图表类型、sourceUrlyield_dashboard_lineage_details()生成仪表盘/图表与底层表之间的血缘关系。孤儿图表的可见性兜底源码中有一个值得注意的细节metadata.py在处理完最后一个仪表盘后连接器会检查是否存在未被任何仪表盘引用的图表orphan_charts_id。若存在则会自动创建一个名为DEFAULT_DASHBOARD的默认仪表盘来收纳这些孤儿图表确保它们在 OpenMetadata 中仍然可见、可检索。该默认仪表盘没有真实的 sourceUrlsourceUrl置为空字符串。血缘的两条解析路径血缘生成是 Metabase 连接器最复杂的部分在 metadata.py 的yield_dashboard_lineage_details中根据图表查询类型分两条路径处理Native原生 SQL查询调用_yield_lineage_from_query()先通过GET /database/{id}获取数据库信息再使用仓库内的 SQL 血缘解析器LineageParser对 SQL 做解析解析前会移除 Metabase 的可选子句语法[[...]]见 metadata.py提取 SQL 中引用的源表并按db_service_prefix前缀逐级过滤后在 OpenMetadata 中搜索匹配的表实体最终为 Dashboard → Table、Chart → Table 分别建立血缘Query Builder可视化查询调用_yield_lineage_from_api()通过GET /table/{table_id}获取图表关联的主表结合前缀配置生成 FQN 搜索串进行匹配。注意源码注释指出若可视化查询中存在 JOIN当前实现只处理单个主表嵌套对象中的其他表暂不覆盖。血缘匹配的前缀过滤示意来自_yield_lineage_from_query(prefix_service_name, prefix_database_name, prefix_schema_name, prefix_table_name) self.parse_db_service_prefix(db_service_prefix) if prefix_database_name and database_name and prefix_database_name.lower() ! database_name.lower(): return # 数据库名不匹配跳过 if prefix_schema_name and database_schema_name and prefix_schema_name.lower() ! database_schema_name.lower(): continue # Schema 不匹配跳过该表 if prefix_table_name and table and prefix_table_name.lower() ! table.lower(): continue # 表名不匹配跳过该表 fqn_search_string build_es_fqn_search_string( database_nameprefix_database_name or database_name, schema_nameprefix_schema_name or database_schema_name, service_nameprefix_service_name or *, table_nameprefix_table_name or table, )从这段逻辑可以推断前缀中未指定的层级会回退使用 Metabase 端解析出的实际值service_name未指定时则以*通配在所有服务中搜索因此正确配置前缀能显著提升匹配效率并避免跨服务误匹配。连接测试与验证OpenMetadata 在创建服务或执行摄取前会执行连接测试Metabase 的连接测试实现位于 connection.py。def custom_executor(): collections client.get_collections_list_test_conn() return client.get_dashboards_list_test_conn(collections) test_fn {GetDashboards: custom_executor}可见连接测试实际做两件事调用GET /api/collection验证认证是否成功、集合列表是否可读尝试从集合中拉取至少一个仪表盘列表验证业务数据的可读性。仓库还提供了针对 Metabase 连接器的拓扑单元测试 test_metabase.py其中使用mock_metabase仪表盘服务与mock_mysql数据库服务构造了完整的血缘场景验证了图表、仪表盘实体的生成与 Dashboard → Table 血缘边EntitiesEdgeLineageDetails的输出格式可作为自行扩展配置与排查血缘问题的参考。另外CLI 端到端测试用例 test_cli_metabase.py 及其配套 YAMLmetabase.yaml也展示了真实摄取场景下的配置组织方式。配置清单速查配置项是否必填取值/格式说明type是Metabase服务类型固定枚举值username二选一字符串基本认证用户名如userorganization.compassword二选一字符串password 格式基本认证密码apiKey二选一字符串password 格式API Key 认证替代用户名/密码hostPort是http(s)://host:portURIMetabase 实例地址唯一强制必填dbServicePrefixes否字符串数组血缘匹配前缀支持最多四级服务/库/Schema/表dashboardFilterPattern否正则对象过滤仪表盘chartFilterPattern否正则对象过滤图表includeOwners否布尔默认false是否摄取 Owner源码get_owner_ref依据source_config.includeOwners决定是否按 creator 邮箱解析负责人配置完成后即可在 OpenMetadata UI 中创建 Metabase 仪表盘服务并调度摄取管线将 Metabase 中的仪表盘、图表资产以及它们与底层数据表之间的血缘关系统一纳入数据上下文Open Context Layer管理。【免费下载链接】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 Metabase 仪表盘连接器配置指南：连接参数、认证方式与血缘匹配详解
OpenMetadata Metabase 仪表盘连接器配置指南连接参数、认证方式与血缘匹配详解【免费下载链接】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 仓库中的 Metabase 连接器说明文档为主体系统讲解如何将 Metabase 实例接入 OpenMetadata完成仪表盘Dashboard、图表Chart元数据与血缘的自动化提取。你将掌握 Username、Password、Host Port 三个核心连接参数的配置方法理解 Database Service PrefixesdbServicePrefixes在血缘匹配中的作用机制并学会通过完整的工作流 YAML 在本地运行元数据摄取。文中所有说明均结合本仓库的 Schema 定义、Python 实现源码与单元测试给出可验证依据可直接对照仓库路径深入阅读。关联文档openmetadata-ui/src/main/resources/ui/public/locales/en-US/Dashboard/Metabase.md该文档同时是 UI 界面中 Metabase 服务连接表单的字段说明来源。前置要求通过 Metabase API 提取元数据Metabase 连接器的元数据提取完全基于 Metabase API 完成因此在配置连接之前需要确认Metabase 实例已部署并可通过 HTTP/HTTPS 访问拥有可用的 Metabase 用户账号用户名 密码或已生成的 API Key该用户对需要摄取的相关仪表盘和图表具备访问权限文档原文要求This user should have access to relevant dashboards and charts in Metabase to fetch the metadata。从仓库源码 client.py 可以看到连接器实际调用的 API 端点包括端点用途POST /api/session/通过用户名/密码换取会话 TokenGET /api/collection获取全部集合Collection列表GET /api/collection/{id}/items?modelsdashboard按集合分页获取仪表盘列表GET /api/card获取全部图表Card数据GET /api/dashboard/{id}获取单个仪表盘详情含 dashcardsGET /api/database/{id}获取数据库信息用于血缘解析GET /api/table/{id}获取表信息用于血缘解析GET /api/user/{id}获取用户信息用于解析 Owner连接详情Connection Details以下字段对应 Metabase 服务在 OpenMetadata UI 中添加服务时的连接表单同时也对应连接配置 JSON Schema metabaseConnection.json 中的属性定义。Username用户名用于连接 Metabase 的用户名示例格式为userorganization.com。该用户需要有权限访问 Metabase 中相关的仪表盘和图表才能正常抓取元数据Schema 中注明其仅在基本认证basic authentication下为必填项Required for basic authentication。Password密码对应连接用户账号的密码Schema 中该字段的format为password在实际存储与日志输出中会被脱敏处理源码中通过password.get_secret_value()取值见 client.py。Host Port主机与端口Metabase 实例的主机地址与端口必须使用 URI 格式的字符串格式http://hostname:port或https://hostname:port示例https://org.metabase.com:3000Schema 中该字段的format为uri并且是连接配置中唯一强制必填required: [hostPort]的字段。在源码中hostPort还会被进一步处理通过clean_uri()去掉末尾多余的/作为所有 API 调用的base_url见 client.py在生成仪表盘、图表的sourceUrl时以{clean_uri(hostPort)}/dashboard/{id}-{name}或{clean_uri(hostPort)}/question/{id}-{name}的形式拼接跳转链接见 metadata.py。提示如果你使用的是 Metabase 云端托管实例需要确保当前运行 OpenMetadata 摄取任务的环境能够直接访问该地址网络策略、防火墙需放行。Database Service Prefixes数据库服务前缀这是血缘匹配的关键配置项对应摄取管线 Schema dashboardServiceMetadataPipeline.json 中lineageInformation.dbServicePrefixes字段。背景在摄取仪表盘和图表时连接器可以提取出创建这些仪表盘/图表所使用的表。为了在 Dashboard 与其来源表之间建立血缘需要知道去 OpenMetadata 中的哪些服务、数据库、Schema、表里查找这些表——dbServicePrefixes正是提供这个查找范围的配置。支持的前缀格式Schema 原文DBServiceName—— 仅指定数据库服务名DBServiceName.DatabaseName—— 服务名 数据库名DBServiceName.DatabaseName.SchemaName—— 服务名 数据库名 Schema 名DBServiceName.DatabaseName.SchemaName.TableName—— 服务名 数据库名 Schema 名 表名配置类型为字符串数组例如lineageInformation: dbServicePrefixes: - my_mysql_service - my_postgres_service.analytics匹配逻辑的源码印证在 metadata.py 中连接器先通过parse_db_service_prefix()将每个前缀解析为service, database, schema, table四元组然后在血缘解析时逐级校验若前缀指定了 database但 Metabase 端解析出的库名与之前缀不一致则跳过_yield_lineage_from_query中prefix_database_name.lower() ! database_name.lower()若前缀指定了 schema 或 table同理逐级比对最终通过build_es_fqn_search_string()构造 FQN 搜索串调用metadata.search_in_any_service()在 OpenMetadata 中模糊匹配目标表实体。也就是说前缀层级越完整血缘匹配越精确只写DBServiceName时连接器会在该服务下按数据库名与表名进行搜索匹配。认证方式会话认证与 API Key 二选一虽然 UI 表单与文档正文只列出了 Username / Password但仓库 Schema 与客户端实现实际上支持两种认证方式理解这一点有助于排查连接问题。在 client.py 的_get_metabase_session()与__init__中可以看到完整逻辑用户名/密码会话认证默认向{hostPort}/api/session/发起 POST携带{username: ..., password: ...}从响应中取出会话id之后所有请求通过请求头X-Metabase-Session携带会话 TokenAPI Key 认证若配置了apiKey字段对应 Schema metabaseConnection.json 中的apiKeyformat: password则跳过会话创建直接通过请求头X-API-KEY携带 Token。两种方式的代码分支如下节选自 client.pyif self.config.apiKey: # Use API token authentication extra_headers{METABASE_API_HEADER: self.config.apiKey.get_secret_value()} else: # Use session-based authentication session_token self._get_metabase_session() extra_headers{METABASE_SESSION_HEADER: session_token}从源码结构看apiKey是用户名/密码之外的另一种更推荐的认证方式尤其适合对服务账号做细粒度权限管理在 UI 表单中未展示该字段时可通过手工编辑服务连接配置或直接修改 YAML 工作流来启用。完整摄取工作流 YAML 示例仓库提供了可直接参考的示例工作流 metabase.yaml完整内容如下source: type: metabase serviceName: test serviceConnection: config: type: Metabase username: username password: password hostPort: http://hostPort # apiKey: api_key sourceConfig: config: type: DashboardMetadata dashboardFilterPattern: {} chartFilterPattern: {} projectFilterPattern: {} sink: type: metadata-rest config: {} workflowConfig: openMetadataServerConfig: hostPort: http://localhost:8585/api authProvider: openmetadata securityConfig: jwtToken: your-jwt-token要点说明serviceConnection.config.type固定为Metabase见 Schema 中metabaseType枚举唯一取值MetabasesourceConfig.config.type固定为DashboardMetadata见 dashboardServiceMetadataPipeline.json 中dashboardMetadataConfigType枚举dashboardFilterPattern/chartFilterPattern为正则过滤器用于排除或包含指定仪表盘/图表留空{}表示全量摄取projectFilterPattern在 Metabase 场景下对应集合Collection维度若需要配置血缘前缀在sourceConfig.config下追加lineageInformation.dbServicePrefixes数组见上文若使用 API Key 认证将username/password替换为apiKey: your_api_key工作流中还支持loggerLevel: INFO # DEBUG, INFO, WARN or ERROR日志级别控制。运行方式仓库只读以下为本地运行摄取的标准方式# 在 ingestion 目录下将上述内容保存为 metabase.yaml 后执行 python -m metadata.workflow.metadata --yaml-file metabase.yaml元数据提取与血缘生成的底层原理摄取流程拓扑连接器的入口类是 metadata.py 中的MetabaseSource继承自DashboardServiceSource。其摄取流程由prepare()与各yield_*方法构成如下prepare()批量拉取全部集合列表get_collections_list与全部图表字典get_charts_dict以 chart id 为键get_dashboards_list()遍历每个集合通过GET /collection/{id}/items?modelsdashboard汇总仪表盘列表get_dashboard_details()逐个获取仪表盘详情解析其dashcards兼容 Metabase 0.48 之前版本的ordered_cards字段见 client.py 中的兼容处理得到每个仪表盘包含的图表 id 列表yield_dashboard()生成CreateDashboardRequest包含 displayName、描述、sourceUrl、所属集合project、图表引用、Owneryield_dashboard_chart()为每个图表生成CreateChartRequest包含名称、描述、图表类型通过get_standard_chart_type()将 Metabase 的 display 类型映射为 OpenMetadata 标准图表类型、sourceUrlyield_dashboard_lineage_details()生成仪表盘/图表与底层表之间的血缘关系。孤儿图表的可见性兜底源码中有一个值得注意的细节metadata.py在处理完最后一个仪表盘后连接器会检查是否存在未被任何仪表盘引用的图表orphan_charts_id。若存在则会自动创建一个名为DEFAULT_DASHBOARD的默认仪表盘来收纳这些孤儿图表确保它们在 OpenMetadata 中仍然可见、可检索。该默认仪表盘没有真实的 sourceUrlsourceUrl置为空字符串。血缘的两条解析路径血缘生成是 Metabase 连接器最复杂的部分在 metadata.py 的yield_dashboard_lineage_details中根据图表查询类型分两条路径处理Native原生 SQL查询调用_yield_lineage_from_query()先通过GET /database/{id}获取数据库信息再使用仓库内的 SQL 血缘解析器LineageParser对 SQL 做解析解析前会移除 Metabase 的可选子句语法[[...]]见 metadata.py提取 SQL 中引用的源表并按db_service_prefix前缀逐级过滤后在 OpenMetadata 中搜索匹配的表实体最终为 Dashboard → Table、Chart → Table 分别建立血缘Query Builder可视化查询调用_yield_lineage_from_api()通过GET /table/{table_id}获取图表关联的主表结合前缀配置生成 FQN 搜索串进行匹配。注意源码注释指出若可视化查询中存在 JOIN当前实现只处理单个主表嵌套对象中的其他表暂不覆盖。血缘匹配的前缀过滤示意来自_yield_lineage_from_query(prefix_service_name, prefix_database_name, prefix_schema_name, prefix_table_name) self.parse_db_service_prefix(db_service_prefix) if prefix_database_name and database_name and prefix_database_name.lower() ! database_name.lower(): return # 数据库名不匹配跳过 if prefix_schema_name and database_schema_name and prefix_schema_name.lower() ! database_schema_name.lower(): continue # Schema 不匹配跳过该表 if prefix_table_name and table and prefix_table_name.lower() ! table.lower(): continue # 表名不匹配跳过该表 fqn_search_string build_es_fqn_search_string( database_nameprefix_database_name or database_name, schema_nameprefix_schema_name or database_schema_name, service_nameprefix_service_name or *, table_nameprefix_table_name or table, )从这段逻辑可以推断前缀中未指定的层级会回退使用 Metabase 端解析出的实际值service_name未指定时则以*通配在所有服务中搜索因此正确配置前缀能显著提升匹配效率并避免跨服务误匹配。连接测试与验证OpenMetadata 在创建服务或执行摄取前会执行连接测试Metabase 的连接测试实现位于 connection.py。def custom_executor(): collections client.get_collections_list_test_conn() return client.get_dashboards_list_test_conn(collections) test_fn {GetDashboards: custom_executor}可见连接测试实际做两件事调用GET /api/collection验证认证是否成功、集合列表是否可读尝试从集合中拉取至少一个仪表盘列表验证业务数据的可读性。仓库还提供了针对 Metabase 连接器的拓扑单元测试 test_metabase.py其中使用mock_metabase仪表盘服务与mock_mysql数据库服务构造了完整的血缘场景验证了图表、仪表盘实体的生成与 Dashboard → Table 血缘边EntitiesEdgeLineageDetails的输出格式可作为自行扩展配置与排查血缘问题的参考。另外CLI 端到端测试用例 test_cli_metabase.py 及其配套 YAMLmetabase.yaml也展示了真实摄取场景下的配置组织方式。配置清单速查配置项是否必填取值/格式说明type是Metabase服务类型固定枚举值username二选一字符串基本认证用户名如userorganization.compassword二选一字符串password 格式基本认证密码apiKey二选一字符串password 格式API Key 认证替代用户名/密码hostPort是http(s)://host:portURIMetabase 实例地址唯一强制必填dbServicePrefixes否字符串数组血缘匹配前缀支持最多四级服务/库/Schema/表dashboardFilterPattern否正则对象过滤仪表盘chartFilterPattern否正则对象过滤图表includeOwners否布尔默认false是否摄取 Owner源码get_owner_ref依据source_config.includeOwners决定是否按 creator 邮箱解析负责人配置完成后即可在 OpenMetadata UI 中创建 Metabase 仪表盘服务并调度摄取管线将 Metabase 中的仪表盘、图表资产以及它们与底层数据表之间的血缘关系统一纳入数据上下文Open Context Layer管理。【免费下载链接】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），仅供参考
