資料工程面試：如何評估並遷移到 Delta Lake Liquid Clustering？
題目與場景
你負責一張按 tenantid、orderdate 分區並長期使用 Z-Ordering 的 Delta Lake 訂單事實表。租戶數量成長後，小租戶查詢仍掃描大量檔案；團隊想改用 Liquid Clustering。請說明如何評估、遷移、驗證和回滾，並給出你會觀察的指標。
面試官考察點
- 能否從真實過濾條件和檔案布局診斷問題，而不是把新功能當作萬靈丹。
- 能否區分分區、Z-Ordering 與 Liquid Clustering 的相容邊界。
- 能否設計小範圍遷移、增量維護、全量重寫和回滾護欄。
- 能否用掃描位元組數、檔案數、p95 延遲和成本證明收益。
先問清楚的澄清問題
- 主要查詢是否穩定過濾
tenantid、時間範圍或customerid，謂詞選擇性如何？ - 當前表的 Delta Lake、Spark/Databricks 執行環境、讀寫用戶端版本是否支援 Liquid Clustering？
- 現有分區和 Z-Ordering 的維護頻率、單檔案大小、近兩週掃描位元組數與 p95 延遲是多少？
- 是否允許背景
OPTIMIZE帶來的額外計算，是否有低峰時段和回滾副本？
30 秒回答示範
我會先用查詢日誌確認最常用且選擇性高的過濾欄位，再用一張影子表做兩週對照。Liquid Clustering 可以在不重寫既有資料的情況下改變後續布局，但它與傳統分區和 Z-Ordering 不能同時作為布局方案，所以要先確認版本、協定和下游用戶端。遷移後按批執行增量 OPTIMIZE，必要時用 OPTIMIZE FULL 覆蓋歷史資料；比較同口徑查詢的掃描位元組數、檔案數、p95、失敗率和成本。只有收益穩定且寫入、並發、回滾都通過，才逐步擴大範圍。
深入拆解
1. 先建立工作負載輪廓
把最近兩週查詢按範本聚合，記錄過濾欄位組合、時間範圍、掃描檔案數、掃描位元組數、返回列數、p50/p95 延遲和執行成本。若查詢常帶 tenant_id，但租戶大小差異很大，單純按日期分區可能讓小租戶仍命中許多檔案。若謂詞高度漂移，固定聚類欄位的收益可能不穩定，應先保留現狀並補充觀測。
2. 選擇聚類欄位並控制欄位數
優先選擇高頻、選擇性高、能被資料跳過機制利用的過濾欄位；把低頻或高基數但幾乎不出現在謂詞中的欄位放入候選而非直接上線。Liquid Clustering 最多支援四個聚類欄位，欄位越多不代表越快，還會增加布局維護成本。用離線回放比較兩到三個候選組合，避免只看單條「最佳」查詢。
3. 設計遷移邊界和相容性檢查
官方文件說明 Liquid Clustering 需要受支援的 Delta Lake 版本；現有表啟用路徑也隨版本變化。啟用前檢查讀寫引擎、協定升級影響、串流寫入、增量讀取、備份工具和舊用戶端。Liquid Clustering 不與傳統分區或 Z-Ordering 組合使用，因此遷移計畫要明確停止舊維護工作，並在影子表驗證舊消費者。
4. 先增量維護，再決定是否全量重寫
改變聚類欄位不會自動重寫既有資料；新寫入和後續最佳化才會按新布局整理。先在影子表或低風險表上啟用並執行增量 OPTIMIZE，觀察新增資料的檔案跳過效果。歷史資料仍是主要掃描來源時，再安排 OPTIMIZE FULL，並把計算成本、鎖競爭和低峰時段納入變更評審。
CREATE TABLE fact_orders (
tenant_id STRING,
order_date DATE,
customer_id STRING,
amount DECIMAL(18, 2)
) USING DELTA
CLUSTER BY (tenant_id, order_date);
OPTIMIZE fact_orders;
ALTER TABLE fact_orders CLUSTER BY (tenant_id, customer_id);
OPTIMIZE fact_orders FULL;5. 用可重現基線驗證收益
固定同一批查詢、資料快照、並發度和快取條件，比較遷移前後掃描檔案數、掃描位元組數、p50/p95 延遲、失敗率、寫入吞吐和每次查詢成本。示例驗收門檻可以是掃描位元組數下降 30%、p95 下降 20%，且寫入成本增加不超過 10%；這些是專案示例，必須根據基線調整。還要驗證時間範圍查詢、跨租戶查詢、回填和並發最佳化，避免只最佳化一種路徑。
6. 設置回滾、治理和持續監控
保留原表快照或影子表，先用小流量讀切換，再逐步擴大。記錄聚類欄位、版本、最佳化批次和指標，給舊用戶端設定相容檢查。若 p95、寫入延遲或成本連續越過閾值，暫停擴大範圍，恢復讀路由並停止新布局維護；回滾後重新分析謂詞和資料傾斜，而不是立即換另一組欄位。
一份更完整的強回答
我會從查詢日誌建立基線，確認 tenant_id 和時間過濾是否真的主導掃描，再用兩到三個聚類欄位組合做影子表回放。上線前核對 Delta/Spark 版本、協定、串流讀寫和舊用戶端，因為 Liquid Clustering 與分區、Z-Ordering 是替代關係，且最多四欄。遷移先覆蓋新資料並增量 OPTIMIZE；若歷史檔案仍造成掃描，再在低峰執行 OPTIMIZE FULL。驗收同時看掃描位元組數、檔案數、p95、成本、寫入吞吐和失敗率，並保留快照、暫停開關和讀路由回退。連續兩個觀測窗口達標後再擴大範圍，任何指標越界都觸發暫停和復盤。
常見失分點
- 只背誦「Liquid Clustering 更快」，沒有查詢基線和對照組。
- 忽略它與分區、Z-Ordering 的不相容，繼續執行舊維護工作。
- 以為修改聚類欄位會立即重寫全部歷史資料，沒有安排增量或全量最佳化。
- 只報平均延遲，不看掃描位元組數、p95、寫入成本和資料傾斜。
- 沒有版本、協定、舊用戶端和回滾檢查，就直接在生產表執行。
追問與延伸
追問一：為什麼不把四個常用欄位全部放進去？
欄位上限不是目標。過多欄位會增加布局維護成本，且不同查詢組合可能互相稀釋收益；應按謂詞頻率、選擇性和回放結果選最小有效集合。
追問二：啟用後舊資料多久會變好？
不能直接承諾時間。既有資料不會因改欄位自動全部重寫；要看增量 OPTIMIZE 覆蓋速度，歷史占比高時再評估 OPTIMIZE FULL 的窗口和成本。
追問三：如何處理租戶極度傾斜？
按租戶分層回放，分別觀察大租戶、小租戶和跨租戶查詢。必要時調整欄位組合或查詢路由，並把最差分位而非總體平均作為門檻。
追問四：什麼信號說明應該停止遷移？
若掃描位元組數沒有穩定下降、p95 或寫入成本持續惡化、舊用戶端不相容，或回滾演練失敗，就暫停擴大範圍，恢復原布局維護並重新做工作負載分析。