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 Lakehouse 或 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 載入這些數據行的所有數據。 載入數據行數據通常是非常快速的作業，但取決於儲存在數據行中的數據基數等因素。
載入記憶體中的數據行接著 會常駐 於記憶體中。 未來只涉及常駐數據行的查詢不需要將更多數據行載入記憶體中。
數據行會保持居民狀態，直到有理由將它從記憶體中移除（收回）。 可能會移除資料列的原因包括：
- 模型或數據表已重新整理（請參閱 下一節中的框架 ）。
- 沒有任何查詢使用數據行一段時間。
- 其他記憶體管理原因，包括容量中的記憶體壓力，因為其他並行作業。
您選擇的網狀架構 SKU 會決定容量上每個 Direct Lake 語意模型的最大可用記憶體。 如需資源護欄和記憶體限制上限的詳細資訊，請參閱 本文稍後的網狀架構容量護欄和限制 。
框架
框架 可為模型擁有者提供時間點控制，以控制將數據載入語意模型。 框架是由語意模型重新整理所觸發的 Direct Lake 作業，在大部分情況下只需要幾秒鐘的時間才能完成。 這是因為這是低成本的作業，語意模型會分析最新版 Delta Lake 數據表的元數據，並更新為參考 OneLake 中最新的 Parquet 檔案。
發生框架時，可能會從記憶體收回常駐數據行，而重新整理的時間點會成為所有未來轉碼事件的新基準。 從這一點開始，Direct Lake 查詢只會考慮在最近框架作業時，差異數據表中的數據。 因此，系統會查詢 Direct Lake 數據表，以根據最近框架作業時 Delta 數據表的狀態傳回數據。 該時間不一定是 Delta 數據表的最新狀態。
下圖顯示 Direct Lake 框架作業的運作方式。
此圖描述下列程式和功能。
| 項目 | 說明 |
|---|---|
|
網狀架構工作區中有語意模型。 |
|
框架作業會定期進行，並設定所有未來 轉碼 事件的基準。 框架作業可以自動、手動、依排程或以程式設計方式進行。 |
|
OneLake 會儲存元數據和 Parquet 檔案，以 Delta 數據表表示。 |
|
最後一個框架作業包含與 Delta 資料表相關的 Parquet 檔案，特別是最後一個框架作業之前新增的 Parquet 檔案。 |
|
稍後的框架作業包含最後一個框架作業之後新增的 Parquet 檔案。 |
|
Direct Lake 語意模型中的常駐數據行可能會從記憶體收回，而且重新整理的時間點會成為所有未來轉碼事件的新基準。 |
|
後續的數據修改，以新的 Parquet 檔案表示，直到下一個框架作業發生之前，才會顯示。 |
當轉碼作業發生時，不一定有代表任何 Delta 數據表最新狀態的數據。 請考慮框架可協助您在差異數據表中的數據暫時性環境中提供一致的查詢結果。 數據可能會因為數個原因而暫時性，例如長時間執行的擷取、轉換和載入 （ETL） 進程發生時。
Direct Lake 語意模型的重新整理可以手動、自動或以程式設計方式完成。 如需詳細資訊，請參閱 重新整理 Direct Lake 語意模型。
如需差異數據表版本設定和框架的詳細資訊，請參閱 瞭解 Direct Lake 語意模型的記憶體。
自動更新
有語意模型層級設定可自動更新 Direct Lake 數據表。 此項目預設為啟用。 它可確保 OneLake 中的數據變更會自動反映在 Direct Lake 語意模型中。 當您想要透過框架控制數據變更時，應該停用自動更新，如上一節所述。 如需詳細資訊，請參閱 管理 Direct Lake 語意模型。
提示
您可以在 Power BI 報表中設定 自動頁面重新 整理。 這是自動重新整理特定報表頁面的功能，提供報表連接到 Direct Lake 語意模型（或其他類型的語意模型）。
DirectQuery 後援
傳送至 Direct Lake 語意模型的查詢可以回復為 DirectQuery 模式。 在此情況下，它會直接從 Lakehouse 或倉儲的 SQL 分析端點擷取數據。 這類查詢一律會傳回最新的數據，因為它們不會受限於最後一個框架作業的時間點。
當語意模型查詢 SQL 分析端點中的檢視，或強制執行數據列層級安全性的 SQL 分析端點數據表時，查詢一律會回復。
此外，當語意模型 超過容量的護欄時，查詢可能會回復。
重要
可能的話，您應該一律設計解決方案或調整容量大小，以避免 DirectQuery 後援。 這是因為它可能會導致查詢效能變慢。
您可以藉由設定 DirectLakeBehavior 屬性來控制 Direct Lake 語意模型的後援。 如需詳細資訊，請參閱 設定 Direct Lake 行為屬性。
網狀架構容量護欄和限制
Direct Lake 語意模型需要 網狀架構容量授權。 此外，還有適用於您的 Fabric 容量訂用帳戶的容量防護欄和限制，如下表所示。
重要
下表中的第一個數據行也包含 Power BI Premium 容量訂用帳戶 （P SKU）。 請注意，Microsoft正在合併購買選項，並淘汰每個容量 SKU 的 Power BI Premium。 新客戶和現有客戶應考慮改為購買 Fabric 容量訂用帳戶 (F SKU)。
如需詳細資訊，請參閱 Power BI Premium 授權 和 Power BI Premium 的重要更新。
| Fabric 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 | 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 對於 Direct Lake 語意模型， Max Memory 代表可分頁多少數據的記憶體資源上限。 基於這個理由，它不是護欄，因為超過它不會產生 DirectQuery 模式的後援;不過，如果數據量夠大而造成 OneLake 數據中的模型數據分頁和移出，可能會對效能造成影響。
如果超過， 磁碟/OneLake 上的模型大小上限會導致語意模型的所有查詢回復為 DirectQuery 模式。 數據表中呈現的所有其他護欄都會根據每個查詢進行評估。 因此，請務必 將 Delta 數據表 和 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 （不是數位）。
- 不支援使用 適用於客戶 使用案例的內嵌案例。
- 只有在使用 Direct Lake 語意模型的固定身分識別時，才支援從 Power BI 發佈至 Web。
- 在 Web 模型化體驗中，Direct Lake 語意模型的驗證有限。 用戶選取專案會假設正確，而且不會發出任何查詢來驗證關聯性的基數或交叉篩選選取專案，或是標示日期數據表中選取的日期數據行。
- 在網狀架構入口網站中，重新 整理歷程記錄中的 [Direct Lake] 索引卷標只會列出 Direct Lake 相關的重新整理失敗。 未列出成功重新整理（框架）作業。
- 您的網狀架構 SKU 會針對容量決定每個 Direct Lake 語意模型的最大可用記憶體。 超過限制時，語意模型的查詢可能會因為模型數據的分頁和移出過多而變慢。
- 不支援在位於數據源工作區不同區域的工作區中建立 Direct Lake 語意模型。 例如，如果 Lakehouse 位於美國中西部，則您只能從相同區域中的這個 Lakehouse 建立語意模型。 因應措施是在其他區域的工作區中建立 Lakehouse，並在建立語意模型之前，先建立數據表的快捷方式。 若要尋找您位於哪個區域，請參閱 尋找您的 Fabric 主區域。
與其他儲存模式的比較
下表比較 Direct Lake 儲存模式與匯入和 DirectQuery 儲存模式。
| 功能 | Direct Lake | Import | DirectQuery |
|---|---|---|---|
| 授權 | 僅限網狀架構容量訂用帳戶 （SKU） | 任何網狀架構或 Power BI 授權（包括Microsoft網狀架構免費授權） | 任何網狀架構或 Power BI 授權（包括Microsoft網狀架構免費授權） |
| 資料來源 | 只有 Lakehouse 或倉儲資料表 （或檢視表） | 任何連接器 | 任何支援 DirectQuery 模式的連接器 |
| 線上到 SQL 分析端點檢視 | 是 – 但會自動回復到 DirectQuery 模式 | Yes | Yes |
| 複合模型 | 否 1 | 是 – 可以結合 DirectQuery 或雙重儲存模式數據表 | 是 – 可以結合匯入或雙重儲存模式數據表 |
| 單一登入 (SSO) | Yes | 不適用 | Yes |
| 計算資料表 | 否 – 除了計算群組、假設參數和字段參數，這些參數會隱含建立匯出數據表 | Yes | 否 – 匯出數據表即使在 DirectQuery 模式中參考其他數據表時，也會使用匯入儲存模式 |
| 計算結果欄 | No | .是 | Yes |
| 混合式資料表 | No | .是 | Yes |
| 模型數據表分割區 | 否 – 不過 ，數據分割 可以在 Delta 數據表層級完成 | 是 – 由累加式重新整理自動建立，或使用 XMLA 端點手動建立 | No |
| 使用者定義的彙總 | No | .是 | Yes |
| SQL 分析端點物件層級安全性或數據行層級安全性 | 是 – 但查詢會回復為 DirectQuery 模式，而且可能會在拒絕許可權時產生錯誤 | 是 – 但必須重複具有語意模型物件層級安全性的許可權 | 是 – 但當許可權遭到拒絕時，查詢可能會產生錯誤 |
| SQL 分析端點資料列層級安全性 （RLS） | 是 – 但查詢會回復為 DirectQuery 模式 | 是 – 但必須使用語意模型 RLS 重複許可權 | Yes |
| 語意模型資料列層級安全性 （RLS） | 是 – 但強烈建議使用 固定身分 識別雲端連線 | Yes | Yes |
| 語意模型物件層級安全性 （OLS） | Yes | .是 | Yes |
| 不需要重新整理的大型數據磁碟區 | Yes | 不太適合 – 查詢和重新整理可能需要較大的容量大小 | Yes |
| 減少數據延遲 | 是 – 啟用自動更新或以程序設計方式重新建構時;不過，數據準備必須先在上游完成 | No | Yes |
1 您無法將 Direct Lake 儲存模式數據表與相同語意模型中的 DirectQuery 或雙重儲存模式數據表結合。 不過，您可以使用Power BI Desktop 在 Direct Lake 語意模型上建立複合模型，然後使用新的數據表來擴充它（使用匯入、DirectQuery 或雙重儲存模式）或計算。 如需詳細資訊，請參閱 在語意模型上建置複合模型。