題干與適用場景
這道題考察資料工程師能否把跨團隊的資料約定變成可驗證、可演進的介面。假設支付團隊發布訂單事件，財務看板、風控特徵和營運報表都依賴它；欄位型別、業務含義、品質門檻和可用時間沒有統一約定，任何小改動都可能在下游變成事故。
適用對象包括資料工程師、資料平台工程師和負責資料產品治理的職位。題目重點是契約邊界、所有權、版本相容、驗證與故障處理，不要求綁定 Kafka、倉庫或某家廠商。回答應明確哪些保證由生產者負責、消費者可以假設什麼，以及無法保證時如何阻斷或降級。
面試官考察點
強回答會把資料契約與單純 schema 區分開：契約還應描述欄位語意、品質斷言、敏感資訊、服務水準、擁有者和變更規則。它會從消費者的業務需求反推最小契約，說明發布前檢查和執行期監控的邊界，並用相容性策略處理新增、棄用和語意變更。最後還要說明違規時誰收到通知、哪些下游被隔離，以及如何回滾或重播。
回答前需要澄清的問題
- 資料載體是事件流、資料表、檔案還是模型特徵？更新頻率和允許延遲是多少？
- 哪些消費者依賴它，分別需要哪些欄位、時間語意、精度和保留期？
- 「正確」如何定義：必填、唯一、範圍、列舉、跨欄位約束和業務對帳分別是什麼？
- 哪些欄位含有個人或財務資訊，存取、脫敏和用途限制由誰審批？
- 變更是向後相容、需要雙寫遷移，還是必須在門禁處拒絕？違規時允許延遲、隔離還是回滾？
30 秒回答框架
「我會先讓消費者寫出業務需求，再把契約拆成結構、語意、品質、時效、安全和責任六類。每份契約有明確 owner、版本、狀態和變更策略，生產者在發布前執行 schema 與品質檢查，消費者在接收端監控新鮮度和可用性。相容變更直接發布，破壞性變更走新版本、雙軌遷移和棄用窗口；檢查失敗時隔離壞資料、通知負責人並保留可重播的原始資料。最後用變更缺陷率、違規發現位置和恢復時間驗證契約是否有效。」
分步深入解答
第一步：從消費者用例劃定契約邊界
先列出消費者真正需要的欄位和決策，不要把生產表的全部欄位複製成契約。對每個欄位寫明業務含義、單位、時區、允許空值和來源；例如 totalamount 是分還是元，createdat 是事件發生時間還是寫入時間。將不屬於共享承諾的內部實作細節留在生產者內部。
第二步：定義結構、語意和品質斷言
結構描述欄位名稱、型別、必填性和巢狀關係；語意描述列舉、單位、時間窗口和計算口徑；品質斷言描述非空、唯一、範圍、分布或跨欄位關係。OpenMetadata 的契約模型把 schema、semantics、安全、業務斷言、SLA 和狀態分開，面試中可以用這種分層避免把「欄位存在」誤當成「資料可信」。
第三步：寫清時效、安全和責任
為資料集定義刷新頻率、最大延遲、保留期和可用窗口，並分別標出生產者 owner、備援聯絡人和消費者支援管道。對敏感欄位增加分類標籤、存取策略和用途限制。責任邊界要可執行：生產者保證發布內容符合契約，消費者可以依賴這些保證；消費者的業務推導仍需自己驗證。
第四步：選擇版本與相容策略
把契約版本和資料產品版本分開。新增可選欄位通常是相容變更；刪除欄位、改型別、改變列舉含義或改變時間口徑屬於高風險變更。對破壞性變更發布新版本，保留雙寫或轉換層，給消費者明確遷移期限，再按使用情況下線舊版本。不要只依賴 schema registry 的相容模式來掩蓋語意變化。
第五步：讓契約進入發布門禁
契約應存放在版本庫中，透過 pull request 評審。CI 先驗證契約格式，再用樣本或影子資料執行結構、品質和相容性測試；資料生產發布前必須通過門禁。Confluent 的資料契約還能表達完整性約束、元資料、遷移規則和敏感標籤，說明機器可執行規則比文件提醒更可靠。門禁失敗要阻止發布或把壞資料送入隔離區。
第六步：設計執行期保護和恢復路徑
發布後監控新鮮度、缺失率、列舉漂移、延遲、消費者錯誤率和契約狀態。違規資料保留原始載荷、版本和校驗結果，便於重播；看板或特徵服務可以暫時使用上一份可信快照，但結算、權限等不可逆動作應停止並告警。告警必須指向 owner 和升級路徑，而不是只顯示「資料異常」。
第七步：用一次變更演練驗證方案
舉例：訂單事件要把 amount 從整數分改成帶幣別的物件。先確認所有消費者，發布新版本並雙寫，執行回放和對帳，觀察新舊結果差異；遷移完成後再進入棄用窗口。若只是把 refunded 的含義從「已發起」改成「已完成」，即使型別不變也應視為破壞性語意變更。這個演練能證明契約覆蓋了語意而非只覆蓋欄位形狀。
第八步：用指標復盤契約是否有效
關注破壞性變更被發布門禁攔截的比例、問題首次被發現的位置、契約違規到恢復的時間、舊版本消費者數量和無 owner 資料集數量。若事故仍主要在下游看板才暴露，表示檢查太晚或斷言太弱；若契約包含大量無人使用的欄位，表示邊界需要收縮。契約隨業務和消費者變化版本化維護，不應一次寫完後無人負責。
設計取捨與邊界
契約越詳細，保護越強，但生產者和消費者的變更成本也越高。我會只把跨團隊、會影響業務決策或難以重播的假設寫進強制契約，把實驗性欄位放進可選擴充。品質門檻要按用途分層：結算資料可能要求嚴格完整，探索分析可以接受延遲並標註可信度。不要把所有治理要求塞進一份契約；存取審批、保留法規和資料產品文件可以透過引用關聯，避免重複維護。
何時拒絕發布
欄位含義不清、關鍵 owner 缺失、破壞性變更沒有遷移計畫，或品質斷言無法在任何邊界執行時，我會拒絕把版本標為 active。可以先以 draft 狀態協作，直到消費者確認假設、生產者提供樣本和重播證據。
如何處理不同消費者的衝突
先把衝突拆成共同保證和消費者特定需求。共享契約保留穩定、可驗證的最小集合；某個消費者需要更高精度或更短延遲時，透過獨立衍生資料產品或分層 SLA 實現，不強迫所有消費者承擔同一成本。每個例外都要有 owner、期限和退出條件。
落地計畫與證據
我會先選一個高影響、消費者數量有限的資料集做試點：登記消費者、寫出最小契約、在 CI 執行樣本驗證，再在生產入口加入新鮮度和品質監控。首個遷移完成後復盤被攔截的變更、誤報、恢復時間和消費者回饋，決定是否擴大到更多主題或資料表。這樣能用實際證據調整斷言，而不是先鋪設一套無人使用的治理平台。
試點的退出條件
試點應有明確退出條件：連續幾個發布週期通過門禁、違規能在下游污染前被發現、消費者完成版本遷移，並且 owner 能在約定時間內回應。達不到條件時縮小範圍或修正契約，不把失敗包裝成全平台成功。
怎樣證明收益不是巧合
比較試點前後的破壞性變更數量、首次發現位置、回滾次數和恢復時間，並按資料集和消費者分層。若只是事故變少但發布頻率也下降，需要結合變更吞吐和等待時間判斷；若檢查攔截很多但誤報高，應優先修正斷言與樣本，而不是關閉門禁。
常見誤區與追問
只寫欄位型別就叫資料契約
型別和必填性只能保護結構，無法說明幣別、時間語意、品質、時效、存取範圍和負責人。缺少這些資訊，下游仍可能得到「格式正確但含義錯誤」的資料。
把所有爭議都交給消費者兜底
消費者可以監控自己的使用結果，但不能替生產者承擔共享資料的定義和發布責任。契約需要明確生產者的保證、消費者的假設和雙方的升級路徑。
只在執行期告警，不設定發布門禁
等到壞資料進入共享層後再告警，往往已經污染多個下游。結構和相容性檢查應盡量左移；無法在發布前判斷的業務斷言，再由執行期監控和隔離補充。
破壞性變更：你如何判斷和遷移？
我會按消費者影響判斷，而不只看 schema diff。刪除欄位、改型別、列舉縮減、時間口徑或單位變化都可能破壞消費者。先發布新版本或轉換層，雙軌驗證並通知 owner，等舊版本使用量降到零且通過棄用窗口再刪除。
契約檢查失敗但業務必須繼續：怎麼辦？
先區分可逆展示和不可逆動作。展示鏈路可使用上一份可信快照並標註延遲；結算、權限、風控決策等鏈路應隔離壞資料、暫停相關動作並保留原始載荷。恢復後透過重播、對帳和消費者驗收再解除隔離。
如何避免契約變成沒人維護的文件？
讓契約進入程式碼評審、CI 門禁、目錄元資料和執行期狀態；每份契約綁定 owner、備援聯絡人、消費者清單和最後驗證時間。用違規率、發現位置和恢復時間復盤，淘汰沒有消費者或無法執行的條目。