流處理和批處理框架

爲何有這種框架？

• 爲了在更短的時間內處理更多的數據。
• 統一處理分佈式系統中的容錯問題。
• 將任務簡化抽象以應對多變的業務要求。
• 分別適用於有界數據集（批處理）和無界數據集（流處理）。

批處理與流處理的發展史簡介

1. Hadoop 與 MapReduce。谷歌讓批處理在一個分佈式系統中像 MapRduceresult = pairs.map((pair) => (morePairs)).reduce(somePairs => lessPairs)同樣簡單。
2. Apache Storm 與有向圖拓撲結構。MapReduce 不能很好地表示迭代算法。所以，內森·馬茲（Nathan Marz）將流處理抽象成一個由 spouts 和 bolts 組件構成的圖結構。
3. Spark 內存計算。辛湜（Reynold Xin）指出 Spark 在處理相同數據的時候比 Hadoop 少使用十倍機器的同時速度卻快三倍
4. 基於 Millwheel 和 FlumeJava 的谷歌數據流（Google Dataflow）。谷歌使用窗口化API同時支持批處理與流處理。

等等...那麼爲何 Flink 變得如此熱門？

1. Flink 快速採納了 Google Dataflow以及Apache Beam 的編程模式。
2. Flink 對 Chandy-Lamport checkpointing 算法的高效實現。

這些框架

架構選擇

若要用商業機器來知足以上的需求，有這些熱門的分佈式系統架構……

• master-slave（中心化的）：Apache Storm + zookeeper， Apache Samza + YARN
• P2P（去中心化的）：Apache s4

功能

1. DAG Topology 用來迭代處理 -例如Spark 中的 GraphX， Apache Storm 中的 topologies， Flink 中的 DataStream API。
2. 交付保證 (Delivery Guarantees)。如何確保節點與節點之間數據交付的可靠性？至少一次 / 至多一次 / 一次。
3. 容錯性。使用cold/warm/hot standby, checkpointing 或者 active-active 來實現容錯。
4. 無界數據集的窗口化API。例如 Apache 的流式窗口。Spark 的Window函數。Apache Beam 的窗口化。

不一樣架構的區別對照表

架構	Storm	Storm-trident	Spark	Flink
模型	原生	微批量	微批量	原生
Guarentees	至少一次	一次	一次	一次
容錯性	記錄Ack	記錄Ack	檢查點	檢查點
最大容錯	高	中	中	低
延遲	很是低	高	高	低
吞吐量	低	中	高	高

本文首發於硅谷io