منهجية نجاح تنفيذ Synapse: تقييم تصميم تجمع لغة الاستعلامات المركبة بلا خادم

إشعار

تمثل هذه المقالة جزءا من نجاح تنفيذ Azure Synapse بواسطة تصميم سلسلة من المقالات. لإلقاء نظرة عامة على السلسلة، راجعنجاح تنفيذ Azure Synapse بواسطة التصميم.

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

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

تحليل الثغرات المناسبة

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

التميز التشغيلي

للتميز التشغيلي، قم بتقييم النقاط التالية.

• بيئة تطوير الحل: ضمن تلك المنهجية، يوجد تقييم لبيئة تطوير الحل. تحديد كيفية تصميم البيئات (التطوير والاختبار والإنتاج) لدعم تطوير الحل. عادةً، ستجد بيئات إنتاجية وغير إنتاجية (للتطوير والاختبار). يلزمك إيجاد كساحة عمل Synapse في كافة البيئات. في أغلب الحالات، سيلزمك فصل مستخدمي الإنتاج والتطوير أو الاختبار الخاصين بك وكذلك أحمال العمل.
• تصميم مساحة عمل Synapse: يوجد ضمن تلك المنهجية تقييمًا لتصميم مساحة عمل Synapse. تحديد كيفية تصميم مساحات العمل للحل الخاص بك. تعرف على التصميم وتعرف على إن كان الحل سيستخدم مساحة عمل واحدة أو إن كانت مساحات عمل متعددة تشكل جزءًا من الحل. تعرف على سبب اختيار تصميم مساحة عمل واحدة أو متعددة. يتم غالبًا اختيار تصميم مساحات عمل متعددة لفرض حدود أمان صارمة.
• نشر: يتوفر لغة الاستعلامات المركبة بلا خادم عند الطلب مع كل مساحة عمل Synapse، لذلك لا يتطلب أي إجراءات نشر خاصة. تحقق من التقارب الإقليمي للخدمة وحساب Azure Data Lake Storage Gen2 (ADLS Gen2) المتصل به.
• المراقبة: تحقق مما إذا كانت المراقبة المدمجة كافية وإذا كانت هناك حاجة إلى وضع أي خدمات خارجية لتخزين بيانات السجل التاريخية. تسمح بيانات السجل بتحليل التغييرات في الأداء وكذلك تحديد التنبيه أو الإجراءات التي يتم تشغيلها لظروف محددة.

كفاءة الأداء

على عكس محركات قاعدة البيانات التقليدية، لا تعتمد لغة الاستعلامات المركبة بلا خادم على طبقة التخزين المحسنة الخاصة بها. لهذا السبب، يعتمد أدائه بشكل كبير على كيفية تنظيم البيانات في ADLS Gen2. لكفاءة الأداء، قم بتقييم النقاط التالية.

• استيعاب البيانات: راجع كيفية تخزين البيانات في مستودع البيانات. تؤثر أحجام الملفات وعددها وبنية المجلد على الأداء. ضع في الاعتبار أنه في حين عمل أحجام الملفات لصالح لغة الاستعلامات المركبة بلا خادم، قد يفرض ذلك مشكلات في المعالجة الفعّالة أو الاستهلاك من قِبل المحركات أو التطبيقات الأخرى. ستحتاج إلى تقييم تصميم تخزين البيانات والتحقق منها في مقابل كافة مستهلكي البيانات، والتي تشمل لغة الاستعلامات المركبة بلا خادم وغير ذلك من أدوات البيانات التي تشكل جزءًا من الحل الخاص بك.
• موضع البيانات: تقييم ما إن كان التصميم الخاص بك يحتوي على أنماط مشتركة موحدة ومحددة لموضع البيانات. تأكد من أن تفريع الدليل يمكن أن يدعم متطلبات الأمان الخاصة بك. هناك بعض الأنماط الشائعة التي يمكنها مساعدتك على الحفاظ على تنظيم بيانات السلاسل الزمنية. مهما كان اختيارك، تأكد من أنه يعمل أيضًا مع المحركات وأحمال العمل الأخرى. إضافة إلى ذلك، تحقق مما إن كان يمكنه مساعدتك في تقسيم الاكتشاف التلقائي لتطبيقات Spark والجداول الخارجية.
• تنسيقات البيانات: في معظم الحالات، توفر لغة الاستعلامات المركبة بلا خادم أفضل أداء وميزات توافق أفضل باستخدام تنسيق Parquet. تحقق من متطلبات الأداء والتوافق، لأنه في حين تحسين أداء Parquet - بفضل ضغط الإدخال والإخراج بطريقة أفضل (من خلال قراءة الأعمدة المطلوبة التي تحتاج للتحليل فحسب) - فإنها تتطلب المزيد من مصادر الحوسبة. أيضًا، نظرًا لعدم دعم بعض أنظمة المصادر لـ Parquet في الأصل بتنسيق تصدير، قد يؤدي ذلك إلى المزيد من خطوات التحويل في البنية الأساسية لبرنامج ربط العمليات التجارية و/أو التبعيات في البنية العامة.
• استكشاف: يختلف كل مجال عن غيره. مع ذلك، في كثير من الحالات، توجد أنماط شائعة للوصول إلى البيانات في الاستعلامات الأكثر تكرارًا. تشمل الأنماط عادة التصفية والتجميعات حسب التواريخ أو الفئات أو المناطق الجغرافية. حدد معايير التصفية الأكثر شيوعًا، واربطها بكمية البيانات التي تتم قراءتها/تجاهلها بواسطة الاستعلامات الأكثر تكرارًا. تحقق من تنظيم المعلومات الموجودة على مستودع البيانات لتفضيل متطلبات الاستكشاف والتوقعات الخاصة بك. بالنسبة للاستعلامات المحددة في التصميم والتقييم الخاصين بك، راجع ما إذا كان يمكنك إزالة الأقسام غير الضرورية في معلمة مسار OPENROWSET، أو - إذا كانت هناك جداول خارجية - في حال كان إنشاء المزيد من الفهارس يمكن أن يساعد.

الموثوقيه

للموثوقية، قم بتقييم النقاط التالية.

• التوافر: التحقق من صحة أي متطلبات توفر مُحددة في مرحلة التقييم. وفي حين عدم وجود أي اتفاقيات مستوى خدمة محددة لـ لغة الاستعلامات المركبة بلا خادم، يوجد مهلة مدتها 30 دقيقة لتنفيذ الاستعلام. حدد أطول استعلامات قيد التشغيل من تقييمك وتحقق من صحتها مقابل تصميم لغة الاستعلامات المركبة بلا خادم. يمكن أن تؤدي مهلة 30 دقيقة إلى كسر التوقعات لحمل العمل الخاص بك وتظهر كمشكلة خدمة.
• الاتساق: صُممت لغة الاستعلامات المركبة بلا خادم بشكل أساس لأحمال عمل القراءة. لذا، تحقق مما إذا كان قد تم إجراء جميع عمليات التحقق من التناسق أثناء تزويد بيانات مستودع البيانات وعملية التكوين. واكب القدرات الجديدة، مثل طبقة التخزين مفتوحة المصدر في Delta Lake، والتي توفر الدعم لضمانات ACID (الذرية والاتساق والعزل والمتانة) للمعاملات. تسمح لك هذه الإمكانية بتنفيذ بنيات lambda أو kappa الفعالة لدعم كل من حالات الاستخدام المتدفقة والدفعية. تأكد من تقييم تصميمك للحصول على فرص لتطبيق قدرات جديدة، لكن ليس على حساب المخطط الزمني لمشروعك أو تكلفته.
• النسخ الاحتياطي: راجع أي متطلبات للتعافي من الكوارث المُحددة أثناء التقييم. تحقق من صحتها مقابل تصميم لغة الاستعلامات المركبة بلا خادم للاسترداد. لا تحتوي لغة الاستعلامات المركبة بلا خادم نفسها على طبقة التخزين الخاصة بها، مما يتطلب معالجة اللقطات ونسخ احتياطية من بياناتك. مخزن البيانات الذي يتم الوصول إليه بواسطة لغة الاستعلامات المركبة بلا خادم خارجي (ADLS Gen2). راجع تصميم الاسترداد في مشروعك لمجموعات البيانات هذه.

الأمان

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

للأمان، قم بتقييم النقاط التالية.

• تخزين البيانات: باستخدام المعلومات التي تم جمعها أثناء مرحلة التقييم، حدد ما إذا كانت مناطق مستودع التخزين الأولية و المرحلة و المُجمعة تحتاج لوضعها في نفس حساب التخوين بدلًا من وضعها في حسابات تخزين مستقلة. قد ينتج عن هذا التأخير المزيد من المرونة في الشروط والأذونات. كما يمكنه إضافة المزيد من عمليات الإدخال/الإخراج في الثانية (IOPS) التي قد تكون مطلوبة إذا كان يجب أن تدعم البنية الخاصة بك أحمال عمل القراءة/الكتابة الثقيلة والمتزامنة (مثل سيناريوهات الوقت الحقيقي أو IoT). تحقق إن كنت بحاجة إلى الفصل عن طريق الاحتفاظ بمناطق بيئة الاختبار المعزولة والرئيسة في حسابات التخزين المنفصلة. لن يحتاج أغلب المستخدمين لتحديث أو حذف البيانات، لذا، لا يحتاجون لكتابة أذونات لمستودع البيانات باستثناء مناطق بيئة الاختبار المعزولة والخاصة.
• من معلومات التقييم الخاصة بك، حدد ما إن كانت أي متطلبات تعتمد على ميزات الأمان مثل Always Encrypted أو إخفاء البيانات الديناميكية أو الأمان على مستوى الصف. تحقق من توفر هذه الميزات في سيناريوهات محددة، مثل عند استخدامها مع الدالة OPENROWSET. يمكن أن تتطلب الحلول البديلة المحتملة.
• من معلومات التقييم الخاصة بك، حدد ما هي أفضل طرق المصادقة. ضع في اعتبارك أساسيات خدمة Microsoft Entra وتوقيع الوصول المشترك (SAS) ومتى وكيف يمكن استخدام المصادقة التمريرية ودمجها في أداة الاستكشاف التي تختارها العميل. تقييم التصميم والتحقق من أن أفضل طريقة مصادقة كجزء من التصميم.

الاعتبارات الأخرى

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

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

في المقالة التاليةفي نجاح Azure Synapse من خلال سلسلة التصميم، تعلم كيفية تقييم تصميم أداة تجمع Spark الخاصة بك لتحديد المشكلات والتحقق من اتباعها للإرشادات والمتطلبات.