Flink：流处理

为什么需要 Flink：批处理与微批无法满足低延迟

传统大数据处理以批为主，数据先落盘再定时调度计算，延迟以分钟甚至小时计。Spark Streaming 引入微批（Micro-batch）模型，把连续数据切成秒级小批次，延迟压缩到秒级，但批次边界仍会造成调度开销与延迟波动，且故障恢复粒度粗。在实时风控、交易监控、IoT 设备告警等场景，毫秒到秒级的延迟差异直接决定业务是否可用。

Flink 的解决思路是真正的逐条事件驱动：数据一到即被算子处理，不存在批次切分。它的运行时为每条消息独立调度，配合分布式快照（Checkpoint）机制，在故障时能恢复到精确一次的处理状态。与微批模型相比，Flink 延迟更低、状态一致性更强，且窗口语义（滚动、滑动、会话）比批处理更容易表达。

在同类工具中，Flink 的差异化在于「状态」是一等公民：内置 RocksDB 状态后端与增量 Checkpoint，支持 GB 到 TB 级状态；同时流批共用一套 Table API，2.0 起批作业与流作业运行在同一套 Runtime 上，代码不必为批/流分别维护。

安装与环境配置：3 步就绪

Flink 依赖 Java 8 或 Java 11 运行环境，先在目标机器确认 java -version。推荐直接下载官方二进制包，免编译免构建。

步骤一：安装。 从官网下载与当前版本匹配的二进制包并解压到 /opt。

步骤二：配置。 编辑 conf/flink-conf.yaml，设置 JobManager 内存与 TaskManager 内存；生产环境需将 jobmanager.memory.process.size 与 taskmanager.memory.process.size 按机器规格显式声明，避免默认值过小。

步骤三：验证。 本地模式启动集群并访问 Web UI 确认运行正常，或提交官方示例作业做端到端验证。

# 下载并解压（以 2.0.1 为例）wget https://archive.apache.org/dist/flink/flink-2.0.1/flink-2.0.1-bin-scala_2.12.tgztar -xzf flink-2.0.1-bin-scala_2.12.tgzcd flink-2.0.1 # 配置内存（conf/flink-conf.yaml）# jobmanager.memory.process.size: 2g# taskmanager.memory.process.size: 4g # 本地模式启动./bin/start-cluster.sh # 验证：访问 http://localhost:8081 确认 Web UI 正常# 提交官方示例作业./bin/flink run examples/streaming/SocketWindowWordCount.jar

快速上手：10 分钟跑通流式 WordCount

Flink 的最小可用流程是：创建执行环境 → 接入数据源 → 定义转换算子 → 指定输出 → 调用 execute() 提交。本地无需部署集群，直接运行 Java 主类即可看到结果。

操作步骤：

1. 用 Maven 创建项目，引入 flink-streaming-java 与 flink-clients 依赖（版本与集群一致）。

2. 编写主类：StreamExecutionEnvironment.getExecutionEnvironment() 获取环境。

3. 用 env.socketTextStream("localhost", 9000) 订阅本地 socket 端口作为无界数据源。

4. 对每行文本 flatMap 拆分单词、map 映射为 (word, 1)、keyBy 按单词分组、sum(1) 累加计数。

5. 调用 env.execute("Socket WordCount") 提交作业。

启动 nc -lk 9000 发送文本，观察控制台输出。进阶练习：将 socket 源替换为 Kafka 源（KafkaSource），并为事件时间字段声明 WatermarkStrategy，即可把作业从演示场景迁移到真实生产数据流。

import org.apache.flink.api.common.eventtime.WatermarkStrategy;import org.apache.flink.api.common.functions.FlatMapFunction;import org.apache.flink.api.java.tuple.Tuple2;import org.apache.flink.streaming.api.datastream.DataStream;import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;import org.apache.flink.util.Collector; public class SocketWordCount {    public static void main(String[] args) throws Exception {        StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();         DataStream<String> text = env.socketTextStream("localhost", 9000);         DataStream<Tuple2<String, Integer>> counts = text            .flatMap(new FlatMapFunction<String, Tuple2<String, Integer>>() {                @Override                public void flatMap(String value, Collector<Tuple2<String, Integer>> out) {                    for (String word : value.split("\\s")) {                        out.collect(Tuple2.of(word, 1));                    }                }            })            .keyBy(tuple -> tuple.f0)            .sum(1);         counts.print();        env.execute("Socket WordCount");    }}

核心能力详解：5 大支柱

支柱一：事件时间与 Watermark（乱序处理）。 事件时间（Event Time）是业务数据自带的时间戳，与数据到达系统的处理时间无关。由于网络延迟与分区不均，数据必然乱序到达，Flink 用 Watermark 标记「事件时间进度」——携带时间戳 T 的 Watermark 表示后续不再有事件时间小于 T 的数据。Watermark 由 WatermarkStrategy 生成器定期发出，窗口在 Watermark 越过窗口末尾时触发计算。此机制是 Flink 应对乱序数据的核心，但需合理设置乱序容忍度（withIdleness 处理空闲分区），否则窗口等待过久或过早触发。

支柱二：Checkpoint 与精确一次（Exactly-once）。 状态一致性是流处理与批处理最本质的差异。Flink 周期性对算子状态做分布式快照，写入外部存储（HDFS、S3），故障时从最近完成的快照整体恢复。精确一次语义依赖两阶段提交（Two-Phase Commit）：Sink 端在 Checkpoint 完成时预提交事务，所有算子快照成功后才正式提交。启用方式是在 StreamExecutionEnvironment 上调用 enableCheckpointing(interval)，并配合重启策略。注意：精确一次需要数据源（如 Kafka）与 Sink 均支持事务回放与提交，单纯的 Checkpoint 只能保证状态不丢，不能保证下游不重复。

支柱三：窗口计算。 窗口把无界流切成有限分片，Flink 内置滚动窗口（Tumbling，固定时长互不重叠）、滑动窗口（Sliding，固定步长向前移动）、会话窗口（Session，按不活跃间隙切分）。窗口可作用在事件时间或处理时间上。窗口内支持聚合（sum、count）、ProcessWindowFunction（拿到窗口内全量数据与上下文）。窗口状态会随数据量增长，需配合 allowedLateness 处理迟到数据，并对延迟数据单独分流（side output）。

支柱四：状态后端与状态管理。 算子状态分 Keyed State（按 key 隔离）与 Operator State（算子级共享）。状态存储在后端中，Flink 提供 HashMapStateBackend（内存，适合小状态）与 RocksDBStateBackend（本地磁盘 + 增量 Checkpoint，适合 GB 级以上状态）。2.0 起状态后端统一为 StateBackend 接口，配置项迁移到 state.backend.type。状态访问通过 RuntimeContext.getState() 或 KeyedProcessFunction 完成，注意 Keyed State 只能在 keyBy 之后使用。

支柱五：批流一体。 Flink 2.0 正式移除 DataSet API，批作业与流作业统一运行在 DataStream 与 Table API 之上。同一份 Table API 作业，输入有界源时按批模式执行、输入无界源时按流模式执行，语义一致。物化表（Materialized Table）将流式 ETL 封装为声明式管道，自动维护结果表与底层状态，简化实时数仓的建表与运维。

生产部署与监控：从上线到运维

部署方式一：Flink on Kubernetes。 生产环境推荐用 Flink Kubernetes Operator 管理作业生命周期。Operator 以 CRD 描述作业，支持滚动升级、Savepoint 自动恢复与资源弹性。安装后通过 kubectl apply -f job.yaml 提交作业，Operator 负责拉起 JobManager/TaskManager Pod 并暴露监控端口。

部署方式二：Flink on YARN。 已有 Hadoop 集群的团队可选 flink run -t yarn-per-job 以 per-job 模式提交。YARN 负责资源申请与容错，Flink 作业与 YARN 集群共享资源池。此模式适合 HDFS 已就绪、不打算引入 Kubernetes 的场景。

可观测性。 Flink 内置 Metrics 体系覆盖吞吐量、延迟、背压（Backpressure）、Checkpoint 耗时与次数。接入 Prometheus 需在 flink-conf.yaml 配置 metrics.reporter.prometheus，再配合 Grafana 面板查看。关键告警项：Checkpoint 失败率（flink_jobmanager_job_numberOfFailedCheckpoints）、背压时间比、TaskManager 堆内存使用率。建议对每个作业设置 Checkpoint 超时与失败容忍阈值。

<p class="para-label">避坑清单：</p>

<ul class="dash-list"><li>未配置 WatermarkStrategy 直接使用事件时间窗口：所有数据被当作迟到数据，窗口永远不触发或结果错误，必须同时声明 Watermark 与允许延迟。</li><li>Checkpoint 设置过频繁：每秒一次以上会拖垮外部存储与磁盘 IO，生产建议 30s–3min，并设置 minPauseBetweenCheckpoints 避免快照叠加。</li><li>状态后端选错：HashMapStateBackend 存 TaskManager 堆内存，状态超 1GB 即面临 OOM，大状态必须用 RocksDB 并开启增量 Checkpoint。</li><li>并行度拍脑袋设置：并行度大于 Kafka 分区数时空闲 Task 空转，小于分区数时单 Task 吞吐成为瓶颈，应按分区数与状态访问模式估算。</li><li>数据倾斜只调大并行度：keyBy 后热点 key 无法通过扩并行度缓解，需对 key 加盐打散后二次聚合，或改用 Random 分区。</li></ul>

版本迭代

Flink 的演进主线是从「流处理引擎」走向「批流一体」。1.12 统一 DataStream 与 Table API 并强化 Kubernetes 支持；1.15–1.19 逐步打磨 Checkpoint 效率、状态演进与物化表能力；至 2.0 正式移除 DataSet API，完成运行时统一，流与批在同一套 API 和 Runtime 上执行。

AI 应用场景

常见误区

面试题

参考来源

• webpageApache Flink 官网项目介绍、下载入口与最新发布公告