《数据密集型应用系统设计》为适应AI和云原生架构进行重写。新版关注对象存储、数据库多样化部署及AI对数据处理的影响。Kleppmann和Riccomini探讨了流系统权衡与专业数据库未来，强调人机协作接口。
译自：Why the "bible" of data systems is getting a massive rewrite for 2026
作者：Cynthia Dunlop
Martin Kleppmann 的标志性著作如何为 AI 和云原生架构演进
自 2017 年发布以来，《数据密集型应用系统设计》(Designing Data-Intensive Applications) 已成为从事大规模数据驱动系统工作者的“圣经”。该书对基本原理（如存储引擎、复制和分区）的关注使其经久不衰。然而，在过去十年中，分布式系统的世界已发生了巨大变化。
云原生架构如今已成为默认选择。对象存储已成为一流的构建块。数据库越来越多地运行在从嵌入式和边缘部署到完全托管的云服务等各种环境中。人工智能驱动的工作负载也对存储格式、查询引擎和索引策略产生了影响。
因此，在多年来对第二版的需求之后，Martin Kleppmann 重新审视了这本书——并邀请了他的长期合作者 Chris Riccomini 作为合著者。他们的目标是：保持核心不变，同时融入新的思想并更新所有细节。随着《数据密集型应用系统设计》第二版已付印，让我们看看 Kleppmann 和 Riccomini 在 2025 年 Monster Scale Summit 上分享的关于该项目的内容。那次对话是在修订中期录制的。
您可以观看完整的对话或阅读下面的亮点。
人们一直在请求推出第二版——为什么是现在？
Kleppmann：是的，我一直想做第二版，但我也还有很多其他事情想做，所以这总是优先顺序的问题。不过，最终我感觉技术发展已经足够了。
这本书的大部分内容都集中在那些变化不那么快的基本概念上。它们的变化周期是几十年，而不是几个月。从这个意义上说，它是一本适合修订的书，因为没有那么多大的变化。与此同时，许多细节确实发生了变化。
最大的变化是与十年前相比，人们现在如何使用云服务。当然，当时云已经存在，但我认为它对数据系统架构的影响直到最近几年才真正显现出来。这是我们试图在第二版书中贯穿始终的内容。
自第一版以来，数据库架构是如何演进的？
Riccomini：我一直在思考，现在我们将数据库部署到更多地方——云端、BYOC、本地、客户端、边缘等——数据库架构是否发生了变化。我认为是的。我有一个假设，未来成功的数据库将能够随你移动或扩展，从你的笔记本电脑到服务器，再到你的云，甚至到另一个云。我们已经看到了 DuckDB 和 MotherDuck 等的证据，它们涵盖了从嵌入式到基于云的用例。我认为 PGlite 和 Postgres 是另一个例子，你看到 Postgres 被嵌入。SQLite 在嵌入式方面是一个明显的信号。
在查询引擎方面，你会在像 Daft 这样的系统中看到这一点，它可以在本地和分布式环境中运行。所以答案是肯定的。
最大的转变是控制平面、数据平面和计算平面之间的分离。这种架构现在已被广泛接受，并且在 SaaS 和 BYOC 之间移动时已被证明是灵活的。
这还有一个操作方面。当你谈论 SaaS 与非 SaaS 时，你谈论的是多租户以及你可以在多大程度上利用云提供商的基础设施。我曾就 Confluent Freight 与 WarpStream 进行了有趣的讨论，它们是两个相互竞争的 Kafka 流式系统。Freight 旨在利用 Confluent 拥有的许多云内 SaaS 基础设施，而 WarpStream 更像是 BYOC 系统，不依赖于自定义网络平面等。
在操作方面，关于安全性和多租户有很多需要考虑的地方，我不确定我们是否已经达到了应有的水平。许多 SaaS 公司正在做的事情仍然感觉是专有的和内部的。这是我对情况的看法。
“在第一版出版时，数据库的模型是一个节点运行在一台机器上。[…]现在我们越来越多地看到一种模型，其中存储是对象存储。”
Kleppmann：我想补充一点。在第一版出版时，数据库的模型是一个节点运行在一台机器上，将数据存储在其本地文件系统上。存储是本地磁盘，复制发生在应用程序层之上。
现在我们越来越多地看到一种模型，其中存储是对象存储。它不是本地文件系统；它是一个远程服务，并且已经进行了复制。在对象存储这样的抽象之上构建，与本地磁盘存储相比，可以实现根本不同的事情。
我并不是说哪个更好——总是存在权衡。但这代表了权衡空间中的一个新点，这在第一版出版时确实是不存在的。当然，那时对象存储就已经存在，但很少有数据库像现在这样利用它们。
我们最近看到了专业数据库的激增——你认为我们正在走向整合吗？
Riccomini：戴上我的投资帽子，这是一个百万美元……或者十亿美元……的问题。到底是哪个？我认为答案可能是两者兼而有之。
现实情况是，Postgres 最近真的风靡全球，其扩展生态系统在最近的版本中变得相当强大。对于大多数人来说，当他们开始时，自然会基于像 Postgres 这样的东西进行构建。他们会使用 pg_search 或类似的东西作为他们的搜索索引，pgvector 用于向量嵌入，以及 PG analytics 或 pg_duckdb 用于他们的数据湖。
那么问题是：随着他们规模的扩大，这仍然可以吗？在某些情况下可以。在其他情况下则不行。
我的个人假设是，当你不仅要扩展规模，还需要对产品至关重要的功能时，你更有可能转向专业系统。例如，pgvector 是一个合理的起点。但如果你的整个产品像 Cursor AI 或一个进行代码补全的 IDE，你可能需要比 pgvector 更健壮、可扩展的东西。到那时，你可能会考虑 Pinecone 或 Turbopuffer 这样的公司。所以我认为两者兼而有之。
由于 Postgres 将占据市场底部，我确实认为专业供应商会减少，但我认为它们不会完全消失。
当今流式系统的一些主要权衡是什么？
Kleppmann：流处理处于一个有点奇怪的空间。典型的流处理器具有一次处理一条记录的、基于回调的 API。它非常命令式。
在此之上，你可以构建关系运算符和查询计划等。但如果你一直朝这个方向推进，结果就会变得更像一个执行增量视图维护的数据库。
有些项目，例如 Materialize，正朝着这个方向发展。你只需给它一个 SQL 查询，而它是流式的这一事实几乎是隐藏的实现细节。
我不知道这是否意味着许多这些系统的结果是：如果你有一个可以用 SQL 表达的查询，你就把它交给其中一个系统，让它维护视图。
而我们目前所认为的流处理，带有较低级别的 API，则用于更专业的应用场景。这可能是非常高规模的用例，或者是不太适合关系风格的查询。
Riccomini：我想补充的另一件事是延迟和吞吐量之间的基本权衡，这是大多数流式系统都必须处理的问题。
理想情况下，你想要尽可能低的延迟。但当你这样做时，就更难获得更高的吞吐量。
增加吞吐量的常用方法是批量写入。但一旦你开始批量写入，就会增加消息发送和接收之间的延迟。
AI 如何影响数据密集型应用？
Kleppmann：我们一直在研究一些 AI 与数据结合的工作（并非本书的一部分）。这个想法是：如果你想让 AI 对系统拥有一些控制权——如果它被允许按下会影响数据的按钮，例如编辑或更新数据——那么最安全的方法就是通过一个定义良好的 API。
该 API 定义了 AI 允许按哪些按钮，并且这些操作对应于有意义的事情，并且可能满足某些一致性属性。
更普遍地说，拥有允许 AI 代理和人类安全协作的接口似乎很重要，而数据库是共同的基础。人类可以更新数据，AI 可以更新数据，并且两者都可以看到彼此的更改。
你可以想象这样的工作流程：更改被审查、比较和合并。如果我们希望人类和 AI 系统之间有良好的协作，这些过程将是必要的。
“拥有允许 AI 代理和人类安全协作的接口似乎很重要，而数据库是共同的基础。”
Riccomini：从实现的角度来看，存储格式肯定会演变。我们已经看到像 LanceDB 这样的系统正在努力更好地支持多模态数据。
例如，Arrow 是为列式数据构建的，这可能不适用于某些多模态用例。这不仅仅是存储，还包括像 Arrow RPC 这样的东西。
在查询引擎方面，围绕查询优化和索引也有大量正在进行的工作。其理念是构建更智能的数据库，可以查看查询模式并随时间进行自我调整。
谷歌之前有一篇很好的论文，使用了更传统的机器学习技术，根据查询模式进行动态索引。这项工作将继续下去。
当然，对嵌入、向量搜索和语义搜索的支持将变得更加普遍。与 RAG（检索增强生成）的良好集成……这也很重要。我们仍处于所有这些的最前沿，所以这很棘手。
