iT邦幫忙

2021 iThome 鐵人賽

DAY 27
0
AI & Data

資料工程師修煉之路 Part II系列 第 27

Batch Processing (4) - Materialization of Intermediate State

Beyond MapReduce

儘管 MapReduce 在 2000 年以後很夯,但它畢竟是分散式系統中諸多程式框架中的其中一種,取決於數據量、數據結構和數據處理的類型,你還有其他更適合的工具可以使用。

MapReduce 是個很有用的學習工具,因為它是分散式系統上一個清楚和簡單的抽象,但是,易於理解不代表易於使用,用原生 MapReduce API 實現一個能動的 job 相當費力,就像你不會想從頭實現 join 算法一樣。

所以今天就來看看,除了 MapReduce 外還有哪些批次處理工具吧。

中介狀態的實體化 (Materialization of Intermediate State)

如同前幾天討論的那般,每一個 MapReduce 的 job 都是獨立的,有依賴關係之 job 的唯一接觸點是資料位置,第 2 個 job 的輸入是第 1 個 job 的輸出,所以有些工程師會仰賴外部工具來安排所有 MapReduce job 的調度。

然而在大多數的情況下,job 的輸出只會被另一個 job 來使用,所以分散式檔案系統上很多資料都處於 中介狀態 (intermediate state),在一個使用 50 ~ 100 個 MapReduce job 的推薦引擎 workflow 下,其中介狀態資料的數量可以很驚人。

相比之下,Day 23 示範的用 Unix 工具分析 log 的例子就沒有這問題,管線命令 (pipe) 不會完整的實體化 (materialize) 中介狀態,而是以逐漸增量的方式,將輸出串流到輸入,而僅使用一個小的記憶體緩衝區。

跟 Unix 工具相比,MapReduce 這種完全實體化中介狀態的方法有以下缺點:

  • 一個 MapReudce job 需要等前面的 job 執行完才會開始,如果發生 Day 25 講的 傾斜 (skew) 就會拖慢 job 處理速度。
  • mapper 通常是多餘的,在某些案例下,你直接把 reducer 的輸出當做下一次 reudcer 的輸入會更快,省得用 mapper 再讀入一次,然後再做一次一樣的排序跟分區。
  • 中介狀態的資料還是會被分散式檔案系統做副本到多個節點上,但其實不需要。

數據流引擎

感謝這些大神,我們有數個工具框架可以解決 MapReduce 的這些問題,像 SparkTezFlink,儘管它們設計的方法不樣,但有一點是相同的:它們能將整個 workflow 視為單一個 job,而不是細分到多個 subjob。

因為它們將數據流拆成多個處理階段,所以也被稱為 數據流引擎 (dataflow engines)

就像 MapReduce 那樣,它們會重複的呼叫 user-defined 函數來處理一條條的數據,也能在多個分區輸入中並行執行,並透過網路讓輸出成為下個函數的輸入。

不像 MapReduce 的是,這些函數並不會嚴格的把角色區分成 map 和 reduce,而是以更靈活的方式組裝,我們稱這些函數為 operator,數據流引擎提供多個選項連接這些 operator

  • 一個選項是做 重新分區 (repartition) 和以 key 做排序,就像 Day 24 的 MapReduce shuffle 一樣。
  • 另一個選項是一次讀取多個輸入並以同樣的方法做分區,但跳過排序,這節省了做 Partitioned hash joins 的力氣,排序對 hash table 的建立沒有任何影響。
  • 對於 Broadcast hash joins,來自同一個 operator 的輸出可以發送到 join operator 的所有分區。

你能使用數據流引擎建立跟 MapReudce 一樣的 workflow,而且執行的較快。


上一篇
Batch Processing (3-2) - MapReduce Map-Side Joins
下一篇
Stream Processing (1-1) - Transmitting Event Streams
系列文
資料工程師修煉之路 Part II30

尚未有邦友留言

立即登入留言