管理 Direct Lake 語意模型
本文說明與管理 Direct Lake 語意模型相關的設計主題。
發行後工作
在您第一次發佈可回報的 Direct Lake 語意模型之後，您應該立即完成一些發行後工作。 這些工作也可以在語意模型的生命週期中隨時調整。
您也可以選擇性地設定數據探索，以允許報表建立者讀取元數據，協助他們探索 OneLake 數據中樞中的數據，並要求存取它。 您也可以 背書 （認證或升階）語意模型，以傳達它代表適合使用的質量數據。
設定雲端連線
Direct Lake 語意模型會使用雲端連線來連線到 SQL 分析端點。 它可讓您存取源數據，也就是 OneLake 中的 Parquet 檔案（Direct Lake 儲存模式，其中包含將數據行數據載入記憶體中）或 SQL 分析端點（當查詢 回復 到 DirectQuery 模式時）。
默認雲端連線
當您建立 Direct Lake 語意模型時，會使用預設的雲端連線。 它會利用單一登錄 （SSO），這表示查詢語意模型（通常是報表使用者）的身分識別會用來查詢 SQL 分析端點數據。
可共用雲端連線
您可以選擇性地建立可共用的雲端連線 （SCC），以便使用固定身分識別建立數據源的連線。 它可協助企業客戶保護其組織數據存放區。 IT 部門可以管理認證、建立 SCC，並與預定的建立者共用，以進行集中式存取管理。
若要設定固定身分識別，請參閱 指定 Direct Lake 語意模型的固定身分識別。
驗證
固定身分識別可以使用 OAuth 2.0 或服務主體進行驗證。
注意
僅支援 Microsoft Entra 驗證。 因此， Direct Lake 語意模型不支援基本 身份驗證。
OAuth 2.0
當您使用 OAuth 2.0 時，可以使用 Microsoft Entra 使用者帳戶進行驗證。 用戶帳戶必須具有查詢 SQL 分析端點數據表和檢視表，以及架構元數據的許可權。
不建議使用特定的用戶帳戶。 這是因為，如果密碼變更或用戶帳戶遭到刪除，語意模型查詢將會失敗（例如當員工離開組織時）。
服務主體
使用服務主體進行驗證是建議的做法，因為它不相依於特定的用戶帳戶。 安全性主體必須具有查詢 SQL 分析端點數據表和檢視表，以及架構元數據的許可權。
為了保持持續性，服務主體認證可以透過秘密/憑證輪替來管理。
注意
網狀架構租用戶設定必須允許服務主體，而且服務主體必須屬於宣告的安全組。
單一登入
當您建立可共用的雲端連線時， 預設會取消核取 [單一登錄 ] 複選框。 這是使用固定身分識別時的正確設定。
當您想要查詢語意模型來查詢 SQL 分析端點的身分識別時，您可以啟用 SSO。 在此組態中，Direct Lake 語意模型會使用固定身分識別來重新整理模型和使用者身分識別來查詢數據。
使用固定身分識別時，通常會停用 SSO，讓固定身分識別同時用於重新整理和查詢，但不需要執行此動作。
雲端連線的建議做法
以下是與雲端連線相關的建議做法：
- 當所有使用者都可以存取數據時（且有權這麼做），就不需要建立共用雲端連線。 相反地，可以使用預設的雲端連線設定。 在此情況下，查詢模型的使用者身分識別應該回復為 DirectQuery 模式。
- 當您想要使用固定身分識別來查詢源數據時，請建立共用雲端連線。 這可能是因為查詢語意模型的使用者未獲授與讀取 Lakehouse 或倉儲的許可權。 當語意模型強制執行 RLS 時，此方法特別相關。
- 如果您使用固定身分識別，請使用 服務主體 選項，因為它更安全且可靠。 這是因為它不依賴單一用戶帳戶或其許可權，而且如果變更密碼或離開組織，則不需要維護（和中斷）。
- 如果不同的用戶必須限制為只存取數據子集，如果可行，請只在語意模型層強制執行 RLS。 如此一來，使用者將受益於記憶體內部查詢的高效能。
- 可能的話，請避免OLS和CLS，因為它會導致報表視覺效果中的錯誤。 錯誤可能會對使用者造成混淆或顧慮。 針對可摘要的數據行，請考慮建立在特定條件中傳回 BLANK 的量值，而不是 CLS（可能的話）。
管理安全性角色成員資格
如果您的 Direct Lake 語意模型強制執行 數據列層級安全性 （RLS），您可能需要管理指派給安全性角色的成員。 如需詳細資訊，請參閱 管理模型的安全性。
設定網狀架構項目許可權
Direct Lake 語意模型遵守分層式安全性模型。 他們會透過 SQL 分析端點執行許可權檢查，以判斷嘗試存取資料的身分識別是否具有必要的數據訪問許可權。
您必須將許可權授與使用者，才能使用或管理 Direct Lake 語意模型。 簡言之，報表取用者需要 讀取 許可權，而報表建立者需要 建置 許可權。 您可以 直接 指派語意模型許可權，或 透過工作區角色隱含取得。 若要管理語意模型設定（用於重新整理和其他組態），您必須是 語意模型擁有者。
視雲端連線設定而定，以及使用者是否需要查詢 Lakehouse 或倉儲 SQL 分析端點，您可能需要授與其他許可權（本節的表格中所述）。
注意
值得注意的是，使用者不需要在 OneLake 中讀取數據的許可權。 這是因為 Fabric 會將必要的許可權授與語意模型，以讀取 Delta 數據表和相關聯的 Parquet 檔案（將數據 行數據 載入記憶體中）。 語意模型也具有定期讀取 SQL 分析端點以執行許可權檢查的必要許可權，以判斷查詢使用者（或固定身分識別）可以存取的數據。
請考慮下列案例和許可權需求。
| 案例 | 所需的權限 | 註解 |
|---|---|---|
| 用戶可以檢視報表 | • 授 與報表的讀取 許可權，以及 語意模型的讀取 許可權。 • 如果 雲端連線 使用 SSO，請至少 授與 Lakehouse 或倉儲的讀取 許可權。 |
報表不需要屬於與語意模型相同的工作區。 如需詳細資訊，請參閱 唯讀取用者的策略。 |
| 使用者可以建立報表 | • 授 與語意模型的建 置許可權。 • 如果雲端連線使用 SSO，請至少 授與 Lakehouse 或倉儲的讀取 許可權。 |
如需詳細資訊，請參閱 內容建立者的策略。 |
| 用戶可以查詢語意模型，但拒絕查詢 Lakehouse 或 SQL 分析端點 | • 請勿授與湖屋或倉庫的任何許可權。 | 只有在雲端連線使用固定身分識別時才適用。 |
| 用戶可以查詢語意模型和 SQL 分析端點，但拒絕查詢 Lakehouse | • 授 與 Lakehouse 或倉儲的讀取 和 ReadData 許可權。 | 重要事項：傳送至 SQL 分析端點的查詢會略過語意模型強制執行的數據訪問許可權。 |
| 管理語意模型，包括重新整理設定 | • 需要語意模型擁有權。 | 如需詳細資訊，請參閱 語意模型擁有權。 |
重要
在將語意模型和報表發行至生產環境之前，您應該一律徹底測試許可權。
如需詳細資訊，請參閱語意模型權限。
重新整理 Direct Lake 語意模型
重新整理 Direct Lake 語意模型會導致 框架 作業。 可以觸發重新整理作業：
- 手動，在網狀架構入口網站中執行隨選重新整理，或從 SQL Server Management Studio （SSMS） 中的腳本執行表格式模型腳本語言 （TMSL） Refresh 命令，或使用透過 XMLA 端點連線的第三方工具。
- 自動，方法是在 Fabric 入口網站中設定 重新整理排程 。
- 自動，在基礎 Delta 數據表中偵測到變更時，如需詳細資訊，請參閱 自動更新 （如下所述）。
- 以程序設計方式，藉由使用 Power BI REST API 或 TOM來觸發重新整理。 您可以觸發程式設計重新整理，做為擷取、轉換和載入 （ETL） 程式的最後一個步驟。
自動更新
有一 個名為「讓您的 Direct Lake 數據保持最新 狀態」的語意模型層級設定，可自動更新 Direct Lake 數據表。 此項目預設為啟用。 它可確保 OneLake 中的數據變更會自動反映在 Direct Lake 語意模型中。 此設定可在網狀架構入口網站、語意模型設定的 [ 重新 整理] 區段中取得。
啟用設定時，每當偵測到基礎 Delta 資料表中的數據修改時，語意模型就會執行框架作業。 框架作業一律僅適用於偵測到數據修改的數據表。
建議您保留設定，特別是當您有小型或中型語意模型時。 當您有低延遲報告需求和 Delta 數據表定期修改時，特別有用。
在某些情況下，您可能想要停用自動更新。 例如，您可能需要允許完成數據準備作業或 ETL 程式，再將任何新數據公開給語意模型的取用者。 停用時，您可以使用程序設計方法觸發重新整理（如先前所述）。
注意
當重新整理期間發生無法復原的錯誤時，Power BI 會暫停自動更新。 例如，在多次嘗試之後，重新整理失敗時，可能會發生無法復原的錯誤。 因此，請確定您的語意模型可以順利重新整理。 當後續隨選重新整理完成時，Power BI 會自動繼續自動更新，而不會發生錯誤。
將快取暖
Direct Lake 語意模型重新整理作業可能會從記憶體收回所有常駐數據行。 這表示 Direct Lake 語意模型重新整理之後的第一個查詢可能會經歷一些延遲，因為 數據行會載入記憶體中。 只有在您擁有極大量的數據時，才會明顯出現延遲。
若要避免這類延遲，請考慮以程序設計方式 將查詢 傳送至語意模型來使快取變暖。 傳送查詢的便利方式是使用 語意連結。 重新整理作業完成之後，應該立即完成此作業。
重要
當延遲無法接受時，讓快取變暖可能才有意義。 請小心不要不必要地將數據載入記憶體中，這可能會對其他容量工作負載造成壓力，導致它們節流或變得無許可權。
設定 Direct Lake 行為屬性
您可以藉由設定 Direct DirectLakeBehavior Lake 語意模型的 屬性來控制後援。 它可以設定為：
- 自動:(預設） 如果必要數據無法有效率地載入記憶體，查詢 會回復為 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 監視器內的服務，Power BI 用來儲存活動記錄。
如需詳細資訊，請參閱 在 Power BI 中使用 Azure Log Analytics。