如何在不影响线上系统的情况下导出一个庞大的数据集？

Question

IT Interview Practice · Accepted Answer

**从 replica 或快照读取（绝不从 primary），用 keyset 分页而非 `OFFSET` 翻页，限制读取速率，并把结果直接流式写入对象存储。**目标是导出 5 亿行，同时不持有长锁、不让 primary CPU 尖峰，也不撑爆内存。

## 导出管道

```text
  Primary DB ──async replication──▶ Read replica / snapshot
                                          │  (isolated from live traffic)
                                          ▼
                                   Export worker
                              keyset page: WHERE id > :last
                                          │  throttle (sleep / rate limit)
                                          ▼
                                   Stream (batches)
                                          │
                                          ▼
                                   S3 / GCS  (NDJSON / Parquet)
```

## 每个部件为何存在

- **Read replica 或快照。**把作业指向一个 follower，使繁重的读取绝不与 primary 上的生产写入竞争。**快照**提供一个稳定的、时间点的视图，使导出即便在实时数据持续变化时也保持一致。
- **Keyset 分页，而非 `OFFSET`。**`OFFSET 10000000` 会让 DB 每页扫描并丢弃 1000 万行——整个导出是 O(n²)。keyset 记住最后一个键并执行 `WHERE id > :last ORDER BY id LIMIT 5000`，它沿着 index 前进，每页 O(1)。
- **限流。**在批次之间 sleep 或限制每秒行数，使 replica 不被饱和，且 replication lag 保持有界。
- **流式写入对象存储。**把每一批以 NDJSON 或 Parquet 写入 S3/GCS；绝不把整个结果集加载进内存。使用游标/服务端游标（server-side cursor），使驱动程序流式地读取行。

## 面试视角

面试官检查你是否保护了线上系统。指出 **replica** 是入门要求；资深信号是**用 keyset 取代 OFFSET**（并能解释 O(n²) 陷阱），加上**反压/限流**以及通过快照实现的**一致性**。一个常见陷阱：在一个事务里执行单个 `SELECT *`——它会把一个读视图保持打开数小时，使 DB 膨胀（Postgres 的 vacuum 无法清理长快照仍能看到的行），并把所有内容缓冲在内存中。

**权衡：**replica 可能有滞后，因此导出反映的是一个略微陈旧的时刻——对分析通常没问题，但对需要"此刻精确"数据的财务对账则不行。keyset 需要一个稳定、唯一、有 index 的排序键；它对任意排序顺序很不方便。当表非常庞大且你掌控存储层时，一个原生工具（`pg_dump`、快照导出到 S3、`COPY`）往往胜过手写的分页。

导出管道

每个部件为何存在

面试视角

相关问题