Postgres数据存S3 Parquet格式：LTAP架构解析

背景

传统数据库（如 MySQL、Postgres、Oracle）本质上都是单体架构：数据库引擎和存储运行在同一台机器上。写事务时，数据库首先将变更追加到预写日志（WAL）中，异步再更新实际数据文件。WAL 负责保证写入快速且安全，数据文件负责保证读取快速。这种设计虽然经典，却也带来一系列根深蒂固的问题：

• 数据丢失风险：如果 WAL 的实际刷盘配置不当（操作系统可能欺骗你“已刷盘”），掉电或内核崩溃会导致已提交事务消失。
• 单节点故障：WAL 和数据文件存放在同一台机器的磁盘上，磁盘损坏即数据全丢。网络附加存储或 RAID 只能部分缓解，无法根除。
• 读扩展昂贵：添加只读副本需要完整物理克隆整个数据库，并流式重放 WAL。大数据库的克隆过程耗时巨大，甚至可能导致主库宕机。
• 高可用成本高：容错需要至少一个备用节点，同样是完整物理副本，需要同步复制，基础设施成本翻倍。
• 分析干扰事务：重分析查询与延迟敏感的事务争抢同一硬件资源，大型报表或 GDPR 清理会拖慢 OLTP 负载。即使将查询放到独立副本，行式存储也不适合分析（分析需要列存）。

这些问题的共同根源是：WAL 和数据文件被锁在一台机器内部。可扩展性、可用性、工作负载隔离都因此受限。

核心内容

从单体到 Lakebase：外化存储服务

Lakebase 的设计思路源自现代云架构：利用廉价、高持久性的对象存储作为底座，配合弹性计算。核心是将 Postgres 计算实例变为无状态，把 WAL 和数据文件分别外化为独立、可独立扩展的服务。

• SafeKeeper：分布式 WAL 存储服务。事务提交不再依赖本地磁盘刷盘，而是将日志记录复制到仲裁节点（quorum）中，实现持久化。这消除了单体架构中因刷盘配置错误或单点磁盘故障导致的丢失风险。
• PageServer：数据文件存储服务。PageServer 从对象存储（如 S3）中读取数据页，缓存热数据，并持续从 SafeKeeper 拉取 WAL 记录以更新页面。计算节点（无状态 Postgres 引擎）只与 PageServer 交互，不直接接触对象存储。

通过这种架构，写操作先写入 SafeKeeper（基于内存复制实现低延迟），再由 SafeKeeper 异步持久化到对象存储；读操作由 PageServer 从缓存或对象存储中提供。计算节点可以随时启停、自由克隆，因为数据完全托管在外部服务中。

解决了什么问题？

• 数据持久性不再依赖单机磁盘，而是依赖分布式仲裁复制。
• 读扩展只需启动新的无状态 Postgres 实例，连接 PageServer 即可，无需物理克隆。
• 高可用同样只需热备计算实例，自动切换 SafeKeeper 和 PageServer 的写入点。
• 计算与存储解耦，可以根据工作负载独立扩缩。

LTAP：一份数据同时支持事务与分析

Lakebase 架构进一步演进为 LTAP（Lake-based Transactional and Analytical Processing 或 Lake-Transact-Analyze-Process，原文作者定义为“one copy for transactions and analytics”）。

核心思想：将操作数据以开放的列式格式（如 Parquet）存储在对象存储中。这样，Postgres（事务引擎）和 Lakehouse 引擎（如 Spark、Presto）都可以直接读取同一份数据，且不需要 CDC（变更数据捕获）管道、不需要第二份副本，分析查询跑在事务刚刚写入的最新数据之上，不会给事务负载带来任何减速。

具体机制：

• Lakebase 内的数据文件已经以列式形式物化在对象存储中（通过 PageServer 转换）。这意味着 Postgres 自身可以高效执行分析查询，同时 Lakehouse 引擎也能直接扫描这些 Parquet 文件。
• 读取最新数据时，Lakehouse 引擎只需读取已固化到对象存储的数据，再加上 SafeKeeper 中尚未持久化的少量增量日志；这个过程完全独立，不影响 Postgres 的事务处理。
• 所有表自动获得这种能力，无需用户额外配置。

与 HTAP 的区别： HTAP（混合事务/分析处理）试图在一个数据库引擎内统一两种负载，往往导致性能妥协或复杂度剧增。LTAP 则在存储层统一：事务用最好的引擎（Postgres），分析用最好的引擎（Lakehouse），两者共享同一份存储格式，数据写后立即可分析，没有延迟、没有复制成本。

关键要点

• 传统单体数据库的痛点：WAL 和数据文件绑定在同一台机器上，导致数据丢失风险、读扩展费时、HA 成本高、分析与事务互相干扰。
• Lakebase 架构：将 WAL 外化到 SafeKeeper（分布式仲裁复制服务），数据文件外化到 PageServer（基于对象存储的页服务）。Postgres 计算实例变为无状态，实现存储弹性、计算弹性、即时分支、更简单的高可用，且无显著延迟增加。
• LTAP 核心创新：操作数据以开放的列式格式（如 Parquet）存储在对象存储中，Postgres 和 Lakehouse 引擎都能读取同一份数据。
• 无 CDC 无副本：不需要变更数据捕获管道或第二份数据副本，分析直接跑在事务刚刚写入的最新数据上。
• 不影响事务性能：分析查询通过扫描对象存储和少量增量日志完成，不干扰 Postgres 的事务处理。
• 自动覆盖所有表：无需用户手动配置，每张表都自动获得事务与分析的双重能力。
• 与 HTAP 的根本区别：HTAP 在引擎层面统一，LTAP 在存储层面统一，各自使用最适合的引擎（Postgres 事务，Lakehouse 分析）。

意义与影响

LTAP 架构重新定义了现代数据库的存储与计算关系，带来以下深远影响：

1. 消除数据复制冗余：企业不再需要维护一套 OLTP 数据库和一套独立的数据仓库，并通过复杂的 CDC 管道同步数据。LTAP 实现了真正的“一份数据，多种用途”，大幅简化数据栈。
2. 实时分析成为默认能力：分析查询能够立即看到刚刚提交的事务数据，无需等待批量 ETL 或 CDC 延迟，极大赋能实时决策场景（如欺诈检测、实时仪表盘）。
3. 降低基础设施成本：计算与存储解耦，可以独立扩缩；分析查询利用对象存储的廉价容量，不需要为分析负载额外准备高性能热存储；无状态计算节点按需启停，避免资源闲置。
4. 简化运维与合规：高可用、数据备份、时间点恢复等操作都在存储层统一管理，无需复杂的复制拓扑。数据只有一份，审计和合规治理也更加清晰。
5. 推动开放生态：LTAP 采用开放列式格式（Parquet），使得任何兼容 Lakehouse 的工具（如 Spark、Presto、Trino）都能直接访问事务数据，避免了厂商锁定。

总之，LTAP 是传统 OLTP 数据库在云原生时代的一次根本性重构，它保留了 Postgres 的事务可靠性，同时吸收了 Lakehouse 在分析、规模、成本上的优势，为一站式数据基础设施提供了新范式。