650GB डेटा (S3 पर Delta Lake): Polars vs. DuckDB vs. Daft vs. Spark

 (dataengineeringcentral.substack.com)
8 पॉइंट द्वारा GN⁺ 2025-11-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • S3 पर 650GB आकार का Delta Lake डेटा स्टोर करके, उसे single-node environment में Polars, DuckDB, Daft, Spark से प्रोसेस करने का performance comparison experiment
  • 32GB मेमोरी वाले EC2 instance पर क्या हर engine बड़े डेटा को संभाल सकता है, इसका सत्यापन; cluster-based Spark की तुलना में single node की संभावनाओं की पड़ताल
  • DuckDB ने 16 मिनट, Polars ने 12 मिनट, Daft ने 50 मिनट, और PySpark ने 1 घंटे से अधिक लिया, जिससे single node पर भी व्यावहारिक processing की संभावना की पुष्टि हुई
  • Polars में Deletion Vector का support नहीं, जबकि केवल DuckDB यह feature support करता है, इसलिए Lake House compatibility में अंतर मौजूद है
  • नतीजे में यह दिखाया गया कि single-node framework कम-लागत hardware पर भी बड़े पैमाने के डेटा को प्रोसेस कर सकते हैं, और distributed computing पर निर्भरता की फिर से समीक्षा की ज़रूरत है

क्लस्टर थकान और single node विकल्प

  • SaaS-आधारित Lake House cluster संचालन की लागत और जटिलता बढ़ने से 'cluster fatigue' की बात सामने आती है
  • पहले Pandas के अलावा विकल्प न होने से Spark का उपयोग होता था, लेकिन DuckDB·Polars·Daft(D.P.D.) के आने से single-node processing की संभावनाएँ बढ़ी हैं
  • D.P.D. memory से बड़े (LTM) dataset को प्रोसेस कर सकता है और तेज़ computation दे सकता है
  • लेख distributed और non-distributed, दोनों विकल्प सामने रखता है, और "Single Node Rebellion" की अवधारणा पर ज़ोर देता है

प्रयोग का environment

  • S3 पर Delta Lake table बनाई गई, और लगभग 650GB डेटा स्टोर किया गया (1TB लक्ष्य था, लेकिन बीच में रोका गया)
  • EC2 instance (32GB RAM, 16 CPU) पर DuckDB, Polars, Daft चलाने के बाद Spark से तुलना की गई
  • डेटा social media post जैसे mock data के रूप में Python dict बनाकर तैयार किया गया, फिर उसे Daft DataFrame में बदलकर Parquet files में सेव किया गया
  • उसके बाद Parquet files को Databricks में Delta Lake table में convert किया गया, और year/month partitioning बनाई गई
  • Delta log को छोड़कर लगभग 650GB डेटा की पुष्टि हुई

मेमोरी सीमाएँ और streaming की ज़रूरत

  • single node (32GB मेमोरी) पर 650GB डेटा प्रोसेस करना था, इसलिए streaming query execution की आवश्यकता सामने आई
  • Polars GitHub issue का हवाला देते हुए, Iceberg के लिए streaming write feature की माँग वाले उदाहरण का उल्लेख किया गया
  • Polars·DuckDB जैसे नए framework में Lake House format को streaming तरीके से पढ़ने और लिखने के लिए built-in support की आवश्यकता पर ज़ोर दिया गया

हर engine के टेस्ट परिणाम

  • DuckDB
    • Deletion Vector support देने वाला एकमात्र engine
    • 32GB Linux machine पर 650GB डेटा को सिर्फ 16 मिनट में प्रोसेस करने में सफल
    • कोड सरल था और result file सही तरह से बनी
  • Polars
    • Deletion Vector support न होने से Lake House environment में कुछ सीमाएँ हैं
    • Lazy API (Scan/Sink) का उपयोग ज़रूरी
    • 12 मिनट में processing पूरी, DuckDB से भी तेज़
  • Daft
    • Rust-आधारित, उपयोग अनुभव अच्छा, लेकिन 50 मिनट processing time के साथ सबसे धीमा
    • Iceberg से जुड़े कामों में स्थिर व्यवहार की पुष्टि हुई
  • PySpark (Databricks Single Node)
    • 1 घंटे से अधिक समय लगा, बिना tuning के चलाया गया
    • single-node engines की तुलना में efficiency कम रही
    • प्रयोग का उद्देश्य speed से अधिक single node की व्यवहारिकता साबित करना था

निष्कर्ष और संकेत

  • प्रयोग से साबित हुआ कि single-node frameworks बड़े Lake House डेटा को प्रोसेस कर सकते हैं
  • कम-लागत hardware पर भी उचित execution time और सरल code structure हासिल किया जा सकता है
  • DuckDB·Polars·Daft तीनों ने distributed cluster के बिना भी व्यावहारिक performance दिया
  • यह दिखाता है कि केवल distributed computing ही एकमात्र समाधान नहीं है, और आधुनिक Lake House architecture पर फिर से सोचने की ज़रूरत है
  • "Single Node Rebellion" की अवधारणा के माध्यम से cost-effective data engineering approach की संभावना उभरती है

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

1 टिप्पणियां

 
GN⁺ 2025-11-16
Hacker News टिप्पणी
  • मैं Eventual में काम करने वाला एक software engineer हूँ, और हमारी टीम द्वारा बनाए गए Daft का benchmark साझा करने के लिए धन्यवाद कहना चाहता हूँ
    Daft, AI workloads के लिए एक high-performance data processing engine है, जो single-node और distributed environment दोनों में काम करता है
    इस benchmark के ज़रिए हमें parallelism और pipelining में सुधार की काफी संभावनाएँ दिखीं। खास तौर पर deltalake reader और groupby operator में optimize करने की काफी गुंजाइश थी
    हम आने वाले release में इन improvements को शामिल करने वाले हैं, और अधिक जानकारी GitHub, Twitter, LinkedIn पर देखी जा सकती है
    अगर Daft दिलचस्प लगे, तो pip install daft के साथ इसे सीधे आज़मा सकते हैं
    • मैं जानना चाहता हूँ कि क्या Daft को ibis backend के रूप में expose करने की कोई योजना है। ऐसा होने पर दूसरे engines से आसानी से switch करके test करना अच्छा रहेगा
    • यह कंपनी के प्रचार के लिए बनाया गया account लगता है
  • Awk? इस पर एक दिलचस्प लेख है — Command-line tools can be 235x faster than your Hadoop cluster
  • 650GB? इतना छोटा data तो मेरे फोन में भी आ जाए
    over-tooling की बजाय बस GNU tools इस्तेमाल कर लो
    संदर्भ के लिए, यह पुराना लेख है लेकिन अभी भी दिलचस्प है — command-line tools can be 235x faster than your Hadoop cluster
    • अब यह उस 2014 के Hadoop दौर जैसा नहीं रहा, जिसकी उस लेख में चर्चा थी
      अगर 650GB JSON data को CLI tools से aggregate करने की कोशिश करें, तो DuckDB या ClickHouse की parallel processing performance तक पहुँचना मुश्किल होगा। GNU Parallel से भी कोशिश की, लेकिन सीमाएँ थीं
    • अगर 650TB होता, तो बात बिल्कुल अलग होती। वह लेख सिर्फ एक microbenchmark है
      असल में data catalog और cluster-based काम की ज़रूरत पड़ती है
    • “इतने छोटे नंबर गिनना ही भूल गया” वाला मज़ाक करते हुए यह वीडियो साझा किया गया
  • मैं अक्सर DuckDB के साथ single node पर ‘biggish data’ प्रोसेस करता हूँ
    Delta या Iceberg की जगह Parquet files को सीधे traverse करके query करता हूँ
    BigQuery से query किए गए results को local Parquet files (करीब 1GB प्रति file) के रूप में डाउनलोड करके DuckDB से analyze करता हूँ। यह RAM से काफी बड़ा data होता है, लेकिन फिर भी अच्छे से काम करता है
    कभी-कभी BigQuery और DuckDB की aggregation performance की तुलना करके काम को दोनों engines में बाँटकर चलाता हूँ। यही data engineering का मज़ेदार हिस्सा है
    • 650GB जितना data तो local filesystem पर भी आराम से handle हो सकता है। जटिल tools की ज़रूरत नहीं है
  • यह benchmark पूरी तरह NIC bandwidth से नियंत्रित experiment जैसा लगता है
    c5.4xlarge instance की अधिकतम 10Gbps bandwidth पर S3 से 650GB पढ़ने में कम-से-कम 9 मिनट लगेंगे
    लगता है I/O scheduling के तरीके में छोटे-छोटे फर्क का परिणामों पर बड़ा असर पड़ा होगा
    उल्टा, बड़ा instance लेकर जल्दी काम खत्म करना ज़्यादा economical भी हो सकता है
    • इसे किसी सामान्य desktop या ठीक-ठाक laptop पर test करना भी दिलचस्प होगा
      NVMe storage S3 से बहुत तेज़ है, और local 8~16-core CPU cloud से बेहतर निकल सकता है
      S3 शानदार product है, लेकिन local storage performance की बराबरी नहीं कर सकता
    • असली query ने शायद पूरी file scan नहीं की होगी, बल्कि S3 byte-range reads का इस्तेमाल करके सिर्फ कुछ columns process किए होंगे
      file size distribution या API call skew शायद इससे भी बड़े variables रहे हों
      “बड़ा instance सस्ता पड़ सकता है” वाली बात से मैं पूरी तरह सहमत हूँ
    • इस experiment की value स्पष्ट नहीं है
      Spark multi-stage बड़े datasets के लिए उपयुक्त है, और S3 को backend के रूप में इस्तेमाल करने पर network bottleneck लागत के रूप में सामने आता है
      DuckDB/Polars का single-node performance प्रभावशाली है, लेकिन यह कुछ वैसा है जैसे runway पर airplane और motorcycle की race कराना
    • 10Gbps तो बहुत कम है। Google में 400Gbps NIC और improved TCP congestion control इस्तेमाल किया गया था
      ऐसे फर्क की वजह से बहुत से लोग distributed computing से थकान महसूस करते हैं
    • मैं इस बात से सहमत हूँ। 30 साल पहले Wall Street में सीखा एक सबक है — system performance test करने से पहले theoretical maximum को समझो
      resource limits पहचानकर, उस सीमा के मुकाबले वास्तविक performance को ratio के रूप में दिखाने पर चीज़ें कहीं ज़्यादा स्पष्ट हो जाती हैं
  • यह लेख दो मायनों में गलत तरीके से पेश किया गया है
    1. असल में column pruning लागू थी, इसलिए संभव है कि सिर्फ 2 columns + metadata ही access किया गया हो
    2. ज़्यादातर समय S3 I/O में गया होगा, और concurrent connection limits का असर ज़्यादा रहा होगा
      अलग-अलग systems को आज़माना अच्छी बात है, लेकिन काश यह सच में memory से बड़े queries को गंभीरता से संभालता
    • यह महत्वपूर्ण है कि query पूरी 650GB का सिर्फ एक हिस्सा लौटाने वाला projection थी
      DuckDB memory overflow streaming में मज़बूत है, लेकिन Polars अभी उतना परिपक्व नहीं है
      S3 की default settings parallel reads को नहीं रोकतीं, इसलिए अंततः VM की network bandwidth ही bottleneck होने की संभावना है
  • हाल ही में मुझे कुछ TB JSON data process करना पड़ा, और असली समस्या ढेर सारी 10~20MB की छोटी files थीं
    ClickHouse सबसे तेज़ था, और DuckDB simplicity और stability के मामले में सबसे अच्छा था
    Flink और PySpark 3~5 गुना धीमे थे, और Dask व Ray भी बहुत धीमे थे
    अब मैं ज़्यादातर workloads के लिए DuckDB या ClickHouse से शुरुआत करने की सलाह देता हूँ। जब Pandas धीमा पड़े, तो DuckDB से बदल देना मेरी default strategy है
    • मैं जानना चाहता हूँ कि क्या आपने JSON data को पहले किसी दूसरे format में convert किया था, या सीधे JSON पर काम किया था
  • Polars, Delta Lake support के लिए delta-rs पर निर्भर करता है, और यह implementation Deletion vectors को support नहीं करती
    single-node library से भी लगभग 1TB तक आराम से handle किया जा सकता है, और 10TB से ऊपर जाकर Spark पर जाना ठीक है
    संबंधित issue
    • बहुत से लोग “Spark में parallelize करना आसान है” सोचकर बहुत जल्दी Spark पर चले जाते हैं
      लेकिन कई बार बेहतर tools से काम हो सकता है
      पहले एक junior engineer ने 5GB वाले सैकड़ों JSON को Python string concatenation से process किया, और उसमें 18 घंटे लगे,
      लेकिन जब इसे simple console tools और multiprocessing से बदला गया, तो समय 35 मिनट रह गया
      सही tool चुनना ही असली बात है
  • Presto(AWS Athena) शायद ज़्यादा तेज़ और बेहतर विकल्प हो सकता है। मैं 650GB data को local पर भी test करना चाहूँगा
    • Presto का नाम अब Trino हो गया है
      maintenance और runtime cost बहुत कम है, और यह बेहतरीन cost-performance वाला tool है
  • DuckDB का नया DuckLake catalog format भी test candidate के रूप में अच्छा लगता है — ducklake.select
    • DuckLake का data inlining flush feature अभी alpha stage में है
      छोटे batch writes के समय बहुत ज़्यादा Parquet files बनने की समस्या हल करने के लिए DuckLake इन्हें DBMS (जैसे Postgres) में inline store करता है
      हाल ही में ही इन्हें फिर से Parquet में लिखने की सुविधा आई है, लेकिन अभी भी stabilization की ज़रूरत है
      संबंधित दस्तावेज़
    • DuckLake format में SQL dependency वाला chicken-and-egg problem है
      catalog को SQL DB के रूप में व्यक्त करना पड़ता है, जबकि Parquet का फायदा ही यह है कि वह इस जटिलता से बचाता है
      अगर catalog को भी Parquet-based बनाया जाए, तो यह एक self-bootstrapping format बन सकता है