مشاركة عبر

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

  • مقالة

ينطبق على: Azure Data Factory Azure Synapse Analytics

تلميح

جرب Data Factory في Microsoft Fabric، وهو حل تحليلي متكامل للمؤسسات. يغطي Microsoft Fabric كل شيء بدءا من حركة البيانات إلى علم البيانات والتحليلات في الوقت الحقيقي والمعلومات المهنية وإعداد التقارير. تعرف على كيفية بدء إصدار تجريبي جديد مجانا!

توضح هذه المقالة كيفية استكشاف أخطاء مشكلة أداء نشاط النسخ في Azure Data Factory.

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

تفاصيل تشغيل مراقبة نشاط النسخ

نصائح ضبط الأداء

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

كمرجع، توفر حالياً نصائح ضبط الأداء اقتراحات للحالات التالية:

الفئة نصائح ضبط الأداء
مخزن بيانات محدد تحميل البيانات في تحليلات Azure Synapse: اقترح استخدام بيان PolyBase أو COPY إذا لم يتم استخدامه.
  نسخ البيانات من/ إلى قاعدة بيانات Azure SQL: عندما تكون وحدة الإرسال الكبرى تحت الاستخدام العالي، اقترح الترقية إلى مستوى أعلى.
  نسخ البيانات من/ إلى Azure Cosmos DB: عندما يكون RU تحت الاستخدام العالي، اقترح الترقية إلى أكبر RU.
نسخ البيانات من جدول SAP:عند نسخ كمية كبيرة من البيانات، اقترح الاستفادة من خيار تقسيم موصل SAP لتمكين التحميل المتوازي وزيادة الحد الأقصى لرقم التقسيم.
  استيعاب البيانات من Amazon Redshift: اقترح استخدام Unload إذا لم يتم استخدامه.
اختناق مخزن البيانات إذا تزاحم عدد من عمليات القراءة/الكتابة بواسطة مخزن البيانات أثناء النسخ، اقترح التحقق من معدل الطلب المسموح به لتخزين البيانات وزيادة هذا المعدل، أو تقليل حمل العمل المتزامن.
وقت تشغيل التكامل إذا كنت تستخدم وقت تشغيل تكامل مستضاف ذاتياً (IR) وينتظر نشاط النسخ طويلاً في قائمة الانتظار حتى يتوفر لدى IR مورد لتنفيذه، اقترح توسيع نطاق/زيادة وقت تشغيل التكامل الخاص بك.
  إذا كنت تستخدم وقت تشغيل تكامل Azure في والتي تعد منطقة غير مثالية ينتج عنها قراءة/كتابة بطيئة، اقترح تكوين لاستخدام وقت تشغيل التكامل في منطقة أخرى.
التسامح مع الخطأ إذا قمت بتكوين التسامح مع الخطأ ويؤدي تخطي الصفوف غير المتوافقة إلى الأداء البطيء، اقترح ضمان توافق بيانات المصدر والمتلقي.
نسخة مرحلية إذا تم تكوين نسخة مرحلية ولكن غير مفيدة لاقتران مصدر- متلقي، اقترح إزالته.
استئناف عند استئناف نشاط النسخ من نقطة الفشل الأخيرة ولكن قمت بتغيير إعداد DIU بعد التشغيل الأصلي، لاحظ أن إعداد DIU الجديد لا يسري.

فهم تفاصيل تنفيذ نشاط النسخ

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

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

- الوقت إلى البايت الأول: الوقت المنقضي بين نهاية الخطوة السابقة والوقت الذي يتلقى فيه وقت تشغيل التكامل البايت الأول من مخزن بيانات المصدر. ينطبق على المصادر غير المستندة إلى الملفات.
- مصدر الإدراج: مقدار الوقت المستغرق في حساب عدد ملفات المصدر أو أقسام البيانات. هذا الأخير ينطبق عند تكوين خيارات التقسيم لمصادر قاعدة البيانات، على سبيل المثال عند نسخ البيانات من قواعد البيانات مثلOracle/ SAP Hana / Teradata / Netezza / الخ.
-القراءة من المصدر: مقدار الوقت المستغرق في استرداد البيانات من مخزن بيانات المصدر.
- النقل إلى متلقي: مقدار الوقت المطلوب لنقل البيانات إلى مخزن بيانات المتلقي. لاحظ أن بعض الموصلات لا تحتوي على هذا المقياس في الوقت الحالي، بما في ذلك Azure الذكاء الاصطناعي Search وAzure Data Explorer وتخزين Azure Table وOracle وSQL Server و Common Data Service وDynamics 365 وDynamics CRM وSalesforce/Salesforce Service Cloud.

استكشاف أخطاء نشاط النسخ وإصلاحها على Azure IR

اتبع خطوات ضبط الأداء لتخطيط وإجراء اختبار الأداء للسيناريو الخاص بك.

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

  • "Pre-copy script" استغرقت مدة طويلة: يعني أن البرنامج النصي للنسخ المسبق يعمل على قاعدة بيانات متلقي تستغرق وقتاً طويلاً للاكتمال. اضبط منطق البرنامج النصي للنسخ المسبق لتحسين الأداء. إذا كنت بحاجة إلى مزيد من المساعدة لتحسين البرنامج النصي، اتصل بفريق قاعدة البيانات الخاص بك.

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

  • "نقل - سرد المصدر" استغرقت مدة عمل طويلة: وهذا يعني أن حساب عدد ملفات المصدر أو أقسام بيانات قاعدة بيانات المصدر بطيئة.

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

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

      • تحقق مما إذا كان يمكنك استخدام عامل التصفية الأصلي لمخزن البيانات بدلاً من ذلك، على وجه التحديد "بادئة" لتخزين Amazon S3/Azure Blob storage/Azure Files و"listAfter / listBefore" لـ ADLS Gen1. هذه الفلاتر هي عامل تصفية من جانب خادم مخزن البيانات وسيكون لها أداء أفضل بكثير.

      • خذ بعين الاعتبار تقسيم مجموعة بيانات كبيرة واحدة إلى عدة مجموعات بيانات أصغر، واسمح لهذه المهام نسخ المهمات في وقت واحد كل منها يعالج جزء من البيانات. يمكنك القيام بذلك باستخدام Lookup/GetMetadata + ForEach + Copy. راجع نسخ الملفات من حاويات متعددة أو قوالب حلول ترحيل البيانات من Amazon S3 إلى ADLS Gen2 كمثال عام.

    • تحقق مما إذا كانت الخدمة تبلغ عن أي خطأ في التحكم في المصدر أو إذا كان مخزن البيانات الخاص بك تحت حالة الاستخدام العالي. إذا كان الأمر كذلك، إما تقليل أحمال العمل على مخزن البيانات أو محاولة الاتصال بمسؤول مخزن البيانات لزيادة حد التقييد أو المورد المتوفر.

    • استخدم Azure IR في نفس منطقة مخزن بيانات المصدر أو بالقرب منها.

  • "نقل - القراءة من المصدر"استغرقت مدة عمل طويلة:

    • اعتماد بيانات خاصة بالموصل لتحميل أفضل الممارسات إذا تم تطبيقها. على سبيل المثال، عند نسخ البيانات من Amazon Redshift، قم بالتكوين لاستخدام Redshift Unload.

    • تحقق مما إذا كانت الخدمة تبلغ عن أي خطأ في التحكم في المصدر أو إذا كان مخزن البيانات الخاص بك قيد الاستخدام العالي. إذا كان الأمر كذلك، إما تقليل أحمال العمل على مخزن البيانات أو محاولة الاتصال بمسؤول مخزن البيانات لزيادة حد التقييد أو المورد المتوفر.

    • تحقق من نمط نسخ المصدر والمتلقي:

      • إذا كان نمط النسخ يدعم وحدات تكامل البيانات (DIUs) أكبر من 4 - راجع هذا القسم حول التفاصيل، فيمكنك بشكل عام محاولة زيادة وحدات DIUs للحصول على أداء أفضل.

      • وإلا، خذ بعين الاعتبار تقسيم مجموعة بيانات كبيرة واحدة إلى عدة مجموعات بيانات أصغر، واسمح لهذه المهام نسخ المهمات في وقت واحد كل منها يعالج جزء من البيانات. يمكنك القيام بذلك باستخدام Lookup/GetMetadata + ForEach + Copy. ارجع إلى نسخ الملفات من حاويات متعددة، ترحيل البيانات من Amazon S3 إلى ADLS Gen2،أو نسخ مجمع مع قوالب حل جدول التحكم كمثال عام.

    • استخدم Azure IR في نفس منطقة مخزن بيانات المصدر أو بالقرب منها.

  • "نقل - الكتابة إلى متلقي" استغرقت مدة عمل طويلة:

    • اعتماد بيانات خاصة بالموصل لتحميل أفضل الممارسات إذا تم تطبيقها. على سبيل المثال، عند نسخ البيانات إلى تحليلات Azure Synapse، استخدم عبارة PolyBase أو COPY.

    • تحقق مما إذا كانت الخدمة تبلغ عن أي خطأ اختناق على متلقي أو إذا كان مخزن البيانات الخاص بك تحت الاستخدام العالي. إذا كان الأمر كذلك، إما تقليل أحمال العمل على مخزن البيانات أو محاولة الاتصال بمسؤول مخزن البيانات لزيادة حد التقييد أو المورد المتوفر.

    • تحقق من نمط نسخ المصدر والمتلقي:

      • إذا كان نمط النسخ يدعم وحدات تكامل البيانات (DIUs) أكبر من 4 - راجع هذا القسم حول التفاصيل، فيمكنك بشكل عام محاولة زيادة وحدات DIUs للحصول على أداء أفضل.

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

    • استخدم Azure IR في نفس منطقة مخزن بيانات المتلقي أو بالقرب منها.

استكشاف نشاط النسخ وإصلاحه على وقت تشغيل التكامل المستضاف ذاتياً

اتبع خطوات ضبط الأداء لتخطيط وإجراء اختبار الأداء للسيناريو الخاص بك.

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

  • "قائمة الانتظار" استغرقت مدة طويلة: وهذا يعني نشاط نسخة ينتظر طويلاً في قائمة الانتظار حتى يكون لدى وقت تشغيل التكامل المستضاف ذاتياً الموارد للتنفيذ. تحقق من سعة واستخدام وقت تشغيل التكامل ووقم بالتوسيع أو الزيادة وفقاً لحمل العمل.

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

  • "نقل - سرد المصدر" استغرقت مدة عمل طويلة: وهذا يعني أن حساب عدد ملفات المصدر أو أقسام بيانات قاعدة بيانات المصدر بطيئة.

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

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

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

      • تحقق مما إذا كان يمكنك استخدام عامل التصفية الأصلي لمخزن البيانات بدلاً من ذلك، على وجه التحديد "بادئة" لتخزين Amazon S3/Azure Blob storage/Azure Files و"listAfter / listBefore" لـ ADLS Gen1. هذه الفلاتر هي عامل تصفية من جانب خادم مخزن البيانات وسيكون لها أداء أفضل بكثير.

      • خذ بعين الاعتبار تقسيم مجموعة بيانات كبيرة واحدة إلى عدة مجموعات بيانات أصغر، واسمح لهذه المهام نسخ المهمات في وقت واحد كل منها يعالج جزء من البيانات. يمكنك القيام بذلك باستخدام Lookup/GetMetadata + ForEach + Copy. راجع نسخ الملفات من حاويات متعددة أو قوالب حلول ترحيل البيانات من Amazon S3 إلى ADLS Gen2 كمثال عام.

    • تحقق مما إذا كانت الخدمة تبلغ عن أي خطأ في التحكم في المصدر أو إذا كان مخزن البيانات الخاص بك تحت حالة الاستخدام العالي. إذا كان الأمر كذلك، إما تقليل أحمال العمل على مخزن البيانات أو محاولة الاتصال بمسؤول مخزن البيانات لزيادة حد التقييد أو المورد المتوفر.

  • "نقل - القراءة من المصدر"استغرقت مدة عمل طويلة:

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

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

    • تحقق من CPU الخاص بوقت تشغيل التكامل المستضاف ذاتياً واتجاه استخدام الذاكرة في مدخل Microsoft Azure -> مصنع البيانات أو مساحة عمل Synapse الخاصة بك > نظرة عامة على الصفحة. خذ بعين الاعتبار توسيع نطاق وقت تشغيل التكامل إذا كان استخدام CPU عالي أو الذاكرة المتوفرة منخفضة.

    • اعتماد بيانات خاصة بالموصل لتحميل أفضل الممارسات إذا تم تطبيقها. على سبيل المثال:

      • عند نسخ البيانات من Oracle وNetezza وTeradata وSAP Hanaو SAP Table وSAP Open Hub، وتمكين خيارات قسم البيانات لنسخ البيانات في موازاة ذلك.

      • عند نسخ البيانات من HDFS، قم بالتكوين لاستخدام DistCp.

      • عند نسخ البيانات من Amazon Redshift، قم بالتكوين لاستخدام Redshift Unload.

    • تحقق مما إذا كانت الخدمة تبلغ عن أي خطأ في التحكم في المصدر أو إذا كان مخزن البيانات الخاص بك قيد الاستخدام العالي. إذا كان الأمر كذلك، إما تقليل أحمال العمل على مخزن البيانات أو محاولة الاتصال بمسؤول مخزن البيانات لزيادة حد التقييد أو المورد المتوفر.

    • تحقق من نمط نسخ المصدر والمتلقي:

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

      • وإلا، خذ بعين الاعتبار تقسيم مجموعة بيانات كبيرة واحدة إلى عدة مجموعات بيانات أصغر، واسمح لهذه المهام نسخ المهمات في وقت واحد كل منها يعالج جزء من البيانات. يمكنك القيام بذلك باستخدام Lookup/GetMetadata + ForEach + Copy. ارجع إلى نسخ الملفات من حاويات متعددة، ترحيل البيانات من Amazon S3 إلى ADLS Gen2،أو نسخ مجمع مع قوالب حل جدول التحكم كمثال عام.

  • "نقل - الكتابة إلى متلقي" استغرقت مدة عمل طويلة:

    • اعتماد بيانات خاصة بالموصل لتحميل أفضل الممارسات إذا تم تطبيقها. على سبيل المثال، عند نسخ البيانات إلى تحليلات Azure Synapse، استخدم عبارة PolyBase أو COPY.

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

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

    • تحقق من CPU الخاص بوقت تشغيل التكامل المستضاف ذاتياً واتجاه استخدام الذاكرة في مدخل Microsoft Azure -> مصنع البيانات أو مساحة عمل Synapse الخاصة بك > نظرة عامة على الصفحة. خذ بعين الاعتبار توسيع نطاق وقت تشغيل التكامل إذا كان استخدام CPU عالي أو الذاكرة المتوفرة منخفضة.

    • تحقق مما إذا كانت الخدمة تبلغ عن أي خطأ اختناق على متلقي أو إذا كان مخزن البيانات الخاص بك تحت الاستخدام العالي. إذا كان الأمر كذلك، إما تقليل أحمال العمل على مخزن البيانات أو محاولة الاتصال بمسؤول مخزن البيانات لزيادة حد التقييد أو المورد المتوفر.

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

أداء الموصل ووقت تشغيل التكامل

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

يختلف وقت تنفيذ النشاط باستخدام Azure IR مقابل Azure VNet IR

يختلف وقت تنفيذ النشاط عندما تستند مجموعة البيانات إلى وقت تشغيل تكامل مختلف.

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

  • السبب: التحقق من تفاصيل تشغيل المسارات، يمكنك مشاهدة أن المسار البطيء قيد التشغيل على وقت تشغيل الشبكة الظاهرية المدارة (VNet) بينما يعمل المسار العادي على Azure IR. حسب التصميم، تستغرق إدارة VNet IR وقتاً أطول في قائمة الانتظار من Azure IR حيث أننا لا نحتفظ بعقدة حساب واحدة لكل مثيل خدمة، لذلك هناك إحماء لكل نشاط نسخ لبدء التشغيل، ويحدث ذلك بشكل أساسي على ربط VNet بدلاً من Azure IR.

انخفاض الأداء عند تحميل البيانات في قاعدة بيانات Azure SQL

  • الأعراض: نسخ البيانات إلى قاعدة بيانات Azure SQL يتحول إلى أن يكون بطيء.

  • السبب: السبب الجذري للمشكلة هو في الغالب بسبب ازدحام جانب قاعدة بيانات Azure SQL. فيما يلي بعض الأسباب المحتملة:

    • مستوى قاعدة بيانات Azure SQL غير مرتفع بما فيه الكفاية.

    • استخدام وحدة الإرسال الكبرى لقاعدة بيانات Azure SQL قريب من 100%. يمكنك مراقبة الأداء والتفكير في ترقية الطبقة المسؤولة عن قاعدة بيانات Azure SQL.

    • لم يتم تعيين الفهارس بشكل صحيح. إزالة كافة الفهارس قبل تحميل البيانات وإعادة إنشائها بعد اكتمال التحميل.

    • WriteBatchSize ليس كبيراً بما يكفي لاحتواء حجم صف المخطط. حاول تكبير الخاصية لهذه المشكلة.

    • بدلا من إدراج مجمع، يتم استخدام الإجراء المخزّن، والذي من المتوقع أن يكون أداؤه أسوأ.

المهلة أو الأداء البطيء عند تحليل ملف Excel كبير

  • الأعراض:

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

    • عند استخدام نشاط النسخ لنسخ البيانات من ملف Excel كبير الحجم (>= 100 ميغا بايت) إلى مخزن بيانات آخر، قد يواجهك بطء في الأداء أو مشكلة OOM.

  • السبب:

    • بالنسبة لعمليات مثل استيراد المخطط ومعاينة البيانات وسرد أوراق العمل على مجموعة بيانات Excel، يكون المهلة 100 ثانية وثابتة. بالنسبة لملف Excel الكبير، قد لا تنتهي هذه العمليات في أثناء قيمة المهلة.

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

  • التحليل:

    • لاستيراد المخطط، يمكنك إنشاء ملف نموذج أصغر، وهو مجموعة فرعية من ملف أصلي، واختيار "استيراد مخطط من نموذج ملف" بدلاً من "استيراد مخطط من الاتصال/المخزن".

    • لإدراج ورقة العمل، في القائمة المنسدلة في ورقة العمل، يمكنك النقر فوق "تحرير" وإدخال اسم/ فهرس الورقة بدلاً من ذلك.

    • لنسخ ملف Excel كبير الحجم (>100 ميغابايت) إلى مخزن آخر، يمكنك استخدام مصدر Data Flow Excel الذي يقرأه البث الرياضي ويؤديه بشكل أفضل.

مشكلة OOM لقراءة ملفات JSON/Excel/XML الكبيرة

  • الأعراض: عند قراءة ملفات JSON/Excel/XML الكبيرة، تواجه مشكلة نفاد الذاكرة (OOM) أثناء تنفيذ النشاط.

  • السبب:

    • بالنسبة لملفات XML الكبيرة: مشكلة OOM لقراءة ملفات XML الكبيرة هي حسب التصميم. والسبب هو أنه يجب قراءة ملف XML بأكمله في الذاكرة لأنه كائن واحد، ثم يتم استنتاج المخطط، ويتم استرداد البيانات.
    • بالنسبة لملفات Excel الكبيرة: مشكلة OOM في قراءة ملفات Excel الكبيرة هي حسب التصميم. والسبب هو أن SDK (POI/NPOI) المستخدمة يجب أن تقرأ ملف excel بأكمله في الذاكرة، ثم استنتاج المخطط والحصول على البيانات.
    • بالنسبة لملفات JSON الكبيرة: مشكلة OOM لقراءة ملفات JSON الكبيرة هي حسب التصميم عندما يكون ملف JSON كائنا واحدا.

  • التوصية: تطبيق أحد الخيارات التالية لحل المشكلة.

    • الخيار 1: تسجيل وقت تشغيل تكامل مستضاف ذاتيا عبر الإنترنت باستخدام جهاز قوي (وحدة معالجة مركزية/ذاكرة عالية) لقراءة البيانات من ملفك الكبير من خلال نشاط النسخ.
    • الخيار 2: استخدم الذاكرة المحسنة والمجموعة ذات الحجم الكبير (على سبيل المثال، 48 ذاكرة أساسية) لقراءة البيانات من ملفك الكبير من خلال نشاط تعيين تدفق البيانات.
    • الخيار 3: تقسيم الملف الكبير إلى ملف صغير، ثم استخدام نسخ أو تعيين نشاط تدفق البيانات لقراءة المجلد.
    • الخيار 4: إذا كنت عالقا أو واجهت مشكلة OOM أثناء نسخ مجلد XML/Excel/JSON، فاستخدم نشاط foreach + نسخ/تعيين نشاط تدفق البيانات في البنية الأساسية لبرنامج ربط العمليات التجارية لمعالجة كل ملف أو مجلد فرعي.
    • الخيار 5: الآخرون:
      • بالنسبة إلى XML، استخدم نشاط دفتر الملاحظات مع نظام المجموعة المحسن للذاكرة لقراءة البيانات من الملفات إذا كان لكل ملف نفس المخطط. حاليا، لدى Spark تطبيقات مختلفة للتعامل مع XML.
      • بالنسبة إلى JSON، استخدم نماذج مستندات مختلفة (على سبيل المثال، مستند واحد ومستند لكل سطر وصفيف من المستندات) في إعدادات JSON ضمن تعيين مصدر تدفق البيانات. إذا كان محتوى ملف JSON هو Document لكل سطر، فإنه يستهلك ذاكرة قليلة جدا.

مراجع أخرى

فيما يلي مراجع مراقبة الأداء وضبط بعض مخازن البيانات المدعومة:

المحتوى ذو الصلة

راجع مقالات نشاط النسخ الأخرى: