流处理（Stream Processing）

流处理是一种以连续数据流为核心的数据处理范式，强调对"实时产生、实时传递、实时计算"的数据进行持续响应。它不仅是一种计算模型，也是一种用于构建实时应用、实时分析系统、实时数据集成平台的架构方法论。

本篇文档从本质模型、关键概念、设计模式、时间语义、容错模型到 Streaming SQL 与流表关系进行系统性升维整理，为理解现代流式系统（Kafka Stream / Flink / Beam / Spark Streaming）的统一认知框架提供参考。

流处理的本质

流处理从根本上解决的是以下问题：

  1. 如何处理无界数据（Unbounded Data）？ 即永不停止增长的数据序列。

  2. 如何保持系统在时间上的一致性与准确性？ 包含事件时间、乱序处理、水位线、触发器、延迟处理等。

  3. 如何管理跨时间演化的状态？ 包含本地状态、长久状态、快照、回放、容错机制等。

  4. 如何让计算逻辑在分布式环境下具备可恢复性、可扩展性与精确一次性语义？

  5. 如何抽象流与表之间的关系？ 包含 CDC、事件溯源、流表双向转换、流式 Join 等。

流处理本质上是一种 “带状态的事件驱动系统”，在无限事件流上做有限时间窗内的滑动计算，并具备可恢复、可重复、可重放的能力。

流处理的应用类型

流处理的典型能力可归纳为三类：

复杂事件处理（CEP）

根据定义好的事件模式检测数据流中是否发生模式事件（如“连续三次失败登录”）。本质是对事件序列进行实时图灵识别。

流分析（窗口分析）

在时间窗口内执行聚合计算，如 5 秒平均、10 分钟 UV、1 小时滑动累计等。

流式 RPC（Streaming RPC）

使用流作为通信方式，实现持续响应的交互模式，如“观察模式”“增量更新模式”“实时订阅”。

消息系统与流处理

演进：从消息队列到分区日志

早期流处理常通过 MQ 级联方式实现：

stateDiagram
  direction LR
  数据源 --> 消息队列1
  消息队列1 --> 处理逻辑1
  处理逻辑1 --> 消息队列2
  消息队列2 --> 处理逻辑3
  消息队列2 --> 处理逻辑4
  处理逻辑3 --> 消息队列3
  处理逻辑4 --> 消息队列3

传统 MQ 存在两个限制：

分区日志消息系统：消息系统与数据库的融合

Kafka/Kinesis/Pulsar 等“分区日志系统”使流可以像数据库日志那样存储，并通过偏移量实现回放、重算。这是现代流平台的关键基石。

每个逻辑数据源都可以建模为它自己的日志

日志成为系统“中枢神经”：

graph TB
    subgraph 以日志为中心的基础设施栈
        A[Log]
        B[Graph DB, OLAP Store, Etc]
        C[Key-Value Query Layer]
        D[Search Query Layer]
        E[Monitoring & Graphs]
        F[Stream Processing]
        G[Hadoop]
        
        B --> A
        C --> A
        A --> C
        D --> A
        E --> A
        F --> A
        A --> F
        G --> A
        A --> G
    end

这形成了“Log-Centric Architecture”。

流处理设计模式（Patterns）

单事件分类处理

---
title: 单事件处理
---
stateDiagram-v2
    direction LR
    主题 --> 分支: 日志事件
    分支 --> 高优先级主题: 错误事件
    分支 --> 低优先级主题: 其他事件
    高优先级主题 --> 转换成Avro
    低优先级主题 --> 转换成Avro
    转换成Avro --> Avro日志

用于事件分流、路由、格式转换。

本地状态聚合

---
title: 本地状态事件处理
---
stateDiagram-v2
    direction LR
    state 处理器 {
        本地状态 --> 聚合min,max
        聚合min,max --> 本地状态
    }
    交易主题 --> 聚合min,max
    聚合min,max --> 交易聚合主题

单处理器内部维护可累积的局部状态，如 min/max/count。

多阶段流水线处理

---
title: 多阶段处理
---
stateDiagram-v2
    state 每日获利处理器1 {
        本地状态1 --> 每日获利或损失1
        每日获利或损失1 --> 本地状态1
    }
    state 每日获利处理器2 {
        本地状态2 --> 每日获利或损失2
        每日获利或损失2 --> 本地状态2
    }
    state top10处理器 {
        top10本地状态 --> top10
        top10 --> top10本地状态
    }
    交易主题 --> 每日获利或损失1
    交易主题 --> 每日获利或损失2
    每日获利或损失1 --> 每日获利或损失主题
    每日获利或损失主题 --> top10
    top10 --> top10主题

多阶段计算串联是构建实时指标体系的核心架构。

外部数据补全（Enrichment）

---
title: 外部数据源填充
---
stateDiagram-v2
    direction LR
    state 处理器 {
        用户信息本地缓存 --> 连接
        连接 --> 用户信息本地缓存
    }
    点击事件主题 --> 连接
    用户信息数据库 --> 用户信息主题: cdc
    用户信息主题 --> 连接
    连接 --> 填充的点击事件主题

典型场景：用户画像、商品信息补全。

流处理与数据库

流和数据库的关系可用统一视角描述：

也就是“流是表的增量，表是流的累积”。

CDC：数据库 → 流

---
title: 带有快速追随者分析数据库的变更数据获取
---
graph LR
    A[应用程序]
    B[生产数据库]
    C[分析快速跟随数据库]
    D[分析]

    A -- 生产事务 --> B
    B -- CDC --> C
    C -- 查询 --> D

CDC 是现代实时数据平台的核心。

DataFlow 模型（Beam 模型）

DataFlow / Beam 在抽象层面定义了流式计算的关键操作：

其强项在于统一批与流模型。

时间语义：事件时间、处理时间、水位线

为什么时间很重要？

流处理是“在时间上分布的数据”，而时间本身可能乱序、延迟或缺失，因此必须保证“语义正确”。

两种时间

事件时间和处理时间在实际流处理系统中的关系

事件时间更准确，处理时间更实时。

水位线（Watermark）

水位线用于推断“事件时间已经前进到某个点，可以执行窗口计算”。

sequenceDiagram
    participant Source as 数据源
    participant System as 流处理系统
    participant Window as 窗口计算
    ...

（水位线图保持原样，此处省略描述）

水位线核心作用：

完美水位线几乎不存在，现代系统均使用启发式水位线。

数据处理模式

时间无关模式

无需窗口，延迟最小。

过滤 内连接 近似算法 流式TopK 流式 K-mean 等

窗口化处理（Windowing）

三大窗口：

  1. **固定窗口**
  2. **滑动窗口**
  3. **会话窗口**

三种窗口类型

事件时间窗口 = 正确但需要缓存 处理时间窗口 = 实时但不稳定

基于事件时间进行窗口划分

触发器（Triggers）

决定窗口何时输出结果。

类型包括：

这是现代流系统输出的核心机制。

精确一次性（Exactly once）

包含：

方法包括：

容错与状态管理

微批处理

小批作为容错单元（Spark Streaming）。

校验点（Checkpoint）

系统恢复的基本能力（Flink、Beam）。

状态类型

隐式状态

仅依赖执行顺序，不可持久化。

广义状态

Flink/Beam 提供的可持久、可并行的结构化状态。

Streaming SQL

实现“用 SQL 处理流”。

关键思想：

两种模型最终都支持实时计算，但抽象不同。

流式连接（Stream Join）

支持：

保留原图：

---
title: 表连接
---
...

流与表的统一模型

流与表是可相互转换的：

可用于统一批与流：

graph TD
    A[Table] --> B[MapRead]
    ...

完整总结：流处理的统一认知框架

  1. **流是无限，表是有限。流是增量，表是快照。**
  2. **事件时间是语义正确的时间，处理时间是执行时间。**
  3. **水位线解决乱序事件，触发器解决何时输出。**
  4. **状态是流处理的灵魂，日志是系统的记忆。**
  5. **容错依赖快照 + 回放。**
  6. **流与表通过 CDC / 聚合 / 事件溯源等机制双向转换。**
  7. **DataFlow 统一了批处理与流处理。**
  8. **Streaming SQL 将流视为表的持续计算。**

关联内容（自动生成）