這篇文章我想分享一個關於資料管線（Data Pipeline）演進的實戰案例。很多工程師在面對「資料更新太慢」的問題時，直覺反應就是要把系統改成「即時串流（Real-time Streaming）」。但實際上，很多時候我們需要的不是每筆紀錄的即時性，而僅僅是消除「排程等待」帶來的延遲。
以下我將以一個 Delta Index（增量索引）管線的遷移過程為例，解釋為什麼有時候「微批次串流」比「純串流」更適合實務需求。
背景：什麼是 Full Index 與 Delta Index
在搜尋或廣告系統中，為了讓使用者能搜尋到最新的內容，通常會採取兩種索引策略。第一種是 Full Index（全量索引），它會把所有資料從頭掃描一遍重新構建，雖然最準確，但耗時極長（例如需要 5 小時），無法頻繁執行。
為了填補這 5 小時的空白，我們會設計 Delta Index（增量索引），只處理最近變動的資料。理論上 Delta Index 應該很快，但如果它是透過傳統的批次排程（例如每 10 分鐘跑一次），就會遇到一個問題：如果資料在第 1 分鐘就到了，它必須等待到第 10 分鐘才被處理。這種由排程器（Orchestrator）引起的延遲，才是導致資料不新鮮的主因，而非運算速度不夠快。
誤區：為什麼不直接用 Record-level Streaming？
很多 Junior 工程師會建議直接用 Kafka 這種 record-level streaming（紀錄級串流），每來一筆資料就處理一筆。但在這個案例中，這樣做反而會增加風險。
原因在於業務邏輯。索引系統通常需要對資料進行分組（Grouping）或聚合。如果每筆紀錄獨立處理，可能會導致索引狀態不一致（例如廣告 A 更新了，但它所屬的產品分組索引還沒更新）。要解決這個問題，得大改整個架構，成本極高且收益低。事實上，業務端不需要「毫秒級」的更新，他們只需要「不要在排程上浪費時間」。
解決方案：微批次串流（Micro-batch Streaming）
最終團隊選擇了 Spark Structured Streaming 的微批次模式，將觸發間隔（Trigger Interval）設為 30 秒。這不是為了追求即時處理，而是為了實現「持續可用性」。
其核心邏輯如下： 系統每 30 秒檢查一次物件儲存（如 S3）中的分區（Partition）。 比對目前最新的分區與上次處理到的水位線（Watermark，即紀錄處理進度的標記）。 如果發現有新分區，就直接處理「最新」的那一個，而跳過中間過時的分區。
這裡提到一個關鍵設計：優先考慮新鮮度（Freshness-driven）。在傳統串流中，我們必須按順序處理所有資料以確保完整性。但在這個增量索引場景中，因為處理視窗（Window）是有重疊的，跳過中間狀態直接處理最新狀態，不僅不會遺失資料，還能大幅降低延遲。
實務陷阱：不要依賴物件儲存的完成標記
在批次處理時，我們習慣用 Success File（成功標記檔案）來判斷一個資料夾是否寫入完成。但在連續運行的串流環境中，這非常危險。
物件儲存（如 S3）具有最終一致性（Eventual Consistency），這意味著你可能看到了成功標記，但資料檔案還沒全部出現在清單中；或者資料到了，標記卻還沒出現。這會導致串流程式在輪詢時產生競爭條件（Race Condition），造成重複處理或漏處理。
正確的做法是改用「時間驅動的確定性進度」。不再等待特定的標記檔案，而是根據分區路徑的時間戳記，由系統決定現在應該處理到哪個時間點。
運維挑戰：將「重啟」視為常態
長時間運行的 JVM 程式（如 Spark）會面臨記憶體壓力（Memory Pressure）和垃圾回收（GC）導致的停頓。與其花大量時間去調優記憶體，最務實的做法是：設計「計畫性重啟（Planned Restarts）」。
團隊將 Job 設定為每 24 小時自動重啟一次。這樣可以強制釋放記憶體、重設內部狀態，並讓新程式碼能自然部署。配合一個外部的監控守護進程（Watchdog），將故障恢復變成一種常態化機制，而非緊急事故。
最終成效與總結
透過這次遷移，端到端延遲從 10 分鐘降低到了 30 秒，且運維壓力反而減輕。
給工程師的啟示： 第一，區分「處理延遲」與「排程延遲」。如果瓶頸在後者，微批次化比全面串流化更高效。 第二，不要盲目追求理論上的「正確設計」（如每筆紀錄處理），要根據業務對一致性與新鮮度的容忍度來選擇方案。 第三，在分散式系統中，簡單且確定性的進度管理（如時間戳比對）遠比複雜的信號機制（如成功標記檔）可靠。
來源：infoq.com - From Batch to Micro-Batch Streaming: Lessons Learned the Hard Way in a Delta Index Pipeline
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。