第 10 / 12 部 待錄

批次處理

《Designing Data-Intensive Applications（DDIA）》Podcast 準備稿：批次處理

書名： 設計資料密集型應用 Designing Data-Intensive Applications（The Big Ideas Behind Reliable, Scalable, and Maintainable Systems） 作者： Martin Kleppmann 系列： 啃一本大書（恩普拉氏） 公開標題建議： 啃一本大書｜DDIA．從 Unix 管線到 MapReduce：批次處理的哲學 (10/12) 涵蓋範圍： 第11章 批次處理（Unix 哲學、MapReduce 與 HDFS、reduce-side/map-side join、批次輸出哲學、超越 MapReduce 的資料流引擎、圖處理）

背景速覽

歡迎進入 Part III——派生資料。前面講「資料怎麼存、怎麼在多台機器間分散與達成共識」；最後這一部講資料怎麼流動、怎麼從既有資料衍生出新資料。第一個主題是批次處理：接收大量輸入、跑一段時間、產出結果，沒有使用者在等。這集從一個看似不起眼的起點切入——Unix 管線的設計哲學——再一路講到 MapReduce、講到 Spark/Flink 這類資料流引擎。MapReduce 本身重要性已下降，但它教給我們的設計原則歷久彌新。

一句話重點

批次處理的全部智慧，濃縮在 Unix 哲學裡——輸入不可變、輸出供未知程式使用、用組合小工具解決大問題；MapReduce 把這套哲學擴展到分散式（HDFS 當檔案系統、map/reduce 當處理器），而它最有價值的遺產不是那個 API（已經被 Spark/Flink 淘汰），而是那套設計原則：因為輸入不可變、輸出完整替換、無副作用，所以批次處理天生可重試、可回滾、可監控——這份「確定性與可恢復性」，才是它真正的禮物。

值得討論的重點

1. Unix 哲學：一個 1964 年的設計典範，至今未過時

Kleppmann 從一行 Unix 指令開始——用 awk | sort | uniq -c | sort | head 在數秒內從 GB 級日誌找出最熱門的五個頁面。然後揭示背後的 Unix 哲學（Doug McIlroy, 1964）：

  1. 讓每個程式做好一件事
  2. 預期每個程式的輸出成為另一個程式的輸入
  3. 儘早設計與建造，不怕丟掉重來
  4. 優先用工具而非人力

它能成立靠三個關鍵：統一介面（一切皆檔案/位元組流，所以能自由組合）、邏輯與接線分離（程式不需知道輸入從哪來、輸出去哪——一種控制反轉）、透明與實驗性（輸入不可變，可反覆執行、可在管線任一點截斷檢視）。Kleppmann 點出：這些原則跟現代 Agile / DevOps 思維驚人地一致。

2. MapReduce：分散式版的 Unix 工具

MapReduce 就像分散式的 Unix——不修改輸入、輸出循序寫一次，差別在於從分散式檔案系統（HDFS） 讀寫而非 stdin/stdout。HDFS 基於 shared-nothing，靠中央 NameNode 追蹤檔案區塊位置、複製到多台機器容錯。

執行流程對應 Unix 日誌分析的四步：讀取拆記錄 → Mapper 提取 key-value → 排序（框架隱含）→ Reducer 合併相同 key 的值。你只寫 mapper 和 reducer 兩個 callback，框架處理其餘。reducer 從各 mapper 拉取對應 partition 的排序檔案、合併處理——這過程叫 shuffle。單一 job 能力有限，所以串成工作流（workflow），前一個的輸出是後一個的輸入。

3. Join 演算法：把相關資料帶到同一處

MapReduce 沒有索引概念，它讀全部輸入（full scan）。要做 join（如使用者活動日誌 join 使用者資料庫），笨方法是逐筆查遠端資料庫——但網路往返延遲會慢死。聰明方法：

  • Reduce-side sort-merge join：兩組 mapper 都以 user ID 為 key 提取，框架排序後同一 user ID 的記錄相鄰送到同一 reducer，靠 secondary sort 保證先看資料庫記錄再看活動事件——reducer 完全不需網路請求。把 mapper 想成「向 reducer 寄信」，key 就是地址。
  • Map-side join（砍掉 reducer 和 sorting，更快，但需對輸入有假設）：broadcast hash join（小資料集載入記憶體廣播給所有 mapper）、partitioned hash join（兩側同樣方式分區）、map-side merge join（兩側同樣分區又同樣排序）。

還要處理資料傾斜（名人的活動量爆大造成 hot key）——又是那個長尾幽靈。

4. 批次輸出的哲學：可回滾、可重試、可監控

批次處理產出的不是報表，而是結構化資料（搜尋索引、機器學習模型的資料庫）。關鍵原則（承襲 Unix）：輸入不可變、輸出完整替換、無副作用——別在 mapper/reducer 裡直接寫線上資料庫（慢、會壓垮它、破壞 all-or-nothing），而是建全新的唯讀資料庫檔案、再原子性切換。

這帶來四個禮物：可回滾（有 bug 修正後重跑就好）、快速迭代（最小化不可逆操作）、自動重試（輸入不可變，失敗 task 可安全重跑）、可監控（同組輸入可被多個 job 使用）。這份「人為錯誤的容錯」是批次處理最被低估的價值。

5. 超越 MapReduce：資料流引擎的進化

MapReduce 有根本問題——中間狀態物化：每個 job 的輸出完整寫進 HDFS，導致必須等前一個 job 全部 task 完成才能開始下一個、mapper 常只是多餘地重新分區、中間狀態被過度複製。

於是 Spark、Tez、Flink 等資料流引擎登場：把整個工作流視為一個 job，處理函式叫 operator，可靈活組合（不必嚴格交替 map/reduce），排序只在需要時做、中間狀態保持在記憶體或本地磁碟、operator 輸入就緒就立即執行。容錯方式也變了——MapReduce 靠寫 HDFS，資料流引擎靠重新計算（Spark 的 RDD 追蹤血統 lineage、Flink 的 checkpoint），前提是 operator 必須確定性（相同輸入相同輸出）。

注意事項

⚠️ MapReduce 的「重要性已下降」，但別因此跳過它。 直接用 MapReduce API 確實過時了（Spark/Flink 全面取代），但它的設計原則（不可變輸入、完整替換輸出、task 級容錯）正是 Spark/Flink 繼承並改良的。理解 MapReduce 是理解一切現代資料流引擎的基礎——就像學物理要先學牛頓力學。提醒聽眾：我們學的是「思想」，不是「要你去寫 MapReduce job」。

⚠️ 「中間狀態物化 vs 重新計算」是個取捨，不是「物化一定不好」。 Spark 用重新計算避免寫 HDFS，但 Kleppmann 誠實指出：若中間資料遠小於源資料、或計算非常 CPU 密集，物化反而比重算經濟。別讓聽眾以為「Spark 全面勝過 MapReduce、物化都是壞的」——這是個依場景而定的工程決策。

⚠️ MapReduce 頻繁寫磁碟，不是因為硬體不可靠。 一個常見誤解。真正原因是 Google 的混合資料中心允許高優先級任務搶占低優先級批處理的資源——一個跑一小時的 MapReduce task 有約 5% 機率被殺。頻繁 checkpoint 是為了讓批處理能安全地利用「剩餘資源」。這個細節很有啟發：容錯設計往往反映的是運維環境，而非單純的硬體可靠性。

專家補充

💡 Unix 哲學是「軟體組合性」的永恆典範。 一切皆檔案、邏輯與接線分離、輸入不可變——這套 1960-70 年代的智慧，今天在容器（Docker）、在函數式編程（不可變資料）、在 Serverless（小函數組合）裡到處重生。DDIA 用批次處理重新詮釋 Unix 哲學，讓你看到好的設計原則是跨時代、跨層級的。這條可以接到 Clean Code 的「做好一件事」（單一職責）。

💡 「把相關資料帶到同一處」是分散式計算的核心母題。 Sort-merge join 的精髓——把 mapper 想成「按地址（key）寄信給 reducer」——是理解所有 shuffle 操作的鑰匙。這個「資料移動到計算」vs「計算移動到資料」的權衡，貫穿大數據領域。broadcast join（把小表搬到每台機器）就是「計算就地、資料來就」的另一種選擇。

💡 圖處理（Pregel/BSP）揭示了一個務實的真相：別動不動就分散式。 Pregel 模型（頂點互相發訊息、迭代到收斂）很優雅，但 Kleppmann 給了一個冷靜的提醒：如果你的圖能放進單機記憶體，單機演算法很可能比分散式批處理更快。 分散式的跨機器通訊開銷極大，只有圖真的大到單機放不下才值得。這個「先問需不需要分散式」的清醒，是整本書反覆強調的工程成熟度。

討論問題

🎙️ 開場鉤子：「一行 Unix 指令，sort | uniq -c | sort | head，能在幾秒內處理 GB 級的日誌。這個 1970 年代就有的小魔法背後，藏著一整套設計哲學——而 MapReduce、Spark、Flink，全都是它的徒子徒孫。」

🎙️ 自問自答：「批次處理最被低估的優點是什麼？」回答：不是『快』，而是『可以安心地搞砸』——因為輸入不可變、輸出完整替換，所以程式有 bug 時，修正後重跑就能恢復正確結果。這份『對人為錯誤的容錯』，才是它真正的禮物。

🎙️ 帶走的一題：「下次你要寫一個資料處理程式時，問自己：它的輸入是不可變的嗎？如果跑到一半掛了，能安全重跑嗎？如果不能——你可能正在製造一個『出錯就無法挽回』的定時炸彈。」

更大範圍關聯

  • 批次與串流是一體兩面：這集（批次）的輸入是有界的（大小已知、會讀完、會結束），下一集（串流）的輸入是無界的（永遠不結束）。但兩者共享大量原則——分區、容錯、join。第12集會講到它們最終如何統一（Lambda 架構、Spark 的微批次、Flink 的批串流統一）。先理解批次，串流就只是「把它推到無界」。
  • 與系統設計實務：資料管線（data pipeline）是現代後端的核心，ETL、推薦系統、搜尋索引建構全靠批次/串流。DDIA 這集給你的是底層原理——你才知道為什麼 Spark 比 MapReduce 快、什麼時候該物化中間結果、join 怎麼選。（見 [軟體工程領域切分藍圖] §5「軟體架構演進」）
  • 思想連線：這集的「不可變輸入、衍生輸出」直接呼應第3集的物化視圖、預示第11/12集的「不可變事件日誌」。DDIA 後半有一條清晰的暗線：不可變性是可靠資料系統的基石——從批次的不可變輸入，到事件溯源的不可變日誌，同一個思想越滾越大。

錄製建議

  • 建議時長：約 22–24 分鐘。配比：Unix 哲學約 7 分（這是靈魂，慢慢講，用那行指令開場）；MapReduce 與 HDFS 約 6 分；join 演算法約 5 分；批次輸出哲學約 3 分；超越 MapReduce 的資料流引擎約 4 分。
  • 討論策略：用「一行 Unix 指令的魔法」開場最有吸引力——它具體、好懂、又藏著大道理。把 Unix 哲學當主菜慢慢講透（這是本集真正歷久彌新的部分），MapReduce 講「它是分散式版的 Unix」這個類比就好，不要陷進 API 細節。批次輸出哲學那段（可回滾、可重試）是情感共鳴點——「能安心搞砸」這個說法很打動工程師。
  • 結尾接好 Part III 的主線：「批次處理的輸入是有界的——它知道何時讀完、最終會結束。但現實世界的資料是源源不絕的：使用者昨天在產生、今天在產生、明天還會繼續。當輸入永遠不結束時，會發生什麼?下一集，串流處理。」