大數據文摘授權轉載自數據派THU
作者:王海濤
本篇文章屬於阿里巴巴Flink系列文章之一。
當提及大數據時,我們無法忽視流式計算的重要性,它能夠完成強大的實時分析。而說起流式計算,我們也無法忽視最強大的數據處理引擎:Spark和Flink。
Apache Spark自2014年以來迅速普及。它提供了一個適用常見數據處理場景的統一引擎,如批處理、流處理、互動式查詢和機器學習。在某些情況下,它的性能是前一代Hadoop MapReduce的數百倍。憑藉其高性能的處理和廣泛的場景支持,它在大數據開發方面受到早期用戶的長期青睞。
在Spark出現後不久,Apache Flink就作為強勁對手進入公眾視野,並在2016年左右名聲大噪。當Spark早期用戶在實時流處理等場景中面臨可用性問題時,Flink提供了一個支持各種場景的高級流處理引擎,Flink的優勢還不僅僅於此。
在這場短暫的競爭中,Spark在持續優化它的實時流處理能力,2.3版(2月份)中引入了一個持續流處理模型,將流處理延遲降至毫秒級。同樣,Flink也是一個強大的創新者。這兩個框架中誰會成為定義下一代大數據計算的主流,這還有待觀察。
為了闡明這個問題,本文將全面分析它們各自的技術和用途。
大數據計算引擎的起源
最初,Hadoop和其他基於MapReduce的數據處理系統出現是為了滿足傳統資料庫能力以外的數據處理需求。2004年穀歌發布MapReduce白皮書以來的發展浪潮,利用Hadoop開源生態系統或者類似系統來處理大數據已經成為業界的基本需求。
儘管操作門檻一降再降,但公司在開發自己的數據處理系統時,還是不可避免地遇到一系列問題。他們經常發現從數據中獲取價值所需的投入遠遠超出了預期。
以下各章節介紹了一些普遍的問題,這有助於解釋Spark和Flink的持續競爭關係。
一條非常艱難的學習曲線
大數據領域的菜鳥們經常會對他們所需的技術數量感到震驚。在過去幾十年中,開發的傳統資料庫通常都是為了廣泛的數據處理而構建的(技術不多),但像Hadoop這樣的大數據生態系統則需要幾個不同的子系統(技術相對較多),原因是在各種需求場景出現前每個子系統都有自己的專攻領域和優勢。