題幹與適用場景
面試官可能問：「你如何演進 OpenLineage 事件 Schema，同時保證下游消費者不被破壞？」題目適用於資料平台、資料基礎設施和血緣系統職位。它考察你能否把 JSON Schema、Facet 擴充、用戶端程式碼生成、事件版本和消費方相容性組成可發布流程。
面試官在考察什麼
重點不是記住某個欄位名稱，而是判斷變更邊界。OpenLineage 文件說明 Schema 以 JSON Schema 為基礎，修改現有檔案時必須提升該檔案版本；Java 和 Python 用戶端會據此生成程式碼。面試官還會看你是否區分 RunEvent、JobEvent、DatasetEvent，以及是否知道自訂 Facet 需要唯一前綴和不可變的版本化 schema URL。
先釐清這幾個問題
先確認要改的是核心物件、現有 Facet，還是新增自訂 Facet；事件由哪些生產者發出，哪些消費者解析；是否存在舊用戶端、回放任務或跨語言 SDK；相容性目標是只讀舊事件、雙寫新舊版本，還是允許一次切換。還要問清欄位是必填、可選還是語義改變，以及失敗事件如何處理。
30 秒回答框架
用五步回答：
- 盤點生產者、消費者、事件類型和目前 Schema 版本。
- 優先新增可選欄位或新 Facet，避免改變既有欄位語義。
- 提升版本、更新範例和生成用戶端，並做相容性矩陣。
- 先在回放和影子流量驗證，再灰度生產者，監控解析失敗和欄位缺失。
- 設定棄用窗口、回滾方式和消費者遷移完成條件。
逐步拆解深度解法
1. 畫出事件與依賴邊界
OpenLineage 的物件模型包含 Job、Run 和 Dataset；RunEvent 表示執行狀態，JobEvent 和 DatasetEvent 表示設計時元資料。先確認變更影響哪類事件、哪個 Facet 和哪些用戶端。把 Schema 儲存庫、生成程式碼、訊息匯流排、索引和查詢 API 列成依賴圖，避免只改生產者。
2. 選擇相容的演進方式
新增可選欄位通常比刪除、改型別或重新解釋欄位安全。若語義確實改變，新增欄位或新 Facet，並在一段時間內雙寫。自訂 Facet 使用專案專屬前綴，避免與標準 Facet 衝突；同一實體同名 Facet 會替換舊實例，因此名稱和版本必須穩定。
3. 版本與程式碼生成一起變更
OpenLineage 要求修改現有 JSON Schema 時提升檔案版本，版本 URL 應指向不可變版本。提交 Schema 後生成 Java 和 Python 用戶端，執行各自測試，並檢查生成程式碼是否被所有生產者和消費者鎖定到預期版本。不要只更新文件或手工複製型別。
4. 明確相容性矩陣
至少測試新生產者配舊消費者、舊生產者配新消費者、新舊雙方配同一回放資料。對每個欄位記錄是否允許缺失、未知欄位是否忽略、列舉新增是否安全、型別轉換是否可逆。若舊消費者無法忽略未知欄位，就不能直接擴大生產流量。
5. 用範例、回放和影子流量驗證
為每個 Facet 保存最小、完整和異常範例。把歷史事件回放到新解析器，比較結構化結果和查詢索引；再讓新生產者複製事件到影子主題，不影響線上血緣圖。監控解析失敗率、未知 Facet、版本分布和端到端延遲，任何異常先停止灰度。
6. 設計棄用與回滾
公布舊版本停止接收時間、遷移負責人和消費者清單。生產者可以先雙寫，消費者完成升級後再停止舊欄位。回滾時保留舊 Schema、舊用戶端和訊息重播能力；不要刪除已寫入的舊版本事件，否則回滾只會恢復程式碼而無法恢復資料解釋。
高品質示範回答
以下回答為虛構示例，候選人應替換事件類型與組織約束：
我會先盤點 RunEvent、JobEvent 和 DatasetEvent 的生產者、消費者、用戶端版本與回放任務，確認要改的是核心 Schema 還是自訂 Facet。預設採用向後相容的新增可選欄位；如果語義變化，就新增欄位或新 Facet，並使用專案專屬前綴。修改現有 JSON Schema 時提升版本，生成 Java 和 Python 用戶端，更新最小、完整和異常範例。驗證階段涵蓋新生產者配舊消費者、舊生產者配新消費者和歷史事件回放，再透過影子流量灰度生產者，監控解析失敗、未知 Facet、版本分布和延遲。穩定後保留雙寫和舊消費者一段棄用窗口，滿足遷移完成條件後再停止舊版本。整個流程保留舊 Schema、用戶端和訊息重播能力，確保回滾不會遺失事件解釋。
常見失分點
只說「加欄位就相容」
欄位是否可選、消費者是否拒絕未知欄位、生成用戶端是否更新，都會改變結論。必須給出相容性矩陣和測試範例。
修改 Schema 卻不提升版本
版本 URL 是消費者識別語義的依據。漏升版本可能導致程式碼生成失敗或不同消費者誤以為仍是舊定義。
把自訂 Facet 當作任意 JSON
自訂 Facet 需要唯一前綴和不可變版本化 Schema URL。同名 Facet 會替換實體上的舊實例，命名衝突會造成靜默覆蓋。
只測新事件，不測歷史回放
血緣系統常要重播歷史事件。沒有回放測試，就無法發現舊欄位缺失、版本混用和索引遷移問題。
追問與進階練習
舊消費者遇到未知 Facet 會失敗，你如何發布？
先讓消費者支援忽略未知 Facet，或把新 Facet 放到影子流量；在確認解析器和指標安全後，再灰度新生產者。不能假設所有 JSON 消費者都寬容。
你會何時選擇新 Facet，何時新增核心欄位？
如果資訊是可獨立演進的上下文，選擇 Facet；如果它改變 Job、Run 或 Dataset 的核心身分和生命週期，才考慮核心 Schema 變更。說明查詢和所有權邊界比欄位數量更重要。
生成用戶端在 Java 通過、Python 失敗，你會怎麼辦？
暫停發布，比較兩種生成器對可選欄位、列舉和未知屬性的處理，修正 Schema 或生成範本，並分別執行用戶端測試。版本升級不能以單一語言通過為完成條件。
遷移窗口結束後仍有舊生產者，你如何處理？
按生產者和團隊列出剩餘來源，限制舊版本寫入並提供明確錯誤或降級；若強制停止會遺失關鍵血緣，則延長窗口並記錄風險，不刪除舊事件或舊 Schema。