企业官网建设流程全解析

数据量涨到单机彻底扛不住的那一年，我第一次认真去读 MapReduce 的原始论文。当时的心态很功利：只要能把那个跑了两天的统计任务压到几小时，怎么都行。结果第一版作业跑完，耗时不但没降，反而因为大量小文件触发了上千个 map 任务，集群调度排队排了一下午。那次之后我才明白，MapReduce 的“原理”不是一个可以背下来的流程图，而是一堆相互牵制的约束条件：切片怎么划、键值对怎么流、shuffle 怎么落地磁盘、失败任务怎么重试，每一个选择都在悄悄改变作业的耗时和稳定性。这篇内容就是我这些年把 MapReduce 拆开、揉碎、再重新拼起来的完整记录，从它要解决的根本问题讲起，一路讲到 shuffle 内部的缓冲区、溢写、归并，再到调度层的容错与本地性，最后给出可以直接照着调的参数清单和自己的踩坑笔记。不管你是刚接触分布式计算、只会写 WordCount 的新手，还是已经能改源码、但总觉得某些现象解释不清的老手，应该都能在里面找到几段对你有用的东西。

1. 单机统计撞墙之后，MapReduce 到底在解决什么问题

1.1 把一个最朴素的统计需求拆开看

先不谈框架，就拿最常见的场景说：一批日志文件，总量按 TB 算，要统计每个访问来源出现了多少次。单机写法谁都会，读文件、按行切分、取字段、累加到一张哈希表、最后输出。代码不到五十行，逻辑一眼可见。问题出在数据规模跨过某个临界点之后：磁盘读不完、内存装不下、CPU 核数吃不满，三个瓶颈同时出现，而且互相叠加。你把文件拆成十份并行跑，单机 I/O 通道就那么宽，十个线程抢同一块磁盘，速度并不会变成十倍，反而因为随机读变多而更慢。

真正的出路只有一条：把数据分散到多台机器上，每台机器只读自己本地的那部分，各自算各自的局部结果，最后再汇总。这就是 MapReduce 藏在名字后面的全部思想——分而治之，然后把“移动数据”换成“移动计算”。这个转变听着简单，但它带来的收益是数量级的：一百台机器各读自己本地磁盘上的 1%，总吞吐理论上就是单机的一百倍，而且不需要把 TB 级数据通过网络搬到某台中心机器上去。

我见过不少人把 MapReduce 理解成“一个能并行的 for 循环”，这个理解在写 demo 时没问题，一旦上生产就会出大问题，因为它完全忽略了“局部结果如何汇总”这一半的工作量，而这一半恰恰是整个框架最复杂的地方。

所以更准确的说法是：MapReduce 定义了一套编程模型和一套执行引擎。编程模型只给你两个接口，map 和 reduce，让你把业务逻辑塞进去；执行引擎负责切片、调度、传输、排序、容错、重试这些脏活。你写的那几十行代码之所以能在上千台机器上跑起来，靠的是引擎而不是模型。

1.2 并行化之后冒出来的三个新麻烦

把计算拆到多机之后，原先不存在的问题立刻浮出水面，而且每一个都很硬。

第一个是切分粒度。一份 1TB 的数据切多大一块交给一个任务？切太大，任务数少，机器闲着，还容易因为单个任务失败导致整体回滚代价高；切太小，任务数暴涨，调度开销、JVM 启动开销、文件打开开销全部放大。这个取舍不是拍脑袋定的，后面会讲到它其实是由底层存储的块大小驱动的。

第二个是中间数据的传输。map 算出来的局部结果怎么送到正确的 reduce 那里？如果按 key 的哈希随便发，网络会被打爆；如果全部发给一个节点再转发，那个节点就是单点瓶颈。这里必须有一套“先分区、再按分区归并”的机制，这就是 shuffle 的由来。

第三个是聚合的语义。同一个 key 的局部结果散落在几十台机器上，最终要合并成一个值。合并操作必须满足结合律，否则不同合并顺序会得到不同结果。这一点经常被忽略，直到有人在 reduce 里做了非幂等操作，重试一次结果就翻倍，才开始回头补课。

理解了这三个麻烦，后面所有的机制设计就都顺理成章了：它们不是凭空加出来的复杂度，而是针对具体问题的必要代价。

2. 一次作业从提交到产出，中间到底经过了哪几道关

2.1 切片不是切文件，MapTask 数量由它决定

新手最容易搞混的一对概念是“块”和“切片”。块是底层存储层面的物理划分，比如默认 128MB 一块，它是数据存放的单位；切片是计算层面的逻辑划分，一个切片对应一个 map 任务，切片只记录“从哪个文件的哪个偏移开始，读多长”，并不真的把数据切开复制一份。

切片大小的计算规则大致是这样：先取块大小作为基准，然后用配置的最小切片值和最大切片值把它夹住，也就是在最小值、块大小、最大值三者之间取一个合理的中间值。默认情况下最小值很小、最大值极大，所以切片大小基本就等于块大小。这意味着一个 128MB 的块通常正好对应一个切片、一个 map 任务，数据在本地读，不走网络，这就是所谓的数据本地性。

但这条规则有个例外：切片不会跨文件。假如你有一万个 10MB 的小文件，每个文件都会被单独切成一片，于是产生一万个 map 任务，而每个任务真正处理的数据只有 10MB，远小于块大小。这就是臭名昭著的“小文件问题”，我第一次踩坑就是栽在这上面。

一万个 map 任务是什么概念？每个任务启动一个 JVM，光是 JVM 启动和销毁的开销就能吃掉大量时间，更别提调度器要维护上万个任务的状态。我那次的实际观测是：真正用于计算的时间不到总耗时的三成，剩下七成全是任务启动、排队和收尾。解决办法有两个方向，一是在入库时就把小文件合并成大文件，二是在读取端使用支持合并的输入格式，把多个小文件打包进同一个切片。前者治本，后者救急，生产上通常两个都做。

2.2 map 的输入输出为什么必须是键值对

很多人写第一个作业时会疑惑：为什么输入非得是“偏移量 → 一行文本”这种奇怪的形态？偏移量对业务毫无意义，为什么要强制给出来？

原因在于框架需要一套统一的、可序列化的、可比较的数据抽象，才能在上面搭建分区、排序、归并这一整套机制。键值对恰好满足：键可比较，所以能排序；键值都可序列化，所以能落盘和跨网络传输；键决定分区，所以同一个键必然流向同一个 reduce。偏移量作为键，只是文本输入格式的一个默认约定，它保证了同一文件内的行是有序的，某些需要行序的场景能用到。

map 函数的输出同样必须是键值对，而且这里的键才是真正决定数据去向的东西。框架会对 map 输出的每一个键值对做三件事：根据键计算分区号、在分区内按键排序、把结果写到本地磁盘。注意，map 的输出不写回分布式存储，只落在执行该任务的机器本地磁盘上，这是一个非常关键的设计，因为中间数据是临时的，写三副本太浪费，写本地一份、失败了重算就行。

从这里能引申出一个实战经验：map 输出的键值对数量往往远大于输入行数。比如解析一行日志产出十个统计项，那就是一比十的放大。如果你的 map 有这种放大效应，就要特别留意内存和磁盘的压力，因为所有的放大都会实打实地落到 shuffle 上。

2.3 reduce 端拿到的是什么，又该吐出什么

reduce 函数接收的是“一个键 + 这个键对应的所有值的迭代器”。这里有个细节值得说清楚：那个迭代器不是一次性把值全部加载进内存的，它是流式的，边归并边吐。所以你在 reduce 里不能假设值的顺序，也不能两次遍历同一个迭代器，第二次遍历会拿到空。这个坑我踩过，当时想把值先收集到列表里排序，结果内存爆了；正确做法是在 map 阶段就把需要排序的信息编进键里，让框架替你排。

reduce 的输出一般直接写入分布式存储，属于最终结果。输出目录必须不存在，否则作业直接报错退出，这个设计是为了防止误覆盖，我第一次跑作业时因为目录已存在排查了半小时，最后发现错误信息里写得明明白白，只是没细看。

还有一个常被忽略的点：reduce 的个数决定了最终输出文件的数量。设 10 个 reduce，输出目录下就有 10 个结果文件。如果下游还要接着处理，文件数太多又会变成新的小文件问题；设 1 个 reduce 则所有数据挤到一个任务里，完全丧失并行度。这个数字的选择后面单独讲。

2.4 用一段最小代码把整条链路串起来

抽象讲完，落到代码上其实很短。下面这段统计词频的骨架，几乎把所有关键角色都体现出来了：

public class TokenCount { // map：输入是 行偏移 -> 一行文本，输出是 词 -> 1 public static class TokenMapper extends Mapper<LongWritable, Text, Text, IntWritable> { private final static IntWritable ONE = new IntWritable(1); private Text word = new Text(); @Override protected void map(LongWritable offset, Text line, Context ctx) throws IOException, InterruptedException { // 按非字母字符切分，逐词发射 for (String token : line.toString().split("[^a-zA-Z]+")) { if (token.isEmpty()) continue; word.set(token.toLowerCase()); ctx.write(word, ONE); // 这一步进入环形缓冲区 } } } // combine：在 map 端先做一次局部聚合，减少网络传输量 public static class TokenCombiner extends Reducer<Text, IntWritable, Text, IntWritable> { @Override protected void reduce(Text key, Iterable<IntWritable> values, Context ctx) throws IOException, InterruptedException { int sum = 0; for (IntWritable v : values) sum += v.get(); ctx.write(key, new IntWritable(sum)); } } // reduce：同一个词的局部结果在这里合并成最终计数 public static class TokenReducer extends Reducer<Text, IntWritable, Text, IntWritable> { @Override protected void reduce(Text key, Iterable<IntWritable> values, Context ctx) throws IOException, InterruptedException { int sum = 0; for (IntWritable v : values) sum += v.get(); ctx.write(key, new IntWritable(sum)); } } }

这段代码里 combiner 和 reducer 逻辑完全一样，很多人就直接复用了，这在求和场景下没问题，但换成求平均值就会出错，后面会详细解释为什么。

3. Shuffle 才是重头戏：缓冲区、溢写和三次归并

3.1 环形缓冲区：map 输出并不是直接落盘

map 函数每调用一次write，数据并不会立刻写到磁盘，而是先进入一块环形内存缓冲区。默认大小 100MB，当写入量达到容量的某个比例（默认 0.8，也就是 80MB）时，一个后台线程被唤醒，把当前缓冲区里的数据整理成有序的溢写文件。

这个“整理”包含两步，顺序不能反：先按(分区号, 键)排序，再按分区号切成若干段写出去。为什么必须先分区再排序？因为 reduce 拉取数据时是按分区拉的，如果溢写文件里分区是混在一起的，reduce 就得读整个文件再过滤，白白浪费 I/O。为什么排序不能省？因为 reduce 端要对同一个键的所有值做归并，如果数据有序，归并只需要一次线性扫描，无序就得反复读盘。

那几个参数值得记住，因为它们直接决定了溢写次数：

100MB 乘以 0.8 等于 80MB，也就是说每写满 80MB 就要落一次盘。假设一个 map 任务的输出是 800MB，那就至少产生十次溢写，最后这十个文件还要再合并成一个大文件。所以“map 输出量大”这件事，代价不只是磁盘空间，而是成倍的写放大。适当调大缓冲区是最简单有效的优化之一，但要注意给任务本身留足堆内存，否则容易 OOM。

3.2 reduce 端的三次合并与拉取时机

reduce 任务启动后并不会立刻开始计算，它要先把属于自己的数据从各个 map 机器上拉过来。这个过程由若干拉取线程并行完成，默认并发数不大，网络带宽充足时可以适当调高。

拉回来的数据不会一次性全塞进内存，而是边拉边归并，整个链路上大概经历三次合并：第一次是在内存里把拉到的多个小段合并；第二次是内存装不下时溢写到磁盘，磁盘上形成若干合并后的文件；第三次是把磁盘上的这些文件做最终归并，形成一条有序的数据流喂给 reduce 函数。所谓“reduce 阶段”实际上从拉取就开始了，真正调用 reduce 函数只是最后那一小段。

这里有个常见误判：看到作业卡在 reduce 阶段很久，就以为是 reduce 函数写得慢。实际上大部分时间花在拉取和归并上，而非业务逻辑。判断方法很简单，看计数器里 reduce 输入记录数和实际输出记录数的比例，如果输入很多输出很少，那确实是计算密集；如果输入也迟迟不涨，那就是卡在拉取环节，八成是某些 map 输出太大，或者网络成了瓶颈。

3.3 Combiner 能省多少网络流量，什么情况下会算错

combiner 的本质是“在 map 端提前做一次 reduce”。它能把同一个 map 内相同键的值先合并，输出的数据量可能从一百万条降到一万条，网络传输量直接砍掉两个数量级。在词频统计这种场景下，开启 combiner 往往能把作业耗时压掉一大半，这是性价比最高的优化之一。

但它有个硬性前提：合并操作必须满足结合律和交换律。求和、求最大值、求并集都满足；求平均值不满足。原因很直白：平均值不满足结合律，先分组求平均再求平均，和整体求平均结果不一样。举个具体例子，键 A 在三个 map 上分别出现 (10, 1次)、(20, 3次)、(30, 1次)，整体平均是 (10+20×3+30)/5=20；如果每个 map 先算平均得到 10、20、30，再对这三个数取平均是 20，看起来碰巧一样，但只要各 map 的数据量不同就会立刻出错，换成 (10,1次)、(20,10次)、(30,1次)，整体是 235/12≈19.6，而先平均再平均是 20。

正确做法是把“次数”也带进值里，让 combiner 合并的是 (和, 次数) 这个二元组，最后在 reduce 里再做一次除法。这个技巧在算分位数、算方差时同样适用，本质是把不满足结合律的运算拆成满足结合律的部分和最终一步归约。

另一个容易忽略的点：combiner 不保证一定被执行，框架可能因为溢写次数、数据量等原因跳过它。所以 reducer 的逻辑必须能正确处理未经 combiner 的原始数据，不能依赖 combiner 一定跑过。

4. 容错与调度：任务挂了之后，集群悄悄做了什么

4.1 四类失败情形和各自的处理方式

分布式环境下，失败是常态而不是异常。MapReduce 把失败分成几类，处理策略各不相同。

第一类是map 或 reduce 任务抛异常。框架会把这次尝试标记为失败，换一台机器重试，默认最多四次。如果四次都失败，整个作业被判定为失败。这里有个坑：如果异常是数据本身导致的（比如某一行格式畸形），那换多少台机器都会在同一个地方失败，重试四次纯属浪费时间，正确的做法是在代码里捕获并跳过脏数据，同时用计数器记下跳过的条数，方便事后核对。

第二类是任务卡住不返回。框架检测不到心跳，会认为任务失联，主动杀掉并重试。这种情况常见于代码里有死循环、或者外部依赖（比如某个远程服务）超时时间没设。

第三类是机器层面的故障。执行 map 的机器挂了，它本地的中间数据就没了，但没关系，map 的输出是可以重新计算的，换台机器重跑这个 map 即可。这也是为什么中间数据不需要多副本——重算的成本低于维护副本的成本。但如果挂的是执行 reduce 的机器，已经产出的部分结果会丢失，reduce 也要重跑。

第四类是作业提交者本身退出。这种情况作业会被杀掉，除非配置了让作业独立运行。

4.2 推测执行：用冗余计算换长尾收敛

集群里总会有那么几个任务跑得特别慢，原因可能是磁盘坏道、可能是宿主机负载高、也可能是数据倾斜。如果不管，整个作业的完成时间就被这几个慢任务拖住，这叫长尾效应。

推测执行的思路很直接：当框架发现某个任务明显落后于同批次任务的平均进度时，就在另一台机器上启动一个一模一样的备份任务，谁先完成就用谁的结果，另一个直接杀掉。这个机制对长尾非常有效，但也不是没有代价：它会额外消耗集群资源，在资源紧张的时候反而加剧排队。

所以在资源吃紧的集群上，我通常会关掉 reduce 的推测执行而保留 map 的，因为 reduce 备份意味着要重新拉一遍数据，代价太高；而 map 备份通常只重算本地数据，相对便宜。当然这也不是铁律，要看具体作业的瓶颈在哪。

4.3 一例真实的慢作业排查链路

说一个印象比较深的排查过程。一个日终统计作业，平时四十分钟跑完，某天突然变成三个半小时。集群资源没变，数据量只涨了百分之五。

第一步先看任务分布，发现绝大多数 map 十分钟内就完成了，只有三个 map 跑了两个小时还没结束。三个任务分布在三台不同机器上，排除了单机硬件问题。

第二步看这三个任务的输入，发现它们各自处理的是一个特别大的文件，大小是其他文件的二十倍。问题初步定位：数据分布不均，切片大小虽然一致，但文件数量差异导致这三个任务摊到的数据量远超平均。

第三步深入看，发现这三个任务的输入是压缩文件，而且压缩格式不支持分片。不支持分片的压缩文件，无论多大都只能由一个 map 处理，这就彻底解释了两个小时的耗时。换成支持分片的压缩格式后重新入库，问题消失。

这个案例的教训是：压缩格式的选择在入库那一刻就决定了下游的并行度，等到作业跑慢了再回头改，成本已经很高了。支持分片的格式意味着框架可以在任意位置切分并独立解压，不支持分片的格式则必须整块处理，这是很多人搭数据管道时不会提前考虑的一点。

5. 三个流传很广的误读，以及它们对应的真实代价

5.1 误读一：map 数越多，并行度越高，跑得越快

这个说法在任务数远小于可用槽位时成立，一旦超过就完全反过来了。每个 map 任务的固定开销包括 JVM 启动、输入格式初始化、缓冲区分配、任务状态上报，这些和实际处理的数据量无关。任务数翻倍，固定开销也翻倍。当单个任务处理的数据量只有几十兆时，固定开销可能占到总耗时的一半以上。

合理的做法是让每个 map 任务处理的数据量接近一个存储块的大小。数据量除以块大小，大致就是合理的任务数。如果你手上有大量小文件，优先做入库合并，退而求其次用支持多文件合并的输入格式，把多个小文件打包进一个切片。这两种手段我都在生产环境用过，前者效果更彻底，后者改动成本更低。

顺带说一句，JVM 重用也是个有用的开关。默认每个任务启动一个新 JVM，把重用次数调大甚至设为不限，可以让同一个 JVM 连续跑多个任务，省掉反复启动的开销。在任务数很多、单个任务又很短的情况下，这个开关的效果非常明显。

5.2 误读二：reduce 个数随便设，反正会自动分配

reduce 的个数直接决定三件事：输出文件数量、单个 reduce 要处理的数据量、以及整个 shuffle 的并行度。设得太少，所有数据挤到少数几个 reduce 上，最后阶段严重串行；设得太多，每个 reduce 都要建立自己的拉取连接、申请自己的缓冲区，调度和内存开销上升，输出一堆小文件。

一个在实践中被反复验证的经验区间是：reduce 个数取“集群可用容器数乘以一个略小于一的系数”，或者“乘以一个略大于一的系数”，前者让所有 reduce 一轮跑完，后者让快的 reduce 跑第二轮来平衡长尾。这个系数不是玄学，它对应的是两种不同的调度策略：一轮跑完追求最短总时长但容易受长尾拖累，两轮跑完牺牲一点并行度换取更均衡的负载。

还有一个隐含约束容易被忘：reduce 个数不能超过分区数。分区数默认等于 reduce 个数，所以一般不会出问题；但如果手动指定了分区函数并返回固定的分区数，而 reduce 个数设得比它多，多出来的 reduce 会拿到空数据，白跑一趟。

5.3 误读三：所有计算都能套进这个模型

MapReduce 的模型约束很强：只有一轮 map、一轮 reduce，数据流是一张简单的有向无环图，中间必须落盘。这个约束在批处理场景下是优点，因为落盘带来了容错能力和确定性；但在其他场景下就是硬伤。

迭代计算是第一个不适合的场景。机器学习里很多算法要迭代几十上百轮，每一轮都要读一遍全量数据。MapReduce 每轮都要从磁盘读、往磁盘写，几十轮下来 I/O 成本高到无法接受。这也是后来基于内存的 DAG 引擎能迅速取代它的主要原因。

低延迟查询是第二个。MapReduce 的启动开销以秒甚至分钟计，无论数据多小，一次作业的固定成本都在那摆着。用它做交互式查询，就像开卡车去买一瓶酱油。

图计算是第三个。图的遍历天然依赖邻居关系，而 MapReduce 的模型里节点之间无法直接通信，只能靠一轮轮的全局 shuffle 传递消息，效率极低。

反过来说，判断一个任务该不该用这个模型，我会问三个问题：数据量大到单机处理不了吗？逻辑能不能拆成互不依赖的局部计算？对延迟的容忍度是不是在分钟级以上？三个都是“是”，那就合适；只要有一个是“否”，就该考虑别的方案。

6. 照着改就能见效的参数清单和实测心得

6.1 一份我常用的调参对照表

调参这件事最怕盲目，看到一个参数就调，最后不知道是哪个起了作用。我的习惯是先定位瓶颈在哪个阶段，再针对性调整。下面这张表是我这些年反复用到的一组对照关系，参数名做了通用化处理，不同发行版可能略有差异，但含义是一致的。

6.2 数据倾斜：那个只有真正跑过才懂的坑

所有坑里，数据倾斜是最难缠的一个。它的表现很典型：99% 的 reduce 十几分钟就完成了，剩下一个跑了三个小时还没结束。原因是某个键的值特别多，比如日志里某个来源标识占了总记录数的四成，这些记录全被分到同一个 reduce 上。

解决思路有几条，我按实际使用的优先级排一下。

第一优先是加盐打散。给热点键拼接一个随机后缀，让它在 map 端被分到多个分区，reduce 端先做局部聚合，然后再起第二个作业把加了后缀的键合并回去。这个方案效果最好，代价是要多跑一个作业，代码也要改。

第二优先是map 端预聚合。如果业务允许，在 map 阶段就对这个热点键做一次强聚合，把数据量压下去再发出去，combiner 就是这个思路的实现。它不改分区逻辑，改动最小，但只在聚合语义成立时有效。

第三是单独处理。把热点键的数据单独抽出来用另一个作业跑，剩下的用主作业跑，最后合并结果。这个方案最土，但在紧急情况下最管用，我就用这招救过一次日终任务的场。

加盐方案有个细节要注意：后缀的取值范围要和分区数匹配。取 10 个后缀而 reduce 只有 3 个，那 10 份数据还是会挤到 3 个 reduce 上，等于没打散。反过来取 2 个后缀而 reduce 有 100 个，那打散效果也很有限。

6.3 观察作业健康度的几个关键指标

不看指标盲目调参是浪费时间。我每次接手一个新作业，第一件事就是把几个计数器加进监控。map 输入记录数能反映切片是否合理，如果某个任务的输入记录数远超平均，说明数据分布有问题。map 输出记录数和输出字节数放在一起看，能算出平均每条记录多大，太大就意味着序列化开销高，要考虑用更紧凑的类型或者提前做字段裁剪。reduce 输入记录数和输出记录数的比值，能判断 reduce 到底在做聚合还是在做透传，比值接近 1 说明大部分工作其实在 map 端就该做掉。

还有一个不太被重视但很有用的信号：溢写次数。它直接反映内存压力。溢写次数突然翻倍，往往意味着数据特征变了，比如某天日志里多了一种特别长的字段。这种变化在耗时指标上可能要几小时后才体现，但溢写次数会立刻反映出来，相当于一个提前预警。

6.4 几条不会写在文档里的经验

最后说几条纯粹靠时间换来的体会，文档里通常找不到。

第一，作业的逻辑正确性要靠重跑验证。把同一个作业连跑三次，结果必须完全一致。但凡有差异，就说明某处依赖了非确定性因素，比如用了随机数、依赖了值的遍历顺序、或者在 reduce 里做了非幂等的累加。这类问题在小数据量下极难发现，等数据量上来才暴露，排查成本高得离谱。

第二，不要在 map 或 reduce 里做任何阻塞式的外部调用。我见过在 map 里调用远程接口查字典的写法，单机测试跑得好好的，上集群后因为并发太高把对方服务打挂，然后所有任务集体超时重试，雪崩。需要外部数据就提前分发到本地，或者用分布式缓存加载。

第三，输出目录的清理要放在作业之外。很多人习惯在代码里判断目录存在就删掉，这在并发环境下非常危险，两个作业同时跑会互相删对方的输出。正确做法是让作业输出到带时间戳的目录，清理交给独立的生命周期策略。

第四，压缩不是越小越好。压缩率高但解压慢的格式，在 CPU 紧张的集群上反而拖慢整体速度。而且前面提过，不支持分片的压缩格式会直接锁死并行度。选格式时要同时看压缩比、解压速度、是否支持分片这三个维度，而不是只盯着文件大小。

第五，先用小数据集把逻辑跑通，再用全量数据压测。我习惯抽千分之一的数据先跑一遍，确认输出没问题再上全量。这一步能省下大量等待时间，尤其是那些跑了三小时才在最后阶段报错的作业，每一个都是血的教训。

说到底，MapReduce 这套东西看起来笨重，中间数据全落盘、一轮一轮地跑，但正是这种笨重换来了确定性：任何一个任务失败了都能重算，任何一个结果都能复现。理解了它每个设计背后的取舍，你在面对别的计算框架时也会更容易看明白它们各自在解决什么问题、又牺牲了什么。我自己后来的体会是，框架会换，但“切分粒度、数据传输、聚合语义、故障恢复”这四个问题永远在，谁把这几件事想清楚了，换什么工具都不会慌。