現(xiàn)在，有用的Apache大數(shù)據(jù)項(xiàng)目似乎每日更新。相比于每次都重新學(xué)習(xí)的方式，如果可以通過(guò)一個(gè)統(tǒng)一的API如何呢?

長(zhǎng)期開(kāi)玩笑說(shuō)Hadoop生態(tài)系統(tǒng)是那種如果你不喜歡一個(gè)為特定系統(tǒng)的API，等待五分鐘，兩個(gè)新的Apache項(xiàng)目將出現(xiàn)隨之而來(lái)嶄新的API可供學(xué)習(xí)。

有很多要趕著學(xué)習(xí)。更糟糕的是，它會(huì)導(dǎo)致很多工作遷移到不同的項(xiàng)目?jī)H僅為了保持通用性。“我們已經(jīng)在暴風(fēng)雨中實(shí)現(xiàn)了流媒體解決方案!現(xiàn)在我們已經(jīng)快速地重做了!我們目前正在重寫(xiě)pache Flink(或Apex)的核心…我們已經(jīng)忘記了起初我們?cè)噲D解決的業(yè)務(wù)用例。

輸入Apache Beam，一個(gè)試圖統(tǒng)一數(shù)據(jù)處理框架有核心API的新項(xiàng)目，允許簡(jiǎn)單的執(zhí)行引擎之間的移植。

現(xiàn)在,我知道你正在思考拋出另一個(gè)API。但Beam有很強(qiáng)的繼承性。它來(lái)自谷歌并且其研究成果在Millwheel FlumeJava論文上，在多年的運(yùn)營(yíng)經(jīng)驗(yàn)后其出版。它定義了一個(gè)有些熟悉的有向無(wú)環(huán)圖數(shù)據(jù)處理引擎，可以處理無(wú)序傳遞成為常態(tài)的情況下的無(wú)限數(shù)據(jù)流，毫無(wú)例外。

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

搭乘Apache Beam

關(guān)于A(yíng)pache Beam SDK有四個(gè)主要的概念：

1、Pipeline：如果你曾經(jīng)用過(guò)Spark，這有點(diǎn)類(lèi)似于SparkContext。你所有的操作將開(kāi)始于調(diào)度對(duì)象,你會(huì)用它來(lái)建立數(shù)據(jù)流從輸入源,應(yīng)用轉(zhuǎn)換,并將結(jié)果寫(xiě)入輸出下沉。

2、PCollection: PCollections類(lèi)似于原始的Spark的彈性分布式數(shù)據(jù)集(RDD),它們包含一個(gè)潛在的無(wú)限數(shù)據(jù)流。這些信息都來(lái)源于輸入源，然后應(yīng)用轉(zhuǎn)換。

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

4、I/O sources and sinks：最后，源和匯為你的數(shù)據(jù)提供輸入和輸出端點(diǎn)。

讓我們來(lái)看一個(gè)完整的Beam項(xiàng)目。為此，我們將使用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()

導(dǎo)入正則表達(dá)式和數(shù)據(jù)流庫(kù)之后，我們構(gòu)造一個(gè)管道對(duì)象并將其傳遞給我們希望使用的送貨員(在本例中,我們使用的是DirectPipelineRunner,本地測(cè)試運(yùn)行器)。

從那，我們從一個(gè)文本文件讀取(位置指向谷歌云存儲(chǔ))和執(zhí)行兩個(gè)轉(zhuǎn)換。第一個(gè)是flatMap,我們通過(guò)一個(gè)正則表達(dá)式把每個(gè)字符串分成詞，并返回一個(gè)PCollection，其中所有單獨(dú)的詞都來(lái)自于“李爾王。”然后我們應(yīng)用內(nèi)置的計(jì)數(shù)操作計(jì)數(shù)我們的單詞。

最后一部分管道將計(jì)數(shù)操作的結(jié)果寫(xiě)入磁盤(pán)。一旦管道被定義，它調(diào)用run()方法。在這種情況下,管道被提交到本地測(cè)試運(yùn)行器，但通過(guò)改變流道類(lèi)型,我們可以向谷歌云數(shù)據(jù)流，F(xiàn)link，Spark或任何其他的可用Apache Beam。

運(yùn)行撥零

一旦我們準(zhǔn)備好應(yīng)用程序，它可以被提交運(yùn)行在谷歌云數(shù)據(jù)流沒(méi)有任何困難，因?yàn)樗皇鞘褂脭?shù)據(jù)流SDK。

我們的想法是，跑步者將提供其他執(zhí)行引擎。Beam目前包括Apache Flink和Apache Spark，分別由DataArtisans和Cloudera維護(hù)。這就是當(dāng)前的一些Beam的褶皺可以發(fā)揮的作用，因?yàn)閿?shù)據(jù)流模型并不總是容易映射到其他平臺(tái)上的。

在Beam網(wǎng)站可用的能力矩陣束上顯示你的特性，這不被支持。特別地，在代碼應(yīng)用運(yùn)行在Spark上您需要有額外的制約。只有幾行額外的代碼，但它不是一個(gè)無(wú)縫過(guò)渡。

很有趣的是Spark 流轉(zhuǎn)目前使用Spark原始的RDD而不是DataFrames。這繞過(guò)Spark催化劑優(yōu)化器,幾乎可以肯定，Beam工作運(yùn)行在Spark上將低于運(yùn)行一個(gè)DataFrame版本。我想當(dāng)Spark 2.0發(fā)布這將會(huì)改變，但它絕對(duì)是一個(gè)限制Spark 運(yùn)行并且超過(guò)了能力矩陣所呈現(xiàn)的所有。

目前，Beam只包括谷歌云數(shù)據(jù)流的運(yùn)行，Apache Spark，Apache Flink以及本地出于測(cè)試目的的運(yùn)行。但有談?wù)摓榭蚣苄陆ㄟ\(yùn)行的比如Storm和MapReduce。在MapReduce的情況下,任何運(yùn)行最終將能夠支持一個(gè)子集Apache Beam所提供的，因?yàn)樗荒転榈讓酉到y(tǒng)提供工作。

巨大的野心

Apache Beam是一個(gè)雄心勃勃的項(xiàng)目。它的最終目標(biāo)是統(tǒng)一所有的數(shù)據(jù)處理引擎在一個(gè)API下，使它非常簡(jiǎn)單的遷移。也就是說(shuō)，Beam應(yīng)用程序運(yùn)行在自托管Flink集群到谷歌云數(shù)據(jù)

人來(lái)開(kāi)發(fā)這些應(yīng)用程序是偉大的。很明顯,谷歌花了數(shù)年時(shí)間精煉Beam模型覆蓋大部分我們中的許多人需要實(shí)現(xiàn)的數(shù)據(jù)處理模式。但是請(qǐng)注意，Beam目前是一個(gè)Apache“孵化”項(xiàng)目，所以在把它投入生產(chǎn)之前注意練習(xí)。Beam值得密切關(guān)注是因?yàn)樗嗟倪\(yùn)行者——以及Beam SDK更多的語(yǔ)言端口。

原文鏈接:

http://www.infoworld.com/article/3056172/application-development/apache-beam-wants-to-be-uber-api-for-big-data.html