Beam 的第一個穩(wěn)定版本是 Beam 社區(qū)發(fā)布的第三個重要里程碑。Beam 在 2016 年 2 月成為 Apache 孵化器項目,，并在同年 12 月升級成為 Apache 基金會的頂級項目,。經(jīng)過從開始至今的 15 個月全神貫注的努力，從一個有點混亂的代碼庫開始,，從各大組織合并代碼,，成就了如今的這個數(shù)據(jù)處理框架，它是一個真正與引擎和環(huán)境無關(guān)的數(shù)據(jù)處理框架,。Beam 經(jīng)過三個孵化器版本和三個后孵化器版本的演化和改進(jìn),，最終迎來了它的第一個穩(wěn)定版 2.0.0。

在從升級為頂級項目至今的 5 個月時間里,，Beam 在采用率和社區(qū)貢獻(xiàn)兩個方面都取得了重大進(jìn)展,。Google Cloud、PayPal,、Talend 等公司都在使用 Beam,。

Beam 2.0.0 改進(jìn)了用戶體驗，專注于提升框架在各種執(zhí)行環(huán)境中的無縫移植能力,，這些執(zhí)行環(huán)境包括執(zhí)行引擎,、操作系統(tǒng)、本地集群、云端,，以及數(shù)據(jù)存儲系統(tǒng)。Beam 的其他特性還包括如下幾點,。

API 穩(wěn)定性和對未來版本的兼容性,。有狀態(tài)的數(shù)據(jù)處理范式，支持高效的依賴數(shù)據(jù)的計算,。支持用戶擴展的文件系統(tǒng),，內(nèi)建支持 Hadoop 分布式發(fā)文件系統(tǒng)及其他。提供了一個度量指標(biāo)系統(tǒng),，可用于深入窺見管道的執(zhí)行情況,。很多貢獻(xiàn)者促成了這個穩(wěn)定版本的發(fā)布，他們承擔(dān)了各種角色的任務(wù)：貢獻(xiàn)代碼,、編寫文檔、測試候選版本、為用戶提供支持,，等等,。

Beam 2.0.0 將會在這周于邁阿密舉行的“Apache：大數(shù)據(jù)”大會上首次亮相，會上將會有四個與 Beam 相關(guān)的主題,。Beam 也將會成為很多開發(fā)者見面會的主角,，包括“圣何塞數(shù)據(jù)的未來”見面會、“倫敦斯特拉塔數(shù)據(jù)大會”,、“柏林 Buzzwords”,，以及“圣何塞 DataWorks 峰會”。

開發(fā)者從今天開始就可以試用 Beam,，也可以考慮加入 Beam 社區(qū),，或者可以通過 Beam 的郵件組、問題跟蹤系統(tǒng)向社區(qū)提供反饋意見和問題,。

Apache Beam 的前世今生 

1月10日，Apache軟件基金會宣布,，Apache Beam成功孵化,，成為該基金會的一個新的頂級項目，基于Apache V2許可證開源,。

2003年,，谷歌發(fā)布了著名的大數(shù)據(jù)三篇論文，史稱三駕馬車：Google FS,、MapReduce,、BigTable。雖然谷歌沒有公布這三個產(chǎn)品的源碼，但是她這三個產(chǎn)品的詳細(xì)設(shè)計論文開啟了全球的大數(shù)據(jù)時代,！從Doug Cutting大神根據(jù)谷歌的論文實現(xiàn)出Hadoop+MapReduce的雛形,，到Hadoop生態(tài)圈各種衍生產(chǎn)品的蓬勃發(fā)展，再到后來的Spark,、流式計算等等,，所有的一切都要歸功于、源自這三篇論文,?？上Ч雀桦m然開啟了這個偉大的時代，卻始終僅僅滿足于偶爾發(fā)表一兩篇論文以強調(diào)自己在理論和工程上的領(lǐng)導(dǎo)地位,，從來沒有親身參與進(jìn)來,，尤其是沒有為開源生態(tài)做出什么貢獻(xiàn)，因而一直沒有從大數(shù)據(jù)市場獲得什么實在的好處,。

痛定思痛,，谷歌開始走開源之路，將自己的標(biāo)準(zhǔn)推廣給社區(qū),。從眾所周知的Kubernetes,，到2016年2月谷歌高調(diào)宣布將Apache Beam（原名Google DataFlow）貢獻(xiàn)給Apache基金會孵化，再到最近大熱的Tensorflow等等,，動作不斷,。Apache Beam被認(rèn)為是繼MapReduce，GFS和BigQuery等之后,，谷歌在大數(shù)據(jù)處理領(lǐng)域?qū)﹂_源社區(qū)的又一個非常大的貢獻(xiàn),。

也就是說，在大數(shù)據(jù)處理的世界里,，谷歌一直在內(nèi)部閉源,，開發(fā)并使用著BigTable、Spanner,、Millwheel等讓大家久聞大名而又無緣一見的產(chǎn)品,，開源世界演進(jìn)出了Hadoop、Spark,、Apache Flink等產(chǎn)品,，現(xiàn)在他們終于殊途同歸，走到一起來了,。

Apache Beam的主要負(fù)責(zé)人Tyler Akidau在他的博客中提到他們做這件事的理念是：

要為這個世界貢獻(xiàn)一個容易使用而又強大的模型，用于大數(shù)據(jù)的并行處理,，同時適用于流式處理和批量處理,，而且在各種不同平臺上還可以移植,。

那這一次為什么不是又酷酷的發(fā)表一篇論文，然后退居一旁靜靜的觀察呢,？為什么要聯(lián)合一眾伙伴為大家直接提供可以運行的代碼了呢,？原因主要有兩點：

• 盡管在過去谷歌一直是閉源的，但在為云客戶服務(wù)的過程中,，谷歌已經(jīng)認(rèn)識到了開源軟件的的巨大價值,，比如基于谷歌三篇論文產(chǎn)生的Hadoop社區(qū)就是一個非常好的例子。思想上的轉(zhuǎn)變使Apache Beam的誕生成為可能,；

• 就Beam這個項目而言，要成功的必要條件之一是,，必須有已經(jīng)開源的Runner為Beam模型提供充分的支持,，這樣它才會在自建云和非谷歌云的場景下成為一個非常有競爭力的備選方案。去年Apache Flink在他們的系統(tǒng)內(nèi)采用了Beam模型,，這一條件也得到了滿足,；

無利不起早，谷歌這樣做也是有著直接商業(yè)動機的,，就是希望能有盡可能多的Apache Beam數(shù)據(jù)處理流水線可以運行在谷歌的Cloud Dataflow上,，別忘了這是Apache Beam的原型。進(jìn)一步說,，采用開源的方式來引導(dǎo)這件事,，也是有許多直接好處的：

• 支持Apache Beam的Runner越多，它作為一個平臺的吸引力就越大,；

• 使用Apache Beam的用戶越多,，想在谷歌云平臺上運行Apache Beam的用戶也就越多；

• 開發(fā)Apache Beam過程中吸引到的伙伴越多,，那對這樣的數(shù)據(jù)處理模型的推廣就越有利,；

而且，好處也不會全都?xì)w于谷歌,，Apache Beam項目中的所有參與方都會受益,。如果在構(gòu)建數(shù)據(jù)處理流水線時存在著這樣一個可移植的抽象層，那就會更容易出現(xiàn)新的Runner,，它們可以專注于技術(shù)創(chuàng)新,，提供更高的性能、更好的可靠性,、更方便的運維管理等,。換句話說，消除了對API的鎖定,，就解放了處理引擎,，會導(dǎo)致更多產(chǎn)品之間的競爭,，從而最終對整個行業(yè)起到良性的促進(jìn)作用。

谷歌堅信Apache Beam就是數(shù)據(jù)批量處理和流式處理的未來,。這么做會為各種不同的Runner營造一個健康的生態(tài)系統(tǒng),，讓它們之間相互競爭，而最后可以讓用戶得到實在的好處,。

要說Apache Beam，先要說說谷歌Cloud Dataflow,。Dataflow是一種原生的谷歌云數(shù)據(jù)處理服務(wù),，是一種構(gòu)建、管理和優(yōu)化復(fù)雜數(shù)據(jù)流水線的方法,，用于構(gòu)建移動應(yīng)用,、調(diào)試、追蹤和監(jiān)控產(chǎn)品級云應(yīng)用,。它采用了谷歌內(nèi)部的技術(shù)Flume和MillWhell,，其中Flume用于數(shù)據(jù)的高效并行化處理，而MillWhell則用于互聯(lián)網(wǎng)級別的帶有很好容錯機制的流處理,。該技術(shù)提供了簡單的編程模型,，可用于批處理和流式數(shù)據(jù)的處理任務(wù)。她提供的數(shù)據(jù)流管理服務(wù)可控制數(shù)據(jù)處理作業(yè)的執(zhí)行,，數(shù)據(jù)處理作業(yè)可使用DataFlow SDK創(chuàng)建,。

Apache Beam本身不是一個流式處理平臺，而是一個統(tǒng)一的編程框架,，它提供了開源的,、統(tǒng)一的編程模型，幫助你創(chuàng)建自己的數(shù)據(jù)處理流水線,，實現(xiàn)可以運行在任意執(zhí)行引擎之上批處理和流式處理任務(wù),。Beam對流式計算場景中的所有問題重新做了一次歸納，然后針對這些問題提出了幾種不同的解決模型,，然后再把這些模型通過一種統(tǒng)一的語言給實現(xiàn)出來,，最終這些Beam程序可以運行在任何一個計算平臺上（只要相應(yīng)平臺——即Runner實現(xiàn)了對Beam的支持）。它的特點有：

• 統(tǒng)一的：對于批處理和流式處理,，使用單一的編程模型,；

• 可移植的：可以支持多種執(zhí)行環(huán)境，包括Apache Apex,、Apache Flink,、Apache Spark和谷歌Cloud Dataflow等；

• 可擴展的：可以實現(xiàn)和分享更多的新SDK,、IO連接器,、轉(zhuǎn)換操作庫等,；

Beam特別適合應(yīng)用于并行數(shù)據(jù)處理任務(wù)，只要可以將要處理的數(shù)據(jù)集分解成許多相互獨立而又可以并行處理的小集合就可以了,。Beam也可以用于ETL任務(wù),，或者單純的數(shù)據(jù)整合。這些任務(wù)主要就是把數(shù)據(jù)在不同的存儲介質(zhì)或者數(shù)據(jù)倉庫之間移動,，將數(shù)據(jù)轉(zhuǎn)換成希望的格式,，或者將數(shù)據(jù)導(dǎo)入一個新系統(tǒng)。

Beam主要包含兩個關(guān)鍵的部分：

• Beam SDK

Beam SDK提供一個統(tǒng)一的編程接口給到上層應(yīng)用的開發(fā)者,，開發(fā)者不需要了解底層的具體的大數(shù)據(jù)平臺的開發(fā)接口是什么,，直接通過Beam SDK的接口，就可以開發(fā)數(shù)據(jù)處理的加工流程,，不管輸入是用于批處理的有限數(shù)據(jù)集,，還是流式的無限數(shù)據(jù)集。對于有限或無限的輸入數(shù)據(jù),，Beam SDK都使用相同的類來表現(xiàn)，并且使用相同的轉(zhuǎn)換操作進(jìn)行處理,。Beam SDK可以有不同編程語言的實現(xiàn),，目前已經(jīng)完整地提供了Java，python的SDK還在開發(fā)過程中,，相信未來會有更多不同的語言的SDK會發(fā)布出來,。

• Beam Pipeline Runner

Beam Pipeline Runner將用戶用Beam模型定義開發(fā)的處理流程翻譯成底層的分布式數(shù)據(jù)處理平臺支持的運行時環(huán)境。在運行Beam程序時,，需要指明底層的正確Runner類型,。針對不同的大數(shù)據(jù)平臺，會有不同的Runner,。目前Flink,、Spark、Apex以及谷歌的Cloud DataFlow都有支持Beam的Runner,。

需要注意的是,，雖然Apache Beam社區(qū)非常希望所有的Beam執(zhí)行引擎都能夠支持Beam SDK定義的功能全集，但是在實際實現(xiàn)中可能并不一定,。例如,，基于MapReduce的Runner顯然很難實現(xiàn)和流處理相關(guān)的功能特性。就目前狀態(tài)而言,，對Beam模型支持最好的就是運行于谷歌云平臺之上的Cloud Dataflow,，以及可以用于自建或部署在非谷歌云之上的Apache Flink。當(dāng)然,，其它的Runner也正在迎頭趕上,，整個行業(yè)也在朝著支持Beam模型的方向發(fā)展,。

那大家可以怎樣與Beam做親密接觸呢？

如上圖所示,，主要有三個方面：

• 數(shù)據(jù)處理：直接使用已有的自己熟悉語言的SDK,，根據(jù)Beam模型去定義并實現(xiàn)自己的數(shù)據(jù)處理流程；

• SDK實現(xiàn)：用新的編程語言去根據(jù)Beam概念實現(xiàn)SDK,，這樣大家以后在編程語言方面就可以有更多選擇了,；

• Runner實現(xiàn)：將已有的分布式數(shù)據(jù)處理平臺作為一種新的Runner，接入Beam模型,；

在任何一個設(shè)計開始之前，都先要確定問題,，Beam也不例外,。

1. 數(shù)據(jù)。分布式數(shù)據(jù)處理要處理的數(shù)據(jù)類型一般可以分為兩類,，有限的數(shù)據(jù)集和無限的數(shù)據(jù)流,。有限的數(shù)據(jù)集，比如一個HDFS中的文件,，一個HBase表等,，特點是數(shù)據(jù)提前已經(jīng)存在，一般也已經(jīng)持久化,，不會突然消失,，不會再改變。而無限的數(shù)據(jù)流,，比如kafka中流過來的系統(tǒng)日志流,，或是從Twitter API拿到的Twitter流等等，這類數(shù)據(jù)的特點是,，數(shù)據(jù)動態(tài)流入,，無窮無盡，無法全部持久化,。一般來說,，批處理框架的設(shè)計目標(biāo)是用來處理有限的數(shù)據(jù)集，流處理框架的設(shè)計目標(biāo)是用來處理無限的數(shù)據(jù)流,。有限的數(shù)據(jù)集可以看做是無限的數(shù)據(jù)流的一種特例,，但是從數(shù)據(jù)處理邏輯的角度，這兩者并無不同之處,。

2. 時間,。Process Time是指數(shù)據(jù)進(jìn)入分布式處理框架的時間，而Event-Time則是指數(shù)據(jù)產(chǎn)生的時間,。這兩個時間通常是不同的,，例如,，對于一個處理微博數(shù)據(jù)的流計算任務(wù)，一條2016-06-01-12:00:00發(fā)表的微博經(jīng)過網(wǎng)絡(luò)傳輸?shù)妊舆t可能在2016-06-01-12:01:30才進(jìn)入到流處理系統(tǒng)中,。批處理任務(wù)通常進(jìn)行全量的數(shù)據(jù)計算,，較少關(guān)注數(shù)據(jù)的時間屬性，但是對于流處理任務(wù)來說,，由于數(shù)據(jù)流是無情無盡的,，無法進(jìn)行全量的計算，通常是對某個窗口中得數(shù)據(jù)進(jìn)行計算,，對于大部分的流處理任務(wù)來說,，按照時間進(jìn)行窗口劃分，可能是最常見的需求,。

3. 亂序,。對于流處理框架處理的數(shù)據(jù)流來說，其數(shù)據(jù)的到達(dá)順序可能并不嚴(yán)格按照Event-Time的時間順序,。如果基于Process Time定義時間窗口,，數(shù)據(jù)到達(dá)的順序就是數(shù)據(jù)的順序，因此不存在亂序問題,。但是對于基于Event Time定義的時間窗口來說,，可能存在時間靠前的消息在時間靠后的消息之后到達(dá)的情況，這在分布式的數(shù)據(jù)源中可能非常常見,。對于這種情況，如何確定遲到數(shù)據(jù),，以及對于遲到數(shù)據(jù)如何處理通常是很棘手的問題,。

Beam模型處理的目標(biāo)數(shù)據(jù)是無限的時間亂序數(shù)據(jù)流，不考慮時間順序或是有限的數(shù)據(jù)集可看做是無限亂序數(shù)據(jù)流的一個特例,。

如上圖,，其中虛線是最理想的，表示處理時間和事件時間是相同的,，紅線是實際上的線,，也叫水位線（Watermark），它一般是通過啟發(fā)式算法算出來的,。

接下來從問題中抽象出四個具體的問題：

A：What are you computing,，對數(shù)據(jù)的處理是哪種類型，數(shù)據(jù)轉(zhuǎn)換,、聚合或者是兩者都有,。例如，Sum,、Join或是機器學(xué)習(xí)中訓(xùn)練學(xué)習(xí)模型等,。在Beam SDK中由Pipeline中的操作符指定,。如圖：

B：Where in event time，數(shù)據(jù)在什么范圍中計算,？例如,，基于Process-Time的時間窗口？基于Event-Time的時間窗口,？滑動窗口等等,。在Beam SDK中由Pipeline中的窗口指定：

C：When in processing time，何時將計算結(jié)果輸出,？在這里引入了一個Trigger機制,，Trigger決定何時將計算結(jié)果發(fā)射出去，發(fā)射太早會丟失一部分?jǐn)?shù)據(jù),，喪失精確性,，發(fā)射太晚會導(dǎo)致延遲變長，而且會囤積大量數(shù)據(jù),，何時Trigger是由水位線來決定的,，在Beam SDK中由Pipeline中的水位線和觸發(fā)器指定。

D：How do refinements relate,，遲到數(shù)據(jù)如何處理,？例如，將遲到數(shù)據(jù)計算增量結(jié)果輸出,，或是將遲到數(shù)據(jù)計算結(jié)果和窗口內(nèi)數(shù)據(jù)計算結(jié)果合并成全量結(jié)果輸出,。在Beam SDK中由Accumulation指定。

Beam模型將”WWWH“四個維度抽象出來組成了Beam SDK,，用戶在基于Beam SDK構(gòu)建數(shù)據(jù)處理業(yè)務(wù)邏輯時,，每一步只需要根據(jù)業(yè)務(wù)需求按照這四個維度調(diào)用具體的API即可生成分布式數(shù)據(jù)處理Pipeline，并提交到具體執(zhí)行引擎上執(zhí)行,?！癢WWH”四個維度的抽象僅僅關(guān)注業(yè)務(wù)邏輯本身，和分布式任務(wù)如何執(zhí)行沒有任何關(guān)系,。

隨著分布式數(shù)據(jù)處理不斷發(fā)展,，新的分布式數(shù)據(jù)處理技術(shù)也不斷被提出，業(yè)界涌現(xiàn)出了越來越多的分布式數(shù)據(jù)處理框架,，從最早的Hadoop MapReduce,，到Apache Spark，Apache Storm,，以及更近的Apache Flink,，Apache Apex等。新的分布式處理框架可能帶來的更高的性能，更強大的功能,，更低的延遲等,，但用戶切換到新的分布式處理框架的代價也非常大：需要學(xué)習(xí)一個新的數(shù)據(jù)處理框架，并重寫所有的業(yè)務(wù)邏輯,。解決這個問題的思路包括兩個部分,，首先，需要一個編程范式,，能夠統(tǒng)一,，規(guī)范分布式數(shù)據(jù)處理的需求，例如,，統(tǒng)一批處理和流處理的需求,。其次，生成的分布式數(shù)據(jù)處理任務(wù)應(yīng)該能夠在各個分布式執(zhí)行引擎上執(zhí)行,，用戶可以自由切換分布式數(shù)據(jù)處理任務(wù)的執(zhí)行引擎與執(zhí)行環(huán)境,。Apache Beam正是為了解決以上問題而提出的。

如Apache Beam項目的主要推動者Tyler Akidau所說：

“為了讓Apache Beam能成功地完成移植,，我們需要至少有一個在部署自建云或非谷歌云時,，可以與谷歌Cloud Dataflow相比具備足夠競爭力的Runner。如Beam能力矩陣所示,，F(xiàn)link滿足我們的要求,。有了Flink，Beam已經(jīng)在業(yè)界內(nèi)成了一個真正有競爭力的平臺,?！?/p>

對此，Data Artisan的Kostas Tzoumas在他的博客中說：

“在谷歌將他們的Dataflow SDK和Runner捐獻(xiàn)給Apache孵化器成為Apache Beam項目時,，谷歌希望我們能幫忙完成Flink Runner,，并且成為新項目的代碼提交者和PMC成員。我們決定全力支持,，因為我們認(rèn)為：1,、對于流處理和批處理來說Beam模型都是未來的參考架構(gòu),；2,、Flink正是一個執(zhí)行這樣數(shù)據(jù)處理的平臺。在Beam成形之后,，現(xiàn)在Flink已經(jīng)成了谷歌云之外運行Beam程序的最佳平臺,。

我們堅信Beam模型是進(jìn)行數(shù)據(jù)流處理和批處理的最佳編程模型。我們鼓勵用戶們在實現(xiàn)新程序時采用這個模型,，用Beam API或者Flink DataStream API都行,。”

目前主流流數(shù)據(jù)處理框架Flink,、Spark,、Apex以及谷歌的Cloud DataFlow等都有了支持Beam的Runner,。

“在谷歌公司里已經(jīng)沒人再使用MapReduce了”！谷歌云的主要負(fù)責(zé)人Mete Atamel如是說,。谷歌堅信Apache Beam就是數(shù)據(jù)批處理和流處理的未來,。Apache Beam的模型對無限亂序數(shù)據(jù)流的數(shù)據(jù)處理進(jìn)行了非常優(yōu)雅的抽象，“WWWH”四個維度對數(shù)據(jù)處理的描述非常清晰與合理,，Beam模型在統(tǒng)一了對無限數(shù)據(jù)流和有限數(shù)據(jù)集的處理模式的同時,，也明確了對無限數(shù)據(jù)流的數(shù)據(jù)處理方式的編程范式，擴大了流處理系統(tǒng)可應(yīng)用的業(yè)務(wù)范圍,。隨著Apache Beam的成功孵化,，隨著越來越多的編程語言可用、越來越多的分布式數(shù)據(jù)處理平臺支持Beam模型,，我們的確可以盡情暢想美好的未來,。