大數據計算框架的發展
最近幾年,出現了很多熱門的開源社區,其中註明的Hadoop Storm,以及很熱門的Spark, 它們有着各自專注的應用場景.Spar掀開了內存計算的先河,也以內爲基礎,贏得了內存計算的飛速發展.Spark的火熱或多或少的掩蓋了其他分佈式計算的系統的身影.就像Flink.
在這裏把計算引擎分爲幾代.首先第一代無疑是Hadoop承載的MapReduce,它將計算分爲兩個階段,分爲Map和Reduce.對於上層應用來說就不得不想方設法拆分算法,甚至於不得不在上層應用來說,就不得不想方法拆分算法,甚至不得不在上層應用實現多個Job的串聯,以完成一個完整的算法,例如迭代計算.
由於這樣的弊端,催生了支持DAG框架的產生.因此,支持DAG的框架被劃分爲第二代計算框架.如Tez以及更上一層的Oozie.這裏我們不去細究各種DAG實現之間的區別,不過對於當時的Tez和Oozie來說,大多還是批處理的任務.
Spark爲代表的第三代的計算引擎.第三代計算引擎的特點主要是Job內部的DAG支持(不跨越Job),以及強調的實時計算.在這裏,很多人認爲第三代計算引擎也能夠很好的運行批處理的Job.
隨着第三代計算的引擎的出現,促進了上層應用快速發展,例如各種迭代計算的性能以及對流計算和 SQL 等的支持。Flink的誕生就被歸爲了第四代.這應該主要表現在Flink對流計算的支持,以及更一步的實時性上面.當然Flink也可以支持Batch的任務,以及DAG的運算.
Flink的計算
在2008年,Flink的前身已經是柏林理工大學的一個研究性項目,在2014被Apache卵化器所化,然後迅速地成爲了 ASF（Apache Software Foundation）的頂級項目之一。Flink 的最新版本目前已經更新到了 0.10.0 了.
Flink是一個針對數據流和批數據的分佈式處理引擎.它主要是由Java代碼實現.對Flink而言,其所要處理的主要場景就是流數據,批數據只是流數據的一個極限特例而已.換句話說,Flink會把所有任務當成流來處理,這也是其最大的特點.Flink可以支持本地的快速迭代,以及一些環形的迭代任務.並且Flink可以定製化內存管理.
在這點,如果要對比Flink和Spark的話,Flink並沒有將內存完全交給應用層,這也是爲什麼Spark相對於Flink,更容易出現OOM(out of memory).就框架本身與應用場景來說，Flink 更相似與 Storm。如果之前瞭解過 Storm 或者 Flume 的讀者，可能會更容易理解 Flink 的架構和很多概念。
Flink的架構圖:
如圖所示可以得出
Clinet, JobManager和TaskManager.Client用來提交任務給JobManager,JobMangerf分發任務給TaskManger去執行,然後TaskManger會心跳的彙報任務狀態.看到這裏，有的人應該已經有種回到 Hadoop 一代的錯覺。確實，從架構圖去看，JobManager 很像當年的 JobTracker，TaskManager 也很像當年的 TaskTracker。然而有一個最重要的區別就是 TaskManager 之間是是流（Stream）。其次,Hadoop一代中,只有Map和Reduce之間是Shuffle,而對Flink而言,可能有很多級,並且在TaskManger內部和TaskManager之間都會有數據傳遞,而不像Hadoop,是固定的Map到,Reduce.
Flink中的調度簡述
在Flink集羣中,在計算資源被定義Task Slot. 每個TaskManger會擁有一個或多個Slots. JobManager會以Slot爲單位調度Task.但是這裏Task跟我們在Hadoop中的理解是有區別.對於Flink的JobManger來說,其調度的是一個Pipeline的Task,而不是一個點.舉個例子，在 Hadoop 中 Map 和 Reduce 是兩個獨立調度的 Task，並且都會去佔用計算資源。對 Flink 來說 MapReduce 是一個 Pipeline 的 Task，只佔用一個計算資源。類同的，如果有一個 MRR 的 Pipeline Task，在 Flink 中其也是一個被整體調度的 Pipeline Task。在 TaskManager 中，根據其所擁有的 Slot 個數，同時會擁有多個 Pipeline。
Flink的生態圈
一個計算框架要有長遠的發展,必須打造一個完整的Stack,只有上層有了具體的應用,並能夠很好的發揮計算框架的優勢,那麼這個計算框架才能吸引更多的資源,纔會更快的進步.
Flink首先支持Scala和Java的API,Python也正在測試中.Flink通過Gelly支持了圖操作
Flink 爲了更廣泛的支持大數據的生態圈，其下也實現了很多 Connector 的子項目。最熟悉的，當然就是與 Hadoop HDFS 集成。
Flink的部署
Flink有三種部署模式,分別是Local, Standalone Cluster和Yarn Cluster. 對於local模式來說,JobManager和TaskManager會公用一個JVM來完成Workload.如果要驗證一個簡單的應用,local模式最方便的.實際應用中大多使用Standalone或者Yarn Cluster.
Standalone 模式
在搭建Flink的安裝包,需要先下載Flink安裝包針對Hadoop版本.
我們需要指定Master和Worker.Master機器會啓動JobManager,Worker則會啓動TaskManager.因此,我們需要修改conf目錄中的Master和Slaves,在配置Master文件時,需要指定的JobManager的UI監聽端口,一般情況下JobManager只需配置一個,Worker則配置一個或多個.
micledeMacBook-Pro:conf micle$ cat masters
localhost:8081
micledeMacBook-Pro:conf micle$ cat slaves
localhost在conf目錄中找到文件楓林客-conf.yaml.在這個文件定義了Flink各個模塊的基本屬性,如RPC的端口,JobManager和TaskManager堆的大小等,在不考慮HA的情況下,一般只需要修改屬性taskmanager.numberOfTaskSlots,也就是每個Task Manger所擁有的Solt個數,在這個屬性,一般設置成機器CPU的core數,用來平衡機器之間的運算性能.其默認值爲1.配置完成後,使用下面的命令啓動JobManager和TaskManager.
啓動StandAlone模式的Flink
啓動之後就可以登錄Flink的GUI頁面,在頁面中我們可以看到Flink集羣的基本屬性,在JobManager和TaskManager的頁面中,可以看到這兩個模塊的屬性.
Yarn Cluster模式
在一個企業中,爲了最大化的利用集羣資源 ,一般都會在一個集羣中同時運行多種類型的Worload.因此Flink也支持在Yarn上面運行.讓我們通過下圖瞭解Yarn和Flink的關係
Flink與Yarn的關係
在圖中可以看出,Flink與Yarn的關係與MapReduce和Yarn的關係是一樣的.Flink通過Yarn的接口實現了自己的AppMaster.在Yarn中部署Flink,Yarn就會用自己的Container來啓動Flink的JobManager和TaskManager
瞭解Flink與Yarn的關係,我們就簡單看下部署的步驟.通過一些命令來查看Yarn中現有的Application且檢查其狀態.
yarn application -list如果命令正確返回,就說明Yarn的RM目前已經在啓動狀態,針對不同Yarn的版本,Flink有不同的安裝包.Flink在Yarn上面有兩種運行模式.一種是讓Yarn直接啓動JobManager和TaskManager,另一種是在運行Flink Workload的時候啓動Flink的模塊,前者相當於讓Flink模塊處於Standby的狀態.
在下載和解壓Flink的安裝包之後,需要在環境中增加環境中增加變量Hadoop_conf_dir或者Yarn_conf_dir,其指向Yarn的配置目錄
export HADOOP_CONF_DIR=/etc/hadoop/conf
這是因爲Flink實現Yarn的Client,因此需要Yarn的一些配置和Jar包.配置好環境變量後,只需簡單的運行的腳本,Yarn就會啓動Flink和JobManager和TaskManager
yarn-session.sh -d -s 2 -tm 800 -n 2
上面的命令的意思是,向Yarn申請2個Container啓動TaskManager(-n 2), 每個TaskManager擁有兩個Task Slot(-s 2), 並且向每個TaskManager的Container申請800M的內存,在上面的命令成功後,我們就可以在YarnApplication頁面看到Flink的記錄
如過有些虛擬機中會有很多錯誤,這裏需要注意內存的大小,Flink向Yarn會申請多個Container,但是Yarn的配置可以限制Container所能申請的內存大小,甚至Yarn本身所管理的內存大小就很小,這樣很可能無法正常啓動TaskManager,尤其當指多個TaskManager的時候.
Flink的HA
對於一個企業級的應用,穩定性是首要考慮的問題,然後纔是性能,因此HA機制是必不可少的.另外對於已經瞭解Flink架構的讀者可能會擔心Flink架構單點問題.和Hadoop一代一樣,從架構中我們可以明顯發現的問題JobManager有明顯單點故障問題(SPOF, single point of failure). JobManager肩負着任務調度及資源分配,一旦JobManager出現意外,其後果可想而知,所有同理Flink同樣有對JobManager HA 的處理方式,原理上基本和Hadoop一樣.
首先，我們需要知道 Flink 有兩種部署的模式，分別是 Standalone 以及 Yarn Cluster 模式。對於 Standalone 來說,Flink必須依賴Zookeeper來實現JobManager的HA(Zookeeper已經成爲了大部分開源框架HA必不可少的模塊).在Zookeeper的幫助下,一個Standalone的Flink集羣會同時有多個活着的JobManager,其中一個處於工作狀態,其它處於standby狀態.當工作中的 JobManager 失去連接後（如宕機或 Crash），Zookeeper 會從 Standby 中選舉新的 JobManager 來接管 Flink 集羣。
對於Yarn Cluaster模式來說, Flink就要依靠Yarn本身來對JobManager做HA.其實這裏完全是Yarn的機制.對於Yarn Cluster模式來說,JobManager和TaskManager都是被Yarn啓動在Yarn的Container中,也就是說它的故障恢復,就要完全依靠Yarn中的ResourceManager(和MapReduce的AppMaster).由於完全依賴Yarn,因此不同版本的Yarn可能會有細微的差異.
Flink的Rest API 介紹
Flink 和其他大多開源的框架一樣，提供了很多有用的 Rest API。Flink DashBoard本省也是通過其Rest來查詢各項的結果數據.在Flink RestAPI基礎上,可以比較容易的將Flink的Monitor功能和其它第三方工具集成.
在Flink的進程中,由於JobManager來提供RestAPI的服務.因此在調用Rest之前,要確定JobManager是否處於正常狀態.在正常情況下,在發送一個Rest請求給JobManager之後,client就會收到一個JSON格式返回結果.由於目前Rest提供的功能還不多,需要增強這塊功能的讀者可以在子項目 flink-runtime-web 中找到對應的代碼。其中最關鍵一個類 WebRuntimeMonitor，就是用來對所有的 Rest 請求做分流的，如果需要添加一個新類型的請求，就需要在這裏增加對應的處理代碼。下面我例舉幾個常用 Rest API。
1.查詢Flink集羣的基本信息:/overview.示例命令格式以及返回結果如下:
$ curl http://localhost:8081/overview{"taskmanagers":1,"slots-total":16,
"slots-available":16,"jobs-running":0,"jobs-finished":0,"jobs-cancelled":0,"jobs-failed":0}
- 查詢當前Flink集羣中的Job信息:/jobs/ 示例命令格式以及返回的結果如下:
$ curl http://localhost:8081/jobs{"jobs-running":[],"jobs-finished":
["f91d4dd4fdf99313d849c9c4d29f8977"],"jobs-cancelled":[],"jobs-failed":[]}
3.查詢一個指定的Job信息:/jobs/jobid.這個查詢結果會返回 特別多的詳細的內容,這是我在瀏覽器中進行的測試,如下圖:
雲心Flink的Workload
WordCount的例子,就像是計算框架的helloworld.這裏就一Wordcount爲例,在Flink中運行Workload.
在安裝Flink的環境中,找到Flink的目錄,然後在bin/flink,它用來提交Flink workload的工具.對於WordCount,我們可以直接使用已有的示例jar包.
./bin/flink run ./examples/WordCount.jar hdfs://user/root/test hdfs://user/root/out
上面的命令是在 HDFS 中運行 WordCount，如果沒有 HDFS 用本地的文件系統也是可以的，只需要將“hdfs://”換成“file://”。這裏我們需要強調一種部署關係，就是 StandAlone 模式的 Flink，也是可以直接訪問 HDFS 等分佈式文件系統的。