Trino 359执行CTAS出现io.trino.server.TaskUpdateRequest无效JSON报错

• 版本固有Bug：Trino 351~360版本存在任务响应序列化缺陷，当Worker节点出现GC长停顿、内存溢出等异常时，/v1/task接口会直接返回纯文本Java异常栈而非标准JSON响应，Coordinator侧解析响应时就会触发JSON解析报错。CTAS写ORC文件属于高内存消耗操作，偶发的资源紧张就会触发该问题，符合无固定规律的表现。
• EMR与Glue Catalog适配问题：EMR 6.4.0内置的Trino Glue连接器默认配置较低，当CTAS操作并发请求Glue更新元数据时，容易触发Glue接口限流或请求超时，Worker侧元数据线程阻塞后返回的响应被截断，混入异常栈文本导致JSON格式非法。
• ORC写入配置不合理：默认的Trino ORC writer内存阈值设置较低，当select distinct返回结果量偏大时，单任务内存占用超过阈值触发异常，导致返回非JSON响应。

• 版本缺陷修复：优先将Trino集群升级至363及以上稳定版本，该版本已修复任务响应序列化的Bug。若需保留EMR 6.4.0版本，可单独给Trino打补丁，修改io.trino.server.TaskUpdateResource类的异常处理逻辑，强制所有接口响应都返回标准JSON格式。
• Glue Catalog配置优化：修改Trino Hive Catalog的配置文件，调整以下参数：
  • hive.metastore.glue.max-connections：调大至20以上，降低Glue接口限流概率
  • hive.metastore.glue.request-timeout：调大至30s，避免元数据请求超时
  • hive.metastore-cache-ttl：设置为10min，hive.metastore-refresh-interval设置为5min，开启元数据缓存减少重复请求
• ORC写入内存优化：调整Trino通用配置参数：
  • task.max-memory：从默认16GB上调至32GB，task.max-memory-per-node同步对应上调
  • hive.orc.writer.max-buffer-size：调大至16MB，hive.orc.writer.stripe-size调大至256MB，降低ORC写入时的内存波动
  • query.slow-start-enabled：设置为true，避免大量高内存任务同时调度引发集群GC尖峰
• 临时规避方案：若暂时无法修改集群配置，可拆分CTAS语句为两步执行，降低单次任务的内存消耗：

-- 第一步：先存储去重结果到临时表
create table ide.tmp_stage_5_distinct as
select distinct i.* from ide.stage_4 i;

-- 第二步：将临时表数据转存为ORC格式的目标表
create table ide.stage_5 with (format = 'ORC') as
select * from ide.tmp_stage_5_distinct;

-- 清理临时表
drop table ide.tmp_stage_5_distinct;

内容的提问来源于stack exchange，提问作者G Taylor Bentz