Trino升级至459+版本后遭遇HIVE_EXCEEDED_SPLIT_BUFFERING_LIMIT错误求助

问题根源（版本变更点） #

从Trino 459版本开始，Hive插件的split缓冲机制发生了关键变更，直接导致该错误频繁出现：

• Split内存计算逻辑修改：旧版本（如457）采用文件大小预估split的内存占用，459+版本改为统计split对象实际占用的堆内存。由于split对象本身包含元数据（路径、分区信息、统计数据等），实际内存占用远高于文件大小预估，即使调大hive.max-outstanding-splits-size也容易触发阈值。
• BackgroundHiveSplitLoader并发优化：新版本优化了split加载的并发策略，会更积极地预加载split到缓冲队列，针对大分区、小文件密集的表（如trino_logs.query_engine_events），短时间内生成的split数量和内存占用会大幅提升。
• 小文件split生成策略调整：新版本对小文件的合并逻辑做了调整，可能生成更多独立split而非合并为大split，进一步加剧缓冲内存压力。

解决方案 #

针对单月分区过滤查询的场景，可按以下优先级尝试调整：

1. 优化核心缓冲参数 #

• 进一步调大hive.max-outstanding-splits-size：根据Coordinator的堆内存资源，尝试设置为16GB（确保Coordinator JVM堆内存至少预留20GB以上）。
• 放宽hive.max-outstanding-splits限制：将当前的400调整为2000，允许缓冲更多split（需配合内存参数）。

2. 解决小文件问题（根源性优化） #

如果表存在大量小文件，这是split过多的核心原因：

• 对ORC/Parquet格式表执行ALTER TABLE trino_logs.query_engine_events PARTITION (partition_col='xxx') CONCATENATE合并小文件。
• 调整Trino的split合并参数：

  hive.min-split-size=64MB
  hive.max-split-size=256MB
  

  提高最小split大小，强制合并小文件，减少split总数。

3. 控制split加载速率 #

• 降低hive.split-loader-threads：从默认8调整为4，减少并发加载split的线程数，缓解短时间内的split生成压力。
• 进一步降低hive.max-splits-per-second：从50调整为20，限制每秒加载的split数量，避免缓冲队列快速填满。

4. 临时回退内存计算逻辑 #

如果上述调整无效，可临时恢复旧版本的split内存计算方式：

hive.use-estimated-split-size=true

该参数让Trino回到文件大小预估内存的逻辑，显著降低缓冲内存的计算值，但注意这是临时方案，后续版本可能移除该配置。

5. 检查Coordinator堆内存 #

确保Trino Coordinator的JVM堆内存配置足够，例如设置-Xmx32G，因为split缓冲占用的是Coordinator的堆内存，堆内存不足会直接触发限制或OOM。

内容的提问来源于stack exchange，提问作者Hafiz Mujadid