JSON को Parquet में बदलें

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

JSON ऐरे ऐसा कोई भरोसा नहीं देता। रिकॉर्ड ऑब्जेक्ट हैं, हर एक जो चाहे कुंजी रखने को आज़ाद, और फ़ॉर्मेट में कुछ भी चालीसवें रिकॉर्ड को किसी फ़ील्ड में स्ट्रिंग रखने से नहीं रोकता जहाँ पहले उनतीस में संख्या थी। बदलाव को वह स्कीमा गढ़नी पड़ती है जो फ़ाइल के पास कभी थी ही नहीं, और इस पेज की हर अजीब हालत इसी एक वाक्य से आती है।

Parquet में किसी सेल के भीतर ऑब्जेक्ट रखने की जगह नहीं, तो रिकॉर्ड को ट्रांसपोज़ करने से पहले चपटा किया जाता है: शहर रखने वाला customer ऑब्जेक्ट customer.city नाम का कॉलम बनता है, JSON में जो टाइप था वही लेकर। यह इस साइट के CSV, TSV, SQL और XLSX writer जो फ़्लैटनिंग करते हैं वही है, जान-बूझकर — एक ही नेस्टेड एक्सट्रैक्ट पाँचों में से किसी को भी भेजने पर एक जैसे कॉलम नाम देता है।

ऐरे सोचने लायक़ मामला है, क्योंकि वे नाम से नहीं, स्थान से चपटे होते हैं। a और b वाली tags ऐरे दो कॉलम बनती है, tags.0 और tags.1, और कॉलम सूची पूरी फ़ाइल के मिलन से बनती है — तो जो फ़ील्ड आम तौर पर दो चीज़ें रखता है और कभी-कभी चालीस, वह चालीस कॉलम बनाता है, जिनमें से अड़तीस ज़्यादातर पंक्तियों में null होते हैं।

जहाँ हर रिकॉर्ड सपाट ऑब्जेक्ट है — कोई इवेंट लॉग, ऑर्डर का एक्सट्रैक्ट, कोई टेबल जो API ने पन्ना-दर-पन्ना लौटाई — वहाँ बदलाव ठीक वही करता है जो आप चाहते हैं, एक ही क़दम में। कुंजियाँ उसी क्रम में कॉलम बनती हैं जिस क्रम में पहली बार दिखीं, और नतीजा वह फ़ाइल है जिसे DuckDB बिना किसी तैयारी के पढ़ लेगा।

ज़्यादातर असली JSON एक्सट्रैक्ट इसी में आते हैं। एनालिटिक्स इवेंट, बिलिंग लाइनें, फ़ॉर्म सबमिशन और ज़्यादातर पन्ना-वाले लिस्ट endpoint डिज़ाइन से ही सपाट होते हैं, क्योंकि उन्हें बनाने वाले सिस्टम पंक्तियाँ लिख रहे होते हैं। जो रिकॉर्ड सचमुच नेस्ट करता है वह भी बदलता है — बस चौड़ा होकर, हर पत्ते के लिए एक डॉट कॉलम के साथ।

जो रिकॉर्ड इस बात पर असहमत हैं कि उनके पास कौन-सी कुंजी है, उन्हें सबको साथ लेकर सुलझाया जाता है। पहले रिकॉर्ड में मौजूद और अगले में ग़ायब फ़ील्ड दूसरी पंक्ति में null वाला कॉलम बनाता है, और दस लाख में से आख़िरी दस रिकॉर्ड में ही दिखने वाला फ़ील्ड भी कॉलम बन जाता है।

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

JSON की असली टाइप हैं, जो स्प्रेडशीट या CSV से बदलने पर असली फ़ायदा है: संख्या संख्या के तौर पर आती है और बूलियन बूलियन के तौर पर, अक्षरों से कुछ भी अंदाज़ा लगाए बिना। बूलियन BOOLEAN बनता है, 32-बिट सीमा में पूर्णांक INT32, बाक़ी संख्या DOUBLE, और टेक्स्ट टेक्स्ट रहता है।

टकराव तब होता है जब रिकॉर्ड असहमत हों। जो फ़ील्ड ज़्यादातर रिकॉर्ड में संख्या है और कुछ में स्ट्रिंग — कोई पहचान संख्या जिसे कुछ सिस्टम उद्धरण में रखते हैं और कुछ नहीं — पूरे कॉलम को टेक्स्ट बना देता है, और संख्या वाले मान भी बाक़ी के साथ टेक्स्ट के तौर पर लिखे जाते हैं। यह जान-बूझकर है: पहले रिकॉर्ड की टाइप लेकर बाक़ी को null करना ऐसी फ़ाइल बनाता जो साफ़ लोड होती दिखे और चुपचाप वे मान मिटा चुकी हो जो फ़िट नहीं बैठे।

Parquet में 64-बिट पूर्णांक टाइप है, और यह बदलाव उसे नहीं लिखता। मान JavaScript नंबर से गुज़रते हैं, जिनमें 53 बिट पूर्णांक सटीकता होती है, इसलिए 32-बिट सीमा के पार का मान DOUBLE के तौर पर लिखा जाता है, एक ऐसी सटीकता का दावा करने की बजाय जो अब उसके पास नहीं।

पहचान संख्या के लिए यह मायने रखता है, और इसका हल आगे नहीं, पीछे है। जो JSON एक्सपोर्ट ऑर्डर संदर्भ स्ट्रिंग के तौर पर लिखता है वह इस बदलाव से सटीक निकलता है और टेक्स्ट कॉलम बनकर उतरता है, जो पहचान संख्या को वैसे भी होना चाहिए। जो एक्सपोर्ट उन्हें सादी संख्या लिखता है वह सोलह अंकों के बाद ही, किसी कन्वर्टर के देखने से पहले, सटीकता खो चुका होता है।

छह फ़ील्ड वाले पचास हज़ार बनाए गए ऑर्डर रिकॉर्ड — id, प्रोडक्ट कोड, शहर, मात्रा, क़ीमत और एक फ़्लैग — Parquet के तौर पर 207 KB के बने। यही रिकॉर्ड compact JSON के तौर पर 4.8 MB के थे और pretty-printed के तौर पर 6.8 MB के, जो ज़्यादातर एक्सपोर्ट का असली रूप है।

यह फ़र्क़ सिर्फ़ कंप्रेशन का नहीं। हर JSON रिकॉर्ड हर कुंजी दोहराता है, तो फ़ील्ड नाम पचास हज़ार बार दिखते हैं; कॉलम स्टोर में वे एक बार, फ़ुटर में दिखते हैं। दोहराई गई क़ीमतें साथ बैठने पर बुरी तरह कंप्रेस होती हैं, यही वजह है शहर और प्रोडक्ट कोड कॉलम की क़ीमत लगभग कुछ नहीं है।

JSON एक्सट्रैक्ट अक्सर एक ऑब्जेक्ट होता है जिसकी एक कुंजी ऐरे रखती है — data, results, records। यह इकलौती-कुंजी वाला लपेटन आपके लिए खोल दिया जाता है और भीतर की ऐरे ही बदलती है, क्योंकि लगभग हर पन्ना-वाला endpoint यही शक्ल लौटाता है।

दो कुंजी पर यह रुक जाता है। {"meta": {...}, "data": [...]} जैसी फ़ाइल में कोई साफ़ ऐरे नहीं जिसे तरजीह दी जाए, तो पूरा ऑब्जेक्ट एक पंक्ति बनता है और रिकॉर्ड इंडेक्स से चपटे होते हैं: data.0.id, data.1.id, जितने भी रिकॉर्ड हों उतने के लिए। पहचान आसान है — एक पंक्ति और हज़ारों कॉलम वाली Parquet फ़ाइल। ऐसे में बदलने से पहले jq से ऐरे तक फ़ाइल छोटी कर लीजिए।

DuckDB फ़ाइल को सीधे FROM में पढ़ता है, pandas एक ही कॉल में, और Spark इसे नेटिव टेबल मानता है। फ़ाइल चार बाइट PAR1 से शुरू और ख़त्म होती है, जिससे इनमें से कोई भी इसे पहचानता है।

सबसे पहले पहली दस पंक्तियों की बजाय स्कीमा देखिए। दो सवाल लगभग सब कुछ बता देते हैं: क्या कोई कॉलम स्ट्रिंग बना है जिसे आप संख्या मानते थे, और क्या कॉलम की गिनती वही है जो आपने सोची थी। पहला बताता है कौन-से रिकॉर्ड टाइप पर असहमत थे; दूसरा बताता है कोई नेस्टेड फ़ील्ड या बदलती-लंबाई की ऐरे फ़ाइल को कितना चौड़ा कर गई।

ब्राउज़र में। Parquet writer सादी JavaScript है जो पेज माँग पर लोड करता है — न कोई WebAssembly, न कोई सर्वर — तो कोई रिक्वेस्ट एक्सट्रैक्ट को कहीं नहीं ले जाती और न कोई अकाउंट, कतार या प्लान टियर है। मुफ़्त स्तर 100 MB तक स्वीकार करता है।

असली सीमा उस संख्या से ज़्यादा मेमोरी की है, क्योंकि पूरी ऐरे पार्स होकर, कॉलम में ट्रांसपोज़ होकर लिखी जाती है, तो पूरा डेटासेट एक साथ मौजूद रहता है। दसियों मेगाबाइट सामान्य है और कई सौ पर टैब थकने लगता है। इसके आगे किसी स्क्रिप्ट में स्ट्रीमिंग रीडर सही औज़ार है।