Flume, 系統編程

01-29

我已經盯著這個 Flume 程序發了半個小時呆。

Flume 的公開版本叫 Dataflow, 確實是個好東西。它有個類似 LINQ 或者 Spark 的編程介面，你只要像組織 SQL 一樣，寫幾個 ParDo, GroupBy 和 Join, 框架的 planner 會自動幫你轉化成幾個互相依賴的 MapReduce 任務，完成很複雜的數據計算。

我眼前這個程序，粗粗算來，為了個簡單的把幾個數據源聚合到一塊的功能，它要跑 6 趟 MapReduce, 編譯來一跑，果然不差。

6 趟。

Flume 很強悍的，再複雜點，搞個十幾趟它都面不改色給你跑出來。更重要的是，這個編程模型太好用了，我看了下代碼歷史，最近一次改動輕描淡寫地加了個小數據源，加了個 GroupBy & Join, 嗯，又加了一趟 MR.

這段程序寫得還真不錯，結構標準，還把一些數據介面封裝了共用庫，一行代碼，你就可以要到很複雜的數據處理結果，一行代碼，你就跑了 6 趟 MR. 這個項目十幾個 daily jobs, 每天都這麼跑上幾個鐘頭。

我的胃開始疼了。

我想了想，調整一下順序，Flume 應該能把其中一些步驟並行起來，這要看 planner 有多聰明了，人要順著機器的脾性，從單機資料庫到 Spanner / F1 再到 Flume 我習慣了。但是如果裸奔 MR, 我確定能全程兩趟跑完。再說了，那麼多 jobs 依賴這個數據源，怎麼著也應該先跑個 job 把數據聚合好 dump 下來，別的 job 再來調吧？

不過，這麼一來，再做改動就沒法輕描淡寫了，你要想怎麼融入現有流程避免再加 MR. 要用一個 dump 下來的共用數據源就又有數據依賴問題，調度問題，版本同步和兼容問題一大堆。或者簡單說，這不夠 scalable.

據說這些都不再應該是工程師要煩惱的問題，MapReduce is deprecated, 我們已經有了新的一層抽象，你應該專註你的數據，你的分析，別再來計較這跑了幾趟 MR.

然而，6 趟 MapReduce 的陰影依然揮之不去。

我見過另一個極端，每個模塊都為了自己那一點點特殊自己寫一個 thread pool 的，覺得多分配幾次內存要死的。不過話說回來，你猜猜看有多少伺服器 CPU 全耗在 memory allocator 上了？

要說大道理很容易了，沒做過 profile 的性能優化都是耍流氓啦，一切都是 trade-off 啦。但每一個具體問題，都還是如此新鮮有趣。

Bjarne Stroustrup 給「什麼是系統編程（Systems Programming)」下了這麼個定義: 如果你要解決的問題遇上了顯著的（硬體）資源限制，那你就要進入系統編程領域了。

那麼，任何一個足夠大，足夠難的工程問題，最後都會或多或少地進入 systems 領域，運用這個領域的思維方式。

這是一個很有趣的領域，是為開篇。