دليل القياس المتوازي لـ Amazon Redshift ونتائج الاختبار

في Skyeng نستخدم Amazon Redshift، بما في ذلك القياس المتوازي، لذلك وجدنا هذه المقالة التي كتبها ستيفان جرومول، مؤسس dotgo.com، لـ intermix.io مثيرة للاهتمام. بعد الترجمة، القليل من خبرتنا من مهندس البيانات دانيار بيلخودجايف.

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

يوفر القياس المتوازي لـ Amazon Redshift لمجموعات Redshift سعة إضافية للتعامل مع أحجام الطلبات القصوى. إنه يعمل عن طريق نقل الطلبات إلى مجموعات "موازية" جديدة في الخلفية. يتم توجيه الطلبات بناءً على تكوين وقواعد WLM.

يعتمد تسعير القياس الموازي على نموذج ائتماني ذو طبقة مجانية. فوق الاعتمادات المجانية، يعتمد الدفع على الوقت الذي تقوم فيه مجموعة القياس الموازي بمعالجة الطلبات.

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

متطلبات الكتلة

لاستخدام القياس المتوازي، يجب أن تستوفي مجموعة Amazon Redshift الخاصة بك المتطلبات التالية:

- منصة: EC2-VPC؛
- نوع العقدة: dc2.8xlarge أو ds2.8xlarge أو dc2.large أو ds2.xlarge؛
- عدد العقد: من 2 إلى 32 (مجموعات العقدة الواحدة غير مدعومة).

أنواع الطلبات المقبولة

القياس المتوازي غير مناسب لجميع أنواع الاستعلامات. في الإصدار الأول، يقوم فقط بمعالجة طلبات القراءة التي تستوفي ثلاثة شروط:

- استعلامات SELECT للقراءة فقط (على الرغم من التخطيط لمزيد من الأنواع)؛
- لا يشير الاستعلام إلى جدول بأسلوب الفرز المتداخل؛
- لا يستخدم الاستعلام Amazon Redshift Spectrum للإشارة إلى جداول خارجية.

ليتم توجيهه إلى مجموعة القياس الموازي، يجب وضع الطلب في قائمة الانتظار. بالإضافة إلى ذلك، الاستعلامات المؤهلة لقائمة الانتظار SQA (تسريع الاستعلام القصير)، لن يتم تشغيله على مجموعات ذات نطاق متوازي.

تتطلب قوائم الانتظار وSQA التكوين المناسب إدارة أحمال العمل ذات التحول الأحمر (WLM). نوصي بتحسين WLM الخاص بك أولاً - وهذا سوف يقلل الحاجة إلى القياس المتوازي. وهذا مهم لأن القياس الموازي يكون مجانيًا فقط لعدد معين من الساعات. تدعي AWS أن التوسع الموازي سيكون مجانيًا لـ 97% من العملاء، وهو ما يقودنا إلى مسألة التسعير.

تكلفة التوسع الموازي

تقدم AWS نموذجًا ائتمانيًا للتوسع المتوازي. كل كتلة نشطة الأمازون الأحمر تتراكم الأرصدة كل ساعة، حتى ساعة واحدة من أرصدة التوسع الموازية المجانية يوميًا.

لن تدفع إلا عندما يتجاوز استخدام مجموعات القياس المتوازية مبلغ الاعتمادات التي تلقيتها.

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

إطلاق التحجيم الموازي

يتم تشغيل القياس المتوازي لكل قائمة انتظار WLM. انتقل إلى وحدة تحكم AWS Redshift وحدد إدارة حمل العمل من قائمة التنقل اليمنى. حدد مجموعة معلمات WLM الخاصة بمجموعتك من القائمة المنسدلة التالية.

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

ترتيب

يعمل القياس المتوازي عن طريق إعادة توجيه الطلبات المناسبة إلى مجموعات مخصصة جديدة. المجموعات الجديدة لها نفس الحجم (نوع وعدد العقد) مثل المجموعة الرئيسية.

العدد الافتراضي للمجموعات المستخدمة للقياس المتوازي هو واحد (1)، مع إمكانية تكوين ما يصل إلى إجمالي عشر (10) مجموعات.
يمكن تعيين العدد الإجمالي للمجموعات للقياس المتوازي بواسطة المعلمة max_concurrency_scaling_clusters. زيادة قيمة هذه المعلمة توفر مجموعات زائدة عن الحاجة.

رصد

هناك العديد من الرسوم البيانية الإضافية المتوفرة في وحدة تحكم AWS Redshift. يعرض مخطط الحد الأقصى لمجموعات قياس العملة المتزامنة قيمة max_concurrency_scaling_clusters بمرور الوقت.

يتم عرض عدد مجموعات القياس النشطة في واجهة المستخدم في قسم "نشاط القياس المتزامن":

في علامة التبويب الاستعلامات، يوجد عمود يشير إلى ما إذا كان الاستعلام قد تم تنفيذه في المجموعة الرئيسية أو في مجموعة القياس المتوازي:

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

تشير القيمة 1 إلى أنه تم تنفيذ الاستعلام في مجموعة المقياس الموازي، بينما تشير القيم الأخرى إلى أنه تم تنفيذه في المجموعة الأساسية.

على سبيل المثال:

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

النتائج

بدأ المؤلفون القياس المتوازي لقائمة انتظار واحدة في المجموعة الداخلية في حوالي الساعة 18:30:00 بتوقيت جرينتش يوم 29.03.2019/3/20. تم تغيير المعلمة max_concurrency_scaling_clusters إلى 30 في حوالي الساعة 00:29.03.2019:XNUMX يوم XNUMX/XNUMX/XNUMX.

لمحاكاة قائمة انتظار الطلبات، قمنا بتقليل عدد الفتحات لقائمة الانتظار هذه من 15 إلى 5.

يوجد أدناه مخطط لوحة معلومات intermix.io يوضح عدد الطلبات الجاري تشغيلها وقائمة الانتظار بعد تقليل عدد الفتحات.

نرى أن وقت انتظار الطلبات في قائمة الانتظار قد زاد، حيث أصبح الحد الأقصى للوقت أكثر من 5 دقائق.

فيما يلي المعلومات ذات الصلة من وحدة تحكم AWS حول ما حدث خلال هذا الوقت:

أطلق Redshift ثلاث (3) مجموعات قياس متوازية كما تم تكوينها. يبدو أن هذه المجموعات لم يتم استغلالها بشكل كافٍ، على الرغم من أن العديد من الطلبات في مجموعتنا كانت في قائمة الانتظار.

يرتبط الرسم البياني للاستخدام بالرسم البياني لنشاط القياس:

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

النتائج

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

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

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

على الرغم من أن القياس المتوازي ليس حلاً عالميًا لإعداد WLM، إلا أن استخدام هذه الميزة يعد أمرًا بسيطًا ومباشرًا.

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

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

تعليق من دانيار بيلخودجايف، مهندس بيانات Skyeng

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

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

هذا جعل من الممكن، إن لم يكن حل مشكلة قوائم الانتظار بالكامل، على الأقل جعل الوضع مقبولًا.

تتزامن ملاحظاتنا إلى حد كبير مع انطباعات الرجال من intermix.io.

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

بعد أن تخلصنا من الأحمال غير الطبيعية في أبريل، دخلنا، كما توقعت AWS، في وضع الاستخدام العرضي - ضمن المعيار المجاني.
يمكنك تتبع تكاليف التوسع الموازي في AWS Cost Explorer. يتعين عليك تحديد الخدمة - التحول نحو الأحمر، ونوع الاستخدام - CS، على سبيل المثال USW2-CS:dc2.large.

يمكنك قراءة المزيد عن الأسعار باللغة الروسية هنا.

المصدر: www.habr.com