Streambed: Streamlining Postgres Data to Apache Iceberg
对于依赖 PostgreSQL 的组织而言，从业务数据向分析洞察的过渡通常涉及繁琐的架构跃迁。传统上，这需要要么启动多个只读副本（这可能会消耗大量资源），要么实现复杂的 ETL (Extract, Transform, Load) 流水线，将数据迁移到专门的分析仓库中。这些模式往往会引入延迟、运维开销以及大量定制化组件的激增。
Streambed 的出现旨在解决这一摩擦，目标是最大限度地减少将数据从事务数据库迁移到可查询分析格式所需的组件。通过利用 Postgres wire protocol 和 Apache Iceberg，Streambed 提供了一条从 Write-Ahead Log (WAL) 到 S3 的更直接的路径。
The Architecture of Streambed
Streambed 的设计围绕着架构极简主义原则。它并不引入沉重的中间件层，而是作为一个逻辑复制订阅者（logical replication subscriber）运行。这与 Postgres 只读副本使用的机制相同，允许 Streambed 从 WAL 中实时捕获变更。
一旦捕获这些变更，它们就会被直接流式传输到存储在 Amazon S3 上的 Apache Iceberg 表中。为了使这些数据立即变得可用，Streambed 集成了嵌入式的 DuckDB 实例，允许用户通过 psql 查询其 Iceberg 表。这创造了一种无缝体验，尽管数据以列式格式存储在对象存储中，用户仍可以使用熟悉的 Postgres 兼容工具与分析数据进行交互。
Solving the "Analytical Query" Bottleneck
Streambed 的动力源于高规模环境中的一个常见痛点。正如作者（曾任 Cloudflare Postgres 团队的技术负责人）所指出的，BI 和仪表板团队经常需要运行耗时较长的分析查询，而这些查询否则会降低主生产数据库的性能。
从历史上看，解决方案包括：
- Bespoke Read Replicas: 为特定的分析工作负载创建特定的副本。
- ETL Dumps: 定期将数据转储到分析数据库中。
Streambed 试图通过将 S3/Iceberg 层视为主要的分析目的地，有效地将分析工作负载与业务数据库解耦，而无需承担传统的大规模数据仓库迁移的开销。
Technical Challenges and Considerations
虽然“低组件”架构的前景很吸引人，但社区已为实施此模式的人员指出了几个关键的考量因素。
The ELT vs. ETL Debate
其中一个主要的批评点在于数据迁移与数据准备之间的区别。虽然 Streambed 处理了流水线的“Extract”和“Load”部分，但它将转换（transformation）的负担转移到了流程的末端。这是一种 ELT (Extract, Load, Transform) 模式。
"Anyone who’s interested into using this for realistic analytics they will have to transform the data at some point. If an org is early enough to think that they can use a solution like this and just get in duckdb and start spitting out reports, they will be up for a really bad experience."
对于简单的报告，这种方法是高效的。然而，对于复杂的商业智能，用户仍必须实现一个转换层，以确保数据质量和性能。
The Complexity of CDC
可靠地实现变更数据捕获 (CDC) 是一项非同寻常的工程任务。在不丢失数据或引入显著延迟的情况下捕获 WAL 变更，需要对 Postgres 内部机制有深入的理解。Streambed 使用 Go 语言进行实现是一个值得注意的选择，因为 Go 语言中可靠的 CDC 库相对稀缺，通常需要开发者“手写”自己的逻辑来处理 Postgres 复制协议中的特定陷阱。
Summary
Streambed 代表了通过缩短业务数据库与分析 Lakehouse 之间的距离，从而简化数据栈的一种引人注目的转变。通过结合逻辑复制、Apache Iceberg 和 DuckDB，它提供了一条以最小基础设施实现实时分析的路径。然而，正如任何 ELT 工具一样，其成功取决于用户管理后续将原始流式数据转换为可操作洞察的能力。