كيف يعمل Logz.io على تسريع توصيات التعلم الآلي وحلول الكشف عن العيوب باستخدام Amazon SageMaker

عقدة المصدر: 1594837

Logz.io هي أحد شركاء التكنولوجيا المتقدمة لشبكة شركاء AWS (APN) كفاءات AWS في DevOps والأمان والبيانات والتحليلات. يقدم Logz.io نظامًا أساسيًا للمراقبة كخدمة (SaaS) يعتمد على حلول برمجية مفتوحة المصدر هي الأفضل في فئتها لتحليلات السجل والقياس والتتبع. يرسل العملاء كمية متزايدة من البيانات إلى Logz.io من مصادر بيانات مختلفة لإدارة صحة وأداء تطبيقاتهم وخدماتهم. قد يكون الأمر مربكًا للمستخدمين الجدد الذين يتطلعون إلى التنقل عبر لوحات المعلومات المختلفة التي تم إنشاؤها بمرور الوقت ، ومعالجة إشعارات التنبيهات المختلفة ، وتوصيل النقاط عند استكشاف مشكلات الإنتاج وإصلاحها.

يعد متوسط ​​الوقت اللازم للكشف (MTTD) ومتوسط ​​الوقت اللازم لحل المشكلة (MTTR) من المقاييس الأساسية لعملائنا. يتم حسابها عن طريق قياس الوقت الذي يبدأ فيه المستخدم في نظامنا الأساسي في التحقيق في مشكلة (مثل خفض خدمة الإنتاج) إلى النقطة التي يتوقف فيها عن القيام بإجراءات في النظام الأساسي تتعلق بالتحقيق المحدد.

لمساعدة العملاء على تقليل MTTD و MTTR ، يتحول Logz.io إلى التعلم الآلي (ML) لتقديم توصيات للوحات المعلومات والاستعلامات ذات الصلة وإجراء اكتشاف الشذوذ عبر التعلم الذاتي. نتيجة لذلك ، يتم تجهيز المستخدم العادي بالتجربة المجمعة لشركته بأكملها ، والاستفادة من حكمة الكثيرين. وجدنا أن حلنا يمكن أن يقلل MTTR بنسبة تصل إلى 20٪.

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

في هذا المنشور ، نشارك كيفية استخدام Logz.io الأمازون SageMaker لتقليل الوقت والجهد لإثبات المفهوم (POC) ، والتجارب من البحث إلى تقييم الإنتاج ، وكيف خفضنا تكلفة استدلال الإنتاج لدينا.

التحدي

حتى استخدام Logz.io لبرنامج SageMaker ، كان الوقت بين البحث واختبار POC والتجارب على الإنتاج طويلًا جدًا. كان هذا لأننا كنا بحاجة إلى إنشاء وظائف Spark لجمع البيانات وتنظيفها وتطبيعها. تطلب DevOps هذا العمل لقراءة كل مصدر بيانات. لا تعد مهارات DevOps وهندسة البيانات جزءًا من فريق ML الخاص بنا ، وقد تسبب هذا في اعتماد كبير بين الفرق.

كان التحدي الآخر هو تقديم خدمة استدلال ML لمنتجاتنا مع تحقيق نسبة التكلفة مقابل الأداء الأمثل. يدعم السيناريو الأمثل لدينا أكبر عدد ممكن من النماذج لوحدة حوسبة ، مع توفير التزامن العالي من العملاء مع العديد من الطرز. كان لدينا مرونة في وقت الاستدلال ، لأن النافذة الأولية لدفق البيانات لخدمة الاستدلال هي مجموعة من السجلات مدتها 5 دقائق.

مرحلة البحث

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

لتسريع دورة التكرار ، أردنا اختبار رمز دفاتر الملاحظات لدينا على بيانات إنتاج حقيقية ، أثناء تشغيله على نطاق واسع. علاوة على ذلك ، أردنا تجنب عنق الزجاجة في DevOps وهندسة البيانات أثناء الاختبار الأولي في الإنتاج ، مع امتلاك القدرة على عرض المخرجات ومحاولة تقدير وقت تشغيل الكود.

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

مرحلة التقييم

خلال هذه المرحلة ، قمنا بتقييم عدد قليل من منصات تعلم الآلة من أجل دعم متطلبات التدريب والخدمة. وجدنا أن SageMaker هو الأنسب لحالات الاستخدام لدينا لأنه يدعم كلاً من التدريب والاستدلال. علاوة على ذلك ، فهو قابل للتخصيص ، حتى نتمكن من تصميمه وفقًا لعملية البحث المفضلة لدينا.

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

قمنا بتقييم العديد من الحلول واخترنا أخيرًا البنية التالية:

  • لوحة البيانات - النسخة مفتوحة المصدر من لوحة البيانات ساعدنا في سحب بياناتنا والانضمام إليها بسهولة من خلال استخدام Spark أمازون EMR مجموعات باستخدام SQL بسيط ، أثناء مراقبة الوصول إلى البيانات
  • مثيل دفتر ملاحظات SageMaker ووظائف المعالجة - ساعدنا ذلك في قابلية التوسع في وقت التشغيل ومرونة أنواع الأجهزة وأطر عمل ML ، أثناء التعاون في الكود الخاص بنا عبر اتصال Git

هندسة حل مرحلة البحث

يوضح الرسم البياني التالي بنية الحل لمرحلة البحث ، ويتكون من المكونات التالية:

  • دفاتر SageMaker - يستخدمها علماء البيانات أجهزة الكمبيوتر المحمولة لإجراء أبحاثهم.
  • دالة AWS Lambda - AWS لامدا هو حل بدون خادم يدير مهمة معالجة عند الطلب. تستخدم الوظيفة حاوية Docker مع الكمبيوتر الدفتري الذي نريد تشغيله أثناء تجربتنا ، جنبًا إلى جنب مع جميع ملفاتنا الشائعة التي تحتاج إلى دعم الكمبيوتر المحمول (requirements.txt ورمز وظائف المعالجة المتعددة في دفتر ملاحظات منفصل).
  • أمازون ECR - سجل الأمازون المرنة للحاويات (Amazon ECR) يخزن حاوية Docker الخاصة بنا.
  • وظيفة معالجة SageMaker - يمكننا تشغيل هذا وظيفة معالجة البيانات على أي جهاز ML ، ويقوم بتشغيل الكمبيوتر الدفتري الخاص بنا مع المعلمات.
  • لوحة البيانات - تساعدنا هذه الخدمة في استخدام SQL والانضمام إلى العديد من مصادر البيانات بسهولة. يقوم بترجمته إلى رمز Spark وتحسينه ، أثناء مراقبة الوصول إلى البيانات والمساعدة في تقليل انتهاكات البيانات. يوفر إصدار Xtra المزيد من الإمكانات.
  • أمازون EMR - تدير هذه الخدمة عمليات استخراج البيانات لدينا كأعباء عمل فوق Spark ، والاتصال بجميع موارد البيانات لدينا.

من خلال دورة حياة مثيل دفتر الملاحظات SageMaker ، يمكننا التحكم في الحد الأقصى لوقت تشغيل مثيل الكمبيوتر الدفتري ، باستخدام autostop.py قالب النصي.

بعد اختبار أطر عمل تعلم الآلة ، اخترنا نواة SageMaker MXNet لمراحل التجميع والترتيب.

لاختبار كود الكمبيوتر المحمول على بيانات الإنتاج الخاصة بنا ، قمنا بتشغيل الكمبيوتر الدفتري من خلال تغليفه عبر Docker في Amazon ECS وتشغيله كوظيفة معالجة للتحقق من الحد الأقصى لوقت التشغيل على أنواع مختلفة من الأجهزة.

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

حل استدلال الإنتاج في الوقت الفعلي

في مرحلة البحث ، استخدمنا الباركيه خدمة تخزين أمازون البسيطة (Amazon S3) للحفاظ على توصياتنا. يتم استهلاكها مرة واحدة يوميًا من خط الأنابيب الهندسي الخاص بنا لإرفاق التوصيات بآلية التنبيهات الخاصة بنا.

ومع ذلك ، تتطلب خارطة الطريق الخاصة بنا حلاً أعلى لمعدل التحديث والسحب مرة واحدة يوميًا ليس كافيًا على المدى الطويل ، لأننا نريد تقديم توصيات حتى أثناء التحقيق.

لتنفيذ هذا الحل على نطاق واسع ، اختبرنا معظم حلول نقاط النهاية من SageMaker في بحثنا الخاص باكتشاف الشذوذ. اختبرنا 500 من النماذج سابقة البناء باستخدام آلة نقطة نهاية واحدة من أنواع مختلفة واستخدمنا عملاء متزامنين متعددي الخيوط لتنفيذ الطلبات إلى نقطة النهاية. قمنا بقياس وقت الاستجابة ووحدة المعالجة المركزية والذاكرة والمقاييس الأخرى (لمزيد من المعلومات ، انظر راقب Amazon SageMaker باستخدام Amazon CloudWatch). وجدنا أن نقطة النهاية متعددة النماذج مناسبة تمامًا لحالات الاستخدام الخاصة بنا.

يمكن أن تقلل نقطة النهاية متعددة النماذج تكاليفنا بشكل كبير مقارنة بنقطة نهاية واحدة أو حتى Kubernetes لاستخدام خدمات الويب Flask (أو Python الأخرى). كان افتراضنا الأول هو أنه يجب علينا توفير نقطة نهاية واحدة ، باستخدام آلة صغيرة 4-vCPU ، لكل عميل ، وفي المتوسط ​​استعلام أربعة نماذج مخصصة ، لأن كل وحدة vCPU تخدم نموذجًا واحدًا. من خلال نقطة النهاية متعددة النماذج ، يمكننا تجميع المزيد من العملاء على جهاز واحد متعدد النقاط الطرفية.

كان لدينا نموذج وملفات ترميز لكل عميل ، وبعد إجراء اختبارات التحميل ، قررنا أنه يمكننا خدمة 50 عميلًا ، كل منها يستخدم 10 نماذج وحتى باستخدام أصغر مثيل ml.t2.medium لحلولنا.

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

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

بعد أن قمنا بتقدير التكاليف باستخدام نقاط النهاية متعددة النماذج مقابل نقاط النهاية القياسية ، اكتشفنا أنه من المحتمل أن يؤدي ذلك إلى خفض التكلفة بنسبة 80٪ تقريبًا.

النتيجة

في هذا القسم ، نستعرض خطوات ونتائج العملية.

نستخدم تكوين دورة حياة الكمبيوتر الدفتري لتمكين تشغيل أجهزة الكمبيوتر المحمولة كوظائف معالجة ، من خلال تغليف الكمبيوتر الدفتري في حاوية Docker للتحقق من صحة الرمز بشكل أسرع واستخدام آلية التشغيل التلقائي:

#!/bin/bash # Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License"). You
# may not use this file except in compliance with the License. A copy of
# the License is located at
#
# http://aws.amazon.com/apache2.0/
#
# or in the "license" file accompanying this file. This file is
# distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF
# ANY KIND, either express or implied. See the License for the specific
# language governing permissions and limitations under the License. set -e # OVERVIEW
# This script installs the sagemaker_run_notebook extension package in SageMaker Notebook Instance
#
# There are two parameters you need to set:
# 1. S3_LOCATION is the place in S3 where you put the extension tarball
# 2. TARBALL is the name of the tar file that you uploaded to S3. You should just need to check
# that you have the version right.
sudo -u ec2-user -i <<'EOF'
# PARAMETERS
VERSION=0.18.0
EXTENSION_NAME=sagemaker_run_notebook
# Set up the user setting and workspace directories
mkdir -p /home/ec2-user/SageMaker/.jupyter-user/{workspaces,user-settings}
# Run in the conda environment that the Jupyter server uses so that our changes are picked up
source /home/ec2-user/anaconda3/bin/activate JupyterSystemEnv
# Install the extension and rebuild JupyterLab so it picks up the new UI
aws s3 cp s3://aws-emr-resources-11111111-us-east-1/infra-sagemaker/sagemaker_run_notebook-0.18.0-Logz-latest.tar.gz ./sagemaker_run_notebook-0.18.0-Logz-latest.tar.gz
pip install sagemaker_run_notebook-0.18.0-Logz-latest.tar.gz jupyter lab build
source /home/ec2-user/anaconda3/bin/deactivate
EOF # sudo -u ec2-user -i <<'EOF'
# PARAMETERS
for PACKAGE in pandas dataplate awswrangler==2.0.0 ipynb==0.5.1 prison==0.1.3 PyMySQL==0.10.1 requests==2.25.0 scipy==1.5.4 dtaidistance joblib sagemaker_run_notebook-0.18.0-Logz-latest.tar.gz fuzzywuzzy==0.18.0; do echo $PACKAGE # Note that "base" is special environment name, include it there as well. for env in base /home/ec2-user/anaconda3/envs/*; do source /home/ec2-user/anaconda3/bin/activate $(basename "$env") if [ $env = 'JupyterSystemEnv' ]; then continue fi pip install --upgrade "$PACKAGE" source /home/ec2-user/anaconda3/bin/deactivate done
done
jupyter lab build # Tell Jupyter to use the user-settings and workspaces directory on the EBS
# volume.
echo "export JUPYTERLAB_SETTINGS_DIR=/home/ec2-user/SageMaker/.jupyter-user/user-settings" >> /etc/profile.d/jupyter-env.sh
echo "export JUPYTERLAB_WORKSPACES_DIR=/home/ec2-user/SageMaker/.jupyter-user/workspaces" >> /etc/profile.d/jupyter-env.sh # The Jupyter server needs to be restarted to pick up the server part of the
# extension. This needs to be done as root.
initctl restart jupyter-server --no-wait # OVERVIEW
# This script stops a SageMaker notebook once it's idle for more than 2 hour (default time)
# You can change the idle time for stop using the environment variable below.
# If you want the notebook the stop only if no browsers are open, remove the --ignore-connections flag
#
# Note that this script will fail if either condition is not met
# 1. Ensure the Notebook Instance has internet connectivity to fetch the example config
# 2. Ensure the Notebook Instance execution role permissions to SageMaker:StopNotebookInstance to stop the notebook
# and SageMaker:DescribeNotebookInstance to describe the notebook.
# PARAMETERS
IDLE_TIME=3600 echo "Fetching the autostop script"
wget https://raw.githubusercontent.com/aws-samples/amazon-sagemaker-notebook-instance-lifecycle-config-samples/master/scripts/auto-stop-idle/autostop.py echo "Starting the SageMaker autostop script in cron" (crontab -l 2>/dev/null; echo "*/5 * * * * /usr/bin/python $PWD/autostop.py --time $IDLE_TIME --ignore-connections") | crontab -

نحن استنساخ دفتر تشغيل sagemaker مشروع GitHub ، وأضف ما يلي إلى الحاوية:

  • متطلبات النقطة لدينا
  • القدرة على تشغيل أجهزة الكمبيوتر المحمولة من داخل جهاز كمبيوتر محمول ، مما يتيح لنا سلوك المعالجة المتعددة للاستفادة من جميع أنوية المثيل ml.m5.12xlarge

يتيح لنا ذلك تشغيل مهام سير العمل التي تتكون من العديد من دفاتر الملاحظات التي تعمل كوظائف معالجة في سطر من التعليمات البرمجية ، مع تحديد نوع المثيل الذي سيتم تشغيله عليه.

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

يمكننا أيضًا إنشاء وظائف جدولة تعمل على تشغيل دفاتر الملاحظات (وحتى تحديد وقت التشغيل).

يمكننا أيضًا ملاحظة عمليات التشغيل الأخيرة وتفاصيلها ، مثل وقت المعالجة.

باستخدام علبة الورق المستخدمة في الحاوية ، يمكننا عرض مخرجات كل عملية تشغيل ، مما يساعدنا في تصحيح الأخطاء في الإنتاج.

تكون مراجعة إخراج الكمبيوتر الدفتري في شكل دفتر ملاحظات قياسي للقراءة فقط.

يساعدنا استخدام المعالجة المتعددة على التوسع في معالجة كل كمبيوتر محمول والاستفادة من جميع النوى. أنشأنا وظائف في دفاتر ملاحظات أخرى يمكنها القيام بمعالجة مكثفة ، مثل ما يلي:

  • تفجير JSONs
  • ابحث عن الصفوف ذات الصلة في DataFrame أثناء تقسيم دفتر الملاحظات الرئيسي إلى DataFrame #cpu-cores عناصر
  • تشغيل المجموعات لكل نوع من إجراءات التنبيه في وقت واحد

ثم نضيف هذه الدفاتر الوظيفية في الحاوية التي تشغل الكمبيوتر المحمول كوظيفة معالجة. انظر ملف Docker التالي (لاحظ أوامر COPY):

ARG BASE_IMAGE=need_an_image
FROM $BASE_IMAGE ENV JUPYTER_ENABLE_LAB yes
ENV PYTHONUNBUFFERED TRUE COPY requirements.txt /tmp/requirements.txt
RUN pip install papermill jupyter nteract-scrapbook boto3 requests==2.20.1
RUN pip install -r /tmp/requirements.txt ENV PYTHONUNBUFFERED=TRUE
ENV PATH="/opt/program:${PATH}" # Set up the program in the image
COPY multiprocessDownloadNormalizeFunctions.ipynb /tmp/multiprocessDownloadNormalizeFunctions.ipynb
COPY multiprocessFunctions.ipynb /tmp/multiprocessFunctions.ipynb
COPY run_notebook execute.py /opt/program/
ENTRYPOINT ["/bin/bash"] # because there is a bug where you have to be root to access the directories
USER root

النتائج

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

أثناء تقييم الاستدلال ، قمنا بتقييم العديد من حلول نقاط النهاية من SageMaker. لقد وجدنا أن استخدام نقطة نهاية متعددة النماذج يمكن أن يساعدنا في خدمة ما يقرب من 50 عميلًا ، لكل منها نماذج متعددة (حوالي 10) في حالة واحدة ، والتي يمكن أن تلبي قيود زمن الوصول المنخفض ، وبالتالي توفر لنا ما يصل إلى 80٪ من التكلفة .

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

الخلاصة والخطوات التالية

في هذا المنشور ، شاركنا كيف استخدم Logz.io SageMaker لتحسين MTTD و MTTR.

كخطوة تالية ، نحن نفكر في توسيع الحل بالميزات التالية:

نحن نشجعك على المحاولة دفاتر SageMaker. لمزيد من الأمثلة ، تحقق من ملف أمثلة SageMaker GitHub repo.


حول المؤلف

أميت جروس يقود قسم الأبحاث في Logz.io ، وهو المسؤول عن حلول الذكاء الاصطناعي لجميع منتجات Logz.io ، من مرحلة البحث إلى مرحلة التكامل. قبل Logz.io ، كان أميت يدير كلاً من مجموعات أبحاث علوم البيانات والأمن في Here inc. و Cellebrite المؤتمر الوطني العراقي. أميت حاصل على ماجستير في علوم الكمبيوتر من جامعة تل أبيب.

يانيف فاكنين هو متخصص في التعلم الآلي في Amazon Web Services. قبل AWS ، شغل يانيف مناصب قيادية مع الشركات الناشئة والخاصة بالذكاء الاصطناعي بما في ذلك المؤسس المشارك والرئيس التنفيذي لشركة Dipsee.ai. تعمل Yaniv مع عملاء AWS لتسخير قوة التعلم الآلي لحل مهام العالم الحقيقي واشتقاق القيمة. في أوقات فراغه ، يستمتع يانيف بلعب كرة القدم مع أولاده.

ايتان سيلا هو مهندس حلول متخصص في التعلم الآلي مع Amazon Web Services. إنه يعمل مع عملاء AWS لتقديم التوجيه والمساعدة الفنية ، ومساعدتهم في بناء وتشغيل حلول التعلم الآلي على AWS. في أوقات فراغه ، يستمتع إيتان بالركض وقراءة أحدث مقالات التعلم الآلي.

المصدر: https://aws.amazon.com/blogs/machine-learning/how-logz-io-accelerates-ml-recommendations-and-anomaly-detection-solutions-with-amazon-sagemaker/

الطابع الزمني:

اكثر من AWS مدونة التعلم الآلي