数据系统的未来

一句话

你以为终章是复习，其实它是宣言。Kleppmann 在这里给出他自己的答案：把「数据库」这个整装产品拆开（unbundling）——存储、索引维护、查询本就是可以分给不同工具做的三件事——再用一条有序、可回放的事件日志把它们重新串成组织级的数据流；而正确性别指望底层事务，要在两端做端到端保证，并把「一致性」拆成及时性与完整性两件性质不同的事分别对待。最后他还追问了一句工程书少见的问题：这些能力，我们该不该都用上。

Glossary · 术语表

坐标

本章是 Part III「派生数据」的收官，也是全书终章。它承接 Ch10、Ch11 的「不可变输入 + 派生结果」世界观，把 Ch5–Ch9 的复制、分区、事务、共识全部回收，落成一套组织级的系统组装法。现实对应任何一家同时跑着主库、搜索、缓存、数仓、特征库的公司——也就是几乎所有公司。

这章要解决什么

前十一章的潜台词一直是「选一个合适的工具」。但真实公司里从来不止一个：一个中等规模电商，主库 PostgreSQL、搜索 Elasticsearch、热点数据 Redis、分析在数仓、风控和推荐各有一份特征库——同一条「用户改了地址」的事实要出现在五六个地方。没有哪个数据库通吃所有访问模式，所以多套系统并存不是坏设计，是必然。

真问题于是变成：怎么让这五六份数据保持一致，且加第七个系统时不会崩溃？不解决就会得到工程师最熟悉的痛——搜索结果和详情页对不上、报表跟线上账目差几百块、每接一个新系统就要在应用里加一段脆弱的双写。更要命的是这类不一致不会自愈，它和「等一会儿就好」的复制滞后是两码事。

核心内容，讲透

一、双写为什么必然坏：顺序没人负责

先把靶子立准。双写就是应用里那两行看似无害的顺序调用：先 db.update(...)、再 search.index(...)。它有两个病。竞态（race condition）：两个客户端几乎同时改同一条记录，主库先收甲后收乙、搜索索引却先收乙后收甲，两边留下不同终值——这不是「等一会儿就一致」，而是永久错位。部分失败：第一个写成功、第二个写失败，两个系统就此分叉。用分布式事务包住两个写倒是可以，但那要求异构系统都支持同一套原子提交协议、还要在提交期间互相持锁等待。

解法是换个提法：不要让应用「同时写两个地方」，而是指定一个系统记录，所有写入先进去、按顺序落成一条事件流；其余系统一律降级为派生数据，只订阅这条流照做。关键收益是顺序只定一次——所有下游看到同一份先后关系，最终状态必然收敛。

作者的结论很实用：在缺乏被广泛支持的分布式事务协议的现实里，基于日志的派生是最有希望的整合方案——它用「确定性重算 + 幂等重试」换掉「加锁互斥 + 原子提交」，弱一档，却是异步的、宽容故障的。边界也得说清：地基是全序，而定序要靠单点或一次共识，吞吐卡在一台机器上；跨地域多活、各持独立状态的微服务、离线客户端都很难塞进一条全局队列——DDIA 到这里也只能说这仍是开放的研究问题。

二、批与流本是一体：Lambda 架构与它的替代

派生数据靠「重算」，而算法有两种跑法：批处理把历史整体算一遍，流处理来一条算一条。Lambda 架构是当年流行的折中：批处理层慢但准、流处理层快但近似，查询时合并。DDIA 的批评很直接：同一套业务逻辑要在两个框架里各写一遍并保持等价，这是长期的维护税，两边结果的合并逻辑本身又是新的 bug 源。作者主张统一：既然日志能回放，「批」不过是「对一段有界历史跑同一套流算子」，一份代码、一套语义就够了。

这里藏着本章最实用的一招：重新处理（reprocessing）是应用演化的正经手段。要换一套推荐特征、改一次数据模型，不必冒险原地改表——用新代码从日志重放、建出一份并行新视图，两份并存一段时间，验证无误再切读流量，出问题原地切回。这把 Ch4「不停机演化 schema」的思路推到了整个派生层：迁移不再是一刀切的大爆炸，而是可回退的渐进过程。代价是日志得留得够久（几周到几个月），且重算历史要吃一波额外算力。

三、数据库解绑：把一个盒子拆到整个组织

这一节是全章的思想核心。作者的观察是：一台数据库内部做的事，和一家公司里跨系统的数据流，本质是同一件事的两种尺度。

数据库内部有写入接口、存储引擎与预写日志、二级索引维护（写一条记录时顺手更新索引）、物化视图维护、触发器、复制日志、查询执行。拆开看：Kafka 这类事件日志 ≈ 复制日志；流处理器 ≈ 触发器与物化视图维护器；下游的搜索索引、缓存、OLAP 表 ≈ 各式各样的索引。于是整个组织的数据流就是一个摊开的超大号数据库——作者称之为「万物之元数据库（meta-database of everything）」。

顺着这个视角，整合异构系统只有两条路，各管一头：

• 联邦查询（federated query）——统一「读」：给一堆异构存储套一个统一的只读查询接口，查询时现场跨库拉数据（PostgreSQL 的外部数据包装器 foreign data wrapper 是典型）。不动写入侧、上手快；但每次查询都要跨系统现拉，性能与可用性受制于人。
• 解绑（unbundling）——统一「写」：所有写入汇成一条日志，各系统作为派生端异步跟进。好处是松耦合：某个下游宕了慢了，只是它自己的 offset 落后，恢复后自动追上；不同团队还能各自独立地开发、升级、替换自己那一段。

必须补上作者的克制，否则这章容易被读成布道：解绑不是要取代数据库。他明确说单个集成产品在它擅长的场景里更快也更简单；解绑赢的不是性能而是场景覆盖面——只有当没有任何一个软件能同时满足你所有需求时才划算。他还留了句遗憾：目前还缺一门「组装数据系统」的高级语言，我们能像 Unix 管道那样拼命令，却没法同样轻巧地拼存储系统。

四、围绕数据流设计应用：写路径与读路径之间那条可移动的边界

把上面的思路推到应用层，会得到一个很好用的心智模型：任何一次「数据从写入到被看见」都由两段组成——写路径（write path）是写入时提前做的工作，读路径（read path）是查询时临场做的工作。而缓存、索引、物化视图，本质都是同一件事：把这条分界线往写路径方向挪。

这个模型解释了很多平时靠经验拍板的决定：全文搜索索引为什么要建？因为把「按关键词找」的活提前干了。为什么不给所有查询都建物化视图？因为每挪一格，写入侧的维护成本和滞后就多一分。选型不是「要不要缓存」，而是「这条边界该停在哪」。作者还把这条流一路推到终端设备：单页应用的本地状态就是一份服务端状态的副本，WebSocket 推送把写路径的终点延伸到了用户屏幕上。

五、追求正确性：端到端、以及把「一致性」拆成两半

组装完了怎么保证不出错？作者从一个尖锐的问题切入：事务真的够吗？

先看「恰好一次」。用户点了一次付款、页面卡住，他又点了一次。中间层的所有去重都不管用：TCP 的重传去重只在一条连接内有效；数据库事务保证的是这一笔要么全做要么不做，可用户提交的是两笔各自完全合法的独立事务；哪怕上了 2PC，跨系统原子提交也挡不住「用户手动重试」。

唯一有效的位置是两端：客户端发起操作时就生成一个唯一操作 ID（如 UUID），一路带到最终端点当去重键——同一个 ID 只认第一次。这正是 1984 年 Saltzer、Reed、Clark 的端到端论证（end-to-end argument）在数据系统里的复现：某些功能只有在掌握完整语义的两个端点上才能被正确实现，中间层做得再好也只是优化。推论很扎心：底层可靠性机制（TCP 校验、事务、复制）都有用，但都不足以单独保证应用层面的正确。

再看约束。「用户名不能重复」这类唯一性约束本质上需要共识（Ch9）。但日志架构里有个漂亮办法：按被约束的值分区（如按用户名哈希分区），同一个用户名的所有申请必然落进同一条队列，单线程消费者顺序处理，第一个成功、后来的一律拒绝——不用跨机器加锁就得到了确定性裁决。跨分区操作（从账户 A 转到 B）思路相同：先把「请求」本身作为一条带 ID 的事件原子写入日志，再由下游派生出两个账户的余额变更；效果等价于 2PC，形状却简单得多、也更容错。

最后是本章最值钱的区分：把「一致性」拆成两半。

• 及时性（timeliness）：用户看到的是不是最新状态。违反它 = 短暂读到旧数据，等一会儿会自己好——也就是「最终一致性」。
• 完整性（integrity）：数据本身有没有损坏、自相矛盾（钱扣了没到账、索引里有条不存在的记录）。违反它 = 永久不一致，不会自愈，必须显式修复。

作者的原话大意是：违反及时性只是「最终一致」，违反完整性却是「永久不一致」。价值在于——ACID 事务把两者捆在一起提供，代价高昂；数据流系统可以解开这个捆：靠确定性派生 + 端到端操作 ID 死守完整性，同时放松及时性。这正是它能避开跨分区协调、跑得又快又稳的根本原因，作者称之为协调回避（coordination-avoiding）——不是不协调，而是把昂贵的协调压缩到真正必要的那一小块。顺着这条线还有个反直觉的主张：很多约束不必当场卡死，航空公司超售、仓库缺货，做法都是先放行、事后对账、越界就补偿道歉。

最后是「信任，但要验证」：软件有 bug、硬件会静默损坏、人会误操作，别把「数据不会坏」当公理。事件溯源式系统天然占优——原始事件在、派生逻辑确定，随时能重放一遍与现有结果比对，这就叫审计（auditing）。作者对区块链态度审慎，但明确希望其中的密码学审计与完整性校验思路（Merkle 树等）进入主流数据系统。

六、做正确的事：能力之外的追问

全书最后一节画风一转谈伦理，分量不轻。三个要点：预测性分析会把历史里的偏见照抄进未来——用历史数据训练的模型把过去的歧视固化成「客观算法」，还因披着数据的外衣而更难申诉；反馈回路会自我强化——被判定高风险的人拿到更差的条件，于是更可能失败，反过来「验证」了算法；数据是负债不是资产——攒着的用户数据随时可能泄露、被滥用、触法，用不着了就该删。他也点破了「隐私政策即同意」的虚伪：用户没有真正的选择权，谈不上自由同意。

关键权衡与选型

表 1 · 三种整合方式：分布式事务 vs 双写 vs 日志派生

表 2 · Lambda 架构 vs 批流统一

表 3 · 两条整合路线：统一读 vs 统一写

表 4 · 及时性 vs 完整性：这条约束到底该不该强协调

一条贯穿性的判据：先问「违反了会不会自愈」。会自愈的（及时性）尽量放松，换吞吐、换可用性、换更简单的架构；不会自愈的（完整性）必须用确定性派生 + 端到端 ID 死守。把这两件事分开定价，是本章给架构决策最实用的一把刀。

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

这一章的主张今天已是现代数据平台的默认形态，只是换了名字：Kafka 当整合总线、Debezium 之类的 CDC 工具把数据库变更抽成流、Flink / Kafka Streams 当那个摊开的物化视图维护器、下游落到 Elasticsearch / ClickHouse / 数据湖表格式（Iceberg、Delta、Hudi）。你在中大型公司架构图上看到的「以 Kafka 为轴、下游一堆派生存储」，正是本章的解绑蓝图。面试和架构评审里，它能兑现成几句有分量的话：为什么反对双写、为什么「重放重建再切流量」比原地改表更安全、为什么「用户名唯一」可以不靠分布式锁，以及那把最好用的刀——把一致性拆成及时性与完整性分别定价。

易错点与争议

• 把「解绑」读成「别用数据库」：作者立场恰恰相反——单一集成产品在它擅长的场景里更快也更简单，解绑赢的是场景覆盖面，不是性能。系统不多、需求单一时，老实用一个数据库。
• 低估全序的代价：地基是「一条全局有序的日志」，但定序要单点或共识，吞吐卡在一台机器上；跨地域多活、独立状态的微服务、离线客户端都难以纳入同一条队列。作者自己承认这是未解的开放问题。
• 以为最终一致「等等就好」：派生端滞后会实实在在伤体验，最典型的是读己之写（刚改完地址、一刷新又是旧的）。要么关键读走系统记录，要么会话内粘性路由（Ch5 的老办法）。
• 低估运维复杂度与重放成本：一条日志 + 若干流作业 + 若干派生存储，意味着多一层要监控消费滞后、演练重放、管 schema 演化的管道——复杂度是从应用代码挪到了基础设施，不是消灭了它。而「出错就重放」的前提是日志留得够久；对攒了几年的大表，全量重放可能是以天计的工程。
• 争议：伦理一节是否跑题？不少读者认为技术书不该谈。但 2017 年之后的现实（大规模数据泄露、算法歧视争议、各国隐私立法）大体印证了作者的判断，「数据是负债而非资产」如今已被相当多合规实践采纳。
• 时代局限：成书于 2017 年，此后流式数据库、湖仓一体、Flink 的 exactly-once 与批流一体、数据血缘 / 契约治理工具都大幅成熟；但作者感叹的「缺一门组装数据系统的高级语言」至今仍未真正填上。训练数据的来源与同意问题，也在生成式 AI 时代被放大到他当年未及展开的规模。

要点