Maven 构建 Flink 应用程序的最佳实践（根除各种类冲突/类加载问题）

作为开发者，在构建 Flink 应用程序时的体验真是一言难尽，想必大家都曾遇到过各种 ClassNotFoundException、NoSuchMethodError 以及 Could not find any factory for identifier kafka/jdbc/hive/hudi that implements org.apache.flink.table.factories.DynamicTableFactory in the classpath 这样的错误。坦率地说，Flink 的应用程序构建体验要比 Spark 差很多，在 Flink 上遇到各种类加载问题和 Jar 包冲突的几率非常高，再加上 Flink 的官方文档也差强人意，给开发者带来了很多困惑和糟糕的用户体验。有些扯远了，回到我们的话题：到底如何才能规避构建 Flink 应用过程中的种种问题，实现平滑顺畅的应用部署呢？本文会根据笔者过去的经验介绍一些重要的最佳实践。

最佳实践(1): 总是使用 maven-shade-plugin 构建 uber-jar

在我以往的经历中，很少使用 maven-shade-plugin，把若干依赖的 Jar 打成一个超大的 uber-jar 并不一种很优雅的做法，且超大的单体 Jar 包在部署时极其不便（每次都要上传或下载大文件）。那么，为什么还用推荐 maven-shade-plugin 来构建 Flink 应用呢？原因并不是因为 uber-jar 本身有什么好处，而是因为 maven-shade-plugin 提供了对依赖包的重命名以及合并 Jar 包元数据的能力，这些处理让生成的 uber-jar 能规避绝大多数的类冲突和类加载问题 ，一个典型的