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

الوحدة 2 — تشريح مخزن المتغيّرات

قبل الحديث عن Feast أو Tecton أو Databricks Feature Store، من المفيد رؤية المكوّنات المُشترَكة بينها كلّها. مخزن المتغيّرات ليس منتجًا محدّدًا بل نمط بنية، وأدواته المختلفة تختار تجسيدات مختلفة للمكوّنات نفسها. نُعدّها هنا واحدًا واحدًا، مرتبطةً بمشروع تسجيل الاحتيال الذي يعبر الدورة.

السجلّ: الحقيقة الوصفيّة الوحيدة​

في قلب أيّ مخزن يوجد السجلّ (registry). ملفّ أو قاعدة بيانات صغيرة تصف: ما هي الكيانات؟ ما هي المصادر؟ ما هي وصفات المتغيّرات؟ من يملكها؟ متى عُدِّلت آخر مرّة؟ ما نسختها الحاليّة؟

السجلّ هو ما يُنسَخ إلى Git ويُراجَع في الطلبات. غيابه يعني أنّ التعريفات موجودة في دفاتر متناثرة أو في رؤوس الأشخاص، وحينها تفشل عمليًّا كلّ الحوكمة المُترتّبة: الاكتشاف، والإصدار، وتحمّل المسؤوليّة.

في Feast يقع السجلّ في ملفّ registry.db (بروتوبوف) أو في PostgreSQL؛ في Tecton يقع في بنيته المركزيّة؛ في Databricks في Unity Catalog. المبدأ واحد.

الكيانات: عمّن نتكلّم؟​

الكيان (entity) هو محور الأعمال الذي يوصف المتغيّر تجاهه. في مشروعنا، الكيانات الطبيعيّة ثلاثة:

  • customer بمعرّف customer_id
  • merchant بمعرّف merchant_id
  • card بمعرّف card_bin لأوّل ستّة أرقام من البطاقة (لأسباب امتثاليّة، لا نُخزّن الرقم كاملًا)

هذه الكيانات هي مفاتيح البحث في وقت الاستدلال. يستقبل النموذج معاملة، ويُخرج منها المعرّفات الثلاثة، ثمّ يسأل المخزن: «أعطني آخر متغيّرات هذه الكيانات». دون كيانات مصرَّحة، لا وجود لواجهة استدعاء نظيفة.

وصفة المتغيّر: العقد​

وصفة المتغيّر (feature view) هي الوحدة الأساسيّة للإعلان. تجمع:

  • كيانًا واحدًا أو أكثر تُوصف عليه
  • مصدرًا يُغذّي القيم
  • قائمة متغيّرات بأنواعها (Int64, Float32, String…)
  • مُدّة صلاحيّة (TTL) بعدها تصبح القيمة مُنتهية
  • مالكًا ووسمًا للإدارة

مثال (تركيبيّ، سنكتبه فعليًّا في الوحدة 7):

customer_counters = FeatureView(
    name="customer_counters",
    entities=[customer],
    ttl=timedelta(days=7),
    schema=[
        Field(name="count_1h", dtype=Int64),
        Field(name="count_24h", dtype=Int64),
        Field(name="count_7d", dtype=Int64),
        Field(name="avg_amount_7d", dtype=Float32),
    ],
    source=transactions_stream,
    owner="fraud-team@example.com",
)

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

المصادر: من أين تأتي القيم؟​

المصدر (source) هو رابط إلى الاستضافة الفعليّة للبيانات. تجد ثلاثة أنواع رئيسة:

  • مصدر دُفعات: جدول Parquet على S3، جدول BigQuery أو Snowflake، مجلّد Iceberg. لا يعرف إلّا القيم التاريخيّة. مثال في مشروعنا: s3://data/transactions/*.parquet.
  • مصدر تدفّق: موضوع Kafka أو Kinesis يُغذّي القيم بشكل متواصل. يحتاج معالجة بـSpark Streaming أو Flink لتحويله إلى متغيّرات.
  • مصدر عند الطلب: دالّة تُنفَّذ عند الاستعلام (مثل حساب المسافة إلى آخر شراء انطلاقًا من معاملة داخلة).

اختيار المصدر يفرض قيدًا مباشرًا على نضارة المتغيّر: أفضل ما يمكن الحصول عليه بمصدر دُفعات ليليّ هو نضارة 24 ساعة. سنعود لهذا في الوحدة 6.

المخزنان: هوَ ولى وجهه شطر التدريب أم الخدمة؟​

من مصدر واحد ينبثق تخزينان مختلفان:

  • المخزن غير المتّصل (offline store): تاريخ كامل، مُحسَّن للقراءات الكبيرة، بلا قيد زمن استجابة. تكنولوجيّاته: Parquet، BigQuery، Snowflake، Delta Lake. يخدم التدريب والتحليل.
  • المخزن المتّصل (online store): آخر قيمة لكلّ كيان، مُحسَّن لقراءات مفاتيح-قيم بزمن استجابة تحت المليّ‌ثانية. تكنولوجيّاته: Redis، DynamoDB، Cassandra، Bigtable. يخدم الاستدلال.

هذا الفصل ليس تجميلًا، بل ضرورة تقنيّة: لا قاعدة واحدة تعطي في آن حجم البيتابايت التاريخيّ والاستجابة تحت 5 مليّ‌ثانية. الوحدة 3 تعالجه بالتفصيل.

الخادم: الواجهة الوحيدة​

خادم المتغيّرات (feature server) هو الواجهة الموحّدة التي يستدعيها النموذج. يستقبل معرّفات الكيانات وقائمة المتغيّرات، ثمّ يستعلم المخزن المتّصل ويُعيد النتائج. غالبًا REST أو gRPC.

بوجود الخادم، لا يعرف مُخدَم الاستدلال شيئًا عن Redis أو DynamoDB: يستدعي /get-features وحسب. وهذا يُلغي التغيير في مُخدَم النموذج حين يتغيّر المخزن السفليّ.

أين يقع كلّ هذا في MLOps​

مخزن المتغيّرات ليس بديلًا لنظام إدارة النماذج (الدورة 20) بل يجاوره:

الطبقةما يتحمّله
مخزن المتغيّراتتعريف المتغيّرات، وحسابها، وتقديمها في نمطَيها
سجلّ النماذجإصدار النماذج، والانتقالات، والاعتمادات
خادم الاستدلالتحميل النموذج، وتلقّي الطلب، ونداء مخزن المتغيّرات
مراقبة الإنتاججودة المتغيّرات (الوحدة 9)، وأداء النموذج، وانحراف المفهوم

هذا التقسيم يُقلّل المسؤوليّات لكلّ طبقة ويُعزّز الاستبدال المستقلّ لأيّ منها.

الخطأ الأشيع في التصميم الأوّل

كثيرون يبنون «مخزن متغيّرات» يكتفي بمخزن متّصل واحد. عندها يعمل الاستدلال، ثمّ عند الحاجة إلى إعادة تدريب النموذج، لا يوجد تاريخ. فيعودون إلى دفتر ينبش الجداول الخام يدويًّا — وتظهر الفجوة من جديد. المخزن غير المتّصل والمخزن المتّصل، الاثنان معًا، من اليوم الأوّل.

الخلاصة​

  • السجلّ يحفظ التعاريف؛ والكيانات تُحدّد محاور البحث؛ ووصفة المتغيّر تُشكّل العقد بين المُنتِج والمستهلكين.
  • تُغذّى الوصفات من مصادر دُفعات أو تدفّق أو عند الطلب، وكلّ نوع يُقيّد نضارة المتغيّر.
  • المخزنان غير المتّصل والمتّصل لازمان معًا: الأوّل للتدريب، والثاني للخدمة تحت المليّ‌ثانية.
  • الخادم هو الواجهة الموحّدة التي يستدعيها النموذج، ويعزل مُخدَم الاستدلال عن اختيار الاستضافة.

الوحدة التالية: نُقارن المخزنين بالتفصيل ونُبيّن كيف يضمنان التطابق بين قيمة تدرّبنا عليها وقيمة نقرّر بها.