Apache Beam是什么？

 

 

　　不多說，直接上干貨！

 

 

 

以下是Apache Beam的官網 ：

https://beam.apache.org/

 

 

 

 

 

 

 

Apache Beam的前世今生

      Apache Beam前身是Google Dataflow SDK，DataFlow是谷歌的提供大數據計算平台。在DataFlow之前，谷歌的批處理和流處理(流計算，實時處理)使用了不同系統，流處理有MillWheel、FlumeJava等，批處理有MapRedude，不同的平台使用了不同的Api，無疑提升了開發的難度，所以DataFlow橫空出世，提出了一套統一批處理和流處理的模型。

      Google在2016年2月貢獻給Apache基金會的Apache孵化項目，2017年2月從孵化器畢業，成為Apache Beam的頂級項目。

 　　

   　 　圖1　　 Apache Beam的進化歷程

 

 

 

 

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

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

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

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

　　　　　　　　　　　　　　

 

 

 

 

 

 

 

 

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

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

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

 

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

• 盡管在過去谷歌一直是閉源的，但在為雲客戶服務的過程中，谷歌已經認識到了開源軟件的的巨大價值，比如基於谷歌三篇論文產生的Hadoop社區就是一個非常好的例子。思想上的轉變使Apache Beam的誕生成為可能；

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

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

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

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

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

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

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

 

 

 

 

 

 

 

 

Apache Beam是什么？

      Apache Beam是大數據的編程模型，定義了數據處理的編程范式和接口，它並不涉及具體的執行引擎的實現，但是，基於Beam開發的數據處理程序可以執行在任意的分布式計算引擎上，目前Dataflow、Spark、Flink、Apex提供了對批處理和流處理的支持，GearPump提供了流處理的支持，Storm的支持也在開發中。

      綜上所述，Apache Beam的目標是提供統一批處理和流處理的編程范式，為無限、亂序、互聯網級別的數據集處理提供簡單靈活、功能豐富以及表達能力十分強大的SDK，目前支持Java和Python兩種SDK。

      如果類比一下的話，大數據領域的Apace Beam相當於Java，提供了跨語言、跨平台的大數據開發標准。 

　　　　　　　　　　　　　　　　

 　　

圖2         Apache Beam概念架構

 

　　我這里，給大家補充一個更完善的圖。

 

 

通過上圖，我們可以清楚的知道，執行一個流程分以下步驟：

1. End Users：選擇一種你熟悉的編程語言提交應用。
2. SDK Writers：該編程語言必須是 Beam 模型支持的。
3. Library Writers：轉換成Beam模型的格式。
4. Runner Writers：在分布式環境下處理並支持Beam的數據處理管道。
5. IO Providers：在Beam的數據處理管道上運行所有的應用。
6. DSL Writers：創建一個高階的數據處理管道。

 

 

 

 

 

 

 

　　

圖3      Apache Beam生態圈

 

 

  

 

　　美國時間 2017年1 月 10 日，Apache 軟件基金會對外宣布，萬眾期待的 Apache Beam 在經歷了近一年的孵化之后終於畢業。這一頂級 Apache 開源項目終熟。這是大數據處理領域的又一大里程碑事件——僅僅在上個月，騰訊宣布將在 2017 年一季度開源其大數據計算平台 Angel 。現在看來，生不逢時的 Angel 可能迎來它最大的對手。至此，谷歌終於也完成了對其雲端大數據平台 Cloud Dataflow 開源的承諾。

 

 

 

 

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

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

• 統一的：對於批處理和流式處理，使用單一的編程模型；

• 可移植的：可以支持多種執行環境，包括Apache Apex、Apache Flink、Apache Spark和谷歌Cloud Dataflow等；

• 可擴展的：可以實現和分享更多的新SDK、IO連接器、轉換操作庫等；

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

 

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

• Beam SDK

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

• Beam Pipeline Runner

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

　　需要注意的是，雖然Apache Beam社區非常希望所有的Beam執行引擎都能夠支持Beam SDK定義的功能全集，但是在實際實現中可能並不一定。例如，基於MapReduce的Runner顯然很難實現和流處理相關的功能特性。就目前狀態而言，對Beam模型支持最好的就是運行於谷歌雲平台之上的Cloud Dataflow，以及可以用於自建或部署在非谷歌雲之上的Apache Flink。當然，其它的Runner也正在迎頭趕上，整個行業也在朝着支持Beam模型的方向發展。

 

 

 

 

 

 

 

它針對什么問題提供了解決方案：

　　大數據處理領域的一大問題是：開發者經常要用到很多不同的技術、框架、API、開發語言和 SDK。雷鋒網(公眾號：雷鋒網)獲知，取決於需要完成的是什么任務，以及在什么情況下進行，開發者很可能會用 MapReduce 進行批處理，用 Apache Spark SQL 進行交互請求（ interactive queries），用 Apache Flink 實時流處理，還有可能用到基於雲端的機器學習框架。

　　近兩年開啟的開源大潮，為大數據開發者提供了十分富余的工具。但這同時也增加了開發者選擇合適的工具的難度，尤其對於新入行的開發者來說。這很可能拖慢、甚至阻礙開源工具的發展：把各種開源框架、工具、庫、平台人工整合到一起所需工作之復雜，是大數據開發者常有的抱怨之一，也是他們支持專有大數據平台的首要原因。

 

 

 

 

 

谷歌開源 Cloud Dataflow 背后的算盤是：

　　Apache Beam 的用戶基礎越大，就會有更多人用谷歌雲平台運它。相應地，他們會轉化為谷歌雲服務的客戶。騰訊開放 Angel 的動機與之類似。

 

 

 

 

背景

　　2016 年 2 月份，谷歌及其合作伙伴向 Apache 捐贈了一大批代碼，創立了孵化中的 Beam 項目（ 最初叫 Apache Dataflow）。這些代碼中的大部分來自於谷歌 Cloud Dataflow  SDK——開發者用來寫流處理和批處理管道（pipelines）的庫，可在任何支持的執行引擎上運行。當時，支持的主要引擎是谷歌 Cloud Dataflow，附帶對 Apache Spark 和 開發中的 Apache Flink 支持。如今，它正式開放之時，已經有五個官方支持的引擎。除去已經提到的三個，還包括 Beam 模型和 Apache Apex。

　　雷鋒網獲知，Apache Beam 的官方解釋是：“Beam 為創建復雜數據平行處理管道，提供了一個可移動（兼容性好）的 API 層。這層 API 的核心概念基於 Beam 模型（以前被稱為 Dataflow 模型），並在每個 Beam 引擎上不同程度得執行。”

谷歌工程師、Apache Beam 項目的核心人物 Tyler Akidau 表示：

“當我們（谷歌和幾家公司）決定把  Cloud Dataflow SDK 和相關引擎加入  Apache Beam 孵化器項目時，我們腦海里有一個目標：為世界提供一個易於使用、但是很強大的數據並行處理模型，支持流處理和批處理，兼容多個運行平台。”

　　　　　　　　　　　　

 

 

前景

　　對於 Apache Beam 的前景，Tyler Akidau 說道：

“一般來講，在孵化器畢業只是一個開源項目生命周期中的一個里程碑——未來還有很多在等着我們。但成為頂級項目是一個信號：Apache Beam 的背后已經有為迎接它的黃金時間准備就緒的開發者社群。

這意味着，我們已經准備好向前推進流處理和批處理的技術邊界，並把可移動性（兼容多平台）帶到可編程數據處理。 這很像 SQL 在陳述性數據（declarative data）分析領域起到的作用。相比不開源、把相關技術禁錮在谷歌高牆之內，我們希望借此創造出前者所無法實現的東西。”

　　另外，Tyler Akidau 信心十足地強調：“流處理和批處理的未來在於 Apache Beam，而執行引擎的選擇權在於用戶。”

　　最后，我們來看看谷歌在去年早些時候發布的 “Apache Beam 技能矩陣”，用它可以看出每一個兼容引擎執行 Beam 模型的效果。換句話說，它展示了 Apache Beam 管道在不同平台執行的兼容能力。

　　　　　　　　

 

　　 Apache Beam（原名Google DataFlow）是Google在2016年2月份貢獻給Apache基金會的Apache孵化項目，被認為是繼MapReduce，GFS和BigQuery等之后，Google在大數據處理領域對開源社區的又一個非常大的貢獻。Apache Beam的主要目標是統一批處理和流處理的編程范式，為無限，亂序，web-scale的數據集處理提供簡單靈活，功能豐富以及表達能力十分強大的SDK。Apache Beam項目重點在於數據處理的編程范式和接口定義，並不涉及具體執行引擎的實現，Apache Beam希望基於Beam開發的數據處理程序可以執行在任意的分布式計算引擎上。

 

 

 

 

 

 

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

　　　　　　　　

 

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

• 數據處理：直接使用已有的自己熟悉語言的SDK，根據Beam模型去定義並實現自己的數據處理流程；

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

• Runner實現：將已有的分布式數據處理平台作為一種新的Runner，接入Beam模型；

 

 

 

 

Beam是怎么做的？

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

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

2. 時間。Process Time是指數據進入分布式處理框架的時間，而Event-Time則是指數據產生的時間。這兩個時間通常是不同的，例如，對於一個處理微博數據的流計算任務，一條2016-06-01-12:00:00發表的微博經過網絡傳輸等延遲可能在2016-06-01-12:01:30才進入到流處理系統中。批處理任務通常進行全量的數據計算，較少關注數據的時間屬性，但是對於流處理任務來說，由於數據流是無情無盡的，無法進行全量的計算，通常是對某個窗口中得數據進行計算，對於大部分的流處理任務來說，按照時間進行窗口划分，可能是最常見的需求。

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

 

 

 

 

 

 

 友商的看法

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

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

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

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

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

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

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