管理 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 分析端點數據表和檢視表，以及架構元數據的許可權。
為了保持持續性，服務主體認證可以透過秘密/憑證輪替來管理。
注意
Fabric 租用戶設定必須允許服務主體，而且服務主體必須屬於指定的安全組。
單一登錄
當您建立可共用的雲端連線時，預設不會勾選 [單一登入] 複選框。 這是使用固定身分識別時的正確設定。
當您希望查詢語意模型的身分識別也能查詢 SQL 分析端點時，可以啟用 SSO。 在此組態中，Direct Lake 語意模型會使用固定身分識別來重新整理模型和使用者身分識別來查詢數據。
使用固定身分識別時，通常會停用 SSO，以便在重新整理和查詢時都使用固定身分識別，但從技術上講，並不必須這麼做。
雲端連線的建議做法
以下是與雲端連線相關的建議做法：
- 當所有使用者都可以存取數據時（且有權這麼做），就不需要建立共用雲端連線。 相反地，可以使用預設的雲端連線設定。 在此情況下，如果查詢返回到 DirectQuery 模式，將使用查詢模型的使用者身分識別。
- 當您想要使用固定身分識別來查詢源數據時，請建立共用雲端連線。 這可能是因為查詢語意模型的使用者沒有被授予閱讀 Lakehouse 或數據倉儲的許可權。 當語意模型強制執行 RLS 時，此方法特別相關。
- 如果您使用固定身分識別，請使用 服務主體 選項，因為它更安全且可靠。 這是因為它不依賴單一用戶帳戶或其許可權，而且如果變更密碼或離開組織，則不需要維護（和中斷）。
- 如果不同的用戶必須限制為只存取數據子集，如果可行，請只在語意模型層強制執行 RLS。 如此一來，使用者將受益於記憶體內部查詢的高效能。
- 如果可能，請避免使用OLS和CLS，因為它會導致報告視覺效果中的錯誤。 錯誤可能會對使用者造成混淆或顧慮。 針對可彙總的欄位，請考慮建立在特定條件下傳回 BLANK 的計算度量，而不是 CLS，如果可能。
管理安全角色的成員資格
如果您的 Direct Lake 語意模型強制執行 數據列層級安全性 （RLS），您可能需要管理指派給安全性角色的成員。 如需詳細資訊，請參閱 管理模型的安全性。
設定Fabric項目許可權
Direct Lake 語意模型遵守分層式安全性模型。 他們會透過 SQL 分析端點執行許可權檢查，以判斷嘗試存取資料的身分識別是否具有必要的數據訪問許可權。
您必須將許可權授與使用者，才能使用或管理 Direct Lake 語意模型。 簡言之，報表取用者需要 讀取 許可權，而報表建立者需要 建置 許可權。 語意模型許可權可以直接 指派，或透過工作區角色 隱含取得的指派。 若要管理語意模型設定（用於重新整理和其他組態），您必須是 語意模型擁有者。
視雲端連線設定而定，以及使用者是否需要查詢 Lakehouse 或倉儲 SQL 分析端點，您可能需要授與其他許可權（本節的表格中所述）。
註記
值得注意的是，使用者無需在 OneLake 中讀取數據的許可權。 這是因為 Fabric 會將必要的許可權授與語意模型，以讀取 Delta 數據表和相關聯的 Parquet 檔案（將數據行數據 載入記憶體中）。 語意模型也具有定期讀取 SQL 分析端點以執行許可權檢查的必要許可權，以判斷查詢使用者（或固定身分識別）可以存取的數據。
請考慮下列案例和許可權需求。
| 場景 | 所需權限 | 評論 |
|---|---|---|
| 用戶可以檢視報表 | • 為報表授與 讀取 許可權，及為語意模型授與 讀取 許可權。 • 如果 雲端連線 使用 SSO，請至少授與湖屋或倉儲 讀取 許可權。 |
報表不需要屬於與語意模型相同的工作區。 如需詳細資訊，請參閱 唯讀取用者的策略。 |
| 使用者可以建立報表 | • 授與語意模型的建置 許可權。 • 如果雲端連線使用 SSO，請至少授與湖屋或倉儲 讀取 許可權。 |
如需詳細資訊，請參閱 內容建立者策略。 |
| 用戶可以查詢語意模型，但拒絕查詢 Lakehouse 或 SQL 分析端點 | • 不可給予湖屋或倉庫任何許可權。 | 只有在雲端連線使用固定身分識別時才適用。 |
| 用戶可以查詢語意模型和 SQL 分析端點，但拒絕查詢 Lakehouse | • 為Lakehouse或倉儲授予讀取 和讀取資料的許可權。 | 重要：傳送至 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 行為屬性
您可以藉由設定其 DirectLakeBehavior 屬性來控制 Direct 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 中使用 效能分析工具，記錄由任何用戶互動引發的查詢所需的報表元素更新處理時間。 如果監視結果顯示 DirectQuery 度量，表示 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 日誌分析
您可以使用 Azure Log Analytics 來收集、分析和處理與 Direct Lake 語意模型相關聯的遙測數據。 這是 Azure 監視器 內服務，Power BI 會用來儲存活動記錄。
如需詳細資訊，請參閱 在 Power BI 中使用 Azure Log Analytics。