📚 课程目录第3章实时数据处理基础

实时数据处理基础：流处理概念、事件时间与处理时间、窗口计算、水位线机制

在实时数据湖仓架构中，流处理是支撑“实时”二字的底层引擎。与传统的批量处理（Batch Processing）不同，流处理面对的是无界数据流——数据永远在产生，没有明确的起点和终点。要正确理解实时链路中的延迟、乱序与聚合结果，必须先掌握四个核心概念：流处理的基本模型、两种时间语义、窗口计算类型以及水位线机制。

一、核心原理：从有界批处理到无界流处理

批处理模型假设数据是有界的，即数据已经完整落盘，可以一次性读取并计算。而流处理模型将数据视为无界的连续事件序列，每条记录携带时间戳，系统在数据到达时立即处理，或按时间窗口进行微批聚合。下图展示了两种模型在数据视图上的本质差异：

流处理的核心优势在于低延迟与事件驱动。当一条交易记录进入Kafka主题，Flink或Spark Structured Streaming可以立即对该事件进行过滤、转换或聚合，而不必等待“今天所有数据都到齐”。但这也带来了新的挑战：数据可能乱序到达，且系统需要决定“何时触发计算、何时认为某个时间段的数据已经完整”。

二、事件时间与处理时间：两种时间语义

流处理中必须区分两种时间概念，否则窗口聚合结果将不可靠：

时间类型	定义	典型来源	优点	缺点
事件时间（Event Time）	事件实际发生的时间，由业务系统在数据产生时写入时间戳	传感器采集时间、用户点击时间、订单创建时间	反映业务真实时序，不受处理速度影响，结果可复现	需要处理乱序与延迟，需配合水位线
处理时间（Processing Time）	事件被流处理引擎处理的当前系统时间	Flink/Spark 所在节点的 wall clock	实现简单，延迟最低	结果受系统负载、重启、背压影响，不可复现

以电商订单为例：用户在 2025-01-15 10:23:05 下单（事件时间），但消息在 Kafka 中积压，直到 10:25:40 才被 Flink 消费（处理时间）。如果按处理时间做“每分钟订单量”统计，该订单会被归入 10:25 那一分钟，这显然歪曲了业务事实。因此，实时数仓中绝大多数业务统计都应使用事件时间，只有对时间精度不敏感或用于监控系统自身健康度的场景才使用处理时间。

三、窗口计算：将无界流切分为有界块

无界流无法直接进行“总数”“平均值”等有限聚合，必须通过窗口将数据切分为有限集合。窗口类型的选择直接影响统计口径与延迟。常见窗口类型如下：

滚动窗口（Tumbling Window）：固定长度、不重叠。例如每5分钟统计一次订单总额，窗口为 [10:00, 10:05)、[10:05, 10:10)……
滑动窗口（Sliding Window）：固定长度但可重叠。例如每1分钟滑动一次，统计最近5分钟的UV，窗口长度为5分钟，滑动步长为1分钟。
会话窗口（Session Window）：按不活动间隔切分。例如用户连续操作超过30秒无新事件则结束当前会话，适合分析用户行为路径。
全局窗口（Global Window）：所有数据归入一个窗口，需自定义触发条件，通常配合 CountTrigger 使用。

在 Flink SQL 中，滚动窗口的声明方式如下：

-- 每5分钟滚动窗口，统计订单金额
SELECT 
  TUMBLE_START(ts, INTERVAL '5' MINUTE) AS win_start,
  TUMBLE_END(ts, INTERVAL '5' MINUTE)   AS win_end,
  SUM(amount) AS total_amount
FROM orders
GROUP BY TUMBLE(ts, INTERVAL '5' MINUTE);

窗口的触发时机由水位线决定，而非由系统时钟决定。这意味着即使数据晚到，只要未超过水位线允许的延迟范围，仍可被正确归入所属窗口。

四、水位线机制：应对乱序与延迟的“时钟”

水位线（Watermark）是流处理引擎中用于表示“事件时间进度”的特殊标记。它声明：所有时间戳小于等于该水位线的事件均已到达。水位线通常以“当前最大事件时间 - 允许的最大乱序延迟”的方式生成。

例如，设置最大乱序延迟为 10 秒，当前已观察到事件时间最大为 10:30:45，则水位线推进到 10:30:35。当水位线越过窗口的结束时间（如 10:30:00 窗口的结束边界），引擎便触发该窗口的计算并输出结果。

水位线生成策略（Flink 示例）

DataStream<Order> stream = env
  .addSource(kafkaConsumer)
  .assignTimestampsAndWatermarks(
    WatermarkStrategy.<Order>forBoundedOutOfOrderness(
        Duration.ofSeconds(10))   // 允许10秒乱序
      .withTimestampAssigner((event, ts) -> event.getEventTime())
  );

水位线的推进遵循以下规则：

水位线单调递增，不会倒退。
每条记录到达后，引擎更新当前最大事件时间，并重新计算水位线。
当水位线 >= 窗口结束时间 + 窗口允许的延迟（如有），则触发窗口计算并销毁窗口状态。
迟到的数据（事件时间 < 水位线）默认被丢弃，但可通过 allowedLateness 或侧输出流（Side Output）捕获处理。

五、案例：实时订单金额分钟级统计

假设某电商平台需要统计“每分钟的订单总金额”，数据从业务库通过 CDC 进入 Kafka，订单事件包含 order_time（事件时间）。由于网络抖动或 CDC 同步延迟，部分订单可能晚到 5~15 秒。我们采用如下配置：

事件时间：order_time
窗口：1分钟滚动窗口
水位线：允许 10 秒乱序延迟
迟到数据处理：允许 30 秒延迟，超过则写入侧输出流

当水位线推进到 10:01:10 时（即最大事件时间达到 10:01:20），引擎触发 [10:00:00, 10:01:00) 窗口的计算。此时若有一条 order_time=10:00:58 的订单在 10:01:15 才到达，由于水位线尚未超过 10:01:10，该订单仍可被正确归入 10:00 窗口。若订单在 10:01:35 才到达，则已超过水位线，但仍在 allowedLateness(30s) 范围内，引擎会重新触发 10:00 窗口的更新计算并输出修正后的结果。

六、常见误区与复盘

误区一：将处理时间当作事件时间使用。 当业务系统与流处理集群存在时钟偏差，或数据经过消息队列积压时，处理时间会严重偏离业务时间，导致窗口统计失真。复盘建议：所有业务分析场景一律使用事件时间，并在源头为每条记录打上事件时间戳。

误区二：水位线设置过小或过大。 水位线过小（如 1 秒）会导致大量乱序数据被丢弃；水位线过大（如 10 分钟）则窗口结果迟迟不输出，增加端到端延迟。复盘建议：根据业务实际延迟分布（P95/P99）设置水位线，并配合 allowedLateness 处理极端迟到数据。

误区三：忽略窗口状态大小。 滑动窗口若步长很小而窗口很长（如窗口1小时、步长1秒），会维护大量重叠窗口状态，导致内存压力。复盘建议：评估窗口数量上限，必要时改用滚动窗口 + 增量聚合，或使用 Flink 的 ContinuousEventTimeTrigger 优化。

最后需要明确：水位线不是万能的，它只是“概率性”地保证数据完整性。在实时数据湖仓中，通常采用批流一体架构——流处理负责秒级/分钟级低延迟统计，批处理（或数据湖的增量读取）在小时级或天级对结果进行修正，从而在延迟与准确性之间取得平衡。理解上述基础概念，是设计可靠实时链路的前提。