現在，有用的Apache大數據項目似乎每日更新。相比于每次都重新學習的方式，如果可以通過一個統一的API如何呢?

長期開玩笑說Hadoop生態系統是那種如果你不喜歡一個為特定系統的API，等待五分鐘，兩個新的Apache項目將出現隨之而來嶄新的API可供學習。

有很多要趕著學習。更糟糕的是，它會導致很多工作遷移到不同的項目僅僅為了保持通用性。“我們已經在暴風雨中實現了流媒體解決方案!現在我們已經快速地重做了!我們目前正在重寫pache Flink(或Apex)的核心…我們已經忘記了起初我們試圖解決的業務用例。

輸入Apache Beam，一個試圖統一數據處理框架有核心API的新項目，允許簡單的執行引擎之間的移植。

現在,我知道你正在思考拋出另一個API。但Beam有很強的繼承性。它來自谷歌并且其研究成果在Millwheel FlumeJava論文上，在多年的運營經驗后其出版。它定義了一個有些熟悉的有向無環圖數據處理引擎，可以處理無序傳遞成為常態的情況下的無限數據流，毫無例外。

但是稍等,我聽到了你在叫喊。這不是谷歌云數據流嗎?是的!也不是。谷歌云數據流是一個完全托管服務,你使用數據流SDK編寫應用程序，然后將它們提交到Google的服務器上運行。Apache Beam，在另一方面，僅僅是數據流SDK和一組“運動者”就是SDK元素映射到一個特定的執行引擎。是的，你可以在谷歌云數據流運行Apache Beam應用程序,但你還可以使用Apache Spark或Apache Flink，代碼幾乎沒有變化。

搭乘Apache Beam

關于Apache Beam SDK有四個主要的概念：

1、Pipeline：如果你曾經用過Spark，這有點類似于SparkContext。你所有的操作將開始于調度對象,你會用它來建立數據流從輸入源,應用轉換,并將結果寫入輸出下沉。

2、PCollection: PCollections類似于原始的Spark的彈性分布式數據集(RDD),它們包含一個潛在的無限數據流。這些信息都來源于輸入源，然后應用轉換。

3、Transforms: 一個操作PCollection處理步驟執行數據操作。典型的傳遞途徑可能會在一個輸入源有多個轉換操作 (例如,將一組日志條目傳入的字符串轉換成一個鍵/值對,關鍵是IP地址和值是日志消息)。Beam SDK附帶的一系列標準聚合建成的,當然,你可以定義根據自己的處理需求自定義。

4、I/O sources and sinks：最后，源和匯為你的數據提供輸入和輸出端點。

讓我們來看一個完整的Beam項目。為此，我們將使用Python still-quite-experimental SDK和完整的文本莎士比亞的《李爾王》:

import re

import google.cloud.dataflow as df

p = df.Pipeline('DirectPipelineRunner')

(p

| df.Read('read',

df.io.TextFileSource(

'gs://dataflow-samples/shakespeare/kinglear.txt'))

| df.FlatMap('split', lambda x: re.findall(r'w+', x))

| df.combiners.Count.PerElement('count words')

| df.Write('write', df.io.TextFileSink('./results')))

p.run()

導入正則表達式和數據流庫之后，我們構造一個管道對象并將其傳遞給我們希望使用的送貨員(在本例中,我們使用的是DirectPipelineRunner,本地測試運行器)。

從那，我們從一個文本文件讀取(位置指向谷歌云存儲)和執行兩個轉換。第一個是flatMap,我們通過一個正則表達式把每個字符串分成詞，并返回一個PCollection，其中所有單獨的詞都來自于“李爾王。”然后我們應用內置的計數操作計數我們的單詞。

最后一部分管道將計數操作的結果寫入磁盤。一旦管道被定義，它調用run()方法。在這種情況下,管道被提交到本地測試運行器，但通過改變流道類型,我們可以向谷歌云數據流，Flink，Spark或任何其他的可用Apache Beam。

運行撥零

一旦我們準備好應用程序，它可以被提交運行在谷歌云數據流沒有任何困難，因為它只是使用數據流SDK。

我們的想法是，跑步者將提供其他執行引擎。Beam目前包括Apache Flink和Apache Spark，分別由DataArtisans和Cloudera維護。這就是當前的一些Beam的褶皺可以發揮的作用，因為數據流模型并不總是容易映射到其他平臺上的。

在Beam網站可用的能力矩陣束上顯示你的特性，這不被支持。特別地，在代碼應用運行在Spark上您需要有額外的制約。只有幾行額外的代碼，但它不是一個無縫過渡。

很有趣的是Spark 流轉目前使用Spark原始的RDD而不是DataFrames。這繞過Spark催化劑優化器,幾乎可以肯定，Beam工作運行在Spark上將低于運行一個DataFrame版本。我想當Spark 2.0發布這將會改變，但它絕對是一個限制Spark 運行并且超過了能力矩陣所呈現的所有。

目前，Beam只包括谷歌云數據流的運行，Apache Spark，Apache Flink以及本地出于測試目的的運行。但有談論為框架新建運行的比如Storm和MapReduce。在MapReduce的情況下,任何運行最終將能夠支持一個子集Apache Beam所提供的，因為它只能為底層系統提供工作。

巨大的野心

Apache Beam是一個雄心勃勃的項目。它的最終目標是統一所有的數據處理引擎在一個API下，使它非常簡單的遷移。也就是說，Beam應用程序運行在自托管Flink集群到谷歌云數據

人來開發這些應用程序是偉大的。很明顯,谷歌花了數年時間精煉Beam模型覆蓋大部分我們中的許多人需要實現的數據處理模式。但是請注意，Beam目前是一個Apache“孵化”項目，所以在把它投入生產之前注意練習。Beam值得密切關注是因為它包含更多的運行者——以及Beam SDK更多的語言端口。

本文轉自d1net（轉載）

總結

以上是生活随笔為你收集整理的Apache Beam欲通过uber api获取大数据的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。