題幹與適用情境
你的團隊把表格資料放在物件儲存，計算引擎從 Spark 擴充到 Trino 與自研服務。原本的 Hive Metastore 用戶端需要多套實作，表格中繼資料提交也會在並行更新時互相覆寫。請設計 Apache Iceberg REST Catalog，說明它管理什麼、如何提交快照、如何驗證授權，以及故障時如何恢復。
Apache Iceberg REST Catalog 規範把目錄操作抽象成跨語言 HTTP API，並用以變更為基礎的提交協助伺服器處理衝突與重試。它管理命名空間、表格中繼資料與快照參照，資料檔案仍由底層物件儲存保存。題目的核心是中繼資料控制面，不是重新實作查詢引擎或物件儲存。
面試官考察點
強回答會先劃清資料平面與中繼資料控制面，再從用戶端相容性、提交並行、權限邊界與故障恢復推導元件。面試官會關注你是否解釋設定發現、載入表格、提交更新、樂觀並行、快照快取與憑證下發的關係。
普通回答往往只說「加一層 REST 服務」，卻沒有說明如何避免兩個 writer 覆寫彼此的快照，也沒有處理 catalog 回傳的資料存取憑證、跨引擎驗證與舊用戶端相容。
回答前需要釐清的問題
存取對象與一致性目標
先問表格規模、命名空間數量、讀寫比例、快照提交頻率，以及是否允許多表原子提交。若只有低頻批次處理，簡單的中繼資料資料庫已足夠；若多個引擎高並行提交，就需要明確衝突偵測、重試預算與提交延遲目標。
儲存與目錄邊界
確認物件儲存、檔案 IO、目錄資料庫與計算引擎分別由誰負責。REST Catalog 回傳表格中繼資料與設定，但不應把大量資料檔案代理穿過目錄服務；資料存取憑證可以按表格或位置短期下發，並限制權限與生命週期。
驗證與治理
確認用戶端使用 OAuth2、雲端簽章還是服務帳號，是否需要租戶隔離、稽核與按欄或按列的策略。目錄授權決定誰能發現、讀取或提交表格；底層物件儲存還要再次執行最小權限檢查，不能把 catalog 當成唯一安全邊界。
30 秒回答框架
「我會把 REST Catalog 當作無狀態中繼資料控制面：用戶端先呼叫設定端點發現能力，再透過命名空間與表格 API 載入中繼資料。目錄資料庫保存目前 metadata location、快照參照與提交版本，writer 以預期版本提交變更，伺服器偵測衝突並回傳可重試結果。驗證採用 OAuth2 或雲端簽章，目錄權限與物件儲存憑證分開控制。表格中繼資料可以短時間快取，但必須用版本或 ETag 驗證；目錄不可用時讀取只能使用已驗證的舊快照，寫入不能繞過提交協定直接修改根中繼資料。」
分步驟深入解答
第一步：定義控制面資料模型
目錄至少需要 namespace、table identifier、目前 metadata location、快照參照、版本號與稽核欄位。表格中繼資料檔案仍放在物件儲存，目錄記錄它的位址與提交版本。如此用戶端可按需載入快照，目錄不會成為大型檔案傳輸通道。
第二步：設計最小 API
設定端點回傳伺服器預設值、覆寫項與支援的 endpoint；命名空間 API 負責建立、列舉與屬性管理；表格 API 負責建立、載入、更新、提交、刪除與重新命名。載入回應可以帶表格設定與資料存取設定，用戶端再依約存取物件儲存。提交回應必須帶新版本，方便用戶端更新本地快取。
第三步：用樂觀並行保護提交
writer 先讀取目前版本並產生新的 metadata 檔案，再提交「我基於版本 V，要切換到位置 M」的變更。伺服器只有在目前版本仍為 V 時才原子更新目錄；若另一個 writer 已提交，回傳衝突，讓用戶端重新載入、合併自己的變更後再試。重試必須有限且加入抖動，避免多個引擎同時失敗後形成提交風暴。
第四步：處理快取與讀取一致性
用戶端可以快取表格設定與快照參照，但快取鍵要包含完整 table identifier 與伺服器身分。優先使用 ETag、版本號或快照參照驗證，而不是只依賴時間到期。讀取可以在明確的陳舊容忍度內使用已提交快照；涉及最新分支、權限變更或寫後讀的請求必須重新驗證目錄版本。
第五步：劃分驗證、授權與憑證下發
目錄 API 使用 OAuth2、雲端簽章或企業服務帳號進行身分驗證，授權策略按 namespace、table 與操作區分。若目錄回傳物件儲存的臨時憑證，憑證應只涵蓋必要位置與動作，並有短 TTL、稽核關聯與撤銷路徑。用戶端不能把目錄回傳的憑證當成永久金鑰寫入日誌或共用設定。
第六步：設計故障與恢復路徑
目錄資料庫故障時，已快取的唯讀快照可以繼續服務，但要標明可見時間；建立、提交、刪除等寫操作必須失敗並讓用戶端稍後重試，不能直接修改物件儲存的根 metadata。物件儲存暫時無法存取時，目錄提交可以保留未完成狀態，但不能把「目錄版本已更新、檔案不存在」當成成功。恢復流程應驗證 metadata location、快照參照與檔案清單，再開放寫入。
第七步：可觀測性與相容演進
記錄請求 ID、用戶端引擎、表格識別、預期版本、實際版本、衝突次數、重試次數與憑證範圍，但不要記錄 token 或金鑰。按 API、命名空間與引擎統計提交延遲、衝突率、快取命中率與陳舊讀取比例。協定新增 endpoint 或欄位時使用能力發現與向後相容的預設值，舊用戶端不認得的欄位不能改變既有提交語意。
高品質示範回答
我會先把 Iceberg REST Catalog 定義成中繼資料控制面。物件儲存保存 data files 與表格 metadata 檔案，catalog 資料庫只保存 table identifier、目前 metadata location、快照參照、版本與權限稽核資訊。如此 Spark、Trino 與其他語言用戶端只需要實作一套 HTTP 協定。
用戶端先讀取設定端點，再載入表格。writer 讀取版本 V、寫出新的 metadata，提交時帶預期版本 V。伺服器在交易中檢查目前版本；仍是 V 才切換到新 location，否則回傳衝突。用戶端重新載入並合併，再用指數退避與有限重試提交。這個規則比「最後寫入者獲勝」安全，因為後提交者可能靜默遺失另一方的 schema 或快照變更。
驗證可以是 OAuth2 或雲端簽章，目錄權限控制發現、讀取與提交；若回傳物件儲存憑證，我會限制到具體位置與短 TTL。表格中繼資料快取使用 ETag 或版本驗證，權限變更與寫後讀不接受未驗證的舊快取。目錄不可用時只允許帶明確陳舊標記的讀取，寫入一律失敗並重試；恢復後驗證 metadata location、快照參照與檔案存在性。最後用並行提交、重複重試、目錄故障、憑證過期、快取陳舊與舊用戶端請求做相容測試。
常見錯誤
- 錯誤表現： 讓 catalog 代理所有資料檔案。→ 失敗原因： 中繼資料控制面變成高頻寬瓶頸，權限與資料存取耦合。→ 修正方法： catalog 回傳中繼資料與受限存取設定，用戶端直接存取物件儲存。
- 錯誤表現： 並行提交採用最後寫入者獲勝。→ 失敗原因： 後提交者可能覆蓋另一個 writer 的 schema 或快照。→ 修正方法： 帶預期版本，以原子條件更新偵測衝突並有限重試。
- 錯誤表現： 只用固定 TTL 判斷快取新鮮度。→ 失敗原因： 寫後讀與權限變更可能在 TTL 內讀到錯誤視圖。→ 修正方法： 使用 ETag、版本或快照參照驗證，並按請求風險決定是否強制重新整理。
- 錯誤表現： 目錄故障時直接修改物件儲存的根 metadata。→ 失敗原因： 繞過提交協定，目錄索引與檔案狀態會分裂。→ 修正方法： 寫請求失敗並重試，恢復時做 location、快照與檔案清單驗證。
追問及應對
追問一：兩個 writer 都基於版本 V，如何合併 schema 變更？
伺服器先拒絕第二次提交，不替用戶端猜測合併結果。用戶端重新載入最新中繼資料，判斷自己的 schema 變更是否與新欄位、分割或屬性衝突；能安全合併才產生新的 metadata 並再次提交。不能自動合併的變更要回傳明確衝突，讓上層作出人工或作業級決策。
追問二：目錄快取與物件儲存出現不一致怎麼辦？
把目錄版本視為提交事實，把物件儲存中的 metadata location 視為可驗證副本。背景驗證器定期檢查 location 可讀、快照參照完整與檔案清單可達；發現目錄已指向不存在的 location 時凍結後續寫入，恢復到最近可驗證版本，並保留稽核記錄。不能靠增加快取 TTL 掩蓋一致性故障。
追問三：為什麼不直接讓每個引擎存取 Hive Metastore？
多套語言用戶端會重複實作驗證、提交衝突與新功能，演進成本會隨引擎數量增加。REST Catalog 提供共同協定與能力發現，伺服器可以集中處理提交去衝突、快取策略與憑證下發。若組織已有穩定 Hive 部署且只有單一引擎，維持原方案可能更簡單；遷移理由應是跨引擎相容與治理收益，而不是追逐名稱。
追問四：物件儲存憑證被用戶端記錄到日誌怎麼辦？
憑證必須短期、最小權限並與請求 ID 關聯，日誌過濾器在用戶端與目錄服務兩側都要遮蔽秘密。偵測到外洩時撤銷或縮短對應工作階段，檢查存取稽核並重新簽發。高敏感資料可以改用伺服器代理或遠端簽章，犧牲一些直連效能換取更窄的憑證暴露面。