LTAP 架构深度解析：从单体数据库到 Lakebase，Postgres 数据统一存储在 Parquet/S3

本文深入解析了 Databricks 提出的 LTAP 架构，通过将 Postgres 的 WAL 和数据文件外部化到独立云服务，实现 OLTP 与 Lakehouse 分析引擎在单一开放列式存储上的实时融合，彻底摆脱了传统单体数据库的扩展性、高可用与混合负载难题。

一、引言：OLTP 数据库远非“已解决的问题”

16 年前，我在加州大学伯克利分校攻读博士时，导师曾告诉我：“OLTP 数据库已经是一个被解决的问题了。它们能工作。专心做分析吧。”那时，我们正处于能够收集海量结构化与非结构化数据，并应用机器学习（也就是现在说的“AI”）的早期阶段。于是我听从了建议，与联合创始人一起开启了后来成为 Apache Spark 的研究项目，随后创办了 Databricks。

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

本文将对 Lakebase 的 OLTP 架构进行深度剖析。我们从传统单体数据库的存储层开始，看痛点从何而来；然后看 Lakebase 如何将相同的组件重新组织为独立的、外部化的服务；最后，聚焦于 LTAP（Lakehouse Transactional/Analytical Processing）——在这种架构下，事务和分析可以在单一数据副本上实时运行，无需 CDC（变更数据捕获）或“镜像”带来的延迟和额外成本。

二、单体数据库：一切问题的根源

目前世界上绝大多数数据库都是单体架构，包括 MySQL、Postgres、经典 Oracle 等。Lakebase 构建在 Postgres 之上，因此我们以 Postgres 为主要示例，但大多数数据库的工作方式类似：

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

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

简单理解：WAL 的存在是为了让写入快速（且安全），而数据文件的存在是为了让读取快速。 日志让你通过一次顺序追加就能提交事务，而不是分散的随机 I/O。数据文件让你通过直接读取当前状态来回答查询，而不必从数据库诞生之初重放全部历史。

（如果你想了解这个设计的所有细节，可以阅读长达 69 页的 ARIES 论文——这是计算机科学领域最复杂的论文之一。）

然而，这种单体架构也带来了诸多挑战：

2.1 配置错误导致的数据丢失

一次提交的持久性，完全取决于其背后的磁盘刷写（flush）。如果数据库、操作系统或存储层配置不当，使得对 WAL 的写入在真正持久化到介质之前就向客户端返回成功，那么一次断电或内核崩溃就可能导致提交丢失。这些设置非常微妙，容易出错，而且故障往往是静默的——操作系统甚至可能对刷写行为撒谎。

2.2 节点故障导致的数据丢失

即使刷写配置正确，WAL 和数据文件也驻留在同一台机器上。如果该机器的磁盘损坏，其上的数据也会随之消失。网络附加存储或 RAID-1/RAID-10 等冗余技术可以提高持久性，但无法从根本上解决这个问题——如果存储挂载点挂了，你的数据访问也就挂了。

2.3 扩展读取需要物理克隆

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

2.4 高可用也需要物理克隆

要应对主节点故障，至少需要运行一个备用节点，它本身也是一个完整的物理副本，通过 WAL 保持同步。这意味着你要为至少两倍的基础设施付费，等待备用节点上线需要很长时间，并且必须设置同步复制以避免主节点宕机时丢失数据（实践中，很多人建议使用 3 个或更多节点）。

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

一个重量级的分析查询会与你的延迟敏感型事务工作负载共享相同的硬件资源。一个大型报表查询或一次 GDPR 数据清理，就可能拖慢你的主要 OLTP 查询。你可以将分析查询放到单独的副本上运行，但这样你既要为副本付费，又因为 OLTP 存储是行式存储（分析需要列式存储才能获得高性能），仍然无法获得最佳性能。

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

三、Lakebase 架构：将单体拆解为独立云服务

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

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

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

3.1 写入扩展：WAL 变成 SafeKeeper

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

你可能会问：将提交从本地磁盘刷写转移到网络复制，不会增加延迟吗？实际上，网络复制比磁盘刷写更快。现代云环境中，网络延迟通常为 1-2 毫秒，而磁盘刷写（特别是远程挂载的磁盘）可能达到 5-10 毫秒。更重要的是，网络复制提供了真正的持久性——只要法定数量的节点存活，数据就不会丢失。

3.2 读取扩展：数据文件变成 PageServer

在单体数据库中，数据文件存储在本地磁盘上，读取需要通过 PostgreSQL 的缓冲区缓存（buffer pool）从磁盘加载页面。在 Lakebase 中，数据文件被外部化到 PageServer——一个分布式缓存/存储层，它从 S3 等对象存储中获取数据文件，并维护一个本地页面缓存。

• PageServer 的工作方式：当 Postgres 计算节点需要读取一个页面时，它向 PageServer 发起请求。PageServer 首先检查其本地缓存，如果命中则直接返回；否则，它从 S3 加载页面，缓存后返回。
• 写时复制（Copy-on-Write）与分支：PageServer 支持高效的写时复制，这意味着你可以瞬间创建一个数据库分支（branch），而不需要复制整个数据集。分支创建后，只有被修改的页面才会产生新的副本。
• 弹性计算：由于计算节点是无状态的，你可以根据需要启动任意数量的只读副本，每个副本都通过 PageServer 读取相同的数据。这些副本不需要物理克隆，启动时间从分钟级缩短到秒级。

3.3 高可用与灾难恢复

在 Lakebase 中，高可用变得简单：

• 主节点故障：SafeKeeper 中保存了最新的 WAL 记录。一个新的计算节点可以立即启动，从 SafeKeeper 读取 WAL 并重放到最新状态，然后接管服务。整个过程不需要复制整个数据集。
• PageServer 故障：PageServer 本身是有状态的，但它的数据来自 S3。如果 PageServer 崩溃，可以启动一个新的实例，从 S3 重新加载数据。S3 本身提供了 99.999999999% 的持久性。
• 区域级故障：由于数据存储在 S3 上，你可以配置跨区域复制，在另一个区域启动 SafeKeeper 和 PageServer 实例，实现区域级灾难恢复。

四、LTAP：事务与分析在单一存储层融合

Lakebase 解决了单体数据库的扩展性和高可用问题，但还有一个更宏大的目标：让 OLTP 和分析工作负载在同一份数据上协同工作，无需数据复制和 CDC 管道。 这就是 LTAP（Lakehouse Transactional/Analytical Processing）的精髓。

4.1 HTAP 的局限

你可能听说过 HTAP（Hybrid Transactional/Analytical Processing），它试图在一个引擎中统一两种工作负载。但 HTAP 存在根本性问题：

• 引擎冲突：OLTP 引擎针对点查和短事务优化（行式存储、索引），而分析引擎针对全表扫描和聚合优化（列式存储、向量化执行）。一个引擎很难同时做好两件事。
• 性能隔离：即使在同一引擎中，事务和分析仍然会争抢 CPU、内存和 I/O 资源。
• 数据模型不匹配：OLTP 数据通常是规范化的，而分析需要宽表或星型模型。

4.2 LTAP 的核心思想：存储层统一，引擎层分离

LTAP 走了一条不同的路：在存储层统一，但为每种工作负载保留最合适的引擎。

具体来说，Lakebase 将 Postgres 的数据以 开放列式格式（如 Apache Parquet） 存储在 S3 上。这意味着：

• OLTP 引擎（Postgres）：通过 PageServer 读取行式页面，执行事务。写入时，数据被转换为列式格式并写入 S3。
• 分析引擎（Lakehouse，如 Spark、Presto、Trino）：直接读取 S3 上的 Parquet 文件，执行分析查询。

关键优势：分析引擎读取的是事务刚刚写入的同一份数据，无需 CDC 管道，无需第二份副本，也不会拖慢事务工作负载。分析查询直接在 S3 上运行，利用列式存储的高压缩比和向量化执行，性能远超在行式存储上运行的分析查询。

4.3 LTAP 如何工作？

1. 写入路径：Postgres 事务提交时，写入 WAL 到 SafeKeeper，同时将数据以行式格式写入 PageServer。PageServer 异步地将数据转换为 Parquet 格式并写入 S3。
2. 读取路径（OLTP）：Postgres 通过 PageServer 读取行式页面，用于点查和短事务。
3. 读取路径（分析）：分析引擎通过 Lakehouse 的元数据服务（如 Hive Metastore 或 Databricks Unity Catalog）发现 S3 上的 Parquet 文件，直接读取。
4. 一致性保证：SafeKeeper 确保所有写入在确认提交前已持久化。分析引擎通过快照隔离（snapshot isolation）读取数据，确保不会读到未提交的事务。

4.4 与 CDC/Mirroring 的对比

传统上，要实现事务数据上的实时分析，你需要设置 CDC 管道（如 Debezium + Kafka），将数据从 OLTP 数据库复制到数据仓库。这带来了：

• 延迟：CDC 管道通常有秒级甚至分钟级延迟。
• 复杂性：需要维护额外的管道组件，处理 schema 变更、数据一致性等问题。
• 成本：需要为两套系统付费（OLTP 数据库 + 数据仓库）。

LTAP 消除了所有这些开销：分析查询直接在事务数据上运行，延迟接近实时（秒级），无需额外组件，只需为一份存储付费。

五、性能与权衡

5.1 延迟分析

你可能会担心：将 WAL 和数据文件外部化到网络服务，会不会增加延迟？

• 写入延迟：SafeKeeper 的网络复制（1-2ms）通常比本地磁盘刷写（5-10ms）更快。对于大多数应用，这种差异可以忽略不计。
• 读取延迟：PageServer 的本地缓存通常能命中大部分热数据。对于冷数据，从 S3 加载的延迟（10-20ms）略高于本地磁盘，但 S3 的带宽极高（单个对象可达到 100 Gbps），对于大范围扫描反而更快。

5.2 成本分析

• 存储成本：S3 的存储成本远低于 EBS（弹性块存储）或本地 SSD。Parquet 的列式压缩通常能将数据体积减少 3-5 倍，进一步降低成本。
• 计算成本：无状态计算节点可以按需启动和停止，不需要为闲置容量付费。分析查询直接在 S3 上运行，不占用 OLTP 计算资源。
• 管理成本：无需维护 CDC 管道、副本和高可用配置，大幅降低运维负担。

5.3 适用场景

LTAP 特别适合以下场景：

• 实时分析：需要对刚刚写入的事务数据运行分析查询，如实时仪表盘、欺诈检测、个性化推荐。
• 运营分析：数据库本身就是分析数据源，如 SaaS 产品的多租户分析、游戏运营数据。
• 数据科学：数据科学家需要直接访问最新的事务数据，用于模型训练和特征工程。

5.4 局限性

• 写入密集型场景：如果写入量极大（数百万次/秒），SafeKeeper 和 PageServer 可能成为瓶颈。但 Lakebase 通过分区和水平扩展可以缓解。
• 极低延迟场景：如果要求 P99 延迟低于 1ms，网络跳转可能带来额外开销。此时，本地 SSD 的单体数据库可能更合适。
• 复杂事务：Postgres 的某些高级特性（如可序列化隔离级别、外键约束）在 Lakebase 中可能实现更复杂。

六、总结与展望

Lakebase 和 LTAP 代表了数据库架构的一次根本性重构：

1. 从单体到微服务：将 WAL 和数据文件外部化为独立服务，解耦了计算和存储，实现了弹性、高可用和无限扩展。
2. 从行式到列式：将事务数据以开放列式格式存储在对象存储上，使得分析引擎可以直接读取同一份数据。
3. 从 HTAP 到 LTAP：不在引擎层强行统一，而是在存储层统一，让每个引擎做自己最擅长的事。

这种架构正在重新定义“数据库”的边界——它不再是运行在一台机器上的软件，而是一个由独立服务组成的平台，能够同时服务于事务和分析工作负载。

对于开发者而言，这意味着：

• 更简单的架构：不需要维护两套系统。
• 更低的总拥有成本：一份存储，两种用途。
• 更实时的洞察：分析查询直接运行在最新数据上。

当然，LTAP 还处于早期阶段。未来，我们可能会看到更多数据库采用类似架构，甚至出现专门为 LTAP 设计的全新引擎。但有一点是确定的：数据库的存储层正在成为新的战场，而开放格式和云原生将是最终的赢家。

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