隨著互聯(lián)網(wǎng)的不斷發(fā)展，行業(yè)內(nèi)對(duì)于數(shù)據(jù)的處理能力和計(jì)算的實(shí)時(shí)性要求都在不斷增加，隨之而來(lái)的是計(jì)算框架的升級(jí)。經(jīng)過(guò)了十余年開(kāi)源社區(qū)的不斷演進(jìn)，現(xiàn)在計(jì)算框架已經(jīng)從第一代的雅虎開(kāi)源的Hadoop體系進(jìn)化到目前主流的Spark框架，這兩套框架的計(jì)算主要是從強(qiáng)依賴硬盤存儲(chǔ)能力的計(jì)算發(fā)展到了內(nèi)存計(jì)算，大大增強(qiáng)了計(jì)算力。下一代計(jì)算引擎，也就是第三代計(jì)算引擎，將會(huì)從計(jì)算實(shí)時(shí)性的角度突破，也就是今天要講到的Flink框架，本文將從簡(jiǎn)入深的介紹Flink框架的特點(diǎn)。
?
基本架構(gòu)
?調(diào)度層面Flink支持本地運(yùn)行以及分布式運(yùn)行兩種，分布式運(yùn)行可以跑在目前主流的基于Yarn體系中，也可以跑在目前業(yè)內(nèi)最主流的K8S中，F(xiàn)link本質(zhì)上還是專注于做計(jì)算框架的部分，應(yīng)用于目前行業(yè)內(nèi)主流的調(diào)度引擎上而確保一個(gè)分布式的計(jì)算能力。
在核心層主要做的是一件事是如何對(duì)流式任務(wù)進(jìn)行編排，流式任務(wù)不同于離線任務(wù)的最大一個(gè)特點(diǎn)在于任務(wù)編排上面，比如我們有三個(gè)事件分別叫1、2、3。在離線任務(wù)中，事件運(yùn)行是有先后順序的，比如要先運(yùn)行1再運(yùn)行2接著運(yùn)行3，在流式任務(wù)場(chǎng)景下這種事件只有邏輯上的先后關(guān)系，實(shí)際上是同時(shí)觸發(fā)并執(zhí)行的。
?API層面稍后單獨(dú)用一個(gè)模塊講解，在Library方面內(nèi)置了圖計(jì)算算法包Gelly和機(jī)器學(xué)習(xí)包FlinkML以及CEP。其中Gelly和FlinkML是基于DataSet API進(jìn)行開(kāi)發(fā)的，而DataSet API是一個(gè)離線批計(jì)算的接口，所以本質(zhì)上Gelly和FlinkML并沒(méi)有發(fā)揮Flink這個(gè)天然流式框架的優(yōu)勢(shì)。個(gè)人覺(jué)得，F(xiàn)link作為Apache相對(duì)比較年輕的開(kāi)源計(jì)算框架，對(duì)于一些組件化的支持還不完善，相比于Spark生態(tài)還有比較大的差距。后續(xù)如果能基于Flink Stream API開(kāi)發(fā)出流式的上層應(yīng)用，會(huì)成為Flink的一大亮點(diǎn)。
分布式架構(gòu)層面Flink和Spark或者Hadoop區(qū)別不大，整體框架是：
?由Flink的Client向Job Master提交任務(wù)，Job Master作為整個(gè)集群的管理節(jié)點(diǎn)。Task Manager是Slave的角色，負(fù)責(zé)底層的運(yùn)算工作。Job Master控制整個(gè)計(jì)算任務(wù)的Checkpoint的進(jìn)度。Task Manager間可以通過(guò)數(shù)據(jù)流的方式交換數(shù)據(jù)，同時(shí)Task Manager在任務(wù)的并行化計(jì)算方面比MapReduce做的更好，F(xiàn)link Task Manager是采用多線程的機(jī)制進(jìn)行并行化數(shù)據(jù)計(jì)算，而傳統(tǒng)的MapReduce方法采用的是JVM進(jìn)程的形式。
開(kāi)發(fā)接口架構(gòu)
作為一個(gè)算法發(fā)燒友，我還是愿意花更多的篇幅來(lái)介紹如何基于Flink框架進(jìn)行開(kāi)發(fā)。首先看下開(kāi)放編程接口的API上下游站位關(guān)系，
最上一層是Flink SQL，這一層其實(shí)是一個(gè)上級(jí)封裝，了解機(jī)器學(xué)習(xí)或者其它更復(fù)雜編程模型的同學(xué)應(yīng)該比較清楚，并不是所有的邏輯都能通過(guò)SQL來(lái)實(shí)現(xiàn)。不過(guò)目前絕大部分的數(shù)據(jù)實(shí)時(shí)處理邏輯通過(guò)SQL這一層就可以解決。
TableAPI這一級(jí)可以看出Flink要實(shí)現(xiàn)流批一體化的野心，F(xiàn)link希望可以在流式DataStream API和離線DataSet API之上做一層封裝，對(duì)用戶暴露更多復(fù)雜計(jì)算的函數(shù)，同時(shí)基于這一層API實(shí)現(xiàn)的功能可以完成流批一體。這個(gè)設(shè)想是很好的，不過(guò)目前還有很多功能沒(méi)辦法在這一級(jí)實(shí)現(xiàn)，也導(dǎo)致了TableAPI的尷尬。
DataStream和DataSet仍是目前的主流編程接口，如果希望在Flink中實(shí)現(xiàn)諸如機(jī)器學(xué)習(xí)算法這樣負(fù)責(zé)邏輯的函數(shù)，還是要依賴于這一層。至于Runtime內(nèi)核開(kāi)發(fā)，這個(gè)明顯是留給非常資深的高級(jí)用戶來(lái)使用，大部分的開(kāi)發(fā)應(yīng)該不會(huì)觸碰。
如何做流式編程
重點(diǎn)講下DataStream這個(gè)開(kāi)發(fā)接口，首先Flink把流式編程模型切分為DataSource模塊、Transformation模塊和DataSink模塊。DataSource和DataSink分別對(duì)應(yīng)著數(shù)據(jù)的流入和流出。
在DataSource和Sink模塊，F(xiàn)link都原生支持了Apache體系內(nèi)的很多產(chǎn)品的I/O，比如Kafka Connector和Elastic Search Connector等等。同時(shí)在數(shù)據(jù)接入導(dǎo)出方面還內(nèi)置了很多數(shù)據(jù)源，
- readFile接口可以實(shí)現(xiàn)讀寫一些CSV、TXT本地文件
- Socket數(shù)據(jù)源可以接收來(lái)自其它服務(wù)的數(shù)據(jù)，這個(gè)接口非常好，可以讓Flink和許多主流的Restful服務(wù)適配
在Transformation模塊，DataStream提供了諸如map、FlatMap、Filter、Reduce、KeyBy這些函數(shù)，我個(gè)人感覺(jué)Flink的這些接口使用起來(lái)還是比較方便的，比如要把下面這個(gè)二元組類型的數(shù)據(jù)都+1，
只需要使用map函數(shù)作如下處理：
流式編程的時(shí)間概念與Watermark
流式開(kāi)發(fā)和離線開(kāi)發(fā)的最大區(qū)別在于對(duì)于數(shù)據(jù)時(shí)間的理解上，離線開(kāi)發(fā)針對(duì)的都是有邊界數(shù)據(jù)，有邊界的意思是在開(kāi)發(fā)過(guò)程中會(huì)用到的數(shù)據(jù)是有限的。而流式應(yīng)用，因?yàn)閿?shù)據(jù)是實(shí)時(shí)流入的，所以對(duì)應(yīng)的數(shù)據(jù)是無(wú)邊界的。以機(jī)器學(xué)習(xí)算法為例，經(jīng)常需要緩沖一部分?jǐn)?shù)據(jù)求區(qū)間內(nèi)的最大值和最小值，那么在無(wú)邊界數(shù)據(jù)條件下如何處理呢？這里就應(yīng)用到了watermark功能。
首先介紹下幾個(gè)時(shí)間的概念：
- Event Time是數(shù)據(jù)在業(yè)務(wù)方的真實(shí)發(fā)生時(shí)間，比如某個(gè)手機(jī)在2019-03-05下午2點(diǎn)被購(gòu)買，這個(gè)時(shí)間就是Event Time
- Ingestion Time指的是數(shù)據(jù)進(jìn)入Flink系統(tǒng)的時(shí)間，理論上會(huì)比Event Time晚一點(diǎn)
- Processing Time：數(shù)據(jù)在當(dāng)前系統(tǒng)被處理的時(shí)間，也就是Flink worker機(jī)器的時(shí)間，這個(gè)是Flink系統(tǒng)的默認(rèn)時(shí)間
所以從概念層面理解，用Flink去處理業(yè)務(wù)最合適的時(shí)間是Event Time，而系統(tǒng)默認(rèn)使用Processing Time是一種簡(jiǎn)化方法，因?yàn)榱魇綌?shù)據(jù)在錄入Flink系統(tǒng)的過(guò)程中會(huì)出現(xiàn)時(shí)間亂序。
接著介紹下Window和Watermark的概念，當(dāng)系統(tǒng)按照Processing Time去流式處理數(shù)據(jù)的時(shí)候，假設(shè)某個(gè)流式算法需要緩沖5分鐘的數(shù)據(jù)算一次Loss，這個(gè)5分鐘就是一個(gè)Window窗口。但是當(dāng)5分鐘已經(jīng)結(jié)束了，還是沒(méi)有數(shù)據(jù)流入計(jì)算引擎，這個(gè)時(shí)候怎么辦？接著等還是執(zhí)行下一個(gè)操作。這就用到了Watermark，當(dāng)?shù)却龝r(shí)間超過(guò)Watermark的設(shè)定時(shí)間，系統(tǒng)就會(huì)自動(dòng)觸發(fā)計(jì)算，無(wú)論數(shù)據(jù)是否滿足Window的要求。
?
寫到做后
本文是我學(xué)習(xí)了Flink的一些資料之后的筆記，可以作為對(duì)Flink框架的一個(gè)大體了解。其實(shí)隨著互聯(lián)網(wǎng)業(yè)務(wù)的不斷發(fā)展和計(jì)算框架的普及，后續(xù)各種廣告推薦、商品推薦、金融風(fēng)控相關(guān)的業(yè)務(wù)都會(huì)逐漸從傳統(tǒng)的離線計(jì)算向流式計(jì)算轉(zhuǎn)型。未來(lái)Flink在數(shù)據(jù)業(yè)務(wù)領(lǐng)域大有可為，期待接下來(lái)產(chǎn)業(yè)計(jì)算的框架升級(jí)。
