題幹與適用場景
團隊已有上游變更流，想把結果維護到動態表中，並涵蓋軟刪除、流靜態連接或有狀態聚合。請說明如何判斷 CUSTOM_INCREMENTAL 是否合適、如何定義增量邏輯、驗證結果並準備回退。不要只複述 Snowflake 的發布說明。
面試官考察點
- 是否知道自訂增量刷新由開發者定義 MERGE 或 INSERT 邏輯，平台負責排程、重試與交易保證。
- 是否能區分增量刷新、全量刷新和流/Task 編排的邊界。
- 是否能處理主鍵、變更順序、重複事件、軟刪除和首次回填。
- 是否把刷新延遲、失敗重試、成本、可觀測性與回退方案說完整。
回答前需要釐清的問題
- 上游是 append-only、CDC 流還是會修正歷史記錄？刪除是否需要在目標表保留墓碑？
- 目標動態表的唯一鍵是什麼？重複事件、遲到事件和同一鍵多次更新如何排序？
- 邏輯是否能被增量化，還是必須定期全量重算？允許多長刷新延遲？
- 首次建立、失敗重試、模式變更和回退期間，誰負責核對結果與告警？
30 秒回答框架
我會先確認資料變化能否由穩定鍵和水位表達，再判斷自訂增量是否能安全維護目標。若選擇它，就明確每次刷新讀取的變更範圍、MERGE/INSERT 的冪等條件、軟刪除和遲到事件規則；同時用對帳查詢比較增量結果與抽樣全量結果。平台的排程、重試和交易保證不能取代業務語義。上線前要設定刷新延遲、失敗、回退到標準刷新或全量重建的指標與開關。
分步驟深入解答
1. 先判斷增量邊界
把目標定義拆成投影、過濾、連接、聚合和刪除語義。只有能明確受影響的輸入列與目標鍵時，增量邏輯才有可驗證邊界；無法定位影響範圍的全局排序或非確定性邏輯，應保留全量刷新方案。
2. 設計變更套用協議
為每筆變更定義業務鍵、版本或事件時間，並規定同鍵衝突的勝出規則。MERGE 的匹配條件必須冪等；軟刪除要記錄刪除標誌或墓碑，避免遲到的舊事件把已刪除列重新寫回。
3. 處理首次執行與異常
首次執行先用受控資料集比較自訂增量結果和全量基線，再擴大範圍。失敗重試必須能重複執行而不產生重複列；遇到模式變更、無法解釋的漂移或水位斷裂時暫停發布，回退到可驗證的全量刷新或重建。
4. 監控正確性與成本
監控刷新延遲、受影響列數、失敗次數、重試次數和上游水位；定期抽樣做增量與全量對帳。將倉儲計算、儲存、重建和下游查詢成本分開估算，避免只看單次刷新耗時。
高品質示範回答
我會先把 CUSTOM_INCREMENTAL 當作一個需要證明正確性的增量維護協議。先確認每筆變更有穩定業務鍵、版本或水位，並明確軟刪除、遲到事件和同鍵衝突規則；若無法定位受影響目標列，就保留全量刷新。接著設計冪等的 MERGE/INSERT 邏輯，用受控樣本與全量基線對帳，再驗證重複執行、失敗重試、首次回填和模式變更。動態表平台提供排程、重試和交易保證，但不替業務決定事件順序或刪除語義。上線後監控水位、刷新延遲、受影響列數、漂移和成本，並準備暫停、全量重建或回退到標準刷新模式的路徑。
常見錯誤
- 把
CUSTOM_INCREMENTAL當成任意 SQL 都能自動增量化。 - 只寫 MERGE 語句，卻沒有穩定鍵、版本和重複事件規則。
- 忽略軟刪除、遲到資料和首次全量回填。
- 把平台交易保證誤解為業務結果天然正確。
- 沒有增量與全量對帳、漂移告警或回退路徑。
- 只比較延遲，不估算持續刷新與重建成本。
追問及應對
什麼時候堅持全量刷新？
當變更影響範圍無法界定、邏輯包含全局排序或非確定性函數，或者增量結果無法透過對帳證明時，優先全量刷新。可先縮小資料範圍和頻率，再評估是否值得增量化。
如何處理同一鍵的遲到事件？
為事件攜帶單調版本或可比較的事件時間，並在 MERGE 條件中只接受更新版本。無法建立可靠順序時，應把衝突記錄到隔離表並告警，不能靜默覆蓋。
怎樣證明增量結果沒有漂移？
按分區或鍵範圍定期重算全量基線，比較列數、校驗和和關鍵業務指標；把差異樣本留存到稽核表，超過閾值就暫停發布或觸發重建。