2. 核心概念：事件时间 vs 处理时间，水位线（Watermark）的诞生背景
做实时计算，第一个绕不开的问题就是：时间。
你可能觉得时间有什么好讨论的？不就是看个时钟吗？
嗯，真不是这么简单。我在做第一个实时项目时，就被时间问题坑得很惨。数据明明到了，但算出来的指标就是不对。后来才发现，我搞混了两种时间。
2.1 两种时间：事件时间 vs 处理时间
先看一个最直观的例子。
假设你在手机上点了个外卖，下单时间是 12:00。但手机信号不好，这条订单数据直到 12:05 才传到服务器。
- 事件时间（Event Time）：12:00 —— 事情真实发生的时刻。
- 处理时间（Processing Time）：12:05 —— 服务器收到数据开始处理的时刻。
就这么简单？对，概念上就这么简单。但实际工程里，这个差异能让你抓狂。
核心原则：做回溯计算和修复，必须依赖事件时间。处理时间只适合做监控和调试。
为什么不能只用处理时间？
我举个例子你就明白了。
假设你要统计「每分钟的订单金额」。如果用处理时间，12:00 下的单，12:05 才到，这笔钱就算到了 12:05 那一分钟里。
这合理吗？不合理。用户明明 12:00 下的单，你凭什么算到 12:05 的头上？
更麻烦的是，如果网络延迟不稳定，数据乱序到达，用处理时间统计出来的结果，每次重跑都不一样。你想想看，一个指标每次跑出来结果不同，谁敢用？
| 对比维度 | 事件时间 | 处理时间 |
|---|---|---|
| 定义 | 数据真实发生的时间 | 数据到达处理引擎的时间 |
| 确定性 | 确定，不会变 | 不确定，每次重跑可能不同 |
| 依赖因素 | 数据本身携带的时间戳 | 系统时钟、网络延迟、负载 |
| 适用场景 | 回溯计算、修复、精确统计 | 实时监控、报警、快速预览 |
| 容错性 | 需要处理乱序和延迟 | 天然有序，但结果不准确 |
2.2 乱序问题：事件时间带来的新麻烦
好了，你决定用事件时间。但新问题来了：数据不是按顺序到的。
我遇到过最夸张的情况：一条 10:00 的数据，因为网络重试，下午 3 点才到。而它后面的数据，11:00 就到了。
这就叫乱序。
乱序带来的核心问题是：你什么时候才能确定，某个时间窗口的数据已经收齐了？
比如你要统计 10:00~10:01 这一分钟的订单。10:01 到了，你敢不敢关窗输出结果？
不敢。因为还有数据在路上，可能 10:00 的订单 10:02 才到。
那等到 10:02？也不行，万一 10:00 的数据 10:03 才到呢？
等到 10:03？那 10:01 的数据又可能 10:04 到……
看到了吗？这是个死循环。你永远不知道数据是不是真的到齐了。
2.3 水位线（Watermark）的诞生
为了解决这个问题，就有了水位线。
水位线的本质是：一个时间戳，告诉系统「在这个时间之前的数据，应该都到了」。
说白了，就是给系统一个「差不多可以关窗了」的信号。
我的理解：水位线就像是一个「迟到截止线」。水位线之前的数据，系统会尽量等；水位线之后才到的数据，就被标记为「迟到数据」，走特殊处理逻辑。
水位线怎么工作的？
我习惯用一个比喻来解释：
- 想象你在车站等人。你定的时间是「12:00 到站」。
- 你等到 12:05，觉得差不多了，开始检票进站。
- 12:05 就是你的「水位线」。
- 12:05 之后才到的人，就是「迟到数据」。
在实时系统里，水位线通常由数据源或计算引擎生成。常见的生成策略有两种：
- 固定延迟：水位线 = 当前最大事件时间 - 固定延迟（比如 5 秒）。适合网络延迟比较稳定的场景。
- 动态估算：根据历史数据到达的延迟分布，动态调整水位线。适合延迟波动大的场景。
我曾经踩过的坑：水位线设得太短，大量数据被当成迟到数据，结果不准。设得太长，窗口迟迟不输出，实时性变差。这个参数需要根据业务容忍度来调，没有标准答案。
2.4 知识体系：时间与水位线的关系
下面这张图，是我梳理的本章知识结构。你可以把它当作一个「思维导图」来看。
2.5 实际工程中的选择建议
说了这么多，到底怎么选？我给出几条实战建议：
- 做回溯计算和修复：必须用事件时间 + 水位线。这是唯一能保证结果确定性的方案。
- 做实时监控和报警：可以用处理时间。监控看的是趋势，差几秒没关系。
- 混合使用：我见过很多系统，主流程用事件时间，同时用处理时间做一条「快速预览」链路。两套数据互相校验。
一个小技巧：在数据进入系统时，同时保留事件时间和处理时间两个字段。这样即使后来发现事件时间有问题，还能用处理时间做对比分析。
嗯，时间概念就讲到这里。理解了事件时间和水位线，你就掌握了实时回溯计算的基石。后面讲具体修复方案时，你会发现所有操作都是围绕这两个概念展开的。