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

الوحدة 9 — خطوط المعالجة والجدولة

الوحدات السابقة أعطتنا مكوّنات منفصلة: قراءة بيانات، تدريب، تسجيل، نشر. الوحدة الحالية تربطها في خطّ معالجة (pipeline) واحد، يعمل يوم الاثنين كلّ أسبوع، ويعيد إنتاج نموذج تنبّؤ الطلب على أحدث بيانات المبيعات لسلسلة المتاجر.

من المهمّة الواحدة إلى خطّ المعالجة​

مهمّة الأمر من الوحدة 5 تنفّذ خطوة واحدة. خطّ المعالجة يُنسّق عدّة خطوات مع تبعيات وتدفّق بيانات بينها:

prepare_data  →  train_model  →  evaluate  →  register_if_better

كلّ خطوة مهمّة أمر مستقلّة (شفرة، بيئة، مدخلات، مخرجات). المخرَج من الخطوة السابقة يصير المدخَل للخطوة التالية.

الفائدة الحاسمة: إعادة استعمال المكوّنات. الخطوة evaluate نفسها تُستعمل في خطوط أخرى (تدريب دون توقّف مبكر مثلًا). كلّ تحسين على مكوّن يستفيد منه كلّ خطّ يستدعيه.

المكوّن (Component)​

المكوّن مهمّة قابلة لإعادة الاستعمال، مسجَّلة في مساحة العمل. تُصرَّح في YAML:

# components/prepare.yml
$schema: https://azuremlschemas.azureedge.net/latest/commandComponent.schema.json
name: prepare_sales
version: 3
type: command
inputs:
  raw:
    type: uri_file
  min_date:
    type: string
outputs:
  train:
    type: mltable
  val:
    type: mltable
code: ../src
environment: azureml:forecast-env:3
command: >
  python prepare.py
  --raw ${{inputs.raw}}
  --min-date ${{inputs.min_date}}
  --train-out ${{outputs.train}}
  --val-out ${{outputs.val}}

التسجيل:

az ml component create --file components/prepare.yml

كلّ إصدار جديد للمكوّن يعطي رقمًا. خطوط المعالجة القديمة تبقى مربوطة بإصدارها.

خطّ معالجة YAML​

$schema: https://azuremlschemas.azureedge.net/latest/pipelineJob.schema.json
experiment_name: weekly-training
display_name: weekly-forecast-2026-w36

inputs:
  weekly_raw:
    type: uri_file
    path: azureml:sales_weekly:2026.36
  min_date: "2024-01-01"

jobs:
  prepare:
    type: command
    component: azureml:prepare_sales:3
    inputs:
      raw: ${{parent.inputs.weekly_raw}}
      min_date: ${{parent.inputs.min_date}}

  train:
    type: command
    component: azureml:train_xgb:5
    inputs:
      train: ${{parent.jobs.prepare.outputs.train}}
      val: ${{parent.jobs.prepare.outputs.val}}
      alpha: 0.1
      max_depth: 6
    compute: azureml:cpu-cluster

  evaluate:
    type: command
    component: azureml:evaluate_model:2
    inputs:
      model: ${{parent.jobs.train.outputs.model}}
      val: ${{parent.jobs.prepare.outputs.val}}
      mae_threshold: 2.0

  register:
    type: command
    component: azureml:register_if_better:1
    inputs:
      model: ${{parent.jobs.train.outputs.model}}
      metric: ${{parent.jobs.evaluate.outputs.mae}}
      name: demand-forecast

الإطلاق:

az ml job create --file pipelines/weekly.yml

Azure يستنتج التبعيات من روابط ${{parent.jobs.X.outputs.Y}} ويشغّل الخطوات بالترتيب الصحيح، بالتوازي حيث يمكن.

عرض في Studio​

صفحة خطّ المعالجة في Azure ML Studio تُظهر رسمًا للخطوات مع تدفّق البيانات، ونجاح أو فشل كلّ خطوة، وسجلّاتها، ومخرجاتها. تصير أداة تشخيص أساسية: خطوة فشلت في السجلّ؟ نقرة عليها تفتح الشفرة والمعطيات والخطأ.

الجدولة الأسبوعية​

بمجرّد أن يعمل خطّ المعالجة يدويًّا، نُحدّد جدولة تُنفّذه أسبوعيًّا:

# schedules/weekly.yml
$schema: https://azuremlschemas.azureedge.net/latest/schedule.schema.json
name: forecast-monday-6am
display_name: تدريب أسبوعي يوم الاثنين
trigger:
  type: cron
  expression: "0 6 * * MON"
  time_zone: "W. Europe Standard Time"
create_job: pipelines/weekly.yml
az ml schedule create --file schedules/weekly.yml

الجدولة تنسخ تعريف خطّ المعالجة عند الإنشاء. تعديل الشفرة لا يُحدّث الجدولة تلقائيًّا — يجب az ml schedule update بعد كلّ تغيير جوهري.

التشغيل عند حدث​

لا تُريد الانتظار حتى الاثنين إن وصلت بيانات جديدة يوم الأربعاء؟ تدمج Azure Event Grid مع خطّ المعالجة. عند نشر ملفّ في مسار محدَّد بـBlob:

  1. Blob Storage يُصدر حدث Microsoft.Storage.BlobCreated.
  2. Event Grid يوجّه الحدث إلى Logic App أو Function.
  3. الدالة تُنفّذ az ml job create --file pipelines/weekly.yml.

هذا يُغيّر التدريب من مجدوَل بالوقت إلى مُقاد بالبيانات. الفائدة: نموذج مُحدَّث دائمًا في حالة اليوم، لا تدريب فارغ حين لا شيء تغيّر.

فخّ مهمّ: نمط الحدث يجب أن يُصفّى بدقّة. عدم التصفية يعني أنّ كلّ رفع صغير (سجلّ، ملفّ نظام) يُطلق تدريبًا يستهلك ساعات حوسبة بلا فائدة. subject: "/blobServices/default/containers/raw-sales/blobs/weekly/" يقصر التشغيل على الملفّات المهمّة.

المعاملات عند التشغيل​

نمّط خطّ المعالجة ليقبل معاملات، ثمّ مرّرها عند الاستدعاء:

az ml job create --file pipelines/weekly.yml --set inputs.min_date="2025-01-01"

يسمح هذا بإعادة تشغيل نفس خطّ المعالجة بمعطيات مختلفة (تدريب على نافذة أطول، تجربة معامل فائق) دون تحرير الملفّ.

أخطاء الجدولة الشائعة​

  • جدولة تُطلق مهامّ على عنقود لا يوجد: أنشئ العنقود قبل الجدولة، ولا تحذفه بعدها بغير تحديث.
  • جدولة تعمل بينما مهمّة سابقة لم تنته: أضف concurrency: 1 أو تحقّق قبل الإطلاق.
  • cron بمنطقة زمنية خاطئة: 0 6 * * MON بدون time_zone يعمل UTC، ينفَّذ في التوقيت المحلّي في وقت خاطئ.
قبل الجدولة، شغّل يدويًّا

جدولة خطّ معالجة لم يعمل يدويًّا مطلقًا وصفة لكوارث ليلية. جرّب يدويًّا ثلاث مرّات على الأقلّ بمعطيات مختلفة، ثمّ فقط أضف الجدولة.

الخلاصة​

  • المكوّنات المعاد استعمالها تُبنى مرّة وتخدم عدّة خطوط.
  • خطّ معالجة YAML ينسّق الخطوات مع تبعيات صريحة وتدفّق بيانات.
  • الجدولة بـcron لدورة أسبوعية، مع منطقة زمنية واضحة.
  • Event Grid + Logic App يُشغّل خطّ المعالجة عند حدث بدل الوقت.
  • جرّب يدويًّا قبل الجدولة، وصفّي أحداث Blob لتجنّب تشغيل عبثيّ.

الوحدة التالية: مراقبة النماذج، تحليل التكاليف، وإدارة الحصص — كيف نُبقي النظام يعمل بلا مفاجآت في الفاتورة الشهرية.