參考這篇文章：

https://www.sohu.com/a/196257023_470008

我們當時的目標就是要設計一款低延遲、exactly once、流和批統一的，能夠支撐足夠大體量的復雜計算的引擎。

Spark streaming 的本質還是一款基於 microbatch 計算的引擎。這種引擎一個天生的缺點就是每個 microbatch 的調度開銷比較大，當我們要求越低的延遲時，額外的開銷就越大。這就導致了 spark streaming 實際上不是特別適合於做秒級甚至亞秒級的計算。

Kafka streaming 是從一個日誌系統做起來的，它的設計目標是足夠輕量，足夠簡潔易用。這一點很難滿足我們對大體量的復雜計算的需求。

Storm 是一個沒有批處理能力的數據流處理器，除此之外 Storm 只提供了非常底層的 API，用戶需要自己實現很多復雜的邏輯。另外，Storm 在當時不支持 exactly once。種種原因，Storm 也無法滿足我們的需求。

最後，我們發現了 Flink，並且驚喜地發現它幾乎完美滿足了我們所有的需求：

a) 不同於 Spark，Flink 是一個真正意義上的流計算引擎，和 Storm 類似，Flink 是通過流水線數據傳輸實現低延遲的流處理；

b) Flink 使用了經典的 Chandy-Lamport 算法，能夠在滿足低延遲和低 failover 開銷的基礎之上，完美地解決 exactly once 的目標；

c）如果要用一套引擎來統一流處理和批處理，那就必須以流處理引擎為基礎。Flink 還提供了 SQL／tableAPI 這兩個 API，為批和流在 query 層的統一又鋪平了道路。因此 Flink 是最合適的批和流統一的引擎；

d) 最後，Flink 在設計之初就非常在意性能相關的任務狀態 state 和流控等關鍵技術的設計，這些都使得用 Flink 執行復雜的大規模任務時性能更勝一籌。

flink和spark stream等框架的對比