Direct Lake 概述
Direct Lake 是 Power BI 语义模型中存储在 Microsoft Fabric 工作区中的表的存储模式选项。 它针对可从 Delta 表快速加载到内存中的大量数据进行了优化，该表将其数据存储在 OneLake 的 Parquet 文件中，这是所有分析数据的单个存储。 加载到内存中后，语义模型将启用高性能查询。 Direct Lake 消除了将数据导入模型的速度缓慢且成本高昂的需求。
可以使用 Direct Lake 存储模式连接到单个 Fabric Lakehouse 或 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 查询、笔记本等与 Lakehouses 集成。 建议将此选项视为快速获取 Fabric 的优势的方法，而无需一定或立即重新设计现有数据仓库和/或分析系统。
Direct Lake 存储模式还适用于最大程度地减少数据延迟，以便快速向业务用户提供数据。 如果增量表间歇性地修改（假设已在 Data Lake 中完成数据准备），则可以依赖于 自动更新 来重新帧以响应这些修改。 在这种情况下，发送到语义模型的查询将返回最新数据。 此功能与 Power BI 报表的自动页面刷新功能合作良好。
请记住，Direct Lake 依赖于在 Data 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 回退直接从 Lakehouse 或仓库的 SQL 分析终结点检索数据。 例如，当 Delta 表包含的数据行数多于 Fabric 容量支持的行时（本文稍后 所述）时，可能会发生回退。 在这种情况下，DirectQuery 操作会将查询发送到 SQL 分析终结点。 回退操作可能会导致查询性能变慢。
下图显示了 Direct Lake 如何使用打开 Power BI 报表的用户的方案工作。
该图表描绘了以下用户操作、流程和功能。
| 项 | 说明 |
|---|---|
 |
OneLake 是一个数据湖，用于以 Parquet 格式存储分析数据。 此文件格式 已针对 Direct Lake 语义模型存储数据进行 优化。 |
 |
Fabric Lakehouse 或 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 模式。 在此模式下，查询将发送到 Lakehouse 或仓库的 SQL 分析终结点。 |
 |
发送到 SQL 分析终结点的 DirectQuery 查询反过来又查询 OneLake 中的 Delta 表。 因此，查询性能可能比内存中查询慢。 |
以下部分介绍 Direct Lake 概念和功能，包括列加载、框架、自动更新和 DirectQuery 回退。
列加载 （转码）
Direct Lake 语义模型仅在首次查询列时从 OneLake 加载数据。 从 OneLake 按需加载数据的过程称为 转码。
当语义模型收到 DAX（或多维表达式 - MDX）查询时，它首先确定生成查询结果所需的列。 所需的列包括查询直接使用的任何列，以及关系和度量值所需的列。 通常，生成查询结果所需的列数比语义模型中定义的列数要小得多。
了解需要哪些列后，语义模型将确定内存中已有哪些列。 如果查询所需的任何列不在内存中，语义模型将从 OneLake 加载这些列的所有数据。 加载列数据通常是一项非常快速的操作，但它可能取决于列中存储的数据基数等因素。
然后 ，加载到内存中的列将驻留 在内存中。 涉及仅驻留列的未来查询不需要将更多列加载到内存中。
列保持驻留状态，直到有理由将其从内存中删除（逐出）。 可能会删除列的原因包括：
- 模型或表已刷新（请参阅 下一部分的框架 ）。
- 没有查询使用了该列一段时间。
- 其他内存管理原因，包括由于其他并发操作导致容量中的内存压力。
选择 Fabric SKU 可确定容量上每个 Direct Lake 语义模型的最大可用内存。 有关资源防护栏和最大内存限制的详细信息，请参阅 本文后面的 Fabric 容量防护措施和限制 。
框架
框架 为模型所有者提供时间点控制将数据加载到语义模型中。 框架是由语义模型刷新触发的 Direct Lake 操作，在大多数情况下只需几秒钟即可完成。 这是因为这是一个低成本的操作，语义模型分析最新版本的 Delta Lake 表的元数据，并更新为引用 OneLake 中的最新 Parquet 文件。
出现帧时，可能会从内存中逐出驻留列，刷新时间点将成为所有将来转码事件的新基线。 从这一点开始，Direct Lake 查询仅考虑在最近的帧操作时增量表中的数据。 因此，会查询 Direct Lake 表，以根据最新帧操作时 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 模式。 在这种情况下，它直接从 Lakehouse 或仓库的 SQL 分析终结点检索数据。 此类查询始终返回最新数据，因为它们不受最后一次帧操作的时间点的约束。
当语义模型查询 SQL 分析终结点中的视图或强制实施行级别安全性的 SQL 分析终结点中的表时，查询始终会回退。
此外，当语义模型 超过容量的护栏时，查询可能会回退。
重要
如果可能，应始终设计解决方案（或调整容量大小），以避免 DirectQuery 回退。 这是因为这可能会导致查询性能变慢。
可以通过设置 DirectLakeBehavior 属性来控制 Direct Lake 语义模型的回退。 有关详细信息，请参阅 设置 Direct Lake 行为属性。
构造容量防护措施和限制
Direct Lake 语义模型需要 Fabric 容量许可证。 此外，还有适用于 Fabric 容量订阅（SKU）的容量防护措施和限制，如下表所示。
重要
下表中的第一列还包括 Power BI Premium 容量订阅（P SKU）。 请注意，Microsoft正在合并购买选项并停用每个容量 SKU 的 Power BI Premium。 新客户和现有客户应考虑改为购买 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 | 10,000 | 10,000 | 12,000 | 无限制 | 200 |
| F1024/P5 | 10,000 | 10,000 | 24,000 | 无限制 | 400 |
| F2048 | 10,000 | 10,000 | 24,000 | 无限制 | 400 |
1 对于 Direct Lake 语义模型， Max Memory 表示可分页数据的内存上限资源限制。 因此，这不是一个护栏，因为超过它不会导致回退到 DirectQuery 模式;但是，如果数据量足够大，导致 OneLake 数据进出模型数据过多，则可能会产生性能影响。
如果超出， 磁盘/OneLake 上的最大模型大小将导致语义模型的所有查询回退到 DirectQuery 模式。 表中显示的所有其他防护措施均按查询进行评估。 因此， 必须优化 Delta 表 和 Direct Lake 语义模型 ，以避免不必要的纵向扩展到更高的结构 SKU（导致成本增加）。
此外， 每个查询的容量单位 和 最大内存限制 也适用于 Direct Lake 语义模型。 有关详细信息，请参阅 容量和 SKU。
注意事项和限制
Direct Lake 语义模型存在一些注意事项和限制。
注意
Direct Lake 语义模型的功能和功能正在不断发展。 请务必定期回查，查看最新的注意事项和限制列表。
- 当 Direct Lake 语义模型表连接到强制实施行级别安全性的 SQL 分析终结点中的表时，涉及该模型表的查询将始终回退到 DirectQuery 模式。 查询性能可能较慢。
- 当 Direct Lake 语义模型表连接到 SQL 分析终结点中的视图时，涉及该模型表的查询将始终回退到 DirectQuery 模式。 查询性能可能较慢。
- 不支持复合建模。 这意味着 Direct Lake 语义模型表不能与其他存储模式下的表（例如 Import、DirectQuery 或 Dual）混合（特殊情况除外，包括 计算组、 模拟参数和 字段参数）。
- 不支持在 Direct Lake 存储模式下引用列或表的计算列和计算表。 支持计算组、 模拟参数和 字段参数，这些参数隐式创建计算表，以及不引用 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 语义模型。 例如，如果 Lakehouse 位于美国中西部，则只能在同一区域中从此 Lakehouse 创建语义模型。 解决方法是在创建语义模型之前在其他区域的工作区和表的快捷方式中创建 Lakehouse。 若要查找你所在的区域，请参阅 查找 Fabric 主区域。
与其他存储模式的比较
下表比较了 Direct Lake 存储模式与 Import 和 DirectQuery 存储模式。
| 功能 | Direct Lake | 导入 | DirectQuery |
|---|---|---|---|
| 许可 | 仅构造容量订阅（SKU） | 任何 Fabric 或 Power BI 许可证（包括Microsoft Fabric 免费许可证） | 任何 Fabric 或 Power BI 许可证（包括Microsoft Fabric 免费许可证） |
| 数据源 | 仅湖屋或仓库表（或视图） | 任何连接器 | 支持 DirectQuery 模式的任何连接器 |
| 连接到 SQL 分析终结点视图 | 是 - 但将自动回退到 DirectQuery 模式 | 是 | 是 |
| 复合模型 | 否 1 | 是 - 可以与 DirectQuery 或双存储模式表结合使用 | 是 - 可以与导入或双重存储模式表结合使用 |
| 单一登录 (SSO) | 是 | 不适用 | 是 |
| 计算表 | 否 – 除 计算组、 模拟参数和 字段参数外，这些参数会隐式创建计算表 | 是 | 否 – 即使计算表引用 DirectQuery 模式下的其他表，计算表也使用导入存储模式 |
| 计算列 | 否 | 是 | 是 |
| 混合表 | 否 | 是 | 是 |
| 模型表分区 | 否 - 但是可以在 Delta 表级别执行分区 | 是 - 由增量刷新自动创建，或使用 XMLA 终结点手动创建 | 否 |
| 用户定义的聚合 | 否 | 是 | 是 |
| SQL Analytics 终结点对象级安全性或列级安全性 | 是 - 但查询将回退到 DirectQuery 模式，在拒绝权限时可能会生成错误 | 是 - 但必须使用语义模型对象级安全性重复权限 | 是 - 但当权限被拒绝时，查询可能会生成错误 |
| SQL 分析终结点行级别安全性 （RLS） | 是 - 但查询将回退到 DirectQuery 模式 | 是 - 但必须使用语义模型 RLS 重复权限 | 是 |
| 语义模型行级别安全性 （RLS） | 是 - 但强烈建议使用 固定标识 云连接 | 是 | 是 |
| 语义模型对象级安全性 （OLS） | 是 | 是 | 是 |
| 不需要刷新的大量数据卷 | 是 | 不太适合 - 查询和刷新可能需要更大的容量大小 | 是 |
| 减少数据延迟 | 是 – 启用自动更新或编程重新帧时;但是，必须先在上游完成数据准备 | 否 | 是 |
1 不能将 Direct Lake 存储模式表与同一语义模型中的 DirectQuery 或双存储模式表合并。 但是，可以使用 Power BI Desktop 在 Direct Lake 语义模型上创建复合模型，然后使用新表（使用 Import、DirectQuery 或双存储模式）或计算对其进行扩展。 有关详细信息，请参阅 在语义模型上生成复合模型。