Pg_lake - Tiện ích mở rộng hỗ trợ truy cập Iceberg và data lake từ Postgres

 (github.com/Snowflake-Labs)
3 điểm bởi GN⁺ 2025-11-05 | 1 bình luận | Chia sẻ qua WhatsApp
  • pg_lake là một tiện ích mở rộng dựa trên Postgres, tích hợp trực tiếp bảng Iceberg và các tệp data lake để hỗ trợ giao dịch và truy vấn tốc độ cao
  • Có thể truy vấn trực tiếp, nhập và xuất các tệp Parquet, CSV, JSON, Iceberg trên object storage như S3
  • Tận dụng bộ máy truy vấn DuckDB ở bên trong để đạt hiệu năng thực thi nhanh trong môi trường Postgres
  • Cung cấp các tính năng lakehouse như tạo bảng Iceberg, tự động suy luận schema cho tệp bên ngoài, I/O với S3 qua lệnh COPY bằng một giao diện SQL duy nhất
  • Sau khi Snowflake mua lại Crunchy Data vào năm 2025, dự án được công bố dưới dạng mã nguồn mở, tạo nền tảng mở rộng tích hợp data lake trong hệ sinh thái Postgres

Tổng quan về pg_lake

  • pg_lake là tiện ích mở rộng tích hợp Iceberg và các tệp data lake vào Postgres, cho phép sử dụng Postgres như một hệ thống lakehouse độc lập
    • Đảm bảo giao dịch và hỗ trợ truy vấn nhanh cho các bảng Iceberg
    • Có thể truy cập trực tiếp các tệp dữ liệu thô trên object storage như S3
  • Các tính năng chính
    • Tạo và chỉnh sửa bảng Iceberg, đồng thời cho phép các engine khác truy vấn
    • Truy vấn và nhập các tệp dữ liệu ở định dạng Parquet, CSV, JSON, Iceberg
    • Xuất kết quả truy vấn lên object storage ở định dạng Parquet, CSV, JSON bằng lệnh COPY
    • Đọc các định dạng dữ liệu không gian địa lý như GeoJSON, Shapefile do GDAL hỗ trợ
    • Cung cấp kiểu map tích hợp sẵn cho dữ liệu bán cấu trúc
    • Có thể kết hợp heap, Iceberg và tệp ngoài trong một truy vấn SQL duy nhất
    • Tự động suy luận cột và kiểu dữ liệu từ nguồn dữ liệu bên ngoài
    • Thực thi tốc độ cao nhờ engine DuckDB

Cài đặt và cấu hình

  • Cách cài đặt
    • Chạy nhanh bằng Docker
    • Cài đặt thủ công hoặc dựng môi trường phát triển bằng biên dịch từ mã nguồn
  • Ví dụ tạo extension 
    CREATE EXTENSION pg_lake CASCADE;
    • Các extension liên quan: pg_lake_table, pg_lake_engine, pg_extension_base, pg_lake_iceberg, pg_lake_copy
  • pgduck_server
    • Là tiến trình độc lập triển khai giao thức dây Postgres và sử dụng DuckDB ở bên trong
    • Chạy trên cổng mặc định 5332 và có thể kết nối trực tiếp bằng psql
    • Cấu hình chính
      • --memory_limit: giới hạn bộ nhớ (mặc định là 80% bộ nhớ hệ thống)
      • --init_file_path: chỉ định tệp SQL sẽ chạy khi khởi động
      • --cache_dir: chỉ định thư mục cache cho tệp từ xa
  • Cấu hình kết nối S3
    • Dùng secrets manager của DuckDB để tự động nhận diện thông tin xác thực AWS/GCP
    • Ví dụ chỉ định vị trí lưu bảng Iceberg 
      SET pg_lake_iceberg.default_location_prefix TO 's3://testbucketpglake';

Ví dụ sử dụng

  • Tạo bảng Iceberg 
    CREATE TABLE iceberg_test USING iceberg AS   
SELECT i as key, 'val_'|| i as val FROM generate_series(0,99)i;
    • Sau khi tạo, SELECT count(*) FROM iceberg_test; cho kết quả 100
    • Có thể kiểm tra vị trí metadata của Iceberg
  • COPY vào/ra S3 
    COPY (SELECT * FROM iceberg_test) TO 's3://.../iceberg_test.parquet';  
COPY iceberg_test FROM 's3://.../iceberg_test.parquet';
    • Hỗ trợ các định dạng Parquet, CSV, JSON
  • Tạo bảng ngoài từ tệp trên S3 
    CREATE FOREIGN TABLE parquet_table()   
SERVER pg_lake   
OPTIONS (path 's3://.../*.parquet');
    • Tự động suy luận cột và có thể truy vấn (SELECT count(*) FROM parquet_table; → 100)

Kiến trúc

  • Các thành phần
    • PostgreSQL + extension pg_lake
    • pgduck_server (thực thi DuckDB và triển khai giao thức Postgres)
  • Cách hoạt động
    • Người dùng kết nối vào Postgres và chạy SQL
    • Một phần truy vấn được thực thi qua DuckDB theo hướng song song và dạng cột
    • Không nhúng DuckDB trực tiếp vào bên trong tiến trình Postgres nên tránh được các vấn đề về an toàn luồng và bộ nhớ
    • Có thể truy cập trực tiếp engine DuckDB thông qua client Postgres tiêu chuẩn

Danh sách chi tiết các thành phần

  • pg_lake_iceberg: triển khai đặc tả Iceberg
  • pg_lake_table: triển khai FDW cho các tệp trên object storage
  • pg_lake_copy: hỗ trợ COPY vào/ra data lake
  • pg_lake_engine: mô-đun dùng chung
  • pg_extension_base: thành phần nền tảng cho các extension khác
  • pg_extension_updater: chức năng tự động cập nhật extension
  • pg_lake_benchmark: chạy benchmark cho lake table
  • pg_map: bộ tạo kiểu map tổng quát
  • pgduck_server: máy chủ nạp DuckDB và phơi bày qua giao thức Postgres
  • duckdb_pglake: bổ sung các hàm tương thích Postgres cho DuckDB

Lịch sử phát triển và công bố

  • Đầu năm 2024, Crunchy Data bắt đầu phát triển để đưa Iceberg vào Postgres
  • Ban đầu tích hợp DuckDB và cung cấp tính năng cho khách hàng của Crunchy Bridge
  • Sau đó triển khai giao thức Iceberg v2 và hỗ trợ giao dịch
  • Tháng 11 năm 2024, tái ra mắt dưới tên Crunchy Data Warehouse
  • Tháng 6 năm 2025, Snowflake mua lại Crunchy Data, và đến tháng 11 năm 2025 pg_lake được công bố mã nguồn mở
    • Phiên bản đầu tiên là 3.0 (bao gồm hai thế hệ trước đó)
    • Người dùng Crunchy Data Warehouse hiện tại có lộ trình nâng cấp tự động

Giấy phép và phụ thuộc

  • Giấy phép Apache 2.0
  • Phụ thuộc vào các dự án Apache Avro và DuckDB
    • Áp dụng bản vá cho extension Avro và DuckDB trong quá trình build

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-11-05
Ý kiến Hacker News
  • Tôi tự hỏi liệu có lý do gì để không dùng luôn Ducklake hay không
    Làm vậy có thể giảm độ phức tạp. Chỉ cần DuckDB và PostgreSQL (pg_duckdb) là đủ
    Nhân tiện, cũng có video bài trình bày của GS. Hannes Mühleisen: DuckLake - The SQL-Powered Lakehouse Format for the Rest of Us
    • DuckLake là một dự án khá tuyệt. Đội của chúng tôi cũng thích DuckDB. Thực ra chính nhờ DuckDB mà pg_lake mới khả thi
      DuckLake có thể làm những việc dựa trên Iceberg mà pg_lake không làm được, và ngược lại Postgres cũng làm được những việc DuckDB không làm được. Ví dụ, nó có thể xử lý hơn 100 nghìn lượt chèn từng dòng mỗi giây
      Xử lý giao dịch không phải miễn phí. Thay vì đặt engine vào trong catalog, nếu đặt catalog vào trong engine thì sẽ có thể thực hiện giao dịch giữa các bảng phân tích và bảng vận hành
      Postgres cũng tự nhiên hơn về mặt tính bền vững và xử lý liên tục. Có thể xây dựng orchestration bằng pg_cron và PL/pgSQL
      Ngoài ra, Iceberg còn có ưu thế về khả năng tương tác với nhiều query engine khác nhau
    • Rốt cuộc đây là vấn đề của quyết định thiết kế. Có thể xem thảo luận liên quan ở chuỗi này
    • Tôi cũng đã rất cố để thực sự thích Ducklake, nhưng khi dùng thực tế thì gặp vấn đề bảo trì. Đặc biệt, có lúc Ducklake ném lỗi HTTP 400 đối với các file do chính nó tạo ra liên quan đến pg catalog
      Tôi không chắc đó là do kiểu ghi dữ liệu của mình (chèn từ Polars DataFrame vào bảng Ducklake), hay do cấu trúc bảng phân vùng
      Trong môi trường dev/test thì ổn, nhưng với cả nhóm thì có khó khăn. Vì vậy cuối cùng tôi quay lại dùng kết hợp file Parquet phân vùng theo Hive và view DuckDB
      Sau này tôi định đăng ví dụ thành issue, nhưng hiện giờ đang thiếu thời gian vì bận việc khác
  • Đây thực sự là một thay đổi lớn
    Trước đây người ta thường nói rằng thị trường Postgres không có một “Snowflake mã nguồn mở”
    Extension Postgres của Crunchy hiện là giải pháp đi trước nhất trên thị trường. Xin chúc mừng Snowflake và đội Crunchy vì đã phát hành mã nguồn mở
    • Nói thật thì tôi nghĩ cứ trả tiền cho Snowflake và tận dụng DB tuyệt vời cùng hệ sinh thái của họ sẽ tốt hơn. Nếu hạ tầng không phải phần cốt lõi tạo ra giá trị cho khách hàng, thì nên giao phần đó đi và tập trung xây dựng thứ gì đó hay ho
  • Tôi thích data lake và các ngôn ngữ truy vấn kiểu SQL. Nó giống như một phiên bản tiến hóa của triết lý “mọi thứ đều là file”
    Trên Linux, có thể đọc và ghi cấu hình hệ thống thông qua file system (cat /sys/..., echo ... > /sys/...)
    Với FUSE, có thể tự triển khai file system driver trong user space. Ví dụ, có thể mount SSH hoặc Google Drive rồi sao chép bằng lệnh cp
    Nhưng file system chỉ phù hợp với dữ liệu có cấu trúc phân cấp. Dữ liệu trong thế giới thực phần lớn có cấu trúc quan hệ
    Data lake cho phép xử lý nhiều nguồn dữ liệu khác nhau như một cơ sở dữ liệu quan hệ duy nhất thông qua sự trừu tượng thanh lịch là SQL
    Cuối cùng, vì nhiều ứng dụng xoay quanh CRUD, cách tiếp cận này hiệu quả hơn nhiều
  • Bạn dùng data lake như thế nào? Với tôi, đó không chỉ là kho lưu trữ đơn thuần mà là không gian cho các tác vụ phân tích không thể dự đoán trước
    Trong những trường hợp như vậy, Postgres có giới hạn. Cần nhiều CPU và RAM hơn, và cuối cùng sẽ cần đến engine phân tán
    • Cốt lõi của data lake là tách biệt compute và storage. Postgres không phải lớp compute mà là lớp truy cập
      Compute sẽ hỏi Postgres kiểu như “dữ liệu hiện tại của các khóa này là gì?” hoặc “dữ liệu của 2 tuần trước là gì?”, còn các truy vấn phân tích thực tế thì thực hiện trực tiếp trên file Parquet
  • Khi Snowflake mua lại Crunchy Data, tôi đã kỳ vọng họ sẽ cung cấp một phiên bản managed như thế này
    Chạy được bằng Docker cục bộ thì tốt, nhưng sẽ hay hơn nếu có thể vận hành trên AWS với hình thức gộp hóa đơn vào tài khoản Snowflake
  • Bây giờ thực sự có cảm giác đây là thời kỳ hoàng kim của PostgreSQL
  • Tôi không phải data engineer nhưng có làm việc ở lĩnh vực liên quan. Tôi tự hỏi liệu có ai có thể giải thích đơn giản vấn đề mà cái này giải quyết là gì không
    • Ví dụ, giả sử một dịch vụ tích lũy dữ liệu log dưới dạng file Parquet trên S3. Khi muốn truy vấn trực tiếp dữ liệu này từ Postgres thì pg_lake sẽ hữu ích
      Có thể nạp dữ liệu Parquet vào Postgres để truy vấn, đồng thời join với các bảng hiện có
  • Tôi có hai câu hỏi
    (1) Có kế hoạch tương thích để dùng đặc tả Ducklake thay vì Iceberg không? Ducklake quản lý catalog bằng bảng SQL thay vì file, nên ghi đồng thời hay quản lý snapshot đơn giản hơn
    (2) Liệu pg_duckdb theo thời gian có khả năng cung cấp cùng chức năng đó không?
    • (1) Chúng tôi đã cân nhắc, nhưng hiện chưa có kế hoạch. Thay vì dùng nguyên xi Ducklake, chúng tôi muốn triển khai trực tiếp bên trong Postgres để giữ ranh giới giao dịch
      Tuy vậy vẫn có độ phức tạp, như xử lý dữ liệu inline. Nếu giải quyết được phần này thì có thể đạt hiệu năng giao dịch cao
      (2) pg_duckdb có thể dễ tái sử dụng phần triển khai Ducklake hơn, nhưng về quản lý tài nguyên hay độ ổn định thì chúng tôi thấy cấu trúc đó kém phù hợp hơn
  • Nhìn vào S3 Table Buckets, Cloudflare R2 Data Catalog, và cả dự án này nữa thì có vẻ như Iceberg đang thắng thế
  • Nếu muốn nạp dữ liệu dễ dàng vào DB tương thích Postgres Wire, tôi khuyên dùng sling-cli
    Có thể chạy các tác vụ ETL bằng CLI, YAML và Python