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

यहाँ आप CSV को Parquet में बदलते हैं, मुफ़्त और बिना खाते के: फ़ाइल ऊपर छोड़िए और कुछ ही सेकंड में नतीजा डाउनलोड के लिए तैयार मिलेगा। कन्वर्ज़न आपके अपने ब्राउज़र के भीतर होता है, इसलिए फ़ाइल कभी अपलोड नहीं होती। यह Windows, macOS और Linux पर वैसे ही चलता है जैसे iPhone और Android पर, और कनेक्शन काट देने पर भी चलता रहता है।

  • कहाँ चलता है आपके ब्राउज़र में। फ़ाइल कभी अपलोड नहीं होती।
  • बिना नुक़सान कुछ नहीं छोड़ा जाता। CSV में जो था, Parquet में ठीक वही रहता है।
  • फ़ाइल आकार की सीमा हर फ़ाइल 100 MB तक, मुफ़्त, बिना खाते के।

एक बार में 100 फ़ाइलें। फ़ॉर्मेट अलग-अलग हों तो भी चलेगा।

CSV में कोई स्कीमा नहीं होती; Parquet इसे फ़ुटर में रखती है

CSV अपने बारे में जो कुछ जानती है वह बस एक हेडर पंक्ति है — नामों की सूची। यह नहीं बता सकती कि amount दशमलव है या is_active बूलियन। हर औज़ार इसे फिर से अंदाज़ा लगाता है, और हर औज़ार थोड़ा अलग अंदाज़ा लगाता है।

Parquet फ़ाइल अंत में एक फ़ुटर के साथ ख़त्म होती है जिसमें स्कीमा, पंक्तियों की गिनती और प्रति-कॉलम मेटाडेटा होता है। क्वेरी इंजन पहले फ़ुटर पढ़ता है — कुछ किलोबाइट का — और बिना कोई डेटा छुए कॉलम नाम व टाइप बता सकता है।

डिक्शनरी पेज, Snappy, और फ़ाइल का सिकुड़ना

हर कॉलम पर तीन चीज़ें होती हैं और वे साथ मिलकर असर बढ़ाती हैं। मान अपने binary रूप में लिखे जाते हैं, हर कॉलम अलग से Snappy से कंप्रेस होता है, और जिस कॉलम के मान दोहराते हैं वह डिक्शनरी-एनकोड होता है — अलग मान एक बार लिखे जाते हैं, बाक़ी छोटे संख्या-संदर्भ बन जाते हैं।

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

row group और वे statistics जो क्वेरी को पन्ने छोड़ने देते हैं

पंक्तियाँ एक ब्लॉक की बजाय समूहों में लिखी जाती हैं, हर समूह में एक हज़ार से एक लाख पंक्तियों के बीच, अंदर पन्ने एक मेगाबाइट तक सीमित। हर समूह के भीतर हर कॉलम-हिस्सा statistics रखता है।

यही वह असर है जिसे लोग «Parquet तेज़ है» कहते हैं। तारीख़ की सीमा पर फ़िल्टर करने वाली क्वेरी फ़ुटर देखती है, पाती है कि कोई समूह पूरी तरह सीमा से बाहर है, और उसे कभी पढ़ती ही नहीं। CSV में यह किसी हाल में मुमकिन नहीं।

आपके CSV कॉलम अंत में किस टाइप के बनते हैं

टाइप मान से निकाला जाता है, घोषित नहीं किया जाता, क्योंकि स्रोत के पास घोषित करने को कुछ नहीं। हर कॉलम पूरा पढ़ा जाता है: सारे बूलियन BOOLEAN बनते हैं, 32-बिट सीमा के अंदर पूरे नंबर INT32, बाक़ी नंबर DOUBLE, बाक़ी सब स्ट्रिंग।

एक भी अटपटा मान पूरे कॉलम को टेक्स्ट बना देता है, और यह जान-बूझकर है। पहली पंक्ति से टाइप लेना ऐसा कॉलम बना देता जो शुरुआत में नंबर हो और बाद के हर ग़ैर-नंबर मान को चुपचाप null कर दे।

जो कुछ CSV ने पहले ही बिगाड़ दिया था, वह Parquet देखता ही नहीं

यह बदलाव CSV को टाइप-अंदाज़े के साथ पढ़ता है, इसलिए 007 पहले ही सात नंबर बन चुका होता है जब writer कॉलम का टाइप तय कर रहा होता है। इसका दोष Parquet पर मढ़ा जाता है और यह ठीक नहीं — नुक़सान टेक्स्ट-पार्सिंग के क़दम पर होता है।

जोखिम में वे कॉलम हैं जहाँ हिसाब बेमानी होता — पिनकोड, पार्ट नंबर, फ़ोन नंबर, ज़ीरो-पैडेड कुछ भी। अगर एक्सट्रैक्ट आपके नियंत्रण में है, तो उन्हें quoted या prefix के साथ भेजिए ताकि वे स्ट्रिंग बनकर पहुँचें।

व्यवहार में आकार का फ़र्क़ कैसा दिखता है

पचास हज़ार पंक्तियों और छह कॉलम की एक टेबल पर — पहचान, प्रोडक्ट कोड, शहर, मात्रा, क़ीमत और एक फ़्लैग — Parquet आउटपुट 301 KB नापा गया। वही डेटा टैब-सेपरेटेड टेक्स्ट में क़रीब 1.8 MB का था।

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

बदले हुए एक्सट्रैक्ट को DuckDB, pandas या Spark में पढ़ना

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

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

ब्राउज़र टैब में बड़ी CSV की असली सीमा

पूरी टेबल मेमोरी में रखी जाती है — CSV पंक्तियों में पढ़ी जाती है, पंक्तियाँ कॉलम में बदली जाती हैं, फिर कॉलम लिखे जाते हैं। दसियों मेगाबाइट बिना दिक़्क़त बदल जाते हैं, सैकड़ों मेगाबाइट पर टैब पर दबाव पड़ने लगता है।

सचमुच बड़े एक्सट्रैक्ट के लिए सही औज़ार DuckDB है, जो CSV को डिस्क से पढ़कर एक ही स्टेटमेंट में Parquet लिख देता है, फ़ाइल को कभी पूरा मेमोरी में रखे बिना।

कच्चे एक्सट्रैक्ट के लिए स्थानीय बदलाव क्यों मायने रखता है

दोनों हिस्से इसी पेज पर चलते हैं — CSV parser और Parquet writer माँग पर लोड होने वाली लाइब्रेरी हैं, और कोई अनुरोध फ़ाइल कहीं नहीं ले जाता। डेटा प्लेटफ़ॉर्म के लिए जा रही CSV अक्सर पूरी पाइपलाइन का सबसे कम छना हुआ हिस्सा होती है।

यह बातचीत से एक स्तर भी हटा देता है। कोई कतार नहीं, कोई अधिकतम पंक्ति-गिनती नहीं, कोई खाता नहीं — सवाल बस यह है कि फ़ाइल मेमोरी में समाती है या नहीं।

जब डेटा को CSV ही रहना चाहिए

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

यह उस लोड के लिए भी ग़लत लक्ष्य है जो एक बार होता है और फिर फेंक दिया जाता है — लिखने की क़ीमत तभी वसूल होती है जब वही डेटा बार-बार क्वेरी, फ़िल्टर और जोड़ा जाए।

CSV को Parquet में ऐसे बदलें

  1. अपनी CSV फ़ाइल इस पेज पर छोड़ें, या चुनने के लिए दबाएँ।
  2. लक्ष्य के रूप में Parquet चुनें। कन्वर्ज़न आपके ब्राउज़र में होता है और फ़ाइल अपलोड नहीं होती।
  3. तैयार Parquet फ़ाइल डाउनलोड कर लें।

CSV या Parquet: क्या बदलता है

CSV और Parquet की तुलना
CSVParquet
पूरा नामComma-Separated ValuesApache Parquet
फ़ाइल एक्सटेंशन.csv.parquet
मीडिया टाइपtext/csvapplication/vnd.apache.parquet
कंप्रेशनबिना नुक़सान — कुछ छोड़ा नहीं जाता
पहली बार प्रकाशित19722013
प्रकाशकApache Software Foundation
विनिर्देशRFC 4180
लाइसेंसखुला मानकखुला मानक
आज की स्थितिमौजूदामौजूदा
ब्राउज़र में खुलता हैकोई ब्राउज़र नहींकोई ब्राउज़र नहीं
इसकी जगह विचारणीयXLSX, JSONJSON

क्या बचा रहता है

कुछ नहीं खोता। CSV और Parquet — दोनों अपनी सामग्री बिना नुक़सान सँभालते हैं: यह कन्वर्ज़न पैकिंग बदलता है, गुणवत्ता नहीं, और आप इसे दोहरा सकते हैं बिना इस डर के कि नुक़सान जमा होता जाएगा।

नतीजा खोलना

pandas CSV और Parquet — दोनों पढ़ लेता है, इसलिए आप नतीजे को असली फ़ाइल के बग़ल में रखकर देख सकते हैं, बिना दूसरा प्रोग्राम खोले।

कौन-सा फ़ॉर्मेट किस काम के लिए है

CSV 1972 में आया। यह RFC 4180 में तय किया गया है, और अगर फ़ाइल को उस औज़ार से ज़्यादा जीना है जिसने उसे लिखा, तो यह बात क़ीमती है।

Parquet Apache Software Foundation का है और 2013 से चला आ रहा है। pandas, Apache Spark और DuckDB इस फ़ॉर्मेट को पढ़ लेते है।

CSV 1972 में आया और Parquet 2013 में। किसी को सौंपने के लिए आम तौर पर पुराना वाला ज़्यादा सुरक्षित रहता है; नया वाला वही काम कम बाइट में कर देता है।

CSV से Parquet: आम सवाल

क्या मेरी CSV फ़ाइल कहीं अपलोड होती है?

नहीं। यह कन्वर्ज़न पूरी तरह आपके ब्राउज़र में होता है, इसलिए फ़ाइल आपके डिवाइस से बाहर नहीं जाती। आप ख़ुद जाँच सकते हैं: डेवलपर टूल्स का नेटवर्क टैब खोलिए और कुछ बदल कर देखिए। आपको पेज ख़ुद दिखेगा और आँकड़ों तथा विज्ञापन के वे अनुरोध दिखेंगे जिनसे इस सेवा का ख़र्च निकलता है — और एक भी ऐसा अनुरोध नहीं जो आपकी फ़ाइल साथ ले जा रहा हो। इस जोड़ी के पीछे parquet-wasm है, Apache Arrow के पाठक का एक WebAssembly संस्करण; आपका ब्राउज़र इसे एक बार उतारता है और फिर सहेज कर रखता है।

क्या CSV को Parquet में बदलना मुफ़्त है?

हाँ। न खाता, न वॉटरमार्क, और न कोई रोज़ का कोटा जो ख़त्म हो: यह आपकी अपनी मशीन पर चलता है, इसलिए आप जितनी बार चाहें लौट सकते हैं। ब्राउज़र 100 MB तक की फ़ाइलें सँभालता है, एक बार में 100। parquet-wasm आपकी अपनी मशीन पर उतरता है और वहीं चलता है — इसीलिए उस पर कोई गिनती नहीं है।

CSV को Parquet में बदलने पर क्या गुणवत्ता जाती है?

नहीं। Parquet वही सामग्री बिना कुछ फेंके सँभालता है: नतीजा गुणवत्ता में असली फ़ाइल जैसा ही होता है।

क्या CSV से Parquet बिना नुक़सान का है?

कुछ नहीं खोता। CSV और Parquet — दोनों अपनी सामग्री बिना नुक़सान सँभालते हैं: यह कन्वर्ज़न पैकिंग बदलता है, गुणवत्ता नहीं, और आप इसे दोहरा सकते हैं बिना इस डर के कि नुक़सान जमा होता जाएगा।

इन फ़ॉर्मेट के बारे में और