1. 为什么一个“老掉牙”的计算框架还值得单独拎出来讲MapReduce 这个词现在很多人第一反应是“历史课本里的东西”。但凡是在数据平台、离线数仓、日志分析这条线上摸爬滚打过几年的人心里都清楚这套计算框架和编程模型至今仍然躺在无数生产集群的调度队列里每天凌晨跑着那些不能被 Spark 轻易替代的、跑十几个小时也不会有人盯着看的重型批处理任务。它解决的问题很朴素——当你有一批大到单机内存装不下、单盘装不下、乃至单机网络带宽都跑不满的数据需要用几百台机器的算力一起啃下来同时又不想为了“并行”这两个字去处理分布式锁、任务失败重试、节点中途掉线、结果合并顺序错乱这一堆烂摊子那 MapReduce 提供的抽象就是最省心的那一层。我把这篇内容定位成一份“能直接照着跑、跑完能调优”的实战笔记。适合三类人看第一类是刚接触离线计算、只知道往集群提交作业但不知道背后发生了什么的同学第二类是正在维护老集群、被数据倾斜和 Shuffle 拖到半夜的运维和开发第三类是想搞清楚“为什么后来的计算引擎要这样设计”的技术负责人——理解了 MapReduce 的取舍才看得懂后面那些框架到底在优化什么。文中所有代码、参数、排查思路都基于我在实际集群上的操作记录整理涉及具体业务的部分做了脱敏,路径和字段名都是通用的示意。需要提前说清楚一点我不会把它写成一份 API 手册。手册谁都能查但“为什么 reduce 数设成 200 而不是 400”“为什么 Combiner 写了反而更慢”“为什么 map 跑到 99% 卡住不动”这类问题手册上永远找不到答案。这篇的重点就在这些地方。2. 核心设计拆解三个反直觉但极其聪明的取舍2.1 移动计算而不是移动数据这是整套设计的地基刚接触分布式计算的人直觉方案通常是“把数据从各个节点拉到一台性能最强的机器上算”。这个思路在小数据量下没问题一旦数据规模上到 TB 级就彻底崩了——集群的骨干网络带宽是有限的公共资源几 TB 数据全往一个点汇聚链路会先成为瓶颈交换机端口先被打满磁盘 IO 反而是最后才用上的。MapReduce 走的是完全相反的路把计算程序分发到数据所在的机器上去执行。作业提交时调度组件会读取输入文件的元信息拿到每个数据块副本所在的节点列表然后尽可能把对应的 map 任务分配到那个节点上。这就是所谓的数据本地性data locality也是整个框架性能模型里权重最高的一项。这里有个细节值得展开。本地性其实分三个层级理解这三层能帮你解释很多“为什么我的作业网络流量这么大”的疑问本地性层级含义性能影响触发条件NODE_LOCAL任务与数据块在同一节点最优走本地磁盘该节点有空闲计算槽位RACK_LOCAL任务与数据块在同一机架可接受走机架内交换同节点槽位已占满OFF_SWITCH跨机架甚至跨机房最差走骨干链路集群资源紧张或数据分布极偏实际运行时调度器会先等一小段时间默认大约几秒可通过参数调整如果本地节点迟迟腾不出槽位就会退让到下一级。我在一个中等规模集群上做过对比把等待时间从默认值调到 0让任务立刻放弃本地性去抢空闲槽位整体作业完成时间反而变长了约 18%。原因很直白——抢到的是远端槽位每个 map 要多拉几百 MB 数据网络先饱和后面所有任务一起排队等带宽。所以那个“等一等”的参数不是保守是算过账的。注意如果你的集群经常出现大量 OFF_SWITCH 级别的任务别急着调参数先去看是不是数据分布本身有问题——比如某几个文件特别大或者上传时副本放置策略被改过。2.2 中间结果落盘用磁盘换容错这笔账其实很划算第二个让我第一次读源码时感到意外的设计是map 的输出不直接喂给 reduce而是先写到本地磁盘再通过网络拉取。放在今天的视角看这简直是在浪费性能——内存里直接传过去不好吗但这个设计针对的是一个非常现实的场景规模。一个作业有上万個 map 任务、几百个 reduce 任务整个过程中随时可能有机器挂掉、磁盘坏掉、进程被系统杀掉。如果中间结果全在内存里任何一个 map 失败依赖它的 reduce 就得全部重跑而中间结果落盘之后失败重试的代价被限制在单个任务内——重跑那个 map重新生成它那份落盘文件其他任务完全不受影响。我把这个取舍理解成“用可控的确定成本换掉不可控的随机风险”。落盘的写放大是确定的、可以估算的而内存态失败引发的级联重算代价是不确定的最坏情况下能把整个作业拖垮。这个思路在后来的很多系统里被反复借用只不过介质从磁盘换成了内存加检查点。代价也很真实Shuffle 阶段的磁盘 IO 和网络传输往往占到整个作业耗时的 60% 以上。所以后面所有调优手段本质上都是在围绕“怎么让落盘的数据更少、排序更省、传输更集中”做文章。2.3 只暴露两个接口是刻意为之的“能力约束”编程模型层面它只给你两个函数map(k1, v1) - list(k2, v2) reduce(k2, list(v2)) - list(k3, v3)就这么两个。没有 join、没有 group by、没有窗口函数、没有自定义的执行计划。初学者会觉得这太寒酸但用过一段时间就会发现这种“寒酸”恰恰是它能稳定跑在几千台机器上的原因。因为接口足够简单框架才能对执行过程做出强假设map 之间完全独立、可以任意并行、可以任意重排reduce 之间也完全独立只依赖按 key 分组后的数据。有了这两条假设失败重试、推测执行、任务搬迁这些机制才能实现得如此干净。你写业务逻辑时不用考虑“我的代码是不是有副作用”“重跑一次会不会写重复数据”——只要你保证 map 和 reduce 是纯函数式的同样的输入永远产生同样的输出框架就替你把所有分布式复杂度吃掉了。反过来一旦你需要“全局有序”“迭代计算”“低延迟交互”这类需求就会立刻撞上这套模型的天花板。这不是它做得不好是它从一开始就没打算做。认清这个边界比学会写 WordCount 重要得多。3. 编程模型细节绕不开的 Shuffle 到底在干什么3.1 输入切片决定了 map 的数量而不是文件数量很多人以为“一个文件对应一个 map”这是个流传很广的误解。真正决定 map 数量的是输入切片input split而切片的划分规则可以写成这样一个式子splitSize max(minSplitSize, min(maxSplitSize, blockSize))默认情况下minSplitSize是 1 字节maxSplitSize是一个极大的值所以切片大小就等于底层存储的块大小常见配置是 128MB。也就是说一个 1GB 的文件会被切成 8 个切片产生 8 个 map 任务每个 map 只读自己那一段key 是行首在文件内的字节偏移量value 是整行内容。这个机制解释了两个常见现象。第一小文件会严重拖慢作业一千个 1MB 的文件会产生一千个 map每个 map 启动 JVM、初始化、读元数据的开销远大于处理 1MB 数据的开销光是任务启动就能耗掉几分钟。第二切片边界会跨行所以框架在读切片末尾时会多读一点直到遇到换行符为止保证不会把一行数据劈成两半——这也意味着相邻两个 map 可能读到同一行的一部分框架层面已经处理好了你写代码时不用管。如果你确实有一堆小文件常见的处理手段是先做一次合并把小文件拼成大文件再跑主作业或者调整切片上限把小文件“塞”进同一个切片里。后者要注意切片上限调大之后单个 map 处理的数据量变大失败重试的代价也随之上升需要权衡。提示判断切片参数是否合理可以看作业的 map 平均执行时间。如果大量 map 的执行时间在 5 秒以内就结束了说明切片太小任务调度开销占了主导。3.2 Combiner 不是必需的但它经常是性价比最高的那一行代码map 输出之后、进入 Shuffle 之前有一个可选的环节叫 Combiner。它的作用是在 map 端先做一次“局部归并”把相同 key 的value 提前合并从而减少要落盘和传输的数据量。举个具体例子。做日志按 URL 计数某个热门路径在单个 map 处理的 128MB 数据里出现了 50 万次那么 map 会输出 50 万条url, 1。如果加了 Combiner这 50 万条会在本地就被压成一条url, 500000网络传输量直接降了五个数量级。在我的经验里只要你的 reduce 逻辑满足结合律和交换律求和、求最大、求并集都算加上 Combiner 几乎不会亏。但这里有个坑必须说清楚Combiner 的执行次数和时机是不确定的。框架可能在每次溢写前调用一次也可能在合并溢写文件时再调用几次甚至可能完全不调用。这意味着两件事第一你的 Combiner 必须能处理“输入已经被部分合并过”的情况不能假设输入是原始的 map 输出第二Combiner 的输入输出类型必须和 map 的输出类型完全一致否则会直接报类型不匹配。我还遇到过另一种情况有人在 Combiner 里做了带状态的聚合比如维护一个全局计数器结果因为调用次数不确定最终结果每次跑都不一样。这类 bug 极难排查因为单看代码逻辑是对的。只要涉及副作用就不要放进 Combiner。3.3 Partitioner 决定了数据往哪个 reduce 走它是最容易被忽视的倾斜源头map 输出经过 Combiner 之后需要被分配到不同的 reduce 上去。分配规则由 Partitioner 决定默认实现非常朴素partition hash(key) % numReduceTasks这个规则在 key 分布均匀时工作良好一旦遇到幂律分布就会出事。经典的场景是统计电商订单少数几个大卖家的订单量可能是普通商家的上万倍取模之后这几个 key 全部落到同一个 reduce 上那个 reduce 要处理的数据量是其他 reduce 的几十倍整个作业的完成时间就被它一个拖住。解决办法是自定义 Partitioner把热点 key 打散。最常用的手法是加盐给 key 拼接一个随机前缀比如key _ random(0, N)让它均匀落到 N 个分区里然后在下游再做一次聚合把前缀去掉。这个方案要多跑一个作业但如果倾斜严重多跑一个作业远比让一个 reduce 跑六个小时划算。另一种情况是空 key 倾斜。日志里经常有大量字段为空的行这些行的 key 全是空字符串hash 之后全部落到同一个分区。处理办法很简单给空 key 随机赋一个值或者干脆在 map 阶段就过滤掉。3.4 Shuffle 的三个子过程卡在哪一步要能分清Shuffle 是整个模型里最复杂的一段把它拆开看其实就三步第一步是溢写。map 的输出不是直接写文件而是先写进一块固定大小的环形内存缓冲区默认 100MB。当写入量达到缓冲区容量的一个阈值默认 0.8也就是 80MB时后台线程开始把这块数据按分区排序后写到磁盘形成一个溢写文件。写满一次溢写一次一个 map 可能产生多个溢写文件。第二步是合并。map 结束前所有溢写文件会被归并成一个大文件每个分区内部按 key 有序。归并过程如果触发了 Combiner会再压一次数据量。第三步是拉取。reduce 任务启动后会通过后台线程去各个 map 节点拉取属于自己分区的数据段先放内存内存不够就落盘最后再做一次归并排序把有序的数据流喂给 reduce 函数。排查性能问题时分清卡在哪一步非常关键。溢写慢说明单机磁盘 IO 有问题或者缓冲区太小导致溢写次数过多拉取慢说明网络带宽不足或者 map 端输出太大归并慢说明拉过来的数据段太多太碎。这三种情况对应的调优方向完全不同盲目调参数只会越调越乱。4. 动手跑一遍从最简例子到能上生产的日志统计4.1 环境与依赖准备我用的是最常见的一套开源实现版本 3.x。为了避免版本差异带来的困扰先把关键环境固定下来组件版本说明运行环境JDK 8高版本 JDK 在部分组件上有兼容问题建议锁 8分布式存储与计算框架同版本保证协议一致避免读写异常资源调度YARN作业提交与容器分配客户端工具命令行客户端提交、查看、杀死作业配置上至少要确认三件事核心配置文件里的文件系统地址指向正确的服务端、调度器地址配置正确、任务运行用户的权限在目标路径上可读写。这三项任何一项不对作业提交时都能看到明确的报错不用猜。我习惯在提交前先手动验证一遍路径可访问# 确认输入路径存在且有数据 hdfs dfs -ls /data/logs/2024/ | head -20 # 确认输出路径不存在框架要求输出目录必须不存在否则直接拒绝 hdfs dfs -test -e /data/out/access_count echo 已存在换路径 || echo 可用第二条经常被忽略。作业跑到一半因为输出目录已存在而被拒绝白等几十分钟。养成习惯输出路径带时间戳是最省事的做法。4.2 用流式接口写一版能跑的日志统计原生接口用 Java 写但为了演示清晰我用流式接口配合 Python 来写逻辑一模一样可读性高得多也方便你直接改成自己的业务。Mapper 部分输入是标准输入的一行行原始日志输出是“组合键 计数”#!/usr/bin/env python3 import sys def main(): for raw in sys.stdin: line raw.rstrip(\n) if not line: continue fields line.split(\t) # 字段不足的脏数据直接丢弃避免后续解析异常 if len(fields) 5: continue url fields[3].strip() status fields[4].strip() if not url or not status: continue # 用竖线拼接组合键避免与制表符分隔符冲突 print({0}|{1}\t1.format(url, status)) if __name__ __main__: main()这里有个细节值得说明为什么用竖线拼接而不是直接用制表符把两个字段分开。流式接口默认把每行的第一个制表符之前的部分当作 key之后的全部当作 value。如果 key 本身含制表符框架会把它切错导致 reduce 收到意料之外的 key。用竖线是成本最低的规避方式比写自定义分隔符配置省事。Reducer 部分输入是已经按 key 排好序的键值对只需要顺序扫描累加#!/usr/bin/env python3 import sys def main(): current_key None total 0 for raw in sys.stdin: parts raw.rstrip(\n).split(\t) if len(parts) ! 2: continue key, cnt parts[0], parts[1] try: cnt int(cnt) except ValueError: continue if key current_key: total cnt else: if current_key is not None: url, status current_key.split(|, 1) print({0}\t{1}\t{2}.format(url, status, total)) current_key key total cnt if current_key is not None: url, status current_key.split(|, 1) print({0}\t{1}\t{2}.format(url, status, total)) if __name__ __main__: main()关键点在于reduce 的输入一定是按 key 排过序的所以只需要和上一个 key 比较不需要维护哈希表。这个假设是框架保证的也是整个模型能处理“内存放不下的分组”的根本原因——分组是流式做的不是在内存里做的。Combiner 可以直接复用 reducer 的脚本因为求和满足结合律。这一步在命令行里加一行参数就行收益通常很大。4.3 参数计算map 数和 reduce 数到底怎么定这是问得最多的问题我给一套可以直接套用的算法。先算 map 数。假设输入总量 2TB块大小 128MBmap 数 ≈ 2 * 1024 * 1024 MB / 128 MB 16384 个这个数不需要你手动设切片规则自动算出来的。你需要关注的是“这个数量级合不合理”。16384 个 map如果集群有 500 个可用容器槽位那就是 33 轮每轮 map 跑 1 分钟的话总共约 33 分钟。如果发现 map 平均只跑了几秒钟那就是切片太小可以把切片上限调大。再算 reduce 数。有个流传很广的经验公式reduce 数 ≈ 集群可用 reduce 槽位数 × (0.95 或 1.75)0.95 适合“reduce 完成后还要接着跑下游作业”的场景能让槽位轮转更紧凑1.75 适合“reduce 内部还要做较重计算”的场景让快的任务先结束、慢的继续整体更均衡。但公式只是起点。真正要卡的是两个约束单个 reduce 处理的数据量和单个 reduce 输出的文件大小。经验上一个 reduce 处理 1GB 到 5GB 的输入比较舒服太小则调度开销占主导太大则失败重试代价高。输出文件建议控制在块大小的量级128MB 到 256MB太小会产生大量小文件给下游添麻烦太大则下游读取并行度不够。按 2TB 输入、每个 reduce 处理 5GB 算reduce 数约 400 个。这时候再看集群槽位如果只有 200 个那 400 个 reduce 要跑两轮可能不如设成 200 个跑一轮。这就是为什么我说参数要结合集群现状算脱离集群谈最优值没有意义。4.4 提交作业与观察运行状态提交命令hadoop jar $HADOOP_HOME/share/hadoop/tools/lib/hadoop-streaming-*.jar \ -D mapreduce.job.nameaccess_log_count_v1 \ -D mapreduce.job.reduces200 \ -D mapreduce.input.fileinputformat.split.maxsize268435456 \ -D mapreduce.task.io.sort.mb200 \ -D mapreduce.map.sort.spill.percent0.85 \ -files mapper.py,reducer.py \ -mapper python3 mapper.py \ -combiner python3 reducer.py \ -reducer python3 reducer.py \ -input /data/logs/2024/ \ -output /data/out/access_count_$(date %s)几个参数的选择理由切片上限设成 256MB两倍块大小是为了减少 map 数量、降低调度开销排序缓冲区从默认 100MB 提到 200MB是为了减少溢写次数——溢写次数少了磁盘寻道和归并的量都跟着降溢写阈值提到 0.85是在内存和磁盘之间稍微偏向内存一侧。作业提交后观察运行状态有两个关键窗口期。第一个是 map 阶段前期看有没有任务立刻失败——通常是环境问题或脚本权限问题这种情况几秒内就暴露。第二个是 reduce 阶段达到 33% 左右的时候这时候第一批拉取已经完成如果出现拉取超时说明网络或者 map 端输出有问题。我习惯盯三个指标map 完成率的增长斜率是否平滑、reduce 阶段的拉取字节数是否和预期量级吻合、有没有个别任务长时间停在同一个百分比。第三条尤其重要后面讲倾斜的时候会展开。4.5 一个更贴近生产的改造上面的例子只做了计数。真实场景里经常需要“按 URL 统计各状态码的占比”这就涉及一次分组内的多值计算。改造思路是在 map 阶段输出更丰富的结构reduce 阶段一次性算完# mapper 输出: url\tstatus\t1用制表符分隔三段 print({0}\t{1}\t1.format(url, status))reduce 阶段按 url 分组需要自定义分隔逻辑或者用 url 作为唯一 key、把状态码塞进 value在同一个 reduce 调用里维护一个小字典统计该 URL 下各状态码的数量最后输出总数、成功数、失败率和 Top 状态码。这种改造的价值在于把“多次扫描”压成“一次扫描”。如果分成两个作业分别算总数和分类数等于把 2TB 数据读了两遍。在离线场景下一次扫描能省下的机时往往比代码复杂度更值钱。不过要留意内存。单个 URL 的状态码种类通常有限几十种用字典没问题但如果是按用户 ID 分组、每个用户有上万个不同行为字典就可能撑爆 reduce 的内存。这种情况要么限制字典大小只保留 Top N要么改成两阶段聚合。判断标准很简单单个 key 对应的不同子类数量乘以子类的内存占用不能超过 reduce 可用堆内存的一半。5. 性能调优与故障排查实录5.1 数据倾斜的三种形态认错了就白调倾斜是这套框架最常见的性能杀手但“倾斜”本身有三种完全不同的成因处理手段也不同。第一种是 key 级倾斜。少数 key 对应的数据量远超其他 key。表现是 reduce 阶段大部分任务在 10 分钟内完成剩下几个卡在 60% 以上不动且这些任务读入的记录数明显偏高。处理手段是加盐两阶段聚合前面已经说过。第二种是输入文件级倾斜。某个文件特别大比如一个 50GB 的压缩文件切片之后产生的 map 数量远多于其他文件且这个文件很可能是不可切分的压缩格式。这种情况下即使 key 分布均匀也会出现个别 map 跑得特别久。处理手段是换用可切分的压缩格式或者在入库时就把大文件拆开。第三种是分区级倾斜。自定义 Partitioner 写得不好导致某些分区分配到的 key 数量远超其他分区。这种倾斜在 map 阶段完全看不出来只有到 reduce 阶段拉取数据量时才暴露。处理手段是检查 Partitioner 的分支逻辑确保各分支的权重接近。我在一次实际排查中遇到过混合情况表面看是 reduce 慢加盐之后仍然慢最后发现是大文件导致的 map 长尾map 拖慢了整个 Shuffle 的启动时间。这种时候单看 reduce 指标会被误导必须同时看 map 阶段的耗时分布。5.2 常见报错与排查路径速查现象大概率原因排查动作作业提交后立刻失败提示输出目录已存在输出路径重复换带时间戳的路径map 任务大量失败日志显示找不到模块运行环境缺少依赖或脚本未随作业分发检查-files参数和节点上的解释器版本reduce 卡在 33% 长时间不动拉取阶段网络受阻或 map 输出过大看拉取字节数增速检查网络与 Combiner 是否生效个别 reduce 卡在 66% 或 99%数据倾斜或单 key 数据量过大统计各 reduce 输入记录数定位热点 key作业报内存溢出堆栈在排序阶段排序缓冲区过大或单条记录过大下调缓冲区或检查是否有超大字段任务被反复杀死重试容器内存超限被调度器终止上调容器内存或降低单个任务处理量作业整体变慢但无报错Combiner 未生效或溢写次数激增对比加/不加 Combiner 的 Shuffle 字节数这张表里最需要警惕的是“任务被反复杀死重试”。它不像其他错误那样有明确堆栈表现是任务进度反复从 0 开始日志里能看到容器被终止的记录。很多人第一反应是调大重试次数结果只是让作业跑得更久。正确做法是看容器的实际内存使用峰值判断是配置给少了还是代码里真有内存泄漏比如在 reduce 里无限制地往集合里塞数据。5.3 几条反直觉的调优经验第一reduce 数不是越多越好。把 reduce 数从 200 提到 800理论上并行度翻了四倍但我实测过作业总时长只降了 12%因为每个 reduce 分到的数据变少启动和初始化的固定开销占比变大而且输出文件数从 200 变成 800下游读取时又要处理小文件问题。合理的做法是按“单个 reduce 处理 3 到 5GB”来定而不是盲目堆数量。第二缓冲区大小调到一定程度就没收益了。把排序缓冲区从 100MB 提到 200MB溢写次数减半效果明显继续提到 400MB收益就很小了反而挤占了任务本身可用的内存容易触发容器超限。我一般在 200MB 到 300MB 之间取值视单条记录大小微调。第三JVM 重用要谨慎开。开启任务级 JVM 重用能省掉反复启动的开销对大量小任务效果显著。但如果你的 map 或 reduce 里有静态状态比如静态缓存、静态计数器重用会导致状态跨任务污染出现“同样的输入跑出不同结果”的诡异现象。开之前先确认代码里没有静态可变状态。第四推测执行不是万能的。它会为跑得慢的任务启动备份副本谁先完成用谁的结果。在资源充裕时确实能救长尾但在资源紧张时备份任务反而抢走了本该给其他任务的计算槽位可能让整体更慢。倾斜类问题开推测执行基本无效——备份任务处理同样的热点数据一样慢。6. 这套模型在今天的位置该用的时候别绕不该用的时候别硬上6.1 它依然难以替代的几类场景第一类是超大规模的、对延迟不敏感的批处理。数据量在几十 TB 到 PB 级允许跑几个小时甚至一整夜结果产出到第二天早上能用就行。这类任务对执行引擎的绝对性能不敏感但对稳定性和容错性极其敏感——跑六个小时的作业中途挂掉要能自动续上而不是从头再来。这套模型在这方面的成熟度是用十几年生产验证堆出来的。第二类是对成本极度敏感的历史数据回刷。当你要对三年前的全量数据重新跑一遍口径变更跑一次就结束不需要常驻集群。这种一次性重活的资源利用方式和常驻内存型引擎的模型完全不同前者能跑在更便宜的存储和更弹性的算力上。第三类是作为数据链路的兜底环节。很多团队的实时链路出问题时会切回离线链路保证数据不丢这条兜底链路往往就是跑在这套框架上的。它慢但它不会因为内存压力或者状态膨胀而突然不可用。6.2 明显不该用它的时候交互式查询绝对不适合。它的启动开销以分钟计跑一个几秒能出结果的查询等作业调度的时间够喝两杯咖啡。迭代式计算也不适合比如图算法或者机器学习训练每一轮迭代都要把中间结果落盘再读回来几轮下来磁盘 IO 就成了主要耗时。流式处理更不用说模型本身就没有为无界数据设计。还有一个容易被忽略的点小数据量下的复杂逻辑。如果你要处理的数据只有几十 GB但业务逻辑复杂到需要多次 join、多次聚合、带窗口计算那么手写这一串 map-reduce 链的成本和出错概率远高于用一套带执行计划优化的引擎。工具的复杂度要和问题的复杂度匹配用大炮打蚊子累的是自己。6.3 一个务实的组合思路我在实际项目里的做法通常不是“二选一”而是分层接入层用轻量的处理把原始数据做初步清洗和格式统一落到规整的分区表核心计算层按任务特征分流重型的全量回刷和长周期聚合走这套批处理模型中等规模、需要快速迭代的分析走更轻的引擎产出层统一做质量校验和一致性比对。这样分工的好处是每层都在自己擅长的区间工作不会出现“为了一个简单的日报去跑三小时批处理”或者“为了回刷三年数据去撑爆内存”这类错配。代价是维护两套运行时需要有人同时懂两边——但对一个数据平台来说这个成本是值得的。最后分享一个我在实际配置里踩过的坑不要小看输出文件的数量。有一次为了追求单任务速度把 reduce 数调得很大结果每个 reduce 输出一个几百 KB 的小文件下游几百个作业读取时全部卡在元数据操作上最后不得不加了一个合并小文件的收尾步骤。从那以后我定参数的第一优先级变成了“输出文件大小是否接近块大小”而不是“任务跑得够不够快”。方向对了速度自然会来。