2026-07-05Databricks 发了一篇博客讲的是他们把 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.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版