Streambed: 將 Postgres 資料流向 Apache Iceberg 的簡化方案

對於依賴 PostgreSQL 的組織而言，從營運資料轉向分析洞察的過程通常涉及繁瑣的架構跳躍。傳統上，這需要建立多個讀取副本（read replicas）——這可能會消耗大量資源——或者實施複雜的 ETL（Extract, Transform, Load）管線來將資料移至專用的分析資料倉儲。這些模式往往會引入延遲、營運開銷以及大量客製化組件的增加。

Streambed 的出現為這種摩擦提供了解決方案，旨在最大限度地減少將資料從交易型資料庫移至可查詢分析格式所需的組件。透過利用 Postgres wire protocol 和 Apache Iceberg，Streambed 提供了一條從 Write-Ahead Log (WAL) 到 S3 的更直接路徑。

Streambed 的架構

Streambed 的設計圍繞著架構極簡主義原則。它並非引入沉重的中間件層，而是作為一個邏輯複製訂閱者（logical replication subscriber）運作。這與 Postgres 讀取副本使用的機制相同，允許 Streambed 從 WAL 即時捕捉變化。

一旦捕捉到這些變化，它們就會被直接串流到儲存在 Amazon S3 上的 Apache Iceberg 表格中。為了讓這些資料立即變得有用，Streambed 整合了內嵌的 DuckDB 實例，允許使用者透過 psql 查詢他們的 Iceberg 表格。這創造了一種無縫的體驗，儘管資料儲存在物件儲存中的欄位格式，使用者仍可以使用熟悉的 Postgres 相容工具與其分析資料進行互動。

解決「分析查詢」瓶頸

Streambed 的動機源於高規模環境中的常見痛點。正如作者（曾任 Cloudflare Postgres 團隊技術主管）所指出的，商業智慧（BI）和儀表板團隊經常需要執行長時間運行的分析查詢，而這些查詢若在主生產資料庫上執行，會降低其效能。

歷史上的解決方案包括：

客製化讀取副本： 為特定的分析工作負載建立特定的副本。
ETL 傾印： 定期將資料傾印到分析資料庫中。

Streambed 試圖繞過這些選項，將 S3/Iceberg 層視為主要的分析目的地，有效地將分析工作負載與營運資料庫解耦，而無需傳統的大規模資料倉儲遷移所帶來的開銷。

技術挑戰與考量因素

雖然「低組件」架構的前景很吸引人，但社群已針對實施此模式的人士提出了幾項關鍵考量因素。

ELT 與 ETL 的辯論

其中一個主要的批評點在於「移動資料」與「為使用而準備資料」之間的區別。雖然 Streambed 處理了管線中的「提取（Extract）」和「載入（Load）」部分，但它將轉換（transformation）的負擔轉移到了流程的末端。這是一種 ELT (Extract, Load, Transform) 模式。

"對於任何有興趣將此用於實際分析的人來說，他們必須在某個時間點進行資料轉換。如果一個組織太早認為他們可以使用這樣的解決方案，然後直接進入 duckdb 並開始產出報告，他們將會面臨非常糟糕的體驗。"

對於簡單的報告，這種方法是高效的。然而，對於複雜的商業智慧，使用者仍必須實施一個轉換層來確保資料品質與效能。

CDC 的複雜性

可靠地實施變更資料捕捉（Change Data Capture, CDC）是一項非平凡的工程任務。在不丟失資料或引入顯著延遲的情況下捕捉 WAL 變化，需要對 Postgres 內部機制有深入的理解。Streambed 的實作中使用 Go 語言是一個值得注意的選擇，因為 Go 語言中可靠的 CDC 函式庫相對稀缺，開發者通常需要「手動實作」自己的邏輯來處理 Postgres 複製協定中的特定陷阱。

總結

Streambed 代表了向簡化資料堆疊的一個引人注目的轉變，透過縮短營運資料庫與分析湖倉（lakehouse）之間的距離。透過結合邏輯複製、Apache Iceberg 和 DuckDB，它提供了一條以最小化基礎設施實現即時分析的路徑。然而，與任何 ELT 工具一樣，其成功取決於使用者管理隨後將原始串流資料轉換為具備行動力的洞察的能力。