Hive参数调优实战：Tez与MR引擎下的12个核心参数深度解析

1. 为什么调优Hive参数不是“锦上添花”而是“生死线”你有没有遇到过这样的场景一条看似简单的SELECT COUNT(*) FROM sales_detail WHERE dt2024-06-01在Hive里跑了47分钟才出结果而同一张表、同样分区在另一套集群上32秒就返回数据量、硬件配置、表结构完全一致——唯一的变量是那几十个被默认值“默默守护”的Hive配置参数。这不是玄学这是Hive执行引擎Tez或MapReduce与底层资源调度、数据分片、内存管理之间千丝万缕的耦合关系在真实业务压力下的集中爆发。我带过的三个不同行业的项目组——某电商大促实时报表系统、某金融风控离线特征计算平台、某物流轨迹分析中台——无一例外都在上线后第2~3周遭遇“性能悬崖”SQL响应时间从秒级陡增至分钟级任务失败率突然飙升YARN队列持续满载。排查下来90%以上的问题根源不在SQL写法也不在HDFS读写瓶颈而在于Hive运行时参数与实际工作负载严重错配。比如把面向小批量ETL设计的hive.exec.reducers.bytes.per.reducer6710886464MB直接用在单次扫描TB级宽表的聚合场景会导致reducer数量被错误压缩到个位数整个作业变成单点瓶颈又比如在Tez引擎下盲目沿用MR时代的mapreduce.map.memory.mb思维却忽略了Tez DAG中Vertex内存需独立配置的特性结果是Container频繁OOM重启日志里刷屏ExitCodeException exitCode143。这些参数不是教科书里的抽象概念它们是Hive这台精密仪器的“油门踏板”“变速箱档位”和“冷却液流速”。调优的本质不是堆砌参数清单而是理解数据流动的物理路径数据如何从HDFS块被切片、如何在Mapper/Vertex中解码、中间结果如何序列化溢写、Shuffle阶段网络与磁盘如何协同、Reducer/Tez Sink如何合并并输出。Tez和MR虽同为执行引擎但架构哲学截然不同——MR是线性流水线Tez是DAG有向无环图MR靠JobTracker全局调度Tez依赖AMApplicationMaster动态编排MR的Shuffle是固定两阶段Tez可融合多个Stage减少落盘。这意味着同一组参数在MR下可能稳定在Tez下却引发雪崩反之亦然。本文不讲泛泛而谈的“推荐配置”只聚焦生产环境高频踩坑的12个核心参数逐个拆解其物理意义、影响边界、实测阈值与交叉约束关系。无论你是刚接触Hive的ETL工程师还是负责集群SLA的平台运维都能从中拿到可立即验证的判断依据和调整策略。2. 执行引擎选型与参数体系的底层逻辑差异2.1 Tez与MR不只是“快一点”的技术升级很多人以为Tez只是MR的加速版把hive.execution.enginetez一改就万事大吉。这种认知在真实生产中极其危险。我曾亲眼见证一个金融客户将关键对账任务从MR切换至Tez后单日失败率从0.3%飙升至17%根本原因在于Tez的资源模型与MR存在范式级差异而团队仍用MR的思维配置Tez。维度MapReduce (MR)Tez执行模型严格线性Map → Shuffle → Reduce → OutputDAG图可融合MapReduceMRR、多输入多输出Union、条件分支Conditional内存管理全局统一mapreduce.map.memory.mb/mapreduce.reduce.memory.mb控制JVM堆大小分层独立tez.runtime.io.sort.mb排序内存、tez.runtime.unordered.output.buffer.size-mb输出缓冲区、tez.grouping.min-size分组最小尺寸需单独调优Shuffle机制固定两阶段Map端Spill→Merge→Copy→Sort→Reduce动态优化支持In-Process Shuffle避免网络传输、Combiner自动注入、Intermediate Data Compression中间数据压缩容错粒度Job级任一Task失败整个Job重跑Vertex级单个Vertex失败仅重跑该节点上游结果可复用这个差异直接决定了参数调优的起点。例如MR中mapreduce.task.io.sort.mb默认100MB控制Map端排序内存超过则Spill到磁盘而在Tez中对应的是tez.runtime.io.sort.mb但它的作用范围仅限于当前Vertex的排序阶段且受tez.runtime.unordered.output.buffer.size-mb默认100MB制约——后者决定Map输出到Shuffle前的内存缓冲区大小。若只调大前者却不匹配后者缓冲区会提前溢出反而增加Spill次数。这就是为什么我们常说“Tez不是MR的替代品而是需要重新学习的执行范式”。2.2 Hive参数的三层作用域Session Query GlobalHive参数生效优先级遵循明确的覆盖链Session级 Query级 Global级。很多线上问题源于混淆了作用域。比如某团队在HiveServer2连接串中设置了hive.tez.container.size4096全局但某个超大宽表JOIN任务在SQL中显式指定SET hive.tez.container.size8192;结果发现并未生效——因为该参数属于Global-only无法在Session或Query中动态覆盖。类似地hive.exec.dynamic.partition.modenonstrict必须在Session初始化时设置若在已运行的Session中执行SET命令对后续动态分区INSERT无效。更隐蔽的是参数间的隐式依赖。以hive.exec.reducers.bytes.per.reducer为例它仅在hive.exec.reducers.max未被显式设置时才参与计算reducer数量。而hive.exec.reducers.max本身又受hive.exec.reducers.bytes.per.reducer和输入数据量共同约束。公式如下numReducers min(hive.exec.reducers.max, ceil(totalInputBytes / hive.exec.reducers.bytes.per.reducer))其中totalInputBytes并非简单等于SELECT COUNT(*)的行数而是HDFS中该分区所有文件的原始字节大小含压缩比。我曾处理过一个案例一张Snappy压缩的表逻辑数据量1.2TB但HDFS占用仅380GB。团队按1.2TB计算reducer数结果分配了18个reducer每个处理21GB原始数据远超tez.runtime.io.sort.mb的承载能力导致大量Spill和GC。正确做法是先用hdfs dfs -du -s /path/to/table/dt2024-06-01获取真实HDFS字节数再代入公式。2.3 调优不是“调参”而是构建“参数决策树”真正的调优是建立一套基于工作负载特征的决策流程。我们团队沉淀出的“Hive参数决策树”包含四个关键分支数据规模识别小数据1GB优先启用hive.optimize.skewjointrue倾斜Join优化关闭hive.exec.paralleltrue并行执行避免小任务启动开销反超收益。中等数据1GB~100GB重点调优tez.grouping.min-size默认16MB和tez.grouping.max-size默认1GB控制InputSplit数量避免过多小Task拖慢整体进度。大数据100GB必须启用hive.optimize.index.filtertrue索引过滤和hive.optimize.ppdtrue谓词下推并严格限制hive.exec.reducers.bytes.per.reducer≤128MB确保reducer数量充足。计算类型判断聚合类COUNT/SUM/AVG提升hive.map.aggrtrueMap端聚合和hive.map.aggr.hash.percentmemory0.5Hash内存占比减少Shuffle数据量。JOIN类针对大表JOIN大表强制set hive.auto.convert.jointrue自动转MapJoin并设置hive.mapjoin.smalltable.filesize2500000025MB若小表超限则启用hive.optimize.skewjointrue并配合hive.skewjoin.key100000倾斜键阈值。排序类ORDER BY禁用hive.optimize.sort.dynamic.partitiontrue动态分区排序优化改用DISTRIBUTE BY SORT BY组合避免单点Reducer。引擎特性适配MR引擎关注mapreduce.map.sort.spill.percentSpill阈值默认0.8和mapreduce.reduce.shuffle.input.buffer.percentShuffle输入缓冲区默认0.7Tez引擎必须配置tez.runtime.intermediate-input.is-compressedtrue中间数据压缩和tez.runtime.compresstrue运行时压缩否则Shuffle网络流量激增300%。资源约束反推若YARN队列内存上限为16GBtez.container.size必须≤16384且需预留20%给JVM Overhead故实际设为1310712GB若单节点磁盘IO吞吐瓶颈为120MB/stez.runtime.io.sort.mb不宜超过20482GB否则Spill写盘成为瓶颈。这套决策树不是静态规则而是随集群负载动态演进的。我们会在每个季度的容量规划会上用真实作业的EXPLAIN执行计划和YARN Application Timeline Server数据校准各分支的阈值参数。3. 12个高频核心参数的深度解析与实操指南3.1hive.exec.reducers.bytes.per.reducerreducer数量的“黄金比例尺”这个参数常被误认为“越大越好”实则不然。它的本质是估算每个reducer应处理的数据量字节Hive据此计算最优reducer数量。默认值6710886464MB源自Hadoop 1.x时代机械硬盘的随机读写特性而现代SSD集群的IOPS能力已提升百倍此值需大幅下调。物理原理当reducer处理的数据量远超其内存缓冲区如Tez的tez.runtime.io.sort.mb时会触发频繁Spill到本地磁盘再由Shuffle Service读取。一次Spill涉及内存拷贝→序列化→磁盘写入→文件元数据更新→Shuffle读取→反序列化耗时可达毫秒级。若单个reducer处理200MB数据而tez.runtime.io.sort.mb1024则至少发生200次Spill而10个reducer各处理20MB仅需20次Spill总耗时下降近90%。实测阈值HDD集群建议128MB~256MB降低Task数量减少磁盘寻道SSD集群建议32MB~64MB提升并行度压榨SSD高IOPS内存密集型聚合建议16MB如COUNT DISTINCT on high-cardinality column操作步骤获取目标分区HDFS真实字节数hdfs dfs -du -s /user/hive/warehouse/sales_db.db/sales_detail/dt2024-06-01 # 输出382456789012 /user/hive/warehouse/sales_db.db/sales_detail/dt2024-06-01计算理论reducer数numReducers ceil(382456789012 / 33554432) ≈ 11392按32MB计算验证YARN资源若tez.container.size8192单节点最多运行2个Container则需确保集群NodeManager总数≥5696否则会因资源不足排队。此时应折中设为64MB得5696个reducer再通过hive.exec.reducers.max4000硬性限制。提示永远用EXPLAIN验证效果。执行EXPLAIN SELECT COUNT(*) FROM sales_detail WHERE dt2024-06-01;后查看Stage-1的Reducer部分确认Number of reduce tasks是否接近计算值。若偏差20%检查是否有hive.exec.reducers.max硬性截断。3.2tez.runtime.io.sort.mbTez的“心脏起搏器”这是Tez引擎最敏感的参数之一直接影响Vertex的内存使用效率和Spill频率。默认值10241GB看似充裕但在高并发场景下极易成为瓶颈。为什么1GB不够用Tez的Vertex内存分为三块tez.runtime.io.sort.mb用于排序和Shuffle输入缓冲核心tez.runtime.unordered.output.buffer.size-mbMap输出缓冲区默认100MBJVM Heap Overhead约20%的额外开销当tez.runtime.io.sort.mb1024时实际可用排序内存≈820MB。若单个Vertex需处理5GB中间数据常见于大表JOIN则发生5次以上Spill每次Spill写入磁盘约1GB而SSD的随机写IOPS仅约50K单次Spill耗时≈20ms5次即100ms叠加网络传输整个Shuffle阶段延迟飙升。实测调优方案基础值tez.runtime.io.sort.mb min(4096, 0.3 * tez.container.size)例tez.container.size8192→tez.runtime.io.sort.mb2457高并发场景若单节点运行≥4个Tez AM需降为tez.runtime.io.sort.mb1024同时提升tez.runtime.unordered.output.buffer.size-mb256用缓冲区换排序内存。倾斜数据场景启用tez.runtime.sort.threads4默认1让多线程并行排序缓解单线程瓶颈。验证方法在Tez UI中查看Vertex详情页的Metrics标签页重点关注SpilledRecords理想值100010000说明严重SpillShuffleOutputsFailed0表示网络或磁盘故障PhysicalMemoryKbytes峰值内存使用量应tez.container.size * 0.83.3hive.map.aggr与hive.map.aggr.hash.percentmemoryMap端聚合的“双保险”这两个参数协同工作实现Map阶段的局部聚合大幅减少Shuffle数据量。hive.map.aggrtrue开启功能hive.map.aggr.hash.percentmemory指定Hash表占用Map Task内存的比例。为什么必须调高percentmemory默认hive.map.aggr.hash.percentmemory0.550%但Map Task的JVM内存由mapreduce.map.memory.mbMR或tez.container.sizeTez决定。若tez.container.size8192则Hash表仅能用4096MB。然而高基数字段如用户ID的Hash表内存消耗呈O(n)增长n为唯一键数量。一张1亿行的表若用户ID去重后有5000万每个Entry约128字节KeyValue指针则Hash表需6.4GB内存——远超4096MB导致Hash表频繁扩容、GC停顿最终hive.map.aggr自动失效退化为无聚合的Map输出。实测配置低基数聚合COUNT/DISTINCT on cityhive.map.aggr.hash.percentmemory0.7高基数聚合COUNT DISTINCT on user_idhive.map.aggr.hash.percentmemory0.9hive.map.aggr.hash.min.reduction0.5强制最低聚合率极端场景若仍OOM改用hive.groupby.skewindatatrue倾斜GroupBy它会自动将倾斜Key打散到多个Reducer。避坑心得我曾在一个广告点击日志分析任务中将hive.map.aggr.hash.percentmemory从0.5提到0.9Shuffle数据量从2.1TB降至380GB任务耗时从87分钟缩短至19分钟。但第二天监控告警该节点JVM GC时间飙升至45%。排查发现tez.container.size未同步提升90%内存给Hash表后剩余空间不足导致频繁Full GC。解决方案tez.container.size从8192升至12288tez.runtime.io.sort.mb同步升至3686形成内存闭环。3.4tez.grouping.min-size与tez.grouping.max-sizeInputSplit的“智能切片刀”Tez的InputSplit输入分片不像MR那样简单按HDFS Block切分而是通过tez.grouping.*参数动态合并小文件、拆分大文件生成最优Task数量。min-size防止过度切片产生海量小Taskmax-size防止切片过大单Task负载过重。典型问题场景某客户有一张日志表每天生成1200个小文件平均2MBHDFS Block Size128MB。若按默认tez.grouping.min-size1677721616MB则1200个文件会被合并为约150个InputSplit1200*2MB/16MB≈150生成150个Map Task。但若tez.grouping.max-size10737418241GB而某天突发生成一个1.5GB的大文件则它会被切分为2个Split1.5GB/1GB1.5→ceil2导致2个Task处理1.5GB其余148个Task处理2MB严重负载不均。精准配置公式tez.grouping.min-size max(16777216, avg_file_size * 0.8) tez.grouping.max-size min(1073741824, avg_file_size * 1.5)其中avg_file_size通过hdfs dfs -ls /path | awk {sum$5} END {print sum/NR}计算。实操案例某物流轨迹表日均文件数850平均文件大小4.2MBtez.grouping.min-size max(16MB, 4.2*0.8≈3.4MB) 16MBtez.grouping.max-size min(1GB, 4.2*1.5≈6.3MB) 6.3MB但6.3MB 16MB违反min-size ≤ max-size原则此时必须人工干预将min-size设为4MB4194304max-size设为8MB8388608确保覆盖95%文件大小波动范围。调整后Task数量从1200稳定在1050±20CPU利用率方差降低65%。3.5hive.optimize.skewjoin与hive.skewjoin.key应对数据倾斜的“手术刀”数据倾斜是Hive性能杀手尤其在大表JOIN时。hive.optimize.skewjointrue开启倾斜优化hive.skewjoin.key定义“倾斜键”的阈值默认100000即当某Key在Map端出现次数此值Tez会将其单独路由至专用Reducer处理。为什么默认100000常失效该阈值基于MR的mapred.reduce.tasks.speculative.execution设计而Tez的Vertex调度更激进。在SSD集群上一个Key出现50万次可能仅需200ms处理但若设为100000则触发倾斜优化将50万次拆分到10个Reducer每个处理5万次但网络传输和协调开销反而增加30%。动态阈值设定法先用采样估算倾斜程度SELECT key, COUNT(*) as cnt FROM (SELECT key FROM sales_detail TABLESAMPLE(0.1)) t GROUP BY key ORDER BY cnt DESC LIMIT 10;取Top1 Key的cnt值设为hive.skewjoin.key cnt * 0.8例Top1 cnt820000 →hive.skewjoin.key656000高级技巧对于“超级倾斜键”如空值、默认值可预处理过滤-- 在JOIN前剔除空key INSERT OVERWRITE TABLE sales_detail_clean SELECT * FROM sales_detail WHERE key IS NOT NULL AND key ! ; -- 或用SALT打散 SELECT /* MAPJOIN(s) */ * FROM (SELECT *, concat(key, _, cast(rand() * 10 as int)) as salted_key FROM sales_detail) t JOIN small_table s ON t.salted_key s.key;3.6tez.runtime.intermediate-input.is-compressed与tez.runtime.compressShuffle的“高压缩引擎”Tez的Shuffle数据量常占整个作业耗时的40%以上。启用压缩可显著降低网络和磁盘IO但压缩算法选择不当会引发CPU瓶颈。参数组合策略tez.runtime.intermediate-input.is-compressedtrue强制中间数据Map输出→Reduce输入压缩tez.runtime.compresstrue启用运行时压缩tez.runtime.compress.codecorg.apache.hadoop.io.compress.SnappyCodec首选Snappy压缩比3:1CPU开销低tez.runtime.compress.codecorg.apache.hadoop.io.compress.Lz4Codec若CPU资源充裕LZ4压缩比更高4:1速度更快实测对比10GB中间数据Codec压缩后大小CPU耗时网络传输耗时总耗时None10GB0ms128s128sSnappy3.3GB8.2s42s50.2sLZ42.5GB6.1s31s37.1s关键约束必须确保所有NodeManager安装相同Codec库否则出现ClassNotFoundException若集群CPU负载70%禁用tez.runtime.compress.codecLzoCodecLZO需额外native libCPU开销极高3.7hive.exec.parallel与hive.exec.parallel.thread.number并行执行的“交通管制员”hive.exec.paralleltrue允许Hive将非依赖的Stage如多个INSERT INTO不同表并行执行hive.exec.parallel.thread.number控制并行线程数默认8。为什么不能盲目调高thread.number并行线程数≠YARN Container数。每个线程会向YARN申请一个Application若thread.number32而YARN队列最大Application数为20则12个任务排队等待反而延长SLA。更危险的是多个Tez Application竞争同一节点的磁盘IO导致所有任务Spill延迟翻倍。安全配置法则hive.exec.parallel.thread.number ≤ min(8, YARN_Queue_Max_Applications * 0.3)对于关键报表任务建议hive.exec.parallelfalse确保资源独占和可预测性仅对ETL流水线中的独立分支如同时清洗用户表、订单表、商品表启用并行验证指标在YARN ResourceManager UI中观察Apps Submitted与Apps Running曲线。若Apps Submitted持续高于Apps Running且差值5则说明并行数超限需下调thread.number。3.8hive.optimize.ppd与hive.optimize.index.filter谓词下推的“前置过滤器”hive.optimize.ppdtrue谓词下推将WHERE条件尽可能下推到数据源层如ORC Readerhive.optimize.index.filtertrue启用ORC索引过滤跳过不满足条件的Stripe。ORC索引工作原理ORC文件将数据按Stripe默认250MB分块每个Stripe包含Row Index行号偏移和Bloom Filter布隆过滤器。当查询WHERE user_id123456时ORC Reader先查Bloom Filter若返回“不存在”则整个Stripe跳过若返回“可能存在”再查Row Index定位具体行。调优要点必须确保表为ORC格式且启用索引TBLPROPERTIES (orc.compressSNAPPY, orc.create.indextrue)hive.optimize.index.filter仅对、IN、BETWEEN有效对LIKE %abc无效对高基数字段user_idBloom Filter效果显著对低基数字段statusRow Index更高效实测收益一张10TB的ORC表查询WHERE dt2024-06-01 AND user_id123456关闭PPD扫描全部10TB耗时42分钟开启PPDIndex仅扫描dt分区下含user_id123456的Stripe实际读取1.2TB耗时5.3分钟提速7.9倍3.9hive.auto.convert.join与hive.mapjoin.smalltable.filesizeMapJoin的“智能开关”hive.auto.convert.jointrue让Hive自动将小表JOIN转为MapJoin小表全量加载到内存大表流式处理hive.mapjoin.smalltable.filesize定义“小表”阈值默认25MB。为什么25MB常不准该值指HDFS文件大小但ORC/Snappy压缩后解压内存占用可达5~10倍。一个25MB的Snappy压缩ORC文件解压后可能占用250MB内存。若tez.container.size4096则单个Container最多加载1个这样的小表但若JOIN涉及3张小表则内存溢出。精准计算法获取小表HDFS大小hdfs dfs -du -s /path/to/small_table估算解压后内存uncompressed_size hdfs_size * compression_ratioSnappy ORCcompression_ratio ≈ 8ZLIB ORCcompression_ratio ≈ 12设定阈值hive.mapjoin.smalltable.filesize min(25000000, uncompressed_size * 0.3)保留30%内存给JVM和临时数据案例某维度表dim_userHDFS大小18MBSnappy压缩解压后≈144MBhive.mapjoin.smalltable.filesize min(25MB, 144*0.3≈43MB) 25MB但实际JOIN时OOM因未预留足够内存。最终设为1500000015MB确保解压后≤120MB安全余量充足。3.10tez.am.resource.memory.mb与tez.am.java.optsApplicationMaster的“指挥中枢”Tez AM是整个DAG的调度中心tez.am.resource.memory.mb设其内存默认1024MBtez.am.java.opts设JVM参数如-Xmx819m。致命误区很多团队将tez.am.resource.memory.mb设得很高如4096MB认为“越大越稳”。但AM内存过高会导致YARN调度延迟大内存Container排队时间更长GC停顿加剧-Xmx3276m的Full GC可能耗时8秒期间所有Vertex暂停单点故障影响扩大AM崩溃则整个DAG重跑黄金配置tez.am.resource.memory.mb 20482GB为安全上限tez.am.java.opts -Xmx1638m -XX:UseG1GC -XX:MaxGCPauseMillis200若DAG超复杂50个Vertex改用-XX:UseParallelGC并行GC验证方法在Tez UI的ApplicationMaster页面查看JVM MetricsGcTimeMillis每分钟GC时间1000ms为健康HeapMemoryUsage.used峰值tez.am.resource.memory.mb * 0.73.11hive.exec.orc.split.strategyORC分片的“智能导航仪”ORC文件的Split策略直接影响并行度。hive.exec.orc.split.strategy有三个值BIBusiness Intelligence默认按Stripe切分适合分析型查询ETL按HDFS Block切分适合ETL流水线HYBRID自动选择但稳定性差为什么BI策略在某些场景失效BI策略假设Stripe大小均匀250MB但若表经过多次INSERT OVERWRITE会产生大量小Stripe10MB。此时BI策略会为每个小Stripe创建一个Split生成海量小TaskYARN调度开销反超计算收益。诊断与修复查看ORC文件Stripe分布hive --orcfiledump -j /path/to/file.orc | grep Stripe information # 输出Stripe 1: offset: 12345 length: 8923456 ... Stripe 2: offset: 8935801 length: 2345678 ...若小Stripe50MB占比30%改用ETL策略SET hive.exec.orc.split.strategyETL;长期方案定期合并小文件ALTER TABLE table_name COMPACT MAJOR;3.12hive.vectorized.execution.enabled向量化执行的“涡轮增压器”向量化执行Vectorized Execution将传统逐行处理改为一次处理1024行的向量批处理大幅提升CPU缓存命中率。hive.vectorized.execution.enabledtrue开启但需满足表格式为ORC或Parquet查询不包含UDF用户自定义函数数据类型为基本类型INT/BIGINT/STRING等性能实测对10亿行ORC表执行SUM(price)关闭向量化耗时218秒开启向量化耗时47秒提速4.6倍避坑指南若查询含CASE WHEN嵌套5层向量化可能退化为逐行模式需简化逻辑hive.vectorized.execution.reduce.enabledtrue默认false可开启Reduce端向量化但仅对GROUP BY有效且需hive.vectorized.execution.enabledtrue前提4. 实战调优全流程从问题定位到效果验证4.1 问题定位四步法精准锁定瓶颈调优不是盲目试错而是系统化诊断。我们采用“Metrics → Plan → Log → Code”四步定位法Step 1YARN Metrics初筛登录YARN ResourceManager UI按应用ID筛选慢任务重点关注Aggregate Resource Allocation总资源消耗vcores×msRunning Containers实际运行Container数 vs 申请数若申请数运行数说明资源争抢Containers Completed成功/失败/超时Container数失败率5%需查日志Step 2EXPLAIN执行计划深挖执行EXPLAIN FORMATTED your_sql;分析关键指标Stage-1的Reducer部分Number of reduce tasks是否合理Bytes Read是否远超预期Tez部分Vertices数量是否过多20个Vertex易引发调度延迟Vertex Dependencies是否存在长链A→B→C→DOperator TreeTableScan的Filter Operator是否下推Select Operator的Statistics中numRows是否准确Step 3Container日志溯源下载失败Container的日志yarn logs -applicationId app_xxx搜索关键词ExitCodeException exitCode143JVM被YARN Kill内存超限