共用方式為

Direct Lake

  • 發行項

Direct Lake 模式是語意模型功能，用於分析 Power BI 中的大量資料。 Direct Lake 根據直接從資料湖中載入 Parquet 格式的檔案，而無需査詢 Lakehouse 或倉儲端點，也無需將資料匯入或複製到 Power BI 模型中。 Direct 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 還支援Power BI 列層級安全性和物件層級安全性，因此使用者只能看到其有權查看的資料。

必要條件

Direct Lake 僅在 Microsoft Premium P 和 Microsoft Fabric F SKU 上受支援。

重要

對於新客戶，Direct Lake 僅在 Microsoft Fabric (F) SKU 上受支援。 現有的客戶可以繼續搭配使用 Direct Lake 和 Premium (P) SKU，但建議轉換至 Fabric 容量 SKU。 如需 Power BI Premium 授權的詳細資訊，請參閱授權公告。

Lakehouse

在使用 Direct Lake 之前，您必須在支援的 Microsoft Fabric 容量上託管的工作區中為 Lakehouse (或倉儲) 設定一個或多個 Delta 資料表。 Lakehouse 是必需的，因為它為您在 OneLake 中的 Parquet 格式檔案提供了儲存位置。

若要了解如何設定 Lakehouse，請在 Lakehouse 中建立 Delta 資料表，並為 Lakehouse 建立基本模型，請參閲為 Direct Lake 建立 Lakehouse。

SQL 分析端點和資料倉儲

作為佈建湖存放庫的一部分，將建立用於 SQL 査詢的 SQL 分析端點，並使用新增至湖存放庫的任何資料表進行更新。 雖然直接從 OneLake 載入資料時，Direct Lake 模式不會査詢 SQL 分析端點，但當 Direct Lake 模型必須無縫後援至 DirectQuery 模式時，例如當資料來源使用進階安全性或無法透過 Direct Lake.Lake 讀取的檢視，而必須使用 SQL 分析端點時。 Direct Lake 模式也會定期査詢 SQL 分析端點以取得與模式和安全性相關的資訊。

作為具有 SQL 分析端點的 Lakehouse 之替代方法，您還可以透過使用 SQL 陳述式或資料管線來設定倉儲和新增資料表。 提供獨立資料倉儲的程序幾乎與湖存放庫的程序相同。

預設 Power BI 語意模型

倉儲和 SQL 分析端點還會在 Direct Lake 模式下建立 [預設的 Power BI 語意模型]。 此預設語意模型只能在倉儲或 SQL 分析端點內編輯，而且有其他限制。 請參閱預設的 Power BI 語意模型文件。 此 Direct Lake 文件適用於 Direct Lake 模式下的非預設 Power BI 語意模型。

在 Direct Lake 儲存模式下建立 Power BI 語意模型

Direct Lake 模式下的 Power BI 語意模型在 Lakehouse 或倉儲中建立。

在 Lakehouse 中，按一下 [新增 Power BI 語意模型]，在 Direct Lake 模式下建立 Power BI 語意模型。

在倉儲或 SQL 分析端點中，選取 [報告] 功能區，然後選取 [新增 Power BI 語意模型]，以便在 Direct Lake 模式下建立 Power BI 語意模型。

然後，您可以新增關聯性、度量、計算群組、格式字串、列層級安全性等，並且透過在瀏覽器中編輯語意模型來重新命名資料表。 稍後，使用來自工作區的特色選單編輯語意模型，以開啟資料模型。

XMLA 端點的模型寫入支援

Direct Lake 模型透過使用 SQL Server Management Studio (19.1 及更高版本) 等工具以及最新版本的外部 BI 工具 (如 Tabular Editor 和 DAX Studio) 支援透過 XMLA 端點進行寫入作業。 透過 XMLA 端點支援的模型寫入作業：

  • 自訂、合併、指令碼處理、偵錯和測試 Direct Lake 模型中繼資料。

  • 與 Azure DevOps 和 GitHub 進行來源和版本控制、持續整合和持續部署 (CI/CD)。

  • 透過使用 PowerShell 和 REST API 對 Direct Lake 模型進行重新整理和套用變更等自動化工作。

使用 XMLA 應用程式建立的 Direct Lake 資料表最初將處於未處理狀態，直到應用程式發出重新整理命令。 未處理的資料表將後援至 DirectQuery 模式。 建立新的語意模型時，請確保重新整理語意模型以處理資料表。

啟用 XMLA 讀寫

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

對於 Fabric 試用容量，試用使用者具有啟用 XMLA 讀寫所需的管理員權限。

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

  2. 選取 [試用] 索引標籤。

  3. 使用 [試用] 功能選取容量，並在容量名稱中選取您的使用者名稱。

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

    Fabric 試用版容量之 XMLA 端點讀寫設定的螢幕擷取畫面。

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

Direct Lake 模型中繼資料

當透過 XMLA 端點連線至獨立 Direct Lake 模型時，中繼資料看起來與任何其他模型一樣。 然而，Direct Lake 模型顯示出以下差異：

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

  • Direct Lake 分割區的 Mode 屬性設定為 directLake。

  • Direct Lake 分割區使用共用運算式來定義資料來源。 運算式指向 Lakehouse 或倉儲的 SQL 分析端點。 Direct Lake 使用 Lakehouse 的 SQL 分析端點來探索結構描述和安全性資訊，但直接從 Delta 資料表載入資料 (除非 Direct Lake 出於任何原因必須後援至 DirectQuery 模式)。

以下是範例，XMLA 査詢位於 SSMS 中：

SSMS 中 XMLA 查詢的螢幕擷取畫面。

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

後援

Direct Lake 模式下的 Power BI 語意模型直接從 OneLake 讀取 Delta 資料表。 但是，如果 Direct Lake 模型上的 DAX 査詢超過 SKU 的限制，或者使用不支援 Direct Lake 模式的功能，如倉儲中的 SQL 檢視，則査詢可以後援至 DirectQuery 模式。 在 DirectQuery 模式下，査詢使用 SQL 從倉儲或湖存放庫的 SQL 分析端點擷取結果，這可能會影響査詢效能。 如果只想在純 Direct Lake 模式下處理 DAX 査詢，可以停用後援至 DirectQuery 模式。 如果不需要後援至 DirectQuery，建議停用後援。 在分析 Direct Lake 模型的査詢處理以確定是否發生後援以及其發生的頻率時，它也很實用。 若要深入了解 DirectQuery 模式，請參閱 Power BI 中的語意模型模式。

護欄為 Direct Lake 模式定義了資源限制，超過此限制，需要後援至 DirectQuery 模式來處理 DAX 査詢。 如需如何確定 Delta 資料表的 Parquet 檔案數和資料列群組數的詳細資料，請參閱 Delta 資料表屬性參考。

對於 Direct Lake 語意模型，最大記憶體表示可以分頁多少資料的記憶體資源上限。 實際上，它不是護欄，因為超過它不會導致後援至 DirectQuery；然而，如果資料量足够大，導致從 OneLake 資料中分頁進出模型資料，則可能會對效能產生影響。

以下資料表列出了資源護欄和最大記憶體：

Fabric SKU 每個資料表的 Parquet 檔案數 每個資料表的資料列群組數 每個資料表資料列數 (百萬) 磁碟/OneLake 上的最大模型大小1 (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，這與每個査詢評估的其他護欄不同。

根據您的 Fabric SKU，其他容量單位和每次査詢的最大記憶體限制也適用於 Direct Lake 模型。 若要深入了解，請參閱容量和 SKU。

後援行為

Direct Lake 模型包括 DirectLakeBehavior 屬性，其有三個選項：

自動 - (預設) 指定如果資料不能有效地載入記憶體中，査詢將後援至 DirectQuery 模式。

DirectLakeOnly - 指定所有査詢僅使用 Direct Lake 模式。 已停用後援至 DirectQuery 模式。 如果資料無法載入記憶體中，則傳回錯誤。 使用此設定可確定 DAX 査詢是否無法將資料載入記憶體中，從而強制傳回錯誤。

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

DirectLakeBehavior 屬性可以透過使用表格式物件模型 (TOM) 或表格模型指令碼語言 (TMSL) 進行設定。

以下範例指定所有査詢僅使用 Direct Lake 模式：

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

在語意模型屬性中，透過在瀏覽器中編輯語意模型也可進行此設定。 在 [資料] 窗格的 [模型] 索引標籤中，選取 [語意模型]。

顯示 Direct Lake 行為的螢幕擷取畫面。

分析查詢處理

若要確定使用 Direct Lake 模式或後援至 DirectQuery 模式時，報表視覺效果對資料來源的 DAX 査詢是否提供了最佳效能，您可以使用 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 會在後續使用者叫用的重新整理完成並且未發生錯誤時，自動繼續自動更新。

預設啟用的單一登入 (SSO)

根據預設，Direct Lake 模型依賴 Microsoft Entra 單一登入 (SSO) 來存取 Fabric Lakehouse 和倉儲資料來源，並使用目前與模型互動的使用者身分識別。 您可以展開 [閘道與雲端連線] 區段，以檢查 Direct Lake 模型設定中的組態，如以下螢幕擷取畫面所示。 Direct Lake 模型不需要明確的資料連線，因為 Lakehouse 或倉儲是直接存取的，而且 SSO 不需要預存的連線認證。

閘道與雲端連線組態設定的螢幕擷取畫面。

在想要使用預存認證的情況下，您也可以將 Lakehouse 或倉儲資料來源明確繫結至一個可共用的雲端連線 (SSO)，這樣就可以為該資料來源連線停用 SSO。 若要明確繫結資料來源，請從 [閘道與雲端連線] 區段的 [對應至：] 清單方塊中選取 SCC。 您還可以透過選取 [建立連線] 來建立新的連線，然後按步驟提供連線名稱。 接下來，選取 [OAuth 2.0] 作為新連線的驗證方法，輸入所需的認證並清除[單一登入] 複選框，然後將 Lakehouse 或倉儲資料來源繫結至您剛才建立的新 SCC 連線。

[預設：單一登入 (Entra ID)] 連線組態簡化了 Direct Lake 模型的組態設定，不過，如果您已經有一個針對 Lakehouse 或倉儲資料來源的個人雲端連線 (PCC)，Direct Lake 模型將自動繫結至相符的 PCC，從而立即套用您已經為資料來源定義的連線設定。 您應該確認 Direct Lake 模型的連線組態，以確保模型使用正確的設定存取其 Fabric 資料來源。

語意模型可以在 Direct Lake、Import 和 DirectQuery 模式中為 Fabric Lakehouse 和倉儲使用 [預設：單一登入 (Entra ID)] 連線組態。 所有其他資料來源都需要明確定義的資料連線。

多層式資料存取安全性

在湖存放庫和倉儲之上建立的 Direct Lake 模型透過 SQL 分析端點執行權限檢查來確定嘗試存取資料的身分識別是否具有所需的資料存取權限，從而遵守湖存放庫和倉儲支援的多層式安全性模型。 根據元素和，Direct Lake 模型使用單一登入 (SSO)，因此互動使用者的有效權限决定了是否允許或拒絕使用者存取資料。 如果 Direct Lake 模型被設定為使用固定身分識別，則固定身分識別的有效權限决定了與語意模型互動的使用者是否可以存取資料。 SQL 分析端點根據 OneLake 安全性和 SQL 權限的組合向 Direct Lake 模型傳回允許或停用。

例如，倉儲系統管理員可以授與使用者對資料表的 SELECT 權限，以便即使使用者沒有 OneLake 安全性權限，也可以從該資料表中讀取。 已在湖存放庫/倉儲層級獲授使用者。 相反，倉儲系統管理員也可以拒絕使用者對資料表的讀取存取。 即使使用者具有 OneLake 安全性讀取權限，也無法從該資料表中讀取。 DENY 陳述式覆寫任何授與的 OneLake 安全性或 SQL 權限。 請參閱下表，了解使用者可以授與 OneLake 安全性和 SQL 權限的任何組合之有效權限。

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

已知問題與限制

  • 根據設計，只有衍生自 Lakehouse 或倉儲中資料表之語意模型中的資料表支援 Direct Lake 模式。 雖然模型中的資料表可能衍生自 Lakehouse 或倉儲中的 SQL 檢視，但使用這些資料表的查詢會遞補至 DirectQuery 模式。

  • Direct Lake 語意模型資料表只能衍生自單一 Lakehouse 或倉儲的資料表和檢視。 單一 Lakehouse 可以包含從其他 Lakehouse 新增的捷徑。

  • 使用列層級安全性對資料倉儲資料表所進行的查詢 (包括 Lakehouse SQL 分析端點) 將會遞補至 DirectQuery 模式。

  • Direct Lake 資料表目前不能與同一模型中的其他資料表類型 (如 Import、DirectQuery 或 Dual) 混合使用。 Power BI 語意模型的複合模型可以使用 Direct Lake 儲存模式中的 Power BI 語意模型作為來源。

  • Direct Lake 模型不支援 DateTime 關聯性。 Date 關聯性則受支援。

  • 尚不支援計算資料行和計算資料表。 計算群組和欄位參數均受支援。

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

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

  • 資料表關聯性要求其關鍵資料行的資料類型一致。 主索引鍵資料行必須包含唯一值。 如果偵測到重複的主索引鍵值，DAX 査詢將失敗。

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

  • Direct Lake 模型不支援浮動值‘NaN’ (不是數字)。

  • 尚未支援依賴內嵌實體的 Power BI Embedded 案例。

  • Direct Lake 模型的驗證有限。 假設使用者選取項目正確，任何査詢都不會驗證關聯性或日期資料表中所選日期資料行的基數和交叉篩選選取項目。

  • 重新整理歷程記錄中的 Direct Lake 索引標籤僅列出與 Direct Lake 相關的重新整理失敗。 目前省略了成功的重新整理。

開始使用

在貴組織中開始使用 Direct Lake 解決方案的最佳方法是建立 Lakehouse，在其中建立 Delta 資料表，然後在 Microsoft Fabric 工作區中為 Lakehouse 建立基本語意模型。 若要深入了解，請參閲為 Direct Lake 建立 Lakehouse。

相關內容