共用方式為

開發 Direct Lake 語意模型

  • 發行項

本文說明與開發 Direct Lake 語意模型相關的設計主題。

建立模型

您可以使用網狀架構入口網站在工作區中建立 Direct Lake 語意模型。 這是一個簡單的程式，牽涉到從單一 Lakehouse 或倉儲中選取要新增至語意模型的數據表。

然後 ，您可以使用 Web 模型化體驗 進一步開發語意模型。 此體驗可讓您建立數據表之間的關聯性、建立量值和計算群組、標記日期數據表，以及設定模型及其對象的屬性（例如數據行格式）。 您也可以藉由定義角色和規則，以及將成員（Microsoft Entra 使用者帳戶或安全組）新增至這些角色，來設定模型 數據列層級安全性 （RLS ）。

或者，您可以使用符合 XMLA 規範的工具繼續開發模型，例如 SQL Server Management Studio （SSMS） （19.1 版或更新版本）或開放原始碼社群工具。 如需詳細資訊，請參閱 本文稍後的 XMLA 端點 模型寫入支援。

提示

您可以完成 本教學課程，瞭解如何建立 Lakehouse、Delta 數據表和基本的 Direct Lake 語意模型。

模型數據表

模型數據表是以數據表或 SQL 分析端點的檢視為基礎。 不過，請盡可能避免使用檢視。 這是因為以檢視為基礎的模型數據表查詢一律 會回復到 DirectQuery 模式，這可能會導致查詢效能變慢。

除了支援模型關聯性的數據行之外，數據表應包含篩選、分組、排序和摘要的數據行。 雖然不必要的數據行不會影響語意模型查詢效能（因為它們不會載入記憶體中），但它們會導致 OneLake 中的記憶體大小較大，而且需要更多計算資源來載入和維護。

警告

不支援在 Direct Lake 語意模型中使用套用 動態數據遮罩 （DDM） 的數據行。

若要瞭解如何選取要包含在 Direct Lake 語意模型中的數據表，請參閱 編輯 Direct Lake 語意模型的數據表。

如需要包含在語意模型數據表中的數據行詳細資訊，請參閱 瞭解 Direct Lake 語意模型的記憶體。

強制執行數據存取規則

當您有將模型數據子集傳遞給不同使用者的需求時，您可以強制執行資料存取規則。 您可以藉由在 SQL 分析端點或語意模型中設定物件層級安全性 （OLS） 和/或資料列層級安全性 （RLS） 來強制執行規則。

注意

強制執行數據存取規則的主題與為管理語意模型的內容取用者、建立者和使用者設定許可權不同，但相關。 如需設定許可權的詳細資訊，請參閱 管理 Direct Lake 語意模型。

物件層級安全性 (OLS)

OLS 牽涉到限制探索和查詢對象或數據行的存取。 例如，您可以使用 OLS 來限制可從資料表存取 Salary 資料行 Employee 的使用者。

針對 SQL 分析端點，您可以設定 OLS 來控制 端點物件的存取，例如數據表或檢視表，以及數據行層級安全性 （CLS） 來控制 端點數據表數據行的存取。

針對語意模型，您可以設定 OLS 來控制 模型數據表或數據行的存取。 您需要使用開放原始碼社群工具，例如表格式編輯器來設定 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. 如果查詢包含強制執行 RLS 或檢視之 SQL 分析端點中的任何數據表，查詢就會回復為 DirectQuery 模式。
    1. 如果雲端連線使用 SSO（預設值），RLS 是由報表取用者的存取層級所決定。
    2. 如果雲端聯機使用固定身分識別，RLS 是由固定身分識別的存取層級所決定。
  4. 如果查詢 超過容量的護欄，則會回復為 DirectQuery 模式。
  5. 否則，會從記憶體內部快取滿足查詢。 數據行數據會在 需要時載入記憶體 中。

來源項目許可權

用來存取數據的帳戶是下列其中一項。

  • 如果雲端連線使用 SSO（預設值），則為報表取用者。
  • 如果雲端聯機使用固定身分識別，則為固定身分識別。

帳戶至少必須具有 來源專案 （Lakehouse 或 warehouse） 的讀取 和 ReadData 許可權。 項目許可權可以繼承自工作區角色，或為項目明確指派，如本文所述。

假設符合此需求，Fabric 會授與語意模型的必要存取權，以讀取 Delta 數據表和相關聯的 Parquet 檔案（將數據行數據載入記憶體中），並套用數據存取規則。

數據存取規則選項

您可以在下列項目中設定資料存取規則：

  • 僅限語意模型。
  • 僅限 SQL 分析端點。
  • 在語意模型和 SQL 分析端點中。

語意模型中的規則

如果您必須強制執行數據存取規則，則只要可行，就應該在語意模型中執行此動作。 這是因為語意模型強制執行的 RLS 是藉由篩選數據記憶體內部快取來達成，以達到高效能查詢。

當報表取用者未獲授與查詢 Lakehouse 或倉儲的許可權時，這也是適當的方法。

不論是哪一種情況，強烈建議雲端連線使用固定身分識別，而不是 SSO。 SSO 表示終端使用者可以直接存取 SQL 分析端點，因此可能會略過語意模型中的安全性規則。

重要

語意模型項目許可權可以透過Power BI 應用程式明確設定，或透過工作區角色隱含取得。

值得注意的是，語意模型數據存取規則不會針對具有 語意模型寫入 許可權的使用者強制執行。 相反地，數據存取規則會套用至指派給 查看器 工作區角色的使用者。 不過，指派給系統管理員、成員或參與者工作區角色的使用者隱含具有語意模型的寫入許可權，因此不會強制執行數據存取規則。 如需詳細資訊，請參閱 工作區中的角色。

SQL 分析端點中的規則

當語意模型雲端連線使用單一登錄 （SSO） 時，適合在 SQL 分析端點中強制執行數據存取規則。 這是因為使用者的身分識別會委派給查詢 SQL 分析端點，以確保查詢只傳回使用者允許存取的數據。 當使用者直接查詢 SQL 分析端點以取得其他工作負載時，也適合在此層級強制執行數據存取規則（例如，建立 Power BI 編頁報表或導出數據）。

不過，值得注意的是，當語意模型查詢包含任何在 SQL 分析端點中強制執行 RLS 的數據表時，會回復為 DirectQuery 模式。 因此，語意模型可能永遠不會將數據快取到記憶體中，以達到高效能查詢。

這兩個層級的規則

數據存取規則可以在這兩個層級強制執行。 不過，此方法牽涉到額外的複雜度和管理額外負荷。 在此情況下，強烈建議雲端連線使用固定身分識別，而不是 SSO。

數據存取規則選項的比較

下表比較數據數據存取設定選項。

將數據存取規則套用至 註解
僅限語意模型 當使用者未獲授與專案許可權來查詢 Lakehouse 或倉儲時，請使用此選項。 設定雲端連線以使用固定身分識別。 您可以從記憶體內部快取達到高查詢效能。
僅限 SQL 分析端點 當使用者需要從倉儲或語意模型存取數據，並使用一致的數據存取規則時，請使用此選項。 確定已啟用雲端連線的 SSO。 查詢效能可能很慢。
Lakehouse 或倉儲 和 語意模型 此選項牽涉到額外的管理額外負荷。 設定雲端連線以使用固定身分識別。

以下是與強制執行數據存取規則相關的建議做法：

  • 如果不同的用戶必須限制為數據子集，只要可行，就只在語意模型層強制執行 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 模型化工具可能會在下次與 Lakehouse 同步處理架構時覆寫任何變更。

在 Power BI 語意模型的 譜系標籤中深入瞭解語意模型物件譜系標記 文章。

重要

使用 XMLA 應用程式建立的 Direct Lake 數據表一開始會處於未處理的狀態，直到應用程式傳送重新整理命令為止。 涉及未處理數據表的查詢一律會回復為 DirectQuery 模式。 因此，當您建立新的語意模型時，請務必重新整理模型來處理其數據表。

如需詳細資訊，請參閱 與 XMLA 端點的語意模型連線。

Direct Lake 模型中繼資料

當您使用 XMLA 端點連線到 Direct Lake 語意模型時，元數據看起來會像任何其他模型一樣。 然而，Direct Lake 模型顯示出以下差異：

  • 資料庫 compatibilityLevel 物件的 屬性為 1604 （或更新版本）。
  • Direct Lake 資料分割的 mode 屬性會設定為 directLake。
  • Direct Lake 分割區使用共用運算式來定義資料來源。 表達式會指向 Lakehouse 或 warehouse 的 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 分析端點數據行為基礎的數據行，這些數據行會套用動態數據遮罩。

相關內容