DDIA 第二版：数据从本地磁盘搬到对象存储

围绕《Designing Data-Intensive Applications》（《数据密集型应用系统设计》）第二版的诸多变化中，有一项听起来纯属基础设施：数据存放在哪里。据 HackerNoon 的一篇文章，越来越多的系统不再写入本地磁盘上的文件系统，而是写入对象存储。

对前线部署工程师（FDE）来说，这个细节很重要。它决定客户的集群能否快速扩容，一次半夜故障会丢多少数据，以及月底账单从哪里来。因此，即便读过第一版，这本书也值得重读。

作者是谁，改了什么？

据 Kleppmann 的个人网站，本书由 O’Reilly Media 出版，2026 年 3 月面世，约 670 页。HackerNoon 报道称，这一次 Kleppmann 请来了长期合作者 Chris Riccomini 担任合著者。

Kleppmann 介绍说，新版以第一版为基础，加入了新技术和正在兴起的趋势。

据 HackerNoon，这次修订的目标是保持核心不变，融入新想法，并全面更新细节。换句话说，这是一次大幅更新，而不是一本新书。

这个选择合情合理。从第一版起，dataintensive.net 网站就把本书定位为一张地图，帮助读者在多样且快速变化的数据存储与处理技术中找到方向。好地图不会标出每一家商店，只画出主干道。

观点一：每个设计都是一场谈判

全书围绕每个现代数据系统都必须解决的五个权衡展开：可扩展性、一致性、可靠性、效率和可维护性。五者很少能同时兼得。

FDE 每天都在面对这件事。客户说“仪表盘必须实时”时，真正的问题是：他们能接受数据滞后几秒，又能换来多少成本或稳定性上的收益。在客户需求调研时问清这一点，往往能帮团队省下一周的返工。

观点二：对象存储让权衡换了位置

文章强调的一个变化是，存储越来越依赖对象存储，也就是本身已做好副本的远程服务，而不是本地文件系统。

要看清后果，可以设想一个基于本地磁盘的三节点数据库集群，每个节点各持一份副本。月底客户想扩到六个节点跑报表。每个新节点都必须先把数据复制过来才能干活，而复制既耗时间又耗带宽。

如果数据放在对象存储里，新增的三个节点无需复制任何数据。它们直接从共享存储读取，用完即关，副本由服务商负责。但权衡并没有消失。原则上，远程读取比磁盘读取慢，请求次数也会成为账单上的一项。

如何把这些用到客户的技术栈上？

这本书提供了一套讨论权衡的词汇。要在客户现场用上它，可以再加一个书中没有的视角：把技术栈拆成三个平面。假设客户使用托管数据仓库，数据存放在对象存储中。

平面	在数据仓库示例中	要问客户的问题
控制面	目录、表元数据、访问权限、集群配置	谁能修改表结构？元数据损坏后如何恢复？
数据面	对象存储中的数据文件，已有副本	数据放在哪个区域？保留多久？
计算面	按需启动、不保存状态的查询集群	并发上限是多少？长时间运行的查询由谁买单？

把书中的五个权衡映射到这张表上，会发现它们落在不同位置。原始数据的可靠性主要由数据面承担，可扩展性落在计算面。一致性和可维护性则集中在控制面：两个作业写同一张表时，决定谁胜出的是目录，而不是磁盘。

所以，和客户第一次工作会议时，先问控制面。它保存着最重要的状态，却是大家最少画出来的那一层。

观点三：先学原理，再学工具

这本书自身的修订方式，即保留核心、更新细节，本身就是一条学习建议。一年后，简历上的产品名称可能已经过时；但能讲清一个系统为何选择一致性而放弃低延迟，这种能力仍然有用。

如果你有两到四年经验，两版都没读过，那就从头读第二版，慢慢读，每周一章，并把每一章和你运维的某个系统对照。

如果读过第一版，就把时间花在书中新增的技术与趋势部分。

看 FDE 岗位描述时，留意“data pipelines”（数据管道）或“distributed systems”（分布式系统）这类字眼。面试前，准备一个你做过的具体权衡决策的故事，并用书中的五个概念来讲。

这本书不会帮你为下一个项目选数据库。它帮你在必须做选择之前问对问题。而在客户现场，一个对的问题往往比一个快的答案更有价值。