管理 Direct Lake 语义模型
本文介绍与管理 Direct Lake 语义模型相关的设计主题。
发布后任务
首次发布 Direct Lake 语义模型以供报告后，应立即完成一些发布后任务。 这些任务也可以在语义模型的生命周期内随时进行调整。
（可选）还可以设置数据发现，以允许报表创建者读取元数据，帮助他们发现 OneLake 数据中心中的数据并请求访问它。 还可以 认可 语义模型，以传达它表示适合使用的质量数据。
设置云连接
Direct Lake 语义模型使用云连接连接到 SQL 分析终结点。 它允许访问源数据，即 OneLake 中的 Parquet 文件（Direct Lake 存储模式（涉及将列数据加载到内存中）或 SQL 分析终结点（当查询 回退 到 DirectQuery 模式时）。
默认云连接
创建 Direct Lake 语义模型时，将使用默认云连接。 它利用单一登录（SSO），这意味着查询语义模型（通常是报表用户）的标识用于查询 SQL 分析终结点数据。
可共享云连接
（可选）可以创建可共享的云连接（SCC），以便可以使用固定标识连接到数据源。 它可以帮助企业客户保护其组织数据存储。 IT 部门可以管理凭据、创建 SC，并与目标创建者共享这些凭据，以便进行集中访问管理。
若要设置固定标识，请参阅 指定 Direct Lake 语义模型的固定标识。
身份验证
固定标识可以使用 OAuth 2.0 或服务主体进行身份验证。
注意
仅支持 Microsoft Entra 身份验证。 因此， Direct Lake 语义模型不支持基本 身份验证。
OAuth 2.0
使用 OAuth 2.0 时，可以使用 Microsoft Entra 用户帐户进行身份验证。 用户帐户必须具有查询 SQL 分析终结点表和视图以及架构元数据的权限。
不建议使用特定用户帐户。 这是因为，如果密码更改或用户帐户被删除（例如员工离开组织时），语义模型查询将失败。
服务主体
建议使用服务主体进行身份验证，因为它不依赖于特定的用户帐户。 安全主体必须具有查询 SQL 分析终结点表和视图以及架构元数据的权限。
为了保持连续性，服务主体凭据可以通过机密/证书轮换进行管理。
注意
Fabric 租户设置必须允许服务主体，并且服务主体必须属于声明的安全组。
单一登录
创建可共享云连接时， 默认情况下将取消选中“单一登录 ”复选框。 使用固定标识时，这是正确的设置。
如果希望查询语义模型的标识也查询 SQL 分析终结点，则可以启用 SSO。 在此配置中，Direct Lake 语义模型将使用固定标识刷新模型和用户标识来查询数据。
使用固定标识时，通常禁用 SSO，以便将固定标识用于刷新和查询，但不需要这样做。
云连接的建议做法
下面是与云连接相关的建议做法：
- 如果所有用户都可以访问数据（并且有权这样做），则无需创建共享云连接。 相反，可以使用默认的云连接设置。 在这种情况下，查询模型的用户标识应回退到 DirectQuery 模式。
- 如果要使用固定标识查询源数据，请创建共享云连接。 这可能是因为查询语义模型的用户没有授予读取 Lakehouse 或仓库的权限。 当语义模型强制实施 RLS 时，此方法尤其相关。
- 如果使用固定标识，请使用 服务主体 选项，因为它更安全且更可靠。 这是因为它不依赖于单个用户帐户或其权限，如果更改密码或离开组织，则不需要维护（和中断）。
- 如果必须将不同的用户限制为仅访问数据子集（如果可行）仅在语义模型层强制实施 RLS。 这样，用户将受益于高性能内存中查询。
- 如果可能，请避免 OLS 和 CLS，因为它会导致报表视觉对象中的错误。 错误可能会给用户造成混淆或关注。 对于可汇总列，请考虑创建在某些条件下返回 BLANK 的度量值，而不是 CLS（如果可能）。
管理安全角色成员身份
如果 Direct Lake 语义模型强制实施 行级别安全性 （RLS），则可能需要管理分配给安全角色的成员。 有关详细信息，请参阅 管理模型的安全性。
设置 Fabric 项权限
Direct Lake 语义模型遵循分层安全模型。 它们通过 SQL 分析终结点执行权限检查，以确定尝试访问数据的标识是否具有必要的数据访问权限。
必须向用户授予权限，以便他们可以使用或管理 Direct Lake 语义模型。 简言之，报表使用者需要 读取 权限，报表创建者需要 生成 权限。 可以直接 分配 语义模型权限，也可以 通过工作区角色隐式获取。 若要管理语义模型设置（用于刷新和其他配置），你必须是 语义模型所有者。
根据设置的云连接以及用户是否需要查询 Lakehouse 或仓库 SQL 分析终结点，可能需要授予其他权限（本部分中的表中所述）。
注意
值得注意的是，用户永远不需要在 OneLake 中读取数据的权限。 这是因为 Fabric 向语义模型授予读取 Delta 表和关联的 Parquet 文件所需的权限（将 列数据 加载到内存中）。 语义模型还具有定期读取 SQL 分析终结点以执行权限检查所需的权限，以确定查询用户（或固定标识）可以访问哪些数据。
请考虑以下方案和权限要求。
| 场景 | 所需的权限 | 注释 |
|---|---|---|
| 用户可以查看报表 | • 授予报表的读取权限，并为语义模型授予读取权限。 • 如果 云连接 使用 SSO，请至少 授予 Lakehouse 或仓库的读取 权限。 |
报表不需要与语义模型属于同一工作区。 有关详细信息，请参阅 只读使用者的策略。 |
| 用户可以创建报表 | • 授予 语义模型的生成 权限。 • 如果云连接使用 SSO，请至少 授予 Lakehouse 或仓库的读取 权限。 |
有关详细信息，请参阅 内容创建者的策略。 |
| 用户可以查询语义模型，但拒绝查询 Lakehouse 或 SQL 分析终结点 | • 不授予湖屋或仓库的任何权限。 | 仅当云连接使用固定标识时适用。 |
| 用户可以查询语义模型和 SQL 分析终结点，但拒绝查询 Lakehouse | • 授予 Lakehouse 或仓库的读取 和 ReadData 权限。 | 重要说明：发送到 SQL 分析终结点的查询将绕过语义模型强制实施的数据访问权限。 |
| 管理语义模型，包括刷新设置 | • 需要语义模型所有权。 | 有关详细信息，请参阅 语义模型所有权。 |
重要
在将语义模型和报表发布到生产环境之前，应始终全面测试权限。
有关详细信息，请参阅语义模型权限。
刷新 Direct Lake 语义模型
刷新 Direct Lake 语义模型会导致 框架 操作。 可以触发刷新操作：
- 手动，通过在 Fabric 门户中执行按需刷新，或者通过 SQL Server Management Studio （SSMS） 中的脚本执行表格模型脚本语言（TMSL）刷新命令，或使用通过 XMLA 终结点连接的第三方工具。
- 通过在 Fabric 门户中设置 刷新计划 ，自动。
- 自动，在基础 Delta 表中检测到更改时，有关详细信息，请参阅 自动更新 （下一步所述）。
- 以编程方式，通过使用 Power BI REST API 或 TOM 触发刷新。 可以触发编程刷新，作为提取、转换和加载过程的最后一步。
自动更新
有一个名为 “使 Direct Lake 数据保持最新 状态”的语义模型级设置，用于自动更新 Direct Lake 表。 默认情况下启用筛选器功能。 它可确保 OneLake 中的数据更改自动反映在 Direct Lake 语义模型中。 该设置在 Fabric 门户中的 语义模型设置的“刷新 ”部分中可用。
启用设置后，每当检测到基础 Delta 表中的数据修改时，语义模型将执行框架操作。 帧操作始终特定于检测到数据修改的那些表。
我们建议你保留该设置，尤其是在具有小型或中型语义模型时。 当你的低延迟报告要求和增量表定期修改时，它特别有用。
在某些情况下，可能需要禁用自动更新。 例如，在向语义模型的使用者公开任何新数据之前，可能需要允许完成数据准备作业或 ETL 过程。 禁用后，可以使用编程方法（前面所述）触发刷新。
注意
当刷新期间遇到不可恢复的错误时，Power BI 会暂停自动更新。 例如，在多次尝试后刷新失败时，可能会出现不可恢复的错误。 因此，请确保可以成功刷新语义模型。 当后续按需刷新完成且没有错误时，Power BI 会自动恢复自动更新。
预热缓存
Direct Lake 语义模型刷新操作可能会从内存中逐出所有驻留列。 这意味着刷新 Direct Lake 语义模型后的第一个查询可能会经历一些延迟，因为 列被加载到内存中。 仅当数据量非常大时，延迟才明显。
若要避免此类延迟，请考虑通过以编程方式 将查询 发送到语义模型来预热缓存。 发送查询的一种便捷方法是使用 语义链接。 刷新操作完成后，应立即完成此操作。
重要
如果延迟不能接受，则缓存变暖可能才有意义。 请注意不要将不必要的数据加载到内存中，这可能会给其他容量工作负荷带来压力，从而导致它们受到限制或被取消特权。
设置 Direct Lake 行为属性
可以通过设置 DirectLakeBehavior Direct Lake 语义模型的属性来控制 Direct Lake 语义模型的回退。 它可以设置为：
- 自动：（默认）如果所需的数据无法有效地加载到内存中，查询 将回退到 DirectQuery 模式 。
- DirectLakeOnly：所有查询仅使用 Direct Lake 存储模式。 已禁用回退到 DirectQuery 模式。 如果无法将数据加载到内存中，则返回错误。
- DirectQueryOnly：所有查询仅使用 DirectQuery 模式。 使用此设置测试回退性能，例如，可以在连接报表中观察查询性能。
可以在 Web 建模体验中设置属性，也可以使用表格对象模型（TOM）或表格模型脚本语言（TMSL）设置属性。
提示
如果只想在 Direct Lake 存储模式下处理查询，请考虑禁用 DirectQuery 回退。 建议在不想回退到 DirectQuery 时禁用回退。 如果想要分析 Direct Lake 语义模型的查询处理，以确定回退的发生频率和频率，也很有帮助。
监视 Direct Lake 语义模型
可以监视 Direct Lake 语义模型以确定报表视觉对象 DAX 查询的性能，或确定它何时回退到 DirectQuery 模式。
可以使用 性能分析器、SQL Server Profiler、Azure Log Analytics 或开源社区工具（如 DAX Studio）。
性能分析器
可以使用 Power BI Desktop 中的性能分析器来记录更新由于任何用户交互导致运行查询的用户交互而启动的报表元素所需的处理时间。 如果监视结果显示 直接查询 指标，则表示 DAX 查询是在 DirectQuery 模式下处理的。 如果没有该指标，DAX 查询是在 Direct Lake 模式下处理的。
有关详细信息，请参阅使用性能分析器进行分析。
SQL Server Profiler
可以使用 SQL Server Profiler 通过跟踪查询事件来检索有关查询性能的详细信息。 它使用SQL Server Management Studio (SSMS)进行安装。 在开始之前，请确保已安装最新版本的 SSMS。
有关详细信息，请参阅 使用 SQL Server Profiler 进行分析。
重要
通常，Direct Lake 存储模式提供快速查询性能，除非需要回退到 DirectQuery 模式。 由于回退到 DirectQuery 模式可能会影响查询性能，因此必须分析 Direct Lake 语义模型的查询处理，以确定回退的频率和原因。
Azure Log Analytics
可以使用 Azure Log Analytics 收集、分析和处理与 Direct Lake 语义模型关联的遥测数据。 它是 Azure Monitor 中的一项服务，Power BI 使用该服务来保存活动日志。
有关详细信息，请参阅 在 Power BI 中使用 Azure Log Analytics。