NDJSON को TSV में बदलें

देखिए किसी इवेंट रिकॉर्ड में असल में क्या है। क्वेरी स्ट्रिंग वाला रिक्वेस्ट पथ। User agent, जो कॉमा और कोष्ठकों से भरा होता है। किसी मान को उद्धृत करता error message। डाक पता। इसे CSV में भेजिए और हर पंक्ति का बड़ा हिस्सा उद्धरण चिह्न में लिपट जाता है, क्योंकि डिलीमीटर लगभग हर लाइन में डेटा के भीतर आता है।

Tab इन मानों के भीतर लगभग कभी नहीं आते, तो ज़्यादातर फ़ील्ड सादे लिखे जाते हैं और फ़ाइल स्थानीय रहती है — कॉलम तीन सच में दूसरे और तीसरे tab अक्षर के बीच है। यही वह गुण है जिसके बारे में बाक़ी पेज है, और यही वह गुण है जो मुट्ठी भर फ़ील्ड चुपचाप छीन सकते हैं।

यह जानना सटीक तौर पर ज़रूरी है कि writer क्या करता है, क्योंकि tab-separated फ़ाइल की पूरी अपील यही है कि उसे पढ़ने वाले टूल सादे हो सकते हैं। tab रखने वाला मान दोहरे उद्धरण चिह्न में लपेटा जाता है। दोहरा उद्धरण चिह्न रखने वाला मान भी लपेटा जाता है, भीतरी उद्धरण दोहराए जाते हैं। बाक़ी सब, कॉमा समेत, जैसा है वैसा लिखा जाता है।

यह RFC 4180 का रिवाज़ है, कॉमा की जगह tab के साथ, और यह tab-separated values की IANA परिभाषा नहीं है, जो फ़ील्ड के भीतर tab को मना करती है, उसे escape नहीं करती। व्यावहारिक नतीजा यह है कि `cut -f4` और `awk -F$'\t'` सही रहते हैं जब तक किसी log message में tab न आ जाए।

कॉलम फ़ाइल में कहीं भी दिखी हर कुंजी का मिलन हैं, जिस क्रम में हर कुंजी पहली बार दिखी उसी में। यह उस स्रोत के लिए सही जवाब है जहाँ कुछ भी दूसरी लाइन को पहली की कुंजियाँ रखने पर मजबूर नहीं करता, और यह इस बदलाव को स्वचालित करने से पहले समझने लायक़ सबसे ज़रूरी बात है।

इसका मतलब है कॉलम क्रम डेटा का गुण है, फ़ॉर्मेट का नहीं। ऐसा रात का एक्सपोर्ट जिसमें आज पहला error रिकॉर्ड लाइन 12 पर आया और कल लाइन 40,000 पर, दो फ़ाइलें देता है जिनके कॉलम अलग क्रम में हैं। जो पाइपलाइन नाम से पढ़ती है वह ठीक है; जो स्थिति से पढ़ती है वह दूसरे दिन ग़लत है।

हल यह है कि फ़ाइल को तय न करने दिया जाए। बदलने से पहले रिकॉर्ड को तय कुंजी सेट पर प्रोजेक्ट कीजिए — `jq -c '{ts, level, service, msg}'` हर लाइन को उसी क्रम में वही चार कुंजी देता है, और फिर बदलाव के पास सिर्फ़ एक मुमकिन कॉलम बनावट रहती है।

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

बनावट वाले लॉग नेस्ट करते हैं — method और path वाला `request` ऑब्जेक्ट, पहचान वाला `user` ऑब्जेक्ट, trace id वाला `context` ब्लॉक। हर पत्ते को उसके पथ के नाम का कॉलम मिलता है: `request.method`, `user.id`, `context.trace_id`।

कॉलम नाम में डॉट `cut` और `awk` के लिए हानिरहित है, जो हेडर कभी नहीं देखते, और बाक़ी हर जगह अजीब है: SQL में इसे quoting चाहिए, और ज़्यादातर loader में यह वैध पहचानकर्ता नहीं। अगर TSV टेबल में जा रही है, प्रोजेक्शन के दौरान नाम बदल दीजिए, बाद में नहीं।

PostgreSQL को ख़ास ध्यान चाहिए, क्योंकि इसका डिफ़ॉल्ट `COPY` text फ़ॉर्मेट backslash escape इस्तेमाल करता है, उद्धरण चिह्न नहीं, और quote किए फ़ील्ड को शब्दशः पढ़ेगा, उद्धरण चिह्न समेत। जो लिखा गया उससे मेल खाता रूप है `\copy events FROM 'out.tsv' WITH (FORMAT csv, DELIMITER E'\t', HEADER true)`।

DuckDB इसे `read_csv('out.tsv', delim='\t', header=true)` से पढ़ता है और सैंपल से टाइप अंदाज़ता है, जो सुविधाजनक है और यही वजह भी है कि पहचान संख्या का कॉलम अपने शुरुआती शून्य खो सकता है। SQLite के `.import --csv` को पहले `.separator "\t"` सेट करना चाहिए।

JSON का null और JSON की ख़ाली स्ट्रिंग दोनों दो tab के बीच कुछ नहीं बनते, और बाद में उन्हें अलग करने का कोई तरीक़ा नहीं। यह writer की लापरवाही नहीं — delimited टेक्स्ट फ़ाइल में उन्हें रखने के लिए तीसरी हालत ही नहीं।

यह मायने रखता है या नहीं यह आपके सवाल पर निर्भर करता है। कितने इवेंट में `user_id` नहीं था यह गिनना, कितने में ख़ाली `user_id` था यह गिनने से अलग सवाल है, और इस बदलाव के बाद दोनों एक ही जवाब देते हैं। अगर फ़र्क़ मायने रखता है, बदलने से पहले इसे कोड करें, या Parquet पर भेजें जहाँ null असली हालत है।

आम तौर पर पहले से कम। स्रोत की हर लाइन अपनी कुंजी के नाम दोहराती है; TSV उन्हें हेडर में एक बार लिखता है और फिर सिर्फ़ मान, तो सँकरा रिकॉर्ड सेट अक्सर साफ़ सिकुड़ता है। चौड़ा, बिखरा हुआ उल्टी दिशा में जाता है।

मुफ़्त सीमा प्रति फ़ाइल 100 MB है और कॉलम तय होने से पहले पूरा एक्सपोर्ट रिकॉर्ड में पढ़ा जाता है, तो सीमा से पहले मेमोरी टकराती है। NDJSON किसी भी लाइन सीमा पर सुरक्षित रूप से बँटता है, तो `split -l 500000` ऐसी फ़ाइलें देता है जो अलग-अलग साफ़ बदलती हैं — पर बँटी फ़ाइलें अलग बदलने पर कॉलम क्रम पर असहमत हो सकती हैं।

अगर कोई इंसान इसे खोलने वाला है, इसे CSV या XLSX भेजिए — स्प्रेडशीट बिना बताए CSV संभाल लेती है, और वर्कबुक पहचान कॉलम को टेक्स्ट रखता है। अगर यह किसी वेयरहाउस में जा रहा है या रखा जाना है, Parquet छोटा, टाइप्ड है और इसमें कॉलम-क्रम की समस्या बिल्कुल नहीं।

TSV ठीक एक हालत में अपनी जगह कमाता है: गंतव्य कोई प्रोग्राम है जो किसी अक्षर पर बाँटता है, और आप चाहते हैं फ़ाइल `head` से पढ़ने लायक़ रहे कमांड बनाते समय। यह "मुझे Excel में चाहिए" जैसा नहीं है।

सादी JavaScript इसी टैब में। कोई अपलोड नहीं, कोई इंजन डाउनलोड नहीं, कोई अकाउंट नहीं, कोई रोज़ाना सीमा नहीं — और नेटवर्क टैब यह पुष्ट करने का तरीक़ा है, इस वाक्य पर भरोसा करने की बजाय।

उत्पादन इवेंट एक्सपोर्ट वह सामग्री है जिसके लिए यह जोड़ी बनी है, और वे IP पते, session पहचानकर्ता, request पथ और user agent ढोते हैं। किसी होस्टेड कन्वर्टर को एक देना किसी तीसरे पक्ष को डेटा ट्रांसफ़र है, कन्वर्टर चाहे जो वादा करे।