flink standalone 部署模式且不能使用 hdfs 场景下的各种问题及其应对方案

一。背景

笔者所在公司某系统在某证券公司现场部署时，客户出于自己集群使用规划的考量，不允许 flink 访问大数据集群，既不能使用yarn资源管理器，也不能访问hdfs文件系统，而该系统中中 flink 应用程序的数据链路是 flink sql 读取 kafka topic中的数据，进行计算分析后写到es中供下游业务系统使用，计算过程中使用到了 flink 的 table api和sql。

该场景其实是flinkstandalone 部署模式且不能使用 hdfs 的典型场景，我在这里汇总分析了下该场景下相关的技术问题，并结合flink相关技术点的细节和原理，给出了各个问题可能的解决方案，供大家参考。

问题主要分为三大类：jobmanager 高可用部署，catalog配置和使用，以及state backend 配置和使用。

以下是正文。

二。什么是 standalone 部署模式

首先明确下什么是 flink 的standalone 部署模式。

flink的 standalone 部署模式，即standalone deploy mode，是从 flink 集群的resource provider的角度说的，指的是flink直接在操作系统上启动flink 相关服务如client, jobmanager, taskmanager，而不依赖其它资源管理框架如yarn, mesos, k8s进行资源管理。

此时是由 flink直接来进行集群资源管理的，比如监控和重启失败的服务进程，分配和释放资源等等。

需要说明的是，standalone模式下，也可以结合使用docker和k8s （flink将使用k8s作为资源管理框架的模式称为native k8s mode，以跟standalone模式下的k8s进行区分）。

三。standalone 部署模式跟 hdfs 的关系

接着看下 standalone 部署模式跟 hdfs 的关系。

通过以上概念可以看出，flink的standalone模式，跟flink是否能访问大数据集群中的hdfs没有任何关系。

很多standalone模式的flink，仍然使用的是大数据集群中的hdfs，作为job manager 高可用部署的后端存储（high-availability.storageDir），作为 checkpoint 时状态快照的后端存储（state.checkpoints.dir/state.savepoints.dir）。

四。standalone 部署模式且不能使用hdfs场景下各种问题及其应对方案