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

एक JSONL फ़ाइल में प्रति पंक्ति एक पूर्ण JSON मान होता है। आधिकारिक दस्तावेज़ इसे "JSON Lines टेक्स्ट फ़ॉर्मेट, जिसे न्यूलाइन-डिलिमिटेड JSON भी कहा जाता है" कहते हैं। यही एकमात्र नियम है जिसके कारण यह अच्छी तरह से स्ट्रीम होता है, आंशिक रूप से पढ़े जाने पर भी सुरक्षित रहता है, और यही कारण है कि कोई स्प्रेडशीट इसे नहीं खोल पाती है।

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

JSON Lines रिकॉर्ड के लिए एक टेक्स्ट फ़ॉर्मेट है। इसके स्पेसिफिकेशन में इसे "संरचित डेटा (structured data) को संग्रहीत करने के लिए एक सुविधाजनक फ़ॉर्मेट" के रूप में वर्णित किया गया है "जिसे एक समय में एक रिकॉर्ड के रूप में प्रोसेस किया जा सकता है।"

दस्तावेज़ स्पष्ट रूप से बताता है कि यह कहाँ उपयुक्त बैठता है। यह "unix-style टेक्स्ट प्रोसेसिंग टूल और शेल पाइपलाइनों के साथ अच्छी तरह से काम करता है," और पेज में आगे कहा गया है कि "यह लॉग फ़ाइलों के लिए एक बेहतरीन फ़ॉर्मेट है।" इसे "सहयोगी प्रक्रियाओं (cooperating processes) के बीच संदेश भेजने के लिए एक लचीले फ़ॉर्मेट" के रूप में भी वर्णित किया गया है

साधारण JSON के साथ इसका अंतर ही मुख्य बात है। 10 लाख (a million) रिकॉर्ड का एक JSON एरे (array) एक ही मान होता है: संरचना पूरी होने से पहले रीडर को पूरी चीज़ को पढ़ना पड़ता है। जबकि 10 लाख रिकॉर्ड की एक JSONL फ़ाइल में 10 लाख अलग-अलग मान होते हैं, और प्रत्येक पंक्ति स्वतंत्र होती है।

एक दूसरा, इससे काफी मिलता-जुलता स्पेसिफिकेशन भी है। NDJSON स्पेसिफिकेशन इसके बारे में सीधे तौर पर कहता है: "वर्तमान में स्ट्रीम प्रोटोकॉल के भीतर JSON टेक्स्ट के इंस्टेंस को ट्रांसपोर्ट करने के लिए कोई मानक नहीं है।" इसका बताया गया उपयोग मामला (use case) "TCP या UNIX Pipes जैसे स्ट्रीमिंग प्रोटोकॉल के माध्यम से JSON टेक्स्ट के कई इंस्टेंस डिलीवर करना" है।

JSONL फ़ाइल की संरचना कैसी होती है

तीन आवश्यकताएं

JSON Lines दस्तावेज़ में ठीक तीन आवश्यकताएं सूचीबद्ध हैं। पहली है UTF-8 एन्कोडिंग। इसमें स्वयं JSON से ली गई एक चेतावनी शामिल है: "JSON मानक की तरह ही एक बाइट ऑर्डर मार्क (U+FEFF) शामिल नहीं किया जाना चाहिए।"

दूसरी यह है कि प्रत्येक पंक्ति एक वैध JSON मान होनी चाहिए। पेज में उल्लेख किया गया है कि "सबसे आम मान ऑब्जेक्ट या एरे होंगे, लेकिन किसी भी JSON मान की अनुमति है।" इसके बाद यह उस विशेष स्थिति (edge case) को बताता है जो लोगों को भ्रमित करती है: "null एक वैध मान है लेकिन एक खाली पंक्ति नहीं है।"

तीसरी यह है कि लाइन टर्मिनेटर \n होना चाहिए। Windows लाइन एंडिंग्स अभी भी काम करती हैं। इसका कारण तकनीकी है: "इसका मतलब है कि \r\n भी समर्थित है क्योंकि JSON मानों को पार्स करते समय आस-पास के व्हाइट स्पेस को अप्रत्यक्ष रूप से अनदेखा कर दिया जाता है।"

एक पंक्ति के भीतर क्या नहीं होना चाहिए

यही वह प्रतिबंध है जो इस फ़ॉर्मेट को काम करने योग्य बनाता है। NDJSON स्पेसिफिकेशन इसे एक आवश्यकता के रूप में बताता है: "JSON टेक्स्ट में न्यूलाइन या कैरिज रिटर्न नहीं होने चाहिए।"

सामान्य तौर पर एक JSON मान को इंडेंटेशन के साथ कई पंक्तियों में फैले होने की अनुमति होती है। लाइन-डिलिमिटेड फ़ाइल में ऐसा नहीं हो सकता, क्योंकि न्यूलाइन ही रिकॉर्ड सेपरेटर (विभाजक) है। प्रत्येक रिकॉर्ड को एक ही भौतिक पंक्ति (physical line) पर लिखा जाना चाहिए।

अंतिम पंक्ति, और खाली पंक्तियाँ

दोनों स्पेसिफिकेशन के बीच दो विवरण अलग हैं, और फ़ाइल के रिजेक्ट होने पर दोनों ही मायने रखते हैं।

अंत में आने वाली न्यूलाइन (trailing newline) को ही लें। JSON Lines कहता है कि "फ़ाइल में अंतिम JSON मान के बाद लाइन टर्मिनेटर शामिल करने की दृढ़ता से अनुशंसा की जाती है लेकिन यह आवश्यक नहीं है।"

खाली पंक्तियों पर दोनों स्पेसिफिकेशन असहमत हैं। JSON Lines सख्त है: एक खाली पंक्ति वैध मान नहीं है। NDJSON उदार है, जो अनुमति देता है कि "पार्सर चुपचाप खाली पंक्तियों को अनदेखा कर सकता है," जबकि यह आवश्यक बनाता है कि "इस व्यवहार को प्रलेखित (documented) किया जाना चाहिए।"

एक्सटेंशन और मीडिया प्रकार

नामकरण भी विभाजित है। JSON Lines कहता है कि फ़ाइलों को "फ़ाइल एक्सटेंशन .jsonl के साथ सहेजा जा सकता है।" मीडिया प्रकार पर यह कहता है कि "MIME प्रकार application/jsonl हो सकता है, लेकिन यह अभी तक मानकीकृत नहीं है।" NDJSON कहता है कि मीडिया प्रकार "application/x-ndjson होना चाहिए" और एक्सटेंशन ".ndjson होना चाहिए।"

कम्प्रेशन के लिए, JSON Lines स्ट्रीम कम्प्रेसर की सिफारिश करता है: "स्थान बचाने के लिए gzip या bzip2 की सिफारिश की जाती है, जिसके परिणामस्वरूप .jsonl.gz या .jsonl.bz2 फ़ाइलें बनती हैं।"

त्रुटि संदेश (error message) पढ़ते समय एक छोटा सा नियम जानना उपयोगी है। टेक्स्ट एडिटर पहली पंक्ति को "लाइन 1" कहते हैं। दस्तावेज़ इसका विस्तार करता है: "JSON Lines फ़ाइल में पहले मान को भी 'वैल्यू 1' कहा जाना चाहिए।"

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

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

लॉग और इवेंट फ़ाइलें। इस फ़ॉर्मेट का अपना दस्तावेज़ लॉग फ़ाइलों का नाम लेता है, और इसका कारण यह है कि लिखने वाला बिना कुछ दोबारा लिखे एक समय में एक पंक्ति जोड़ (append) सकता है।

वेयरहाउस लोड। Google का BigQuery दस्तावेज़ इस फ़ॉर्मेट की आधिकारिक स्थिति का एक अच्छा उदाहरण है। यह "Cloud Storage से न्यूलाइन-डिलिमिटेड JSON (ndJSON) डेटा" लोड करने का समर्थन करता है, और इसका फ़ाइल-फ़ॉर्मेट पिकर इस विकल्प को "JSONL (Newline delimited JSON)" के रूप में सूचीबद्ध करता है।

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

मशीन लर्निंग डेटासेट। ट्रेनिंग और इवैल्यूएशन सेट आमतौर पर इसी तरह वितरित किए जाते हैं, क्योंकि एक ट्रेनिंग लूप एक समय में एक रिकॉर्ड पढ़ता है।

इन सब में समान कड़ी स्ट्रीमिंग है। जब फ़ाइल को क्रमिक रूप से (incrementally) तैयार किया जाता है या क्रमिक रूप से उपयोग किया जाता है, तो यह एक स्पष्ट विकल्प बन जाता है।

JSONL बनाम JSON बनाम CSV

	JSONL	JSON	CSV
फ़ाइल की इकाई	प्रति पंक्ति एक मान	पूरी फ़ाइल के लिए एक मान	प्रति पंक्ति एक रो (row)
नेस्टेड डेटा	हाँ, प्रति रिकॉर्ड	हाँ	मूल रूप से नहीं
रिकॉर्ड जोड़ना (Append)	एक पंक्ति जोड़ें	कंटेनर को दोबारा लिखें	एक रो (row) जोड़ें
आंशिक रूप से पढ़ना उपयोगी है	हाँ	शायद ही कभी	हाँ
स्प्रेडशीट में खुलता है	नहीं	नहीं	आमतौर पर
रिकॉर्ड का आकार भिन्न हो सकता है	हाँ	हाँ	नहीं, कॉलम निश्चित होते हैं
एडिटर में मनुष्यों द्वारा पढ़ने योग्य	हाँ, प्रत्येक एक लंबी पंक्ति	हाँ, जब इंडेंट किया गया हो	हाँ

जिस रो (row) से सबसे अधिक आश्चर्य होता है वह नीचे से दूसरी (last-but-one) है। एक ही JSONL फ़ाइल में दो पंक्तियों में अलग-अलग कुंजियाँ (keys) हो सकती हैं। यही बात इस फ़ॉर्मेट को लचीला बनाती है, और इसी वजह से एक साधारण इम्पोर्ट से असमान (ragged) कॉलम बनते हैं।

कॉलम-ओरिएंटेड बाइनरी विकल्प के लिए, Parquet गाइड स्टोरेज के नजरिए से इसी विषय को कवर करता है। सबसे सरल टेबल वाले मामले के लिए, TSV विश्लेषण टैब-सेपरेटेड टेक्स्ट को कवर करता है।

मुख्य लाभ

केवल जोड़कर लिखना (Append-only writing)। एक नया रिकॉर्ड एक नई पंक्ति है। फ़ाइल में पहले की किसी भी चीज़ को बदलने की आवश्यकता नहीं होती है।

स्ट्रीमिंग रीड्स। उपभोक्ता 20 लाखवां (two million) रिकॉर्ड लिखे जाने से पहले ही पहले रिकॉर्ड को प्रोसेस कर सकता है।

विफलता सहनशीलता (Failure tolerance)। एक कटी हुई (truncated) फ़ाइल भी अंतिम पूर्ण पंक्ति तक पढ़ी जा सकती है। जबकि एक कटा हुआ JSON एरे आमतौर पर पूरी तरह से अपठनीय हो जाता है।

नेस्टिंग सुरक्षित रहती है। जिस संरचना को CSV में फ़्लैटन (सपाट) करना पड़ता, वह प्रत्येक रिकॉर्ड के भीतर सुरक्षित रहती है।

शेल-अनुकूल (Shell-friendly)। दस्तावेज़ unix-style टेक्स्ट प्रोसेसिंग और शेल पाइपलाइनों को इसका श्रेय देता है, क्योंकि लाइन-ओरिएंटेड फ़ाइल लाइन-ओरिएंटेड टूल के साथ काम करती है।

वेयरहाउस समर्थन। BigQuery का दस्तावेज़ उस नियम को बताता है जिसे वह लागू करता है: "प्रत्येक JSON ऑब्जेक्ट फ़ाइल में एक अलग पंक्ति पर होना चाहिए।"

JSONL कहाँ मददगार साबित नहीं होता

यह फ़ॉर्मेट ट्रांसपोर्ट और अपेंडिंग (जोड़ने) की समस्या को हल करता है। यह सामग्री के बारे में आपके किसी भी प्रश्न का समाधान नहीं करता है।

कम्प्रेशन एक वास्तविक समझौता (trade-off) है, न कि कोई मुफ्त का लाभ। BigQuery का दस्तावेज़ इसकी लागत के बारे में स्पष्ट है: "यदि आप gzip कम्प्रेशन का उपयोग करते हैं, तो BigQuery समानांतर (parallel) रूप से डेटा नहीं पढ़ सकता है।" यह आगे जोड़ता है कि "कम्प्रेस किए गए JSON डेटा को BigQuery में लोड करना अनकम्प्रेस किए गए डेटा को लोड करने की तुलना में धीमा है।" फ़ॉर्मेट का अपना पेज स्थान बचाने के लिए gzip की सिफारिश करता है। दोनों बातें सच हैं, और वे विपरीत दिशाओं में खींचती हैं।

यह विस्तृत (verbose) भी है। प्रत्येक पंक्ति हर कुंजी (key) के नाम को दोहराती है, इसलिए एक विस्तृत रिकॉर्ड सेट कॉलम वाले फ़ॉर्मेट में उसी डेटा की तुलना में काफी बड़ा होता है।

और यह निरंतरता (consistency) के बारे में कुछ नहीं कहता। विभिन्न आकारों वाले रिकॉर्ड की अनुमति है, जिसका अर्थ है कि कोई फ़ील्ड बिना किसी अमान्यता के फ़ाइल के बीच में ही चुपचाप दिखना बंद हो सकता है।

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

यही व्यावहारिक अंतर है। व्यावसायिक उपकरण (Business tooling) रो और कॉलम की अपेक्षा करते हैं, और एक .jsonl फ़ाइल उस तरह से नहीं खुलेगी जैसे कोई CSV खुलती है।

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

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

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

निष्कर्ष

JSONL एक नियम वाला टेक्स्ट फ़ॉर्मेट है: प्रति पंक्ति एक पूर्ण JSON मान, और मान के भीतर कोई न्यूलाइन नहीं। यह नियम अपेंडेबिलिटी (जोड़ने की क्षमता), स्ट्रीमिंग और आंशिक-पठन सहनशीलता प्रदान करता है, यही कारण है कि लॉग और वेयरहाउस लोड डिफ़ॉल्ट रूप से इसका उपयोग करते हैं।

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

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

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

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

इसका उपयोग रिकॉर्ड स्ट्रीम के लिए किया जाता है: लॉग फ़ाइलें, इवेंट एक्सपोर्ट, वेयरहाउस लोड और मशीन लर्निंग डेटासेट। इस फ़ॉर्मेट का दस्तावेज़ विशेष रूप से लॉग फ़ाइलों और शेल पाइपलाइनों का नाम लेता है। सामान्य कारक यह है कि रिकॉर्ड एक समय में एक ही लिखे या पढ़े जाते हैं।

JSONL और NDJSON में क्या अंतर है?

वे अलग-अलग कागजी कार्रवाई के साथ एक ही विचार का वर्णन करते हैं। JSON Lines .jsonl एक्सटेंशन का उपयोग करता है और उल्लेख करता है कि application/jsonl अभी तक मानकीकृत नहीं है। NDJSON .ndjson और application/x-ndjson निर्दिष्ट करता है, और यह पार्सर को खाली पंक्तियों को अनदेखा करने की अनुमति देता है।

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

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

JSONL में एक रिकॉर्ड कई पंक्तियों में क्यों नहीं फैल सकता?

क्योंकि न्यूलाइन कैरेक्टर ही रिकॉर्ड सेपरेटर (विभाजक) है। NDJSON स्पेसिफिकेशन बताता है कि "JSON टेक्स्ट में न्यूलाइन या कैरिज रिटर्न नहीं होने चाहिए।" इसलिए प्रिटी-प्रिंटेड (pretty-printed) JSON को प्रति रिकॉर्ड एक पंक्ति में समेटना पड़ता है।

क्या JSONL फ़ाइल में खाली पंक्ति की अनुमति है?

दोनों स्पेसिफिकेशन अलग हैं। JSON Lines बताता है कि "null एक वैध मान है लेकिन एक खाली पंक्ति नहीं है।" NDJSON पार्सर को चुपचाप खाली पंक्तियों को अनदेखा करने की अनुमति देता है, बशर्ते कि उस व्यवहार को प्रलेखित (documented) किया गया हो।