流处理

一句话

这一章讲流处理（stream processing）：把数据看成一条永不结束的事件流（unbounded stream），事件一到就处理，让派生结果（索引、缓存、实时指标、告警）持续贴近「此刻」。它和上一章批处理共用「不可变数据 + 派生」的世界观，只是把「有界的一大批」换成「无界的连续流」。两根支柱撑起全章：日志型消息代理（log-based message broker，如 Kafka）——一条持久、有序、可回放的事件日志；事件溯源 / 流表二象性——把「每一次变化」而非「最新状态」当作事实之源。一句反直觉：你以为流处理的难点是「算得快」，其实是「时间」——事件时间与处理时间的错位，才是这一章真正的深水区。

Glossary · 术语表

坐标

本章是全书 Part III「派生数据（Derived Data）」的第二块拼图，紧接上一章批处理（Ch10）。Ch10 处理有界、静态的一大批数据；本章掉头处理无界、实时的连续流。二者不是对手而是同一世界观的两副面孔——都把数据当不可变输入、从中派生结果，区别只在「批 vs 流」。它上承 Ch10 的批处理、也回收了 Ch5 复制里「复制日志」、Ch7「事务与 exactly-once」的伏笔；下启终章 Ch12——作者要用流的思路把整个数据系统重新组织。对应现实里的 Kafka / Flink / Spark Streaming 生态、实时数仓、风控与监控管线。

这章要解决什么

假设你在做一个电商风控系统：每秒涌进 50,000 笔交易，你要在用户点下「支付」到银行返回之间——不到 200 毫秒——判断这笔是不是盗刷。再假设运营要一块实时大屏，看当下每分钟的 GMV、各城市的下单热力。这类活的共同点是：结果的价值随时间飞快衰减，「今晚跑、明早出」的批处理彻底没用——等你算完，钱早被盗刷走了、大促也结束了。

可你又不能把批处理那套「每小时把全量从头算一遍」硬缩短到「每秒算一遍」——那会把机器和数据库压垮。真正要解决的是三个环环相扣的难题：① 怎么把源源不断的事件可靠、有序地从产生方送到处理方，还能在处理方崩溃重启后从断点续上、甚至回放历史；② 怎么让一处数据的变化实时、正确地传导到所有派生系统（搜索、缓存、报表），不让它们各说各话；③ 怎么在事件乱序、迟到的现实里，对「一个时间窗口」给出可信的聚合。不解决这些，你要么忍几小时延迟，要么写一堆脆弱的、丢消息又对不上账的实时脚本。

核心内容，讲透

一、事件与消息传递：从「删了就没」到「流水账可回放」

流处理的起点是怎么把事件从生产者送到消费者。最朴素的做法是让消费者不停轮询数据库看有没有新数据，但太笨。专门的消息代理（message broker）应运而生，历史上分两大流派——理解它们的差别，是理解 Kafka 为什么重要的关键：

• 传统消息队列（AMQP / JMS 风格，如 RabbitMQ、ActiveMQ）：像发快递——一条消息投递给消费者、对方签收（ack）确认后，broker 就把它删了。为了扩吞吐，常让多个消费者分摊一个队列（负载均衡）。问题是：消息一旦被消费就没了，没法回放；而且并发消费下消息的处理顺序容易乱。它擅长「任务分发」（每条消息只需被某一个 worker 处理一次，如发一封邮件）。
• 日志型消息代理（log-based broker，如 Kafka、Kinesis）：像报社的合订本——所有事件只追加、按顺序钉在一条持久日志上，读过也不删（按时间 / 容量保留，如留 7 天）。每个消费者自己维护一个偏移量（offset）当书签，读到哪记到哪。这带来两个杀手锏：①可回放——把 offset 往回拨，就能重读历史（调试、给新加的下游补算、代码修好后重跑）；②有序——同一分区内严格保序。为了扩展，日志按 key 分区（partition），每个分区内保序、跨分区并行，正是 Ch6 分区那套。

日志型 broker 的意义在于：它同时具备数据库的持久性和消息队列的低延迟——把「传递消息」和「存储数据」合成一件事。这正是让「流」能当作可信事实之源的技术地基。代价是：一个分区只能被一个消费者顺序读，想让 100 个消费者并行分摊同一批消息、且乱序无所谓时，传统队列反而更灵活。

二、数据库与流：变更数据捕获（CDC）与事件溯源

把「流」这个抽象接到数据库上，就打通了本章最有用的一类应用：让所有系统保持同步。现实里你几乎不可能只用一个数据库——主库之外还有搜索引擎（Elasticsearch）、缓存（Redis）、数仓、推荐特征库，它们都要跟着主库的数据变。传统做法是应用层双写（改完数据库再手动改搜索），但双写极易在并发或部分失败下对不上账。更干净的办法是把数据库的变化变成一条流：

变更数据捕获（CDC）：主库每发生一次增删改，就抽成一条事件（通常直接读它的复制日志 / WAL），推进一条流。所有下游订阅这条流、按序应用，就能最终和主库一模一样——本质上是把 Ch5 的「主从复制」推广到异构系统之间。工具如 Debezium 就干这个。

事件溯源（event sourcing）：更彻底的一步——干脆不把「当前状态」当事实之源，而把「导致状态的每一个事件」当事实之源。购物车不存「现在有 2 件商品」，而存下 加入X、加入Y、移除X 这串不可变事件，当前状态由重放算得。好处：完整审计（每步留痕、可追责）、可回到任意历史时刻、同一份事件流能派生多种视图（同样一串下单事件，既算库存、又算营收、还喂推荐）。

三、流表二象性：把数据库「里外翻转」

CDC 和事件溯源背后是同一个深刻观察，作者称之为流与表的二象性（stream-table duality）：

• 表是流的「快照」：一张数据库表的当前内容，等于把它从建表以来所有变更事件（changelog）从头重放、加总的结果。你的银行余额，就是全部流水的和。
• 流是表的「变更日志」：反过来，只要持续记录一张表的每一次变化，就得到一条流；订阅这条流、逐条应用，任何下游都能维护出一份与源表一致的副本。

这不是文字游戏，而是一种架构世界观：把数据库「里外翻转」——传统数据库把「变更日志」藏在内部、只把「当前状态」露给你；流处理反过来，把变更日志本身升格为一等公民（就放在 Kafka 里），让『当前状态』退化成随时可从日志重建的、多份的物化视图。于是搜索索引、缓存、报表全成了「同一条事实日志的不同投影」，天然一致、坏了能从日志重建。这正是 Kleppmann 那句著名的「turning the database inside out（把数据库里外翻转）」，也是终章 Ch12 的思想内核。

四、时间的麻烦：事件时间 vs 处理时间、窗口与水位

这是本章公认最烧脑、也最见真章的一节。批处理里「时间」不是问题（数据都在，随便算）；到了流处理，你想算「过去一分钟有多少笔交易」，立刻撞上一个哲学难题：哪个「一分钟」？

• 事件时间（event time）：事件真正发生的时刻（手机上点下支付的那一秒）。
• 处理时间（processing time）：事件被服务器处理到的时刻。

二者常对不上：用户在地铁里下了单，手机没信号，5 分钟后出站才把事件补发上来。若按处理时间算，这笔会被错记进 5 分钟后的那个窗口。按处理时间算简单但结果会因系统忙闲、网络抖动而失真；按事件时间算才「对」，但你会遇到一个死结：你永远不能确定某个时间窗口的事件是不是都到齐了——总可能还有个掉队的（straggler）在路上。

解药是水位线（watermark）：系统维护一条启发式的界线「事件时间 T 之前的，我认为基本都到了」，一旦水位越过窗口的结束边界，就先把这个窗口的结果算出来发下去。之后再来的迟到事件怎么办？三种态度：直接丢弃（并计数报警）、发一条更正（撤回旧结果重发）、或允许一段宽限期再迟到就丢。这里没有免费午餐——想等得久一点、少漏一个，就得牺牲延迟；想快点出结果，就得容忍偶有漏网。

切窗口本身也有讲究，常见四种：滚动窗口（tumbling）——首尾相接不重叠（「每整分钟」）；跳动窗口（hopping）——固定长度但按更小步长滑动、会重叠（「每分钟统计过去 5 分钟」）；滑动窗口（sliding）——任意时刻都看「往前 N 分钟」；会话窗口（session）——没有固定长度，按「同一用户一连串活动、中间静默超过若干分钟才算断」来切。

五、流上的连接与容错：三种 join 与 exactly-once

和批处理一样，流上也常要 join，但因为数据在「流动」，形态更微妙，分三类：①流-流 join（窗口连接）——把两条流在一个时间窗口内配对，如「搜索事件」配「点击事件」算点击率，难点是两边都在动、要缓存一个窗口的状态等对方；②流-表 join（补全 / enrichment）——用一张（缓慢变化的）表去丰富流里的每条事件，如给每条点击事件补上用户画像，实现上常把表通过 CDC 也变成流、在本地维护一份副本；③表-表 join（维护物化视图）——两条 changelog 流合并出一个持续更新的联表视图。

容错与 exactly-once（恰好一次）是流处理的终极考题。批处理失败大不了整批重跑（输入还在）；流是无界的、没有「跑完」，崩溃重启后怎么保证「每个事件的效果恰好生效一次、不重不漏」？三条主流路线：①微批（microbatching，Spark Streaming）——把流切成一秒一个的小批，退化成批处理来容错，简单但延迟受限于批长；②检查点 + 幂等（checkpoint，Flink）——周期性给算子状态打快照，崩溃后回滚到上个检查点重放，配合幂等写出，达成「效果恰好一次」；③原子提交——把「推进读进度」和「写结果」绑进一个事务一起成败（如 Kafka 事务）。注意：exactly-once 指「对外部效果恰好生效一次」，而非「物理上只处理一次」——底层往往仍靠重放 + 去重 / 幂等实现。

关键权衡与选型

流处理的选型，核心是在可回放性、顺序、实时性、正确性代价之间权衡。三张表把最常考、最实用的对比拎出来。

表 1 · 传统消息队列 vs 日志型消息代理（Kafka）

表 2 · 事件时间 vs 处理时间（及迟到事件对策）

表 3 · 流上三种 join 怎么选

为什么重要 / 落到真实系统

流处理是当今实时数据栈的骨架。Apache Kafka（LinkedIn 2011 年开源）把「日志」抬成了基础设施，几乎成了事件流的事实标准；其上 Kafka Streams、Apache Flink、Spark Streaming、Storm、Samza 层层生长。CDC 工具（Debezium）把老数据库接进流；实时数仓、实时风控、推荐特征、监控告警、物联网遥测，骨子里都是这一章的思想。作者提出的「把数据库里外翻转」（unbundling / 流表二象性）更直接定义了 Ch12 的方向。面试里，「Kafka 为什么能既持久又低延迟」「exactly-once 到底怎么实现」「事件时间和处理时间的区别与水位线」几乎是数据 / 后端岗高频题——答案全在本章。

易错点与争议

• 把 exactly-once 理解成「物理上只处理一次」：这是最大误解。它指的是「对外部世界的效果恰好生效一次」，底层往往仍靠重放 + 幂等 / 事务去重实现——消息可能被处理多次，只是效果不重复。
• 无脑用处理时间：图省事按处理时间开窗，结果一遇网络抖动 / 消费积压，「每分钟指标」就随系统忙闲失真。要真实业务口径（计费、风控）必须用事件时间 + 水位线。
• 以为迟到事件能「完全不丢」：只要用事件时间，就永远存在「等多久才收工」的取舍——等得久也总有更晚的掉队者。工程上只能选一个水位策略并承认偶有漏网 / 事后更正，没有两全。
• 双写代替 CDC：应用层同时写数据库和搜索索引，看似直接，实则在并发 / 部分失败下极易对不上账。用 CDC 把「一处变更」变成流、单向传导，才是可靠做法。
• Lambda 架构之争：同时跑批 + 流两套（Lambda）曾流行，但因要维护两份逻辑、结果还常对不齐饱受批评；Kappa（只用流 + 回放）更简洁，但对「超长历史重算」的成本和成熟度有要求。二者至今仍有取舍，非一边倒。
• 时代局限：本章 2017 年成书，此后 Flink 的事件时间语义、Kafka 的 exactly-once 事务、以及「批流一体」（Flink、数据湖 Iceberg / Delta / Hudi）大幅成熟；但「不可变事件日志 + 派生视图」的世界观至今是实时系统的地基。

要点