企业官网建设流程全解析

1. 从一次集群告警说起：为什么必须吃透Flink的架构体系

凌晨两点，监控面板上某个作业的背压指标突然飙红，Checkpoint连续失败，TaskManager的堆内存曲线像坐了火箭。如果你只停留在“会写DataStream API”的层面，面对这种场景基本只能重启大法。但如果你清楚JobManager在做什么、TaskManager的内存是怎么切的、Slot和并行度之间是什么关系，排查方向会完全不同——你能立刻判断出是资源不足、数据倾斜，还是状态后端配置不当。

这就是我坚持把Flink架构体系单独拎出来讲的原因。很多人学Flink的路径是“先跑WordCount，再学算子，最后补架构”，结果遇到生产问题就抓瞎。架构体系不是面试八股，它是你排查问题、做容量规划、调优性能的底层地图。这篇内容会围绕Flink运行时架构的核心组件、作业提交的完整链路、资源调度机制、内存模型这几个维度展开，把每个组件“为什么这样设计”讲透。适合已经能写Flink作业、但想真正搞懂它内部怎么运转的开发者，也适合正在做实时平台选型和容量评估的工程师。

我尽量不堆术语，每个概念都配上“它在实际场景里对应什么现象”的说明。读完你至少能做到：看到作业卡顿知道先看哪几个指标，做资源规划时能算出大概需要多少Slot和内存，遇到Checkpoint问题能定位到是哪个环节出了岔子。

2. Flink运行时架构的四大件：各自到底扛了什么活

2.1 JobManager：不只是“老大”这么简单

很多人把JobManager简单理解成“主节点”，这个说法没错但太粗糙。在Flink的运行时架构里，JobManager其实承担了三件截然不同的事，而且这三件事在Flink 1.11之后被拆得越来越清晰。

第一件事是作业调度。当你提交一个作业，JobManager里的Dispatcher组件负责接收，然后启动一个JobMaster。JobMaster才是真正管这个作业的角色——它把用户写的StreamGraph转换成ExecutionGraph，再根据并行度拆成一个个Task，最后决定这些Task分配到哪些TaskManager的Slot上。这里有个容易混淆的点：一个JobManager可以同时跑多个JobMaster，也就是多个作业可以共享一个JobManager进程，这在Session模式下很常见。

第二件事是资源管理。JobManager里的ResourceManager负责和外部资源平台打交道，比如Kubernetes、YARN或者Standalone集群。它手里维护着整个集群的Slot池，TaskManager启动后会向ResourceManager注册自己的Slot，ResourceManager再把这些Slot分配给提出申请的JobMaster。这个“申请-分配”的过程是异步的，所以你会看到作业启动时有个短暂的“资源等待”阶段。

第三件事是协调与元数据管理。Checkpoint的触发指令是JobManager发出的，它通过CheckpointCoordinator组件向所有Source算子注入Barrier，然后收集各Task的确认。作业的故障恢复也由它主导，比如Task失败后决定是重启整个作业还是只重启失败的Task。

实际排查经验：如果作业一直卡在“RESTARTING”状态反复重启，先看JobManager日志里是不是ResourceManager分配不到足够Slot。很多时候不是代码问题，是集群Slot总数不够，或者某个TaskManager掉线了。

2.2 TaskManager：干活的“工人”和它的Slot账本

TaskManager是真正执行Task的进程。一个TaskManager就是一个JVM进程，里面可以跑多个Task。但Task不是随便塞的，它们要被装进Slot里。Slot是TaskManager资源分配的最小单位，你可以把它理解成“工位”——每个工位有固定的内存和CPU份额。

这里有个关键设计：Slot共享（Slot Sharing）。默认情况下，Flink允许同一个作业的不同Task（比如map和keyBy之后的算子）共享同一个Slot，只要它们属于同一个Slot Sharing Group。这个设计的目的是让一个Slot里能跑完一条完整的算子链，减少数据在网络间的传输。举个例子，source -> map -> filter这条链如果并行度都是2，那它们会被打包成2个Task，每个Task占一个Slot，而不是6个Slot。

但Slot共享也带来一个坑：如果某个算子的并行度特别高，它会撑爆Slot里的内存。因为一个Slot的内存是所有共享它的Task平分的。我见过一个案例，某作业在keyBy之后做了大状态聚合，并行度设了200，但Slot只有50个，结果每个Slot里挤了4个并行实例，状态一涨就OOM。后来把并行度降到和Slot数匹配，问题就消失了。

Slot的数量怎么定？TaskManager的taskmanager.numberOfTaskSlots参数控制。Standalone模式下默认是1，生产环境一般设成CPU核数。但注意，Slot数不等于并行度上限，因为Slot可以共享。一个作业的最大并行度受限于集群总Slot数除以该作业占用的Slot Sharing Group数。

2.3 Dispatcher与JobMaster：作业提交的“前台”和“项目经理”

Dispatcher是Flink 1.11引入的组件，它的职责很单一：接收客户端提交的作业，然后为每个作业启动一个JobMaster。在Session模式下，Dispatcher是常驻的；在Per-Job模式下，Dispatcher随作业启动而创建，作业结束就销毁。

JobMaster是每个作业的“项目经理”，它持有这个作业的ExecutionGraph，负责向ResourceManager申请Slot、向TaskManager部署Task、触发Checkpoint、处理Task失败。一个JobMaster只管一个作业，作业结束后JobMaster也就结束了。

这个拆分带来的好处是隔离性。以前所有作业共享一个JobManager，一个作业把JobManager搞挂了，所有作业都遭殃。现在每个作业有自己的JobMaster，一个作业的异常不会直接影响其他作业的调度。但Dispatcher还是共享的，如果Dispatcher挂了，新作业提交不了，已运行的作业不受影响。

2.4 组件之间的通信：RPC和Actor模型

Flink内部组件之间通信用的是Akka（新版本逐步迁移到自己的RPC框架），基于Actor模型。JobManager和TaskManager之间、TaskManager和TaskManager之间都有RPC通道。数据平面（Task之间的数据传输）走的是Netty，控制平面（心跳、Checkpoint确认、状态更新）走RPC。

这个区分很重要。当你看到网络指标异常时，要分清是数据平面的吞吐问题还是控制平面的延迟问题。数据平面堵了表现为背压，控制平面堵了表现为Checkpoint超时或心跳丢失。两者的排查思路完全不同。

3. 作业提交的完整链路：从一行命令到Task跑起来

3.1 客户端生成JobGraph：优化发生在提交之前

当你在命令行敲下flink run，客户端做的第一件事是把你写的DataStream API代码转换成StreamGraph。StreamGraph是最原始的拓扑图，每个算子都是一个节点，节点之间的边表示数据流向。

然后客户端会做一轮优化，把StreamGraph转成JobGraph。这个优化最关键的一步是算子链合并（Operator Chaining）。默认情况下，Flink会把满足条件的相邻算子合并成一个Task。条件包括：并行度相同、没有数据重分区（比如keyBy会打断链）、在同一个Slot Sharing Group里。合并的好处是减少线程间切换和网络传输，map和filter这种轻量算子合并后在一个线程里顺序执行，性能提升很明显。

但有时候你需要手动打断算子链。比如某个算子特别耗CPU，你希望它单独占一个Slot，就可以用disableChaining()或者startNewChain()。我一般建议在以下场景考虑打断：算子里有同步IO、算子状态特别大、算子需要单独调优并行度。

JobGraph生成后，客户端把它提交给Dispatcher。如果是Per-Job模式，客户端还会负责启动集群（比如向YARN申请容器），然后把JobGraph交给JobManager。

3.2 JobMaster生成ExecutionGraph：并行度在这里落地

JobMaster收到JobGraph后，会把它转换成ExecutionGraph。这个转换的核心是根据并行度把每个算子展开成多个并行Task。比如一个并行度为3的map算子，在ExecutionGraph里就是3个ExecutionVertex，每个Vertex对应一个Task实例。

ExecutionGraph还负责管理Task之间的连接。如果两个算子之间是Forward连接（比如map到filter），那上游的每个并行实例只连下游对应的一个实例；如果是KeyBy连接，上游每个实例要连下游所有实例，这就是shuffle。

这个阶段还会计算Task需要的资源。每个Task需要一定数量的Slot，JobMaster会向ResourceManager申请。如果申请不到，作业就卡在“等待资源”状态。

3.3 TaskManager部署Task：Slot分配和线程启动

ResourceManager把Slot分配给JobMaster后，JobMaster会通知对应的TaskManager：“你这里有个Task要跑”。TaskManager收到通知后，在分配的Slot里启动一个线程来执行Task。

这里有个细节：一个Slot里可以跑多个Task（如果它们属于同一个Slot Sharing Group），这些Task共享Slot的内存。TaskManager会为每个Slot维护一个MemoryManager，负责管理这个Slot的内存分配。

Task启动后，会先初始化自己的状态后端（比如RocksDB），然后开始从上游拉数据或等待上游推数据。Source Task会主动拉取外部数据源，中间Task则通过Netty接收上游数据。

3.4 一个完整的提交时序：把上面几步串起来

把上面的过程串起来，一个作业从提交到运行大概是这样的：

1. 客户端生成StreamGraph，优化成JobGraph，提交给Dispatcher。
2. Dispatcher为作业启动一个JobMaster。
3. JobMaster把JobGraph转成ExecutionGraph，向ResourceManager申请Slot。
4. ResourceManager从TaskManager注册的Slot池里分配Slot，通知JobMaster。
5. JobMaster通知TaskManager部署Task。
6. TaskManager在Slot里启动Task线程，Task开始运行。
7. Task运行过程中，JobMaster持续监控，触发Checkpoint，处理故障。

这个链路里任何一环出问题，作业都起不来。我遇到过最常见的是第4步卡住——ResourceManager没有足够的Slot。这时候要看TaskManager是否都正常注册了，以及taskmanager.numberOfTaskSlots是不是设得太小。

4. 资源调度模式：Session、Per-Job、Application该怎么选

4.1 Session模式：共享集群，适合小作业快速提交

Session模式是最“传统”的方式。你先启动一个Flink集群（JobManager + 若干TaskManager），然后往这个集群里提交多个作业。所有作业共享集群资源。

优点是启动快，集群已经在那儿了，提交作业秒级响应。适合频繁提交小作业的场景，比如开发测试环境、或者作业很多但每个都很小的场景。

缺点是隔离性差。一个作业把TaskManager搞挂了，其他作业也受影响。而且资源是抢占式的，先提交的作业把Slot占满，后面的作业只能等。另外，如果JobManager挂了，所有作业都挂。

实操建议：Session模式在生产环境慎用，除非你的作业都很小且能容忍互相影响。我一般只在开发环境用Session模式，生产环境用Per-Job或Application模式。

4.2 Per-Job模式：一个作业一个集群，隔离性最好

Per-Job模式下，每个作业提交时都会启动一个独立的Flink集群（独立的JobManager和TaskManager）。作业结束后集群销毁。

优点是隔离性极好，一个作业的故障不会影响其他作业。资源也是按作业申请的，不会互相抢占。适合生产环境的大作业。

缺点是启动慢，每个作业都要等集群启动。而且如果作业很多，集群管理开销大。另外，Per-Job模式需要资源管理平台支持（比如YARN或Kubernetes），Standalone模式不支持。

4.3 Application模式：main方法在集群里执行

Application模式是Flink 1.11引入的，为了解决Per-Job模式的一些问题。在Per-Job模式下，客户端的main方法是在本地执行的，生成JobGraph后再提交。这意味着客户端需要下载所有依赖，而且如果main方法里有大量计算（比如读取配置文件、连接数据库），这些都在客户端做，可能成为瓶颈。

Application模式下，main方法直接在JobManager上执行。客户端只负责提交一个包含main方法的jar包，剩下的都在集群里完成。这样客户端压力小，而且依赖管理更简单。

缺点是main方法在JobManager上跑，如果main方法里有阻塞操作，会影响JobManager。所以main方法里不要做耗时操作，尽快生成JobGraph。

4.4 三种模式的对比与选型建议

我的选型经验是：开发环境用Session，生产环境优先Application模式。如果资源管理平台是YARN且版本较老，Per-Job也可以。Application模式在Kubernetes上尤其好用，因为main方法在集群里跑，客户端不需要配置复杂的K8s认证。

5. 内存模型：TaskManager的内存到底怎么分的

5.1 从JVM堆到Flink内存模型：为什么不能只用堆内存

早期Flink版本（1.10之前）的内存管理比较粗放，TaskManager的内存基本就是JVM堆内存。但堆内存有几个问题：一是GC压力大，尤其是状态大的作业，频繁Full GC会导致Checkpoint超时；二是堆外内存不受JVM管理，容易出现OOM但堆内存看起来还正常的情况；三是内存分配不可控，多个Task共享堆内存，一个Task内存泄漏会影响其他Task。

所以Flink 1.10之后引入了精细化的内存模型，把TaskManager的内存切成了多个独立区域，每个区域有明确的用途和配置参数。这个模型在1.11和1.12又做了调整，现在（1.13+）已经比较稳定了。

5.2 内存区域的划分：每个区域负责什么

TaskManager的总内存（taskmanager.memory.process.size）被切分成以下几块：

JVM元空间（Metaspace）：存放类的元数据，默认256MB。如果你的作业依赖很多第三方库，可能需要调大。

JVM开销（Overhead）：包括线程栈、JVM内部结构、直接内存等，默认是总内存的10%或至少192MB。这个区域容易被忽略，但设太小会导致JVM启动失败。

Flink总内存（Total Flink Memory）：这是Flink能用的内存，又进一步切分：

• 框架堆内存（Framework Heap）：Flink框架自身用的堆内存，默认128MB。
• 框架堆外内存（Framework Off-Heap）：框架用的堆外内存，默认128MB。
• 任务堆内存（Task Heap）：用户代码用的堆内存，比如你在算子里的对象分配。
• 任务堆外内存（Task Off-Heap）：用户代码用的堆外内存，比如Netty缓冲区。
• 网络内存（Network Memory）：Task之间数据传输用的缓冲区，默认是Flink总内存的10%。这个区域很关键，设太小会导致背压，设太大浪费内存。
• 托管内存（Managed Memory）：用于RocksDB状态后端、批处理算子等。默认是Flink总内存的40%。如果你用RocksDB做状态后端，这个区域要足够大。
• JVM直接内存（Direct Memory）：Netty等用的直接内存。

5.3 内存配置的实操建议：怎么算、怎么调

配置内存的第一步是确定taskmanager.memory.process.size。这个值取决于你的作业状态大小、并行度、以及TaskManager上跑多少个Slot。一个粗略的估算方法是：单个Slot的内存需求乘以Slot数，再加上JVM开销。

单个Slot的内存需求怎么估？看你的状态后端。如果用RocksDB，托管内存要够大，一般建议每个Slot至少1-2GB托管内存。如果用HashMapStateBackend（纯堆内存），任务堆内存要够大，一般每个Slot 2-4GB。

网络内存的配置有个经验值：如果作业有大量shuffle（比如keyBy之后聚合），网络内存要调大，可以设到Flink总内存的15%-20%。如果作业基本是forward连接，10%就够了。

踩坑记录：我曾经遇到一个作业Checkpoint一直超时，排查发现是托管内存设太小，RocksDB频繁flush导致IO瓶颈。后来把托管内存从2GB调到6GB，Checkpoint时间从3分钟降到20秒。所以用RocksDB的话，托管内存千万别抠。

还有一个容易忽略的点：taskmanager.memory.jvm-overhead.fraction默认是0.1，但如果你的TaskManager上跑了很多Slot，线程数会很多，线程栈开销大，这个比例可能不够。可以适当调到0.15。

6. 并行度与Slot的配合：资源规划的核心逻辑

6.1 并行度的三层设置：算子级别、执行环境级别、集群级别

Flink的并行度可以在三个地方设置，优先级从高到低：

算子级别：在代码里用map(...).setParallelism(4)直接指定。这个优先级最高，会覆盖其他设置。

执行环境级别：用env.setParallelism(4)设置，对这个环境里所有算子生效，除非算子自己覆盖。

集群级别：在flink-conf.yaml里设parallelism.default，这是默认值，如果代码里没设就用这个。

我一般建议在代码里显式设置执行环境级别的并行度，这样作业的并行度是自包含的，不依赖集群配置。算子级别的并行度只在特殊场景用，比如某个算子特别耗资源需要单独调。

6.2 Slot Sharing Group：怎么让Task合理共享Slot

默认情况下，所有算子属于同一个Slot Sharing Group（名为"default"）。这意味着一个Slot里会跑这个作业的所有算子各一个并行实例。比如并行度为4的作业，有source、map、sink三个算子，那每个Slot里跑source、map、sink各一个，总共4个Slot。

但有时候你需要把某些算子隔离出来。比如source算子要读外部系统，可能比较慢，你希望它单独占Slot，不要和其他算子抢资源。这时候可以用slotSharingGroup("source-group")把source放到单独的组里。

Slot Sharing Group的配置会影响Slot总数需求。如果作业有两个组，那Slot数至少要等于并行度乘以组数。所以不要随便创建太多组，否则Slot需求会膨胀。

6.3 一个容量规划的实例：从作业需求反推集群配置

假设你有一个作业，并行度设为10，用RocksDB做状态后端，每个并行实例的状态大约2GB。你打算用Application模式提交到Kubernetes。

第一步，算Slot需求。默认所有算子在一个Slot Sharing Group里，所以需要10个Slot。

第二步，算每个Slot的内存。状态2GB在RocksDB里，托管内存至少需要2GB（RocksDB的实际内存占用可能比状态大小多，因为还有索引和缓存）。任务堆内存给1GB，网络内存给512MB，加上框架内存和JVM开销，每个Slot大约需要4GB。

第三步，算TaskManager配置。如果每个TaskManager配4个Slot，那需要3个TaskManager（10/4向上取整）。每个TaskManager的内存是4GB乘以4个Slot，加上JVM开销，大约18GB。所以taskmanager.memory.process.size设18GB，taskmanager.numberOfTaskSlots设4。

第四步，算JobManager配置。JobManager内存一般2-4GB就够了，除非作业特别大（比如有上万个Task）。

这个估算不是精确的，但能给你一个起点。实际部署后要根据监控指标调整。如果发现GC频繁，加任务堆内存；如果Checkpoint慢，加托管内存；如果背压严重，加网络内存或提高并行度。

7. 故障恢复与Checkpoint：架构体系里的可靠性设计

7.1 Checkpoint的触发与传播：Barrier是怎么流的

Checkpoint是Flink可靠性的基石。JobMaster里的CheckpointCoordinator定期触发Checkpoint，向所有Source Task发送Barrier。Barrier是一种特殊的数据标记，会随着数据流一起往下游传播。

当Task收到所有上游的Barrier后，会先做本地状态快照（比如把RocksDB的数据刷到磁盘），然后把Barrier继续往下游发。Sink Task收到Barrier后，会通知CheckpointCoordinator“我这个分支完成了”。当所有分支都完成，CheckpointCoordinator就认为这次Checkpoint成功，把元数据持久化。

这里有个关键概念：Barrier对齐（Barrier Alignment）。如果一个Task有多个上游，它要等所有上游的Barrier都到了才能做快照。在等待期间，它会暂停处理数据（或者把后来的数据缓存起来）。这个对齐过程会导致短暂的背压，如果某个上游特别慢，对齐时间会很长，Checkpoint就超时了。

Flink 1.11引入了非对齐Checkpoint（Unaligned Checkpoint），允许Task在等待Barrier时继续处理数据，把未处理的数据也存到状态里。这样Checkpoint不会被慢上游阻塞，但状态会变大。非对齐Checkpoint适合背压严重的场景，但会增加状态大小和恢复时间。

7.2 状态后端的选择：HashMap vs RocksDB

Flink有两种主要的状态后端：

HashMapStateBackend：状态存在TaskManager的堆内存里。优点是读写快，没有序列化开销。缺点是状态大小受堆内存限制，状态大时GC压力大。适合状态小（比如几GB以内）的作业。

EmbeddedRocksDBStateBackend：状态存在RocksDB里，RocksDB是嵌入式KV存储，数据在磁盘上，内存里只有缓存。优点是状态可以很大（TB级别），GC压力小。缺点是读写有序列化开销，比堆内存慢。适合状态大的作业。

选择哪个？我的经验是：状态小于10GB且对延迟敏感，用HashMap；状态大于10GB或者状态增长不可控，用RocksDB。另外，如果用RocksDB，托管内存要配够，否则RocksDB性能会很差。

7.3 故障恢复的过程：从Task失败到作业恢复

当Task失败时，TaskManager会通知JobMaster。JobMaster根据重启策略决定是否重启。默认的重启策略是固定延迟重启，比如重启3次，每次间隔10秒。

重启时，JobMaster会从最近的Checkpoint恢复。它把Checkpoint里的状态分发给各个Task，Task从状态里恢复自己的进度，然后重新开始处理数据。Source Task会根据Checkpoint里记录的偏移量重新拉取数据，保证Exactly-Once语义。

恢复时间取决于状态大小和并行度。状态越大，从RocksDB加载状态越慢。并行度越高，需要恢复的Task越多。我见过一个状态500GB的作业，恢复花了15分钟。所以状态大的作业要考虑恢复时间，必要时用增量Checkpoint减少状态传输量。

实操心得：如果作业频繁失败重启，先看失败原因。如果是OOM，加内存或调状态后端；如果是Checkpoint超时，看是不是背压导致对齐慢，考虑非对齐Checkpoint；如果是TaskManager掉线，看是不是资源不足被K8s杀了。不要盲目加重启次数，那只是掩盖问题。

8. 架构视角下的调优切入点：知道看哪里比知道怎么调更重要

8.1 背压的定位：从Web UI到线程栈

背压是Flink作业最常见的性能问题。Web UI上每个算子都有背压指标，分为OK、LOW、HIGH三档。如果某个算子显示HIGH，说明它的下游处理不过来，数据在它这里堆积。

但Web UI只能告诉你哪个算子背压，不能告诉你为什么。要进一步定位，可以看TaskManager的线程栈。如果某个线程卡在Netty的写操作上，说明下游接收慢；如果卡在RocksDB的写操作上，说明状态写入慢；如果卡在用户代码的同步IO上，说明代码有阻塞。

我一般按这个顺序排查背压：先看是不是数据倾斜（某个并行实例处理的数据远多于其他），再看是不是下游算子有同步IO，最后看是不是资源不足（CPU或内存）。

8.2 Checkpoint调优：从超时到稳定

Checkpoint问题通常表现为超时或失败。超时的原因可能是：状态太大导致快照慢、Barrier对齐慢、网络传输慢、或者Checkpoint间隔太短。

调优方向：如果状态大，用增量Checkpoint；如果对齐慢，用非对齐Checkpoint；如果网络慢，加网络内存或减少并行度；如果间隔太短，调大Checkpoint间隔。另外，Checkpoint的超时时间（execution.checkpointing.timeout）要设合理，默认10分钟，状态大的作业可以设20-30分钟。

8.3 资源利用率的观察：Slot够不够、内存紧不紧

Slot利用率看Web UI的TaskManager页面，如果所有Slot都占满且作业还在等资源，说明Slot不够。内存利用率看TaskManager的GC指标，如果Full GC频繁（比如每分钟好几次），说明堆内存不够。

但要注意，Slot占满不一定代表资源不够。如果Slot共享配置合理，一个Slot里跑多个Task是正常的。关键看CPU和内存的实际使用率。如果CPU使用率很低但Slot占满，可能是并行度设太高，每个Task处理的数据太少。

8.4 一个真实的调优案例：从背压到稳定运行

某作业在keyBy之后做窗口聚合，窗口大小1小时，并行度50。运行一段时间后出现严重背压，Checkpoint频繁超时。

排查过程：先看Web UI，发现keyBy之后的聚合算子背压HIGH。看线程栈，发现线程卡在RocksDB的写操作上。看内存指标，托管内存使用率接近100%。判断是托管内存不足导致RocksDB写入慢。

调整方案：把托管内存从4GB调到12GB，同时把Checkpoint间隔从1分钟调到3分钟。调整后背压消失，Checkpoint稳定在30秒内完成。

这个案例说明，背压的根因可能在内存配置，而不是并行度。如果盲目加并行度，只会让更多Task抢同样的托管内存，问题更严重。

9. 写在最后：架构知识怎么用起来

我刚开始学Flink的时候，也觉得架构体系离实际开发很远。直到有一次作业在生产环境挂了，我花了两个小时才定位到是Slot Sharing Group配置导致资源死锁，从那以后我就知道架构知识不是纸上谈兵。

我的建议是：不要死记硬背组件名称和参数，而是带着问题去理解。比如你遇到Checkpoint超时，就去查CheckpointCoordinator是怎么工作的、Barrier是怎么传播的、状态后端是怎么快照的。这样学到的知识是活的，下次遇到类似问题能直接迁移。

另外，多动手改配置、看日志、观察指标。Flink的Web UI信息很丰富，但很多人只看吞吐和延迟，忽略了背压、Checkpoint、内存这些关键指标。把这些指标和架构组件对应起来，你就能从“会写作业”进阶到“会运维作业”。

最后分享一个小技巧：如果你不确定某个参数该设多少，先用默认值跑，然后根据监控指标调整。Flink的默认值对大多数场景是合理的，只有在特定场景（比如大状态、高背压）才需要调。不要一上来就抄网上的“最优配置”，那可能不适合你的场景。