圆山中庸把执行引擎从 MapReduce 切到 Tez 之后，我这边负责的 Hive 离线任务平均耗时下降了 70% 左右，最夸张的一个从 63 分钟降到了 11 分钟。后面团队内部照着这套配置推广到其他几条业务线，只要 SQL 本身没写崩，基本都能稳定拿到三倍以上的提速。
这篇文章是完整的 Tez 引擎配置指南，包含版本选型、部署步骤、参数取舍逻辑，以及我实际使用中踩过的高发问题排查过程。适合的读者很明确：你正在用 Hive 跑 T+1 离线任务，执行引擎还是默认的 MapReduce，SQL 里有 join、子查询、多级聚合，任务动不动跑十几分钟甚至个把小时，那么这篇文章可以帮你把大部分任务的时间直接砍掉一大截。我会尽量把每一步背后的原因讲透，而不是丢给你一份参数清单让你照抄。
1. MapReduce拖后腿的根源，也是Tez的切入点
1.1 一条三阶段SQL，MR把它拆成了三个独立Job
写过 Hive SQL 的人都有感觉，一条稍微复杂的查询会先被翻译成一棵执行计划树。以最常见的两表关联加分组聚合为例：
sql复制SELECT u.city, COUNT(1) AS cnt, SUM(o.amount) AS amt
FROM orders o JOIN users u ON o.user_id = u.id
WHERE o.dt BETWEEN '2025-01-01' AND '2025-01-31'
GROUP BY u.city;
在 MapReduce 引擎下，这条 SQL 通常被拆成两个甚至三个 MR Job，先后串行执行。每个 Job 都要从头跑一遍 Map、Shuffle、Reduce 三个阶段；上一个 Job 的输出必须落盘到 HDFS，下一个 Job 再从 HDFS 读回来。如果你的查询里还有多个子查询嵌套，比如三层 join，MR 引擎会把整棵树拍平成三四个独立 Job，依次排队执行。
这和 Spark、Tez 那一类 DAG 调度是完全不同的逻辑。MR 引擎的多个 Job 之间没有"管道"衔接：上游 Job 不结束，下游 Job 根本不会启动，中间结果全部落进临时目录。换句话说，一条 SQL 每多一级 join 或子查询，就多一次完整的 HDFS 写读往返。在数据量大的场景下，这个磁盘 IO 开销往往比计算本身还高，这也是"为什么 hive 执行流程看着简单，但跑起来就是慢"的主要答案。
1.2 每个Task都要重新拉起JVM，隐性成本被严重低估
除了中间结果落盘，MR 引擎还有一个很重的隐性开销：每个 MapTask、ReduceTask 都会启动一个独立的 JVM。虽然 YARN 对容器有一定复用能力，但 MR AppMaster 管理 Task 进程的方式比较笨重，一个 Task 跑完 JVM 就退出，下一个 Task 重新 new 一个 JVM。
我在一个 64GB 内存的节点上统计过，一个包含 2000 来个 MapTask 的任务，光耗在 JVM 启动、类加载、初始化这些环节上的时间，累计就能超过 3 分钟。任务越短，这笔固定成本占的比例越离谱。跑 2 分钟的小任务，启动开销可能就占了接近一半；跑 1 小时的超大任务，这些浪费被摊薄，反而不那么明显。
1.3 Tez 的思路：把执行计划变成一张 DAG，中间数据不用回 HDFS
Tez 的核心做法，是把 MR 里 Map、Shuffle、Reduce 这种固定执行阶段，抽象成更细粒度的算子：Input、Processor、Output、Edge。它允许一个任务的输出直接作为下一个任务的输入，中间数据可以留在内存或者本地磁盘，不需要回到