Spark兩套流處理方案，團隊該站哪邊？

凌晨兩點，某電商平臺的實時風控系統突然報警。工程師盯著屏幕上的延遲曲線——同樣的流量，兩套代碼，一個穩如老狗，一個開始丟數據。這不是故障演練，是Spark Streaming和Structured Streaming在真實業務里的正面交鋒。

老派方案：把流切成一塊一塊處理

Spark Streaming誕生于2014年，Spark 1.0版本。它的核心思路很直白：既然批處理成熟，那把實時流也切成小批不就行了？

這個模型叫DStream（離散化流）。系統每隔幾秒（通常2-10秒）切一刀，把這段時間的數據包成一個RDD（彈性分布式數據集），然后用批處理那套算子——map、filter、reduceByKey——挨個處理。

2014到2018年間，這套方案撐起了大量早期實時業務。日志監控、點擊流追蹤、簡單的實時大屏，DStream都能應付。團隊不用學新東西，會寫Spark批處理就會寫流處理。

但切批的代價很快暴露。DStream操作的是裸RDD，沒有Schema約束，沒有SQL支持。更頭疼的是事件時間處理——用戶3:05產生的行為，3:12才到服務器，這種亂序數據需要工程師自己寫補償邏輯?！窤pache Spark Services團隊在處理DStream的事件時間問題時，經常需要構建自定義的變通方案」，原文這樣描述當時的困境。

延遲數據、亂序數據、窗口聚合的準確性，這些在批處理里不存在的概念，在流場景下成了硬骨頭。DStream把問題拋給了開發者。

新方案：把流當成一張永遠增長的表

Spark 2.0帶來結構性轉變。Structured Streaming不再切批，而是把數據流看作「無界表」——新記錄不斷追加進來，查詢在表上持續運行。

關鍵設計在這里：用DataFrame/Dataset API寫查詢，同一套代碼，批和流無縫切換。SQL風格的聚合、Join、窗口函數，全部原生支持。開發者不需要在兩種心智模型之間來回切換。

事件時間處理被內置了。系統引入watermark（水?。C制：你設定一個容忍閾值，比如10分鐘，引擎會等待遲到數據直到超時，再輸出最終的窗口結果。電商平臺的訂單流可以配置為：按訂單時間戳等10分鐘，遲到的記錄照樣計入統計。

這個設計把「流處理的復雜性」從業務代碼下沉到了引擎層。工程師寫聲明式查詢，引擎操心一致性、容錯、狀態管理。

同一個人，兩種完全不同的工作方式

假設一個場景：實時統計各城市過去5分鐘的訂單總額。

用DStream的工程師要手動維護狀態，處理亂序，考慮容錯恢復。代碼里充斥著updateStateByKey的樣板邏輯，測試困難，調參靠猜。

用Structured Streaming的工程師寫一段SQL：GROUP BY window(eventTime, "5 minutes"), city。水印自動兜底遲到數據，Checkpoint自動保障Exactly-Once。代碼量可能只有前者的三分之一。

但這不是簡單的「新老替代」。DStream在某些場景仍有生存空間——超低延遲（亞秒級）、與遺留RDD生態深度綁定的系統、或者團隊確實沒有Schema化改造的動力。

Structured Streaming的代價是更高的抽象層帶來的黑盒感。當作業延遲飆升，你需要理解狀態存儲的RocksDB調優、輸出模式的語義差異、以及Checkpoint與WAL的交互機制。

選型背后的組織信號

技術選型從來不只是技術問題。觀察一個團隊的選擇，能讀出很多信息。

堅持DStream的團隊，往往有歷史包袱：2016年前后搭建的平臺，數百個作業，遷移成本被反復評估后擱置?；蛘邩I務場景極其簡單，切批的延遲可接受，沒有事件時間處理的剛需。

全面轉向Structured Streaming的團隊，通常經歷了痛徹的教訓——某次大促期間，DStream的手動狀態管理在流量峰值下出錯，導致財務統計偏差。或者團隊剛從批處理轉型，希望統一技術棧，降低認知負荷。

更微妙的是「混合態」：核心鏈路用Structured Streaming保障正確性，邊緣監控用DStream快速迭代。這種分層本身說明，兩種模型在工程實踐中有明確的邊界劃分。

一個被忽略的長期成本

Spark 3.x版本對Structured Streaming的投入持續加大。新的流式Join優化、增量執行模式、與Delta Lake的深度集成，這些特性都不會回溯到DStream。

這意味著選擇DStream不僅是選擇一種編程模型，更是選擇一條逐漸收窄的技術路線。社區維護的重心已經明確轉移，未來遇到深層次的Bug或性能瓶頸，修復周期會顯著拉長。

但「未來」是多遠的未來？對于生命周期只剩18個月的業務系統，這個考量權重為零。對于計劃服役五年的平臺基礎設施，這是決定性因素。

技術債務的殘酷之處在于，它不會在你做選擇時顯形，只會在某個凌晨的報警電話里突然攤牌。

你的團隊現在處于哪個階段？是還在維護2017年寫的DStream作業，還是已經在Structured Streaming上踩過生產環境的坑？如果今天從零開始設計一套實時風控系統，你會給團隊設定怎樣的技術約束？