实时计算与流处理全景知识图谱

4.1 延迟 / 吞吐 / 一致性三角

流计算的三个核心指标不可兼得：降低延迟需要更频繁的处理（牺牲吞吐）；保证一致性需要 Checkpoint 和事务（增加延迟）；提高吞吐需要批量处理（增加延迟）。

工程判断：先明确业务对延迟的真实需求。大量场景"秒级"就够，不需要"毫秒级"。过度追求低延迟会让系统复杂度和成本指数上升。

4.2 时间语义与 Watermark

Event Time vs Processing Time：Event Time 是事件实际发生时间，Processing Time 是引擎处理时间。生产环境几乎都应该用 Event Time，否则乱序和延迟会导致结果不确定。

Watermark：引擎对"数据完整性"的估计——"我认为时间 T 之前的数据都已到达"。Watermark 太激进会丢迟到数据，太保守会增加延迟。

迟到数据处理：Allowed Lateness（允许窗口延迟关闭）+ Side Output（迟到数据旁路输出）。没有完美方案，只有业务可接受的权衡。

4.3 窗口策略

Tumbling Window（滚动窗口）：固定大小、不重叠。适合周期性聚合（每分钟 PV、每小时 GMV）。

Sliding Window（滑动窗口）：固定大小、可重叠。适合移动平均、趋势检测。窗口越密集计算开销越大。

Session Window（会话窗口）：按活动间隔动态划分。适合用户行为分析、会话聚合。实现复杂度高于固定窗口。

Global Window + Trigger：自定义触发条件，最灵活但最难调试。适合不规则聚合场景。

4.4 状态管理与 Checkpoint

State Backend：HashMapStateBackend（内存，快但容量有限）vs RocksDBStateBackend（磁盘，容量大但有序列化开销）。生产环境大状态场景几乎都用 RocksDB。

Checkpoint：定期将算子状态快照到持久化存储（HDFS/S3）。增量 Checkpoint 只保存变化部分，大幅降低 IO。Checkpoint 间隔是恢复时间和性能开销的权衡。

Savepoint：手动触发的全量快照，用于版本升级、拓扑变更、A/B 测试。Savepoint 兼容性是 Flink 作业长期运维的关键挑战。

4.5 Exactly-once 端到端

引擎内部：Flink 通过 Checkpoint Barrier 对齐实现算子间 Exactly-once。Barrier 对齐会引入背压，Unaligned Checkpoint 缓解但增加恢复时间。

Source 端：需要可回放（Kafka offset 回退）。不可回放的 Source（如 Socket）无法保证 Exactly-once。

Sink 端：两阶段提交（Kafka/JDBC）或幂等写入（Upsert 语义）。两阶段提交延迟高但语义强，幂等写入延迟低但需要业务配合。

工程判断：端到端 Exactly-once 的代价是吞吐下降 10-30% 和延迟增加。大多数场景用 At-least-once + 幂等 Sink 更务实。