管理 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 模式，则将使用查询模型的用户的标识。
- 如果要使用固定标识查询源数据，请创建共享云连接。 这可能是因为查询语义模型的用户没有被授予读取湖屋或仓库的权限。 当语义模型强制实施 RLS 时，此方法尤其相关。
- 如果使用固定标识，请使用“服务主体”选项，因为它更安全且更可靠。 这是因为它不依赖于单个用户帐户或其权限，如果他们更改密码或离开组织，则不需要维护（和中断）。
- 如果必须限制不同用户只能访问一部分数据，则如果可行，请仅在语义模型层强制执行 RLS。 这样，用户将受益于高性能内存中查询。
- 如果可能，请避免 OLS 和 CLS，因为它会导致报表视觉对象出现错误。 错误可能会让用户感到困惑或担忧。 对于可汇总列，考虑创建在某些条件下返回 BLANK 而不是 CLS 的度量（如果可能）。
管理安全角色成员身份
如果 Direct Lake 语义模型强制实施行级别安全性 (RLS)，则可能需要管理分配给安全角色的成员。 有关详细信息，请参阅管理模型的安全性。
设置 Fabric 项权限
Direct Lake 语义模型遵循分层安全模型。 它们通过 SQL 分析终结点执行权限检查，以确定尝试访问数据的标识是否具有必要的数据访问权限。
必须向用户授予权限，以便他们可以使用或管理 Direct Lake 语义模型。 简言之，报表使用者需要“读取”权限，报表创建者需要“生成”权限。 可以直接分配语义模型权限，也可以通过工作区角色隐式获取语义模型权限。 若要管理语义模型设置（用于刷新和其他配置），必须是语义模型所有者。
根据设置的云连接以及用户是否需要查询湖屋或仓库 SQL 分析终结点，可能需要授予其他权限（本部分中的表中所述）。
注意
值得注意的是，用户不需要权限即可读取 OneLake 中的数据。 这是因为 Fabric 向语义模型授予读取 Delta 表和关联的 Parquet 文件所需的权限（将列数据加载到内存中）。 语义模型还具有定期读取 SQL 分析终结点来执行权限检查以确定查询用户（或固定标识）可以访问哪些数据所需的权限。
请考虑以下应用场景和权限要求。
| 场景 | 所需的权限 | 注释 |
|---|---|---|
| 用户可以查看报表 | • 授予对报表的“读取”权限和对语义模型的“读取”权限。 • 如果云连接使用 SSO，请至少授予对湖屋或仓库的“读取”权限。 |
报表不需要与语义模型属于同一工作区。 有关详细信息，请参阅面向只读使用者的策略。 |
| 用户可以创建报表 | • 授予对语义模型的“生成”权限。 • 如果云连接使用 SSO，请至少授予对湖屋或仓库的“读取”权限。 |
有关详细信息，请参阅面向内容创建者的策略。 |
| 用户可以查询语义模型，但被拒绝查询湖屋或 SQL 分析终结点 | • 不要授予对湖屋或仓库的任何权限。 | 仅当云连接使用固定标识时适用。 |
| 用户可以查询语义模型和 SQL 分析终结点，但被拒绝查询湖屋 | • 授予对湖屋或仓库的“读取”和 ReadData 权限。 | 重要说明：发送到 SQL 分析终结点的查询将绕过语义模型强制实施的数据访问权限。 |
| 管理语义模型，包括刷新设置 | • 需要语义模型所有权。 | 有关详细信息，请参阅语义模型所有权。 |
重要
在将语义模型和报表发布到生产环境之前，应始终全面测试权限。
有关详细信息，请参阅语义模型权限。
刷新 Direct Lake 语义模型
刷新 Direct Lake 语义模型会导致组帧操作。 可以触发刷新操作：
- 手动：在 Fabric 门户中执行按需刷新，或从 SQL Server Management Studio (SSMS) 中的脚本执行表格模型脚本语言 (TMSL) 刷新命令，或使用通过 XMLA 终结点连接的第三方工具。
- 自动：在 Fabric 门户中设置刷新计划。
- 自动：当在基础 Delta 表中检测到更改时 — 有关详细信息，请参阅自动更新（如下所述）。
- 以编程方式：使用 Power BI REST API 或 TOM 触发刷新。 可以触发编程刷新作为提取、转换和加载 (ETL) 过程的最后一步。
自动更新
有一个名为“保持 Direct Lake 数据最新”的语义模型级设置，可以自动更新 Direct Lake 表。 默认情况下启用筛选器功能。 它可确保 OneLake 中的数据更改自动反映在 Direct Lake 语义模型中。 该设置在 Fabric 门户的语义模型设置的“刷新”部分中提供。
启用设置后，每当检测到基础 Delta 表中的数据修改时，语义模型将执行组框操作。 组帧操作始终特定于检测到数据修改的那些表。
建议保持启用该设置，尤其是在具有小型或中型语义模型时。 当你有低延迟报告要求并且增量表定期修改时，它特别有用。
在某些情况下，可能需要禁用自动更新。 例如，在向语义模型的使用者公开任何新数据之前，可能需要允许完成数据准备作业或 ETL 过程。 禁用后，可以使用编程方法（前面所述）触发刷新。
注意
当刷新期间遇到不可恢复的错误时，Power BI 会暂停自动更新。 例如，在多次尝试后刷新失败时，可能会出现不可恢复的错误。 因此，请确保可以成功刷新语义模型。 当后续按需刷新完成且没有错误时，Power BI 会自动恢复自动更新。
预热缓存
Direct Lake 语义模型刷新操作可能会从内存中逐出所有驻留列。 这意味着刷新 Direct Lake 语义模型后的第一个查询可能会遇到一些延迟，因为列会加载到内存中。 仅当数据量非常大时，延迟才明显。
若要避免此类延迟，请考虑通过以编程方式向语义模型发送查询来预热缓存。 发送查询的一种便捷方法是使用语义链接。 刷新操作完成后，应立即完成此操作。
重要
仅当延迟不可接受时，预热缓存才有意义。 注意不要不必要地将数据加载到内存中，因为这可能会对其他容量工作负载造成压力，导致它们受到限制或降低优先级。
设置 Direct Lake 行为属性
可以通过设置 Direct Lake 语义模型的 DirectLakeBehavior 属性来控制回退。 它可以设置为：
- 自动：（默认）如果无法有效地将所需数据加载到内存中，查询将回退到 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 中的性能分析器来记录更新报表元素所需的处理时间，这些报表元素是因任何导致运行查询的用户交互而启动的。 如果监视结果显示 Direct 查询指标，则表示 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。