أحمد حايس
الرئيسيةمن أناالدوراتالمدونةالعروض
أحمد حايس

دورات عربية متخصصة في التقنية والبرمجة والذكاء الاصطناعي.

المنصة مبنية على الوضوح، التطبيق، والنتيجة النافعة: شرح مرتب يساعدك تفهم الأدوات، تكتب كودًا أفضل، وتستخدم الذكاء الاصطناعي بوعي داخل العمل الحقيقي.

تعلم أسرعوصول مباشر للدورات والمسارات من الموبايل.
تنقل أوضحالروابط الأساسية والدعم في مكان واحد بدون تشتيت.

المنصة

  • الرئيسية
  • من أنا
  • الدورات
  • العروض
  • المدونة

الدعم

  • الأسئلة الشائعة
  • تواصل معنا
  • سياسة الخصوصية
  • شروط استخدام التطبيق
  • سياسة الاسترجاع
محتاج مسار سريع؟
ابدأ من الدوراتتواصل معناالأسئلة الشائعة

© 2026 أحمد حايس. جميع الحقوق محفوظة.

الرئيسيةالدوراتالعروضالمدونةالدخول

اعمل محول CSV إلى Parquet بـ DuckDB في 15 دقيقة

📅 ٢٦ أبريل ٢٠٢٦⏱ 4 دقائق قراءة
اعمل محول CSV إلى Parquet بـ DuckDB في 15 دقيقة

اعمل محول CSV إلى Parquet بـ DuckDB في 15 دقيقة

مستوى القارئ: متوسط

هتطلع من المقال بأداة CLI بسيطة تحول ملفات CSV الكبيرة إلى Parquet، بدل ما كل تحليل يبدأ بانتظار طويل وذاكرة بتزيد بدون داعي.

المشكلة باختصار

لو عندك export يومي من نظام مبيعات أو CRM بحجم 2GB إلى 10GB بصيغة CSV، فالطريقة الشائعة إنك تفتحه كل مرة بـ Python أو Excel أو BI tool. الطريقة دي بتفشل لما التحليل يتكرر. كل قراءة بتعيد parsing للنص، وكل عمود بيتقرأ حتى لو محتاج عمودين فقط.

Parquet بيحل جزء كبير من المشكلة لأنه format عمودي ومضغوط. يعني لو الاستعلام محتاج customer_id وtotal فقط، الأداة تقدر تقرأ الأعمدة دي بدل الملف كله. الافتراض هنا إن بياناتك جدولية، وبتتقرأ للتحليل أكثر من مرة، ومش محتاج تعدل الصفوف واحد واحد.

مخطط يوضح انتقال ملفات CSV كبيرة عبر DuckDB CLI إلى ملفات Parquet جاهزة للتحليل

الفكرة بمثال واضح

ركز في السيناريو ده: عندك ملف orders_2026_04.csv حجمه 5GB، وفيه 35 عمود. فريق التحليل بيحتاج يقرأه 20 مرة في الأسبوع عشان يجرب queries مختلفة. لو قراءة CSV الواحدة بتاخد 95 ثانية، فأنت بتحرق حوالي 31 دقيقة أسبوعيًا في القراءة فقط. بعد تحويله إلى Parquet، نفس القراءة التحليلية قد تنزل إلى 14 ثانية في جهاز مناسب. الرقم هنا تقديري لكنه واقعي كاتجاه: المكسب الحقيقي يأتي من الضغط وقراءة الأعمدة المطلوبة فقط.

المفهوم العلمي بالظبط: CSV نصي row-based. كل صف لازم يتقرأ ويتفسر من جديد. Parquet columnar. يخزن بيانات كل عمود في chunks مع metadata وضغط. DuckDB يقرأ Parquet بكفاءة من غير ما تحتاج تشغل سيرفر قاعدة بيانات.

جهز المشروع

هنعمل سكربت Bash صغير اسمه csv2parquet. لو على Windows، شغله من Git Bash أو WSL. ولو عايز نسخة PowerShell، نفس أوامر DuckDB الأساسية هتفضل كما هي.

  1. ثبت DuckDB CLI من صفحة التثبيت الرسمية.
  2. اعمل فولدر data/raw للـ CSV وفولدر data/parquet للنتيجة.
  3. اكتب السكربت بحيث يستقبل input وoutput من command line.
Bash
mkdir -p data/raw data/parquet bin

cat > bin/csv2parquet <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

INPUT="${1:?usage: csv2parquet input.csv output.parquet}"
OUTPUT="${2:?usage: csv2parquet input.csv output.parquet}"

if [ ! -f "$INPUT" ]; then
  echo "Input file not found: $INPUT" >&2
  exit 1
fi

duckdb -c "
COPY (
  SELECT *
  FROM read_csv_auto('$INPUT', sample_size=200000, all_varchar=false)
) TO '$OUTPUT'
(FORMAT PARQUET, COMPRESSION ZSTD);
"

duckdb -c "
SELECT count(*) AS rows_count
FROM read_parquet('$OUTPUT');
"
EOF

chmod +x bin/csv2parquet
./bin/csv2parquet data/raw/orders_2026_04.csv data/parquet/orders_2026_04.parquet

الـ sample_size=200000 يخلي DuckDB يفحص عينة أكبر قبل ما يستنتج أنواع الأعمدة. ده يقلل أخطاء النوع في ملفات فيها قيم ناقصة أو أرقام متأخرة. الـ trade-off هنا إن أول تحويل أبطأ قليلًا، مقابل schema أكثر ثباتًا.

تحقق إن التحويل يستاهل

بدل ما تفترض إن Parquet أسرع، قيس. استخدم time على قراءة CSV وقراءة Parquet لنفس السؤال. المثال التالي يقارن مجموع المبيعات حسب اليوم.

Bash
time duckdb -c "
SELECT order_date, sum(total) AS revenue
FROM read_csv_auto('data/raw/orders_2026_04.csv')
GROUP BY order_date
ORDER BY order_date;
"

time duckdb -c "
SELECT order_date, sum(total) AS revenue
FROM read_parquet('data/parquet/orders_2026_04.parquet')
GROUP BY order_date
ORDER BY order_date;
"

في حالة ملف 5GB على SSD عادي، نتيجة مقبولة إن CSV يأخذ 60 إلى 120 ثانية، وParquet يأخذ 8 إلى 20 ثانية لنفس query. لو الفرق أقل من 20%، راجع هل الاستعلام بيقرأ أغلب الأعمدة فعلًا، أو هل الملف صغير أصلاً.

رسم أعمدة يقارن زمن قراءة CSV بقراءة Parquet لملف تحليلي حجمه 5GB

حسّن السكربت بدون تعقيد زائد

أفضل طريقة تبدأ بها هي تحويل كل export مرة واحدة بعد وصوله، ثم تجعل أدوات التحليل تقرأ Parquet فقط. لو عندك ملفات يومية، خزنها بهذا الشكل: data/parquet/orders/date=2026-04-26/orders.parquet. التقسيم حسب التاريخ يساعد DuckDB والأدوات الأخرى على تجاهل أيام لا تخص الاستعلام.

لكن لا تحول كل شيء بشكل أعمى. Parquet يكسبك سرعة قراءة وضغط أفضل، لكنه يضيف خطوة build في pipeline. لو التحويل يأخذ 6 دقائق يوميًا ويختصر 40 دقيقة من التحليل الأسبوعي، المكسب واضح. لو الملف 20MB ويتقرأ مرة واحدة في الشهر، أنت بتضيف تعقيد بلا عائد.

متى لا تستخدم هذه الطريقة

  • لو الملف صغير أقل من 50MB ويتقرأ نادرًا.
  • لو البيانات بتتعدل صف بصف وتحتاج updates مستمرة. استخدم قاعدة بيانات بدل ملف Parquet منفرد.
  • لو الـ schema بيتغير بعنف كل يوم، ثبت schema صريح الأول بدل الاعتماد الكامل على read_csv_auto.
  • لو الفريق غير قادر يشغل خطوة تحويل في CI أو cron، ابدأ بقياس يدوي قبل إدخالها في الإنتاج.

مصادر مهمة

  • DuckDB CSV Import
  • DuckDB Parquet Support
  • DuckDB COPY Statement
  • Apache Parquet Documentation

الخطوة التالية

اختار أكبر CSV بيتقرأ عندك أكثر من 3 مرات في الأسبوع، وحوله مرة واحدة بالأمر السابق. القرار العملي: لو قراءة Parquet أسرع بـ 3 مرات على الأقل، انقل التحليل اليومي لها.

هل استفدت من المقال؟

اطّلع على المزيد من المقالات والدروس المجانية من نفس المسار المعرفي.

تصفّح المدونة