Power BI 中的复合模型：混合导入和 DirectQuery

多年来，Power BI 从业者必须选择：导入模式（快速，但数据仅与上次刷新一样新鲜）或 DirectQuery（始终是最新的，但可能很慢且查询受限）。复合模型改变了这种计算方式，允许两种存储模式共存于一个模型中——并且关系跨越模式边界。

此功能解锁了以前不可能的场景：仪表板显示来自导入分区的昨天的完整交易历史记录以及来自 DirectQuery 源的今天的实时数据，所有这些都连接到按需查询的实时 Salesforce 机会表。了解复合模型的工作原理以及它们何时产生比解决的问题更多的问题是任何高级 Power BI 从业者的基本知识。

要点

• 复合模型在单个语义模型中混合导入、DirectQuery 和双存储模式
• 导入模式为历史数据提供 VertiPaq 压缩和内存中查询性能
• DirectQuery模式实时查询源——新鲜度极佳，但性能取决于源
• 双模式表可以充当导入或 DirectQuery，具体取决于查询上下文
• 跨越存储模式边界的关系增加了查询复杂性并可能导致性能问题
• 复合模型中的聚合表显着提高了 DirectQuery 查询性能
• DirectQuery for Power BI 数据集（链接）支持在共享语义模型之上构建复合模型
• 导入和 DirectQuery 表之间的有限关系限制了某些 DAX 函数

---

存储模式：导入、DirectQuery 和 Dual

在理解复合模型之前，必须单独理解每种存储模式。

导入模式 将数据从源系统加载到 Power BI 的内存 VertiPaq 存储引擎中。数据被压缩（通常为 10:1 或更好）并存储为列式数据，可以极快地执行分析查询 — 对于高达数亿行的数据集的大多数查询通常只需几毫秒。限制：数据仅与上次计划或手动刷新一样新鲜。

DirectQuery 模式 每当用户与报表交互时都会实时查询源系统。 Power BI 引擎将 DAX 查询转换为本机源查询（关系数据库的 SQL 等），并针对源执行它们。数据始终是最新的，但性能完全取决于源系统的查询性能。索引完善的专用分析数据库可以很好地处理 DirectQuery 查询；事务负载繁重的 OLTP 生产数据库可能会产生缓慢且不一致的结果。

双模式是复合模型中可用的特殊混合模式。双模式表在物理上存储为导入（数据加载到 VertiPaq 中），但也可以在查询上下文需要时通过 DirectQuery 进行查询。这主要用于需要参与与导入和 DirectQuery 事实表的关系的共享维度表。

---

何时使用复合模型

复合模型适用于特定场景。当更简单的架构满足要求时，它们增加了不合理的复杂性。

在以下情况下使用复合模型：

在以下情况下不要使用复合模型：

• 完整导入模型刷新速度足够快，数据延迟是可以接受的（大多数情况）
• DirectQuery 源无法处理查询负载（生产 OLTP 数据库）
• 需要复杂的 DAX 计算 - 复合模型限制某些 DAX 函数
• 行级安全性需要跨越存储模式边界（实现复杂）

---

配置存储模式

在 Power BI Desktop 中，存储模式是按表设置的。右键单击模型视图中的表 → 属性 → 高级 → 存储模式。

对于 DirectQuery 中具有大型事实表和导入中具有维度的典型复合模型：

1.设置FactSales→存储模式：DirectQuery 2. 设置 DimDate → 存储模式：双（同时提供导入和 DirectQuery 查询） 3.设置DimProduct→存储模式：导入（小表，全缓存） 4.设置DimCustomer→存储模式：Dual（跨源关系时使用） 5.设置RealtimeSales（今天的数据）→存储模式：DirectQuery

当您将表配置为 DirectQuery 或更改存储模式时，Power BI 会显示有关关系和潜在限制的警告。仔细检查这些 - 它们表明模型行为可能与纯导入模型不同。

---

复合模型中的关系

不同存储模式的表之间的关系与相同模式的关系表现不同，理解这些差异对于构建产生正确结果的模型至关重要。

常规关系 连接两个表，其中“多”方可以使用“一”方进行过滤。在导入模型中，两个表都在内存中，并且关系在内存中快速执行。在具有一个导入表和一个 DirectQuery 表的复合模型中，这种关系会导致对一个表进行表扫描，然后使用该表来筛选另一个表 - 可能会生成大型跨模式查询。

当 DirectQuery 表与导入表具有多对多关系或在某些其他跨模式场景中时，会自动创建 有限关系。有限关系不支持双向筛选器，并限制某些 DAX 函数（例如，依赖于关系筛选器路径的函数）。 Power BI 使用虚线而不是实线报告模型视图中的有限关系。

跨源关系 连接来自完全不同数据源的表（例如，通过 DirectQuery 连接的来自 SQL Server 的表和通过另一个 DirectQuery 连接连接的来自 Salesforce 的表）。这些关系要求一侧是双模式表 - Power BI 需要能够在内存中具体化关系的一侧以连接到另一侧。

这些关系类型的实际影响：在纯导入模型中正常工作的 DAX 度量可能会在复合模型中产生意外结果或错误。更改存储模式后，请仔细测试所有措施，特别是涉及 USERELATIONSHIP、CROSSFILTER、使用关系相关过滤器函数进行计算以及相关表聚合的措施。

---

聚合表：核心复合模型模式

最有价值的复合模型模式将大型 DirectQuery 事实表与导入模式聚合表相结合，以更高的粒度预先汇总数据。

问题：DirectQuery 中的 5 亿行销售事实表对于大多数源系统来说太大，无法进行交互查询 - 每个图表都需要 10 秒以上，因为源执行昂贵的聚合查询。

解决方案：预先构建一个汇总表，将事实聚合为每日/每月/产品类别粒度，并将该汇总表导入 Power BI。大多数查询（每月、每季度或类别级别）都会遇到快速导入聚合。只有深入到单个事务级别的查询才会返回到 DirectQuery。

设置聚合：

首先，在数据仓库中创建聚合表：

CREATE TABLE SalesByDayProduct AS
SELECT
    SaleDateKey,
    ProductKey,
    CustomerSegmentKey,
    RegionKey,
    SUM(SalesAmount) as SalesAmount,
    SUM(Quantity) as Quantity,
    SUM(Cost) as Cost,
    COUNT(*) as TransactionCount
FROM FactSales
GROUP BY SaleDateKey, ProductKey, CustomerSegmentKey, RegionKey;

将此表导入 Power BI 并将存储模式设置为 导入。

然后，在 Power BI 中配置聚合：

• 右键单击 SalesByDayProduct → 管理聚合
• 将每一列映射到其与明细表和汇总函数（Sum、Average、Count 等）的关系
• 设置“汇总”列（SalesAmount → Sum 映射到 FactSales[SalesAmount] → Sum）

Power BI 的查询引擎现在会在可能的情况下自动将查询路由到聚合表，并且仅当查询需要聚合未提供的行级详细信息时才回退到 DirectQuery 详细信息表。

性能结果是惊人的：以前需要 15 秒的类别级别和时间级别聚合现在只需不到 1 秒即可返回，同时钻取单个事务的选项仍然可用。

---

Power BI 数据集的 DirectQuery

Power BI 引入了适用于 Power BI 数据集的 DirectQuery（也称为“与复合模型的实时连接”或简称为“共享数据集上的复合模型”）。这允许开发人员创建使用现有已发布的 Power BI 数据集作为 DirectQuery 源的新报表或数据集，同时添加新表、计算度量和本地导入数据。

关键用例：组织拥有经过认证的企业语义模型，涵盖核心财务和销售数据。从事特定分析的团队需要添加一些本地数据（包含项目代码的 CSV 文件、包含目标的 Excel 文件），而无需修改经过认证的企业模型。他们使用 DirectQuery for Power BI 数据集创建一个复合模型，该模型通过 DirectQuery 引用企业模型，并将其本地表添加为导入数据。

这实现了受管理的分析架构，其中：

• 中央数据团队维护经过认证的企业数据集
• 业务团队根据本地上下文扩展这些数据集，而无需创建单独的、不一致的模型
• 企业模型仍然是共享指标的单一事实来源

限制：DirectQuery for Power BI 数据集继承了常规 DirectQuery 的所有限制 - 某些 DAX 函数受到限制，必须正确配置行级安全性才能通过复合模型传播，并且与源数据集的连接添加了一层查询处理。

---

复合模型的性能优化

与纯导入模型相比，复合模型需要更仔细的性能调整。以下优化影响最大：

减少跨模式查询：每次跨越存储模式边界的关系遍历都会增加延迟。通过将维度表保持为双模式（它们可以同时提供导入和 DirectQuery 查询而无需跨模式遍历）并构建模型以使大多数查询保持在单一模式中，可以最大限度地减少这些问题。

在源处预聚合：不要要求 DirectQuery 源执行 Power BI 可以更有效地执行的聚合。在源数据库中构建视图或物化视图，根据您的报告实际需要的粒度进行预聚合。

使用性能分析器监控查询计划：在 Power BI Desktop 中，视图 → 性能分析器记录每个视觉对象的 DAX 查询和后续源查询（如果是 DirectQuery）所花费的时间。这揭示了哪些视觉效果较慢，以及缓慢的查询是在 DAX 层还是源查询层。

使用查询缩减设置：在 Power BI Desktop → 选项 → 查询缩减中，启用选项以将“应用”按钮添加到切片器和筛选器。这可以防止每个切片器交互立即触发源查询 - 对于每个查询都有网络和源执行延迟的 DirectQuery 报告尤其重要。

限制 DirectQuery 连接数：复合模型中的每个不同 DirectQuery 源都会创建一个单独的连接池。尽可能限制 1-2 个 DirectQuery 源；超过 3 会显着增加模型复杂性和潜在的性能问题。

---

复合模型中的行级安全性

复合模型中的行级安全性 (RLS) 需要仔细规划，尤其是在与 DirectQuery 表有关系的导入表上定义 RLS 时。

当具有 RLS 筛选器的用户查询报表时，Power BI 会将筛选器应用到相应的表。如果筛选的表处于导入模式并且与 DirectQuery 表有关系，Power BI 必须将导入筛选器转换为可发送到 DirectQuery 源的筛选器。这在大多数情况下都有效，但对于复杂的过滤器层次结构可能会产生意外的结果。

最佳实践：在导入模式维度表（而不是 DirectQuery 事实表）上定义 RLS。过滤器通过关系从维度传播到事实——其工作可靠。直接在 DirectQuery 表上定义 RLS 是可能的，但更难测试和调试。

对于使用 DirectQuery for Power BI 数据集的复合模型，在查询该数据集时会自动应用源数据集中定义的 RLS。可以在复合模型层中定义附加的 RLS。这种分层 RLS 方法需要仔细测试，以确保过滤器正确组合。

---

常见问题

我可以在一个复合模型中混合来自完全不同数据库平台的数据吗？

是的。复合模型可以同时包含来自 SQL Server (DirectQuery)、Salesforce (DirectQuery)、Azure Blob 存储文件（导入）和 Snowflake (DirectQuery) 的表。每个源都维护自己的连接。不同源的表之间的关系必须至少有一张双模表，以方便跨源连接。性能和复杂性随着每个附加源的增加而增加——对于大多数实现来说，限制为 2-3 个源是可行的。

哪些 DAX 函数在复合模型中不起作用？

某些 DAX 函数在具有 DirectQuery 表的复合模型中受到限制或表现不同。不适用于有限关系的函数包括 SUMMARIZE（在某些上下文中）、TOPN（在 DirectQuery 表上）和一些时间智能函数。 USERELATIONSHIP 可以工作，但可能会导致跨模式查询。完整的限制列表记录在 Microsoft Power BI 文档的“DirectQuery 限制”下。强烈建议在添加 DirectQuery 表后测试所有关键指标。

增量刷新如何与复合模型配合使用？

增量刷新适用于复合模型中的导入模式分区。配置为 DirectQuery 的表不使用增量刷新 - 它们在每次交互时实时查询源。最常见的组合是在导入模式历史分区上使用增量刷新，同时对当前周期数据使用 DirectQuery — 这就是混合表功能，它是单个表中复合建模的一种特定形式。

复合模型与纯导入相比对性能有何影响？

具有 DirectQuery 组件的复合模型始终比等效查询的等效纯导入模型慢。性能差距取决于源系统性能以及命中 DirectQuery 与导入分区的查询的比例。通过精心设计的聚合表，大多数用户查询都会命中导入聚合并在 1 秒内返回，从而使性能可以接受。钻取 DirectQuery 详细信息的查询可能需要 3-15 秒，具体取决于源性能。

我应该使用复合模型还是只是安排更频繁的刷新？

对于大多数可以接受“近实时”的用例，更频繁的刷新（导入模式每 15 分钟一次）就足够了。使用 DirectQuery 的复合模型会显着增加复杂性 - 仅在以下情况下使用它们：(a) 您需要真正实时到分钟或秒的数据，(b) 数据集太大，即使使用增量刷新，也无法在可用窗口内刷新，或者 (c) 您需要合并来自无法整合到单个仓库刷新中的源的数据。

---

后续步骤

复合模型是复杂 Power BI 架构的强大工具 - 但它们需要仔细设计以避免性能和正确性陷阱。最成功的实现将复合模型用于特定的、合理的场景，而不是作为默认架构。

ECOSIRE 的 Power BI 数据建模服务 包括复合模型设计、聚合表实现和性能优化。请联系我们评估复合模型是否适合您特定的数据新鲜度和性能要求。