數據對於技術發展的重要程度不言而喻，尤其是在互聯網大行其道的當下，任何一款產品，數據都是其最寶貴的資源。而如何把數據的價值最大化，如何更高效的計算以及分析這些數據就顯得尤為重要。正值QCon十週年之際，QCon來到廣州，現場為你解讀大數據的應用技巧以及實時流計算框架的選擇。

隨著移動互聯網規模的不斷擴大，用戶群體越來越多，大家對於移動互聯網產品的需求越來越多樣化的同時，對於體驗的要求也越來越“嚴苛”。這麼一想的確沒錯，在產品同質化十分嚴重的現在，同一領域下的競品可能有數十家，如何從這些競品中脫穎而出，用戶體驗顯得尤為重要。

“實時性”是影響當下互聯網用戶體驗最重要的一個因素之一，無法想象打車、外賣、網購、在線視頻等場景下需要花費很長的時間來等待，更快給用戶的反饋已經成為用戶體驗中極為重要的一部分。讓用戶能夠迅速感知到產品的反饋，無論是點擊、購買、視頻等等，無延遲、及時的反饋等等都會給用戶帶來極其良好的體驗感受。

所以如何處理數據並從數據中挖掘有價值的信息呢？這裡不說大家也應該知道了，肯定是實時流計算技術。當下，實時流計算框架可以說是群雄並起，Flink 與 Spark 可以說是當下大環境中應用最廣的兩款實時流計算框架，Spark 和 Flink 都支持實時計算，且都可基於內存計算。但同時 Spark 與 Flink 也有著諸多的不同，我們在生產中應該用哪個？Flink 確定完勝 Spark 嗎？

Spark 真的適用於流計算嗎？

Spark 的核心概念是 RDD (resilient distributed dataset)，指的是一個只讀的，可分區的分佈式數據集，這個數據集的全部或部分可以緩存在內存中用在多次的計算期間。其強一致性的特點，使得 Spark 可以利用強大一致的批處理引擎的重複運行來提供無界數據集的連續處理，可以在確保正確性的同時降低延遲。

Spark 的真正精彩之處在於強大的批處理引擎解決了太多底層麻煩的問題，如果基於此構建流式處理引擎則整個流處理系統將簡單很多，而且可以獨自提供一致性語義保障的流式處理系統。

但是用流計算的思路開發批計算才是最優雅的方式，因此對於 Spark 來講，大換血不可能，只有局部優化。並且 Spark 的本質是一款基於 microbatch 計算的引擎，這種引擎天生的缺點就是延遲越低，所需要的額外開銷就越大。這就決定了 Spark 並非特別適合於做秒級甚至亞秒級的計算。

Flink 在流計算上沒有包袱，一開始就走在對的路上

Flink 是可擴展的批處理和流式數據處理的數據處理平臺，在大規模流處理方面走在最前沿。不同於 Spark，Flink 是一個真正意義上的流計算引擎，通過流水線數據傳輸來實現低延遲的流處理方式。Flink 流行的一個重要因素，即如果要用一套引擎來統一流處理和批處理的話，就必須以流處理引擎為基礎。Flink 提供了 SQL／tableAPI 這兩個 API，為批和流在 query 層的統一鋪平了道路。

通過快速將無序流式數據處理的強大功能帶到開源世界，並將其與分佈式快照及保存點功能等自身創新相結合，Flink 提高了開源流處理的業界標準並引領了當前流式處理創新趨勢。

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

但是，那就一定要選擇 Flink 嗎？

小孩子才做選擇題，我全都要

Flink、Spark 都是十分優秀的、高性能開源大規模數據處理引擎，都為 Apache 的頂級開源項目，目標是在一個系統中支持所有的數據處理以帶來效能的提升。Spark 社區是目前最為活躍的社區之一，經過幾年發展和 Hadoop 生態已經能夠實現較好的結合，也已經被廣泛視為 Hadoop MapReduce 引擎的取代者，但是 Flink 也受到了眾多大廠的青睞。

無論是 Spark 還是 Flink ，未來的發展重點將是數據科學和平臺的 API 化，除了傳統的統計算法外，還包括學習算法，同時使其生態系統越來越完善。未來，Spark 和 Flink 它們都將會是下一代大數據引擎的最有力競爭者。

無論是 Spark 還是 Flink，QCon 全球軟件開發大會廣州站，兩位分別踐行“Spark”與“Flink”的大數據實時流計算技術專家將會現場“Solo”，各執一詞，聽誰的完全取決於你。

Flink，spark更多免費學習資料獲取方式：

1. 轉發 關注
2. 後臺私信我【資料】即可獲得資料免費領取方式！