在几分钟内将数TB数据加载到Lakebase Postgres
内容提要
Lakebase 的 LTAP 架构将大批量数据加载从主库卸载到 Spark 分布式引擎，避免与在线事务争抢资源。Spark 通过沙箱 Postgres 生成合法堆页和索引，主库仅发布结果。1TB 数据加载不到 5 分钟，客户每日 10 亿行同步从 8 小时大幅加速，且不影响线上性能。
延伸解读
LTAP 架构如何绕过单写入瓶颈
传统 Postgres 中，所有批量加载都必须经过主库这一个写入点，即使使用 Spark 并行读取，每一行仍需通过单个 Postgres 写入器，导致主库成为瓶颈。LTAP 架构将持久状态移至分布式存储层，使 Spark 可以直接构建 Postgres 堆页和索引，主库仅发布结果，从而彻底绕开单写入限制，实现近乎线性的吞吐扩展。
沙箱 Postgres 与页面验证机制
每个 Spark 执行器启动一个沙箱 Postgres 实例，利用 binary-upgrade 模式移植目标目录的 OID，确保生成的页面与目标数据库兼容。通过 FREEZE 标记元组为已提交，并计算页面校验和，由 pageserver 验证，防止损坏数据成为权威页面。这些机制在不修改 Postgres 核心的前提下，通过扩展和表访问方法实现。
索引构建的优化策略
由于堆数据分布在多个上传切片中，索引构建器无需下载整个堆。每个堆工作器导出键列和元组 ID 到对象存储，索引构建器通过自定义表访问方法扫描仅包含这些信息的辅助表，并将切片本地 ctid 偏移为最终位置，从而用标准 B-tree 构建器生成索引，大幅减少数据移动。
对在线事务性能的实际影响
在测试中，客户每日加载约 10 亿行数据，原本需要超过 8 小时并完全饱和主库 CPU 和内存，即使自动扩展也需过度配置。采用 LTAP 后，加载速度大幅提升，且在线事务性能完全不受影响。内部基准显示加载 1 TB 数据仅需不到 5 分钟，但当前仅测量堆页构建时间，索引并行构建仍在开发中。
Q&A
LTAP架构是什么？它如何提升Lakebase Postgres的批量加载性能？
LTAP（Lake Transactional/Analytical Processing）架构允许事务型和分析型引擎在数据湖中处理完全相同的数据。它通过将大批量数据加载从主计算节点卸载到Spark等分布式引擎，避免与在线事务争抢资源，从而提升批量加载性能。
使用LTAP架构加载1TB数据需要多长时间？
根据内部基准测试，加载1TB数据现在需要不到5分钟。注意：该基准测试测量的是数据加载时间（构建堆页面），索引构建的并行化仍在进行中。
传统Postgres批量加载的主要瓶颈是什么？
传统Postgres架构中，主库是持久状态的唯一守门人，批量加载必须通过这个单一瓶颈。每一行导入都会在同一个实例上生成堆页面、更新索引并写入WAL记录，同时该实例还服务于在线应用流量，导致资源竞争和性能下降。
LTAP架构如何确保Spark生成的页面能被目标Postgres数据库正确读取？
通过以下机制：每个Spark执行器启动一个沙箱Postgres实例，使用二进制升级模式移植目标目录的OID；使用FREEZE标记元组为已提交；驱动分配不重叠的OID范围；每个工作节点计算页面校验和，由pageserver验证。这些确保生成的页面符合标准Postgres格式。
LTAP架构如何优化索引构建过程？
索引构建器不需要堆内容，只需要（键，ctid）对。每个堆工作节点在构建切片时导出键列和元组ID到对象存储文件。然后使用自定义表访问方法扫描仅包含这些信息的辅助表，在CREATE INDEX期间将ctid写入索引条目，并调整ctid指向最终堆位置。这样标准B-tree构建器无需下载整个堆即可构建索引。
LTAP架构如何避免批量加载影响在线事务性能？
LTAP架构将批量加载完全卸载到Spark，主库仅发布结果。主库不再需要处理每一行的堆页面生成、索引更新和WAL写入，从而释放CPU、内存、I/O等资源，保护在线应用流量不受影响。
