ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

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

DataHub 接入 Microsoft Power BI:概念映射、Entra 权限配置与 M-Query 血缘解析实战指南 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.mdPower 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.pyPowerBiDashboardSourceConfig定义了全部可配置项租户、客户端凭据、过滤模式、血缘开关、画像开关等并用 pydantic 做了大量交叉校验powerbi.py负责把 Power BI 对象转换为 DataHub 的 Metadata Change ProposalMCP与 Metadata Work Unitrest_api_wrapper/ 与 m_query/分别封装 Power BI REST API 调用与 M-Query / Native SQL 血缘解析。概念映射Power BI 对象到 DataHub 实体理解该连接器最快捷的方式是掌握官方文档给出的概念映射表见 README.mdPowerBIDataHubDashboardDashboardDatasets TableDatasetTileChartReport.webUrlChart.externalUrlWorkspaceContainerReportDashboardPaginatedReportDashboardPageChartAppDashboard两条补充规则如果Tile由报表Report创建则Chart.externalUrl会被设置为对应Report.webUrl对于 Power BI 分页报表PaginatedReportPage不可用分页报表不以页面为单位组织可视化。这份映射在源码中可以得到印证powerbi.py 的report_to_dashboard把 Report 转为 DataHubDashboarddashboardTool为powerbidashboardId形如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公共 APIPublic APIs面向开发者用于与租户内的特定资源交互要求 Entra 应用被显式授予对各个工作区的访问权限Admin APIAdmin APIs面向管理员可站在租户全局视角返回所有 Power BI 资源的元数据。官方推荐的做法是两者都配置把 Entra 应用加入要接入的工作区同时授予公共 API 与 Admin API 权限从而让 ingestion 提取到最完整的元数据。授予公共 API 访问权限在 Power BI / Fabric 中进入Settings-Admin portal-Tenant settings在Developer Settings下启用Service principals can call Fabric Public APIsPower BI 旧版本中名为Allow service principals to use Power BI APIs并将应用的 Entra 组加入Specific security groups将 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 访问权限同样在Admin portal-Tenant settings中将应用的 Entra 组加入Specific security groups为以下三项开关逐个启用并添加安全组Service principals can access read-only admin APIsEnhance admin APIs responses with detailed metadataEnhance admin APIs responses with DAX and mashup expressions获得 Admin API 权限后该源可接入血缘Lineage、数据集Datasets、标签化认可Endorsement as tag、仪表盘、仪表盘磁贴、报表、报表页面、App。完整 recipe 与核心配置详解仓库提供了开箱即用的示例 recipepowerbi_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 BigQuerykey 为项目名对 Fabric OneLakeDirectLake 血缘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 corpuserfalse 仍会提取工作区/仪表盘所有权 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的定义以下参数对实战最要紧参数默认值说明tenant_id/client_id/client_secret必填Entra 租户、应用标识与客户端密钥用于获取访问令牌environmentcommercialcommercial商用版或governmentGCC 政府云web 地址为app.powerbigov.usworkspace_name_pattern/workspace_id_pattern全部允许按名称/ID 正则过滤工作区二者与workspace_type_filter联合生效workspace_type_filter[Workspace]仅处理类型匹配的工作区Workspace/PersonalGroup/Personal/AdminWorkspace/AdminInsightsextract_dashboardstrue是否把仪表盘与磁贴接入为 DataHub Dashboard/Chartextract_reportstrue是否接入报表extract_dataset_schematrue是否接入数据集表的列与度量该开关为 true 时才能做 schema 提取与列级血缘extract_lineagetrue是否接入数据集表级血缘需要 Admin APIextract_ownershipfalse是否接入所有权需要 Admin API且可能覆盖 DataHub 网页端手动维护的 ownerextract_workspaces_to_containerstrue工作区映射为 DataHub 容器extract_datasets_to_containersfalse把数据集下的表归入“数据集”容器形成 Workspace → Dataset → Table 层级extract_endorsements_to_tagsfalseEndorsement 转为标签注意默认实现会覆盖实体的既有标签native_query_parsingtrue是否解析 Power BI 原生查询以提取血缘enable_advance_lineage_sql_constructtrue启用 join、子查询等高级 SQL 构造解析依赖native_query_parsingextract_column_level_lineagetrue列级血缘需要native_query_parsing、enable_advance_lineage_sql_construct、extract_lineage、extract_dataset_schema同时开启配置校验会强制这一点见 config.pyadmin_apis_onlyfalse仅使用 Admin API损失页面、参数解析与画像能力scan_timeout60元数据扫描超时秒scan_batch_size1批量发送 workspace id 给 Power BI 的大小上限 100m_query_parse_timeout70单条 M-Query 解析超时秒遇到 “M-Query Parsing Timeout” 报告时可调大modified_sinceNone配合 Admin API 仅接入修改过的工作区时间格式如2023-02-10T00:00:00.0000000Zconvert_urns_to_lowercase/convert_lineage_urns_to_lowercasefalse/true是否把资产 URN / 血缘 URN 转为小写profile_pattern全部允许画像范围过滤匹配格式workspace_name.dataset_name.table_namestateful_ingestionNone有状态接入配置用于 stale entity 删除patch_metadatatrue对仪表盘元数据使用 PATCH 方式更新用户与所有权处理软引用模式与完整用户创建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_userspowerbi.py负责生成 corpuser 相关 MCP并且在 to_datahub_work_units 中用户 MCP 以is_primary_sourceFalse单独处理避免有状态接入把用户实体当作主数据源跟踪/软删除。按访问权限过滤 Ownerowner_criteria用于限定哪些用户能成为 Owner只有至少具备其中一个指定访问权限的用户才会被指派为 Owner。合法取值取决于资源dataset、report、dashboard的 Power BI 访问权限类型。若owner_criteria未设置或为空列表则所有principalType: User的用户均符合条件。ownership: owner_criteria: - ReadWriteReshareExplore - Owner - Admin其余相关配置use_powerbi_email决定用邮箱还是 Power BI 用户标识构建用户 URNremove_email_suffix可去掉邮箱后缀如acryl.iodataset_configured_by_as_owner把数据集configuredBy作为数据集 owner。Admin scan 与工作区列列举双通道Power BI 接入对每个工作区使用两条元数据路径见 powerbi_post.md路径何时使用拉取内容API 调用量Admin scan配置的 principal 具备 Admin API 权限且工作区扫描有返回Reports、users、datasets、lineage、endorsements——全部来自单次工作区扫描响应每个工作区批次 1 次扫描请求工作区列列举回退Workspace listing fallbackAdmin scan 对某工作区无返回权限、限流等通过每个工作区的/reports端点拉取报表仅当extract_ownership: true时通过/admin/reports/{id}/users按报表拉取用户O(工作区数 报表数) 次请求当回退被触发时接入报告会为对应工作区记录一条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 AthenaNative 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/ 目录parser.pyget_upstream_tables是血缘提取入口通过 resolver.py 的resolve_to_data_access_functions解析 M-Query 中的数据访问函数如PostgreSQL.Database、Snowflake.Databases、Oracle.Database等pattern_handler.pySupportedPattern为每种数据源提供专门的create_lineage实现含 ODBC、Oracle、Snowflake、Athena 等make_urn负责按server_to_platform_instance映射与平台详情构造上游 Dataset URNnative_sql_parser.py对 M-Query 内嵌的 Native SQLValue.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{[Schemapublic,Itembook]}[Data], issue_history Source{[Schemapublic,Itemissue_history]}[Data], combine_result Table.Combine({book_date, issue_history}) in combine_resultPattern-2不支持let Source PostgreSQL.Database(localhost, book_store), combine_result Table.Combine({Source{[Schemapublic,Itembook]}[Data], Source{[Schemapublic,Itemissue_history]}[Data]}) in combine_resultPattern-2不支持上游表血缘提取因为它使用嵌套的 item-selector即{Source{[Schemapublic,Itembook]}[Data], ...}直接作为 M-Query 表函数Table.Combine的参数Pattern-1先取出表赋值给变量、再用变量参与表函数因此可以被解析。在编写 Power BI 查询时尽量采用“先取表到变量、再组合”的写法血缘才能完整落地。Oracle TNS 别名与内联原生查询Power BI 用户可通过 TNS 别名任何基于tnsnames.ora的部署连接 Oracle并用Query参数内嵌 SQLlet Source Oracle.Database( EDWPSFN, [HierarchicalNavigation true, Query SELECT … FROM PS_VENDOR, PS_COR_CNTRCT_PROJ …]) in SourceOracle.Database首参数的三种形式都会被识别EZ-Connecthost:port/service[.domain]裸 TNS 别名如EDWPSFN、MYDB.WORLD完整 TNS 描述符(DESCRIPTION(ADDRESS…)(CONNECT_DATA(SERVICE_NAMEfoo)))。对于裸别名与描述符形式别名 / 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 段Oracle.Database 形式Database 段EZ-Connecthost:port/service恒为 3 段取service裸 TNS 别名 / 描述符无——默认 2 段因此裸 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 补 schemadefault_schema内联QuerySQL 常引用未限定的表名可在别名条目上声明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第一个参数中的连接 IDproject.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: postgreskey 格式DSN 限定DSN_NAME:database.table——仅作用于特定 DSN全局database.table——作用于所有 DSN。DSN 限定的 key 优先于全局 key从而允许同一表名在不同 Athena 数据源下有不同覆盖。该覆盖仅作用于 Athena ODBC 连接其他 ODBC 平台的血缘仍由 DSN 配置决定。源码中AthenaPlatformOverrideconfig.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 为标签默认falsefilter_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创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表