هندسة Lakehouse بإتقان: Bronze وSilver وGold في Microsoft Fabric

By Mirko Peters · 2026-08-28

مرحبًا بكم مجددًا في مدونة المرافقة للبودكاست! في حلقتنا الأخيرة تعمّقنا في الواقع العملي لهندسة تعلّم الآلة ضمن منظومة Microsoft، ومنها…

Automatically translated with AI from the original post. Read the English original

Titelbild: Mastering Lakehouse Architecture: Bronze, Silver, and Gold in Microsoft Fabric

مرحبًا بكم مجددًا في مدونة المرافقة للبودكاست! في حلقتنا الأخيرة تعمّقنا في الواقع العملي لهندسة تعلّم الآلة ضمن منظومة Microsoft. إن لم تستمعوا إليها بعد، فتأكدوا من الاطلاع على Build Machine Learning Models in Microsoft Fabric. واليوم سنتوسّع في تلك المفاهيم ونستكشف كيف يشكّل تنظيم بياناتكم باستخدام بنية الطبقات الميدالية (Medallion) داخل Lakehouse في Microsoft Fabric الأساس المتين لعملية تعلّم آلة ناجحة وقابلة للتوسّع.

بناء نماذج تعلّم آلة جاهزة للإنتاج لا يقتصر على اختيار الخوارزمية الصحيحة أو ضبط المعاملات الفائقة. في أغلب الأحيان، يتوقف نجاح نماذجكم التنبؤية على نظافة البيانات، وخطوط معالجة قابلة لإعادة الإنتاج، وحوكمة متينة. فلنستعرض كيف تتقنون بنية Lakehouse باستخدام Microsoft Fabric.

البنية في لمحة

عند تصميم منصة متكاملة للبيانات وتعلّم الآلة في Microsoft Fabric، يكون فهم مسار تدفّق البيانات أمرًا بالغ الأهمية. تبدأ كل العملية في OneLake، الذي يعمل كطبقة تخزين موحّدة. ومن هناك تُوجَّه البيانات إلى Lakehouse، حيث تمرّ عبر جداول Delta من نوع Bronze وSilver وGold.

على صعيد الحوسبة، تمنح Fabric Notebooks علماء البيانات وصولًا إلى حزمة علوم بيانات مُعدّة مسبقًا تعمل بتقنية Spark وPython وR. ويُدار تتبّع التجارب بسلاسة عبر عمليات MLflow المدمجة، فتُسجَّل المقاييس والمعاملات والمخرجات دون الحاجة إلى خوادم تتبّع خارجية. وبعد تدريب النماذج تنتقل إلى السجل الموحّد، مع الإصدارات والموافقات وتتبّع كامل لسلسلة البيانات. وأخيرًا تُقدَّم النماذج عبر مهام دفعية مُدارة أو نقاط نهاية HTTP فورية، لتغذية مستهلكين مثل Power BI وPower Apps وعملاء API المخصصين.

Lakehouse: تهذيب المدخلات والحفاظ على التحكم

الفلسفة الجوهرية لـ Lakehouse هي الجمع بين مرونة بحيرات البيانات وموثوقية مستودعات البيانات. ولكي يعمل ذلك بفعالية، عليكم تقسيم بياناتكم إلى طبقات مميزة.

قسّموا جداولكم إلى طبقات

Bronze: هذه هي طبقة الاستيعاب الخام. تصل البيانات إلى هنا وفق مبادئ schema-on-read، وتبقى غير قابلة للتعديل لأغراض التدقيق وإعادة المعالجة.
Silver: في هذه الطبقة تُنظَّف البيانات وتُحدَّد أنواعها وتُدمج. يُقلَّل تواجد PII، وتُفرض فحوصات الجودة الأولية.
Gold: تحتوي طبقة Gold على مجموعات تجميعية جاهزة للميزات، مبنية على عقود بيانات واضحة وموثّقة يمكن لنماذج تعلّم الآلة الخاصة بكم استهلاكها مباشرة.

الوصول حسب الغرض

استخدموا التحكم في الوصول القائم على الأدوار على مستوى مساحة العمل مقترنًا بقوائم التحكم في الوصول على مستوى الجداول. امنحوا علماء البيانات صلاحية القراءة لجداول Silver وGold، وقيّدوا صلاحية الكتابة تحديدًا على جداول الميزات والمجلدات التجريبية.

ضوابط جودة البيانات

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

مخزن ميزات مبسّط

تعاملوا مع الميزات القابلة لإعادة الاستخدام كجداول Gold، على سبيل المثال feat_customer_rolling_90d، وأرفقوها بقاموس بيانات بصيغة YAML لضمان أن يفهم فريقكم ما تمثّله كل ميزة.

دفاتر ملاحظات بلا متاعب

يمكن أن تتحول البرمجة التعاونية إلى فوضى بسرعة إذا اعتمد المطوّرون على بيئات مختلفة. توفّر Fabric نوى (kernels) مثبّتة مسبقًا تشمل pandas وPySpark وscikit-learn وPyTorch، بما يضمن أن يعمل الجميع انطلاقًا من الأساس نفسه تمامًا.

اعتمدوا تخطيطًا منظمًا للمشروع يفصل بين دفاتر الاستكشاف، وسكربتات هندسة الميزات، وروتينات تدريب النماذج، وملفات الإعداد. واجعلوا قابلية إعادة الإنتاج في الشيفرة البرمجية لا في النقرات اليدوية على الواجهة. اقرأوا من Lakehouse عبر Spark SQL، واكتبوا الميزات النهائية كجداول Delta، ودائمًا أنشئوا جداول عينات تطوير أصغر حجمًا كي يتمكن فريقكم من التكرار بسرعة دون انتظار استعلامات على مجموعات البيانات الكاملة الضخمة.

تتبّع كل شيء باستخدام MLflow (مدمج)

تؤدي متابعة تجارب النماذج يدويًا إلى نتائج لا يمكن إعادة إنتاجها. باستخدام تكامل MLflow المدمج في Fabric، تضمنون قابلية مقارنة كل عملية تشغيل بغيرها، وقابلية تدقيق كاملة، وإمكانية التراجع بسهولة عندما يقل أداء نموذج تم نشره حديثًا.

سجِّلوا جميع المعلمات الفائقة ومقاييس التقييم وملفات النموذج المدرَّب مباشرةً داخل نصوص التدريب الخاصة بكم. واحرصوا على وسم عمليات التشغيل ببيانات سياقية مثل نافذة البيانات، وإصدارات مجموعة الميزات، ومعرّفات الإيداع (commit hashes) في الشيفرة، مع تثبيت جداول التدريب على إصدارات Delta snapshot محددة.

السجل والموافقات وتتبع النسب

يجب ألا يكون نقل النموذج من مرحلة التجريب إلى الإنتاج مسألة تخمين أبدًا. رقّوا أفضل عمليات التشغيل أداءً إلى نموذج مسجَّل (Registered Model) باستخدام الترقيم الدلالي للإصدارات، مثل 1.0.0. نفِّذوا عملية موافقة من خطوتين تتطلب توقيع كل من مالك علم البيانات ومالك العمل. وأخيرًا، اجمعوا بيانات وصفية شاملة لبطاقة النموذج (model card) توضح غرض النموذج ونطاق بياناته وملاحظات العدالة وأهداف مستوى الخدمة للمراقبة.

خيارات التقديم (اختاروا حسب عبء العمل)

التسجيل الدفعي (منخفض التكلفة وموثوق)

بالنسبة لأعباء العمل التي لا تتطلب استجابة فورية أقل من ثانية، يُعد التسجيل الدفعي الخيار الأمثل. استخدموا مهام Fabric المجدولة أو دفاتر الملاحظات لقراءة النماذج الإنتاجية من السجل، وتطبيقها على مجموعات البيانات الدفعية، ثم كتابة التنبؤات مجددًا إلى Lakehouse.

نقطة نهاية فورية (للتطبيقات التفاعلية)

عندما يحتاج المستخدمون إلى ردود فعل فورية، مثل التحقق من صحة النماذج أو تقييم المخاطر عند النقر، انشروا النموذج المسجَّل كنقطة نهاية فورية مُدارة مباشرةً من واجهة مستخدم Fabric. اعرضوا عقد JSON قابلًا للتنبؤ، واربطوه بأمان مع Power Apps أو التطبيقات الخارجية.

المراقبة وإعادة التدريب

نشر النموذج ليس سوى نصف المعركة. يجب أن تراقبوا باستمرار انحراف البيانات (data drift) بمقارنة توزيعات الميزات الحية بخط الأساس للتدريب، باستخدام تباعد Kullback-Leibler أو عتبات مؤشر استقرار السكان (Population Stability Index). تابعوا مقاييس الصحة التشغيلية، ومنها زمن استجابة نقطة النهاية ومعدلات الأخطاء والتكلفة لكل ألف تقييم. أتمتوا خطوط إعادة التدريب باستخدام مزيج من المحفزات الزمنية وتنبيهات الانحراف القائمة على الأحداث، لضمان بقاء نماذجكم دقيقة مع مرور الوقت.

الأمان والامتثال

الحفاظ على الأمان أمر بالغ الأهمية عند التعامل مع بيانات المؤسسة. طبِّقوا مبدأ أقل الامتيازات بمنح علماء البيانات صلاحية القراءة على طبقتي silver وgold، مع قصر صلاحيات الكتابة على دلائل الميزات والتجارب المخصصة لذلك. استخدموا الهويات المُدارة وAzure Key Vault لتخزين جميع بيانات الاعتماد، بحيث لا تُكتب الأسرار أبدًا بشكل ثابت في دفاتر الملاحظات. وقلّلوا تعرّض المعلومات الشخصية القابلة للتعريف (PII) بتجزئة المعلومات الحساسة أو ترميزها (tokenization) مبكرًا في طبقة silver، حتى لا تنتقل إلى مخازن الميزات أبدًا.

ما الذي يجب قياسه (أثبتوا القيمة بسرعة)

لإثبات قيمة مبادرات تعلم الآلة بسرعة، ركّزوا على المقاييس الصحيحة. قيسوا قوة النموذج باستخدام AUC وprecision-at-k لأنظمة الترتيب، وتتبعوا الأثر على الأعمال من خلال الإيرادات الإضافية أو انخفاض معدلات فقدان العملاء، وراقبوا سرعة الانتقال من جاهزية البيانات إلى النشر في الإنتاج، وقيّموا موثوقية البنية التحتية وكفاءة التكلفة لكل ألف تنبؤ.

خطة النشر خلال 14 يومًا

إذا أردتم الانتقال من الصفر إلى نشر Fabric جاهز للإنتاج بسرعة، فاتبعوا خطة النشر المنظمة هذه على مدى أسبوعين:

اليوم 1–2: تنظيف Lakehouse، وبناء هيكل bronze/silver/gold، وقوائم ACLs، وفحوص الجودة.
اليوم 3: تهيئة الدفاتر، والأدوات المساعدة للبيانات، وجداول العينات للتطوير.
اليوم 4–5: مجموعة الميزات v1، وتدريب النموذج الأساسي، وتسجيل MLflow.
اليوم 6: مجموعة التقييم، وإنشاء بطاقة النموذج، وتسجيل النموذج (v0.1).
اليوم 7: إنشاء مهمة التسجيل الدفعي، وتكامل لوحة Power BI.
اليوم 8: الحد الأدنى القابل للتطبيق للمراقبة، وفحوص الانحراف، وتسجيل العمليات التشغيلية.
اليوم 9: تنفيذ سير عمل الموافقات، والترقية إلى الإنتاج.
اليوم 10: إعداد نقطة النهاية الفورية، وتحديد معدل الطلبات، وتسجيل الطلبات (إن أمكن).
اليوم 11–12: اختبار A/B، والاختبار الرجعي (backtesting)، وتحديد مؤشرات الأداء الرئيسية للأعمال.
اليوم 13: حوكمة التكلفة، وضوابط التوسيع التلقائي، وخطة النشر التدريجي (canary).
اليوم 14: توثيق دليل التشغيل، وتسليم المهام للفريق، وتخطيط قائمة المهام المتراكمة.

المزالق الشائعة (وحلول سريعة)

حتى الفرق ذات الخبرة تصطدم بعوائق. تجنّبوا عشوائية الدفاتر (notebook roulette) بتثبيت بيئاتكم على نوى Fabric القياسية. لا تختبروا حصرياً على عيّنات صغيرة تفشل عند توسيعها إلى مجموعات البيانات الكاملة. امنعوا ظهور النماذج الشبحية في الإنتاج بفرض تطبيق سير عمل ترقية السجل بصرامة. أبقوا تكاليف السحابة تحت السيطرة بجعل المعالجة الدفعية الخيار الافتراضي كلما أمكن، وبتخزين الميزات المشتقة مؤقتاً.

مقتطفات كود مفيدة

للمساعدة في انطلاق مشروعكم التالي، إليكم مقتطف سريع يوضح كيفية قراءة إصدار محدد من جدول Delta:

sales_v = spark.read.option("versionAsOf", 123).table("lakehouse.gold.sales_txn")

إذا رغبتم في استخراج أهمية الميزات باستخدام scikit-learn وتسجيلها مباشرةً في MLflow، فاستخدموا هذا الأسلوب:

import pandas as pd
fi = pd.Series(clf.feature_importances_, index=feature_cols).sort_values(ascending=False)
mlflow.log_artifact(fi.head(30).to_frame("importance").to_csv("fi.csv", index=True))

ولحساب مؤشر استقرار السكان (PSI) لكشف الانحراف (drift):

import numpy as np
def psi(expected, actual, bins=10):
    e, b = np.histogram(expected, bins=bins, range=(np.min(expected), np.max(expected)))
    a, _ = np.histogram(actual,   bins=b,     range=(np.min(expected), np.max(expected)))
    e = np.clip(e / e.sum(), 1e-6, None); a = np.clip(a / a.sum(), 1e-6, None)
    return np.sum((a - e) * np.log(a / e))

إذا رغبتم، شاركوا أسماء جداول Lakehouse الحالية لديكم وحالة الاستخدام المستهدفة، مثل فقدان العملاء (churn)، أو تقييم العملاء المحتملين، أو التنبؤ بالطلب، في التعليقات أو تواصلوا معي مباشرةً. سأرسم لكم مجموعة ميزات أساسية محدودة، واختياراً مبدئياً للنموذج الأساسي، وربط المعالجة الدفعية أو الفورية بدقة، لمساعدتكم على إطلاق أول نشر لكم في Microsoft Fabric بسرعة!