F3 - भविष्य के लिए ओपन सोर्स डेटा फ़ाइल फ़ॉर्मेट

 (db.cs.cmu.edu)
9 पॉइंट द्वारा GN⁺ 2025-10-03 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • F3(Future-proof File Format) एक अगली पीढ़ी का ओपन सोर्स columnar storage format है, जिसका मुख्य डिज़ाइन सिद्धांत interoperability, extensibility और efficiency हैं, और जिसका उद्देश्य डेटा processing तथा computing environment में हर बदलाव पर नया format बनाने की आवश्यकता को समाप्त करना है
  • हर F3 फ़ाइल self-describing संरचना वाली होती है, जिसमें डेटा और metadata के साथ WebAssembly(Wasm) binary decoder भी एम्बेड होता है, ताकि native decoder न होने पर भी सभी platforms पर compatibility सुनिश्चित हो
  • यह नवीन encoding तकनीकों (cascading compression, vectorized decoding) सहित एक efficient storage layout प्रदान करता है, और Parquet तथा ORC के layout संबंधी मुद्दों को सुधारते हुए I/O, encoding और dictionary units को अलग करता है
  • plugin-आधारित decoding API और Wasm embedding mechanism के ज़रिए developers आसानी से नई encoding schemes जोड़ सकते हैं, और library version की परवाह किए बिना सभी फ़ाइलें पढ़ी जा सकती हैं, जिससे Parquet की interoperability समस्याएँ हल होती हैं
  • मूल्यांकन के परिणाम दिखाते हैं कि F3 के storage layout की efficiency और Wasm-आधारित decoding के लाभ प्रमाणित हैं; storage overhead kilobyte स्तर का बहुत कम है, और Wasm decoding की performance गिरावट native की तुलना में 10~30% है, जो स्वीकार्य स्तर पर है

पृष्ठभूमि और प्रेरणा

मौजूदा columnar formats की सीमाएँ

  • Parquet और ORC को 2010 के शुरुआती वर्षों में Hive, Impala, Spark जैसे data analytics systems के लिए विकसित किया गया था, और इन्होंने data warehouse तथा data lake के बीच data sharing संभव बनाई
  • 10 साल बाद, शोध बताते हैं कि ये formats आधुनिक data analytics के लिए पर्याप्त नहीं हैं, क्योंकि ये अपने डिज़ाइन के समय की पुरानी hardware performance assumptions और workload access pattern assumptions पर आधारित थे
    • पिछले 10 वर्षों में storage और network performance कई गुना बढ़ी है, लेकिन CPU performance उतनी नहीं बढ़ी, इसलिए systems में bottleneck अब I/O नहीं बल्कि compute पर आता है
    • data lake के उदय के साथ अधिक data high-bandwidth, high-latency cloud storage (जैसे Amazon S3) में रखा जा रहा है
    • applications अब केवल कम columns वाले tabular data को store नहीं करतीं। ML workloads में हज़ारों columns वाली wide tables, high-dimensional vector embeddings, बड़े blobs (images, video) आदि को store करना सामान्य है
    • random access या updates की मांग भी बढ़ी है, लेकिन मौजूदा formats ऐसे usage patterns के लिए उपयुक्त नहीं हैं
  • compression, indexing और filtering की नई प्रगति इन कमियों को दूर करने की कोशिश करती है, लेकिन मौजूदा file formats को आसानी से extend करने के लिए डिज़ाइन नहीं किया गया था
    • नई सुविधाएँ जोड़ने पर भी Parquet और ORC libraries की विभिन्न भाषाओं में बहुत सारी implementations होने के कारण नवीनतम version की उपलब्धता मान लेना मुश्किल है
    • पुराने library versions का उपयोग करने वाले systems नई फ़ाइलों की सामग्री decode नहीं कर पाते, इसलिए ज़्यादातर systems interoperability समस्याओं से बचने के लिए केवल न्यूनतम common denominator features को ही support करते हैं

नए file formats का उदय और उनकी सीमाएँ

  • इन समस्याओं को दूर करने के लिए Meta Nimble, Lance, TSFile, Bullion, BtrBlocks जैसे पूरी तरह नए file formats प्रस्तावित किए गए
  • लेकिन इन्होंने भी अपने पूर्ववर्तियों जैसी वही गलतियाँ दोहराईं
    • इन्हें आधुनिक hardware और workload assumptions के आधार पर डिज़ाइन किया गया
    • नई सुविधाओं को support करते हुए मौजूदा deployments के साथ interoperability बनाए रखने के लिए आसान extensibility को बढ़ावा नहीं दे पाए
    • यदि इनमें से कोई Parquet या ORC का प्रमुख विकल्प बन भी जाए, तो 10 साल बाद उसकी कमियों को दूर करने के लिए फिर एक नया format बनाना पड़ेगा

F3 का दृष्टिकोण

  • F3 का लक्ष्य interoperability, extensibility और efficiency को एक साथ हासिल करना है
  • F3 का मूल तीन specifications को परिभाषित करना है:
    1. फ़ाइल की सामग्री का metadata
    2. फ़ाइल के भीतर encoded data का physical grouping layout
    3. data की encoding scheme से स्वतंत्र data access API
  • F3 की metadata scheme table के columns के किसी subset को retrieve करने के लिए आवश्यक data को न्यूनतम करती है
  • F3, Parquet के व्यापक "row group" concept को हटाकर I/O, encoding और dictionary units को अलग करता है, जिससे layout संबंधी समस्याएँ हल होती हैं
  • इसमें cascading compression और vectorized decoding जैसे आधुनिक तरीकों को एकीकृत किया गया है

F3 अवलोकन

समग्र संरचना

  • F3 फ़ाइल metadata section और data section से बनी होती है
    • metadata section: OptionalData(OptData), Column Metadata(ColMetadata), Footer, Postscript
    • data section: Row Groups(RG) से बना होता है और इसमें वास्तविक data शामिल होता है
  • F3, Parquet और ORC की तरह ही PAX layout अपनाता है
  • लेकिन F3 में मौजूदा formats की तुलना में कई महत्वपूर्ण अंतर हैं:
    1. metadata deserialization overhead को हटाता है (Parquet/ORC की समस्या का समाधान)
    2. physical I/O Unit(IOUnit) को logical row group से अलग किया गया है, जिससे storage media के अनुसार IOUnit का आकार स्वतंत्र रूप से समायोजित किया जा सकता है
    3. dictionary encoding range को logical row group से अलग किया गया है, जिससे हर column के लिए सबसे प्रभावी range तय की जा सकती है
    4. हर IOUnit कई Encoding Unit(EncUnit) से मिलकर बना होता है, और EncUnit encoding तथा decoding की न्यूनतम इकाई है

interoperability और extensibility mechanism

  • F3 एक public API expose करता है, जो यह परिभाषित करती है कि implementation फ़ाइल के अंदर compressed data को कैसे decode करेगी
  • encoding methods को plugins की तरह माना जाता है, ताकि इन्हें core library से अलग install और upgrade किया जा सके
  • सभी library versions सभी फ़ाइलों को पढ़ सकें, इसके लिए decoder implementation को WebAssembly(Wasm) binary के रूप में फ़ाइल के भीतर एम्बेड किया जाता है
    • यानी हर F3 फ़ाइल में data के साथ उसे पढ़ने वाला code भी शामिल होता है
  • F3 की API में native code और Wasm versions के लिए अलग implementation की ज़रूरत नहीं होती; वही code बिना बदलाव के दोनों targets के लिए compile किया जा सकता है
  • यह डिज़ाइन F3 को future-proof बनाता है, ऊपर बताई गई समस्याओं से बचाता है, और मौजूदा समाधानों की तुलना में तेज़ी से विकसित होने की क्षमता देता है
    • developers पूरे fleet में library version upgrade की चिंता किए बिना Wasm code को फ़ाइल में शामिल कर future encoding methods को production systems में deploy कर सकते हैं
    • Wasm binary का storage overhead बहुत कम (kilobyte स्तर) है, और native implementation की तुलना में Wasm decoding की performance गिरावट भी न्यूनतम (10~30%) है

निष्कर्ष

  • F3 एक अगली पीढ़ी का columnar file format है, जो interoperability, extensibility और efficiency को एक साथ हासिल करता है
  • efficient file layout डिज़ाइन के माध्यम से यह मौजूदा formats की inefficiencies को दूर करता है
  • plugin-आधारित decoding API और Wasm embedding के माध्यम से यह ऐसा future-proof mechanism देता है, जिससे library version की परवाह किए बिना सभी फ़ाइलें पढ़ी जा सकें
  • prototype evaluation के परिणाम layout डिज़ाइन की efficiency और Wasm mechanism की practicality को साबित करते हैं
  • Wasm overhead kilobyte स्तर के storage और 10~30% performance loss तक सीमित है, जो स्वीकार्य दायरे में है

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

1 टिप्पणियां

 
GN⁺ 2025-10-03
Hacker News टिप्पणियाँ

  • जल्दी से देखने पर लगा कि इसने Parquet की कई कमियों को काफी हद तक दूर किया है, इसलिए उम्मीदें बड़ी हैं

    • Parquet metadata भले ही Thrift-आधारित है, लेकिन उसमें सिर्फ इस तरह की टिप्पणियाँ हैं कि "अगर यह field है तो वह field भी ज़रूर होना चाहिए"; वास्तविक validation logic नहीं है, इसलिए गलत Thrift डालने पर reader टूट सकता है

    • Parquet metadata को parse करना पड़ता है, इसलिए buffer allocation और metadata parsing के लिए dynamic allocation बार-बार होती है और heap allocation बहुत बढ़ जाती है। इस बार का format Flatbuffers तरीका अपनाता है, इसलिए Flatbuffer bytes को सीधे interpret किया जा सकता है और यह समस्या हल हो जाती है

    • Encoding कहीं अधिक शक्तिशाली लगती है। ऐसा लगता है कि database उद्योग जिस हल्की और composable encoding की लंबे समय से वकालत करता आया है, वह अब संभव हो गई है। BtrBlocks, FastLanes जैसे पुराने format Parquet से बेहतर थे, इसलिए अच्छा है कि उनके अच्छे ideas आगे बढ़े हैं

    • Parquet का Dremel record-shredding बहुत जटिल था और मुझे पसंद नहीं था, इसलिए अच्छा है कि इस बार वह हटा दिया गया है

    • Parquet में DataPage के अंदर row count अलग-अलग होने के कारण मनचाही row खोजने के लिए पूरे ColumnChunk को scan करना पड़ता है, लेकिन इस format में सीधे इच्छित DataPage(IOUnit) पर jump किया जा सकता है

    • भारी compression हटाकर सिर्फ Delta/Dictionary/RLE छोड़ा गया है। भारी compression से व्यावहारिक फायदा कम मिलता है, implementation झंझटभरा होता है, और external dependency भी बहुत बढ़ती है

    • कुल मिलाकर यह बहुत बड़ी प्रगति है। उम्मीद है कि यह format data analytics उद्योग पर छा जाएगा

    • अगर भारी compression से मतलब zstd या brotli है, तो यह कम repetition वाले string column में बहुत उपयोगी है

      • मैंने खुद ऐसे मामले देखे हैं जहाँ डेटा ज्यादातर ASCII था और common substring बहुत थीं, इसलिए compression ratio 1% तक आ गया था

    • अगर wasm compiler शामिल करना पड़े, तो उल्टा ‘heavy’ compression से भी ज्यादा dependencies जुड़ सकती हैं

      • पहले CPU resource, network या disk bandwidth की तुलना में अपेक्षाकृत ज्यादा उपलब्ध होते थे, इसलिए भारी compression अधिक सार्थक था, लेकिन अब वह अंतर कम हो गया है

    • Parquet फ़ाइल में column जोड़ने पर StackOverflow चर्चा

    • क्या आजकल compression तरीका zstd पर स्थिर हो गया है?

    • Parquet उम्मीद से ज्यादा जटिल है। इसे सही और कुशल तरीके से इस्तेमाल करने के लिए बहुत से असुविधाजनक और कम documented details समझने पड़ते हैं, इसलिए यह आसान नहीं है

  • Wes McKinney

    • जो लोग Wes McKinney को नहीं जानते, उनके लिए: वे Python की सबसे व्यापक रूप से इस्तेमाल होने वाली tabular analysis library Pandas के creator हैं

    • उनके बनाए format को शुरुआती रिलीज़ से ही बाज़ार का भरोसा मिल सकता है, और वे इस समस्या पर लंबे समय से लगन के साथ काम करते आए हैं, इसलिए उनकी insight को खास महत्व दिया जाता है

    • Andy Pavlo का भी ज़िक्र होना चाहिए

      • वे database क्षेत्र के विशेषज्ञ हैं, और data-केंद्रित जीवन जीने के लिए जाने जाते हैं
      • उनके "What goes around comes around" नामक दो papers देखें, तो database क्षेत्र के अतीत और भविष्य को आसानी से समझा जा सकता है
      • CMU Seminar Series भी शानदार है, और उनके शामिल होने से उत्सुकता और बढ़ती है
      • चीनी सह-लेखकों के बारे में मैं ज्यादा नहीं जानता, इसके लिए खेद है, लेकिन मैंने इस paper को bookmark कर लिया है और इसे ध्यान से पढ़ने की योजना है

    • Pandas के प्रभाव को लेकर मैं एक प्रशंसक के रूप में सहमत हूँ, लेकिन तकनीकी रूप से मुझे लगता है कि Arrow data format ने पूरे data ecosystem पर उससे भी बड़ा प्रभाव डाला है, जैसे DataFusion आदि

      • अब मैं देखना चाहता हूँ कि F3 वास्तव में है क्या (आपकी वजह से मैंने लिंक खोला)

    • Wes McKinney, Apache Arrow के creator भी हैं

      • यह आधुनिक data analytics का एक मुख्य component है

    • मुझे लगता है कि Parquet पर उनका काम उल्टा और ज्यादा भरोसा देता है

    • Data और code को मिलाना सुरक्षा की दुनिया की एक क्लासिक गलती है

      • किसी प्रसिद्ध व्यक्ति की भागीदारी से गलती गायब नहीं हो जाती

  • लगता नहीं कि यह भौतिकविदों के भविष्य में लागू होगा

    • आने वाले 20 वर्षों में CERN के Large Hadron Collider से उत्पन्न exabyte-स्तरीय डेटा के लिए CERN अपना खुद का विकसित किया हुआ format इस्तेमाल करेगा

    • CERN data format पर सामग्री

    • CERN इस क्षेत्र में अधिकांश लोगों से बहुत पहले से बड़े पैमाने का डेटा संभालता आया है

  • मैं column-oriented storage से इसके अंतर को ठीक से न समझ पाने के लिए क्षमा चाहता हूँ

    • मुझे जिज्ञासा है कि यह इतना क्रांतिकारी क्यों है; सवाल यह है कि "क्या असली बात sandbox के साथ एक छोटा vector embedding database भेज पाना है?"

    • Paper पढ़कर लगा कि इसमें कोई नई नींव बनने की क्षमता है, और project के नाम में एक तरह की फ़्रांसीसी आभा भी महसूस हुई

    • मैं इसका अधिकांश हिस्सा समझ नहीं पाया, लेकिन चित्र और रंग योजना सुंदर और साहसी लगी। आसानी से प्रभावित हो जाने वाले व्यक्ति के रूप में मेरी तरफ से दो अंगूठे ऊपर

    • असली बात compatibility layer है

      • उदाहरण के लिए, ORCv2 ने नया format version बनाने और features को चरणबद्ध तरीके से rollout करने की कोशिश की, लेकिन अंततः रिलीज़ नहीं हो पाया
      • अगर कोई नया float encoding WASM shim के साथ फ़ाइल में ही distribute किया जा सकता, तो read software update या compatibility समस्या के बिना नया format आसानी से पहुँचाया जा सकता था
      • Spark के variant type की तरह, जब complex recombination की ज़रूरत होती है, तब interpreter की जगह bytecode भेजना कहीं आसान होता है
      • निजी तौर पर, ORC tuning करते हुए रातें जागने के बाद benchmark में उसके डटे रहने पर मुझे गर्व महसूस हुआ

    • Column storage का असली फायदा यह है कि जटिल nested schema को primitive values में तोड़कर store किया जा सकता है

      • Leaf value को सीधे पढ़ने से IO और parsing efficiency बहुत बढ़ जाती है
      • Format आम तौर पर top-level पर row group इकाइयों में partition किए जाते हैं
      • यह नया format data page से सीधे Apache Arrow buffer प्राप्त करने देता है, चाहे WASM का उपयोग हो या native decoder का
      • Parquet अभी बहुत जटिल है। यह Dremel encoding का उपयोग करके primitive values को दो integer stream (repetition/definition level) के साथ store करता है, इसलिए आम लोगों के लिए इसे parse करना मुश्किल है
      • खासकर bit-packing+RLE का मिश्रण है, और reference implementation में सिर्फ bit-packing code ही 74 हज़ार lines का है
      • Arrow buffer में बदलने के लिए काफी काम करना पड़ता है। F3 में यह बहुत आसान हो सकता है और future compatibility भी बेहतर होगी
      • इसके अलावा metadata random access का संभव होना भी बहुत बड़ा लाभ है
      • उदाहरण के लिए, GeoParquet इस्तेमाल करते समय अगर SQLite index न लगाया जाए, तो एक spatial query में औसतन 10 मिनट लगते हैं, और 500 फ़ाइलों के footer parse करने के लिए 150MB Thrift parsing करनी पड़ती है
      • Flatbuffers का चुनाव थोड़ा अप्रत्याशित है। Flatbuffers की memory safety समस्याएँ ज्ञात हैं (संबंधित चेतावनी)
      • मुझे तो लगता है कि अंदर SQLite database डालना शायद बेहतर विकल्प होता

    • Column-oriented storage का असली लाभ यह है कि पूरे column को एक साथ बहुत तेज़ी से scan किया जा सकता है

      • इससे OS buffer का बहुत कुशल उपयोग संभव होता है। उदाहरण के लिए select a where b = 'x' query बहुत तेज़ हो जाती है

  • यह निराशाजनक है कि wasm decoder native की तुलना में 10-30% धीमा है

    • यानी शुरुआत से ही 10-30% performance hit स्वीकार करनी पड़ती है, और भविष्य में decoder सुधारने के अवसर भी स्थायी रूप से छोड़ने पड़ते हैं

    • "पूरा block decode करना और memory में store करना" जैसी basic प्रक्रिया के बाहर की advanced decoding capabilities भी इस्तेमाल नहीं की जा सकेंगी

    • सच में समझ नहीं आता कि इसे इस तरह बनाने की ज़रूरत ही क्या थी

    • अगर speed महत्वपूर्ण है तो wasm समाधान नहीं है, और अगर speed महत्वपूर्ण नहीं है तो फिर जाने-पहचाने encoding इस्तेमाल किए जा सकते थे

    • WASM backup के तौर पर दिया गया है

      • अगर native decoder (जैसे crate) installed हो, तो पहले वही इस्तेमाल होगा, और न हो तो WASM fallback करेगा
      • 10-30% नुकसान सह लेना फ़ाइल को बिल्कुल पढ़ न पाने से बेहतर है, यही तर्क है

    • मैं कुछ हद तक सहमत हूँ, लेकिन मामला थोड़ा अधिक जटिल है

      • ऐसी ही स्थिति पहले से अलग-अलग compression तरीकों के साथ भी बार-बार आती रही है
      • उदाहरण के लिए bitpack method या compression बदलने पर हर बार “transcoding”, यानी file rewrite की ज़रूरत पड़ती है
      • WASM लाने के बाद भी file rewrite की ज़रूरत बनी रहेगी
      • क्या future-proofing का लाभ इतना बड़ा है, इस पर संदेह है। exabyte-स्तरीय systems में data re-encoding सचमुच बहुत कठिन होता है

  • Vortex और F3 का रिश्ता ठीक से समझ नहीं आ रहा

    • दोनों ही यह vision बताते हैं कि “नया format बनाए बिना भी encoding तरीकों को आसानी से जोड़ा जा सके”

    • परिचय में लिखा है कि Vortex की encoding implementation इस्तेमाल होती है, लेकिन type system अलग बताया गया है

    • Project की पृष्ठभूमि जटिल है

      • शुरुआत में CMU, Tsinghua, Meta, CWI, VoltronData, Nvidia, SpiralDB ने consortium बनाकर एक unified file format बनाने की कोशिश की थी
      • लेकिन Meta NDA (गोपनीयता समझौता) से जुड़ी CMU के वकील की समस्या के कारण यह योजना टूट गई
      • इसलिए सबने अपने-अपने file format जारी किए
      • शोध के लिहाज़ से CMU+Tsinghua ने encoder development से ज्यादा WASM embedding पर ध्यान दिया
      • DuckDB के Hannes ने सबसे पहले यह idea Wes McKinney को सुझाया था
      • Vortex की encoding implementation Rust-आधारित है, इसलिए थोड़ा काम करके उसका अधिकांश हिस्सा WASM में compile किया जा सकता है
      • Vortex, F3 से अलग एक स्वतंत्र project है, और F3 फिलहाल एक academic prototype है
      • जर्मनी में भी इस साल WASM का उपयोग करने वाला अलग format जारी हुआ: AnyBlox format (वह पूरी फ़ाइल को WASM बनाता है; F3 column group इकाई पर काम करता है)

  • अब अगले साल F4 की घोषणा की भी उम्मीद होने लगी है

  • source code कहाँ है, यह मैं काफ़ी देर तक खोजता रहा, लेकिन यहाँ सार्वजनिक है

  • डेटा पढ़ने के लिए WebAssembly चलाना अनिवार्य हो जाए, तो dependency या bloat कम रखना चाहने वाले environments के लिए यह उपयुक्त नहीं लगता

    • wasm सरल है

      • इसका “web” से सीधा संबंध नहीं है
      • जैसा किसी और ने कहा, wasm backup है
      • अगर native binding दिया जाए तो performance और बेहतर हो सकती है

    • अगर native decoder मौजूद है, तो WASM इस्तेमाल करने की ज़रूरत ही नहीं

      • यह बात abstract में भी साफ़ लिखी है

  • लगता है यह WebAssembly module embed करने वाले शुरुआती file formats में से एक है

    • compression के नज़रिए से यह खास दिलचस्प है। अगर WASM preprocessor सही तरह डिज़ाइन किया जाए, तो compression ratio काफ़ी बेहतर हो सकती है

    • मैं भी इसी concept पर एक file format बना रहा हूँ

    • Alan Kay ने 60 के दशक में किसी programmer द्वारा बनाए गए tape-based storage system को ‘पहला object-oriented system’ कहा था

      • उस tape के format में खास positions को पढ़ने और लिखने वाले routine का एक set शामिल था
      • यानी इसका एक पूर्व उदाहरण मौजूद है
      • संबंधित paper का लिंक (पेज 4)