简介面向需要在 CDH 6.3.2 集群中部署 Flink 1.13.1 的大数据运维与开发人员这份安装包提供了完整的 Parcel 分发包与 YARN 集成组件解决实时计算环境搭建、作业提交发布以及版本兼容与资源配置问题。资源共 5 个文件包含 Flink 核心库、Flink on YARN 客户端 jar、Parcel 元数据、适配 CentOS 7 与 Scala 2.11 的 parcel 安装包及 SHA 校验文件压缩后约 299.52MB。已有 3495 人学习下载适合在 CDH 集群中快速导入并激活 Parcel、配置 Flink 与 YARN 交互参数、提交和管理实时作业。包内整理了可直接使用的二进制发行组件能减少手工编译与依赖匹配成本借助 YARN 资源调度可在现有集群中稳定运行 Flink 作业并通过清晰的文件构成与校验信息快速完成部署上线。1. flink-1.13.1 与 cdh6.3.2 的组合是私有化实时计算的常态而非过时选择把 flink-1.13.1 和 cdh6.3.2 放在一起不是某个冷门实验而是很多企业内部实时数仓的真实底座。CDH 6.3.2 是 Cloudera 在合并前最后几批稳定发行版之一底下的 HDFS 是 Hadoop 3.0.0YARN 是 Capacity Scheduler很多存量集群至今还跑在这套东西上。Flink 1.13.1 则是社区里口碑相当稳的一个版本既有 DataStream API 的成熟用法又具备生产级的 SQL 能力配 CDH 正好不激进也不落伍。这篇文章适合两类人一类是要在 CDH 6.3.2 上从零搭 Flink 实时任务的开发或运维另一类是已经在用别的版本组合、但因为集群隔离或合规要求不得不往这套版本上迁。后面会从目录布局、依赖处理、YARN 提交流程、Hive 接入一直写到排错按能直接照做的标准来。2. 把 Flink 1.13.1 放进 CDH 6.3.2目录布局与 Hadoop 依赖处理2.1 为什么不用 CDH 自带的 Flink版本差异与服务管理原因CDH 6.3.2 的产品生态里实时计算主推的是 Spark Streaming 和自己集成的 Flink 组件但 CDH 自带的 Flink 组件版本普遍落后而且和 Flink 1.13.1 的部署方式差别较大。CDH 的 parcel 和 CSD 机制会把 Flink 塞进 Cloudera Manager 的管理体系里好处是能统一看监控和配置下发坏处是版本被 Cloudera 的发布节奏卡住想用 Flink 1.13.1 的 Window 优化、Application 模式、动态表特性就难了。另一个现实原因是存量 CDH 集群往往不是全新部署上面已经跑了 Hive、Spark、HDFS 和 YARN应用团队对 Cloudera Manager 的改动权限通常很谨慎。直接把 Flink 1.13.1 做成独立目录放在边缘节点或提交节点通过 YARN 申请资源不碰 CM 的配置是风险最小的接入方式。这样 Flink 只是 YARN 的一个客户端HDFS 和 YARN 的认证跟着集群走后续升级 Flink 也只是换一个目录的事不用动整个 CDH 生态。所以我的建议很直接在 CDH 6.3.2 上跑 Flink 1.13.1别用 CM 那一套托管方案手动部署独立 Flink 发行版让 YARN 做资源层CDH 只提供存储、调度和元数据。这套模式在私有化环境里被验证过很多次运维成本反而最低。2.2 最小安装步骤解压、认领 HADOOP_CLASSPATH、放置配置文件拿到 flink-1.13.1 的二进制包后解压到指定目录然后做三件事确认 Java 版本、设置 HADOOP_CLASSPATH、把 CDH 的 Hadoop 配置文件放到位。Flink 1.13.1 推荐 Java 8 或 Java 11CDH 6.3.2 的 DataNode 和 NodeManager 一般跑在 JDK 8 上客户端节点保持一致最省心。# 解压到 /opt并建立软链方便后续切换版本 tar -xzf flink-1.13.1-bin-scala_2.12.tgz ln -s /opt/flink-1.13.1-bin-scala_2.12 /opt/flink # 在 /etc/profile.d/flink.sh 里写入以下环境变量 export FLINK_HOME/opt/flink export PATH$FLINK_HOME/bin:$PATH export HADOOP_CONF_DIR/etc/hadoop/conf export HADOOP_CLASSPATH$(hadoop classpath) export HADOOP_USER_NAMEhdfs # 验证 Flink 能正常识别 Hadoop 配置 $FLINK_HOME/bin/flink --version这里的逻辑是Flink 1.13.1 的 lib 目录下不再内置 flink-shaded-hadoop-2-uber 这种大而全的依赖包它需要从环境变量里拿 Hadoop 客户端。hadoop classpath会把 CDH 6.3.2 的 HDFS、YARN、Common 相关 jar 全部拼出来Flink 在启动 YARN 客户端时靠这个 classpath 找到YarnClusterDescriptor否则会在提交任务时直接报 ClassNotFoundException。HADOOP_CONF_DIR指向 CDH 的客户端配置目录里面有 core-site.xml、hdfs-site.xml、yarn-site.xmlFlink 通过它识别 NameNode 地址、YARN ResourceManager 地址和 HDFS 的 HA 配置。HADOOP_USER_NAME是 CDH 没开 Kerberos 时的兜底变量让 Flink 以 hdfs 用户的身份去访问 HDFS 和 YARN避免因为提交用户权限不足而翻车。如果集群开了 Kerberos这个变量就不能用了要改成 keytab 方式后面第 4 章会单独说。把 Hadoop 配置文件和 Flink 配置分开放很重要。千万不要把 CDH 的 core-site.xml 拷进 FLINK_HOME/conf 覆盖 Flink 自己的配置因为 Flink 的 conf 目录还要放 flink-conf.yaml、log4j.properties 这些自有配置混在一起会互相污染。正确做法是只设置HADOOP_CONF_DIR环境变量Flink 在需要时自己去那个目录读。2.3 依赖冲突怎么管flink-shaded-hadoop 还是 CDH 原生 client很多没在 CDH 上跑过 Flink 的人会纠结一个问题要不要往 Flink 的 lib 目录里塞一个 flink-shaded-hadoop-2-uber.jar。这个 jar 在 Flink 1.10 之前是必需的但从 1.11 开始官方移除了内置的 shaded hadoop 包改为要求用户自己提供 Hadoop 客户端环境。在 CDH 6.3.2 上正确做法是用 CDH 自带的原生 hadoop-client 依赖也就是让 HADOOP_CLASSPATH 去拼 CDH 的 jar而不是塞一个针对 Apache Hadoop 2.x 的 uber jar。这两条路的差异在类加载顺序上。flink-shaded-hadoop-2-uber 会优先加载它内部的 Hadoop 2.7 版本类而 CDH 6.3.2 的 HDFS 是 Hadoop 3.0.0协议和 RPC 在某些场景下不一致容易出现NoSuchMethodError或 RPC 握手失败。反过来用 CDH 原生 client 没有这个问题因为版本和集群是严格对应的。# 在提交 Flink 任务的节点上执行确认输出的依赖路径里有 cdh 字样 hadoop classpath | tr : \n | grep -i cdh | head逻辑说明这条命令能帮你确认当前节点是否安装了完整的 CDH Hadoop 客户端。如果输出为空说明这台机器只有 Flink没有部署 CDH 的 hadoop-client后续提交任务时大概率会因为缺类失败。参数说明hadoop classpath是 Hadoop 提供的命令输出是一个冒号分隔的 classpath 字符串用tr换行后 grep 能快速定位到具体 jar 路径。还有一个常见做法是把 CDH 的 hadoop-client 相关 jar 直接拷进 FLINK_HOME/lib但我不推荐。因为 Flink 1.13.1 自身有一些依赖会和 CDH 的 jar 冲突比如 guava、ow2-asm、commons-logging放进 lib 会让 classpath 顺序失控排查起来很痛苦。保持 lib 目录干净只放 Flink 自带的 jarHadoop 依赖全走环境变量是这套组合最稳妥的做法。3. 配置与提交用 YARN session / application 模式跑通第一个任务3.1 flink-conf.yaml 里的 5 个必调参数Flink 1.13.1 在 CDH 6.3.2 上能不能稳定跑flink-conf.yaml 里的参数起着决定性作用。默认配置适合本地伪集群扔到 CDH 的 YARN 上会出现各种资源不对齐的问题。我最先调的是下面 5 个参数。参数名建议值调整原因jobmanager.memory.process.size2048m限制 JobManager 整体内存避免默认值过大被 YARN 拒绝taskmanager.memory.process.size4096m与 YARN 容器内存对齐防止容器内存超限被杀taskmanager.numberOfTaskSlots4单个 TaskManager 的并发 slot 数按 CPU 核数定parallelism.default2没有显式设置并行度时的兜底值先小后大classloader.check-leaked-in-releasefalseCDH 的 Hadoop client 里有继承 ThreadLocal 的类默认校验会误报并中断任务jobmanager.memory.process.size和taskmanager.memory.process.size要配合 CDH 6.3.2 的 YARN 调度上限来设置。在 CM 的 YARN 配置里yarn.scheduler.maximum-allocation-mb决定了单个容器最大能申请多少内存如果 Flink 的 process size 超过这个上限提交时会被 YARN 直接拒绝报错是Resource request exceeds maximum allowed allocation。建议先看 CM 页面里这个参数的值再回头设 Flink 的内存。classloader.check-leaked-in-release这个参数是 Flink 1.13 新加的检查项它会扫描用户代码里有没有加载了不应该加载的 Hadoop 类。CDH 6.3.2 的 Hadoop 3.0.0 里有一部分类实现了Closeable但没注册到 Flink 的泄漏检查白名单默认 true 会导致任务在初始化阶段被强制中止。设成 false 不是逃避问题而是因为这是 CDH 客户端自身的实现细节Flink 的检查覆盖不到主动关掉才能跑起来。另外建议把 flink-conf.yaml 里的env.java.opts加上-Dfile.encodingUTF-8CDH 6.3.2 的节点上默认 locale 可能是 POSIX不指定会偶尔出现中文乱码。这不是必调项但加上以后能少一个排查维度。3.2 先跑 yarn-session最小命令和参数说明yarn-session 模式适合开发和调试它会先在 YARN 上申请一个常驻的 Flink 集群然后你可以反复用flink run往这个 session 里提交作业不用每个作业都重新申请资源。# 启动一个 YARN session申请 1 个 TaskManager每个 4G 内存 $FLINK_HOME/bin/yarn-session.sh \ -s 2 \ -jm 2048 \ -tm 4096 \ -nm flink-cdh-session \ -d逻辑说明yarn-session.sh会读取前面设置的 HADOOP_CONF_DIR向 CDH 6.3.2 的 ResourceManager 提交一个 Flink Application Master 的容器这个 AM 启动成功后会在 YARN 的 application 列表里看到一个名为 flink-cdh-session 的任务。-d表示 detached 模式session 在后台运行不会占用当前终端。参数说明-s 2是给每个 TaskManager 分配 2 个 slot配合parallelism.default为 2意味着每个 TaskManager 能同时跑 2 个 task-jm 2048是 JobManager 容器内存 2G-tm 4096是 TaskManager 容器 4G这两个值要和 flink-conf.yaml 里的 process.size 保持一致否则容器能启动但内部内存模型会错位-nm是 YARN 上显示的 application 名称便于在 CM 或yarn application -list里定位别起成默认的 Flink session不然多个 session 同时跑的时候根本分不清谁是谁。session 起来以后用下面的命令提交一个最简单的 Flink 作业测试连通性。Flink 1.13.1 自带 examples 包里面有个 WordCount可以直接拿来做冒烟测试。# 先把测试文件写入 HDFS hdfs dfs -mkdir -p /tmp/flink-test echo hello flink cdh | hdfs dfs -put - /tmp/flink-test/input.txt # 向已运行的 session 提交 WordCount 作业 $FLINK_HOME/bin/flink run \ -m yarn-cluster \ -c org.apache.flink.streaming.examples.wordcount.WordCount \ $FLINK_HOME/examples/streaming/WordCount.jar \ --input hdfs:///tmp/flink-test/input.txt \ --output hdfs:///tmp/flink-test/output逻辑说明-m yarn-cluster告诉 Flink 去连接当前正在运行的 YARN session类名org.apache.flink.streaming.examples.wordcount.WordCount是 WordCount jar 里的主类。--input和--output是 Flink 自带 example 的作业参数。输出路径必须是 HDFS 上不存在的目录否则会报 AlreadyExistsException。这里有一个 CDH 上的特殊点如果开的是 HA NameNodeHDFS 路径写hdfs:///tmp/flink-test/input.txt这种简写形式也能解析因为 Flink 会从 core-site.xml 里拿到fs.defaultFS。如果写死成hdfs://nameservice1/...也必须保证抹除nameservice1与 core-site.xml 中的配置一致。第一次测试建议用简写路径少一个排查面。3.3 再走 application 模式日志与 Per-Job 隔离yarn-session 虽然调试方便但生产环境里更推荐 application 模式。application 模式下每个作业都会启动一个独立的 Flink Application Master作业之间资源完全隔离一个作业的失败不会影响别的作业日志也按 application 单独聚合。# 用 application 模式提交 WordCount作业元数据自动上报到 YARN $FLINK_HOME/bin/flink run-application \ -t yarn-application \ -D yarn.application.nameflink-wordcount-app \ -D yarn.application.queueroot.flink \ -c org.apache.flink.streaming.examples.wordcount.WordCount \ $FLINK_HOME/examples/streaming/WordCount.jar \ --input hdfs:///tmp/flink-test/input.txt \ --output hdfs:///tmp/flink-test/output-app逻辑说明run-application是 Flink 1.13 引入的 application 模式提交入口-t yarn-application指定运行类型。这个命令会把用户代码和 Flink 运行时一起打包到 YARN 上由 AM 负责拉起 JobManager然后 JobManager 再申请 TaskManager 容器整个过程和 session 模式不同不需要本地提前跑一个常驻 session。参数说明-D yarn.application.name设置 YARN 上的应用名-D yarn.application.queue指定 YARN 队列。CDH 6.3.2 默认队列是root.default如果没做队列规划可以先不写这个参数写到默认队列里验证通过后再调整。-c指定主类和 session 模式一样。在 CDH 6.3.2 上application 模式的日志查看有讲究。yarn logs -applicationId application_xxx能看到 AM 和 JobManager 的标准输出但 TaskManager 的日志需要 TaskManager 容器运行过才能拉取。如果作业启动后马上失败往往只能看到 AM 日志TaskManager 根本没来得及启动。后文第 5 章会专门讲怎么在这种场景下定位原因这里先记住application 模式下yarn logs的可用性和作业存活时间强相关失败越早越难查日志提前开好log4j的文件输出路径很重要。4. 接入 Hive 与 HDFS让 Flink SQL 在 CDH 6.3.2 上能查会写4.1 把 Hive 2.1.1 的 metastore 接进来Flink 1.13.1 的 SQL 生态里Hive 集成是一个大头。很多实时数仓作业需要读 Hive 表或把结果写回 Hive 表而 CDH 6.3.2 自带的 Hive 版本是 2.1.1不在 Flink 官方预编译支持的 Hive 版本列表中间。官方预编译的 flink-sql-connector-hive 主要覆盖 Hive 2.3.x 和 3.1.x所以直接用官方 connector 包连 CDH 的 Hive metastore 会报版本不兼容或NoSuchMethodError。我一般做法是手动把 CDH 的 Hive 客户端依赖组装给 Flink。在装了 Hive 客户端的 CDH 节点上找到 Hive 的 lib 目录把hive-exec、hive-metastore、hive-common、hive-serde、libfb303这些核心 jar 软链或拷贝到 FLINK_HOME/lib 下。CDH 的 Hive 客户端 jar 版本号都带-cdh6.3.2后缀比如hive-exec-2.1.1-cdh6.3.2.jar这类 jar 可以从 CM 管理的 Hive Gateway 节点上直接拿。# 在 Hive Gateway 节点上执行把 Hive 客户端依赖合并进 Flink lib HIVE_LIB_DIR/opt/cloudera/parcels/CDH/lib/hive/lib FLINK_LIB_DIR/opt/flink/lib cp $HIVE_LIB_DIR/hive-exec-*.jar $FLINK_LIB_DIR/ cp $HIVE_LIB_DIR/hive-metastore-*.jar $FLINK_LIB_DIR/ cp $HIVE_LIB_DIR/hive-common-*.jar $FLINK_LIB_DIR/ cp $HIVE_LIB_DIR/hive-serde-*.jar $FLINK_LIB_DIR/ cp $HIVE_LIB_DIR/libfb303-*.jar $FLINK_LIB_DIR/ # 检查是否引入了 CDH 6.3.2 特有的 hadoop 版本 jar避免与 Flink 冲突 ls $FLINK_LIB_DIR | grep -E hive|hadoop | head逻辑说明这样做的本质是把 Hive metastore 客户端代码加载进 Flink 的 classpath让 Flink SQL 能通过 Thrift 协议连接 Hive Metastore。hive-exec是执行引擎的客户端接口Flink 需要它的HiveConf和TableSchema来解析 Hive 表hive-metastore负责和 Hive Metastore 服务通信libfb303是 thrift 的依赖缺了它会在创建 catalog 时报 NoClassDefFoundError。参数说明拷贝 jar 时有两点必须注意。第一不要一股脑把$HIVE_LIB_DIR下所有 jar 都拷过去Hive 的 lib 里有大量和 Flink 冲突的旧版依赖比如guava、log4j、slf4j-api全拷会让 classpath 变成雷区。第二hive-exec可能存在多个版本CDH 6.3.2 的 Hive 目录里通常只有一个版本但如果有多个只保留2.1.1-cdh6.3.2其他删掉否则 Flink 会随机加载其中一个导致 metastore 协议不匹配。拷完 jar 之后还要把 Hive 的配置告诉 Flink。Flink SQL 里创建 HiveCatalog 时需要指定hive-site.xml的路径。CDH 的 Hive 配置一般在/etc/hive/conf/hive-site.xml里面包含 metastore 的 thrift 地址和连接方式。# 在通过 flink-sql-client 执行 SQL 前确认 Hive 配置能被 Flink 读取 export HADOOP_CONF_DIR/etc/hadoop/conf export HIVE_CONF_DIR/etc/hive/conf逻辑说明HIVE_CONF_DIR这个变量不是 Flink 官方强制要求的但它能让 flink-sql-client 启动时顺带加载 Hive 的配置文件避免手动在 SQL 里写死 metastore URL。设置后创建 HiveCatalog 时可以少传一个路径参数Flink 会从HIVE_CONF_DIR定位 hive-site.xml。参数说明如果集群里有多套 Hive 环境这个变量要指向具体的 conf 目录不能写多个路径。4.2 用 flink-sql-client 测一条 SQL装完 Hive 集成依赖后先用 flink-sql-client 做一次真实链路验证确认 Flink 能通过 CDH 的 Hive metastore 建表、读表、写表这一整条链路通了后续的任务开发才有基础。# 进入 flink-sql-client指定 Hive Catalog $FLINK_HOME/bin/flink-sql-client 2/dev/null在 sql-client 的交互界面里执行下面的 SQL-- 创建 Hive Cataloghive-conf-dir 指向 CDH 的 Hive 配置目录 CREATE CATALOG myhive WITH ( type hive, hive-conf-dir /etc/hive/conf ); USE CATALOG myhive; -- 在 CDH 的 Hive 默认库下建一张测试表 CREATE TABLE flink_hive_test ( id INT, name STRING, ts TIMESTAMP ) PARTITIONED BY (dt STRING) WITH ( connector hive, hive-conf-dir /etc/hive/conf ); -- 写入一条数据验证 HDFS 写入路径 INSERT INTO flink_hive_test VALUES (1, cdh-test, CURRENT_TIMESTAMP, 2024-06-01); -- 回读数据验证 Hive 表和 Flink 的 Schema 映射 SELECT * FROM flink_hive_test;逻辑说明CREATE CATALOG myhive是在 Flink 侧注册一个 HiveCatalogmyhive是自定义逻辑名后面用USE CATALOG myhive把当前会话绑到这个 catalog。HiveCatalog 会连接 CDH 6.3.2 的 Hive Metastore并把 Flink 的表操作映射成 Hive 元数据操作。CREATE TABLE flink_hive_test这一段用的是 Hive connector 语法connector hive表示这是一张 Hive 表数据底层的存储和分区都由 Hive 管理。注意这张表不是同步 Hive 里已有的表而是在 Flink 里新建一张 Hive 表。PARTITIONED BY (dt STRING)是 Hive 表最常见的分区模式Flink 写入时会生成对应的分区目录。踩坑点在于INSERT INTO之后如果马上在 Hive 命令行里查这张表可能查不到数据。因为 Flink 写 Hive 表默认走的是 staging 目录再合并的流程写入完成后才把文件移动到正式的分区目录。如果数据量小merge 很快数据量大时要确认 Flink 作业里的 commit 是否成功而不是直接在 Hive 里傻等。4.3 Kerberos 与权限注意CDH 6.3.2 如果是开启 Kerberos 的生产集群上面所有操作都要加上认证环节否则 Flink 连接 HDFS 会报java.io.IOException: LoginException连接 Hive metastore 会报GSSException。Flink 1.13.1 支持在 flink-conf.yaml 里直接配置 Kerberos keytab。# flink-conf.yaml 中的 Kerberos 配置 security.kerberos.login.use-ticket-cache: false security.kerberos.login.keytab: /etc/security/keytabs/flink.service.keytab security.kerberos.login.principal: flink/serviceEXAMPLE.COM逻辑说明security.kerberos.login.principal是 Flink 提交作业时使用的 Kerberos 主体keytab是这个主体对应的密钥文件。Flink 的 YARN 客户端在提交阶段会先用这个 keytab 执行 Kerberos 登录然后凭证会随着容器启动传给 JobManager 和 TaskManager。参数说明use-ticket-cache设置成 false是为了强制每次都用 keytab 重新登录而不是依赖当前节点的 ticket cache避免 klist 的票据过期导致任务失败。在 CDH 6.3.2 上这个 keytab 必须要从 Cloudera Manager 里创建并给对应的 Flink 主体授权 HDFS 和 Hive 的访问权限。创建主体和导出 keytab 在 CM 的 Security 页面做导出的 keytab 文件要放到所有提交 Flink 任务的节点同一个位置。如果你用的是HADOOP_USER_NAMEhdfs这种方式跑通了任务那是没开 Kerberos 的集群一旦开了 KerberosHADOOP_USER_NAME就失效了必须走 keytab 这条路别混着用。5. 常见问题/避坑CDH 6.3.2 上跑 Flink 1.13.1 的 5 个典型踩坑5.1 提交时找不到 YarnClusterDescriptor / Hadoop 类不识别现象Flink 提交任务到 YARN 时报ClassNotFoundException: org.apache.flink.yarn.YarnClusterDescriptor或者NoClassDefFoundError: org/apache/hadoop/yarn/client/api/impl/YarnClientImpl但本机 hadoop 命令能正常执行。原因绝大多数是因为启动 Flink 的终端里没有加载 HADOOP_CLASSPATH。Flink 的 bin 目录下的脚本在启动时读取这个变量变量为空时Flink 不会自动去推测 Hadoop 依赖而是拿着一个残缺的 classpath 提交 YARN自然找不到相关类。CDH 6.3.2 的 CM 节点上 hadoop 命令本身是能跑的但那是 CM 的包装脚本在起作用不依赖 HADOOP_CLASSPATH容易掩盖问题。解决在提交任务的用户.bashrc里显式设置export HADOOP_CLASSPATH$(hadoop classpath)并确认/opt/flink/bin/flink能读到这个变量。验证方式是执行$FLINK_HOME/bin/flink run --help不报错再看flink脚本输出里是否包含HADOOP_CLASSPATH的实际路径。更稳妥的办法是在 flink-conf.yaml 里增加env.java.opts: -Djava.class.path$HADOOP_CLASSPATH但这属于非常规手段大多数场景设置环境变量就够了。5.2 Hive SQL 报 Schema 版本不一致或找不到 hive-site.xml现象Flink SQL 里执行CREATE CATALOG myhive失败报MetaException: Could not connect to meta store using any of the URIs in metaStoreUrls或报Table not found又或者出现Invalid method name: get_table_req这类的 Thrift 协议错误。原因CDH 6.3.2 的 Hive Metastore 是 2.1.1 版本和 Flink 1.13.1 官方默认支持的 Hive 2.3.x 在 Thrift API 上有细微差异。如果你把 Flink 官方预编译的 flink-sql-connector-hive-2.3.x jar 放到 lib 里它内部的 hive-metastore 客户端版本是 2.3.x和 CDH 的 2.1.1 服务端握手时部分 RPC 方法对不上就会出现上述错误。解决按第 4.1 节的方式从 CDH 的 Hive Gateway 节点拷贝 2.1.1-cdh6.3.2 版本的 Hive 客户端 jar并且不要把 Flink 官方自带的 hive connector jar 同时放进 lib。如果拷贝后依然报错检查hive-site.xml中hive.metastore.uris是否为完整可访问的 Thrift 地址并确认 Flink 节点和 Hive Metastore 之间的 9083 端口通。在 CDH 上Hive Metastore 的地址要写主机名不要写 localhost否则从另一台机器访问必然失败。5.3 TaskManager 容器启动后反复被杀YARN 界面看不到明确异常现象yarn-session 或 application 模式提交后YARN 显示有容器启动但几秒到几十秒后容器退出然后 Flink 反复重新申请容器作业一直处于 RESTARTING。点进 YARN 的 container 日志只有 JVM 退出的记录没有明显异常栈。原因这不是 CDH 的锅而是 Flink 1.13.1 的内存模型和 YARN 容器内存上限不匹配。Flink 的taskmanager.memory.process.size是总内存但 JVM 实际启动参数里还会加上taskmanager.memory.framework.off-heap.size、taskmanager.memory.task.off-heap.size这些额外堆外内存。假如 process.size 设成 4Gos 和 metaspace 又额外占了几百 M而 CDH 的 YARN 里yarn.scheduler.maximum-allocation-mb恰好也是 4G容器申请时就会超过上限或者在物理内存超过 cgroup 限制时被 NodeManager 直接 kill。解决先查 CDH 的 YARN 配置里yarn.nodemanager.pmem-check-enabled和yarn.nodemanager.vmem-check-enabled这两个开关在 CDH 6.3.2 默认开着。如果你在测试环境不想纠结内存模型可以临时把vmem-check-enabled设为 false但生产环境不建议这么做。更稳的方案是把taskmanager.memory.process.size调成 YARN 上限的 80%-90%比如 YARN 单容器上限 8GFlink 就设 7168m并且同步设置taskmanager.memory.jvm-overhead.fraction为 0.1给 JVM 留出余量。5.4 作业写 HDFS 报权限错误或票据过期现象Flink 作业在向 HDFS 写 checkpoint 或 sink 到 Hive 表时报org.apache.hadoop.security.AccessControlException: Permission denied或者java.io.IOException: LoginException: java.lang.reflect.InvocationTargetException。原因如果集群开了 Kerberos且客户端没配置 keytabFlink 的 TaskManager 在访问 HDFS 时用的是当前进程的 user这个 user 往往没有对应 HDFS 目录的写权限甚至根本没有票据。另一个常见原因是 HDFS 目录的属主是 hdfs 或 hive而 Flink 进程以 yarn 用户运行导致写入临时文件或分区目录时无权限。解决在 flink-conf.yaml 里配置第 4.3 节的 keytab 和 principal确保 principal 有 HDFS 和 Hive 的授权。如果集群没开 Kerberos就用export HADOOP_USER_NAMEhdfs让 Flink 以 hdfs 身份提交和运行但要注意这在多人共用集群时不安全。写入 Hive 表时还要检查目标 Hive 表在 HDFS 上的目录权限给 Flink 使用的用户授予rwx权限。最省事的排查办法是先手动hdfs dfs -ls /user/hive/warehouse/表名看能不能访问不能访问就先把权限放出来再跑 Flink。5.5 SLF4J 绑定冲突导致日志全丢任务失败原因查不到现象Flink 作业失败后yarn logs和 TaskManager 的 stdout 里全是SLF4J: Class path contains multiple SLF4J bindings的警告实际日志内容却没几条JobManager 的异常栈只看到一半。原因CDH 6.3.2 的 Hive 客户端 jar 里带了旧的slf4j-log4j12绑定而 Flink 1.13.1 用的是log4j-slf4j-impl。两个绑定同时在 classpath 里时SLF4J 会随机选一个如果选到 CDH 那个日志输出会串到 CDH 的 log4j 体系里Flink 自己的 log4j2.xml 就不生效了。解决启动 Flink 前检查 lib 目录下是否有slf4j-log4j12-*.jar有就删掉或移到备份目录只保留 Flink 自带的log4j-slf4j-impl-*.jar。检查方式find /opt/flink/lib -name slf4j-log4j12* -o -name log4j-slf4j-impl*逻辑说明find命令输出 classpath 里所有 slf4j 相关 jar如果同时出现了两个绑定按上面的做法删除旧的。参数说明-o表示 or 条件用括号把两个-name包起来更严谨避免 find 的优先级干扰但我这里直接用-o简写了。这个操作不会影响 Hive 集成能力因为 CDH 的 Hive 客户端本身也兼容 log4j2删掉旧绑定后 Flink 的日志体系才能统一。6. 用一条体检命令缩小故障面配置、依赖、权限一次扫清最后分享一个我每次在 CDH 6.3.2 上部署完 Flink 1.13.1 都会跑一遍的体检脚本。它不查作业逻辑只查环境配置是否对齐能在一分钟内排除掉前面几章最常见的配置类故障。这个习惯帮我省了大量排查时间尤其是接手别人部署过的集群时先扫一遍比看 CM 配置有效率得多。#!/bin/bash # 体检脚本flink_on_cdh_check.sh FLINK_HOME/opt/flink HADOOP_CONF_DIR/etc/hadoop/conf HIVE_CONF_DIR/etc/hive/conf echo 1. Flink 目录 ls $FLINK_HOME/bin/flink || echo FAIL: flink 可执行文件缺失 echo 2. Hadoop 配置 ls $HADOOP_CONF_DIR/core-site.xml $HADOOP_CONF_DIR/hdfs-site.xml $HADOOP_CONF_DIR/yarn-site.xml /dev/null 21 echo OK || echo FAIL: hadoop 配置缺失 echo 3. HADOOP_CLASSPATH [ -n $HADOOP_CLASSPATH ] echo OK: ${#HADOOP_CLASSPATH} 字符 || echo FAIL: HADOOP_CLASSPATH 未设置 echo 4. 依赖冲突检查 cd $FLINK_HOME/lib find . -name slf4j-log4j12* | grep . echo WARN: 存在旧版 slf4j 绑定 find . -name hive-exec-2.1.1-cdh* | grep . echo OK: hive-exec cdh 版本在列 echo 5. YARN 连通性 timeout 10 yarn application -list /dev/null 21 echo OK: 能连接到 ResourceManager || echo FAIL: yarn application 不可用逻辑说明这个脚本把整个部署环境拆成 5 个关键检查点。第 1 步确认 Flink 二进制就位第 2 步确认 Hadoop 配置文件能被 Flink 读到第 3 步检查 HADOOP_CLASSPATH 是否在启动终端里生效第 4 步检测两个最容易引发隐性故障的 jar 冲突第 5 步直接跟 YARN 通信确认 ResourceManager 地址和认证没问题。参数说明timeout 10给 YARN 命令加上限时避免在 ResourceManager 不可达时脚本长时间卡住这一步连不上就直接进入排障流程而不是反复等待。脚本跑完正常输出应该是 5 到 6 行都带 OK。如果某一步 FAIL就按前面章节对应的步骤处理第 2 步失败去查 CM 的客户端配置分发第 3 步失败重写环境变量第 4 步有 WARN 就删 jar第 5 步失败查 Kerberos 票据和 YARN 服务状态。验证这套组合是否真正可用我习惯在体检脚本之后再做一次最小链路验证也就是第 3 章的 yarn-session 加 WordCount再叠加第 4 章的 Hive 表创建。链路打通后才会上真实业务作业。我先小后大、先环境后业务的节奏在十几个 CDH 集群上都没有出过大岔子。一个环境值不值得投入其实在一轮体检和一次最小任务之后就有答案了。希望这篇文章能帮你在 flink-1.13.1 和 cdh6.3.2 的组合上少走弯路把时间花在作业本身而不是环境拉锯上。本文还有配套的精品资源点击获取