做数据平台的人，迟早会在 Hive 执行引擎的选择上纠结一轮。我自己前前后后帮三个团队做过迁移评估，也在自己这边跑过上千批次的对比测试，真实感受是：MapReduce、Tez、Spark 这三者的差异，影响的绝不只是“查询快了几分钟”，而是一整套系统的资源账单、运维方式、问题排查手段，甚至业务方对技术团队的耐心程度。
这篇文章不是从原理文档里抄来的概念科普，而是把我这些年踩过的坑、验证过的数据、切换引擎时最容易翻车的地方全部梳理一遍。适合正在做技术选型的数据平台负责人，也适合每天写 Hive SQL 但不太清楚任务底层怎么跑的数据开发。看完你至少能回答一个问题：我手里的这套业务，到底应该用哪个引擎，以及怎么切才不至于把线上任务切崩。
1. 三种执行引擎到底差在哪：原理与演进脉络
1.1 MapReduce：每一步都落盘的“笨重流水线”
要理解后续两种引擎的改进，得先搞清楚 MapReduce 的痛点在哪。它最底层的模型非常朴素：一个任务就是一次 Map 再加一次 Reduce，Map 处理完一批数据后，会把中间结果溢写到本地磁盘或者 HDFS，Reduce 阶段再去把这些数据拉过来做聚合或输出。如果一条 SQL 比较复杂，Hive 会把它拆成一串 MR 作业，前一个作业的输出落盘，后一个作业再重新读取。
这四个 MR 作业串联的场景下，每一层数据都要走一遍磁盘读写，这个开销非常大。我见过一个团队跑二十多层的数仓任务，工作日夜间跑批经常跑到凌晨还没结束，打开 YARN 页面一看，大量时间都消耗在作业之间的数据传递和重复落盘上，真正计算的时间占比反而不高。MapReduce 不是不能用，它是为了极致的容错和简单性做了取舍：每一步都有持久化的中间结果，某一步挂了可以从上一个完整输出点重跑。但代价就是慢，这个慢不是某一次任务慢，而是结构性慢。
1.2 Tez：用 DAG 把零散步骤串起来
Tez 的核心改进听着简单，但解决的是真痛点：把多个 MR 作业之间的依赖关系整理成一张 DAG，在一个 ApplicationMaster 会话内统一调度，中间结果不需要每一个都落到 HDFS，能走内存缓冲就走内存缓冲，能直接从本地磁盘拉取就直接拉取。同时 Tez 还引入了容器复用，一个 Container 可以在 DAG 的多个阶段间连续干活，不用像 MR 那样每跑一个阶段都要重新申请资源。
形象点说，MapReduce 是每条流水线的工人在完成自己工序后，必须把半成品运回总仓库，下一个工序的工人再去仓库取货；Tez 则是把这几条流水线直接接在一起，上一道工序完工后，半成品通过传送带直接到下一道工序的工位。省掉的不只是搬运时间，还有仓库的存取调度时间。反映到真实数据上，在不改任何 SQL、不优化数据倾斜的前提下，仅仅把执行引擎从 MR 切到 Tez，大部分批任务能快两到三倍，复杂一点的能快更多。
1.3 Spark：内存计算带来的体验变化
Spark 的登场把这种 DAG 思想又往前推了一步，它不只是把中间结果停留在内存，而是从根上重新设计了计算模型：用 RDD/DataFrame 抽象统一了 SQL、机器学习、图计算等所有场景，用 Catalyst 优化器对 SQL 做逻辑优化和物理优化，动态规划选择 join 顺序，能广播的小表直接广播，避免一次可能拖垮全集群的 shuffle。对跑 Hive SQL 的人来说，最直观的感受就是查得快，尤其是一些多表 join、子查询嵌套很深的复杂 SQL，Spark 能榨出的执行计划质量往往比 Tez 更高。
但“快”是有代价的。Spark 对内存的要求非常贪婪，Executor 内存小了容易频繁 GC，甚至 OOM；内存大了又可能把 YARN 集群的资源吃光，导致其他任务排队等待。同一个 SQL，在资源不宽裕的集群上用 Spark 跑，反而可能因为等待内存资源而比 Tez 更慢。这就是我后来反复强调的一个观点：引擎选型不是跑分竞赛，是资源博弈。
1.4 三者在关键维度上的差异对照
| 对比维度 | MapReduce | Tez | Spark |
|---|---|---|---|
| 执行模型 | 严格两阶段，多作业串联 | DAG 单作业多阶段 | DAG 内存计算，粗细粒度调度 |
| 中间结果 | 频繁落盘，容错强 | 减少落盘，本地传递 | 尽量驻留内存，可落盘容错 |
| 容器复用 | 无，每阶段重新申请 | 有，DAG 内复用 | 有，按 Executor 常驻管理 |
| SQL 复杂度表现 | 越复杂越慢 | 较复杂任务提升明显 | 对复杂 join 优化最好 |
| 资源占用 | CPU 和磁盘为主 | 中等，内存可控 | 内存需求大，波动明显 |
| 默认稳定性 | 最高，最笨最稳 | 高，但需调容器参数 | 中等，依赖资源管理 |
| 适用定位 | 小集群、极简维护 | 常规离线批处理 | 即席分析、复杂计算、流批一体 |
2. 技术选型的影响范围：不只是“跑得快”
很多人选引擎的时候只看一条：谁快。但真正做过生产环境的人都知道，一次引擎切换直接影响的是一个平台未来两三年的方方面面。把影响范围想清楚，比纠结那几分钟的耗时更重要。
2.1 对研发效率和排障体验的影响
不同引擎对应着完全不同的排查思路。MapReduce 的任务日志结构非常简单，哪个阶段卡住、哪个 node 失败，进去看 JobHistory 很快就能定位。Tez 的日志分散在 DAG 的不同顶点里，排查时得先搞清楚是 map 端顶点、reduce 端顶点还是合并顶点出问题，再逐层点日志。Spark 更复杂，一个任务失败，真实报错可能埋在几十个 Executor 日志里的某个 Executor 上，不借助日志聚合系统，排查一次能让你怀疑人生。
这意味着技术团队的学习成本和排障效率也是选型的一部分。我之前合作过的一个团队，整体技术水平比较偏传统数仓，他们当时想在集群上直接上 Spark，我说先别急，先问自己：如果凌晨两点任务出问题，团队里有几个人能在半小时内通过日志定位到具体 Executor？他们后来评估完，决定先保留 Tez 为主，Spark 只开给少数交互式查询，这个决策后来被证明非常明智。
2.2 对资源成本与运维稳定性的影响
资源账单这件事，很多团队一开始不算，等月底看到整个大数据平台的资源使用率报表才意识到：不同引擎跑同一个 SQL，消耗的资源差异可以很大。MapReduce 慢，但每个任务占用的内存毕竟小；Spark 快，但同一时刻可能把集群内存吃出好几倍的瞬时波动。在共享集群上，过度激进的 Spark 任务配置会挤压其他业务方的资源，引发跨团队的资源争夺。
运维上最常见的坑是“有资源但没内存”。很多集群运行久了，CPU 使用率并不高，但内存已经被各种 Executor 占满了，这时候你再提一个新任务，要么疯狂排队，要么触发 YARN 的强杀策略把老任务干掉。Tez 的内存模型相对收敛，给每个 Container 分配固定内存，动态波动小，夜间大批量跑批时压力曲线比较平滑；Spark 的 Executor 内存则需要你做更细致的预分配，而且任务和任务之间互相影响更明显。
2.3 一步选错，未来要付出的重构代价
引擎切换不是把配置改一下就行，SQL 本身也会被引擎反噬。Hive 的一些老 HINT，比如 MAPJOIN、SKEWJOIN，在 MR 和 Tez 下可能还能正常用，到了 Spark 下不一定生效，甚至会影响执行计划生成。另外 UDF 的兼容性也要逐一验证，特别是用了反射、直接访问文件系统、依赖第三方依赖包的 UDF，在 Spark 的执行环境里很可能行为不一致。更隐蔽的是，切换后同一套 SQL 的数据格式选择也会受影响，比如 ORC 在 Tez 下写出的文件大小粒度到了 Spark 下可能不同，直接影响下游任务的输入分片。
所以选型背后隐含着选择的是平台未来的演进方向。如果你确定后续要做流批一体、要做复杂的机器学习作业，那 Spark 是必须早一步引入的；如果只是为了解决慢的问题，Tez 的改动成本远低于 Spark，收益也足够大。
3. 场景化决策：什么业务配什么引擎
3.1 定时批处理 ETL：Tez 是性价比之选
绝大多数数仓场景，主力负载其实是夜间定时跑批任务：每一层 DWD、DWS、ADS 大量表的清洗、聚合、关联、重跑，任务数量动辄上千。这类任务的特点是：输入输出固定，逻辑相对稳定，要求到点完成、尽量少失败重试。在这种场景里，Tez 是性价比极高的选择。
我以前在某数据平台做迁移评估时，从 MR 切到 Tez 的过程让我印象非常深刻。整体跑批时间缩短了接近 60%，原来跑到凌晨四点的任务，切换后凌晨一点多就全部结束了。而且极少需要改 SQL，主要是调整了容器大小和 sort 内存，保证 DAG 里那些临时数据不要撑爆堆内存。稳定性上，Tez 的失败率跟 MR 基本持平，因为它的中间结果大部分还是走 HDFS 或本地磁盘，容错底子还在，不像 Spark 那样一旦 Executor 挂掉，整个 Stage 要重算。
3.2 交互式分析与探索：Spark 是更好的那一只手
如果你有一批分析师，经常临时写 SQL 跑各种探索性查询，一条 SQL 拖几十秒和拖几分钟，体验是完全不一样的。这种即席查询场景，Spark 的优势非常明显。它可以在一次会话里连续执行多条 SQL，共享执行计划和数据缓存，再加上 Catalyst 对 join 条件的优化，很多在 Tez 下要跑两三分钟的 SQL，Spark 可以在十几秒内返回。
但这里有一个重要的前提：交互式查询并发不能太高，要控制好资源配额。分析师一多，几十个 Spark 任务同时申请 Executor，再大的内存集群也扛不住。更合理的方式是给交互式查询建一个独立的 YARN 队列，限制最大并发数，同时给 Spark 任务设好单个 Executor 的内存上限，宁可让某些任务跑慢一点，也不能让别人没法跑。
3.3 小集群与极简维护：MapReduce 的最后一席
说到小集群，很多人的第一反应是“赶紧换 Tez 提升性能”，但我反而建议谨慎。小型集群通常内存资源有限，运维团队也未必对 Tez 和 Spark 的底层机制很熟。MapReduce 尽管慢，但它足够简单，没有任何 DAG 调度、Container 复用、会话管理这些额外概念。如果任务量不大，夜间跑批时间也在可接受范围内，硬切引擎反而是给自己找事。
我的建议是：集群总内存小于 50GB，或者团队没有专职大数据运维，或者任务总数量不到一百，可以不动引擎，继续用默认的 MR。等业务量真正涨上来了，一次性切到 Tez 也不迟，反正切换成本不高。如果一开始就去追 Spark，大概率会把集群资源炸穿。
3.4 决策步骤：用五个问题代替感觉
在帮助团队做选型的时候，我通常会先抛五个问题，要求他们把答案写成文档，而不是脑子里想想：
- 线上任务以定时批处理为主，还是即席交互查询占比更大？
- 当前集群内存是否宽裕，能不能接受 Executor 长时间驻留？
- 团队排障能力如何，是否具备定位 Spark Executor 日志的能力？
- 未来半年内，是否要做机器学习、图计算或流批一体？
- 现在跑批最慢的任务，慢在计算还是慢在数据量膨胀？
如果问题 1 的答案是批处理为主，问题 2 的答案是不宽裕，问题 3 的答案是一般，那么答案已经呼之欲出：Tez。反过来，如果交互式分析占比很高，内存资源又够，团队也愿意学习新的排障方式，那就大胆上 Spark。
4. 切换与调优实战：把引擎切换跑稳
4.1 从 MR 切到 Tez 的最短路径
MR 切 Tez 是整个切换里最平滑的一条路，因为 Hive 本身对执行引擎做了一层封装，SQL 语法基本不用动。操作上只需要在 Hive 会话里改引擎配置：
SET hive.execution.engine=tez; SET hive.tez.container.size=4096; SET tez.am.resource.memory.mb=2048; SET tez.runtime.io.sort.mb=1024; SET tez.runtime.unordered.output.buffer.size.mb=512;这几个参数是最基本的地基。hive.tez.container.size是每个 Tez 容器分配的内存，一般以任务的峰值内存为准，我习惯先从 4GB 起步，观察一段时间再上调。tez.runtime.io.sort.mb是排序缓冲区，如果任务涉及大的 ORDER BY 或者 DISTRIBUTE BY，缓冲区太小会频繁溢写磁盘，这时候需要相应调大。
切换时要特别注意一个容易翻车的点：不要一次性把全量任务切过去。正确做法是先挑一条耗时最长、逻辑最复杂的任务，用 Tez 模式跑一遍，和 MR 模式对比执行时间和资源消耗。跑通后再按业务线灰度，先切一个业务方的任务，观察两三天的失败率和重试率，没问题再全量切。全量切换后的第一周，重点盯两类任务：一是涉及超大规模动态分区的写入任务，二是小文件特别多的输入任务。
4.2 再往前走一步：从 Tez 切到 Spark
如果已经上了 Tez，并且团队整体技术准备度不错，想进一步提速，特别是为了交互式分析引入 Spark，那需要做更充分的准备。先看 Hive 版本和 Spark 的兼容性，Hive On Spark 在不同版本上的表现差异非常大，老版本经常出现任务提交失败、Executor 启动超时的兼容性问题，这一步要做在前头。
然后是资源参数，我的一份 Spark On Hive 配置建议是这样的：
SET hive.execution.engine=spark; SET spark.executor.memory=8g; SET spark.executor.cores=4; SET spark.sql.shuffle.partitions=200; SET spark.serializer=org.apache.spark.serializer.KryoSerializer; SET spark.yarn.executor.memoryOverheadFactor=0.3;spark.sql.shuffle.partitions是一个很经典的坑，默认值是 200，很多场景下这 200 个分区根本不够，数据量一大就会产生严重的数据倾斜或者单个分区数据过大。但也不能无脑调大，分区数越大 shuffle 的 overhead 越大，要看实际数据量来评估。memoryOverheadFactor是给 Executor 预留的直接内存空间，驱动端做 shuffle 拉取数据或者 UDF 里用了堆外内存时，这个空间不够会直接导致 Executor 被 YARN 杀掉，日志里会报内存超限。
切到 Spark 之后的第一个星期，我建议不要马上把全部任务切过去。先筛选出二十条左右高耗时、计算逻辑复杂的任务，用 Spark 跑一周，把每一条任务的执行时间、失败次数、资源消耗记录下来，和 Tez 时期对比。这种灰度至少持续两周，确认没有隐性 bug 再逐步扩大范围。
4.3 调优思路：先跑通，再按瓶颈调
很多新手调参有个坏习惯，一上来就堆资源，参数恨不得全部拉满。但实际上，参数调优的正确顺序是先跑通，再定点优化。第一步用默认参数把任务跑一遍，主要目的是看它会挂在哪；第二步根据日志判断瓶颈：是 shuffle 数据量太大，还是某一个 Stage 长时间不动，还是 Executor 频繁 GC；第三步再有针对性地调整对应参数。
比如任务执行时间都集中在某个 Join 的 Stage 上，先去检查是不是小表没有广播，或者存在严重的数据倾斜。如果是大表 join 大表，需要考虑给 join 键加盐或者拆分逻辑；如果发现某个 reduce 端处理的数据量明显高于其他 worker，那就是倾斜问题，在 Tez 下可以通过hive.groupby.skewindata或者调整分区数来解决，在 Spark 下则可以针对 key 做前缀打散。调参不是一次到位，而是要形成一个闭环：跑、看日志、改配置、再跑。
5. 常见问题与排查技巧实录
5.1 任务长时间卡住不动，日志里又没报错
这种问题在 MR 时代基本不常见，因为每个阶段都有明确进度。到了 Tez 时代开始出现：DAG 的某个顶点在等待上游输出，但上游顶点因为数据倾斜迟迟完成不了，从外部看就像卡死。排查时先打开顶点的详细日志，看当前正在处理的记录数和数据分布；如果某个顶点的计数器在跳动，但速度极慢，大概率是倾斜后的长尾任务。
另外一个隐蔽原因是 Tez 会话的复用机制。第一次提交任务时，Tez 会启动一个 ApplicationMaster 再创建 session，这个过程本身要消耗十几秒甚至更久。但如果同时并发提交大量任务，AM 的创建可能排队。遇到这种情况，可以把tez.session.am.dag.submit.time.secs适当调大，让 AM 等待 DAG 提交的时间更长一些，减少反复创建会话的 overhead。
5.2 Container 反复被 YARN 杀掉
Tez 或 Spark 任务跑着跑着，日志里看到Container killed on request. Exit code: 143，这种报错大多数情况是内存超限触发了 YARN 的强杀机制。Tez 下需要检查hive.tez.container.size和tez.runtime.io.sort.mb的关系：容器总内存 4GB，但排序缓冲区给你设了 3GB，再加上其他数据结构，必然溢出。合理的做法是排序缓冲区不要超过容器内存的四分之一到三分之一，剩下的内存留给实际计算和 shuffle。
Spark 下遇到 Executor 被杀的频率更高，原因往往在于spark.executor.memory只设置了堆内存，忽略了memoryOverhead。默认的 overhead 比例可能不够，特别是在跑聚合类任务、shuffle 拉取量大时，容易触发堆外内存超限。我一般会手动把spark.yarn.executor.memoryOverheadFactor调到 0.2 到 0.3，宁可让 Executor 可用堆内存小一点，也不要让它被 YARN 杀掉导致整个 Stage 重算。
5.3 数据倾斜在不同引擎下的应对差异
数据倾斜是一个老生常谈却绕不过去的话题。MR 和 Tez 下，最常见的是某个 reduce 阶段长时间打转，其他 reduce 早早就结束了。Tez 下可以先看 DAG 顶点里几个 task 的处理时间分布，如果某个 task 的 running 时间远高于同级的其他 task，说明瓶颈就出在这里。比较实用的做法是先把hive.groupby.skewindata打开，让 Hive 对倾斜 key 做一次预处理和打散聚合，但这只对明显的 group by 倾斜有效。
Spark 下倾斜的表现更直接：某个 Stage 的部分分区数据量大，某个 Executor 处理时间明显偏长。应对方式有两个方向：一是把spark.sql.shuffle.partitions调大，让数据拆得更散；二是对 join 的倾斜 key 做前缀加盐，把大 key 随机拆分后再聚合。调大分区数是最省事的，但只适用于总数据量特别大而单 key 并不极端的情况；如果某个 key 本身就占了三分之一的数据量，加盐还是绕不开的，需要认真改 SQL。
5.4 常见问题速查表
| 问题表现 | 可能原因 | 快速定位方法 | 常见解法 |
|---|---|---|---|
| 任务启动极慢，一直显示 ACCEPTED | 大量并发任务抢占资源，或 AM 会话频繁创建 | 看 YARN 队列资源使用率 | 调大tez.session.am.dag.submit.time.secs，并排队错峰 |
| Tez 容器反复被杀 | 容器内存小于任务峰值内存 | 查看 Container 崩溃日志中的内存指标 | 调整hive.tez.container.size，降低tez.runtime.io.sort.mb |
| Spark Executor 频繁 OOM | 堆内存或堆外内存不足 | 看 Executor 日志里的 GC 统计和内存超限报错 | 调大spark.executor.memory或memoryOverheadFactor |
| 某个 Reduce/Stage 耗时极长 | 数据倾斜 | 对比多个 task 的耗时分布 | 开hive.groupby.skewindata，或对 key 加盐打散 |
| 小文件很多，Map 数爆炸 | 输入目录大量小文件 | 查看输入分片数量和文件统计 | 用合并输入格式或离线先做小文件合并 |
| 切换 Spark 后 SQL 结果不一致 | HINT 不生效或 UDF 行为差异 | 对比执行计划，检查 UDF 日志 | 重写 SQL 去掉老 HINT，重写或替换 UDF |
6. 选型决策清单：把“选择”变成可执行的规则
我知道很多人看完前面内容还是会纠结，毕竟每个集群情况不同。这里给一套我实际用过的决策清单，照着走一遍，基本能得出明确结论。
先把线上任务的统计报表拉出来，看几个关键指标：任务总数、平均执行时间、失败率、资源消耗 TOP 任务。然后做一次成本核算：如果切换到更快的引擎，省下来的是机器成本还是业务等待时间？如果夜间跑批本身就来得及，只是某个季度因为业务量翻倍开始超时，那先用 Tez 做一次平滑升级，观察一个月，往往就解决了。如果确实到了非 Spark 不可的地步，再考虑 Spark。
切流方案上，我强烈建议按这个节奏走：准备环境验证、小规模灰度、重点业务全量、全局默认切换。每一步之间至少留三到五天的观察期，重点看新引擎对失败任务重试机制的影响。Hive 任务在 MR 下失败后重试往往很快，但 Spark 下 Stage 重算的代价大，如果反复失败，反而会把调度器拖垮，这一点要提前设定重试上限。
另外保留一个兜底口子：全局切到 Tez 或 Spark 之后，仍然建议在调度系统里保留一条 MR 模式的任务通道，某些特殊任务（比如极端复杂的老 SQL、用到不太兼容的 UDF）如果在新引擎下反复失败，可以立刻指回 MR，避免业务方长时间等待。这个口子看似土的掉渣，但真到半夜出问题时，它是救命稻草。
最后再分享一个我自己的体会：选引擎这事，真的不要只盯着技术测评文章里的加速倍数。加速十倍的前提是资源管够、团队能扛住复杂排障、任务模式适合新引擎。我给团队做建议时，最看重的是“最不容易半夜惊醒的引擎”。先把你手上的任务历史和失败率拉出来看看，再决定切不切。我自己就踩过一次坑，在一个内存并不宽裕的集群上，因为想追求 Spark 的性能，结果内存等待和 Executor 反复 OOM 让任务平均失败率不降反升。后来老老实实切回 Tez，把稳定性做扎实，又花了小半年时间，才逐步把真正适合 Spark 的批次任务迁移过去。稳，有时候比快更重要。
