2026-07-05

Databricks 发了一篇博客，讲的是他们把 PostgreSQL 的数据存到 Parquet 格式里，然后放在 S3 上。不读不知道，读完我盯着屏幕愣了三秒。

这不是普通的"我们改了个存储方案"那种文章——他们直接在 Postgres 和对象存储之间搭了一座桥，让 SQL 查询可以直接跑在 S3 上的 Parquet 文件上。而且不是只读的那种，是完整的读写事务。

等等。你说 Postgres 的数据存在 Parquet 里？还是 S3 上？那 ACID 咋办？

Lakebase LTAP 到底是个啥

简单说，Databricks 搞了个叫 Lakebase 的东西，LTAP 是它的核心架构——Long-Term Analytical Processing，长期分析处理。

等一下，我知道你在想什么。"不就是把数据从 Postgres 导到数据湖那一套吗？ETL 我都做了十年了。"不是。完全不是。

传统方案是：Postgres 负责 OLTP（在线事务处理），数据通过 ETL 管道导到数据湖或数据仓库，然后在上层做分析。这套流程里有个天然的矛盾——数据同步永远有延迟，而且存储两份数据意味着双倍的成本和管理负担。

Databricks 的做法激进得多：直接在 Postgres 内部用 Parquet 格式存数据，底层存储放在 S3 上。

这意味着什么？意味着你的 PostgreSQL 实例的底层存储不再是本地磁盘或者 EBS 卷，而是 S3 上的 Parquet 文件。查询引擎可以同时跑事务查询和分析查询，不需要复制数据。

我喝了口咖啡继续看。

架构拆解：它到底是怎么工作的

说实话，看到"\<0\>Parquet on S3"这个组合，我第一个想到的问题是延迟。

S3 的延迟在毫秒到几十毫秒级别，比本地 SSD 慢一到两个数量级。把在线事务系统跑在 S3 上，听起来就像用卡车送外卖——送到的时候订单都凉了。

但 Databricks 的方案不是简单粗暴地把整个 Postgres 数据目录扔 S3 上。它的架构有几个关键设计：

缓冲区 + 分层存储。 热数据（最近操作的数据页）缓存在本地 SSD 上，冷数据自动下沉到 S3 上的 Parquet 文件。这个思路不新鲜——很多数据库都做过类似的分层存储。但关键区别在于，下沉的不是原始数据页，而是转换后的列式格式。

这就有意思了。

传统 Postgres 存的是行式数据（heap），一条记录的所有字段连续存放。而 Parquet 是列式存储，同一列的数据连续存放。对于分析查询——比如"求去年所有用户的消费总和"——列式存储只需要读取那一列的数据，IO 量可能只有行式的十分之一甚至更少。

我原本以为这只是个冷热分离的噱头……后来发现，整个查询引擎都被改写了。

真正颠覆的地方在哪里

这不是简单的"加个存储层"。

Databricks 把 Parquet 文件变成了 Postgres 的原生表格式。这意味着你的 SQL 查询——不管是简单的 SELECT，还是复杂的 JOIN + GROUP BY——都能直接访问 Parquet 文件，不需要额外的转换层。

等一下，这不是跟 pg_parquet 扩展一样吗？我用过那个扩展，它允许 Postgres 读取 Parquet 文件，但功能非常有限——主要是导入导出数据，不适合在线查询。

Lakebase 的做法完全不同：

第一，Parquet 文件是主存储，不是备份。你的数据在 Postgres 里本身就是 Parquet 格式，不需要导入导出。写入时直接写 Parquet，读时直接从 Parquet 读。

第二，利用 S3 的无限存储空间。传统 Postgres 受限于单机磁盘容量，即使分片也有天花板。S3 理论上无限，你不需要再担心"磁盘满了怎么办"这种问题了。

第三，与 Spark/Delta Lake 的原生互操作。因为数据已经是 Parquet 格式，Spark 作业可以直接读取同一份数据，不需要经过任何导出管道。ETL 环节直接消失了——不是简化，是彻底消失。

怎么说呢。这套方案让之前我们架设的"实时数仓"架构显得像个笑话。

但我还是有疑问

第一点，写入性能。Parquet 是列式格式，它的设计假设是一次写入、多次读取。而 Postgres 的大量操作是频繁的小写入——INSERT、UPDATE、DELETE。每次小写入都要生成一个新的 Parquet 文件？还是说后台有合并机制？

揉了揉眼睛，我重新看了他们的架构描述。原来他们确实保留了行式写入缓冲区——小写入先写到本地的行式存储里，达到阈值后才批量转换成 Parquet 下沉到 S3。所以短时间的小写入性能并不会崩，长尾的大批量数据才会列式化。这合理。

第二点，事务隔离。Postgres 用 MVCC（多版本并发控制）来保证事务隔离。当数据分散在本地缓冲区和 S3 上的多个 Parquet 文件里时，MVCC 还能正常工作吗？

Databricks 的答案是：他们保留了 Postgres 的事务日志机制，但把可见性信息嵌入到了 Parquet 文件的元数据中。每个 Parquet 文件都记录了它所包含数据的事务范围，查询引擎在读取时会根据当前事务的快照信息过滤不可见的数据。

嗯，有那味儿了。

第三点，成本。S3 的存储成本确实比 EBS 低，但 Parquet 文件的小文件问题很严重——大量小文件会导致读放大和元数据开销。如果每个小写入都生成一个小 Parquet 文件，S3 的 LIST 操作会变得很慢。

他们在博客里提到了一个 Compaction Service，后台自动合并小文件。这个机制在 Delta Lake 里就已经实现了，所以有一定的成熟度。

谁在乎？反正我在乎——因为小文件合并是个典型的"后台跑着跑着就跑崩了"的场景，但愿 Databricks 在这方面做得好。

这个方案适合谁

讲真，不是所有人都需要这个方案。

如果你只是跑一个小型业务系统，日活几千、数据库几十 GB，传统 Postgres 已经够用了。Lakebase 的优势在大数据量和混合负载场景下才能体现出来：

• 你的业务数据库已经超过 1TB，分库分表让你头疼
• 你的分析团队频繁问你要数据库的只读副本，每次都给整一个只读实例，成本扛不住
• 你的 ETL 管道越来越复杂，维护成本已经超过了业务价值

如果你中了以上任意一条，Lakebase LTAP 值得关注。

我的一点看法

这不是一个已经成熟的产品。博客里也说了，这是他们的"实验性架构"，还在完善中。

但它的方向我觉得是对的。数据库的未来不是 OLTP 和 OLAP 分裂，而是融合。用户不需要关心"我的数据在事务库还是在分析库"，他们只需要知道数据在那里、查询能跑就行。

Parquet on S3 这个组合在分析领域已经证明了自己——Delta Lake、Iceberg、Hudi 都是基于类似的思路。现在 Databricks 想把这条路延伸到事务领域，让同一份 Parquet 数据同时服务事务和分析。

卡——死——了。

两个世界之间的墙被拆掉的那一刻，就是真正统一数据平台的那一天。

冲的咖啡已经凉了。算了，再续一杯吧。

关于维基框架

维基框架（Wiki Framework）是一套面向复杂业务场景的轻量级开发框架，支持多语言、多协议、多部署形态。适用于企业级应用开发、微服务架构、云原生部署等场景。

官网：framewiki.com

Gitee：gitee.com/wiki-framework

GitHub：github.com/wiki-framework

示例项目：gitee.com/cdkjframework/framewiki-example

📄 许可证：MulanPSL-2.0（木兰宽松许可证，第2版）