Apache Beam 歷史發(fā)展，10分鐘了解ApacheBeam

在2003年之前，谷歌內(nèi)部還沒(méi)有一個(gè)成熟的處理框架來(lái)處理大規(guī)模數(shù)據(jù)。當(dāng)時(shí)，谷歌的搜索業(yè)務(wù)迫使工程師們面對(duì)處理大規(guī)模數(shù)據(jù)的應(yīng)用場(chǎng)景，比如計(jì)算網(wǎng)站url訪問(wèn)量和計(jì)算網(wǎng)頁(yè)倒排索引等等。

那該怎么辦呢?這個(gè)答案既簡(jiǎn)單又復(fù)雜：自己寫(xiě)一個(gè)。

沒(méi)錯(cuò)，當(dāng)時(shí)的工程師需要編寫(xiě)一個(gè)定制的邏輯處理架構(gòu)來(lái)處理數(shù)據(jù)。由于需要處理的數(shù)據(jù)量非常大，業(yè)務(wù)邏輯不太可能只在一臺(tái)機(jī)器上運(yùn)行。在許多情況下，我們必須在分布式環(huán)境中部署業(yè)務(wù)邏輯。因此，這種定制的邏輯處理架構(gòu)還必須包括容錯(cuò)系統(tǒng)的設(shè)計(jì)。隨著時(shí)間的推移，一組邏輯處理架構(gòu)將在谷歌內(nèi)部的不同組之間開(kāi)發(fā)。由于工程師遇到的許多問(wèn)題是相似的，因此開(kāi)發(fā)的邏輯處理體系結(jié)構(gòu)往往是相似的，但在數(shù)據(jù)處理方面存在一些邏輯上的差異。毫無(wú)疑問(wèn)，這已經(jīng)成為一種大家一起重新創(chuàng)造輪子的局面。

這時(shí)候，就有工程師想到，能不能改善這一種狀況。MapReduce的架構(gòu)思想也就由此應(yīng)運(yùn)而生。其實(shí)MapReduce的架構(gòu)思想可以從兩個(gè)方面來(lái)看。一方面，它希望能提供一套簡(jiǎn)潔的API來(lái)表達(dá)工程師數(shù)據(jù)處理的邏輯。另一方面，要在這一套API底層嵌套一套擴(kuò)展性很強(qiáng)的容錯(cuò)系統(tǒng)，使得工程師能夠?qū)⑿乃挤旁谶壿嬏幚砩?，而不用過(guò)于分心去設(shè)計(jì)分布式的容錯(cuò)系統(tǒng)。這個(gè)架構(gòu)思想的結(jié)果你早就已經(jīng)知道了。MapReduce這一套系統(tǒng)在Google獲得了巨大成功。在2004年的時(shí)候，Google發(fā)布的一篇名為“MapReduce: Simplified Data Processing on Large Clusters”的論文就是這份成果的總結(jié)。

在MapReduce的計(jì)算模型里，它將數(shù)據(jù)的處理抽象成了以下這樣的計(jì)算步驟Map：計(jì)算模型從輸入源(Input Source)中讀取數(shù)據(jù)集合，這些數(shù)據(jù)在經(jīng)過(guò)了用戶(hù)所寫(xiě)的邏輯后生成出一個(gè)臨時(shí)的鍵值對(duì)數(shù)據(jù)集(Key/Value Set)。MapReduce計(jì)算模型會(huì)將擁有相同鍵(Key)的數(shù)據(jù)集集中起來(lái)然后發(fā)送到下一階段。這一步也被稱(chēng)為Shuffle階段。

很多人都說(shuō)，這篇MapReduce論文是具有劃時(shí)代意義的?？赡阒罏槭裁炊歼@么說(shuō)嗎?這是因?yàn)镸ap和Reduce這兩種抽象其實(shí)可以適用于非常多的應(yīng)用場(chǎng)景，而MapReduce論文里面所闡述的容錯(cuò)系統(tǒng)，可以讓我們所寫(xiě)出來(lái)的數(shù)據(jù)處理邏輯在分布式環(huán)境下有著很好的可擴(kuò)展性(Scalability)。

MapReduce在內(nèi)部的成功使得越來(lái)越多的工程師希望使用MapReduce來(lái)解決自己項(xiàng)目的難題。但是，就如我在模塊一中所說(shuō)的那樣，使用MapReduce來(lái)解決一個(gè)工程難題往往會(huì)涉及到非常多的步驟，而每次使用MapReduce的時(shí)候我們都需要在分布式環(huán)境中啟動(dòng)機(jī)器來(lái)完成Map和Reduce步驟，以及啟動(dòng)Master機(jī)器來(lái)協(xié)調(diào)這兩個(gè)步驟的中間結(jié)果(Intermediate Result)，消耗不少硬件上的資源。這樣就給工程師們帶來(lái)了以下一些疑問(wèn)：?jiǎn)栴}既然已經(jīng)提出來(lái)了，Google的工程師們便開(kāi)始考慮是否能夠解決上述這些問(wèn)題。最好能夠讓工程師(無(wú)論是新手工程師亦或是經(jīng)驗(yàn)老到的工程師)都能專(zhuān)注于數(shù)據(jù)邏輯上的處理，而不用花更多時(shí)間在測(cè)試調(diào)優(yōu)上。FlumeJava就是在這樣的背景下誕生的。

這里，我先將FlumeJava的成果告訴你。因?yàn)镕lumeJava的思想又在Google內(nèi)容獲得了巨大成功，Google也希望將這個(gè)思想分享給業(yè)界。所以在2010年的時(shí)候，Google公開(kāi)了FlumeJava架構(gòu)思想的論文。FlumeJava的思想是將所有的數(shù)據(jù)都抽象成名為PCollection的數(shù)據(jù)結(jié)構(gòu)，無(wú)論是從內(nèi)存中讀取的數(shù)據(jù)，還是Reduce：接收從Shuffle階段發(fā)送過(guò)來(lái)的數(shù)據(jù)集，在經(jīng)過(guò)了用戶(hù)所寫(xiě)的邏輯后生成出零個(gè)或多個(gè)結(jié)果。我們的項(xiàng)目數(shù)據(jù)規(guī)模是否真的需要運(yùn)用MapReduce來(lái)解決呢?是否可以在一臺(tái)機(jī)器上的內(nèi)存中解決呢?我們所寫(xiě)的MapReduce項(xiàng)目是否已經(jīng)是最優(yōu)的呢?因?yàn)槊恳粋€(gè)Map和Reduce步驟這些中間結(jié)果都需要寫(xiě)在磁盤(pán)上，會(huì)十分耗時(shí)。是否有些步驟可以省略或者合并呢?我們是否需要讓工程師投入時(shí)間去手動(dòng)調(diào)試這些MapReduce項(xiàng)目的性能呢?

在分布式環(huán)境下所讀取的文件。這樣的抽象對(duì)于測(cè)試代碼中的邏輯是十分有好處的。要知道，想測(cè)試MapReduce的話，你可能需要讀取測(cè)試數(shù)據(jù)集，然后在分布式環(huán)境下運(yùn)行，來(lái)測(cè)試代碼邏輯。但如果你有了PCollection這一層抽象的話，你的測(cè)試代碼可以在內(nèi)存中讀取數(shù)據(jù)然后跑測(cè)試文件，也就是同樣的邏輯既可以在分布式環(huán)境下運(yùn)行也可以在單機(jī)內(nèi)存中運(yùn)行。

而FlumeJava在MapReduce框架中Map和Reduce思想上，抽象出4個(gè)了原始操作(Primitive Operation)，分別是parallelDo、groupByKey、 combineValues和flatten，讓工程師可以利用這4種原始操作來(lái)表達(dá)任意Map或者Reduce的邏輯。同時(shí)，F(xiàn)lumeJava的架構(gòu)運(yùn)用了一種Deferred Evaluation的技術(shù)，來(lái)優(yōu)化我們所寫(xiě)的代碼。對(duì)于Deferred Evaluation，你可以理解為FlumeJava框架會(huì)首先會(huì)將我們所寫(xiě)的邏輯代碼靜態(tài)遍歷一次，然后構(gòu)造出一個(gè)執(zhí)行計(jì)劃的有向無(wú)環(huán)圖。這在FlumeJava框架里被稱(chēng)為Execution Plan Dataflow Graph。有了這個(gè)圖之后，F(xiàn)lumeJava框架就會(huì)自動(dòng)幫我們優(yōu)化代碼。例如，合并一些本來(lái)可以通過(guò)一個(gè)Map和Reduce來(lái)表達(dá)，卻被新手工程師分成多個(gè)Map和Reduce的代碼。

FlumeJava框架還可以通過(guò)我們的輸入數(shù)據(jù)集規(guī)模，來(lái)預(yù)測(cè)輸出結(jié)果的規(guī)模，從而自行決定代碼是放在內(nèi)存中跑還是在分布式環(huán)境中跑。

總的來(lái)說(shuō)，F(xiàn)lumeJava是非常成功的。但是，F(xiàn)lumeJava也有一個(gè)弊端，那就是FlumeJava基本上只支持批處理(Batch Execution)的任務(wù)，對(duì)于無(wú)邊界數(shù)據(jù)(Unbounded Data)是不支持的。所以，Google內(nèi)部有著另外一個(gè)被稱(chēng)為Millwheel的項(xiàng)目來(lái)支持處理無(wú)邊界數(shù)據(jù)，也就是流處理框架。

在2013年的時(shí)候，Google也公開(kāi)了Millwheel思想的論文。這時(shí)Google的工程師們回過(guò)頭看，感嘆了一下成果，并覺(jué)得自己可以再優(yōu)秀一些：既然我們已經(jīng)創(chuàng)造出好幾個(gè)優(yōu)秀的大規(guī)模數(shù)據(jù)處理框架了，那我們能不能集合這幾個(gè)框架的優(yōu)點(diǎn)，推出一個(gè)統(tǒng)一的框架呢?這也成為了Dataflow Model誕生的契機(jī)。

在2015年時(shí)候，Google公布了Dataflow Model的論文，同時(shí)也推出了基于Dataflow Model思想的平臺(tái)Cloud Dataflow，讓Google以外的工程師們也能夠利用這些SDK來(lái)編寫(xiě)大規(guī)模數(shù)據(jù)處理的邏輯。講到這么多，你可能會(huì)有個(gè)疑問(wèn)了，怎么Apache Beam還沒(méi)有出場(chǎng)呢?別著急，Apache Beam的登場(chǎng)契機(jī)馬上就到了。

前面我說(shuō)了，Google基于Dataflow Model的思想推出了Cloud Dataflow云平臺(tái)，但那畢竟也需要工程師在Google的云平臺(tái)上面運(yùn)行程序才可以。如果有的工程師希望在別的平臺(tái)上面跑該如何解決呢?

所以，為了解決這個(gè)問(wèn)題，Google在2016年的時(shí)候聯(lián)合了Talend、Data Artisans、Cloudera這些大數(shù)據(jù)公司，基于Dataflow Model的思想開(kāi)發(fā)出了一套SDK，并貢獻(xiàn)給了Apache Software Foundation。而它Apache Beam的名字是怎么來(lái)的呢?Beam的含義就是統(tǒng)一了批處理和流處理的一個(gè)框架。

這就是Apache Beam的發(fā)展歷史，從中你可以看到它擁有很多優(yōu)點(diǎn)，而這也是我們需要Beam的原因。

在現(xiàn)實(shí)世界中，很多時(shí)候我們不可避免地需要對(duì)數(shù)據(jù)同時(shí)進(jìn)行批處理和流處理。Beam提供了一套統(tǒng)一的API來(lái)處理這兩種數(shù)據(jù)處理模式，讓我們只需要將注意力專(zhuān)注于在數(shù)據(jù)處理的算法上，而不用再花時(shí)間去對(duì)兩種數(shù)據(jù)處理模式上的差異進(jìn)行維護(hù)。它能夠?qū)⒐こ處煂?xiě)好的算法邏輯很好地與底層的運(yùn)行環(huán)境分隔開(kāi)。也就是說(shuō)，當(dāng)我們通過(guò)Beam提供的API寫(xiě)好數(shù)據(jù)處理邏輯后，這個(gè)邏輯可以不作任何修改，直接放到任何支持Beam API的底層系統(tǒng)上運(yùn)行。關(guān)于怎么理解這個(gè)優(yōu)點(diǎn)，其實(shí)我們可以借鑒一下SQL(Structure Query Language)的運(yùn)行模式。

我們?cè)趯W(xué)習(xí)SQL語(yǔ)言的時(shí)候，基本上都是獨(dú)立于底層數(shù)據(jù)庫(kù)系統(tǒng)來(lái)學(xué)習(xí)的。而在我們寫(xiě)完一個(gè)分析數(shù)據(jù)的Query之后，只要底層數(shù)據(jù)庫(kù)的Schema不變，這個(gè)Query是可以放在任何數(shù)據(jù)庫(kù)系統(tǒng)上運(yùn)行的，例如放在MySql上或者Oracle DB上。

同樣的，我們用Beam API寫(xiě)好的數(shù)據(jù)處理邏輯無(wú)需改變，可以根據(jù)自身的需求，將邏輯放在Google CloudDataflow上跑，也可以放在Apache Flink上跑。在Beam上，這些底層運(yùn)行的系統(tǒng)被稱(chēng)為Runner?，F(xiàn)階段Apache Beam支持的Runner有近十種，包括了我們很熟悉的Apache Spark和Apache Flink。

當(dāng)然，最后Apache Beam也希望自己編寫(xiě)的sdk能夠支持任意數(shù)量的語(yǔ)言。在這個(gè)階段，Beam持Java、Python和Golang。換句話說(shuō)，通過(guò)apache beam，我們最終可以使用我們自己的編程語(yǔ)言，通過(guò)一組beam模型統(tǒng)一的數(shù)據(jù)處理api，編寫(xiě)適合您的應(yīng)用程序場(chǎng)景的數(shù)據(jù)處理邏輯，并在您喜歡的運(yùn)行程序上運(yùn)行它。

推薦了解：
大數(shù)據(jù)培訓(xùn)課程