1. 为什么 Flink 值得花时间啃下来第一次接触 Flink 的时候我盯着那张流批一体的架构图看了整整一个下午脑子里只有一个念头这东西到底解决什么问题后来在真实项目里被 Spark Streaming 的微批延迟折磨了几周之后我才真正理解 Flink 的价值所在——它把流当作一等公民而不是把流拆成一个个小批次去模拟。Flink 的核心定位是一个分布式流处理引擎但它同时支持批处理并且能做到 Exactly-Once 语义。这意味着什么举个生活化的例子你用 Spark Streaming 处理数据就像把水管里的水先接到一个桶里攒够一定量再倒出去处理而 Flink 是直接在水管上装了一个实时过滤器水龙头一开处理逻辑立刻运转。这个差别在低延迟场景下是致命的。适合看这篇总结的人已经了解过大数据基本概念比如 Hadoop、Spark 的基本模型准备系统学习 Flink或者正在做实时计算项目选型的人。我会按照自己学习 Flink 的实际路径把核心概念、架构原理、常见踩坑点串起来讲不照搬官方文档的目录结构而是按照一个从业者真正需要理解什么来组织。注意这篇总结基于 Flink 1.17 到 1.18 版本的常见实践不同版本 API 可能有细微差异建议对照官方 release note 确认。2. Flink 架构里那几个绕不开的核心概念2.1 JobManager 与 TaskManager谁在干活谁在指挥Flink 的运行时架构是典型的 Master-Slave 模式。JobManager是大脑负责接收作业、调度任务、协调 checkpoint、处理故障恢复。TaskManager是干活的工人负责实际执行算子任务管理内存和网络缓冲。一个 Flink 集群至少有一个 JobManager 和若干个 TaskManager。JobManager 内部又分几个组件Dispatcher 负责接收客户端提交的作业并启动 JobMasterResourceManager 负责资源分配JobMaster 负责管理单个作业的执行。这个设计的好处是一个 JobManager 可以同时管理多个作业在 Session 模式下每个作业有自己的 JobMaster。TaskManager 里最关键的资源单位叫Task Slot。一个 TaskManager 可以配置多个 slot每个 slot 能跑一个算子链operator chain。这里有个容易搞混的点slot 不是 CPU 核数它更像是一个内存隔离单元。默认情况下一个 TaskManager 的多个 slot 共享 JVM 内存所以 slot 数量不等于并行度上限但会影响资源隔离程度。我踩过的一个坑在测试环境把 TaskManager 的 slot 数设成 1然后作业并行度设成 4结果作业一直卡在等待资源状态。后来才明白slot 数决定了单个 TaskManager 能同时跑多少个并行子任务slot 不够就得等新的 TaskManager 注册。2.2 算子链为什么你的作业图被合并了Flink 会把满足条件的算子合并成一个算子链Operator Chain在同一个线程里执行。这样做的好处是减少线程间切换和网络传输开销。比如source - map - filter这三个算子如果并行度相同且没有 shuffle就会被链在一起。但有时候你不想让它们链在一起。比如某个 map 算子特别耗 CPU你希望它单独占一个 slot这时候可以用disableChaining()或者startNewChain()来打断算子链。这个技巧在调优时非常有用但新手往往不知道。判断是否会被链接的条件下游算子的输入分区方式必须是 forward一对一且两个算子并行度相同且没有禁用链接。只要有一个条件不满足就会产生 shuffle算子链断开。2.3 时间语义Event Time 和 Processing Time 的本质区别这是 Flink 最核心也最容易出错的概念之一。Processing Time是数据被处理时机器的时间简单但不准确Event Time是数据本身携带的时间戳准确但需要处理乱序。为什么 Event Time 这么重要假设你在统计每小时的订单量如果用户手机信号不好订单数据延迟了 10 分钟才到用 Processing Time 就会把这条数据算到错误的时段。Event Time 配合 Watermark 机制可以容忍一定程度的乱序等迟到的数据到了再触发计算。Watermark 的本质是一个时间戳表示所有时间戳小于等于这个值的数据都已经到齐了。当 Watermark 超过窗口结束时间时窗口触发计算。这里的关键参数是out-of-orderness最大乱序程度设得太小会丢迟到数据设得太大窗口触发延迟高。// 设置 Event Time 和 Watermark 的典型写法 env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime); DataStreamEvent stream env.addSource(new KafkaSource()) .assignTimestampsAndWatermarks( WatermarkStrategy.EventforBoundedOutOfOrderness(Duration.ofSeconds(5)) .withTimestampAssigner((event, timestamp) - event.getTimestamp()) );2.4 状态与 CheckpointFlink 可靠性的基石Flink 的状态State是算子内部保存的数据比如聚合操作的中间结果。状态分为 Keyed State 和 Operator State 两类。Keyed State 只能用在 KeyedStream 上每个 key 维护一份状态Operator State 绑定在算子实例上和 key 无关。Checkpoint是 Flink 实现容错的核心机制。它定期把状态快照持久化到外部存储比如 HDFS、S3当作业失败时从最近的 checkpoint 恢复。Checkpoint 的触发由 JobManager 的 Checkpoint Coordinator 发起通过 Barrier 在数据流中传播确保所有算子在同一逻辑时间点做快照。这里有个经典问题Barrier 对齐。当算子有多个输入流时需要等所有输入流的 Barrier 都到达才能开始快照这会导致快一些的流被阻塞。如果开启CheckpointingMode.EXACTLY_ONCE就必须对齐如果改成AT_LEAST_ONCE可以跳过对齐但可能重复处理数据。这个取舍在延迟敏感场景下很关键。3. 环境搭建与第一个作业的完整跑通路径3.1 本地模式最快验证想法的方式学习阶段最推荐的方式是本地模式Local Mode不需要搭集群直接在 IDE 里跑。Maven 依赖只需要核心几个dependency groupIdorg.apache.flink/groupId artifactIdflink-streaming-java/artifactId version1.18.0/version /dependency dependency groupIdorg.apache.flink/groupId artifactIdflink-clients/artifactId version1.18.0/version /dependency写一个 WordCount 是经典入门public class WordCount { public static void main(String[] args) throws Exception { StreamExecutionEnvironment env StreamExecutionEnvironment.getExecutionEnvironment(); DataStreamString text env.socketTextStream(localhost, 9999); DataStreamTuple2String, Integer counts text .flatMap(new Tokenizer()) .keyBy(value - value.f0) .sum(1); counts.print(); env.execute(WordCount); } }跑之前先在终端开一个nc -lk 9999然后输入单词控制台就能看到实时计数。这个流程走通说明环境没问题。3.2 集群模式Standalone 与 YARN 的选型逻辑生产环境一般用 Standalone 或 YARN/K8s 模式。Standalone 适合固定规模的集群部署简单但资源利用率低YARN 模式能动态申请资源适合和 Hadoop 生态共存的场景。Standalone 部署步骤下载二进制包解压修改conf/flink-conf.yaml里的jobmanager.rpc.address指向 master 节点把masters和workers文件配好然后bin/start-cluster.sh启动。Web UI 默认在 8081 端口。YARN 模式提交作业的命令./bin/flink run -m yarn-cluster \ -yn 2 -ys 2 -yjm 1024 -ytm 2048 \ ./my-job.jar参数含义-yn是 TaskManager 数量-ys是每个 TaskManager 的 slot 数-yjm和-ytm分别是 JobManager 和 TaskManager 的内存MB。这些参数要根据数据量和算子复杂度来调不是越大越好。3.3 并行度设置的三个层级Flink 的并行度可以在三个地方设置优先级从高到低算子级别 环境级别 集群配置级别。算子级别map(...).setParallelism(4)环境级别env.setParallelism(4)集群配置parallelism.default: 4在 flink-conf.yaml 里实际项目中source 和 sink 的并行度往往受外部系统限制。比如 Kafka 一个分区只能被一个消费者读所以 source 并行度不应该超过分区数。而中间算子的并行度可以设大一些充分利用 CPU。提示并行度不是越大越好。每个并行子任务都有状态和网络缓冲开销并行度过高会导致 checkpoint 变大、恢复变慢。一般建议单个并行子任务处理的数据量在几十 MB/s 到几百 MB/s 之间。4. 窗口、时间与状态三个最容易翻车的地方4.1 窗口类型的选择逻辑Flink 的窗口分四大类滚动窗口Tumbling、滑动窗口Sliding、会话窗口Session、全局窗口Global。选哪种取决于业务语义。滚动窗口是固定大小、不重叠的比如每 5 分钟统计一次。滑动窗口有固定大小和滑动步长可以重叠比如每 1 分钟统计过去 5 分钟的数据。会话窗口按活动间隙切分适合用户行为分析。全局窗口需要自定义 Trigger否则永远不会触发。// 滚动窗口每5分钟统计一次 stream.keyBy(...).window(TumblingEventTimeWindows.of(Time.minutes(5))).sum(...); // 滑动窗口每1分钟统计过去5分钟 stream.keyBy(...).window(SlidingEventTimeWindows.of(Time.minutes(5), Time.minutes(1))).sum(...);一个常见误区以为窗口大小就是处理延迟。实际上窗口触发还要等 Watermark 超过窗口结束时间所以实际延迟 窗口大小 乱序容忍时间 处理时间。4.2 迟到数据的三种处理策略即使设了 Watermark还是可能有数据迟到时间戳小于当前 Watermark。Flink 提供三种策略丢弃默认行为迟到数据直接扔掉。allowedLateness允许窗口在触发后再保留一段时间迟到数据还能触发更新。sideOutputLateData把迟到数据输出到侧流单独处理。OutputTagEvent lateTag new OutputTagEvent(late){}; SingleOutputStreamOperatorResult result stream .keyBy(...) .window(TumblingEventTimeWindows.of(Time.minutes(5))) .allowedLateness(Time.minutes(1)) .sideOutputLateData(lateTag) .process(new MyProcessFunction()); DataStreamEvent lateStream result.getSideOutput(lateTag);我的经验是allowedLateness 不要设太大否则窗口状态一直不释放内存压力大。一般设成业务能接受的最大延迟即可。侧流输出适合做监控告警看看有多少数据迟到。4.3 状态后端与 Checkpoint 存储的搭配Flink 的状态后端State Backend决定状态存在哪、怎么存。常见的有三种状态后端存储位置适用场景HashMapStateBackendJVM 堆内存状态小、对延迟敏感EmbeddedRocksDBStateBackendRocksDB本地磁盘状态大、超出内存组合使用堆内存 RocksDB混合场景Checkpoint 存储位置一般选 HDFS 或 S3要保证所有节点都能访问。Checkpoint 间隔的设置是个权衡间隔短恢复快但开销大间隔长开销小但恢复慢。一般建议 1 到 5 分钟。env.setStateBackend(new EmbeddedRocksDBStateBackend()); env.getCheckpointConfig().setCheckpointStorage(hdfs:///flink/checkpoints); env.getCheckpointConfig().setCheckpointInterval(60000); // 1分钟 env.getCheckpointConfig().setMinPauseBetweenCheckpoints(30000); // 两次checkpoint最小间隔 env.getCheckpointConfig().setCheckpointTimeout(300000); // 超时时间 env.getCheckpointConfig().setMaxConcurrentCheckpoints(1); // 同时只允许一个注意RocksDB 状态后端虽然能存大状态但读写有序列化开销延迟比堆内存高。如果状态不大优先用 HashMapStateBackend。5. 反压、数据倾斜与性能调优的实战判断5.1 反压的定位与解决思路反压Backpressure是 Flink 作业最常见的性能问题。本质是下游处理速度跟不上上游生产速度导致上游被阻塞。Flink 的 Web UI 里算子框会变红表示反压严重。定位反压的步骤先看 Web UI 哪个算子反压然后看该算子的 subTask 是否均匀。如果某个 subTask 特别慢可能是数据倾斜如果所有 subTask 都慢可能是算子逻辑太重或资源不足。解决反压的常见手段增加并行度如果是资源瓶颈优化算子逻辑减少同步阻塞、避免在算子里做重 IO调整网络缓冲taskmanager.network.memory.fraction使用异步 IO 访问外部系统我遇到过一个案例作业在 map 算子调用了外部 HTTP 接口同步等待导致吞吐上不去。改成 AsyncDataStream 后吞吐提升了近 10 倍。5.2 数据倾斜的识别与打散数据倾斜是 keyBy 之后某些 key 的数据量远大于其他 key。表现是某个 subTask 的 records 数远超其他。解决方法加盐打散给 key 加随机前缀先聚合再二次聚合。自定义分区实现 Partitioner 接口手动控制数据分布。两阶段聚合先局部聚合再全局聚合。// 加盐示例给key加随机前缀 DataStreamTuple2String, Integer salted stream .map(value - Tuple2.of(value.f0 - new Random().nextInt(10), value.f1)) .returns(Types.TUPLE(Types.STRING, Types.INT)); // 第一次聚合后去掉前缀再聚合5.3 内存配置的关键参数Flink 的内存模型分几块Framework Heap、Task Heap、Managed Memory、Network Memory。最容易出问题的是 Managed Memory 和 Network Memory。taskmanager.memory.managed.fractionRocksDB 用的内存比例默认 0.4。taskmanager.memory.network.fraction网络缓冲比例默认 0.1。taskmanager.memory.process.size整个 TaskManager 进程的内存。如果作业频繁 Full GC可能是 Task Heap 太小如果反压严重且网络指标高可能是 Network Memory 不够。调优时先用jmap和 Flink 的 Metrics 确认瓶颈在哪再针对性调整。6. 从学习到落地我踩过的几个真实坑6.1 Checkpoint 一直失败不是配置问题是数据量问题有次作业 checkpoint 一直超时查了半天配置没问题。后来发现是某个算子的状态太大几十 GB每次快照都要写很久。解决方案是换 RocksDB 状态后端并开启增量 checkpoint。增量 checkpoint 只上传变化的部分能大幅减少快照时间。EmbeddedRocksDBStateBackend backend new EmbeddedRocksDBStateBackend(true); // true开启增量 env.setStateBackend(backend);6.2 时间语义搞混导致结果对不上早期做实时统计时我用了 Processing Time结果发现数据对不上离线报表。原因是数据从产生到被处理有延迟Processing Time 把不同时段的数据混在一起了。改成 Event Time 后结果和离线一致。这个教训是只要业务关心数据本身的时间就必须用 Event Time。6.3 并行度改了但没生效有次在代码里设了env.setParallelism(4)但提交到集群后还是按集群默认并行度跑。原因是提交命令里用了-p参数覆盖了代码设置。优先级是命令行 代码 集群配置。所以调并行度时要确认没有命令行参数干扰。6.4 状态没清理导致内存泄漏用了allowedLateness之后窗口状态会保留到 allowedLateness 过期。如果 allowedLateness 设得很大状态一直不释放最终 OOM。解决方法是合理设置 allowedLateness并定期监控状态大小。另外Keyed State 如果 key 一直增加比如用户 ID也需要设置 State TTL。StateTtlConfig ttlConfig StateTtlConfig .newBuilder(Time.days(7)) .setUpdateType(StateTtlConfig.UpdateType.OnCreateAndWrite) .setStateVisibility(StateTtlConfig.StateVisibility.NeverReturnExpired) .build(); valueStateDescriptor.enableTimeToLive(ttlConfig);7. 后续深入的方向建议把上面这些跑通之后基本能应付大部分实时计算场景了。再往下深入可以看几个方向Flink SQL 和 Table API写 SQL 就能做流处理开发效率高很多、Flink CDC直接对接数据库变更日志、Flink on K8s云原生部署。每个方向都够写一篇长文这里就不展开了。我个人在实际操作中的体会是Flink 的学习曲线前期陡主要是概念多、配置杂但一旦把状态、时间、窗口这三个核心搞透剩下的都是组合应用。遇到问题先看 Web UI 的指标再查日志最后才怀疑配置。大部分问题都能从反压和 checkpoint 这两个入口找到线索。 
长河君 · 2026/10/19 8:07:46 · 阅读 1.2k Flink 流处理实战：核心概念、架构原理与性能调优指南
1. 为什么 Flink 值得花时间啃下来第一次接触 Flink 的时候我盯着那张流批一体的架构图看了整整一个下午脑子里只有一个念头这东西到底解决什么问题后来在真实项目里被 Spark Streaming 的微批延迟折磨了几周之后我才真正理解 Flink 的价值所在——它把流当作一等公民而不是把流拆成一个个小批次去模拟。Flink 的核心定位是一个分布式流处理引擎但它同时支持批处理并且能做到 Exactly-Once 语义。这意味着什么举个生活化的例子你用 Spark Streaming 处理数据就像把水管里的水先接到一个桶里攒够一定量再倒出去处理而 Flink 是直接在水管上装了一个实时过滤器水龙头一开处理逻辑立刻运转。这个差别在低延迟场景下是致命的。适合看这篇总结的人已经了解过大数据基本概念比如 Hadoop、Spark 的基本模型准备系统学习 Flink或者正在做实时计算项目选型的人。我会按照自己学习 Flink 的实际路径把核心概念、架构原理、常见踩坑点串起来讲不照搬官方文档的目录结构而是按照一个从业者真正需要理解什么来组织。注意这篇总结基于 Flink 1.17 到 1.18 版本的常见实践不同版本 API 可能有细微差异建议对照官方 release note 确认。2. Flink 架构里那几个绕不开的核心概念2.1 JobManager 与 TaskManager谁在干活谁在指挥Flink 的运行时架构是典型的 Master-Slave 模式。JobManager是大脑负责接收作业、调度任务、协调 checkpoint、处理故障恢复。TaskManager是干活的工人负责实际执行算子任务管理内存和网络缓冲。一个 Flink 集群至少有一个 JobManager 和若干个 TaskManager。JobManager 内部又分几个组件Dispatcher 负责接收客户端提交的作业并启动 JobMasterResourceManager 负责资源分配JobMaster 负责管理单个作业的执行。这个设计的好处是一个 JobManager 可以同时管理多个作业在 Session 模式下每个作业有自己的 JobMaster。TaskManager 里最关键的资源单位叫Task Slot。一个 TaskManager 可以配置多个 slot每个 slot 能跑一个算子链operator chain。这里有个容易搞混的点slot 不是 CPU 核数它更像是一个内存隔离单元。默认情况下一个 TaskManager 的多个 slot 共享 JVM 内存所以 slot 数量不等于并行度上限但会影响资源隔离程度。我踩过的一个坑在测试环境把 TaskManager 的 slot 数设成 1然后作业并行度设成 4结果作业一直卡在等待资源状态。后来才明白slot 数决定了单个 TaskManager 能同时跑多少个并行子任务slot 不够就得等新的 TaskManager 注册。2.2 算子链为什么你的作业图被合并了Flink 会把满足条件的算子合并成一个算子链Operator Chain在同一个线程里执行。这样做的好处是减少线程间切换和网络传输开销。比如source - map - filter这三个算子如果并行度相同且没有 shuffle就会被链在一起。但有时候你不想让它们链在一起。比如某个 map 算子特别耗 CPU你希望它单独占一个 slot这时候可以用disableChaining()或者startNewChain()来打断算子链。这个技巧在调优时非常有用但新手往往不知道。判断是否会被链接的条件下游算子的输入分区方式必须是 forward一对一且两个算子并行度相同且没有禁用链接。只要有一个条件不满足就会产生 shuffle算子链断开。2.3 时间语义Event Time 和 Processing Time 的本质区别这是 Flink 最核心也最容易出错的概念之一。Processing Time是数据被处理时机器的时间简单但不准确Event Time是数据本身携带的时间戳准确但需要处理乱序。为什么 Event Time 这么重要假设你在统计每小时的订单量如果用户手机信号不好订单数据延迟了 10 分钟才到用 Processing Time 就会把这条数据算到错误的时段。Event Time 配合 Watermark 机制可以容忍一定程度的乱序等迟到的数据到了再触发计算。Watermark 的本质是一个时间戳表示所有时间戳小于等于这个值的数据都已经到齐了。当 Watermark 超过窗口结束时间时窗口触发计算。这里的关键参数是out-of-orderness最大乱序程度设得太小会丢迟到数据设得太大窗口触发延迟高。// 设置 Event Time 和 Watermark 的典型写法 env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime); DataStreamEvent stream env.addSource(new KafkaSource()) .assignTimestampsAndWatermarks( WatermarkStrategy.EventforBoundedOutOfOrderness(Duration.ofSeconds(5)) .withTimestampAssigner((event, timestamp) - event.getTimestamp()) );2.4 状态与 CheckpointFlink 可靠性的基石Flink 的状态State是算子内部保存的数据比如聚合操作的中间结果。状态分为 Keyed State 和 Operator State 两类。Keyed State 只能用在 KeyedStream 上每个 key 维护一份状态Operator State 绑定在算子实例上和 key 无关。Checkpoint是 Flink 实现容错的核心机制。它定期把状态快照持久化到外部存储比如 HDFS、S3当作业失败时从最近的 checkpoint 恢复。Checkpoint 的触发由 JobManager 的 Checkpoint Coordinator 发起通过 Barrier 在数据流中传播确保所有算子在同一逻辑时间点做快照。这里有个经典问题Barrier 对齐。当算子有多个输入流时需要等所有输入流的 Barrier 都到达才能开始快照这会导致快一些的流被阻塞。如果开启CheckpointingMode.EXACTLY_ONCE就必须对齐如果改成AT_LEAST_ONCE可以跳过对齐但可能重复处理数据。这个取舍在延迟敏感场景下很关键。3. 环境搭建与第一个作业的完整跑通路径3.1 本地模式最快验证想法的方式学习阶段最推荐的方式是本地模式Local Mode不需要搭集群直接在 IDE 里跑。Maven 依赖只需要核心几个dependency groupIdorg.apache.flink/groupId artifactIdflink-streaming-java/artifactId version1.18.0/version /dependency dependency groupIdorg.apache.flink/groupId artifactIdflink-clients/artifactId version1.18.0/version /dependency写一个 WordCount 是经典入门public class WordCount { public static void main(String[] args) throws Exception { StreamExecutionEnvironment env StreamExecutionEnvironment.getExecutionEnvironment(); DataStreamString text env.socketTextStream(localhost, 9999); DataStreamTuple2String, Integer counts text .flatMap(new Tokenizer()) .keyBy(value - value.f0) .sum(1); counts.print(); env.execute(WordCount); } }跑之前先在终端开一个nc -lk 9999然后输入单词控制台就能看到实时计数。这个流程走通说明环境没问题。3.2 集群模式Standalone 与 YARN 的选型逻辑生产环境一般用 Standalone 或 YARN/K8s 模式。Standalone 适合固定规模的集群部署简单但资源利用率低YARN 模式能动态申请资源适合和 Hadoop 生态共存的场景。Standalone 部署步骤下载二进制包解压修改conf/flink-conf.yaml里的jobmanager.rpc.address指向 master 节点把masters和workers文件配好然后bin/start-cluster.sh启动。Web UI 默认在 8081 端口。YARN 模式提交作业的命令./bin/flink run -m yarn-cluster \ -yn 2 -ys 2 -yjm 1024 -ytm 2048 \ ./my-job.jar参数含义-yn是 TaskManager 数量-ys是每个 TaskManager 的 slot 数-yjm和-ytm分别是 JobManager 和 TaskManager 的内存MB。这些参数要根据数据量和算子复杂度来调不是越大越好。3.3 并行度设置的三个层级Flink 的并行度可以在三个地方设置优先级从高到低算子级别 环境级别 集群配置级别。算子级别map(...).setParallelism(4)环境级别env.setParallelism(4)集群配置parallelism.default: 4在 flink-conf.yaml 里实际项目中source 和 sink 的并行度往往受外部系统限制。比如 Kafka 一个分区只能被一个消费者读所以 source 并行度不应该超过分区数。而中间算子的并行度可以设大一些充分利用 CPU。提示并行度不是越大越好。每个并行子任务都有状态和网络缓冲开销并行度过高会导致 checkpoint 变大、恢复变慢。一般建议单个并行子任务处理的数据量在几十 MB/s 到几百 MB/s 之间。4. 窗口、时间与状态三个最容易翻车的地方4.1 窗口类型的选择逻辑Flink 的窗口分四大类滚动窗口Tumbling、滑动窗口Sliding、会话窗口Session、全局窗口Global。选哪种取决于业务语义。滚动窗口是固定大小、不重叠的比如每 5 分钟统计一次。滑动窗口有固定大小和滑动步长可以重叠比如每 1 分钟统计过去 5 分钟的数据。会话窗口按活动间隙切分适合用户行为分析。全局窗口需要自定义 Trigger否则永远不会触发。// 滚动窗口每5分钟统计一次 stream.keyBy(...).window(TumblingEventTimeWindows.of(Time.minutes(5))).sum(...); // 滑动窗口每1分钟统计过去5分钟 stream.keyBy(...).window(SlidingEventTimeWindows.of(Time.minutes(5), Time.minutes(1))).sum(...);一个常见误区以为窗口大小就是处理延迟。实际上窗口触发还要等 Watermark 超过窗口结束时间所以实际延迟 窗口大小 乱序容忍时间 处理时间。4.2 迟到数据的三种处理策略即使设了 Watermark还是可能有数据迟到时间戳小于当前 Watermark。Flink 提供三种策略丢弃默认行为迟到数据直接扔掉。allowedLateness允许窗口在触发后再保留一段时间迟到数据还能触发更新。sideOutputLateData把迟到数据输出到侧流单独处理。OutputTagEvent lateTag new OutputTagEvent(late){}; SingleOutputStreamOperatorResult result stream .keyBy(...) .window(TumblingEventTimeWindows.of(Time.minutes(5))) .allowedLateness(Time.minutes(1)) .sideOutputLateData(lateTag) .process(new MyProcessFunction()); DataStreamEvent lateStream result.getSideOutput(lateTag);我的经验是allowedLateness 不要设太大否则窗口状态一直不释放内存压力大。一般设成业务能接受的最大延迟即可。侧流输出适合做监控告警看看有多少数据迟到。4.3 状态后端与 Checkpoint 存储的搭配Flink 的状态后端State Backend决定状态存在哪、怎么存。常见的有三种状态后端存储位置适用场景HashMapStateBackendJVM 堆内存状态小、对延迟敏感EmbeddedRocksDBStateBackendRocksDB本地磁盘状态大、超出内存组合使用堆内存 RocksDB混合场景Checkpoint 存储位置一般选 HDFS 或 S3要保证所有节点都能访问。Checkpoint 间隔的设置是个权衡间隔短恢复快但开销大间隔长开销小但恢复慢。一般建议 1 到 5 分钟。env.setStateBackend(new EmbeddedRocksDBStateBackend()); env.getCheckpointConfig().setCheckpointStorage(hdfs:///flink/checkpoints); env.getCheckpointConfig().setCheckpointInterval(60000); // 1分钟 env.getCheckpointConfig().setMinPauseBetweenCheckpoints(30000); // 两次checkpoint最小间隔 env.getCheckpointConfig().setCheckpointTimeout(300000); // 超时时间 env.getCheckpointConfig().setMaxConcurrentCheckpoints(1); // 同时只允许一个注意RocksDB 状态后端虽然能存大状态但读写有序列化开销延迟比堆内存高。如果状态不大优先用 HashMapStateBackend。5. 反压、数据倾斜与性能调优的实战判断5.1 反压的定位与解决思路反压Backpressure是 Flink 作业最常见的性能问题。本质是下游处理速度跟不上上游生产速度导致上游被阻塞。Flink 的 Web UI 里算子框会变红表示反压严重。定位反压的步骤先看 Web UI 哪个算子反压然后看该算子的 subTask 是否均匀。如果某个 subTask 特别慢可能是数据倾斜如果所有 subTask 都慢可能是算子逻辑太重或资源不足。解决反压的常见手段增加并行度如果是资源瓶颈优化算子逻辑减少同步阻塞、避免在算子里做重 IO调整网络缓冲taskmanager.network.memory.fraction使用异步 IO 访问外部系统我遇到过一个案例作业在 map 算子调用了外部 HTTP 接口同步等待导致吞吐上不去。改成 AsyncDataStream 后吞吐提升了近 10 倍。5.2 数据倾斜的识别与打散数据倾斜是 keyBy 之后某些 key 的数据量远大于其他 key。表现是某个 subTask 的 records 数远超其他。解决方法加盐打散给 key 加随机前缀先聚合再二次聚合。自定义分区实现 Partitioner 接口手动控制数据分布。两阶段聚合先局部聚合再全局聚合。// 加盐示例给key加随机前缀 DataStreamTuple2String, Integer salted stream .map(value - Tuple2.of(value.f0 - new Random().nextInt(10), value.f1)) .returns(Types.TUPLE(Types.STRING, Types.INT)); // 第一次聚合后去掉前缀再聚合5.3 内存配置的关键参数Flink 的内存模型分几块Framework Heap、Task Heap、Managed Memory、Network Memory。最容易出问题的是 Managed Memory 和 Network Memory。taskmanager.memory.managed.fractionRocksDB 用的内存比例默认 0.4。taskmanager.memory.network.fraction网络缓冲比例默认 0.1。taskmanager.memory.process.size整个 TaskManager 进程的内存。如果作业频繁 Full GC可能是 Task Heap 太小如果反压严重且网络指标高可能是 Network Memory 不够。调优时先用jmap和 Flink 的 Metrics 确认瓶颈在哪再针对性调整。6. 从学习到落地我踩过的几个真实坑6.1 Checkpoint 一直失败不是配置问题是数据量问题有次作业 checkpoint 一直超时查了半天配置没问题。后来发现是某个算子的状态太大几十 GB每次快照都要写很久。解决方案是换 RocksDB 状态后端并开启增量 checkpoint。增量 checkpoint 只上传变化的部分能大幅减少快照时间。EmbeddedRocksDBStateBackend backend new EmbeddedRocksDBStateBackend(true); // true开启增量 env.setStateBackend(backend);6.2 时间语义搞混导致结果对不上早期做实时统计时我用了 Processing Time结果发现数据对不上离线报表。原因是数据从产生到被处理有延迟Processing Time 把不同时段的数据混在一起了。改成 Event Time 后结果和离线一致。这个教训是只要业务关心数据本身的时间就必须用 Event Time。6.3 并行度改了但没生效有次在代码里设了env.setParallelism(4)但提交到集群后还是按集群默认并行度跑。原因是提交命令里用了-p参数覆盖了代码设置。优先级是命令行 代码 集群配置。所以调并行度时要确认没有命令行参数干扰。6.4 状态没清理导致内存泄漏用了allowedLateness之后窗口状态会保留到 allowedLateness 过期。如果 allowedLateness 设得很大状态一直不释放最终 OOM。解决方法是合理设置 allowedLateness并定期监控状态大小。另外Keyed State 如果 key 一直增加比如用户 ID也需要设置 State TTL。StateTtlConfig ttlConfig StateTtlConfig .newBuilder(Time.days(7)) .setUpdateType(StateTtlConfig.UpdateType.OnCreateAndWrite) .setStateVisibility(StateTtlConfig.StateVisibility.NeverReturnExpired) .build(); valueStateDescriptor.enableTimeToLive(ttlConfig);7. 后续深入的方向建议把上面这些跑通之后基本能应付大部分实时计算场景了。再往下深入可以看几个方向Flink SQL 和 Table API写 SQL 就能做流处理开发效率高很多、Flink CDC直接对接数据库变更日志、Flink on K8s云原生部署。每个方向都够写一篇长文这里就不展开了。我个人在实际操作中的体会是Flink 的学习曲线前期陡主要是概念多、配置杂但一旦把状态、时间、窗口这三个核心搞透剩下的都是组合应用。遇到问题先看 Web UI 的指标再查日志最后才怀疑配置。大部分问题都能从反压和 checkpoint 这两个入口找到线索。