Power BI 的 Data model 类型、示例与实用技巧（第 1 部分）

• 在 Power BI 中，首先要决定数据如何存储。这是你在 Power BI 项目早期就必须做出的关键决策。
  
• 选错可能带来灾难性后果，而且在团队与项目中并不少见。
• 存储模式有多种类型：Import、DirectQuery、Direct Lake、复合模型（composite model）。还有一些特殊表配置，例如 Dual 或混合表格。
• 总体来说，Import 应作为在 Power BI 中连接并存储数据的默认首选。只有在特定情况下，你才可能想用——或必须用——其他存储模式。
• 在最终拍板前，先做个 PoC（概念验证），或针对你的场景评估该存储模式在功能、性能与成本上的影响。

在 Power BI 中，你需要创建一个语义模型（也叫 Data model），用来支撑 Report 或仪表板、数据透视表以及 AI 的分析。当你在 Power BI 里连接数据时，最早要做的决策之一就是：数据要如何存储。默认情况下，Power BI 会把数据导入到内存中。这意味着 Power BI 会加载一份数据副本，供 Report 可视化对象查询（这些可视化对象会在后台生成 DAX 查询）。Import 存储模式是连接数据最简单、最省心的方式，但它并非唯一选项。在 Power BI 项目中，选择存储模式类型往往是最早、也最重要的决策之一，并且会显著影响你的模型设计与功能实现。 

Power BI 提供多种存储模式，Microsoft 文档从总体以及能力差异两个角度做了总结。由于存储模式是按表来决定的，在一些场景下你也可以把它们组合在同一个模型里，这称为复合模型（composite model）。我们会在本文后面讨论复合模型。 

下图对不同存储模式类型做了一个快速概览： 

本文会简要介绍这些存储模式，并给出一些建议与示例，帮助你在 Power BI 项目中更好地选择与使用。简要来说： 

• Import 是首选默认项，适用于大多数“把数据加载到内存中”的场景。 

• DirectQuery 指的是直接对受支持的数据源进行查询，通常更慢也更贵。不过，如果你确实需要接近实时的数据，它可以满足这一点；当你无法使用 Direct Lake 时，它在特定场景下会派上用场。DirectQuery 也常用于在复合模型里把现有语义模型的数据与其他数据结合。 

• Direct Lake 仅在 Microsoft Fabric 中可用。它会按需且快速地把 OneLake 中的列数据加载到内存，而不是像 Import 那样在模型刷新时加载整张表的所有列。因此，Direct Lake 可以看作是对 Import 的技术优化，查询性能可比。它适用于数据量更大、刷新性能有挑战，并且你具备相应流程成熟度来搭建与管理 OneLake 中的Delta 表。通常你应优先选择Direct Lake over OneLake，而不是Direct Lake over SQL Endpoint；但需要注意的是，截至 2025 年 10 月，Direct Lake over OneLake 仍处于公开预览版。另外，在大多数场景下，Direct Lake 通常也优先于 DirectQuery。相较其他存储模式，Direct Lake 的技术细节更多、也更“讲究”。 

• Composite models 指在同一个模型中混用多种存储模式。它在特定情况下能解决特定问题，但也会因多种原因显著增加模型设计、开发与分发的复杂度。 

• 特殊表配置（例如 Dual 或混合表格）在需要时很有用：Dual 常见于复合模型，混合表格常见于增量刷新场景。混合表格不支持在 Pro Workspace 中使用。 

务必谨慎选择存储模式：不要草率决定，否则后面很可能会很痛（也可能很烧钱）。下面我们会展开一些细节。 

Import 是最常见、也最简单的存储模式，适用于绝大多数场景。它支持所有数据源与文件类型。使用 Import 存储模式时，数据驻留在内存中，因此性能最好。不过，当你想让 Data model 包含最新数据时，就需要执行刷新。当数据量更大或模型更复杂时，刷新可能会成为一些团队的“税负”：刷新时间变长，或给源系统带来压力。但在很多情况下，遵循推荐实践即可避免这些问题，例如： 

• 数据缩减：只保留你真正需要的数据，过滤或移除不需要的数据。 

• 设置增量刷新：只获取表中新增加或发生变化的行，而不是每次都刷新整张表。 

• Power Query 优化：例如确保查询能折叠到数据源（让数据源承担主要计算，而不是让 Power BI 来“干重活”）。   

• 合理的流程管理：例如避免在同一个数据源上同时刷新多个模型。 

• 合理的资源管理：例如根据数据源/场景配置你需要的数据网关（Gateway），以便与某些数据源中的数据进行通信。  

Import 存储模式适用于以下这类场景： 

• 你在构建一个标准的 Power BI Data model，现实中并没有对数据源连接、数据量、数据新鲜度或复杂度提出特定要求。这也是大多数 Power BI Data model 的情况。 

• 你在 Power BI Desktop 中对本地文件（例如 Excel 或 .csv）做有限分析。这些文件可以在你的电脑上，但如果你要配置计划刷新以自动获取最新数据，就需要把文件放到云端位置（例如 SharePoint 或 OneDrive），或者使用本地数据网关（on-premises data gateway）来访问这些文件。 

• 你需要（或希望）创建计算列或计算表格，而这些通常在 DirectQuery 或 Direct Lake 中不支持（后文会介绍）。 
• 你刚开始或仍处于 Power BI 落地的早期阶段，没有明确需求必须使用 DirectQuery 或 Direct Lake（后文会介绍）。这两者会带来额外复杂度、限制与需要你额外管理的注意事项。  

DirectQuery 是一种替代存储模式：你直接对受支持的数据源进行查询（例如 Azure SQL 数据库、Snowflake 或 Databricks）。使用 Import 时，可视化对象会用 DAX 查询内存中的数据；使用 DirectQuery 时，会多一步：把 DAX 翻译成 SQL 并发送到源系统。 

因此，当用户首次打开连接到 DirectQuery 模式语义模型的 Report 时，他们看到的是截至上一次页面刷新或交互时的相对新数据。相较之下，如果语义模型使用 Import，那么数据只会反映截至最近一次语义模型刷新时的状态。因此，当你需要接近实时的 Report，或对数据新鲜度有更高要求时，DirectQuery 可能适用。 

但由于数据不在内存中，使用 DirectQuery 时查询通常更慢。Report 出数会更慢，同时你也会付出更高的“间接成本”去优化 Data model 与计算。你还需要考虑 DirectQuery 专属的配置与优化，其中一些仅限 PPU、Premium 容量或 Fabric capacity 才能使用，例如自动与用户定义聚合。此外，查询源系统本身可能带来直接成本，因此 Report 使用量越高，账单可能越高。例如，在 Snowflake 或 Databricks 这类按量计费的 Warehouse 上就很典型。 

DirectQuery 可能适用于以下这类场景： 

• 你确实需要接近实时的数据或极高的数据新鲜度要求，而 Import 无法满足，并且你也不会用 Microsoft Fabric 的Real-Time Intelligence 工作负载来解决。 

• 你希望在语义模型查询中复用数据源里定义的数据安全性，并且这么做有明确、可度量的收益（而不只是教条或偏好）。要记得，你也可以在语义模型中重新定义这些安全规则，例如行级和 对象级安全性在语义模型中也可以设置，而且很简单。 \n
  • 你计划在复合模型中，针对某些表按需使用 DirectQuery（本文后面会介绍复合模型）。  
  \ntabs=filterstep%2Cimport\">导入模式下的增量刷新。通过增量刷新，你可以将表配置为只刷新新增或变化的行，从而显著缩短刷新时间。其工作方式是把表拆分成称为分区的“块”（通常基于日期字段），并且只刷新其中部分分区（通常是最近的那些）。 

   

  \n

  不过，你也可以把表配置为：部分分区使用导入模式，而最新的分区使用 DirectQuery。这种混合表格配置适用于这样的场景：你确实需要更高的数据新鲜度，但只针对最近的时间窗口（例如今天或本周）；而其他时间段（例如本月）按计划刷新，更早的历史数据保持静态、归档。这样做的关键是：我们通过只对“很小一部分、与新鲜度窗口相关的数据”使用 DirectQuery，来缓解 DirectQuery 固有的性能问题。 

  \n

  从现实角度看，只有当这个数据新鲜度需求非常明确且真实存在时，你才应在传统增量刷新之外考虑混合表格。对绝大多数场景来说，标准的增量刷新已经足够。 

  \n

  最后补充一点：混合表格是高级功能。这意味着你无法在发布到 Pro Workspace 的语义模型中使用混合表格。只有当 Workspace 采用 Premium Per User (PPU)、Premium 容量或 Fabric capacity 许可模式时，才能使用。