从单体到Lakebase再到LTAP：重新设计Postgres存储架构的深度解析

将Postgres的WAL和数据文件外迁至独立云服务，实现无状态计算与统一存储，支撑事务与分析在单份数据上实时运行。

引言：OLTP数据库远未解决

16年前，我在加州大学伯克利分校开始攻读博士时，导师告诉我：“OLTP数据库已经是一个解决过的问题了。它们工作得很好。专注于分析吧。”彼时，我们正处于能够收集更多结构化与非结构化数据、并应用机器学习（如今称为“AI”）的早期阶段。我听从了建议，与联合创始人一起投身于后来成为Apache Spark的研究项目，并最终创立了Databricks。

在构建Databricks的过程中，我们开始使用各种数据库，并意识到OLTP数据库远非一个解决过的问题：它们笨重、难以扩展、且极其脆弱。我们一度感到非常沮丧，以至于问自己：如果今天从头设计一个OLTP数据库，它会是什么样子？这个问题催生了Lakebase——我们的无服务器Postgres数据库。

本文深入剖析Lakebase的OLTP架构。我们从传统单体数据库的存储层出发，看清痛点来源；然后考察Lakebase如何将相同组件重新编排为独立的外部化服务；最后转向LTAP（Lakehouse Transactional and Analytical Processing，湖仓事务与分析处理），探讨同一架构如何让事务与分析在单份数据上实时运行，无需CDC（Change Data Capture，变更数据捕获）管道或第二份副本，且不拖慢事务性工作负载。

单体数据库的困境

当今世界上运行的绝大多数数据库都是单体架构，包括MySQL、Postgres、经典Oracle。Lakebase构建于Postgres之上（巧合的是，Postgres也诞生于伯克利），因此我们将以Postgres为主要示例，但大多数数据库的工作原理类似：

• 你预置一台机器，运行数据库引擎和存储。
• 磁盘上有两个最重要的东西：预写日志（WAL）和数据文件。

当你提交一个事务时，数据库不会立即重写数据文件——那样会很慢，因为你触及的行分散在文件中，需要随机I/O。相反，数据库先将变更的描述追加到WAL中，这是一个磁盘上的顺序日志。事务在日志条目被持久化写入的那一刻即被视为已提交。之后，数据库才异步地回过头来更新实际的数据文件以反映变更。

简单理解：WAL的存在是为了让写入又快又安全，数据文件的存在是为了让读取快速。日志让你只需一次顺序追加即可提交事务，而非散乱的随机I/O。数据文件让你直接读取当前状态来回答查询，无需从数据库诞生之初重放整个历史。（若想了解所有复杂细节，可阅读69页的ARIES论文——这被认为是计算机科学中最复杂的论文之一。）

然而，这种设计作为几乎所有数据库的基础，也带来了诸多挑战：

1. 配置错误导致数据丢失

一次提交的持久性仅取决于其背后的磁盘刷新。如果数据库、操作系统或存储层配置成：在WAL写入实际刷新到持久介质之前就向客户端确认写入成功，那么一次电源故障或内核恐慌就可能导致提交消失。这些设置微妙且容易出错，而失败往往是静默的——操作系统甚至可能欺骗你关于刷新状态的信息。

2. 节点丢失导致数据丢失

即使刷新配置正确，WAL和数据文件也只存在于一台机器上。如果该机器的磁盘损坏，其上的数据也会丢失。注意，网络附加存储或RAID-1/RAID-10等冗余技术可以提高持久性，但并未从根本上解决这个问题：如果存储挂载点失效，数据访问同样中断。

3. 扩展读取需要物理克隆

当一台机器无法再承载流量时，标准答案是添加只读副本。但只读副本是整个数据库的完整物理副本，它从主库流式传输WAL并重放。预置一个副本意味着复制整个数据集，然后追赶日志。对于大型数据库，这不是一个快速操作，甚至可能拖垮主库。

4. 高可用同样需要物理克隆

要应对主库丢失，至少需要运行一个备用节点，它本身就是数据库的完整物理副本，通过WAL保持同步。你至少要支付双倍的基础设施费用，等待很长时间才能让备用节点上线，并且必须设置同步复制以避免主库宕机时丢失数据（实践中，许多人推荐3个或更多节点）。

5. 分析查询与事务流量争抢资源

一个重型分析查询会与对延迟敏感的事务性工作负载争夺同一台机器的硬件资源。一次大型报表查询或一次GDPR数据清理就可能拖慢你的核心OLTP查询。你也可以在单独的副本上运行分析查询，但最终你为该副本付费，并且由于OLTP存储的行式导向，仍然无法获得最佳性能（分析需要列式存储才能高效）。

几乎所有这些问题都追溯到同一个根本原因：WAL和数据文件存储在一台机器内部。持久性与该机器的磁盘绑定；扩展和高可用需要物理克隆该机器；工作负载因共享该机器而相互干扰。

Lakebase架构：让Postgres计算无状态

如果你今天重新设计一个OLTP数据库，你会从现代云的组件出发：廉价且高度持久的云对象存储，搭配弹性计算。这正是Neon团队所走的道路，也是Lakebase的基础。

核心举措是让Postgres计算实例成为无状态的。我们通过将WAL和数据文件从本地磁盘外迁到专门构建、独立可扩展的服务中来实现这一点。计算层变成了一个无状态的Postgres引擎，可以自由启动、停止和复制，因为它不再拥有数据。

让我们看看这两个存储服务如何协同工作，在不牺牲性能的前提下解决前述挑战。

写入扩展：WAL变为SafeKeeper

在单体中，写入通过刷新到本地磁盘来确保持久性。在Lakebase中，WAL被外迁到一个名为SafeKeeper的分布式存储服务。持久性不再依赖磁盘刷新，而是通过基于Paxos的网络复制，将日志记录复制到SafeKeeper节点的法定数量（quorum）上来实现。不再有磁盘故障导致数据丢失，也不再有配置错误的刷新悄悄破坏你的持久性保证。

你自然会问：将提交从本地磁盘刷新移到网络复制，难道不会增加延迟吗？关键在于，现代云网络延迟（同区域通常亚毫秒级）远低于机械磁盘的延迟，并且通过精心设计的Paxos实现，可以做到非常高效。实际上，对于许多工作负载，这种网络复制的延迟甚至低于传统磁盘刷新的延迟，因为后者往往包含操作系统和硬件层面的不可预测性。

读取扩展：数据文件变为PageServer

在单体中，数据文件存储在本地磁盘，读取时从该磁盘获取页面。在Lakebase中，数据文件被外迁到一个名为PageServer的服务。PageServer负责从持久对象存储（如S3）中获取页面，并维护一个本地缓存以加速热数据访问。当Postgres计算节点需要读取一个页面时，它向PageServer发送请求；PageServer从缓存或对象存储中返回页面。

这种架构带来的好处：

• 计算无状态：任何Postgres节点都可以处理任何查询，因为它们都从同一组PageServer读取。
• 弹性扩展：你可以根据需要启动任意数量的只读计算节点，无需复制底层数据。
• 即时分支：由于数据文件存储在对象存储中，创建数据库分支（branch）只需创建一个指向新快照的指针，几乎瞬间完成，而无需复制数据。

高可用与灾难恢复

由于计算是无状态的，主库故障的处理方式非常简单：启动一个新的计算节点，连接到相同的SafeKeeper和PageServer即可。SafeKeeper中已经持久化了所有已提交的WAL记录，新节点可以从最近的检查点开始重放日志，快速恢复服务。无需等待物理克隆，无需同步复制（尽管你仍然可以配置同步模式以获得更强保证）。

LTAP：事务与分析在单份数据上实时运行

Lakebase架构已经解决了单体数据库的许多痛点，但Databricks更进一步，提出了LTAP（Lakehouse Transactional and Analytical Processing）的概念。

LTAP vs. HTAP

你可能听说过HTAP（Hybrid Transactional and Analytical Processing，混合事务与分析处理）。HTAP试图在同一个引擎中统一事务和分析工作负载——例如，一个数据库既处理OLTP事务，又直接运行分析查询。这听起来很理想，但在实践中面临巨大挑战：

• 两种工作负载对存储格式的要求截然不同：OLTP需要行式存储（高效的点查询和更新），OLAP需要列式存储（高效的聚合和扫描）。
• 一个引擎很难同时优化两种模式，往往导致两者都做不好。

LTAP的理念不同：它不在引擎层面统一，而是在存储层统一。具体来说，LTAP将操作数据以开放的列式格式（如Apache Parquet）存储在对象存储（如S3）上。这种格式既可以被Postgres（通过Lakebase）用于事务处理，也可以被Lakehouse引擎（如Apache Spark、Presto、Databricks SQL）直接用于分析查询。

核心优势

1. 单份数据，无需CDC：传统架构中，要将事务数据用于分析，通常需要设置CDC管道，将变更从OLTP数据库流式传输到数据仓库或数据湖。这引入了延迟、复杂性和额外的维护成本。LTAP消除了这个需求：事务写入的数据立即以列式格式可供分析引擎读取。

2. 实时分析：分析查询运行在与事务相同的最新数据上。当你提交一个事务后，分析查询可以立即看到该变更，无需等待CDC管道或批处理加载。

3. 无性能干扰：事务处理和分析查询使用完全不同的计算资源。事务在Postgres计算节点上运行，分析在Lakehouse引擎上运行。它们共享同一个存储层，但不共享计算资源，因此分析查询不会拖慢事务。

4. 开放格式，避免锁定：数据以Apache Parquet等开放格式存储，任何兼容的引擎都可以读取。这使得你可以自由选择最适合特定工作负载的工具，而不会被单一厂商锁定。

技术实现细节

LTAP的关键在于如何让Postgres以事务一致的方式写入列式格式。传统Postgres的数据文件是行式存储的（堆文件）。Lakebase的做法是：

• 写入路径：Postgres计算节点通过SafeKeeper提交事务，WAL记录以行式格式暂存。后台进程将这些变更转换为列式格式（Parquet），并写入对象存储（S3）。这个过程是异步的，但对事务的可见性进行了精心设计，确保分析查询读取到的数据是一致的。
• 读取路径：分析查询直接读取S3上的Parquet文件，利用列式存储的高效压缩和扫描能力。事务查询则通过PageServer读取，PageServer可以访问最新的行式数据（通过WAL重放），也可以从Parquet文件中获取冷数据。
• 事务隔离：Lakebase使用Postgres的MVCC（多版本并发控制）机制，确保事务隔离性。分析查询读取的是已提交的、一致的快照，不会看到未提交的变更。

与传统架构的对比

特性	单体数据库	Lakebase (OLTP)	LTAP
存储位置	本地磁盘	SafeKeeper + PageServer + 对象存储	对象存储 (Parquet)
计算状态	有状态	无状态	无状态
扩展读取	物理克隆	启动新计算节点	启动新计算节点或分析引擎
高可用	物理备用节点	即时故障切换	即时故障切换
分析查询	与事务争抢资源	需要单独副本	直接在存储层运行，不干扰事务
数据新鲜度	实时（同一副本）	实时（同一副本）	实时（单份数据）
格式	行式	行式（内部）+ 列式（对象存储）	列式 (Parquet)
CDC需求	无（但分析慢）	需要（若需高效分析）	无

结语：重新思考数据库存储

从单体到Lakebase再到LTAP，这是一次对数据库存储层的根本性重新思考。Lakebase通过将WAL和数据文件外迁到独立、可扩展的云服务，解决了单体数据库在持久性、扩展性和工作负载隔离方面的核心痛点。而LTAP更进一步，通过使用开放的列式格式作为统一存储，让事务和分析在单份数据上实时运行，无需CDC管道，无需第二份副本，且不牺牲任何一方的性能。

这种架构并非试图用一个引擎解决所有问题（如HTAP），而是在存储层实现统一，让每个工作负载使用最适合自己的引擎。这代表了数据库架构演进的一个重要方向：解耦计算与存储，开放格式统一存储层。

原文链接：https://www.databricks.com/blog/lakebase-ltap-rethinking-database-storage