EMR 5.13.0迁移Hive作业时Kryo库出现StackOverflowError问题

我刚帮朋友排查过类似的迁移坑，正好能给你一些实用的建议。你在从EMR 3.7.0升级到5.13.0时遇到的Kryo库StackOverflowError，核心原因是Hive 2.3.2内置的Kryo版本还停留在未修复泛型递归解析的旧版本——虽然这个递归问题早在2015年就被Kryo官方修复了，但Hive的依赖包并没有同步更新。

问题根源拆解 #

从你贴的堆栈跟踪能明确看出来：Kryo在解析java.util.concurrent.atomic.AtomicReference的泛型类型时陷入了无限递归，而这段导致死循环的代码，在Kryo的修复版本里已经被移除了。触发点是Brickhouse的ToJsonUDF依赖的Jackson组件，和Hive内置的旧版Kryo不兼容，最终在序列化UDF对象时触发了这个遗留bug。

经过验证的解决办法 #

这里有几个可落地的方案，你可以根据自己的业务场景选择：

• 替换Hive内置的Kryo版本
  下载已经修复该问题的Kryo版本（推荐2.24.0及以上），将JAR包放到Hive的auxlib目录下，覆盖原有旧版本。注意先在测试环境验证，确保新版本和Hive其他组件没有兼容性冲突。

• 修改Brickhouse UDF的实现逻辑
  如果有权限修改Brickhouse代码，可以调整ToJsonUDF中JsonFactory的初始化方式：比如将JsonFactory标记为transient，或者在UDF的initialize方法中延迟初始化，让Kryo跳过对这个对象的序列化操作。

• 改用Hive内置JSON函数替代
  放弃Brickhouse的ToJsonUDF，直接用Hive 2.0+内置的to_json函数，这样可以彻底避开依赖冲突的问题。如果业务需要复杂JSON处理，也可以自定义一个轻量UDF，基于Jackson但避免触发Kryo序列化的风险。

临时应急方案 #

如果以上方案暂时无法实施，可以先通过禁用Hive的Operator序列化优化绕开错误：

SET hive.exec.operators.serialization.class=org.apache.hadoop.hive.ql.exec.persistence.WritableSerialization;

这个设置会让Hive改用旧的Writable序列化方式，虽然会损失一点性能，但能快速解决当前的运行报错问题。

内容的提问来源于stack exchange，提问作者abhay kumar