mikaio.dev/freetools

Parquet থেকে CSV কনভার্টার

কিছু ইনস্টল না করেই Apache Parquet ফাইল খুলুন এবং CSV-তে রূপান্তর করুন। ফাইলটি ব্রাউজার ট্যাবের ভিতরেই পড়া হয় — এটি আপনার ডিভাইস ছাড়ে না, তাই ইন্টারনেট বন্ধ থাকলেও কাজ চলে।

ফাইল স্থানীয়ভাবে পড়া হয়। আপলোড নেই, সার্ভার নেই, ট্র্যাকিং নেই।

এই কনভার্টারটি কী করে

Apache Parquet সেই ফরম্যাট যা আজকাল প্রায় প্রতিটি ডেটা পাইপলাইন লেখে: কলাম-ভিত্তিক, সংকুচিত, বাইনারি, অ্যানালিটিক্স ইঞ্জিনের জন্য তৈরি। যন্ত্রের জন্য চমৎকার, মানুষের চোখের জন্য অকেজো। টেক্সট এডিটরে খোলা যায় না, স্প্রেডশিটে কাজ করা সহকর্মীকে সরাসরি পাঠানো যায় না, কোনো টিকিটে পেস্টও করা যায় না। CSV ঠিক উল্টো: বিশ্লেষণের জন্য আনাড়ি, অথচ সর্বত্র পড়া যায়।

এই পাতাটি দুই দিককে সবচেয়ে সরাসরি উপায়ে জোড়া দেয়। আপনি ডিস্ক থেকে একটি .parquet ফাইল বেছে নেন, পাতা সেটি ডিকোড করে, কত সারি ও কত কলাম পেল তা জানায়, একটি প্রিভিউ দেখায় এবং ডাউনলোডের জন্য CSV তৈরি করে দেয়। কোনো অ্যাকাউন্ট নেই, সারি ধরে অপেক্ষা নেই, আপলোডের প্রগতি বার নেই — কারণ পুরো প্রক্রিয়ায় কোনো সার্ভারই যুক্ত হয় না।

শেষ কথাটিই এই টুল থাকার কারণ। বেশিরভাগ অনলাইন Parquet কনভার্টার আসলে একটি ফর্ম, যা আপনার ফাইল ব্যাকএন্ডে পাঠিয়ে দেয়। ফাইলে যদি গ্রাহকের রেকর্ড, বেতন, রোগীর শনাক্তকারী কিংবা ডেটা নীতির আওতাধীন অন্য কিছু থাকে, তবে ওই পাঠানোটাই মূল সমস্যা। এখানে রূপান্তর মানে আপনার ট্যাবে চলা JavaScript, যা ফাইল বেছে নেওয়ার মুহূর্তে ব্রাউজার পাতাকে যে বাইটগুলো দিয়েছে সেগুলোই পড়ে।

চার ধাপে ব্যবহার

  1. ফাইল ফিল্ডে আপনার .parquet ফাইল বেছে নিন। তার আগে কিছুই ঘটে না।
  2. বিভাজক বেছে নিন। কমা ডিফল্ট; যেসব অঞ্চলে কমা দশমিক চিহ্ন সেখানে সাজানো স্প্রেডশিটের জন্য সেমিকোলন ভালো; ট্যাব দিয়ে তৈরি TSV বেশিরভাগ স্প্রেডশিট প্রোগ্রামে পরিষ্কারভাবে বসে যায়।
  3. ঠিক করুন প্রথম সারিতে কলামের নাম থাকবে কি না। হেডার চেকবক্স আগে থেকেই চালু, আর সেটি বদলালে আউটপুট সঙ্গে সঙ্গে নতুন করে তৈরি হয়, ফাইল আবার পড়ার দরকার হয় না।
  4. প্রিভিউ দেখে CSV ডাউনলোড চাপুন। পাতা হালকা রাখতে প্রিভিউতে প্রথম ২০০ সারি দেখানো হয়; ডাউনলোড করা ফাইলে Parquet-এর সব সারি থাকে।

রূপান্তরের পর বিভাজক বা হেডার বদলালে ফাইল আবার ডিস্ক থেকে পড়া হয় না। ডিকোড হওয়া টেবিলটি ট্যাবের মেমরিতে থাকে, তাই কয়েক লক্ষ সারিতেও এসব বদল তাৎক্ষণিক।

Parquet কীভাবে টেবিল রাখে, আর রূপান্তর কেন সহজ নয়

CSV হলো সারির একটি ধারা। Parquet ঠিক উল্টোটা করে: প্রতিটি কলাম আলাদা করে রাখে, row group নামের ব্লকে; আর একটি row group-এর ভিতরে কলাম থাকে কয়েকটি পেজ দিয়ে গড়া chunk-এ। প্রতিটি পেজ সংকুচিত হতে পারে, আর ভিতরের মানগুলো কয়েক রকম ভিন্ন উপায়ে এনকোড হতে পারে।

তাই এটি পড়া মানে কয়েকটি স্তর খুলে ফেলা:

সব ঠিক চললে এসবের কিছুই গুরুত্বপূর্ণ নয়; গুরুত্বপূর্ণ হয় যখন কিছু ভুল হয়। ডিকোডার প্রতিটি স্তর বোঝে বলেই অসমর্থিত ফাইলে সে কম্প্রেশন, এনকোডিং বা নেস্টিং নিয়ে সুনির্দিষ্ট বার্তা দেয়, নিঃশব্দে নষ্ট হওয়া CSV নয়।

সমাধান করা উদাহরণ: কোন মান কেমন দেখাবে

তিনটি Parquet ধরনের CSV-তে সরাসরি প্রতিরূপ নেই, তাই ঠিক কী লেখা হয় তা জেনে রাখা ভালো।

তারিখের কলাম। DATE ধরন ১৯৭০ সালের ১ জানুয়ারি থেকে দিন গোনার একটি ৩২-বিট সংখ্যা রাখে। জমা থাকা সংখ্যা যদি 19723 হয়, তবে যুগ শুরুর ১৯৭২৩ দিন পরে আসে ২০২৪ সালের ১ জানুয়ারি, আর CSV ঘরে লেখা হয় 2024-01-01। কোনো টাইমজোন প্রয়োগ হয় না, কারণ তারিখে সরানোর মতো কোনো সময় নেই।

মাইক্রোসেকেন্ড টাইমস্ট্যাম্প। মাইক্রোসেকেন্ড নির্ভুলতার TIMESTAMP কলাম যুগ থেকে মাইক্রোসেকেন্ড গোনার ৬৪-বিট সংখ্যা রাখে। ধরুন মান 1704112215123456। ১,০০০,০০০ দিয়ে ভাগ করলে পাওয়া যায় 1704112215 পূর্ণ সেকেন্ড, অর্থাৎ ২০২৪ সালের ১ জানুয়ারি ১২:৩০:১৫ UTC, আর অবশিষ্ট থাকে 123456 মাইক্রোসেকেন্ড। ঘরে লেখা হয় 2024-01-01 12:30:15.123456। ভগ্নাংশের শেষের শূন্যগুলো ছেঁটে ফেলা হয়, তাই ঠিক সেকেন্ডে পড়া টাইমস্ট্যাম্প দশমিক অংশ ছাড়াই লেখা হয়।

decimal কলাম। DECIMAL(12,2) কলাম একটি পূর্ণসংখ্যা ও একটি scale হিসেবে রাখা হয়। পূর্ণসংখ্যা 1230 আর scale 2 মানে 12.30, আর সেটিই আক্ষরিকভাবে 12.30 লেখা হয়। এই কারণেই আর্থিক কলাম কখনো ফ্লোটের মধ্য দিয়ে নেওয়া উচিত নয়: টেক্সট সঠিক মানও ধরে রাখে, schema-র প্রতিশ্রুত দশমিক ঘরের সংখ্যাও ধরে রাখে।

বুলিয়ান লেখা হয় truefalse, শূন্য মান হয়ে যায় ফাঁকা ঘর, আর যেসব বাইনারি কলাম বৈধ UTF-8 নয় সেগুলো base64-তে লেখা হয়, যাতে কাঁচা বাইট CSV-র গঠন ভেঙে না দেয়।

অফলাইন কনভার্টার কোথায় কাজে আসে

সবচেয়ে স্পষ্ট ক্ষেত্র গোপনীয়তা: ব্যবহারকারীর রেকর্ডের একটি রপ্তানি, যা শেয়ার্ড ড্রাইভের কাছে যাওয়ার আগে আপনি একবার দেখে নিতে চান। কিছুই ল্যাপটপ ছাড়ে না, তাই কোনো নীতি বাঁকাতে হয় না।

দ্বিতীয় ক্ষেত্র হলো ঝামেলা। সহকর্মী একটি Parquet নমুনা পাঠালেন, আপনার তিনটি কলাম মিলিয়ে দেখা দরকার, অথচ পাঁচ মিনিট পরে মুছে ফেলা ফাইলের জন্য Python আর PyArrow বসানো অযৌক্তিক খরচ। একটি ট্যাব খোলা নয়।

তৃতীয় ক্ষেত্র সেই যন্ত্র যা বদলানোর অধিকার আপনার নেই: তালাবদ্ধ অফিস ল্যাপটপ, ক্লায়েন্টের কম্পিউটার, ল্যাবের মেশিন যেখানে প্যাকেজ বসে না। ব্রাউজার সেখানে আগে থেকেই আছে।

চতুর্থ ক্ষেত্র শেখানো। একই টেবিল প্রথমে অস্বচ্ছ বাইনারি খণ্ড, পরে সাধারণ টেক্সট হিসেবে দেখলে কলাম-ভিত্তিক আর সারি-ভিত্তিক সংরক্ষণের পার্থক্য এমনভাবে ধরা দেয়, যা কোনো ছক সহজে পারে না।

সাধারণ ভুল ও তা এড়ানোর উপায়

স্প্রেডশিটে CSV খুলে একটিমাত্র বিশাল কলাম দেখা। আপনার প্রোগ্রাম তার ভাষা-সেটিংয়ের বিভাজক আশা করে। সেমিকোলন বিকল্প দিয়ে ফাইলটি আবার তৈরি করুন, অথবা ইমপোর্ট ডায়ালগে বিভাজক স্পষ্ট করে বলুন।

লম্বা সংখ্যাসূচক শনাক্তকারী বৈজ্ঞানিক রূপে বদলে যাওয়া। এটি স্প্রেডশিটের কাণ্ড, CSV-র নয়। ফাইলে অঙ্কগুলো অক্ষত আছে; প্রোগ্রাম সেগুলো ফ্লোট হিসেবে দেখানোর সিদ্ধান্ত নিয়েছে। কলামটি টেক্সট হিসেবে ইমপোর্ট করুন।

স্থানীয় সময় আশা করা। টাইমস্ট্যাম্প UTC-তে লেখা হয়। Parquet সাধারণত সেগুলোকে একটি মুহূর্ত হিসেবে রাখে, আর আপনার যন্ত্র কাকতালীয়ভাবে যে টাইমজোনে আছে সেখানে বদলে নিলে প্রতিটি মান নিঃশব্দে বদলে যেত। দরকার হলে পরে সজ্ঞানে সরিয়ে নিন।

নেস্টেড রপ্তানি দেওয়া। struct, list বা map কলামযুক্ত ফাইল বাতিল হয়। আগে pandas.json_normalize, Polars-এর unnest, বা পাতা-ফিল্ড বেছে নেওয়া DuckDB কোয়েরি দিয়ে সমতল করুন, সমতল Parquet লিখুন, তারপর সেটি রূপান্তর করুন।

সীমাবদ্ধতা: কখন এটি সঠিক টুল নয়

এটি পুরো ফাইল মেমরিতে পড়ে, তাই কয়েকশো মেগাবাইটের বেশি বড় রপ্তানি DuckDB বা row group ধরে ধরে স্ট্রিম করা ছোট স্ক্রিপ্টে ভালো চলে। Zstd, Brotli ও LZ4 কম্প্রেশন অর্ধেক ডিকোড হওয়ার বদলে বাতিল হয়; এমন ফাইল Snappy বা Gzip দিয়ে আবার লিখুন। এনক্রিপ্ট করা Parquet ইচ্ছাকৃতভাবেই সমর্থিত নয়। নেস্টেড schema-ও পরিসরের বাইরে, কারণ লিস্ট কলামকে CSV-র একটি ঘরে গুটিয়ে ফেলা আপনার ডেটা নিয়ে নেওয়া সিদ্ধান্ত, যা সাধারণ কনভার্টারের নিঃশব্দে নেওয়া উচিত নয়।

গোপনীয়তা

পাতায় কোনো আপলোড কোড নেই, আপনার ফাইল নিয়ে কোনো অ্যানালিটিক্স নেই, রূপান্তরের সময় কোনো নেটওয়ার্ক কলও হয় না। ফাইলটি ব্রাউজারের নিজস্ব ফাইল ইন্টারফেস দিয়ে পড়া হয় এবং ট্যাবেই ডিকোড হয়। প্রতিশ্রুতির বদলে প্রমাণ চাইলে: পাতা লোড করুন, ইন্টারনেট বিচ্ছিন্ন করুন, তারপর একটি ফাইল রূপান্তর করুন। ফল হুবহু একই থাকবে, কারণ তারের অন্য প্রান্তে কখনো কিছু ছিলই না।

Parquet থেকে CSV — সাধারণ প্রশ্ন

আমার ডেটা কি সত্যিই কোথাও যায় না?
ঠিক তাই। কনভার্টারটি সাধারণ JavaScript, যা ফাইল ফিল্ডে বেছে নেওয়া বাইটগুলো পড়ে পাতার ভিতরেই ডিকোড করে। কোনো আপলোড নেই, কোনো API কল নেই, আপনার ডেটা নিয়ে কোনো অ্যানালিটিক্স নেই। পাতা লোড হওয়ার পর ইন্টারনেট বন্ধ করে দিলেও টুলটি চলবে — নিজে যাচাই করার সবচেয়ে সহজ উপায় এটাই।
কোন ধরনের Parquet ফাইল চলে?
pandas, PyArrow, Polars, DuckDB ও Spark-এর মতো প্রচলিত টুলে লেখা সমতল টেবিল। কম্প্রেশনবিহীন, Snappy ও Gzip পেজ ডিকোড হয়, সেই সঙ্গে PLAIN, ডিকশনারি, RLE, delta ও byte-stream-split এনকোডিং এবং ডেটা পেজ v1 ও v2। Zstd, Brotli, LZ4 ও এনক্রিপ্ট করা ফাইল ভুল ফল না দিয়ে স্পষ্ট বার্তা দিয়ে বাতিল হয়।
নেস্টেড কলামের কী হয়?
সেগুলো ইচ্ছাকৃতভাবেই বাতিল করা হয়। struct, list বা map কলামের একক স্বাভাবিক CSV রূপ নেই, আর চুপচাপ একটি বেছে নিলে ডেটা নষ্ট হবে। আগে pandas, Polars বা DuckDB-তে গঠনটি সমতল করুন, সমতল Parquet লিখুন, তারপর এখানে রূপান্তর করুন।
তারিখ, টাইমস্ট্যাম্প ও decimal কীভাবে লেখা হয়?
তারিখ YYYY-MM-DD আকারে আসে। টাইমস্ট্যাম্প UTC-তে YYYY-MM-DD HH:MM:SS আকারে আসে এবং কলামে থাকা মিলিসেকেন্ড, মাইক্রোসেকেন্ড বা ন্যানোসেকেন্ড অঙ্ক অক্ষুণ্ণ থাকে। decimal কলাম টেক্সট হিসেবে নিজের সঠিক দশমিক ঘর ধরে রাখে, তাই 12.30 ঠিক 12.30-ই থাকে, গোল করা ফ্লোট হয় না। শূন্য মান ফাঁকা ঘর হয়ে যায়।