2. Flink核心概念回顾：DataStream与DataSet API、事件时间与处理时间、状态后端与Checkpoint机制
好，咱们正式开始第二讲。在数据网格里用 Flink，说白了就是拿它当那个“流动的管道”，把数据从源头搬到各个数据域。但光会搬不行，你得知道 Flink 到底是怎么理解数据的，它的时间观是什么样的，以及它怎么保证不出错。
这一节，我把 Flink 最核心的几个概念串一遍。你可能会觉得“这些我都知道”，但别急，我会结合我在数据网格项目里踩过的坑来讲，保证有干货。
2.1 DataStream 与 DataSet API：流与批的“分分合合”
Flink 最早的时候，把流处理和批处理分得很清楚。DataStream API 管流，DataSet API 管批。但后来 Flink 社区想明白了一件事：批处理不就是有限流吗？所以从 Flink 1.12 开始，DataSet API 被标记为“软弃用”，官方推荐统一用 DataStream API 来处理所有场景。
我个人习惯是：只要数据是活的，就用 DataStream。哪怕你今天只是跑一个离线报表，我也建议你用 DataStream 加上批模式运行。为什么？因为将来这个报表要是想改成实时增量，你改几行代码就行，不用重写整个作业。
核心区别一句话总结：
- DataStream：无界或有界数据流，事件驱动，天然支持实时。
- DataSet：有界数据集，批处理专用，API 更接近传统 MapReduce。
我在项目中遇到过这样一个场景：数据网格里有个“用户画像”数据域，每天凌晨跑一次全量更新，用的是 DataSet API。后来业务方说“能不能每 10 分钟增量更新一次？”好嘛，整个作业得重写。如果一开始就用 DataStream 的批模式，改个时间窗口就完事了。
下面这张图帮你理清 Flink 的 API 层次：
我的建议：新项目直接放弃 DataSet API。如果你还在维护老代码，尽快迁移到 DataStream。数据网格讲究的是“数据域自治”，每个域的数据处理方式可能不同，但底层引擎统一用 DataStream，能减少很多运维成本。
2.2 事件时间与处理时间：Flink 的时间哲学
时间，是流处理里最绕不开的话题。Flink 支持三种时间语义，但实际生产中，90% 的场景你只需要关心事件时间和处理时间。
| 时间语义 | 定义 | 典型场景 | 注意事项 |
|---|---|---|---|
| 事件时间 | 数据产生时自带的时间戳 | 日志分析、交易流水、IoT 传感器 | 需要处理乱序和延迟 |
| 处理时间 | 数据到达 Flink 算子的系统时间 | 实时监控、简单聚合 | 结果不稳定，重跑可能不一致 |
| 摄入时间 | 数据进入 Flink 源算子时自动分配 | 很少单独使用 | 已被事件时间替代 |
为什么事件时间这么重要？你想想看，在数据网格里，数据可能从多个数据域汇聚过来。A 域的数据晚到了 10 秒，B 域的数据准时到了。如果你用处理时间做窗口聚合，那 A 域的数据就永远对不齐。事件时间加上 Watermark，才能让 Flink 知道“我等多久，再关窗”。
我曾经在一个金融风控项目里吃过亏。当时用处理时间做 5 分钟滑动窗口，结果因为网络抖动，一批交易数据延迟了 3 秒到达，窗口直接切过去了，那批交易没被统计到。后来改成事件时间 + 允许 10 秒乱序，问题才解决。
⚠️ 避坑指南：事件时间不是万能的。如果数据源本身就没有可靠的时间戳，或者时间戳乱得离谱（比如跨天乱序），那事件时间反而会带来更多麻烦。这时候，我建议你在数据接入层先做一次“时间戳清洗”。
下面这张图展示了事件时间与处理时间在窗口计算中的区别：
2.3 状态后端与 Checkpoint 机制：Flink 的“记忆”与“保险”
Flink 是有状态的。每个算子都可以保存一些数据，比如聚合的中间结果、窗口里的元素。这些状态存在哪？怎么保证挂了不丢？这就是状态后端和 Checkpoint 要解决的问题。
2.3.1 状态后端：你的数据存在哪？
Flink 提供了三种状态后端，我按推荐程度排个序：
| 状态后端 | 存储位置 | 适用场景 | 我的评价 |
|---|---|---|---|
| RocksDBStateBackend | 本地磁盘 + 异步快照到远程存储 | 大状态（GB/TB 级）、需要增量 Checkpoint | 生产首选，几乎万能 |
| HashMapStateBackend | JVM 堆内存 | 小状态（MB 级）、对延迟极度敏感 | 适合开发测试，生产慎用 |
| EmbeddedRocksDBStateBackend | 内嵌 RocksDB 实例 | 与 RocksDBStateBackend 类似，但更轻量 | Flink 1.13+ 推荐 |
我个人习惯：只要状态超过 100MB，无脑上 RocksDB。为什么？HashMap 全在内存里，一旦 TaskManager 挂了，状态全丢。RocksDB 虽然读写慢一点（毫秒级 vs 微秒级），但胜在稳定，而且支持增量 Checkpoint，恢复快。
经验之谈：在数据网格里，每个数据域的状态大小差异很大。比如“用户画像”域可能存几百 GB 的标签数据，而“实时监控”域可能只有几 MB。我建议你为每个数据域单独配置状态后端，不要一刀切。
2.3.2 Checkpoint 机制：Flink 的“自动存档”
Checkpoint 是 Flink 实现容错的核心。它定期把算子的状态快照保存到远程存储（比如 HDFS、S3）。一旦作业失败，Flink 从最近的 Checkpoint 恢复，重新处理数据。
关键参数就几个：
// 核心 Checkpoint 配置示例
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
// 开启 Checkpoint，间隔 60 秒
env.enableCheckpointing(60000);
// 精确一次语义
env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);
// 超时时间 10 分钟
env.getCheckpointConfig().setCheckpointTimeout(600000);
// 同时进行的 Checkpoint 数
env.getCheckpointConfig().setMaxConcurrentCheckpoints(1);
// 两次 Checkpoint 之间的最小间隔
env.getCheckpointConfig().setMinPauseBetweenCheckpoints(30000);
// 失败次数
env.getCheckpointConfig().setTolerableCheckpointFailureNumber(3);
我曾经遇到过一个坑：Checkpoint 超时导致作业反复重启。查了半天，发现是状态太大了，60 秒根本快照不完。后来把间隔调到 120 秒，超时调到 15 分钟，问题解决。嗯，这里要注意：Checkpoint 间隔不是越短越好，太频繁反而影响性能。
⚠️ 重要提醒：Checkpoint 不是备份，它是“一致性快照”。如果你需要长期保存状态用于回溯，请用 Savepoint。Savepoint 是手动触发的，可以指定路径，适合版本升级、作业迁移等场景。
下面这张图展示了 Checkpoint 的完整流程：
核心要点：
- Checkpoint 是自动的，Savepoint 是手动的。
- RocksDB 状态后端 + 增量 Checkpoint 是大状态场景的黄金组合。
- Checkpoint 间隔建议 30 秒到 5 分钟，具体看状态大小和业务容忍度。
- 如果作业频繁因 Checkpoint 超时失败，先调大超时时间，再考虑优化状态大小。
好了，这一章的内容就这些。DataStream 和 DataSet 怎么选、事件时间和处理时间怎么用、状态后端和 Checkpoint 怎么配，都是你后面写 Flink 作业时天天要面对的问题。把这些基础打牢，后面讲数据网格的“数据域隔离”和“联邦查询”时，你才能跟得上。