圆山中庸把执行引擎从 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 开销往往比