Direct Lake

  • 發行項

Direct Lake 模式是一種語意模型功能，可用來分析 Power BI 中非常大的數據量。 Direct Lake 是以直接從 Data Lake 載入 parquet 格式的檔案為基礎，而不需要查詢 Lakehouse 或倉儲端點，也不需要將數據匯入或複製至 Power BI 模型。 Direct Lake 是將數據直接從 Lake 載入 Power BI 引擎的快速路徑，可供分析。 下圖顯示傳統匯入和 DirectQuery 模式與 Direct Lake 模式的比較方式。

Direct Lake 功能的圖表。

在 DirectQuery 模式中，Power BI 引擎會查詢來源的數據，這可能會變慢，但不需要像使用匯入模式一樣複製數據。 數據源的任何變更都會立即反映在查詢結果中。

另一方面，使用匯入模式時，效能可能會更好，因為數據會針對DAX和MDX報表查詢進行快取和優化，而不需要將SQL或其他類型的查詢轉譯至數據源。 不過，Power BI 引擎必須在重新整理期間先將任何新數據複製到模型。 來源的任何變更只會在下一個模型重新整理時挑選。

Direct Lake 模式會藉由直接從 OneLake 載入數據來消除匯入需求。 不同於 DirectQuery，從 DAX 或 MDX 轉譯到其他資料庫系統上的其他查詢語言或查詢執行，會產生類似匯入模式的效能。 因為沒有明確的匯入程式，所以在數據源發生時可能會挑選任何變更，結合 DirectQuery 和匯入模式的優點，同時避免其缺點。 Direct Lake 模式是分析非常大型模型和模型的理想選擇，且數據源經常更新。

Direct Lake 也支援數據列層級安全性和物件層級安全性，讓使用者只能看到他們有權查看的數據。

必要條件

僅限 Microsoft 進階版 （P） SKU 和 Microsoft Fabric （F） SKU 支援 Direct Lake。

重要

對於新客戶，僅限 Microsoft Fabric （F） SKU 支援 Direct Lake。 現有的客戶可以繼續使用 Direct Lake 搭配 進階版 （P） SKU，但建議轉換至網狀架構容量 SKU。 如需 Power BI 進階版 授權的詳細資訊，請參閱授權公告。

Lakehouse

使用 Direct Lake 之前，您必須在裝載於支援的 Microsoft Fabric 容量的工作區中，布建 Lakehouse （或倉儲）與一或多個 Delta 數據表。 Lakehouse 是必要的，因為它會提供 OneLake 中 parquet 格式檔案的儲存位置。 Lakehouse 也提供存取點來啟動Web模型功能，以建立 Direct Lake 模型。

若要瞭解如何布建 Lakehouse、在 Lakehouse 中建立 Delta 數據表，以及建立湖屋的基本模型，請參閱 建立 Direct Lake 的 Lakehouse。

SQL 端點

在布建 Lakehouse 時，會建立 SQL 查詢的 SQL 端點，以及報告的預設模型，並以任何新增至 Lakehouse 的數據表進行更新。 雖然 Direct Lake 模式在直接從 OneLake 載入數據時不會查詢 SQL 端點，但當 Direct Lake 模型必須順暢地回復至 DirectQuery 模式時，就不需要查詢 SQL 端點，例如數據源使用進階安全性或無法透過 Direct Lake 讀取的檢視等特定功能時。 Direct Lake 模式也會查詢 SQL 端點的架構和安全性相關信息。

資料倉儲

除了使用 SQL 端點的 Lakehouse，您也可以使用 SQL 語句或資料管線來布建倉儲和新增數據表。 布建獨立數據倉儲的程序幾乎與 Lakehouse 的程式完全相同。

使用 XMLA 端點的模型寫入支援

Direct Lake 模型支援透過 XMLA 端點的寫入作業，方法是使用 SQL Server Management Studio 等工具（19.1 和更新版本），以及表格式編輯器和 DAX Studio 等最新版的外部 BI 工具。 透過 XMLA 端點支援的模型寫入作業：

  • 自定義、合併、腳本、偵錯及測試 Direct Lake 模型元數據。

  • 來源和版本控制、持續整合和持續部署 （CI/CD） 與 Azure DevOps 和 GitHub。

  • 使用 PowerShell 和 REST API 將變更套用至 Direct Lake 模型等自動化工作。

請注意，使用 XMLA 應用程式建立的 Direct Lake 數據表一開始會處於未處理的狀態，直到應用程式發出重新整理命令為止。 未處理的數據表會回復為 DirectQuery 模式。 建立新的語意模型時，請務必重新整理語意模型來處理您的數據表。

啟用 XMLA 讀寫

透過 XMLA 端點在 Direct Lake 模型上執行寫入作業之前，必須針對容量啟用 XMLA 讀寫功能。

針對 Fabric 試用 容量，試用版使用者具有啟用 XMLA 讀寫所需的系統管理員許可權。

  1. 在 管理員 入口網站中，選取 [容量設定]。

  2. 按兩下 [ 試用版] 索引標籤。

  3. 在容量名稱中選取 [試用版] 的容量和您的用戶名稱。

  4. 展開 Power BI 工作負載，然後在 [XMLA 端點] 設定中，選取 [讀取寫入]。

    網狀架構試用容量之 XMLA 端點讀寫設定的螢幕快照。

請記住，XMLA 端點設定會套用至指派給容量的所有工作區和模型。

Direct Lake 模型元數據

透過 XMLA 端點連線到獨立 Direct Lake 模型時，元數據看起來像任何其他模型。 不過，Direct Lake 模型會顯示下列差異：

  • 資料庫 compatibilityLevel 物件的 屬性為 1604 或更高版本。

  • Mode Direct Lake 資料分割的 屬性會設定為 directLake。

  • Direct Lake 分割區會使用共用運算式來定義數據源。 表達式會指向 Lakehouse 或 warehouse 的 SQL 端點。 Direct Lake 會使用 SQL 端點來探索架構和安全性資訊，但直接從 Delta 數據表載入資料（除非 Direct Lake 因任何原因必須回復到 DirectQuery 模式）。

以下是 SSMS 中的 XMLA 查詢範例：

SSMS 中的 XMLA 查詢螢幕快照。

若要深入瞭解透過 XMLA 端點的工具支援，請參閱 與 XMLA 端點的語意模型連線。

後援

Direct Lake 模式中的 Power BI 語意模型會直接從 OneLake 讀取 Delta 數據表。 不過，如果 Direct Lake 模型的 DAX 查詢超過 SKU 的限制，或使用不支援 Direct Lake 模式的功能，例如倉儲中的 SQL 檢視，則查詢可以回復為 DirectQuery 模式。 在 DirectQuery 模式中，查詢會使用 SQL 從 Lakehouse 或倉儲的 SQL 端點擷取結果，這可能會影響查詢效能。 如果您想要只以純 Direct Lake 模式處理 DAX 查詢，則可以 停用 DirectQuery 模式的後援 。 如果您不需要 DirectQuery 後援，建議您停用後援。 分析 Direct Lake 模型的查詢處理時，也可以有所説明，以識別後援的發生頻率和頻率。 若要深入瞭解 DirectQuery 模式，請參閱 Power BI 中的語意模型模式。

護欄 會定義 Direct Lake 模式的資源限制，因此需要後援 DirectQuery 模式才能處理 DAX 查詢。 如需如何判斷 Delta 數據表之 parquet 檔案和數據列群組數目的詳細資訊，請參閱 Delta 數據表屬性參考。

針對 Direct Lake 語意模型， Max Memory 代表可分頁多少數據的記憶體資源上限。 實際上，它不是護欄，因為超過它不會造成 DirectQuery 的後援;不過，如果數據量夠大而造成 OneLake 數據的分頁和移出模型數據，它可能會對效能造成影響。

下表列出資源防護欄和記憶體上限：

網狀架構 SKU 每一數據表的 Parquet 檔案 每個數據表的數據列群組 每個資料表的資料列數 （百萬個） 磁碟/OneLake1 上的模型大小上限 （GB） 最大記憶體 (GB)
F2 1,000 1,000 300 10 3
F4 1,000 1,000 300 10 3
F8 1,000 1,000 300 10 3
F16 1,000 1,000 300 20 5
F32 1,000 1,000 300 40 10
F64/FT1/P1 5,000 5,000 1,500 無限制 25
F128/P2 5,000 5,000 3,000 無限制 50
F256/P3 5,000 5,000 6,000 無限制 100
F512/P4 10,000 10,000 12,000 無限制 200
F1024/P5 10,000 10,000 24,000 無限制 400
F2048 10,000 10,000 24,000 無限制 400

1 - 如果超過，磁碟/Onelake 上的模型大小上限會導致模型的所有查詢回復到 DirectQuery，不同於每個查詢評估的其他護欄。

視您的網狀架構 SKU 而定，每個查詢的額外容量單位和最大記憶體限制也適用於 Direct Lake 模型。 若要深入瞭解，請參閱 容量和SKU。

後援行為

Direct Lake 模型包含 DirectLakeBehavior 属性，其有三個選項：

自動 - （預設值） 指定當數據無法有效率地載入記憶體時，查詢會回復為 DirectQuery 模式。

DirectLakeOnly - 指定所有查詢僅使用 Direct Lake 模式。 已停用 DirectQuery 模式的後援。 如果無法將數據載入記憶體中，則會傳回錯誤。 使用此設定來判斷 DAX 查詢是否無法將數據載入記憶體中，強制傳回錯誤。

DirectQueryOnly - 指定所有查詢僅使用 DirectQuery 模式。 使用此設定來測試後援效能。

您可以使用表格式物件模型 （TOM） 或表格式模型腳本語言 （TMSL） 來設定 DirectLakeBehavior 屬性。

下列範例會指定所有查詢僅使用 Direct Lake 模式：

// Disable fallback to DirectQuery mode.
//
database.Model.DirectLakeBehavior = DirectLakeBehavior.DirectLakeOnly = 1;
database.Model.SaveChanges();

分析查詢處理

若要判斷報表視覺效果對數據源的 DAX 查詢是否使用 Direct Lake 模式提供最佳效能，或回到 DirectQuery 模式，您可以使用 Power BI Desktop、SQL Server Profiler 或其他第三方工具來分析查詢的效能分析器。 若要深入瞭解，請參閱 分析 Direct Lake 模型的查詢處理。

Refresh

根據預設，OneLake 中的數據變更會自動反映在 Direct Lake 模型中。 您可以停用 讓 Direct Lake 數據保持在模型設定中的最新 狀態，以變更此行為。

模型設定中 Direct Lake 重新整理選項的螢幕快照。

例如，您可能需要在將任何新數據公開給模型的取用者之前，先允許完成數據準備作業，才能停用。 停用時，您可以手動或使用重新整理 API 叫用重新整理。 叫用 Direct Lake 模型的重新整理是低成本的作業，其中模型會分析最新版 Delta Lake 數據表的元數據，並更新以參考 OneLake 中的最新檔案。

請注意，如果重新整理期間發生無法復原的錯誤，Power BI 可以暫停 Direct Lake 數據表的自動更新，因此請確定您的語意模型可以順利重新整理。 Power BI 會在後續使用者叫用的重新整理完成時自動繼續自動更新，而不會發生錯誤。

分層數據存取安全性

在 Lakehouse 和倉儲之上建立的 Direct Lake 模型會遵循 Lakehouse 和倉儲支援的分層安全性模型，方法是透過 T-SQL 端點執行許可權檢查，以判斷嘗試存取數據的身分識別是否具有必要的數據訪問許可權。 根據預設，Direct Lake 模型會使用單一登錄 （SSO），因此互動式使用者的有效許可權會判斷使用者是否允許或拒絕存取數據。 如果 Direct Lake 模型設定為使用固定身分識別，則固定身分識別的有效許可權會決定與語意模型互動的使用者是否可以存取數據。 T-SQL 端點會根據 OneLake 安全性和 SQL 許可權的組合，將允許或拒絕傳回 Direct Lake 模型。

例如，倉儲系統管理員可以授與數據表的使用者 SELECT 許可權，讓使用者可以讀取該數據表，即使使用者沒有 OneLake 安全性許可權也一樣。 使用者已在 Lakehouse/warehouse 層級獲得授權。 相反地，倉儲系統管理員也可以拒絕使用者讀取數據表的存取權。 用戶之後將無法從該數據表讀取，即使使用者具有 OneLake 安全性讀取許可權也一樣。 DENY 語句會覆寫任何已授與 OneLake 安全性或 SQL 許可權。 請參閱下表，以取得用戶可給予 OneLake 安全性和 SQL 許可權的任何組合的有效許可權。

OneLake 安全性許可權 SQL 權限 有效權限
允許 無 允許
無 允許 允許
允許 拒絕 拒絕
無 拒絕 拒絕

已知問題與限制

  • 根據設計，只有衍生自 Lakehouse 或 Warehouse 中數據表之語意模型中的數據表支援 Direct Lake 模式。 雖然模型中的數據表可以衍生自 Lakehouse 或 Warehouse 中的 SQL 檢視，但使用這些數據表的查詢會回復為 DirectQuery 模式。

  • Direct Lake 語意模型數據表只能衍生自單一 Lakehouse 或 Warehouse 的數據表和檢視。

  • Direct Lake 數據表目前無法與相同模型中的其他數據表類型混合，例如 Import、DirectQuery 或 Dual。 目前不支持複合模型。

  • Direct Lake 模型中不支援 DateTime 關聯性。

  • 不支援匯出數據行和匯出數據表。

  • 某些數據類型可能不受支援，例如高精確度小數和貨幣類型。

  • Direct Lake 資料表不支援複雜的 Delta 數據表數據行類型。 也不支援二進位和 Guid 語意類型。 您必須將這些資料類型轉換成字串或其他支援的數據類型。

  • 數據表關聯性需要索引鍵數據行的數據類型才能重合。 主鍵數據行必須包含唯一值。 如果偵測到重複的主鍵值，DAX 查詢將會失敗。

  • 字串數據行值的長度限制為 32,764 個 Unicode 字元。

  • Direct Lake 模型中不支援浮點值 『NaN』（非數位）。

  • 尚不支援依賴內嵌實體的內嵌案例。

  • Direct Lake 模型的驗證有限。 用戶選取專案會假設正確，而且不會驗證關聯性的基數和交叉篩選選取專案，或日期數據表中選取的日期數據行。

  • [重新整理記錄] 中的 [Direct Lake] 索引標籤只會列出 Direct Lake 相關的重新整理失敗。 目前省略成功的重新整理。

開始使用

在組織中開始使用 Direct Lake 解決方案的最佳方式是建立 Lakehouse、在其中建立 Delta 數據表，然後在 Microsoft Fabric 工作區中建立 Lakehouse 的基本語意模型。 若要深入瞭解，請參閱 建立 Direct Lake 的 Lakehouse。

相關內容