澄清关于LTAP的误解
内容提要
文章澄清了关于Lakebase/LTAP的四个误解：湖是数据库的唯一持久存储而非副本；Postgres的堆页、索引和缓存只是同一逻辑表的层级，不构成第二个数据库；列式Parquet与行式堆页是无损的两种编码，服务于不同访问路径；分析查询通过LSN读取一致快照，未落湖的最新提交从pageserver读取，无需CDC管道。逻辑复制逐行重放WAL、携带状态且不传DDL，成本高，不适合作为湖存储。
延伸解读
如何判断“第二副本”：能否独立查询或故障切换
文章提出一个清晰标准：如果某一层数据能被当作独立数据库查询或故障切换，它就是副本；否则只是层级。Postgres的WAL、缓存、索引都存储与堆页重叠的字节，但没人称索引为副本，因为它没有自己的目录和时间线。LTAP把同样的层级搬到对象存储上，湖是唯一持久副本，前面的层只是让表持久且快速的缓存。CDC则不同，它解码出外部模式并写入源库从不读回的表，形成两个可独立查询、可能漂移的目录。
列式Parquet与行式堆页：无损编码服务不同访问路径
文章澄清“一份逻辑副本不等于一种编码”。只要两种格式能无损表示同一行数据，就可以让点查走8KB堆页、扫描走Parquet，各取所需。索引仍留在热层，不转码为Parquet。文章也指出一个有效局限：Postgres生成的列式文件按堆页顺序排列，适合重建页和重写脏页，但不适合按日期范围做聚簇；若仓库查询需要这种聚簇，可像silver表一样从操作源派生，而不再需要以创建湖副本为目的的CDC管道。
分析查询的新鲜度：LSN作为一致快照的截止点
文章反驳“分析总是落后”的直觉。Iceberg/Delta在对象存储上提供快照隔离，但对象存储延迟高，容易让人以为查询只能看到已落湖数据。LTAP中，分析查询还能看到尚未进入对象存储的页：查询开始时，Postgres只返回少量近期页，引擎以LSN为截止点，从pageserver读取最新提交。同一LSN也保证跨表连接一致，类似REPEATABLE READ，而不是各管道最后刷新的时间点。小表因Iceberg元数据开销大，可留在页缓存并参与LSN一致读。
逻辑复制为何不适合作为湖存储：读放大与状态负担
文章指出逻辑复制逐行重放WAL，无法把同一页的多次更新合并为当前页镜像。热页在检查点间可能记录上百次，逻辑解码就产生上百个事件，下游再按主键upsert；而页分层路径只读一次页。逻辑复制还携带状态：复制槽落后会占满磁盘，且不传DDL，ALTER TABLE、类型变更、重命名会导致事件与目录不一致，无主键表需REPLICA IDENTITY FULL。因此它通常只用于部分表，与“每个Postgres表都出现在湖中”相反。文章也澄清并行解码WAL不可行，因为日志记录有序且可见性依赖LSN处的pg_xact、proc a
Q&A
LTAP 和 CDC 到底有什么区别？为什么说 LTAP 不是 CDC？
LTAP 不是 CDC，因为 CDC 会创建一个可独立查询、可故障切换的第二数据库（通常按主键 upsert 到外部表），存在类型漂移、DDL 丢失、复制槽丢行等风险，导致两个 catalog 不同步。而 LTAP 只保留一份逻辑表，湖是它的持久存储，Postgres 的堆页、索引和缓存只是服务该表的层级，没有第二张表需要同步，也不存在需要选择加入的表列表。
LTAP 中 Postgres 的堆页、索引和缓存算不算第二份数据副本？
不算。判断是否为副本的标准是：该层能否作为独立数据库被查询或故障切换。堆页、索引和缓存都没有自己的 catalog 或时间线，它们只是同一逻辑表的层级，用于让 Postgres 以 OLTP 延迟服务该表。类似地，S3 对象存储本身也会多副本存储，但 API 只命名一个对象，没有同步任务。
LTAP 同时使用行式堆页和列式 Parquet，这会不会导致数据重复或不一致？
不会。LTAP 的两种格式是无损编码，可以表示相同的行而不丢失信息。列式 Parquet 作为湖中的持久存储，堆页则成为它的缓存。点查询走 8KB 堆页（计算节点、本地磁盘、pageserver），扫描走 Parquet（OLAP 引擎），索引保留在热层不转码。这类似于 Postgres 用堆和覆盖索引服务不同访问路径，但逻辑上仍是一张表。
LTAP 如何保证分析查询能看到最新提交的数据？会不会有延迟？
LTAP 中每个分析查询读取一致快照。尚未落入湖的最新提交从 pageserver 读取，因此查询不会漏掉已提交的数据。查询使用 LSN 作为截止点，告诉引擎合并需要到哪一步，并保证跨表连接的一致性（所有表在同一 LSN 读取，类似 REPEATABLE READ）。小表留在页缓存中参与 LSN 一致读，跳过 Iceberg 提交，因此小表不是新鲜度限制，而是元数据开销。
为什么逻辑复制不适合用来把 Postgres 数据同步到湖里？
逻辑复制成本高：它逐行重放 WAL 的每个变更，无法将同一页的多次更新合并为当前页镜像，热页可能产生上百个事件；它携带状态（复制槽必须持续前进，否则 WAL 堆积），且不传 DDL，导致 ALTER TABLE、类型变更等使事件与 catalog 不一致；无主键表需要 REPLICA IDENTITY FULL。此外，它通常只应用于部分表，与 LTAP 中所有 Postgres 表自动出现在湖里的理念相反。
LTAP 能否并行解码 WAL 来加速数据提取？
不能。WAL 记录是有序的，后续记录依赖前面的记录，可见性信息存在于 pg_xact、proc array 和该 LSN 的 catalog 中，而非元组内，因此独立 worker 无法各自解码不相交的字节范围并输出正确的当前行。LTAP 并行化的是页，而不是日志记录：它通过 WAL 摘要（Postgres 17+）或 pageserver 的 LSM 树找出自上次快照以来变更的页，每个脏页独立处理，分区后转码并提交一个 Iceberg 快照。
