基于 Azure ADMicrosoft Entra ID的 DataHub 用户与用户组元数据摄取实战指南【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub导读本文围绕 DataHub 官方提供的azure-ad摄取模块完整讲解如何将 Microsoft Entra IDAzure AD中的用户、用户组与用户组成员关系同步到 DataHub 的 CorpUser、CorpGroup 与 GroupMembership 元数据模型。你将掌握从 Azure 门户应用注册授权、最小 Recipe 配置到用户名/组名的正则映射、用户状态映射、嵌套组展开、有状态删除检测等一系列可落地的实操方案并深入理解其底层调用 Microsoft Graph REST API 的实现原理。模块定位与能力总览azure-ad是 DataHub metadata-ingestion 中面向身份元数据的摄取模块用于生产环境的身份同步工作流。从仓库文档metadata-ingestion/docs/sources/azure-ad/README.md可以看到该模块覆盖的身份实体包括源端概念DataHub 概念说明所有权与协作主体CorpUser、CorpGroup由支持所有权与身份元数据的模块发出在源码实现中azure_ad.py该模块被标记为support_status(SupportStatus.GA)即正式生产可用并通过capability(SourceCapability.DELETION_DETECTION, Enabled by default via stateful ingestion)声明了删除检测能力——也就是说只要开启有状态摄取源端删除的用户/用户组可以在 DataHub 中被自动识别与清理。模块的整体摄取流程在get_workunits_internal中有明确注释azure_ad.py执行顺序为先摄取用户组CorpGroup再摄取用户组成员关系GroupMembership最后摄取用户CorpUser。前置准备在 Azure AD 门户创建 DataHub 应用并授权必需的应用权限按照官方文档azure-ad_post.md 与 azure-ad_pre.md你需要先在 Azure AD 门户中为 DataHub 注册一个应用App Registration并授予以下Application 类型权限用于读取组织内的用户与用户组Group.Read.All—— 读取全部用户组信息GroupMember.Read.All—— 读取用户组成员关系User.Read.All—— 读取全部用户信息在 Azure 门户中打开应用注册后进入API permissionsAPI 权限选项卡即可添加上述权限。下图为该模块文档中给出的权限配置示例界面获取配置所需的 Endpoint授予权限后你还需要在应用注册的Overview概述页中点击Endpoints终结点按钮查看后续 Recipe 配置所需的各个端点地址主要包括 OAuth2 token 端点与 Graph API 端点SSO 登录前提重要 Caveat需要特别注意的是从该连接器摄取进 DataHub 的用户只有在 DataHub 部署中配置了 OIDC SSO单点登录时才能实际登录 DataHub。也就是说azure-ad模块解决的是“身份元数据同步”而“登录认证”仍需依赖 DataHub 侧的 OIDC SSO 配置。最小可用配置文件Recipe模块的完整示例配置位于 azure-ad_recipe.yml核心结构如下source: type: azure-ad config: client_id: 00000000-0000-0000-0000-000000000000 tenant_id: 00000000-0000-0000-0000-000000000000 client_secret: xxxxx redirect: https://login.microsoftonline.com/common/oauth2/nativeclient authority: https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000 token_url: https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/oauth2/token graph_url: https://graph.microsoft.com/v1.0 ingest_users: True ingest_groups: True groups_pattern: allow: - .* users_pattern: allow: - .* sink: # sink configs其中client_id、tenant_id、client_secret均可从 Azure 门户的应用注册页获取对应 Application ID、Directory ID 与 Client secrettoken_url与authority中的00000000-0000-0000-0000-000000000000需替换为你的实际租户 ID。配置参数详解所有配置项都在源码的AzureADConfig类中定义azure_ad.py下表汇总了完整参数及其默认值配置项是否必填默认值说明client_id必填无应用注册中的 Application IDtenant_id必填无应用注册中的 Directory IDclient_secret必填无应用注册中的客户端机密配置类中声明为TransparentSecretStr以保护敏感值authority必填无MSAL 用于请求令牌的目录 URLv1.0 风格token_url必填无获取令牌的端点 URL该模块仅支持 v1.0 端点redirect可选https://login.microsoftonline.com/common/oauth2/nativeclient应用注册中的重定向 URIgraph_url可选https://graph.microsoft.com/v1.0Microsoft Graph API 端点azure_ad_response_to_username_attr可选userPrincipalName用于映射 DataHub 用户名的 Azure User Response 属性azure_ad_response_to_username_regex可选(.*)从上述属性中解析用户名的正则表达式azure_ad_response_to_groupname_attr可选displayName用于映射 DataHub 用户组名的 Azure Group Response 属性azure_ad_response_to_groupname_regex可选(.*)从上述属性中解析用户组名的正则表达式ingest_users可选True是否摄取用户ingest_groups可选True是否摄取用户组ingest_group_membership可选True是否摄取组成员关系若开启则ingest_groups必须为Trueingest_groups_users可选True仅在ingest_usersFalse且ingest_group_membershipTrue时生效开启后仅摄取所选用户组的成员用户users_pattern可选全部允许过滤摄取的用户的正则模式AllowDenyPatterngroups_pattern可选全部允许过滤摄取的组的正则模式AllowDenyPatternmask_group_id可选True是否对组的 WorkUnit ID 打码避免泄露敏感信息mask_user_id可选True是否对用户的 WorkUnit ID 打码stateful_ingestion可选无Azure AD 有状态摄取配置StatefulStaleMetadataRemovalConfig摄取原理OAuth2 客户端凭证流与 Graph API 调用链令牌获取模块初始化时会通过get_token()azure_ad.py向token_url发起 POST 请求携带grant_typeclient_credentials、client_id、client_secret、resourcehttps://graph.microsoft.com与scopehttps://graph.microsoft.com/.default换取access_token。若响应非 200会在日志中记录状态码与响应内容并在摄取报告中记录失败信息。Graph API 数据拉取与分页数据拉取统一通过_get_azure_ad_data()azure_ad.py完成请求头携带Authorization: Bearer token按需请求以下三类资源/users—— 拉取用户列表/groups—— 拉取用户组列表/groups/{group_id}/members—— 拉取指定用户组成员。每次响应会从odata.nextLink读取下一页地址并循环拉取直到没有下一页从而实现大租户下海量用户/用户组的分页遍历。请求使用requests.Session挂载了重试适配器azure_ad.py对429, 500, 502, 503, 504状态码最多重试 5 次、退避因子为 1增强了生产环境的健壮性。摄取 DataHub 用户CorpUser用户名的映射规则用户名是 DataHub 中用户的唯一标识。根据文档说明该连接器默认使用 Azure AD User Response 中的userPrincipalName字段作为用户名来源它是 Azure AD 用户的唯一标识符。如果你希望自定义映射方式可以通过以下两个配置项实现azure_ad.pyazure_ad_response_to_username_attr指定从 Azure User Response 中取哪个属性作为映射输入azure_ad_response_to_username_regex用正则从该属性值中解析出最终的 DataHub 用户名。最终用户名经make_user_urn生成形如urn:li:corpuser:username的 CorpUser URNazure_ad.py。值得注意的是用户过滤users_pattern是作用在生成的 CorpUser URN 上的azure_ad.py。用户基础信息与 CorpUserInfo 方面连接器会从 Azure User Response 中提取以下基础信息映射到 DataHub 的CorpUserInfo方面display name显示名first name名last name姓email邮箱title职位country国家在源码实现中azure_ad.pydisplayName、givenName、surname、mail、jobTitle被分别映射到displayName、firstName、lastName、email、titlefullName由givenName surname拼接。一个值得留意的实现细节是当前源码中countryCode字段实际取自 Azure Response 的mobilePhone字段与你预期中的“国家/地区”语义可能不一致如需精确的国家信息建议以实际 Graph API 返回字段为准并在后续版本中跟进。用户状态映射corpUserInfo.active 与 corpUserStatus该连接器会为每个用户同时发出corpUserInfo.active与corpUserStatus两方面元数据。状态判定逻辑实现在 corp_user_status.py 的derive_corp_user_status_from_azure_ad中Azure ADaccountEnabledDataHubcorpUserStatuscorpUserInfo.activefalseSUSPENDEDfalsetrue或缺失ACTIVEtrue每个用户还会附带Origin方面OriginTypeClass.EXTERNALAZURE_AD与StatusClass(removedFalse)分别标记其外部来源与未删除状态azure_ad.py。摄取 DataHub 用户组CorpGroup用户组名的映射规则用户组名是 DataHub 中组的唯一标识。根据文档说明连接器使用 Azure Group Response 的name属性提取组名默认情况下URL 编码后的完整组名作为唯一标识CorpGroupKey原始name属性值则作为显示名展示在 DataHub UI 中。从源码看azure_ad.py组名取值属性默认为displayName同样可通过两个配置项自定义映射azure_ad_response_to_groupname_attr指定取哪个 Azure Group Response 属性azure_ad_response_to_groupname_regex用正则解析最终的组名。生成的组 URN 为urn:li:corpGroup:url_encoded_group_nameazure_ad.pyURL 编码由urllib.parse.quote完成用于处理组名中的特殊字符。组基础信息与 CorpGroupInfo 方面连接器从 Azure AD Group Response 中提取以下字段映射到 DataHub 的CorpGroupInfo方面name名称description描述源码实现azure_ad.py同时会映射mail作为组的邮箱并初始化空的members、groups、admins列表。摄取用户组成员关系GroupMembership该连接器会额外拉取 Azure AD 中存储的 User 与 Group 之间的边即通过/groups/{group_id}/members获取组成员并将其映射为用户CorpUser关联的GroupMembership方面azure_ad.py。源码中对成员对象按odata.type分情况处理azure_ad.py#microsoft.graph.user将用户加入其所属组写入该用户 URN 对应的GroupMembership#microsoft.graph.group递归处理嵌套组——由于DataHub 不支持嵌套组嵌套组内的成员会被摊平explode到其祖先组中而不是挂到嵌套组上其他类型记录 warning 后静默跳过。测试用例 test_azure_ad.py 中的test_azure_ad_source_nested_groups专门验证了嵌套组场景并对比 golden 文件azure_ad_mces_golden_nested_groups.json校验输出结果。过滤、正则映射与错误语义模块提供了两层过滤能力映射正则azure_ad_response_to_username_regex/azure_ad_response_to_groupname_regex决定“哪些源数据能成功映射为 DataHub 标识”模式过滤users_pattern/groups_pattern决定“映射成功后哪些对象真正进入摄取结果”。这两层的错误语义在源码中有明确区分并被测试用例覆盖test_azure_ad.py正则不匹配 → 静默过滤test_azure_ad_group_regex_mismatch_is_filtered_not_failed验证了当组名不匹配azure_ad_response_to_groupname_regex例如设置为^.*_(OWNER|MEMBER)$时这些组会被记入report.filtered而非失败运行不会因此标记为失败属性缺失 → 明确失败test_azure_ad_group_missing_attr_is_failure验证了当azure_ad_response_to_groupname_attr指向的键在响应中不存在时会被视为配置错误并记录为report.failures。仅摄取部分用户的组合用法ingest_groups_users参数支持一种常见场景当ingest_usersFalse且ingest_group_membershipTrue时只有属于被选中用户组的用户才会被摄取azure_ad.py实现“按组圈定用户”的精细化同步。有状态摄取与删除检测azure-ad模块基于StatefulIngestionSourceBase实现有状态摄取并默认启用删除检测能力azure_ad.py。启用方式是在 Recipe 中配置stateful_ingestionsource: type: azure-ad config: ... stateful_ingestion: enabled: True state_provider: type: datahub config: datahub_api: server: http://localhost:8080启用后每次摄取都会把当前已同步的 CorpUser/CorpGroup URN 集合写入状态检查点下一次运行时通过StaleEntityRemovalHandler对比前后状态识别出源端已删除的实体并生成删除 WorkUnit。集成测试 test_azure_ad_stateful_ingestion 使用azure_ad_groups_deleted_groupDisplayName3.json模拟“组被删除”的场景验证第二次运行能够识别出urn:li:corpGroup:groupDisplayName3的差异并触发删除。局限性与故障排查局限性模块行为受源端 API、权限与平台暴露的元数据约束以下场景需要特别留意不支持嵌套组Azure AD 支持嵌套组但 DataHub 不支持连接器会将其摊平到祖先组而非保留嵌套结构不支持组内非用户/非组对象组成员中的其他对象类型如设备、服务主体会被跳过登录依赖 SSO摄取的“用户”仅是元数据用户实际登录 DataHub 仍需部署 OIDC SSO仅支持 v1.0 token 端点token_url必须使用 Azure AD v1.0 风格的 OAuth2 token 端点。故障排查如果摄取失败建议按以下顺序排查azure-ad_post.md校验凭据确认client_id、tenant_id、client_secret正确且未过期校验权限确认应用已授予Group.Read.All、GroupMember.Read.All、User.Read.All三项 Application 权限校验连通性确认执行摄取的环境能访问login.microsoftonline.com与graph.microsoft.com校验范围过滤检查users_pattern、groups_pattern与映射正则是否过严导致数据被静默过滤查看摄取日志日志中会输出 token 获取失败、Graph API 请求失败含 URL、状态码与响应内容等源端特定错误结合report.failures与report.filtered区分“配置错误”与“正常过滤”。仓库内的深入阅读入口如需进一步研究实现细节推荐阅读以下仓库文件连接器完整实现metadata-ingestion/src/datahub/ingestion/source/identity/azure_ad.py用户状态推导与双写逻辑metadata-ingestion/src/datahub/ingestion/source/identity/corp_user_status.py集成测试与 golden 数据metadata-ingestion/tests/integration/azure_ad/test_azure_ad.py模块前置说明与能力文档metadata-ingestion/docs/sources/azure-ad/azure-ad_pre.md、metadata-ingestion/docs/sources/azure-ad/azure-ad_post.md模块概览与概念映射metadata-ingestion/docs/sources/azure-ad/README.md【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 基于 Azure AD（Microsoft Entra ID）的 DataHub 用户与用户组元数据摄取实战指南
基于 Azure ADMicrosoft Entra ID的 DataHub 用户与用户组元数据摄取实战指南【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub导读本文围绕 DataHub 官方提供的azure-ad摄取模块完整讲解如何将 Microsoft Entra IDAzure AD中的用户、用户组与用户组成员关系同步到 DataHub 的 CorpUser、CorpGroup 与 GroupMembership 元数据模型。你将掌握从 Azure 门户应用注册授权、最小 Recipe 配置到用户名/组名的正则映射、用户状态映射、嵌套组展开、有状态删除检测等一系列可落地的实操方案并深入理解其底层调用 Microsoft Graph REST API 的实现原理。模块定位与能力总览azure-ad是 DataHub metadata-ingestion 中面向身份元数据的摄取模块用于生产环境的身份同步工作流。从仓库文档metadata-ingestion/docs/sources/azure-ad/README.md可以看到该模块覆盖的身份实体包括源端概念DataHub 概念说明所有权与协作主体CorpUser、CorpGroup由支持所有权与身份元数据的模块发出在源码实现中azure_ad.py该模块被标记为support_status(SupportStatus.GA)即正式生产可用并通过capability(SourceCapability.DELETION_DETECTION, Enabled by default via stateful ingestion)声明了删除检测能力——也就是说只要开启有状态摄取源端删除的用户/用户组可以在 DataHub 中被自动识别与清理。模块的整体摄取流程在get_workunits_internal中有明确注释azure_ad.py执行顺序为先摄取用户组CorpGroup再摄取用户组成员关系GroupMembership最后摄取用户CorpUser。前置准备在 Azure AD 门户创建 DataHub 应用并授权必需的应用权限按照官方文档azure-ad_post.md 与 azure-ad_pre.md你需要先在 Azure AD 门户中为 DataHub 注册一个应用App Registration并授予以下Application 类型权限用于读取组织内的用户与用户组Group.Read.All—— 读取全部用户组信息GroupMember.Read.All—— 读取用户组成员关系User.Read.All—— 读取全部用户信息在 Azure 门户中打开应用注册后进入API permissionsAPI 权限选项卡即可添加上述权限。下图为该模块文档中给出的权限配置示例界面获取配置所需的 Endpoint授予权限后你还需要在应用注册的Overview概述页中点击Endpoints终结点按钮查看后续 Recipe 配置所需的各个端点地址主要包括 OAuth2 token 端点与 Graph API 端点SSO 登录前提重要 Caveat需要特别注意的是从该连接器摄取进 DataHub 的用户只有在 DataHub 部署中配置了 OIDC SSO单点登录时才能实际登录 DataHub。也就是说azure-ad模块解决的是“身份元数据同步”而“登录认证”仍需依赖 DataHub 侧的 OIDC SSO 配置。最小可用配置文件Recipe模块的完整示例配置位于 azure-ad_recipe.yml核心结构如下source: type: azure-ad config: client_id: 00000000-0000-0000-0000-000000000000 tenant_id: 00000000-0000-0000-0000-000000000000 client_secret: xxxxx redirect: https://login.microsoftonline.com/common/oauth2/nativeclient authority: https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000 token_url: https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/oauth2/token graph_url: https://graph.microsoft.com/v1.0 ingest_users: True ingest_groups: True groups_pattern: allow: - .* users_pattern: allow: - .* sink: # sink configs其中client_id、tenant_id、client_secret均可从 Azure 门户的应用注册页获取对应 Application ID、Directory ID 与 Client secrettoken_url与authority中的00000000-0000-0000-0000-000000000000需替换为你的实际租户 ID。配置参数详解所有配置项都在源码的AzureADConfig类中定义azure_ad.py下表汇总了完整参数及其默认值配置项是否必填默认值说明client_id必填无应用注册中的 Application IDtenant_id必填无应用注册中的 Directory IDclient_secret必填无应用注册中的客户端机密配置类中声明为TransparentSecretStr以保护敏感值authority必填无MSAL 用于请求令牌的目录 URLv1.0 风格token_url必填无获取令牌的端点 URL该模块仅支持 v1.0 端点redirect可选https://login.microsoftonline.com/common/oauth2/nativeclient应用注册中的重定向 URIgraph_url可选https://graph.microsoft.com/v1.0Microsoft Graph API 端点azure_ad_response_to_username_attr可选userPrincipalName用于映射 DataHub 用户名的 Azure User Response 属性azure_ad_response_to_username_regex可选(.*)从上述属性中解析用户名的正则表达式azure_ad_response_to_groupname_attr可选displayName用于映射 DataHub 用户组名的 Azure Group Response 属性azure_ad_response_to_groupname_regex可选(.*)从上述属性中解析用户组名的正则表达式ingest_users可选True是否摄取用户ingest_groups可选True是否摄取用户组ingest_group_membership可选True是否摄取组成员关系若开启则ingest_groups必须为Trueingest_groups_users可选True仅在ingest_usersFalse且ingest_group_membershipTrue时生效开启后仅摄取所选用户组的成员用户users_pattern可选全部允许过滤摄取的用户的正则模式AllowDenyPatterngroups_pattern可选全部允许过滤摄取的组的正则模式AllowDenyPatternmask_group_id可选True是否对组的 WorkUnit ID 打码避免泄露敏感信息mask_user_id可选True是否对用户的 WorkUnit ID 打码stateful_ingestion可选无Azure AD 有状态摄取配置StatefulStaleMetadataRemovalConfig摄取原理OAuth2 客户端凭证流与 Graph API 调用链令牌获取模块初始化时会通过get_token()azure_ad.py向token_url发起 POST 请求携带grant_typeclient_credentials、client_id、client_secret、resourcehttps://graph.microsoft.com与scopehttps://graph.microsoft.com/.default换取access_token。若响应非 200会在日志中记录状态码与响应内容并在摄取报告中记录失败信息。Graph API 数据拉取与分页数据拉取统一通过_get_azure_ad_data()azure_ad.py完成请求头携带Authorization: Bearer token按需请求以下三类资源/users—— 拉取用户列表/groups—— 拉取用户组列表/groups/{group_id}/members—— 拉取指定用户组成员。每次响应会从odata.nextLink读取下一页地址并循环拉取直到没有下一页从而实现大租户下海量用户/用户组的分页遍历。请求使用requests.Session挂载了重试适配器azure_ad.py对429, 500, 502, 503, 504状态码最多重试 5 次、退避因子为 1增强了生产环境的健壮性。摄取 DataHub 用户CorpUser用户名的映射规则用户名是 DataHub 中用户的唯一标识。根据文档说明该连接器默认使用 Azure AD User Response 中的userPrincipalName字段作为用户名来源它是 Azure AD 用户的唯一标识符。如果你希望自定义映射方式可以通过以下两个配置项实现azure_ad.pyazure_ad_response_to_username_attr指定从 Azure User Response 中取哪个属性作为映射输入azure_ad_response_to_username_regex用正则从该属性值中解析出最终的 DataHub 用户名。最终用户名经make_user_urn生成形如urn:li:corpuser:username的 CorpUser URNazure_ad.py。值得注意的是用户过滤users_pattern是作用在生成的 CorpUser URN 上的azure_ad.py。用户基础信息与 CorpUserInfo 方面连接器会从 Azure User Response 中提取以下基础信息映射到 DataHub 的CorpUserInfo方面display name显示名first name名last name姓email邮箱title职位country国家在源码实现中azure_ad.pydisplayName、givenName、surname、mail、jobTitle被分别映射到displayName、firstName、lastName、email、titlefullName由givenName surname拼接。一个值得留意的实现细节是当前源码中countryCode字段实际取自 Azure Response 的mobilePhone字段与你预期中的“国家/地区”语义可能不一致如需精确的国家信息建议以实际 Graph API 返回字段为准并在后续版本中跟进。用户状态映射corpUserInfo.active 与 corpUserStatus该连接器会为每个用户同时发出corpUserInfo.active与corpUserStatus两方面元数据。状态判定逻辑实现在 corp_user_status.py 的derive_corp_user_status_from_azure_ad中Azure ADaccountEnabledDataHubcorpUserStatuscorpUserInfo.activefalseSUSPENDEDfalsetrue或缺失ACTIVEtrue每个用户还会附带Origin方面OriginTypeClass.EXTERNALAZURE_AD与StatusClass(removedFalse)分别标记其外部来源与未删除状态azure_ad.py。摄取 DataHub 用户组CorpGroup用户组名的映射规则用户组名是 DataHub 中组的唯一标识。根据文档说明连接器使用 Azure Group Response 的name属性提取组名默认情况下URL 编码后的完整组名作为唯一标识CorpGroupKey原始name属性值则作为显示名展示在 DataHub UI 中。从源码看azure_ad.py组名取值属性默认为displayName同样可通过两个配置项自定义映射azure_ad_response_to_groupname_attr指定取哪个 Azure Group Response 属性azure_ad_response_to_groupname_regex用正则解析最终的组名。生成的组 URN 为urn:li:corpGroup:url_encoded_group_nameazure_ad.pyURL 编码由urllib.parse.quote完成用于处理组名中的特殊字符。组基础信息与 CorpGroupInfo 方面连接器从 Azure AD Group Response 中提取以下字段映射到 DataHub 的CorpGroupInfo方面name名称description描述源码实现azure_ad.py同时会映射mail作为组的邮箱并初始化空的members、groups、admins列表。摄取用户组成员关系GroupMembership该连接器会额外拉取 Azure AD 中存储的 User 与 Group 之间的边即通过/groups/{group_id}/members获取组成员并将其映射为用户CorpUser关联的GroupMembership方面azure_ad.py。源码中对成员对象按odata.type分情况处理azure_ad.py#microsoft.graph.user将用户加入其所属组写入该用户 URN 对应的GroupMembership#microsoft.graph.group递归处理嵌套组——由于DataHub 不支持嵌套组嵌套组内的成员会被摊平explode到其祖先组中而不是挂到嵌套组上其他类型记录 warning 后静默跳过。测试用例 test_azure_ad.py 中的test_azure_ad_source_nested_groups专门验证了嵌套组场景并对比 golden 文件azure_ad_mces_golden_nested_groups.json校验输出结果。过滤、正则映射与错误语义模块提供了两层过滤能力映射正则azure_ad_response_to_username_regex/azure_ad_response_to_groupname_regex决定“哪些源数据能成功映射为 DataHub 标识”模式过滤users_pattern/groups_pattern决定“映射成功后哪些对象真正进入摄取结果”。这两层的错误语义在源码中有明确区分并被测试用例覆盖test_azure_ad.py正则不匹配 → 静默过滤test_azure_ad_group_regex_mismatch_is_filtered_not_failed验证了当组名不匹配azure_ad_response_to_groupname_regex例如设置为^.*_(OWNER|MEMBER)$时这些组会被记入report.filtered而非失败运行不会因此标记为失败属性缺失 → 明确失败test_azure_ad_group_missing_attr_is_failure验证了当azure_ad_response_to_groupname_attr指向的键在响应中不存在时会被视为配置错误并记录为report.failures。仅摄取部分用户的组合用法ingest_groups_users参数支持一种常见场景当ingest_usersFalse且ingest_group_membershipTrue时只有属于被选中用户组的用户才会被摄取azure_ad.py实现“按组圈定用户”的精细化同步。有状态摄取与删除检测azure-ad模块基于StatefulIngestionSourceBase实现有状态摄取并默认启用删除检测能力azure_ad.py。启用方式是在 Recipe 中配置stateful_ingestionsource: type: azure-ad config: ... stateful_ingestion: enabled: True state_provider: type: datahub config: datahub_api: server: http://localhost:8080启用后每次摄取都会把当前已同步的 CorpUser/CorpGroup URN 集合写入状态检查点下一次运行时通过StaleEntityRemovalHandler对比前后状态识别出源端已删除的实体并生成删除 WorkUnit。集成测试 test_azure_ad_stateful_ingestion 使用azure_ad_groups_deleted_groupDisplayName3.json模拟“组被删除”的场景验证第二次运行能够识别出urn:li:corpGroup:groupDisplayName3的差异并触发删除。局限性与故障排查局限性模块行为受源端 API、权限与平台暴露的元数据约束以下场景需要特别留意不支持嵌套组Azure AD 支持嵌套组但 DataHub 不支持连接器会将其摊平到祖先组而非保留嵌套结构不支持组内非用户/非组对象组成员中的其他对象类型如设备、服务主体会被跳过登录依赖 SSO摄取的“用户”仅是元数据用户实际登录 DataHub 仍需部署 OIDC SSO仅支持 v1.0 token 端点token_url必须使用 Azure AD v1.0 风格的 OAuth2 token 端点。故障排查如果摄取失败建议按以下顺序排查azure-ad_post.md校验凭据确认client_id、tenant_id、client_secret正确且未过期校验权限确认应用已授予Group.Read.All、GroupMember.Read.All、User.Read.All三项 Application 权限校验连通性确认执行摄取的环境能访问login.microsoftonline.com与graph.microsoft.com校验范围过滤检查users_pattern、groups_pattern与映射正则是否过严导致数据被静默过滤查看摄取日志日志中会输出 token 获取失败、Graph API 请求失败含 URL、状态码与响应内容等源端特定错误结合report.failures与report.filtered区分“配置错误”与“正常过滤”。仓库内的深入阅读入口如需进一步研究实现细节推荐阅读以下仓库文件连接器完整实现metadata-ingestion/src/datahub/ingestion/source/identity/azure_ad.py用户状态推导与双写逻辑metadata-ingestion/src/datahub/ingestion/source/identity/corp_user_status.py集成测试与 golden 数据metadata-ingestion/tests/integration/azure_ad/test_azure_ad.py模块前置说明与能力文档metadata-ingestion/docs/sources/azure-ad/azure-ad_pre.md、metadata-ingestion/docs/sources/azure-ad/azure-ad_post.md模块概览与概念映射metadata-ingestion/docs/sources/azure-ad/README.md【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考