Direct Lake 概述
Direct Lake 是 Power BI 语义模型中存储在 Microsoft Fabric 工作区中的表的存储模式选项。 它针对可从 Delta 表快速加载到内存的大量数据进行了优化，该 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 湖屋的 Spark 作业、Fabric 仓库的 T-SQL DML 语句、数据流、管道等。 此方法有助于确保在体系结构中尽可能少地执行数据准备逻辑，以最大程度地提高可重用性。 但是，如果语义模型作者无法修改源项，例如，如果自助服务分析师对 IT 管理的湖屋没有写入权限，则导入存储模式可能是更好的选择。 这是因为它支持使用 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 容量上的工作区中。 湖屋有一个 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 加载这些列的所有数据。 加载列数据通常是一项非常快速的操作，但它可能取决于某些因素，例如列中存储的数据的基数。
然后，加载到内存中的列在内存中驻留。 如果未来的查询仅涉及驻留列，则无需再向内存加载任何列。
列将保持驻留状态，直到有理由将其从内存中删除(逐出)。 可能会删除列的原因包括:
选择 Fabric SKU 可确定容量上每个 Direct Lake 语义模型的最大可用内存。 有关资源防护栏和最大内存限制的详细信息，请参阅下文的“Fabric 容量防护栏和限制”。
组帧
组帧为模型所有者提供时间点控制功能，确定何时将数据加载到语义模型中。 组帧是由语义模型刷新触发的 Direct Lake 操作，在大多数情况下只需几秒钟即可完成。 这是因为它是一种低成本操作，语义模型会分析最新版本 Delta 表的元数据，并更新为引用 OneLake 中的最新 Parquet 文件。
发生组帧操作时，可能会从内存中逐出驻留列，而刷新时间点将成为将来所有转码事件的新基线。 从此时起，Direct Lake 查询仅考虑最近组帧操作发生时 Delta 表中的数据。 因此，在最近组帧操作发生时，系统会查询 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 语义模型”。
DirectQuery 回退
发送到 Direct Lake 语义模型的查询可以回退到 DirectQuery 模式。 在这种情况下，它会直接从湖屋或仓库的 SQL 分析终结点检索数据。 此类查询始终会返回最新数据，因为它们不受最后一次组帧操作的时间点的约束。
当语义模型查询 SQL 分析终结点中的视图或强制实施行级安全性 (RLS) 的 SQL 分析终结点中的表时，查询始终会回退。
此外，当语义模型超出容量的护栏时，查询可能会回退。
重要
如有可能，设计解决方案时要始终考虑避免出现 DirectQuery 回退，或调整容量来避免回退。 这是因为回退可能会导致查询变慢。
你可以通过设置 Direct Lake 语义模型的 DirectLakeBehavior 属性来控制该模型的回退。 有关详细信息，请参阅“设置 Direct Lake 行为属性”。
Fabric 容量护栏和限制
Direct Lake 语义模型需要 Fabric 容量许可证。 此外，还有适用于 Fabric 容量订阅 (SKU) 的容量护栏和限制，具体如下表所示。
重要
下表中的第一列还包括 Power BI Premium 容量订阅 (P SKU)。 请注意，Microsoft 正在合并购买选项并停用按容量 SKU 的 Power BI Premium。 新客户和现有客户应考虑改为购买 Fabric 容量订阅 (F SKU)。
| 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 语义模型，最大内存表示页换入数据的内存资源上限。 因此，这不是一个护栏，因为超过它不会导致回退到 DirectQuery 模式。但是，如果数据量大到会导致来自 OneLake 数据的模型数据页换入和换出过多，则可能会影响性能。
如果超出，则磁盘/OneLake 上的最大模型大小将导致语义模型的所有查询回退到 DirectQuery 模式。 表中显示的所有其他护栏均按查询进行评估。 因此，请务必优化 Delta 表和 Direct Lake 语义模型，以避免需要纵向扩展到更高的 Fabric SKU（导致成本增加）。
此外，容量单位和每个查询的最大内存限制适用于 Direct Lake 语义模型。 有关详细信息，请参阅“容量和 SKU”。
注意事项和限制
Direct Lake 语义模型存在一些注意事项和限制。
注意
Direct Lake 语义模型的功能正在不断发展。 请务必定期回查，查看最新的注意事项和限制列表。
- 当 Direct Lake 语义模型表连接到强制实施行级安全性 (RLS) 的 SQL 分析终结点中的表时，涉及该模型表的查询将始终回退到 DirectQuery 模式。 查询可能会变慢。
- 当 Direct Lake 语义模型表连接到 SQL 分析终结点中的视图时，涉及该模型表的查询将始终回退到 DirectQuery 模式。 查询可能会变慢。
- 不支持复合建模。 这意味着 Direct Lake 语义模型表不能与其他存储模式(例如导入、DirectQuery 或双重模式)下的表混合(特殊情况除外，包括计算组、what-if 参数，以及字段参数)。
- 不支持在 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 语义模型工作区的参与者或更高权限。
- Direct Lake 不支持使用服务主体配置文件进行身份验证。
与其他存储模式对比
下表比较了 Direct Lake 存储模式与导入和 DirectQuery 存储模式。
| 功能 | Direct Lake | 导入 | DirectQuery |
|---|---|---|---|
| 许可 | 仅 Fabric 容量订阅(SKU) | 任何 Fabric 或 Power BI 许可证(包括 Microsoft Fabric 免费许可证) | 任何 Fabric 或 Power BI 许可证(包括 Microsoft Fabric 免费许可证) |
| 数据源 | 仅湖屋或仓库表(或视图) | 任何连接器 | 支持 DirectQuery 模式的任何连接器 |
| 连接到 SQL 分析终结点视图 | 是 – 但将自动回退到 DirectQuery 模式 | 是 | 是 |
| 复合模型 | 否 1 | 是 – 可以与 DirectQuery 或双存储模式表结合使用 | 是 – 可以与导入或双存储模式表结合使用 |
| 单一登录 (SSO) | 是 | 不适用 | 是 |
| 计算表 | 否 – 除了计算组、What-if 参数和字段参数，它们隐式创建计算表 | 是 | 否 – 即使计算表引用 DirectQuery 模式下的其他表，也会使用导入存储模式 |
| 计算列 | 否 | 是 | 是 |
| 混合表 | 否 | 是 | 是 |
| 模型表分区 | 否 – 但是，可以在 Delta 表级别执行分区 | 是 - 由增量刷新自动创建，或者使用 XMLA 终结点手动创建 | 否 |
| 用户定义的聚合 | 否 | 是 | 是 |
| SQL 分析终结点对象级安全性或列级安全性 | 是 – 但查询将回退到 DirectQuery 模式，并且在权限被拒绝时可能会发生错误 | 是 – 但必须使用语义模型对象级安全性复制权限 | 是 – 但当权限被拒绝时，查询可能会发生错误 |
| SQL 分析终结点行级安全性 (RLS) | 是 – 但查询将回退到 DirectQuery 模式 | 是 – 但必须使用语义模型 RLS 复制权限 | 是 |
| 语义模型行级安全性 (RLS) | 是 – 但强烈建议使用固定标识云连接 | 是 | 是 |
| 语义模型对象级安全性 (OLS) | 是 | 是 | 是 |
| 没有刷新要求的大型数据卷 | 是 | 没那么适合 – 查询和刷新可能需要更大的容量大小 | 是 |
| 减少数据延迟 | 是 - 启用自动更新或编程组帧时；但是，必须先在上游完成数据准备 | 否 | 是 |
1 不能在同一语义模型中将 Direct Lake 存储模式表与 DirectQuery 或双存储模式表合并。 但是，可以使用 Power BI Desktop 在 Direct Lake 语义模型上创建复合模型，然后使用新表(使用导入、DirectQuery 或双存储模式)或计算对其进行扩展。 有关详细信息，请参阅“在语义模型上生成复合模型”。