从 Hive 慢查询到集群资源吃饱：一次 Tez 引擎资源限制的完整调优记录
如果你正在管理一套 Hadoop 集群，并且 Hive 跑批经常出现“有资源但任务跑不动”、Container 反复被杀、明明节点很多但并发上不去这类问题，那这篇文章大概率对你有用。我这次要分享的是针对 Apache Tez 引擎做资源限制与参数调优的完整过程，核心目标是让集群资源在稳定可控的前提下跑满跑透，而不是简单粗暴地堆内存。
Tez 引擎相比老 MapReduce 模型的优势不用多吹，DAG 化执行、避免中间结果反复落盘、算子复用这些特性让它成为 Hive on Tez 的主流选择。但在实际生产里，Tez 的资源模型和 MR 差异很大，如果直接把 MR 时代的参数习惯搬过来，往往会遇到两类典型问题：一个是 Tez 容器内存越开越大，导致 ApplicationMaster 被 YARN 频繁杀死；另一个是并发能力上不去，资源利用率看着只有 30%，任务却已经排队排队到天荒地老。下面我把这次优化的思路、关键参数、计算公式、踩坑实录全部整理出来，方便你在自己的集群上直接复现。
1. 先搞明白 Tez 的资源模型再动手
1.1 Tez 与 MR 资源管理本质区别
很多从 MR 迁移过来的同学最容易犯的错，就是习惯性地把 hive.tez.container.size 和 mapreduce.map.memory.mb 混为一谈。实际上 Tez 的容器模型更贴近 YARN 原生的“容器即资源抽象”概念：一个 Tez Container 就是一个被 YARN 托管的内存+CPU 组合单元，同一个 Container 里可以顺序执行多个 Tez Task，也可以被复用执行多个 DAG 节点。
MR 时代是“一个 MapTask 一个 JVM”，跑完就销毁，资源分配是粗粒度、短生命周期的。Tez 走的是“容器复用”路线：一个 Container 启动之后，它的 JVM 不会因为某个 Task 跑完而退出，而是继续装载下一批 Task。这种设计省掉了大量 JVM 启动开销，但副作用是——如果容器内部的内存规划不精确，残留任务和数据块会把 JVM 撑爆，表现就是莫名其妙的 Container OOM，但其实 YARN 日志里所有任务的物理内存都在限额之内。
所以，理解 Tez 资源限制的核心，不能只看“一个任务要多少内存”，而要同时看三个维度：
- 容器总内存（Container Memory）
- JVM 可用堆内存（通过 java opts 控制）
- 容器内并发任务数与 CPU 配额的关系
1.2 资源限制为什么会导致“假性饥饿”
我这次接手的一个典型场景：集群共 8 台节点，单机 128GB 内存，YARN 可分配资源配到了 96GB，vCore 配到 32 个。理论上总共可分配 768GB 内存、256 vCore。但跑了一个中等量级的 Hive 离线任务，观测下来资源利用率长期徘徊在 25% 上下，并行度始终推不上去。
看 YARN 调度面板，每个节点都有足够的空闲内存，可是新容器就是起不来。后来检查发现，问题根源在于某个任务配置的 Container 内存为 16GB，但hive.tez.java.opts只给了 8GB 堆。这个不叫“资源不够”，而是“JVM 最大堆内存远小于容器内存”，导致任务执行时频繁触发 Full GC，实际处理能力被压得很低，数据吞吐上不去，于是其他等待的 Task 就绪队列越拉越长。
更隐蔽的问题在于 CPU 配额没有和内存一起调整。当时tez.task.resource.cpu.vcores一直保持默认的 1，容器内存 16GB 意味着单机最多同时跑 6 个容器（96GB可用），但 CPU 只有 6 个 vCore 在干活，剩下 26 个 vCore 全部闲置。容器内存翻了好几倍，CPU 没跟上，处理器利用率的“假性饥饿”就是这么来的。
2. 解析 Tez 资源限制涉及的核心参数
2.1 内存链路：Container 与 JVM 的关系
Tez 的资源限制配置主要由几个参数组成，理解它们的层级关系非常重要：
| 参数 | 作用 | 默认值 | 说明 |
|---|---|---|---|
| hive.tez.container.size | Tez 容器总内存 | 4096MB | 这是最核心的总闸门，约等于 MR 时代 mapreduce.map.memory.mb |
| hive.tez.java.opts | Tez 容器内 JVM 启动参数 | -Xmx2048m | 设置堆内存最大值，必须低于容器总内存 |
| tez.am.resource.memory.mb | Tez ApplicationMaster 内存 | 1024MB | AM 负责调度协调，内存太小会导致任务提交失败或恢复困难 |
| tez.am.java.opts | AM 的 JVM 堆参数 | -Xmx512m | 需要和 AM 内存配套调整 |
| tez.task.resource.memory.mb | 单个 Tez Task 内存上限 | 动态 | 通常建议和容器内存保持一致或略低 |
我习惯把这条链路理解成“房子和人的关系”：hive.tez.container.size是租下来的房子总面积，hive.tez.java.opts是房子里摆的床铺大小（JVM 堆），而tez.task.resource.memory.mb是住进来的房客占用的活动空间。房子不能小于床铺，房客也不能超出房子的承载能力，三者一旦失衡，轻则浪费租金，重则房塌人伤。
2.2 CPU 和并行度的隐形上限
除了内存，还有一组 CPU 参数在限制 Tez 的吞吐效率：
- tez.task.resource.cpu.vcores：每个 Tez Task 申请的虚拟 CPU 核数，默认 1
- hive.tez.max.task.data.size：单 Task 处理的数据量阈值，默认 1GB（影响动态拆分）
- hive.tez.dynamic.partitioning.max：动态分区的最大数量
- hive.exec.parallel：控制 Stage 级并行，默认 false
- hive.exec.parallel.thread.number：并行执行的最大线程数
很多人只调内存不调 CPU，结果就是内存开得很大但 CPU 空闲。CPU 核数设置还会影响 YARN 调度器对容器数量的计算。举个例子，单节点 32 vCore，如果设置每个容器 4 vCore，那么理论上单机最多同时运行 8 个容器；如果保持默认 1 vCore，但内存 16GB，单机最多同时运行 6 个容器（受内存限制），这时候节点上其实有 26 个 vCore 在摸鱼。
2.3 YARN 层面的全局约束
优化 Tez 之前，最好先盘点一下 YARN 本身的资源约束参数，这些是全局天花板：
- yarn.nodemanager.resource.memory-mb：单节点可供 YARN 使用的总内存
- yarn.nodemanager.resource.cpu-vcores：单节点可供 YARN 使用的总 vCore
- yarn.scheduler.maximum-allocation-mb：单个容器可申请的最大内存
- yarn.scheduler.minimum-allocation-mb：单个容器可申请的最小内存（默认 1024MB，会向上取整）
有几个实践教训：YARN 的maximum-allocation-mb如果小于 Tez 请求的容器内存，任务会被直接拒绝；minimum-allocation-mb如果设置过大，会浪费小任务的内存资源。很多集群把这两个参数遗忘了，结果 Tez 侧怎么调都是白调——YARN 那层根本不给你这么大的容器。
3. 优化实战：一次完整的参数计算与配置流程
3.1 摸清集群资源底账
这一步是全部优化的地基。我这次集群的基本情况如下：
- 节点数：8
- 单机物理内存：128GB
- 单机 CPU 逻辑核：32
- 操作系统预留：内存 20GB，CPU 4 核（给系统进程、HDFS DataNode、系统组件等用）
于是每台节点可供 YARN 的资源为：
- 内存：128 - 20 = 108GB，保守再留 8GB 余量，取 100GB
- CPU：32 - 4 = 28 vCore
集群整体可用：内存 800GB，vCore 224。这里我特意强调“保守再留余量”，因为在实际运行中 NodeManager、容器外进程、JVM 堆外内存都是会吃内存的，一次性分干榨净的配置必然导致节点不稳定。
3.2 从业务需求推导容器规格
我的目标是把日批量任务控制在 1.5 小时内完成，任务总共要处理约 6TB 输入数据，涉及多个 join 和 group by，shuffle 量较大。
首先确定单容器内存。考虑数据倾斜风险和 JVM GC 压力，我选 8GB 作为容器基线：hive.tez.container.size = 8192MB。为什么不选更大的 16GB？因为根据经验，大容器会降低并行度，而且一旦某个 Container 内并发 Task 数过多，单个节点上的资源调度就会变得迟钝。反过来，小于 4GB 的容器在 shuffle 数据量大的场景又容易频繁溢写和 GC。8GB 是一个很多生产集群验证过的平衡点。
接着是 JVM 堆内存。我遵循“堆内存占容器内存 70% 到 80%”的安全原则。但要注意，Java 进程的堆外内存（Metaspace、线程栈、IO 缓冲等）也都在容器边界内，如果堆内存顶到 90%，很快会被 YARN 判定为物理内存超限杀死。这次配置为：
hive.tez.java.opts=-Xmx6144m -Djava.net.preferIPv4Stack=true这里-Xmx6144m是 6GB，约占容器内存的 75%。剩余 2GB 留给堆外和 JVM 自身开销，稳妥。
然后看 CPU。我们单机 28 vCore，容器内存 8GB，单机最多能同时跑 12 个这样的容器（100GB / 8GB ≈ 12）。为了让 CPU 不成为瓶颈，我把 CPU 配额设置成 2 vCore 每容器：
tez.task.resource.cpu.vcores=2 tez.task.resource.memory.mb=8192这样单机满载时大约会占用 24 vCore，还有 4 个 vCore 余量给 AM、日志聚合、系统抖动等场景。这里的核心计算逻辑是：单机容器数量上限 = min(内存配额/单容器内存, CPU配额/单容器vCore)。我要让这两个比值尽量接近，才不会出现“内存够但 CPU 不够”或相反的情况。按上面的值，内存维度可以跑 12 个容器，CPU 维度可以跑 14 个容器（28/2），取较小值就是 12 个，两端平衡。
3.3 AM 与 Executor 的专属配置
Tez ApplicationMaster 是任务的“大脑”，负责 DAG 调度和 Container 申请。我遇到的 AM 频繁崩溃，往往就是 AM 内存太小导致。AM 本身也走一个独立容器，和 Task 容器互不共享。
tez.am.resource.memory.mb=2048 tez.am.java.opts=-Xmx1536mAM 容器设 2GB，堆内存 1.5GB，这个配置在日均几百个任务的集群上都没问题。如果你有两个很大的 DAG（比如几千个 Vertex），AM 需要承载更多状态信息，届时可以考虑把 AM 堆内存提升到 2GB 或 3GB。另外顺手把 AM 的 CPU 配额也给了：
tez.am.resource.cpu.vcores=1这部分开销不大，但如果节点资源被占满，AM 容器起不来，整个任务会卡在“Submitted”状态无法前进。在做资源限制时，记得给 AM 留出口。
3.4 调整动态资源分配与并行度
Tez 支持动态调整单个 Task 的内存和并行度。在生产里，我通常会关掉完全不合理的动态资源分配，采用固定配置更利于观测和复现：
tez.runtime.optimize.memory=true tez.runtime.unordered.output.buffer.size-mb=256 tez.runtime.io.sort.mb=256 hive.auto.convert.join=true hive.auto.convert.join.noconditionaltask.size=524288000 hive.exec.parallel=true hive.exec.parallel.thread.number=16tez.runtime.unordered.output.buffer.size-mb和tez.runtime.io.sort.mb控制数据在内存中排序和缓冲的大小。在 8GB 容器下，我给到 256MB 跑批任务，实际表现良好。hive.exec.parallel打开后，多个无依赖的 Stage 会并行执行，能显著压缩整体 DAG 时间，但这也意味着瞬时资源申请量会变大，所以务必确保 AM 内存和 YARN 的调度上限能扛住。
这里还要强调一个并行度参数——hive.tez.max.partition（默认 4096？实际上更常用的检查项是hive.exec.reducers.bytes.per.reducer）：
hive.exec.reducers.bytes.per.reducer=536870912 hive.tez.min.partition.factor=0.25 hive.tez.max.partition.factor=0.5每个 Reducer 处理 512MB 左右的输入，动态调整分区数，避免因 reducer 数量过少导致长尾或数据倾斜。这个在 join 大表场景下特别重要，因为 Tez 不会像 MR 那样按固定分区数盲算。
3.5 将配置落地到集群
配置生效有两种途径：一种是加到 Hive 的hive-site.xml全局生效，另一种是在 SQL 会话里用set临时调整。我建议一个调优项目里，先用set做小规模验证，跑 3 到 5 个典型任务确认稳定后再写进配置文件。
这里贴一份我当时验证用的初始化脚本片段：
set hive.tez.container.size=8192; set hive.tez.java.opts=-Xmx6144m -Djava.net.preferIPv4Stack=true; set tez.am.resource.memory.mb=2048; set tez.am.java.opts=-Xmx1536m; set tez.task.resource.memory.mb=8192; set tez.task.resource.cpu.vcores=2; set hive.exec.parallel=true; set hive.exec.parallel.thread.number=16; set hive.auto.convert.join=true; set hive.auto.convert.join.noconditionaltask.size=524288000; set hive.exec.reducers.bytes.per.reducer=536870912;注意这些 set 命令只在当前会话有效。如果任务是通过调度平台以脚本方式提交的，需要把这段配置统一写进脚本模板里，否则调度任务不会自动带上。
还有一点：在 HiveServer2 的长连接模式下，如果之前的用户会话修改过这些参数，可能会导致同一会话后续查询互相污染。最稳妥的做法是在每次执行耗资源查询前，显式置回一套标准配置，而不是依赖全局默认值。
4. 优化效果验证与动态调整策略
4.1 新老配置对比实测
我拿了一套典型的日批任务做验证。任务逻辑是：3 张大表 join + 1 个 group by + 动态分区写入输出表。处理数据量约 1.2TB。
| 配置项 | 优化前 | 优化后 |
|---|---|---|
| 容器内存 | 4096MB | 8192MB |
| JVM 堆 | 2048MB | 6144MB |
| Task vCore | 1 | 2 |
| AM 内存 | 1024MB | 2048MB |
| 单节点并发容器数 | 约 24 个 | 约 12 个 |
| 运行时长 | 68 分钟 | 31 分钟 |
| 峰值内存利用率 | 32% | 83% |
| 峰值 CPU 利用率 | 18% | 71% |
| Container 被杀次数 | 4 次 | 0 次 |
优化前虽然单节点能跑 24 个容器，但每个容器 JVM 只有 2GB 堆，面对 1.2TB 的 shuffle 数据时每个 Task 处理能力不足，导致大量的磁盘溢写和 GC 停顿，整体并不快。优化后容器数减半，但每个 Task 的吞吐几乎翻了两倍，整体耗时不升反降。
有个反直觉的点值得单独拎出来：容器并发数少，不等于性能差。关键是每个容器的数据处理效率和资源配比是否匹配。我们优化的目标不是“塞满容器”，而是让每个容器以合理的性能跑完任务。
4.2 监控面板重点看什么
优化完不等于一劳永逸，生产环境还是要通过观测来持续调整。我主要看三个维度的指标：
- 资源利用均衡度：观察每个节点的 CPU 和内存利用率，如果出现某些节点跑满、某些节点空闲，可能是数据本地性或调度不均导致
- Shuffle 阶段的执行时间：Tez UI 里查看每个 Vertex 的耗时，如果 Shuffle 时间占比超过 40%，说明并行度和内存缓冲还要调整
- GC 日志和 Container 日志：重点关注 Full GC 的频率和时长，Full GC 频繁说明堆内存给小了，或单容器内 Task 数过多
我实际观察过一种情况：某个 Vertex 的 map 阶段耗时极短，但 reduce 阶段等待数据的时间很长。这通常是因为 map 任务的输出在内存缓冲里放不下，提前溢写磁盘，导致 reduce 拉取时狂做 IO。此时调整tez.runtime.io.sort.mb和tez.runtime.unordered.output.buffer.size-mb往往比单纯加容器内存更有用。
4.3 动态调整的节奏建议
这里整理一下我常用的动态调整步骤，适合新接手一套集群的读者按顺序执行：
- 先跑一个基线任务，记录完成时间、资源利用率、Container 数量
- 调高
hive.tez.container.size到 8GB，同步设置 JVM 堆和 CPU vCore，保证配比合理 - 观察任务完成时间和容器被杀情况，如果 OOM 减少、时间下降，说明配比到位；如果出现 CPU 等待或资源排队，适当降低容器数
- 开启
hive.exec.parallel，并行度从 4 开始递增测试，直到 CPU 利用率达到 70% 以上且稳定性不下降 - 每轮验证时只改动一个维度的参数，方便定位问题来源
有几个参数组合在工程上特别值得注意。hive.tez.container.size和tez.task.resource.memory.mb这两个参数的值如果差距过大，会导致 Tez 在申请资源时反复调整容器规格，反而增加调度开销。我通常直接让tez.task.resource.memory.mb等于容器大小，宁可任务少开几个并发，也不让容器规格漂移。
5. 常见问题与排查实录
5.1 Container 反复被杀，日志提示物理内存超限
这是个高频问题。现象是任务跑了一半，YARN 的 NodeManager 日志里出现Container killed ... memory limit exceeded。
排查思路：
- 先看该容器的内存请求额和
hive.tez.java.opts的堆设置。如果 -Xmx 设得太接近容器内存，堆外内存很容易把容器撑爆 - 用
yarn logs -applicationId拉取该容器的 GC 日志，确认堆内存使用峰值 - 检查是否有系统内存缓存干扰（Page Cache），
Linux Container Executor模式下会统计物理内存，很多场景是 HDFS 读路径中的页缓存没被回收而导致超限误判
解决方案通常是把堆内存占容器比例控制在 70%-80%，并且给 NodeManager 预留更大的系统内存缓冲。此外可以调整：
yarn.nodemanager.vmem-pmem-ratio=2.1但这个值不要拉得过高，否则容易掩盖真实的内存泄漏问题。
5.2 容器内存很大，但任务仍然慢
有一种情况很“诡异”：容器内存已经开到 16GB，CPU 也有 4 vCore，但 Tez UI 显示任务的关键路径耗时还是很高。后来我查了tez.task.resource.cpu.vcores和 YARN 的调度比例才发现，容器虽然申请了 4 vCore，但实际 Task 内部还有细粒度的并行分配，如果hive.tez.max.worker.threads或者 JVM 线程数受限，CPU 利用率同样起不来。
这里有个隐藏的参数tez.task.max.memory，在部分版本中会单独限制任务内存。如果容器内存开得很大，但某个 Task 被限制在较小的内存块中，任务还是会在小堆里挣扎。我在生产里直接统一了这一组值，避免多个参数各自为政互相矛盾。
另一个检查项是数据倾斜。Tez 的动态分区调整在处理倾斜 join 时，如果hive.optimize.skewjoin=true开启，要注意倾斜任务的额外资源申请是否超出了 YARN 的调度上限。在资源受限的环境，倾斜任务可能会导致系统反复申请大容器而失败，表现为任务卡在“Pending”状态。
5.3 AM 起不来，任务提交后一直 Pending
如果 AM 容器内存大于 YARN 的yarn.scheduler.maximum-allocation-mb，ApplicationMaster 会一直申请不到资源。注意这个参数是“单容器可申请的内存上限”，很多集群默认才 8GB。如果tez.am.resource.memory.mb配到 4GB 以上，先检查这个全局上限是否够用。
另外还要确认：
yarn.app-mapreduce.am.resource.mb=2048某些发行版的 Tez 会读取这个旧参数作为 AM 的基线，导致和tez.am.resource.memory.mb冲突。建议把两处都统一设置，避免调度时取到意外值。
5.4 小文件过多导致 Tez 任务启动过慢
Tez 的优势是减少中间落盘，但如果输入是几十万个小文件，Driver 端要构建的文件列表会拖慢 Job 启动甚至撑爆 AM 内存。这种情况靠资源参数解决不了，要在数仓模型上治理小文件，或者使用分区合并、hive.merge.mapfiles/hive.merge.mapredfiles等参数提前合并。
资源限制优化管的是“给了任务多少资源”，如果任务本身存在大量无效开销，再大的池子也填不满性能缺口。我处理过最极端的一个案例，Task 数量超过 3 万个，AM 内存 2GB 依然在生成执行计划时 OOM，最后靠源头合并输入文件才真正解决。
5.5 shuffle 数据量巨大导致节点磁盘写满
调大容器内存后，如果tez.runtime.io.sort.mb没跟着调，shuffle 数据还是会在内存缓冲溢满后大量落盘，在某些情形下比调优前写盘还多。我在一次验证中观察到一个 2TB shuffle 的任务，磁盘 IO 占比高达 85%，节点磁盘在高峰期几乎打满。
解决办法是分析任务日志中的 shuffle 指标：
- 如果
spilled records数量很多，说明内存排序缓冲太小，需要调大tez.runtime.io.sort.mb或tez.runtime.unordered.output.buffer.size-mb - 如果单个容器处理的数据量过大，需要让 Tez 动态拆分，适当调低
hive.tez.max.task.data.size
当然，也要合理评估节点存储。对于 shuffle 很重的批任务，节点上只要有足够的临时目录空间，并且把yarn.nodemanager.local-dirs配置到多块盘上分散 IO，能明显缓解单盘热度。
6. 资源限制优化后的一些个人体会
调优 Tez 引擎的资源限制，真正考验的不是记住几个参数，而是理解资源链路的耦合关系。内存、CPU、容器数、JVM 堆、YARN 上限这五者必须放在同一张表里通盘计算。就拿 Container 数量来说，不是越多越好，也不是越少越好，而是要和单容器处理能力相乘后得到最大吞吐。
我个人在实践中还有一个体会：参数配置要留有安全余量。有人喜欢把节点资源算到 99%，追求极致的利用率，但生产环境不是实验室，HDFS 的短时峰值、其他组件的突发占用、Java 堆外内存的波动，都会让极限配置在一夜之间拖垮节点。我通常把 YARN 资源配到物理资源的 80% 左右，后续再根据实际监控慢慢加，这比一次性打满稳定得多。
另外，一定要养成记录配置变更的习惯。Tez 参数之间联动很隐蔽，今天改了容器的 CPU 配额，明天可能就会影响 AM 的调度优先级。我维护过一份“参数变更日志”，每次调整都记录旧值、新值、验证任务耗时和资源利用数据，后续问题回溯时省了非常多时间。
最后分享一个追加的小技巧：如果你在测试环境验证参数，可以在 Tez UI 里勾选“查看每个 Vertex 的容器分布”。哪些 Container 在等待资源、哪些 Container 做了大量 GC，这张图比任何监控仪表盘都直观。许多调优决策，我是看着这张图才拍板的——仔细研究过的容器分布，比盲目迭代参数的效率高得多。
