由 John Doe 九月 2, 2026
Databricks 抛出了全新的 LTAP 架构，基于原生 Postgres 从存储层彻底重构，让事务和分析共享同一份数据，既完整保留 Postgres 的生态与能力，又直接打通了湖仓的实时分析能力。
目录
从存储层重构数据库，一份数据同时跑事务与实时分析
数据库圈最近扔出了重磅消息：Databricks 正式推出 LTAP（Lake Transactional/Analytical Processing） 架构，在自家 Lakebase 云原生数据库的基础上，彻底撬动了困扰行业几十年的 “事务与分析割裂” 难题。
最关键的是：事务侧全程由原生 Postgres 支撑，完整兼容 wire 协议、SQL 语法、扩展与生态；分析侧直接复用湖仓引擎的高性能能力，两者共享同一份数据。既没有 CDC 同步延迟，也不需要维护两份数据副本，更不会出现分析拖垮事务的情况。
这篇文章我们就拆解一下，LTAP 到底是怎么做到的，它和传统的 HTAP 又有什么本质区别。
传统数据库的死结：单体架构埋下的所有痛点
我们熟悉的绝大多数数据库（Postgres、MySQL、经典 Oracle 等）都是典型的单体架构：数据库引擎和存储都跑在同一台机器上，核心靠两样东西工作：
- WAL（预写日志）：顺序写入，用最小的 I/O 代价保证事务提交的速度与持久性；
- 数据文件：按行组织存储，支撑快速的随机读取与查询。
这套设计沿用了几十年，是数据库工程的经典成果，但也埋下了几乎所有运维痛点的根源：
- 数据风险绑死单机：WAL 和数据都存在本地磁盘，单节点磁盘故障就可能丢数据；刷盘配置稍有不慎，断电或内核崩溃就可能导致已提交数据消失，且故障往往静默发生。
- 扩缩容全靠 “克隆机器”：读流量扛不住就加只读副本，要高可用就加备机，每加一个节点就要全量拷贝一份数据。大库克隆动辄数小时，还可能拖垮生产主库。
- 分析与事务抢资源：跑报表、做数据清理等重负载查询，会和交易业务争抢同一台机器的 CPU 与内存，直接拖慢核心事务；卸到副本又要额外花钱，且行存格式对分析极不友好。
- 数据同步永远慢半拍：想让分析用上事务数据，就得搭 CDC 同步链路，链路脆弱难维护、天然有延迟，还要同时治理两份数据的权限与一致性，成本极高。
追根溯源，所有问题的核心都是同一个：WAL 和数据文件被锁死在单台机器里。
Lakebase 打底：把 Postgres 的存储 “拆” 出来
Databricks 给出的解法，第一步是先把 Postgres 从 “单体” 里解放出来，这就是 Lakebase 架构的核心 ——让计算层无状态，把 WAL 和数据文件分别外化为独立可扩展的云服务。
1. 写扩展：WAL 变成 SafeKeeper
事务提交的持久化不再依赖本地磁盘刷盘，而是交给分布式的 SafeKeeper 服务，通过 Paxos 协议在多节点间同步日志副本。只要多数节点写入成功，事务就算持久化，单机磁盘故障再也不会导致数据丢失。
很多人会问：多走一次网络会不会变慢？ 答案是不会。但凡对可用性有要求的生产 Postgres，本来就要配置同步流复制，本身就有网络开销。而 SafeKeeper 的架构优化反而能带来 5 倍的写入吞吐量提升。
2. 读扩展：数据文件变成 PageServer
数据页被剥离到 PageServer 服务，它持续消费 SafeKeeper 的 WAL 流，异步更新数据页，最终物化到低成本的云对象存储里。PageServer 相当于对象存储的 “写通缓存”，当 Postgres 请求数据页时，优先走多级缓存（内存缓冲池→本地磁盘缓存），缓存未命中才访问 PageServer。
对于绝大多数查询，读延迟和单体数据库几乎没有区别，但换来的是近乎无限的存储容量，以及计算节点秒级扩缩、随时启停的 Serverless 能力。
这一步拆解之后，很多以前难以实现的能力都变成了现实：
- 存储不限量，不用再按峰值规划磁盘容量；
- 计算无状态，负载高时秒级扩容，闲时可缩到零；
- 高可用更简单，数据本身多副本持久化，不用再维护一套全量物理备机；
- 秒级分支 / 克隆 / 时间点恢复，仅操作元数据，不用全量拷贝，测试、高危迁移再也不用怕影响生产。
但到这里还只是 “更好的 OLTP 数据库”，真正的革命，是 LTAP。
LTAP 登场：一份数据，同时跑事务和分析
在 Lakebase 之前，哪怕是计算存储分离的云原生数据库，对象存储里的数据也还是 Postgres 原生的行存格式 —— 事务好用，分析却很难直接高效利用。企业还是得再倒一份数据到数仓 / 湖仓，走 CDC 同步。
LTAP 的核心突破，就是在存储层统一事务与分析：不试图做一个 “全能引擎”，而是让 Postgres 继续管事务、湖仓引擎继续管分析，两者共享同一份开放列式格式的数据。
1. 数据落地即转列式，语义丝毫不差
当 PageServer 把数据物化到对象存储时，会同步把 Postgres 的行存格式转码为 Parquet 列式格式，兼容 Delta、Iceberg 等开放表格式。
最关键的是，这个转码完全保留 Postgres 的原生事务语义：
- 类型系统精准映射：绝大多数 Postgres 类型直接对应 Parquet 原生类型；特殊类型（如高精度 NUMERIC、NaN / 无穷值）通过扩展字段完整保留，可无损还原回 Postgres 原始字节。
- MVCC 多版本完整保留：Postgres 的行版本、快照隔离、时间点恢复能力全部继承；分析引擎看到干净的表级一致性快照，事务引擎依然保留完整的多版本历史。
而且转码工作由 PageServer 的空闲算力完成，完全不占用事务侧 Postgres 的 CPU 资源，事务性能不受任何影响。列式存储还自带超高压缩比，通常能压缩 10 倍以上，进一步降低存储和网络成本。
2. 分析读最新数据，丝毫不影响事务
很多 “湖仓直连事务库” 的方案死在 “数据新鲜度” 上：刚提交的数据还没物化到对象存储，分析就查不到。 LTAP 的解法非常巧妙：
- 分析查询启动时，先向 Postgres 要一个当前的 LSN（日志序列号），这只是一次极轻量的元数据查询；
- 大部分已物化的数据，直接从对象存储的列式文件里读取，充分利用湖仓引擎的并行能力；
- 少数还没来得及物化的最新增量，从 PageServer 拉取，和存量数据合并后，就是截止到该 LSN 的完整最新数据。
整个过程中，Postgres 几乎不承担任何分析负载，只返回一个 LSN 数字。事务该跑多快跑多快，再大的分析查询也不会拖慢交易系统。
3. 所有表自动可用，零配置、零同步
和 CDC、镜像同步方案不同，LTAP 不需要你手动选哪些表要同步、哪些表要入湖。 只要是 Postgres 里存在的表，天然就在湖里、天然可被分析引擎查询。没有 ETL 链路要搭建、没有同步任务要监控、没有两份数据要治理权限，事务写进去的数据，分析端立即可见，永远不会出现两边数据不一致的情况。
LTAP ≠ HTAP：从根上就是两条路
很多人看到 “事务 + 分析” 就会想到 HTAP，但 LTAP 和 HTAP 走的是完全相反的技术路线：
- HTAP：试图用一个引擎同时搞定事务和分析，统一在计算层。
- LTAP：事务和分析各用各自最好的引擎，统一在存储层。
这也直接导致了 HTAP 一直难以大规模普及的三大痛点，LTAP 全部绕开了：
- 功能不会残缺：不用从零打造一个新引擎，事务侧是完整的原生 Postgres，分析侧是成熟的湖仓引擎，SQL 支持、优化器、事务语义全都是经过几十年验证的能力。
- 生态完全复用：Postgres 的所有驱动、扩展、工具链全部能用；湖仓侧的 Spark、BI、AI 生态也全部打通，不用重新适配。
- 性能完全隔离：事务和分析跑在不同的计算资源上，再大的分析任务也抢不到事务的 CPU 和内存，彻底告别 “报表跑死主库”。
简单说：HTAP 想让 “一个引擎打两份工”，而 LTAP 是 “让专业的引擎干专业的事，数据只存一份”。
结语
从单体数据库，到计算存储分离的云原生数据库，再到今天 LTAP 在存储层打通事务与分析，数据库的演进正在一步步解开历史遗留的枷锁。
对于企业来说，LTAP 最实在的价值在于：不用再在 “事务稳定性” 和 “实时分析” 之间做取舍，不用再维护复杂的 CDC 链路和多份数据副本，既保留了 Postgres 生态的全部资产，又能享受湖仓的分析与 AI 能力。
按照 Databricks 的规划，后续还会基于这套架构，把更多重型运维操作从事务核心中剥离出去。LTAP 只是一个开始，存储层的重构，或许会打开下一代数据库的全新想象空间。