BigQuery تربط SQL وPython بأمر %%bqsql السحري في دفتر واحد

أبرز النقاط

• أمر %%bqsql يلغي الحاجة لنقل البيانات يدوياً بين SQL وPython
• يمكن تشغيل استعلامات BigQuery على DataFrames المحلية مباشرةً
• الميزة متاحة مجاناً عبر BigQuery Sandbox دون بطاقة ائتمان

يجد علماء البيانات ومهندسوها أنفسهم غالباً في مفترق طرق: هل يكتبون استعلامات SQL للاستفادة من قوة محرك BigQuery في معالجة البيانات الضخمة، أم يبقون في بيئة Python بمكتباتها الغنية؟ الإجابة التقليدية كانت مؤلمة: نفّذ الاستعلام، صدّر النتائج إلى DataFrame، عالجها في Python، ثم أعِد كتابتها في جدول مؤقت ليقرأها SQL مجدداً. هذا التنقل المتكرر يستهلك الوقت ويُعقّد سير العمل.

أطلق فريق Google Cloud حلاً جذرياً لهذه المعضلة: أمر %%bqsql السحري ضمن مكتبة BigQuery DataFrames. الفكرة بسيطة لكنها فعّالة: اكتب خلية SQL في دفتر Jupyter، وسيتولى الأمر رفع بيانات pandas المحلية تلقائياً كجداول مؤقتة، ثم تنفيذ الاستعلام على محرك BigQuery، وإعادة النتائج إلى Python — كل ذلك دون سطر كود إضافي لنقل البيانات.

ما المشكلة التي يحلها %%bqsql؟

تخيّل هذا السيناريو المألوف: لديك بيانات محلية في pandas DataFrame، وتريد تطبيق تحويلات معقدة باستخدام SQL لأنها أكثر وضوحاً لهذه المهمة، ثم متابعة التحليل في Python. قبل %%bqsql، كنت مضطراً لكتابة النتائج في جدول مؤقت على BigQuery، ثم قراءتها مجدداً. هذا يعني كوداً إضافياً، وزمن انتظار، واحتمال أخطاء في تحويل الأنماط (schema mapping).

الأمر السحري الجديد يُزيل هذا الاحتكاك: حين تكتب استعلام SQL يشير إلى DataFrame محلية بالاسم، يرفعها BigQuery DataFrames ضمنياً كجدول مؤقت، ينفّذ الاستعلام على محرك BigQuery السحابي، ويُعيد النتيجة إلى بيئة Python مباشرةً. النتيجة: سلسلة معالجة متصلة (chained workflow) تنتقل بسلاسة بين اللغتين.

كيف تبدأ: إعداد البيئة خطوة بخطوة

الخبر السار أن التجربة مجانية بالكامل عبر BigQuery Sandbox، دون الحاجة لبطاقة ائتمان. إليك الخطوات:

• فعّل BigQuery Sandbox من لوحة تحكم Google Cloud، ودوّن معرّف المشروع (Project ID).
• جهّز بيئة Python محلية، أو افتح الدفتر مباشرةً في Colab الذي يأتي ببيئة جاهزة.
• إن اخترت البيئة المحلية، أنشئ بيئة افتراضية (venv) وفعّلها: source ./env/bin/activate
• ثبّت الحزم المطلوبة: pip install --upgrade jupyterlab bigframes python-calamine
• شغّل Jupyter Lab بالأمر jupyter lab، ثم افتح الرابط الظاهر في المتصفح.
• أنشئ دفتراً جديداً أو حمّل الدفتر الجاهز من مستودع BigQuery DataFrames على GitHub.

تحميل البيانات المحلية وتهيئتها

في هذا المثال العملي، سنحلل بيانات القمح من وزارة الزراعة الأمريكية (USDA). نبدأ بتحميلها عبر pandas، وهو السيناريو المعتاد حين تعمل على ملفات محلية أو مصادر خارجية:

نقرأ البيانات باستخدام dtype_backend='pyarrow' لضمان توافق أفضل مع أنماط BigQuery ومعالجة سليمة للقيم الفارغة (NULL). ثم ننظّف أسماء الأعمدة بإزالة الرموز الخاصة مثل / لأن BigQuery يدعم معظم رموز Unicode لكن بعض الرموز تسبب مشاكل. أخيراً، نطبّق فلتراً بسيطاً بلغة Python لحذف الصفوف الناقصة — هذه مرحلة Python الأولى في سلسلة المعالجة.

تفعيل أمر %%bqsql السحري

الخطوة المحورية هي تحميل إضافة bigframes في الدفتر:

%load_ext bigframes

ثم تحديد معرّف المشروع ليعرف BigQuery أين يُنفّذ الاستعلامات (حتى في الطبقة المجانية):

import bigframes.pandas as bpd
bpd.options.bigquery.project = 'your-project-id-here'

ملاحظة: في بيئات BigQuery Studio وColab، تكون الإضافة محمّلة مسبقاً.

تنفيذ استعلامات SQL على بيانات pandas مباشرةً

الآن يأتي السحر الفعلي. بعد تحميل بياناتك في DataFrame اسمها مثلاً full_rows، يمكنك كتابة خلية SQL تشير إليها بالاسم مباشرةً:

%%bqsql
SELECT Year, Production, Imports
FROM full_rows
WHERE Production > 2000
ORDER BY Year DESC

ما يحدث خلف الكواليس: يرفع bigframes البيانات المحلية كجدول مؤقت، يُرسل الاستعلام إلى محرك BigQuery، ويُعيد النتيجة كـ DataFrame جديدة يمكنك متابعة العمل عليها في Python. لا نسخ يدوي، لا جداول وسيطة تديرها بنفسك.

ما الذي يدعمه %%bqsql؟

• DataFrames محلية من pandas (يرفعها تلقائياً كجداول مؤقتة)
• جداول BigQuery الفعلية في مشروعك
• جداول خارجية (External Tables) على Cloud Storage بصيغ Parquet وIceberg وCSV

هذا يعني أنك تستطيع في استعلام واحد دمج بيانات محلية مع جداول سحابية ضخمة، والاستفادة من قدرات BigQuery في المعالجة الموزعة دون مغادرة دفتر Jupyter.

لماذا يهم هذا فرق الهندسة؟

بحسب استطلاعات الصناعة، أكثر من 70% من علماء البيانات يستخدمون Python لغةً أساسية، لكن SQL تبقى اللغة الأكثر شيوعاً للاستعلام عن البيانات المخزنة. الفجوة بينهما كانت مصدر احتكاك يومي: كود مكرر، تحويلات يدوية، أخطاء في الأنماط. أمر %%bqsql يُقلّص هذه الفجوة إلى الحد الأدنى، ما يعني إنتاجية أعلى ووقتاً أقل في السباكة التقنية.

الميزة متاحة الآن في النظام البيئي مفتوح المصدر (Jupyter، pandas، BigFrames)، وليست حكراً على Colab Enterprise. هذا يعني أن فرق DevOps يمكنها دمجها في بيئات التطوير المحلية أو خطوط CI/CD دون تبعية لمنتج مغلق.

الأسئلة الشائعة

هل أمر %%bqsql مجاني؟

نعم، يمكنك استخدامه مع BigQuery Sandbox المجاني دون بطاقة ائتمان، مع مراعاة حدود الاستخدام الموثقة في وثائق Sandbox.

هل يعمل %%bqsql خارج Colab؟

نعم، الميزة متاحة في أي بيئة Jupyter محلية أو سحابية بعد تثبيت حزمة bigframes وتحميل الإضافة.

ما الفرق بين %%bqsql وSQL cells في Colab Enterprise؟

SQL cells ظهرت أولاً في Colab Enterprise، ثم وسّعت Google التجربة للنظام البيئي المفتوح عبر %%bqsql magic الذي يعمل مع Jupyter القياسي.

هل يدعم %%bqsql البيانات الضخمة؟

البيانات المحلية تُرفع كجداول مؤقتة، لذا الحجم محدود بذاكرة الجهاز. لكن يمكنك دمجها مع جداول BigQuery السحابية بحجم بيتابايت في نفس الاستعلام.

كيف أتعامل مع أسماء أعمدة تحتوي رموزاً خاصة؟

أزِل أو استبدل الرموز مثل / و\ قبل الاستعلام، لأن BigQuery يدعم Unicode لكن بعض الرموز تسبب أخطاء تحليل.