企业官网建设流程全解析

DataHub 接入 Microsoft Power BI：概念映射、Entra 权限配置与 M-Query 血缘解析实战指南

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

本指南基于 DataHub 仓库中的 Power BI 元数据接入文档与powerbi源插件源码，完整讲解如何将 Microsoft Power BI 的仪表盘、报表、数据集、工作区等 BI 资产及其表级血缘、数据画像（Profiling）、所有权与标签（Endorsement）同步到 DataHub。读者将掌握 Entra 服务主体权限的两种授予路径（公共 API 与 Admin API）、可运行的完整 recipe 配置，以及 Power BI M-Query 血缘解析的底层原理与常见高级场景（Oracle TNS、BigQuery EXTERNAL_QUERY 联邦、Athena 联邦覆盖）的配置方法。

概览：DataHub 的 Power BI 集成覆盖哪些能力

Microsoft Power BI 是微软的商业智能与分析平台。DataHub 提供的powerbi源模块将 Power BI 中的 BI 实体接入 DataHub，覆盖以下能力（见 powerbi_pre.md）：

• Power BI 仪表盘（Dashboard）、磁贴（Tile）与数据集（Dataset）；
• 仪表盘与磁贴的名称、描述与 URL；
• 仪表盘的所有者；
• 表级与列级血缘（Table- & Column-level Lineage）、数据画像（Profiling）、所有权、标签，以及基于状态的有状态删除检测（stateful deletion detection）；
• 数据集表 schema（列与度量）、报表与报表页面、App 等（依赖 Admin API 权限）。

从源码结构看，该模块位于 metadata-ingestion/src/datahub/ingestion/source/powerbi/，主要由三部分构成：

• config.py：PowerBiDashboardSourceConfig定义了全部可配置项（租户、客户端凭据、过滤模式、血缘开关、画像开关等），并用 pydantic 做了大量交叉校验；
• powerbi.py：负责把 Power BI 对象转换为 DataHub 的 Metadata Change Proposal（MCP）与 Metadata Work Unit；
• rest_api_wrapper/ 与 m_query/：分别封装 Power BI REST API 调用与 M-Query / Native SQL 血缘解析。

概念映射：Power BI 对象到 DataHub 实体

理解该连接器最快捷的方式是掌握官方文档给出的概念映射表（见 README.md）：

两条补充规则：

• 如果Tile由报表（Report）创建，则Chart.externalUrl会被设置为对应Report.webUrl；
• 对于 Power BI 分页报表（PaginatedReport），Page不可用（分页报表不以页面为单位组织可视化）。

这份映射在源码中可以得到印证：powerbi.py 的report_to_dashboard把 Report 转为 DataHubDashboard（dashboardTool为powerbi，dashboardId形如powerbi.linkedin.com/dashboards/{report.id}）；pages_to_chart 把报表页面转为Chart并为其设置 SubTypePOWERBI_PAGE；而工作区与数据集在启用extract_workspaces_to_containers/extract_datasets_to_containers后会被映射为 DataHubContainer。值得注意：Power BI 的Report与Page在 DataHub 中被表达为Dashboard/Chart层级，这与 Tableau、Looker 等 BI 源的建模思路一致，便于统一在 DataHub 的 BI 资产视图中浏览。

前置条件：Entra 服务主体与两类 API 权限

执行该源需要先创建 Microsoft Entra（原 Azure AD）应用程序服务主体，并在 Power BI 中为其授予权限。Power BI 的 REST API 分为两套权限结构不同的 API（详见 powerbi_pre.md）：

• 公共 API（Public APIs）：面向开发者，用于与租户内的特定资源交互，要求 Entra 应用被显式授予对各个工作区的访问权限；
• Admin API（Admin APIs）：面向管理员，可站在租户全局视角返回所有 Power BI 资源的元数据。

官方推荐的做法是两者都配置：把 Entra 应用加入要接入的工作区，同时授予公共 API 与 Admin API 权限，从而让 ingestion 提取到最完整的元数据。

授予公共 API 访问权限

1. 在 Power BI / Fabric 中进入Settings->Admin portal->Tenant settings；
2. 在Developer Settings下启用Service principals can call Fabric Public APIs（Power BI 旧版本中名为Allow service principals to use Power BI APIs），并将应用的 Entra 组加入Specific security groups；
3. 将 Entra 应用作为成员加入要接入的工作区——大多数场景下Viewer角色即可，但若要启用数据集画像（Profiling），需要Contributor角色。

完成上述配置后，该源可以接入以下元数据：仪表盘（Dashboards）、仪表盘磁贴（Dashboard Tiles）、报表（Reports）、报表页面（Report Pages）。

如果不希望把 Entra 应用加入工作区，可设置admin_apis_only: true仅使用 Admin API。但需注意该模式的三个限制（源码中 config.py 亦明确注释）：

• 报表页面（Report Pages）不会被接入，因为页面接口在 Power BI Admin API 中不可用；
• Power BI Parameters 在处理 M-Query 血缘时不会被解析为实际值；
• 数据集画像不可用，因为它依赖非 Admin 的工作区 API。

授予 Admin API 访问权限

1. 同样在Admin portal->Tenant settings中，将应用的 Entra 组加入Specific security groups；
2. 为以下三项开关逐个启用并添加安全组：
   • Service principals can access read-only admin APIs
   • Enhance admin APIs responses with detailed metadata
   • Enhance admin APIs responses with DAX and mashup expressions

获得 Admin API 权限后，该源可接入：血缘（Lineage）、数据集（Datasets）、标签化认可（Endorsement as tag）、仪表盘、仪表盘磁贴、报表、报表页面、App。

完整 recipe 与核心配置详解

仓库提供了开箱即用的示例 recipe：powerbi_recipe.yml。以下为完整配置（凭据为占位示例）：

source: type: "powerbi" config: # Power BI 租户标识 tenant_id: a949d688-67c0-4bf1-a344-e939411c6c0a # Microsoft Entra 应用标识 client_id: 12345678-abcd-abcd-abcd-123456789012 # Microsoft Entra 应用客户端密钥 client_secret: Abc12d~efg3hijkl_45Abcdefg67aBcdef89 # 仅接入以下 Power BI 工作区 workspace_name_pattern: allow: - MyWorkspace deny: - PrivateWorkspace # 是否接入仪表盘的所有权信息 extract_ownership: true # 是否把工作区映射为 DataHub 容器 extract_workspaces_to_containers: true # 是否把 Endorsement 转为标签。注意：可能覆盖已接入实体的既有标签！ extract_endorsements_to_tags: false # 可选：上游表 platform-instance 映射（仅在有此需求时配置） # key 为 PowerBI 数据源 server，即 host[:port]；:port 仅在数据源运行在非标准端口时需要。 # 对 Google BigQuery，key 为项目名；对 Fabric OneLake（DirectLake 血缘），key 为 PowerBI 工作区 ID。 # platform_instance 通常代表 Fabric 租户标识，与 OneLake 连接器按租户分组工作区的方式一致。 server_to_platform_instance: ap-south-1.snowflakecomputing.com: platform_instance: operational_instance env: DEV oracle-server:1920: platform_instance: high_performance_production_unit env: PROD big-query-sales-project: platform_instance: sn-2 env: QA # Fabric OneLake：工作区 ID -> (platform_instance, env) ff23fbe3-7418-42f8-a675-9f10eb2b78cb: # PowerBI workspace ID platform_instance: contoso-tenant # Fabric 租户 / platform instance env: PROD # 需要 Admin API；仅接入自该时间起被修改过的工作区 modified_since: "2023-02-10T00:00:00.0000000Z" ownership: # 是否把 Power BI 用户创建为 DataHub corpuser；false 仍会提取工作区/仪表盘所有权 create_corp_user: false # 用邮箱构建用户 URN 而非 Power BI 用户标识 use_powerbi_email: true # 去除邮箱后缀（如 @acryl.io） remove_email_suffix: true # 仅接入具备指定权限的用户 owner_criteria: ["ReadWriteReshareExplore","Owner","Admin"] # 将 Power BI 表（DataHub dataset）归入单个 Power BI 数据集（DataHub 容器） extract_datasets_to_containers: true # 仅接入被认可（如 "Certified"）的数据集 filter_dataset_endorsements: allow: - Certified # 是否接入 Power BI 仪表盘与磁贴 extract_dashboards: false # 是否接入 Power BI 数据集表 schema extract_dataset_schema: true # 是否启用数据集画像 profiling: enabled: false # 限定画像资源范围的正则；匹配格式为 workspace_name.dataset_name.table_name profile_pattern: deny: - .* sink: # sink 配置

关键配置参数速查

结合 config.py 中PowerBiDashboardSourceConfig的定义，以下参数对实战最要紧：

用户与所有权处理：软引用模式与完整用户创建

Power BI 源提供两种所有权处理模式（详见 powerbi_post.md）。

软引用模式（推荐）

设置ownership.create_corp_user: false时：

• 仅把所有权信息提取为 URN 引用（soft references）；
• 不在 DataHub 中创建用户实体；
• 用户档案需来自身份提供方（LDAP/SCIM/Okta）。

这是推荐做法，可避免 Power BI 覆盖身份提供方维护的用户档案。

ownership: create_corp_user: false # 软引用模式（文档推荐）

需要说明：文档将软引用模式标注为“Default/推荐”，而仓库源码中该字段的 pydantic 默认值声明为true（见 config.py）。为避免歧义，建议在 recipe 中始终显式写出create_corp_user，不要依赖默认值。

完整用户创建模式（可选）

设置ownership.create_corp_user: true时：

• 使用 Power BI 提供的displayName与email创建用户实体；
• 这可能覆盖来自 LDAP/Okta/SCIM 的既有用户档案。

警告：仅当 Power BI 是用户信息的权威来源时才启用此模式。

ownership: create_corp_user: true # 创建用户实体

从源码看，to_datahub_users（powerbi.py）负责生成 corpuser 相关 MCP；并且在 to_datahub_work_units 中，用户 MCP 以is_primary_source=False单独处理，避免有状态接入把用户实体当作主数据源跟踪/软删除。

按访问权限过滤 Owner

owner_criteria用于限定哪些用户能成为 Owner：只有至少具备其中一个指定访问权限的用户才会被指派为 Owner。合法取值取决于资源（dataset、report、dashboard）的 Power BI 访问权限类型。若owner_criteria未设置或为空列表，则所有principalType: User的用户均符合条件。

ownership: owner_criteria: - ReadWriteReshareExplore - Owner - Admin

其余相关配置：use_powerbi_email决定用邮箱还是 Power BI 用户标识构建用户 URN；remove_email_suffix可去掉邮箱后缀（如@acryl.io）；dataset_configured_by_as_owner把数据集configuredBy作为数据集 owner。

Admin scan 与工作区列列举双通道

Power BI 接入对每个工作区使用两条元数据路径（见 powerbi_post.md）：

当回退被触发时，接入报告会为对应工作区记录一条Report Scan Fallback Active条目，便于把该工作区较慢的接入与缺失的扫描输出关联起来。源码中 powerbi_api.py 的fill_metadata_from_scan_result/fill_regular_metadata_detail分别实现这两条路径，create_scan_job/wait_for_scan_to_complete则封装了扫描任务的创建、轮询与结果获取（扫描结果按批次等待，超时由scan_timeout控制）。

表级血缘：M-Query 解析与平台支持

该源为 Power BI 数据集中的表提取表级血缘。例如数据集SALES_REPORT以 PostgreSQL 为数据源，其中的表SALES_ANALYSIS由 PostgreSQL 的SALES_ANALYSIS_VIEW支撑，则SALES_ANALYSIS_VIEW会作为SALES_ANALYSIS的上游数据集出现。

血缘提取通过解析 Power BI M-Query 表达式以及 Power BI API 返回的数据集数据完成（powerbi_post.md）：

• 源会尝试从 M-Query 中的 ODBC 连接串解析数据库类型；若类型匹配受支持平台且能提取足够信息构造合法 Dataset URN，即为该数据源提取血缘；
• 支持的数据源平台：Snowflake、Oracle、PostgreSQL、Microsoft SQL Server、Google BigQuery、Databricks、MySQL、Amazon Redshift、Amazon Athena；
• Native SQL 查询解析支持：Snowflake、Amazon Redshift、Oracle 以及 ODBC 数据源；
• extract_lineage控制血缘接入开关，默认true（需要 Admin API 权限）。

平台映射关系在源码中由SupportedDataPlatform枚举集中定义（config.py），例如PostgreSQL → postgres、Snowflake → snowflake、Amazon Athena → athena、Databricks/DatabricksMultiCloud → databricks、FabricOneLake → fabric-onelake等，并据此生成默认的dataset_type_mapping。注意dataset_type_mapping已被标记为 deprecated，应改用server_to_platform_instance。

M-Query 血缘解析的源码链路

从源码结构看，血缘解析分为三层（m_query/ 目录）：

1. parser.py：get_upstream_tables是血缘提取入口，通过 resolver.py 的resolve_to_data_access_functions解析 M-Query 中的数据访问函数（如PostgreSQL.Database、Snowflake.Databases、Oracle.Database等）；
2. pattern_handler.py：SupportedPattern为每种数据源提供专门的create_lineage实现（含 ODBC、Oracle、Snowflake、Athena 等），make_urn负责按server_to_platform_instance映射与平台详情构造上游 Dataset URN；
3. native_sql_parser.py：对 M-Query 内嵌的 Native SQL（Value.NativeQuery、Query=等）用 sqlglot 做方言化解析，支持 join、子查询等高级构造，并输出表级与列级血缘。

接入报告（config.py 的PowerBiDashboardSourceReport）会统计 M-Query 解析尝试数、成功数、超时数、非 M-Query 表达式数、未知错误数、resolver 失败数以及 EXTERNAL_QUERY 连接解析/未映射数，方便定位血缘缺口。

M-Query 支持模式：Pattern-1 与 Pattern-2

以下 M-Query 将两张 PostgreSQL 表合并，存在两种写法：

Pattern-1（支持）

let Source = PostgreSQL.Database("localhost", "book_store"), book_date = Source{[Schema="public",Item="book"]}[Data], issue_history = Source{[Schema="public",Item="issue_history"]}[Data], combine_result = Table.Combine({book_date, issue_history}) in combine_result

Pattern-2（不支持）

let Source = PostgreSQL.Database("localhost", "book_store"), combine_result = Table.Combine({Source{[Schema="public",Item="book"]}[Data], Source{[Schema="public",Item="issue_history"]}[Data]}) in combine_result

Pattern-2不支持上游表血缘提取，因为它使用嵌套的 item-selector（即{Source{[Schema="public",Item="book"]}[Data], ...}直接作为 M-Query 表函数Table.Combine的参数）；Pattern-1先取出表赋值给变量、再用变量参与表函数，因此可以被解析。在编写 Power BI 查询时，尽量采用“先取表到变量、再组合”的写法，血缘才能完整落地。

Oracle TNS 别名与内联原生查询

Power BI 用户可通过 TNS 别名（任何基于tnsnames.ora的部署）连接 Oracle，并用Query=参数内嵌 SQL：

let Source = Oracle.Database( "EDWPSFN", [HierarchicalNavigation = true, Query = "SELECT … FROM PS_VENDOR, PS_COR_CNTRCT_PROJ …"]) in Source

Oracle.Database首参数的三种形式都会被识别：

1. EZ-Connect：host:port/service[.domain]；
2. 裸 TNS 别名：如EDWPSFN、MYDB.WORLD；
3. 完整 TNS 描述符：(DESCRIPTION=(ADDRESS=…)(CONNECT_DATA=(SERVICE_NAME=foo)))。

对于裸别名与描述符形式，别名 / SERVICE_NAME 会作为server_to_platform_instance的serverkey。该查找不区分大小写，因此 M-Query 中的EDWPSFN能匹配 recipe 里的EDWPSFN（或edwpsfn）。同时，config.py 会在配置加载阶段拒绝仅大小写不同的重复 key，防止 case-insensitive 回退匹配时按字典序静默选错 platform-instance。

匹配 Oracle URN 形态（database 段）：生成的上游 URN 必须与你的 Oracle 接入为同一张表生成的 URN 一致，否则血缘边会指向不存在的数据集。默认情况下 Oracle 接入产出2 段schema.tableURN，仅在开启add_database_name_to_urn: true时产出3 段database.schema.tableURN。Power BI 按下表推导 database 段：

因此裸 TNS 别名默认产出 2 段 URN，与默认 Oracle 接入一致。若你的 Oracle 接入使用add_database_name_to_urn: true，则为别名条目设置default_database补齐缺失段（取值与 Oracle 接入的database/urn_db_name相同）：

source: type: powerbi config: server_to_platform_instance: EDWPSFN: default_database: edwprd # 仅当 Oracle 接入使用 3 段 URN 时设置 default_schema: sysadm # 未限定 schema 的内联 SQL 表的 owner schema # platform_instance: EDWPSFN # 仅当你的 Oracle 接入使用了 platform_instance 时设置

为未限定的内联 SQL 补 schema（default_schema）：内联Query=SQL 常引用未限定的表名，可在别名条目上声明default_schema让这些引用解析到已接入的 Oracle 数据集。default_schema只作用于内联原生 SQL——层级导航（HierarchicalNavigation）的 schema 取自 M-Query 本身。若未设置default_schema且内联 SQL 引用了未限定表，血缘仍会为 SQL 中的限定表绘制，并在接入报告中给出结构化警告，明确指出哪个别名需要配置。此外，Oracle 条目至少要设置default_schema/default_database之一；两者都不需要的映射应写成普通的platform_instance/env条目（该校验同样由 config.py 的OraclePlatformDetail保证）。

BigQuery EXTERNAL_QUERY 联邦

若 Power BI 中通过 BigQuery 联邦（EXTERNAL_QUERY("project.region.connection", "<sql>")）在 Cloud SQL、AlloyDB 等外部引擎上执行 SQL，通用 SQL 解析器无法解析这些调用——其参数是字符串字面量而非表标识符——因此在配置映射前，联邦上游会被跳过并在报告中记录。

要求：native_query_parsing: true、enable_advance_lineage_sql_construct: true、extract_lineage: true（默认开启）。联邦解析发生在血缘提取阶段，因此在以上任一开关关闭时配置映射会直接校验失败而非静默无效。目标platform必须是 Power BI 血缘支持的平台之一：athena、bigquery、databricks、fabric-onelake、hive、mssql、mysql、odbc、oracle、postgres、redshift、snowflake。DataHub 中存在但血缘不支持的平台（如cloudsql、alloydb、spanner、mariadb）会在配置校验时被拒绝——请把映射指向引擎线缆兼容的平台（Cloud SQL 与 AlloyDB 暴露的是postgres或mysql）。若收窄了dataset_type_mapping，请保留目标平台的 Power BI 名称，否则解析出的上游会被过滤掉。

配置示例：

source: type: powerbi config: native_query_parsing: true enable_advance_lineage_sql_construct: true # ... 其他配置 ... bigquery_external_query_connection_to_platform: "my-gcp-project.us-east1.my_cloudsql_connection": platform: postgres # 必填；例如 postgres、mysql default_database: ext_db # 可选；与外部源的 URN 形态匹配 default_schema: public # 可选 # platform_instance: pg-prod # 可选 # env: PROD # 可选

映射 key 必须与EXTERNAL_QUERY第一个参数中的连接 ID（project.region.connection）完全一致。不包含EXTERNAL_QUERY调用的查询中该映射是 no-op；未映射的连接以 info 级别报告（BigQuery EXTERNAL_QUERY connection not mapped），解析失败与空解析则以SQL Parsing Failure警告报告。

Athena 联邦查询平台覆盖

当通过 ODBC 使用 Amazon Athena 查询联邦数据源（例如 Athena 通过联邦连接器查询 MySQL/PostgreSQL）时，血缘 URN 默认指向 Athena 平台。可用athena_table_platform_override把血缘指向真实源平台：

source: type: powerbi config: # ... 其他配置 ... dsn_to_platform_name: MyAthenaDSN: athena athena_table_platform_override: # 按 DSN 限定的 key（优先） "MyAthenaDSN:analytics.users": mysql # 全局 key（任意 DSN 的回退） "reporting.orders": postgres

key 格式：

• DSN 限定："DSN_NAME:database.table"——仅作用于特定 DSN；
• 全局："database.table"——作用于所有 DSN。

DSN 限定的 key 优先于全局 key，从而允许同一表名在不同 Athena 数据源下有不同覆盖。该覆盖仅作用于 Athena ODBC 连接；其他 ODBC 平台的血缘仍由 DSN 配置决定。源码中AthenaPlatformOverride（config.py）在 catalog 剥离之后应用，因此应使用 2 段名database.table而非 3 段名catalog.database.table。

再例如下列查询，OPERATIONS_ANALYTICS.TRANSFORMED_PROD.V_UNIT_TARGET会被接入为上游表：

let Source = Value.NativeQuery( Snowflake.Databases( "sdfsd788.ws-east-2.fakecomputing.com", "operations_analytics_prod", [Role = "OPERATIONS_ANALYTICS_MEMBER"] ){[Name = "OPERATIONS_ANALYTICS"]}[Data], "select #(lf)UPPER(REPLACE(AGENT_NAME,\'-\',\'\')) AS Agent,#(lf)TIER,#(lf)UPPER(MANAGER),#(lf)TEAM_TYPE,#(lf)DATE_TARGET,#(lf)MONTHID,#(lf)TARGET_TEAM,#(lf)SELLER_EMAIL,#(lf)concat((UPPER(REPLACE(AGENT_NAME,\'-\',\'\'))), MONTHID) as AGENT_KEY,#(lf)UNIT_TARGET AS SME_Quota,#(lf)AMV_TARGET AS Revenue_Quota,#(lf)SERVICE_QUOTA,#(lf)BL_TARGET,#(lf)SOFTWARE_QUOTA as Software_Quota#(lf)#(lf)from OPERATIONS_ANALYTICS.TRANSFORMED_PROD.V_UNIT_TARGETS#(lf)#(lf)where YEAR_TARGET >= 2020#(lf)and TEAM_TYPE = \'foo\'#(lf)and TARGET_TEAM = \'bar\'", null, [EnableFolding = true] ), #"Added Conditional Column" = Table.AddColumn( Source, "Has PS Software Quota?", each if [TIER] = "Expansion (Medium)" then "Yes" else if [TIER] = "Acquisition" then "Yes" else "No" ) in #"Added Conditional Column"

注意from子句请使用完整表名（例如dev.public.category）。

Endorsement 转标签

默认关闭将 Endorsement 信息转为标签的功能。若组织使用 Power BI 的认可机制（Endorsement，如 Certified/Promoted）标识内容质量，可开启此功能。注意默认实现会覆盖已接入实体的标签；如需保留既有标签，建议配合 DataHub 的 transformer（例如 dataset_transformer.md 中 simple-add-dataset-globaltags 的semantics: PATCH语义）而非OVERWRITE。

相关参数：

• extract_endorsements_to_tags：是否提取 Endorsement 为标签，默认false；
• filter_dataset_endorsements：按 Endorsement 过滤数据集，例如只允许Certified的数据集被接入；允许列表可同时包含Certified与Promoted（命中其一即接入），默认允许全部数据集。

数据集画像（Profiling）

画像功能通过查询 Power BI 的 DAX 查询端点（Datasets - Execute Queries）实现，因此 principal 必须拥有查询待画像数据集的权限——通常意味着服务主体需要目标工作区的Contributor角色。画像采用基于列的查询（column-based queries）以避免宽表超时。需要留意：画像实现会执行相当数量的 DAX 查询，对大型数据集会给 Power BI 系统带来明显负载，建议谨慎启用并按需限定范围。

profile_pattern可用于把画像限定到 Power BI 中特定资源。allow/deny 规则按以下格式匹配数据集中的每张表：workspace_name.dataset_name.table_name，因此可分别按表、按数据集或按工作区粒度限制画像。例如：

profiling: enabled: true profile_pattern: allow: - sales_workspace.sales_report.sales_analysis deny: - .*

画像所需的最小权限与公共 API 场景下的Viewer角色不同，这也是官方文档强调“要画像必须Contributor”的原因。

限制与注意事项

• 部分元数据与血缘字段仅能通过 Admin API 或特定租户设置获得；
• 血缘质量取决于可用的模型元数据与支持的查询/数据源模式（例如Pattern-2形态的 M-Query、未映射的 EXTERNAL_QUERY 均无法解析）；
• 拥有大量工作区的大型租户需要更长的提取时间窗；
• admin_apis_only: true会损失报表页面、Power BI Parameters 解析与数据集画像能力；
• 开启extract_ownership/extract_endorsements_to_tags可能覆盖 DataHub 中已有的 owner / 标签，需要结合 transformer 的 PATCH 语义或谨慎评估后再启用。

故障排查指引

• 认证失败：核对tenant_id、client_id、client_secret，并确认应用具备所需的 Power BI API 权限（公共 API 与 Admin API 的三项开关是否都已配置、Entra 组是否正确加入）；
• 缺少工作区 / 资产：检查服务主体对目标工作区的访问权限，或按需启用对应的 Admin API 模式与租户设置；个人工作区类型（PersonalGroup/Personal）不可按 id 寻址，接入时会被过滤；
• 血缘缺口：确认extract_lineage、native_query_parsing、enable_advance_lineage_sql_construct等血缘相关配置已开启，语义模型暴露了受支持的上游源细节，同时检查接入报告中的 M-Query 解析统计与SQL Parsing Failure警告；若使用 Oracle TNS 别名或 BigQuery 联邦，还需核对server_to_platform_instance/bigquery_external_query_connection_to_platform映射及其 URN 形态是否与对应数据源接入一致。

小结

Power BI 源是 DataHub 接入 BI 层资产的核心连接器之一：通过 Entra 服务主体 + 公共/Admin 双通道权限，把仪表盘、磁贴、报表、页面、数据集、工作区与 App 统一映射为 DataHub 的 Dashboard/Chart/Dataset/Container 实体，并借助 M-Query 与 Native SQL 解析构建表级、列级血缘，配合 DAX 查询实现数据画像。配置层面的关键点在于：显式声明 ownership 模式、正确映射server_to_platform_instance（尤其是 Oracle TNS 与 BigQuery 联邦等特殊形态）、合理开启容器化与 Endorsement 转标签，并依据接入报告中的解析统计持续校准血缘质量。建议以仓库中的 powerbi_recipe.yml 为起点，结合本指南逐项核对参数后再投入生产。

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