走过冬季

层级API 类型抽象程度灵活性开发效率典型用途底层低⭐⭐⭐⭐⭐低复杂事件处理、自定义逻辑中层中⭐⭐⭐⭐中主流实时计算、ETL高层高⭐⭐⭐⭐⭐⭐⭐实时数仓、分析查询Flink API 分为三层：底层 ProcessFunction 提供最大灵活性，中层 DataStream API 是主流开发选择，高层 Table API/SQL 实现流批统一的声明式分析——开发者可根据需求“按需取用，层层递进”。

数据到达时机Flink 行为在窗口结束前到达正常参与计算，窗口触发时输出在窗口结束后、allowedLateness 内到达窗口状态保留，重新计算并输出更新结果超过 allowedLateness进入，主窗口不再处理⚠️ 注意：只有场景才涉及延迟数据处理；Processing Time 窗口无此概念。

状态后端是 Flink 管理状态存储与恢复的“引擎”，根据状态大小和性能需求选择 Memory、Fs 或 RocksDB 后端，是保障作业稳定性和扩展性的关键配置。

Flink 通过周期性 Checkpoint 将计算状态和数据源位置快照到持久化存储，故障时从最近快照恢复，从而实现低延迟、高可靠的容错能力。

Kafka]↓ (消费 offset=100)├─ 处理数据 → 更新内部状态└─ 预提交：将结果写入 Sink 临时区（事务中）↓Checkpoint 成功？├─ 是 → 正式提交 Sink（commit 事务）└─ 否 → 回滚 Sink（abort 事务），从 offset=100 重放。

反压是指在 Flink 数据流中，下游算子处理能力不足，导致其输入缓冲区（Input Buffer）被填满，进而阻塞上游算子继续发送数据的现象。问题答案什么是反压？下游处理慢 → 上游自动减速的流控机制是否正常？✅ 正常且必要，防止 OOM如何发现？Web UI 查看 Backpressure 状态根本原因？瓶颈算子（通常是 Sink 或窗口）如何解决？优化 Sink、解决倾斜、调并行度、扩容资源💡最佳实践不要试图“消除”反压，而是通过优化让反压消失。健康的 Flink 作业在负载变化时应能。

Watermark 是一种特殊的时间戳标记，表示“在此 Watermark 之前（≤ W）的事件已经全部到达”，即系统认为不会再有 ≤ W 的事件到来。Watermark 是单调递增的（不能倒退）表示 “事件时间 ≤ t 的数据已完整”对事件时间进度的估计概念说明事件时间事件真实发生的时间（来自数据本身）Watermark“≤ W 的事件已到齐”的进度标记作用触发事件时间窗口、处理乱序事件核心原则Watermark 单调递增，取多流最小值关键配置✅。