Streambed：Postgres 到 Iceberg 的实时 CDC 管道与查询代理

生产环境的 PostgreSQL 数据库长期面临一个两难困境：OLTP 事务负载与 OLAP 分析查询争夺相同的计算资源。传统解决方案通常涉及复杂的 ETL 管道 —— 从逻辑复制到消息队列，再经 Spark 或 Flink 写入数据湖，最终通过 Trino 或 Presto 提供查询服务。这种架构链路长、组件多、运维成本高。

Streambed 提供了一种更直接的思路：它作为 Postgres 的逻辑复制订阅者，实时捕获 WAL（Write-Ahead Log）变更，将其转换为 Parquet 文件写入 S3，同时维护 Apache Iceberg 的表元数据。更重要的是，它内置了一个查询服务器，通过 Postgres wire 协议暴露 Iceberg 表，用户可以直接使用 psql 或任何 Postgres 客户端进行查询。

架构设计与数据流

Streambed 的数据流可以概括为五个阶段：

Postgres WAL ──▶ Decode ──▶ Buffer ──▶ Parquet ──▶ S3 ──▶ Iceberg Commit
                                                              │
                                                    DuckDB ◀──┘ (query server)

在复制阶段，Streambed 以逻辑复制槽（replication slot）的形式连接到源 Postgres，订阅 pgoutput 或 test_decoding 插件输出的变更流。对于 INSERT 操作，数据被缓冲并按表分区，达到阈值后批量写入 Parquet 文件。对于 UPDATE 和 DELETE，Streambed 采用 copy-on-write 策略：读取现有 Parquet 文件，合并变更后生成新版本，确保 Iceberg 表的时间旅行（time travel）语义完整。

查询层使用嵌入式 DuckDB 作为执行引擎。DuckDB 直接读取 S3 上的 Iceberg 元数据，无需额外的 catalog 服务。Streambed 在 DuckDB 之上实现了 Postgres wire 协议的前端，将客户端的 SQL 查询解析后交由 DuckDB 执行，再将结果集封装为 Postgres 协议格式返回。这种设计使得现有的 BI 工具、ORM 框架无需修改即可接入，降低了迁移成本。

部署配置与关键参数

Streambed 采用 Go 1.22+ 编写，依赖 CGO 以链接 DuckDB 和 SQLite（用于本地状态存储）。以下是本地测试环境的启动配置：

# 启动 Postgres + MinIO
docker compose up -d

# 构建（需安装 Go 和 CGO 工具链）
go build -o streambed ./cmd/streambed

# 启动同步与查询服务
./streambed sync \
  --source-url="postgres://postgres:test@localhost:5432/postgres" \
  --s3-bucket="streambed" \
  --s3-endpoint="http://localhost:9000" \
  --s3-prefix="test" \
  --query-addr=:5433

关键配置参数包括：

• --source-url：源数据库连接字符串，需确保 Postgres 已开启 wal_level=logical 并创建复制槽
• --s3-bucket、--s3-endpoint、--s3-prefix：目标存储配置，支持 MinIO 等兼容 S3 的对象存储
• --query-addr：查询服务器监听地址，默认 5433，与源数据库端口错开避免冲突
• --buffer-size 和 --flush-interval：控制 Parquet 文件的生成频率，平衡实时性与小文件问题

所有参数均支持通过 STREAMBED_ 前缀的环境变量注入，便于容器化部署。

运维命令与数据回填

Streambed 提供四个子命令覆盖完整生命周期：

全量回填（resync）功能在初次接入或表结构变更后尤为重要。它利用 Postgres 的 REPEATABLE READ 隔离级别获取一致性快照，避免与实时 CDC 流冲突。对于大表，建议分批执行或调整 work_mem 参数以优化 COPY 性能。

适用场景与工程权衡

Streambed 的定位是轻量级分析卸载，适合以下场景：

1. 中小规模数据仓库：数据量在 TB 级别，查询并发不高，无需 Spark/Flink 等重型基础设施
2. 快速原型验证：团队熟悉 Postgres 生态，希望以最小成本验证湖仓架构
3. 边缘或私有化部署：资源受限环境，无法部署完整的云原生数据栈

然而，当前版本（截至 2026 年 6 月）存在若干限制需要评估：

• 成熟度：项目处于早期阶段（GitHub 11 stars），生产环境使用前需充分测试故障恢复、复制延迟监控等边界情况
• 查询扩展性：嵌入式 DuckDB 受限于单机内存，高并发或超大数据集场景可能需要外接独立的 DuckDB 集群或迁移至 Trino
• Schema 变更：Postgres 的 DDL（如 ALTER TABLE）需要手动处理 Iceberg 的 schema evolution，目前无自动化机制
• CGO 依赖：构建环境需配置 C 编译器，跨平台部署（如 ARM64）需额外验证

与现有方案的对比

相较于 Debezium + Kafka + Spark + Iceberg 的经典组合，Streambed 将链路压缩为单一代码库，组件间网络开销和序列化成本大幅降低。但代价是牺牲了水平扩展能力 —— 当单节点成为瓶颈时，必须引入外部查询引擎或分片策略。

与 Materialize、RisingWave 等流处理数据库相比，Streambed 不提供物化视图或增量计算能力，仅做数据搬运和存储格式转换。它的优势在于与 Iceberg 生态的深度集成，以及 Postgres 协议带来的工具兼容性。

总结

Streambed 展示了一种务实的湖仓一体路径：利用 Postgres 成熟的逻辑复制机制，结合 Iceberg 的开放表格式和 DuckDB 的向量化执行能力，在单一进程中完成从 CDC 捕获到查询服务的完整闭环。对于希望在不引入复杂数据平台的前提下，将分析负载从生产 Postgres 卸载的团队，这是一个值得关注的实验性方案。

实际落地时，建议先在非核心业务表上验证同步延迟、存储成本增长和查询性能，逐步建立监控指标（如复制槽滞后字节数、Parquet 文件大小分布）后再扩大范围。

参考来源

• Streambed GitHub 仓库
• Hacker News 讨论

systems