企业官网建设流程全解析

简介：面向在 CDH 6.3.2 集群中集成 Flink 1.13.1 的大数据运维与开发人员，这份压缩包汇集了部署所需的安装与分发文件，重点应对 Parcel 管理、YARN 资源调度及 Flink 运行环境准备等场景。包内共 5 个文件，约 299.52MB，主要由 jar、parcel、sha 和 json 构成：Flink 核心库与 YARN 客户端 jar 支撑程序开发和作业提交，parcel 与校验文件服务于 CDH 软件分发和完整性检查，manifest.json 则提供版本及依赖元数据。已有 3498 人学习下载。借助这套文件，读者可以更直观地理解 CDH 环境下 Flink 的集成结构与组件关系，核对包版本、依赖和校验信息，并为 YARN 资源分配、日志路径、权限配置等问题的排查提供依据，适合作为集群部署实验与生产预演的参考材料。

1.

CDH 6.3.2 自带的那套计算栈停在 Spark 2.4 和 Hive 2.1.1，想在上面补一个 Flink 1.13.1，把官方二进制包直接解压扔进去，十次有八次起不来：YARN 客户端找不到 RM 地址、Hadoop 的类被两套 ClassLoader 抢着加载、Kerberos 票据传不进容器、Checkpoint 写 HDFS 报权限。这份资源就是冲着这个组合去的——Flink 1.13.1 按 CDH 6.3.2 侧的 Hadoop 3.0.0、Hive 2.1.1、ZooKeeper 3.4.5、Scala 2.11、JDK 8 重新对齐过的可部署包。它真正解决的是「能不能在一套带认证的老集群上稳定提交、断点续跑、直接读 Hive 元数据」这几个问题，适合手上只有 CDH 集群、又想上 Flink SQL 的团队。

2. 版本对齐：Flink 1.13.1 与 CDH 6.3.2 的依赖矩阵怎么核

2.1 Hadoop 3.0.0 的 ABI 边界，决定了要不要自己编 shaded 包

Flink 从 1.11 起就不再往发行包里塞 Hadoop 依赖了，官方只提供一个「预打包 Hadoop」的可选 jar，分 2.x 和 3.x 两支。这件事在普通 Apache Hadoop 集群上无所谓，反正版本对不上换个 jar 就行；但在 CDH 6.3.2 上要先想清楚一件事：发行版的 Hadoop 是 3.0.0 打了若干补丁的构建，包名带-cdh6.3.2后缀，而社区给的预打包 jar 走的是 3.1.1 那条线。

Hadoop 3.0.0 到 3.1.x 之间，FileSystem、Path、DFSClient这些核心类的公开签名基本没动，所以拿 3.1.1 的 shaded 包去连 3.0.0 的 NameNode，多数读写场景能跑通，我手上几个纯 HDFS 落盘的作业就是这么将就的。真正的边界在两处：一是用到 EC（纠删码）或ViewFileSystem较新 API 的地方，3.0.0 上没有对应实现，运行期会抛NoSuchMethodError；二是 YARN 侧的ApplicationSubmissionContext、Resource之类结构体，发行版改过字段的话，序列化就会对不上。

我的判断标准很土：只用 HDFS 读写 + YARN 起容器，先拿预打包 jar 试，跑通了就不折腾；一旦业务 jar 里引了 HBase 2.1、或者要用 Hive 2.1.1 的 metastore 客户端，就老老实实按发行版版本号重编一份 shaded 包。重编的收益不在「能跑」，而在省掉后面所有NoSuchMethodError的排查时间——那种错误栈指向业务代码，实际根因在依赖，血泪经验。

重编用的是 flink-shaded 这个独立仓库，13.0 分支对应 Flink 1.13 系列，打出来的产物直接丢lib/就能被 Flink 的 ClassLoader 认出来。

# 1) 取 flink-shaded 源码，13.0 分支对应 Flink 1.13 系列 git clone --depth 1 -b release-13.0 <flink-shaded 仓库地址> flink-shaded cd flink-shaded # 2) 打开 vendor-repos profile，否则发行版仓库里的 -cdh6.3.2 构件解析不到 mvn clean install -pl flink-shaded-hadoop-3-parent/flink-shaded-hadoop-3 -am \ -Pvendor-repos \ -Dhadoop.version=3.0.0-cdh6.3.2 \ -Dhive.version=2.1.1-cdh6.3.2 \ -DskipTests \ -Dcheckstyle.skip=true \ -Dmaven.javadoc.skip=true

参数里最关键的是-Pvendor-repos，它在pom.xml里挂了一个额外的 Maven 仓库地址，指向发行版自己的构件库。不加这个 profile，Maven 只会在中央仓库找3.0.0-cdh6.3.2，找不到就直接 failed，报错还挺含糊。-Dhadoop.version必须写全带后缀的字符串，只写3.0.0会拉到社区版，编出来的包看着能用，实际和集群的 RPC 协议对不齐。-am是把父模块一起带上，不然flink-shaded-hadoop-3依赖的flink-shaded-asm之类会缺。

提示：这套构建要联网拉发行版的构件，仓库地址通常走内网镜像。公司内网只放行中央仓库时，提前把发行版的 hadoop/hive 构件mvn install:install-file到本地仓库，比临时开权限快。

2.2 一张对齐表：哪些 jar 进 lib，哪些坚决不进

对齐这件事的本质是「同一份类只能有一个来源」。Flink 的lib/目录会被加进用户的 ClassLoader，你在里面放两套 Hadoop，运行期谁先被加载全看运气，表现出来就是随机出现的ClassCastException，最难查的一类问题。

表里最容易被忽略的是 ZooKeeper 那一行。很多人看到集群是 3.4.5，就顺手把/usr/share/zookeeper/lib下的 jar 复制进 Flink 的lib/，结果 HA 切换时 JobManager 卡在选主阶段，日志里只有一行 curator 的重试。Flink 自带的 ZK 客户端已经做了 shading，包名都改了，跟集群那份不冲突，保持原样最稳。

另一个反直觉的点是 Hive 那三行。社区有flink-sql-connector-hive-2.2.0_2.11这种开箱即用的 shaded 包，看着省事，但它内嵌的是社区版 2.2.0 的 metastore 客户端。CDH 6.3.2 的 metastore 是 2.1.1 加补丁，thrift 接口有小幅差异，连上去能列库、但一到get_partitions就返回空，排查起来像玄学。所以我一般直接用flink-connector-hive_2.11加发行版的hive-exec、hive-metastore、libfb303三件套，包大一点，行为可预期。

2.3 编译与产物校验：三条命令确认打进去的真是发行版

包编出来了不等于编对了。Maven 构建成功只说明依赖解析通过，不说明hadoop.version真的生效——-D参数被 profile 覆盖、或者父 pom 里写死了版本，这两种情况我都遇到过。所以构建完必须做产物校验。

# 1) 看产物里 Hadoop 核心类是否存在，顺便确认没有把源码或测试类打进来 unzip -l flink-shaded-hadoop-3/target/flink-shaded-hadoop-3-uber-*.jar \ | grep -E 'org/apache/hadoop/(hdfs/DFSClient|yarn/client/api/YarnClient)\.class' # 2) 反查清单里记录的版本号，确认是 -cdh6.3.2 而不是社区版 unzip -p flink-shaded-hadoop-3/target/flink-shaded-hadoop-3-uber-*.jar \ META-INF/MANIFEST.MF | grep -i 'hadoop-version\|Implementation-Version' # 3) 把产物放到 lib 下，用 Flink 自己的脚本验证类路径可见性 cp flink-shaded-hadoop-3/target/flink-shaded-hadoop-3-uber-*.jar $FLINK_HOME/lib/ $FLINK_HOME/bin/flink classloader 2>/dev/null || \ $FLINK_HOME/bin/flink run -t yarn-per-job --help >/dev/null && echo "hadoop classes ok"

第一条命令看的是DFSClient和YarnClient两个类。shaded 包重写包名的时候是按规则匹配的，个别子包漏掉是常有的事，缺了YarnClient就提交不了作业，报错是ClassNotFoundException: org.apache.hadoop.yarn.client.api.YarnClient。第二条看清单里的版本字符串，这一步别省——很多人编完直接拷过去，跑了两周才发现连的是社区版协议。第三条是个土办法，flink run --help这个动作会初始化 YARN 客户端，类路径有问题在这一步就会暴露，比等到真正提交作业再发现要好。

注意：如果你选的是HADOOP_CLASSPATH方案（不往lib/放 shaded jar），那就把上面第三条换成echo $HADOOP_CLASSPATH | tr ':' '\n' | grep hadoop，确认hadoop classpath的输出真的进了环境变量。这两条路只能走一条，两边都配的结果是双份 Hadoop 类同时可见。

3. 落盘部署：三个节点上的目录、参数与认证

3.1 目录规划与账号权限

目录规划看着琐碎，但它决定了后面所有权限问题的形态。CDH 集群一般由管理台统一分发配置，/etc/hadoop/conf是个软链，指向当前生效的版本目录。Flink 读配置只认HADOOP_CONF_DIR或HADOOP_HOME两个环境变量，所以第一步就是把这个软链指对。

# 1) 统一安装目录，用版本号做真实目录、软链做入口，升级回滚都靠它 sudo mkdir -p /opt/flink/flink-1.13.1 sudo tar -xzf flink-1.13.1-bin-scala_2.11.tgz -C /opt/flink/flink-1.13.1 --strip-components=1 sudo ln -sfn /opt/flink/flink-1.13.1 /opt/flink/current # 2) 数据盘与临时目录，别落在系统盘上 sudo mkdir -p /data/flink/{tmp,rocksdb,logs} sudo chown -R flink:flink /opt/flink /data/flink # 3) 环境变量写到全局 profile，提交节点与 TaskManager 节点都要有 sudo tee /etc/profile.d/flink.sh >/dev/null <<'EOF' export FLINK_HOME=/opt/flink/current export HADOOP_CONF_DIR=/etc/hadoop/conf export PATH=$FLINK_HOME/bin:$PATH EOF

这里每一步都有原因。用「版本号真实目录 +current软链」的结构，是为了让升级变成一次软链切换：新版本解压到flink-1.13.2，改一行软链，出问题再切回来，比覆盖安装快得多。/data/flink/tmp单独挂盘，是因为 Flink 的io.tmp.dirs会承接大量溢写，RocksDB 的本地目录也在同一块盘上，系统盘被写满会连带拖垮 NodeManager。

账号权限上有个默认坑：Flink 目录属主是flink，但提交作业的人往往是业务账号。YARN 上跑容器用的是提交者身份，容器里要读/opt/flink/current/lib，目录权限 755、文件权限 644 才不会出问题。如果集群开了 Kerberos，提交者还需要有对应 keytab 的读权限，keytab 文件权限一般是 400 且属主为提交用户，这一点后面 3.3 会展开。

3.2 flink-conf.yaml 里真正要改的十几行

flink-conf.yaml有几百个配置项，绝大多数不用碰。下面这十几行是我在 CDH 6.3.2 上每次都要改的，按「资源 / 状态 / HA / 类加载」四块排列。

# ---- 资源与内存：1.13 统一用 process.size 统管，不要再写 heap.size ---- jobmanager.memory.process.size: 2048m taskmanager.memory.process.size: 6144m taskmanager.memory.managed.fraction: 0.4 taskmanager.numberOfTaskSlots: 4 parallelism.default: 8 # ---- 运行期目录 ---- io.tmp.dirs: /data/flink/tmp env.java.opts.taskmanager: >- -Djava.security.krb5.conf=/etc/krb5.conf -XX:+UseG1GC -XX:MaxGCPauseMillis=200 # ---- 状态后端与检查点 ---- state.backend: rocksdb state.backend.rocksdb.localdir: /data/flink/rocksdb state.backend.incremental: true state.checkpoints.dir: hdfs://hacluster/flink/checkpoints state.savepoints.dir: hdfs://hacluster/flink/savepoints execution.checkpointing.interval: 60000 execution.checkpointing.mode: EXACTLY_ONCE execution.checkpointing.externalized-checkpoint-retention: RETAIN_ON_CANCELLATION # ---- HA：ZooKeeper 选主 + HDFS 存元数据 ---- high-availability: zookeeper high-availability.zookeeper.quorum: zk01:2181,zk02:2181,zk03:2181 high-availability.zookeeper.path.root: /flink high-availability.storageDir: hdfs://hacluster/flink/ha high-availability.cluster-id: /apps/flink-cdh high-availability.zookeeper.client.acl: creator # ---- 类加载：这一段是 CDH 上能不能跑通的关键 ---- classloader.parent-first-patterns.additional: >- org.apache.hadoop.;org.apache.hive.;com.google.common.;org.apache.curator.

内存那几行是 1.13 的变化点。1.13 用的是进程级内存模型，taskmanager.memory.process.size是整个容器的上限，Flink 从里面切出堆、堆外、托管、metaspace 和 JVM overhead 五块。同时写taskmanager.heap.size会和它打架，配错的表现是容器起不来但日志只有一句The configured heap size is invalid。managed.fraction给 0.4 是按 RocksDB 场景调的，纯流式无状态作业可以降到 0.2，把内存让给堆。

classloader.parent-first-patterns.additional这一行值得单独说。Flink 默认用 child-first 类加载，业务 jar 里的类优先，这在普通场景下是好事，避免和框架冲突；但 Hadoop、Hive 这些必须和集群用同一份的类，child-first 就会加载出两份，症状是莫名其妙的ClassCastException: cannot be cast to org.apache.hadoop.conf.Configuration。把org.apache.hadoop.、org.apache.hive.放进 parent-first 白名单，等于告诉 Flink「这几个包别自己造，用父加载器的」。com.google.common.是防 Guava 冲突，org.apache.curator.是防 ZK 客户端混用。

提示：这个白名单支持分号分隔的多个前缀，写在一行里会很长。用 YAML 的>-折叠写法，实际读出来还是单行，别用>之外的块标量，否则尾部换行符会混进最后一个前缀里，导致匹配失败。

3.3 Kerberos、YARN 与 ZooKeeper HA 的对接

CDH 集群十有八九开了 Kerberos，这是整套部署里最容易卡住的一环，因为失败现场往往只有一行GSSException，看不出是谁的问题。整条链路要打通三段：提交节点拿到票据、票据能带进 YARN 容器、容器里的 Flink 组件能用这张票访问 HDFS 和 ZK。

# 1) 提交节点：验证 keytab 本身可用（不看业务，只看认证） klist -kt /etc/security/keytabs/flink.keytab | head -5 kinit -kt /etc/security/keytabs/flink.keytab flink@BIGDATA.COM klist # 确认拿到的是 flink 主体、有效期覆盖作业运行时长 # 2) 验证票据能访问 HDFS 与 ZooKeeper 两个关键路径 hadoop fs -ls hdfs://hacluster/flink/checkpoints hadoop fs -ls hdfs://hacluster/flink/ha # 3) 清理本地票据，正式提交时不依赖 ticket cache kdestroy

第一步的klist -kt是验 keytab 文件本身，输出里能看到主体名和 kvno（密钥版本号），keytab 过期或 kvno 和服务端对不上，在这里就会露出马脚。第二步是关键，很多人验完kinit就以为通了，实际 HDFS 目录权限是另一回事——/flink这类根目录通常是hdfs:supergroup属主、755 权限，flink用户建不了子目录。常见做法是提前用hdfs账号建好目录并chown给运行账号：

sudo -u hdfs hadoop fs -mkdir -p /flink/{checkpoints,savepoints,ha} sudo -u hdfs hadoop fs -chown -R flink:flink /flink sudo -u hdfs hadoop fs -chmod -R 775 /flink

第三步的kdestroy是刻意的。Flink 有两种取票方式：用本地 ticket cache，或者用配置里的 keytab 自己续票。前者在长时间运行的流作业上会失效（票据一般 24 小时），表现出来是作业跑了十几个小时后突然 Checkpoint 全部失败，报No valid credentials provided。所以生产上我一般强制走 keytab 方式，把security.kerberos.login.use-ticket-cache设成false，配合下面几个参数一起写进配置。

security.kerberos.login.use-ticket-cache: false security.kerberos.login.keytab: /etc/security/keytabs/flink.keytab security.kerberos.login.principal: flink@BIGDATA.COM security.kerberos.login.contexts: Client,KafkaClient zookeeper.sasl.service-name: zookeeper zookeeper.sasl.login-context-name: Client

security.kerberos.login.contexts里的Client是给 HDFS 用的，KafkaClient只有接了 Kafka 才需要——但写上不会坏事，多注册一个 context 的开销可以忽略。zookeeper.sasl.service-name要和集群 ZK 的zookeeper.server.principal前缀一致（常见是zookeeper或zookeeper/host），对不上时 HA 选主会一直重试，日志里反复出现SaslException。这两个参数是 ZK 开了 SASL 才需要的，纯 Kerberos 没开 SASL 的集群可以省略，但省略了又恰好开了 SASL，症状会很像网络不通，排查方向容易跑偏。

3.4 起服务与冒烟：用一个 WordCount 验到底

静态配置改完，先起一个本地会话集群验证基础链路，再上 YARN。之所以不在第一步就上 YARN，是因为本地会话能把「类路径」和「配置」两类问题隔离出来——本地都跑不通，上 YARN 只会多一层容器日志要看。

# 1) 用三个 slot 起本地会话集群，standalone 模式足够验证类路径 $FLINK_HOME/bin/start-cluster.sh $FLINK_HOME/bin/flink list # 2) 跑一个读 HDFS 写 HDFS 的作业，把认证、类加载、状态目录都验一遍 $FLINK_HOME/bin/flink run \ -c com.example.smoke.HdfsCopyJob \ $FLINK_HOME/examples/streaming/SmokeDemo.jar \ --source hdfs://hacluster/tmp/smoke/in \ --sink hdfs://hacluster/tmp/smoke/out # 3) 验证 Checkpoint 真的落了盘（别只看 UI 上的绿点） hadoop fs -ls -R hdfs://hacluster/flink/checkpoints | head -20

第二步之所以强调「读 HDFS 写 HDFS」，是因为这一步同时压缩了三类风险：读的时候用FileSystem拿Configuration，能验出 parent-first 白名单配没配对；写的时候走 NameNode RPC，能验出 Kerberos 认证；作业一旦启动就会按execution.checkpointing.interval触发检查点，能验出状态目录权限和 RocksDB 本地盘。

第三步是经验之谈。UI 上 Checkpoint 显示绿色只能说明「最近一次成功」，但目录结构是否正确、有没有因为权限问题写到/tmp去，必须去 HDFS 上看。正常的目录结构长这样：<job-id>/chk-<n>/下是一堆状态文件，同级有一个_metadata。如果只看到_metadata没有chk-目录，多半是state.backend没配对或者本地盘写不进去，状态被丢弃了。

注意：本地会话集群验证通过之后，stop-cluster.sh一定要执行，并且确认lib/里没有残留的临时 jar。本地跑和 YARN 跑用的是同一个lib/，本地塞进去的东西在 YARN 模式下会被上传到分布式缓存，多出来一个不兼容的 jar 就是新的故障源。

4. 提交作业：Per-Job 模式的参数组合与 Hive 打通

4.1 flink run 的参数怎么拼

Per-Job 模式的特点是「一个作业一个 YARN Application」，JobManager 跑在 YARN 容器里，作业结束资源就释放。这种模式在 CDH 这类共享集群上最受欢迎，因为不和别人抢 AM 资源，出了问题也只影响自己。代价是每次提交都要重新申请容器，启动慢几十秒。

export HADOOP_CONF_DIR=/etc/hadoop/conf $FLINK_HOME/bin/flink run \ -t yarn-per-job \ -ynm etl-demo-$(date +%m%d%H%M) \ -yqu root.flink \ -yn 2 \ -ys 4 \ -D state.checkpoints.dir=hdfs://hacluster/flink/checkpoints/etl-demo \ -D execution.checkpointing.interval=60000 \ -D yarn.application-attempts=3 \ -D classloader.parent-first-patterns.additional='org.apache.hadoop.;org.apache.hive.;com.google.common.' \ -D security.kerberos.login.use-ticket-cache=false \ -D security.kerberos.login.keytab=/etc/security/keytabs/flink.keytab \ -D security.kerberos.login.principal=flink@BIGDATA.COM \ -c com.example.etl.DemoJob \ hdfs://hacluster/apps/jars/etl-demo-1.0.jar \ --window 60

参数逐个说。-t yarn-per-job是 1.13 里的模式选择，早前的-m yarn-cluster写法在新版本里已经不推荐。-yn 2是两个 TaskManager 容器，-ys 4是每个 TM 四个 slot，乘起来 8 个 slot 正好对应parallelism.default: 8，配不齐的话作业要么排队要么闲置。-yqu指定 YARN 队列，共享集群上这个必须显式给，走默认队列容易撞上别人的资源上限。

-D传的是每个作业独立的动态参数，会覆盖flink-conf.yaml里的同名项。这条路径有个细节：-D传进去的参数里，state.checkpoints.dir我用的是作业专属子目录，而不是全局目录。原因是 Per-Job 模式下多个作业共享一个 checkpoints 根目录时，目录名按 job-id 生成，回滚找状态文件会很痛苦；按作业名分目录，配合-ynm里带的时间戳，能一眼看出哪次提交对应哪份状态。

作业 jar 放在 HDFS 上（hdfs://hacluster/apps/jars/）而不是本地路径，是 CDH 环境下的习惯做法。YARN 的分布式缓存机制会把本地 jar 上传，几十兆的包每次上传都占带宽；放 HDFS 上，各节点直接从 HDFS 拉，省事且版本统一。代价是 jar 更新要走一次hadoop fs -put，所以我会在 jar 名里带版本号，避免缓存命中旧版本。

4.2 Checkpoint 落 HDFS 的配置与验证

状态能不能恢复，是流作业有没有价值的唯一标准。Checkpoint 的配置分三层：目录、策略、超时。

state.backend: rocksdb state.backend.incremental: true state.backend.rocksdb.localdir: /data/flink/rocksdb state.checkpoints.dir: hdfs://hacluster/flink/checkpoints/etl-demo state.checkpoints.num-retained: 5 execution.checkpointing.interval: 60000 execution.checkpointing.timeout: 10min execution.checkpointing.min-pause: 30000 execution.checkpointing.max-concurrent-checkpoints: 1 execution.checkpointing.tolerable-failed-checkpoints: 3

state.checkpoints.num-retained: 5是后悔药，保留最近 5 个成功检查点，作业挂了可以从任意一个恢复。max-concurrent-checkpoints: 1是防雪崩的关键——默认值在 1.13 里是 1，但有些模板会改成 2，状态大的作业并发做检查点会把网络和 HDFS 打满，表现出来是整个作业反压飙高。tolerable-failed-checkpoints: 3让连续失败三次才判作业失败，避免偶发的 HDFS 抖动直接干掉作业。

验证不止看 UI。REST API 能看到每次检查点的耗时和大小分布，这个信息比绿点有用得多：

# 1) 拿到 job id JOB_ID=$($FLINK_HOME/bin/flink list -r 2>/dev/null | grep -oE '[0-9a-f]{32}' | head -1) # 2) 查检查点统计，重点看 size 和 duration 两个字段的趋势 curl -s "http://jm-host:8081/jobs/${JOB_ID}/checkpoints" \ | python -m json.tool | head -40 # 3) 从 HDFS 侧确认状态文件真的写进去了 hadoop fs -du -h hdfs://hacluster/flink/checkpoints/etl-demo

第二条命令输出的history数组里，每个元素带size和duration。如果size一直涨但业务数据量没涨，多半是状态里攒了不该留的东西（比如没设 TTL 的键值状态）；如果duration从 3 秒涨到 40 秒，通常是 RocksDB 本地盘 IO 打满或者 HDFS 写入慢，得去看 NodeManager 那台机器的iostat。这两个指标的趋势比单次成败更有诊断价值。

4.3 Hive Catalog：让 SQL 直接读到 2.1.1 的元数据

CDH 集群上的 Hive 元数据是现成资产，Flink SQL 能直接挂上去读，这是这套组合最实用的部分。前提是 2.2 节说的那三件套已经放进lib/，且hive-site.xml在HADOOP_CONF_DIR能扫到的位置。

-- 在 sql-client 里执行，把发行版的 Hive 元数据挂成 Flink 的一个 Catalog CREATE CATALOG hive_cdh WITH ( 'type' = 'hive', 'default-database' = 'ods', 'hive-conf-dir' = '/etc/hive/conf', 'hadoop-conf-dir' = '/etc/hadoop/conf', 'hive-version' = '2.1.1' ); USE CATALOG hive_cdh; SHOW DATABASES; SHOW TABLES; -- 建一张带分区的表，验证写入路径 CREATE TABLE ods.demo_events ( user_id BIGINT, event_at TIMESTAMP(3), payload STRING ) PARTITIONED BY (dt STRING) WITH ( 'connector' = 'filesystem', 'path' = 'hdfs://hacluster/warehouse/ods/demo_events', 'format' = 'parquet', 'sink.partition-commit.policy.kind' = 'metastore,success-file' );

hive-conf-dir和hadoop-conf-dir分开配，是因为 CDH 把 Hive 和 Hadoop 的配置放在两个目录下，前者提供 metastore 的 thrift 地址和 warehouse 路径，后者提供 HDFS 的 HA 信息。两个都缺一不可：只配 `hive-conf-dir

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