CDH 6.3.2 部署 Flink 1.13.1 与 YARN 集成避坑

简介：围绕 Flink 1.13.1 与 CDH 6.3.2 的集成部署资料包，面向使用 Cloudera 大数据平台、需要把 Flink 接入 YARN 的运维与开发人员，也适合想理解 Parcel 分发机制的中高级读者。压缩包共 5 个文件，约 299.52MB，包含 Flink 核心 jar、YARN 客户端 jar、Parcel 二进制包及其 SHA 校验文件、Parcel 元数据，基本覆盖在 CDH 上分发、激活和运行 Flink 所需组件。已有 3499 人学习，说明这一版本组合在实际集群中具有参考需求。对实际使用者而言，价值在于帮助读者理清 Flink 1.13.1 与 CDH 6.3.2 的版本匹配关系、Parcel 仓库的完整性校验思路，以及 YARN 模式下 JobManager 与 TaskManager 的资源调度入口；可用于搭建测试环境、核对依赖清单，并排查分发、激活与作业提交环节的常见问题。

1. CDH 6.3.2 上装 Flink 1.13.1：先别急着解压那个 tar 包

上周又有人贴出一段报错：在 CDH 6.3.2 的边缘节点上解压完 flink-1.13.1-bin-scala_2.11.tgz，改了两行jobmanager.rpc.address，./bin/start-cluster.sh起本地集群一切正常；换成./bin/yarn-session.sh -n 2 -jm 1024 -tm 2048就直接抛出NoClassDefFoundError: org/apache/hadoop/yarn/client/api/YarnClient。这个组合的翻车率相当高，问题不在命令写错，而在 Flink 从 1.11 起不再把 Hadoop 依赖打进发行包，而 CDH 的 Hadoop jar 又是被 CM 单独管理的一批文件。本地模式用不到 YARN 客户端类，所以一切正常；一旦上 YARN，问题立刻暴露。

下面这条安装路线是按 CDH 6.3.2（Hadoop 3.0.0 / Hive 2.1.1 / Scala 2.11 / JDK 8）实打实走一遍的：包怎么选、jar 怎么塞、flink-conf.yaml哪几行必须改、Kerberos 打开后补哪几处、坏了从哪看日志。新手照着能跑通，熟手能对上版本和参数取舍。

2. 版本对齐：Flink 1.13.1 与 CDH 6.3.2 的组件对照

动手之前先把集群里到底有什么版本弄清楚。CDH 6.3.2 的组件版本在 CM（Cloudera Manager）里是固定的，不是你想换就能换，所以 Flink 侧要反过来迁就它们。这一步偷懒，后面会以NoSuchMethodError、ClassNotFoundException的形式一笔一笔讨回来。

2.1 先把 CDH 6.3.2 的组件版本抄在纸上

在 CM 主页点进各个服务，或者直接看/opt/cloudera/parcels/CDH-6.3.2-1.cdh6.3.2.p0.1605554/lib/下的目录名，能确认这套版本：

Hadoop 3.0.0 这个版本号很容易被忽略。Flink 官方给的 hadoop3 uber jar 是按 Hadoop 3.1/3.3 编的，跑在 3.0.0 上大部分 API 兼容，但涉及YarnConfiguration、DelegationToken的少数方法会有差异，遇到时优先怀疑这里，而不是怀疑 Flink 本身。

2.2 三个包的取舍：Scala 版本、Hadoop 绑定、Hive connector

Flink 1.13.1 的二进制包页面会给出多个选项，选错一个就得重来：

第一个是 Scala 版本。CDH 6.3.2 生态里 Spark、Hive 都是 Scala 2.11 编的，如果 Flink 侧要用 Hive connector、要读写 Hive 表，就必须用flink-1.13.1-bin-scala_2.11.tgz。选 2.12 的包能跑纯 Flink 作业，但接 Hive 时会因为 Scala 二进制不兼容报NoSuchMethodError，而且这类报错堆栈很深，不好认。

第二个是 Hadoop 绑定。Flink 从 1.11 起把 Hadoop 依赖从发行包里剥离了，下载页会额外给一个flink-shaded-hadoop-3-uber-*.jar。这个 jar 里打包的是 shaded 过的 Hadoop 类，不会和你系统里的 Hadoop 冲突，放在lib/下就能让 Flink 认得 HDFS 和 YARN。CDH 是 Hadoop 3，所以选 hadoop3 那个，不要选 hadoop2。

第三个是 Hive connector，这个不在主包里，要单独下flink-sql-connector-hive-2.2.0_2.11-1.13.1.jar。注意它是 shaded 过的整包，不要再往lib/里丢hive-exec、hive-metastore，否则类加载顺序一变就是连环LinkageError。

提示：文件名里的 Hadoop 小版本号随发行批次变化，下载下来后不必改名，只要保证lib/下只有一个 hadoop uber jar。

2.3 JDK 与操作系统的几个硬性前提

JDK 必须是 8，且最好是 CDH 节点上已经装好的那个。Flink 1.13 在 JDK 11 上虽然能起，但反射相关的告警会刷屏，RocksDB 状态后端也可能因为 JNI 出问题，生产上不建议试。

其余几条是血泪经验攒出来的：

• 主机名解析必须双向可通。CM 管着的节点一般没问题，但自己加的边缘节点经常只配了正向解析，YARN 分配容器后 TaskManager 反查主机名超时，表现是容器一直处于 ACCEPTED。
• 所有节点时间要同步。Kerberos 对时间偏移默认容忍 5 分钟，超了就是Clock skew too great。
• /etc/hadoop/conf必须可读。CDH 通过 alternatives 把这个目录指向/etc/hadoop/conf.cloudera.yarn之类的实际路径，ls -l看一眼软链是否正常。
• 文件句柄数调到 65535 以上。Flink 的 RocksDB 状态后端会开不少文件，ulimit -n是 1024 的话，跑一会儿就Too many open files。

3. 部署落地：把 Flink 1.13.1 铺到 CDH 边缘节点的四步

部署位置有两种选择：塞进 CM 做成 parcel 由 CM 统一管，或者手工铺在边缘节点上。parcel 那套要自己打 CSD 描述文件，改一次配置要重新分发，运维成本高；除非集群规模大、要统一纳管，否则我一般选手工部署在边缘节点。这里的边缘节点指的是装了 CDH 客户端、能用hdfs dfs -ls的那台机器，不是集群里的 DataNode。

3.1 目录规划与解压

不要解压到/opt根下再随手改目录名，后面升级、回滚都麻烦。约定一个固定路径：

# 统一放在 /opt 下，版本号体现在目录名里，升级时新旧并存 sudo mkdir -p /opt/flink sudo tar -xzf flink-1.13.1-bin-scala_2.11.tgz -C /opt/flink sudo ln -sfn /opt/flink/flink-1.13.1 /opt/flink/current sudo mkdir -p /data/flink/tmp /data/flink/log sudo chown -R $(whoami):$(whoami) /data/flink

解压后第一件事是建软链，/opt/flink/current指向当前版本。升级时只改软链，FLINK_HOME不用动，回滚一条ln -sfn就回去了。这是我在被一次升级事故折腾到半夜之后固定下来的习惯，后悔药要提前备。

/data/flink/tmp是 TaskManager 的本地临时目录。Flink 会把溢写的中间结果、RocksDB 实例、shuffle 文件放这里，如果这个分区和系统盘是同一个、根分区只有 50G，跑大状态作业会把盘写满，然后整个节点上的服务一起遭殃。所以单独挂一块盘，这一点别省。

接着把环境变量写进/etc/profile.d/flink.sh：

export FLINK_HOME=/opt/flink/current export HADOOP_CONF_DIR=/etc/hadoop/conf export HADOOP_CLASSPATH=`hadoop classpath` export PATH=$FLINK_HOME/bin:$PATH

HADOOP_CONF_DIR指向的是 CDH 的客户端配置目录，里面core-site.xml、hdfs-site.xml、yarn-site.xml、hive-site.xml都在。这个变量必须设，Flink 靠它读 HDFS 的 nameservice、YARN 的 RM 地址和 Kerberos 相关配置，不设的结果是 Flink 用默认配置去连localhost:9000。

HADOOP_CLASSPATH是让 Flink 能加载到集群 Hadoop jar 的兜底手段。注意用反引号包住hadoop classpath，它是命令不是字面量。有些环境里这个字符串能到几万字符，超过 shell 环境变量长度限制时会静默截断，此时可以把结果写进文件再 source，或者干脆只靠lib/下的 uber jar。

3.2 注入 CDH 的 Hadoop 依赖

把下载好的 hadoop3 uber jar 复制进去：

# 只保留这一个 hadoop 相关的 jar，多余的先挪走 cp flink-shaded-hadoop-3-uber-3.1.1.7.1.1.0-565-9.0.jar /opt/flink/current/lib/ ls /opt/flink/current/lib/ | grep -i hadoop

最后那条ls不是多余的。lib/下混进两个不同版本的 hadoop jar 是极其常见的翻车源：某个 jar 先被类加载器扫到，缺了另一个 jar 里的方法，运行时抛NoSuchMethodError，堆栈指向的根本不是真正的问题点。跑之前扫一眼，只有一行输出才放心。

复制完做一次连通性自检：

# 用 Flink 自带的 hadoop 类去读 HDFS 根目录，能列出来说明 jar 和配置都对 hdfs dfs -ls / $FLINK_HOME/bin/flink run -t yarn-per-job \ -Dyarn.application.name=env-check \ $FLINK_HOME/examples/batch/WordCount.jar \ --input hdfs://nameservice1/tmp/words.txt \ --output hdfs://nameservice1/tmp/wc-out

这里的-t yarn-per-job是 Flink 1.11 之后的新写法，替代了老版本-m yarn-cluster。老写法在 1.13 里还能用但已标记废弃，混着用会出现行为不一致，团队里统一一种。

hdfs://nameservice1是 CDH 开了 HDFS HA 之后的逻辑名，具体值以 CM 里 HDFS 服务页面显示的 Nameservice 名为准，有的集群叫nameservice1，有的叫mycluster。写错会报UnknownHostException，别看错方向以为是 DNS 问题。

3.3 flink-conf.yaml 里必须改的那几行

默认配置文件里能改的项有几百个，但真正跑起来只需要动这么几块：

# /opt/flink/current/conf/flink-conf.yaml # 1) 本地模式的 RPC 地址，上 YARN 后由 JobManager 动态接管，但本地调试要用 jobmanager.rpc.address: node01 jobmanager.rpc.port: 6123 # 2) 内存配置，1.13 用的是 process-size 新内存模型，不要再写 taskmanager.heap.size jobmanager.memory.process.size: 2048m taskmanager.memory.process.size: 8192m taskmanager.memory.managed.fraction: 0.4 taskmanager.memory.jvm-overhead.min: 256m # 3) 槽位和默认并行度，一般按 TaskManager 核数的一半到一倍给 taskmanager.numberOfTaskSlots: 4 parallelism.default: 4 # 4) 本地临时目录，必须指向独立数据盘 io.tmp.dirs: /data/flink/tmp # 5) 高可用，Session 集群和多 JM 场景必须开 high-availability: zookeeper high-availability.zookeeper.quorum: node01:2181,node02:2181,node03:2181 high-availability.zookeeper.path.root: /flink high-availability.cluster-id: /default_ns high-availability.storageDir: hdfs://nameservice1/flink/ha

taskmanager.memory.process.size是 Flink 1.13 内存模型的核心参数，它描述的是整个 TaskManager 容器的进程内存，包含堆内存、堆外内存、Metaspace、JVM 自身的开销，以及 RocksDB 用的 native 内存。1.13 之前大家习惯写taskmanager.heap.size，那个值只覆盖堆，YARN 按容器限制一卡就容器的物理内存越界被 kill。managed.fraction: 0.4是给 RocksDB 状态后端预留的托管内存占比，不用 RocksDB 时可以降到 0.2 左右，把内存还给算子。

jvm-overhead.min: 256m是我必调的一项。默认值在小内存容器里够用，但当taskmanager.memory.process.size给到 8G 以上时，JVM 自身的线程栈、code cache、GC 元数据开销会超过默认比例，容器就会被 YARN 以 "exceeding memory limits" 干掉，日志里还看不出任何异常，非常玄学。

high-availability.storageDir三处配置缺一不可，且这个 HDFS 目录权限要对，Kerberos 环境下还要保证 Flink 用的 principal 有写权限。cluster-id在同集群跑多套 Flink 时要各自不同，否则两套集群在 ZooKeeper 里抢同一个节点，表现是多套集群互相踢。

改完配置做一次语法自检，比直接提交作业试错快得多：

# 用 flink 自带的 CLI 读一遍配置，能打印出解析后的值说明 yaml 没错 $FLINK_HOME/bin/flink list -t yarn-per-job -Dtaskmanager.memory.process.size=8192m

4. YARN 提交：Session 集群与 Per-Job 两套参数的摆法

Flink 跑在 YARN 上有两种主流方式：Session 集群是先起一个常驻的 Flink 集群，多个作业共用；Per-Job 是每个作业起一套独立集群，作业结束集群销毁。CDH 这种多租户集群里我一般推荐 Per-Job，资源隔离干净，一个作业的 OOM 不会拖垮隔壁；但如果作业很多、每个都很小，Session 集群省去的启动开销很可观。

4.1 flink-conf.yaml 里与 YARN 相关的几行

不管哪种方式，这几项都要配好：

# YARN 队列，按 CM 里实际划分的队列名填，默认 default yarn.application.name: flink-job # 应用重试次数，节点失联、NM 重启时靠它续命 yarn.application-attempts: 3 # Flink 发行包统一放 HDFS，避免每次提交都上传几百 MB yarn.provided.lib.dirs: hdfs://nameservice1/flink/dist # 容器规格，vcores 就是 YARN 看到的 CPU 核数 yarn.containers.vcores: 4

yarn.provided.lib.dirs是 1.11 之后很实用的一个优化项。不加的话，每次flink run都会把整个lib/目录上传到 HDFS 的暂存区，几百兆的 jar 每次传一遍，提交耗时能到几分钟。做法是提前把发行包传上去：

# 只需要上传一次，升级 Flink 版本时重新上传并覆盖 hdfs dfs -mkdir -p /flink/dist hdfs dfs -put -f /opt/flink/current/lib /flink/dist/ hdfs dfs -chmod -R 755 /flink/dist

目录结构必须是<provided-lib-dirs>/lib/，这是 Flink 约定好的，直接传整个lib目录进去，最终路径就变成/flink/dist/lib，正好对上。传完记得改权限，Kerberos 环境下别的用户提交作业时读不到会报Permission denied。

yarn.containers.vcores和taskmanager.numberOfTaskSlots是两个概念，前者是 YARN 分配给容器的 CPU 核数，后者是 Flink 在一个 TaskManager 上切出的槽位数。常见配置是核数等于槽位数、或核数是槽位数的两倍（给 GC 和 IO 线程留余量）。如果核数小于槽位数，多个 slot 抢同一个 CPU，YARN 侧看不出问题，但作业的反压会异常严重。

4.2 yarn-session.sh 与 flink run 的参数差异

Session 集群的启动命令：

# -n 是 TaskManager 个数，-jm/-tm 在这里被解释为 process 内存 $FLINK_HOME/bin/yarn-session.sh \ -n 4 \ -jm 2048m \ -tm 8192m \ -s 4 \ -nm flink-session-prod \ -d

-jm和-tm在 Flink 1.13 的新内存模型下分别对应jobmanager.memory.process.size和taskmanager.memory.process.size。这一点和 1.9 时代不一样，老参数名的语义变了，从旧版本升上来的集群如果照抄老命令，容器的内存会被算少一截，跑一会儿就被 YARN kill。-s是每个 TM 的槽位数，-nm是 YARN 应用名，-d表示 detached 模式，命令返回但集群还在跑。

启动后记下输出的 application ID，后面提交作业要用：

# 提交到已有 session 集群，-m 后面跟的是 session 的 application id $FLINK_HOME/bin/flink run \ -m yarn-cluster -yid application_1690000000000_0042 \ -c com.example.StreamingJob \ ./jobs/streaming-job.jar

注意这里的-yid是 YARN 专属参数，只有-m yarn-cluster时有效。如果配了yarn.provided.lib.dirs，提交时 Flink 会从 HDFS 读发行包而不是本地传，速度差别很明显。

Per-Job 方式更简单，一条命令搞定：

# -t yarn-per-job 会让 Flink 为这个作业单独创建一套集群 $FLINK_HOME/bin/flink run -t yarn-per-job \ -Dyarn.application.name=order-etl-20240115 \ -Dtaskmanager.memory.process.size=8192m \ -Dtaskmanager.numberOfTaskSlots=4 \ -c com.example.OrderEtlJob \ ./jobs/order-etl.jar

命令行的-D优先级高于flink-conf.yaml，适合给单个作业做差异化配置。应用名里带日期是我自己的习惯，出问题时在 YARN 的 ResourceManager 页面按名字一搜就能定位到是哪一天的哪次提交，比翻日志快。

4.3 Kerberos 打开之后要补的三处配置

CDH 集群十有八九开了 Kerberos。没开的可以跳过这节，开了的漏配任何一处，表现都是作业提交成功但一读 HDFS 就GSS initiate failed。

第一处是登录方式。在边缘节点上跑，最省事的是用 ticket cache：

# 先 kinit，票默认缓存到 /tmp/krb5cc_<uid> kinit -kt /etc/security/keytabs/flink.keytab flink@EXAMPLE.COM klist # 确认票没过期

对应配置里加两行：

# 使用已有的 ticket cache，不把 keytab 路径写进配置文件 security.kerberos.login.use-ticket-cache: true security.kerberos.login.contexts: Client,KafkaClient

use-ticket-cache: true表示 Flink 从当前用户的 ticket cache 里取凭证，好处是 keytab 不落盘到配置里，坏处是提交作业的 shell 必须先kinit。如果是长期跑的服务，改用 keytab 方式：

security.kerberos.login.keytab: /etc/security/keytabs/flink.keytab security.kerberos.login.principal: flink@EXAMPLE.COM security.kerberos.login.contexts: Client,KafkaClient

contexts里列的是需要获取凭证的安全上下文。只读 HDFS 的话Client就够；如果作业里还要连 Kafka，加KafkaClient。这个字段配少了，作业会在连接 Kafka 的瞬间报认证失败，而 HDFS 部分一切正常，很容易误判成 Kafka 集群的问题。

第二处是 YARN 侧的 delegation token。Flink 提交作业时会向 RM 申请 token，用来让 TaskManager 访问 HDFS。这部分不需要额外配置，但要求提交用户对/flink/dist有读权限、对high-availability.storageDir有写权限。

第三处是 Hive metastore。Kerberos 环境下hive.metastore.uris指向的 metastore 也需要认证，hive-site.xml里的hive.metastore.sasl.enabled和hive.metastore.kerberos.principal必须正确，直接把 CM 下发的/etc/hive/conf/hive-site.xml软链到HADOOP_CONF_DIR里最省事。

5. 避坑排查：CDH 6.3.2 上跑 Flink 1.13.1 的五个高频翻车点

下面这五条是这套组合里反复出现的，按现象、原因、解决三段来记，遇到时对号入座比翻源码快。

5.1 提交和启动阶段的两个坑

现象一：flink run -t yarn-per-job直接报NoClassDefFoundError: org/apache/hadoop/yarn/client/api/YarnClient，本地start-cluster.sh却完全正常。

原因是 Flink 1.13 的发行包不带 Hadoop 依赖，lib/下没有 hadoop3 uber jar，也没设HADOOP_CLASSPATH。本地模式走的是LocalStreamEnvironment，压根不碰 YARN 客户端类，所以看不出问题。

解决办法是把 shaded hadoop3 uber jar 放进lib/，或者确保export HADOOP_CLASSPATH=$(hadoop classpath)在提交作业的 shell 里生效。两者选其一即可，同时做反而容易引类冲突。

现象二：作业提交后卡在 ACCEPTED，容器一直分配不出来，RM 页面显示应用在排队，但队列里明明有空闲资源。

这种情况先看 YARN 队列的资源上限，再看容器规格是不是超出了单节点能提供的最大值。CDH 6.3.2 默认给 YARN 的yarn.scheduler.maximum-allocation-mb往往是 8G 或 16G，如果taskmanager.memory.process.size配了 20G，YARN 连试都不试，直接让应用无限期排队，日志里只有一个含糊的Application is waiting for resources。

解决是到 CM 的 YARN 配置里看yarn.scheduler.maximum-allocation-mb和yarn.nodemanager.resource.memory-mb，把 TaskManager 的内存压到上限以内。如果业务确实需要更大的 TM，就让 CM 调大上限并滚动重启 NM，别在 Flink 侧硬顶。

5.2 运行和读写阶段的三个坑

现象三：TaskManager 起来几十秒后被 YARN 杀掉，日志里写着Container [pid=xxx] is running beyond physical memory limits，但 Flink 日志里没有任何 OOM 堆栈。

这是新内存模型的典型表现。taskmanager.memory.process.size包含了 JVM 自身开销，但 JVM 实际占用往往比配置的略高：线程栈、GC 辅助结构、JIT code cache 都在进程内存里，YARN 按 cgroup 统计是硬限制，超一点就杀。

处理办法是给足 JVM overhead。除了taskmanager.memory.jvm-overhead.min: 256m，大内存场景下还可以显式设taskmanager.memory.jvm-overhead.fraction: 0.15，把整个进程内存的 15% 留作 JVM 开销。经验值是 8G 以上的 TM 必须调，4G 以下用默认值问题不大。

现象四：Kerberos 环境下作业能提交，但一读 HDFS 就报GSS initiate failed或No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)。

出现在边缘节点上多半是 ticket 过期，klist一看就知道；出现在 TaskManager 里则是凭证没有传到容器里，或者security.kerberos.login.contexts少了Client。还有一种隐蔽情况：提交作业的用户 kinit 了，但 YARN 的 NM 节点时钟偏移超过 5 分钟，令牌校验失败。

解决顺序是先klist -e看票的有效期和加密类型，再date比对 NM 节点的时间，最后检查security.kerberos.login.use-ticket-cache是不是和实际登录方式一致。时间偏移这种问题最难查，因为报错信息里根本不会提时间。

现象五：SQL Client 连 Hive 时报NoSuchMethodError: org.apache.hadoop.hive.ql.metadata.Hive.getMSC()或者ClassNotFoundException: org.apache.hive.common.util.HiveVersionInfo。

根因是版本错配。CDH 6.3.2 的 Hive 是 2.1.1，Flink 1.13.1 官方没有出 2.1.1 的 connector，只能用 2.2.0 的版本凑。如果lib/里还混进了 CDH 下发的hive-exec、hive-common，类加载顺序一变就出问题。

处理方式是只保留flink-sql-connector-hive-2.2.0_2.11-1.13.1.jar这一个 Hive 相关 jar，hive-exec之类全部清出lib/。如果依旧报方法找不到，说明 connector 走的还是集群上那套旧 Hive 类，需要检查HADOOP_CLASSPATH里是不是把 CDH 的 Hive jar 提前加载了。

6. 验收跑通：从 WordCount 到 SQL Client 的三步确认

装完不等于跑通。我自己的验收分三步，每步都对应一个明确的验证目标，任何一步过不了，就不往下走。

6.1 第一步：批作业能读写 HDFS

# 准备输入，输出目录必须事先不存在，否则 Flink 会拒绝覆盖 hdfs dfs -mkdir -p /tmp/flink-check echo "flink on cdh hadoop yarn" > /tmp/words.txt hdfs dfs -put -f /tmp/words.txt /tmp/flink-check/words.txt hdfs dfs -rm -r -f /tmp/flink-check/out $FLINK_HOME/bin/flink run -t yarn-per-job \ -Dyarn.application.name=wm-count-check \ $FLINK_HOME/examples/batch/WordCount.jar \ --input hdfs://nameservice1/tmp/flink-check/words.txt \ --output hdfs://nameservice1/tmp/flink-check/out hdfs dfs -cat /tmp/flink-check/out/1*

这一步同时验证了四件事：Hadoop uber jar 能被加载、HADOOP_CONF_DIR指向正确、YARN 能正常分配容器、提交用户对 HDFS 有写权限。四者缺一个，命令都会失败，但报错位置不同，看堆栈就能反推是哪一环。

6.2 第二步：SQL Client 能挂上 Hive 元数据

# 启动 SQL Client，CREATE CATALOG 的方式不用改 sql-client-defaults.yaml $FLINK_HOME/bin/sql-client.sh embedded

进交互界面后依次执行：

-- 指向 CDH 的 Hive 配置目录，复用其中的 metastore 地址和 Kerberos 设置 CREATE CATALOG hive_catalog WITH ( 'type' = 'hive', 'hive-conf-dir' = '/etc/hive/conf' ); USE CATALOG hive_catalog; SHOW DATABASES;

SHOW DATABASES能列出库名，说明 metastore 连通、认证通过、connector 版本兼容。这一步过不去，前面所有的配置都白搭，所以它是我判断 Hive 集成是否真的可用的分水岭。

6.3 第三步：把三项检查记成一张表

这张表我一般会贴到部署记录里，下次换节点重装时照着打勾，比凭记忆查配置可靠得多。

从那以后我每次在这类老集群上装 Flink，都会在跑业务作业之前先强制走一遍上面这三步，哪怕时间再紧也不跳。曾经有一次图省事省掉了 Hive 那步，结果业务跑了三天才发现写入 Hive 的分区路径一直是错的，回补数据补了整整一个周末。希望帮到你。

本文还有配套的精品资源，点击获取