StreamPark项目中使用Flink SQL在YARN-Per-Job模式下的兼容性问题分析

问题背景

在Apache StreamPark项目开发过程中，发现当使用Flink 1.16或1.17版本运行Demo Flink SQL作业时，如果部署模式选择yarn-per-job，会出现作业无法正常启动的问题。值得注意的是，同样的作业如果直接使用flink run命令在本地运行则可以正常工作。

错误现象分析

系统抛出的异常堆栈显示，核心问题出现在Janino编译器初始化阶段。具体错误为"Unable to instantiate java compiler"，更深层次的异常是"org.codehaus.janino.CompilerFactory cannot be cast to org.codehaus.commons.compiler.ICompilerFactory"。

这个错误表明在类加载过程中出现了版本冲突，Janino编译器相关的类被不同的类加载器加载，导致类型转换失败。Janino是一个轻量级的Java编译器，Flink SQL在优化查询计划时会使用它来动态生成和编译代码。

根本原因

经过深入分析，这个问题源于Flink类加载机制的复杂性，特别是在以下方面：

1. 类加载器隔离问题：在yarn-per-job模式下，Flink会创建独立的类加载器来加载用户代码。当StreamPark打包的作业jar中包含的janino相关类与Flink运行时环境中的版本不一致时，就会出现类加载冲突。

2. 依赖冲突：Flink Table Planner模块本身已经包含了janino相关依赖，而StreamPark的打包过程可能又引入了不同版本的janino库，导致在运行时出现类转换异常。

3. Flink版本差异：Flink 1.16和1.17版本在SQL模块的内部实现上有所调整，对janino的依赖处理方式也有所变化，这使得问题在这些版本中更为突出。

解决方案

针对这个问题，可以采取以下几种解决方案：

1. 依赖排除：在StreamPark项目构建时，显式排除janino相关的传递依赖，确保只使用Flink运行时提供的版本。

2. 类加载策略调整：修改作业提交逻辑，控制类加载器的父子关系，确保核心组件由父加载器加载，而用户代码由子加载器加载。

3. 依赖版本统一：确保StreamPark打包的janino相关依赖与目标Flink版本完全一致，避免版本冲突。

4. 模块化打包：将SQL相关依赖与核心依赖分离，采用更精细的依赖管理策略。

最佳实践建议

对于StreamPark用户在使用Flink SQL时，建议：

1. 仔细检查项目中所有与janino相关的依赖，确保版本一致性。

2. 对于Flink 1.16及以上版本，建议使用Flink官方推荐的依赖管理方式。

3. 在复杂依赖场景下，考虑使用maven-shade-plugin等工具进行依赖重定位。

4. 定期更新StreamPark版本，以获取最新的兼容性修复。

总结

这类类加载冲突问题在大数据生态系统中并不罕见，特别是在涉及多个框架和复杂依赖关系的场景下。理解Flink的类加载机制和依赖管理原理，对于解决类似问题至关重要。StreamPark团队已经注意到这个问题，并在后续版本中进行了相应修复，用户只需保持项目更新即可避免此类问题。