Flink 流处理

• 两阶段提交（2PC）原理
• Flink 的 TwoPhaseCommitSinkFunction
• 与 Kafka 事务（transactional producer）配合

Flink 通过"两阶段提交（2PC）"实现端到端 Exactly-Once，核心是 TwoPhaseCommitSinkFunction。它把每个 checkpoint 的提交分成两阶段：预提交（pre-commit）与提交（commit）。checkpoint 执行时，sink 先预提交（把数据写入外部系统的事务，但未真正提交），checkpoint 完成并持久化后，sink 执行真正的 commit；若中途失败，则回滚（abort）未完成的事务。Flink 的 CheckpointCoordinator 负责协调 JobManager 与各 task 的 2PC 协议，保证"所有算子都 checkpoint 成功才提交，否则回滚"。对 Kafka 的依赖：Kafka 提供事务性 producer（transactional.producer），支持在事务内写入并跨分区原子提交；Flink 的 Kafka Sink 基于该事务把数据写入 pending transaction，checkpoint 完成后把事务 commit 到 Kafka，实现端到端 Exactly-Once。因此 2PC 依赖外部系统支持事务（如 Kafka、JDBC 连接器的 2PC），否则只能靠幂等或 at-least-once。

核心是"预提交+提交"两阶段，由 checkpoint 周期驱动。Kafka 事务使 sink 写入可原子提交，是端到端 Exactly-Once 的关键支撑。

• 源端 KafkaConsumer 的 offset 管理
• sink 端 Kafka 事务 producer
• checkpoint 与事务的协同

Flink 与 Kafka 的精确一次要求"读不丢、写不重"。源端：Flink Kafka Connector 通过 Flink 的 checkpoint 记录消费的 Kafka offset（offset 作为算子状态的一部分随 checkpoint 持久化），恢复时从 checkpoint 记录的位置继续消费，实现"不重复消费"（源端精确一次）。Sink 端：使用 Kafka 事务性 producer（transactional.id），Flink 开启一批事务（transaction.timeout.ms 需大于 checkpoint 间隔），sink 在 checkpoint 时把数据写入事务并预提交，checkpoint 完成后统一 commit 事务；若恢复则 abort 未提交事务，保证"不重复写入"。保证一致性的前提：消费端 isolation.level=read_committed 只读已提交数据，且 Checkpointing 开启（enableCheckpointing）。源端与 sink 端都由同一个 checkpoint 协调（align），保证"消费 offset 与写入数据"原子对齐，从而端到端 Exactly-Once。

分两层记忆：源端靠 checkpoint 记录 offset 防重读，sink 端靠 Kafka 事务防重写，二者由 checkpoint 对齐。Kafka 版本需支持事务。

• Barrier 对齐机制
• aligned vs unaligned checkpoint
• 延迟与一致性的取舍

Flink Checkpoint 通过 Barrier（屏障）实现一致性快照。Barrier 由 JobManager 周期性注入到数据源，随数据流向下传播；每个算子收到所有输入流的 Barrier 后做对齐（aligned）：等待所有输入分支的 Barrier 到达，期间缓冲该分支后续数据，全部到齐后对算子状态做快照，再向输出传播 Barrier。对齐保证"快照包含的处理状态与已处理数据一致"，从而精确一次。但对齐会因慢分支阻塞快分支，导致高延迟、影响吞吐。为缓解，Flink 1.11+ 支持不对齐 Checkpoint（Unaligned Checkpoint）：不等待 Barrier 对齐，直接把缓冲区中未处理的数据也纳入快照，从而减少背压、降低延迟，但快照体积更大、恢复更慢。取舍：对齐适合低延迟敏感、网络稳定场景，保证精确一次但可能受背压影响；不对齐适合背压明显、需要低快照延迟的场景，代价是快照更大、恢复更长。

关键理解"Barrier 对齐=等待所有输入，保证一致性；不对齐=跳过对齐牺牲体积换速度"。对齐是精确一次的基础，不对齐是对背压场景的优化。

• Checkpoint 的快照机制
• 状态备份与恢复
• 端到端 Exactly-Once 的配合

Flink 的 Exactly-Once 基于 Checkpoint 实现。Checkpoint 是 Flink 周期性对算子状态 + 数据流位置（source offset）做的一致快照：通过 Barrier 对齐，保证每个算子快照时"已处理数据与状态"一致，快照持久化到可恢复存储（如 RocksDB、HDFS）。恢复时，从最近一次成功的 Checkpoint 恢复所有算子状态与 source 位置，未处理完的数据重新处理，从而"不丢不重精确一次"。Flink 提供的 Exactly-Once 是"计算引擎级"一致；端到端 Exactly-Once 还需源端可重放（Kafka offset）+ sink 端事务/幂等（2PC、Kafka 事务），由 checkpoint 全局协调。若只开启 checkpoint 但 sink 非事务，则退化为 at-least-once。配置：enableCheckpointing(interval)、setStateBackend、setMinPauseBetweenCheckpoints 等。

记住"Checkpoint 是 Flink 精确一次的地基"，其核心是"Barrier 对齐的一致快照 + 恢复重放"。引擎级与端到端要区分开。

• 状态 TTL 配置（StateTtlConfig）
• 状态膨胀的 checkpoint 与内存问题
• 治理手段

Flink 支持给状态配置 TTL（存活时间），过期状态自动清理。通过 StateTtlConfig.newBuilder(Time.seconds(60)).setUpdateType(OnCreateAndWrite).setTtlTimeCharacteristic(ProcessingTime).build() 配置，并指定 setStateTtlConfig。清理策略多样：Background 清理（后台线程周期扫）、增量清理（Incremental Cleanup，HeapState 上逐批清理）、RocksDB 压缩清理（RocksDBFullFilter 等）。状态膨胀问题：状态无界增长时，checkpoint 体积增大、耗时变长、网络与存储开销大，且堆状态占用内存导致 GC/OOM，RocksDB 状态则磁盘与恢复变慢。治理：①给状态加 TTL 自动过期；②合理裁剪/压缩状态（减少存储键值）；③用 RocksDB 状态后端支撑大状态；④增大 checkpoint 频率与并行度分担；⑤对 key 做分区/加盐避免单 key 状态爆炸。TTL 是"以过期清理换状态收敛"的常用手段。

抓住"TTL 配置 + 清理策略 + 状态膨胀治理"。状态膨胀直接威胁 checkpoint 与内存，TTL 是最直接的缓解。回答要落到"怎么配、怎么清、怎么治"。

• CEP 的定义与模式（Pattern）
• Pattern API 的匹配（连续/循环/选择）
• 应用场景（告警、风控）

Flink CEP（Complex Event Processing）是 Flink 的复杂事件处理库，用于在无界事件流中检测复杂事件模式。核心是 Pattern API：定义模式（如"连续 3 次失败（next）"、"失败后成功（followedBy）"、"循环 N 次"），通过 Pattern.begin(...).next(...).where(...).times(3) 描述事件间的关系（严格/非严格连续、循环、optional），然后 CEP.pattern(stream, pattern) 把模式应用到流上，用 select/flatSelect 处理匹配结果。支持时间窗口内匹配、时长约束（within）、超时事件处理（side output）。常用于：实时告警（连续失败检测）、风控（异常交易序列）、用户行为分析（转化漏斗）。CEP 的状态管理基于 Flink 状态，配合 checkpoint 可精确恢复。注意 CEP 对事件顺序敏感，需合理设置时间语义与 watermark。

抓住"Pattern API 定义模式 + CEP 匹配驱动"。核心概念是 next/followedBy 等连续关系与 within 时长约束。答题落到"哪类模式、怎么定义、怎么用"。

• FlinkML 的定位与模块
• 流式机器学习能力
• 与 Spark MLlib 的对比

FlinkML（Flink Machine Learning）是 Flink 的机器学习库，提供表驱动的机器学习算法与统计工具，支持与 Table API 集成，其设计目标之一是在流式数据上做在线学习。早期版本（Flink 1.x）提供 ALS（协同过滤）、KMeans、SVM、线性回归等批量算法，以及部分在线学习（在线学习分类器）。但 FlinkML 早期发展缓慢、算法覆盖窄，远不如 Spark MLlib 成熟（MLlib 有完整 pipeline、特征工程、评估、广泛算法）。Flink 1.15+ 重启了 FlinkML 作为独立模块（flink-ml），聚焦于 online learning（如在线逻辑回归）与 Table API 的 sklearn 风格接口，但仍处于早期。工程定位：Flink 主要做流式数据预处理与特征工程（配合 CEP/窗口），复杂模型训练通常用 Spark MLlib / 外部 ML 框架，Flink 做在线推断或轻量在线学习。

诚实说明 FlinkML 发展滞后、算法少，重点在"在线学习 + Table API"，工程上常与 Spark MLlib 分工。避免吹嘘 FlinkML 能力。

• 类型序列化体系（TypeInformation/TypeSerializer）
• Kryo 序列化
• Avro 序列化

Flink 用 TypeInformation 描述数据类型并生成对应的 TypeSerializer 做序列化。Flink 内置对常见类型（基本类型、POJO、Tuple、Row）的高效序列化器，性能优于 Kryo。当遇到无法识别或未注册的自定义类型时，Flink 回退到 Kryo 序列化：Kryo 是通用、反射式序列化，能处理任意类型，但性能差、体积大，且需注册类（env.registerType） 才能优化。Avro 是 schema 驱动的序列化框架，支持 schema 演进（字段兼容性），Flink 的 Avro 序列化器（AvroTypeInfo）用于与 Avro 数据格式（如 Kafka 中的 Avro 消息、Avro schema）交互，配合 Schema Registry 管理 schema。取舍：能识别的类型用内置序列化器（快）；自定义类型优先注册或实现 TypeSerializer 而不是依赖 Kryo；与外部系统交换结构化数据用 Avro（带 schema）。

按"内置 > 自定义 TypeSerializer > Kryo"的优先级看待序列化。Kryo 是兜底但慢，Avro 是 schema 化的交换格式。回答强调"别滥用 Kryo"。

• Metric 类型（Counter/Gauge/Histogram/Meter）
• flink-metrics 的 reporter 体系
• 关键监控指标

Flink 内置完善的 Metric 系统（flink-metrics），用于监控作业运行状态。Metric 分为四类：Counter（计数器，如处理条数）、Gauge（当前值，如内存使用）、Histogram（分布，如延迟）、Meter（速率，如吞吐）。用户可在算子中通过 getRuntimeContext().getMetricGroup() 注册自定义 metric。Flink 通过 reporter（如 Prometheus、InfluxDB、Graphite、JMX）把 metric 上报到监控系统，配置 metrics.reporter.* 与对应用的 flink-metrics-prometheus 依赖。常用监控指标：checkpoint 时长与失败率、背压（backpressure）程度、水位（watermark）进度、吞吐、延迟、状态大小、资源（CPU/内存）。监控体系用于定位作业卡顿、背压、checkpoint 失败等问题，是 Flink 运维的关键。

记住四种 metric 类型 + reporter 上报机制。监控重点在"checkpoint 失败、背压、watermark 推进"这三个流式作业核心指标。

• ProcessFunction 的分类（KeyedProcessFunction/ProcessAllWindowFunction）
• Timer 的注册与触发
• 使用场景（事件驱动、超时）

ProcessFunction 是 Flink 的底层处理函数，能访问元素、状态、时间戳与所在算子上下文，并注册 Timer（定时器）。常用子类：KeyedProcessFunction（按 key 处理，可访问 keyed state）、ProcessAllWindowFunction（窗口处理）、ProcessFunction（非 keyed）。Timer 是 ProcessFunction 提供的定时能力：可通过 ctx.timerService().registerEventTimeTimer(timestamp)（事件时间）或 registerProcessingTimeTimer（处理时间）注册定时器，到时间后回调 onTimer。Timer 常用于：事件驱动状态清理（如会话超时）、延迟触发计算、超时检测（如等待某事件超时）、窗口内辅助状态。Timer 也是状态的一部分，随 checkpoint 持久化，故障可恢复。注意 Timer 数量过多会占用状态与内存，需合理设置。

抓住"ProcessFunction = 底层访问元素/状态/时间/Timer 的窗口"。Timer 是"事件驱动回调"的核心，结合 watermark 实现事件时间定时。答题落到"注册 Timer + onTimer 回调"。

• Checkpoint 的自动、周期、轻量定位
• Savepoint 的手动、触发、运维定位
• 差异（生命周期、存储、兼容性）

Checkpoint 与 Savepoint 都是 Flink 的状态快照，但定位不同：Checkpoint 是自动、周期性触发（由 JobManager 按间隔），用于故障自动恢复，生命周期短、可被清理，通常存于本地/特定目录，体积可优化（增量），不要求跨版本兼容；Savepoint 是手动、按需触发（flink savepoint 命令或 API），用于运维操作（升级 Flink 版本、调整并行度、代码变更、迁移集群），需要长期保存，要求跨版本兼容（格式稳定），便于恢复与迁移。Savepoint 通常基于 Checkpoint 生成（可触发"savepoint 式的 checkpoint"），两者格式可互换但语义不同。工程上：Checkpoint 管"日常故障恢复"，Savepoint 管"版本升级/迁移/扩容"。恢复时需注意 operator id 与状态命名对齐。

用"自动周期 vs 手动按需"、"短生命周期 vs 长期保存"、"无需跨版本兼容 vs 需兼容"三组对比记忆。Savepoint 是运维工具，Checkpoint 是保障机制。

• Streaming 逐事件低延迟
• Batch 有界批处理
• 批流一体（统一 API 与语义）

Flink 提供两种执行模式：Streaming（流式）与 Batch（批式）。Streaming 模式处理无界数据流，逐事件流水线处理，低延迟、持续运行，依赖 watermark 处理 event-time，支持 checkpoint 一致性与事件驱动；Batch 模式处理有界数据集，一次性执行，可做更重度的优化（如按序执行、更深的算子优化、全物化），吞吐高、延迟不敏感。Flink 1.12+ 的批流一体（Unified Batch Streaming）：同一套 DataStream/Table API 既能跑流也能跑批，Batch 可视为特殊的"有界流"，通过 setExecutionMode 或 SET execution.runtime-mode=BATCH 切换。批流一体让同一套代码、同一套语义（如窗口、SQL、状态）在批与流间复用，减少两套引擎的维护。实际中，批流一体优化了资源利用与吞吐，但流式特有的低延迟在批模式下不适用。

抓住"有界 vs 无界"是核心区别，批流一体是"一套 API 两种模式"。理解 Batch 可做更重优化，Streaming 追求低延迟与一致性。

• Table API / SQL 的声明式编程
• 动态表（Dynamic Table）与连续查询
• 与 DataStream API 的互操作

Flink 的 Table API 与 SQL 是声明式（declarative）的流/批处理 API，基于关系模型：把流/批数据视为"动态表（Dynamic Table）"，用 SQL 或 Table API 写连续查询（Continuous Query），查询结果持续更新（追加/更新/删除）。Table API 是类型安全的 Java/Scala DSL，SQL 是标准 SQL 语句，二者都由 Flink 的查询优化器（Flink Planner）优化为执行计划。底层通过 DataStream API 执行。互操作：TableEnvironment.toDataStream(table) / fromDataStream(stream) 可在 Table 与 DataStream 间转换，toChangelogStream 处理 changelog；Table 编程抽象层次高、适合复杂 JOIN/聚合，DataStream 编程灵活、适合低层处理与状态定制。实际中常混合使用：SQL 做复杂查询，DataStream 做自定义算子。

核心是"动态表 + 连续查询"模型，Table/SQL 是高层声明式，DataStream 是底层命令式，二者可互转。记住互转方法名。

• 三种时间语义定义
• 各自适用场景
• 时间语义的选择与配置

Flink 提供三种时间语义：①Event Time（事件时间）：事件在源头产生的时间，由事件携带（如日志时间戳），最符合业务语义，能正确反映乱序事件，需配合 watermark 处理乱序与迟到，是流处理推荐的时间语义；②Processing Time（处理时间）：算子处理该事件时的系统时间，最简单、延迟低、无乱序问题，但结果依赖处理速度、不具确定性，适合对时间不敏感或实时告警场景；③Ingestion Time（摄入时间）：事件进入 Flink 源时的时间，由 Source 注入，介于两者之间，自动生成 watermark 但比 Event Time 晚（引入摄入延迟）。选择：需要按业务事件时间聚合/统计（如订单、日志）用 Event Time；实时性优先、不关心事件真实时间用 Processing Time；无法从事件提取时间戳且需近似语义时用 Ingestion Time。通过 setStreamTimeCharacteristic（旧）/ env.setStreamTimeCharacteristic 或 Table 的 time 属性配置。

用"何时打时间戳"区分：Event 在源头、Processing 在算子、Ingestion 在源。Event Time 最语义化但需 watermark，Processing 最简单但不确定。答题给出选择依据。

• Watermark 的定义与含义
• 生成方式（周期性/单调递增/自定义）
• 乱序与迟到数据处理

Watermark（水位线）是 Flink 用于处理 Event Time 乱序数据的机制，它表示"时间戳小于等于 watermark 的事件已全部到达"的进度标记。当 watermark 推进到 t 时，Flink 认为 event time 小于等于 t 的乱序事件已到齐，可触发窗口等计算。生成方式：assignTimestampsAndWatermarks 配合 WatermarkStrategy，常用 forBoundedOutOfOrderness(Duration)（周期生成，容忍固定乱序延迟）、forMonotonicTimestamps（假设有序）、自定义 WatermarkGenerator。watermark 随数据流向下游传播，下游取各输入分支的最小 watermark 作为推进依据。迟到数据：晚于 watermark 但仍在窗口内的数据被视为迟到，可用 allowedLateness 再次触发窗口，或 sideOutputLateData 输出到旁路流。Watermark 过大会延迟窗口触发、过小会漏掉乱序数据，需按业务乱序程度权衡。

Watermark 是"乱序问题的进度标记"。核心是"watermark 推进触发计算 + allowedLateness 兜底迟到 + side output 旁路"。理解"最小 watermark 传播"。

• 反压的产生与传播
• 背压的监测（JobManager UI）
• 治理手段

反压（Backpressure）是下游处理速度慢于上游时，数据积压导致上游算子被阻塞流控的机制。Flink 的处理算子是流水线、逐条传递的，当下游算子（如 sink、聚合）处理不过来时，通过 TaskManager 的缓冲池与网络缓冲把压力反传到上游，上游算子 slowed 直到源端，形成"背压链"。Flink 自动处理背压（无需手动），但背压持续会导致作业吞吐下降、延迟增加、checkpoint 变慢。定位：JobManager Web UI 的 Backpressure 面板显示各算子背压程度（Low/Medium/High），通过采样 thread 的 buffer 占用判断。治理：①优化下游瓶颈算子（如减少聚合复杂度、加并行度）；②增大算子的并行度/缓冲（taskmanager.network.memory）；③优化 sink 写入（批量、异步、事务）；④检查窗口/状态是否过大导致处理慢；⑤对数据倾斜打散。Flink 1.11+ 的 unaligned checkpoint 可缓解背压对 checkpoint 的影响。

反压是"动态流控"不是错误，核心是"下游慢→上游堵"。定位用 UI 背压面板，治理找瓶颈算子。注意反压与 checkpoint 的相互影响。

• 窗口的 Trigger 机制
• 增量聚合（AggregateFunction/ReduceFunction）
• 实时指标计算场景

Flink 窗口由 Trigger（触发器）决定"何时计算/输出窗口结果"。内置 Trigger 如 EventTimeTrigger（watermark 越过窗口结束触发）、ProcessingTimeTrigger、CountTrigger（到条数触发）、以及自定义 Trigger（onElement/onProcessingTime/onEventTime/clear）。Trigger 返回 CONTINUE/FIRE/PURGE/FIRE_AND_PURGE 控制是否计算与清理。增量聚合：用 aggregate(AggregateFunction) 或 reduce(ReduceFunction) 在窗口内边接收数据边聚合，只维护一个中间结果（如计数、求和、最大值），无需缓存全部数据，内存占用小、性能高，适合实时指标（如每秒订单量、实时 PV/UV、均值）。配合窗口（滚动/滑动）+ 事件时间 + 水位线，可实时输出窗口聚合结果。Trigger 控制"何时触发输出"，增量聚合"如何高效计算"，二者结合实现低延迟高吞吐的实时指标。

分清"Trigger 决定何时算、AggregateFunction 决定怎么算"。增量聚合避免全量缓存，是实时指标的效率关键。答题落到"触发时机 + 增量计算"。

• Flink CDC 与 Debezium 原理
• 实时入湖入仓应用
• 快照（snapshot）与增量（binlog）切换

Flink CDC（基于 Debezium）通过读取数据库的 binlog（MySQL）、redo log（Oracle）等变更日志，实时捕获数据库的增删改，把变更解析为 changelog 流供 Flink 消费，实现"数据库实时入湖入仓"。相比传统全量抽数+定时增量，CDC 提供秒级实时、低延迟、不侵入业务表。应用场景：实时数据同步到数仓/数据湖（Hudi/Iceberg/Delta）、实时维表 join、实时数据管道。快照/增量切换：首次启动时先做全量快照（Snapshot），扫描现有数据生成初始 changelog，快照完成后自动切换到**增量（binlog）**读取，全程无需停库；Flink CDC 记录了 binlog 位点保证切换无损、支持断点续传（checkpoint）。注意事项：CDC 要求源库开启 binlog 并配置合理保留期；快照阶段对库有压力，需分批读取；需处理 schema 变更与 DDL。MySQL CDC 连接器（Flink 官方）内部用 Debezium 的增量快照（Incremental Snapshot）机制提升效率。

抓住"binlog 变更捕获 + 全量快照→增量切换 + checkpoint 断点续传"。CDC 是实时入湖的核心通道。回答要提"快照与增量无缝切换"。

• Native 与 Standalone 部署差异
• K8s ConfigMap 的 HA 方案
• ZooKeeper 的 HA 方案

Flink on Kubernetes 有两种部署模式：Standalone（独立）：Flink 集群由 Flink 的 JobManager/TaskManager 镜像组成，TaskManager 通过 JobManager 动态分配，不依赖 Kubernetes 调度 Native 资源，K8s 只负责容器编排；Native（原生）：Flink 直接使用 Kubernetes 的 Pod/资源 API 动态申请 Executor（TaskManager），由 Flink 的 KubernetesResourceManager 管理 Pod 生命周期，支持自动扩容/缩容，更贴合云原生。JobManager 高可用（HA）有两种实现：①K8s ConfigMap 方案：Flink 把 JobManager 的 leader 信息、checkpoint 元数据、job 图等存入 K8s ConfigMap，多个 JobManager 通过 ConfigMap 竞相注册 leader，实现主备切换，无需额外组件；②ZooKeeper 方案：Flink 借助 ZooKeeper 的临时节点/leader 选举实现 JobManager 高可用，适合已有 ZK 集群的场景。Native 模式配 ConfigMap HA 是当前推荐的云原生组合。

区分"Standalone 不深度用 K8s API 调度 vs Native 用 K8s API 动态管理"。"ConfigMap 存元数据 + 选主"与"ZooKeeper 选主"是两种 HA 介质。回答要落到部署差异与 HA 介质。

• JobManager 的职责（调度、checkpoint、leader）
• TaskManager 的职责（执行、slot、状态）
• 协作流程

Flink 采用 Master/Slave 架构：JobManager（主）负责任务调度、checkpoint 协调、故障恢复、资源分配与 leader 选举，是整个集群的"大脑"；JobManager 内部含 Dispatcher（作业提交）、ResourceManager（资源管理）、JobMaster（单个作业的调度协调）。TaskManager（从）是执行节点，负责真正执行算子（运算）与维护状态；每个 TaskManager 被划分为若干 Slot（任务槽），每个 Slot 运行一个 operator 子任务，Slot 是资源分配与并行度的基本单位。协作流程：客户端提交作业到 JobManager，JobManager 生成执行图并调度到各 TaskManager 的 Slot 上，TaskManager 执行算子并周期性汇报状态，JobManager 协调 checkpoint 与故障恢复。JobManager 可配 HA（多副本），TaskManager 可水平扩展。状态存储（Memory/RocksDB/Fs）在 TaskManager 侧。

用"JobManager 管调度、TaskManager 管执行"记忆。Slot 是资源单位，checkpoint 由 JobManager 协调。回答要点出两层职责与 Slot。

• MemoryStateBackend
• FsStateBackend
• RocksDBStateBackend

Flink 状态后端决定状态如何存储、checkpoint 如何持久化。三类：①MemoryStateBackend：状态存于 TaskManager 的 JVM 堆内存，checkpoint 存于 JobManager 内存，速度快但状态容量受堆内存限制、大状态易 OOM，且 checkpoint 存 JobManager 内存易撑爆，仅适合小状态/测试；②FsStateBackend：状态在 TaskManager 堆内存，checkpoint 持久化到分布式文件系统（HDFS/OSS），状态容量受堆限制但 checkpoint 可靠，适合中量状态；③RocksDBStateBackend：状态存于 RocksDB（本地磁盘、基于 LSM 的 KV 存储），可支撑超大状态（GB/TB 级），checkpoint 持久化到文件系统，支持增量 checkpoint，适合大状态、高并发场景，但读写有磁盘 IO 开销、序列化/反序列化开销。选择依据：状态规模与内存。现在 Flink 推荐用 EmbeddedRocksDBStateBackend（RocksDB）处理大状态，Memory/Fs 已被基于堆的 HashMapStateBackend 取代。

用"内存 vs 磁盘"区分：Memory/Fs 存堆内存（小状态），RocksDB 存磁盘（大状态）。RocksDB 支撑大状态是核心卖点。回答落到"状态规模决定后端选择"。

• 滚动窗口（Tumbling）
• 滑动窗口（Sliding）
• 会话窗口（Session）

Flink 窗口是对流数据按时间/数量分组计算的基本单元，常用三类：①滚动窗口（Tumbling）：固定大小、不重叠、无缝衔接（如每 10 分钟一个窗口），每个元素只属于一个窗口，简单、适合定时聚合；②滑动窗口（Sliding）：固定大小+固定滑动步长，窗口可重叠（滑步小于窗口长度时同一元素属于多个窗口），适合需要细粒度输出的场景（如每 5 分钟看过去 1 小时），但重叠造成重复计算；③会话窗口（Session）：按不活跃间隔（gap）切分，无固定长度，相邻事件间隔超过 gap 则新开窗口，适合用户会话/在线行为分析（活动期间的连续事件）。窗口按时间语义用 Event/Processing/Ingestion Time，配合 watermark 与 allowedLateness 处理迟到。窗口类型用 window/windowAll 或 SQL 的 TUMBLE/HOP/SESSION 定义。

用"是否重叠、长度是否固定"区分三种窗口：滚动不重叠固定、滑动重叠固定、会话不固定按间隔。会话窗口最贴合"行为会话"语义。

• allowedLateness 的多次触发
• sideOutputLateData 的旁路输出
• 数据丢弃时机

Flink 窗口对迟到数据（late events，event time 晚于 watermark 但应属于该窗口）通过 allowedLateness 与 sideOutputLateData 协作处理。allowedLateness：允许窗口在 watermark 越过窗口结束时间后，再保留一段时间（如 allowedLateness(Time.minutes(5))），期间迟到的数据会再次触发窗口计算（FIRE），从而把迟到数据纳入结果；当延迟超过 allowedLateness 时，窗口被清理（清除）。sideOutputLateData：把超出 allowedLateness 仍迟到的数据输出到旁路侧输出流（side output），供单独处理（如记录、告警、重算），避免数据静默丢失。协作机制：窗口生命周期 = 窗口结束时间 + allowedLateness；在此时间窗内到达的迟到数据触发窗口 → 触发结束后且超过 allowedLateness 到达的数据 → 进 side output（若配置）或被丢弃。若既不配置 allowedLateness 也不配置 side output，迟到的数据在窗口触发后到达即被丢弃。

明确"窗口生命周期 = 结束时间 + allowedLateness"。allowedLateness 负责"晚到再算"，side output 负责"太晚的兜底"，都未配置则丢弃。答题要讲清"丢弃时机"。

• Table → DataStream（toDataStream/toChangelogStream）
• DataStream → Table（fromDataStream）
• 互操作注意事项

Flink 的 Table/SQL 与 DataStream API 可互转，实现高层声明式与底层命令式结合。DataStream → Table：TableEnv.fromDataStream(stream) 或 fromChangelogStream 把流注册为表，之后可用 SQL/Table API 查询；Table → DataStream：TableEnv.toDataStream(table) 把表转为追加流（append-only），toChangelogStream(table) 把变化表转为 changelog 流（含 insert/update/delete），toRetractStream 返回 retract 流。互操作注意：转换时需保证类型（Row 类型与 schema 匹配）、时间属性（event time / watermark 在转换中保留）、以及表的 append-only 语义（若表非 append-only，需用 changelog 流）。工程上常用于"SQL 做复杂聚合 + DataStream 做自定义算子/状态"的组合。Flink 1.14+ 推荐用 Table.newStreamTableBuilder 与 toDataStream/fromDataStream 简化互转。

记住两个方向四个方法：fromDataStream（流→表）、toDataStream/toChangelogStream（表→流）。注意 append-only 与 changelog 语义差异。