DataHub datahub-apply 使用指南以编程方式批量应用 Ownership、Domain、Tag 与 Glossary Term【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahubdatahub-apply是 DataHub 元数据摄取Metadata Ingestion体系中的一类特殊 Source它不从外部系统发现元数据而是将配置文件中声明的元数据变更直接应用到 DataHub 中已存在的实体上非常适合批量所有权Ownership、域Domain、标签Tag和术语表术语Glossary Term的策管Curation任务。读完本文你将掌握datahub-apply的配置结构、四类应用操作owner/tag/term/domain的写法、其底层基于 Metadata Change ProposalMCP与 Patch 的更新机制以及配套的datahub containerCLI 命令和故障排查方法。一、模块定位从提取到应用的元数据工作流DataHub 的大多数摄取 Source如 Hive、Snowflake 等负责发现并提取外部系统的元数据而datahub-apply的角色完全相反——它只应用配置好的更新不做任何发现。官方文档将其定位为Thedatahub-applymodule applies metadata changes directly to existing DataHub entities. It is useful for programmatic curation tasks such as bulk ownership, domain, tag, and glossary-term updates.在 datahub-apply_pre.md 的基础上README.md 给出了直观的概念映射源侧概念Source ConceptDataHub 概念说明Apply 操作输入Metadata Change ProposalMCP更新输入驱动元数据更新而非元数据发现资产目标列表Dataset / Container及其他受支持实体目标在 recipe 配置中显式选定Ownership / domain / tag / term 赋值Ownership、Domain、GlobalTags、GlossaryTerms 等 aspect直接应用到现有 DataHub 实体从源码结构看datahub-apply在连接器注册表中被登记为platform_id: datahubapply、platform_name: DataHubApply其 classname 指向 datahub_apply.py 中的DataHubApplySource参见 connector_registry/datahub.json并在 setup.py 中注册了入口点datahub-apply。该 Source 的类注释明确写道它是 CLI 的辅助封装目的是让用户通过 Managed Ingestion托管摄取也能执行这类元数据应用任务。二、前置条件Prerequisites按 datahub-apply_pre.md 的要求运行前需满足DataHub 实例访问权限能够访问目标 DataHub 实例且拥有更新目标实体的权限涉及 Ownership、Domain、Tag、Glossary Terms 等 aspect 的写入。有效的认证配置为本次摄取运行配置合法的身份认证如 Personal Access Token、用户名密码等具体取决于部署环境。目标实体已存在每个配置的 apply 操作所指向的目标实体dataset、container 等必须已存在于 DataHub 中因为该模块只做更新、不做创建或发现。三、最小可用 Recipe 与四类 Apply 配置官方示例 datahub-apply_recipe.yml 给出了最小配置骨架source: type: datahub-apply config: owner_apply: - owner_urn: urn:li:corpuser:datahub assets: - urn:li:dataset:(urn:li:dataPlatform:hive,SampleHiveDataset,PROD) sink: # sink configssink部分通常配置为 DataHub REST/GraphQL sink例如type: datahub-rest并附带 server 地址与 token用于把生成的 MCP 提交回实例。在源码 datahub_apply.py 中DataHubApplyConfig定义了四个可选的顶层列表分别对应四类策管操作配置键元素配置类元素字段作用domain_applyDomainApplyConfigdomain_urn、assets将域domain应用到资产tag_applyTagApplyConfigtag_urn、assets将标签tag应用到资产term_applyTermApplyConfigterm_urn、assets将术语表术语term应用到资产owner_applyOwnerApplyConfigowner_urn、assets将所有者owner应用到资产每个子配置均由两个字段构成type_urn要应用的 URN。例如owner_urn: urn:li:corpuser:datahub用户实体、tag_urn: urn:li:tag:pii、term_urn: urn:li:glossaryTerm:...、domain_urn: urn:li:domain:...。从字段定义看它没有默认值之外的约束但必须是 DataHub 中已存在的实体 URN。assets目标资产列表List[str]默认空列表。字段注释明确指出当前仅支持 Container 与 Dataset 两类实体且应用是层次化hierarchically的——当目标是 Container 时会递归作用于其下的所有 Dataset 与子 Container。四个列表均可独立配置、可同时出现DataHubApplySource.get_workunits_internal会依次产出 domain、tag、term、owner 四类更新见 datahub_apply.py。一个同时覆盖四类操作的完整示例source: type: datahub-apply config: domain_apply: - domain_urn: urn:li:domain:finance assets: - urn:li:container:finances tag_apply: - tag_urn: urn:li:tag:pii assets: - urn:li:container:finances - urn:li:dataset:(urn:li:dataPlatform:hive,SomeNonContainerDataset,PROD) term_apply: - term_urn: urn:li:glossaryTerm:account assets: - urn:li:container:finances owner_apply: - owner_urn: urn:li:corpuser:datahub assets: - urn:li:dataset:(urn:li:dataPlatform:hive,SampleHiveDataset,PROD)四、底层原理从配置到 MCP 的调用链4.1 核心函数apply_association_to_container四类操作的底层都汇聚到同一个核心函数apply_association_to_container(container_urn, association_urn, association_type, emit, graph)见 datahub_apply.py。其处理流程为收集目标 URN 列表先把配置里给定的资产 URN 本身放入列表再调用graph.get_urns_by_filter(containercontainer_urn, batch_size1000, entity_types[dataset, container])找出该 Container 下所有 Dataset 与 Container 子实体。get_urns_by_filter的 container 过滤是递归的会包含子 Container 下的实体但需要实体具备 browsePathV2 aspectDataHub 0.10.4详见 client.py。构建 Patch对每个 URN 使用DatasetPatchBuilder构建增量补丁tagbuilder.add_tag(TagAssociationClass(tag_urn))termbuilder.add_term(GlossaryTermAssociationClass(term_urn))ownerbuilder.add_owner(OwnerClass(ownerowner_urn, typeOwnershipTypeClass.TECHNICAL_OWNER))注意所有者类型固定为TECHNICAL_OWNERdomain直接构造MetadataChangeProposalWrapper将DomainsClass(domains[domain_urn])作为 aspect。产出 MCPemitFalse时返回 MCP/MCPW 列表Source 摄取路径使用此模式交给 sink 统一发送emitTrue时通过进度条逐条调用graph.emit(mcp)直接提交CLI 路径使用此模式。4.2 Source 侧组装与托管摄取DataHubApplySource在初始化时通过ctx.require_graph()获得DataHubGraphdatahub_apply.py随后_handle_assets对每个资产调用上述核心函数、将返回的 proposal 逐个包装为MetadataWorkUnitMCPW 用as_workunit()原生 MCP 用MetadataWorkUnit.generate_workunit_id生成 ID最终流入标准摄取管线。该 Source 还通过get_allowed_workunit_processors限定仅允许AutoWorkunitsReporterProcessor保持行为简单可预期。这种Source 产 MCP、sink 负责提交的设计意味着datahub-apply 可以直接跑在 DataHub 的托管摄取Managed Ingestion平台上无需本地 CLI 环境这正是其作为CLI 的辅助封装的意义所在。4.3 命令行等价物datahub container系列命令与datahub-applySource 共用同一个核心函数的还有datahub containerCLI 子命令组见 container_cli.pydatahub container tag --container-urn URN --tag-urn URN # 给容器下所有 dataset 打标签 datahub container term --container-urn URN --term-urn URN # 给容器下所有 dataset 加术语 datahub container owner --container-urn URN --owner-urn URN # 给容器下所有 dataset 加 owner datahub container domain --container-urn URN --domain-urn URN # 给容器下所有 dataset 加 domain四个子命令均通过apply_association_to_container(container_urn, x_urn, type)直接执行此时emitTrue立即向默认 graph 提交。它们适合一次性、交互式的批量操作而 recipe datahub ingest -c recipe.yml的方式则更适合可复现、可纳入 CI 或托管摄取的场景。五、能力边界、限制与故障排查datahub-apply_post.md 明确了该模块的能力边界与运维要点5.1 Capabilities能力本模块聚焦于应用元数据更新而非从外部系统提取元数据支持的能力以上方Important Capabilities表格为准当前注册表中datahub-apply的 capabilities 列表为空参见 connector_registry/datahub.json实际能力体现在上述四类 aspect 的应用上。5.2 Limitations限制不做源元数据发现只应用配置中显式声明的更新错误的 URN 或选择器会导致部分更新或空操作no-op例如 asset 不存在、URN 拼写错误或目标实体类型不在 dataset/container 范围内时对应更新不会生效。5.3 Troubleshooting排查建议运行大规模 apply 任务前先校验目标 URN 与实体存在性确认 asset 与type_urn都是 DataHub 中真实存在的实体从小范围 recipe 起步先配置单个资产验证权限与预期更新行为再逐步扩大到容器级、批量级检查摄取日志关注 DataHub API 返回的校验或鉴权错误validation / authorization errors据此修正 URN 或补齐权限。六、实践建议层次化更新的成本意识当assets指向 Container 时get_urns_by_filter会递归展开其下所有 dataset/container每批 1000 个请确认容器规模符合预期避免意外的大范围更新。Owner 类型说明owner 应用固定使用TECHNICAL_OWNER类型如需其他所有权类型需要调整源码层面的OwnerClass.type或改用其他 API 路径。与托管摄取的结合由于DataHubApplySource是标准 Source 实现可直接在 DataHub 平台的托管摄取功能中注册该 recipe 并定时执行把批量策管变成可持续的自动化任务。幂等与部分失败建议对每个 apply 列表保持小粒度、可独立验证配合日志逐条确认提交结果降低部分更新带来的排障成本。通过本文介绍的配置方式与底层原理你可以用一份 YAML 文件完成对一批实体含容器递归展开的所有者、域、标签与术语表术语的批量应用并将这一能力沉淀为 DataHub 日常元数据治理工作流的一部分。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 DataHub datahub-apply 使用指南：以编程方式批量应用 Ownership、Domain、Tag 与 Glossary Term
DataHub datahub-apply 使用指南以编程方式批量应用 Ownership、Domain、Tag 与 Glossary Term【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahubdatahub-apply是 DataHub 元数据摄取Metadata Ingestion体系中的一类特殊 Source它不从外部系统发现元数据而是将配置文件中声明的元数据变更直接应用到 DataHub 中已存在的实体上非常适合批量所有权Ownership、域Domain、标签Tag和术语表术语Glossary Term的策管Curation任务。读完本文你将掌握datahub-apply的配置结构、四类应用操作owner/tag/term/domain的写法、其底层基于 Metadata Change ProposalMCP与 Patch 的更新机制以及配套的datahub containerCLI 命令和故障排查方法。一、模块定位从提取到应用的元数据工作流DataHub 的大多数摄取 Source如 Hive、Snowflake 等负责发现并提取外部系统的元数据而datahub-apply的角色完全相反——它只应用配置好的更新不做任何发现。官方文档将其定位为Thedatahub-applymodule applies metadata changes directly to existing DataHub entities. It is useful for programmatic curation tasks such as bulk ownership, domain, tag, and glossary-term updates.在 datahub-apply_pre.md 的基础上README.md 给出了直观的概念映射源侧概念Source ConceptDataHub 概念说明Apply 操作输入Metadata Change ProposalMCP更新输入驱动元数据更新而非元数据发现资产目标列表Dataset / Container及其他受支持实体目标在 recipe 配置中显式选定Ownership / domain / tag / term 赋值Ownership、Domain、GlobalTags、GlossaryTerms 等 aspect直接应用到现有 DataHub 实体从源码结构看datahub-apply在连接器注册表中被登记为platform_id: datahubapply、platform_name: DataHubApply其 classname 指向 datahub_apply.py 中的DataHubApplySource参见 connector_registry/datahub.json并在 setup.py 中注册了入口点datahub-apply。该 Source 的类注释明确写道它是 CLI 的辅助封装目的是让用户通过 Managed Ingestion托管摄取也能执行这类元数据应用任务。二、前置条件Prerequisites按 datahub-apply_pre.md 的要求运行前需满足DataHub 实例访问权限能够访问目标 DataHub 实例且拥有更新目标实体的权限涉及 Ownership、Domain、Tag、Glossary Terms 等 aspect 的写入。有效的认证配置为本次摄取运行配置合法的身份认证如 Personal Access Token、用户名密码等具体取决于部署环境。目标实体已存在每个配置的 apply 操作所指向的目标实体dataset、container 等必须已存在于 DataHub 中因为该模块只做更新、不做创建或发现。三、最小可用 Recipe 与四类 Apply 配置官方示例 datahub-apply_recipe.yml 给出了最小配置骨架source: type: datahub-apply config: owner_apply: - owner_urn: urn:li:corpuser:datahub assets: - urn:li:dataset:(urn:li:dataPlatform:hive,SampleHiveDataset,PROD) sink: # sink configssink部分通常配置为 DataHub REST/GraphQL sink例如type: datahub-rest并附带 server 地址与 token用于把生成的 MCP 提交回实例。在源码 datahub_apply.py 中DataHubApplyConfig定义了四个可选的顶层列表分别对应四类策管操作配置键元素配置类元素字段作用domain_applyDomainApplyConfigdomain_urn、assets将域domain应用到资产tag_applyTagApplyConfigtag_urn、assets将标签tag应用到资产term_applyTermApplyConfigterm_urn、assets将术语表术语term应用到资产owner_applyOwnerApplyConfigowner_urn、assets将所有者owner应用到资产每个子配置均由两个字段构成type_urn要应用的 URN。例如owner_urn: urn:li:corpuser:datahub用户实体、tag_urn: urn:li:tag:pii、term_urn: urn:li:glossaryTerm:...、domain_urn: urn:li:domain:...。从字段定义看它没有默认值之外的约束但必须是 DataHub 中已存在的实体 URN。assets目标资产列表List[str]默认空列表。字段注释明确指出当前仅支持 Container 与 Dataset 两类实体且应用是层次化hierarchically的——当目标是 Container 时会递归作用于其下的所有 Dataset 与子 Container。四个列表均可独立配置、可同时出现DataHubApplySource.get_workunits_internal会依次产出 domain、tag、term、owner 四类更新见 datahub_apply.py。一个同时覆盖四类操作的完整示例source: type: datahub-apply config: domain_apply: - domain_urn: urn:li:domain:finance assets: - urn:li:container:finances tag_apply: - tag_urn: urn:li:tag:pii assets: - urn:li:container:finances - urn:li:dataset:(urn:li:dataPlatform:hive,SomeNonContainerDataset,PROD) term_apply: - term_urn: urn:li:glossaryTerm:account assets: - urn:li:container:finances owner_apply: - owner_urn: urn:li:corpuser:datahub assets: - urn:li:dataset:(urn:li:dataPlatform:hive,SampleHiveDataset,PROD)四、底层原理从配置到 MCP 的调用链4.1 核心函数apply_association_to_container四类操作的底层都汇聚到同一个核心函数apply_association_to_container(container_urn, association_urn, association_type, emit, graph)见 datahub_apply.py。其处理流程为收集目标 URN 列表先把配置里给定的资产 URN 本身放入列表再调用graph.get_urns_by_filter(containercontainer_urn, batch_size1000, entity_types[dataset, container])找出该 Container 下所有 Dataset 与 Container 子实体。get_urns_by_filter的 container 过滤是递归的会包含子 Container 下的实体但需要实体具备 browsePathV2 aspectDataHub 0.10.4详见 client.py。构建 Patch对每个 URN 使用DatasetPatchBuilder构建增量补丁tagbuilder.add_tag(TagAssociationClass(tag_urn))termbuilder.add_term(GlossaryTermAssociationClass(term_urn))ownerbuilder.add_owner(OwnerClass(ownerowner_urn, typeOwnershipTypeClass.TECHNICAL_OWNER))注意所有者类型固定为TECHNICAL_OWNERdomain直接构造MetadataChangeProposalWrapper将DomainsClass(domains[domain_urn])作为 aspect。产出 MCPemitFalse时返回 MCP/MCPW 列表Source 摄取路径使用此模式交给 sink 统一发送emitTrue时通过进度条逐条调用graph.emit(mcp)直接提交CLI 路径使用此模式。4.2 Source 侧组装与托管摄取DataHubApplySource在初始化时通过ctx.require_graph()获得DataHubGraphdatahub_apply.py随后_handle_assets对每个资产调用上述核心函数、将返回的 proposal 逐个包装为MetadataWorkUnitMCPW 用as_workunit()原生 MCP 用MetadataWorkUnit.generate_workunit_id生成 ID最终流入标准摄取管线。该 Source 还通过get_allowed_workunit_processors限定仅允许AutoWorkunitsReporterProcessor保持行为简单可预期。这种Source 产 MCP、sink 负责提交的设计意味着datahub-apply 可以直接跑在 DataHub 的托管摄取Managed Ingestion平台上无需本地 CLI 环境这正是其作为CLI 的辅助封装的意义所在。4.3 命令行等价物datahub container系列命令与datahub-applySource 共用同一个核心函数的还有datahub containerCLI 子命令组见 container_cli.pydatahub container tag --container-urn URN --tag-urn URN # 给容器下所有 dataset 打标签 datahub container term --container-urn URN --term-urn URN # 给容器下所有 dataset 加术语 datahub container owner --container-urn URN --owner-urn URN # 给容器下所有 dataset 加 owner datahub container domain --container-urn URN --domain-urn URN # 给容器下所有 dataset 加 domain四个子命令均通过apply_association_to_container(container_urn, x_urn, type)直接执行此时emitTrue立即向默认 graph 提交。它们适合一次性、交互式的批量操作而 recipe datahub ingest -c recipe.yml的方式则更适合可复现、可纳入 CI 或托管摄取的场景。五、能力边界、限制与故障排查datahub-apply_post.md 明确了该模块的能力边界与运维要点5.1 Capabilities能力本模块聚焦于应用元数据更新而非从外部系统提取元数据支持的能力以上方Important Capabilities表格为准当前注册表中datahub-apply的 capabilities 列表为空参见 connector_registry/datahub.json实际能力体现在上述四类 aspect 的应用上。5.2 Limitations限制不做源元数据发现只应用配置中显式声明的更新错误的 URN 或选择器会导致部分更新或空操作no-op例如 asset 不存在、URN 拼写错误或目标实体类型不在 dataset/container 范围内时对应更新不会生效。5.3 Troubleshooting排查建议运行大规模 apply 任务前先校验目标 URN 与实体存在性确认 asset 与type_urn都是 DataHub 中真实存在的实体从小范围 recipe 起步先配置单个资产验证权限与预期更新行为再逐步扩大到容器级、批量级检查摄取日志关注 DataHub API 返回的校验或鉴权错误validation / authorization errors据此修正 URN 或补齐权限。六、实践建议层次化更新的成本意识当assets指向 Container 时get_urns_by_filter会递归展开其下所有 dataset/container每批 1000 个请确认容器规模符合预期避免意外的大范围更新。Owner 类型说明owner 应用固定使用TECHNICAL_OWNER类型如需其他所有权类型需要调整源码层面的OwnerClass.type或改用其他 API 路径。与托管摄取的结合由于DataHubApplySource是标准 Source 实现可直接在 DataHub 平台的托管摄取功能中注册该 recipe 并定时执行把批量策管变成可持续的自动化任务。幂等与部分失败建议对每个 apply 列表保持小粒度、可独立验证配合日志逐条确认提交结果降低部分更新带来的排障成本。通过本文介绍的配置方式与底层原理你可以用一份 YAML 文件完成对一批实体含容器递归展开的所有者、域、标签与术语表术语的批量应用并将这一能力沉淀为 DataHub 日常元数据治理工作流的一部分。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考