題幹與適用場景
資料湖接收結構經常變化的 JSON 事件。團隊希望保留任意欄位，又希望常用欄位可以被欄式讀取與剪枝。請解釋 Parquet Variant 的 value 與 metadata 元件、Variant Shredding 的 typedvalue 與 fieldoffset，並設計相容、演進與驗證方案。
Parquet 官方規範把 Variant 表示為二進位 value 與 metadata 欄位；Variant Shredding 可以把部分同質欄位提取為獨立欄，再按偏移重建原始值。面試重點是格式不變量、讀取語義與工作負載驗證，不是把 JSON 原樣塞進一個字串欄。
面試官考察點
面試官會看你能否區分 Variant 的自描述中繼資料與實際值，能否說明 typedvalue、fieldid、field_offset 的對應關係；能否處理缺失欄位、型別混合、欄位順序與版本演進；能否解釋分解後如何支援欄位投影、謂詞下推、壓縮與回退；能否用等價性、效能與相容矩陣證明設計成立。
回答前需要釐清的問題
欄位與查詢
確認常用查詢欄位、欄位型別是否穩定、是否需要保留任意未知欄位，以及查詢引擎是否支援 Variant 與分解欄。
相容與治理
確認檔案需要被哪些舊讀取器讀取，是否存在 schema registry，欄位刪除與重新命名如何定義，壞資料是否允許進入原始 Variant 欄。
效能目標
確認掃描比例、物件儲存請求成本、寫入延遲、壓縮比、快取預算與重建 CPU 預算。不能只用單一 JSON 樣本推斷收益。
30 秒回答框架
「我會把 Variant 視為 value 與 metadata 兩個二進位元件，metadata 描述物件鍵或型別資訊；對穩定且高頻的子欄位做 Variant Shredding，寫成 typedvalue 與 fieldoffset 等欄，同時保留原始 Variant 以覆蓋未知欄位。讀取時按 field_id 和 offset 重建語義，缺失或型別不匹配走明確的 null/錯誤策略。上線前用新舊讀取器矩陣、隨機巢狀資料等價性、欄位裁剪與真實掃描成本驗證，失敗時回退到未分解欄。」
分步驟深入解答
第一步：定義 Variant 不變量
為每筆記錄保存 value 與 metadata。metadata 必須能解釋 value 中的型別、鍵與偏移；同一 field_id 的解釋在一個檔案內保持一致。為 null、缺失、陣列、物件與數字型別建立明確編碼。
第二步：選擇可分解欄位
只把型別分布穩定、查詢頻繁且具有收益的路徑拆出。稀疏或高度多態欄位繼續放在 Variant 中，避免產生大量低密度欄與額外寫放大。拆分規則應由版本化設定驅動。
第三步：設計 typed_value 與 offset
對適合欄式處理的欄位寫入 typedvalue；對巢狀結構保留 fieldid、field_offset 或等價定位資訊，使讀取器可以把分散欄重新組裝為 Variant。不能假設欄位順序等於物件語義。
第四步：處理模式演進
新增欄位先留在 Variant，再在觀測到穩定查詢後加入分解規則。型別改變時建立新 field_id 或新版本，禁止讓同一欄靜默改變物理型別。刪除欄位要保留讀取舊快照所需的 metadata 解釋。
第五步：規劃讀取與剪枝
查詢只需要已分解欄位時，讀取器可投影 typed_value 並使用統計資訊；需要未知路徑時讀取原始 value 與 metadata。謂詞下推必須證明不會因 null、缺失或多態值產生錯誤剪枝。
read(record, path):
if path has shredded column:
value = typed_value[row]
if value is present: return value
variant = decode(value[row], metadata[row])
return lookup_path(variant, path)第六步：建立一致性檢查
對每筆記錄執行重建後等價性檢查，比較型別、陣列順序、缺失與 null 語義。隨機抽樣檢查 field_offset 邊界、metadata 引用與跨 row group 讀取，發現不一致就阻斷發布。
第七步：驗證成本與回退
分別測量只查分解欄、查未知路徑與全量重建的讀取延遲、掃描位元組、物件儲存請求、壓縮比與 CPU。保留寫入原始 Variant 的開關；當讀取器不支援新編碼或收益低於門檻時，按檔案版本回退。
高品質示範回答
我會保留 Variant 的 value/metadata 作為完整事實來源，再把高頻、型別穩定的路徑做 shredding。typedvalue 存可欄式處理的值，fieldid 與 fieldoffset 讓讀取器能按規範重建巢狀語義；未知欄位仍從原始 Variant 查詢。演進透過版本化規則和新 fieldid 管理，避免物理欄靜默變型。發布前驗證新舊讀取器、缺失/null、多態陣列、謂詞剪枝與重建等價性，並以掃描位元組、請求數與 CPU 決定是否啟用。
常見錯誤
- 錯誤表現： 把 Variant 當作單一 JSON 字串欄。→ 失敗原因： 遺失自描述 metadata 與欄式分解機會。→ 修正方法： 明確 value、metadata、field_id 與 offset 的關係。
- 錯誤表現： 所有路徑都拆成欄。→ 失敗原因： 稀疏欄位造成欄位爆炸與寫放大。→ 修正方法： 按查詢頻率、型別穩定性與密度選擇路徑。
- 錯誤表現： 用欄位順序取代 field_id。→ 失敗原因： 物件順序變化不應改變語義。→ 修正方法： 使用規範定義的識別與偏移重建。
- 錯誤表現： 只比較查詢結果，不測舊讀取器。→ 失敗原因： 格式支援與回退風險可能在生產才暴露。→ 修正方法： 建立檔案版本、讀取器版本與能力矩陣。
追問及應對
什麼時候不應做 shredding？
當欄位極度稀疏、型別不斷變化、查詢很少或讀取器不支援時，保留 Variant 更簡單。應以掃描與重建成本的實測門檻決定。
如何避免謂詞下推誤剪枝？
只有在統計資訊涵蓋該欄位且能區分缺失、null 與型別不匹配時才下推；否則讀取候選列後再解釋 Variant。
如何測試重建等價性？
生成包含巢狀物件、陣列、重複鍵、null、缺失和多種數字型別的樣本，比較原始 Variant 與分解後重建結果的規範化表示，並覆蓋跨版本檔案。
舊讀取器不支援 Variant 時怎麼辦？
按檔案能力標記路由到相容寫入格式或旁路轉換服務；不要把不支援編碼的錯誤偽裝成空資料。逐步遷移完成後再清理回退路徑。