DataHub Glue 连接器：跨账号访问、平台实例对齐与资源链接（Resource Link）摄入实战指南

DataHub Glue 连接器：跨账号访问、平台实例对齐与资源链接（Resource Link）摄入实战指南

【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub

本篇围绕 DataHub 的glue摄入源（AWS Glue Data Catalog 连接器）展开，完整覆盖其官方文档metadata-ingestion/docs/sources/glue/glue_pre.md中的核心内容：Glue 元数据摄入范围、IAM 权限清单、基于 STS AssumeRole 的跨账号访问、catalog_id跨账号目录访问、catalog_to_platform_instance目录到平台实例的映射，以及 Lake Formation 资源链接的 schema 解析。读完本文，你将能够正确配置 Glue 摄入配方（recipe）、为摄入角色规划最小权限集、在多账号场景下保证同一张表的 URN 唯一且一致，并能理解每个配置项在源码中的落地位置。

1. Glue 连接器摄入什么

glue模块将 AWS Glue Data Catalog 的元数据摄入 DataHub，面向生产级摄入流程。根据官方文档，该插件提取以下内容：

• Glue catalog 中的表（Tables）；
• 每张表关联的列类型（Column types）；
• 表元数据，如 owner、描述与 parameters；
• Glue 作业（Jobs）及其组件转换（transformations）、数据源（data sources）和数据汇（data sinks）；
• 由 Glue 作业引用的 JDBC 数据源（如 PostgreSQL、MySQL、Redshift）的上游血缘。

连接器在源码中由 GlueSource 实现，其声明的能力与文档描述一一对应（见 glue.py 能力声明）：

概念映射上，Glue Database 对应 DataHub Container（子类型Database），Glue Table 对应 Dataset（子类型Table），Glue Job 对应 DataFlow，作业内的转换/数据源/数据汇对应 DataJob 与 Dataset（概念映射表见 README）。

最简配方如 glue_recipe.yml 所示：

source: type: glue config: # Coordinates aws_region: "my-aws-region" sink: # sink configs

2. IAM 权限清单

运行摄入前，需确保网络可达、凭据有效、且拥有文档要求的读取权限。文档给出了三组最小权限策略：

2.1 数据集摄入所需权限

{ "Effect": "Allow", "Action": [ "glue:GetDatabases", "glue:GetTables" ], "Resource": [ "arn:aws:glue:$region-id:$account-id:catalog", "arn:aws:glue:$region-id:$account-id:database/*", "arn:aws:glue:$region-id:$account-id:table/*" ] }

2.2 作业摄入（extract_transforms: True）额外所需权限

{ "Effect": "Allow", "Action": [ "glue:GetDataflowGraph", "glue:GetJobs", "glue:GetConnection", "s3:GetObject" ], "Resource": "*" }

文档特别指出：glue:GetConnection仅在 Glue 作业引用了命名连接（named connections，即在 Glue 控制台配置的 JDBC 连接）时才需要；如果作业只使用内联（inline）连接参数，可以不需要该权限。从源码可以印证这一说法：GlueSource._resolve_glue_connection 中调用glue_client.get_connection(...)，而s3:GetObject则对应作业脚本的下载逻辑 get_dataflow_script。

2.3 数据集 Profiling 额外所需权限

{ "Effect": "Allow", "Action": [ "glue:GetPartitions" ], "Resource": "*" }

3. 跨账号访问（Cross-Account Access）

Glue 连接器通过 AWS STS AssumeRole 支持跨账号访问，允许运行在一个 AWS 账号中的 DataHub 摄入另一个 AWS 账号里 Glue catalog 的元数据。

3.1 目标账号：创建可被 Assume 的 IAM 角色

在目标账号（Glue catalog 所在账号）创建一个 IAM 角色，附加第 2 节中的 Glue 权限策略，并配置信任策略允许源账号 assume 该角色：

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::SOURCE-ACCOUNT-ID:role/DataHubExecutionRole" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "your-unique-external-id" } } } ] }

3.2 摄入配方：配置aws_config.aws_role

简单 ARN 格式：

source: type: glue config: aws_config: aws_role: "arn:aws:iam::TARGET-ACCOUNT-ID:role/DataHubGlueReadRole"

带 External ID（出于安全考虑推荐）：

source: type: glue config: aws_config: aws_role: RoleArn: "arn:aws:iam::TARGET-ACCOUNT-ID:role/DataHubGlueReadRole" ExternalId: "your-unique-external-id"

角色链（Role chaining，按顺序 assume 多个角色）：

source: type: glue config: aws_config: aws_role: - "arn:aws:iam::INTERMEDIARY-ACCOUNT-ID:role/IntermediateRole" - RoleArn: "arn:aws:iam::TARGET-ACCOUNT-ID:role/DataHubGlueReadRole" ExternalId: "your-unique-external-id"

源码印证：aws_role定义在 AwsConnectionConfig，类型为Optional[Union[str, List[Union[str, AwsAssumeRoleConfig]]]]，即支持字符串或字符串/对象混合列表，对象格式对应 AwsAssumeRoleConfig（RoleArn+ 可选ExternalId，且作为PermissiveConfigModel允许透传 boto3 STS 的额外参数，如文档所述的RoleSessionName、DurationSeconds、Policy）。

实际执行时：

• assume_role() 构造 STS 客户端并发起assume_role，默认注入RoleSessionName="DatahubIngestionSource"，再叠加角色对象中的字段；
• AwsConnectionConfig.get_session() 会先检测当前运行环境（ECS/EKS/Lambda/App Runner/Beanstalk/EC2 等，见 detect_aws_environment），仅当目标角色与当前身份不同时才真正执行 assume，并按列表顺序循环串联assume（角色链循环），这与文档中“assume multiple roles in sequence”的语义一致；
• 临时凭据会被缓存，并在到期前不足 5 分钟时自动刷新（_should_refresh_credentials），避免长摄入任务中途凭据失效。

3.3 跨账号 Catalog 访问（不 assume 角色）：catalog_id

对于访问另一个账号中的特定 Glue catalog（无需 assume 角色），可使用catalog_id参数：

source: type: glue config: catalog_id: "123456789012" # Target account's AWS account ID

这适用于“账号 A 已将 Glue catalog 共享给账号 B，而摄入运行在账号 B、需要访问账号 A 的 catalog”的场景。catalog_id字段定义在 GlueSourceConfig，描述为“The aws account id where the target glue catalog lives. If None, datahub will ingest glue in aws caller's account.”

从源码看，catalog_id会作为CatalogId参数透传给分页 API：get_all_databases 与 get_tables_from_database 中的paginator.paginate(DatabaseName=..., CatalogId=self.source_config.catalog_id)；作业脚本读取则不受其影响——get_all_jobs 的注释明确说明 boto3 的get_jobs不支持跨账号，因此跨账号场景下作业摄入仍发生在运行账号内。

3.4 平台实例（platform instance）注意事项

文档区分了两种情形：

• 不使用 platform instance：如果从不同账号摄入同一个 Glue catalog 而不设置platform_instance，DataHub 会将它们识别为相同实体，只产生一个 dataset；
• 使用 platform instance：使用不同的platform_instance值会创建具有不同 URN 的独立 dataset 实体，适用于追踪同一数据经由不同访问路径的流转。

4.catalog_to_platform_instance：将目录映射到平台实例

单个platform_instance会把同一摄入运行中的所有表打上同一个 instance 戳。当一次摄入看到了不同账号拥有的表时（例如跨账号catalog_id摄入，或共享进你 catalog 的 Lake Formation 表），就会出现问题：这些表被打上的是摄入账号的 instance，其 URN 与属主账号自己的 Glue 摄入产生的 URN 不一致，同一张表在 DataHub 中出现两次。

catalog_to_platform_instance用于将每个拥有方 catalog 映射到属主所使用的platform_instance（以及可选的env），每张表按其所属 catalog 打上戳。键是该 catalog 的 ARN authorityarn:aws:glue:{region}:{account-id}——账号 + 区域，因为同一账号在两个区域是两个不同的 catalog：

source: type: glue config: aws_region: us-east-1 platform_instance: ingestion_acct # fallback for tables with no catalog mapping catalog_to_platform_instance: "arn:aws:glue:us-east-1:111122223333": platform_instance: domain_a env: PROD "arn:aws:glue:us-east-1:444455556666": platform_instance: domain_b

未在映射中列出的表，回退到 source 自身的platform_instance/env。对于 Lake Formation 资源链接，连接器还会额外产出一条指向属主表 URN 的表级上游血缘边（经同一映射解析），使共享表“接回”其来源，而不是像重复实体一样出现。

源码印证：

• 字段定义与文档语义一致：catalog_to_platform_instance，其 description 额外说明了键格式中 partition 的取值（商业区aws、GovCloudaws-us-gov、中国区aws-cn、隔离区aws-iso*），并指出该键与 Spark/OpenLineage 的connections映射使用相同键；
• 键的校验在 check_catalog_arn_keys 中完成：先用正则 GLUE_CATALOG_ARN_PATTERN 校验arn:{partition}:glue:{region}:{12位账号}形状，再通过 _aws_partition_for_region（委托 botocore 的get_partition_for_region，而非手写区域前缀表）校验 partition 与 region 是否匹配——两者任一不满足都会抛出带非法键列表的ValueError；
• 运行时解析在 _resolve_platform_instance：按表返回的CatalogId拼出 ARN authority 查映射表，命中则覆盖platform_instance/env（映射值为None的字段保留 source 默认值），未命中则回退。表实体（_gen_table_wu）与作业 DAG 中的 Glue 表节点（process_dataflow_node，支持作业通过from_catalog(catalog_id=...)携带的catalog_id）都走同一条解析路径，保证两侧 URN 一致。

5. 资源链接（Resource Link）的 Schema 解析：resolve_resource_link_schema

资源链接只是一个指针，因此在 catalog 中不携带自身 schema。默认（resolve_resource_link_schema: true）下，连接器会用属主表的 schema 填充链接的 schema，使列信息在摄入的 dataset 上可见。解析顺序是先读 DataHub（属主账号已摄入时，不产生额外 AWS 调用），否则对目标做跨账号glue:GetTable（要求对共享表有glue:GetTable权限）。两个来源都不可用时，链接保持无 schema，其列仍可通过上游血缘边触达。设置resolve_resource_link_schema: false可使资源链接始终无 schema。

源码印证（均在 glue.py）：

• 配置字段 resolve_resource_link_schema 默认True，description 与文档完全对应；
• 解析主流程 _resource_link_schema 会深拷贝属主 schema（避免污染从 DataHub 读回的 aspect 对象）并改写schemaName为链接本地表名；
• 两级回退在 _resolve_owner_schema：先 _resource_link_schema_from_datahub（ctx.graph.get_schema_metadata(owner_urn)，GMS/网络错误不中断运行），再 _resource_link_schema_from_glue（glue_client.get_table(CatalogId=..., ...)，权限不足时降级为无 schema 并告警）；
• 摄入报告 GlueSourceReport 设有三个计数器num_resource_link_schema_from_datahub、num_resource_link_schema_from_glue、num_resource_link_schema_unresolved，用于观测上述回退的实际命中分布；
• 表级上游边（COPY 类型）由 _resource_link_owner_upstreams 生成，与存储血缘合并进同一个UpstreamLineageaspect（get_lineage_if_enabled 是数据集UpstreamLineage的唯一出口，避免两个全量替换型 aspect 相互覆盖）。

6. 验证依据：单元测试与黄金文件

跨账号与平台实例行为有专门的测试与期望输出，可作为本文配置说明的可验证依据：

• 测试主文件：test_glue_source.py，测试桩见 test_glue_source_stubs.py；
• 跨账号摄入的黄金输出：glue_mces_cross_account_golden.json；
• 平台实例相关的黄金输出：glue_mces_platform_instance_golden.json；
• 其余黄金文件（表/列血缘、视图、profiling、Lake Formation 标签、Delta schema 等）位于 tests/unit/glue/，可用于对照各配置项的完整 MCE 输出形态。

7. 小结与配置速查

适用前提与限制：以上均以当前仓库中metadata-ingestion的实现为准；跨账号 catalog 访问要求目标账号已按 AWS 侧要求完成 catalog 共享，且 boto3get_jobs不支持跨账号（作业相关能力仍运行在摄入账号内）；catalog_to_platform_instance的键必须严格为arn:{partition}:glue:{region}:{account}形式且 partition 与 region 匹配，否则在配方加载阶段即报错。

【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub