在湖倉（Lakehouse）架構中，資料在磁碟上的實體排列方式往往是最關鍵、卻最少被量化討論的決策之一。同樣一批資料，查詢要掃描多少位元組、延遲高低、以及因此產生多少雲端運算費用，很大程度取決於檔案怎麼擺。目前常見的三種做法思路完全不同：Partitioning（分區）把資料依某個欄位切成不同目錄，例如依交易日期分資料夾，查詢只要帶上相同條件就能整批跳過目錄，屬於最直覺也最省事的裁剪方式；ZOrder 是 Delta Lake 內建的重新排序機制，透過 OPTIMIZE 指令把多個指定欄位值相近的資料列集中到同一批檔案中，讓查詢能更精準地排除不相關檔案；Liquid Clustering 則是 Databricks 推出的新一代動態聚類，它不預先定義分區欄位，而是用 Hilbert 曲線這種空間填充曲線來決定每筆資料在檔案內的落點，資料持續進來時以增量方式調整佈局。三者一個靠目錄、一個靠固定欄位順序的檔案裁剪、一個靠檔內局部性，取捨點因此完全不同。
這篇由 Kushal Kumar Vishwakarma 發表於 InfoQ 的文章，指出目前公開的比較多半來自 Databricks 官方，或是從第一性原理推論而缺乏實際量測；作者在 TCS UK（民航航太專案）與 IBM（Shell Maritime 專案）架構 Delta Lake 平台時，發現佈局選擇會直接影響管線的服務級別協議（SLA）達成與運算成本，於是設計了一套可控的基準測試。實驗使用五千萬筆合成的零售交易資料，欄位包含均勻分佈、範圍 12,000,000 至 12,000,000 的 customer_id、涵蓋 2019 至 2023 年的 txn_date、偏向歐美市場的 region 分類、右偏且帶有高價離群值的 amount，以及 12 類的 product_cat。資料分佈刻意混合均勻與偏態，Zipf α 設為 1.2、熱點分割採 80/20，參數是依據生產環境遙測資料校準，因為真實工作負載中前兩成的客戶群體通常就貢獻了約八成的查詢流量。三種佈局分別以 partitionBy('txn_date')、OPTIMIZE 搭配 ZORDER BY (customer_id, region, txn_date)，以及 CLUSTER BY 同組欄位建立，並以四種分析工作負載交叉測試：點查、時間範圍彙總、多欄位選擇性篩選，以及無條件的全表大彙總。
四項結果中，有三項由 Liquid Clustering 拿下最低延遲。點查方面，Liquid Clustering 以 1.003 秒勝出，比只依日期分區的基準快 49%，但耐人尋味的是它掃描了 784.86 MB，反而比只讀 369.09 MB 的 ZOrder 還多一倍；原因在於檔內局部性，Hilbert 曲線把相同 customer_id 的資料緊密放在同一檔案中，磁碟尋道開銷大幅降低、掃描吞吐提高，而 ZOrder 雖然靠檔案裁剪少讀資料，卻因為要開啟更多檔案而抵銷了優勢。時間範圍彙總與全表大彙總同樣是 Liquid Clustering 最快（659 毫秒），全表情境下檔案裁剪毫無用武之地，勝負完全取決於檔內讀取效率與任務排程。真正的反轉出現在多欄位選擇性篩選：當查詢條件恰好精準對上 ZOrder 的聚類鍵組合時，ZOrder 以 615 毫秒、僅讀取 59.03 MB 拿下最佳，Liquid Clustering 卻花了 2.967 秒、讀取 639.95 MB，慢了近五倍、多掃十倍資料，因為 Liquid Clustering 為了因應多變查詢而做的廣泛局部性最佳化，無法像 ZOrder 那樣鎖定固定欄位順序做到近乎完美的檔案排除，這項代價在查詢窄且可預測時完全暴露。
另一個更值得注意的是 ZOrder 在日期範圍查詢上的隱性失效模式：當 txn_date 只被放在 ZORDER BY 的第三順位時，時間範圍彙總耗時 1.845 秒，比單純按日期分區的 1.038 秒慢了 78%。連續的日期值被打散到各個檔案中，分區原本免費提供的範圍掃描效率因此被破壞，而換回來的裁剪收益不足以彌補損失。把四項結果放在一起看，背後其實只有兩個機制在作用：檔案裁剪效率決定能避開多少資料的讀取，檔內局部性決定已讀取的資料被掃得多快。查詢若能精準對上穩定的聚類鍵，裁剪主導、ZOrder 勝出；查詢不符合、或必須全掃，局部性主導、Liquid Clustering 勝出，日期範圍的退化正是同一組取捨的另一面。據此，作者給出的核心判斷是先問一個問題：前三名的查詢是否一直篩選同樣那兩三個欄位？答案是肯定且這些欄位穩定不變，就對這幾欄做 ZOrder，並把選擇性最高的欄位排在最前；答案是否定、或查詢模式預期會演變，就以 Liquid Clustering 為預設，因為它在四種工作負載中拿下三種，還免除了手動排程 OPTIMIZE 與週期性全表重寫的維運負擔。作者也在 GitHub 開放了全部查詢與決策輔助程式供人驗證。
限制方面，作者明確指出實驗採用合成資料是為了可重現性並避免客戶資料外流，真實生產資料還有綱要漂移、存取模式的季節性與領域特定偏態，可能改變三種佈局的相對表現，因此這批結果應視為方向性指引，在做下不可逆的綱要決策前，務必用自己的前三種查詢模式、在具代表性的資料樣本上把三種配置各跑一遍。此外實驗未量測各佈局的寫入放大 I/O 與新資料進來時的維護運算開銷；從機制上推論 Liquid Clustering 的增量更新寫入成本應低於 ZOrder 的週期性全表重寫，但這一點尚未經實驗驗證，值得另行研究。整體而言，這項基準測試的價值不在於宣告某一種佈局勝出，而在於把「檔案裁剪」與「檔內局部性」兩條軸線講清楚，並標出兩個未被文件記載、可能正在生產環境中默默拖慢查詢的失效情境。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。