bittern.cn
11

流处理

实时数据的力量

阅读量：2 · 预计 20 分钟读完

事件流Kafka时间语义Exactly-once
关联层级：L7 应用抽象
阅读进度4%

第十一章 流处理 - 实时数据的力量

导读

如果说批处理是"事后分析"，那么流处理就是"实时响应"。流处理（Stream Processing）将数据视为一个无界的、持续到达的事件流，在数据到达时立即处理，而不是等待数据积累到一定量后再批量处理。

流处理的核心优势是低延迟——从数据产生到处理结果可用，延迟可以从批处理的分钟/小时级降低到毫秒/秒级。这使得流处理成为实时分析、事件驱动架构、实时监控等场景的理想选择。

本章将深入探讨流处理的核心概念：事件时间 vs 处理时间、窗口操作、流 joins、容错机制，以及主流流处理框架（Kafka Streams、Flink、Spark Streaming）的设计哲学。

核心概念详解

11.1 事件与事件流

11.1.1 事件的定义

事件（Event）是对"某件事在某个时间发生了"的记录。一个事件通常包含：

  • 事件类型：发生了什么事？（如"用户下单"、"支付成功"、"传感器报警"）
  • 事件时间：事情是什么时候发生的？
  • 事件数据：事情的详细信息是什么？（如订单 ID、用户 ID、金额）
  • 事件键（可选）：用于分区的键（如用户 ID），确保相关事件被路由到同一个分区。

事件的特点：

  • 不可变（Immutable）：事件一旦记录就不能修改。如果需要更正，只能追加一个新事件。
  • 持久化（Durable）：事件被写入持久存储（如 Kafka），不会丢失。
  • 有序（Ordered）：在同一个分区内，事件是有序的。

11.1.2 事件流

事件流（Event Stream / Message Stream）是一个无界的、持续到达的事件序列。

事件流的特点：

  • 无界（Unbounded）：没有结束标记，理论上永远有新事件到达。
  • 有序（Ordered）：在同一个分区内，事件按到达顺序排列。
  • 可重放（Replayable）：事件被持久化存储，可以被多次消费。

典型的事件流来源：

  • 用户行为：点击、搜索、下单、支付。
  • 系统事件：日志、指标、告警。
  • IoT 数据：传感器读数、设备状态。
  • 金融交易：股票交易、支付清算。

11.1.3 消息队列与事件流

消息队列（Message Queue）和事件流（Event Stream）在概念上有重叠，但设计目标不同：

消息队列（如 RabbitMQ、ActiveMQ）：

  • 设计目标：可靠地传递消息，消息被消费后通常删除。
  • 消息是"任务"——消费者处理消息后，消息的使命完成。
  • 通常不支持消息重放。

事件流平台（如 Kafka、Pulsar）：

  • 设计目标：持久化事件流，支持多次消费。
  • 事件是"事实"——被记录后永久保存，可以被多个消费者独立处理。
  • 支持消息重放，可以从任意位置重新消费。

Kafka 的成功在于它将消息队列和事件流合二为一——既提供了消息队列的可靠性，又提供了事件流的可重放性。

11.2 事件时间 vs 处理时间

11.2.1 两种时间的区别

在流处理中，有两种重要的时间概念：

事件时间（Event Time）：事件实际发生的时间，记录在事件中。

  • 例如：用户在 10:00 点击了一个按钮，事件时间就是 10:00。

处理时间（Processing Time）：事件被流处理引擎处理的时间。

  • 例如：事件在 10:05 被处理引擎读取和处理，处理时间就是 10:05。

两者的差异来源：

  • 网络延迟：事件从产生到被处理引擎读取需要时间。
  • 排队延迟：事件在消息队列中排队等待。
  • 时钟偏移：事件产生节点和处理引擎节点的时钟不一致。

11.2.2 为什么事件时间很重要

使用事件时间还是处理时间，对结果有重大影响。

例如，统计每小时的订单量：

  • 使用事件时间：订单按实际下单时间统计。10:00-11:00 的订单包括所有在这个时间段下单的订单，即使它们延迟到达。
  • 使用处理时间：订单按被处理的时间统计。一个 10:59 下单但 11:01 才被处理的订单，会被统计到 11:00-12:00 的窗口中。

对于大多数业务场景，事件时间是正确的选择——我们关心的是"事情什么时候发生的"，而不是"我们什么时候知道的"。

11.2.3 乱序事件

由于网络延迟和时钟偏移，事件可能乱序到达——处理引擎先收到事件时间较晚的事件，后收到事件时间较早的事件。

处理乱序事件的策略：

Watermark（水位线）：

  • Watermark 是一个时间戳，表示"事件时间小于 Watermark 的事件都已经到达"。
  • 当 Watermark 推进到某个窗口的结束时间时，窗口关闭，计算结果。
  • 如果 Watermark 之后还有迟到事件到达，可以选择忽略、更新结果或触发侧输出。

窗口延迟（Allowed Lateness）：

  • 在窗口关闭后，仍然等待一段时间，接收迟到事件。
  • 迟到事件到达时，更新窗口结果。
  • 延迟时间结束后，窗口结果不再更新。

11.3 窗口操作

11.3.1 窗口的类型

窗口（Window）是将无界流分割为有界块进行处理的机制。常见的窗口类型：

滚动窗口（Tumbling Window）：

  • 固定大小、不重叠的窗口。
  • 例如：每 5 分钟一个窗口，[0:00-5:00)、[5:00-10:00)、[10:00-15:00)。
  • 每个事件只属于一个窗口。

滑动窗口（Sliding Window）：

  • 固定大小、重叠的窗口。
  • 例如：每 1 分钟滑动一次的 5 分钟窗口，[0:00-5:00)、[1:00-6:00)、[2:00-7:00)。
  • 一个事件可能属于多个窗口。

会话窗口（Session Window）：

  • 大小不固定，由活动间隔（Session Gap）决定。
  • 如果一段时间内没有新事件到达，会话结束。
  • 例如：用户行为分析中，如果用户 30 分钟没有操作，认为会话结束。

全局窗口（Global Window）：

  • 所有事件属于同一个窗口。
  • 需要自定义触发器来决定何时计算结果。

11.3.2 窗口的实现

窗口的实现需要考虑以下问题：

状态管理：

  • 每个窗口需要维护状态（如计数器、累加器）。
  • 状态可能很大（如数百万个窗口），需要高效的存储。
  • 窗口关闭后，状态需要清理。

迟到事件：

  • 窗口关闭后到达的事件如何处理？
  • 忽略？更新结果？触发侧输出？

窗口合并：

  • 对于会话窗口，两个窗口可能因为新事件的到达而合并。
  • 合并时需要将两个窗口的状态合并。

11.4 流 Joins

11.4.1 流-表 Join（Stream-Table Join）

流-表 Join 是将事件流与一个表（数据库、KV 存储）进行关联。

例如：订单流与用户表 Join，获取每个订单的用户信息。

实现方式：

  • 对于每个订单事件，查询用户表获取用户信息。
  • 用户表可以是本地缓存、远程数据库或物化视图。

挑战：

  • 用户表可能更新，如何处理？
  • 如果用户信息在订单之后更新，是否需要重新计算？

11.4.2 流-流 Join（Stream-Stream Join）

流-流 Join 是将两个事件流进行关联。

例如：订单流和支付流 Join，匹配订单和对应的支付。

实现方式：

  • 维护两个流的状态（如最近 N 分钟的订单和支付）。
  • 当一个事件到达时，在另一个流的状态中查找匹配。
  • 匹配成功后，输出 Join 结果。

挑战：

  • 两个流的事件可能乱序到达，需要等待一段时间。
  • 状态可能很大，需要高效的存储和清理机制。
  • 如何处理不匹配的事件（如订单没有支付、支付没有订单）？

11.4.3 时间窗口 Join

为了限制状态大小和等待时间，流-流 Join 通常使用时间窗口：

  • 只 Join 时间相近的事件（如订单和支付的时间差不超过 1 小时）。
  • 超过窗口的事件不再 Join，作为"未匹配"处理。

11.5 容错与状态管理

11.5.1 流处理的容错挑战

流处理的容错比批处理更复杂，因为：

  • 流是无界的，不能简单地重新处理。
  • 流处理维护状态，状态需要恢复。
  • 流处理的输出可能已经发送到下游，不能简单地撤回。

11.5.2 微批处理（Micro-Batch）

Spark Streaming 采用微批处理策略：

  • 将流数据按时间切片（如 1 秒），每个切片作为一个批处理作业。
  • 使用 Spark 的批处理引擎处理每个微批。
  • 容错通过 Spark 的 RDD 血统机制实现。

优势：

  • 复用 Spark 的批处理引擎，容错机制成熟。
  • 吞吐量高。

劣势：

  • 延迟受限于微批大小（至少秒级）。
  • 状态管理不如原生流处理引擎灵活。

11.5.3 原生流处理（Native Stream Processing）

Flink 和 Kafka Streams 采用原生流处理策略：

  • 每个事件独立处理，不等待批。
  • 状态存储在本地（RocksDB）或分布式 KV 存储中。
  • 通过检查点（Checkpoint）实现容错。

检查点机制（Flink）：

  • 定期（如每 10 秒）对所有任务的状态做快照。
  • 快照写入持久存储（如 HDFS、S3）。
  • 如果任务失败，从最近的检查点恢复状态，重新处理检查点之后的事件。
  • 使用Chandy-Lamport 算法保证分布式快照的一致性。

Exactly-Once 语义：

  • Flink 通过检查点 + 两阶段提交实现端到端的 Exactly-Once 语义。
  • 源端：记录消费位点，恢复时从检查点的位点重新消费。
  • 处理端：状态从检查点恢复。
  • 输出端：使用两阶段提交，确保输出只在检查点成功时才可见。

11.5.4 状态后端

流处理引擎需要高效的状态管理。常见的状态后端：

内存状态后端：

  • 状态存储在 JVM 堆内存中。
  • 优势：速度快。
  • 劣势：状态大小受内存限制，GC 可能影响性能。

RocksDB 状态后端：

  • 状态存储在 RocksDB（本地磁盘）中。
  • 优势：状态大小不受内存限制，可以存储 TB 级状态。
  • 劣势：读写速度比内存慢。

混合状态后端：

  • 热数据在内存中，冷数据在 RocksDB 中。
  • 自动管理数据在内存和磁盘之间的迁移。

重要知识点

知识点 1：Exactly-Once vs At-Least-Once vs At-Most-Once

流处理的语义保证：

At-Most-Once（最多一次）：

  • 每个事件最多被处理一次。
  • 如果处理失败，事件丢失。
  • 实现最简单，但可能丢失数据。

At-Least-Once（至少一次）：

  • 每个事件至少被处理一次。
  • 如果处理失败，事件会被重新处理。
  • 可能导致重复处理，需要下游幂等。

Exactly-Once（精确一次）：

  • 每个事件恰好被处理一次。
  • 即使处理失败，也不会丢失或重复。
  • 实现最复杂，需要检查点 + 两阶段提交。

选择哪种语义取决于业务需求：

  • 日志收集：At-Least-Once 足够（少量重复可以接受）。
  • 金融交易：需要 Exactly-Once（不能丢失或重复）。
  • 实时监控：At-Most-Once 可以接受（少量丢失不影响趋势）。

知识点 2：背压（Backpressure）

背压是指下游处理速度跟不上上游数据产生速度时，压力向上游传播的现象。

背压的处理策略：

有界缓冲（Bounded Buffer）：

  • 在上下游之间设置有限大小的缓冲区。
  • 当缓冲区满时，上游停止发送数据。
  • 优势：防止内存溢出。
  • 劣势：可能导致上游阻塞，延迟增加。

丢弃策略：

  • 当缓冲区满时，丢弃新到达的事件。
  • 优势：不会阻塞上游。
  • 劣势：数据丢失。

采样/降采样：

  • 当压力过大时，只处理部分事件（如每 10 个事件处理 1 个）。
  • 优势：减少处理量，降低延迟。
  • 劣势：结果不准确。

自动扩缩容：

  • 当压力过大时，自动增加处理节点。
  • 优势：动态适应负载。
  • 劣势：扩缩容有延迟，可能来不及应对突发流量。

Flink 的背压机制：

  • 使用有界缓冲区 + 基于 Credit 的流控。
  • 下游向上游发送 Credit（可用缓冲区大小），上游只在有 Credit 时发送数据。
  • 自动传播背压，无需手动干预。

知识点 3：流处理的确定性

流处理的确定性是指：给定相同的输入流，流处理引擎总是产生相同的输出。

确定性的挑战：

  • 时间依赖：如果处理逻辑依赖当前时间（如 System.currentTimeMillis()），不同执行时间可能产生不同结果。
  • 随机性：如果处理逻辑使用随机数，不同执行可能产生不同结果。
  • 外部状态：如果处理逻辑依赖外部状态（如数据库），外部状态的变化可能导致不同结果。

保证确定性的策略：

  • 使用事件时间而非处理时间。
  • 避免使用随机数，或使用可重现的随机种子。
  • 将外部状态纳入事件流（通过 Change Data Capture）。

知识点 4：Kafka 的日志结构

Kafka 的核心是一个分布式日志系统：

Topic 与 Partition：

  • Topic 是消息的逻辑分类。
  • Partition 是 Topic 的物理分片，每个 Partition 是一个有序的、不可变的消息序列。
  • 消息通过 Key 哈希到 Partition，保证同一 Key 的消息在同一个 Partition 中有序。

消费者组（Consumer Group）：

  • 多个消费者可以组成一个消费者组。
  • 每个 Partition 只能被组内的一个消费者消费。
  • 不同消费者组独立消费，互不影响。

Offset：

  • 每个消费者维护一个 Offset，表示已经消费到的位置。
  • Offset 可以手动或自动提交。
  • 消费者可以重置 Offset，重新消费历史消息。

常见误区

误区 1："流处理可以完全替代批处理"

纠正：流处理和批处理有不同的适用场景。流处理适合实时性要求高、数据量适中的场景；批处理适合数据量大、实时性要求低的场景。很多系统同时使用流处理和批处理（Lambda 架构），流处理提供实时结果，批处理提供准确的最终结果。

误区 2："事件时间和处理时间差不多，可以混用"

纠正：事件时间和处理时间可能有显著差异，特别是在网络延迟大、数据乱序到达的场景中。使用处理时间可能导致统计结果不准确（如将 10:59 的事件统计到 11:00 的窗口中）。对于需要准确性的场景，应该使用事件时间 + Watermark 机制。

误区 3："Exactly-Once 总是最好的选择"

纠正：Exactly-Once 的实现代价高（检查点、两阶段提交），会增加延迟和资源消耗。对于很多场景（如日志收集、实时监控），At-Least-Once 已经足够。选择语义保证应该根据业务需求，而不是一味追求 Exactly-Once。

误区 4："流处理不需要状态管理"

纠正：大多数流处理应用都需要状态——窗口聚合、流 Joins、去重等都需要维护状态。状态管理是流处理引擎的核心能力之一。状态的大小、访问速度、容错机制直接影响流处理应用的性能和可靠性。

误区 5："Kafka 只是一个消息队列"

纠正：Kafka 不仅仅是一个消息队列，它是一个事件流平台。它的核心特性包括：

  • 持久化存储：消息被持久化到磁盘，可以长期保存。
  • 可重放：消费者可以从任意位置重新消费消息。
  • 多消费者组：多个消费者组独立消费同一份数据。
  • Exactly-Once 语义：通过事务支持端到端的 Exactly-Once。

这些特性使得 Kafka 成为流处理生态系统的核心组件。

实践应用

实践 1：设计流处理应用

设计流处理应用的步骤：

定义事件：明确事件的格式、时间戳、键。

选择时间语义：根据业务需求选择事件时间或处理时间。

设计窗口：根据分析需求选择合适的窗口类型和大小。

设计 Joins：如果需要关联多个流或表，设计 Join 策略。

选择语义保证：根据业务需求选择 At-Least-Once 或 Exactly-Once。

设计状态管理：确定状态的大小、访问模式、清理策略。

实践 2：选择流处理框架

根据场景选择合适的流处理框架：

场景推荐框架理由
简单事件处理Kafka Streams轻量级，与 Kafka 深度集成
复杂事件处理Flink功能强大，支持复杂窗口和 Joins
批流统一Flink / Spark统一引擎，减少复杂性
实时分析Flink / Druid低延迟，高吞吐
微批处理Spark Streaming复用 Spark 生态

实践 3：监控流处理应用

流处理应用的关键监控指标：

吞吐量：每秒处理的事件数。

延迟：从事件产生到处理完成的时间（事件时间到处理时间的差）。

背压：下游处理是否跟得上上游？

Checkpoint 状态：Checkpoint 是否成功？耗时多长？

状态大小：状态存储占用了多少空间？

消费者 Lag：消费者落后生产者多少？

实践 4：处理迟到事件

处理迟到事件的策略：

Watermark + Allowed Lateness：

- 设置 Watermark 和允许的延迟时间。

- 在延迟时间内到达的迟到事件更新窗口结果。

- 延迟时间后到达的事件被丢弃或发送到侧输出。

侧输出（Side Output）：

- 将迟到事件发送到侧输出流。

- 侧输出流可以单独处理（如更新数据库、发送告警）。

Lambda 架构：

- 流处理提供实时但不精确的结果。

- 批处理定期重算，提供精确的最终结果。

- 流处理的结果被批处理的结果覆盖。

本章小结

本章深入探讨了流处理的核心概念和实践：

事件与事件流：

- 事件是对"某件事在某个时间发生了"的记录，不可变、持久化、有序。

- 事件流是无界的、持续到达的事件序列。

- Kafka 等事件流平台提供持久化、可重放的消息存储。

事件时间 vs 处理时间：

- 事件时间是事件实际发生的时间，处理时间是事件被处理的时间。

- 对于大多数业务场景，事件时间是正确的选择。

- Watermark 机制处理乱序事件。

窗口操作：

- 滚动窗口、滑动窗口、会话窗口、全局窗口。

- 窗口将无界流分割为有界块进行处理。

流 Joins：

- 流-表 Join：事件流与数据库表关联。

- 流-流 Join：两个事件流关联，需要维护状态和处理乱序。

容错与状态管理：

- 微批处理（Spark Streaming）：将流切片为批处理。

- 原生流处理（Flink、Kafka Streams）：检查点 + 状态快照。

- Exactly-Once 语义需要检查点 + 两阶段提交。

关键概念：

- 语义保证：At-Most-Once、At-Least-Once、Exactly-Once。

- 背压：下游处理速度跟不上上游时的流控机制。

- 确定性：相同输入产生相同输出。

流处理是实时数据系统的核心。理解事件时间、窗口、流 Joins、状态管理等概念，是构建可靠流处理应用的基础。选择合适的流处理框架和语义保证，根据业务需求权衡延迟、吞吐量和一致性，是流处理系统设计的关键。

流处理的一个重要趋势是"流优先"（Stream-First）的设计理念。越来越多的系统开始将事件流作为数据的"真实来源"（Source of Truth），而非传统的数据库。在这种架构中，所有状态变更都首先记录为事件流中的事件，数据库的当前状态只是事件流的一个物化视图。这种设计带来了诸多好处：完整的变更历史（审计和回溯）、松耦合的系统集成（多个消费者独立处理同一事件流）、以及灵活的派生数据（从同一事件流可以派生出多种视图和报表）。

事件溯源（Event Sourcing）和 CQRS（命令查询责任分离）模式正是这种"流优先"理念的典型体现。在这些模式中，事件流不仅是系统间通信的媒介，更是数据存储的核心形式。这种架构特别适合需要完整审计追踪、支持时间旅行查询、以及需要灵活数据视图的业务场景。

此外，随着 Apache Flink 等引擎的成熟，流处理的编程模型也在不断简化。声明式的 SQL 接口（如 Flink SQL）使得开发者可以用熟悉的 SQL 语法编写流处理逻辑，而无需深入了解底层的状态管理和容错机制。这将大大降低流处理的技术门槛，推动实时数据处理在更广泛的场景中落地。