【數(shù)據(jù)分析小兵】專注數(shù)據(jù)中臺產(chǎn)品領域,覆蓋開發(fā)套件,包含數(shù)據(jù)集成、數(shù)據(jù)建模、數(shù)據(jù)開發(fā)、數(shù)據(jù)服務、數(shù)據(jù)可視化、數(shù)據(jù)治理相關產(chǎn)品以及相關行業(yè)的技術方案的分享。對數(shù)據(jù)中臺產(chǎn)品想要體驗、做二次開發(fā)、關注方案資料、做技術交流的朋友們，可以關注我。

大家好，我是數(shù)據(jù)分析小兵，小兵今天為大家介紹Flink及Spark兩種大數(shù)據(jù)處理引擎的概念、特點與不同，本文重點是針對計算模式（流計算、批計算）和容錯機制兩個重要特性，嘗試通過通俗易懂的文字舉例分析，來講清楚在什么情況下適合選擇Flink和Spark。

01Spark VS Flink概述

Apache Spark?,是一個統(tǒng)一的、快速的分布式計算引擎，能夠同時支持批處理與流計算，充分利用內(nèi)存做并行計算，官方給出Spark內(nèi)存計算的速度比MapReduce快100倍。因此可以說作為當下最流行的計算框架，Spark已經(jīng)足夠優(yōu)秀了。

Apache Flink?是一個分布式大數(shù)據(jù)計算引擎，是一個Stateful Computations Over Streams，即數(shù)據(jù)流上的有狀態(tài)的計算，被定義為下一代大數(shù)據(jù)處理引擎，發(fā)展十分迅速并且在行業(yè)內(nèi)已有很多最佳實踐。

02Spark?VS Flink發(fā)展歷史

Spark由加州大學伯克利分校AMPLab于2009年啟動，并于2010年成立Apache開源基金會。Spark的目標是解決Hadoop的瓶頸問題，通過內(nèi)存計算和數(shù)據(jù)分片處理等方法提高大數(shù)據(jù)處理的效率和性能。2014 年 2 月，Spark 成為 Apache 的頂級項目。

Flink是Apache軟件基金會的一個頂級項目，是為分布式、高性能、隨時可用以及準確的流處理應用程序打造的開源流處理框架，并且可以同時支持實時計算和批量計算。Flink起源于Stratosphere 項目，該項目是在2010年到2014年間由柏林工業(yè)大學、柏林洪堡大學和哈索普拉特納研究所聯(lián)合開展的，開始是做批處理，后來轉(zhuǎn)向了流計算。

2014年12月，Flink項目成為Apache軟件基金會頂級項目。目前，Flink是Apache軟件基金會的5個最大的大數(shù)據(jù)項目之一，在全球范圍內(nèi)擁有350多位開發(fā)人員，并在越來越多的企業(yè)中得到了應用。在國外，優(yōu)步、網(wǎng)飛、微軟和亞馬遜等已經(jīng)開始使用Flink。在國內(nèi)，包括阿里巴巴、美團、滴滴等在內(nèi)的知名互聯(lián)網(wǎng)企業(yè)，都已經(jīng)開始大規(guī)模使用Flink作為企業(yè)的分布式大數(shù)據(jù)處理引擎。

03Spark?VS Flink技術棧

3.1Spark技術棧

支持從多種數(shù)據(jù)源獲取數(shù)據(jù)，包括Kafk、Flume、Twitter、ZeroMQ、Kinesis 以及TCP sockets，從數(shù)據(jù)源獲取數(shù)據(jù)之后，可以 使用諸如map、reduce、join和window等高級函數(shù)進行復雜算法的處理。最后還可以將處理結(jié)果 存儲到文件系統(tǒng)，數(shù)據(jù)庫和現(xiàn)場 儀表盤。在“One Stack rule them all”的基礎上，還可以使用Spark的其他子框架，如集群學習、圖計算等，對流數(shù)據(jù)進行處理。

3.2Flink技術棧

Flink與Spark類似，同樣提供了多種編程模型，從流計算到批處理，再到結(jié)構化數(shù)據(jù)處理以及機器學習、圖計算等。

lDataStreamAPl DataSetAP!:這是Fink核心的編程模型，這兩套AP!分別面向流處理與批處理，是構建在有狀態(tài)流處理以及Runtime之上的高級抽象，供大部分業(yè)務邏輯處理使用。

lTabIe API& SQL: Table API& SQL是以DataStream AP!和 DataSetAP!為基礎面向結(jié)構化數(shù)據(jù)處理的高級抽象，提供類似于關系型數(shù)據(jù)庫的Table和SQL查詢功能，能夠簡單方便的操作數(shù)據(jù)流。

lCEP:是DataStream APl/DataSetAPI的另一個高級抽象，是一個面向復雜事件處理的庫。

lFlinkML:Flink機器學習庫，批處理API的高級封裝，提供可擴展的ML算法、直觀的API和工具。

lGelly:Flink圖計算的庫，也是在批處理API基礎上做的一層封裝，提供了創(chuàng)建、轉(zhuǎn)換和修改圖的方法以及圖算法庫。

04Spark?VS Flink技術特點

4.1Spark特點：

l高性能，與?Hadoop 的 MapReduce 相比，Spark 基于內(nèi)存的運算要快 100 倍以上，基于硬盤的運算也要快 10 倍以上。Spark 實現(xiàn)了高效的 DAG 執(zhí)行引擎，可以通過基于內(nèi)存來高效處理數(shù)據(jù)流。

l易用性，Spark 支持 Java、Python、R 和 Scala 的 API，還支持超過 80 種高級算法，使用戶可以快速構建不同的應用。

l通用性，Spark 提供了統(tǒng)一的解決方案。Spark 可以用于批處理、交互式查詢(Spark SQL)、實時流處理(Spark Streaming)、機器學習(Spark MLlib)和圖計算(GraphX)。這些不同類型的處理都可以在同一個應用中無縫使用。

l兼容性，Spark 可以非常方便地與其他的開源產(chǎn)品進行融合。比如，Spark 可以使用 Hadoop 的 YARN 和 Apache Mesos 作為它的資源管理和調(diào)度器，并且可以處理所有 Hadoop 支持的數(shù)據(jù)，包括 HDFS、HBase 和 Cassandra 等。這對于已經(jīng)部署 Hadoop 集群的用戶特別重要因為不需要做任何數(shù)據(jù)遷移就可以使用 Spark 的強大處理能力。

4.2Flink特點：

l高容錯性，Flink提供了容錯機制，可以恢復數(shù)據(jù)流應用到一致狀態(tài)。該機制確保在發(fā)生故障時，程序的狀態(tài)最終將只反映數(shù)據(jù)流中的每個記錄一次，也就是實現(xiàn)了“精確一次”（exactly -once）的容錯性。Flink的容錯機制不斷地創(chuàng)建分布式數(shù)據(jù)流的快照，通過異步快照來確保數(shù)據(jù)狀態(tài)的一致性。

l豐富的狀態(tài)管理，流處理應用需要在一定時間內(nèi)存儲所接收到的事件或中間結(jié)果，以供后續(xù)某個時間點訪問并進行后續(xù)處理。Flink提供了豐富的狀態(tài)管理相關的特性支持。

l同時支持高吞吐、低延遲、高性能，高吞吐、高性能、低時延的實時流處理引擎，能夠提供ms級時延處理能力。

l豐富的時間語義支持，時間是流處理應用的重要組成部分，對于實時流處理應用來說，基于時間語義的窗口聚合、檢測、匹配等運算是非常常見的。Flink提供了豐富的時間語義支持。

05Spark?VS Flink應用場景分析

5.1?計算模式分析

首先我們先通過兩個例子來介紹一下流計算和批計算的特點。

流計算的特點是我在處理一條數(shù)據(jù)的時候，無法預知未來還有多少數(shù)據(jù)，而且這個數(shù)據(jù)的總量是不確定的，有可能有無窮無盡的數(shù)據(jù)，也有可能到某個點就沒有了。如上圖所示，我們不知道數(shù)據(jù)“5”后面還有沒有數(shù)據(jù)，還有多少條數(shù)據(jù)。

而批計算之所以叫批計算，就是因為在我處理的那一瞬間，或者說在我程序啟動的那一瞬間有多少數(shù)據(jù)是已經(jīng)確定了的，它是不會再變了的。如上圖，需要計算的數(shù)據(jù)是12條，那在整個處理生命周期里面就是這12條數(shù)據(jù)，不會再改變。

這樣的不同的特點帶來的影響就是不同的計算模式，他的計算實現(xiàn)策略也不相同，我們舉一個批計算的例子：我們來做一個分組聚合的計算，統(tǒng)計下圖中有多少綠色球，多少白色球。

我們要怎么來實現(xiàn)呢？

1. 因為是分布式批計算，所以這次計算任務他要計算的數(shù)量是固定且已知的，我們可以建立兩個分布式任務Task1和Task2，分別去讀左半邊和右半邊數(shù)據(jù)，將取到的綠色球存在partition0，白色球存在partition1，并落地存儲為一個文件。

2. 當Task1和Task2對所有的數(shù)據(jù)做完處理并存儲為數(shù)據(jù)文件后，再讓Task3和Task4分別去取partition0和partition1數(shù)據(jù)并求和，就算出了綠色球和白色球的數(shù)量。

3. 注意一個細節(jié)，Task3和Task4是需要等他的上游任務將所有數(shù)據(jù)處理完并形成文件后再去讀數(shù)據(jù)，但如果數(shù)據(jù)是動態(tài)的，我們不知道有多少數(shù)據(jù)，還能這樣去計算么？答案顯然是不能的。因為這樣的特性，批計算可以在上游任務設計一些策略進行一些預處理，比如Task1和Task2在取完數(shù)據(jù)后，對綠色球和白色球分別做一個求和，提前計算出數(shù)量，通過這些策略來優(yōu)化計算性能，但是流計算是不能采用這樣的策略的。

總結(jié)：Spark和Flink都是批流一體的計算引擎，但是Spark更適合做批計算，而Flink更適合做流計算。Spark?適合于吞吐量比較大的場景，數(shù)據(jù)量非常大而且邏輯復雜的批數(shù)據(jù)處理，并且對計算效率有較高要求（比如用大數(shù)據(jù)分析來構建推薦系統(tǒng)進行個性化推薦、廣告定點投放等）。Flink?主要用來處理要求低延時的任務，實時監(jiān)控、實時報表、流數(shù)據(jù)分析和實時倉庫。Flink可以用于事件驅(qū)動型應用，數(shù)據(jù)管道，數(shù)據(jù)流分析等。

5.2?容錯機制分析

上面提到了，sparkstreaming也是可以做流計算的，包括Storm也可以，那我們?yōu)槭裁凑fFlink最適合做流計算呢，就是因為Flink提供了很強的容錯機制，接下來我們就舉幾個簡單的例子來分析一下Flink的容錯機制，這也是Flink最為核心的特點之一。

1. 復雜的計算需要記錄變量

   首先，我們做復雜計算時需要記錄變量，舉個例子，我們要分別統(tǒng)計白色數(shù)據(jù)和綠色數(shù)據(jù)的最大值，如下圖所示：

   

   當處理完白色數(shù)據(jù)“5”之后，因為“5”是處理的第一個數(shù)據(jù)，所以需要在緩存記錄當前的最大值為5，這樣再處理下一個數(shù)據(jù)“2”的時候，才能夠就進行比較。

2. ?Flink采用STATE組件記錄變量

   有的朋友可能會說了，不就是記錄個變量么？其他的流計算引擎也可以，你為什么說Flink更強？那是因為Flink提供了非常強大的狀態(tài)容錯能力。還是上面的例子，大家想一下，雖然我記錄了變量，但是如果是記錄在內(nèi)存里，系統(tǒng)一旦掛掉，這些變量是不是就沒有了，這樣再計算出來的結(jié)果很可能就是錯誤的。而Flink提供STATE組件來記錄變量，如下圖。

   

   ?

   Flink的STATE組件提供了兩種狀態(tài)后端，分別是HashMapStateBackend和EmbededRocksDbStateBackend。

   HashMapStateBackend，將變量記錄在內(nèi)存的一張數(shù)據(jù)表中；

   EmbededRocksDbStateBackend，會將變量記錄在Flink內(nèi)嵌的一個數(shù)據(jù)庫RocksDB中，而RocksDB會將變量存儲在本地磁盤上。

3. ?Flink通過異步快照機制保證語義的一致性

   有的朋友肯定又有疑惑了，你說的這HashMapStateBackend不也是存在內(nèi)存里么？系統(tǒng)掛了還不是會丟失狀態(tài)值？這里就要介紹一下Flink的checkpoint（快照）機制了。還是先來看一個例子，我們要求一組數(shù)據(jù)中的最大值，如下圖：

我們創(chuàng)建2個任務，task1負責讀取數(shù)據(jù)，通過STATE記錄數(shù)據(jù)偏移量后傳送給task2，task2負責計算最大值。通過barrier和快照來保證語義的一致性。

• 首先，我們假設task1讀取了數(shù)據(jù)“14”，那么task1的state偏移量將變?yōu)?；

• 接下來task2計算數(shù)據(jù)“14”，并將task2的state最大值更新為14。注意這個時候barrier被task1讀取，會對state偏移量進行快照，將偏移量1的快照存入HDFS；

• Task1繼續(xù)讀取數(shù)據(jù)“20”，將task1的state偏移量將變?yōu)?，而task2讀取到了barrier，會對state最大值進行快照，將最大值14的快照存入HDFS，此時的狀態(tài)如下圖：

  

那我們假設這個時候系統(tǒng)掛掉了，重啟后task1的state將加載偏移量1，而task2的state將加載最大值14。接下來task1將重新讀取數(shù)據(jù)“20”，這樣就確保了最后計算的最大值是沒有問題的，因為task1和task2的state都是處理了相同的數(shù)字（“5”“2”“8”“14”）后的狀態(tài)，這就是Flink通過異步快照機制實現(xiàn)的語義一致和高容錯性。

小兵今天通過舉例重點介紹了計算模式和容錯機制兩個特性，結(jié)論就是如果您的業(yè)務場景大部分是批計算，那就選擇Spark；如果大部分場景需要流計算就選擇Flink，Flink提供了更為強大的容錯機制。

參考資料：

《Flink編程基礎（Scala版）》--林子雨編著

Apache 流框架 Flink，Spark Streaming，Storm對比分析--網(wǎng)易數(shù)帆

大數(shù)據(jù)之Spark--濁酒南街

實戰(zhàn)Flink+Doris實時數(shù)倉