Direct Lake 概述
Direct Lake 是 Power BI 语义模型中存储在 Microsoft Fabric 工作区中的表的存储模式选项。 它针对大量数据进行了优化，可以从 Delta 表快速加载到内存中，这些数据存储在 OneLake的 Parquet 文件中，这是所有分析数据的单个存储。 加载到内存中后，语义模型将启用高性能查询。 Direct Lake 消除了将数据导入模型的速度缓慢且成本高昂的需求。
可以使用 Direct Lake 存储模式连接到单个 Fabric 湖屋或 Fabric 仓库的表或视图。 这两个 Fabric 项和 Direct Lake 语义模型都需要 Fabric 容量许可证。
在某些方面，Direct Lake 语义模型类似于 导入语义模型。 这是因为 VertiPaq 引擎将模型数据加载到内存中，以获取快速查询性能（除了 DirectQuery 回退的情况除外，本文稍后将对此进行介绍）。
但是，Direct Lake 语义模型与导入语义模型有重要区别。 这是因为 Direct Lake 语义模型的刷新操作在概念上不同于导入语义模型的刷新操作。 对于 Direct Lake 语义模型，刷新涉及 框架 操作（本文稍后所述），可能需要几秒钟才能完成。 这是一种低成本操作，语义模型分析最新版本 Delta 表的元数据，并更新为引用 OneLake 中的最新文件。 相比之下，对于导入语义模型，刷新会生成数据的副本，这可能需要相当长的时间，并消耗大量的数据源和容量资源（内存和 CPU）。
注意
导入语义模型的增量刷新 有助于缩短刷新时间和容量资源的使用。
何时应使用 Direct Lake 存储模式？
Direct Lake 存储模式的主要用例通常是使用以湖为中心的体系结构的 IT 驱动的分析项目。 在此方案中，你已在 OneLake 中累积大量数据，或者预期会累积大量数据。 将数据快速加载到内存中、频繁和快速刷新操作、有效使用容量资源以及快速查询性能对于此用例都很重要。
注意
导入和 DirectQuery 语义模型在 Fabric 中仍然相关，并且它们是某些方案的语义模型的正确选择。 例如，导入存储模式通常适用于需要快速行动的自由和敏捷性的自助服务分析师，而无需依赖 IT 来添加新的数据元素。
此外，OneLake 集成会自动将导入存储模式下的表的数据写入 OneLake 中的 Delta 表，而无需进行任何迁移工作。 使用此选项，可以实现 Fabric 的许多优势，这些优势适用于导入语义模型用户，例如通过快捷方式、SQL 查询、笔记本等功能与湖屋集成。 建议将此选项视为快速获取 Fabric 的优势的方法，而无需一定或立即重新设计现有数据仓库和/或分析系统。
Direct Lake 存储模式还适用于最大程度地减少数据延迟，以便快速向业务用户提供数据。 如果间歇性地修改 Delta 表（假设已在数据湖中完成数据准备），则可以依赖自动更新根据这些修改来重新调整。 在这种情况下，发送到语义模型的查询返回最新数据。 此功能与 Power BI 报表的 自动页面刷新 功能协同工作。
请记住，Direct Lake 依赖于在数据湖中完成的数据准备。 可以使用各种工具完成数据准备，例如 Fabric lakehouses 的 Spark 作业、Fabric 仓库的 T-SQL DML 语句、数据流、管道等。 此方法有助于确保在体系结构中尽可能低地执行数据准备逻辑，以最大程度地提高可重用性。 但是，如果语义模型作者无法修改源项，例如，如果自助服务分析师对 IT 管理的 lakehouse 没有写入权限，则导入存储模式可能是更好的选择。 这是因为它支持使用 Power Query（定义为语义模型的一部分）进行数据准备。
在考虑使用 Direct Lake 存储模式时，请务必考虑当前 Fabric 容量许可证和 Fabric 容量防护栏。 此外，请考虑注意事项和限制，本文稍后将对此进行介绍。
提示
建议生成 原型或概念证明（POC），以确定 Direct Lake 语义模型是否是正确的解决方案，以及降低风险。
Direct Lake 的工作原理
通常，发送到 Direct Lake 语义模型的查询通过来自 Delta 表的列的内存缓存进行处理。 Delta 表的基础存储是 OneLake 中的一个或多个 Parquet 文件。 Parquet 文件按列而不是行整理数据。 语义模型将 Delta 表中的整个列加载到内存中，因为查询需要这些列。
Direct Lake 语义模型还可能使用 DirectQuery 回退，这涉及到无缝切换到 DirectQuery 模式。 DirectQuery 回退直接从湖屋的 SQL 分析终结点或仓库检索数据。 例如，当 Delta 表包含的数据行数多于 Fabric 容量支持的行数（本文稍后会介绍）时，可能会发生回退。 在这种情况下，DirectQuery 操作会将查询发送到 SQL 分析终结点。 回退操作可能会导致查询性能变慢。
下图通过使用用户打开 Power BI 报表的场景，展示了 Direct Lake 的工作原理。
此图描述了以下用户操作、流程和功能。
| 项 | 描述 |
|---|---|
|
OneLake 是一个数据湖，用于以 Parquet 格式存储分析数据。 此文件格式经过优化，用于存储 Direct Lake 语义模型的数据。 |
|
Fabric 湖屋或 Fabric 仓库存在于 Fabric 容量上的工作区中。 Lakehouse 有一个 SQL 分析终结点，该终结点提供基于 SQL 的查询体验。 表（或视图）提供了一种使用 Transact-SQL （T-SQL） 查询 OneLake 中的 Delta 表的方法。 |
|
Direct Lake 语义模型存在于 Fabric 工作区中。 它连接到湖屋或仓库中的表或视图。 |
|
用户打开 Power BI 报表。 |
|
Power BI 报表将数据分析表达式 （DAX） 查询发送到 Direct Lake 语义模型。 |
|
如果可能（如有必要），语义模型直接从 OneLake 中存储的 Parquet 文件将列加载到内存中。 查询可实现内存中性能，这非常快。 |
|
语义模型返回查询结果。 |
|
Power BI 报表会呈现视觉对象。 |
|
在某些情况下，例如当语义模型超出容量限制的 防护措施 时，语义模型查询会自动回退到 DirectQuery 模式。 在此模式下，查询发送到湖屋或仓库的 SQL 分析终结点。 |
|
发送到 SQL 分析终结点的 DirectQuery 查询反过来又查询 OneLake 中的 Delta 表。 因此，查询性能可能比内存中查询慢。 |
以下部分介绍 Direct Lake 概念和功能，包括列加载、框架、自动更新和 DirectQuery 回退。
列加载（转码）
Direct Lake 语义模型仅在首次查询列时从 OneLake 加载数据。 从 OneLake 按需加载数据的过程称为“转码”。
当语义模型收到 DAX（或多维表达式 - MDX）查询时，它首先确定生成查询结果所需的列。 需要由查询直接使用的任何列以及关系和度量值所需的列。 通常，生成查询结果所需的列数明显小于语义模型中定义的列数。
了解需要哪些列后，语义模型将确定内存中已有哪些列。 如果查询所需的任何列不在内存中，语义模型将从 OneLake 加载这些列的所有数据。 加载列数据通常是一项快速操作，但它可能取决于列中存储的数据基数等因素。
然后，加载到内存中的列在内存中驻留。 涉及仅驻留列的未来查询不需要将更多列加载到内存中。
列将保持驻留状态，直到有理由将其从内存中移除（逐出）。 可能会移除列的原因包括：
- 在源处的 Delta 表更新之后，模型或表已刷新（请参阅下一节中的组帧）。
- 在一段时间内，没有查询使用相应列。
- 其他内存管理原因，包括由于其他并发操作导致的容量内存压力。
选择 Fabric SKU 可确定容量上每个 Direct Lake 语义模型的最大可用内存。 有关资源防护栏和最大内存限制的详细信息，请参阅下文的“Fabric 容量防护栏和限制”。
组帧
框架 为模型所有者提供在特定时间点控制将数据加载到语义模型中的能力。 框架是由语义模型刷新触发的 Direct Lake 操作，在大多数情况下只需几秒钟才能完成。 这是因为它是一种低成本操作，语义模型会分析最新版本 Delta 表的元数据，并更新为引用 OneLake 中的最新 Parquet 文件。
发生组帧操作时，如果基础数据已更改，并且刷新时间点成为将来所有转码事件的新基线，则可能会从内存中逐出驻留表列段和字典。 从此时起，Direct Lake 查询仅考虑最近组帧操作发生时 Delta 表中的数据。 因此，系统会查询 Direct Lake 表，以根据最近的组帧操作发生时 Delta 表的状态返回数据。 该时间不一定是 Delta 表的最新状态。
请注意，语义模型在帧过程中分析每个 Delta 表的 Delta 日志，以仅删除受影响的列段，并在转码期间重新加载新添加的数据。 一个重要的优化是，增量框架生效时，通常不会删除字典，并将新值添加到现有字典中。 这种增量框架方法有助于减轻重载负担并有利于查询性能。 理想情况下，当 Delta 表未收到更新时，内存中已驻留的列无需重新加载，且由于增量框架实质上使语义模型能够在现有内存数据中进行大范围更新，查询在框架处理后性能受到的影响要小得多。
下图显示了 Direct Lake 框架操作的工作原理。
此图描述了以下过程和功能。
| 项 | 描述 |
|---|---|
|
|
Fabric 工作区中存在语义模型。 |
|
|
框定操作会定期进行，并为将来的所有 转码 事件确定基准。 帧操作可以自动、手动、按计划或以编程方式发生。 |
|
|
OneLake 存储元数据和 Parquet 文件，这些文件表示为 Delta 表。 |
|
|
最新的组帧操作包括与 Delta 表相关的 Parquet 文件，特别是在最新的组帧操作之前添加的 Parquet 文件。 |
|
|
之后的组帧操作包括在最新的组帧操作之后添加的 Parquet 文件。 |
|
|
可能会从内存中逐出 Direct Lake 语义模型中的驻留列，而刷新时间点将成为将来所有转码事件的新基线。 |
|
|
随后的数据修改（以新的 Parquet 文件形式表示）在下一个框架操作发生之前是不可见的。 |
在执行转码操作时，不一定总是需要拥有代表任何 Delta 表最新状态的数据。 请考虑组帧可帮助你在 Delta 表数据是暂时性数据的环境中，提供一致的查询结果。 数据可能是暂时性的，原因有多种，例如，当提取、转换和加载（ETL）进程运行时间较长时。
可以手动、自动或以编程方式完成 Direct Lake 语义模型的刷新。 有关详细信息，请参阅 刷新 Direct Lake 语义模型。
有关 Delta 表版本控制和组帧的详细信息，请参阅了解 Direct Lake 语义模型的存储。
自动更新
有一个语义模型级设置，用于自动更新 Direct Lake 表。 默认情况下，它已启用。 它可确保 OneLake 中的数据更改自动反映在 Direct Lake 语义模型中。 如果要通过框架控制数据更改，应禁用自动更新，如上一部分所述。 有关详细信息，请参阅 管理 Direct Lake 语义模型。
提示
你可以在 Power BI 报表中设置自动页面刷新。 它是一项自动刷新特定报表页的功能，条件是该报表连接到 Direct Lake 语义模型（或其他类型的语义模型）。
DirectQuery 回退
发送到 Direct Lake 语义模型的查询可以回退到 DirectQuery 模式。 在这种情况下，它会直接从湖屋或仓库的 SQL 分析终结点检索数据。 此类查询始终返回最新数据，因为它们不受最后一次帧操作的时间点的约束。
当语义模型查询 SQL 分析终结点中的视图或强制实施行级安全性 (RLS) 的 SQL 分析终结点中的表时，查询始终会回退。
此外，当语义模型 超出容量的限制时，查询可能会退回。
重要
如果可能，应始终设计解决方案（或调整容量大小），以避免 DirectQuery 回退。 这是因为这可能会导致查询性能变慢。
通过设置 DirectLakeBehavior 属性，您可以控制 Direct Lake 语义模型的回退。 有关详细信息，请参阅设置 Direct Lake 行为属性。
Fabric 容量护栏和限制
Direct Lake 语义模型需要 Fabric 容量许可证。 此外，还有适用于 Fabric 容量订阅（SKU）的容量防护措施和限制，如下表所示。
重要
下表中的第一列还包括 Power BI Premium 容量订阅（P SKU）。 请注意，Microsoft 正在合并购买选项并停用 Power BI Premium 按容量 SKU。 新客户和现有客户应考虑改为购买 Fabric 容量订阅 (F SKU)。
有关详细信息，请参阅 Power BI Premium 许可 和 Power BI Premium的重要更新。
| Fabric SKU | 每个表的 Parquet 文件数 | 每个表的行组数 | 每个表的行数（数百万） | 存储在磁盘或 OneLake 上的最大模型大小（GB） | 最大内存（GB）1 |
|---|---|---|---|---|---|
| F2 | 1,000 | 1,000 | 300 | 10 | 3 |
| F4 | 1,000 | 1,000 | 300 | 10 | 3 |
| F8 | 1,000 | 1,000 | 300 | 10 | 3 |
| F16 | 1,000 | 1,000 | 300 | 20 | 5 |
| F32 | 1,000 | 1,000 | 300 | 40 | 10 |
| F64/FT1/P1 | 5,000 | 5,000 | 1,500 | 无限制 | 25 |
| F128/P2 | 5,000 | 5,000 | 3,000 | 无限制 | 50 |
| F256/P3 | 5,000 | 5,000 | 6,000 | 无限制 | 100 |
| F512/P4 | 一万 | 一万 | 12,000 | 无限制 | 200 |
| F1024/P5 | 一万 | 一万 | 24,000 | 无限制 | 400 |
| F2048 | 一万 | 一万 | 24,000 | 无限制 | 400 |
1 对于 Direct Lake 语义模型，最大内存表示可调入页面的数据的内存资源上限。 因此，这并非一种限制，因为超过它不会导致切换回 DirectQuery 模式；但是，如果数据量大到足以引起 OneLake 数据与模型数据之间的大量交换，则可能会对性能产生影响。
如果超出阈值，磁盘/OneLake 上的 最大模型大小会使语义模型的所有查询回退到 DirectQuery（直接查询）模式。 表中显示的所有其他护栏均按查询进行评估。 因此，请务必优化 Delta 表和 Direct Lake 语义模型，以避免不必要地纵向扩展到更高的 Fabric SKU（导致成本增加）。
此外，容量单元 和 每个查询的最大内存限制 适用于 Direct Lake 语义模型。 有关详细信息，请参阅 容量和 SKU。
注意事项和限制
Direct Lake 语义模型存在一些注意事项和限制。
注意
Direct Lake 语义模型的功能和功能正在不断发展。 请务必定期回查，查看最新的注意事项和限制列表。
- 当 Direct Lake 语义模型表连接到强制实施行级别安全性的 SQL 分析终结点中的表时，涉及该模型表的查询将始终回退到 DirectQuery 模式。 查询性能可能较慢。
- 当 Direct Lake 语义模型表连接到 SQL 分析终结点中的视图时，涉及该模型表的查询将始终回退到 DirectQuery 模式。 查询性能可能较慢。
- 不支持复合建模。 这意味着 Direct Lake 语义模型表不能与其他存储模式下的表（例如 Import、DirectQuery 或 Dual）混合（特殊情况除外，包括 计算组、模拟参数，以及 字段参数）。
- 不支持在 Direct Lake 存储模式下引用列或表的计算列和计算表。 支持隐式创建计算表的计算组、What-if 参数和字段参数，以及不引用 Direct Lake 列或表的计算表。
- Direct Lake 存储模式表不支持复杂的 Delta 表列类型。 二进制和 GUID 语义类型也不受支持。 必须将这些数据类型转换为字符串或其他受支持的数据类型。
- 表关系需要相关列的数据类型才能匹配。
- 关系的单侧列必须包含唯一值。 如果在一侧列中检测到重复值，查询将失败。
- 不支持 Power BI Desktop 中的自动数据/时间智能。 支持将自己的日期表标记为日期表。
- 字符串列值的长度限制为 32,764 个 Unicode 字符。
- 不支持 NaN（而不是数字）的浮点值。
- 仅当为 Direct Lake 语义模型使用固定标识时，才支持使用服务主体从 Power BI 发布到 Web。
- 在 Web 建模体验中，Direct Lake 语义模型的验证受到限制。 用户选择被假定为正确，因此不会发出任何查询来验证关系的基数、交叉筛选选择，或标记日期表中选定日期列的选择。
- 在 Fabric 门户中，刷新历史记录中的“Direct Lake”选项卡仅列出与 Direct Lake 相关的刷新失败。 未列出成功的刷新（组帧）操作。
- Fabric SKU 可确定容量上每个 Direct Lake 语义模型的最大可用内存。 超出该限制后，由于调入和调出页面的模型数据过多，对语义模型的查询可能会变慢。
- 不支持在位于数据源工作区不同区域的工作区中创建 Direct Lake 语义模型。 例如，如果湖屋位于美国中西部，则只能在同一区域中从此湖屋创建语义模型。 解决方法是在创建语义模型之前在其他区域的工作区中创建湖屋和表的快捷方式。 若要查找你所在的区域，请参阅 查找你的 Fabric 所在区域。
- 可以使用服务主体标识创建和查看自定义 Direct Lake 语义模型，但默认的 Direct Lake 语义模型不支持服务主体。 确保为租户中的 Fabric REST API 启用服务主体身份验证，并向 Direct Lake 语义模型的工作区授予服务主体参与者或更高权限。
- 嵌入报表需要 V2 嵌入令牌。
- Direct Lake 不支持使用服务主体配置文件进行身份验证。
- 支持由服务主体和具有服务主体的查看器创建的自定义 Direct Lake 语义模型，但不支持默认的 Direct Lake 语义模型。
与其他存储模式的比较
下表比较了 Direct Lake 存储模式与 Import 和 DirectQuery 存储模式。
| 能力 | Direct Lake | 进口 | DirectQuery（直接查询） |
|---|---|---|---|
| 授权 | 仅 Fabric 容量订阅 (SKU) | 任何 Fabric 或 Power BI 许可证（包括Microsoft Fabric 免费许可证） | 任何 Fabric 或 Power BI 许可证（包括Microsoft Fabric 免费许可证） |
| 数据源 | 仅湖屋或仓库表（或视图） | 任何连接器 | 支持 DirectQuery 模式的任何连接器 |
| 连接到 SQL 分析终结点视图 | 是 - 但将自动回退到 DirectQuery 模式 | 是的 | 是的 |
| 复合模型 | 否 1 | 是 - 可以与 DirectQuery 或双存储模式表结合使用 | 是 - 可以与导入或双重存储模式表结合使用 |
| 单一登录 （SSO） | 是的 | 不適用 | 是的 |
| 计算表 | 否 – 除了 计算组、模拟参数，以及 字段参数，这些都隐式创建计算表。 | 是的 | 否——即使计算表引用了处于 DirectQuery 模式的其他表，它们仍然会使用导入存储模式。 |
| 计算列 | 不 | 是的 | 是的 |
| 混合表 | 不 | 是的 | 是的 |
| 模型表分区 | 否 – 但是，可以在 Delta 表级别执行分区 | 是 - 由增量刷新自动创建，或者使用 XMLA 终结点手动创建 | 不 |
| 用户定义的聚合 | 不 | 是的 | 是的 |
| SQL 分析终端对象级别安全或列级别安全 | 是 - 但查询将回退到 DirectQuery 模式，在拒绝权限时可能会生成错误 | 是 - 但必须使用语义模型对象级安全性复制权限 | 是 - 但当权限被拒绝时，查询可能会生成错误 |
| SQL 分析端点行级安全性 （RLS） | 是 - 但查询将回退到 DirectQuery 模式 | 是的——但必须用语义模型 RLS 复制权限 | 是的 |
| 语义模型行级安全性 (RLS) | 是 - 但强烈建议使用 固定标识 云连接 | 是的 | 是的 |
| 语义模型对象级安全性 （OLS） | 是的 | 是的 | 是的 |
| 没有刷新要求的大型数据卷 | 是的 | 不太适合 - 查询和刷新可能需要更大的容量大小 | 是的 |
| 减少数据延迟 | 是 - 启用自动更新或编程组帧时；但是，必须先在上游完成数据准备 | 不 | 是的 |
| Power BI Embedded | 是 2 | 是的 | 是的 |
1 不能在同一语义模型中将 Direct Lake 存储模式表与 DirectQuery 或双存储模式表合并。 但是，可以使用 Power BI Desktop 在 Direct Lake 语义模型上创建复合模型，然后使用新表（使用 Import、DirectQuery 或双存储模式）或计算对其进行扩展。 有关详细信息，请参阅 在语义模型上生成复合模型。
2 需要 V2 嵌入令牌。 如果使用服务主体，则必须使用固定标识云连接。