Unity Catalog 指标视图现已登陆 Power BI：为所有报表与 AI 提供统一、受治理的语义层
内容提要
Databricks推出“发布到Power BI”功能（私有预览），可将Unity Catalog指标视图直接发布为Power BI语义模型，实现业务指标一次定义、多端复用。每个指标视图对应一张表，维度转为列，度量自动转为DAX，连接与计算仍在Databricks执行，指标视图保持唯一可信来源。配合Lakeflow任务可自动同步更新，并借助DirectQuery继承Unity Catalog权限与治理，确保Power BI、AI/BI仪表板与Genie使用一致口径。
延伸解读
治理边界：DirectQuery 与 Import 模式的关键差异
文章明确指出，只有通过 DirectQuery 连接时，Power BI 查询才会继承 Unity Catalog 的行过滤、列掩码和 ABAC 策略。若使用 Import 模式，数据会被加载到 Power BI 中，该副本的访问权限由 Power BI 自身权限控制，不再受 Unity Catalog 治理。这意味着选择连接模式直接决定了治理是否延续，读者需根据安全要求权衡实时性与权限一致性。
单向发布：指标定义权收归 Databricks
发布流程是单向的：从 Unity Catalog 指标视图到 Power BI 语义模型。在 Power BI 中修改已发布的度量值不会回写到指标视图。若需调整受治理的指标，必须回到 Databricks 更新指标视图并重新发布，或通过 Lakeflow 任务自动同步。这一设计确保了指标视图作为唯一可信来源的地位，但也要求团队明确变更流程，避免在 Power BI 侧做无效修改。
性能优化与实时性的后续能力
文章提到，由于 Power BI 直接查询指标视图，未来将能受益于指标视图物化（materialization）。物化会预计算结果以加速查询，但不改变指标定义和 DAX 度量值，结果保持一致。此外，结合 Lakehouse//RT 与 DirectQuery，Power BI 报表可获得实时性能，且无需单独复制数据到服务系统，同时继续执行 Unity Catalog 的安全策略。这些能力目前尚未完全落地，但指明了性能与治理兼得的方向。
Q&A
Unity Catalog 指标视图发布到 Power BI 后，语义模型的结构是怎样的？
每个指标视图对应 Power BI 语义模型中的一张表，指标视图的维度（字段）变为列，度量自动转换为 DAX 度量值。由于连接已在指标视图中定义，连接后的维度会作为普通列出现，无需在 Power BI 中重建表关系。
Power BI 查询的是指标视图还是底层表？计算在哪里执行？
Power BI 查询的是指标视图本身（如同查询一张表），只有度量表达式被翻译为 DAX，且这些 DAX 引用指标视图的维度。指标视图保持为唯一可信来源，连接和计算仍在 Databricks 中执行。
如何让 Power BI 语义模型在指标视图变更后自动更新？
可以在 Lakeflow Job 中添加 Power BI 任务，将发布指标视图作为数据管道的一个步骤，按计划或在上下游表刷新后自动运行。这样更新的度量、新度量和新维度会自动流入 Power BI，无需手动重做。
使用 DirectQuery 时，Power BI 的访问权限如何受 Unity Catalog 管控？
使用 DirectQuery 时，每个查询都遵循 Unity Catalog 的访问控制和安全策略（包括行过滤、列掩码和 ABAC 策略），血缘关系保持连接。而在导入模式下，数据被加载到 Power BI，对该副本的访问遵循 Power BI 权限。
在 Power BI 中修改已发布的度量值，会同步回 Unity Catalog 吗？
不会。发布是单向的，仅从 Unity Catalog 到 Power BI。在 Power BI 中编辑已发布的度量值不会写回指标视图。要更改受治理的指标，需在 Databricks 中更新指标视图并重新发布，或通过 Lakeflow Job 的 Power BI 任务按计划更新语义模型。
为什么应该将指标定义放在 Unity Catalog 而不是 Power BI 语义模型中？
将指标定义保留在 Unity Catalog 可以确保单一受治理的定义，供 Power BI、AI/BI 仪表板和 Genie 等所有消费者使用。Power BI 语义模型主要服务于 Power BI，难以被外部 BI 工具或 AI 代理访问，会导致同一指标在每个工具中重复构建。发布指标视图到 Power BI 会自动将度量转换为 DAX，让 Power BI 用户保留报表的同时，为 AI 和其他用例维护统一治理的定义。
