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

الأمازون الأحمر إدارة عبء العمل (WLM) يساعدك على زيادة إنتاجية الاستعلام والحصول على أداء متسق لأحمال عمل التحليلات الأكثر تطلبًا من خلال الاستخدام الأمثل لموارد مستودع البيانات الحالي لديك.

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

التحكم في الوصول المستند إلى الدور (RBAC) هو تحسين جديد يساعدك على تبسيط إدارة امتيازات الأمان في Amazon Redshift. يمكنك استخدام RBAC للتحكم في وصول المستخدم النهائي إلى البيانات على مستوى واسع أو تفصيلي بناءً على دوره الوظيفي. لقد قدمنا ​​الدعم ل أدوار التحول الأحمر في طوابير WLM، سوف تجد الآن أدوار المستخدمين الرائعة بالإضافة إلى مجموعات الاعضاء و مجموعات الاستعلام كآلية توجيه الاستعلام.

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

نظرة عامة على حالة الاستخدام

تعد exampleCorp مؤسسة تستخدم Amazon Redshift لتحديث منصة البيانات والتحليلات الخاصة بها. لديهم مجموعة متنوعة من أعباء العمل مع المستخدمين من مختلف الأقسام والشخصيات. تختلف متطلبات الأداء على مستوى الخدمة حسب طبيعة عبء العمل وشخصيات المستخدم التي تصل إلى مجموعات البيانات. ترغب شركة exampleCorp في إدارة الموارد والأولويات في Amazon Redshift باستخدام قوائم انتظار WLM. بالنسبة لهذه البنية متعددة المستأجرين حسب القسم، يمكن لـ exampleCorp تحقيق عزل القراءة/الكتابة باستخدام مشاركة بيانات Amazon Redshift الميزة وتلبية متطلبات قياس الحوسبة غير المتوقعة باستخدام تحجيم التزامن.

يوضح الشكل التالي شخصيات المستخدم وإمكانية الوصول في exampleCorp.

لدى exampleCorp مجموعات متعددة من Redshift. في هذه التدوينة نركز على ما يلي:

• منصة مستودع بيانات المؤسسة (EDW). - يحتوي هذا على جميع أعباء عمل الكتابة، إلى جانب بعض التطبيقات التي يتم تشغيلها للقراءة عبر واجهة برمجة تطبيقات Redshift Data. يتم الوصول إلى البيانات الموحدة للمؤسسة من مجموعة EDW من خلال مجموعات المستهلكين المتعددة باستخدام ميزة مشاركة بيانات Redshift لتشغيل التقارير النهائية ولوحات المعلومات وأحمال عمل التحليلات الأخرى.
• سوق بيانات التسويق - يحتوي هذا على أحمال عمل يمكن التنبؤ بها للاستخراج والتحويل والتحميل (ETL) وذكاء الأعمال (BI) في أوقات محددة من اليوم. يفهم مسؤول المجموعة متطلبات الموارد الدقيقة حسب نوع حمل العمل.
• سوق بيانات المراجع – يتم استخدام هذا فقط لبضع ساعات يوميًا لتشغيل التقارير المجدولة.

ترغب شركة exampleCorp في إدارة أعباء العمل الخاصة بها بشكل أفضل باستخدام WLM.

حل نظرة عامة

كما ناقشنا في القسم السابق، تمتلك شركة exampleCorp العديد من مستودعات بيانات Redshift: مستودع بيانات مؤسسي واحد ومستودعين بيانات Redshift النهائيين. يحتوي كل مستودع بيانات على أعباء عمل واتفاقيات مستوى الخدمة ومتطلبات التزامن مختلفة.

سيقوم مسؤول قاعدة البيانات (DBA) بتنفيذ إستراتيجيات WLM المناسبة على كل مستودع بيانات Redshift بناءً على حالة الاستخدام الخاصة به. في هذه التدوينة نستخدم الأمثلة التالية:

• يوضح مستودع بيانات المؤسسة Auto WLM مع أولويات الاستعلام
• تعرض مجموعة سوق بيانات التسويق دليل WLM
• يستخدم فريق المدققين سوق البيانات الخاص بهم بشكل غير متكرر لأعباء العمل المتفرقة؛ هم يستخدمون أمازون Redshift Serverless، والذي لا يتطلب إدارة عبء العمل

يوضح الرسم البياني التالي بنية الحل.

المتطلبات الأساسية المسبقة

قبل البدء في هذا الحل، تحتاج إلى ما يلي:

• حساب AWS
• الوصول الإداري إلى Amazon Redshift

لنبدأ بفهم بعض المفاهيم الأساسية قبل حل بيان المشكلة الخاص بـ exampleCorp. أولاً، كيفية الاختيار بين WLM التلقائي مقابل WLM اليدوي.

تلقائي مقابل WLM اليدوي

يمكّنك Amazon Redshift WLM من إدارة الأولويات بمرونة ضمن أعباء العمل لتلبية اتفاقيات مستوى الخدمة الخاصة بك. يدعم Amazon Redshift WLM التلقائي أو WLM اليدوي لمستودع بيانات Redshift المتوفر لديك. ويوضح الرسم البياني التالي قوائم الانتظار لكل خيار.

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

باستخدام WLM اليدوي، يمكنك إدارة تزامن الاستعلام وتخصيص الذاكرة، بدلاً من WLM التلقائي، حيث تتم إدارته بواسطة Amazon Redshift تلقائيًا. يمكنك تكوين قوائم انتظار WLM منفصلة لأحمال العمل المختلفة مثل ETL، وBI، والمخصصة وتخصيص تخصيص الموارد. للحصول على معلومات إضافية، راجع البرنامج التعليمي: تكوين قوائم انتظار إدارة عبء العمل اليدوي (WLM)..

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

الآن بعد أن اخترت WLM التلقائي أو اليدوي، دعنا نستكشف معلمات وخصائص WLM.

الخصائص الثابتة مقابل الخصائص الديناميكية

يتم تعيين تكوين WLM لمستودع بيانات Redshift باستخدام مجموعة معلمات ضمن خصائص تكوين قاعدة البيانات.

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

لاحظ ما يلي:

• تعتبر معلمات مجموعة المعلمات وتبديل WLM من يدوي إلى تلقائي أو العكس خصائص ثابتة، وبالتالي تتطلب إعادة تشغيل المجموعة.
• بالنسبة لخصائص WLM Concurrency on main، والنسبة المئوية للذاكرة المستخدمة، وTimeout، والتي تعد ديناميكية لـ WLM اليدوي، ينطبق التغيير فقط على الاستعلامات الجديدة المرسلة بعد تغيير القيمة وليس للاستعلامات الجاري تشغيلها حاليًا.
• قواعد مراقبة الاستعلام، والتي سنناقشها لاحقًا في هذا المنشور، هي قواعد ديناميكية ولا تتطلب إعادة تشغيل المجموعة.

في القسم التالي، سنناقش مفهوم فئة الخدمة، أي قائمة الانتظار التي سيتم إرسال الاستعلام إليها ولماذا.

فئة الخدمة

سواء كنت تستخدم WLM تلقائيًا أو يدويًا، فإن استعلامات المستخدم المرسلة تنتقل إلى قائمة انتظار WLM المقصودة عبر إحدى الآليات التالية:

• مجموعات الاعضاء - يتم تعيين قائمة انتظار WLM مباشرة إلى مجموعات الانزياح الأحمر الذي سيظهر في جدول pg_group.
• Query_Groups - يعتمد تعيين قائمة الانتظار على query_group ملصق. على سبيل المثال، يمكن أن تحتوي لوحة المعلومات المرسلة من نفس مستخدم التقارير على أولويات منفصلة حسب التعيين أو القسم.
• User_Roles (أحدث إضافة) - يتم تعيين قائمة الانتظار على أساس أدوار التحول الأحمر.

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

قوائم انتظار WLM التي تحددها بناءً على ذلك user_groups, query_groupsالطرق أو user_roles تقع في معرف فئة الخدمة 6-13 لـ WLM اليدوي ومعرف فئة الخدمة 100-107 لـ WLM التلقائي.

باستخدام Query_group، يمكنك فرض استعلام للانتقال إلى فئة الخدمة 5 وتشغيله في قائمة انتظار المستخدم المتميز (شريطة أن تكون مستخدمًا متميزًا معتمدًا) كما هو موضح في الكود التالي:

set query_group to 'superuser';
analyze table_xyz;
vacuum full table_xyz;
reset query_group;

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

تعطي قائمة انتظار تسريع الاستعلامات القصيرة (SQA) (فئة الخدمة 14) الأولوية للاستعلامات قصيرة المدى قبل الاستعلامات طويلة المدى. إذا قمت بتمكين SQA، فيمكنك تقليل قوائم انتظار WLM المخصصة لتشغيل الاستعلامات القصيرة. بالإضافة إلى ذلك، لا تحتاج الاستعلامات طويلة الأمد إلى التعامل مع الاستعلامات القصيرة للفتحات الموجودة في قائمة الانتظار، لذا يمكنك تكوين قوائم انتظار WLM الخاصة بك لاستخدام عدد أقل فتحات الاستعلام (مصطلح يستخدم للتزامن المتاح). يستخدم Amazon Redshift خوارزمية ML لتحليل كل استعلام مؤهل والتنبؤ بوقت تشغيل الاستعلام. يقوم Auto WLM ديناميكيًا بتعيين قيمة للحد الأقصى لوقت تشغيل SQA بناءً على تحليل عبء عمل مجموعتك. وبدلاً من ذلك، يمكنك تحديد قيمة ثابتة تتراوح من 1 إلى 20 ثانية عند استخدام WLM اليدوي.

يتم تمكين SQA افتراضيًا في مجموعة المعلمات الافتراضية ولجميع مجموعات المعلمات الجديدة. يمكن أن يكون لـ SQA حد أقصى للتزامن يصل إلى ستة استعلامات.

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

قواعد مراقبة الاستعلام

يمكنك استخدام Amazon Redshift قواعد مراقبة الاستعلام (QMRs) لتعيين حدود الأداء المستندة إلى المقاييس لقوائم انتظار WLM وتحديد الإجراء الذي يجب اتخاذه عندما يتجاوز الاستعلام تلك الحدود.

تقوم مجموعة Redshift تلقائيًا بجمع مقاييس مراقبة الاستعلام. يمكنك الاستعلام عن عرض النظام SVL_QUERY_METRICS_SUMMARY كوسيلة مساعدة لتحديد قيم العتبة لتحديد QMR. ثم قم بإنشاء QMR بناءً على السمات التالية:

• وقت تشغيل الاستعلام، بالثواني
• الاستعلام عن عدد صفوف الإرجاع
• وقت وحدة المعالجة المركزية لبيان SQL

للحصول على قائمة كاملة بـ QMRs، راجع قواعد مراقبة استعلام WLM.

إنشاء مجموعات معلمات العينة

بالنسبة لحالة استخدام exampleCorp الخاصة بنا، نعرض WLM التلقائي واليدوي لمستودع بيانات Redshift المتوفر ونشارك منظور WLM بدون خادم.

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

مجموعة Redshift لمستودع بيانات المؤسسة باستخدام WLM التلقائي

بالنسبة لمجموعة EDW، نستخدم Auto WLM. لتكوين فئة الخدمة، ننظر إلى الخيارات الثلاثة: user_roles, user_groupsو query_groups.

فيما يلي لمحة عن كيفية إعداد ذلك في قوائم انتظار WLM ثم استخدامه في استعلاماتك.

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

أدوار المستخدم في WLM

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

لمزيد من المعلومات حول كيفية التحويل من المجموعات إلى الأدوار، راجع أدوار Amazon Redshift (RBAC)، الذي يرشدك خلال أ الإجراء المخزن لتحويل المجموعات إلى أدوار.

في المثال التالي، قمنا بإنشاء قائمة انتظار WLM EDW_Admins، والذي يستخدم edw_admin_role تم إنشاؤها في Amazon Redshift لإرسال أعباء العمل في قائمة الانتظار هذه. ال EDW_Admins يتم إنشاء قائمة الانتظار بأولوية عالية ووضع تحجيم التزامن التلقائي.

مجموعات الاعضاء

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

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

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

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

في المثال التالي، قمنا بإنشاء قائمتي انتظار WLM مختلفتين لـ ETL وBI. تتمتع قائمة انتظار ETL بأولوية عالية ويتم إيقاف تشغيل وضع القياس المتزامن، في حين أن قائمة انتظار BI لها أولوية منخفضة ويتم إيقاف تشغيل وضع القياس المتزامن.

استخدم الكود التالي لإنشاء مجموعة بها عدة مستخدمين:

-- Example of create group with multiple users
create group ETL with user etl_user1, etl_user2;
Create group BI with user bi_user1, bi_user2;

مجموعات الاستعلام

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

فائدة استخدام query_groups هو أنه يمكنك استخدامه لتقييد النتائج من STL_QUERY و STV_INFLIGHT الجداول و SVL_QLOG منظر. يمكنك تطبيق تسمية منفصلة على كل استعلام تقوم بتشغيله لتعريف الاستعلامات بشكل فريد دون الحاجة إلى البحث عن معرفاتها.

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

الآن دعونا نرى كيف يمكنك فرض استعلام لاستخدام query_groups قائمة الانتظار التي تم إنشاؤها للتو.

يمكنك تعيين استعلام إلى قائمة انتظار في وقت التشغيل عن طريق تعيين الاستعلام الخاص بك إلى مجموعة الاستعلام المناسبة. استخدم الأمر SET لبدء مجموعة استعلام:

SET query_group TO wbr;
-- or
SET query_group TO weekly_business_report;

ستنتقل الاستعلامات التي تتبع أمر SET إلى قائمة انتظار WLM Query_Group_WBR حتى تقوم إما بإعادة تعيين مجموعة الاستعلام أو إنهاء جلسة تسجيل الدخول الحالية. للحصول على معلومات حول إعداد وإعادة تعيين معلمة تكوين الخادم، راجع طقم و RESET، على التوالي.

يجب تضمين تسميات مجموعة الاستعلام التي تحددها في تكوين WLM الحالي؛ خلاف ذلك، مجموعة query_group الأمر ليس له أي تأثير على قوائم انتظار الاستعلام.

لمزيد من query_groups أمثلة، راجع قواعد تخصيص قائمة انتظار WLM.

تسويق مجموعة Redshift باستخدام WLM اليدوي

بالتوسع في حالة استخدام مجموعة Redshift التسويقية الخاصة بـ exampleCorp، تخدم هذه المجموعة نوعين من أعباء العمل:

• تشغيل ETL لمدة ساعتين بين الساعة 2:7 صباحًا وحتى 00:9 صباحًا
• تشغيل تقارير ذكاء الأعمال ولوحات المعلومات للوقت المتبقي خلال اليوم

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

دعونا إعداد دليل WLM في هذه الحالة، مع قائمتي انتظار WLM: ETL وBI.

لتحقيق أقصى استفادة من الموارد، نستخدم واجهة سطر الأوامر AWS (AWS CLI) في بداية ETL، مما سيجعل قوائم انتظار WLM الخاصة بنا صديقة لـ ETL، مما يوفر توافقًا أعلى لقائمة انتظار ETL. في نهاية ETL، نستخدم أمر AWS CLI لتغيير قائمة انتظار WLM للحصول على إعدادات موارد متوافقة مع BI. لا يتطلب تعديل قوائم انتظار WLM إعادة تشغيل مجموعتك؛ ومع ذلك، تعديل المعلمات أو مجموعة المعلمات يفعل ذلك.

إذا كنت ستستخدم Auto WLM، فمن الممكن أن يتم تحقيق ذلك عن طريق التغيير الديناميكي لأولوية الاستعلام لقوائم انتظار ETL وBI.

بشكل افتراضي، عندما تختار إنشاء، سيكون WLM الذي تم إنشاؤه هو Auto WLM. يمكنك التبديل إلى WLM اليدوي عن طريق الاختيار تبديل وضع WLM. بعد تبديل وضع WLM، اختر تحرير قوائم انتظار عبء العمل.

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

بعد إضافة قوائم انتظار ETL وBI، اختر حفظ. كان ينبغي عليك تكوين ما يلي:

• قائمة انتظار ETL مع تخصيص ذاكرة بنسبة 60% وتزامن استعلام قدره 9
• قائمة انتظار BI مع تخصيص ذاكرة بنسبة 30% وتزامن استعلام قدره 4
• قائمة انتظار افتراضية مع تخصيص ذاكرة بنسبة 10% وتزامن استعلام قدره 2

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

قد تفضل الشركات إكمال هذه الخطوات بطريقة آلية. بالنسبة لحالة استخدام سوق بيانات التسويق، يبدأ ETL في الساعة 7:00 صباحًا. البداية المثالية لتدفق ETL هي الحصول على وظيفة تجعل إعدادات WLM الخاصة بك صديقة لقائمة انتظار ETL. إليك كيفية تعديل التزامن والذاكرة (كلا الخصائص الديناميكية في قوائم انتظار WLM اليدوية) إلى تكوين مناسب لـ ETL:

aws redshift --region 'us-east-1' modify-cluster-parameter-group --parameter-group-name manual-wlm-demo --parameters '{"ParameterName": "wlm_json_configuration","ParameterValue": "[{"query_group": [], "user_group": ["etl"],"query_group_wild_card": 0,"user_group_wild_card": 0, "query_concurrency": 9, "max_execution_time": 0, "memory_percent_to_use": 60, "name": "ETL" }, {"query_group": [], "user_group": ["bi"],"query_group_wild_card": 0,"user_group_wild_card": 0, "query_concurrency": 3, "max_execution_time": 0, "memory_percent_to_use": 20, "name": "BI" }, { "query_group": [], "user_group": [], "query_group_wild_card": 0, "user_group_wild_card": 0, "query_concurrency": 3, "max_execution_time": 5400000, "memory_percent_to_use": 20, "name": "Default queue", "rules": [ { "rule_name": "user_query_duration_threshold", "predicate": [ { "metric_name": "query_execution_time", "operator": ">", "value": 10800 } ], "action": "abort" } ] }, { "short_query_queue": "true" } ]","Description": "ETL Start, ETL Friendly"}';

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

بالنسبة لحالة استخدام سوق بيانات التسويق، في الساعة 9:00 صباحًا أو عند انتهاء ETL، يمكنك الحصول على مهمة تشغيل أمر AWS CLI لتعديل إعدادات مورد قائمة انتظار WLM إلى تكوين صديق BI كما هو موضح في التعليمة البرمجية التالية:

aws redshift --region 'us-east-1' modify-cluster-parameter-group --parameter-group-name manual-wlm-demo --parameters '{"ParameterName": "wlm_json_configuration","ParameterValue": "[{"query_group": [], "user_group": ["etl"],"query_group_wild_card": 0,"user_group_wild_card": 0, "query_concurrency": 1, "max_execution_time": 0, "memory_percent_to_use": 5, "name": "ETL" }, {"query_group": [], "user_group": ["bi"],"query_group_wild_card": 0,"user_group_wild_card": 0, "query_concurrency": 12, "max_execution_time": 0, "memory_percent_to_use": 80, "name": "BI" }, { "query_group": [], "user_group": [], "query_group_wild_card": 0, "user_group_wild_card": 0, "query_concurrency": 2, "max_execution_time": 5400000, "memory_percent_to_use": 15, "name": "Default queue", "rules": [ { "rule_name": "user_query_duration_threshold", "predicate": [ { "metric_name": "query_execution_time", "operator": ">", "value": 10800 } ], "action": "abort" } ] }, { "short_query_queue": "true" } ]","Description": "ETL End, BI Friendly"}';

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

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

مستودع بيانات Auditor Redshift باستخدام WLM في Redshift Serverless

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

في Redshift Serverless، يمكنك إعداد حدود الاستخدام والاستعلام. تتيح لك حدود الاستعلام إعداد QMR. يمكنك اختيار إدارة حدود الاستعلام لتشغيل إجراء الإجهاض الافتراضي تلقائيًا عندما تتجاوز الاستعلامات حدود الأداء. لمزيد من المعلومات، راجع مقاييس مراقبة الاستعلام لـ Amazon Redshift Serverless.

لمعرفة الحدود التفصيلية الأخرى في Redshift Serverless، راجع قم بتكوين المراقبة والحدود والإنذارات في Amazon Redshift Serverless للحفاظ على إمكانية التنبؤ بالتكاليف.

مراقبة استخدام طرق عرض النظام للمقاييس التشغيلية

يتم استخدام عروض النظام في Amazon Redshift لمراقبة أداء حمل العمل. يمكنك عرض حالة الاستعلامات وقوائم الانتظار وفئات الخدمة باستخدام نظام خاص بـ WLM الجداول. يمكنك الاستعلام عن جداول النظام لاستكشاف التفاصيل التالية:

• عرض الاستعلامات التي يتم تعقبها والموارد المخصصة بواسطة مدير عبء العمل
• معرفة قائمة الانتظار التي تم تعيين الاستعلام إليها
• عرض حالة الاستعلام الذي يتم تعقبه حاليًا بواسطة مدير عبء العمل

يمكنك تنزيل العينة دفتر SQL استعلامات النظام. يمكنك استيراد هذا في محرر الاستعلام V2.0. يمكن أن تساعدك الاستعلامات الموجودة في نموذج دفتر الملاحظات في استكشاف أحمال العمل التي تتم إدارتها بواسطة قوائم انتظار WLM.

وفي الختام

في هذا المنشور، قمنا بتغطية أمثلة واقعية لأنماط WLM التلقائية وأنماط WLM اليدوية. لقد قدمنا ​​تعيين أدوار المستخدم لقوائم انتظار WLM، والاستعلامات المشتركة حول طرق عرض النظام والجداول لجمع الرؤى التشغيلية حول تكوين WLM الخاص بك. نحن نشجعك على استكشاف استخدام أدوار مستخدم Redshift مع إدارة أحمال العمل. استخدم ال البرنامج النصي متوفر على AWS re:Post لتحويل المجموعات إلى أدوار، والبدء في استخدام أدوار المستخدم لقوائم انتظار WLM الخاصة بك.

حول المؤلف

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

هارشيدا باتيل هو متخصص رئيسي في SA مع AWS.

نيتا شاه هو مهندس حلول متخصص في التحليلات في AWS ومقره في نيويورك. تعمل على إنشاء حلول لمستودعات البيانات لأكثر من 20 عامًا وتتخصص في Amazon Redshift. وهي تركز على مساعدة العملاء في تصميم وبناء تحليلات جيدة التصميم ومنصات دعم القرار على مستوى المؤسسات.

يانشو جي مدير منتجات في فريق Amazon Redshift. لديها خبرة في رؤية المنتج والاستراتيجية في منتجات ومنصات البيانات الرائدة في الصناعة. لديها مهارة بارزة في بناء منتجات برمجية كبيرة باستخدام تطوير الويب وتصميم النظام وقاعدة البيانات وتقنيات البرمجة الموزعة. في حياتها الشخصية ، تحب Yanzhu الرسم والتصوير ولعب التنس.

• محتوى مدعوم من تحسين محركات البحث وتوزيع العلاقات العامة. تضخيم اليوم.
• PlatoData.Network Vertical Generative Ai. تمكين نفسك. الوصول هنا.
• أفلاطونايستريم. ذكاء Web3. تضخيم المعرفة. الوصول هنا.
• أفلاطون كربون، كلينتك ، الطاقة، بيئة، شمسي، إدارة المخلفات. الوصول هنا.
• أفلاطون هيلث. التكنولوجيا الحيوية وذكاء التجارب السريرية. الوصول هنا.
• المصدر https://aws.amazon.com/blogs/big-data/manage-your-workloads-better-using-amazon-redshift-workload-management/