1. 先别急着写代码搞清楚StandAlone模式是干嘛的很多朋友接触Flink时第一个上手的就是StandAlone模式。打开官网下载一个压缩包本地解压start-cluster.sh一跑Web UI一开集群起来了然后就开始提交作业跑WordCount。这一套流程虽然简单但如果只停留在“能跑通”的程度后面真正上了环境就会很被动——提交作业报错、资源不够、作业莫名其妙挂掉都不知道从哪里排查。我在实际工作中带过不少新人发现大家最容易陷入的误区是把StandAlone当成一种“生产可用的部署方式”来用。其实不是。StandAlone的核心定位是自管理集群它需要你自己维护JobManager和TaskManager的进程自己分配资源自己处理故障恢复。它更适合学习、测试、以及小规模的自建集群场景。相比YARN、K8s这种资源管理平台StandAlone少了“资源按需分配”和“作业隔离”的能力但胜在架构简单、链路透明是理解Flink作业提交原理的最佳手术台。这篇文章我会按照完整实操流程来写从集群搭建、配置调整、作业打包到Web UI提交、命令行提交、SQL作业提交再到日志排查和常见问题。整条链路我都会把原理和实操结合起来讲尤其是一些只在实际操作中才会踩到的坑我会单独整理出来。无论你是刚接触Flink的菜鸟还是已经在用YARN/K8s部署但想补全底层理解的同学这篇文章应该都能给你一些参考。2. 环境准备与集群搭建先把底座打好2.1 节点规划与版本选择StandAlone集群的最小单位是1个JobManager节点加1个TaskManager节点。生产环境如果要自建建议JobManager至少2台做高可用TaskManager根据并行度和数据量来决定。我自己测试时常用一台机器搞定全部角色但千万记住这只是测试环境别把这种单机多角色的部署方式直接搬上生产。版本选择上这里需要特别提醒一句。Flink社区迭代速度很快不同大版本之间的提交命令、配置项甚至Web UI界面都有差异。以我常用的Flink 1.17/1.18为例StandAlone集群的搭建流程基本一致但如果你用的是Flink 1.14以前的版本部分配置项名称会不一样。建议统一使用一个稳定版本我是以Flink 1.17为基础写的下面的配置如果你用的版本不同重点看配置项名称的对齐别直接复制文件就完事。JDK版本同样关键。Flink 1.17开始已经要求Java 8或者Java 11我用的是JDK 1.8稳定跑了一段时间没出问题。如果你的Flink版本比较新建议直接用JDK 11后续升级Flink版本时不用再折腾JDK。下面是一个3节点StandAlone集群的规划示例这个配置我实际测试过跑一些联机和窗口作业没问题但别拿它去扛大流量。节点角色配置建议说明node01JobManager4C8G跑Dispatcher、ResourceManager、JobMasternode02TaskManager4C8G提供Slot给作业调度node03TaskManager4C8G与node02形成资源池这里的C和G指的是CPU核数与内存大小Flink在StandAlone模式下不会自动感知机器的实际资源需要你在flink-conf.yaml里手工指定指定多了会OOM指定少了会浪费机器后面我会详细讲怎么算。2.2 flink-conf.yaml核心配置项逐行解读启动集群前需要修改conf目录下的flink-conf.yaml。这个文件是StandAlone模式的核心配置Flink所有进程的启动参数都从这里读取。默认文件里注释很多真正需要关注的没有几项我来逐个说明。# JobManager的通信地址StandAlone模式下TaskManager需要知道去哪注册 jobmanager.rpc.address: node01 # JobManager的RPC通信端口默认6123 jobmanager.rpc.port: 6123 # JobManager总内存建议至少1G起步我测试机用的2G jobmanager.memory.process.size: 2048m # TaskManager总内存这个值决定了单台机器能提供多少资源给作业 taskmanager.memory.process.size: 4096m # TaskManager管理的CPU核心数注意这个不是机器物理核数是逻辑资源 taskmanager.cpu.cores: 2 # 每台TaskManager提供的Slot数量默认1个 taskmanager.numberOfTaskSlots: 4 # 默认并行度提交作业时不指定并行度就使用这个值 parallelism.default: 2 # 每个TaskManager的最小/最大堆内存StandAlone模式下建议直接交给Flink托管 taskmanager.memory.managed.fraction: 0.4 # 临时文件目录建议修改到磁盘空间充足的路径 io.tmp.dirs: /data/flink/tmp这里我着重说下Slot和并行度的对应关系这是很多初学者最糊涂的地方。一个TaskManager的Slot数量决定了这台机器最多能同时运行多少个任务子任务而作业的并行度决定了这个作业会被拆成多少个子任务。比如一个作业并行度是4你有两台TaskManager各4个Slot那正好能容下。如果你的作业并行度是10而集群总Slot只有8个那作业就会一直处于等待资源的状态永远跑不起来日志里会反复提示“Not enough task slots to schedule tasks”。2.3 masters与workers文件配置conf目录下还有masters和workers两个文件。masters文件用于配置JobManager节点地址workers文件用于配置TaskManager节点地址。在Flink 1.17版本里这两个文件的主要作用是配合start-cluster.sh脚本实现集群的远程启动和停止。# masters文件内容一行一个JobManager地址 node01:8081 # workers文件内容一行一个TaskManager地址 node02 node03注意masters文件里可以指定Web UI端口默认是8081。如果你有多台JobManager做HA这里要全部写上但需要额外配置ZooKeeper或Kubernetes做leader选举篇幅原因这里不展开本文按单JobManager情况处理。2.4 启动集群与检验配置完成后在node01上执行以下命令启动集群# 进入Flink安装目录 cd /opt/flink # 启动集群脚本会读取masters和workers文件远程拉起所有节点进程 bin/start-cluster.sh启动成功后浏览器访问http://node01:8081就能看到Flink Web UI。页面右上角会显示当前集群的TaskManager数量和可用Slot数如果看到“Total Task Managers: 2”、“Available Slots: 8”说明集群已经正常起来了。我在第一次搭建时踩过一个非常经典的坑进程明明起来了但Web UI打不开。排查了半天才发现是安全组没放行8081端口。如果你也是远程访问记得先确认端口对外的访问策略否则功能都正常但页面就是打不开。另外提醒一个小习惯我每次启动完都会用jps命令检查一下Java进程jps # 正常输出 # 12345 StandaloneSessionClusterEntrypoint # 23456 TaskManagerRunner注意JobManager进程名是StandaloneSessionClusterEntrypointTaskManager进程名是TaskManagerRunner如果只看到其中一个要么是启动失败要么是workers文件配置有误导致节点没被拉起。3. 作业提交完整流程把每一步都走一遍3.1 作业打包与入口类设置集群准备就绪后接下来就是提交作业。Flink作业的本质是一个包含所有依赖和主类信息的Jar包。使用Maven开发时需要引入flink-streaming-java和flink-clients依赖然后通过maven-shade-plugin打一个fat jar。build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-shade-plugin/artifactId version3.2.4/version executions execution phasepackage/phase goals goalshade/goal /goals configuration transformers transformer implementationorg.apache.maven.plugins.shade.resource.ManifestResourceTransformer !-- 指定主类也可以提交时用-c参数指定 -- mainClasscom.example.flink.StreamingJob/mainClass /transformer /transformers /configuration /execution /executions /plugin /plugins /build打包好后jar包通常在target目录下命名类似flink-demo-1.0-SNAPSHOT.jar。我建议在jar包名里加上版本号和提交日期方便后续区分线上跑的是哪个版本。3.2 Web UI提交方式实操Web UI提交是可视化程度最高、最适合新手的方式。我刚开始学Flink时基本都用它因为每一步操作都能在界面上看到反馈。首先打开http://node01:8081在左侧菜单找到“Submit New Job”子页面。先点击“Add New”上传jar包上传界面支持直接拖拽文件还是蛮方便的。上传成功后jar包会出现在右侧的列表里点击jar包名称进入提交配置页面。配置页面有几个关键字段需要填我逐个说字段说明示例Entry Class主类全限定名com.example.flink.StreamingJobParallelism作业并行度4Program Arguments传给main方法的参数--input hdfs://input.txt --output hdfs://outputFlink JobManager目标JM地址node01:8081这里有一个容易忽略的地方Program Arguments的解析逻辑完全由你的代码自己处理。如果你在主类里没有写解析逻辑那么填了参数也不会生效相反如果代码里强制要求某个参数为空就报错那么这里必须填对。我见过不少同事在这里反复报错翻代码一看args解析用的是自己的工具类和Flink的命令行解析完全是两回事。提交前还建议先看一眼右侧的“Available Slots”数量确保作业并行度小于等于可用Slot数。我之前遇到过一个作业一直卡在“INITIALIZING”状态其实就是并行度设成了8而集群只有4个SlotFlink调度器一直在等待资源从Web UI的日志面板能看到反复提示资源不足。3.3 命令行提交方式详解生产必会生产环境中命令行提交更常见因为可以做一些脚本化封装。Flink的命令行工具是bin/flink标准提交命令长这样bin/flink run \ -m node01:8081 \ -c com.example.flink.StreamingJob \ -p 4 \ -d \ /opt/flink/jars/flink-demo-1.0-SNAPSHOT.jar \ --input /data/input.txt \ --output /data/output.txt这里每个参数都有它的用途我按实际使用频率逐个解释-m指定JobManager的RPC地址格式是host:port。如果你就在JobManager本机执行命令这个参数可以省略默认读取conf里的配置。但建议每次都显式指定避免换机器后默认配置不同导致连错集群。-c指定主类与打包时在manifest中设置的Main-Class等效。如果你的jar包中只有一个main方法可以省略如果你在同一个jar里打了多个作业必须用这个参数区分。-p指定作业并行度覆盖代码里env.setParallelism()和配置文件的parallelism.default设置优先级最高。-d表示detached模式即提交命令返回后客户端退出作业在集群后台继续运行。如果不加这个参数客户端会一直保持连接把作业的日志打印到终端一旦你关掉终端或者断开SSH提交命令会被杀掉作业也可能跟着停止。我第一次用的时候没加-d结果关闭终端后作业就无了排查了很久才发现是这个原因。如果作业代码里有需要动态传入的参数比如输入路径、窗口大小、Topic名称等直接在jar包路径后面追加即可这些参数会原封不动地传给main方法的String[] args。参数解析依赖你代码里的逻辑有可能是基础for循环也有可能是commons-cli建议提前确认解析方式。3.4 提交后如何验证作业正常运行命令行提交成功后终端会输出类似内容Job has been submitted successfully with JobID 2f5c7e1b3a9a4f8cbe63f4a0c94b9123拿到JobID说明作业提交已经成功。这时候从Web UI的“Running Jobs”就能看到这个作业点击进去可以看到DAG图、各算子并行度、数据流量、BackPressure等指标。我自己的验证习惯分三步走第一步看作业状态是否为RUNNING第二步看各个Task的Metrics吞吐量是否正常增长第三步看最终的sink输出结果是否符合预期。很多新手提交完作业只看第一步作业状态是RUNNING就以为万事大吉实际上算子可能因为某些数据问题在内部疯狂重试吞吐量为0这种问题从状态面板和反压指标一眼就能看出来。3.5 SQL作业提交适合快速迭代的场景随着Flink SQL在社区的普及越来越多场景开始用SQL的方式来提交作业。StandAlone模式下Flink提供了两个途径传统的sql-client.sh和较新的SQL Gateway。以sql-client为例先启动客户端并连接到现有的StandAlone集群bin/sql-client.sh \ embedded \ -Djobmanager.rpc.addressnode01 \ -Djobmanager.rpc.port6123 \ -Djobmanager.memory.process.size1024m \ -Dtaskmanager.memory.process.size4096m \ -Dtaskmanager.numberOfTaskSlots4连接成功后就可以在交互式命令行里写SQLCREATE TABLE orders ( order_id BIGINT, user_id BIGINT, amount DECIMAL(10, 2), ts TIMESTAMP(3), WATERMARK FOR ts AS ts - INTERVAL 5 SECOND ) WITH ( connector kafka, topic orders, properties.bootstrap.servers kafka:9092, format json, starting-offsets earliest ); CREATE TABLE order_stats ( user_id BIGINT, total_amount DECIMAL(10, 2) ) WITH ( connector print ); INSERT INTO order_stats SELECT user_id, SUM(amount) FROM orders GROUP BY user_id;SQL Client的模式更适合快速验证逻辑、做数据探索优点是无需写Java代码维护成本低。但缺点是作业提交后的控制力比较弱比如设置状态后端、管理Savepoint、配置重启策略都需要额外的SET命令来实现。如果团队里有多个同学并行开发SQL作业我建议关注一下SQL Gateway方案。它可以把SQL提交服务化让不同客户端通过RESTful API提交作业作业之间互相隔离比一个共享的sql-client会话要干净。不过SQL Gateway的部署配置会多一层大家可以根据团队规模自行选择。4. 提交模式对比与选型建议4.1 三种提交模式到底有什么不一样Flink作业提交模式在不同版本之间有一些变化。以Flink 1.17为例区分三种基本模式Session模式、Per-Job模式、Application模式。其中Session模式在StandAlone集群上是最常见的一种Per-Job模式在StandAlone上其实已经不再单独支持Application模式则是现在官方主推的提交方式。我在实践中的体会是这三种模式的核心差异本质上是“作业和集群生命周期”的关系不同。用一个生活化的类比来说Session模式就像一家共享餐厅已经租好场地、请好厨师你来点菜就行吃完可以走人但餐厅始终开着菜与菜之间可能会互相影响Per-Job模式相当于包场每来一批客人就重新开一家餐厅客走门关Application模式则像流动餐车每次出摊连场地、设备、人员一起打包带走出摊结束全部撤掉。这三种模式的取舍关系如下模式Cluster生命周期资源隔离运维成本适用场景Session常驻弱作业间共享TM低小作业、临时查询、教学测试Application作业即集群强作业独享中生产环境推荐Per-Job作业即集群强作业独享中老版本Flink常见方式在StandAlone集群上两种主要提交方式对应命令为# Session模式提交复用已有集群 bin/flink run -d -c com.example.flink.StreamingJob app.jar # Application模式提交为这个作业单独拉起一个集群 bin/flink run-application -d -c com.example.flink.StreamingJob app.jar4.2 为什么生产环境我不推荐StandAlone说完提交模式再说下部署模式的选型。Flink支持StandAlone、YARN、Kubernetes等部署方式。很多人会有疑问既然StandAlone也能跑为什么生产上大家还是优先选YARN或K8s我在一个自建集群的项目里有过一段切身体会。当时为了节省运维成本选用了StandAlone模式跑十几个作业。刚开始没什么问题但随着作业数量增加问题开始显现TaskManager内存被某个大作业吃光其他作业集体失败两台TaskManager中有一台网络抖动上面的作业直接重启没有自动故障转移想要给某个作业增加并行度却发现集群总Slot不够得手工加机器。这些痛点让我明白了一个道理StandAlone不是不能跑生产而是它的容错和资源管理能力太依赖人工人一旦忙不过来系统就会变得很脆弱。相比之下YARN和K8s的优势在于资源管理器会自动调度、自动重启、自动伸缩。比如YARN下Application模式提交的作业如果失败YARN会帮你重新拉起一个Application MasterK8s下则可以通过Pod重启机制保证任务的可用性。这些能力StandAlone虽然也能通过配置实现一部分但复杂度会高很多。所以我的建议非常明确如果是学习、搭建测试环境、快速验证逻辑放心大胆用StandAlone如果是生产环境优先考虑YARN或K8s。如果你所在的公司已经统一使用了容器化调度平台直接用K8s部署Flink即可StandAlone可以作为你在本地调试时的辅助环境。5. 作业运行监控与问题排查手段5.1 Flink日志应该怎么看作业提交成功只是开始真正花时间和精力的往往是运行期的排查。Flink的日志体系在StandAlone模式下主要在log目录下我在实际排查问题时的路径如下log/flink-{user}-standalonesession-{id}-{host}.logJobManager主日志包含作业提交、调度、检查点等核心信息。log/flink-{user}-taskexecutor-{id}-{host}.logTaskManager日志算子的执行异常、序列化错误、背压相关信息都在这里。log/flink-{user}-taskexecutor-{id}-{host}.out算子里的println或log输出有时候写代码时打的日志会进这个文件。一个高效的排查顺序是先看Web UI上作业状态快速定位问题出在哪个算子再去看对应TaskManager日志的ERROR级别内容如果日志里没有明确报错但作业卡住再看系统指标比如CPU、内存、BackPressure。这样比漫无目的翻日志效率要高得多。5.2 常见运行期问题与处理方案我在实际运行中遇到最多的四类问题这里整理出来供参考问题一JobManager连接失败作业提交报错。org.apache.flink.util.FlinkException: Could not connect to the leading JobManager原因通常有几种JobManager进程没启动成功、jobmanager.rpc.address配置写错、防火墙没有开放6123端口。我建议先在本机执行telnet node01 6123验证网络是否能通如果通了再检查Flink进程是否还在。问题二TaskManager注册失败Web UI上一直看不到TaskManager。排查思路是先看TaskManager日志比较常见的错误是java.io.IOException: Failed to connect to node01:6123。这种大概率是TaskManager节点到JobManager节点的网络不通或者masters文件里的地址写的不是JobManager实际监听的地址。另外如果JobManager和TaskManager的Flink版本不一致也会导致注册失败建议统一版本再启动。问题三作业并行度大于可用Slot数作业一直处于等待状态。这个问题在前面提过属于资源规划问题。解决方式有两种调低作业并行度或者给TaskManager增加Slot数量需要重启TaskManager使配置生效。在真正生产环境我建议通过监控提前跟踪集群Slot使用率超过80%的时候就扩容避免作业提交了但没法调度。问题四检查点失败导致作业反复重启。如果日志里出现Checkpoint was declined或Checkpoint expired before completing通常说明检查点存储路径有问题或者检查点间隔太短导致来不及完成。解决方案是延长检查点间隔、检查存储系统如HDFS的写入速度、确认状态后端配置正确。我建议检查点间的间隔不要低于30秒否则频繁做快照会拖慢整个作业。5.3 我常用的几个排查命令除了看Web UI和日志下面几个命令在我排查问题时会经常用到# 查看实时日志输出方便调试 tail -f log/flink-*-taskexecutor-*.log # 查看端口监听状态确认Flink进程是否正常 netstat -tlnp | grep 6123 netstat -tlnp | grep 8081 # 查看JVM堆内存Flink的OOM排查很依赖这个命令 jstat -gcutil pid 1000 # 如果作业卡住抓一份线程栈来看阻塞位置 jstack pid jstack_dump.txt我遇到过几次作业“假死”的情况从Web UI看作业状态是RUNNING但吞吐量是0。用jstack抓线程栈后发现任务是卡在访问外部系统的连接上比如数据库连接池耗尽、HTTP接口超时无响应等。这种问题日志里通常不会主动报错需要靠线程栈来定位。5.4 SQL作业排查与数据血缘追踪用Flink SQL提交的作业排查起来和DataStream作业有些不同。因为SQL作业的算子名称往往是系统自动生成的比如Source: orders、GroupAggregate从日志中判断某个算子的业务含义会比较费劲。我的建议是在建表时尽量选用能表达业务含义的表名、字段名和注释并且在提交SQL时把作业名设置得有意义一些比如SET pipeline.name orders-agg-daily-job;这样Web UI中看到作业名就能快速对应业务。另外数据血缘数据从哪里来、经过哪些算子、落到哪里去在SQL作业的运维中非常有用。Flink社区和商业版都有相关的血缘解析工具可以把SQL解析成完整的血缘图。当某个下游表数据异常时通过血缘图可以快速反查是哪个上游源表、哪个作业处理出了问题。这比凭经验去猜要高效得多。6. 问题速查表与避坑经验下面是我在实际操作中经常遇到的现象、原因和解决方案整理成一张速查表方便大家遇到问题时直接对号入座。现象可能原因排查方法解决方案Web UI打不开8081端口被防火墙拦截netstat -tlnpgrep 8081JobManager进程启动即退出flink-conf.yaml配置有误或JDK版本不兼容查看JobManager日志修正配置确认JDK版本TaskManager注册不上masters/workers地址配置错误或网络不通telnet到6123端口修改配置检查网络作业一直INITIALIZINGSlot资源不足Web UI查看Available Slots调低并行度或扩容TaskManager作业运行但无输出Sink配置问题或数据源消费不到查看TaskManager日志与吞吐指标检查Source/Sink连接器参数检查点持续失败存储路径写入慢或检查点间隔过短查看JobManager日志增大间隔、换存储、调整状态后端反压持续出现下游处理能力不足Web UI查看BackPressure指标优化算子逻辑、增加并行度6.1 我在StandAlone实操中踩过的坑第一坑修改配置后没有重启所有进程导致配置不生效。Flink的配置在进程启动时一次性读取修改后必须重启JobManager和TaskManager。如果你只重启了JobManagerTaskManager还是旧的配置集群行为就完全不可预期。我之前因为没有重启TaskManager导致新增的Slot一直不生效浪费了半个多小时排查。第二坑把作业的jar包放在集群节点以外的机器上执行flink run。提交命令所在的客户端会读取jar包并上传到JobManager但如果jar包本身依赖了本地绝对路径的资源文件比如读文件系统这些资源文件不会随jar包上传运行时会报FileNotFound。解决方式是把这类资源文件放到HDFS或对象存储上用统一的路径访问。第三坑TaskManager JVM内存设置过大导致节点本身内存吃紧。Flink的taskmanager.memory.process.size包含堆内和堆外内存如果在4G内存的机器上设置了4G甚至更高操作系统本身和Flink网络等进程就没有内存可用了轻则Swap严重重则进程被系统OOM Killer直接杀掉。我建议预留20%到30%的系统内存不要顶着物理内存配置。第四坑本地调试和线上集群的依赖不一致。很多同学本地能正常跑的作业提交到StandAlone集群就报NoSuchMethodError或ClassNotFoundException。这通常是jar包内打入了和Flink框架冲突的依赖版本例如Jackson、Netty、Hadoop建议使用maven-shade-plugin时把Provided作用域的Flink依赖排除掉只保留真正需要的业务依赖。6.2 一个经典案例Flink JDBC连接器异常排查全过程我在用Flink SQL往MySQL写数据时遇到过一次很典型的连接器异常现象是作业提交流程完成但作业启动后不断报错重启。错误日志大致如下org.apache.flink.connector.jdbc.internal.connection.JdbcConnectionProvider: Failed to get db connection Caused by: java.sql.SQLException: Communications link failure当时第一反应是网络不通或者MySQL配置有问题。但检查后发现本机用MySQL客户端连数据库是正常的。后来我查看了TaskManager的日志发现报错信息中出现了“Connection refused”字样加上排查执行日志中指向的IP是TaskManager所在机器的IP才意识到问题出在数据库的白名单配置上。原来MySQL只对特定IP网段开放了访问权限而TaskManager所在的主机不在白名单内。从这里可以得到一个排查连接器异常的通用思路不要只看错误信息的第一行先确认报错主机的IP和你的客户端IP是否一致其次检查MySQL侧的max_connections是否够用Flink作业多个并行度同时建连时很容易打满连接数最后检查连接器的参数设置例如--driver、--url、--username、--password是否都配置正确且没有特殊字符被转义。这个案例也再次印证了一个管理经验连接器类问题往往不在Flink本身而在外部系统的访问策略。排查的时候优先把目标系统和Flink集群的连通性、权限、配额搞清楚能省很多时间。7. 最后分享一点个人体会从开始折腾Flink到现在StandAlone模式始终是我用来理解Flink运行机制的首选环境。它不像YARN/K8s那样帮你屏蔽了很多细节反而逼着你去理解组件间的通信方式、资源调度逻辑和作业生命周期管理。对这些底层机制的理解会让你在以后使用其他部署模式时更加从容。有几个建议给刚入门的朋友第一一定要自己动手搭一遍StandAlone集群然后把示例作业用Web UI和命令行各提交一次形成完整的操作记忆第二遇到问题先看日志不要盲目去网上搜“Flink报错”然后复制一个配置就完事自己学会从日志中定位问题的根因比任何现成答案都可靠第三把本文末尾这张问题速查表保存下来实践中遇到类似问题时对照排查能快速找到方向。我自己的经验是CSDN、官网、Stack Overflow都是很好的辅助工具但真正的能力提升来自于把一个个具体问题处理完之后的复盘。每解决一个问题就把排查思路和解决过程记录下来日积月累就能形成一套自己的排除方法论。