1. 为什么Flink On Yarn不是“装完就跑”而是必须重写调度逻辑的起点Flink On Yarn这个标题表面看是讲怎么把Flink集群塞进Yarn里跑起来——但如果你真这么理解十有八九会在第二天凌晨三点被告警电话叫醒。我见过太多团队在测试环境用./bin/yarn-session.sh -n 3 -jm 1024 -tm 2048一行命令拉起Session后拍手庆祝结果上线第一天就发现任务提交延迟飙升、资源申请失败率超40%、TaskManager频繁失联而Yarn ResourceManager日志里只有一行冰冷的Application attempt appattempt_171... failed with state FAILED。这不是Flink的问题也不是Yarn的bug而是对“On Yarn”本质的误读。Flink On Yarn从来不是简单的“容器搬运工”它是一次调度权的移交Flink不再自己管资源JVM进程、内存分配、节点存活而是把资源申请、生命周期管理、容错恢复全部交由Yarn统一调度。这意味着你写的每一份Flink作业配置都必须通过Yarn的资源模型来翻译你调的每一个并行度参数最终都要映射成Yarn的Container规格你依赖的本地磁盘路径在Yarn的分布式沙箱里可能根本不存在。关键词里虽然没填但实际落地中绕不开的三个硬核概念是ApplicationMasterAM角色切换、Yarn Container资源隔离边界、Flink JobGraph到Yarn Application Submission的编译时转换。很多人卡在第一步——以为yarn-session.sh启动的是Flink集群其实它启动的是一个长期运行的Flink AM实例这个AM才是和Yarn通信的唯一代理。所有后续提交的Job都是向这个AM发请求再由AM向Yarn申请新的Container来运行TaskManager。这中间没有“直连”只有“委托”。更关键的是Flink的默认内存模型JVM堆内/堆外、Network Buffers、Managed Memory和Yarn的Container内存限制yarn.nodemanager.resource.memory-mb存在天然错位。比如你设-tm 4096Flink会按需分配堆内存堆外内存但Yarn只认-Xmx3g这一块剩下的1g如果被Netty Buffer或RocksDB占用Yarn会直接Kill Container——而Flink日志里只会报Container killed by YARN for exceeding memory limits不告诉你具体超在哪。所以Flink On Yarn的本质是一场资源语义的翻译战争。你不是在部署一个框架而是在两个调度系统之间架设一座语法转换桥。桥塌了不是桥本身质量差而是你没校准两端的单位制Yarn说“内存单位是MB”Flink说“内存分Heap/Off-heap/Network三块”而你的配置文件里却写着taskmanager.memory.process.size: 4096m——这就像给公制图纸配英尺扳手拧得越用力崩得越快。提示不要迷信官方文档里的“Quick Start”示例。那些参数如-tm 1024是为单机伪分布式设计的真实集群中必须根据Yarn NodeManager的yarn.nodemanager.resource.memory-mb值反向推算。例如若NodeManager总内存为32GB建议单Container上限设为8GB留出系统开销和Yarn自身占用否则极易触发Yarn的OOM Killer。2. Flink On Yarn的三种模式Session、Per-Job、Application选错等于埋雷Flink On Yarn不是单一部署方式而是三种截然不同的资源契约模型。很多团队踩坑根源在于用Session模式扛生产流量却按Per-Job模式调参——就像用共享单车的刹车系统去开高铁物理上能动但安全边界早已失效。2.1 Session模式共享AM的“长租公寓”适合开发调试而非生产Session模式的核心是一个AM长期驻留多个Job复用同一组TaskManager。启动命令是./bin/yarn-session.sh -d -n 4 -s 4 -jm 2048 -tm 4096其中-n指定TaskManager数量-s指定每个TM的slot数。它的优势是启动快、资源复用率高但致命缺陷在于资源强耦合与故障域放大。举个真实案例某公司用Session模式跑实时风控作业配置了8个TM每个4个slot。某天一个作业因代码Bug导致某个TM的JVM Full GC持续12秒Yarn检测到该Container无心跳强制Kill。结果整个Session崩溃——因为Flink的Session模式下AM与所有TM是强绑定关系一个TM挂AM判定集群不可用主动退出。所有正在运行的作业瞬间中断且无法自动恢复除非手动重启Session并重提作业。更隐蔽的问题是资源争抢。假设A作业占满3个TMB作业只用1个slot但B作业的算子需要大状态RocksDB而Flink的Managed Memory是全局池化分配的。当B作业触发大量状态读写会挤占A作业的Network Buffer导致A作业反压加剧吞吐骤降。这种“邻居效应”在Session模式下无法隔离。注意Session模式仅推荐用于开发环境快速验证逻辑或离线批处理场景作业间无状态依赖。生产环境绝对禁止使用除非你已实现AM的高可用HA TM的自动扩缩容需自研或集成Kubernetes Operator但这已超出纯Yarn范畴。2.2 Per-Job模式一作业一集群的“单间民宿”资源干净但成本高Per-Job模式通过./bin/flink run -m yarn-cluster -p 4 -yjm 2048 -ytm 4096 ./myjob.jar提交每次提交都启动全新的AM和专属TM集群。它的核心价值是资源硬隔离与故障域收敛A作业崩溃B作业完全不受影响A作业内存溢出只Kill自己的ContainerAM和其他Job的TM毫发无损。但代价是资源效率低下。假设你每天提交50个作业每个作业平均运行2小时那么Yarn上会同时存在50个独立的AM进程每个AM至少占用512MB内存。这些AM不干活只监听却持续消耗Yarn的ApplicationMaster资源配额。某次我们实测当并发AM数超过200Yarn ResourceManager的RPC响应延迟从20ms飙升至2s导致新作业提交超时。另一个常被忽略的细节是Jar包分发机制。Per-Job模式下Flink客户端会将用户Jar及所有依赖包括Flink lib目录打包上传至HDFS临时目录yarn.ship-files再由AM分发给各TM。如果Jar包超大500MB上传过程可能耗时数分钟且HDFS NameNode压力剧增。我们曾遇到因HDFS小文件过多触发NameNode GC导致AM启动失败。2.3 Application模式作业即集群的“定制别墅”Flink 1.15的生产首选Application模式是Flink 1.15引入的终极解法命令为./bin/flink run-application -t yarn-application -Dyarn.application.namemy-job -Djobmanager.memory.process.size2048m -Dtaskmanager.memory.process.size4096m ./myjob.jar。它的革命性在于用户Jar包内嵌JobManager启动逻辑AM由用户代码直接控制。这意味着什么第一AM不再是Flink预编译的二进制而是你作业的Main Class。你可以在这个Main方法里做任何事初始化HBase连接池、预热Redis缓存、加载外部配置中心数据——所有这些都在AM启动阶段完成避免了Job运行时的冷启动延迟。第二资源申请粒度更精细。传统模式中TM的内存配置是静态的-ytm 4096而Application模式支持动态内存配置例如-Dtaskmanager.memory.managed.fraction0.4让Flink根据实际负载调整Managed Memory大小避免固定分配造成的浪费。第三也是最关键的——故障恢复能力质变。当某个TM失败AM可基于Checkpoint重新申请Container并只恢复失败Task的状态而非整个Job重启。我们在线上对比测试同样一个包含100个KeyGroup的窗口作业Per-Job模式恢复耗时47秒Application模式仅12秒因为后者跳过了AM重建和全量Jar分发环节。实操心得Application模式要求Flink版本≥1.15且必须使用flink-sql-client或flink run-application命令。切勿在旧版Flink上强行套用参数会导致AM启动失败并报ClassNotFoundException: org.apache.flink.client.deployment.application.ApplicationClusterEntryPoint。升级前务必验证Yarn版本兼容性需Hadoop 3.1。3. Yarn侧必须死磕的五个参数它们决定Flink能否活过第一个小时Flink On Yarn不是Flink单方面的事Yarn集群的配置才是地基。很多团队Flink配置调得飞起却栽在Yarn的默认参数上。以下五个参数每个都曾在我们线上环境引发过P0级事故必须逐条核对。3.1yarn.nodemanager.resource.memory-mbNodeManager的“总预算”这是Yarn为每个NodeManager设定的最大可用内存上限。Flink申请的Container内存-ytm不能超过此值否则Yarn直接拒绝。但问题在于这个值默认往往设得太小。Hadoop官方文档建议设为物理内存的80%但很多运维同学直接照搬导致32GB物理内存的机器只开放25GB给Yarn剩下7GB留给OS和Yarn自身进程——这看似合理实则埋雷。为什么因为Flink的taskmanager.memory.process.size包含JVM堆内存、JVM堆外内存Direct Memory、Native内存Netty、RocksDB三部分。而Yarn的memory-mb只约束JVM堆Direct MemoryNative内存是“游离态”的。当Flink开启RocksDB状态后端Native内存可能暴涨至2GB若NodeManager预算只有25GB而Flink申请的Container Process Size为8GB含2GB NativeYarn实际分配时会发现剩余可用内存不足8GB于是拒绝申请Flink日志报Failed to request resources from YARN。解决方案将yarn.nodemanager.resource.memory-mb设为物理内存的90%并预留5%给Native内存。例如32GB机器设为28672MB28GB再通过-Dtaskmanager.memory.native.heap.size1024m显式限制Native内存上限。3.2yarn.scheduler.maximum-allocation-mbContainer的“单笔限额”这个参数定义了单个Container能申请的最大内存。它必须≥Flink申请的最大Container内存-ytm或-Dtaskmanager.memory.process.size。但很多集群设为8192MB8GB而Flink作业需要12GB TM结果Yarn返回Requested container memory 12288 exceeds maximum allowed container memory 8192。更隐蔽的陷阱是此参数在Yarn Web UI的“Scheduler”页签中显示为max allocation但实际生效需重启NodeManager。我们曾遇到修改后未重启导致新参数始终不生效排查三天才发现是服务未重载。3.3yarn.nodemanager.vmem-pmem-ratio虚拟内存与物理内存的“汇率”Yarn默认允许虚拟内存VMEM是物理内存PMEM的2.1倍。但Flink的Netty和RocksDB大量使用Direct Memory这部分内存计入VMEM但不计入PMEM。当vmem-pmem-ratio过低如1.5Yarn会因VMEM超限Kill Container而Flink日志只显示Container was killed by YARN不提示具体原因。实测数据一个-ytm 8192的Flink TM在vmem-pmem-ratio2.1时稳定运行当ratio降至1.8RocksDB Compaction期间VMEM峰值达15GB触发Yarn Kill。解决方案是将ratio调至4.0并配合-Dtaskmanager.memory.network.max2048m限制网络缓冲区从源头压降VMEM。3.4yarn.resourcemanager.am.max-attemptsAM的“复活次数”此参数决定AM失败后最多重试几次。默认值为2意味着AM崩溃两次后整个Application永久失败。对于Per-Job或Application模式这会导致作业彻底丢失。必须设为4以上并配合-Dyarn.application-attempts4Flink侧参数形成双保险。3.5yarn.nodemanager.env-whitelist环境变量的“白名单签证”Flink需要将HADOOP_CONF_DIR、JAVA_HOME等环境变量透传给Container否则TM无法读取HDFS配置或找不到Java。但Yarn默认只白名单JAVA_HOME和HADOOP_COMMON_HOME等少数变量。若漏配HADOOP_CONF_DIRTM启动时报java.lang.RuntimeException: Failed to load Hadoop configuration而错误堆栈深藏在Container日志里极难定位。正确做法在yarn-site.xml中添加property nameyarn.nodemanager.env-whitelist/name valueJAVA_HOME,HADOOP_COMMON_HOME,HADOOP_HDFS_HOME,HADOOP_CONF_DIR,PATH,LANG,TZ/value /property并确保HADOOP_CONF_DIR指向正确的HDFS配置目录通常为/etc/hadoop/conf。踩坑实录某次升级Hadoop后HADOOP_CONF_DIR路径从/etc/hadoop/conf变为/etc/hadoop/conf.cloudera但Yarn白名单未更新导致所有Flink TM无法连接HDFS。排查时发现ResourceManager日志有Environment variable HADOOP_CONF_DIR is not whitelisted警告但Flink客户端日志完全不体现最终靠抓包发现TM发起的是localhost:8020连接默认fallback而非配置的HA NameService地址。4. Flink侧配置的七道生死关从JVM参数到状态后端的硬核调优Flink On Yarn的稳定性70%取决于Flink自身的配置是否与Yarn资源模型对齐。以下七个配置项每个都经过线上百万级QPS场景验证错一个轻则性能抖动重则集群雪崩。4.1taskmanager.memory.process.size进程总内存的“宪法”这是Flink 1.10引入的统一内存配置取代了旧版的taskmanager.heap.size和taskmanager.memory.off-heap.size。它定义了TM进程的总内存上限包含JVM Heap堆内存JVM Off-HeapDirect MemoryNative MemoryNetty、RocksDB等关键原则process.size必须≤Yarn的yarn.scheduler.maximum-allocation-mb且建议预留10%余量。例如Yarn单Container上限为8GB则设-Dtaskmanager.memory.process.size7168m7GB。计算公式process.size heap.size off-heap.size native.heap.size network.max其中network.max默认为process.size * 0.1native.heap.size默认为process.size * 0.1。因此若设process.size7168m则Heap约5GBOff-Heap约700MBNative约700MBNetwork约700MB。实操技巧用jstat -gc pid监控TM的JVM内存重点关注OUOld Used和OCOld Capacity。若OU/OC 0.8且持续上升说明Heap不足需增大process.size或调小-Dtaskmanager.memory.jvm-metaspace.size512mMetaspace默认1G常过剩。4.2state.backend与state.checkpoints.dir状态后端的“心脏起搏器”Flink的容错基石是Checkpoint而Checkpoint的性能和可靠性由状态后端决定。生产环境唯一推荐RocksDB因其支持增量Checkpoint和异步快照避免堆内存压力。但RocksDB有两大陷阱第一state.backend.rocksdb.localdir必须指向本地高速磁盘如NVMe SSD而非HDFS或网络存储。RocksDB的Compaction和Write-Ahead LogWAL需要低延迟IOHDFS的网络IO会拖垮吞吐。我们实测本地SSD下Checkpoint间隔10秒WAL写入延迟5msHDFS下同样配置WAL延迟峰值达1200ms触发Flink反压。第二state.checkpoints.dir必须指向高可用HDFS路径如hdfs://nameservice1/flink/checkpoints且该路径需开启Erasure CodingEC以节省空间。注意RocksDB的本地目录localdir和Checkpoint远程目录checkpoints.dir是两个完全独立的路径前者管瞬时IO后者管持久化。4.3execution.checkpointing.interval与execution.checkpointing.tolerable-failed-checkpointsCheckpoint的“心跳节律”Checkpoint间隔不是越短越好。设为30秒看似保障数据一致性实则带来三重压力频繁触发WAL刷盘增加磁盘IO每次Checkpoint需序列化全量状态CPU占用飙升网络传输Checkpoint数据占用带宽我们线上采用分级策略核心交易流60秒平衡一致性与性能日志分析流120秒容忍少量重复维度广播流300秒状态小频次低tolerable-failed-checkpoints默认为0即一次失败就Fail Job。生产环境必须设为3允许短暂网络抖动或HDFS延迟导致的Checkpoint失败避免雪崩。4.4restart-strategy重启策略的“急救协议”Flink默认重启策略是fixed-delay固定延迟但生产环境必须用failure-rate失败率。配置为restart-strategy: failure-rate restart-strategy.failure-rate.max-failures-per-interval: 3 restart-strategy.failure-rate.failure-rate-interval: 600s restart-strategy.failure-rate.delay: 60s这意味着10分钟内最多允许3次失败每次失败后等待60秒再重启。相比fixed-delay无限重启它能有效阻断“失败-重启-再失败”的死亡循环。例如TM因内存泄漏OOMfixed-delay会不断重启直至耗尽Yarn资源而failure-rate在3次失败后停止重启触发告警人工介入。4.5parallelism.default与jobmanager.execution.failover-strategy并行度的“交通管制”parallelism.default设为1是新手常见错误导致作业单线程运行吞吐归零。必须根据Kafka Topic分区数或HDFS文件数设置原则是并行度 ≤ 数据源分区数。例如Kafka Topic有16个Partition则-Dparallelism.default16确保每个Subtask消费一个Partition。failover-strategy决定Task失败时的恢复范围。默认region区域级会重启整个Region含上下游Task而full全图级重启整个Job。对于状态大的作业region更高效但对于跨Operator强依赖的作业如CEP复杂事件处理full更稳妥避免Region重启导致状态不一致。4.6web.submit.enable与high-availabilityWeb UI的“双保险”web.submit.enabletrue允许通过Flink Web UI提交作业但生产环境必须关闭因为UI提交的作业默认走Session模式且无权限控制任何员工都能提交任意Jar包存在严重安全风险。所有作业必须通过CI/CD流水线用flink run-application命令提交。high-availability必须启用配置为zookeeper推荐或filesystem。ZooKeeper方案需配置high-availability: zookeeper high-availability.storageDir: hdfs://nameservice1/flink/ha/ high-availability.zookeeper.quorum: zk1:2181,zk2:2181,zk3:2181 high-availability.zookeeper.path.root: /flink注意storageDir必须是HDFS高可用路径且Flink用户需有读写权限否则HA无法选举Leader。4.7 JVM参数GC的“呼吸节奏”Flink TM必须用G1 GC禁用CMS。JVM参数模板-XX:UseG1GC -XX:MaxGCPauseMillis50 -XX:ParallelRefProcEnabled -XX:G1HeapRegionSize2M -XX:G1HeapWastePercent5 -XX:G1MixedGCCountTarget8 -XX:InitiatingHeapOccupancyPercent15关键点InitiatingHeapOccupancyPercent15表示堆占用15%就触发GC避免Full GC。G1的MaxGCPauseMillis50需配合-Xmx5gHeap Size若Heap过大如8gG1可能无法满足暂停目标需调小Heap或改用ZGCFlink 1.17支持。经验总结我们线上集群的黄金组合是Yarn NodeManager内存32GB →yarn.nodemanager.resource.memory-mb28672→ Flink TMtaskmanager.memory.process.size7168m→ JVM Heap-Xmx5120m→ G1 GC参数如上。此配置下100个TM集群连续运行6个月无一次因内存问题导致的非计划中断。5. 从提交到运行的完整链路一次flink run-application背后的17个关键步骤很多人以为flink run-application是一条命令实则背后是Flink Client、Yarn RM、NodeManager、Flink AM、TaskManager五方协同的精密舞蹈。理解每一步才能精准定位故障。5.1 步骤1-3Client端的“战前准备”Jar包解析与依赖扫描Flink Client读取myjob.jar扫描MANIFEST.MF中的Class-Path递归收集所有依赖Jar包括Flink lib目录下的flink-dist_*.jar。若依赖冲突如两个不同版本的guava.jarClient会报Duplicate class found并终止。配置合并与校验Client合并命令行参数-D、flink-conf.yaml、log4j.properties校验关键参数合法性。例如检查taskmanager.memory.process.size是否为数字是否超过Yarn单Container上限。HDFS上传与资源注册Client将用户Jar、依赖Jar、配置文件打包为application_timestamp.zip上传至HDFS临时目录/user/user/flink/application_...。此步耗时取决于Jar包大小和HDFS网络带宽。5.2 步骤4-7Yarn侧的“资源审批”ApplicationSubmissionContext构建Client向Yarn ResourceManagerRM发送SubmitApplicationRequest携带ApplicationMaster启动命令、资源需求vCores、Memory、队列名-Dyarn.application.queuedefault。RM准入检查RM检查队列资源配额yarn.scheduler.capacity.root.default.maximum-capacity、用户权限、AM内存是否超限。若队列已满返回Queue default is full。Container分配与AM启动RM为AM分配首个Container通知对应NodeManagerNM启动。NM拉取HDFS上的application.zip解压并执行AM启动脚本。AM注册与心跳建立AM进程启动后向RM注册开始发送心跳默认1秒一次。RM将AM状态置为ACCEPTED等待AM申请TaskManager资源。5.3 步骤8-12Flink AM的“集群编排”JobGraph生成与优化AM加载用户Jar反射调用main()方法生成JobGraph。此时会进行算子链优化Chaining、SlotSharingGroup分配。TaskManager资源申请AM根据JobGraph的并行度向RM申请多个Container。例如并行度16每个TM 4个slot则申请4个TM Container。TM Container启动RM将申请转发给NMNM拉取相同application.zip启动TM进程。注意TM和AM共用同一份Jar包但启动类不同AM是ApplicationClusterEntryPointTM是TaskManagerRunner。TM注册与Slot报告TM启动后向AM注册报告自身可用Slot数。AM将Slot加入资源池。Job部署与Task分发AM将JobGraph拆分为ExecutionGraph为每个Task分配Slot向对应TM发送DeployTask消息。TM收到后加载Task代码启动线程执行。5.4 步骤13-17运行时的“生命维持”Checkpoint协调AM作为Checkpoint Coordinator定期向所有TM发送TriggerCheckpoint消息TM执行快照后将StateHandle状态句柄发回AM。心跳与健康检查TM每5秒向AM发送心跳AM每10秒向RM发送心跳。若AM连续3次未收到TM心跳标记TM为LOST触发Failover。日志聚合与查询Yarn的Log Aggregation功能将所有Container日志包括AM、TM汇聚到HDFS指定路径/app-logs/user/logs可通过yarn logs -applicationId id查看。Metrics上报Flink TM内置的MetricRegistry通过org.apache.flink.metrics.reporter.prom.PrometheusReporter将指标如numRecordsInPerSecond、checkpointDuration暴露为Prometheus格式供监控系统采集。优雅关闭当Job Cancel或完成AM向所有TM发送StopTaskTM清理状态、释放资源向AM报告TaskTerminatedAM最后向RM发送FinishApplicationMasterRequestRM将Application状态置为FINISHED。排查口诀当作业卡在“Accepted”状态查RM日志看AM是否注册成功卡在“Running”但无数据查TM日志看DeployTask是否收到Checkpoint失败先查AM日志的CheckpointCoordinator线程栈再查TM的RocksDBStateBackend日志。永远记住Flink的日志分散在Yarn的AM日志、TM日志、Client日志三处缺一不可。6. 生产环境避坑指南那些文档不会写的12个血泪教训这些经验来自我们支撑日均千亿事件的Flink平台每一条都对应一次线上事故。它们不在任何官方文档里却是保障SLA的生命线。6.1 教训1永远不要在flink-conf.yaml里写jobmanager.rpc.addressFlink On Yarn模式下JobManager的地址由Yarn动态分配写死jobmanager.rpc.address会导致Client无法连接。必须删除该配置让Flink Client通过Yarn的ApplicationReport自动获取AM地址。6.2 教训2HDFS权限问题比想象中更顽固Flink Checkpoint路径state.checkpoints.dir的HDFS用户必须与Yarn提交用户一致。若用hadoop用户提交但Checkpoint路径属主是flink则TM写Checkpoint时会报Permission denied。解决方案统一用yarn用户提交或在HDFS上执行hdfs dfs -chown -R yarn:yarn /flink/checkpoints。6.3 教训3Kerberos认证的“双重身份”陷阱开启Kerberos后Flink Client需kinit但Yarn NM也需要Kerberos票据才能启动Container。若NM的keytab过期Container启动失败日志只显示ExitCodeException exitCode255。必须确保所有NM节点的krb5.conf和keytab同步更新并设置yarn.nodemanager.keytab指向正确路径。6.4 教训4Flink SQL的CREATE TABLE语句必须显式指定connectorFlink SQL Client在Yarn模式下若CREATE TABLE未指定connectorkafka或connectorjdbc会默认使用filesystem导致作业提交后卡在Creating table。必须写全CREATE TABLE kafka_source ( id BIGINT, name STRING ) WITH ( connector kafka, topic input-topic, properties.bootstrap.servers kafka:9092 );6.5 教训5-D参数的优先级高于flink-conf.yaml命令行-D参数会覆盖flink-conf.yaml中的同名配置。例如flink-conf.yaml设parallelism.default: 4但提交时加-Dparallelism.default8则以8为准。调试时务必确认最终生效值用flink run-application --help查看参数优先级说明。6.6 教训6Yarn队列的“弹性配额”是假象Yarn Capacity Scheduler的maximum-capacity是软限制当队列空闲时其他队列可借用。但Flink作业启动时若队列已满即使有弹性配额RM也不会立即分配资源而是排队等待。必须为Flink专用队列设置maximum-capacity100并限制其他队列的maximum-capacity总和≤80%留出20%缓冲。6.7 教训7Flink的rest.port在Yarn模式下无效Yarn模式下Flink Web UI端口由Yarn随机分配yarn.webapp.addressrest.port配置被忽略。若需固定端口必须配置Yarn的yarn.resourcemanager.webapp.address并确保该端口在防火墙开放。6.8 教训8state.backend.rocksdb.predefined-options必须匹配硬件RocksDB预设选项如DEFAULT、SPINNING_DISK_OPTIMIZED_HIGH_MEM针对不同硬件。SSD硬盘必须用SPINNING_DISK_OPTIMIZED_HIGH_MEM否则Compaction线程数过少IO利用率不足50%。实测提升吞吐40%。6.9 教训9taskmanager.numberOfTaskSlots不是越多越好Slot数代表TM的并发Task数但每个Slot需独立内存。设-Dtaskmanager.numberOfTaskSlots8但process.size4096m则每个Slot仅512m远低于RocksDB最小需求1g导致OOM。原则Slot数 ≤ process.size / 1024。6.10 教训10Flink的log4j配置必须放在conf目录而非Jar包内Flink Client读取conf/log4j.properties若用户Jar包内有log4j.properties会被忽略。要自定义日志必须修改Flink安装目录下的conf/log4j-console.properties并重启Client。6.11 教训11yarn.provided.lib.dirs的路径必须可读Flink 1.16支持yarn.provided.lib.dirs参数指定Yarn上预置的Flink lib目录避免每次上传。但该路径必须对所有Yarn用户可读hdfs dfs -chmod -R 755 /flink/lib否则NM无法读取报NoClassDefFoundError。6.12 教训12Flink的classloader.resolve-order必须设为parent-firstYarn的ClassLoader默认child-first导致Flink加载Hadoop类时冲突。必须在flink-conf.yaml中添加classloader.resolve-order: parent-first否则会报java.lang.NoSuchMethodError: org.apache.hadoop.fs.FileSystem.createHadoop API版本不匹配。最后分享一个压箱底技巧每次上线新Flink版本务必用flink run-application -d -p 1 -Dtaskmanager.memory.process.size2048m ./test-job.jar提交一个空作业观察AM和TM日志的INFO级别输出。正常应看到Starting application master、Registered task manager、Deploying task等日志。若卡在任一环节说明环境配置有硬伤绝不能跳过这步直接上生产作业。