实时聚合核心概念：事件时间与处理时间、水位线、窗口类型

做实时数仓，绕不开这几个基础概念。我见过不少团队，代码写得挺溜，但一遇到数据乱序、延迟到达就抓瞎——说白了，就是没把事件时间、水位线、窗口这三样东西吃透。

这一章，咱们就把它们掰开揉碎讲清楚。

事件时间 vs 处理时间：你信谁的时间？

先问个问题：一条数据产生的时间，和它到达计算引擎的时间，哪个更可信？

事件时间（Event Time），就是数据真实发生的时间戳。比如用户在 10:00:00 点击了按钮，这条日志里就带着 10:00:00。不管网络怎么延迟、系统怎么重试，这个时间不会变。

处理时间（Processing Time），是数据到达 Flink 算子时的系统时钟。同样是 10:00:00 产生的点击，可能因为网络抖动，10:00:03 才到 Flink，那处理时间就是 10:00:03。

为什么？举个例子。你在统计「每分钟下单用户数」。如果按处理时间算，10:00:00 到 10:00:59 这分钟的数据，可能因为延迟被算到下一分钟。那报表上的峰值就永远不准。我在项目中遇到过，业务方拿着处理时间聚合的曲线图来找我，说「你们实时数据怎么跟离线差这么多？」——查了半天，就是时间语义没选对。

对比维度	事件时间	处理时间
时间来源	数据自身携带	引擎系统时钟
对乱序容忍度	高（配合水位线）	低（谁先到算谁）
结果确定性	可重算、可回溯	每次重跑结果可能不同
延迟	需要等待迟到数据	无等待，延迟最低
适用场景	精确指标、离线对账	简单告警、快速看板

水位线（Watermark）：乱序数据的交通警察

事件时间虽好，但有个麻烦：数据会乱序。比如用户 10:00:01 的点击，可能比 10:00:00 的还晚到。这时候窗口该不该关？关了，迟到的数据就丢了；不关，窗口永远不触发。

水位线就是来解决这个问题的。它本质上是一个「时间进度标记」，告诉引擎：到这个时间点为止，我认为该来的数据都来差不多了，可以触发计算了。

举个例子。你设置水位线延迟为 5 秒。当引擎收到一条事件时间为 10:00:10 的数据时，它会推算：水位线 = 10:00:10 - 5s = 10:00:05。这意味着，10:00:05 之前的数据，引擎认为已经到齐了，可以放心关窗。

水位线的生成方式有两种：

• 周期性水位线：每隔 N 毫秒生成一次，基于当前已收到数据的最大事件时间减去延迟。最常用。
• 标点水位线：数据流中携带特殊标记，遇到标记就推进水位线。适合数据源本身有批次边界的情况。

代码里怎么配？Flink 的写法大致是这样：

DataStream<Event> stream = env
    .addSource(kafkaConsumer)
    .assignTimestampsAndWatermarks(
        WatermarkStrategy.<Event>forBoundedOutOfOrderness(Duration.ofSeconds(5))
            .withTimestampAssigner((event, timestamp) -> event.getEventTime())
    );

注意，forBoundedOutOfOrderness 是固定延迟，适合大部分场景。如果数据延迟波动很大，可以考虑用 forGenerator 自定义水位线逻辑。

窗口类型：Tumble、Hop、Session

窗口就是把无限流切成有限块的手段。DWS 层最常见的三种窗口，我一个个说。

滚动窗口（Tumble Window）

固定大小，不重叠。比如每 5 分钟一个窗口，10:00~10:05、10:05~10:10……每条数据只属于一个窗口。

适合场景：每 5 分钟统计一次实时 GMV、每分钟的活跃用户数。

// Flink SQL 示例
SELECT 
    TUMBLE_START(event_time, INTERVAL '5' MINUTE) AS window_start,
    COUNT(DISTINCT user_id) AS dau
FROM page_views
GROUP BY TUMBLE(event_time, INTERVAL '5' MINUTE);

滑动窗口（Hop Window）

固定大小，但可以重叠。比如窗口大小 10 分钟，滑动步长 5 分钟。那 10:00~10:10、10:05~10:15 两个窗口会同时存在。每条数据可能出现在多个窗口里。

适合场景：需要平滑曲线的指标，比如每 5 分钟看过去 10 分钟的实时转化率。

会话窗口（Session Window）

没有固定大小，按数据之间的「空闲间隔」来切分。比如用户连续操作，间隔不超过 30 秒，就属于同一个会话；超过 30 秒没动作，就关闭当前会话，开启下一个。

适合场景：用户行为路径分析、单次访问时长统计。

// Flink DataStream API 示例
stream
    .keyBy(event -> event.getUserId())
    .window(EventTimeSessionWindows.withGap(Time.seconds(30)))
    .apply(new SessionWindowFunction());

三种窗口对比速查

窗口类型	是否重叠	大小固定	典型场景	状态开销
滚动窗口	否	是	分钟级聚合、定时报表	低
滑动窗口	是	是	平滑曲线、滚动指标	中~高
会话窗口	否	否	用户行为、访问时长	高（需跟踪每个 key）

一张图理清核心逻辑

下面这张图展示了事件时间、水位线、窗口三者的协作关系。数据从左到右流动，水位线像一把尺子，标记着「哪些时间窗口可以安全关闭」。

从图上能看明白：数据乱序不可怕，水位线就是用来兜底的。只要迟到数据不超过水位线设定的延迟，它依然能进入正确的窗口。窗口的触发时机，由水位线决定，而不是由数据到达时间决定。