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

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

01Spark VS Flink概述

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

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

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

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

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

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

03Spark?VS Flink技術(shù)棧

3.1Spark技術(shù)棧

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

3.2Flink技術(shù)棧

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

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

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

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

lFlinkML:Flink機(jī)器學(xué)習(xí)庫，批處理API的高級封裝，提供可擴(kuò)展的ML算法、直觀的API和工具。

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

04Spark?VS Flink技術(shù)特點(diǎn)

4.1Spark特點(diǎn)：

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

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

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

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

4.2Flink特點(diǎn)：

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

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

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

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

05Spark?VS Flink應(yīng)用場景分析

5.1?計算模式分析

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

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

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

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

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

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

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

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

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

5.2?容錯機(jī)制分析

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

1. 復(fù)雜的計算需要記錄變量

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

   

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

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

   有的朋友可能會說了，不就是記錄個變量么？其他的流計算引擎也可以，你為什么說Flink更強(qiáng)？那是因?yàn)镕link提供了非常強(qiáng)大的狀態(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通過異步快照機(jī)制保證語義的一致性

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

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

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

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

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

  

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

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

參考資料：

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

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

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

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