أنماط ومقاييس إمكانية المراقبة لضبط الأداء

يوضح هذا الحل أنماط المراقبة والمقاييس لتحسين أداء معالجة نظام البيانات الضخمة الذي يستخدم Azure Databricks.

بناء الأنظمة

قم بتنزيل ملف Visio لهذه البنية.

‏‏سير العمل‬

يشتمل الحل علي الخطوات التالية:

1. يرسل الخادم ملف GZIP كبير يتم تجميعه بواسطة العميل إلى المجلد المصدر في Azure Data Lake Storage.

2. ثم يرسل Data Lake Storage ملف عميل تم استخراجه بنجاح إلى Azure Event Grid، والذي يحول بيانات ملف العميل إلى عدة رسائل.

3. ترسل Azure Event Grid الرسائل إلى خدمة Azure Queue Storage، والتي تخزنها في قائمة انتظار.

4. يرسل Azure Queue Storage قائمة الانتظار إلى النظام الأساسي لتحليلات بيانات Azure Databricks للمعالجة.

5. يقوم Azure Databricks بفك حزم بيانات قائمة الانتظار ومعالجتها في ملف تمت معالجته يرسله مرة أخرى إلى Data Lake Storage:

   1. إذا كان الملف المعالج صالحًا، فسينتقل إلى المجلد Landing.

   2. وإلا، فسينتقل الملف إلى شجرة المجلد Bad. في البداية، ينتقل الملف إلى المجلد الفرعي إعادة المحاولة ، ويحاول Data Lake Storage معالجة ملفات العميل مرة أخرى (الخطوة 2). إذا كان زوج من محاولات إعادة المحاولة لا يزال يؤدي إلى إرجاع Azure Databricks للملفات المعالجة غير الصالحة، فسينتقل الملف المعالج إلى المجلد الفرعي Failure.

6. كما يقوم Azure Databricks بفك البيانات ومعالجتها في الخطوة السابقة، فإنه يرسل أيضًا سجلات التطبيق والمقاييس إلى Azure Monitor للتخزين.

7. تطبق مساحة عمل Azure Log Analytics استعلامات Kusto على سجلات التطبيق والمقاييس من Azure Monitor لاستكشاف الأخطاء وإصلاحها والتشخيص العميق.

المكونات

• Azure Data Lake Storage هو مجموعة من القدرات المخصصة لعمليات تحليل البيانات الضخمة.
• تتيح Azure Event Grid للمطور إنشاء تطبيقات بسهولة باستخدام البنى القائمة على الأحداث.
• Azure Queue Storageهي خدمة لتخزين أعداد كبيرة من الرسائل. تسمح بالوصول إلى الرسائل من أي مكان في العالم عبر المكالمات المُصدق عليها باستخدام HTTP أو HTTPS. يمكنك استخدام قوائم الانتظار لإنشاء تراكم العمل لمعالجته بشكل غير متزامن.
• Azure Databricks هو نظام أساسي لتحليل البيانات محسن للنظام الأساسي السحابي Azure. إحدى البيئتين التي يقدمها Azure Databricks لتطوير تطبيقات كثيفة الاستخدام للبيانات هي مساحة عمل Azure Databricks، وهي محرك تحليلات موحد قائم على Apache Spark لمعالجة البيانات على نطاق واسع.
• يجمع Azure Monitor بيانات تتبع الاستخدام للتطبيق ويحللها، مثل مقاييس الأداء وسجلات النشاط.
• Azure Log Analytics هو أداة تستخدم لتحرير وتشغيل استعلامات السجلات بالبيانات.

تفاصيل السيناريو

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

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

• مقاييس التطبيق المخصصة
• دفق أحداث الاستعلام
• رسائل سجل التطبيق

يمكن لـAzure Databricks إرسال بيانات المراقبة هذه إلى خدمات تسجيل مختلفة، مثل Azure Log Analytics.

يوضح هذا السيناريو استيعاب مجموعة كبيرة من البيانات التي تم تجميعها بواسطة العميل وتخزينها في ملف أرشيف GZIP. السجلات التفصيلية غير متوفرة من Azure Databricks خارج واجهة مستخدم Apache Spark™ في الوقت الحقيقي، لذلك يحتاج فريقك إلى طريقة لتخزين جميع البيانات لكل عميل، ثم القياس والمقارنة. مع سيناريو بيانات كبير، من المهم العثور على مجموعة منفذ تركيبة مثالية وحجم الجهاز الظاهري (VM) لأسرع وقت معالجة. بالنسبة لسيناريو العمل هذا، يعتمد التطبيق العام على سرعة متطلبات الاستيعاب والاستعلام، بحيث لا ينخفض معدل نقل النظام بشكل غير متوقع مع زيادة حجم العمل. يجب أن يضمن السيناريو أن النظام يفي باتفاقيات مستوى الخدمة (SLAs) التي تم إنشاؤها مع عملائك.

حالات الاستخدام المحتملة

تتضمن السيناريوهات التي يمكن أن تستفيد من هذا الحل ما يلي:

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

الاعتبارات

تنفذ هذه الاعتبارات ركائز Azure Well-Architected Framework، وهو عبارة عن مجموعة من المبادئ التوجيهية التي يمكن استخدامها لتحسين جودة حمل العمل. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.

ضع هذه النقاط في الاعتبار عند النظر في هذه البنية:

• يمكن لـAzure Databricks تخصيص موارد الحوسبة اللازمة لوظيفة كبيرة تلقائيًا، ما يتجنب المشاكل التي تقدمها الحلول الأخرى. على سبيل المثال، مع التحجيم التلقائي المحسن لـDatabricks على Apache Spark، قد يتسبب التوفير المفرط في استخدام الموارد دون المستوى الأمثل. أو قد لا تعرف عدد المنفذين المطلوبين للوظيفة.

• يمكن أن يصل حجم رسالة في Azure Queue Storage إلى 64 كيلوبايت. قد تحتوي قائمة الانتظار على ملايين رسائل قائمة الانتظار، حتى الحد الأقصى للسعة الإجمالية لحساب التخزين.

تحسين التكلفة

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

استخدم حاسبة أسعار Azure لتقدير تكلفة تنفيذ هذا الحل.

نشر هذا السيناريو

للحصول على جميع سجلات العملية ومعلوماتها، قم بإعداد Azure Log Analytics ومكتبة مراقبة Azure Databricks. تقوم مكتبة المراقبة ببث الأحداث على مستوى Apache Spark ومقاييس Spark Structured Streaming من وظائفك إلى Azure Monitor. لا تحتاج إلى إجراء أي تغييرات على التعليمات البرمجية للتطبيق الخاص بك لهذه الأحداث والمقاييس.

خطوات إعداد ضبط الأداء لنظام البيانات الضخمة هي كما يلي:

1. في مدخل Microsoft Azure، قم بإنشاء مساحة عمل Azure Databricks. انسخ معرف اشتراك Azure (معرف فريد عمومي (GUID) واحفظه واسم مجموعة الموارد واسم مساحة عمل Databricks وعنوان URL لمدخل مساحة العمل لاستخدامها لاحقا.

2. في مستعرض ويب، انتقل إلى عنوان URL لمساحة عمل Databricks وقم بإنشاء رمز مميز للوصول الشخصي لـDatabricks. انسخ واحفظ سلسلة الرمز المميز التي تظهر (التي تبدأ بـdapi وقيمة سداسية عشرية مكونة من 32 حرفًا) لاستخدامها لاحقًا.

3. استنساخ مستودع GitHub mspnp/spark-monitoring على الكمبيوتر المحلي. يحتوي هذا المستودع على التعليمات البرمجية المصدر للمكونات التالية:

   • قالب Azure Resource Manager (قالب ARM) لإنشاء مساحة عمل Azure Log Analytics، والتي تقوم أيضا بتثبيت الاستعلامات التي تم إنشاؤها مسبقا لجمع مقاييس Spark
   • مكتبات مراقبة Azure Databricks
   • نموذج التطبيق لإرسال مقاييس التطبيق وسجلات التطبيق من Azure Databricks إلى Azure Monitor

4. باستخدام الأمر Azure CLI لنشر قالب ARM، قم بإنشاء مساحة عمل Azure Log Analytics مع استعلامات قياس Spark التي تم إنشاؤها مسبقًا. من إخراج الأمر، انسخ الاسم الذي تم إنشاؤه واحفظه لمساحة عمل Log Analytics الجديدة (بتنسيق spark-monitoring-<randomized-string>).

5. في مدخل Microsoft Azure، انسخ وحفظ معرف مساحة عمل Log Analytics والمفتاح للاستخدام لاحقًا.

6. قم بتثبيت Community Edition من IntelliJ IDEA، وهي بيئة تطوير متكاملة (IDE) تحتوي على دعم مضمن لمجموعة تطوير Java (JDK) وApache Maven. إضافة المكون الإضافي Scala.

7. باستخدام IntelliJ IDEA، أنشئ مكتبات مراقبة Azure Databricks. للقيام بخطوة الإنشاء الفعلية، حدد عرض>أداة Windows>Maven لإظهار نافذة أدوات Maven، ثم حدد تنفيذحزمة Mvn الهدف >Maven.

8. باستخدام أداة تثبيت حزمة Python، قم بتثبيت Azure Databricks CLI وإعداد المصادقة باستخدام رمز الوصول الشخصي Databricks الذي نسخته سابقًا.

9. قم بتكوين مساحة عمل Azure Databricks عن طريق تعديل البرنامج النصي Databricks init مع قيم Databricks وLog Analytics التي نسختها سابقًا، ثم استخدام Azure Databricks CLI لنسخ البرنامج النصي init ومكتبات مراقبة Azure Databricks إلى مساحة عمل Databricks.

10. في مدخل مساحة عمل Databricks، قم بإنشاء وتكوين مجموعة Azure Databricks.

11. في IntelliJ IDEA، أنشئ نموذج التطبيق باستخدام Maven. ثم في مدخل مساحة عمل Databricks، قم بتشغيل نموذج التطبيق لإنشاء نماذج من السجلات والمقاييس لـAzure Monitor.

12. في أثناء تشغيل عينة المهمة في Azure Databricks، انتقل إلى مدخل Microsoft Azure لعرض أنواع الأحداث والاستعلام عنها (سجلات التطبيق والمقاييس) في واجهة Log Analytics:

    1. حدد الجداول>سجلات مخصصة لعرض مخطط الجدول لأحداث مستمع Spark (SparkListenerEvent_CL) وأحداث تسجيل Spark (SparkLoggingEvent_CL) ومقاييس Spark (SparkMetric_CL).
    2. حدد Query explorer>Saved Queries>Spark Metrics لعرض الاستعلامات التي تمت إضافتها عند إنشاء مساحة عمل Log Analytics وتشغيلها.

    اقرأ المزيد حول عرض الاستعلامات المعدة مسبقًا والمخصصة وتشغيلها في القسم التالي.

الاستعلام عن السجلات والمقاييس في Azure Log Analytics

الوصول إلى الاستعلامات التي تم إنشاؤها مسبقًا

يتم سرد أسماء الاستعلامات التي تم إنشاؤها مسبقًا لاسترداد مقاييس Spark أدناه.

كتابة استعلامات مخصصة

يمكنك أيضًا كتابة الاستعلامات الخاصة بك بلغة استعلام Kusto (KQL). ما عليك سوى تحديد الجزء الأوسط العلوي، والذي يمكن تحريره، وتخصيص الاستعلام لتلبية احتياجاتك.

يسحب الاستعلامان التاليان البيانات من أحداث تسجيل Spark:

SparkLoggingEvent_CL | where logger_name_s contains "com.microsoft.pnp"

SparkLoggingEvent_CL
| where TimeGenerated > ago(7d)
| project TimeGenerated, clusterName_s, logger_name_s
| summarize Count=count() by clusterName_s, logger_name_s, bin(TimeGenerated, 1h)

وهذان المثالان هما استعلامات في سجل مقاييس Spark:

SparkMetric_CL
| where name_s contains "executor.cpuTime"
| extend sname = split(name_s, ".")
| extend executor=strcat(sname[0], ".", sname[1])
| project TimeGenerated, cpuTime=count_d / 100000

SparkMetric_CL
| where name_s contains "driver.jvm.total."
| where executorId_s == "driver"
| extend memUsed_GB = value_d / 1000000000
| project TimeGenerated, name_s, memUsed_GB
| summarize max(memUsed_GB) by tostring(name_s), bin(TimeGenerated, 1m)

مصطلحات الاستعلام

يوضح الجدول التالي بعض المصطلحات المستخدمة عند إنشاء استعلام لسجلات التطبيق والمقاييس.

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

معدل نقل النظام

حالة تشغيل مهمة Spark

استخدام موارد النظام

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

للحصول على تعريفات أكثر تفصيلًا لكل مقياس، راجع المرئيات في لوحات المعلومات على موقع الويب هذا، أو راجع قسم المقاييس في وثائق Apache Spark.

تقييم خيارات ضبط الأداء

تعريف الأساس

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

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

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

إذا نظرت أكثر إلى تلك الـ40 ثانية، فسترى البيانات أدناه للمراحلك:

عند علامة 19:30، هناك مرحلتين: مرحلة برتقالية من 10 ثوانٍ، ومرحلة خضراء في 30 ثانية. راقب ما إذا كانت مرحلة ما ترتفع، لأن الارتفاع يشير إلى تأخير في مرحلة.

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

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

الآن مراقبة وقت المعالجة. نظرًا لأن لديك سيناريو دفق، انظر إلى معدل نقل البث.

في مخطط معدل النقل المتدفق/زمن انتقال الدفعة أعلاه، يمثل الخط البرتقالي معدل الإدخال (صفوف الإدخال في الثانية). يمثل الخط الأزرق معدل المعالجة (الصفوف المعالجة في الثانية). في بعض النقاط، لا يلتقط معدل المعالجة معدل الإدخال. المشكلة المحتملة هي أن ملفات الإدخال تتراكم في قائمة الانتظار.

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

التحقيق في التقسيم

أولًا، حدد أيضًا العدد الصحيح لمنفذي التحجيم الذين تحتاج إليهم مع Azure Databricks. تطبيق قاعدة الإبهام لتعيين كل قسم مع وحدة المعالجة المركزية المخصصة في تشغيل المنفذين. على سبيل المثال، إذا كان لديك 200 مفتاح قسم، يجب أن يساوي عدد وحدات المعالجة المركزية مضروبًا في عدد المنفذين 200. (على سبيل المثال، ستكون ثماني وحدات معالجة مركزية مقترنة بـ25 منفذًا مطابقة جيدة.) باستخدام 200 مفتاح قسم، يمكن لكل منفذ العمل على مهمة واحدة فقط، ما يقلل من فرصة حدوث ازدحام.

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

تتبع الأخطاء

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

تعرض لوحة المعلومات هذه عدد الأخطاء ورسالة الخطأ ومعرف المهمة لتصحيح الأخطاء. في الرسالة، يمكنك بسهولة تتبع الخطأ مرة أخرى إلى ملف الخطأ. هناك عدة ملفات في خطأ في أثناء القراءة. يمكنك مراجعة المخطط الزمني العلوي والتحقيق في النقاط المحددة في الرسم البياني (16:20 و16:40).

اختناقات أخرى

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

ملخص تقييم ضبط الأداء

بالنسبة لهذا السيناريو، حددت هذه المقاييس الملاحظات التالية:

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

لتشخيص هذه المشكلات، استخدمت المقاييس التالية:

• زمن انتقال المهمة
• زمن انتقال المرحلة
• زمن انتقال المهمة
• دفق معدل النقل
• مدة المهمة (الحد الأقصى، المتوسط، الحد الأدنى) لكل مرحلة
• تتبع الخطأ (العدد والرسالة ومعرف المهمة)

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكاتب الرئيسي:

• ديفيد ماكغي | مدير البرنامج الأساسي

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

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

• اقرأ البرنامج التعليمي Log Analytics.
• مراقبة Azure Databricks في مساحة عمل Azure Log Analytics
• نشر Azure Log Analytics باستخدام مقاييس Spark
• أنماط إمكانية المراقبة

الموارد ذات الصلة

• إرسال سجلات تطبيق Azure Databricks إلى Azure Monitor
• استخدام لوحات المعلومات لتصور قياسات Azure Databricks
• أفضل الممارسات لمراقبة التطبيقات والخدمات السحابية
• نمط إعادة المحاولة