Apache Beam：統一的分散式資料處理程式設計庫

微信公眾號： 深廣大資料Club

關注可瞭解更多大資料相關資訊。問題或建議，請公眾號留言;

如果你覺得深廣大資料Club對你有幫助，歡迎讚賞 ^[1]

背景介紹

作為一名大資料開發者，不得不說自從hadoop問世之後，接連而來的各種各樣的大資料處理框架層出不窮，而我們則要不斷的去學習，運用不同的技術、框架、api，甚至是開發語言以及sdk，去開發專案功能，解決專案問題。

• 平臺遷移問題：根據專案的需求，技術的更新迭代，專案效能的要求等等，同樣的業務要在不同的框架上執行，可能你就要花費很長一段時間去學習新的框架，新的api。

• 開發工具難抉擇：近兩年開啟的開源大潮，為大資料開發者提供了十分富餘的工具。但這同時也增加了開發者選擇合適的工具的難度，尤其對於新入行的開發者來說。這很可能拖慢、甚至阻礙開源工具的發展

Apache Beam（原名Google DataFlow）是Google在2016年2月份貢獻給Apache基金會的Apache孵化專案，被認為是繼MapReduce，GFS和BigQuery等之後，Google在大資料處理領域對開源社群的又一個非常大的貢獻。Apache Beam的主要目標是統一批處理和流處理的程式設計正規化，為無限，亂序，web-scale的資料集處理提供簡單靈活，功能豐富以及表達能力十分強大的SDK。

Apache Beam專案重點在於資料處理的程式設計正規化和介面定義，並不涉及具體執行引擎的實現。

Apache Beam希望基於Beam開發的資料處理程式可以執行在任意的分散式計算引擎上

特性

• 統一(Unified)：

  對於批處理和流式處理，使用單一的程式設計模型，能夠實現批處理（Batch processing）、流處理（Streaming Processing），通常的做法是把待處理的資料集（Dataset）統一，一般會把有界（Bound）資料集作為無界（Unbound）資料集的一種特殊情況來看待，比如Apache Flink便是按照這種方式處理，在差異化的API層之上構建一個統一的API層。

• 可移植(Portable)：

  在多個不同的計算環境下，都能夠執行已經定義好的資料處理Pipeline。也就是說，對資料集處理的定義（即構建的Data Pipeline），與最終所要Deploy的執行環境完全無關。這對實現資料處理的企業是非常友好的，當下資料處理新技術不斷湧現，企業資料處理平臺也為了能夠與時俱進並提高處理效率，當然希望在底層計算平臺升級的過程中無需重寫上層已定義的Data Pipeline。

  目前，Apache Beam專案開發整體來看還處在初期，初步決定底層執行環境支援主流的計算平臺：

  Apache Apex、Apache Flink、Apache Spark、Google Cloud Dataflow。實際上，Apache Beam的這種統一程式設計模型，可以支援任意的計算引擎，通過Data Pipeline層與執行引擎層之間開發一個類似Driver的聯結器即可實現。

• 可拓展(Extensible)：可以實現和分享更多的新SDK、IO聯結器、轉換操作庫等；

核心概念

Pipeline

Pipeline抽象封裝了資料處理任務中的所有資料和步驟。 您的Beam驅動程式通常首先構造一個Pipeline物件，然後使用該物件作為建立管道資料集的基礎，如PCollections及其作為Transforms的操作。

PCollection

PCollection抽象表示為分佈的多元素資料集。 您可以將PCollection視為“管道”資料; Beam Transforms 使用PCollection物件作為輸入和輸出。 因此，如果要處理管道中的資料，則必須採用PCollection的形式。

Transforms

管道中的每個步驟，它接收一個或者若干個輸入PCollection，進行處理後，輸出PCollection

Transforms是管道中的操作，並提供通用處理框架。 以函式物件的形式提供處理邏輯（通俗地稱為“使用者程式碼”），並且使用者程式碼會應用於輸入PCollection（或多個PCollection）的每個元素。 根據您選擇的管道執行程式和後端，群集中的許多不同工作程式可以並行執行使用者程式碼的例項。 在每個worker上執行的使用者程式碼生成輸出元素，這些元素最終被新增到轉換產生的最終輸出PCollection中。

Pipeline I/O

建立管道時，通常需要從某些外部源（例如檔案或資料庫）讀取資料。 同樣，您可能希望管道將其結果資料輸出到外部儲存系統。 Beam為許多常見的資料儲存型別提供讀寫轉換。 如果希望管道讀取或寫入內建轉換不支援的資料儲存格式，則可以實現自己的讀寫轉換。

資料編碼及型別安全

當Beam執行程式執行您的管道時，它們通常需要實現PCollections中的中間資料，這需要將元素轉換為位元組字串和從位元組字串轉換元素。 Beam SDK使用稱為Coders的物件來描述如何編碼和解碼給定PCollection的元素。

視窗（Windowing）

視窗化根據其各個元素的時間戳細分PCollection。 聚合多個元素的變換（例如GroupByKey和Combine）在每個視窗的基礎上隱式工作 - 它們將每個PCollection作為一系列多個有限視窗處理，儘管整個集合本身可能具有無限大小。

觸發器 （Triiger）

在將資料收集並分組到視窗時，Beam使用觸發器來確定何時發出每個視窗的聚合結果（稱為窗格）。 如果使用Beam的預設視窗配置和預設觸發器，則Beam會在估計所有資料到達時輸出聚合結果，並丟棄該視窗的所有後續資料。

基本架構

架構圖

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

• End Users：選擇一種你熟悉的程式語言提交應用

• SDK Writers：該程式語言必須是 Beam 模型支援的

• Library Writers：轉換成Beam模型的格式

• Runner Writers：在分散式環境下處理並支援Beam的資料處理管道

• IO Providers：在Beam的資料處理管道上執行所有的應用

• DSL Writers：建立一個高階的資料處理管道

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。

語言(Language)

目前Apache Beam SDK支援的語言包含了以下幾種：

• Java

• Python

• Go

• Scala

執行器(Runner)

Beam目前支援使用以下分散式處理後端的Runners：

• Apache Apex

• Apache Flink

• Apache Gearpump (incubating)

• Apache Samza

• Apache Spark

• Google Cloud Dataflow

  注意：你始終可以在本地執行管道以進行測試和除錯。

總結

Apache Beam的Beam Model對無限亂序資料流的資料處理進行了非常優雅的抽象，“WWWH”四個維度對資料處理的描述，非常清晰與合理，Beam Model在統一了對無限資料流和有限資料集的處理模式的同時，也明確了對無限資料流的資料處理方式的程式設計正規化，擴大了流處理系統可應用的業務範圍，例如，Event-Time/Session視窗的支援，亂序資料的處理支援等。Apache Flink，Apache Spark Streaming等專案的API設計均越來越多的借鑑或參考了Apache Beam Model，且作為Beam Runner的實現，與Beam SDK的相容度也越來越高。

目前apache beam的開發處於初步階段，對python的支援還在開發中，對java的支援的內容相對比較豐富，支援的runner也會逐步增加，實現平臺遷移的可移植，降低／解決大資料開發者框架選擇的問題。

參考連結：

https://beam.apache.org

https://www.infoq.com/presentations/apache-beam

http://www.cnblogs.com/smartloli/p/6685106.html

關注公眾號