2. 核心概念：数据流、算子、窗口、水位线、状态后端、检查点

说实话，刚接触流处理的人，最容易被一堆术语砸晕。什么数据流、算子、窗口、水位线……听着都像那么回事，但真要上手调优，就发现哪哪都对不上。我当年带团队做第一个实时数仓项目时，就吃过这个亏——代码写完了，跑起来总丢数据，查了三天才发现是水位线设错了。

这一章，咱们就把这些核心概念掰开揉碎。不搞玄学，只讲实战。

2.1 数据流：一切的基础

数据流，说白了就是源源不断的事件序列。你想想看，用户点击、传感器读数、交易记录……这些事件按时间顺序排成一列，就是数据流。

流处理里，数据流有两种形态：

  • 有界流：数据有头有尾，比如处理一个固定文件。批处理其实可以看作有界流的特例。
  • 无界流：数据永远不结束，比如实时日志。这才是流处理的真正战场。

我的经验：很多新手把无界流想得太复杂。其实你只要记住——永远不要假设数据会停。写代码时，所有逻辑都要按“数据可能永远不来，也可能突然爆发”来设计。

2.2 算子：处理逻辑的原子单元

算子就是流处理里的“操作符”。每个算子干一件事，多个算子串起来就形成处理拓扑。

常见的算子类型：

算子类型 作用 典型场景
Map 一对一转换 字段清洗、格式转换
Filter 过滤不符合条件的数据 剔除脏数据、白名单过滤
KeyBy 按key分组 按用户ID、设备ID分流
Window 将无界流切分成有限段 每5分钟统计一次PV
Join 关联两个流 订单流+支付流关联

算子之间通过数据管道连接。我习惯把算子链想象成工厂流水线——每个工位只干一件事，但组合起来就能完成复杂加工。

避坑指南：我曾经在项目里把十几个算子串成一条长链，结果性能惨不忍睹。后来发现，算子链太长会导致反压传播慢、故障恢复慢。建议关键节点之间做一次rebalance或rescale，打断长链。

2.3 窗口：把无界流切成有限段

无界流永远不结束，但计算必须有个边界。窗口就是干这个的——把无限的数据流，按时间或数量切成有限的小段。

窗口类型主要有三种：

  • 滚动窗口（Tumbling Window）：固定大小，不重叠。比如每5分钟一个窗口。
  • 滑动窗口（Sliding Window）：固定大小，但会重叠。比如窗口长度10分钟，每5分钟滑动一次。
  • 会话窗口（Session Window）：按活动间隙切分。用户连续操作算一个会话，空闲超过阈值就切下一个。

选哪种窗口，取决于业务场景。我举个例子：

// 滚动窗口：每5分钟统计一次
dataStream
    .keyBy(event -> event.getUserId())
    .window(TumblingEventTimeWindows.of(Time.minutes(5)))
    .aggregate(new MyAggregateFunction());

// 滑动窗口：每1分钟统计过去5分钟的数据
dataStream
    .keyBy(event -> event.getUserId())
    .window(SlidingEventTimeWindows.of(Time.minutes(5), Time.minutes(1)))
    .aggregate(new MyAggregateFunction());

注意：滑动窗口会产生大量重叠数据，内存开销是滚动窗口的数倍。我见过有人用1秒滑动、1小时窗口做实时大屏，结果集群直接OOM。如果业务允许，优先用滚动窗口。

2.4 水位线（Watermark）：解决乱序问题的关键

水位线是流处理里最容易被误解的概念。很多人觉得它就是个时间戳，其实不然。

水位线的本质是“进度信号”。它告诉系统：到这个时间点为止，该来的数据基本都来了，可以触发计算了。

为什么需要水位线？因为数据会乱序。比如：

  • 事件A发生在10:00:00，但网络延迟，10:00:05才到
  • 事件B发生在10:00:03，反而10:00:02就到了

如果没有水位线，系统按处理时间触发窗口，就会把A算到上一个窗口里，导致结果错误。

水位线的设置策略：

策略 说明 适用场景
固定延迟 水位线 = 最大事件时间 - 固定时长 网络延迟相对稳定
周期性生成 每隔N毫秒生成一次水位线 通用场景，默认策略
自定义策略 根据业务特征动态计算 延迟波动大，需要精细控制

我的经验：水位线设得太小，会丢数据；设得太大，窗口迟迟不触发，延迟高。我一般建议先按业务容忍的最大延迟来设，比如业务能接受30秒延迟，水位线就设30秒。上线后观察丢数据率，再逐步调小。

2.5 状态后端：状态数据的存储引擎

流处理里，很多算子需要记住历史数据。比如做去重，你得知道哪些用户ID已经来过了。这些“记住的数据”就是状态。

状态后端就是管理这些状态的存储引擎。Flink支持三种：

  • MemoryStateBackend：状态存在JVM堆内存里。快，但容量有限，且故障会丢数据。
  • FsStateBackend：状态存在TaskManager内存，检查点存到文件系统。平衡了性能和可靠性。
  • RocksDBStateBackend：状态存在本地RocksDB（磁盘），检查点存到文件系统。支持超大状态。

怎么选？我有个简单判断：

if (状态大小 < 1GB && 可以接受少量数据丢失) {
    用 MemoryStateBackend
} else if (状态大小 < 50GB) {
    用 FsStateBackend
} else {
    用 RocksDBStateBackend
}

避坑指南：我曾经在一个项目里用RocksDB，但没调优，结果读写性能比内存慢了一个数量级。后来加了RocksDB的列族压缩和缓存配置，性能才上来。记住：RocksDB不是银弹，需要针对你的访问模式做调优。

2.6 检查点（Checkpoint）：流处理的“存档”机制

检查点就是流处理的全局快照。它把算子的状态和数据源的位置一起保存下来。一旦任务失败，就从最近的检查点恢复，保证精确一次（Exactly-Once）语义。

检查点的工作原理：

  1. JobManager发起：向所有Source算子发送“开始检查点”的指令
  2. Source算子保存偏移量：比如Kafka的消费位置
  3. Barrier传播：检查点屏障（Barrier）随数据流一起传递
  4. 算子保存状态：每个算子收到Barrier后，把当前状态快照保存到状态后端
  5. 确认完成：所有算子完成快照后，JobManager标记检查点完成

检查点的关键配置：

参数 说明 建议值
checkpointInterval 检查点间隔 30秒~5分钟，视状态大小而定
checkpointTimeout 超时时间 一般为间隔的2~3倍
minPauseBetweenCheckpoints 最小间隔 防止检查点过于密集
maxConcurrentCheckpoints 最大并发数 通常设为1，避免资源竞争

注意：检查点不是免费的。每次检查点都会暂停数据处理一小段时间（Stop-the-World）。如果状态很大，暂停时间可能长达数秒。我建议监控检查点耗时，如果超过1秒，就要考虑优化状态后端或调整检查点策略。

2.7 核心概念关系图

说了这么多，这些概念到底怎么串起来的？我画了张图，你看一眼就明白了：

流处理核心概念关系图 数据流 算子 窗口 水位线 状态后端 检查点 核心流程： 数据流 → 算子（处理逻辑）→ 窗口（切分数据）→ 水位线（控制触发时机） 状态后端（存储中间结果）→ 检查点（全局快照，保证容错） 这六个概念共同构成了流处理引擎的完整工作闭环。

这张图把六个核心概念串成了一个闭环。你想想看：数据流进来，经过算子处理，窗口负责切分，水位线决定什么时候触发计算，状态后端保存中间结果，检查点保证整个流程的可靠性。缺一个，系统就跑不稳。

← 上一章 📖 返回目录 下一章 →