批处理

一句话

这一章讲批处理（batch processing）：把海量数据当作不可变的输入、成批读进来、算出派生结果（搜索索引、推荐、报表），追求的是吞吐量而非响应时间。核心是把 Unix 的老智慧（小工具 + 管道）搬到上千台机器上——MapReduce：你只写 map 和 reduce 两个函数，框架靠一次分布式排序把同类数据凑到一起。一句要你记住的反直觉：你以为批处理的灵魂是「算得快」，其实是「输入不可变 + 确定性」带来的那份『算错了大不了重来』的从容。

Glossary · 术语表

坐标

本章属全书 Part III「派生数据（Derived Data）」的开篇。Part II 讲的是怎么在多台机器上正确地存与读（复制、分区、事务、共识）；Part III 掉头问怎么从已有数据批量算出新数据。作者先把数据系统分成三类——在线服务、批处理、流处理；本章讲批处理（离线、有界数据），下一章（Ch11）讲流处理（无界、实时），二者共用一套「不可变数据 + 派生」的世界观。对应现实里的 Hadoop / Spark 生态、数据仓库 ETL、离线特征与模型训练。

这章要解决什么

假设你要为一个上亿用户的网站做两件事：① 每天扫一遍 10 TB 的访问日志，算出「每个网页被访问了多少次、哪些是热门」；② 把用户行为喂进推荐系统，算出「猜你喜欢」。这类活的共同点是：数据大到单机存不下、算不完，但又允许「今晚跑、明早出」——不追求实时。

难点从来不是那两行统计逻辑，而是怎么驾驭一大群机器：如何把 10 TB 切开、公平地分给上千台机器并行啃；某台机器算到一半宕了，怎么不让整批白跑；中间半成品放哪、算完的结果怎么安全地全量替换旧结果。不解决这些，你要么被单机容量卡死，要么写一堆脆弱的、一台机器崩就全盘皆输的手工脚本。这一章给的，正是一套把「协调机群、容错、数据流」这些脏活标准化的通用骨架。

核心内容，讲透

一、Unix 哲学：批处理的祖师爷

别急着上分布式。作者先带你看一个 Unix 单机例子：从一份网站日志里揪出访问量最高的 5 个网址，一行命令就够：awk '{print $7}' access.log | sort | uniq -c | sort -rn | head。awk 抽出网址那一列，sort 把它们排成队（相同的挨到一起），uniq -c 数出每个出现几次，再 sort -rn 按次数倒排、head 取前几名。

这条管道藏着三条影响深远的设计原则（Doug McIlroy 提出的 Unix 哲学）：①每个程序只做一件事、做好（sort 只管排序，但排得极好——数据比内存大时它自动用磁盘做归并排序）；②一个程序的输出能当另一个的输入（用管道 | 串起来）；③统一接口——大家都读写纯文本行流，所以任意两个工具都能拼。MapReduce 几乎是这套哲学的分布式翻版：把「统一接口=文本流、组合=管道」换成「统一接口=HDFS 文件、组合=作业链」。

二、MapReduce：铺到上千台机器的「排序凑堆」

MapReduce 让你只写两个纯函数，剩下的机群调度、容错、数据搬运全由框架包办：

• Map：框架对输入里的每条记录调用一次你的 map，你从中挑出并吐出若干 (键, 值) 对。例：读一行日志，吐出 (网址, 1)。
• Shuffle（洗牌，框架自动做）：把所有 Mapper 吐出的键值对按键排序、并把同一个键的所有值聚到一起——这一步跨机器搬数据，是 MapReduce 的发动机。
• Reduce：框架对每个不同的键调用一次你的 reduce，把该键名下的一串值交给你汇总。例：(网址, [1,1,1,…]) → 求和 → (网址, 总次数)。

关键要看懂：「按键排序、把同键聚拢」这一步是整个模型的心脏。Mapper 把输出按目标 Reducer 分区（通常 hash(键) mod R，R 是 Reducer 数）、在本地排好序落盘；每个 Reducer 再把属于自己的那些分片从各 Mapper 拉过来、做归并——这样散落在上千台机器上的同一个键，最终一定在同一个 Reducer 处碰头。数据规模能有多大？开源的 Hadoop 曾在数千台机器上排序 1 PB 级的数据，正是这套机制在撑。

单个 MapReduce 作业只能表达「一进一出」的简单变换，真实任务（如推荐系统）往往要把几十个作业串成工作流——前一个的输出目录当后一个的输入，由 Airflow、Oozie 之类的调度器编排。Google 内部一个复杂流程曾串起约 50 个乃至更多的 MapReduce 作业。

三、连接（join）：批处理里最见功夫的一招

推荐、分析几乎都要 join：手上有一份「用户活动日志」（谁点了什么，海量），要拼上「用户资料表」（用户的年龄地区，相对小），才能算「各年龄段爱看什么」。在批处理里，你不能像在线数据库那样逐条去远程查资料表——上亿次网络往返会慢到天荒地老、还把数据库打垮。于是有了几套截然不同的 join 策略：

Reduce 端 join（sort-merge join，排序归并连接）：把两份数据都用 用户ID 当键喂进 Map，框架一洗牌，同一个用户的活动记录和资料记录自然聚到同一个 Reducer，在那里一拼即可。好处是不对输入做任何假设、通用；代价是两份数据都得完整排序、洗牌，开销大。

Map 端 join：如果小表（资料表）小到能塞进内存，就不必洗牌——广播哈希连接（broadcast hash join）把整张小表加载成哈希表、复制到每个 Mapper，Mapper 一边流式扫大表、一边查表拼上，全程无 Reduce。若两份数据已按相同方式分区，则用分区哈希连接（partitioned hash join），每个 Mapper 只需装载对应的那一片小表。Map 端 join 快得多，但前提苛刻（要么一边够小，要么两边分区对齐）。

热点键的坑：若某个用户是超级大 V、活动记录奇多，负责该键的那个 Reducer 会被压垮、拖慢整批（数据倾斜）。对策是「分片 / 倾斜 join」：把热点键的记录随机拆散到多个 Reducer 分头算，另一边数据复制多份配合——这与 Ch6 分区那章处理热点的思路一脉相承。

四、批处理输出的哲学：不可变输入 + 确定性 = 从容

批处理任务的产出通常是：建搜索索引（如为全站文档生成 Lucene 倒排索引文件）、批量构建键值存储（把算好的推荐结果、机器学习模型打包成只读文件，整体加载进线上服务库，如早期 LinkedIn 的 Voldemort 只读存储）。这里藏着本章最重要的思想，它直接呼应了 Unix 哲学：

• 输入不可变、只读：作业绝不原地修改输入，只往新目录写新输出。所以随便重跑、随便调试，不怕污染源数据。
• 算子确定、无副作用：给定相同输入，输出必然相同，且不会偷偷去改数据库、发邮件。于是任一任务失败，框架换台机器把这块重算即可（这也让「推测执行」——给慢任务开个备胎并行跑——成为可能）。
• 人为容错（human fault tolerance）：代码写错了？改完把整批重跑，或直接切回上一版旧输出——因为旧输入还在、旧输出也没被覆盖。这份「可回滚」是在线系统很难有的奢侈。

一句话：把「计算逻辑」和「读写线路」彻底分开，让数据流清清爽爽——正是这份克制，换来了批处理系统标志性的皮实与可维护。

五、超越 MapReduce：数据流引擎与迭代计算

MapReduce 一统江湖多年，但有个硬伤：每个作业都把中间结果完整写回 HDFS（还带副本），下一个作业再读回来。一个几十级的工作流，就要反复「落盘—读盘」几十趟；而且后一步必须干等前一步整个跑完才能起步。这叫中间状态的物化（materialization）——稳，但慢、且浪费。

数据流引擎（dataflow engines：Spark、Tez、Flink）把整个工作流看成一张算子图（DAG）一次性提交，于是能：不必每步都排序、不必落 HDFS 而是流水线式（pipelining）把数据直接递给下一个算子（或只留在内存），算子一有输入就开工。容错怎么办？不再靠「处处存副本」，而是靠谱系重算——记住每份中间数据是怎么算出来的（Spark 的 RDD 血缘），丢了就照着重算（前提是算子确定性）。官方基准里，迭代式作业（同一份数据反复算很多轮，如机器学习、图算法）靠把数据留在内存，能比 MapReduce 快一个数量级。

还有两类专门化：迭代 / 图计算用 Pregel 模型（又称批量同步并行 BSP）——每个顶点给邻居发消息、一轮轮迭代到收敛，天生适合 PageRank、最短路径这类要反复扫图的算法。高层 API——没人愿意天天手写 map/reduce，于是 Hive、Pig、Spark SQL、Flink Table 让你写声明式的类 SQL，由查询优化器自动选 join 算法、排执行计划（这正呼应了 Ch2「声明式胜过命令式」的主题）。

关键权衡与选型

批处理的选型，本质是在通用性、速度、容错代价、上手门槛之间做取舍。三张表把最常考、最实用的对比拎出来。

表 1 · MapReduce vs 数据流引擎（Spark / Tez / Flink）

表 2 · 三种 join 策略怎么选

表 3 · 三类数据系统：批处理放在哪

为什么重要 / 落到真实系统

批处理是整个大数据生态的地基。Google 的 MapReduce + GFS（2003–2004 两篇论文）直接催生了开源 Hadoop（HDFS + MapReduce），让「用一堆廉价机器啃 PB 级数据」从 Google 的独门秘技变成人人可用的基础设施。此后 Hive（SQL-on-Hadoop）、Spark（数据流引擎）、Flink 层层演进；今天的数据仓库 ETL、离线特征工程、推荐 / 广告的离线训练管线，骨子里都是这一章的思想。面试里，「MapReduce 的 shuffle 在做什么」「reduce-side 和 map-side join 怎么选」「为什么 Spark 比 MapReduce 快」几乎是数据岗必考题——答案全在本章。

易错点与争议

• 「MapReduce = 大数据」是过时印象：它开创了范式，但因反复落盘、表达力弱，如今在多数场景已被 Spark / Flink 等数据流引擎取代；连 Google 自己都早已转向后继系统。学它是学思想，不是学要上线的技术。
• 把 shuffle 当小事：新手以为瓶颈在 map/reduce 的逻辑，实则洗牌（跨机排序搬运）往往才是最贵的一环，也是数据倾斜（热点键）最容易爆炸的地方。
• join 策略选错：明明一边小到能进内存，却用了 reduce-side sort-merge，白白多排序洗牌一整轮——一大一小的 join 该优先广播哈希。
• 误以为批处理能干实时：它天生有界、有延迟（等整批算完），要「数据来一点算一点」得靠流处理（Ch11）。二者不是替代而是互补——著名的 Lambda 架构 就想同时用批和流，但也因维护两套逻辑而饱受争议。
• 时代局限：本章 2017 年成书，此后云上的对象存储（S3）取代自建 HDFS、Spark / Flink 进一步成熟、批流一体（如 Flink、数据湖 Iceberg / Delta）成为新潮流；但「不可变输入 + 派生结果」的世界观至今不过时。

要点