本文說明與開發 Direct Lake 語意模型相關的設計主題。
建立模型
您可以在 Power BI Desktop 中，或從瀏覽器中的許多 Fabric 專案建立 Direct Lake 語意模型。 例如，從打開的 Lakehouse 中，您可以選擇 新增語意模型，在 Direct Lake 儲存模式中建立新的語意模型。
您可以在瀏覽器中使用 Power BI Desktop 或 Web 模型 來編輯語意模型，以新增關聯性、重新命名字段、新增量值和其他語意模型化工作。
或者，如同任何 Power BI 語意模型，您可以使用符合 XMLA 規範的工具繼續開發模型，例如 SQL Server Management Studio （SSMS） （19.1 版或更新版本）或開放原始碼社群工具。 如需詳細資訊，請參閱本文稍後 的 XMLA 端點模型寫入支援 。 Fabric 筆記本也能透過語意連結與語意連結實驗室，程式化地建立與編輯語意模型。
模型表
模型數據表是以數據表或 SQL 分析端點的檢視為基礎。 不過，請盡可能避免使用視圖。 以檢視為基礎的模型數據表查詢 會回復到 DirectQuery 模式，這可能會導致查詢效能變慢。
Warning
檢視只能在 SQL 上的 Direct Lake 中使用，而且無法在 OneLake 上的 Direct Lake 中使用。
除了支援模型關聯性的數據行之外，數據表應包含篩選、分組、排序和摘要的數據行。 不必要的欄位不會影響語意模型查詢效能，因為它們不會載入記憶體，但會導致 OneLake 的儲存空間變大，且需要更多運算資源來載入和維護。
Warning
不支援在 Direct Lake 語意模型中使用套用 動態數據遮罩 （DDM） 的數據行。
匯入表格可以透過 Direct Lake 新增到 OneLake 表格的語意模型中。 只要計算表未引用 Direct Lake 表，就可以添加。 您可以新增計算群組。
若要瞭解如何選取要包含在 Direct Lake 語意模型中的數據表，請參閱 編輯 Direct Lake 語意模型的數據表。
如需有關包含在語意模型資料表中的欄位的詳細資訊，請參閱 瞭解 Direct Lake 查詢效能。
強制執行數據存取規則
當您有將模型數據子集傳遞給不同使用者的需求時，您可以強制執行資料存取規則。 您可以藉由在 SQL 分析端點 或語意模型中設定物件層級安全性 （OLS） 和/或資料列層級安全性 （RLS） 來強制執行規則。
Note
強制執行數據存取規則的主題與語意模型（及相關 Fabric 項目）的管理者、內容取用者和建立者設定許可權這一主題不同，但密切相關。 如需設定許可權的詳細資訊，請參閱 管理 Direct Lake 語意模型。
物件層級安全性 （OLS）
OLS 牽涉到限制探索和查詢對象或數據行的存取。 例如，您可以使用 OLS 來限制可從 Salary 資料表存取 Employee 資料行的使用者。
針對 SQL 分析端點，您可以設定 OLS 來控制 端點物件的存取，例如數據表或檢視表，以及數據行層級安全性 （CLS） 來控制 端點數據表數據行的存取。
針對語意模型，您可以設定 OLS 來控制 模型數據表或數據行的存取。 您需要使用開放原始碼社群工具，例如表格式編輯器來設定 OLS。
資料列層級安全性（RLS）
RLS 牽涉到限制對數據表中數據子集的存取。 例如，您可以使用 RLS 來確保銷售人員只能存取其銷售區域中客戶的銷售數據。
針對 SQL 分析端點，您可以設定 RLS 來控制 對端點數據表中數據列的存取。
Important
當查詢使用 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） 的 讀取 和 ReadData 許可權。 項目許可權可以從工作區角色繼承，也可以為項目明確指派，如這篇文章中所述 。
假設符合此需求，Fabric 會授與語意模型必要的存取權，以讀取 Delta 表格和相關聯的 Parquet 檔案（將欄位數據載入記憶體），並可套用數據存取規則。
數據存取規則選項
您可以在下列項目中設定資料存取規則：
- 語意模型而已。
- 僅限 SQL 分析端點。
- 在語意模型和 SQL 分析端點中。
語意模型中的規則
如果您必須強制執行數據存取規則，則只要可行，就應該在語意模型中執行此動作。 這是因為語意模型強制執行的 RLS 是藉由篩選數據記憶體內部快取來達成，以達到高效能查詢。
當報表取用者未獲授與查詢資料湖庫或資料倉庫的許可權時，這也是一種適當的做法。
不論是哪一種情況，強烈建議雲端連線使用固定身分識別，而不是 SSO。 SSO 表示終端使用者可以直接存取 SQL 分析端點，因此可能會略過語意模型中的安全性規則。
Important
語意模型項目許可權可以透過Power BI 應用程式明確設定，或透過工作區角色隱含取得。
值得注意的是，語意模型數據存取規則不會針對具有語意模型 寫入 許可權的使用者強制執行。 相反地，數據存取規則會套用至指派給 查看器 工作區角色的使用者。 不過，指派給 系統管理員、 成員或 參與者 工作區角色的使用者隱含具有語意模型的 寫入 許可權，因此不會強制執行數據存取規則。 如需詳細資訊，請參閱 工作區中的角色。
SQL 分析端點中的規則
當語意模型 雲端 連線使用 單一登錄 （SSO） 時，適合在 SQL 分析端點中強制執行數據存取規則。 這是因為使用者的身分識別會委派給查詢 SQL 分析端點，以確保查詢只傳回使用者允許存取的數據。 當使用者直接查詢 SQL 分析端點以取得其他工作負載時，也適合在此層級強制執行數據存取規則（例如，建立 Power BI 編頁報表或導出數據）。
不過，值得注意的是，當語意模型查詢包含任何在 SQL 分析端點中強制執行 RLS 的數據表時，會回復為 DirectQuery 模式。 因此，語意模型可能永遠不會將數據快取到記憶體中，以達到高效能查詢。
這兩個層級的規則
數據存取規則可以在這兩個層級強制執行。 不過，此方法牽涉到額外的複雜度和管理額外負荷。 在此情況下，建議雲端連線使用固定身分識別，而不是 SSO。
數據存取規則選項的比較
下表比較數據數據存取設定選項。
| 將數據存取規則套用至 | Comment |
|---|---|
| 僅語意模型 | 當使用者未獲得項目權限以查詢資料湖或資料倉儲時，請使用此選項。 設定雲端連線以使用固定身分識別。 您可以從記憶體內部快取達到高查詢效能。 |
| 僅限 SQL 分析端點 | 當使用者需要從倉儲或語意模型存取數據，並使用一致的數據存取規則時，請使用此選項。 請確保雲端連線已啟用 SSO。 查詢效能可能很慢。 |
| Lakehouse 或資料倉儲和語意模型 | 此選項牽涉到額外的管理額外負荷。 設定雲端連線以使用固定身分識別。 |
強制執行數據存取規則的建議做法
以下是與強制執行數據存取規則相關的建議做法：
- 如果不同的用戶必須限制為數據子集，只要可行，就只在語意模型層強制執行 RLS。 如此一來，使用者就受益於高效能的記憶體內查詢。 在此情況下，強烈建議雲端連線使用固定身分識別，而不是 SSO。
- 可能的話，請避免在任一層強制執行 OLS 和 CLS，因為它會導致報表視覺效果發生錯誤。 錯誤可能會導致使用者混淆或擔心。 針對可摘要的資料行，請考慮建立在特定條件中傳回 BLANK 的度量值，而不是 CLS（如果可行的話）。
XMLA 端點的模型寫入支援
Direct Lake 語意模型使用 SSMS（19.1 或更新版本）和開放原始碼社群工具等工具來支援 XMLA 端點的寫入作業。
Tip
如需使用第三方工具來開發、管理或優化語意模型的詳細資訊，請參閱 進階數據模型管理 使用案例。
您必須先針對容量啟用 XMLA 讀寫選項，才能執行寫入作業。 如需詳細資訊，請參閱 啟用 XMLA 讀寫。
使用 XMLA 端點支援的模型寫入作業：
- 自定義、合併、腳本、偵錯及測試 Direct Lake 模型元數據。
- 來源控制和版本控制、CI/CD 持續整合和持續部署，使用 Azure DevOps 和 GitHub。 如需詳細資訊，請參閱 內容生命週期管理。
- 自動化工作，例如語意模型重新整理，以及使用 PowerShell 和 REST API 將變更套用至 Direct Lake 語意模型。
使用 XMLA 變更語意模型時，您必須更新已變更物件的 ChangedProperties 和 PBI_RemovedChildren 集合，以包含任何已修改或移除的屬性。 如果您未執行該更新，Power BI 模型化工具可能會在下次與 Lakehouse 同步處理架構時覆寫任何變更。
在 Power BI 語意模型的譜系標籤 一文中深入瞭解語意模型物件譜系標記。
Important
使用 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 語意模型。