DuckLake - एकीकृत डेटा लेक और कैटलॉग फ़ॉर्मेट

 (ducklake.select)
13 पॉइंट द्वारा GN⁺ 2025-05-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • डेटा लेक और कैटलॉग फ़ॉर्मेट को एकीकृत करने वाला नया समाधान
  • Parquet फ़ाइलों और SQL डेटाबेस पर आधारित, और पारंपरिक lakehouse की तुलना में अधिक सरल डेटा लेक इम्प्लीमेंटेशन को संभव बनाता है
  • PostgreSQL, SQLite, MySQL, DuckDB जैसे कई डेटाबेस के ऊपर metadata catalog management संभव है
  • snapshot, time travel query, schema change, partitioning जैसी विभिन्न सुविधाओं का समर्थन करते हुए हल्का snapshot processing प्रदान करता है, जिसमें बार-बार compact करने की ज़रूरत नहीं पड़ती
  • कई instances के एक साथ डेटा पढ़ने और लिखने वाले multiplayer DuckDB model का समर्थन करता है, और डिफ़ॉल्ट DuckDB में उपलब्ध नहीं concurrency processing model को लागू करता है
  • DuckLake एक ऐसा व्यापक कॉन्सेप्ट है जिसमें specification, DuckDB extension, और DuckLake फ़ॉर्मेट में संग्रहीत dataset शामिल हैं, और इसे MIT license के तहत जारी किया गया है

DuckLake परिचय

  • DuckLake, DuckDB टीम द्वारा बनाया गया एक open format है, जो जटिल lakehouse के बिना भी उन्नत डेटा लेक फीचर्स प्रदान करता है
  • केवल SQL डेटाबेस और Parquet फ़ाइलों के साथ अपना data warehouse बनाया जा सकता है.
  • metadata management के लिए डेटाबेस का उपयोग: PostgreSQL, SQLite, MySQL, DuckDB

DuckLake की मुख्य विशेषताएँ

  • डेटा लेक operations

    • snapshot
    • समय-बिंदु क्वेरी (Time travel)
    • schema evolution
    • partitioning

  • हल्का snapshot processing

    • snapshots की संख्या पर कोई सीमा नहीं, इसलिए इन्हें बनाया जा सकता है
    • बार-बार compact करने की आवश्यकता के बिना काम कर सकता है

  • ACID transactions

    • multi-table operations के लिए concurrent access और transaction guarantee

  • performance-केंद्रित डिज़ाइन

    • filter pushdown के लिए statistics का उपयोग
    • बड़े datasets पर भी तेज़ querying संभव

अक्सर पूछे जाने वाले प्रश्न

  • DuckLake का उपयोग क्यों करें?

    • डेटा लेक और कैटलॉग को एकीकृत करने वाला हल्का समाधान चाहिए तो यह उपयुक्त है
    • कई DuckDB instances एक ही dataset को पढ़ और लिख सकते हैं, यानी multiplayer environment संभव है
      • यह मौजूदा DuckDB में समर्थित नहीं concurrency model है
    • सिर्फ DuckDB का उपयोग करके भी समय-बिंदु क्वेरी, partitioning, और multi-file storage structure जैसे लाभ मिल सकते हैं

  • DuckLake क्या है?

    • DuckLake निम्न तीन चीज़ों को संदर्भित करता है:
      1. DuckLake फ़ॉर्मेट की specification
      2. DuckLake को सपोर्ट करने वाला DuckDB extension (ducklake extension)
      3. DuckLake फ़ॉर्मेट में संग्रहीत dataset स्वयं

  • DuckLake का लाइसेंस क्या है?

    • इसे MIT license के तहत जारी किया गया है

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

1 टिप्पणियां

 
GN⁺ 2025-05-29
Hacker News की राय

  • Parquet के बारे में एक चीज़ हमेशा खलती रही है: अलग-अलग “data lake / lakehouse” सिस्टम्स ने ‘ranged partitioning’ को अपने-अपने असंगत तरीकों से हल किया है। मेरा application लगभग पूरी तरह Parquet में फिट बैठता है, लेकिन मैं ऐसे डेटा के साथ काम करता हूँ जो time-series logs की तरह timestamp के हिसाब से समान रूप से वितरित नहीं होता। partition columns Hive partitioning का पालन करते हैं, लेकिन साथ ही timestamp के आधार पर स्वाभाविक रूप से बँटे हुए हैं। समस्या यह है कि Hive partitioning इसे support नहीं करता, इसलिए मुख्य query tools मेरी data structure को सही तरह import नहीं कर पाते। date-based columns जैसी बेकार workaround अपनानी पड़ती है, या फिर बस files जमा करते रहो, जिससे performance और cost दोनों बढ़ते हैं। Iceberg, Delta Lake आदि में ranged partitioning है, लेकिन मुझे इतनी complexity नहीं चाहिए; काश simple filename या directory naming rules ही standardize कर दिए जाएँ। और Parquet row, Arrow row, Thrift, protobuf जैसे formats काफी मिलते-जुलते हैं, लेकिन पूरी तरह एक जैसे नहीं हैं; अगर single row या row stream के लिए कोई binary format साथ में होता, तो अलग-अलग tools के बीच interoperability और बेहतर हो सकती थी

    • क्या Parquet file के footer metadata से ज़रूरी जानकारी लेने के लिए वह पर्याप्त नहीं है? metadata में उस column के min/max timestamp होते हैं, इसलिए query के समय query tool सिर्फ वही metadata पढ़कर तय कर सकता है कि file पढ़नी है या नहीं, और इससे बेकार reads रोकी जा सकती हैं

    • समय संबंधी डेटा को संभालना मुश्किल है, लेकिन तरीके के अनुसार इसे टाला भी जा सकता है। raw time-series को सीधे query करने के बजाय event processing चरण में timestamps को normalize करके store करना उपयोगी हो सकता है। sliding window के आधार पर event start points ढूँढकर offset adjust किया जा सकता है, ताकि यह पहचाना जा सके कि time-series किस जगह reference point (0) पर लौटती है, और उसे event unit के रूप में इस्तेमाल किया जा सके

    • Hive injected और dynamic, दो तरह की partitioning support करता है। partition key के रूप में UNIX time आधारित hour column (epoch से हर 3600 seconds पर बढ़ने वाला integer) इस्तेमाल किया जा सकता है। query engine में शायद partition range स्पष्ट रूप से बतानी पड़े, लेकिन query में datepartition >= a AND datepartition < b जैसे रूप में इसका उपयोग किया जा सकता है। Iceberg यह काम बहुत अधिक सरल बनाता है क्योंकि वह सीधे timestamp range के रूप में इस्तेमाल करने देता है, और ऐसे partitions को अपने आप exclude कर देता है जिनके लिए metadata की ज़रूरत नहीं है

    • arrow/parquet low-level libraries में row group और data pages को सीधे control किया जा सकता है। arrow-rs crate का इस्तेमाल करके मैंने file query speed को 10x से भी अधिक बेहतर किया है। कभी row groups कम होते हैं, कभी बहुत ज़्यादा, लेकिन मनचाहे row groups को तेज़ी से skip किया जा सकता है, इसलिए skew समस्या नहीं बनता। हाँ, यह ध्यान रखना चाहिए कि प्रति file row groups की सीमा 2^15 है

    • यह Parquet की समस्या कम और Hive की सीमा ज़्यादा लगती है। columns की min/max जानकारी देखने के लिए Parquet file खोलनी पड़ती है, लेकिन एक बार पता चल जाए कि data range के भीतर नहीं है, तो आगे कोई अतिरिक्त request नहीं करनी पड़ती। अगर इस metadata को एक ऊपरी स्तर पर, जैसे DuckLake में, इस्तेमाल किया जाए तो यह अधिक कुशल होगा

  • Iceberg (Delta Lake भी कुछ वैसा ही है, लेकिन व्यक्तिगत रूप से मुझे Iceberg थोड़ा ज़्यादा कठिन लगता है) में सबसे असुविधाजनक बातों में से एक यह थी कि इसे notebook या local environment में आज़माना आसान नहीं है। Delta Lake के कई Python implementations हैं, लेकिन वे बिखरे हुए हैं, और Iceberg में JVM cluster setup वगैरह का झंझट ज़्यादा है। मैं sqlite/postgres + duckdb + parquet के combination को blob storage पर store करना चाहता था, लेकिन यह काफ़ी झंझटी निकला। DuckDB वाली दिशा में चीज़ें बिना इस तरह की मेहनत के सीधे काम करती हैं और ठीक-ठाक आकार के data तक स्वाभाविक रूप से scale भी हो जाती हैं। DuckDB टीम इस क्षेत्र को अच्छी तरह समझती है, और इससे सच में काफ़ी उम्मीदें हैं

    • क्या आपने PyIceberg इस्तेमाल किया है? यह pure Python implementation है और काफ़ी अच्छा काम करता है। यह SQL Catalog और SQLite-based in-memory catalog भी support करता है
      https://py.iceberg.apache.org/

    • S3 और RDS का इस्तेमाल करने वाली step-by-step setup guide भी है। इसे local sqlite में बदलना भी मुश्किल नहीं होना चाहिए
      https://www.definite.app/blog/cloud-iceberg-duckdb-aws

    • इसे local पर सच में बहुत आसानी से आज़माया जा सकता है। marimo notebook में यह कुछ lines of code से हो जाता है (नोट: मैं marimo developer हूँ)
      https://www.youtube.com/watch?v=x6YtqvGcDBY

    • मैं सोच रहा हूँ कि क्या k3s के साथ अच्छी तरह काम करने वाला Helm chart बनाया जाए। datapains का उपयोग करें तो trino भी आसानी से चलाया जा सकता है, और थोड़ी-सी tweaking के साथ hivemetastore भी उठाया जा सकता है। मैंने trino के साथ Iceberg connector जोड़कर पूरा flow test किया है। structure यह है कि data को hive में load करो, फिर trino से वही table point कराओ, और select के साथ iceberg में insert कर दो। अगर DuckDB वाली तरफ़ से सच में ऐसा environment आ जाए जो बहुत आसानी से काम करे, तो यह industry leadership भी ले सकता है

    • delta-io (deltalake-r आधारित) local पर बहुत आसानी से काम करता है। pip से install करके तुरंत catalog और file writing की जा सकती है
      https://delta-io.github.io/delta-rs/

  • यह Iceberg पर एक तेज़ और सटीक आलोचना है—जब आप वैसे भी database इस्तेमाल कर रहे हैं, तो metadata को files में क्यों रखा और संभाला जाए, यह सवाल वाजिब है। DuckLake के लिए DuckDB से बाहर व्यापक सफलता पाना आसान नहीं होगा, लेकिन अंततः यह ऐसी structure बन सकती है जहाँ catalog metadata तक संभाले, और मौजूदा Iceberg format इतिहास के एक क्षण बनकर रह जाए

  • मौजूदा Lakehouse systems (जैसे Iceberg) schema/file list जैसी महत्वपूर्ण table जानकारी को S3 जैसे object storage में छोटे metadata files के रूप में बिखेरकर रखते हैं। इस वजह से query planning और table updates जैसे कामों में network calls बहुत ज़्यादा हो जाते हैं, जिससे चीज़ें धीमी होती हैं या conflicts बढ़ते हैं। DuckLake सभी metadata को एक तेज़ और transactional SQL database में रखता है, जिससे एक ही query में सारी ज़रूरी जानकारी मिल जाती है और efficiency व reliability दोनों काफ़ी बेहतर हो जाते हैं

  • DuckLake से जुड़ा manifesto: https://ducklake.select/manifesto/

  • मैं अंदरूनी तौर पर deltalake-rs के Python bindings और duck db का इस्तेमाल करके एक “poor man’s datalake” बना रहा हूँ। structure यह है कि parquet files blob storage में रखी जाती हैं। लेकिन concurrent writes में हमेशा समस्या आती है। किसी तय interval पर cloud function का API से data pull करना ठीक चलता है। लेकिन अगर backfill कई बार चलाया जाए, तो timer function के साथ एक ही समय पर चलकर conflict का ख़तरा बढ़ जाता है। खासकर तब जब backfill queue में सैकड़ों jobs जमा हों और workers saturated हो जाएँ

    • filename के अंत में random suffix जोड़ने का एक तरीका है

    • write से पहले json file पर temporary lease लगाकर और write requests को queue में manage करके conflicts रोके जा सकते हैं

  • Iceberg की सीमाओं, खासकर metadata management की समस्या को address करने वाला एक competing solution (जैसे Snowflake metadata management के लिए FoundationDB का उपयोग करता है, जबकि Iceberg blob storage तक जाता है)
    https://quesma.com/blog-detail/apache-iceberg-practical-limitations-2025

    • मुझे भी ऐसा ही लगा था, लेकिन वीडियो देखने पर DuckLake सीधा competitor नहीं है
      https://youtu.be/zeonmOO9jm4?t=4032
      DuckLake ज़रूरत पड़ने पर ही Iceberg के manifest/metadata files लिखकर sync करता है, और यह पहले से मौजूद Iceberg data को पढ़ना भी support करता है। इसने Iceberg की मुख्य समस्याओं को बेहतर किया है; यह अलग competitor product कम और Iceberg के साथ साफ़-सुथरी bidirectional integration वाली structure ज़्यादा है

    • metadata bloat को स्थिति के अनुसार काफ़ी हद तक manage किया जा सकता है

      • snapshots की संख्या
      • बार-बार होने वाले बड़े schema changes
      • बार-बार row-level updates / बहुत सारी छोटी files
      • statistics information आदि
        पहले बड़े schemas की वजह से आख़िरी बिंदु समस्या बनता था। ज़्यादातर engines compaction, snapshot export जैसे tools के साथ management support देते हैं, हालाँकि ज़िम्मेदारी कुछ हद तक user की भी होती है। S3 tables कुछ management features देती हैं। अगर metadata 1~5MB है, तो असल में वह समस्या नहीं है। commit speed metadata size और writers की संख्या पर निर्भर करती है। 1GB से अधिक metadata को भी मैंने scripts से संभाला है—आमतौर पर overwritten snapshots को साफ़ करके (असल file deletion को bucket policy पर छोड़ते हुए) या पुराने schema versions हटाकर समस्या हल हो जाती है

  • आखिरकार, अगर database को सही तरह बनाना है, तो उसे सचमुच database की तरह ही बनाना पड़ेगा। DuckDB टीम को सलाम

  • Mother Duck(https://motherduck.com/) के साथ इसका क्या संबंध है? यह “DuckDB-powered data warehousing” करने वाली कंपनी है, और DuckLake से पहले शुरू हुई थी

    • MotherDuck और DuckLake बहुत अच्छी तरह integrate होने वाले हैं। MotherDuck data को DuckLake में store किया जाएगा, जिससे scalability, concurrency और consistency बेहतर होगी, और third-party tools से भी underlying data तक पहुँचा जा सकेगा। पिछले कुछ महीनों से इस पर काम चल रहा है, और जल्द ही ज़्यादा जानकारी साझा की जाएगी

    • MotherDuck वह service है जो आपके data upload करने पर उसे अपने आप organize करती है और DuckDB के ज़रिए data interface देती है। अगर आपको ज़्यादा lakehouse-जैसी capabilities, blob storage integration, DuckLake के साथ अतिरिक्त integration, या metadata storage को MotherDuck में रखना है, तो DuckLake इस्तेमाल किया जा सकता है

    • MotherDuck, duckdb को cloud में host करने वाली service है, जबकि DuckLake कहीं ज़्यादा खुला system है। DuckLake में S3, EC2 जैसे अलग-अलग environments में कई instances और petabyte-scale warehouse, multiple readers/writers के साथ, transactional तरीके से बनाए जा सकते हैं। MotherDuck में एक समय पर केवल एक Writer संभव है, read replicas में लगभग 1 minute की latency होती है और वह transactional भी नहीं है। कई instances एक साथ अलग-अलग tables पर write नहीं कर सकते। DuckLake storage और compute का separation, और एक transactional metadata layer भी देता है

  • मुझे duckDB बहुत पसंद है और DuckLake भी सच में शानदार लगता है। एक सवाल: अगर आज से इसका उपयोग शुरू किया जाए, और company पहले से Snowflake चला रही हो, तो analysts को क्या अपने-अपने local systems पर duckdb + extensions install करके blob store और datalake extension के लिए database (मान लें VM पर चल रहा duckdb) को point करना होगा? query run होने पर compute कहाँ होगा, और बड़े workloads के लिए क्या करना होगा? क्या structure ऐसा होगा कि सभी users किसी बड़े duckdb VM में ssh करके queries चलाएँ? इस हिस्से पर स्पष्टीकरण चाहिए

    • अगर duckdb local पर चल रहा है, तो compute हर user के अपने PC पर होगा। अगर ज़्यादा compute चाहिए, तो VM चलाकर उसका उपयोग किया जा सकता है। दोनों संभव हैं—छोटे कामों के लिए local, और बड़े workloads के लिए VM तक scale किया जा सकता है