實時計算這個概念是與離線計算相伴相生的,以 Hadoop為例, Hadoop 批處理 job 的執行時間往往需要幾十分鐘到幾個小時(不同的數據量),所以一般數據的處理是按照時間區間處理的,這叫離線計算,但是,從業務場景上來說,離線計算不能滿足所有業務的需求。
流計算的產生即來源於對於上述數據加工時效性的嚴苛需求:數據的業務價值隨著時間的流失而迅速降低,因此在數據發生後必須儘快對其進行計算和處理。在許多的業務場景上,比如在實時大數據分析、風控預警、實時預測、金融交易等諸多業務場景領域,以銀行的交易系統為例,可靠性要達到 4個 9,甚至 5個 9的地步,而流計算作為一類針對流數據的實時計算模型,可有效地縮短全鏈路數據流時延、實時化計算邏輯、平攤計算成本,最終有效滿足實時處理大數據的業務需求。
2015 年是流計算百花齊放的時代,各個流計算框架層出不窮。Storm, JStorm, Heron, Flink, Spark Streaming, Google Dataflow (後來的 Beam) 等等。其中 Flink 的一致性語義和最接近 Dataflow 模型的開源實現,使其成為流計算框架中最耀眼的一顆。也許這也是阿里看中 Flink的原因,並決心投入重金去研究基於 Flink的 Blink框架。
如果問是基於什麼具體的原因使得阿里選擇了 Flink框架,阿里巴巴的高級技術專家大沙曾言,他們是在 2015年開始調研新一代流計算引擎的,當時的目標就是要設計一款低延遲、exactly once、流和批統一的,能夠支撐足夠大體量的複雜計算的引擎。
Spark streaming的本質還是一款基於 microbatch計算的引擎。這種引擎一個天生的缺點就是每個 microbatch的調度開銷比較大。Kafka streaming是從一個日誌系統做起來的,它的設計目標是足夠輕量,足夠簡潔易用。這一點很難滿足對大體量的複雜計算的需求。Storm是一個沒有批處理能力的數據流處理器,除此之外 Storm只提供了非常底層的 API,用戶需要自己實現很多複雜的邏輯。
有別於 FLink,Blink主要在以下幾個方面做了改進:
優化了集群調度策略使得 Blink能夠更好更合理地利用集群資源;
優化了 checkpoint機制,使得 Blink能夠很高效地處理擁有很大狀態的 job;
優化了 failover的策略,使得 job在異常的時候能夠更快恢復,從而對業務延遲造成更少的影響;
設計了異步算子,使得 Blink能夠在即使被讀取外部數據阻塞的同時還能繼續處理其他 event,從而獲得整體非常高的吞吐率。
以前,MySQL+Linux+PHP可以免費的構建一個小型的網站,也許不久,類似 Flume + Kafka + Blink,也會成為實時流計算一套完整的解決方案。實時計算必然是未來的主流趨勢。
如果你也對實時計算感興趣,請關注 2018年 4月 23日到 24日,我們在北京國際會議中心舉辦的 QCon深度培訓。在會上,阿里巴巴的高級技術專家王紹翾和鄧小勇將為大家帶來 阿里巴巴 Blink流計算平臺介紹與實踐,詳細的介紹 Blink的前世今生,現在報名立享 8折優惠,點擊「閱讀原文」即可了解更多詳情。或添加 chenxi988625諮詢。