Pg_lake - Postgres में Iceberg और data lake access को सपोर्ट करने वाला extension

 (github.com/Snowflake-Labs)
3 पॉइंट द्वारा GN⁺ 2025-11-05 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • pg_lake Postgres-आधारित एक extension है जो Iceberg tables और data lake files को सीधे integrate करता है, और transaction व high-speed queries को सपोर्ट करता है
  • S3 जैसी object storage में मौजूद Parquet, CSV, JSON, Iceberg files को सीधे query, import और export किया जा सकता है
  • DuckDB query engine का आंतरिक उपयोग करके Postgres environment के भीतर तेज execution performance हासिल की जाती है
  • Iceberg table creation, external files के लिए automatic schema inference, और COPY command के जरिए S3 I/O जैसी data lakehouse features एक single SQL interface में प्रदान की जाती हैं
  • Snowflake ने 2025 में Crunchy Data का अधिग्रहण करने के बाद इसे open source के रूप में जारी किया, जिससे Postgres ecosystem में data lake integration का आधार विस्तृत हुआ

pg_lake अवलोकन

  • pg_lake एक extension है जो Iceberg और data lake files को Postgres में integrate करता है, जिससे Postgres को standalone lakehouse system की तरह इस्तेमाल किया जा सकता है
    • Iceberg tables के लिए transaction guarantees और तेज queries का support
    • S3 जैसी object storage में raw data files तक direct access
  • मुख्य features
    • Iceberg tables बनाना/संशोधित करना और उन्हें अन्य engines से query करना
    • Parquet, CSV, JSON, Iceberg format की data files को query और import करना
    • COPY command से query results को Parquet, CSV, JSON format में object storage पर export करना
    • GDAL द्वारा समर्थित GeoJSON, Shapefile जैसे geospatial data formats पढ़ना
    • semi-structured data के लिए built-in map type प्रदान करना
    • heap, Iceberg, और external files को एक single SQL query में combine करना
    • external data sources से columns और types का automatic inference
    • DuckDB engine के जरिए high-speed execution

इंस्टॉलेशन और configuration

  • इंस्टॉलेशन के तरीके
    • Docker का उपयोग करके आसान रन
    • source build के जरिए manual installation या development environment setup
  • extension बनाने का उदाहरण 
    CREATE EXTENSION pg_lake CASCADE;
    • संबंधित extensions: pg_lake_table, pg_lake_engine, pg_extension_base, pg_lake_iceberg, pg_lake_copy
  • pgduck_server
    • Postgres wire protocol को implement करने वाली standalone process, जो internally DuckDB का उपयोग करती है
    • default port 5332 पर चलती है और psql से सीधे connect किया जा सकता है
    • मुख्य settings
      • --memory_limit: memory limit (default system memory का 80%)
      • --init_file_path: startup पर execute होने वाली SQL file निर्दिष्ट करता है
      • --cache_dir: remote file cache directory निर्दिष्ट करता है
  • S3 connection configuration
    • DuckDB के secrets manager का उपयोग करके AWS/GCP credentials को automatically recognize किया जाता है
    • Iceberg table storage location निर्दिष्ट करने का उदाहरण 
      SET pg_lake_iceberg.default_location_prefix TO 's3://testbucketpglake';

उपयोग के उदाहरण

  • Iceberg table बनाना 
    CREATE TABLE iceberg_test USING iceberg AS   
SELECT i as key, 'val_'|| i as val FROM generate_series(0,99)i;
    • creation के बाद SELECT count(*) FROM iceberg_test; का परिणाम 100
    • Iceberg metadata location की पुष्टि की जा सकती है
  • S3 पर COPY I/O 
    COPY (SELECT * FROM iceberg_test) TO 's3://.../iceberg_test.parquet';  
COPY iceberg_test FROM 's3://.../iceberg_test.parquet';
    • Parquet, CSV, JSON formats supported
  • S3 files से external table बनाना 
    CREATE FOREIGN TABLE parquet_table()   
SERVER pg_lake   
OPTIONS (path 's3://.../*.parquet');
    • columns का automatic inference, query संभव (SELECT count(*) FROM parquet_table; → 100)

आर्किटेक्चर

  • components
    • PostgreSQL + pg_lake extension
    • pgduck_server (DuckDB execution और Postgres protocol implementation)
  • काम करने का तरीका
    • user Postgres से connect होकर SQL execute करता है
    • query का कुछ हिस्सा DuckDB के जरिए parallel और column-oriented तरीके से execute होता है
    • DuckDB को Postgres process के भीतर embed नहीं किया जाता, इसलिए thread और memory safety issues से बचाव होता है
    • standard Postgres clients के जरिए DuckDB engine तक direct access संभव

components की विस्तृत सूची

  • pg_lake_iceberg: Iceberg spec implementation
  • pg_lake_table: object storage files के लिए FDW implementation
  • pg_lake_copy: data lake के लिए COPY I/O support
  • pg_lake_engine: common module
  • pg_extension_base: अन्य extensions के लिए base component
  • pg_extension_updater: extension auto-update feature
  • pg_lake_benchmark: lake table benchmark execution
  • pg_map: generalized map type generator
  • pgduck_server: DuckDB को load करके Postgres protocol के रूप में expose करने वाला server
  • duckdb_pglake: DuckDB में Postgres-compatible functions जोड़ता है

development और release history

  • 2024 की शुरुआत में Crunchy Data ने Iceberg को Postgres में लाने के लिए development शुरू किया
  • शुरुआती चरण में DuckDB integration और Crunchy Bridge customers के लिए features प्रदान किए गए
  • बाद में Iceberg v2 protocol और transaction support implement किया गया
  • नवंबर 2024 में Crunchy Data Warehouse के रूप में फिर से जारी किया गया
  • जून 2025 में Snowflake ने Crunchy Data का अधिग्रहण किया, और नवंबर 2025 में pg_lake को open source के रूप में जारी किया गया
    • initial version 3.0 था (पिछली दो generations सहित)
    • मौजूदा Crunchy Data Warehouse users के लिए automatic upgrade path प्रदान किया गया

लाइसेंस और dependencies

  • Apache 2.0 license
  • Apache Avro और DuckDB projects पर निर्भर
    • build के समय Avro और DuckDB extensions पर patches apply किए जाते हैं

संबंधित पढ़ाई

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 लाख से ज़्यादा single-row inserts संभाल सकता है
      ट्रांज़ैक्शन प्रोसेसिंग मुफ़्त नहीं होती। इंजन को catalog के अंदर रखने के बजाय catalog को इंजन के अंदर रखने से analytical और operational tables के बीच ट्रांज़ैक्शन संभव हो जाते हैं
      persistence और continuous processing के लिहाज़ से भी Postgres स्वाभाविक लगता है। pg_cron और PL/pgSQL से orchestration बनाया जा सकता है
      साथ ही Iceberg की ताकत कई query engines के साथ interoperability भी है
    • आख़िरकार यह डिज़ाइन फ़ैसले का सवाल है। इससे जुड़ी चर्चा इस थ्रेड में देखी जा सकती है
    • मैंने भी Ducklake को सच में पसंद करने की बहुत कोशिश की, लेकिन असल इस्तेमाल में maintenance problems थे। ख़ासकर pg catalog से जुड़ी बातों में, Ducklake कभी-कभी अपने ही बनाए फ़ाइलों पर HTTP 400 error दे देता था
      यह मेरे data write pattern (Polars DataFrame से Ducklake table में insert) की वजह से था या partitioned table structure की वजह से, यह पक्का नहीं है
      dev/test environment में तो ठीक था, लेकिन पूरी टीम के स्तर पर दिक्कतें थीं। इसलिए आख़िरकार Hive-partitioned Parquet files और DuckDB views के संयोजन पर वापस लौट आया
      बाद में issue के रूप में उदाहरण डालने का सोच रहा हूँ, लेकिन अभी दूसरे कामों के कारण समय नहीं है
  • यह सच में बड़ा बदलाव है
    पहले मैं कहा करता था कि Postgres बाज़ार में “open-source Snowflake” नहीं है
    Crunchy का Postgres extension अभी बाज़ार में सबसे आगे दिखने वाला solution है। Snowflake और Crunchy टीम को इसे open source करने पर बधाई
    • सच कहूँ तो, मुझे लगता है कि सीधे Snowflake को पैसे देकर उसके शानदार DB और ecosystem का इस्तेमाल करना बेहतर है। अगर infrastructure ग्राहक value का core हिस्सा नहीं है, तो वह काम उन्हें सौंपकर कुछ बढ़िया बनाने पर ध्यान देना चाहिए
  • मुझे data lakes और SQL-जैसी query languages पसंद हैं। यह “everything is a file” दर्शन का विकसित रूप लगता है
    Linux में file system के ज़रिए system settings पढ़ी और लिखी जा सकती हैं (cat /sys/..., echo ... > /sys/...)
    FUSE का उपयोग करके user space में file system driver सीधे implement किया जा सकता है। उदाहरण के लिए, SSH या Google Drive को mount करके cp कमांड से copy किया जा सकता है
    लेकिन file system सिर्फ hierarchical data के लिए उपयुक्त है। असली दुनिया का ज़्यादातर data relational structure में होता है
    data lake, SQL नाम की सुंदर abstraction के ज़रिए अलग-अलग data sources को एक relational database की तरह संभालने देता है
    आख़िरकार बहुत-सी applications CRUD-केंद्रित होती हैं, इसलिए यह तरीका कहीं ज़्यादा कुशल है
  • आप data lake का इस्तेमाल कैसे करते हैं? मेरे लिए यह सिर्फ storage नहीं, बल्कि अप्रत्याशित analysis workloads के लिए जगह है
    ऐसे मामलों में Postgres की सीमाएँ हैं। ज़्यादा CPU और RAM चाहिए, और अंत में distributed engine की ज़रूरत पड़ती है
    • data lake का मूल विचार compute और storage का अलगाव है। Postgres compute layer नहीं, access layer है
      compute, Postgres से पूछता है “इन keys का current data क्या है?” या “2 हफ़्ते पहले का data क्या था?”, और असली analytical queries सीधे Parquet files पर चलती हैं
  • जब Snowflake ने Crunchy Data का अधिग्रहण किया था, तब मैंने उम्मीद की थी कि वे ऐसा managed version देंगे
    इसे local Docker में चला पाना अच्छा है, लेकिन AWS पर Snowflake account के साथ integrated billing के रूप में इसे चला पाना और भी अच्छा होगा
  • अभी सच में PostgreSQL का स्वर्ण युग लगता है
  • मैं data engineer नहीं हूँ, लेकिन संबंधित क्षेत्र में काम करता हूँ। क्या कोई आसान तरीके से समझा सकता है कि यह किस समस्या को हल करता है?
    • मान लीजिए कोई service S3 में logs को Parquet files के रूप में जमा करती है। अगर आप इस data को सीधे Postgres में query करना चाहते हैं, तो pg_lake उपयोगी है
      आप Parquet data को Postgres से query कर सकते हैं, और मौजूदा tables के साथ join भी कर सकते हैं
  • मेरे दो सवाल हैं
    (1) क्या Iceberg की जगह Ducklake spec के साथ compatible होने की कोई योजना है? Ducklake catalog को files की बजाय SQL tables में manage करता है, इसलिए concurrent writes और snapshot management ज़्यादा सरल हो जाते हैं
    (2) क्या समय के साथ pg_duckdb भी वही काम करने लगेगा?
    • (1) इस पर विचार किया था, लेकिन अभी ऐसी कोई योजना नहीं है। Ducklake को ज्यों का त्यों इस्तेमाल करने के बजाय Postgres के भीतर सीधे implement करके transaction boundaries बनाए रखना चाहते हैं
      हालाँकि inline data processing जैसी जटिलताएँ हैं। इन्हें हल कर लिया जाए तो उच्च transaction performance मिल सकती है
      (2) pg_duckdb के लिए Ducklake implementation को reuse करना आसान है, लेकिन resource management और stability के लिहाज़ से वह संरचना कम उपयुक्त लगती है
  • S3 Table Buckets, Cloudflare R2 Data Catalog, और इस प्रोजेक्ट को देखते हुए माहौल ऐसा लग रहा है कि Iceberg जीत रहा है
  • अगर आप Postgres Wire-compatible DB में data आसानी से load करना चाहते हैं, तो sling-cli की सिफ़ारिश करूँगा
    CLI, YAML, Python के ज़रिए ETL jobs चला सकते हैं