flink和spark stream等框架的對比

我們當時的目標就是要設計一款低延遲、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 執行複雜的大規模任務時效能更勝一籌。