[[182474]]

本文由InfoQ中文站社區(qū)編輯足下編譯并分享

“神說，要有光，就有了光”。——《圣經》

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

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

痛定思痛，谷歌開始走開源之路，將自己的標準推廣給社區(qū)。從眾所周知的Kubernetes，到2016年2月谷歌高調宣布將Apache Beam(原名Google DataFlow)貢獻給Apache基金會孵化，再到最近大熱的Tensorflow等等，動作不斷。Apache Beam被認為是繼MapReduce，GFS和BigQuery等之后，谷歌在大數據處理領域對開源社區(qū)的又一個非常大的貢獻。

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

為什么要推出開源的Apache Beam?

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

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

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

• 盡管在過去谷歌一直是閉源的，但在為云客戶服務的過程中，谷歌已經認識到了開源軟件的的巨大價值，比如基于谷歌三篇論文產生的Hadoop社區(qū)就是一個非常好的例子。思想上的轉變使Apache Beam的誕生成為可能;
• 就Beam這個項目而言，要成功的必要條件之一是，必須有已經開源的Runner為Beam模型提供充分的支持，這樣它才會在自建云和非谷歌云的場景下成為一個非常有競爭力的備選方案。去年Apache Flink在他們的系統(tǒng)內采用了Beam模型，這一條件也得到了滿足;

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

• 支持Apache Beam的Runner越多，它作為一個平臺的吸引力就越大;
• 使用Apache Beam的用戶越多，想在谷歌云平臺上運行Apache Beam的用戶也就越多;
• 開發(fā)Apache Beam過程中吸引到的伙伴越多，那對這樣的數據處理模型的推廣就越有利;

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

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

Apache Beam是什么?

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

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

• 統(tǒng)一的：對于批處理和流式處理，使用單一的編程模型;
• 可移植的：可以支持多種執(zhí)行環(huán)境，包括Apache Apex、Apache Flink、Apache Spark和谷歌Cloud Dataflow等;
• 可擴展的：可以實現和分享更多的新SDK、IO連接器、轉換操作庫等;

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

Beam主要包含兩個關鍵的部分：

• Beam SDK

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

• Beam Pipeline Runner

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

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

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

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

• 數據處理：直接使用已有的自己熟悉語言的SDK，根據Beam模型去定義并實現自己的數據處理流程;
• SDK實現：用新的編程語言去根據Beam概念實現SDK，這樣大家以后在編程語言方面就可以有更多選擇了;
• Runner實現：將已有的分布式數據處理平臺作為一種新的Runner，接入Beam模型;

Beam是怎么做的?

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

1. 數據。分布式數據處理要處理的數據類型一般可以分為兩類，有限的數據集和***的數據流。有限的數據集，比如一個HDFS中的文件，一個HBase表等，特點是數據提前已經存在，一般也已經持久化，不會突然消失，不會再改變。而***的數據流，比如kafka中流過來的系統(tǒng)日志流，或是從Twitter API拿到的Twitter流等等，這類數據的特點是，數據動態(tài)流入，無窮無盡，無法全部持久化。一般來說，批處理框架的設計目標是用來處理有限的數據集，流處理框架的設計目標是用來處理***的數據流。有限的數據集可以看做是***的數據流的一種特例，但是從數據處理邏輯的角度，這兩者并無不同之處。
2. 時間。Process Time是指數據進入分布式處理框架的時間，而Event-Time則是指數據產生的時間。這兩個時間通常是不同的，例如，對于一個處理微博數據的流計算任務，一條2016-06-01-12:00:00發(fā)表的微博經過網絡傳輸等延遲可能在2016-06-01-12:01:30才進入到流處理系統(tǒng)中。批處理任務通常進行全量的數據計算，較少關注數據的時間屬性，但是對于流處理任務來說，由于數據流是無情無盡的，無法進行全量的計算，通常是對某個窗口中得數據進行計算，對于大部分的流處理任務來說，按照時間進行窗口劃分，可能是最常見的需求。
3. 亂序。對于流處理框架處理的數據流來說，其數據的到達順序可能并不嚴格按照Event-Time的時間順序。如果基于Process Time定義時間窗口，數據到達的順序就是數據的順序，因此不存在亂序問題。但是對于基于Event Time定義的時間窗口來說，可能存在時間靠前的消息在時間靠后的消息之后到達的情況，這在分布式的數據源中可能非常常見。對于這種情況，如何確定遲到數據，以及對于遲到數據如何處理通常是很棘手的問題。

Beam模型處理的目標數據是***的時間亂序數據流，不考慮時間順序或是有限的數據集可看做是***亂序數據流的一個特例。 

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

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

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

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

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

D：How do refinements relate，遲到數據如何處理?例如，將遲到數據計算增量結果輸出，或是將遲到數據計算結果和窗口內數據計算結果合并成全量結果輸出。在Beam SDK中由Accumulation指定。 

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

友商的看法

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

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

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

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

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

我們堅信Beam模型是進行數據流處理和批處理的***編程模型。我們鼓勵用戶們在實現新程序時采用這個模型，用Beam API或者Flink DataStream API都行。”

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

結論

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

QCon北京2017將于4月16日~18日在北京·國家會議中心舉行，精心設計了互聯網廣告系統(tǒng)實踐、大數據實時計算與流處理和金融科技轉型與未來等30來個專題，將邀請來自Google、Facebook、阿里巴巴、騰訊、百度、美團點評、愛奇藝等典型互聯網公司的技術專家，分享技術領域***成果。