LTAP架构详解：Postgres数据以Parquet格式存储S3实践

引言：数据库架构的新范式

在传统数据库世界中，OLTP（在线事务处理）与OLAP（在线分析处理）长期被视为两个独立领域——前者追求低延迟事务读写，后者专注大规模数据的高效分析。这一分野并非偶然：E.F. Codd（埃德加·科德）于1993年在其论文《Providing OLAP to User-Analysts: An IT Mandate》中正式提出OLAP概念，并给出了著名的"FASMI"定义（Fast Analysis of Shared Multidimensional Information）。值得注意的是，Codd本人也是关系模型的奠基人——正是他在1970年的论文《A Relational Model of Data for Large Shared Data Banks》中构建了现代关系数据库的理论基础。

OLTP系统以高并发、短事务为核心特征，在存储层面通常采用B+树索引（如Postgres的heap存储搭配B-tree索引），以行为单位组织数据，优化随机点查和短事务，强调ACID（原子性、一致性、隔离性、持久性）保证；OLAP系统则面向决策支持，多采用列式存储和位图索引，处理跨越数百万行的聚合分析。两类系统在缓冲池管理、锁粒度、日志策略以及索引结构和查询优化器设计上存在根本差异，这也是HTAP（Hybrid Transactional/Analytical Processing）至今仍是业界重大挑战的根本原因。

HTAP之所以如此困难，根源在于OLTP与OLAP在存储引擎层面存在深层的物理矛盾。行式存储对单行随机访问友好，因为一行数据物理连续，一次磁盘I/O可取出完整记录；但全表聚合时需读取每行的所有字段，大量无关列数据浪费带宽。列式存储则相反：聚合操作只需顺序扫描目标列，CPU缓存利用率极高，但更新单条记录需要定位并修改多个列文件。此外，事务隔离（MVCC）与列式压缩在实现上存在天然张力——MVCC需要保存多个行版本，而列式压缩的高效性依赖数据稳定性。这些根本性的物理约束，导致企业长期需要维护两套系统，并依靠每日批处理的ETL管道在两者间同步数据，引入数据延迟的同时带来高昂维护成本。

随着云原生技术和对象存储的普及，一种新的架构思路正逐渐成熟：LTAP（Lightweight Transactional and Analytical Processing），即将Postgres数据以Parquet列式格式存储在S3等对象存储上。

这一思路的核心在于：打破存储与计算的紧耦合，让同一份数据既能服务于事务处理，又能高效支撑分析查询。 本文将从技术原理到实践权衡，系统解析LTAP架构的设计逻辑与现实价值。

为什么要把Postgres数据存到S3？

存储成本与弹性的双重优势

传统Postgres将数据存储在本地块存储（如EBS）或挂载磁盘上，存储与计算强绑定，扩容时往往需要同步扩展两者，成本高且缺乏弹性。

Amazon S3（Simple Storage Service）于2006年正式推出，是云计算时代最具影响力的基础设施之一。对象存储（Object Storage）的设计哲学与传统文件系统截然不同——块存储提供原始磁盘块访问，支持字节级随机读写；文件存储提供POSIX兼容的文件系统语义；而对象存储则以HTTP REST API（GET/PUT/DELETE）为接口，以键值对形式管理不可变对象。S3采用扁平化命名空间，通过唯一键（Key）寻址对象，底层数据以不可变（Immutable）方式写入——这意味着"修改"操作实际上是创建新对象并替换元数据引用。这种不可变性并非限制，而是架构优势：它使得多版本控制（Versioning）、跨区域复制（CRR）和强一致性（S3于2020年12月宣布实现强一致性）的实现大为简化。在持久性（AWS承诺11个9）和成本上也具有极大优势：S3 Standard存储约为0.023美元/GB/月，而高性能EBS（gp3）约为0.08美元/GB/月，差距高达3倍以上。值得注意的是，S3的高请求成本（PUT请求约0.005美元/1000次）也促使LTAP架构必须将小写入合并为批量写入，这在架构设计上有着深远影响。

将数据迁移至S3对象存储，可带来三项显著收益：

成本大幅降低：S3单位存储成本远低于高性能块存储，尤其适合冷数据和历史归档。
近乎无限的扩展性：对象存储天然支持海量数据，彻底消除单机容量瓶颈。
真正的存算分离：计算节点可按需启停、弹性付费，闲时无需为存储持续买单。

Parquet：为分析场景而生的列式格式

选择Parquet而非Postgres原生行式堆存储（heap），是LTAP架构发挥分析性能的关键。Apache Parquet由Twitter工程师Julien Le Dem和Cloudera联合设计，其设计灵感直接来源于Google 2010年发表的《Dremel: Interactive Analysis of Web-Scale Datasets》论文中描述的列式存储与嵌套数据模型，于2013年成为Apache顶级项目。其文件结构分为三层：文件级（File）、行组（Row Group，默认128MB）和列块（Column Chunk）。每个Row Group内，数据按列连续存储，并为每列维护min/max、null count等统计信息（Statistics）。

Parquet支持复杂嵌套数据类型（Map、List、Struct），并通过Dremel的"definition level"和"repetition level"机制精确编码嵌套结构。在编码层面，Parquet内置多种编码方式：字典编码（Dictionary Encoding）适合低基数列，Delta编码（Delta Encoding）适合时间戳等单调递增数据，RLE（Run-Length Encoding）适合大量重复值，游程位图（Bit-packing）进一步降低整数存储开销。

Parquet作为列式存储格式，具备三大核心优势：

列裁剪（Column Pruning）：分析查询通常只涉及少数列，Parquet可精准读取所需列，显著减少I/O开销。
高压缩比：同列数据类型一致，支持字典编码、Delta编码等多种压缩方式，压缩比通常达行式格式的3-10倍。
谓词下推（Predicate Pushdown）：利用每个Row Group的min/max统计元数据，查询引擎可在扫描前直接跳过不满足条件的Row Group（Row Group Skipping），在选择性高的查询中可跳过90%以上的数据读取。Parquet的页级统计信息（Page Statistics）和行组统计信息（Row Group Statistics）构成了谓词下推的数据基础，这一机制在Apache Arrow项目中被进一步标准化为"Dataset API"，成为现代分析引擎的通用优化手段。

简言之，行式存储擅长OLTP的点查与写入，列式存储擅长OLAP的聚合与全表扫描。LTAP架构的目标，正是让Postgres在保留完整事务能力的同时，获得列式存储的分析性能红利。

LTAP架构的核心设计

事务与分析能力的统一

LTAP名称中的"Lightweight"（轻量）是理解这一架构的关键词。它并不追求成为重量级分布式数据仓库，而是在Postgres生态内以较低复杂度同时承载两类工作负载。典型实现思路分为三层：

热数据留在Postgres本地：近期频繁读写的数据以行式格式存储在本地，保障事务低延迟。
冷数据下沉至S3 Parquet：历史与分析型数据以Parquet格式归档到对象存储，节省成本。
透明查询层：通过外部表（Foreign Data Wrapper）或扩展机制，用户以标准SQL无感知地跨本地与远程数据查询。

在实现热数据到S3的数据同步时，PostgreSQL的WAL（Write-Ahead Log）机制是不可忽视的关键基础。WAL采用预写日志策略：所有数据变更在写入实际数据页之前，先以日志记录形式顺序写入WAL文件，这保证了崩溃恢复能力。在LTAP场景中，可通过逻辑复制（Logical Replication）或WAL解析工具（如pgoutput、wal2json）将WAL日志流解码为行级变更事件，再由专用进程将这些变更批量转换为Parquet格式写入S3。这一路径天然保留了事务边界信息，使得S3上的Parquet数据可与Postgres主库保持事务级一致性，而非仅仅是周期性快照。

关于透明查询层，Foreign Data Wrapper（FDW）源自ISO/IEC 9075-9:2003标准（即SQL/MED，SQL Management of External Data），该标准定义了通过标准SQL访问外部数据源的统一接口规范。PostgreSQL自9.1版本（2011年发布）起实现FDW框架，并在9.3版本中增加了写入支持，在PostgreSQL 10中引入了并行扫描能力。FDW的核心API包括：GetForeignRelSize（估算外部表行数与代价）、GetForeignPaths（生成访问路径）、GetForeignPlan（生成执行计划）和IterateForeignScan（实际数据扫描）等函数。

在LTAP场景中，parquet_fdw扩展实现了对S3上Parquet文件的透明访问，其关键优化在于谓词下推（Pushdown）——查询优化器将WHERE条件中可下推的谓词传递给FDW，由FDW在读取Parquet文件时利用行组统计信息跳过不满足条件的数据块，避免将全部远程数据拉取至本地，使得用户以统一SQL端点同时查询本地热数据与S3冷数据。近年来，以DuckDB为后端的FDW方案（如pg_duckdb扩展）进一步将DuckDB的向量化执行引擎引入Postgres查询路径，在分析查询性能上取得了数量级的提升。

DuckDB之所以能在分析查询上取得如此显著的性能提升，核心在于其向量化执行引擎（Vectorized Execution Engine）的设计。传统火山模型（Volcano Model）每次调用next()只返回一行数据，函数调用开销在大数据量下不可忽视。向量化执行借鉴了MonetDB/X100的设计，每次处理一个批次（通常1024-8192行）的数据，以列式内存布局配合SIMD指令集（如AVX-512）实现并行计算，CPU分支预测命中率也大幅提升。DuckDB还深度优化了对Parquet格式的原生读取，能够直接将Parquet的列块解压为内存中的Arrow列式格式，无需中间转换。与pg_duckdb扩展结合后，Postgres查询优化器可将分析型子查询路由至DuckDB引擎执行，再将结果返回给PostgreSQL的执行层，从而在不改变用户SQL接口的前提下实现透明的性能加速。

与Lakehouse理念的深度契合

LTAP架构在设计思想上与近年兴起的**Lakehouse（湖仓一体）**高度呼应。Lakehouse概念由Databricks于2020年在论文《Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics》中正式系统化，其核心洞察是：传统数据湖虽然存储成本低且格式开放，但缺乏ACID事务支持；而传统数仓封闭的存储格式（如Redshift的内部格式）则造成厂商锁定。

Lakehouse通过在对象存储上构建事务元数据层来解决这一矛盾。目前三条主要技术路线各有侧重：Delta Lake（2019年开源）以JSON格式的事务日志记录所有变更，依赖Spark生态深度集成；Apache Hudi（Uber于2019年捐献至Apache基金会）以Upsert性能和增量处理为核心优势；Apache Iceberg（Netflix于2018年启动，2020年成为Apache顶级项目）则以纯开放规范著称——它将表的元数据、快照、清单文件（Manifest）和数据文件完全解耦，任何符合规范的引擎均可读写同一张Iceberg表，这使得Iceberg在多引擎互操作场景中脱颖而出。Apache Iceberg的时间旅行（Time Travel）能力依赖快照（Snapshot）机制：每次写入操作生成新快照，旧快照保留在元数据层，查询时可通过AS OF语法指定任意历史时间点，在数据审计和回滚场景中具有极高价值。LTAP架构如能在Parquet文件层之上引入Iceberg表格格式，可直接获得这些能力，是未来演进的自然方向。

LTAP则从数据库侧切入，以Postgres为入口，将数据以开放的Parquet格式落储于湖中，是从数据库侧向Lakehouse演进的一条清晰路径。

这种方式的核心价值在于数据开放性：Parquet是业界通用格式，存储在S3上的数据可被Spark、DuckDB、Trino、Athena等主流引擎直接消费，彻底规避数据被锁定在专有格式中的风险。

技术挑战与架构权衡

写入放大与数据一致性

对象存储并非为频繁小写入设计。S3对象本质上不可变，更新单条记录往往意味着重写整个文件，写入放大问题不可忽视。

业界常见解法是引入LSM（Log-Structured Merge）思路或分层写入机制。LSM树由Patrick O'Neil、Edward Cheng等人于1996年在论文《The Log-Structured Merge-Tree (LSM-Tree)》中正式提出，其设计动机是优化面向机械硬盘的写入性能——顺序写入的吞吐量可比随机写入高出1-2个数量级。被RocksDB（Meta开发，LevelDB的高性能分支）、Cassandra、LevelDB等众多现代存储引擎广泛采用，RocksDB还被TiDB、CockroachDB等NewSQL数据库作为底层存储引擎。其核心思想是将随机写入转化为顺序写入：新数据首先写入内存中的MemTable，溢出后以不可变的SSTable文件形式顺序刷写，后台Compaction进程定期合并多个文件并消除过期版本。

将这一思路应用于LTAP场景时，可将本地Postgres缓冲区类比为MemTable，WAL日志类比为Commit Log，而定期将数据批量合并为S3上的Parquet文件则对应Compaction过程——将随机写入的性能瓶颈转移为后台批处理，有效平衡写入频率与存储效率。值得注意的是，与磁盘LSM不同，对象存储的Compaction需要在网络传输开销、API调用成本和最终数据有序性之间做出更精细的权衡，这也是Iceberg、Delta Lake等湖表格式在元数据层引入"小文件合并"（Small File Compaction）机制的原因。

查询延迟

访问S3的网络延迟远高于本地磁盘。对交互式低延迟查询而言，直接读取S3往往难以满足响应要求。通常需要组合本地缓存、元数据索引和合理的数据分区策略来系统性缓解这一瓶颈。

在S3上合理组织Parquet文件的分区结构，是降低查询延迟的核心手段之一。Hive分区风格（如s3://bucket/table/year=2024/month=01/）允许查询引擎根据分区键直接跳过无关目录，将S3 LIST操作的开销降至最低。分区键的选择直接影响查询效率：时间维度（如按天、月分区）适合时序数据；高选择性的业务键（如tenant_id、region）适合多租户场景。过细的分区粒度会导致小文件问题（每个Parquet文件过小，元数据开销占比过高），过粗则谓词下推效果差。实践中通常结合Parquet文件内部的Row Group Statistics与外部分区剪枝（Partition Pruning）两层过滤机制，在文件组织与查询效率之间取得平衡。

运维复杂度

尽管LTAP强调"轻量"，但引入对象存储、格式转换、缓存层等组件后，整体系统复杂度依然会提升。团队需要在存储成本节约与运维负担之间做出清醒的权衡。

适用场景与未来展望

LTAP架构目前更适合以下业务场景：

数据量大但访问频率分化明显：海量历史数据下沉S3归档，热数据保留本地，冷热分层存储效益显著。
需要分析能力但不想维护独立数仓：在Postgres内直接完成轻量级分析，简化整体技术栈。
重视数据开放性与互操作性：数据以标准Parquet格式存储，跨引擎流通无障碍。

值得关注的是，这一方向已有多个开源项目和商业产品在积极探索，包括各类Postgres S3扩展、外部表方案及新兴湖仓数据库。它们的共同目标是：让存算分离和列式分析成为Postgres的原生能力。

结语

LTAP架构代表了数据库演进的一个值得关注的方向：不再机械地划分OLTP与OLAP边界，而是通过存算分离与开放格式，让一套系统灵活应对多样化工作负载。将Postgres数据以Parquet格式存储在S3上，本质上是在拥抱云时代的三大核心诉求——成本效益、弹性扩展与数据开放。

这一架构仍处于快速演进阶段，写入放大、查询延迟等工程挑战尚需持续打磨。但对于追求精简技术栈、同时希望兼顾事务与分析能力的团队而言，LTAP无疑是一个值得深度关注的技术趋势。