这一章在做什么

读之前：先预测

前面十章大多在讲请求和响应：在线系统收到请求，尽快给出结果。这一章换一种做法，也是全书「派生数据」这一块的开头。第 1 章分过「记录系统」和「派生数据」，批处理的输出就是派生数据；第 4 章的 LSM 树、有序段的合并、云数仓，在这里会以集群的规模再出现一次；第 7 章的按键哈希分片，就是洗牌把数据分给各个任务的办法。下一章把输入从有限的一批换成永不结束的流，第 13 章再把批处理和流处理放进同一套数据集成的思路里。

1. 内存哈希表和排序都能做计数。各在什么条件下更合适？§1.3
2. 对象存储和分布式文件系统，哪些操作看起来一样、其实不一样？§2.2
3. 两个 mapper 吐出同一个键，框架怎么保证它们落到同一个 reducer？排序在这里起什么作用？§3.3§3.4
4. 批处理的结果为什么不该在任务里一条条写进线上数据库？§4.4

这一章的骨架

这一章先在一台机器上把问题讲清（§1），再借「分布式操作系统」的类比，依次讲集群上的存储、编排、计算三层（§2–§3），最后是用途（§4）。容易乱的是 §2.3 和 §3：前者很长，调度、工作流、容错三件事混在一节里；后者从 MapReduce 讲到 SQL，中间的 §3.3 洗牌才是机制的核心，读到那里要回头和 §1.3 的排序对上。

边读边填：每行一个问题，读到答案就写一两句。只存在你这台设备的浏览器里，别人看不到。

分节地图

全章约 1.2 万词，建议分四次读。第一次是热身，命令行和存储都不难；第二次的 §2.3 最长，可以在小标题处喘口气；第三次是机制的核心，慢一点读；第四次几个用途彼此独立，§4.4 最值得细读。

1. 第一次坐下§0–§2.2 · 约 3900 词 · 从一台机器的命令行到集群上的存储
2. Much of this book so far…约 1100 词开篇在线系统和批处理的分别，输入只读带来的好处，MapReduce 之后的变化和全章路线。
3. Batch Processing with Unix Tools约 200 词用 Unix 工具做批处理一行网页服务器日志里有什么，为什么日志分析是批处理的老本行。
4. Simple Log Analysis约 400 词简单的日志分析一串命令找出最热门的页面。只看每一步做了什么，不用记命令。
5. Chain of Commands Versus Custom Program约 200 词命令链和自己写程序同一件事写成一段脚本。语法的差别是表面的，执行方式的差别在下一节。
6. Sorting Versus In-Memory Aggregation约 400 词排序和内存里聚合哈希表和排序各在什么时候合适，工作集是什么。全章排序这条线的起点。
7. Batch Processing in Distributed Systems约 100 词分布式系统里的批处理一台机器上的文件系统、调度器、管道，到集群上各对应什么。
8. Distributed Filesystems约 900 词分布式文件系统和本地文件系统一层层对照：块、缓存、元数据、协议；方框讲共享磁盘和无共享。
9. Object Stores约 700 词对象存储对象存储和文件系统哪里不同：对象不可变、没有真目录、改名、计算和存储分开。
10. 第二次坐下§2.3–§3.2 · 约 3400 词 · 调度和容错，MapReduce 和数据流引擎
11. Distributed Job Orchestration约 2000 词分布式作业编排编排器的三个部件，资源怎么分配，工作流的调度，任务失败了怎么办。全章最长的一节。
12. Batch Processing Models约 100 词批处理的模型两种最常见的处理模型，以及为什么还要先懂 MapReduce。
13. MapReduce约 700 词MapReduce 模型mapper 和 reducer 各做什么，怎样和前面命令行的例子一一对上。
14. Dataflow Engines约 500 词数据流引擎Spark、Flink 这类引擎把整个工作流当一个作业，比 MapReduce 省在哪。
15. 第三次坐下§3.3–§3.6 · 约 2300 词 · 洗牌和连接，再到 SQL 和 DataFrame
16. Shuffling Data约 700 词洗牌分布式排序：map 的输出怎么按键分给各个 reduce。全章机制的核心，配合下面的模拟器读。
17. Joins and Grouping约 600 词连接和分组排好序之后，reducer 怎么一次拿到一个键的全部数据，做连接和聚合。
18. Query Languages约 800 词查询语言SQL 怎样成了批处理的共同语言；方框讲批处理和云数仓怎么越走越近。
19. DataFrames约 300 词DataFrame 数据框DataFrame 从单机搬到分布式之后，哪些地方和原来不一样。
20. 第四次坐下§4–§5 · 约 2500 词 · 批处理拿来做什么，结果怎么交出去
21. Batch Use Cases约 200 词批处理的用途什么样的活适合批处理，几个行业里的例子。
22. Extract–Transform–Load约 400 词抽取、转换、加载批处理做 ETL 的几个长处；数据流水线不再只归一个团队管。
23. Analytics约 300 词分析在批处理系统上跑分析查询：预先聚合和临时查询两种用法。
24. Machine Learning约 500 词机器学习特征、训练、批量推理、图计算，以及大模型训练前的数据处理。
25. Serving Derived Data约 700 词把派生数据交给线上算好的结果怎么送回线上：为什么不逐条写库，流和批量导入各管什么。
26. Summary约 400 词小结全章回顾。先自己回忆一遍再读它。

先用中文过一遍

输入只读、输出重算：批处理敢重跑的前提

在线数据库里，一个写错数据的 bug 上线了，把代码回滚也收不回那些错数据。批处理作业把输入当成只读的，每次运行都从头生成输出，也不去改外部系统，于是出了错的补救很简单：修好代码，删掉坏的输出，再跑一遍。旧的输出还留着的话，直接切回去也行。这一条贯穿全章：任务失败时只要把它的半截输出删掉、换台机器重跑；工作流里上下游之间靠文件交接；结果要交给线上系统时，麻烦也恰好出在「往外写」这一步（§4.4）。代价是哪怕输入只改了一个字节，也得把整份输入重新处理一遍。

计数的两种做法：哈希表，还是先排序

统计「每个商品卖出了几单」，最直接的办法是一个内存哈希表，读一行加一次。它要的内存只取决于有多少个不同的商品，和明细有多长无关；书里把一个作业需要随机访问的那部分内存叫工作集（working set）。另一种办法是先按商品排序，相同的商品就挨在一起了，从头扫一遍、数相邻的就行。排序的好处在内存不够时显出来：在内存里排好一块，写成一个有序段，最后把几个段归并，读写盘全是顺序的。这正是第 4 章 LSM 树刷盘、合并的那一套。分布式批处理选了排序这条路，原因也在这里。

map、洗牌、reduce：同一个键怎么凑到一起

把计数搬到集群上，输入已经切成很多分片，每个分片交给一个 map 任务。map 任务对每条记录调用一次你写的 mapper，吐出若干个「键，值」对，记录之间不留任何状态。难点在下一步：两个 map 任务都吐出了「杭州」，怎么让它们最后由同一个 reduce 任务处理？办法是每个 map 任务给每个 reduce 任务在本地盘上单独写一个文件，用键的哈希值决定一条记录进哪个文件，文件里的记录边写边排好序。map 跑完后，每个 reduce 任务去各个 map 那里把属于自己的文件拉过来，归并成一个有序序列，同一个键就挨在一起了，然后对每个键调用一次 reducer。这个「分桶、排序、拉取、归并」的过程就叫洗牌（shuffle），它其实是一个分布式排序，和洗扑克牌的「打乱」正好相反。

MapReduce 把这套 map、洗牌、reduce 做成固定的一步，复杂的计算就串成好几个作业，每个作业的输出写回分布式文件系统，下一个作业再读。数据流引擎（Spark、Flink）把整条工作流当成一个作业：只在真需要的地方排序，中间结果尽量放在内存或本地盘，下游不用等上游整个跑完。读 §3.2 时，留意它为此在容错上换了什么办法（§2.3 的末尾已经提了一句）。

用排序做连接：reducer 一次只看一个键

两张大表连接，比如几十亿条订单要按商家 ID 连上商家资料，拿到商家所在的城市。逐条订单去查商家表，就是几十亿次网络请求。洗牌给了另一条路：两张表各用一个 mapper，都把商家 ID 当键吐出来，订单那边的值是金额，商家那边的值是城市。洗牌之后，同一个商家的资料和它的全部订单到了同一个 reducer，还可以让框架把商家那条排在最前面（二次排序）。reducer 先记下城市，再把后面每条订单配上城市写出去，内存里任何时候只有一个商家的资料。下一个作业再按城市洗牌，就能算每个城市的订单额。

这一章点名的系统

动手：模拟器

先猜：48 条订单里将近一半属于同一个商家（分布选「一个热键」）。reduce 任务从 2 个加到 6 个，reduce 阶段的用时能缩短到原来的几分之一？换成「均匀」分布再猜一次。猜好了，点「跑完」，再拖滑杆验证。书里这一章没有专门讲倾斜，它的道理在第 7 章 §3.3；这里看的是它在洗牌里的样子。

1. 选「一个热键」，点「跑完」，把 reduce 任务数从 2 拖到 6，记下「最忙的 reduce」每次是多少。它最低能降到多少？为什么降不到平均值？
2. 换成「均匀」，把 reduce 任务数拖到 5，再点「换一批数据」几次。没有热键时，各个 reduce 的条数也不一样多，甚至有一个一条都没分到，原因在哪？
3. 回到「一个热键」，勾上「拆开最热的键」（第 7 章 §3.3 讲的加随机后缀）。最忙的 reduce 降了多少？多出来的第二轮在做什么？如果两个子键碰巧落到同一个 reduce 上，又会怎样？

词与短语

词条按在书里出现的顺序排，按节分组；读一节之前先把这一节的过一遍，读的时候就不用停。斜体小字是原句里连续的几个词，在电子书里搜它就能找到那一句。标着「每个字都认识」的，是字面意思会把你带偏的。行话（compaction、quorum 这类）不在这里，在上面的术语表里。

§0 Much of this book so far…

§1 Batch Processing with Unix Tools

§1.1 Simple Log Analysis

§1.2 Chain of Commands Versus Custom Program

§1.3 Sorting Versus In-Memory Aggregation

§2.1 Distributed Filesystems

§2.2 Object Stores

§2.3 Distributed Job Orchestration

§3 Batch Processing Models

§3.1 MapReduce

§3.2 Dataflow Engines

§3.3 Shuffling Data

§3.4 Joins and Grouping

§3.5 Query Languages

§3.6 DataFrames

§4 Batch Use Cases

§4.1 Extract–Transform–Load

§4.2 Analytics

§4.3 Machine Learning

§4.4 Serving Derived Data

读完：回到你的预测

判断题：换成你来选

场景都是本站编的。先选，再看解释；解释里写了对应的节号，拿不准就回原书看那一节。

和本站其他书对照

值得停下来的句子

if you deploy buggy code that writes bad data to the database, rolling back the code will do nothing to fix that data.— §0。本站译：如果你上线了往数据库里写坏数据的 bug，回滚代码对修复那些数据毫无作用。

这句话说的是在线数据库，衬出来的是批处理最大的好处。批处理不改输入，只从头生成输出，坏数据可以整份扔掉重算。全章后面很多设计都靠这一点：任务失败了只重跑一个任务，工作流的上下游靠文件交接，§4.4 一再强调别从任务里直接写外部系统，因为那样就把这个好处丢了。

MapReduce was a step forward … but now it is largely obsolete and no longer used at Google.— §0。本站译：MapReduce 曾是一大进步……但现在它基本已经过时，Google 自己也不再用了。

值得停下来，是因为这一章仍然花了不少篇幅讲 MapReduce。作者的理由在 §3：后来的数据流引擎和云数仓都继承了它的思路，尤其是洗牌。读的时候把 MapReduce 当成一个讲清机制的最小模型，而不是一个推荐你去用的系统。

检查一下理解

用一句话说这一章（写给一个没读过的朋友）：

精彩回顾

一句话：批处理读只读的输入、从头算出输出，靠洗牌这个分布式排序把同一个键的数据送到一起，出了错就重跑。