简介面向CDH6.3.2大数据平台的集成安装包专门服务需要在Cloudera环境中部署Flink 1.16.2的运维与开发人员。该资源针对CDH手工编译打包Flink流程繁琐、容易踩坑的痛点把集成所需的核心组件全部预置开箱即用省去逐项排查版本兼容性的麻烦。压缩包内共7个文件类型涵盖parcel、jar、sha、jsonparcel用于集群分发与安装json为集成清单sha提供完整性校验jar包含CSD服务描述与Hadoop相关依赖整体体积约518.32MB。目前已有972人学习下载适合具备CDH基础、希望将Flink无缝接入YARN的读者。配合随附的部署教程可在CDH6.3.2中快速添加parcel并完成集成无需自行打包或调整底层依赖。同时资源内置Hadoop相关shaded uber依赖能有效规避运行时依赖冲突让Flink与HDFS、YARN的对接更平滑对批量部署多个节点的大数据团队而言这份安装包可直接复用大幅缩短环境搭建时间。1. 为什么把 Flink 1.16.2 往 CDH 6.3.2 上放是件需要「讲条件」的事我最早接到这个需求时以为就是下载一个 Flink 包、解压、改两个配置、往 YARN 上一扔。结果第一次提交作业就在 ResourceManager 那边报了一串依赖缺失的异常排查下来才意识到CDH 6.3.2 自带的是 Hadoop 3.0.0 没错但它是发行版的私有裁剪版本跟 Apache Hadoop 3.0.0 的客户端 jar 不完全等价。Flink 1.16.2 官方发布的安装包默认携带的是 Apache Hadoop 的 shaded 依赖这套组合直接上线轻则 ClassNotFound重则跟 CDH 自带的 YARN 客户端互相顶掉类。这篇笔记的定位很直接讲清楚 Flink 1.16.2 与 CDH 6.3.2 集成时真正需要动手做的几件事——怎么确认版本兼容、怎么把 Flink 提交到 CDH YARN、怎么让 Flink SQL 连上 CDH 里的 Hive 元数据以及那些「跑不起来」的现象背后到底是什么原因。适合已经在维护 CDH 集群、想引入 Flink 做实时计算或者被分配了「把 Flink 部署到现有集群」这类任务的人阅读。2. 动手前的版本核对与依赖取舍CDH 不是标准 Hadoop2.1 先认清 CDH 6.3.2 的 Hadoop 底子与 Flink 的兼容边界Flink 官方发布包的兼容性列表里写着支持 Hadoop 2.x 和 3.x这没问题。但 CDH 6.3.2 内部的 Hadoop 版本是 3.0.0-cdh6.3.2这个版本号不能直接拿去对应 Apache Hadoop 3.0.0 的二进制接口。实际工作中我见过太多人下载了flink-shaded-hadoop-3-uber这个 jar 塞进 Flink 的 lib 目录然后提交到 CDH YARN 上运行一段时间后作业突然抛NoSuchMethodError。原因就是 CDH 的 HDFS 客户端和 YARN 客户端在某些内部 API 上与 Apache 版实现不一致shaded uber jar 把 Apache 实现打进 Flink 进程跟集群客户端一碰就翻车。我一般会先把 Flink 自带的lib目录翻一遍确认有没有带flink-shaded-hadoop-*-uber这类包。如果有直接移除没有的话就不用额外补。原则上Flink 跑在 CDH YARN 上Hadoop 相关依赖全部交给 CDH 的HADOOP_CLASSPATH提供Flink 侧只保留自身、连接器和用户代码的依赖。这样类冲突的暴露面最小。接着打开 CDH 里 YARN 的配置页确认一下 NodeManager 的 Java 版本。CDH 6.3.2 官方推荐 Java 8而 Flink 1.16.2 支持 Java 8 和 Java 11。生产上我建议统一用 Java 8避免 JDK 11 模块化导致--add-exports这类参数到处补。很多开发者在自己电脑上用 JDK 17 写代码关掉 IDE 的自动编译后直接把 fat jar 丢上来作业一启动 JVM 就报错这是非常常见的低级翻车点。2.2 准备 Flink 安装目录剔除无用依赖并核对关键 jarFlink 发行包解压后先不急着改配置。我用以下命令检查 lib 目录里的内容cd /opt/flink-1.16.2 ls -1 lib/ # 期望看到类似 # flink-csv-1.16.2.jar # flink-dist-1.16.2.jar # flink-json-1.16.2.jar # flink-sql-connector-kafka-1.16.2.jar # flink-table-api-java-1.16.2.jar # ... # 如果存在 flink-shaded-hadoop-*-uber-*.jar建议移出 lib mkdir -p /opt/flink-1.16.2/opt-hadoop-backup mv lib/flink-shaded-hadoop-*-uber-*.jar /opt/flink-1.16.2/opt-hadoop-backup/这个操作背后的逻辑是在 CDH 环境里YARN 和 HDFS 的客户端 jar 远比你塞进去的 uber jar 更适配集群。shaded uber jar 本来是给没有 Hadoop 环境的纯 Flink 集群用的而 CDH 本身就是完整的 Hadoop 发行版叠加使用反而制造不确定性。然后是检查conf/flink-conf.yaml里的两个基础项。以下是一份我在 CDH 环境里常用的最小配置jobmanager.memory.process.size: 1600m taskmanager.memory.process.size: 2048m taskmanager.numberOfTaskSlots: 2 parallelism.default: 2 # 这些配置让 Flink 与 CDH YARN 交互更稳定 akka.ask.timeout: 60s web.timeout.application.enable: truejobmanager.memory.process.size和taskmanager.memory.process.size是进程总内存包含 JVM 堆、堆外和框架开销。CDH 的 YARN 容器默认会检查资源申请量如果 Flink 申请的总内存超过了 YARN 队列里允许的单容器上限作业会在提交阶段直接被拒绝。我一般按队列的yarn.scheduler.maximum-allocation-mb倒推 taskmanager 内存比如队列上限 8 GBtaskmanager 就别超过 6 GB给 YARN 的 overhead 留余量。2.3 生成 CDH 环境变量HADOOP_CLASSPATH 的正确打开方式提交 Flink 作业到 YARN 之前必须让 Flink 拿到 CDH 的 Hadoop 客户端依赖。这一步是整个集成里最容易出问题的地方——不是让你手工拼一堆 jar 路径而是用 CDH 自带脚本生成export HADOOP_HOME/opt/cloudera/parcels/CDH/lib/hadoop export HADOOP_CONF_DIR/etc/hadoop/conf export HADOOP_CLASSPATH$(hadoop classpath) echo $HADOOP_CLASSPATH | tr : \n | wc -l注意最后一条命令它会输出 classpath 里有多少个路径。正常 CDH 环境下这个数字通常在一百以上。如果你的输出只有个位数说明hadoop命令本身没有真正读到 CDH 的配置后续 Flink 提交时必然报找不到 YARN 的类。把这三个环境变量写进/etc/profile.d/flink-cdh.sh或者写进你提交脚本的头部。不要把它们写进flink-conf.yaml因为flink-conf.yaml里的env.java.opts不负责承载这类 classpath写了反而容易出现路径解析异常。到这里基础环境就备好了。下一步是把 Flink 作业真正提交到 CDH 的 YARN 上。3. 把 Flink 作业提交到 CDH YARN从命令行到参数语义3.1 Flink 1.16.2 在 YARN 上的三种部署模式怎么选Flink 1.16 时代yarn-cluster这种老旧的提交方式已经被标记为废弃官方推荐的是-t yarn-application和-t yarn-per-job。在 CDH 6.3.2 上我建议直接用yarn-application模式。yarn-per-job需要客户端维持与集群的会话一旦提交作业的机器断网或者客户端进程被杀整个作业跟着消失这对生产环境是致命的问题。yarn-application模式下Flink 的 JobManager 和 TaskManager 都以 YARN 容器的方式运行客户端只负责把 jar 和配置上传到 HDFS提交之后就可以退出终端。这个模式对 CDH 的运维习惯也更友好你的作业生命周期由 YARN 管理重启、日志、资源隔离都能在 YARN 的 Web 界面里看到。下面是一条我在 CDH 环境里最常用的提交命令cd /opt/flink-1.16.2 ./bin/flink run -t yarn-application \ -D yarn.application.nameflink-connector-test \ -D yarn.application.idapplication_technical_test \ -D jobmanager.memory.process.size1600m \ -D taskmanager.memory.process.size4096m \ -D taskmanager.numberOfTaskSlots2 \ -D parallelism.default2 \ -Dyarn.ship-files/opt/flink-1.16.2/conf/log4j2.properties \ -c com.example.flink.StreamingJob \ /data/jars/flink-connector-test-1.0.jar-t yarn-application指定部署目标-Dyarn.ship-files会把指定的配置文件随作业一起上传到 YARN 容器里这一步对 CDH 环境非常重要。因为 CDH 的 NodeManager 通常不会自动读取 Flink 安装目录里的 log4j2 配置你不 ship 过去容器起来后日志打印全走默认级别排障时什么都看不到。提交后需要关注 YARN 控制台的几个状态RM 是否把 AM 调度起来了、AM 使用的资源是否符合预期、TaskManager 是否成功注册。切忌提交完就以为万事大吉Flink 在 YARN 上最常见的失败发生在 AM 启动阶段而 AM 启动失败往往是因为资源不足或 classpath 缺依赖。3.2 资源参数与 CDH 队列怎么设才不会被 YARN 拒单CDH 的 YARN 调度器默认是 Capacity Scheduler每个队列都有maximum-am-resource-percent和容器上限限制。很多开发者直接把taskmanager.memory.process.size设成 16 GB但队列的单容器上限只有 8 GB提交后会被 YARN 直接拒绝。这时错误提示一般是Application is rejected by the scheduler或Resource request exceeds maximum allocation。我的经验是先跑一个小作业验证连通性参数如下-D jobmanager.memory.process.size1024m -D taskmanager.memory.process.size2048m -D taskmanager.numberOfTaskSlots2这个小资源配置在 CDH 默认队列里几乎不会碰壁。确认作业能跑通再用yarn top或者 YARN 页面观察实际内存占用逐步上调。YARN 页面上每个容器显示的物理内存是 Flink 进程实际消耗不是申请量两者有差距。如果显示容器内存长期贴着申请上限说明需要调大 Flink 的堆外比例或者减小并行度而不是硬怼容器规格。小结一下这章的核心点Flink 在 CDH 上的资源管理要遵循「先小后大、观察再调」的原则而不是照搬纯 Flink 集群的大内存配置。CDH 上同时跑着 Hive、Spark 等其他负载内存争抢是常态一上来就把队列资源申满别人的作业会受影响你的作业也可能因为租约超时被 YARN 杀掉。4. 让 Flink SQL 连接 CDH 的 Hive 元数据从 jar 到 Catalog4.1 为什么 Flink SQL 在 CDH 上必须考虑 Hive CatalogCDH 集群的离线数仓几乎都以 Hive 为核心表结构、分区信息、数据路径都记录在 Hive Metastore 里。Flink SQL 如果只做自己的内存表那跟数仓基本是割裂的。最常见的真实需求是Flink 从 Kafka 消费实时数据写入 Hive 表或者从 Hive 表读取维度数据做关联。要做到这一点Flink 必须通过 Hive Catalog 访问 Metastore。Flink 1.16.2 官方提供了flink-sql-connector-hive-*.jar但这里有个大坑官方连接器默认是针对 Apache Hive 版本编译的直接拿来连 CDH 的 Hive 会报 Thrift 协议不匹配或者找不到org.apache.hadoop.hive.conf.HiveConf的某些方法。常见做法是不要用官方那个连接器 jar而是自己从 CDH 的 Hive 安装目录里收集依赖。我一般这样操作export CDH_HIVE_HOME/opt/cloudera/parcels/CDH/lib/hive mkdir -p /opt/flink-1.16.2/lib-hive cp $CDH_HIVE_HOME/lib/hive-exec-*.jar /opt/flink-1.16.2/lib/ cp $CDH_HIVE_HOME/lib/hive-metastore-*.jar /opt/flink-1.16.2/lib/ cp $CDH_HIVE_HOME/lib/hive-service-*.jar /opt/flink-1.16.2/lib/ cp $CDH_HIVE_HOME/lib/libfb303-*.jar /opt/flink-1.16.2/lib/ cp $CDH_HIVE_HOME/lib/libthrift-*.jar /opt/flink-1.16.2/lib/ # 再把 Hive 依赖的第三方包一并放入 lib cp $CDH_HIVE_HOME/lib/hive-common-*.jar /opt/flink-1.16.2/lib/加完 jar 后需要把 CDH 的hive-site.xml放到 Flink 的conf/目录下或者显式通过-D hive-site指定路径。这里有一个容易踩的细节CDH 的hive-site.xml里往往包含数据库连接密码、Kerberos 相关的 keytab 路径放到 Flink 目录下之前要确认该项配置对 Flink 进程可读。否则 JobManager 一启动就报Failed to connect to metastore。4.2 SQL Client 里注册 Hive Catalog 与真实查询验证装好 jar 和配置后启动 SQL Client 做一次冒烟验证/opt/flink-1.16.2/bin/sql-client.sh embedded -d /opt/flink-1.16.2/conf/sql-client.yaml在 SQL Client 里执行CREATE CATALOG my_hive WITH ( type hive, hive-conf-dir /opt/flink-1.16.2/conf/, hive-version 3.1.0 ); USE CATALOG my_hive; SHOW DATABASES;hive-version这个参数在连接 CDH 时容易让人困惑。CDH 6.3.2 内部 Hive 的版本是 2.1.1但 Flink 1.16.2 的 Hive 兼容列表里没有 2.1.1 这个档位官方只列了 2.3.x 和 3.1.x。实际测试中在 CDH 6.3.2 上用hive-version2.3.9也能成功连接 Metastore因为 Flink 的 Hive 兼容层主要依赖 Hive Metastore 的 Thrift API而 CDH 的 Metastore 接口基本保持了对 2.3 系列的兼容。如果SHOW DATABASES能正常列出 CDH 上的库名说明 Catalog 通了。接着可以跑一个最简单的查询SELECT count(*) FROM my_hive.default.some_table WHERE dt 2024-01-01;这类查询会把查询计划下推到 Hive 的 Filter 和 ProjectionFlink 只负责计算最终聚合结果。如果这里出现Couldnt find meta store或TTransportException排查思路按顺序走先确认hive-site.xml里的hive.metastore.uris指向的地址能不能从 Flink 所在节点访问再用hive --service metastore --help确认 Metastore 进程状态最后检查 lib 目录里有没有同时存在两个版本的hive-execjar——不同版本共存时类加载顺序会导致奇怪的方法缺失。5. Flink CDH 集成的四条高频踩坑记录现象、原因与解法5.1 提交作业时报 NoClassDefFoundError: org/apache/hadoop/yarn/api/records/ApplicationId现象Flink 提交命令执行后客户端 JVM 抛出NoClassDefFoundError指向 YARN 的 API 类。原因Flink 客户端进程在解析 YARN 相关类时需要HADOOP_CLASSPATH但你的 shell 环境里没导这个变量。很多 CDH 机器的/etc/hadoop/conf路径下确实有配置文件但hadoop命令本身依赖的HADOOP_HOME没指向 CDH parcels导致导出的 classpath 是空的。解决执行echo $HADOOP_CLASSPATH如果为空按第二章的方式用hadoop classpath重新导出并把导出命令放到提交脚本的最前面。5.2 作业在 YARN 上启动后TaskManager 一直处于 PENDING最后失败现象YARN 页面上能看到 AM 起来了但 TaskManager 容器迟迟调度不上等待一段时间后 AM 标记作业失败。原因当前队列的空闲资源不够。CDH 里 YARN 的默认队列可能已经跑了很多 Hive 或 Spark 作业Flink 申请一个较大的容器时调度器无法满足只能一直等。AM 默认会等待一段时间超过阈值就放弃。解决先砍并行度和内存把容器规格降到队列空闲值以下验证连通性后再调大。同时可以打开 YARN 的资源管理页面实时观察空闲资源。这件事考验的是你对队列资源的判断不是 Flink 本身的问题。5.3 Flink SQL 连接 Hive 时报 ClassNotFoundException: com.facebook.fb303现象SQL Client 里创建 Hive Catalog 成功但执行SHOW DATABASES时抛异常找不到com.facebook.fb303相关类。原因CDH 的 Hive Metastore 依赖了老版本的 Thrift 与 fb303 库Flink 官方 Hive 连接器不带这些依赖。不同版本 CDH 对应的 fb303 版本不同硬塞高版本反而可能引入序列化不兼容问题。解决从 CDH 的 Hive lib 目录复制libfb303-*.jar和libthrift-*.jar到 Flink 的 lib 目录。注意只保留 CDH 自带的版本不要从 Maven 下载新版本覆盖。5.4 作业成功提交后YARN 日志里看不到 Flink 的 INFO 级别日志现象作业能正常运行但 YARN 容器日志里只有寥寥几行输出想看的 Main 方法里的打印和 Flink 内部 INFO 日志全都没有。原因Flink 1.16 默认使用 log4j2配置文件log4j2.properties位于 Flink 的conf/目录。但 YARN 容器启动时不会自动把这个配置文件传到容器里导致容器实际使用了 log4j2 的默认配置默认情况下只输出 ERROR 级别。解决提交时加-Dyarn.ship-files/opt/flink-1.16.2/conf/log4j2.properties并验证容器内的日志确实多起来了。对于线上生产我建议把log4j2.properties里的根日志级别调到 INFO同时单独为org.apache.flink命名空间设置为 INFO。6. 收尾验证与进阶微调一个值得养成的检查清单如果你照着前面的步骤走完了最后这章可以当作你每次部署完的验证清单。我的习惯是每次部署完 Flink 1.16.2 到 CDH 6.3.2都要按顺序跑一遍三步验证法。第一步用flink list -t yarn-application看看当前有没有已经提交的作业。如果命令能正常列出作业状态说明 Flink 客户端与 CDH YARN 的通信链路没问题。这里有个容易忽略的点执行该命令的机器必须跟提交作业时使用同一个HADOOP_CLASSPATH否则连不上 RM。第二步找一个真实业务表跑一次 count 查询验证 Hive Catalog 连通性和 HDFS 读取权限。这一步比任何安装检查都更能证明系统「能用」。很多环境 Flink 能启动但实际读 Hive 表时因为权限问题被拒这问题只在真实查询时暴露。第三步观察一个短作业完整跑完后的状态确认没有频繁 Full GC。在 CDH 环境里Flink TaskManager 启动后如果持续 GC通常是因为taskmanager.memory.managed.size太大而系统内存不足导致换页。一个短作业的 GC 日志足够反映问题。进阶微调方面有两个参数值得单独关注。第一个是taskmanager.memory.jvm-overhead.min默认值 192 MB对某些需要大堆外内存的连接器可能不够。第二个是yarn.application.heartbeat-delay在 CDH 集群负载较高时适当调大这个值能减少因心跳超时而误杀 AM 的偶发情况。这两个参数不可能通过一遍测试就定死要根据自己的集群水位调整。带 Flink 上 CDH 这件事第一次做时自动化不了后面操作熟练了脚本化之后倒是很省心。留下一个个人习惯供你参考我会在每个作业的启动脚本里固定记录集群的队列上限、内存申请值和实际峰值三个数字一起写进运维文档下次调参时就不用靠猜。希望帮到你。本文还有配套的精品资源点击获取