瞭解 Direct Lake 語意模型的儲存空間

本文介紹 直接資料湖 的儲存概念。 它描述 Delta 數據表和 Parquet 檔案。 它也描述如何優化 Direct Lake 語意模型的 Delta 數據表，以及如何維護它們，以協助提供可靠、快速的查詢效能。

Delta 表格

OneLake 中存在 Delta 表。 它們會將檔案型數據組織成數據列和數據行，並可用於Microsoft Fabric 計算引擎，例如 筆記本、Kusto，以及 lakehouse 和 倉儲。 您可以使用 Data Analysis Expressions (DAX)、Multidimensional Expressions (MDX)、T-SQL (Transact-SQL)、Spark SQL，甚至是 Python 來查詢 Delta 表。

注意

Delta — 或 Delta Lake— 是開放原始碼記憶體格式。 這表示 Fabric 也可以查詢其他工具和廠商所建立的 Delta 數據表。

Delta 數據表會將其數據儲存在 Parquet 檔案中，通常儲存在 Direct Lake 語意模型用來載入數據的 Lakehouse 中。 不過，Parquet 檔案也可以儲存在外部。 外部 Parquet 檔案可以使用 OneLake 快捷方式來參考，其指向特定儲存位置，例如 Azure Data Lake Storage （ADLS） Gen2、Amazon S3 儲存器帳戶或 Dataverse。 在幾乎所有情況下，計算引擎會藉由查詢 Delta 數據表來存取 Parquet 檔案。 不過，通常 Direct Lake 模型會使用稱為 轉碼的程式，直接從 OneLake 中優化的 Parquet 檔案載入欄位資料。

數據版本控制

Delta 表格包含一個或多個 Parquet 檔案。 這些檔案隨附一組 JSON 鏈接檔案，可追蹤每個與 Delta 數據表相關聯之 Parquet 檔案的順序和本質。

請務必瞭解基礎 Parquet 檔案本質上是累加式的。 因此，名稱 Delta 是累加式數據修改的參考。 每次對 Delta 資料表進行寫入作業時，例如插入、更新或刪除數據時，都會建立新的 Parquet 檔案，以 版本來表示數據修改。 因此，Parquet 檔案 固定，這表示永遠不會修改。 因此，在 Delta 資料表的一組 Parquet 檔案中，數據可能會重複多次。 Delta 架構依賴連結檔案來判斷產生正確查詢結果所需的實體 Parquet 檔案。

請考慮本文用來說明不同數據修改作業之 Delta 數據表的簡單範例。 數據表有兩個數據行，並儲存三個數據列。

ProductID	StockOnHand
一個	1
B	2
C	3

Delta 數據表數據會儲存在包含所有數據的單一 Parquet 檔案中，而且有一個單一鏈接檔案，其中包含插入數據時的相關元數據（附加）。

• Parquet 檔案 1：
  • ProductID：A、B、C
  • StockOnHand： 1， 2， 3
• 連結檔案 1：
  • 包含建立 Parquet file 1 的時間戳，以及附加數據的記錄。

插入作業

請考慮插入作業發生時會發生什麼事：插入產品 C 的新數據列，並插入 4 的庫存值。 這項作業會導致建立新的 Parquet 檔案和鏈接檔案，因此現在有兩個 Parquet 檔案和兩個鏈接檔案。

• Parquet 檔案 1：
  • ProductID：A、B、C
  • StockOnHand： 1， 2， 3
• Parquet 檔案 2：
  • ProductID： D
  • StockOnHand： 4
• 連結檔案 1：
  • 包含建立 Parquet file 1 的時間戳，以及附加數據的記錄。
• 連結檔案 2：
  • 包含建立 Parquet file 2 的時間戳，以及附加數據的記錄。

此時，Delta 數據表的查詢會傳回下列結果。 結果來自多個 Parquet 檔案沒有關係。

ProductID	現有庫存
一個	1
B	2
C	3
D	4

每次後續的插入作業都會建立新的 Parquet 檔案和鏈接檔案。 這表示 Parquet 檔案和連結檔案的數目隨著每個插入作業而成長。

更新作業

現在，請考慮更新作業發生時會發生什麼事：產品 D 的資料列已將庫存數量變更為 10。 這項作業會導致建立新的 Parquet 檔案和鏈接檔案，因此現在有三個 Parquet 檔案和三個鏈接檔案。

• Parquet 檔案 1：
  • ProductID：A、B、C
  • StockOnHand： 1， 2， 3
• Parquet 檔案 2：
  • ProductID： D
  • StockOnHand： 4
• Parquet 檔案 3：
  • ProductID： C
  • StockOnHand： 10
• 連結檔案 1：
  • 包含建立 Parquet file 1 的時間戳，以及附加數據的記錄。
• 連結檔案 2：
  • 包含建立 Parquet file 2 的時間戳，以及附加數據的記錄。
• 連結檔案 3：
  • 包含建立 Parquet file 3 的時間戳，以及更新數據的記錄。

此時，Delta 數據表的查詢會傳回下列結果。

ProductID	StockOnHand
一個	1
B	2
C	10
D	4

產品 C 的數據現在存在於多個 Parquet 檔案中。 不過，Delta 數據表的查詢會結合連結檔案，以判斷應該使用哪些數據來提供正確的結果。

刪除作業

現在，請考慮刪除作業發生時會發生什麼情況：刪除產品 B 的數據列。 這項作業會產生新的 Parquet 檔案和鏈接檔案，因此現在有四個 Parquet 檔案和四個鏈接檔案。

• Parquet 檔案 1：
  • ProductID：A、B、C
  • StockOnHand： 1， 2， 3
• Parquet 檔案 2：
  • ProductID： D
  • 現有存貨：4
• Parquet 檔案 3：
  • ProductID： C
  • 庫存現有量：10
• Parquet 檔案 4：
  • ProductID：A、C、D
  • StockOnHand： 1， 10， 4
• 連結檔案 1：
  • 包含建立 Parquet file 1 的時間戳，以及附加數據的記錄。
• 連結檔案 2：
  • 包含建立 Parquet file 2 的時間戳，以及附加數據的記錄。
• 連結檔案 3：
  • 包含建立 Parquet file 3 的時間戳，以及更新數據的記錄。
• 連結檔案 4：
  • 包含建立 Parquet file 4 的時間戳，以及已刪除數據的記錄。

請注意，Parquet file 4 不再包含產品 B的數據，但它確實包含數據表中所有其他數據列的數據。

此時，Delta 數據表的查詢會傳回下列結果。

ProductID	現有庫存
一個	1
C	10
D	4

注意

此範例很簡單，因為它牽涉到小型數據表、只是一些作業，而且只有次要修改。 執行許多寫入作業且包含許多行數據的大型資料表，會在每個版本產生不止一個 Parquet 檔案。

重要

視您定義 Delta 資料表的方式和資料修改作業的頻率而定，可能會導致許多 Parquet 檔案。 請注意，每個 Fabric 容量授權都有 限制條款。 如果 Delta 資料表的 Parquet 檔案數量超過您 SKU 的限制，查詢將會 返回到 DirectQuery，這可能導致查詢效能下降。

若要管理 Parquet 檔案數目，請參閱本文稍後的 Delta 數據表維護。

時間增量旅行

鏈接檔案讓你能查詢數據，追溯至先前的時間點。 這項功能稱為 Delta 時間移動。 先前的時間點可能是時間戳記或版本號。

請考慮下列查詢範例。

SELECT * FROM Inventory TIMESTAMP AS OF '2024-04-28T09:15:00.000Z';
SELECT * FROM Inventory AS OF VERSION 2;

提示

您也可以使用 @ 速記語法來指定時間戳或版本做為資料表名稱的一部分來查詢資料表。 時間戳的格式必須為 yyyyMMddHHmmssSSS。 您可以在 @ 之後指定版本，方法是在版本前面加上 v。

以下是使用速記語法重寫的先前查詢範例。

SELECT * FROM Inventory@20240428091500000;
SELECT * FROM Inventory@v2;

重要

使用時間旅行技術存取的表格版本，是由交易日誌檔案的保留閾值和 VACUUM 作業的頻率及指定保留期限的組合所決定（稍後在 Delta 表格維護 部分中詳述）。 如果您每天以預設值執行 VACUUM，則會有七天的數據可供時間移動。

框架

框架 是 Direct Lake 作業，可設定應該用來將數據載入語意模型數據行的 Delta 資料表版本。 同樣重要的是，版本也會決定載入數據時應該排除的內容。

框架作業會將每個 Delta 資料表的時間戳/版本戳記到語意模型數據表中。 此時，當語意模型需要從 Delta 數據表載入數據時，會使用與最新框架作業相關聯的時間戳/版本來判斷要載入的數據。 自從最新的框架作業以來，對 Delta 數據表進行的任何後續數據修改都會被忽略（直到下一次框架作業）。

重要

因為框架語意模型參考特定的 Delta 數據表版本，所以來源必須確定它會保留 Delta 數據表版本，直到完成新版本的框架為止。 否則，當模型需要存取 Delta 資料表檔案，而這些檔案已經被生產者的工作負載清理或刪除時，使用者就會遇到錯誤。

如需架構的詳細資訊，請參閱 Direct Lake 概觀。

資料表分區

可以對 Delta 表進行分割，以便將資料列的子集儲存在一組 Parquet 檔案中。 分割區可以加速查詢和寫入作業。

假設 Delta 數據表有一十億個銷售數據列，為期兩年。 雖然可以將所有數據儲存在單一 Parquet 檔案集中，但對於此數據磁碟區而言，讀取和寫入作業並不理想。 相反地，透過將數十億個數據列分散到多個 Parquet 檔案，即可改善效能。

在設定資料表分割時，必須定義 分割鍵。 分區鍵決定哪些行要儲存在哪個系列中。 對於 Delta 資料表，分區鍵可以根據指定資料行中的不同值來定義，例如日期資料表的月/年資料行。 在此情況下，兩年的數據會分散到24個分割區（2年 x12個月）。

分布式計算引擎無法辨識資料表分割。 當他們插入新的分割區索引鍵值時，會自動建立新的分割區。 在 OneLake 中，您會找到每個唯一分割區索引鍵值的一個子資料夾，而每個子資料夾會儲存自己的一組 Parquet 檔案和鏈接檔案。 至少必須有一個 Parquet 檔案和一個連結檔案存在，但每個子資料夾中的實際檔案數目可能會有所不同。 在進行數據修改操作時，每個分割區都會維護自己的一組 Parquet 檔案和連結檔案，以追蹤給定的時間戳或版本需要返回的內容。

如果對分區的 Delta 資料表進行查詢，僅篩選最近三個月的銷售數據，則可以快速識別需要存取的 Parquet 檔案和連結檔案的子集。 如此一來，即可完全略過許多 Parquet 檔案，進而提升讀取效能。

不過，不會根據分割索引鍵進行篩選的查詢不一定總是能夠有更好的表現。 當 Delta 表將所有資料儲存在單一大型 Parquet 檔案集中，而出現檔案或行組片段時，就可能發生這種情況。 雖然可以在多個叢集節點之間並行獲取多個 Parquet 檔案中的數據，但許多小型 Parquet 檔案可能會對檔案 I/O 造成負面影響，因此影響查詢效能。 基於這個理由，最好避免在大部分情況下分割 Delta 數據表，除非寫入作業或擷取、轉換和載入 （ETL） 程式會從中明顯受益。

數據分割也有利於插入、更新和刪除作業，因為檔案活動只會發生在符合已修改或刪除數據列之數據分割索引鍵的子資料夾中。 例如，如果將一批數據插入數據分割的 Delta 數據表中，則會評估數據以判斷批次中存在的數據分割索引鍵值。 然後，資料只會導向分區的相關資料夾。

瞭解差異數據表使用分割區的方式，可協助您設計最佳的 ETL 案例，以減少更新大型差異數據表時需要執行的寫入作業。 寫入效能可以透過減少需要建立的新 Parquet 檔案的數量和大小來提升。 針對依月份/年分割的大型 Delta 數據表，如上一個範例所述，新數據只會將新的 Parquet 檔案新增至最新的分割區。 先前行事曆月份的子資料夾仍維持不變。 如果必須修改前一個行事曆月份的任何數據，則只有相關的分割區資料夾會收到新的分割區和鏈接檔案。

重要

如果 Delta 數據表的主要用途是作為語意模型的數據來源（其次是用於其他查詢工作負載），通常最好避免分區，以便將 列載入優化至記憶體。

針對 Direct 湖語義模型或 SQL 分析端點，優化 Delta 資料表分割的最佳方式是讓 Fabric 自動管理每個版本的 Delta 資料表的 Parquet 檔案。 將管理留給 Fabric 應該透過平行處理來產生高查詢效能，不過它不一定提供最佳寫入效能。

如果您必須針對寫入操作進行優化，請考慮使用分區，根據分區鍵將寫入操作優化至 Delta 表格。 不過，請注意，過度分割 Delta 數據表可能會對讀取效能造成負面影響。 基於這個理由，我們建議您仔細測試讀寫表現，可以考慮建立相同 Delta 表的多個副本來比較時間。

警告

如果您在高基數欄位上分區，可能會導致過多的 Parquet 檔案。 請注意，每個 Fabric 容量授權都有 限制。 如果 Delta 資料表的 Parquet 文件數量超過 SKU 的限制，查詢將 回退至 DirectQuery，這可能會導致查詢速度變慢。

Parquet 檔案

Delta 數據表的基礎記憶體是一或多個 Parquet 檔案。 Parquet 檔案格式通常用於 一次寫入、多次讀取 的應用程式。 每次修改 Delta 資料表中的數據時，都會建立新的 Parquet 檔案，無論是插入、更新或刪除作業。

注意

您可以使用工具存取與 Delta 資料表相關聯的 Parquet 檔案，例如 OneLake 檔案總管。 檔案可以下載、複製或移至其他目的地，就像移動任何其他檔案一樣容易。 不過，它是 Parquet 檔案與 JSON 鏈接檔案的組合，可讓計算引擎以 Delta 數據表的形式對檔案發出查詢。

Parquet 檔案格式

Parquet 檔案的內部格式與其他常見的數據儲存格式不同，例如 CSV、TSV、XMLA 和 JSON。 這些格式會依數據列 組織數據，而 Parquet 則依數據行 組織數據。 此外，Parquet 檔案格式與這些格式不同，因為它會將數據列組織成一或多個 數據列群組，。

Power BI 語意模型的內部數據結構是以列為基礎，這表示 Parquet 檔案與 Power BI 有許多相似之處。 這種相似性表示 Direct Lake 語意模型可以有效率地將數據從 Parquet 檔案直接載入記憶體。 事實上，大量的數據可以在幾秒內載入。 將這項功能與「匯入」語意模型的重新整理形成對比，該模型必須擷取區塊或源數據，然後處理、編碼、儲存，然後將它載入記憶體中。 匯入語意模型重新整理作業也可以耗用大量的計算（記憶體和CPU），而且需要相當長的時間才能完成。 不過，使用 Delta 數據表時，當 Parquet 檔案被產生，大部分準備適合直接載入語意模型的數據的努力就已經完成。

Parquet 檔案儲存數據的方式

請考慮下列範例數據集。

日期	ProductID	StockOnHand
2024年9月16日	一個	10
2024-09-16	B	11
2024年9月17日	一個	13
…

以 Parquet 檔案格式儲存時，概念上，此數據集看起來可能會像下列文字。

Header:
RowGroup1:
    Date: 2024-09-16, 2024-09-16, 2024-09-17…
    ProductID: A, B, A…
    StockOnHand: 10, 11, 13…
RowGroup2:
    …
Footer:

資料會藉由將常見值替換為字典鍵來壓縮，並套用 長度編碼法（RLE）。 RLE 會努力將一系列相同的值壓縮成較小的表示法。 在下列範例中，會在標頭中建立數值索引鍵與值的字典對應，並使用較小的索引鍵值來取代數據值。

Header:
    Dictionary: [
        (1, 2024-09-16), (2, 2024-09-17),
        (3, A), (4, B),
        (5, 10), (6, 11), (7, 13)
        …
    ]
RowGroup1:
    Date: 1, 1, 2…
    ProductID: 3, 4, 3…
    StockOnHand: 5, 6, 7…
Footer:

當 Direct Lake 語義模型需要資料來計算依 ProductID分組的 StockOnHand 欄位總和時，只需要與這兩個欄位相關聯的字典和資料。 在包含許多欄的大型檔案中，可以略過 Parquet 檔案的許多部分，以協助加快讀取過程。

注意

Parquet 檔案的內容不是人類可讀取的，因此它不適合在文本編輯器中開啟。 不過，有許多開放原始碼工具可供開啟並顯示 Parquet 檔案的內容。 這些工具也可以讓您檢查元數據，例如檔案中包含的數據列和數據列群組數目。

V 順序

Fabric 支援一種稱為 V-Order的額外優化。 V 順序是 Parquet 檔案格式在寫入過程中的一項優化。 套用 V 順序後，檔案會變得更小，因而讀取更快。 此優化特別適用於 Direct Lake 語意模型，因為它會準備數據以快速載入記憶體，因此對容量資源的需求較少。 這也會導致查詢效能更快，因為需要掃描的記憶體較少。

由 Fabric 元件建立和載入的 Delta 表，例如 資料管道、資料流程，以及 筆記本 會自動套用 V 順序套用。 不過，上傳至 Fabric Lakehouse 的 Parquet 檔案，或由 快捷方式所參考的 Parquet 檔案，可能不會套用此優化。 雖然非優化的 Parquet 檔案仍可被讀取，但其讀取效能可能不如應用了 V-Order 排序的對等 Parquet 檔案那麼快。

注意

已套用 V-Order 的 Parquet 檔案仍然遵循開放原始碼的 Parquet 檔案格式。 因此，非網狀架構工具可以讀取它們。

如需詳細資訊，請參閱 Delta Lake 表格優化和 V-Order。

Delta 表格優化

本節說明優化 Delta 資料表以符合語意模型的各種主題。

數據量

雖然 Delta 表可以成長以儲存極大量的數據，但 Fabric 容量限制 限制查詢它們的語意模型。 當超過這些限制時，查詢會 回復為 DirectQuery，這可能會導致查詢效能變慢。

因此，請考慮藉由提高數據粒度（儲存摘要數據）、減少維度或儲存較少的歷程記錄，來限制大型 事實數據表的數據列計數。

此外，請確保已套用 V-Order，因為它會產生較小且因此更快速的檔案讀取。

欄位資料類型

努力減少每個 Delta 資料表中每個數據行中的基數（唯一值數目）。 這是因為所有數據行都會使用 哈希編碼來壓縮和儲存。 哈希編碼需要 V 順序優化，才能將數值標識符指派給數據行中包含的每個唯一值。 這麼一來，儲存的就是數字識別碼，在儲存和查詢過程中需要做哈希查找。

當您使用 近似數值數據類型時（例如 float 和 real），請考慮進行四捨五入並使精度降低。

不必要的欄

和任何數據表一樣，Delta 資料表應該只儲存所需的數據行。 在本文中，這是由語意模型所要求的，不過可能有可以查詢 Delta 表格的其他分析工作負載。

Delta 表應包含支援模型關聯性的欄位，並包括語意模型所需的欄位以進行篩選、分組、排序及摘要。 雖然不必要的欄位不會影響語意模型查詢效能（因為它們不會載入記憶體），但它們會導致更大的存儲空間需求，因此需要更多計算資源來載入和維護。

由於 Direct Lake 語意模型不支援計算欄位，因此您應將這類欄位具體化於 Delta 表格中。 請注意，此設計方法是匯入和 DirectQuery 語意模型的反模式。 例如，如果您有 FirstName 和 LastName 數據行，而且您需要 FullName 數據行，請在將數據列插入 Delta 資料表時具體化此數據行的值。

請考慮某些語意模型摘要可能相依於一個以上的數據行。 例如，若要計算銷售，模型中的量值會加總兩個數據行的乘積：Quantity 和 Price。 如果這兩個數據行都未獨立使用，將銷售計算具體化為單一數據行會更有效率，而不是將其元件值儲存在不同的數據行中。

列群組大小

在內部，Parquet 檔案會將數據列組織成每個檔案內的多個數據列群組。 例如，包含 30,000 個數據列的 Parquet 檔案可能會將它們分成三個數據列群組，每個群組都有 10,000 個數據列。

數據列群組中的數據列數目會影響 Direct Lake 讀取數據的速度。 由於 I/O 過多，具有較少行數的較多行群組數目可能會對將欄位數據載入語意模型中產生負面影響。

一般而言，我們不建議您變更預設的數據列群組大小。 不過，您可以考慮變更大型 Delta 數據表的數據列群組大小。 請務必仔細測試讀取和寫入效能，例如建立具有不同組態的相同的 Delta 資料表的多個副本來比較計時。

重要

請注意，每個 Fabric 容量授權都有 護欄。 如果 Delta 數據表的數據列群組數目超過 SKU 的限制，查詢 回復到 DirectQuery，這可能會導致查詢效能變慢。

Delta 表維護

一段時間后，隨著寫入作業的發生，Delta 數據表版本會累積。 最後，您可能會發現讀取效能受到負面影響的程度變得明顯。 更糟的是，如果每個數據表的 Parquet 檔案數目或每個數據表的數據列群組，或每個數據表的數據列超過容量 的護欄，查詢 會回復為 DirectQuery，這可能會導致查詢效能變慢。 因此，請務必定期維護 Delta 數據表。

優化

您可以使用 OPTIMIZE，將 Delta 數據表優化，將較小的檔案聯合成較大的檔案。 您也可以將 WHERE 子句設定為僅以符合指定分割條件的篩選資料列子集作為目標。 僅支援涉及分割區索引鍵的篩選。 OPTIMIZE 命令也可以套用 V 順序來壓縮和重寫 Parquet 檔案。

建議您定期在大型且經常更新的 Delta 數據表上執行此命令，或許每天都會在 ETL 程式完成時執行。 平衡更好的查詢效能與優化數據表所需的資源使用量成本之間的取捨。

真空

您可以使用 VACUUM 來移除不再參考和/或早於設定保留閾值的檔案。 請小心設定適當的保留期間，否則您可能會失去 時間移動 回到語意模型數據表中加上圖章的版本的能力。

重要

因為框架語意模型參考特定的 Delta 數據表版本，所以來源必須確定它會保留 Delta 數據表版本，直到完成新版本的框架為止。 否則，當模型需要存取 Delta 資料表檔案，而這些檔案已被生產工作負載清除或刪除時，使用者就會遇到錯誤。

REORG TABLE

您可以使用 REORG TABLE 來重新組織 Delta 表，方法是重寫檔案以清除虛刪除的數據，例如當您使用 ALTER TABLE DROP COLUMN卸除欄位時。

自動化數據表維護

若要自動化數據表維護作業，您可以使用 Lakehouse API。 如需詳細資訊，請參閱 使用 Microsoft Fabric REST API 管理 Lakehouse。

提示

您也可以在網狀架構入口網站中使用 lakehouse 資料表維護功能，以簡化 Delta 數據表的管理。

相關內容

• Direct Lake 概觀
• 開發 Direct Lake 語意模型
• 管理 Direct Lake 語意模型
• Delta Lake 資料表優化和 V-Order