資料工程面試：如何把遺留日誌遷移到 OpenTelemetry Logs Data Model？
題干與適用場景
公司同時產生應用文字日誌、容器標準輸出和舊 JSON 事件，欄位名稱、時間精度和嚴重性寫法各不相同。團隊希望遷移到 OpenTelemetry Logs Data Model，保留歷史可搜尋性，並讓 TraceId 關聯不誤導排障。請設計離線回填與即時雙寫方案。
OpenTelemetry 分開定義 Timestamp、ObservedTimestamp、TraceId、SpanId、SeverityNumber、Body、Resource 與 Attributes。遷移核心是可追溯的資料契約，不是把整行字串塞進 Body。高品質回答還要處理解析失敗、時區、重複、敏感欄位與回放水位。
面試官考察點
- 能否區分事件發生時間、觀測時間、資源屬性和事件屬性。
- 是否設計 schema 映射、版本、未知欄位保留與解析失敗路徑。
- 是否保持 TraceId、SpanId 和請求識別的真實性與可選性。
- 是否處理租戶隔離、脫敏、重複、亂序與歷史回填成本。
- 是否給出可重播、可對帳和品質門檻，而非只描述 ETL 工具。
回答前需要澄清的問題
- 舊日誌的時間是本地時間、UTC 還是混合格式？精度能到毫秒還是奈秒？
- 哪些來源有穩定 schema，哪些來源需要正則或樣本驅動解析？
- TraceId、SpanId、請求 ID 是由應用程式產生還是由採集器猜測？
- 是否需要保留原始載荷，保留多久，誰可以讀取？
- 歷史回填與即時雙寫是否共用目標儲存與索引，允許多大查詢差異？
30 秒回答框架
我會先建立版本化映射表，並保留原始載荷和解析狀態。Timestamp 表示事件發生，ObservedTimestamp 表示被觀察到的時間；Resource 放服務、主機和租戶等穩定來源，Attributes 放事件實例欄位，Body 保留結構化業務內容。TraceId 和 SpanId 只在有可信上下文時填入。遷移採用離線回填加即時雙寫，按來源和時間分區對帳，失敗記錄進入可重播死信。品質門檻包括解析成功率、欄位完整性、時間偏差、重複率、脫敏命中率和查詢等價性。
分步驟深入解答
1. 先固定資料契約
為每種來源定義 parser 版本、必填欄位、預設值與未知欄位策略。原始行產生穩定事件 ID，記錄來源、檔案偏移或訊息位點。未知欄位可暫存於 Attributes 或原始載荷，但不能悄悄丟棄；欄位語意變化必須升級映射版本。
{
"timestamp": "2026-08-02T02:00:00.123Z",
"observedTimestamp": "2026-08-02T02:00:00.800Z",
"severityNumber": 17,
"severityText": "ERROR",
"body": {"message": "payment declined", "code": "CARD_DECLINED"},
"resource": {"service.name": "checkout", "tenant.id": "t-7"},
"attributes": {"region": "us-east-1"}
}2. 處理時間語意
把帶時區的時間解析為統一時區，並保留原始字串與解析狀態。Timestamp 是事件發生時間；ObservedTimestamp 是採集器觀察到它的時間。缺少事件時間時可以使用觀察時間作為降級值，但必須標記，避免把採集延遲誤當業務延遲。對未來時間、過舊時間與精度截斷設定驗證規則。
3. 映射 Resource、Attributes 與 Body
Resource 描述產生日誌的實體，例如服務名、版本、主機、叢集與租戶；Attributes 描述單筆事件的區域、請求類型或實驗分組；Body 保存結構化訊息或未拆解內容。欄位放錯位置會影響聚合、索引與成本，因此映射表要記錄理由與下游使用者。
4. 處理嚴重性與上下文
把舊系統的 WARN、ERR、數字等級映射到 SeverityNumber，並保留原始 SeverityText。TraceId、SpanId 和 TraceFlags 只接受符合格式且來自可信注入點的值；缺失時保留空值與缺失原因，不能隨機產生鏈路 ID。請求 ID 可以作為普通 Attribute，但不要把它冒充 TraceId。
5. 設計雙寫與回填
即時路徑在採集器中同時寫舊儲存和新目標，使用同一事件 ID；離線回填按檔案、分區或訊息位點切片，記錄 checkpoint。兩條路徑共用 parser 與脫敏規則，但允許不同批大小。回填完成後按來源、時間視窗和事件 ID 對帳，再逐步把查詢流量切到新模型。
6. 失敗、重複與亂序
解析失敗寫入包含原始資料、錯誤碼和 parser 版本的死信，可在修復後按 checkpoint 重播。重複由事件 ID、來源位點和內容雜湊組合去重；亂序不應修改事件時間，查詢索引按事件時間與觀察時間分別支援。無法去重時寧可標記不確定，也不要靜默覆蓋。
7. 隔離、脫敏與成本
租戶 ID 應來自可信資源屬性，不能接受客戶端任意覆蓋。密鑰、令牌和個人資料在落盤前按欄位規則脫敏，同時保留脫敏版本與命中計數。原始載荷單獨加密、限權並設定較短保留期；高基數 Attributes 需要索引預算，避免統一模型造成成本爆炸。
8. 品質驗收與回滾
抽樣對比舊查詢與新查詢的事件數、嚴重性分布、時間差和關鍵欄位。設定解析成功率、必填欄位完整率、重複率、時間偏差、脫敏漏報與查詢等價性門檻。灰度期間保留舊寫入，發現欄位錯位或租戶洩露時按 checkpoint 停止新寫入並回滾查詢路由，不刪除可重播原始資料。
高品質示範回答
我會把遷移拆成契約、解析、雙寫、回填、對帳和切流六層。每個來源有版本化 parser 與穩定事件 ID；Timestamp 表示事件發生，ObservedTimestamp 表示採集時間。Resource 放服務、主機和租戶等穩定屬性，Attributes 放事件欄位，Body 保留結構化業務內容；SeverityNumber 從舊等級映射，TraceId 只接受可信上下文。
即時階段舊、新儲存雙寫，離線階段按位點回填，失敗進入帶原始資料和錯誤碼的死信。用事件 ID 與位點對帳，分別監控亂序與重複。落盤前脫敏，原始載荷單獨加密限權。灰度比較事件數、欄位完整性、時間偏差和查詢結果；門檻不達標就停寫新模型並切回舊查詢。
常見錯誤
- 把所有內容放進 Body → 下游無法按資源和屬性聚合 → 按資料模型分層映射並保留未知欄位。
- 用採集時間覆蓋事件時間 → 無法分析業務延遲 → 同時保留 Timestamp 與 ObservedTimestamp。
- 為缺失上下文隨機產生 TraceId → 產生虛假鏈路 → 保留空值並記錄缺失原因。
- 只做即時雙寫不做回填對帳 → 歷史和即時結果無法證明一致 → 用位點、事件 ID 和時間視窗對帳。
- 解析失敗直接丟棄 → 無法修復 parser 後補償 → 寫入可重播死信。
- 先落盤再脫敏 → 原始資料擴大洩露面 → 在受控入口執行欄位級脫敏並隔離原文。
追問及應對
沒有事件時間怎麼辦？
使用 ObservedTimestamp 作為明確降級值，同時設定缺失標記；不要把它偽裝成業務發生時間，並在品質報表中單獨統計。
如何驗證 TraceId 沒有被偽造？
只信任應用 SDK 或受控代理注入的上下文，驗證格式與關聯範圍；客戶端日誌中的同名欄位只能作為普通 Attribute。
雙寫產生重複如何處理？
產生穩定事件 ID，結合來源位點和內容雜湊做冪等寫入；如果無法確定是否同一事件，保留重複標記並讓查詢層解釋。
遷移期間欄位語意變化怎麼辦？
升級 parser 和 schema 版本，保留舊欄位映射與版本資訊，允許新舊欄位並存一段時間，並對下游查詢做相容測試。
原始載荷為什麼不能全部刪除？
它支援解析修復、爭議核驗和重播，但應單獨加密、限權、稽核存取並縮短保留期，不能與標準化索引混存。