[[442090]]

一.Flink與主流計算引擎對比

1. Hadoop MapReduce

MapReduce 是由谷歌首次在論文“MapReduce: Simplified Data Processing on Large Clusters”(谷歌大數(shù)據(jù)三駕馬車之一)中提出的，是一種處理和生成大數(shù)據(jù)的編程模型。Hadoop MapReduce借鑒了谷歌這篇論文的思想，將大的任務分拆成較小的任務后進行處理，因此擁有更好的擴展性。如圖1所示，Hadoop MapReduce 包括兩個階段—Map和Reduce：Map 階段將數(shù)據(jù)映射為鍵值對(key/value)，map 函數(shù)在Hadoop 中用Mapper類表示;Reduce階段使用shuffle后的鍵值對數(shù)據(jù)，并使用自身提供的算法對其進行處理，得到輸出結果，reduce函數(shù)在Hadoop中用Reducer類表示。其中shuffle階段對MapReduce模式開發(fā)人員透明。

圖1　Hadoop MapReduce處理模型

Hadoop MR1 通過JobTracker進程來管理作業(yè)的調度和資源，TaskTracker進程負責作業(yè)的實際執(zhí)行，通過Slot來劃分資源(CPU、內存等)，Hadoop MR1存在資源利用率低的問題。Hadoop MR2 為了解決MR1存在的問題，對作業(yè)的調度與資源進行了升級改造，將JobTracker變成YARN，提升了資源的利用率。其中，YARN 的ResourceManager 負責資源的管理，ApplicationMaster負責任務的調度。YARN 支持可插拔，不但支持Hadoop MapReduce，還支持Spark、Flink、Storm等計算框架。Hadoop MR2 解決了Hadoop MR1的一些問題，但是其對HDFS的頻繁I/O操作會導致系統(tǒng)無法達到低延遲的要求，因而它只適合離線大數(shù)據(jù)的處理，不能滿足實時計算的要求。

2. Spark

Spark 是由加州大學伯克利分校開源的類Hadoop MapReduce的大數(shù)據(jù)處理框架。與 Hadoop MapReduce相比，它最大的不同是將計算中間的結果存儲于內存中，而不需要存儲到HDFS中。

Spark的基本數(shù)據(jù)模型為RDD(Resilient Distributed Dataset，彈性分布式數(shù)據(jù)集)。RDD是一個不可改變的分布式集合對象，由許多分區(qū)(partition)組成，每個分區(qū)包含RDD的一部分數(shù)據(jù)，且每個分區(qū)可以在不同的節(jié)點上存儲和計算。在Spark 中，所有的計算都是通過RDD的創(chuàng)建和轉換來完成的。

Spark Streaming 是在Spark Core的基礎上擴展而來的，用于支持實時流式數(shù)據(jù)的處理。如圖2所示，Spark Streaming 對流入的數(shù)據(jù)進行分批、轉換和輸出。微批處理無法滿足低延遲的要求，只能算是近實時計算。

圖2　Spark Streaming 處理模型

Structured Streaming 是基于Streaming SQL 引擎的可擴展和容錯的流式計算引擎。如圖3所示，Structured Streaming將流式的數(shù)據(jù)整體看成一張無界表，將每一條流入的數(shù)據(jù)看成無界的輸入表，對輸入進行處理會生成結果表。生成結果表可以通過觸發(fā)器來觸發(fā)，目前支持的觸發(fā)器都是定時觸發(fā)的，整個處理類似Spark Streaming的微批處理;從Spark 2.3開始引入持續(xù)處理。持續(xù)處理是一種新的、處于實驗狀態(tài)的流式處理模型，它在Structured Streaming的基礎上支持持續(xù)觸發(fā)來實現(xiàn)低延遲。

圖3　Structured Streaming處理模型

3. Flink

Flink是對有界數(shù)據(jù)和無界數(shù)據(jù)進行有狀態(tài)計算的分布式引擎，它是純流式處理模式。流入Flink的數(shù)據(jù)會經(jīng)過預定的DAG(Directed Acyclic Graph，有向無環(huán)圖)節(jié)點，F(xiàn)link會對這些數(shù)據(jù)進行有狀態(tài)計算，整個計算過程類似于管道。每個計算節(jié)點會有本地存儲，用來存儲計算狀態(tài)，而計算節(jié)點中的狀態(tài)會在一定時間內持久化到分布式存儲，來保證流的容錯，如圖4所示。這種純流式模式保證了Flink的低延遲，使其在諸多的實時計算引擎競爭中具有優(yōu)勢。

圖4　Flink 流式處理模型

二.Flink基本架構

下面從分層角度和運行時角度來介紹Flink 基本架構。其中，對于運行時Flink 架構，會以1.5版本為分界線對前后版本的架構變更進行介紹。

1. 分層架構

Flink是分層架構的分布式計算引擎，每層的實現(xiàn)依賴下層提供的服務，同時提供抽象的接口和服務供上層使用。整體分層架構如圖5所示。

圖5　Flink 分層架構

• 部署：Flink 支持本地運行，支持Standalone 集群以及YARN、Mesos、Kubernetes管理的集群，還支持在云上運行。
• 核心：Flink的運行時是整個引擎的核心，是分布式數(shù)據(jù)流的實現(xiàn)部分，實現(xiàn)了運行時組件之間的通信及組件的高可用等。
• API：DataStream 提供流式計算的API，DataSet 提供批處理的API，Table 和SQL AP提供對Flink 流式計算和批處理的SQL的支持。
• Library：在Library層，F(xiàn)link 提供了復雜事件處理(CEP)、圖計算(Gelly)及機器學習庫。

2. 運行時架構

Flink 運行時架構經(jīng)歷過一次不小的演變。在Flink 1.5 版本之前，運行時架構如圖6所示。

圖6　Flink 1.5 以前版本的運行時架構

• Client 負責編譯提交的作業(yè)，生成DAG，并向JobManager提交作業(yè)，往JobManager發(fā)送操作作業(yè)的命令。
• JobManager 作為Flink引擎的Master角色，主要有兩個功能：作業(yè)調度和檢查點協(xié)調。
• TaskManager為Flink 引擎的Worker角色，是作業(yè)實際執(zhí)行的地方。TaskManager通過Slot對其資源進行邏輯分割，以確定TaskManager運行的任務數(shù)量。

從Flink 1.5開始，F(xiàn)link 運行時有兩種模式，分別是Session 模式和Per-Job模式。

Session模式：在Flink 1.5之前都是Session模式，1.5及之后的版本與之前不同的是引入了Dispatcher。Dispatcher負責接收作業(yè)提交和持久化，生成多個JobManager和維護Session的一些狀態(tài)，如圖7所示。

圖7　Session模式

Per-Job模式：該模式啟動后只會運行一個作業(yè)，且集群的生命周期與作業(yè)的生命周期息息相關， 而Session 模式可以有多個作業(yè)運行、多個作業(yè)共享TaskManager資源， 如圖8所示。

圖8　Per-Job模式

關于作者：羅江宇，趙士杰，李涵淼，閔文俊，四位作者都是非常資深的Flink專家，部分作者是Flink源代碼的維護者和改造者。

羅江宇：Flink技術專家，先后就職于新浪微博、滴滴和某大型電商公司。先后主導或參與了多家公司的Flink實時計算服務的構建、對超大規(guī)模集群的維護以及Flink引擎的改造。擁有豐富的實時計算實戰(zhàn)經(jīng)驗，目前專注于Kubernetes調度、Flink SQL及Flink流批一體化方向。

趙士杰：資深大數(shù)據(jù)技術專家，曾就職于滴滴、阿里巴巴等一線互聯(lián)網(wǎng)公司。從0到1深度參與了滴滴的大數(shù)據(jù)建設，擁有非常豐富的大數(shù)據(jù)平臺一線建設經(jīng)驗，對于大數(shù)據(jù)領域的計算和存儲引擎也有深入研究。

李涵淼：大數(shù)據(jù)研發(fā)專家，曾任滴滴大數(shù)據(jù)開發(fā)工程師。從事大數(shù)據(jù)領域工作多年，參與過多家公司流計算平臺的設計與研發(fā)，目前專注于流批一體、OLAP技術方向的研究與應用。

閔文俊：螞蟻集團技術專家、開源大數(shù)據(jù)社區(qū)愛好者、Flink Contributor，在實時計算領域工作多年，深度參與了滴滴、螞蟻集團的實時計算平臺建設。 書評

本文摘編于《Flink技術內幕：架構設計與實現(xiàn)原理》，經(jīng)出版方授權發(fā)布。(書號：9787111696292)轉載請保留文章來源。