full stack on prem cv mlops

نظام MLOps كامل المكدس محليًا لرؤية الكمبيوتر

◀️ تكوين واحد وأمر واحد من Jupyter Notebook لخدمة ملايين المستخدمين ◀️

جدول المحتويات

• ملخص
• فيديوهات تجريبية
• الأدوات / التقنيات
• الممارسات المعتمدة
• منافذ الخدمة
• كيفية الاستخدام
  • يثبت
  • الحد الأدنى من الاستخدام
  • التخصيص
• كيف يعمل كل شيء معًا
• من مكان العمل إلى السحابة
• مخططات قاعدة البيانات
• استكشاف الأخطاء وإصلاحها

ملخص

مرحبًا بك في نظام MLOps البيئي الشامل الخاص بنا والذي تم تصميمه خصيصًا لمهام رؤية الكمبيوتر، مع التركيز بشكل أساسي على تصنيف الصور. يزودك هذا المستودع بكل ما تحتاجه، بدءًا من مساحة عمل التطوير في Jupyter Lab/Notebook وحتى الخدمات على مستوى الإنتاج. أفضل جزء؟ لا يتطلب الأمر سوى "تكوين واحد وأمر واحد" لتشغيل النظام بأكمله بدءًا من إنشاء النموذج وحتى النشر! لقد قمنا بدمج العديد من أفضل الممارسات لضمان قابلية التوسع والموثوقية مع الحفاظ على المرونة. في حين أن حالة الاستخدام الأساسية لدينا تدور حول تصنيف الصور، فإن هيكل مشروعنا يمكن أن يتكيف بسهولة مع مجموعة واسعة من تطورات ML/DL، وحتى الانتقال من مكان العمل إلى السحابة!

الهدف الآخر هو إظهار كيفية دمج كل هذه الأدوات وجعلها تعمل معًا في نظام واحد كامل. إذا كنت مهتمًا بمكونات أو أدوات محددة، فلا تتردد في اختيار ما يناسب احتياجات مشروعك.

يتم وضع النظام بأكمله في حاوية في ملف Docker Compose واحد. لإعداده، كل ما عليك فعله هو تشغيل docker-compose up ! هذا نظام داخلي بالكامل، مما يعني عدم الحاجة إلى حساب سحابي، ولن يكلفك استخدام النظام بأكمله سنتًا واحدًا !

نوصي بشدة بمشاهدة مقاطع الفيديو التجريبية في قسم مقاطع الفيديو التجريبية للحصول على نظرة عامة شاملة وفهم كيفية تطبيق هذا النظام على مشاريعك. تحتوي مقاطع الفيديو هذه على تفاصيل مهمة قد تكون طويلة جدًا وغير واضحة بدرجة كافية لتغطيتها هنا.

فيديوهات تجريبية

العرض التوضيحي: https://youtu.be/NKil4uzmmQc
إرشادات تقنية متعمقة: https://youtu.be/l1S5tHuGBA8

الموارد في الفيديو:

• ملفات النموذج (النماذج المستندة إلى ResNet50): الرابط
• الشريحة: الرابط

الأدوات / التقنيات

لاستخدام هذا المستودع، ما عليك سوى Docker. كمرجع، نستخدم إصدار Docker 24.0.6 وبناء ed223bc وإصدار Docker Compose v2.21.0-desktop.1 على Mac M1.

• المنصة: عامل الميناء
• مساحة العمل: مختبر جوبيتر
• إطار التعلم العميق: TensorFlow
• إصدار البيانات: DvC
• التحقق من صحة البيانات: DeepChecks
• منصة التعلم الآلي / تتبع التجربة: MLflow
• منسق خط الأنابيب: المحافظ
• نشر خدمة التعلم الآلي: FastAPI، وUvicorn، وGunicorn، وNginx (+ HTML وCSS وJS لواجهة مستخدم بسيطة)
• قواعد البيانات: PostgreSQL (SQL)، وPrometheus (السلسلة الزمنية)
• مراقبة نموذج التعلم الآلي واكتشاف الانجراف: من الواضح
• مراقبة النظام الشامل ولوحة القيادة: Grafana

الممارسات المعتمدة

لقد قمنا بتنفيذ العديد من أفضل الممارسات في هذا المشروع:

• أداة تحميل/خط أنابيب بيانات فعالة باستخدام tf.data لـ TensorFlow
• تكبير الصور باستخدام imgaug lib للحصول على مرونة أكبر في خيارات التكبير مقارنة بالوظائف الأساسية من TensorFlow
• استخدام os.env للتكوينات المهمة أو على مستوى الخدمة
• التسجيل باستخدام وحدة logging بدلاً من print
• تخزين قاعدة البيانات لنتائج استجابة الخدمة
• التكوين الديناميكي من خلال .env للمتغيرات في docker-compose.yml
• استخدام default.conf.template لـ Nginx لتطبيق متغيرات البيئة بشكل أنيق في تكوين Nginx (ميزة جديدة في Nginx 1.19)
• تكوين Nginx لعرض سجل المحطة الطرفية
• إعداد عامل محافظ لدعم العمل على المجموعة

منافذ الخدمة

يمكن تخصيص معظم المنافذ في ملف .env في جذر هذا المستودع. فيما يلي الإعدادات الافتراضية:

• جوبيتر لاب: 8888 (رقم الهاتف: 123456789 )
• ملفلوو: 5050
• الوالي: 4200
• بوستجري إس كيو إل: 5432
• pgAdmin: 16543 (المستخدم: [email protected] ، pw: SuperSecurePwdHere )
• خدمة التعلم العميق: 4242
• واجهة واجهة المستخدم على الويب لخدمة التعلم العميق: 4243
• نجينكس: 80
• الظاهر: 8000
• بروميثيوس: 9090
• جرافانا: 3000 (المستخدم: admin , pw: admin )

كيفية الاستخدام

عليك أن تفكر في التعليق على هذا platform: linux/arm64 في docker-compose.yml إذا كنت لا تستخدم جهاز كمبيوتر يستند إلى ARM (نحن نستخدم Mac M1 للتطوير). وإلا فإن هذا النظام لن يعمل.

يثبت

1. استنساخ هذا الريبو. هناك وحدتان فرعيتان في هذا الريبو، لذا فكر في استخدام علامة --recurse-submodules في أمرك: git clone --recurse-submodules https://github.com/jomariya23156/full-stack-on-prem-cv-mlops
2. [بالنسبة للمستخدمين الذين لديهم CUDA] إذا كان لديك وحدات معالجة رسومات (GPU) متوافقة مع CUDA، فيمكنك إلغاء التعليق على قسم deploy ضمن خدمة jupyter في docker-compose.yml وتغيير الصورة الأساسية في services/jupyter/Dockerfile من ubuntu:18.04 إلى nvidia/cuda:11.4.3-cudnn8-devel-ubuntu20.04 (النص موجود في الملف، ما عليك سوى التعليق عليه و uncomment) للاستفادة من وحدة (وحدات) GPU الخاصة بك. قد تحتاج أيضًا إلى تثبيت nvidia-container-toolkit على الجهاز المضيف حتى يعمل. بالنسبة لمستخدمي Windows/WSL2، وجدنا هذه المقالة مفيدة جدًا.
3. في جذر دليل الريبو، قم بتشغيل docker-compose up أو docker-compose up -d لفصل الوحدة الطرفية.
4. في المرة الأولى، يمكن أن يستغرق الأمر بعض الوقت بسبب حجم الصور، خاصة بالنسبة لـ jupyter لأنه يحتوي على الكثير من الحزم والمكتبات. بشكل عام، يمكن أن يستغرق الأمر من 5 إلى 20 دقيقة.
5. انتقل إلى الوحدة الفرعية DvC في datasets/animals10-dvc واتبع الخطوات الموجودة في قسم كيفية الاستخدام .

الحد الأدنى من الاستخدام

1. افتح معمل Jupyter على المنفذ 8888 http://localhost:8888/lab
2. انتقل إلى دليل مساحة العمل cd ~/workspace/
3. قم بتنشيط بيئة conda (الاسم قابل للتكوين في docker-compose.yml ) conda activate computer-viz-dl
4. قم بتشغيل python run_flow.py --config configs/full_flow_config.yaml
5. استرخ وشاهد إنشاء المصنف الجديد الخاص بك وتدريبه وتقييمه ونشره (على نطاق واسع) ومراقبته على نظام تشغيل كامل!

التخصيص

• هناك الكثير من الأشياء التي تعمل معًا، ومن الصعب التحدث بالتفصيل في كل جزء منها. لا توجد طريقة أفضل من أن تتسخ يديك وتعرف أيضًا بقراءة الرموز، ومحاولة فهمها، ومحاولة تخصيصها بنفسك!
• على أية حال، هناك بعض الإرشادات التي يمكنك اتباعها لجعل المكونات تعمل معًا بسلاسة كما ينبغي:
  • يجب إنشاء مهامك داخل دليل tasks
  • من المفترض أن يتم استدعاء جميع مهامك من التدفقات التي تم إنشاؤها داخل دليل flows
  • يجب استدعاء التدفقات الخاصة بك باستخدام run_flow.py في جذر الريبو.
  • لكي يتم استدعاؤك بهذه الطريقة، يجب عليك تنفيذ وظيفة start(config) في ملف التدفق الخاص بك. تقبل هذه الوظيفة التكوين باعتباره إملاءًا لـ Python ثم تستدعي بشكل أساسي التدفق المحدد في هذا الملف.
  • يجب أن تكون مجموعات البيانات موجودة داخل دليل datasets ويجب أن يكون لها جميعًا نفس بنية الدليل الموجودة داخل هذا الريبو.
  • يجب أن يحتوي central_storage في ~/ariya/ على دليلين فرعيين على الأقل باسم models و ref_data . يخدم هذا central_storage غرض تخزين الكائنات المتمثل في تخزين جميع الملفات المرحلية لاستخدامها عبر بيئات التطوير والنشر. (هذا أحد الأشياء التي يمكنك التفكير في تغييرها إلى خدمة تخزين سحابية في حالة رغبتك في النشر على السحابة وجعلها أكثر قابلية للتطوير)

اتفاقيات مهمة يجب توخي الحذر الشديد إذا كنت تريد التغيير (لأن هذه الأشياء مرتبطة وتستخدم في أجزاء مختلفة من النظام):

• مسار central_storage -> بالداخل يجب أن يكون هناك models/ ref_data/ أدلة فرعية
• تسمية الملفات في Central_storage، على سبيل المثال <model_name>.yaml ، <model_name>_uae ، <model_name>_bbsd ، <model_name>_ref_data.parquet
• جميع مخططات قاعدة البيانات (الأعمدة) -> مرتبطة في العديد من الأماكن (بشكل أساسي dl_service، prefect_worker/repo، بوضوح)
• مفتاح/اسم المتغيرات الرئيسية current_model_metadata_file و monitor_pool_name
• الإصدار 2.13.2، هناك أخطاء في قالب ملف prefect.yaml وقد تم إصلاحها في هذا الإصدار. لذا، إذا لم يكن ذلك ضروريًا، فلا تنتقل إلى ما دون هذا الإصدار وإلا فستحتاج إلى إجراء تغييرات على الملفات ذات الصلة بـ Prefect.
• من الواضح أن الإصدار 0.4.5، خطأ mmd، الذي نستخدمه كطريقة لتضمين اكتشاف الانجراف، قد تم إصلاحه في هذا الإصدار. مرة أخرى، إذا كنت تريد تغيير الإصدار، حاول ألا تقل عن 0.4.5.

كيف يعمل كل شيء معًا

• يُعد Jupyter Lab بمثابة مساحة العمل الخاصة بك للبرمجة. وهو يشتمل على بيئة Conda المثبتة مسبقًا والتي تسمى computer-viz-dl (القيمة الافتراضية)، مع كافة الحزم المطلوبة لهذا المستودع. من المفترض أن يتم تشغيل جميع أوامر/أكواد Python داخل Jupyter هذا.
• يقوم المحافظ بتنسيق جميع رموز التنفيذ الرئيسية، بما في ذلك المهام والتدفقات.
• يعمل حجم central_storage بمثابة مخزن الملفات المركزي المستخدم خلال عملية التطوير والنشر. يحتوي بشكل أساسي على ملفات نموذجية (بما في ذلك أجهزة كشف الانجراف) وبيانات مرجعية بتنسيق Parquet. في نهاية خطوة تدريب النموذج، يتم حفظ النماذج الجديدة هنا، وتقوم خدمة النشر بسحب النماذج من هذا الموقع. ( ملاحظة : هذا هو المكان المثالي للاستبدال بخدمات التخزين السحابية من أجل قابلية التوسع.)
• هذه هي التوضيحات خطوة بخطوة لما يحدث عند تشغيل التدفق الكامل. يتكون التدفق الكامل من 3 تدفقات فرعية؛ تدريب وتقييم ونشر التشغيل بشكل تسلسلي. يحتوي كل تدفق على مجموعته الخاصة من ملفات التكوين، ويمكن أن يكون ملف .yaml مخصصًا لكل تدفق أو يمكن أن يكون ملف .yaml واحدًا فقط للتدفق الكامل (ألق نظرة على الملفات الموجودة في مجلد التكوين ):
  1. تدفق القطار
     1. قراءة التكوين.
     2. استخدم قسم model في التكوين لإنشاء نموذج مصنف. تم إنشاء النموذج باستخدام TensorFlow وتم ترميز بنيته ضمن tasks/model.py:build_model .
     3. استخدم قسم dataset في التكوين لإعداد مجموعة بيانات للتدريب. يتم استخدام DvC في هذه الخطوة للتحقق من تناسق البيانات الموجودة في القرص مقارنة بالإصدار المحدد في التكوين. إذا كانت هناك تغييرات، فإنه يحولها مرة أخرى إلى الإصدار المحدد برمجياً. إذا كنت تريد الاحتفاظ بالتغييرات، في حالة قيامك بتجربة مجموعة البيانات، يمكنك تعيين حقل dvc_checkout في التكوين إلى false حتى لا يقوم DvC بأشياءه.
     4. يقوم DeepChecks بعد ذلك بالتحقق من صحة مجموعة البيانات المعدة وحفظ تقرير النتيجة. يمكنك إضافة بعض الشروط في هذه الخطوة. على سبيل المثال، إذا فشلت بعض الاختبارات الجادة، قم بإنهاء العملية حتى لا تقوم بتدريب نموذج سيء.
     5. استخدم قسم train في التكوين لإنشاء أداة تحميل البيانات وبدء عملية التدريب. يتم تعقب معلومات التجربة والتحف وتسجيلها باستخدام MLflow . ملاحظة: يتم أيضًا تحميل تقرير النتائج (في ملف .html ) من DeepChecks إلى تجربة التدريب على MLflow الخاصة بالاتفاقية.
     6. أنشئ ملف بيانات تعريف النموذج من قسم model في ملف config.
     7. احفظ النموذج المُدرب وملف البيانات الوصفية المطابق له على القرص المحلي.
     8. قم بتحميل النموذج وملفات البيانات التعريفية للنموذج إلى central_storage (في هذه الحالة، يتم فقط إنشاء نسخة إلى موقع central_storage . هذه هي الخطوة التي يمكنك تغييرها لتحميل الملفات إلى التخزين السحابي)
     9. قم ببناء أجهزة كشف الانجراف بناءً على النموذج المُدرب وقسم model/drift_detection في ملف التكوين.
     10. حفظ وتحميل أجهزة الكشف عن الانجراف إلى central_storage .
     11. إنشاء بيانات مرجعية باستخدام أجهزة الكشف عن الانجراف ومجموعة البيانات.
     12. احفظ البيانات المرجعية في ملف .parquet وقم بتحميلها على central_storage .
     13. أعد المسار إلى النماذج التي تم تحميلها وملف بيانات تعريف النموذج للتدفق التالي.
  2. تدفق التقييم
     1. تحميل النماذج المحفوظة وملفات بيانات التعريف النموذجية.
     2. قم بإعداد مجموعة بيانات للاختبار (أعد استخدام نفس المهمة كما في تدفق القطار)
     3. أنشئ محمل بيانات من التكوين وقم بتقييم النموذج
     4. قم بتسجيل النتائج في MLflow
  3. تدفق النشر
     1. طلب PUT لتشغيل الخدمة قيد التشغيل (المقدمة مع FastAPI + Uvicorn + Gunicorn + Nginx ) لجلب النموذج المدرب حديثًا من central_storage . (هذه إحدى المخاوف التي تمت مناقشتها في الفيديو التوضيحي التعليمي، شاهده لمزيد من التفاصيل)
     2. قم بإنشاء أو تحديث المتغيرات المثالية لمراقبة التكوين، إن وجدت. بشكل أساسي متغيران هما current_model_metadata_file الذي يخزن اسم ملف بيانات تعريف النموذج المنتهي بـ .yaml و monitor_pool_name يخزن اسم مجمع العمل لنشر العامل المحافظ والتدفقات.
     3. انشر تدفق المراقبة المحافظ الذي يجلب البيانات داخليًا من PostgreSQL ويستخدم Evidently لحساب التقارير والمقاييس المتعلقة بانجراف البيانات. قم cd برمجيًا في deployments/prefect-deployments وتشغيل prefect --no-prompt deploy --name {deploy_name} باستخدام المدخلات من قسم deploy/prefect في التكوين.
     4. تمت جدولة تدفق المراقبة ليتم تشغيله أسبوعيًا ويعرف أيضًا باسم مرة واحدة في الأسبوع. ولكن يمكنك تشغيل التدفق المنشور يدويًا من Prefect UI. تحقق من مستندهم الرسمي حول كيفية القيام بذلك (بسيط جدًا ومباشر)
     5. يمكنك أيضًا عرض لوحة معلومات انجراف البيانات على Evidently UI (المنفذ 8000، افتراضيًا)

من مكان العمل إلى السحابة

نظرًا لأن كل شيء قد تم إرساءه ووضعه في حاوية بالفعل في هذا الريبو، فإن تحويل الخدمة من الخدمة المحلية إلى السحابة يعد أمرًا بسيطًا للغاية. عند الانتهاء من تطوير واختبار واجهة برمجة تطبيقات الخدمة الخاصة بك، يمكنك فقط فصل الخدمات/dl_service عن طريق إنشاء الحاوية من ملف Dockerfile الخاص بها، ودفعها إلى خدمة تسجيل حاوية سحابية (AWS ECR، على سبيل المثال). هذا كل شيء!
ملحوظة: هناك مشكلة واحدة محتملة في كود الخدمة إذا كنت تريد استخدامه في بيئة إنتاج حقيقية. لقد تناولت هذا الأمر في الفيديو المتعمق وأوصيك بقضاء بعض الوقت في مشاهدة الفيديو بأكمله.

مخططات قاعدة البيانات

لدينا ثلاث قواعد بيانات داخل PostgreSQL: واحدة لـ MLflow، وواحدة للـ Prefect، وواحدة أنشأناها لخدمة نموذج ML الخاص بنا. لن نتعمق في الأولين، حيث تتم إدارتهما ذاتيًا بواسطة تلك الأدوات. قاعدة البيانات الخاصة بخدمة نموذج ML لدينا هي تلك التي صممناها بأنفسنا.

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

جدير بالملاحظة: input_img و raw_hm_img و overlaid_img عبارة عن صور مشفرة بـ base64 ومخزنة كسلاسل. uae_feats و bbsd_feats عبارة عن مصفوفات من ميزات التضمين لخوارزميات اكتشاف الانجراف لدينا.

استكشاف الأخطاء وإصلاحها

• إذا واجهت ImportError: /lib/aarch64-linux-gnu/libGLdispatch.so.0: cannot allocate memory in static TLS block ، فحاول export LD_PRELOAD=/lib/aarch64-linux-gnu/libGLdispatch.so.0 ثم أعد تشغيل البرنامج النصي.