資料工程面試：如何用 Avro Parsing Canonical Form 管理 schema 指紋？
題幹與適用場景
事件平台的 Avro writer 與 reader 由不同團隊維護。有人只改了 JSON 空白或 doc，有人新增了帶預設值的欄位；註冊表需要穩定識別「讀取意義相同」的 schema，同時拒絕真正不相容的變更。請設計規範化、指紋、相容閘門和快取協商。
題目考察 Apache Avro 規範能力，不把指紋當作安全簽章，也不假設所有語言函式庫的註冊表 API 相同。
面試官考察點
- 能否區分 Parsing Canonical Form、schema resolution 與業務版本號。
- 能否準確說明哪些屬性會被移除、排序或轉義規範化。
- 能否按碰撞機率選擇 64 位、128 位或 SHA-256 指紋，並保留完整 schema。
- 能否設計發佈閘門、快取命中、協商失敗和回滾觀測。
回答前需要澄清的問題
- 指紋用於本地快取鍵、跨服務協議協商，還是稽核與供應鏈身分？
- 註冊表是否保存 writer schema，消費者是否能按指紋取得它？
- 相容策略要求向後、向前，還是雙向相容？
- 指紋碰撞時是否允許退回完整 canonical bytes 比較？
- 現有客戶端使用哪一版 Avro 規範，是否有自訂 canonicalizer？
30 秒回答框架
「我先把合法 schema 轉成 Avro Parsing Canonical Form，再對 canonical bytes 計算指紋；規範會移除 doc 等非解析屬性、固定物件鍵順序並消除 JSON 空白。指紋只做快取和協商索引，完整 schema 仍存註冊表，相容性由 writer/reader resolution 規則閘門控制。預設用 64 位 Rabin 處理小規模快取，規模或風險更高時用 128 位或 SHA-256，並在命中後比較 canonical bytes 防禦碰撞。發佈和執行期都記錄規範版本、指紋、解析結果與退回原因。」
分步驟深入解答
1. 產生規範化位元組
輸入必須是有效 UTF-8 的 Avro JSON schema。按規範先把 primitive 變成簡單形式，補齊 fullname 並移除多餘 namespace；只保留 type、name、fields、symbols、items、values、size 等解析屬性。物件鍵按固定順序排列，字串轉義還原，整數去引號與前導零，最後移除字串外空白。
2. 處理「相同」與相容
canonical 文字相等表示對 reader 而言不可區分，不等於兩個版本都能互讀。相容閘門仍執行 schema resolution：記錄欄位按名稱匹配，writer 多出的欄位可被忽略，reader 新增欄位必須有預設值；整數到更寬型別的提升也要按規範檢查。
3. 選擇指紋長度
64 位 Rabin 指紋適合百萬級 schema 快取，128 位摘要適合更大規模，SHA-256 適合需要更長識別子的場景。Avro 規範強調這些指紋不提供安全保證，因此不能取代簽章、授權或防竄改校驗。註冊表以完整 canonical bytes 和 schema 內容作為權威值。
valid schema -> canonical bytes -> fingerprint
| |
registry value cache / handshake key4. 設計發佈閘門
提交時計算 canonical bytes 與指紋，先檢查是否只是 doc、namespace 冗餘或空白變化，再用 writer/reader resolution 對照生產消費者集合。閘門輸出「canonical 相同」「相容但 canonical 不同」或「不相容」，不能只比較原始 JSON 文字。把指紋、完整 schema、規範化實作版本和相容報告綁定保存。
5. 執行期協商與碰撞退回
消費者先送出指紋，服務端命中後返回 schema 或確認快取；未命中時按 registry 查詢完整 schema。若不同 canonical bytes 產生相同短指紋，服務端必須比較完整 bytes 並返回衝突，不得靜默重用快取。快取鍵可使用指紋加 canonical 長度或內容摘要，減少錯誤命中。
6. 觀測、升級與復原
記錄 producer、consumer、指紋、canonicalizer 版本、resolution 結論、registry 延遲、未命中、衝突和退回次數；禁止把事件資料寫入日誌。升級 canonicalizer 時離線重算舊 schema，雙讀舊鍵與新鍵，確認命中率和相容報告穩定後再切換。回滾保留完整 schema 與舊指紋映射。
高品質示範回答
「我把 Avro schema 當作結構化輸入，按規範生成 canonical bytes：移除 doc 等不影響解析的屬性，補全 fullname，固定鍵順序，規範字串、整數和空白。canonical 相同只說明 reader 無法區分，發佈仍要執行 writer/reader resolution，特別檢查新增欄位預設值、欄位按名稱匹配和型別提升。指紋用於快取和協議協商，不承擔安全性；小規模用 64 位 Rabin，大規模可用 128 位或 SHA-256，命中後保留完整 bytes 比較以處理碰撞。註冊表保存完整 schema，觀測指紋、canonicalizer 版本、相容結論、未命中和衝突，升級時雙讀並可回滾。」
常見錯誤
- 直接對原始 JSON 做 hash → 空白或鍵順序變化造成偽版本 → 先生成 canonical bytes。
- 把 canonical 相同當作所有版本互讀 → 忽略 reader 預設值和型別提升 → 仍執行 schema resolution。
- 把 64 位指紋當簽章 → 無法抵抗偽造和竄改 → 另用簽章與存取控制。
- 只存短指紋不存 schema → 未命中或衝突時無法復原 → 註冊表保留完整 canonical bytes。
- 升級規範化器直接切換 → 新舊快取鍵分裂 → 雙讀、觀測後再切換。
追問及應對
doc 改了為何 canonical 可能不變？
doc 不參與解析，規範會剝離它；因此 canonical 相同。但產品文件版本、稽核或生成程式碼仍可能需要另行保存原始 schema 與變更說明。
指紋碰撞如何證明沒有誤讀？
把短指紋僅當索引，命中後比較完整 canonical bytes；若不等則返回衝突並走完整 schema 查詢，告警並阻止自動解碼。
為什麼不只用業務版本號？
業務版本號表達發佈意圖，不能識別跨團隊重複 schema 或 JSON 表示差異。指紋與完整 schema、resolution 報告組合，才能支援去重、協商和稽核。