完整刷新串流表會丟棄所有現有資料和元資料，並從頭開始串流。 具體來說，它會清空串流資料表，移除所有檢查點資料，然後為每個寫入資料表的串流流程新增檢查點並重新啟動。 以下章節將涵蓋何時進行全面刷新、其對資料來源的影響，以及最佳實務。
關於管線資料集中刷新的運作概述，請參見 「管線如何更新？」。 關於如何觸發完整刷新的指引，請參見 「執行管線更新」。
對資料來源的影響
完整刷新會從串流表中移除所有現有資料。 如果你的資料來源有保留限制（例如保留期短的 Kafka 主題），部分歷史資料在完全刷新後可能會無法恢復。
舉例來說，如果你的來源是 Kafka，且保留期為 24 小時，且在該時間段後執行完整刷新，舊訊息將不再可取得且無法重新處理。
備註
不建議在高流量串流工作負載或上行保留阻礙重播歷史資料時進行完整刷新。
如果串流資料表有相依的下游資料表，管線會失敗，除非這些資料表也完全刷新，除非串流資料表啟用了 skipChangeCommits 。 下游具體化視圖也必須完全刷新。
何時進行完整刷新
完整刷新必須明確觸發。 你可以在管道介面點擊 「完全刷新 」或在 Lakeflow Connect 啟用自動全更新來執行完整刷新。
當變更阻礙串流查詢從現有檢查點安全恢復，或先前處理的資料與更新的邏輯、結構或來源設定不符時，建議全面刷新。 以下章節描述常見情境。
結構變更
目標表中的以下結構變更不向下相容，需全面刷新：
- 未啟用欄位映射模式的情況下重新命名欄位。
- 更改重複去重欄位。
- 修改欄位資料型態，包括：
- 類型縮小（例如，
BIGINT → INT或DOUBLE → FLOAT）。 - 不相容的型別變更（例如，
STRING → INT）。
- 類型縮小（例如，
- 從資料表結構中硬性刪除欄位。
針對這類結構變更，Databricks 建議建立一個包含所需結構或名稱的新欄位，然後在串流表上方使用檢視來合併舊值與新值。
實體資料版面變更
以下實體資料配置變更需全面更新：
- 從舊有分區轉換到新的叢集方案。
上游原始碼變更
以下上游原始碼變更需全面更新：
- 修改串流查詢讀取的來源資料表。
- 切換來源類型（例如從 Kafka 轉 Delta，或自動載入器轉 Kafka）。
- 更改來源位置，例如表格路徑或 Kafka 主題訂閱。
- 即使架構維持不變，仍會刪除並重新建立來源 Delta 資料表。
有狀態處理變更
以下有狀態處理變更需要全面刷新：
- 修改聚合、分組鍵或聚合函數。
- 新增或移除聚合。
- 更改連接鍵或連接類型。
- 新增或移除連接。
- 修改去重欄位或去重邏輯。
資料連續性問題
當資料連續性受到損害時，可能需要全面刷新：
- 由於保存期限屆滿，CDC 日誌已無法取得。
- 串流檢查點目錄的損壞或刪除。
- 結構追蹤或結構位置檔案的損壞或遺失。
欲了解更多從檢查點故障中恢復管線的資訊，請參見 「從串流檢查點失效中恢復管線」。
局限性
以下限制適用於完整刷新。 請參閱 最佳實務 ，以協助在這些限制下工作。
- 除非你的來源保留完整的歷史資料集，否則完全刷新不會重新處理資料。
- 龐大的資料集會使完整刷新變得昂貴且耗時。
- 依賴該資料表的下游消費者可能會失敗或回傳不完整的結果，直到刷新完成。
最佳做法
| Situation | 最佳做法 |
|---|---|
| 設計以穩定為重 | 規劃你的架構，避免需要完全更新的變更。 新增欄位通常是安全的，而修改現有欄位或分割方案通常需要重新計算資料表。 |
| 從保留期短的來源串流 | 從沒有長保留期的來源（例如 Kafka 主題）串流，意味著完整刷新會遺失尚未在原始碼中的資料。 為避免遺失歷史資料，將原始資料串流到串流表（在 medallion 架構中稱為青銅表）。 使用彈性欄位類型（例如變體或字串），以避免上游資料變更時需要完整刷新此表格。 此資料表可儲存歷史資料，並供下游串流資料表使用（這些資料表可能有更嚴格的類型或其他結構變更）。 若下游資料表需要完整刷新，該資料表包含歷史資料，且本身不需完整刷新。 |
| 在進行全面刷新前，請考慮其他替代方案 | 替代方案包括：
|
| 當需要全面刷新時 | 當 需要 全面更新時，請遵循以下最佳實務：
|
若要在完全刷新後回填資料，可以建立append once流程。 此裝置能執行一次性回填，且不會在第一次回填後繼續運行。 程式碼會留在你的管線中，如果管線再次完全重置，backfill操作會重新執行。