OpenZL: फ़ाइल फ़ॉर्मेट को पहचानने वाला ओपन सोर्स compression framework

• Meta द्वारा जारी OpenZL संरचित डेटा के लिए lossless compression देने वाला एक नया open source compression framework है, जो डेटा फ़ॉर्मेट को पहचानकर कुशल transformation प्रक्रिया चलाता है
• हर फ़ाइल फ़ॉर्मेट पर अलग transformation चरण लागू होते हैं, लेकिन सभी फ़ाइलों को एकल universal decompressor से डिकोड किया जा सके, इस तरह इसे डिज़ाइन किया गया है
• compressor को डेटा संरचना स्पष्ट रूप से बताकर transformation प्रक्रिया को optimize किया जा सकता है, और सीखे गए compression config के ज़रिये speed और compression ratio के बीच अलग-अलग संतुलन चुने जा सकते हैं
• Meta के आंतरिक Managed Compression सिस्टम के साथ इंटीग्रेशन इसकी खासियत है, जिससे डेटा बदलने पर automatic retraining और updates संभव हैं
• स्पष्ट संरचना वाले datasets में यह उच्च प्रदर्शन दिखाता है, जिससे datacenter processing efficiency बेहतर हो सकती है और compression ecosystem को एक single decoder से सरल बनाने की संभावना दिखती है

---

OpenZL का अवलोकन

• OpenZL Meta द्वारा जारी एक format-aware data compression framework है, जो structured data के लिए विशेषीकृत compression efficiency प्रदान करता है
  • अगर डेटा का फ़ॉर्मेट स्पष्ट रूप से बताया जाए, तो यह अपने आंतरिक transformation graph के माध्यम से डेटा के नियमबद्ध पैटर्न और पुनरावृत्ति पहचानकर अधिक कुशल compression करता है
• यह Zstandard के अगले चरण जैसी अवधारणा है, जो फ़ॉर्मेट-विशिष्ट optimized compression के प्रदर्शन को single executable की maintainability के साथ जोड़ती है
  • Zstandard ने datacenter में speed और compression ratio दोनों को पूरा करते हुए बड़ी प्रगति की, लेकिन algorithm के सामान्यीकरण के कारण क्रमिक सुधार की सीमा मौजूद रही
• structured data में सामान्य compression तरीकों की तुलना में फ़ॉर्मेट के अनुरूप customized compression ratio और speed दोनों में अधिक लाभकारी होता है
• लेकिन हर फ़ाइल फ़ॉर्मेट के लिए अलग compression/restoration tool बनाना और चलाना काफ़ी बोझिल है
• OpenZL का लक्ष्य अलग-अलग customized compressors के प्रदर्शन और single binary संचालन की सरलता दोनों को साथ लाना है

संरचना-आधारित compression तरीका

• जहाँ सामान्य compressors अनुमान-आधारित तरीके से डेटा को प्रोसेस करते हैं, वहीं OpenZL डेटा संरचना को explicit input के रूप में प्राप्त करता है
  • उपयोगकर्ता Simple Data Description Language (SDDL) के माध्यम से डेटा का रूप (rows, columns, enums, nested structures आदि) बता सकते हैं
  • इस जानकारी के आधार पर OpenZL offline training (trainer) के ज़रिये सर्वोत्तम transformation sequence (Plan) बनाता है
  • बाद में compression के समय इसी Plan के आधार पर वास्तविक decoding graph (Resolved Graph) बनाया जाता है और frame में एम्बेड किया जाता है

उदाहरण: SAO डेटा compression

• Silesia Compression Corpus की SAO फ़ाइल के उदाहरण में, OpenZL हर field को अलग करके समान प्रकृति वाले data streams में बदलता है और फिर अलग-अलग optimization लागू करता है
  • X-axis coordinate (SRA0) में क्रमबद्ध प्रवृत्ति होने के कारण delta transformation लागू की जाती है
  • Y-axis coordinate (SDEC0) में range limitation का उपयोग करके transpose transformation किया जाता है
  • बाकी fields में कम cardinality होने के कारण tokenize transformation से dictionary-based compression किया जाता है
• परिणामस्वरूप, इसने zstd की तुलना में 2 गुना से अधिक compression ratio और ज़्यादा तेज़ speed (340 MB/s) दर्ज की

automatic compressor generation और training प्रक्रिया

• OpenZL का trainer डेटा samples के आधार पर स्वचालित रूप से compression strategy खोजता और सीखता है
  • training प्रक्रिया: describe(SDDL) → train(Plan generation) → compress(graph embedding) → decode(single binary से restore)
  • control points का उपयोग करके runtime पर statistics के आधार पर सर्वोत्तम path चुना जाता है
  • नया Plan लागू होने पर भी मौजूदा डेटा को पहले की तरह decode किया जा सकता है, यानी backward compatibility बनी रहती है

single decompressor के फायदे

• OpenZL किसी भी फ़ॉर्मेट में compress किए गए डेटा को single decompressor binary से restore कर सकता है
  • security और stability verification केवल एक बार करने पर पूरे सिस्टम पर लागू किया जा सकता है
  • decompressor update होने पर सभी पुराने डेटा पर भी performance improvement का लाभ लागू हो सकता है
  • operational simplicity और पूरे fleet में consistency सुनिश्चित होती है
  • कई फ़ॉर्मेट एक साथ मैनेज करते हुए भी backward compatibility बनी रहती है

performance comparison results

• विभिन्न datasets में इसने zstd, xz जैसे general-purpose compressors की तुलना में उच्च compression ratio और speed हासिल की
  • SAO: 2.06x compression ratio, 1200 MB/s restore speed
  • ERA5 (numerical data): समान समय में अधिक compression ratio, या समान compression ratio पर अधिक speed
  • Parquet और CSV datasets में भी format-aware आधार पर custom optimization संभव है
• हालाँकि text-based जैसे बिना संरचना वाले डेटा में इसका प्रभाव सीमित है, और वहाँ zstd पर fallback करके न्यूनतम प्रदर्शन सुनिश्चित किया जाता है
• compression ratio / compression speed / restore speed के तीन आयामों में अलग-अलग संयोजन चुने जा सकते हैं, और यह पारंपरिक compressors के “level” नियंत्रण से अलग लचीलापन देता है

डेटा evolution और automatic retraining

• Meta के Managed Compression से जुड़कर, डेटा फ़ॉर्मेट बदलने पर compression Plan को अपने-आप retrain किया जा सकता है
  • समय-समय पर sampling और evaluation के बाद बेहतर Plan मिलने पर उसे अपने-आप update किया जाता है
  • decompressor वही रहता है, इसलिए operational risk न्यूनतम रहता है

open source ecosystem में भागीदारी और आगे की दिशा

• OpenZL vector, table और tree-structured data के लिए उपयुक्त है, और time series, ML tensors, database tables आदि में उच्च दक्षता दिखाता है
• बिना संरचना वाले text (जैसे: enwik, dickens आदि) पर zstd लागू किया जाता है
• आगे की योजनाएँ:
  • time series और grid data के लिए transformation library का विस्तार
  • SDDL की nested data expressiveness को मजबूत करना
  • automatic compressor explorer के प्रदर्शन और स्थिरता में सुधार
• community participation के तरीके:
  • आधिकारिक OpenZL साइट और GitHub repository पर examples और documents देखे जा सकते हैं
  • नए डेटा फ़ॉर्मेट का परीक्षण और Plan प्रस्ताव
  • C/C++ engine optimization, नए transformations जोड़ना, और benchmark में योगदान संभव

निष्कर्ष

• OpenZL format-aware compression को standardize करते हुए, मौजूदा ecosystem को single decoder-केंद्रित रूप में एकीकृत करने वाला नया दृष्टिकोण प्रस्तुत करता है
• Meta का लक्ष्य इसके माध्यम से पूरे datacenter में compression efficiency, speed और maintainability को एक साथ बेहतर बनाना है

[GN⁺]

Hacker News राय

• हाल की HN की genomic data compression पोस्ट(लिंक) देखकर OpenZL की बात छिपाए रखने के लिए मुझे काफी मेहनत करनी पड़ी, यह इस बात का शानदार उदाहरण है कि डेटा पर बहुत सरल transformations भी compression efficiency को काफी बढ़ा सकते हैं, OpenZL भी अंदरूनी तौर पर ऐसे transformations को आसानी से कर सकता है(SDDL का उपयोग करके)
  • मुझे भी वही पोस्ट तुरंत याद आई, जानना चाहता/चाहती हूँ कि क्या किसी ने वहाँ बताए गए specialized compressor की OpenZL से तुलना की है, उदाहरण के लिए Grace Blackwell का 2.6Tbp 661k dataset microbial genome benchmark में क्लासिक माना जाता है, और Karel Břinda की MiniPhy पद्धति इसे 2.46TiB से 27GiB(compression ratio 91) तक घटा देती है, जानना चाहूँगा/चाहूँगी कि क्या इसी तरह के नतीजे संभव हैं
  • मैं सामान्य genomic formats(fa, fq, sam, vcf) पर benchmark results देखना चाहूँगा/चाहूँगी, खासकर nanopore data पर इसकी उपयोगिता को लेकर जिज्ञासा है, FAST5/POD5 storage मुश्किल है इसलिए बहुत सा उपयोगी data खो रहा/रही हूँ
  • [0] पोस्ट का लेखक हूँ, इसे रोककर रखने के लिए बधाई, अच्छा किया, मैं इसे ज़रूर आज़माना चाहता हूँ, fasta compressor training के बारे में OpenZL guide(लिंक) के अलावा कोई अतिरिक्त सलाह है क्या?
• थोड़ा संबंधित विषय है, हाल ही में F3 file format पर चर्चा(लिंक) हुई थी, वहाँ भी decompressor code को WASM में embed करके format-aware compression संभव है, F3 की मुख्य प्रेरणा future compatibility है लेकिन यह customized compression algorithms भी इस्तेमाल कर सकता है, इसका approach OpenZL से पूरी तरह अलग है, और OpenZL की dependencies भी काफी हल्की हैं(SDDL compiler/runtime ही चाहिए)
  • zpaq में भी पिछले 15 साल से embedded decompressor फीचर था, उसका ज़िक्र न होना थोड़ा अफ़सोसजनक है
  • compression file में executable code शामिल करने से क्या virus vulnerabilities और नहीं बढ़ जाएँगी, इसे लेकर चिंता है
• यह देखकर हैरानी हुई कि कितना अच्छा tool आया है, मुझे लगता है यह बहुत पहले आ जाना चाहिए था, अगर data container structure को ठीक से समझ लिया जाए तो deduplication efficiency बहुत बढ़ जाती है, BSD-3-Clause license, साफ-सुथरा C++ implementation, और documentation भी शानदार है, उम्मीद है आगे और file formats जुड़ेंगे
  • file-format specialization पहले भी एक जाना-पहचाना तरीका रहा है(जैसे 7-Zip का x86 opcode prefilter, ZPAQ का specialized decoder bytecode embedding), लेकिन OpenZL का actual implementation, data description तरीका, और training system प्रभावित करते हैं
• अगर मैं सही समझा/समझी हूँ, तो SDDL से data structure describe करने पर compressor हर हिस्से के लिए सबसे उपयुक्त compression strategy बना सकता है, यह सच में बहुत शानदार लगता है, अच्छा होगा अगर यह custom format compression के लिए एक सामान्य framework में विकसित हो सके
  • सही! SDDL(लिंक) ऐसा no-code toolkit देता है, अभी features सीमित हैं लेकिन आगे विस्तार की योजना है, उससे पहले C++ या Python में सीधे format parser भी बनाया जा सकता है, और ध्यान देने की बात यह है कि यह code सिर्फ compressor side पर चाहिए, decompressor format-agnostic तरीके से काम करता है
• जानना चाहता/चाहती हूँ कि क्या यह tool seekable compression को support करता है
• docs पढ़ते हुए यह जिज्ञासा हुई कि AI, imhex या Kaitai जैसी मौजूदा technologies के descriptions को SDDL में कितनी अच्छी तरह बदल पाएगा, इस तरीके से शायद अच्छे schemas बहुत जल्दी इकट्ठा किए जा सकते हैं
  • मुझे अभी तक पता ही नहीं था कि ऐसे tools मौजूद हैं, लेकिन सच में इन्हें SDDL में बदला जा सकता है, मैं इसे ज़रूर देखूँगा/देखूँगी
• Meta का Nimble, OpenZL(pre-OSS version) को native तौर पर integrate करता है, और इससे बहुत बड़ा फायदा देख रहा है
  • column-based data formats के backend compression के लिए OpenZL बिल्कुल उपयुक्त है, अगर आपको पता है कि compress होने वाला data i64 या float जैसे numbers हैं, तो यह सीधे Zstandard पर बड़ा फायदा देता है
• जानना चाहता/चाहती हूँ कि schema-undefined JSON log data पर OpenZL उपयुक्त है या नहीं, मैं एक log compression tool बना रहा/रही हूँ(लिंक)
• Non-Linear Compression(गैर-रेखीय compression) पर मैंने पहले कुछ ideas के साथ थोड़ा प्रयोग किया था, लेकिन बहुत आगे नहीं बढ़ पाया/पाई(लिंक), इसलिए ऐसा प्रयास देखकर बहुत खुशी हुई, साझा करने के लिए धन्यवाद
• यह पागलपन की हद तक दिलचस्प लग रहा है, आज शाम इसे बड़े CSV पर ज़रूर आज़माऊँगा/आज़माऊँगी
  • अगर आप अपना अनुभव साझा करें तो अच्छा होगा, OpenZL मूल रूप से Meta के internal use के लिए बनाया गया था, हाल में इसे बाहरी users के लिए भी आसान बनाने पर काफी मेहनत की गई है, feedback का स्वागत है