Spark 持續流處理和微批處理的對比
Spark從2.3版本開始引入了持續流式處理模型，可將流處理延遲降低至毫秒級別，讓 Structured Streaming 達到了一個里程碑式的高度。
下面的架構圖中，既有微批處理，還有持續流處理，兩種模式對使用者是暴露的API是高度統一的：
今天我們著重看下兩者的設計思路和區別點
在持續模式下，流處理器持續不斷地從資料來源拉取和處理資料，而不是每隔一段時間讀取一個批次的資料，這樣就可以及時地處理剛到達的資料。如下圖所示，延遲被降低到毫秒級別，完全滿足了極低延遲的要求。
持續模式目前支援的 Dataset 操作包括 Projection、Selection 以及除 current_timestamp()、current_date()、聚合函式之外的 SQL 操作。它還支援將 Kafka 作為資料來源和資料池（Sink），也支援將控制檯和記憶體作為資料池。
開發者可以根據實際的延遲需求來選擇使用持續模式還是微批次模式，總之，Structured Streaming 為開發者提供了容錯和可靠性方面的保證。以及端到端的毫秒級延遲、至少一次處理保證等。
微批處理
Structured Streaming 預設使用微批模式，spark 引擎會定期檢查是否有新資料到達，然後開啟一個新的批次進行處理，如下圖：
在微批模式下， driver 在執行每個批次前，都需要先把 offset range 寫入 WAL， 為了掛掉後可以 recover，當一條日誌到達後，並不會立即處理，需要先處理完上一個批次，然後把這一個批次的 offset 記錄後，才會處理，如下圖：
這種模式下，最低的延遲可以搞到 100ms， 這種模式是架構在 Spark SQL 上的，所以就坐享 spark SQL 中已有的優化方式（code generation 和 project Tungsten，參考 https://databricks.com/blog/2016/05/23/apache-spark-as-a-compiler-joining-a-billion-rows-per-second-on-a-laptop.html），這種模式主要是面向吞吐量進行設計，而且可以滿足絕大部分應用場景，比如ETL和準實時監控，但是對於要求延遲在 10ms 的場景就力不從心了，所以2.3 版本中又引入了 持續流處理 模型。
持續流處理
在持續流模式下，spark不是定期排程新批次的任務，而是啟動一直執行的駐守在 executor 上的任務，源源不斷的進行讀取處理輸出資料，如下圖：
因為在 executor 端是持續流處理的，所以最低延遲可以降到 幾毫秒，spark 內部採用的分散式快照演算法類似 Chandy-Lamport 演算法，不過略有區別，在source 端隔一段時間注入特殊標記（epoch markers）到資料流，然後就相當於把資料切分為不同的 epochs， 當特殊標記流到 最後的 operator， executor 獲取後，向driver 彙報，driver等齊所有executor的彙報，統一發號施令，統一提交，有點類似於二次提交演算法，全部的 executor 都提交後，driver 再寫入提交日誌中，這個 epochs 就算是全部ok了，防止重複執行。
後續這個分散式演算法的設計和實現我會抽一篇文章來單獨介紹。
大家都在看
▼
關注 【spark技術分享】
一起擼spark原始碼，一起玩spark最佳實踐
