انتقل إلى المحتوى الرئيسي

الوحدة 2 — الدفاتر المُدارة وبيئات التطوير

الدفتر هو أوّل شيء يفتحه عالِم البيانات صباحًا وآخر شيء يُغلقه (نظريًّا) مساءً. على Vertex AI، دفتر متروك يعمل ليلة كاملة على وحدة معالجة رسوميّة يُنتِج فاتورة بحجم راتب متدرِّب. هذه الوحدة تُغطّي كيف نُنشئ دفترًا سليمًا، نصله بمصادر البيانات، ونضمن ألّا يعمل حين لا يستعمله أحد.

Workbench مقابل Colab Enterprise​

عائلتان من الدفاتر على Vertex AI:

  • Vertex AI Workbench: آلات JupyterLab كاملة، تشتغل تحت هويّة المستخدم أو حساب خدمة، مع صلاحية sudo على الآلة. مناسبة للتطوير الجدّي: تثبيت مكتبات نظام، أدوات تصحيح، وقت طويل على مجموعة بيانات كبيرة.
  • Colab Enterprise: تجربة Colab المعتادة داخل حدود GCP: تعاون فوريّ بين عدّة مستخدمين على الدفتر نفسه، عزل قصير الأمد، أذونات مُدارة على مستوى المؤسّسة. مناسبة للاستكشاف السريع وورشات العمل.

الفيل الأحمر (كشف الاحتيال) يحتاج مجموعة بيانات كبيرة وتدريبات طويلة: نختار Workbench. سنستعمل Colab Enterprise لاحقًا في الوحدة 10 لعرض نموذج أساس بسرعة أمام غير المتخصّصين.

إنشاء آلة Workbench سليمة​

القاعدة الذهبية: آلة صغيرة بالافتراضيّ، مع خيار الترقية. أغلب العمل يمرّ في التنظيف والاستكشاف؛ لا نحتاج وحدة معالجة رسوميّة أثناء تعديل استعلام SQL أو رسم مخطّط pandas. نحجز الوحدة الرسوميّة للدفعات الحقيقيّة للتدريب.

gcloud workbench instances create fraud-notebook-01 \
  --location=europe-west1-b \
  --machine-type=n1-standard-4 \
  --idle-shutdown \
  --idle-shutdown-timeout=1800 \
  --service-account=sa-training@fraud-detection-lab.iam.gserviceaccount.com

ثلاث ملاحظات على هذا الأمر:

  1. n1-standard-4: أربع أنوية، 15 غيغا ذاكرة — يكفي لpandas على بضعة ملايين سطر. لن نُشغِّل التدريب هنا مباشرة، بل سنُطلقه على تدريب مخصّص (الوحدة 4).
  2. --idle-shutdown-timeout=1800: 30 دقيقة بلا نشاط ⇒ إيقاف تلقائيّ. هذا الخيار وحده يوفّر معظم تكاليف الدفاتر المنسيّة.
  3. --service-account: تعمل الآلة بهويّة sa-training، لا بهويّتك. هذا يعني أنّ استعلامات BigQuery المُشغَّلة من الدفتر تُنسَب إلى الحساب الروبوتيّ، وتعمل مثلما ستعمل تمامًا في خطّ الإنتاج.

النوى المُثبَّتة مسبقًا​

Workbench يقدّم عدّة نوى (kernels) جاهزة، لكلٍّ منها مجموعة مكتبات مُثبَّتة مسبقًا:

  • python3 عامّ
  • tensorflow-cpu.2-15 وTensorFlow مع GPU
  • pytorch.2-3 وPyTorch مع GPU
  • xgboost.1-7
  • r-4-2 للغة R

للفيل الأحمر نستعمل نواة xgboost.1-7: تحتوي pandas وscikit-learn وxgboost وgoogle-cloud-* الأساس. تجنّبُ pip install عند بدء كلّ جلسة يُوفِّر دقائق ومصدر أخطاء نسخيّ.

لتثبيت مكتبات إضافيّة بصورة دائمة، نُنشئ بيئة conda خاصّة تُخزَّن على القرص الدائم:

conda create -n fraud python=3.11 -y
conda activate fraud
pip install "google-cloud-aiplatform>=1.60" \
            "google-cloud-bigquery>=3.20" \
            xgboost pandas scikit-learn pyarrow
python -m ipykernel install --user --name fraud --display-name "Fraud (xgboost)"

النواة الجديدة تظهر في قائمة الاختيار عند فتح دفتر، وتبقى بعد إعادة تشغيل الآلة، لأنّ القرص الدائم لا يُمحى عند الإيقاف.

الوصول إلى BigQuery من الدفتر​

مرور البيانات من BigQuery إلى pandas مسألة يوميّة. أسرع مسار:

from google.cloud import bigquery
import pandas as pd

client = bigquery.Client(project="fraud-detection-lab")

sql = """
SELECT event_ts, amount, merchant_country, is_fraud
FROM `fraud-detection-lab.transactions.raw`
WHERE event_ts BETWEEN '2025-06-01' AND '2025-06-30'
LIMIT 200000
"""

df = client.query(sql).to_dataframe(create_bqstorage_client=True)

نقطتان تُغيّران التجربة كليًّا:

  • create_bqstorage_client=True يُفعِّل مسار BigQuery Storage API، الذي يقرأ الأعمدة بشكل متوازٍ. سرعته من عشرة إلى مئة ضعف مقارنة بالمسار العاديّ على استعلام يعود بمليون سطر.
  • LIMIT 200000 أثناء الاستكشاف: BigQuery يفوتَر على البايتات المسحوبة، لا على الأسطر المُعادة، لكن LIMIT مع فلترة زمنيّة صحيحة تُقلِّص عمود المسح.

للمشروع الأكبر، عوض إنزال جدول بأكمله إلى الذاكرة، يُفضَّل إبقاء الحساب داخل BigQuery (تحويلات SQL) ثمّ إنزال المجاميع فقط.

المُساحرات (magic) لأوامر BigQuery​

نواة الدفتر تُتيح استعلامًا مباشرًا:

%%bigquery daily_fraud --project fraud-detection-lab
SELECT DATE(event_ts) AS day,
       COUNTIF(is_fraud) / COUNT(*) AS fraud_rate
FROM `fraud-detection-lab.transactions.raw`
GROUP BY day
ORDER BY day

النتيجة تُوضَع تلقائيًّا في متغيّر daily_fraud من نوع DataFrame. مفيد للاستكشاف الخاطف بلا كتابة قالب متكرِّر.

عزل الأسرار​

مفتاح API لخدمة خارجيّة، رمز Slack لإشعارات، كلمة سرّ قاعدة بيانات ما وراء البيانات: كلّها لا تُكتَب في الدفتر. البديل: Secret Manager.

from google.cloud import secretmanager

def read_secret(name: str) -> str:
    client = secretmanager.SecretManagerServiceClient()
    resource = f"projects/fraud-detection-lab/secrets/{name}/versions/latest"
    return client.access_secret_version(name=resource).payload.data.decode()

slack_token = read_secret("slack-alerts-token")

الدفتر يُشارَك، يُصدَّر PDF، يُلصَق في تذكرة دعم؛ سرّ مكتوب في خليّة ينكشف حتمًا في يوم من الأيّام.

Colab Enterprise في سطور​

نُنشئ نموذج تشغيل (runtime template) واحدًا للفريق يحدّد نوع الآلة والصورة والمنطقة، ثمّ يفتح كلّ شخص دفترًا يستعمله. الدفاتر تُخزَّن على Google Drive المؤسّسيّ ويمكن أن يعدّلها اثنان في الوقت نفسه. المرور بـIAM أوسع من الشخصيّ Colab: مؤسّستك ترى من فتح، ماذا نفَّذ، ومتى أوقف.

الاستعمال المثمر: ورشة تجريبيّة لمدّة ساعتَين، جلسة تعليم زملاء، عرض حيّ لنموذج أساس. للتطوير الطويل يبقى Workbench هو الأصلح.

حجم القرص الدائم لا يعود إلى الوراء

عند إنشاء آلة Workbench، اختر قرصًا دائمًا بين 200 و500 غيغا. الرفع لاحقًا ممكن، لكنّ التقليص غير مدعوم. قرص 100 غيغا يمتلئ سريعًا مع بيئات conda وبيانات مؤقّتة، فيتوقّف الدفتر ولا يُتاح إلّا إعادة إنشاء الآلة.

اقتصاد لحظة، تكلفة شهر

إنشاء آلة n1-standard-16 مع T4 لاختبار بسيط ثم نسيانها ليلة كاملة يكلّف نحو 40 دولارًا. الأخطر: تنسى الآلة أسبوعًا كاملًا لأنّها لا تظهر إلّا في تبويبة «Workbench» غير المفتوحة. الحلّ المؤسّسيّ: تنبيه فوتُرَة على مستوى المشروع عند تجاوز عتبة يوميّة، مع سياسة إيقاف تلقائيّ إلزاميّة على كلّ آلة جديدة.

في الخلاصة​

  • Workbench للعمل الجدّي، Colab Enterprise للتعاون السريع.
  • آلة صغيرة بالافتراضيّ + إيقاف عند الخمول 30 دقيقة = فاتورة تحت السيطرة.
  • الوصول إلى BigQuery من الدفتر يمرّ عبر create_bqstorage_client=True، والاستعلامات الكبيرة تُنفَّذ داخل BigQuery لا في الذاكرة.
  • الأسرار في Secret Manager، لا في خلايا الدفتر التي تُشارَك حتمًا.

الوحدة التالية: كيف نُنظِّم البيانات على Cloud Storage وBigQuery، ونُنشئ مجموعة بيانات Vertex قابلة لإعادة الاستعمال.