題幹與適用場景
一張 Iceberg 表按日期與租戶組織，查詢經常按低基數狀態欄位過濾，但每次規劃仍要檢查大量資料檔。團隊希望把不能直接放進 manifest 的索引或統計放入 Puffin，再由規劃器選擇性使用。請說明如何綁定 snapshot、避免陳舊統計誤導裁剪、處理統計缺失與並行提交，並證明收益不犧牲正確性。
容量、過濾選擇性與檔案數量是面試設定，不是通用基準。題目適合資料工程、湖倉儲存、查詢引擎與資料平台職位。核心能力是表格式中繼資料與查詢規劃，因此歸為 data。
面試官考察點
第一，能否理解 Puffin 邊界。Puffin 是存放 Iceberg 表索引與統計的檔案格式，blob 中繼資料描述內容；它不能取代表快照或 manifest。
第二，能否區分「可選最佳化」與「正確性中繼資料」。統計可被 reader 忽略，忽略時仍必須正確讀取；裁剪只能安全減少確定不匹配的候選。
第三，能否綁定 snapshot 與分割區。統計要標識適用 snapshot、分割區或資料檔範圍；表更新後不能盲用舊 blob。
第四，能否處理成本與維護。額外檔案需要物件儲存 I/O、快取、生成作業與過期策略；低選擇性查詢可能只增加規劃成本。
第五，能否設計灰度與回退。讀取失敗、blob 缺失、版本不相容或校驗失敗時，規劃器應回退 manifest 與資料檔掃描。
回答前需要釐清的問題
- 使用的 Iceberg 版本與查詢引擎是否支援目標 Puffin blob 類型？
- 統計按分割區、資料檔、欄位還是值域生成？
- 表是否頻繁提交 snapshot、回寫與時間旅行？
- 統計生成延遲允許多久，能否接受最終一致的最佳化收益？
- blob 的壓縮、校驗、加密與物件儲存權限如何管理？
- 查詢規劃器如何證明候選被安全排除？
30 秒回答框架
「我先確認 reader 支援的 Puffin blob 類型與 Iceberg snapshot 關聯方式。統計只提供可選最佳化，不能成為正確性前提；每個 blob 要記錄適用 snapshot、分割區或資料檔範圍，規劃器遇到缺失、陳舊或解析失敗就回退 manifest。生成作業以 snapshot 為輸入並原子提交引用，避免在新 snapshot 上重用舊統計。灰度比較候選檔案數、規劃時間、額外 Puffin I/O、端到端延遲與結果校驗。」
分步驟深入解答
第一步：確認 Puffin 與表 snapshot 的關係
Puffin 用於保存不能直接放進 Iceberg manifest 的索引與統計。StatisticsFile API 提供路徑、檔案大小、footer 大小、blob 中繼資料與關聯 snapshot ID。先把這些欄位納入中繼資料契約，不能只把物件路徑寫入外部設定。
第二步：定義 blob 內容與範圍
每個 blob 應說明類型、版本、編碼、覆蓋的分割區或資料檔、生成 snapshot，以及統計欄位與比較規則。低基數狀態欄位可用分割區計數或值域摘要；無法安全判斷的高基數欄位只用於觀測。
statistics = build_from_snapshot(snapshot_id, data_files)
blob = {
type, version, snapshot_id, partition_scope,
covered_files, column_rules, checksum, payload
}
commit_statistics_file(blob)第三步：設計安全裁剪
只有統計明確證明檔案不可能命中時，規劃器才排除候選。統計缺失、值域重疊、null 語義不確定、blob 版本未知或校驗失敗，都回退 manifest 與資料檔過濾。不能把「沒有統計」解釋為「沒有資料」。
第四步：處理 snapshot 並行與陳舊性
生成作業從固定 snapshot 讀取輸入，提交時檢查表仍可引用該 snapshot 或相容後代。新寫入、刪除與分割區演進可能改變檔案集合；舊 blob 只能用於它聲明覆蓋的範圍。不要在物件儲存中原地改寫 Puffin。
第五步：規劃讀取與快取
Puffin 本身也有 footer 與 blob I/O。規劃器先用輕量目錄資訊判斷是否值得讀取，再按查詢欄位與分割區選 blob。快取鍵包含表識別、snapshot、blob 類型與版本；讀取異常時使快取失效並回退。
第六步：成本、過期與權限
記錄 blob 位元組、footer 比例、生成 CPU、物件儲存請求與規劃命中率。snapshot 過期或檔案重寫後，統計檔要按引用關係清理，不能只按修改時間刪除。生成與讀取身份授予最小權限，必要時加密敏感統計。
第七步：灰度驗收
對同一 snapshot 使用統計開啟與關閉兩條規劃路徑，比較候選檔案集合、掃描位元組、規劃 p50/p95、額外 Puffin I/O、端到端延遲與結果雜湊。故意刪除 blob、製造版本不匹配與並行提交，驗證回退仍返回完整結果。
高品質示範回答
「我會把 Puffin 當作可選的規劃加速層。生成作業從固定 snapshot 讀取資料檔，blob 中繼資料記錄 snapshot、分割區或檔案範圍、欄位規則、版本與校驗值；新 snapshot 不能重用超出聲明範圍的舊 blob。
規劃器只有在統計能安全證明不匹配時才排除檔案。缺失、陳舊、解析失敗、null 語義不清或版本未知都回退 manifest 與資料檔過濾，不能把缺統計當成空結果。快取鍵包含表、snapshot、類型與版本。
灰度時比較候選檔案數、規劃時間、Puffin I/O、端到端 p95 與結果雜湊，並故意注入缺失 blob 與並行提交。只有收益穩定、回退正確且維護成本可接受才擴大。」
常見錯誤
- 把 Puffin 當 snapshot 真源 → 統計失效會改變結果 → 只做可選最佳化並保留 manifest 回退。
- 只記錄物件路徑 → 無法判斷適用 snapshot 與範圍 → 寫入完整 blob 中繼資料。
- 陳舊 blob 繼續裁剪 → 新寫入或刪除可能被漏掉 → 綁定 snapshot 與覆蓋檔案。
- 缺失統計返回空結果 → 把未知誤判為無匹配 → 回退正常過濾。
- 原地覆蓋 Puffin → 並行 reader 看到混合版本 → 生成新檔並原子引用。
- 快取不帶 snapshot → 不同 snapshot 重用錯誤統計 → 快取鍵納入版本與 snapshot。
- 只測規劃時間 → 掃描結果可能改變 → 比較候選集合與結果雜湊。
- 按修改時間直接刪檔 → 仍被 snapshot 或分支引用 → 按引用關係過期清理。
追問及應對
追問一：為什麼統計資訊可以被 reader 忽略？
Puffin 統計是 informational。表仍可依賴 manifest 與資料檔正確讀取，因此 reader 不支援或暫時無法讀取時應透明回退。
追問二：如何處理 snapshot 過期？
先確認沒有保留 snapshot、分支或標籤需要 blob 覆蓋的資料範圍，再按表格式引用關係清理，不能只看物件最後修改時間。
追問三：統計值域不完整怎麼辦？
把未知部分視為可能命中，擴大候選集合或完全回退。最佳化可容忍假陽性，不能產生假陰性。
追問四：並行寫入時何時生成統計？
以已提交 snapshot 為輸入，在中繼資料提交成功後生成或綁定；寫入期間的臨時檔不應被規劃器使用，提交時重新檢查相容性。
追問五：什麼時候不值得使用 Puffin？
查詢選擇性低、blob 大於節省的 manifest I/O、生成延遲過高或維護成本超過收益時，應關閉或縮小範圍。
追問六：如何證明最佳化沒有改變結果？
在同一 snapshot 執行開啟與關閉統計的等價查詢，比較完整結果、聚合、候選檔案集合與邊界樣本；再注入缺失、損壞與版本不相容 blob 驗證回退。