開發 Direct Lake 語意模型
本文說明與開發 Direct Lake 語意模型相關的設計主題。
建立模型
您可以使用網狀架構入口網站在工作區中建立 Direct Lake 語意模型。 這是一個簡單的過程，牽涉到從單一 Lakehouse 或倉儲中選取要新增至語意模型的數據表。
然後，您可以使用 Web 模型化體驗 進一步開發語意模型。 此體驗可讓您建立數據表之間的關聯性、建立量值和計算群組、標記日期數據表，以及設定模型及其對象的屬性（例如數據行格式）。 您也可以藉由定義角色和規則，以及將成員（Microsoft Entra 使用者帳戶或安全組）新增至這些角色，來設定模型 數據列層級安全性 （RLS）。
或者，您可以使用符合 XMLA 規範的工具繼續開發模型，例如 SQL Server Management Studio （SSMS） （19.1 版或更新版本）或開放原始碼社群工具。 如需詳細資訊，請參閱本文稍後的 XMLA 端點 模型寫入支援。
模型數據表
模型數據表是以數據表或 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 以 控制模型數據表或數據行的存取。 您需要使用開放原始碼社群工具，例如表格式編輯器來設定 OLS。
資料列層級安全性（RLS）
RLS 牽涉到限制對數據表中數據子集的存取。 例如，您可以使用 RLS 來確保銷售人員只能存取其銷售區域中客戶的銷售數據。
針對 SQL 分析端點，您可以設定 RLS 以 控制端點數據表中數據列的存取。
重要
當查詢使用 SQL 分析端點中有 RLS 的任何數據表時，它會回復為 DirectQuery 模式。 查詢效能可能會變慢。
針對語意模型，您可以設定 RLS 以 控制對模型數據表中數據列的存取。 您可以在 Web 模型化體驗中設定 RLS 或使用第三方工具。
如何評估查詢
開發 Direct Lake 語意模型 原因是在 OneLake 中達到大量數據的高效能查詢。 因此，您應該努力設計可最大化記憶體內查詢機率的解決方案。
下列步驟會大致瞭解查詢的評估方式（以及查詢是否失敗）。 只有在達到第五個步驟時，Direct Lake 儲存模式的優點才可行。
- 如果查詢包含任何受語意模型 OLS 限制的數據表或數據行，則會傳回錯誤結果（報表視覺效果無法轉譯）。
- 如果查詢包含任何受 SQL 分析端點 CLS 限制的數據行（或數據表遭到拒絕），則會傳回錯誤結果（報表視覺效果將無法轉譯）。
- 如果雲端連線使用 SSO（預設值），CLS 是由報表取用者的存取層級所決定。
- 如果雲端聯機使用固定身分識別，CLS 是由固定身分識別的存取層級所決定。
- 如果查詢包含 SQL 分析端點中的任何數據表，且該表強制執行 RLS 或使用檢視，則查詢將回退至 DirectQuery 模式。
- 如果雲端連線使用 SSO（預設值），RLS 是由報表取用者的存取層級所決定。
- 如果雲端聯機使用固定身分識別，RLS 是由固定身分識別的存取層級所決定。
- 如果查詢 超過容量的護欄，則會回復為 DirectQuery 模式。
- 否則，查詢將由記憶體快取中獲得滿足。 欄位數據 根據需要進行載入記憶體。
來源項目許可權
用來存取數據的帳戶是下列其中一項。
- 如果雲端連線使用 SSO（預設值），則為報表取用者。
- 如果雲端連線使用固定身分，那麼它就是固定身分。
帳戶至少必須具有來源專案 （lakehouse 或 warehouse） Read 和 ReadData 許可權。 項目許可權可以從工作區角色繼承，也可以為項目明確指派，如這篇文章中所述 。
假設符合此需求，Fabric 會授與語意模型必要的存取權，以讀取 Delta 表格和相關聯的 Parquet 檔案（將欄位數據載入記憶體），並可套用數據存取規則。
數據存取規則選項
您可以在下列項目中設定資料存取規則：
- 語意模型而已。
- 僅限 SQL 分析端點。
- 在語意模型和 SQL 分析端點中。
語意模型中的規則
如果您必須強制執行數據存取規則，則只要可行，就應該在語意模型中執行此動作。 這是因為語意模型強制執行的 RLS 是藉由篩選數據記憶體內部快取來達成，以達到高效能查詢。
當報表取用者未獲授與查詢資料湖庫或資料倉庫的許可權時，這也是一種適當的做法。
不論是哪一種情況，強烈建議雲端連線使用固定身分識別，而不是 SSO。 SSO 表示終端使用者可以直接存取 SQL 分析端點，因此可能會略過語意模型中的安全性規則。
重要
語意模型項目許可權 可以透過 Power BI 應用明確設定，或透過工作區角色取得隱含的 許可。
值得注意的是，語意模型數據存取規則不會針對具有語意模型 寫入 許可權的使用者強制執行。 相反地，數據存取規則會套用至指派給 Viewer 工作區角色的使用者。 不過，指派為 管理員、成員或 參與者 工作區角色的使用者，會隱含擁有對語意模型的 寫入 許可權，因此不會強制執行數據存取規則。 如需詳細資訊，請參閱 工作區中的角色。
SQL 分析端點中的規則
當語意模型 雲端連線 使用 單一登錄 （SSO）時，適合在 SQL 分析端點中強制執行數據存取規則。 這是因為使用者的身分識別會委派給查詢 SQL 分析端點，以確保查詢只傳回使用者允許存取的數據。 當使用者直接查詢 SQL 分析端點以取得其他工作負載時，也適合在此層級強制執行數據存取規則（例如，建立 Power BI 編頁報表或導出數據）。
不過，值得注意的是，當語意模型查詢包含任何在 SQL 分析端點中強制執行 RLS 的數據表時，會回復為 DirectQuery 模式。 因此，語意模型可能永遠不會將數據快取到記憶體中，以達到高效能查詢。
這兩個層級的規則
數據存取規則可以在這兩個層級強制執行。 不過，此方法牽涉到額外的複雜度和管理額外負荷。 在此情況下，強烈建議雲端連線使用固定身分識別，而不是 SSO。
數據存取規則選項的比較
下表比較數據數據存取設定選項。
| 將數據存取規則套用至 | 評論 |
|---|---|
| 僅語意模型 | 當使用者未獲得項目權限以查詢資料湖或資料倉儲時，請使用此選項。 設定雲端連線以使用固定身分識別。 您可以從記憶體內部快取達到高查詢效能。 |
| 僅限 SQL 分析端點 | 當使用者需要從倉儲或語意模型存取數據，並使用一致的數據存取規則時，請使用此選項。 請確保雲端連線已啟用 SSO。 查詢效能可能很慢。 |
| Lakehouse 或資料倉儲 和 語意模型 | 此選項牽涉到額外的管理額外負荷。 設定雲端連線以使用固定身分識別。 |
強制執行數據存取規則的建議做法
以下是與強制執行數據存取規則相關的建議做法：
- 如果不同的用戶必須限制為數據子集，只要可行，就只在語意模型層強制執行 RLS。 如此一來，使用者將受益於記憶體內部查詢的高效能。 在此情況下，強烈建議雲端連線使用固定身分識別，而不是 SSO。
- 可能的話，請避免在任一層強制執行 OLS 和 CLS，因為它會導致報表視覺效果發生錯誤。 錯誤可能會導致使用者混淆或擔心。 針對可摘要的資料行，請考慮建立在特定條件中傳回 BLANK 的度量值，而不是 CLS（如果可行的話）。
XMLA 端點的模型寫入支援
Direct Lake 語意模型使用 SSMS（19.1 或更新版本）和開放原始碼社群工具等工具來支援 XMLA 端點的寫入作業。
提示
如需使用第三方工具來開發、管理或優化語意模型的詳細資訊，請參閱 進階數據模型管理 使用案例。
您必須先針對容量啟用 XMLA 讀寫選項，才能執行寫入作業。 如需詳細資訊，請參閱 啟用 XMLA 讀寫。
使用 XMLA 端點支援的模型寫入作業：
- 自定義、合併、腳本、偵錯及測試 Direct Lake 模型元數據。
- 來源控制和版本控制、CI/CD 持續整合和持續部署，使用 Azure DevOps 和 GitHub。 如需詳細資訊，請參閱 內容生命週期管理。
- 自動化工作，例如語意模型重新整理，以及使用 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 區段的模式屬性設定為
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 語意模型的即時連線，然後使用新的量值加以擴充，然後從該處單擊選項來 變更此模型 新增數據表（使用 Import、DirectQuery 或雙重儲存模式）。 此動作會在 Direct Lake 模式下建立與語意模型的 DirectQuery 連線，因此數據表會顯示為 DirectQuery 的存取模式，但這並不表示需要回退至 DirectQuery。 只有這個新模型與 Direct Lake 模型之間的連線是 DirectQuery，而查詢仍會利用 Direct Lake 從 OneLake 取得數據。 如需詳細資訊，請參閱 在語意模型上建置複合模型。
- 以 SQL 分析端點欄位為基礎的欄位，套用動態資料遮罩。