pg_lake - PostgresでIcebergとデータレイクへのアクセスをサポートする拡張

 (github.com/Snowflake-Labs)
3 ポイント 投稿者 GN⁺ 2025-11-05 | 1件のコメント | WhatsAppで共有
  • pg_lakeは、Postgres を基盤として Iceberg テーブルとデータレイクファイルを直接統合し、トランザクションと高速クエリをサポートする拡張
  • S3 などの オブジェクトストレージ上の Parquet、CSV、JSON、Iceberg ファイルを直接参照・取り込み・エクスポート可能
  • 内部的に DuckDB クエリエンジンを活用し、Postgres 環境内で高速な実行性能を確保
  • Iceberg テーブルの作成、外部ファイルの自動スキーマ推論、COPY コマンドによる S3 入出力など、データレイクハウス機能を単一の SQL インターフェースで提供
  • Snowflake が 2025 年に Crunchy Data を買収した後、オープンソースとして公開され、Postgres エコシステムにおけるデータレイク統合を拡張する基盤

pg_lake 概要

  • pg_lakeは、Iceberg およびデータレイクファイルを Postgres に統合する拡張機能で、Postgres を単独の レイクハウスシステムとして活用可能
    • Iceberg テーブルに対するトランザクション保証と高速クエリをサポート
    • S3 などのオブジェクトストレージ上の生データファイルに直接アクセス可能
  • 主な機能
    • Iceberg テーブルの作成・変更、および他のエンジンからのクエリに対応
    • Parquet、CSV、JSON、Iceberg 形式のデータファイルの参照と取り込み
    • COPY コマンドでクエリ結果を Parquet、CSV、JSON 形式としてオブジェクトストレージにエクスポート
    • GDAL がサポートする GeoJSON、Shapefile などの 地理空間データ形式の読み込み
    • 半構造化データ向けの 組み込み map 型を提供
    • heap、Iceberg、外部ファイルを 単一の SQL クエリで結合可能
    • 外部データソースから カラムと型を自動推論
    • DuckDB エンジンによる高速実行

インストールと設定

  • インストール方法
    • Docker を使った簡単な実行
    • ソースビルドによる手動インストール、または開発環境の構築
  • 拡張作成の例 
    CREATE EXTENSION pg_lake CASCADE;
    • 関連拡張: pg_lake_table, pg_lake_engine, pg_extension_base, pg_lake_iceberg, pg_lake_copy
  • pgduck_server
    • Postgres ワイヤープロトコルを実装した独立プロセスで、内部的に DuckDB を使用
    • デフォルトポート 5332 で動作し、psql で直接接続可能
    • 主な設定
      • --memory_limit: メモリ制限（デフォルトはシステムメモリの 80%）
      • --init_file_path: 起動時に実行する SQL ファイルを指定
      • --cache_dir: リモートファイルのキャッシュディレクトリを指定
  • S3 接続設定
    • DuckDB の secrets manager を使って AWS/GCP 資格情報を自動認識
    • Iceberg テーブルの保存先指定例 
      SET pg_lake_iceberg.default_location_prefix TO 's3://testbucketpglake';

使用例

  • Iceberg テーブルの作成 
    CREATE TABLE iceberg_test USING iceberg AS   
SELECT i as key, 'val_'|| i as val FROM generate_series(0,99)i;
    • 作成後、SELECT count(*) FROM iceberg_test; の結果は 100
    • Iceberg メタデータの場所を確認可能
  • S3 への COPY 入出力 
    COPY (SELECT * FROM iceberg_test) TO 's3://.../iceberg_test.parquet';  
COPY iceberg_test FROM 's3://.../iceberg_test.parquet';
    • Parquet、CSV、JSON 形式をサポート
  • S3 ファイルを外部テーブルとして作成 
    CREATE FOREIGN TABLE parquet_table()   
SERVER pg_lake   
OPTIONS (path 's3://.../*.parquet');
    • カラムを自動推論し、クエリ可能（SELECT count(*) FROM parquet_table; → 100）

アーキテクチャ

  • 構成要素
    • PostgreSQL + pg_lake 拡張
    • pgduck_server（DuckDB の実行と Postgres プロトコルの実装）
  • 動作方式
    • ユーザーは Postgres に接続して SQL を実行
    • クエリの一部は DuckDB を通じて並列・カラム指向方式で実行
    • DuckDB を Postgres プロセス内に埋め込まないことで、スレッド・メモリ安全性の問題を回避
    • 標準的な Postgres クライアントを通じて DuckDB エンジンへ直接アクセス可能

構成要素の詳細一覧

  • pg_lake_iceberg: Iceberg 仕様の実装
  • pg_lake_table: オブジェクトストレージファイル向け FDW 実装
  • pg_lake_copy: データレイクへの COPY 入出力をサポート
  • pg_lake_engine: 共通モジュール
  • pg_extension_base: 他の拡張の基盤コンポーネント
  • pg_extension_updater: 拡張自動更新機能
  • pg_lake_benchmark: レイクテーブルのベンチマークを実行
  • pg_map: 汎用 map 型ジェネレーター
  • pgduck_server: DuckDB をロードし、Postgres プロトコルで公開するサーバー
  • duckdb_pglake: DuckDB に Postgres 互換関数を追加

開発と公開の経緯

  • 2024 年初頭、Crunchy Dataで Iceberg を Postgres に導入するための開発を開始
  • 当初は DuckDB 統合と Crunchy Bridge 顧客向け機能の提供からスタート
  • その後、Iceberg v2 プロトコルとトランザクションサポートを実装
  • 2024 年 11 月、Crunchy Data Warehouseとして再リリース
  • 2025 年 6 月、Snowflake が Crunchy Data を買収し、2025 年 11 月に pg_lake をオープンソース公開
    • 初期バージョンは 3.0（それ以前の 2 世代を含む）
    • 既存の Crunchy Data Warehouse 利用者には自動アップグレード経路を提供

ライセンスと依存関係

  • Apache 2.0 ライセンス
  • Apache Avro および DuckDB プロジェクトに依存
    • ビルド時に Avro および DuckDB 拡張へパッチを適用

関連記事

1件のコメント

 
GN⁺ 2025-11-05
Hacker Newsのコメント
  • 単に Ducklake を使えばいいのでは、と思う
    そうすれば 複雑さを減らせる。必要なのは DuckDB と PostgreSQL（pg_duckdb）だけ
    参考までに、Prof. Hannes Mühleisen による発表動画 DuckLake - The SQL-Powered Lakehouse Format for the Rest of Us もある
    • DuckLake はかなり素晴らしいプロジェクト。私たちのチームも DuckDB が好き。実際、pg_lake が実現できたのも DuckDB のおかげ
      DuckLake は Iceberg ベースの pg_lake にできないことができるし、逆に Postgres は DuckDB にできないことができる。たとえば、1 秒あたり 10 万件を超える単一行挿入を処理できる
      トランザクション処理はただでは手に入らない。エンジンをカタログの中に入れる代わりに、カタログをエンジンの中に入れれば、分析用テーブルと運用用テーブルの間でトランザクションが可能になる
      Postgres は永続性（persistence）と 継続的処理 の面でも自然。pg_cron と PL/pgSQL を使ってオーケストレーションを構築できる
      また、Iceberg は複数のクエリエンジンとの相互運用性にも強みがある
    • 結局は 設計上の意思決定 の問題。この件に関する議論は このスレッド で見られる
    • 私も Ducklake を本当に気に入りたかったが、実際に使ってみると メンテナンス上の問題 があった。特に pg catalog 関連で、Ducklake が自動生成したファイルに対して HTTP 400 エラーを返すことがあった
      それが自分のデータ書き込みパターン（Polars DataFrame から Ducklake テーブルへの挿入）のせいなのか、パーティションテーブルの構造のせいなのかははっきりしない
      開発・テスト環境では問題なかったが、チーム全体で使うには難しさがあった。そこで結局、Hive パーティション化された Parquet ファイルと DuckDB ビューの組み合わせに戻った
      あとで issue に例を上げるつもりだが、今は他の作業で時間が足りない
  • これは本当に 大きな変化 だ
    以前は Postgres 市場には「オープンソースの Snowflake」がないと言われていた
    Crunchy の Postgres 拡張は、現時点の市場で最も先を行くソリューションだ。Snowflake と Crunchy のチームがこれをオープンソースとして公開したことを祝福したい
    • 正直に言えば、単に Snowflake にお金を払って、その優れた DB と エコシステム を活用する方がよいと思う。インフラが顧客価値の中核でないなら、その部分は任せて、素晴らしいものを作ることに集中すべきだ
  • 私は データレイク と SQL ライクなクエリ言語が好き。「すべてはファイルである」という哲学の進化形のように感じる
    Linux ではファイルシステムを通じてシステム設定を読み書きできる（cat /sys/..., echo ... > /sys/...）
    FUSE を使えば、ユーザー空間でファイルシステムドライバを直接実装できる。たとえば SSH や Google Drive をマウントして、cp コマンドでコピーできる
    しかしファイルシステムは階層型データにしか向いていない。現実世界のデータの大半は リレーショナル構造 だ
    データレイクは SQL というエレガントな抽象化を通じて、異なるデータソースを 1 つのリレーショナルデータベースのように扱えるようにする
    結局、多くのアプリケーションは CRUD 中心なので、このアプローチの方がはるかに効率的だ
  • あなたはデータレイクをどう使うのか。私にとっては単なるストレージではなく、予測不能な分析作業 のための空間だ
    こういう場合、Postgres には限界がある。より多くの CPU と RAM が必要になり、最終的には 分散エンジン が必要になる
    • データレイクの核心は コンピュートとストレージの分離 にある。Postgres はコンピュート層ではなくアクセス層だ
      コンピュートは Postgres に「これらのキーの現在のデータは？」あるいは「2 週間前のデータは？」と問い合わせ、実際の分析クエリは Parquet ファイルに対して直接実行する
  • Snowflake が Crunchy Data を買収したとき、こうした マネージド版 が提供されることを期待していた
    ローカルの Docker で動かせるのはよいが、AWS 上で Snowflake アカウントに統合請求される形で運用できるとうれしい
  • 今は本当に PostgreSQL の黄金時代 だと感じる
  • 私はデータエンジニアではないが、その周辺分野で働いている。これがどんな問題を解決するのか、わかりやすく説明 できる人がいないか気になる
    • たとえば、あるサービスが S3 に Parquet ファイルとしてログデータをためているとする。このデータを Postgres からそのままクエリしたいとき、pg_lake が役立つ
      Parquet データを Postgres に取り込んでクエリでき、既存テーブルと 結合 することも可能
  • 2 つ質問がある
    (1) Iceberg の代わりに Ducklake 仕様を使う互換計画はあるのか？ Ducklake はカタログをファイルではなく SQL テーブルで管理するので、同時書き込み やスナップショット管理がより簡単になる
    (2) pg_duckdb が将来的に同じ機能を担う可能性はあるのか？
    • (1) 検討はしたが、現時点では計画していない。Ducklake をそのまま使うより、Postgres 内部で直接実装して トランザクション境界 を維持したい
      ただし、インラインデータ処理などの複雑さがある。そこを解決できれば、高いトランザクション性能が得られる
      (2) pg_duckdb は Ducklake の実装を再利用しやすいが、リソース管理や安定性の面では、その構造はあまり適していないと考えている
  • S3 Table Buckets、Cloudflare R2 Data Catalog、そして今回のプロジェクトまで見ると、Iceberg が勝ちつつある 雰囲気だ
  • Postgres Wire 互換 DB にデータを簡単にロードしたいなら、sling-cli を勧める
    CLI、YAML、Python で ETL ジョブ を実行できる