四個動畫秒懂 Apache Beam 模型

The_Next_Generation_of_Data_Processing_OSS - 騰訊視頻 https://v.qq.com/x/page/o0375yo21qi.html

微信公眾號: bigdata_summit (大數據技術峰會解讀)

今天解讀的內容是 Hadoop Summit San 2016 上來自 Google 的關於 Apache Beam 的一個介紹： The Next Generation of Data Processing OSS

說明：上次的 「Apache 流處理框架大比拼」 文章比較了多種流處理框架的特點和適用場景，但是多種框架並存的情況對用戶來說卻也存在各種弊端，如：編程模型不一致和應用遷移成本高等，Apache Beam 正是在這樣的背景下孕育產生。

背景

Apache Beam 是Google 開源的一個統一編程框架，它本身不是一個流式處理平台，而是提供了統一的編程模型，幫助用戶創建自己的數據處理流水線，實現可以運行在任意執行引擎之上批處理和流式處理任務。它包含：

• 一個可以涵蓋批處理和流處理的統一編程模型
• Beam SDK，支持 Java 和 Python
• 一系列Runner（可以理解為「適配器」吧），讓其編程模型運行在不同底層處理引擎（Google Cloud Dataflow，Spark，Flink等）

Beam （模型）能為用戶帶來什麼價值？

這裡使用一個例子簡單地介紹 Beam的能力。在此之前先介紹了流數據處理的兩個基本概念：

• 事件時間（Event Time）：事件產生的時間
• 處理時間（Processing Time）：事件（數據）到達處理系統的時間

上圖中，橫軸表示的是事件時間（從12:00開始），縱軸表示的是處理時間（從12:05開始），虛線表示的是一種理想的情況，即事件時間與處理時間相同，也就是說事件一產生就直接被系統接收到並處理（註：由於縱軸的時間是從12:05開始，所以此處虛線是從事件時間12:05的位置開始畫出）。

圖上面的灰色圓點表示的是一系列事件，他們只能出現在虛線的左上方（因為必須滿足：時間事件小於處理時間，也就是事件總是先產生然後才被系統接收處理）。我們看到標號為「3」的點與虛線的水平距離很近，也就是說此事件一產生就被系統接收到進行處理，延時較小；反之，編號為「9」的圓點，它所代表的事件在12:01~12:02直接產生，但是到了 12:08之後才被處理，延時較大。

明白了以上兩個概念，接下來通過四個動畫來回答四個問題，我們可以較好地了解 Beam 編程模型的能力：

做什麼計算？（What result are calculated?）

拿 sum （累加事件的某個指標，如上圖灰色圓點的整數值）為例，如下圖所示，在某個時刻（如12:10）計算出之前所接收到的整數的和，這是一個典型的批處理的場景。

註：以下所有動畫中的累加數字，白色表示計算的中間結果，黃色表示返回的計算結果，才是用戶可見的。

相應的 Beam 代碼如下圖所示

當然，做到這一步還看不出 Beam 的特殊能力，從下面一個問題開始，才開始顯現 Beam 模型的價值

數據在什麼範圍中計算？(Where in event time are results calculated?)

就是在代表事件時間的橫軸坐標上，對落在哪個區間的灰色圓點施加計算呢？

假如我們現在想在事件時間橫軸上統計每個2分鐘時間窗口的整數累加值，即完成如下圖動畫所示的效果：

對有些計算框架來說，這就開始有些棘手了。但是有了 Beam，下面寥寥幾行代碼就可以實現（新增的代碼為藍色部分）：

Beam 自動為每個時間窗口創建一個小的批處理作業，在處理時間縱軸 12:10 的時候觸發計算。但是這樣，我們只能等到最後的一個時間點（12:10）才能得到計算結果。如果我們想在更早的時間點得到時間窗口的統計結果（這個問題就開始變得複雜了），我們開始需要考慮如何回答下一個問題。

何時將計算結果輸出？(When in processing time are result materialized?)

就是在代表處理時間的縱軸坐標上，在什麼時間點返回計算結果？

為了回答這個問題，我們首先要回答，對於事件時間橫軸上的每個時間窗口，在處理時間縱軸上的哪個位置，待統計的數據/事件（也就是圖中的圓點）都被接收到了？這就涉及到一個叫做水位線（watermark）的概念，它的作用就是來回答我們這個問題的。在下圖動畫中的曲線就是一條 水位線，它可以根據某些指標（比如歷史數據等）推測出來（但不一定完全準確）。這樣，我們就可以不必等到最後的時間點才能得到各個時間窗口的統計結果，具體效果如下圖動畫所示：

新增的 Beam 代碼如下圖綠色部分所示：

比如對於第一個時間窗口而言，水位線的預測存在偏差，因為標號為「9」的數據落在這條曲線之上，也就是在 watermark 預測的處理時間點（12:06左右）時還未被系統接收到。這就涉及到下一個問題。

遲到數據如何處理？(How do refinement of result related?)

就是在接收到延遲到達的數據後，如何對之前的計算結果進行修正？

通過對上面的代碼稍加修改（如下圖所示，綠色和紅色部分）

我們可以得到如下動畫展示的效果：

從中我們可以看到：

動畫中標識為「early」的結果為探測性結果 ，因為根據 watermark預測，後續還有可能繼續接收到這個時間窗口的數據

動畫中標識為「on-time」的結果為（及時/普通）結果， 因為根據 watermark 預測，後續不再會接收到此時間窗口的數據

動畫中標識為「late」的結果為延遲結果，這種情況表示有數據延遲到達，也就是 watermark 的預測出現偏差，需要對結果進行校正，這裡採用的校正方式就是累加更新結果

可以看到，利用 Beam 的模型，我們不需要編寫複雜的邏輯，就可以靈活地/優雅地處理流處理計算過程中出現的一些棘手場景。