Pg_lake - ส่วนขยายที่รองรับการเข้าถึง Iceberg และดาต้าเลกจาก Postgres

 (github.com/Snowflake-Labs)
3 คะแนน โดย GN⁺ 2025-11-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • pg_lake เป็นส่วนขยายที่ผสาน ตาราง Iceberg และไฟล์ดาต้าเลกเข้ากับ Postgres ได้โดยตรง เพื่อรองรับทรานแซกชันและการคิวรีความเร็วสูง
  • สามารถ คิวรี นำเข้า และส่งออกไฟล์ Parquet, CSV, JSON และ Iceberg บน object storage เช่น S3 ได้โดยตรง
  • ใช้ DuckDB query engine ภายในเพื่อให้ได้ประสิทธิภาพการรันที่รวดเร็วในสภาพแวดล้อม Postgres
  • มอบ ความสามารถแบบ data lakehouse ผ่าน SQL interface เดียว เช่น การสร้างตาราง Iceberg, การอนุมานสคีมาของไฟล์ภายนอกอัตโนมัติ, และการรับส่งข้อมูลกับ S3 ผ่านคำสั่ง COPY
  • หลังจาก Snowflake เข้าซื้อ Crunchy Data ในปี 2025 ก็ได้ เปิดซอร์สโค้ด เพื่อเป็นฐานในการขยายการผสานดาต้าเลกใน ecosystem ของ Postgres

ภาพรวมของ pg_lake

  • pg_lake เป็นส่วนขยายที่ผสาน Iceberg และไฟล์ดาต้าเลกเข้ากับ Postgres ทำให้สามารถใช้ Postgres เป็น ระบบเลกเฮาส์ แบบสแตนด์อโลนได้
    • รับประกันทรานแซกชันสำหรับตาราง Iceberg และรองรับการคิวรีที่รวดเร็ว
    • เข้าถึงไฟล์ข้อมูลดิบบน object storage เช่น S3 ได้โดยตรง
  • ความสามารถหลัก
    • สร้างและแก้ไขตาราง Iceberg และให้เอนจินอื่นคิวรีได้
    • คิวรีและนำเข้าข้อมูลไฟล์ในรูปแบบ Parquet, CSV, JSON และ Iceberg
    • ส่งออกผลลัพธ์ของคิวรีไปยัง object storage ในรูปแบบ Parquet, CSV, JSON ด้วยคำสั่ง COPY
    • อ่าน รูปแบบข้อมูลเชิงภูมิศาสตร์ เช่น GeoJSON และ Shapefile ที่ GDAL รองรับ
    • มี map type ในตัว สำหรับข้อมูลกึ่งโครงสร้าง
    • สามารถ รวม heap, Iceberg และไฟล์ภายนอกไว้ใน SQL query เดียวกัน
    • อนุมานคอลัมน์และชนิดข้อมูลอัตโนมัติ จากแหล่งข้อมูลภายนอก
    • ประมวลผลความเร็วสูงด้วย DuckDB engine

การติดตั้งและการตั้งค่า

  • วิธีติดตั้ง
    • รันได้ง่ายด้วย Docker
    • ติดตั้งด้วยตนเองหรือจัดเตรียมสภาพแวดล้อมพัฒนาด้วย การคอมไพล์จากซอร์ส
  • ตัวอย่างการสร้างส่วนขยาย 
    CREATE EXTENSION pg_lake CASCADE;
    • ส่วนขยายที่เกี่ยวข้อง: pg_lake_table, pg_lake_engine, pg_extension_base, pg_lake_iceberg, pg_lake_copy
  • pgduck_server
    • เป็นโปรเซสแยกที่ implement Postgres wire protocol และใช้ DuckDB ภายใน
    • ทำงานบนพอร์ตเริ่มต้น 5332 และเชื่อมต่อได้โดยตรงด้วย psql
    • การตั้งค่าหลัก
      • --memory_limit: จำกัดหน่วยความจำ (ค่าเริ่มต้น 80% ของหน่วยความจำระบบ)
      • --init_file_path: ระบุไฟล์ SQL ที่จะรันตอนเริ่มต้น
      • --cache_dir: ระบุไดเรกทอรีแคชของไฟล์ระยะไกล
  • การตั้งค่าการเชื่อมต่อ S3
    • ใช้ secrets manager ของ DuckDB เพื่อรู้จำข้อมูลรับรอง 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
    • สามารถตรวจสอบตำแหน่ง metadata ของ Iceberg ได้
  • COPY รับส่งข้อมูลกับ S3 
    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 และ implement โปรโตคอล Postgres)
  • วิธีการทำงาน
    • ผู้ใช้เชื่อมต่อกับ Postgres เพื่อรัน SQL
    • บางส่วนของคิวรีจะถูกรันผ่าน DuckDB แบบขนานและเชิงคอลัมน์
    • ไม่ฝัง DuckDB ไว้ภายในโปรเซสของ Postgres จึง หลีกเลี่ยงปัญหาด้าน thread และ memory safety
    • เข้าถึง DuckDB engine ได้โดยตรงผ่านไคลเอนต์ Postgres มาตรฐาน

รายการองค์ประกอบโดยละเอียด

  • pg_lake_iceberg: implement สเปก Iceberg
  • pg_lake_table: implement FDW สำหรับไฟล์บน object storage
  • pg_lake_copy: รองรับ COPY รับส่งข้อมูลกับดาต้าเลก
  • pg_lake_engine: โมดูลส่วนกลาง
  • pg_extension_base: องค์ประกอบพื้นฐานสำหรับส่วนขยายอื่น
  • pg_extension_updater: ความสามารถอัปเดตส่วนขยายอัตโนมัติ
  • pg_lake_benchmark: ใช้รันเบนช์มาร์กของตารางเลก
  • pg_map: ตัวสร้าง map type แบบทั่วไป
  • pgduck_server: เซิร์ฟเวอร์ที่โหลด DuckDB และเปิดใช้งานผ่านโปรโตคอล Postgres
  • duckdb_pglake: เพิ่มฟังก์ชันที่เข้ากันได้กับ Postgres ให้ DuckDB

ประวัติการพัฒนาและการเปิดเผย

  • เริ่มพัฒนาในต้นปี 2024 ที่ Crunchy Data เพื่อนำ Iceberg มาใช้กับ Postgres
  • ช่วงแรกมุ่งไปที่การผสาน DuckDB และการให้ความสามารถแก่ลูกค้า Crunchy Bridge
  • ต่อมาได้ implement โปรโตคอล Iceberg v2 และรองรับทรานแซกชัน
  • เดือนพฤศจิกายน 2024 เปิดตัวอีกครั้งในชื่อ Crunchy Data Warehouse
  • เดือนมิถุนายน 2025 Snowflake เข้าซื้อ Crunchy Data และเดือนพฤศจิกายน 2025 เปิดซอร์สโค้ด pg_lake
    • เวอร์ชันเริ่มต้นคือ 3.0 (รวมสองเจเนอเรชันก่อนหน้า)
    • ผู้ใช้ 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 ทำบางอย่างที่ pg_lake ซึ่งอิงกับ Iceberg ทำไม่ได้ และในทางกลับกัน Postgres ก็ทำบางอย่างที่ DuckDB ทำไม่ได้ เช่นรองรับการแทรกข้อมูลทีละแถวได้มากกว่า 100,000 รายการต่อวินาที
      การประมวลผลธุรกรรม ไม่ได้มาฟรี ๆ ถ้าแทนที่จะเอาเอนจินไปไว้ในแค็ตตาล็อก แล้วเอาแค็ตตาล็อกมาไว้ในเอนจิน ก็จะสามารถทำธุรกรรมระหว่างตารางสำหรับงานวิเคราะห์กับตารางสำหรับงานปฏิบัติการได้
      Postgres ยังดูเป็นธรรมชาติกว่าในแง่ของ persistence และ การประมวลผลแบบต่อเนื่อง ด้วย สามารถจัดทำ orchestration ได้ด้วย pg_cron และ PL/pgSQL
      อีกอย่าง Iceberg ก็มีจุดแข็งด้านการทำงานร่วมกับหลาย query engine
    • สุดท้ายแล้วมันเป็นเรื่องของ การตัดสินใจด้านการออกแบบ ดูการถกเถียงที่เกี่ยวข้องได้ในเธรดนี้
    • ฉันเองก็พยายามจะชอบ Ducklake ให้มากจริง ๆ แต่พอใช้จริงกลับมี ปัญหาด้านการดูแลรักษา โดยเฉพาะเกี่ยวกับ pg catalog ที่บางครั้ง Ducklake โยน HTTP 400 กับไฟล์ที่มันสร้างเอง
      ไม่แน่ใจว่าเป็นเพราะแพตเทิร์นการเขียนข้อมูลของฉัน (แทรกจาก Polars DataFrame ไปยังตาราง Ducklake) หรือเป็นเพราะโครงสร้างตารางแบบ partition
      ในสภาพแวดล้อมพัฒนา/ทดสอบมันโอเค แต่พอใช้ทั้งทีมกลับมีปัญหา สุดท้ายเลยกลับไปใช้ไฟล์ Parquet แบบ Hive-partitioned ร่วมกับ DuckDB view
      ตั้งใจว่าจะเอาตัวอย่างไปเปิดเป็น issue ทีหลัง แต่ตอนนี้ยังไม่มีเวลาเพราะติดงานอื่น
  • นี่คือ การเปลี่ยนแปลงครั้งใหญ่ จริง ๆ
    เมื่อก่อนฉันมักพูดว่าในตลาด Postgres ยังไม่มี “โอเพนซอร์ส Snowflake”
    ส่วนขยาย Postgres ของ Crunchy ตอนนี้เป็นโซลูชันที่ล้ำหน้าที่สุดในตลาด ขอแสดงความยินดีกับ Snowflake และทีม Crunchy ที่ปล่อยสิ่งนี้เป็นโอเพนซอร์ส
    • พูดตามตรง ฉันคิดว่าจ่ายเงินให้ Snowflake ไปเลยแล้วใช้ DB กับ ecosystem ที่ยอดเยี่ยมของมันน่าจะดีกว่า ถ้าโครงสร้างพื้นฐานไม่ใช่หัวใจของคุณค่าที่มอบให้ลูกค้า ก็ควรปล่อยให้คนอื่นจัดการส่วนนั้น แล้วโฟกัสกับการสร้างของเจ๋ง ๆ
  • ฉันชอบ ดาต้าเลก กับภาษา query ที่คล้าย SQL มันให้ความรู้สึกเหมือนวิวัฒนาการของแนวคิด “ทุกอย่างคือไฟล์”
    บน Linux เราสามารถอ่านและเขียนค่าตั้งค่าระบบผ่านไฟล์ซิสเต็มได้ (cat /sys/..., echo ... > /sys/...)
    ด้วย FUSE คุณสามารถเขียนไดรเวอร์ไฟล์ซิสเต็มใน userspace ได้เอง เช่นเมานต์ SSH หรือ Google Drive แล้วคัดลอกด้วยคำสั่ง cp
    แต่ไฟล์ซิสเต็มเหมาะกับข้อมูลแบบลำดับชั้นเท่านั้น ข้อมูลในโลกจริงส่วนใหญ่เป็น โครงสร้างเชิงสัมพันธ์
    ดาต้าเลกทำให้เราจัดการแหล่งข้อมูลที่ต่างกันเสมือนเป็นฐานข้อมูลเชิงสัมพันธ์เดียวกันได้ ผ่านนามธรรมอันสวยงามของ SQL
    และเพราะท้ายที่สุดแล้วแอปจำนวนมากก็เน้น CRUD แนวทางนี้จึงมีประสิทธิภาพกว่ามาก
  • คุณใช้ดาต้าเลกกันอย่างไร? สำหรับฉันมันไม่ใช่แค่ที่เก็บข้อมูล แต่เป็นพื้นที่สำหรับงานวิเคราะห์ที่ คาดเดาล่วงหน้าไม่ได้
    ในกรณีแบบนี้ Postgres มีข้อจำกัด ต้องใช้ CPU และ RAM มากขึ้น และสุดท้ายก็ต้องพึ่ง เอนจินแบบกระจาย
    • แก่นของดาต้าเลกคือ การแยก compute ออกจาก storage ส่วน Postgres ไม่ใช่ชั้น compute แต่เป็นชั้นสำหรับการเข้าถึง
      ส่วน compute จะถาม Postgres ว่า “ข้อมูลล่าสุดของคีย์เหล่านี้คืออะไร?” หรือ “ข้อมูลเมื่อ 2 สัปดาห์ก่อนคืออะไร?” แล้ว query วิเคราะห์จริง ๆ จะไปรันกับไฟล์ Parquet โดยตรง
  • ตอนที่ Snowflake เข้าซื้อ Crunchy Data ฉันคาดหวังว่าจะมี เวอร์ชันแบบ managed แบบนี้ออกมา
    การรันบน Docker ในเครื่องก็ดี แต่ถ้าสามารถใช้งานบน AWS พร้อมรวมบิลผ่านบัญชี Snowflake ได้ก็น่าจะดีมาก
  • ตอนนี้รู้สึกว่าเป็น ยุคทองของ PostgreSQL จริง ๆ
  • ฉันไม่ใช่วิศวกรข้อมูล แต่ทำงานในสายที่เกี่ยวข้อง เลยสงสัยว่าจะมีใคร อธิบายแบบเข้าใจง่าย ได้ไหมว่าสิ่งนี้แก้ปัญหาอะไร
    • สมมติว่ามีบริการหนึ่งเก็บข้อมูลล็อกเป็นไฟล์ Parquet ไว้บน S3 ถ้าคุณอยาก query ข้อมูลนี้จากใน Postgres โดยตรง pg_lake ก็มีประโยชน์
      คุณสามารถดึงข้อมูล Parquet มา query ใน Postgres ได้ และยัง join กับตารางเดิมได้ด้วย
  • มีสองคำถาม
    (1) มีแผนจะรองรับการใช้สเปก Ducklake แทน Iceberg หรือไม่? Ducklake จัดการแค็ตตาล็อกด้วยตาราง SQL แทนไฟล์ ทำให้ การเขียนพร้อมกัน หรือการจัดการ snapshot ง่ายกว่า
    (2) เป็นไปได้ไหมว่า pg_duckdb เมื่อเวลาผ่านไปจะทำฟังก์ชันเดียวกันได้?
    • (1) เคยพิจารณาแล้ว แต่ตอนนี้ยังไม่มีแผน แทนที่จะใช้ Ducklake ตรง ๆ เราอยากทำใน Postgres โดยตรงเพื่อคง ขอบเขตของธุรกรรม เอาไว้
      อย่างไรก็ตามยังมีความซับซ้อน เช่นการจัดการข้อมูลแบบ inline แต่ถ้าแก้ได้ก็จะได้ประสิทธิภาพธุรกรรมที่สูง
      (2) สำหรับ pg_duckdb นั้นอาจนำ implementation ของ Ducklake มาใช้ซ้ำได้ง่ายกว่า แต่ในมุมของการจัดการทรัพยากรและเสถียรภาพ เรามองว่าโครงสร้างแบบนั้นเหมาะน้อยกว่า
  • จาก S3 Table Buckets, Cloudflare R2 Data Catalog และโปรเจ็กต์นี้ ดูเหมือนว่า Iceberg กำลังชนะ
  • ถ้าคุณอยากโหลดข้อมูลเข้า DB ที่รองรับ Postgres Wire ได้ง่าย ๆ ขอแนะนำ sling-cli
    คุณสามารถรัน งาน ETL ได้ผ่าน CLI, YAML และ Python