Apache Beam欲通過uber api擷取大資料

文章講的是<b>Apache Beam欲通過uber api擷取大資料</b>，現在，有用的Apache大資料項目似乎每日更新。相比于每次都重新學習的方式，如果可以通過一個統一的API如何呢?

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

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

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

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

　　搭乘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更多的語言端口。

作者:趙钰瑩

來源：IT168

原文連結:Apache Beam欲通過uber api擷取大資料