概述
本文不是一篇Beam的入門文檔速客，不會介紹Beam的基本概念戚篙；而會主要探討B(tài)eam的表達(dá)力，Beam的性能溺职，以及Beam目前在業(yè)內(nèi)的使用情況岔擂。面向的讀者是那些想使用Beam作為自己公司操作大數(shù)據(jù)的統(tǒng)一API位喂，但是還有所顧慮的人們。
表達(dá)力
離線
Beam里面有兩個核心原語：
- ParDo: 來處理通用的基于單條數(shù)據(jù)的計(jì)算: 每條需要處理的數(shù)據(jù)會被喂給用戶提供的指定的一個函數(shù)(Beam里面的@ProcessElement), 然后輸出0個或者多個輸出乱灵。
- 我們平常熟悉的Filter, AppendColumn等等都可以通過ParDo來實(shí)現(xiàn)塑崖。
- ParDo的語義涵蓋了Hadoop中Map-Shuffle-Reduce的Map，Reduce
- GroupByKey: 用來做Grouping的操作痛倚。
- 我們平常熟悉的Count, Sum, Min等等都可以通過GroupByKey來實(shí)現(xiàn)规婆。
- Group的語義涵蓋了Hadoop中Map-Shuffle-Reduce的Shuffle
既然Map-Shuffle-Reduce這三個關(guān)鍵語義都被Beam涵蓋了，你覺得它的表達(dá)力如何蝉稳？
實(shí)時
對于GroupByKey操作聋呢，在實(shí)時場景下會有所不同：實(shí)時場景下我們不知道什么時候應(yīng)該完成對某個key的group。因此GroupByKey被擴(kuò)展成了更通用的: GroupByKeyAndWindow颠区。這里的Window通常是按照時間來劃分的削锰，比如“小時窗口”，“5分鐘窗口”毕莱。當(dāng)窗口結(jié)束的時候器贩，我們就認(rèn)為GroupByKey說需要的所有的數(shù)據(jù)到到達(dá)了，因此可以完成這個操作朋截。
通過引入Window原語蛹稍，（離線情況下有一個默認(rèn)的全局window），我們把GroupByKey這種聚合操作在離線和實(shí)時層面也統(tǒng)一了部服。
數(shù)據(jù)延時
而在實(shí)際業(yè)務(wù)中唆姐，數(shù)據(jù)的到達(dá)時間往往不會嚴(yán)格按照窗口規(guī)定的時間按時到達(dá):
- 數(shù)據(jù)可能晚來，導(dǎo)致實(shí)時計(jì)算的數(shù)據(jù)不準(zhǔn)確
- 窗口可能畫的太大廓八，延遲太高
Beam提供了Trigger的機(jī)制來解決上述的兩個問題奉芦。
總結(jié)一下, Beam的模型支持了ParDo, GroupByKey, Window等核心概念，通過這些概念的任意組合就可以表達(dá)我們在離線剧蹂、實(shí)時業(yè)務(wù)中遇到各種問題声功。Beam還提供了Trigger的機(jī)制來讓我們可以在準(zhǔn)確性和時間延遲之間做平衡。
關(guān)于Beam表達(dá)力的進(jìn)一步信息可以參見參考資料[3]宠叼。
Beam的表達(dá)力能涵蓋底層引擎(比如ODPS先巴， Spark, Hadoop)的所有功能么？
我就這個問題咨詢了一下Beam的開發(fā)者: Google的Beam開發(fā)者Frances Perry, 他給出的回復(fù)是:
Beam的表達(dá)能力的集合既不是所有底層引擎能力的交集(那樣的話冒冬，API的能力太受限了), 也不是所有底層引擎能力的并集（那樣的話那也太理想太激進(jìn)了）伸蚯。
Beam是要站在所有數(shù)據(jù)處理的最前端（數(shù)據(jù)處理人直接面對的那一層），把表達(dá)數(shù)據(jù)邏輯所需要的“模式”(比如Beam里面的Windowing, Trigger)封裝出來简烤，包成API剂邮。而把具體的一些實(shí)現(xiàn)細(xì)節(jié)功能點(diǎn)隱藏掉(比如Storm里面的Bolt, Spark里面的DataFrame等等)。
因此Beam作為一種數(shù)據(jù)處理的API, 其實(shí)只需要關(guān)心模式乐埠，而不關(guān)心細(xì)節(jié)的功能點(diǎn)抗斤。
當(dāng)然這并不意味著Beam的API從設(shè)計(jì)的第一天起就可以表達(dá)所有的數(shù)據(jù)計(jì)算邏輯囚企，Beam的API也是不斷演進(jìn)的，比如最近就準(zhǔn)備加入一個新的叫做Stateful Processing的新特性瑞眼。但是既然已經(jīng)那么多公司在使用Beam了(詳見本文最后一節(jié))龙宏，說明目前用它表達(dá)絕大部分?jǐn)?shù)據(jù)處理的場景已經(jīng)不是問題了。
關(guān)于作者的詳細(xì)回復(fù)可以看參考文獻(xiàn): [2]伤疙。
Beam Pipeline的性能
由于目前關(guān)于Beam性能方面的資料比較少银酗，我去研究了它的前身FlumeJava性能相關(guān)的資料。因此下面的論述的主體都是FlumeJava, 但是因?yàn)锽eam是從FlumeJava演化而來的徒像，因此這些性能相關(guān)的結(jié)論對Beam也適用黍特。
理論分析
延遲求值
為了獲得更好的性能，F(xiàn)lumeJava內(nèi)部對并行的操作使用了延遲求值的優(yōu)化锯蛀。我們代碼中對于并行操作(各種Transform)的調(diào)用并沒有真正的去執(zhí)行那個操作灭衷，而只是簡單的把這些對數(shù)據(jù)的操作以及對應(yīng)的參數(shù)記錄了下來。這些被記錄下來的操作串聯(lián)拼接在一起就組成了一個DAG狀的執(zhí)行計(jì)劃旁涤。
通過生成執(zhí)行計(jì)劃翔曲，而不是直接運(yùn)行用戶編寫的Pipeline, 使得Beam(FlumeJava)有機(jī)會可以對這個執(zhí)行計(jì)劃進(jìn)行各種優(yōu)化 -- 優(yōu)化之后會比你手動優(yōu)化之后的任務(wù)要更高效！
執(zhí)行計(jì)劃的優(yōu)化
在真正執(zhí)行之前劈愚，Beam會對這個執(zhí)行進(jìn)行一些優(yōu)化, 比如ParDo操作的的合并
通過ParDo的合并瞳遍，可以減少任務(wù)的步數(shù)，這樣在生成底層引擎任務(wù)的時候菌羽，比如Hadoop的時候掠械，會生成比較少的MapReduce, 更少的MapReduce意味著更少的IO, 更好的性能。
其它的優(yōu)化措施還有MSCR(把一個ParDo, GroupByKey, CombineValues, Flattern操作合并成一個MapReduce), MSCR合并等等注祖。
Benchmark
圖中Ads Logs, IndexStats, Build Logs, SiteData是Google內(nèi)部的幾個用來做性能測試的幾個不同的場景猾蒂，這幾種場景分別用FlumeJava, MapReduce, 以及手工優(yōu)化過的MapReduce來編寫的∶ズ洌可以看出:
FlumeJava與經(jīng)過手工優(yōu)化過的MapReduce的性能是差不多的婚夫。
關(guān)于這個性能測試的更詳細(xì)的信息見參考資料[4]浸卦。
Beam在目前業(yè)界的使用情況怎么樣?
- Google: Beam在Google的前身是FlumeJava, FlumeJava是Google內(nèi)部并行數(shù)據(jù)計(jì)算的主要Java API（參考資料[4]）署鸡。
- Spotify: 他們在生產(chǎn)環(huán)境使用Beam, 實(shí)時和離線的場景都有，他們目前感覺Beam在離線計(jì)算方面比實(shí)時要成熟限嫌。（參考資料[1]）
- Cisco: 準(zhǔn)備在生產(chǎn)環(huán)境中使用Beam靴庆，runner會采用Google Dataflow Service，一開始會以實(shí)時任務(wù)為主怒医。（參考資料[1]）
- Talend準(zhǔn)備把Beam作為他們產(chǎn)品的中間層能力炉抒，這樣可以讓在支持各種底層計(jì)算引擎（CDH Hadoop， HDP Hadoop稚叹， Spark等等 ）的時候公用代碼焰薄，減少維護(hù)各種不同底層引擎升級帶來的痛苦（原文是: versions updates are really painful）（參考資料[1]）
