Streambed: PostgresデータをApache Icebergへ効率化する
PostgreSQLに依存している組織にとって、運用データから分析的なインサイトへの移行は、しばしば煩雑なアーキテクチャ上の飛躍を伴います。従来、これにはリソースを圧迫する可能性のある複数のリードレプリカを立ち上げるか、データを専用の分析用ウェアハウスに移動するための複雑なETL (Extract, Transform, Load) パイプラインを実装する必要があります。これらのパターンは、しばしばレイテンシ、運用オーバーヘッド、および独自のコンポーネントの乱立を引き起こします。
Streambedは、この摩擦を解消するためのソリューションとして登場し、トランザクションデータベースからクエリ可能な分析形式へデータを移動するために必要なコンポーネントを最小限に抑えることを目指しています。Postgres wire protocolとApache Icebergを活用することで、StreambedはWrite-Ahead Log (WAL) からS3へのより直接的なパスを提供します。
Streambedのアーキテクチャ
Streambedは、アーキテクチャのミニマリズムという原則に基づいて設計されています。重いミドルウェア層を導入するのではなく、論理レプリケーションのサブスクライバーとして動作します。これはPostgresのリードレプリカで使用されているものと同じメカニズムであり、StreambedがWALからリアルタイムで変更をキャプチャすることを可能にします。
キャプチャされた変更は、Amazon S3に保存されているApache Icebergテーブルに直接ストリームされます。このデータを即座に活用できるようにするため、Streambedは組み込みのDuckDBインスタンスを統合しており、ユーザーがpsqlを介してIcebergテーブルにクエリを実行できるようにします。これにより、データがオブジェクトストレージ上のカラムナ形式で存在しているにもかかわらず、ユーザーが使い慣れたPostgres互換のツールを使用して分析データと対話できるシームレスな体験が生まれます。
「分析クエリ」のボトルネックの解決
Streambedの動機は、高スケールな環境における共通のペインポイントに由来します。CloudflareのPostgresチームの元テックリードである著者が指摘するように、BIやダッシュボードチームは、頻繁に長時間実行される分析クエリを実行する必要があり、それが他の方法ではプライマリのプロダクションデータベースのパフォーマンスを低下させてしまうことがあります。
歴史的に、解決策は以下の通りでした：
- 独自のリードレプリカ: 特定の分析ワークロードのために特定のレプリカを作成する。
- ETLダンプ: 定期的にデータを分析用データベースにダンプする。
Streambedは、S3/Icebergレイヤーを主要な分析先として扱うことで、これらのオプションを回避しようと試みています。これにより、フルスケールのデータウェアハウス移行に伴う従来のオーバーヘッドなしに、分析ワークロードを運用データベースから効果的に切り離すことができます。
技術的な課題と検討事項
「コンポーネントの少ない」アーキテクチャは魅力的ですが、コミュニティは、このパターンを実装する者に対していくつかの重要な検討事項を強調しています。
ELT vs. ETL の議論
データの移動と、使用するための準備との区別が、主な批判の一つです。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."
シンプルなレポート作成には、このアプローチは効率的です。しかし、複雑なビジネスインテリジェンスにおいては、ユーザーはデータの品質とパフォーマンスを確保するために、依然として変換レイヤーを実装する必要があります。
CDC の複雑さ
Change Data Capture (CDC) を信頼性高く実装することは、容易なことではありません。データを失ったり、大幅な遅延を導入したりすることなくWALの変更をキャプチャするには、Postgresの内部構造に関する深い理解が必要です。Streambedの実装にGoを使用していることは注目すべき選択です。Goにおける信頼性の高いCDCライブラリは比較的少なく、開発者がPostgresレプリケーションプロトコルの特定の落とし穴を扱うために、独自のロジックを「手作り」する必要があることが多いためです。
Summary
Streambedは、運用データベースと分析用レイクハウスの間の距離を縮めることで、データスタックを簡素化することへの魅力的なシフトを表現しています。論理レプリケーション、Apache Iceberg、およびDuckDBを組み合わせることで、最小限のインフラストラクチャでリアルタイム分析への道を提供します。しかし、あらゆるELTツールと同様に、その成功は、ストリームされた生のデータを、実行可能なインサイトへと変換するユーザーの能力に依存します。