Direct Lake 概觀
Direct Lake 是 Power BI 語意模型中儲存在 Microsoft Fabric 工作區中的數據表儲存模式選項。 它已針對大量數據進行優化，可從 Delta 數據表快速載入記憶體，其數據會儲存在 OneLake的 Parquet 檔案中，這是所有分析數據的單一存放區。 加載記憶體之後，語意模型會啟用高效能查詢。 Direct Lake 可消除將數據匯入模型中的速度變慢且成本高昂的需求。
您可以使用 Direct Lake 儲存模式來連線到單一 Fabric lakehouse 或 Fabric 倉儲的資料表或檢視表。 這兩個網狀架構專案和 Direct Lake 語意模型都需要 網狀架構容量授權。
在某些方面，Direct Lake 語意模型類似於 匯入語意模型。 這是因為 VertiPaq 引擎會將模型數據載入記憶體中，以取得快速的查詢效能（除了 DirectQuery 後援的情況除外，本文稍後會加以說明）。
不過，Direct Lake 語意模型與匯入語意模型以重要方式不同。 這是因為 Direct Lake 語意模型的重新整理作業在概念上與匯入語意模型的重新整理作業不同。 針對 Direct Lake 語意模型，重新整理牽涉到 框架 作業（本文稍後所述），可能需要幾秒鐘的時間才能完成。 這是低成本的作業，語意模型會分析最新版 Delta 數據表的元數據，並更新為參考 OneLake 中的最新檔案。 相反地，針對匯入語意模型，重新整理會產生數據的複本，這可能需要相當長的時間，並耗用大量的數據源和容量資源（記憶體和 CPU）。
注意
匯入語意模型的累加式重新整理，有助於減少重新整理時間和容量資源的使用。
何時應該使用 Direct Lake 儲存模式？
Direct Lake 儲存模式的主要使用案例通常是針對使用以湖為中心的架構的 IT 驅動分析專案。 在此案例中，您有或預期會在 OneLake 中累積大量數據。 將數據快速載入記憶體、頻繁且快速重新整理作業、有效率地使用容量資源，以及快速查詢效能對於此使用案例而言都很重要。
注意
匯入和 DirectQuery 語意模型仍然與 Fabric 相關，而且是某些案例語意模型的正確選擇。 例如，匯入儲存模式通常適用於自助分析師，其需要自由和靈活度來快速採取行動，而不需要依賴 IT 來新增數據元素。
此外，OneLake 整合 會自動將數據寫入以匯入儲存模式儲存的表格至 OneLake 中的 Delta 數據表，且不需要任何移轉工作。 使用此選項，您可以瞭解可供匯入語意模型使用者使用的 Fabric 的許多優點，例如透過快捷方式、SQL 查詢、筆記本等方式與 Lakehouses 整合。 我們建議您考慮選擇此選項，作為快速獲得 Fabric 優勢的方法，無需立即或必然重新設計您現有的數據倉儲和/或分析系統。
Direct Lake 儲存模式也適合將數據延遲降至最低，以快速將數據提供給商務使用者。 如果您的 Delta 資料表是間歇性地被修改（假設您已經在 Data Lake 中做好資料準備），您可以依賴 自動更新功能 來重新調整以回應這些修改。 在此情況下，傳送至語意模型的查詢會傳回最新的數據。 此功能與Power BI報表 自動頁面重新整理 功能搭配運作良好。
請記住，Direct Lake 依賴於在 Data Lake 中完成的資料準備。 您可以使用各種工具來完成數據準備，例如 Fabric Lakehouses 的 Spark 作業、適用於網狀架構倉儲的 T-SQL DML 語句、數據流、管線等。 這種方法有助於確保架構中的數據準備邏輯盡可能低地執行，以最大化重複使用性。 不過，如果語意模型作者無法修改來源專案，例如，如果自助分析師沒有IT所管理之Lakehouse的寫入許可權，則匯入儲存模式可能是較佳的選擇。 這是因為其支援使用Power Query來準備數據，其定義為語意模型的一部分。
當您考慮 Direct Lake 儲存模式時，請務必考慮您目前的 Fabric 容量授權 和 Fabric 容量限制。 此外，請考慮 的考量和的限制，本文稍後會加以說明。
提示
建議您產生 原型或概念證明（POC），以判斷 Direct Lake 語意模型是否為正確的解決方案，以及降低風險。
Direct Lake 的運作方式
通常，傳送至 Direct Lake 語意模型的查詢會由 Delta 表產生的數據行組成的記憶體快取處理。 Delta 數據表的基礎記憶體是 OneLake 中的一或多個 Parquet 檔案。 Parquet 檔案會依數據行而非數據列來組織數據。 語意模型會將整個數據行從 Delta 資料表載入記憶體，因為查詢需要這些數據行。
Direct Lake 語意模型也可能使用 DirectQuery 後援，這牽涉到順暢地切換至 DirectQuery 模式。 DirectQuery 備援直接從 lakehouse 的 SQL 分析端點或倉儲 擷取數據。 例如，當 Delta 資料表包含的資料列比所支援的 Fabric 容量更多時，可能會有回退情況（於本文稍後所述）。 在此情況下，DirectQuery 作業會將查詢傳送至 SQL 分析端點。 後援作業可能會導致查詢效能變慢。
下圖說明了 Direct Lake 的運作原理，並透過使用者開啟 Power BI 報表的情境來進行展示。
此圖描述下列使用者動作、程式和功能。
| 項目 | 描述 |
|---|---|
|
OneLake 是儲存 Parquet 格式分析數據的數據湖。 此檔案格式 已針對 Direct Lake 語意模型的資料儲存進行最佳化。 |
|
Fabric 湖棧或 Fabric 倉儲存在於具有 Fabric 容量的工作區間運行。 Lakehouse 具有 SQL 分析端點，可提供 SQL 型查詢體驗。 數據表（或檢視表）提供使用 Transact-SQL （T-SQL） 查詢 OneLake 中 Delta 數據表的方法。 |
|
Direct Lake 語意模型存在於 Fabric 工作區中。 它會連接到湖屋或倉儲中的數據表或檢視。 |
|
用戶開啟Power BI報表。 |
|
Power BI 報表會將數據分析表示式 （DAX） 查詢傳送至 Direct Lake 語意模型。 |
|
可能的話，語意模型會將數據行直接從儲存在 OneLake 中的 Parquet 檔案載入記憶體中。 查詢可達到記憶體內部效能，速度非常快。 |
|
語意模型會傳回查詢結果。 |
|
Power BI 報表會呈現視覺效果。 |
|
在某些情況下，例如當語意模型超過容量 護欄時，語意模型查詢會自動回復到 DirectQuery 模式。 在此模式中，查詢會傳送至 Lakehouse 或倉儲的 SQL 分析端點。 |
|
傳送至 SQL 分析端點的 DirectQuery 查詢會接著查詢 OneLake 中的 Delta 數據表。 因此，查詢效能可能會比記憶體內部查詢慢。 |
下列各節說明 Direct Lake 概念和功能，包括數據行載入、框架、自動更新和 DirectQuery 後援。
欄位載入（轉碼）
Direct Lake 語意模型僅在首次查詢欄位時，從 OneLake 同時載入數據。 從 OneLake 按需載入資料的過程稱為 轉碼。
當語意模型收到 DAX （或多維度表示式 — MDX） 查詢時，它會先判斷產生查詢結果所需的數據行。 查詢中直接使用的任何欄，以及關聯性和量值所需的欄都是必需的。 一般而言，產生查詢結果所需的數據行數目明顯小於語意模型中定義的數據行數目。
一旦瞭解需要哪些數據行，語意模型就會判斷哪些數據行已經在記憶體中。 如果查詢所需的任何數據行不在記憶體中，語意模型會從 OneLake 載入這些數據行的所有數據。 載入欄位數據通常是快速的操作，然而這可能取決於欄位中儲存的數據基數等因素。
然後，載入記憶體中的數據行會 記憶體中的常駐。 未來只涉及常駐數據行的查詢不需要將更多數據行載入記憶體中。
資料列會保持駐留狀態，直到有理由將它從記憶體中移除（逐出）。 可能會移除欄的原因包括：
- 在來源的 Delta 數據表更新之後，模型或數據表會重新整理（請參閱下一節中的 框架）。
- 已經有一段時間沒有查詢使用這個數據欄。
- 其他記憶體管理原因，包括由於其他並行作業而導致容量記憶體壓力增加。
您選擇的 Fabric SKU 將決定容量內每個 Direct Lake 語意模型的最大可用記憶體。 如需資源護欄和記憶體限制上限的詳細資訊，請參閱本文稍後 網狀架構容量護欄和限制。
框架
框架 為模型擁有者提供時間點控制哪些數據載入語意模型。 框架是由語意模型重新整理所觸發的 Direct Lake 作業，在大部分情況下只需要幾秒鐘的時間才能完成。 因為這是一個低成本的操作，語意模型會分析 Delta Lake 表格最新版本的元數據，並更新以參考 OneLake 中最新的 Parquet 格式檔案。
框架化發生時，如果基礎數據已變更，而重新整理的時間點成為所有未來轉碼事件的新基準，駐留表格的數據列區段和字典可能會從記憶體中被移除。 從這一點開始，Direct Lake 查詢只會考慮到最近一次框架操作時的 Delta 表格中的數據。 因此，系統會查詢 Direct Lake 表，以根據 Delta 表 在最近的框架作業時的狀態傳回數據。 該時間不一定是 Delta 數據表的最新狀態。
請注意，語意模型在建構時會分析每個 Delta 表的 Delta 記錄，以便只卸除受影響的欄位區段，並在轉碼期間重新載入新加入的數據。 重要的優化是，當累加框架生效時，通常不會卸除字典，而且會將新的值新增至現有的字典。 這個累加框架方法有助於降低重載負擔，並有利於查詢效能。 在理想情況下，當 Delta 數據表未收到任何更新時，記憶體中已經駐留的欄位不需要重載，而且查詢在框架後的效能影響明顯減小，因為增量框架基本上能使語義模型對現有記憶體中的數據進行大部分就地更新。
下圖顯示 Direct Lake 框架作業的運作方式。
此圖描述下列程式和功能。
| 項目 | 描述 |
|---|---|
|
|
Fabric 工作區中存在語義模型。 |
|
|
框架作業會定期進行，並設定所有未來 轉碼 事件的基準。 框架作業可以自動、手動、依排程或以程式設計方式進行。 |
|
|
OneLake 會儲存元數據和 Parquet 檔案，以 Delta 數據表表示。 |
|
|
最後一個框架作業包含與 Delta 資料表相關的 Parquet 檔案，特別是上一次 最後一個 框架作業之前新增的 Parquet 檔案。 |
|
|
稍後的框架作業包含在最後 框架作業之後新增的 Parquet 檔案。 |
|
|
Direct Lake 語意模型中的駐留欄可能被逐出記憶體，而且刷新的時間點會成為所有未來轉碼事件的新基準。 |
|
|
後續的數據修改，會以新的 Parquet 檔案形式呈現，直到下一次框架操作發生時才會顯示。 |
轉碼作業發生時，並非總是需要獲得代表任何 Delta 數據表最新狀態的數據。 請考慮使用框架可以幫助您在 Delta 資料表中的短暫性環境中提供一致的查詢結果。 數據可能會因為數個原因而暫時性，例如長時間執行的擷取、轉換和載入 （ETL） 進程發生時。
Direct Lake 語意模型的重新整理可以手動、自動或以程式設計方式完成。 如需詳細資訊，請參閱 重新整理 Direct Lake 語意模型。
如需有關 Delta 資料表版本控制和框架的詳細資訊，請參閱 瞭解 Direct Lake 語意模型的儲存。
自動更新
有語意模型層級設定可自動更新 Direct Lake 數據表。 默認會啟用。 它可確保 OneLake 中的數據變更會自動反映在 Direct Lake 語意模型中。 當您想要透過框架控制數據變更時，應該停用自動更新，如上一節所述。 如需詳細資訊，請參閱 管理 Direct Lake 語意模型。
提示
您可以在 Power BI 報表中設定 自動頁面重新整理。 這是一項自動重新整理特定報表頁面的功能，前提是報表連接到 Direct Lake 語意模型（或其他類型的語意模型）。
DirectQuery 備援
傳送至 Direct Lake 語意模型的查詢可以退回至 DirectQuery 模式。 在此情況下，它會直接從 Lakehouse 或倉儲的 SQL 分析端點擷取數據。 這類查詢一律會傳回最新的數據，因為它們不會受限於最後一個框架作業的時間點。
當語意模型查詢 SQL 分析端點中的檢視，或 強制執行數據列層級安全性 （RLS）的 SQL 分析端點數據表時，查詢 一律會 回復。
此外，當語意模型 超出容量的防線時，查詢可能會退回。
重要
如果可能，您應該一律設計您的解決方案或調整您的容量，以避免 DirectQuery 回退機制。 這是因為它可能會導致查詢效能變慢。
您可以藉由設定其 DirectLakeBehavior 屬性來控制 Direct Lake 語意模型的回退。 如需詳細資訊，請參閱 設定 Direct Lake 行為屬性。
網狀架構容量護欄和限制
Direct Lake 語意模型需要 Fabric 容量授權。 此外，還有適用於您的 Fabric 容量訂用帳戶的容量防護欄和限制，如下表所示。
重要
下表中的第一欄也包含 Power BI Premium 容量訂用帳戶（P SKUs）。 請注意，Microsoft正在合併購買選項，並淘汰每個容量 SKU 的 Power BI Premium。 新舊客戶應該考慮購買 Fabric 容量訂閱（F SKU）來代替。
如需詳細資訊，請參閱 Power BI Premium 授權 和 Power BI Premium的重要更新。
| 布料 SKU | 每一資料表的 Parquet 檔案 | 每個表格的行群組 | 每個資料表的資料列數 （百萬個） | 磁碟或 OneLake 上的模型大小上限（GB） | 最大記憶體 （GB） 1 |
|---|---|---|---|---|---|
| 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 | 一萬 | 一萬 | 12,000 | 無限 | 200 |
| F1024/P5 | 一萬 | 一萬 | 24,000 | 無限 | 400 |
| F2048 | 一萬 | 一萬 | 24,000 | 無限 | 400 |
1 Direct Lake 語意模型，Max Memory 代表可分頁數據的記憶體資源上限。 基於這個理由，它不被視作一個限制，因為即使超過這個範圍，系統也不會退回至 DirectQuery 模式；然而，如果數據量大到足以導致 OneLake 數據中的模型數據過多地分頁和調出/調入，可能會對效能造成影響。
當超出磁碟/OneLake 上模型的最大大小 時，所有對語意模型的查詢將回退到 DirectQuery 模式。 數據表中呈現的所有其他護欄都會根據每個查詢進行評估。 因此，請務必 優化差異數據表，並 Direct Lake 語意模型，以避免必須不必要地相應增加至較高的網狀架構 SKU（導致成本增加）。
此外，容量單位 和 每個查詢的最大記憶體限制 適用於 Direct Lake 語意模型。 如需詳細資訊，請參閱 容量和 SKU。
考慮和限制
Direct Lake 語意模型提供一些考慮和限制。
注意
Direct Lake 語意模型的功能和功能正在演進。 請務必定期回來查看，以檢閱最新的考慮和限制清單。
- 當 Direct Lake 語意模型數據表連接到強制執行數據列層級安全性的 SQL 分析端點中的數據表時，涉及該模型數據表的查詢一律會回復為 DirectQuery 模式。 查詢效能可能會變慢。
- 當 Direct Lake 語意模型數據表連線到 SQL 分析端點中的檢視時，牽涉到該模型數據表的查詢一律會回復到 DirectQuery 模式。 查詢效能可能會變慢。
- 不支持複合模型化。 這表示 Direct Lake 語意模型數據表無法與其他儲存模式中的數據表混合，例如 Import、DirectQuery 或 Dual（除了特殊案例，包括 計算群組、假設參數，以及 字段參數）。
- 不支持參考 Direct Lake 儲存模式中之資料行或數據表的匯出數據行和計算數據表。 計算群組、假設參數，以及 欄位參數，隱式創建計算表，以及支持未參考 Direct Lake 欄或表的計算表。
- Direct Lake 儲存模式數據表不支援複雜的 Delta 數據表資料行類型。 也不支援二進位和 GUID 語意類型。 您必須將這些資料類型轉換成字串或其他支援的數據類型。
- 數據表關聯性需要相關數據行的數據類型才能比對。
- 關聯性的單邊欄位必須包含唯一的值。 如果在單邊數據行中偵測到重複的值，查詢會失敗。
- 不支援Power BI Desktop中的自動資料/時間智慧。 支援將您自己的日期數據表標示為日期表。
- 字串數據行值的長度限制為 32,764 個 Unicode 字元。
- 不支援 NaN（不是數位）的浮點值。
- 使用服務主體從 Power BI 發行至 Web，只有在使用 Direct Lake 語意模型 的固定身分識別時，才支援 。
- 在 Web 模型化體驗中，Direct Lake 語意模型的驗證有限。 用戶的選擇會被假定為正確，並且不會發出任何查詢來驗證關聯上的基數或交叉篩選的選項，以及標記的日期表中選定的日期欄位。
- 在 Fabric 入口網站中，重新整理歷程記錄中的 [Direct Lake] 索引標籤只會列出 Direct Lake 相關的重新整理失敗。 未列出成功的重新整理（框架）操作。
- 您的網狀架構 SKU 會針對容量決定每個 Direct Lake 語意模型的最大可用記憶體。 超出限制時，語意模型的查詢可能會因為模型數據的載入和卸載而變慢。
- 不支援在位於數據源工作區不同區域的工作區中建立 Direct Lake 語意模型。 例如，如果 Lakehouse 位於美國中西部，則您只能從相同區域中的這個 Lakehouse 建立語意模型。 一個解決方案是在其他區域的工作區中創建 Lakehouse，並在創建語意模型之前，先對數據表建立捷徑。 若要尋找您位於哪個區域，請參閱 尋找您的 Fabric 主區域。
- 您可以使用服務主體身分識別來建立和檢視自定義 Direct Lake 語意模型，但預設的 Direct Lake 語意模型不支援服務主體。 請確保在您的租用戶中已啟用 Fabric REST API 的服務主體驗證，並將 Contributor 或更高的權限授與 Direct Lake 語意模型的工作區。
- 內嵌報表需要 V2 內嵌令牌。
- Direct Lake 不支援服務主體憑證進行身份驗證。
- 支援由服務主體和查看器所建立的自定義 Direct Lake 語意模型，但不支援預設的 Direct Lake 語意模型。
與其他儲存模式的比較
下表比較 Direct Lake 儲存模式與匯入和 DirectQuery 儲存模式。
| 能力 | Direct Lake | 進口 | 直接查詢 |
|---|---|---|---|
| 授權許可 | 僅限網狀架構容量訂用帳戶 （SKU） | 任何網狀架構或 Power BI 授權（包括Microsoft網狀架構免費授權） | 任何網狀架構或 Power BI 授權（包括Microsoft網狀架構免費授權） |
| 數據源 | 只有湖倉或數據倉儲的資料表（或檢視表） | 任何連接器 | 任何支援 DirectQuery 模式的連接器 |
| 連接到 SQL 分析端點檢視 | 是 – 但會自動回復到 DirectQuery 模式 | 是的 | 是的 |
| 複合模型 | 無 1 | 是 – 可以結合 DirectQuery 或雙重儲存模式數據表 | 是 – 可以結合匯入或雙重儲存模式數據表 |
| 單一登入 （SSO） | 是的 | 不適用 | 是的 |
| 計算表 | 否 – 除了 計算群組、假設參數，以及 字段參數，以隱含方式建立導出數據表 | 是的 | 否 – 計算表即使在參考 DirectQuery 模式中的其他表時，也會使用匯入儲存模式。 |
| 計算欄 | 不 | 是的 | 是的 |
| 混合式數據表 | 不 | 是的 | 是的 |
| 模型數據表分割區 | 否 – 不過，分區 可以在 Delta 表層級完成 | 是 – 由累加式重新整理自動建立，或使用 XMLA 端點手動建立 | 不 |
| 使用者定義的匯總 | 不 | 是的 | 是的 |
| SQL 分析端點物件層級安全性或數據行層級安全性 | 是 – 但查詢會回復為 DirectQuery 模式，而且可能會在拒絕許可權時產生錯誤 | 是 – 但必須重複具有語意模型物件層級安全性的許可權 | 是 – 但當許可權遭到拒絕時，查詢可能會產生錯誤 |
| SQL 分析端點資料列層級安全性（RLS） | 是 – 但查詢會回復為 DirectQuery 模式 | 是 – 但必須要使用語意模型 RLS 複製許可權 | 是的 |
| 語意模型資料列層級安全性 （RLS） | 是 – 但強烈建議使用 固定身分識別 雲端連線 | 是的 | 是的 |
| 語意模型物件層級安全性 （OLS） | 是的 | 是的 | 是的 |
| 不需要重新整理的大型數據磁碟區 | 是的 | 不太適合 – 查詢和重新整理可能需要較大的容量大小 | 是的 |
| 減少數據延遲 | 是 – 自動更新 啟用時，或以程序設計方式重新整理;不過，必須先完成上游 數據準備 | 不 | 是的 |
| Power BI Embedded | 是 2 | 是的 | 是的 |
1 您無法將 Direct Lake 儲存模式資料表與 DirectQuery 或雙重儲存模式資料表結合在相同的語意模型中 。 不過，您可以使用Power BI Desktop 在 Direct Lake 語意模型上建立複合模型，然後使用新的數據表來擴充它（使用匯入、DirectQuery 或雙重儲存模式）或計算。 如需詳細資訊，請參閱 在語意模型上建置複合模型。
2 需要 V2 內嵌令牌。 如果您正在使用服務主體，則必須使用 固定身分識別 雲端連線。