Spark Stream、Kafka Stream、Storm和Flink對比，以及阿里巴巴基於Flink打造的Blink解決的問題

1、Spark Stream、Kafka Stream、Storm等存在的問題

在設計一個低延遲、exactly once、流和批統一的，可以支撐足夠大致量的複雜計算的引擎時，Spark Stream等的劣勢就顯現出來。Spark Streaming的本質仍是一個基於microbatch計算的引擎。這種引擎一個天生的缺點就是每一個microbatch的調度開銷比較大，當咱們要求的延遲越低，額外的開銷就越大。這就致使了Spark Streaming實際上不是特別適合於作秒級甚至亞秒級的計算。

Kafka Streaming是從一個日誌系統作起來的，它的設計目標是足夠輕量，足夠簡潔易用。這一點很難知足咱們對大致量的複雜計算的需求。

Storm是一個沒有批處理能力的數據流處理器，除此以外Storm只提供了很是底層的API，用戶須要本身實現不少複雜的邏輯。

2、Flink的優點

（1）不一樣於Spark，Flink是一個真正意義上的流計算引擎，和Storm相似，Flink是經過流水線數據傳輸實現低延遲的流處理；

（2）Flink使用了經典的Chandy-Lamport算法，可以在知足低延遲和低failover開銷的基礎之上，完美地解決exactly once的目標；

（3）若是用一套引擎來統一流處理和批處理，那就必須以流處理引擎爲基礎。Flink還提供了SQL/tableAPI這兩個API，爲批和流在query層的統一又鋪平 了道路。所以，Flink是最合適的批和流統一的引擎；

（4）Flink在設計之初就很是在乎性能相關的任務狀態state和流控等相關技術的設計，這些都使得用Flink執行復雜的大規模任務能時性能更勝一籌。

3、Flink和Blink的主要區別

簡單地說，Blink就是阿里巴巴開發的基於開源Flink的企業版計算引擎。如前面所說，雖然Flink在理論模型和架構方面有不少創新，可是在工程實現上還有很多問題。

2015年到2016年，阿里巴巴團隊主要專一於解決Blink的runtime穩定性和scalability的問題：

（1）優化了集羣調度策略使得Blink可以更好更合理地利用集羣資源；

（2）優化了checkpoint機制，使得Blink可以很高效地處理擁有很大狀態的job；

（3）優化了failover的策略，使得job在異常的時候可以更快恢復，從而對業務延遲形成更少的影響；

（4）設計了異步算子，使得Blink可以在即便被讀取外部數據阻塞的同時還能繼續處理其餘event，從而得到總體很是高的吞吐率。

在擁有了穩定的runtime以後，開始專一於加強Blink的易用性 。因此在2016年末到如今，阿里巴巴團隊大力開發Blink實時計算SQL，經過SQL做爲統一API服務於各類複雜業務。從規範Streaming SQL的語義和標準，到實現UDX、join、aggregation、window等一系列SQL最重要的算子，幾乎一手打造了完整的Streaming SQL，而且將這些工做推回了FLink社區，獲得Flink社區的承認。截止目前，Blink團推前後擁有了5位Flink貢獻者。

4、流數據的SQL查詢存在的難點，以及Blink的解決方案

流計算SQL設計中最大的難點就是Stream SQL的語義和標準。這個事情在Flink和Calcite兩個社區一直都在討論研究中，後來達成共識---世界上不存在Stream SQL。流和 批的計算能夠天然而然地在傳統SQL這一層統一。

流計算所特有的unbounded特性其實本質只是什麼時候觀測抽樣計算結果，這種屬性能夠做爲一個job的configure來設置而無需去改變用戶的業務查詢邏輯。爲了可以使用傳統SQL在流計算上執行，阿里巴巴和Flink社區一塊兒引入了動態表的概。除了動態表以外，阿里巴巴還提出並解決了流計算撤回等其餘重要的流計算場景擁有的概念。有了這些語義和功能，使用傳統批處理SQL就能寫出Blink流式計算的任務，這樣就使得使用Blink SQL做爲一個支持流處理和批處理的統一的API成爲可能。

基於Blink SQL，阿里巴巴打造了新一代阿里巴巴流計算平臺streamCompute。如今整個阿里集團包括搜索、推薦、廣告等大部分核心流計算業務都是經過streamCompute平臺來提供服務。 ---------------------