為了深入落實(shí)國家大數(shù)據(jù)戰(zhàn)略，推動(dòng)大數(shù)據(jù)產(chǎn)業(yè)交流與合作，展示我國大數(shù)據(jù)產(chǎn)業(yè)最新發(fā)展成果，2019年6月4日至5日，由中國信息通信研究院、中國通信標(biāo)準(zhǔn)化協(xié)會(huì)主辦，大數(shù)據(jù)技術(shù)標(biāo)準(zhǔn)推進(jìn)委員會(huì)承辦的2019大數(shù)據(jù)產(chǎn)業(yè)峰會(huì)在北京國際會(huì)議中心隆重舉辦。

會(huì)上，來自工業(yè)和信息化部的領(lǐng)導(dǎo)，我國眾多優(yōu)秀大數(shù)據(jù)領(lǐng)域服務(wù)商、行業(yè)應(yīng)用客戶、研究機(jī)構(gòu)、地方大數(shù)據(jù)主管機(jī)構(gòu)的領(lǐng)導(dǎo)和專家，將對(duì)大數(shù)據(jù)政策、產(chǎn)業(yè)、技術(shù)的現(xiàn)狀與趨勢(shì)等內(nèi)容進(jìn)行交流探討。

6月5日，在大數(shù)據(jù)前沿技術(shù)分論壇上，阿里云實(shí)時(shí)計(jì)算產(chǎn)品經(jīng)理郭華為我們帶來了《從Flink看大數(shù)據(jù)實(shí)時(shí)變化》的精彩演講。

阿里云實(shí)時(shí)計(jì)算產(chǎn)品經(jīng)理郭華

大家好，非常高興來到這邊，我來自阿里云的郭華，今天的題目是《從Flink看大數(shù)據(jù)實(shí)時(shí)化》。

講到Flink或者大數(shù)據(jù)實(shí)時(shí)化一般講到的是流處理系統(tǒng)，今天的主題圍繞這三個(gè)方面進(jìn)行展開：流處理概述、流處理一般應(yīng)用架構(gòu)、流處理應(yīng)用場(chǎng)景。

首先從實(shí)時(shí)性、易用性方面看一下開源大數(shù)據(jù)引擎這十幾年的簡(jiǎn)單歷史，我們都知道開源大數(shù)據(jù)引擎實(shí)際上理論上起源于04年谷歌發(fā)表的那篇MapReduce的論文，06年的Hadoop基本上完整實(shí)現(xiàn)了論文里描述的當(dāng)時(shí)的系統(tǒng)叫做MapReduce，但是MapReduce在實(shí)時(shí)性、易用性上都有問題，實(shí)時(shí)中把大量中間數(shù)據(jù)放到硬盤中去導(dǎo)致雖然具備大批量的數(shù)據(jù)處理能力，但是它的數(shù)據(jù)是比較慢的。另外在易用性方面，只提供了MapReduce，這意味著都必須拆解成Map和、Reduce兩個(gè)階段，這意味著一系列的都需要MapReduce串聯(lián)起來進(jìn)行調(diào)度非常的繁瑣。08年facebook啟動(dòng)了一個(gè)ladoop項(xiàng)目，大家知道SQL是一個(gè)使用門檻非常低的語言，把SQL提交給hive，其實(shí)hive是大大降低了MapReduce的應(yīng)用門檻，所以Hadoop和hive還是標(biāo)準(zhǔn)化的解決方案。05年Spark出現(xiàn)了，在實(shí)時(shí)性、易用性上都有改變。從實(shí)時(shí)性上講，這是Spark最大的亮點(diǎn)，設(shè)置了基于內(nèi)存中間數(shù)據(jù)，通過這種形式大大加速了批處理內(nèi)容，從易用性方面提供了RDD的數(shù)據(jù)抽象，在此基礎(chǔ)上提供了非常多的算子，還有了更高的表達(dá)靈活度。但是Spark雖然說加速了MapReduce的計(jì)算過程，但還不是大數(shù)據(jù)實(shí)時(shí)化的系統(tǒng)，真正的流處理是11年研究的。當(dāng)時(shí)它的作者經(jīng)常處理來自消息隊(duì)列的數(shù)據(jù)，這時(shí)候他想既然數(shù)據(jù)是一條條過來的，為什么計(jì)算不能一條條處理？在這種思路影響下開發(fā)了Storm引擎。Storm也比較成功但是還是初級(jí)的引擎，14年的Flink是比Storm成熟的。Storm可以做到至少處理一次，而Flink能夠做到確保只處理一次，同時(shí)是沒有中間階段的，Flink是有自己的中間狀態(tài)存儲(chǔ)的，所以直接可以在里面進(jìn)行統(tǒng)計(jì)。另外Flink在這個(gè)基礎(chǔ)上又提供了更高級(jí)別的窗口以及更高層次的API、SQL等等，另外Flink除了流處理之外還在流處理基礎(chǔ)上又封裝了一層批處理引擎，所以我們說Flink叫下一代的大數(shù)據(jù)引擎，是因?yàn)樗暾木邆淞肆骱团奶幚砟芰Α?/p>

從這個(gè)版本里面來看，開源大數(shù)據(jù)的計(jì)算引擎主要通過實(shí)時(shí)性和易用性兩個(gè)方面演進(jìn)的，免備案主機(jī)，實(shí)時(shí)性從最開始基于硬盤的批處理、基于內(nèi)存的批處理、實(shí)時(shí)的流處理，易用性上從MapReduce到RDD到bolt到了SQL，這是一個(gè)簡(jiǎn)單的歷史。

剛才說Storm那種起訴的批處理不是實(shí)時(shí)化，流處理才是。什么是實(shí)時(shí)化？是一個(gè)事件從發(fā)生到把結(jié)果發(fā)出去的延遲，從這個(gè)結(jié)果來看批處理，假設(shè)有一堆數(shù)據(jù)，這時(shí)候有個(gè)需求開發(fā)了一個(gè)作業(yè)，這個(gè)作業(yè)提交之后把那些數(shù)據(jù)都讀過來進(jìn)行處理，處理完之后把結(jié)果發(fā)出去，所以在這種情況下它的延遲是比較高的。具體體現(xiàn)在兩個(gè)方面：第一，它是由計(jì)算驅(qū)動(dòng)的，而計(jì)算往往是由調(diào)度器發(fā)起的，調(diào)度器和事件發(fā)生本身是沒有直接關(guān)系的；另外，它每次處理是個(gè)全量的處理，把所有數(shù)據(jù)都撈進(jìn)來進(jìn)行計(jì)算，計(jì)算本身也是比較耗時(shí)的。這兩種計(jì)算影響下延遲是比較高的，基本上是小時(shí)級(jí)別的延遲。

再看一下流處理，流處理整個(gè)模型是不一樣的，流處理里面數(shù)據(jù)是沒有終結(jié)數(shù)概念的，會(huì)假設(shè)數(shù)據(jù)源源不斷流進(jìn)來。寫個(gè)作業(yè)提交以后，作業(yè)也不會(huì)停止。同樣從那兩個(gè)角度來看，首先是由事件驅(qū)動(dòng)的，只要有事件觸發(fā)計(jì)算就會(huì)自動(dòng)進(jìn)行，這個(gè)延遲比較低；另一個(gè)它是一個(gè)增量的計(jì)算，意味著每次只處理一小部分?jǐn)?shù)據(jù)，計(jì)算過程本身也比較難。綜合這兩方面，流處理能夠做到秒級(jí)亞秒級(jí)的延遲，所以叫做大數(shù)據(jù)實(shí)時(shí)化的引擎。

流處理一般的應(yīng)用架構(gòu)，如圖是個(gè)非常抽象的應(yīng)用架構(gòu)，有兩個(gè)關(guān)鍵點(diǎn)：

1、消息隊(duì)列；

2、流計(jì)算數(shù)據(jù)。