北京
你有沒有過這樣的困惑：生產數據庫跑得好好的，但分析部門一跑報表，主庫就開始卡頓。加只讀副本成本不低，做數據倉庫又得折騰一圈抽取轉換加載流程。一個剛在“Show HN”亮相的開源工具——Streambed，試圖給出第三種解法：把Postgres表的變化直接流式同步成Iceberg格式落到S3上，同時保留用psql查詢的能力。
Streambed本質上是一套針對Postgres到Iceberg的變更數據捕獲引擎。按照項目文檔的描述，它不會改變現有應用，而是通過邏輯復制訂閱數據庫的預寫日志變更，把解碼后的增、刪、改行緩沖在內存里，定期刷成Parquet文件寫入S3，最后提交Iceberg元數據。這樣一來，任何兼容Iceberg的查詢引擎都能直接分析同一份數據。
和常見的“先抽取再轉換”流程不同，Streambed的設計思路是直接把Postgres與S3之間架一條直通管道。項目首頁用pgbench的基準測試做了對比：同樣的分析查詢，在包含100萬個賬戶、50萬行歷史記錄的數據庫上，左側是Postgres原生執行，右側是Streambed。它想傳遞的信號很明確——沒有傳統意義上的抽取轉換過程，沒有Spark集群，只有Postgres加上對象存儲。
具體到操作層面，Streambed的使用門檻被刻意壓得比較低。啟動本地Postgres和MinIO只需要一條docker compose up -d命令；隨后用Go編譯出streambed二進制文件，再執行streambed sync并指定源數據庫地址、S3桶名、端點、前綴和查詢服務端口，就能在5433端口上啟動同步和查詢服務。之后分析師依然可以用習慣的psql客戶端連接localhost的5433端口，像查詢普通Postgres表一樣查詢Iceberg表。項目還特別說明，所有命令行參數都支持以STREAMBED_前綴的環境變量注入，方便在容器化環境里使用。
從數據流轉路徑來看，內部的鏈路被設計成幾個明確階段：Postgres預寫日志消息先被解碼，再按表聚合并放入緩沖區，到達一定閾值后生成Parquet文件推送到S3，最后由Iceberg提交讓數據可見。對于更新和刪除操作，Streambed采用了寫時復制合并策略，與已有的Parquet數據進行合并處理。在查詢這一側，它內嵌了DuckDB作為查詢服務器，通過Postgres有線協議對外暴露Iceberg表，這也是為什么psql和任何Postgres客戶端都能直接連接的原因。
不過，Streambed對運行環境有明確的前提。項目README里寫到需要Go 1.22以上版本，并且因為依賴go-duckdb和go-sqlite3，必須開啟CGO編譯。代碼目錄結構也一并公開：核心邏輯在internal包下，單元測試可以用常規go test命令執行，集成測試則需要Docker環境，通過scripts目錄下的腳本運行，測試會拉起Postgres的5434端口和MinIO的9002端口，對應docker-compose里定義的測試容器。
把分析負載從主庫遷移到對象存儲上的Iceberg表，這個想法本身并不新。但Streambed試圖用“單條命令同步、psql原生查詢”的封裝把整個過程的復雜度降下來，瞄準的無疑是那些既要保留Postgres使用習慣，又想獲得湖倉靈活性的團隊。至于它在生產級負載下的穩定性、數據延遲的可控程度，目前還只能從項目的集成測試和社區反饋中去尋找線索。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
