通过

开发 Direct Lake 语义模型

  • 项目

本文介绍与开发 Direct Lake 语义模型相关的设计主题。

创建模型

请使用 Fabric 门户在工作区中创建 Direct Lake 语义模型。 这是一个简单的过程，涉及选择从单个湖屋或仓库中添加哪些表到语义模型中。

然后，可以使用 Web 建模体验来进一步开发语义模型。 通过这种体验，可以创建表之间的关系、创建度量值和计算组、标记日期表以及设置模型及其对象的属性（如列格式）。 还可以通过定义角色和规则以及通过向这些角色添加成员（Microsoft Entra 用户帐户或安全组）来设置模型行级别安全性 (RLS)。

也可使用符合 XMLA 标准的工具（如 SQL Server Management Studio (SSMS)（版本 19.1 或更高版本））或开放源代码社区工具继续开发模型。 有关详细信息，请参阅本文后面的使用 XMLA 终结点的模型写入支持。

提示

通过完成此教程，可以了解如何创建湖屋、Delta 表和基本的 Direct Lake 语义模型。

模型表

模型表基于 SQL 分析终结点的表或视图。 但是，请尽可能避免使用视图。 这是因为对某个基于视图的模型表的查询将始终回退到 DirectQuery 模式，这可能会导致查询性能下降。

除了支持模型关系的列外，表还应包括用于筛选、分组、排序和汇总的列。 虽然不需要的列不会影响语义模型查询性能（因为它们不会加载到内存中），但它们会在 OneLake 中导致更大的存储大小，需要更多的计算资源来加载和维护。

警告

不支持在 Direct Lake 语义模型中使用那些应用动态数据掩码 (DDM) 的列。

若要了解如何选择要包含在 Direct Lake 语义模型中的表，请参阅编辑 Direct Lake 语义模型的表。

有关要包含在语义模型表中的列的详细信息，请参阅了解 Direct Lake 语义模型的存储。

强制执行数据访问规则

需要向不同用户提供模型数据的子集时，可以强制执行数据访问规则。 可以通过在 SQL 分析终结点或语义模型中设置对象级安全性 (OLS) 和/或行级别安全性 (RLS) 来强制执行规则。

注意

“强制执行数据访问规则”主题与适用于内容使用者、创建者以及将要管理语义模型（和相关的 Fabric 项）的用户的“设置权限”主题有所不同，但又有所关联。 若要详细了解如何设置权限，请参阅管理 Direct Lake 语义模型。

对象级安全性 (OLS)

OLS 涉及限制发现和查询对象或列所需的访问权限。 例如，可以使用 OLS 来限制可以访问 Employee 表中的 Salary 列的用户。

对于 SQL 分析终结点，可以设置 OLS 来控制对终结点对象（例如表或视图）的访问，并设置列级别安全性 (CLS) 来控制对终结点表列的访问。

对于语义模型，可以设置 OLS 来控制对模型表或列的访问。 需要使用开放源代码社区工具（如 Tabular Editor）来设置 OLS。

行级别安全性 (RLS)

RLS 涉及限制对表中数据子集的访问。 例如，可以使用 RLS 来确保销售人员只能访问其销售区域内的客户的销售数据。

对于 SQL 分析终结点，可以设置 RLS 来控制对终结点表中行的访问。

重要

当查询使用在 SQL 分析终结点中具有 RLS 的任何表时，查询将回退到 DirectQuery 模式。 查询可能会变慢。

对于语义模型，可以设置 RLS 来控制对模型表中行的访问。 可以在 Web 建模体验中设置 RLS，也可以使用第三方工具来这样做。

如何计算查询

开发 Direct Lake 语义模型的原因是为了实现对 OneLake 中大量数据的高性能查询。 因此，应该努力设计一个可最大限度地提高内存中查询机会的解决方案。

以下步骤大致说明了查询是如何计算的（以及查询是否失败）。 只有实现了第五步，才有可能发挥 Direct Lake 存储模式的优势。

  1. 如果查询包含任何受语义模型 OLS 限制的表或列，则会返回错误结果（报表视觉对象将无法呈现）。
  2. 如果查询包含任何受 SQL 分析终结点 CLS 限制的列（或表被拒绝），则会返回错误结果（报表视觉对象将无法呈现）。
    1. 如果云连接使用 SSO（默认设置），则 CLS 取决于报表使用者的访问级别。
    2. 如果云连接使用固定标识，则 CLS 取决于固定标识的访问级别。
  3. 如果查询包含在 SQL 分析终结点中强制执行 RLS 的任何表，或者如果使用了视图，则查询会回退到 DirectQuery 模式。
    1. 如果云连接使用 SSO（默认设置），则 RLS 取决于报表使用者的访问级别。
    2. 如果云连接使用固定标识，则 RLS 取决于固定标识的访问级别。
  4. 如果查询超出容量的护栏，则查询会回退到 DirectQuery 模式。
  5. 否则，查询将从内存中缓存得到满足。 当需要时，列数据就会加载到内存中。

源项权限

用于访问数据的帐户是下列帐户之一。

  • 如果云连接使用 SSO（默认设置），则它是报表使用者。
  • 如果云连接使用固定标识，则它是固定标识。

该帐户必须至少具有对源项（湖屋或仓库）的“读取”和“ReadData”权限。 项权限可能是从工作区角色继承的，也可能是按照此文中的说明为项显式分配的。

假定满足此要求，则 Fabric 会授予语义模型必要的访问权限，以读取 Delta 表和关联的 Parquet 文件（目的是将列数据加载到内存中），而数据访问规则可以得到应用。

数据访问规则选项

可以在以下位置中设置数据访问规则：

  • 仅语义模型。
  • 仅 SQL 分析终结点。
  • 语义模型和 SQL 分析终结点中。

语义模型中的规则

如果必须强制执行数据访问规则，则应在可行的情况下在语义模型中执行该操作。 这是因为语义模型强制执行的 RLS 是通过筛选内存中数据缓存来实现高性能查询而实现的。

当报表使用者没有被授予查询湖屋或仓库的权限时，这也是一种合适的方法。

无论哪种情况，强烈建议让云连接使用固定标识而不是 SSO。 SSO 意味着最终用户可以直接访问 SQL 分析终结点，因此可能会绕过语义模型中的安全规则。

重要

语义模型项权限可以通过 Power BI 应用显式设置，也可以通过工作区角色隐式获取。

值得注意的是，对于拥有语义模型“写入”权限的用户，不会强制执行语义模型数据访问规则。 与之相反，数据访问规则适用于那些分配有“观看者”工作区角色的用户。 但是，分配有“管理员”、“成员”或“参与者”工作区角色的用户隐式拥有语义模型的“写入”权限，因此系统不会强制执行数据访问规则。 有关详细信息，请参阅工作区中的角色。

SQL 分析终结点中的规则

当语义模型云连接使用单一登录 (SSO) 时，在 SQL 分析终结点中强制执行数据访问规则是适当的。 这是因为用户的标识被委托用来查询 SQL 分析终结点，确保查询仅返回用户获允访问的数据。 当用户直接为其他工作负载查询 SQL 分析终结点以执行特定操作（例如，创建 Power BI 分页报表或导出数据）时，在此级别强制执行数据访问规则也是适当的。

但值得注意的是，当语义模型查询包含在 SQL 分析终结点中强制执行 RLS 的任何表时，该查询会回退到 DirectQuery 模式。 因此，语义模型可能永远不会将数据缓存到内存中以实现高性能查询。

两个层的规则

数据访问规则可以在两个层上强制执行。 然而，这种方法涉及额外的复杂性和管理开销。 在这种情况下，强烈建议让云连接使用固定标识而不是 SSO。

数据访问规则选项的比较

下表比较了数据的数据访问设置选项。

将数据访问规则应用于 注释
仅语义模型 当用户没有被授予查询湖屋或仓库的项权限时，使用此选项。 设置云连接以使用固定标识。 可以通过内存中缓存实现高的查询性能。
仅 SQL 分析终结点 当用户需要从仓库或语义模型访问数据且使用的数据访问规则一致时，请使用此选项。 确保为云连接启用 SSO。 查询性能可能很低。
湖屋或仓库和语义模型 此选项涉及额外的管理开销。 设置云连接以使用固定标识。

下面是与强制执行数据访问规则相关的建议做法：

  • 如果不同用户只能访问不同的数据部分，则只要可行，就可以只在语义模型层强制执行 RLS。 这样，用户将受益于高性能内存中查询。 在这种情况下，强烈建议让云连接使用固定标识而不是 SSO。
  • 如果可能，请避免在任一层强制执行 OLS 和 CLS，因为它会导致报表视觉对象出现错误。 错误可能会导致用户感到困惑或担忧。 对于可汇总列，考虑创建在某些条件下返回 BLANK 而不是 CLS 的度量值（如果可能）。

使用 XMLA 终结点的模型写入支持

Direct Lake 语义模型通过使用 SSMS（19.1 或更高版本）之类的工具和开放源代码社区工具，支持使用 XMLA 终结点进行写入操作。

提示

若要详细了解如何使用第三方工具开发、管理或优化语义模型，请查看高级数据模型管理使用方案。

在执行写入操作之前，必须为容量启用 XMLA 读写选项。 有关详细信息，请参阅启用 XMLA 读写。

使用 XMLA 终结点支持的模型写入操作：

  • 自定义、合并、脚本编写、调试和测试 Direct Lake 模型元数据。
  • 使用 Azure DevOps 和 GitHub 进行源和版本控制、持续集成和持续部署 (CI/CD)。 有关详细信息，请参阅内容生命周期管理。
  • 自动化任务，例如语义模型刷新、使用 PowerShell 和 REST API 将更改应用于 Direct Lake 语义模型。

使用 XMLA 更改语义模型时，必须更新已更改对象的 ChangedProperties 和 PBI_RemovedChildren 集合，以包含任何已修改或已移除的属性。 如果不执行该更新，Power BI 建模工具可能会在下次同步架构时覆盖任何更改。

用于通过 XMLA 更改语义模型的受支持模型如下：

  • 表/列重命名（ChangeProperty = 名称）
  • 移除表（将表添加到查询表达式中的 PBI_RemovedChildren 注释）

重要

使用 XMLA 应用程序创建的 Direct Lake 表最初将处于未处理状态，直到应用程序发送刷新命令。 涉及未处理表的查询将始终回退到 DirectQuery 模式。 因此，创建新的语义模型时，请务必刷新该模型以处理其表。

有关详细信息，请参阅与 XMLA 终结点的语义模型连接。

Direct Lake 模型元数据

使用 XMLA 终结点连接到 Direct Lake 语义模型时，元数据看起来就像任何其他模型的元数据一样。 但是，Direct Lake 模型具有以下差异：

  • 数据库对象的 compatibilityLevel 属性为 1604（或更高）。
  • Direct Lake 分区的模式属性设置为 directLake。
  • Direct Lake 分区使用共享表达式来定义数据源。 表达式指向湖屋或仓库的 SQL 分析终结点。 Direct Lake 使用 SQL 分析终结点来发现架构和安全信息，但它直接从 OneLake 加载数据（除非它因任何原因回退到 DirectQuery 模式）。

发布后任务

发布 Direct Lake 语义模型后，应完成一些设置任务。 有关详细信息，请参阅“管理 Direct Lake 语义模型”。

不支持的功能

Direct Lake 语义模型不支持以下模型功能：

  • 引用 Direct Lake 存储模式下的表或列的计算表
  • 引用 Direct Lake 存储模式下的表或列的计算列
  • 混合表
  • 用户定义的聚合
  • 复合模型，因为不能在同一模型中将 Direct Lake 存储模式表与 DirectQuery 存储模式表或双存储模式表合并。 不过，可以使用 Power BI Desktop 创建与 Direct Lake 语义模型的实时连接，然后使用新的度量值对其进行扩展，然后就可以单击用于更改此模型的选项来添加新表（使用“导入”、“DirectQuery”或“双”存储模式）。 此操作在 Direct Lake 模式下创建与语义模型的 DirectQuery 连接，因此这些表显示为 DirectQuery 存储模式，但此存储模式并不表示回退到 DirectQuery。 只有这个新模型与 Direct Lake 模型之间的连接是 DirectQuery，而查询仍然利用 Direct Lake 从 OneLake 获取数据。 有关详细信息，请参阅“在语义模型上生成复合模型”。
  • 基于那些应用动态数据掩码的 SQL 分析终结点列的列。

相关内容