Parquet फ़ाइलों में महारत हासिल करना: संरचना, उपयोग के मामले और मुख्य लाभ

एक Parquet फ़ाइल डेटा को रो (row) के बजाय कॉलम (column) के अनुसार स्टोर करती है। Apache Parquet प्रोजेक्ट इसे "एक ओपन सोर्स, कॉलम-ओरिएंटेड डेटा फ़ाइल फ़ॉर्मेट के रूप में वर्णित करता है जिसे कुशल डेटा स्टोरेज और रिट्रीवल के लिए डिज़ाइन किया गया है।" यही एक डिज़ाइन विकल्प यह स्पष्ट करता है कि यह आकार में छोटा, क्वेरी करने में तेज़ और डबल-क्लिक करके खोलने में अधिक कठिन क्यों है।

Parquet फ़ाइल क्या है?

Parquet टैबुलर (tabular) डेटा के लिए एक फ़ाइल फ़ॉर्मेट है, जिसे एक Apache प्रोजेक्ट के रूप में बनाए रखा जाता है। आधिकारिक दस्तावेज़ बताते हैं कि यह "थोक में जटिल डेटा को संभालने के लिए उच्च प्रदर्शन वाले कम्प्रेशन और एन्कोडिंग स्कीम्स प्रदान करता है।" यह आगे जोड़ता है कि यह फ़ॉर्मेट "कई प्रोग्रामिंग भाषाओं और एनालिटिक्स टूल्स में समर्थित है।"

इसकी सबसे मुख्य विशेषता इसका ओरिएंटेशन (orientation) है। एक CSV एक बार में एक रो लिखता है: रिकॉर्ड एक का प्रत्येक फ़ील्ड, फिर रिकॉर्ड दो का प्रत्येक फ़ील्ड। Parquet एक बार में एक कॉलम लिखता है: पहले कॉलम का प्रत्येक मान, फिर दूसरे कॉलम का प्रत्येक मान।

यह सुनने में एक तकनीकी बात लग सकती है। इसके दो बड़े परिणाम होते हैं। एक ही कॉलम के मान आपस में मिलते-जुलते होते हैं, जिससे वे एक मिश्रित रो की तुलना में कहीं बेहतर तरीके से कंप्रेस हो जाते हैं। और एक ऐसी क्वेरी जिसे नब्बे में से केवल तीन कॉलम की आवश्यकता है, वह अधिकांश डेटा को खारिज करने के लिए हर रो को स्कैन करने के बजाय केवल उन तीन कॉलम को पढ़ सकती है।

यह फ़ॉर्मेट औपचारिक रूप से निर्दिष्ट है। Apache दस्तावेज़ों में उल्लेख है कि "parquet-format रिपॉजिटरी Parquet फ़ाइल फ़ॉर्मेट के आधिकारिक विनिर्देश (specification) को होस्ट करती है, जो यह परिभाषित करती है कि डेटा को कैसे संरचित और स्टोर किया जाता है।"

Parquet फ़ाइल कैसे संरचित होती है

एन्वलप (The envelope)

प्रत्येक Parquet फ़ाइल एक ही तरह के चार बाइट्स के साथ शुरू और समाप्त होती है। इसके विनिर्देश (specification) की शुरुआत में "4-बाइट मैजिक नंबर 'PAR1'" और बिल्कुल अंत में वही मैजिक नंबर दिखाई देता है।

उनके बीच में डेटा और, अंत के करीब, मेटाडेटा होता है। बंद होने वाले मैजिक नंबर से ठीक पहले "फ़ाइल मेटाडेटा के बाइट्स में 4-बाइट की लंबाई (little endian)" होती है। यह मान रीडर को बताता है कि मेटाडेटा ब्लॉक खोजने के लिए कितना पीछे जाना है।

रो ग्रुप्स और कॉलम चंक्स

एन्वलप के अंदर, डेटा को दो बार विभाजित किया जाता है। विनिर्देश (specification) एक ऐसी फ़ाइल का वर्णन करता है जिसमें "इस टेबल में N कॉलम हैं, जो M रो ग्रुप्स में विभाजित हैं।"

एक रो ग्रुप एक क्षैतिज स्लाइस (horizontal slice) है — यानी रो का एक बैच। प्रत्येक रो ग्रुप के भीतर, प्रत्येक कॉलम के मानों को एक कॉलम चंक के रूप में एक साथ स्टोर किया जाता है। इसलिए 90 कॉलम और 10 रो ग्रुप वाली फ़ाइल में 900 कॉलम चंक्स होते हैं, जिनमें से प्रत्येक एक ही कॉलम के मानों का एक निरंतर क्रम होता है।

यह दोहरा विभाजन ही चुनिंदा रीडिंग को संभव बनाता है। एक क्वेरी उन पूरे रो ग्रुप्स को छोड़ सकती है जिनमें मैचिंग रो नहीं हो सकते हैं, और फिर बचे हुए ग्रुप्स में से केवल उन्हीं कॉलम चंक्स को पढ़ सकती है जिनकी उसे आवश्यकता है।

मेटाडेटा अंत में क्यों होता है

यह उन लोगों को हैरान करता है जो हेडर की उम्मीद करते हैं। Apache दस्तावेज़ इसका कारण सीधे स्पष्ट करते हैं: "सिंगल पास राइटिंग की अनुमति देने के लिए फ़ाइल मेटाडेटा को डेटा के बाद लिखा जाता है।"

एक बड़े डेटासेट को स्ट्रीम करने वाले राइटर को तब तक प्रत्येक चंक की अंतिम बाइट स्थिति का पता नहीं होता जब तक कि वह उन्हें लिख नहीं लेता। मेटाडेटा को अंत में रखने का मतलब है कि उसे कभी भी वापस जाकर हेडर को पैच नहीं करना पड़ता है।

पढ़ने का पैटर्न इसी का अनुसरण करता है। दस्तावेज़ों के अनुसार, फ़ाइल मेटाडेटा में "सभी कॉलम चंक के शुरू होने के स्थानों की लोकेशन होती है।" यह आगे जोड़ता है कि "रीडर्स से उम्मीद की जाती है कि वे अपनी रुचि के सभी कॉलम चंक्स को खोजने के लिए सबसे पहले फ़ाइल मेटाडेटा को पढ़ें।"

Parquet का उपयोग किस लिए किया जाता है

आप आमतौर पर चार स्थितियों में से किसी एक में .parquet फ़ाइल का सामना करेंगे।

डेटा वेयरहाउस एक्सपोर्ट। जब कोई आधुनिक वेयरहाउस से एक बड़ी टेबल एक्सपोर्ट करता है, तो यह अक्सर डिफ़ॉल्ट विकल्प होता है, क्योंकि फ़ाइल प्रबंधनीय बनी रहती है।

डेटा लेक स्टोरेज। क्लाउड ऑब्जेक्ट स्टोरेज में मौजूद फ़ाइलें आमतौर पर इसका उपयोग करती हैं, ठीक इसलिए क्योंकि इंजन सब कुछ डाउनलोड किए बिना कॉलम के एक सबसेट को पढ़ सकते हैं।

टीमों के बीच हैंडऑफ़। आपको एक साल के ट्रांजेक्शन भेजने वाला डेटा इंजीनियर अक्सर कई गुना बड़ी CSV के बजाय इसी फ़ॉर्मेट को चुनेगा।

एनालिटिक्स टूल इंटरचेंज। चूंकि यह फ़ॉर्मेट कई भाषाओं और टूल्स में समर्थित है, इसलिए यह बीच में किसी कन्वर्शन स्टेप के बिना सिस्टम के बीच आसानी से ट्रांसफर हो जाता है।

इन सब में सामान्य बात आकार (size) है। यह उस बिंदु पर एक स्पष्ट विकल्प बन जाता है जहां एक CSV को इधर-उधर ट्रांसफर करना असुविधाजनक हो जाता है।

Parquet बनाम CSV

	Parquet	CSV
ओरिएंटेशन (Orientation)	कॉलम-ओरिएंटेड	रो-ओरिएंटेड
टेक्स्ट एडिटर में पढ़ा जा सकता है	नहीं, यह बाइनरी है	हाँ
सामान्य फ़ाइल आकार	कॉलम कम्प्रेशन के कारण छोटा	समान डेटा के लिए बड़ा
कुछ कॉलम पढ़ना	केवल उन्हीं कॉलम चंक्स को पढ़ता है	पूरी फ़ाइल पढ़ता है
डेटा प्रकार (Data types)	फ़ाइल मेटाडेटा में शामिल होते हैं	इसे खोलने वाले टूल द्वारा अनुमानित किए जाते हैं
डबल-क्लिक करके खुलता है	आमतौर पर नहीं	आमतौर पर स्प्रेडशीट में खुलता है
इसके लिए सबसे अच्छा है	बड़ी टेबल, बार-बार क्वेरी करना	छोटी टेबल, त्वरित निरीक्षण, सार्वभौमिक साझाकरण (universal sharing)

डेटा टाइप के व्यवहार पर ध्यान देना ज़रूरी है। एक CSV को यह नहीं पता होता है कि 00123 एक संख्या है या एक स्ट्रिंग, यही वजह है कि इम्पोर्ट करने पर शुरुआती शून्य और तारीखें खराब हो जाती हैं। Parquet अपने मेटाडेटा में टाइप रिकॉर्ड करता है, इसलिए जो मान आपने लिखा है, वही मान आपको वापस मिलता है।

इस तुलना के रो-ओरिएंटेड पक्ष के लिए, CSV एक्सप्लेनर दूसरी दिशा से इसी विषय को कवर करता है। TSV ब्रेकडाउन टैब-सेपरेटेड वेरिएंट को कवर करता है।

मुख्य लाभ

कम्प्रेशन जो वास्तव में फ़ायदा पहुँचाता है। समान मानों को एक दूसरे के बगल में स्टोर करने से एन्कोडर को काम करने के लिए बहुत अधिक सुविधा मिलती है। Apache दस्तावेज़ इसका श्रेय "उच्च प्रदर्शन वाले कम्प्रेशन और एन्कोडिंग स्कीम्स" को देते हैं।

कॉलम प्रूनिंग (Column pruning)। नब्बे में से तीन कॉलम पढ़ने में नब्बे के बजाय लगभग तीन कॉलम का ही I/O खर्च होता है।

रो ग्रुप स्किपिंग (Row group skipping)। चूंकि मेटाडेटा यह रिकॉर्ड करता है कि प्रत्येक रो ग्रुप में क्या है, इसलिए एक रीडर उन्हें छूने से पहले ही पूरे स्लाइस को खारिज कर सकता है।

डेटा टाइप सुरक्षित रहते हैं। तारीखें तारीखें ही बनी रहती हैं और आइडेंटिफायर्स अपने शुरुआती शून्य को बनाए रखते हैं, क्योंकि स्कीमा फ़ाइल के अंदर ही मौजूद रहता है।

सिंगल-पास राइटिंग (Single-pass writing)। अंत में मेटाडेटा होने का मतलब है कि बहुत बड़ी फ़ाइलों को एक स्ट्रीम के रूप में लिखा जा सकता है।

व्यापक समर्थन। दस्तावेज़ों में "कई प्रोग्रामिंग भाषाओं और एनालिटिक्स टूल्स" में इसके समर्थन का उल्लेख है, इसलिए यह शायद ही कभी कोई बंद रास्ता साबित होता है।

जहाँ Parquet मददगार नहीं रह जाता

Parquet स्टोरेज और रिट्रीवल की समस्या को हल करता है। यह इस बारे में आपके किसी भी सवाल का समाधान नहीं करता है कि वास्तव में फ़ाइल के अंदर क्या है।

यह बाइनरी है, इसलिए आप इसे एक नज़र में नहीं देख सकते। यह जांचने के लिए कि रेवेन्यू कॉलम ग्रॉस है या नेट, एक CSV को खोलने में पांच सेकंड लगते हैं। एक बाइनरी फ़ाइल को देखने के लिए आपको किसी टूल की आवश्यकता होती, तभी आप कुछ देख पाते हैं।

यह छोटे डेटा के लिए भी अनुपयुक्त है। 200-रो वाली लुकअप टेबल के लिए, मेटाडेटा ओवरहेड और टूलिंग की आवश्यकता किसी भी कम्प्रेशन लाभ से अधिक हो जाती है। वहां एक CSV बेहतर फ़ॉर्मेट है, और इस बारे में ईमानदार होना Parquet का सही ढंग से उपयोग करने का एक हिस्सा है।

और यह गुणवत्ता के बारे में कुछ नहीं कहता। फ़ाइल पूरी तरह से सही टाइप वाले, कुशलतापूर्वक कंप्रेस किए गए निरर्थक डेटा को ले जा सकती है। डुप्लिकेट रिकॉर्ड, दो मुद्राओं को मिलाने वाला एक करेंसी कॉलम, एक कस्टमर ID जिसका स्कीमा मार्च में बदल गया था। यह फ़ॉर्मेट सटीकता (fidelity) की गारंटी देता है, शुद्धता (correctness) की नहीं।

यदि आप इंजीनियर नहीं हैं तो Parquet फ़ाइल के साथ कैसे काम करें

यही व्यावहारिक अंतर है। अधिकांश व्यावसायिक टूल्स स्प्रेडशीट मानकर चलते हैं, और एक .parquet फ़ाइल उस तरह से नहीं खुलेगी जैसे कोई CSV खुलती है।

व्यावहारिक तरीका एक कन्वर्शन स्टेप है। जिसने भी फ़ाइल बनाई है, उससे उन कॉलमों का CSV या Excel एक्सट्रैक्ट मांगें जिनकी आपको वास्तव में आवश्यकता है, या किसी भी Parquet-अवेयर टूल से इसे स्वयं कनवर्ट करें। आप कम्प्रेशन का लाभ खो देते हैं, लेकिन एक बार जब डेटा आपकी मशीन पर आ जाता है और उसका दायरा सीमित हो जाता है, तो इससे कोई फर्क नहीं पड़ता।

वहां से आगे का काम सामान्य विश्लेषण है। Powerdrill Bloom का प्राइसिंग पेज Excel, CSV, PDF और दस्तावेज़ों के लिए अपलोड सूचीबद्ध करता है, इसलिए एक कनवर्ट किया गया एक्सट्रैक्ट सीधे उसमें चला जाता है। प्रश्न क्वेरी के रूप में लिखे जाने के बजाय प्राकृतिक भाषा में पूछे जाते हैं। CSV AI assistant उस मार्ग को कवर करता है, और data connectors उन मामलों को कवर करते हैं जहां डेटा को एक्सपोर्ट करने के बजाय पुल करना बेहतर होता है।

ध्यान रखने योग्य अंतर यह है कि Parquet एक स्टोरेज निर्णय है जो आपसे पहले (upstream) लिया जाता है। यह कोई विश्लेषण टूल नहीं है, और फ़ाइल आपके डेस्क पर पहुँचने के बाद इसे दूसरे फ़ॉर्मेट में बदलना एक सामान्य प्रक्रिया है, न कि कोई कामचलाऊ समाधान (workaround)।

निष्कर्ष

Parquet एक कॉलम-ओरिएंटेड स्टोरेज है जिसका स्कीमा और इंडेक्स फ़ाइल के अंत में होता है। यह डिज़ाइन कम्प्रेशन, चुनिंदा रीड्स और विश्वसनीय डेटा प्रकार प्रदान करता है, यही वजह है कि यह किसी भी बड़े डेटा के लिए डिफ़ॉल्ट बन गया है।

जो चीज़ यह प्रदान नहीं करता है, वह है दृश्यता (visibility)। जैसे ही फ़ाइल किसी ऐसे व्यक्ति के पास पहुँचती है जिसे स्टोरेज के बजाय जवाबों की आवश्यकता होती है, तो उपयोगी अगला कदम आमतौर पर एक सीमित एक्सट्रैक्ट और एक प्रश्न पूछना होता है।

यदि आप इसी स्थिति में हैं, तो कनवर्ट की गई फ़ाइल के साथ Powerdrill Bloom आज़माएं और इसे एक चार्ट में बदलने से शुरुआत करें।

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

Parquet फ़ाइल का उपयोग किस लिए किया जाता है?

Parquet का उपयोग बड़े टैबुलर डेटासेट को कुशलतापूर्वक स्टोर करने के लिए किया जाता है। यह डेटा वेयरहाउस एक्सपोर्ट, डेटा लेक स्टोरेज, टीमों के बीच हैंडऑफ़ और एनालिटिक्स टूल्स के बीच इंटरचेंज के लिए आम है। इसका कारण यह है कि यह अच्छी तरह से कंप्रेस होता है और केवल चयनित कॉलम को पढ़ने का समर्थन करता है।

क्या Parquet, CSV से बेहतर है?

बार-बार क्वेरी की जाने वाली बड़ी टेबल के लिए, हाँ: यह आकार में छोटा होता है, डेटा प्रकारों को साथ रखता है, और कॉलम प्रूनिंग का समर्थन करता है। छोटी टेबल जिन्हें आपको जांचना या व्यापक रूप से साझा करना है, उनके लिए CSV आसान है क्योंकि यह टेक्स्ट है और कहीं भी खुल जाता है।

क्या मैं Excel में Parquet फ़ाइल खोल सकता हूँ?

डबल-क्लिक करके नहीं, क्योंकि Parquet टेक्स्ट के बजाय एक बाइनरी फ़ॉर्मेट है। सामान्य तरीका इसे पहले CSV या Excel में बदलना है, या किसी ऐसे टूल का उपयोग करना है जो Parquet को सीधे पढ़ता है।

Parquet मेटाडेटा फ़ाइल के अंत में क्यों स्टोर किया जाता है?

Apache दस्तावेज़ स्पष्ट करते हैं कि "सिंगल पास राइटिंग की अनुमति देने के लिए" मेटाडेटा को डेटा के बाद लिखा जाता है। एक बड़े डेटासेट को स्ट्रीम करने वाले राइटर को पहले से अंतिम चंक स्थितियों का पता नहीं होता है, इसलिए अंत में मेटाडेटा लिखने से हेडर पर दोबारा जाने से बचा जा सकता है।

Parquet में रो ग्रुप्स (row groups) क्या हैं?

एक रो ग्रुप टेबल का एक क्षैतिज स्लाइस (horizontal slice) होता है। विनिर्देश (specification) एक फ़ाइल के कॉलम को "M रो ग्रुप्स में विभाजित" के रूप में वर्णित करता है, जिसमें प्रत्येक कॉलम प्रत्येक ग्रुप के अंदर एक अलग चंक के रूप में स्टोर होता है। यह लेआउट रीडर्स को उन ग्रुप्स और कॉलम दोनों को छोड़ने की अनुमति देता है जिनकी उन्हें आवश्यकता नहीं है।