F3 - भविष्य के लिए ओपन सोर्स डेटा फ़ाइल फ़ॉर्मैट
(github.com/future-file-format)- F3 एक डेटा फ़ाइल फ़ॉर्मैट है जिसे दक्षता, इंटरऑपरेबिलिटी और स्केलेबिलिटी को ध्यान में रखकर डिज़ाइन किया गया है
- यह Parquet जैसे पिछली पीढ़ी के फ़ॉर्मैट की layout सीमाओं को सुधारने वाला डेटा organization तरीका प्रदान करता है, और built-in Wasm decoder के माध्यम से इंटरऑपरेबिलिटी और एक्स्टेंसिबिलिटी बनाए रखता है
- self-describing F3 फ़ाइल की संरचना में डेटा और metadata के साथ-साथ डेटा को डिकोड करने वाला WebAssembly binary भी शामिल होता है
- फ़ाइल में decoder को embed करने का तरीका kilobyte स्तर की न्यूनतम storage space मांगता है, और native decoder न होने पर भी किसी भी platform पर compatibility सुनिश्चित करने के लिए डिज़ाइन किया गया है
- यह Future-proof File Format प्रोजेक्ट है, जो डेवलपर्स को नए encoding तरीके आसानी से जोड़ने के लिए data organization structure और generic API प्रदान करता है
- वर्तमान स्थिति एक research prototype है जो पेपर के आइडिया को सत्यापित करता है, और production उपयोग के लिए नहीं है
- build केवल Intel मशीन की Debian 12 पर टेस्ट किया गया है, और PoC package build तथा unit test को
cargo build -p fff-poc,cargo test -p fff-pocसे चलाया जाता है - फ़ाइल फ़ॉर्मैट की परिभाषा FlatBuffer आधारित है, और इसके साथ मुख्य कोड, Wasm decoding implementation, तथा पेपर प्रयोगों के लिए benchmark और scripts भी प्रदान किए गए हैं
- लाइसेंस MIT License है
1 टिप्पणियां
Hacker News की राय
समझ नहीं आ रहा कि इसे इतने upvotes क्यों मिले, और landing page भी खास नहीं है, इसलिए पेपर देखना बेहतर लगता है: https://dl.acm.org/doi/epdf/10.1145/3749163
यह Parquet की कुछ कमियों को दूर करने की कोशिश करने वाला column-oriented storage format लगता है, लेकिन ऐसे format की असली कसौटी compatibility होती है, और नया format आते ही उस मामले में नुकसान में रहता है
Parquet सिर्फ सबसे पहले व्यापक रूप से फैल जाने की वजह से भी बहुत मजबूत है, और पेपर के मुताबिक सबसे ज़्यादा इस्तेमाल होने वाला Parquet version भी 2013 वाला सबसे पुराना version है, यानी Parquet भी Parquet को replace नहीं कर पाया
F3 को इसे पार करना है तो बहुत दमदार नतीजे दिखाने होंगे, लेकिन अभी ऐसा नहीं लगता
व्यक्तिगत रूप से Parquet के बारे में मेरी सबसे बड़ी शिकायत, यानी प्रति फ़ाइल single table वाली समस्या, इसे भी यह address नहीं करता, इसलिए नाम भी थोड़ा बढ़ा-चढ़ाकर रखा हुआ लगता है; और decoding के लिए Wasm binary डालने के बावजूद उस blob को parse करने के लिए FlatBuffers चाहिए, इससे मकसद भी धुंधला हो जाता है
मुख्य उपलब्धि random access में सुधार जैसी लगती है, लेकिन column-oriented storage तो मूलतः random access छोड़कर तेज़ analytics पाने के लिए बना था, और F3 Wasm decoder की वजह से तेज़ analytics की कुर्बानी देता दिखता है, इसलिए बात साफ़ नहीं लगती
Spark, DataFusion, DuckDB शायद multi-table file मिलने पर ठीक से न समझ पाएँ कि क्या करना है
यह सही है कि Parquet बहुत से काम अच्छी तरह करता है, लेकिन सिर्फ पहले आ जाने का मतलब यह नहीं कि वही हमेशा analytics के लिए एकमात्र file format बना रहे
तेज़ analytics और आधुनिक machine learning workloads में मूल रूप से batch scan और random access दोनों का मिश्रण होता है
F3 के कुछ authors ने Parquet की कमियों पर विस्तार से एक पेपर भी लिखा था: https://www.vldb.org/pvldb/vol17/p148-zeng.pdf
हाल के Vortex, Lance, F3 जैसे format उसी पेपर में गिनाई गई समस्याओं को हल करने की कोशिश कर रहे हैं
Lance में कुछ दिलचस्प ideas हैं, और Vortex Parquet के black-box encoder को transparent encoding से बदलकर extensibility और performance पर ध्यान देता है
इससे bulk decoding और element-wise decoding के बीच का tradeoff कम किया जा सकता है, और efficient full scan के साथ बहुत तेज़ random access भी मिल सकता है
उदाहरण के लिए LangChain ने बताया कि उसने Parquet-file-based system को Vortex में फिर से बनाया और बड़ी speedup देखी: https://www.langchain.com/blog/introducing-smithdb
संदर्भ के लिए, मैं Vortex पर काम कर रहा हूँ, इसलिए “नया format क्यों बनाया जाए” इस सवाल पर मैंने खुद बहुत सोचा है
अगर कई tables चाहिएँ तो कई Parquet files को tar में बाँध दो; tar और Parquet libraries वाले किसी भी language में इसे पढ़ना आसान है, और यही इसकी खूबसूरत सादगी है
.parquetzनाम के एक format की कल्पना की थीअगर वह बिना compress की गई कई Parquet files वाला zip file हो, तो एक ही file में कई tables ले जाए जा सकते हैं, और range requests से उस तक पहुँचना भी संभव होगा
language-specific SDKs या libraries पर निर्भर हुए बिना, और उनके न होने पर built-in Wasm methods पर fallback कर पाना, काफ़ी चतुर idea है
“हर self-describing F3 file में सिर्फ data और metadata ही नहीं, बल्कि data को decode करने वाला WebAssembly(Wasm) binary भी शामिल होता है। हर file में decoder embed करने के लिए ज़रूरी storage बहुत कम है (kilobytes में), और native decoder न होने पर भी यह सभी platforms पर compatibility सुनिश्चित करता है”
PDF के लिए embedded decoder कैसा दिखेगा?
चूँकि यह file bytes से बहुत कसकर जुड़ा है, इसलिए file writer यह चुन सकता है कि कौन-सा format उचित है, लेकिन हर format के लिए एक ही “सही decoding step” हो, ऐसा ज़रूरी नहीं
decoder आखिर किस चीज़ में decode करता है?
यह data type पर पूरी तरह निर्भर करेगा; कुछ format byte streams होते हैं, कुछ 2D pixel planes, कुछ में vertices, 2D pixel planes, UV maps चाहिए होते हैं, और कुछ मामलों में object graph ज़्यादा natural होता है
समझ नहीं आ रहा लोग क्या देखकर बात कर रहे हैं
README में यह क्या है, किस समस्या को हल करता है, इस बारे में लगभग कोई जानकारी नहीं है; सिर्फ FlatBuffers की व्याख्या और source code directories के links दिखते हैं
क्या मैं कोई context miss कर रहा हूँ?
लगता है कि “क्यों” की थोड़ी और ज़रूरत है
कहा जा रहा है कि यह Parquet की कमियों को दूर करता है, लेकिन वे कमियाँ क्या हैं यह जानने की उत्सुकता है
व्यापक tool support तो निश्चित रूप से नहीं होगा
Parquet या ORC को छोड़कर यह संरचना क्यों अपनाई जाए?
पहले paper देखना बेहतर होगा: https://doi.org/10.1145/3749163
यह लेख दिलचस्प लगा: https://medium.com/@reliabledataengineering/f3-the-future-pr...
कुछ लोगों ने इसे प्रतिभाशाली कहा, लेकिन अगर परेशान करने वाले HN skeptic की भूमिका निभाऊँ तो यह कुछ हद तक मूर्खतापूर्ण लगता है
data compression format, decode होने के बाद उस data के साथ क्या करना है, उसके मुकाबले द्वितीयक चीज़ है
audio file और SVG image पूरी तरह अलग हैं, और सिर्फ इसलिए कि video को raw pixels में खोलने वाला built-in VM हो, ऐसा नहीं कि उस video को text editor में चला सकें; इसलिए कोई बुनियादी नई interoperability नहीं बनती
हर नए format के लिए फिर भी format-specific handling चाहिए
उदाहरण के लिए, अगर H.265 से बेहतर video compression तरीका बना भी लें लेकिन सभी platform उसे support न करें, तो decoder को embed करके पुराने hardware पर playback कराने का एक उपयोग हो सकता है
लेकिन वही इसकी कमजोरी भी दिखाता है। पुराने hardware के लिए भविष्य के video formats को software decoding से अच्छे से संभाल पाना संभव नहीं लगता, और अगर यह विचार 1990 के दशक में आया होता तब भी इससे i386 पर Netflix देख पाना संभव नहीं हो जाता
इसी तरह, यह Word 2021 file को Word 97 में खुलवा देता — इस पर भी संदेह है, क्योंकि data structures के बीच 1:1 mapping नहीं है
अगर ऐसी compatibility कोई स्पष्ट जीत नहीं है, तो लक्ष्य क्या है यह समझ नहीं आता
कमियाँ तो साफ़ हैं। अगर decoder में कोई bug निकले जिसे ठीक करना हो, तो उन सभी files को कैसे patch करेंगे जिनमें वही decoder पहले से embedded है?
इसके साथ size overhead और security risk भी हैं, और यह हर format parser में काफ़ी बड़ा attack surface जोड़ देता है, जिससे remote code execution, resource exhaustion attacks जैसी संभावनाएँ बढ़ती हैं
यह हमेशा गलत approach नहीं है, लेकिन असली सवाल यह है कि फायदा क्या है
column-oriented storage formats खोजेंगे तो इनके फायदे-नुकसान आजकल काफ़ी अच्छी तरह लिखे मिलेंगे
यह निश्चित रूप से video decoding के लिए नहीं है
कुछ आधुनिक formats का फायदा यह है कि tools उन्हें बहुत ऊँची perceived speed से पढ़ सकते हैं
उदाहरण के लिए, DuckDB अपने native format या Parquet को पढ़ते समय हर तरह की optimization लागू कर सकता है
लेकिन अगर किसी format को समझने के लिए Wasm का एक blob चलाना पड़े, तो उस पर ऐसी optimizations प्रभावी ढंग से लागू हो पाएँगी या नहीं, यह स्पष्ट नहीं है
चाहे SIMD न हो या SIMD-optimized हो, अगर data पर एक pass लगाते समय वह pass query को समझ ही नहीं रहा, तो हो सकता है कि आप पहले ही नुकसान में हों
मैंने paper की शुरुआत ही सरसरी तौर पर देखी है, इसलिए असली format शायद सुनने में जितना general लगता है उससे कम general हो
self-extracting EXE की जगह इसे लेते हुए कुछ हद तक कल्पना की जा सकती है, लेकिन किसी विशेष file format को चुनने का बड़ा कारण अक्सर उस format की ठोस सुविधाएँ होती हैं
self-describing system भी दूसरे formats की तरह उसी स्थिति में फँस सकता है जहाँ “प्रतिस्पर्धी features बहुत ज़्यादा हैं और कोई भी सब कुछ handle नहीं कर पाता”
उदाहरण के लिए, क्या इस file को कुशलता से
mmapकिया जा सकता है?अगर यह अंदर से tar जैसी संरचना अपनाए तो शायद हो सके, लेकिन चलाकर देखे बिना पता नहीं
क्या किसी खास byte position पर जाकर सिर्फ उसका कुछ हिस्सा decompress किया जा सकता है?
हो सकता है यह ISO-36898533 search के सिर्फ pre-release version को support करे, और आपकी इस्तेमाल की जा रही file library ने 6 साल पहले ही उसका support हटा दिया हो
अगर बीच का 1MB फिर से लिखना हो, तो क्या disk के सिर्फ वही pages बदलने होंगे, या पूरी चीज़ दोबारा लिखनी पड़ेगी?
हो सकता है Wasm blob इसके लिए 97 APIs support करता हो, जिनमें से 35 सिर्फ नाम बदलकर दोहराई गई copies हों, इसलिए वह data से भी बड़ा हो गया हो, और किसी ने परवाह न की हो
आख़िर में पहचानने योग्य विकल्प 19 ही बचें, लेकिन CPU का native Wasm acceleration उनमें से सिर्फ दो-तीन को संभाले, इसलिए फिर भी code को काफ़ी विशेषीकृत करना पड़े
कम से कम
*.tar.gzहो तो कुछ अंदाज़ा तो रहता है कि क्या संभव हैअच्छा है। दुनिया को हमेशा बेहतर data formats की ज़रूरत रहती है
लेकिन अगर README में Parquet और दूसरे file formats की तुलना में इसके फायदे सीधे लिखे हों, तो शायद ज़्यादा रुचि मिले
जो भी https://github.com/future-file-format/f3 पर आए, उसे यह दिखना चाहिए कि इसे आज़माना क्यों चाहिए
फायदे और metrics डालिए, metrics चाहें तो अपने पक्ष के चुन सकते हैं
अच्छा use case होने की संभावना है, लेकिन मौजूदा README देखकर यह साफ़ नहीं होता कि कौन और क्यों इसे इस्तेमाल करे
अगर PB-स्तर के data को 10 साल से ज़्यादा समय तक रखना हो, तो मैं इस पर निर्भर नहीं रहना चाहूँगा कि भविष्य में भी Wasm interpreter मौजूद होगा और काफ़ी तेज़ भी होगा ताकि file पढ़ी जा सके
मैं Parquet जैसी सरल और अच्छी तरह documented byte specification चाहूँगा
ऊपर से decoding logic को Wasm binary के भीतर डालना, ऐसी चीज़ में active execution layer जोड़ना है जिसे cold storage होना चाहिए
उसे sandbox किया गया, व्यापक रूप से स्वीकार भी किया गया, और Wasm में भी वही sandboxing क्षमता है
लंबे समय के archival के लिए इसे उल्टा बेहतर भी माना जा सकता है
अलग से decompression program साथ लेकर चलने की ज़रूरत नहीं, क्योंकि वह archive file के अंदर ही मौजूद है
अगर decoding फ़ेल हो जाए, तो चिंता इस बात की है कि किसी और के डाले हुए Wasm को debug करना पड़ेगा, और उसमें मनमाने bugs हो सकते हैं
अगर प्रोजेक्ट द्वारा मेंटेन और test की गई कोई standard decoder library हो तो मदद मिल सकती है, लेकिन तब यह साफ़ नहीं है कि क्या इससे इस तरीके की flexibility का फ़ायदा खत्म हो जाएगा
यानी यह मेरी system में नया पैदा हुआ issue नहीं है, और वे इसे किसी भी client से स्वतंत्र रूप से reproduce कर सकें