Direct Lake 是 Power BI 语义模型中存储在 Microsoft Fabric 工作区中的表的存储模式选项。 它针对大量数据进行了优化，可以从存储在 OneLake 中的 Delta 表（所有分析数据的单个存储）快速加载到内存中。 加载到内存中后，语义模型可实现高性能交互式分析。
Direct Lake 非常适合用于连接大型 Fabric 湖屋、数据仓库以及其他带有 Delta 表数据源的语义模型，尤其是当将全部数据量复制到导入模型中存在困难或无法实现时。 Direct Lake 查询由 VertiPaq 查询引擎处理，与导入模式相同，而 DirectQuery 会将查询分发到基础数据源。 这意味着 Direct Lake 查询（如导入模式）通常优于 DirectQuery。
但是，Direct Lake 与导入模式在一个重要方面有所不同：Direct Lake 语义模型的刷新操作在概念上与导入语义模型的刷新操作不同。 导入模式复制数据，并为语义模型创建整个缓存的数据副本，而 Direct Lake 刷新仅复制元数据（如本文稍后所述的 框架），这可能需要几秒钟才能完成。 Direct Lake 刷新是一项低成本的操作，用于分析最新版本 Delta 表的元数据，并更新以引用 OneLake 中的最新文件。 相比之下，对于导入刷新操作，会生成一个数据副本，这可能需要相当长的时间，并消耗大量的数据源和计算资源（内存和 CPU）。 Direct Lake 会将数据准备移动到 OneLake，并在这样做时使用结构技术的完整范围来准备数据，包括 Spark 作业、T-SQL DML 语句、数据流、管道等。
Direct Lake 存储模式具有以下主要优势：
- 与导入模式类似，Direct Lake 查询由 VertiPaq 引擎处理，因此提供与导入模式相当的查询性能，而无需管理数据刷新周期的开销来加载整个数据卷。
- 它通过与大型湖屋、数据仓库以及其他带有 Delta 表的 Fabric 数据源无缝集成来利用现有 Fabric 投资。 例如，Direct Lake 是奖牌湖屋体系结构中“金牌”分析层的理想选择。
- 最大化投资回报（ROI），因为分析的数据量可能超过容量的最大内存限制，因为只有回答查询所需的数据加载到内存中。
- 通过将语义模型与其源快速自动同步来最大程度地减少数据延迟，使新数据可供业务用户使用，而无需刷新计划。
何时应使用 Direct Lake 存储模式？
Direct Lake 存储模式的主要用例通常是使用以湖为中心的体系结构的 IT 驱动的分析项目。 在这种情况下，你已在 OneLake 中累积或预期会累积大量数据。 将数据快速加载到内存中、频繁和快速刷新操作、有效使用容量资源以及快速查询性能对于此用例都很重要。
注意
导入和 DirectQuery 语义模型在 Fabric 中仍然相关，并且它们是某些方案的语义模型的正确选择。 例如，导入存储模式通常适用于需要快速行动的自由和敏捷性的自助服务分析师，而无需依赖 IT 来添加新的数据元素。
此外， OneLake 集成 会自动将导入存储模式下的表的数据写入 OneLake 中的 Delta 表 ，而无需进行任何迁移工作，这使你能够实现为导入语义模型用户提供的 Fabric 的许多优势，例如通过快捷方式、SQL 查询、笔记本等与 lakehouses 集成。 建议使用此选项快速获取 Fabric 的优势，而不一定或立即重新设计现有的数据仓库和/或分析系统。
Direct Lake 依赖于数据湖中完成的数据准备。 可以使用各种工具（例如 Fabric lakehouse 的 Spark 作业、Fabric 仓库的 T-SQL DML 语句、数据流、管道等）来完成数据准备，这有助于确保数据准备逻辑在体系结构上游执行，以最大程度地提高可重用性。 但是，如果语义模型作者没有修改源项的能力，例如，如果自助服务分析师对 IT 管理的 Lakehouse 没有写入权限，那么使用导入存储模式表扩充模型可能是一个不错的选择，因为导入模式支持使用 Power Query 进行数据准备， 定义为语义模型的一部分。
在考虑 Direct Lake 存储模式时，请务必考虑当前的 Fabric 容量许可证 和 Fabric 容量防护措施 。 此外，请考虑注意事项和限制，本文稍后将对此进行介绍。
提示
建议生成 原型或概念证明（POC），以确定 Direct Lake 语义模型是否是正确的解决方案，以及降低风险。
关键概念和术语
本文假设读者熟悉以下概念：
- 用户与 Power BI 报表中的视觉对象进行交互，这些视觉对象生成对语义模型的 DAX 查询。
-
存储模式：语义模型根据所使用的存储模式以不同的方式处理 DAX 查询。 例如：
- 导入和 Direct Lake 存储模式使用 VertiPaq 引擎来处理 DAX 查询并将结果返回到 Power BI 报表和用户。
- 另一方面，DirectQuery 将 DAX 查询转换为数据源的查询语法（通常是 SQL 形式），并将其联合到基础数据库。 与导入和 Direct Lake 模式相比，源数据库查询处理器通常不采用 BI 样式的聚合查询，因此会导致性能降低，并且用户交互性降低。
存储模式是语义模型中表的属性。 当语义模型包含具有不同存储模式的表时，它称为复合模型。 有关存储模式的详细信息，请参阅 Power BI 服务中的语义模型模式。
Direct Lake 模式 可以使用两种不同的访问方法：
- OneLake 上的 Direct Lake 不依赖于 SQL 终结点，可以使用任何带有 Delta 表的 Fabric 数据源的数据。 OneLake 上的 Direct Lake 不会回退到 DirectQuery 模式。
注意
OneLake 上的 Direct Lake 目前处于公共预览阶段。
- SQL 终结点上的 Direct Lake 使用 Fabric 湖屋或仓库的 SQL 终结点进行 Delta 表发现和权限检查。 当无法直接从 Delta 表加载数据时，SQL 终结点上的 Direct Lake 可以回退到 DirectQuery 模式，例如当数据源是 SQL 视图或仓库使用基于 SQL 的行级别安全性（RLS 时）。 SQL 终结点上的 Direct Lake 已正式发布，在生产环境中完全受支持。
存储模式比较
下表比较了 Direct Lake 存储模式与 Import 和 DirectQuery 存储模式。
| 能力 | OneLake 上的 Direct Lake | SQL 终结点上的 Direct Lake | 进口 | DirectQuery（直接查询） |
|---|---|---|---|---|
| 授权 | 仅 Fabric 容量订阅 (SKU) | 仅 Fabric 容量订阅 (SKU) | 任何 Fabric 或 Power BI 许可证（包括Microsoft Fabric 免费许可证） | 任何 Fabric 或 Power BI 许可证（包括Microsoft Fabric 免费许可证） |
| 数据源 | 任何由 Delta 表支持的 Fabric 数据源的表 | 仅湖屋或仓库表（或视图） | 任何连接器 | 支持 DirectQuery 模式的任何连接器 |
| 连接到 SQL 分析终结点视图 | 不 | 是 - 但将自动回退到 DirectQuery 模式 | 是的 | 是的 |
| 复合模型 | 否 1 | 否 1 | 是 - 可以与 DirectQuery 或双存储模式表结合使用 | 是 - 可以与导入或双重存储模式表结合使用 |
| 单一登录 （SSO） | 是的 | 是的 | 不適用 | 是的 |
| 计算表 | 是 - 但计算不能引用 Direct Lake 模式下的表列。 | 否 – 除了 计算组、模拟参数，以及 字段参数，这些都隐式创建计算表。 | 是的 | 否——即使计算表引用了处于 DirectQuery 模式的其他表，它们仍然会使用导入存储模式。 |
| 计算列 | 是 - 但计算不能引用 Direct Lake 模式下的表列。 | 不 | 是的 | 是的 |
| 混合表 | 不 | 不 | 是的 | 是的 |
| 模型表分区 | 否 – 但是，可以在 Delta 表级别执行分区 | 否 – 但是，可以在 Delta 表级别执行分区 | 是 - 由增量刷新自动创建，或者使用 XMLA 终结点手动创建 | 不 |
| 用户定义的聚合 | 不 | 不 | 是 - 支持在 DirectQuery 表上导入聚合表 | 是的 |
| SQL 分析终端对象级别安全或列级别安全 | 不 | 是 - 但在拒绝权限时可能会生成错误 | 是 - 但必须使用语义模型对象级安全性复制权限 | 是 - 但当权限被拒绝时，查询可能会生成错误 |
| SQL 分析端点行级安全性 （RLS） | 不 | 是 - 但查询将回退到 DirectQuery 模式 | 是的——但必须用语义模型 RLS 复制权限 | 是的 |
| 语义模型行级安全性 (RLS) | 是 - 但强烈建议使用 固定标识 云连接 | 是 - 但强烈建议使用 固定标识 云连接 | 是的 | 是的 |
| 语义模型对象级安全性 （OLS） | 是的 | 是的 | 是的 | 是的 |
| 没有刷新要求的大型数据卷 | 是的 | 是的 | 不 | 是的 |
| 减少数据延迟 | 是 – 启用 自动更新 或编程重新帧时 | 是 – 启用 自动更新 或编程重新帧时 | 不 | 是的 |
| Power BI Embedded（嵌入式分析功能） | 是 2 | 是 2 | 是的 | 是的 |
1 在 SQL 终结点上使用 Direct Lake 时，不能将 Direct Lake 存储模式表与 同一语义模型中的 DirectQuery 或双存储模式表组合在一起。 但是，可以使用 Power BI Desktop 在 Direct Lake 语义模型上创建复合模型，然后使用新表（使用 Import、DirectQuery 或双存储模式）或计算对其进行扩展。 有关详细信息，请参阅 在语义模型上生成复合模型。
2 需要 V2 嵌入令牌。 如果使用服务主体，则必须使用固定标识云连接。
Direct Lake 的工作原理
通常，发送到 Direct Lake 语义模型的查询通过来自 Delta 表的列的内存缓存进行处理。 Delta 表的基础存储是 OneLake 中的一个或多个 Parquet 文件。 Parquet 文件按列而不是行整理数据。 语义模型将 Delta 表中的整个列加载到内存中，因为查询需要这些列。
OneLake 上的 Direct Lake 与 SQL 终结点不耦合，从而实现了与 OneLake 功能（如 OneLake 安全性）的更紧密集成，并带来了更高效的 DAX 查询计划，例如，无需单独检查 SQL 基于的安全性。 OneLake 上的 Direct Lake 不支持 DirectQuery 回退。
使用 SQL 终结点上的 Direct Lake，DAX 查询可能会使用 DirectQuery 回退，这意味着可以无缝切换到 DirectQuery 模式。 DirectQuery 回退直接从湖屋的 SQL 分析终结点或仓库检索数据。 例如，在 SQL 终结点中检测到基于 SQL 的安全性时，会发生回退。 在这种情况下，DirectQuery 操作会将查询发送到 SQL 分析终结点。 回退操作可能会导致查询性能变慢。
以下部分介绍 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 语义模型。
自动更新
有一个语义模型级设置，用于自动更新 Direct Lake 表。 默认情况下，它已启用。 它可确保 OneLake 中的数据更改自动反映在 Direct Lake 语义模型中。 如果要通过框架控制数据更改，应禁用自动更新，如上一部分所述。 有关详细信息，请参阅 管理 Direct Lake 语义模型。
提示
你可以在 Power BI 报表中设置自动页面刷新。 它是一项自动刷新特定报表页的功能，条件是该报表连接到 Direct Lake 语义模型（或其他类型的语义模型）。
DirectQuery 回退
在 SQL 终结点上使用 Direct Lake 时，发送到 Direct Lake 语义模型的查询可以回退到 DirectQuery 模式 ，在这种情况下，表不再在 Direct Lake 模式下运行。 它会直接从湖屋或仓库的 SQL 分析终结点检索数据。 此类查询始终返回最新数据，因为它们不受最后一次帧操作的时间点的约束。
发生 DirectQuery 回退时，查询不再使用 Direct Lake 模式。 当语义模型查询 SQL 分析终结点中的视图或强制实施行级别安全性的 SQL 分析终结点中的表时，查询不能利用 Direct Lake 模式。 此外，当 Delta 表超出容量限制时，查询将无法利用 Direct Lake 模式。
重要
如果可能，应始终设计解决方案（或调整容量大小），以避免 DirectQuery 回退。 这是因为这可能会导致查询性能变慢。
通过设置 DirectLakeBehavior 属性，您可以控制 Direct Lake 语义模型的回退。 此设置仅适用于 SQL 终结点上的 Direct Lake。 OneLake 上的 Direct Lake 不支持 DirectQuery 回退机制。 有关详细信息，请参阅设置 Direct Lake 行为属性。
数据安全性和访问权限
默认情况下，Direct Lake 使用单一登录（SSO），这意味着查询语义模型（通常是报表用户）的标识必须有权访问数据。 或者，可以将 Direct Lake 模型绑定到可共享云连接（SCC），以提供固定标识并禁用 SSO。 在这种情况下，只有固定标识需要具备对源中数据的读取权限。
Fabric 项目权限
Direct Lake 语义模型遵循分层安全模型。 它们执行权限检查，以确定尝试访问数据的标识在源数据项和语义模型中是否具有必要的数据访问权限。 可以在 Microsoft Fabric 中使用工作区角色直接分配或隐式获取权限。
请务必知道 OneLake 上的 Direct Lake 和 SQL 终结点上的 Direct Lake 以不同的方式执行权限检查。
- OneLake 上的 Direct Lake 需要湖屋/仓库上的 Read 和 ReadAll 权限才能访问 Delta 表。
- SQL 终结点上的 Direct Lake 需要湖屋/仓库上的 Read 和 ReadData 权限才能访问 SQL 分析终结点中的数据。
注意
OneLake 上的 Direct Lake 要求用户拥有对 OneLake 中的 Delta 表的读取权限，而不一定需要拥有对 SQL 终结点的读取权限。 这强制实施集中式安全设计，其中 OneLake 是单一访问控制源。
另一方面，SQL 终结点上的 Direct Lake 要求用户具有对 SQL 终结点的读取访问权限，不一定有权访问 OneLake 中的 Delta 表。 这是因为 Fabric 向语义模型授予读取 Delta 表和关联的 Parquet 文件所需的权限（将列数据加载到内存中）。 语义模型还具有定期读取 SQL 分析终结点以执行权限检查所需的权限，以确定查询用户（或固定标识）可以访问哪些数据。
语义模型权限
除了 Fabric 项权限，还必须向用户授予权限，以便他们能够使用或管理 Direct Lake 语义模型。 简言之，报表使用者需要 读取 权限，报表创建者需要其他 生成 权限。 可以直接分配语义模型权限，也可以通过使用工作区角色隐式获取语义模型权限。 若要管理语义模型设置（用于刷新和其他配置），你必须是 语义模型所有者。
权限要求
请考虑以下方案和权限要求。
| 情景 | 所需的权限 | 注释 |
|---|---|---|
| 用户可以查看报表 | 授予报表的读取权限和语义模型的读取权限。 如果语义模型在 SQL 终结点上使用 Direct Lake，并且云连接使用 SSO，则需至少授予对湖屋或仓库的 Read 和 ReadData 权限。 如果语义模型使用 OneLake 上的 Direct Lake，并且云连接使用 SSO，请至少授予 OneLake 中 Delta 表的 读取 和 ReadAll 权限。 |
报表不需要与语义模型属于同一工作区。 有关详细信息，请参阅面向只读使用者的策略。 |
| 用户可以创建报表 | 授予语义模型的 生成 权限。 如果语义模型在 SQL 终结点上使用 Direct Lake，并且云连接使用 SSO，则需至少授予对湖屋或仓库的 Read 和 ReadData 权限。 如果语义模型使用 OneLake 上的 Direct Lake，并且云连接使用 SSO，请至少授予 OneLake 中 Delta 表的 读取 和 ReadAll 权限。 |
有关详细信息，请参阅 内容创建者战略。 |
| 用户可以查看报表，但拒绝在 OneLake 中查询 Lakehouse、SQL 分析终结点或 Delta 表 | 授予报表的读取权限和语义模型的读取权限。 不要向用户授予对湖屋、仓库或 Delta 表的任何权限。 |
仅当 Direct Lake 模型通过禁用 SSO 的云连接使用固定标识时适用。 |
| 管理语义模型，包括刷新设置 | 需要语义模型所有权。 | 有关详细信息，请参阅 语义模型所有权。 |
重要
在将语义模型和报表发布到生产环境之前，应始终全面测试权限。
有关详细信息，请参阅 语义模型权限。
织物容量要求
Direct Lake 语义模型需要 Fabric 容量许可证。 此外，还有适用于 Fabric 容量订阅（SKU）的容量防护措施和限制，如下表所示。
重要
下表中的第一列还包括 Power BI Premium 容量订阅（P SKU）。 Microsoft正在整合购买选项，并停用按容量收费的 Power BI Premium SKU。 新客户和现有客户应考虑改为购买 Fabric 容量订阅 (F SKU)。
有关详细信息，请参阅 Power BI Premium 许可 和 Power BI Premium的重要更新。
| 织物 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 | 无限制 | 二十五 |
| 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 语义模型的功能和功能正在迅速演变。 请务必定期回查，查看最新的注意事项和限制列表。
| 注意事项/限制 | OneLake 上的 Direct Lake | SQL 终结点上的 Direct Lake |
|---|---|---|
| 当 SQL 分析终结点强制实施行级别安全性时，DAX 查询会根据所使用的 Direct Lake 模式类型以不同的方式进行处理。 使用 OneLake 上的 Direct Lake 时，查询将成功，并且不会应用基于 SQL 的 RLS。 OneLake 上的 Direct Lake 要求用户有权访问 OneLake 中的文件，后者不观察基于 SQL 的 RLS。 |
查询将成功。 | 是的，除非禁用回退，在这种情况下查询将失败。 |
| 如果语义模型中的表基于（非具体化）SQL 视图，则根据所使用的 Direct Lake 模式类型，以不同的方式处理 DAX 查询。 在这种情况下，SQL 终结点上的 Direct Lake 将回退到 DirectQuery。 不支持在 OneLake 表上依据非物化 SQL 视图创建 Direct Lake。 由于 Delta 表已创建，因此你可以改用湖屋具体化视图。 或者，对于基于非具体化 SQL 视图的表，请使用其他存储模式，例如 Import 或 DirectLake。 |
不適用 | 是的，除非禁用回退，在这种情况下查询将失败。 |
| 目前不支持复合建模，这意味着 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 所在区域。 | 是的 | 是的 |
| 嵌入报表需要 V2 嵌入令牌。 | 是的 | 不支持 |
| Direct Lake 不支持使用服务主体配置文件进行身份验证。 | 不支持 | 是的 |
| Power BI Direct Lake 语义模型可由服务主体创建和查询，并且支持具有服务主体的查看者角色成员资格，但湖屋/仓库上的默认 Direct Lake 语义模型不支持此场景。 | 是的 | 是的 |
| 湖屋中的快捷方式可用作语义模型表的数据源。 | 公开预览版不支持此功能 | 是的 |
| 个人工作区（我的工作区）不支持 Direct Lake 模型。 | 不支持 | 不支持 |