هذه مشاركة ضيف تمت كتابتها بالاشتراك مع براندون أبير، ودينيش شارما، وجون بوش، وأوزكان إييخان من GoDaddy.

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

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

في هذا المنشور، نناقش كيف قمنا بتعزيز الكفاءة التشغيلية باستخدام أمازون EMR بدون خادم. نحن نشارك نتائج ومنهجية قياس الأداء لدينا، والرؤى حول فعالية تكلفة EMR Serverless مقابل السعة الثابتة أمازون EMR على EC2 مجموعات عابرة على سير عمل البيانات لدينا يتم تنسيقها باستخدام تدفقات عمل أمازون المدارة لتدفق أباتشي (أمازون MWAA). نحن نشارك إستراتيجيتنا لاعتماد EMR Serverless في المجالات التي تتفوق فيها. تكشف النتائج التي توصلنا إليها عن فوائد كبيرة، بما في ذلك خفض التكلفة بنسبة تزيد عن 60%، وأعباء عمل Spark بنسبة 50% أسرع، وتحسين ملحوظ خمس مرات في سرعة التطوير والاختبار، وانخفاض كبير في البصمة الكربونية لدينا.

خلفيّة

في أواخر عام 2020، بدأت منصة بيانات GoDaddy رحلة AWS Cloud، حيث قامت بترحيل مجموعة Hadoop المكونة من 800 عقدة مع 2.5 بيتابايت من البيانات من مركز البيانات الخاص بها إلى EMR على EC2. سهّل نهج الرفع والتحويل هذا إجراء مقارنة مباشرة بين البيئات المحلية والبيئات السحابية، مما يضمن الانتقال السلس إلى مسارات AWS، وتقليل مشكلات التحقق من صحة البيانات وتأخير الترحيل.

بحلول أوائل عام 2022، نجحنا في ترحيل أعباء عمل البيانات الضخمة لدينا إلى EMR على EC2. باستخدام أفضل الممارسات المستفادة من برنامج AWS FinHack، قمنا بضبط الوظائف كثيفة الاستخدام للموارد، وتحويل وظائف Pig وHive إلى Spark، وخفضنا إنفاق عبء العمل المجمع لدينا بنسبة 22.75% في عام 2022. ومع ذلك، ظهرت تحديات قابلية التوسع بسبب تعدد الوظائف . وقد دفع هذا GoDaddy إلى الشروع في رحلة تحسين منهجية، وإنشاء أساس لمعالجة البيانات الضخمة بشكل أكثر استدامة وكفاءة.

سبع طبقات من فرص التحسين

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

الطبقات هي كما يلي:

• تحسين الكود – يركز على تحسين منطق التعليمات البرمجية وكيف يمكن تحسينه للحصول على أداء أفضل. يتضمن ذلك تحسينات في الأداء من خلال التخزين المؤقت الانتقائي، وتقسيم التقسيم والإسقاط، وتحسينات الانضمام، والضبط الآخر الخاص بالمهمة. يعد استخدام حلول ترميز الذكاء الاصطناعي أيضًا جزءًا لا يتجزأ من هذه العملية.
• تحديثات البرنامج - التحديث إلى أحدث إصدارات البرامج مفتوحة المصدر (OSS) للاستفادة من الميزات والتحسينات الجديدة. على سبيل المثال، يوفر تنفيذ الاستعلام التكيفي في Spark 3 تحسينات كبيرة في الأداء والتكلفة.
• تكوينات سبارك المخصصة - ضبط تكوينات Spark المخصصة لتعظيم استخدام الموارد والذاكرة والتوازي. يمكننا تحقيق تحسينات كبيرة من خلال تحديد حجم المهام بشكل صحيح، مثل من خلال spark.sql.shuffle.partitions, spark.sql.files.maxPartitionBytes, spark.executor.coresو spark.executor.memory. ومع ذلك، قد تؤدي هذه التكوينات المخصصة إلى نتائج عكسية إذا لم تكن متوافقة مع إصدار Spark المحدد.
• وقت توفير الموارد - الوقت المستغرق لإطلاق الموارد مثل مجموعات السجلات الطبية الإلكترونية سريعة الزوال الأمازون الحوسبة المرنة السحابية (أمازون إي سي 2). على الرغم من أن بعض العوامل التي تؤثر على هذا الوقت تكون خارجة عن سيطرة المهندس، إلا أن تحديد ومعالجة العوامل التي يمكن تحسينها يمكن أن يساعد في تقليل وقت التوفير الإجمالي.
• القياس الدقيق على مستوى المهمة - ضبط الموارد ديناميكيًا مثل وحدة المعالجة المركزية والذاكرة والقرص وعرض النطاق الترددي للشبكة بناءً على احتياجات كل مرحلة داخل المهمة. الهدف هنا هو تجنب أحجام المجموعات الثابتة التي قد تؤدي إلى إهدار الموارد.
• التوسع الدقيق عبر مهام متعددة في سير العمل - نظرًا لأن كل مهمة لها متطلبات فريدة من الموارد، فإن الحفاظ على حجم مورد ثابت قد يؤدي إلى نقص أو زيادة في توفير مهام معينة ضمن نفس سير العمل. تقليديًا، يحدد حجم المهمة الأكبر حجم المجموعة لسير عمل متعدد المهام. ومع ذلك، يؤدي ضبط الموارد ديناميكيًا عبر مهام وخطوات متعددة ضمن سير العمل إلى تنفيذ أكثر فعالية من حيث التكلفة.
• تحسينات على مستوى النظام الأساسي – يمكن للتحسينات في الطبقات السابقة فقط تحسين وظيفة معينة أو سير عمل. يهدف تحسين النظام الأساسي إلى تحقيق الكفاءة على مستوى الشركة. يمكننا تحقيق ذلك من خلال وسائل مختلفة، مثل تحديث أو ترقية البنية التحتية الأساسية، أو تقديم أطر عمل جديدة، أو تخصيص الموارد المناسبة لكل ملف تعريف وظيفي، أو موازنة استخدام الخدمة، أو تحسين استخدام Savings Plans وSpot Instances، أو تنفيذ تغييرات شاملة أخرى لتعزيز الكفاءة في جميع المهام وسير العمل.

الطبقات 1-3: تخفيضات التكلفة السابقة

بعد أن انتقلنا من العمل المحلي إلى AWS Cloud، ركزنا في المقام الأول جهودنا لتحسين التكلفة على الطبقات الثلاث الأولى الموضحة في الرسم التخطيطي. من خلال نقل خطوط أنابيب Pig وHive القديمة الأكثر تكلفة لدينا إلى Spark وتحسين تكوينات Spark لـ Amazon EMR، حققنا وفورات كبيرة في التكلفة.

على سبيل المثال، استغرقت مهمة Pig القديمة 10 ساعات لإكمالها وتم تصنيفها ضمن أغلى 10 وظائف EMR. عند مراجعة سجلات TEZ ومقاييس المجموعة، اكتشفنا أن المجموعة تم توفيرها بشكل مفرط لحجم البيانات الجاري معالجتها وظلت غير مستغلة بشكل كافٍ في معظم وقت التشغيل. كان الانتقال من Pig إلى Spark أكثر كفاءة. على الرغم من عدم توفر أدوات تلقائية للتحويل، فقد تم إجراء تحسينات يدوية، بما في ذلك:

• تقليل عمليات الكتابة غير الضرورية على القرص، وتوفير وقت التسلسل وإلغاء التسلسل (الطبقة 1)
• تم استبدال موازنة مهمة Airflow بـ Spark، مما أدى إلى تبسيط Airflow DAG (الطبقة 1)
• تمت إزالة تحويلات Spark الزائدة عن الحاجة (الطبقة 1)
• تمت الترقية من Spark 2 إلى 3، باستخدام تنفيذ الاستعلام التكيفي (الطبقة 2)
• معالجة الصلات المنحرفة وتحسين جداول الأبعاد الأصغر (الطبقة 3)

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

الطبقات من 4 إلى 6: ابحث عن حل الحوسبة الصحيح واعتمده

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

فهم حالة معالجة الدفعات لدينا

نحن نستخدم Amazon MWAA لتنسيق سير عمل البيانات لدينا في السحابة على نطاق واسع. أباتشي تدفق الهواء هي أداة مفتوحة المصدر تُستخدم لتأليف تسلسل العمليات والمهام وجدولتها ومراقبتها برمجيًا سير العمل. في هذه التدوينة الشروط سير العمل و وظيفة يتم استخدامها بالتبادل، في إشارة إلى الرسوم البيانية غير الدورية الموجهة (DAGs) التي تتكون من المهام التي تنظمها Amazon MWAA. لكل سير عمل، لدينا مهام متسلسلة أو متوازية، وحتى مزيج من الاثنين معًا في DAG create_emr و terminate_emr المهام التي يتم تشغيلها على مجموعة EMR عابرة ذات سعة حسابية ثابتة طوال تشغيل سير العمل. حتى بعد تحسين جزء من عبء العمل لدينا، لا يزال لدينا العديد من مسارات العمل غير المحسنة التي لم يتم استغلالها بشكل كافٍ بسبب الإفراط في توفير موارد الحوسبة استنادًا إلى المهمة الأكثر استهلاكًا للموارد في سير العمل، كما هو موضح في الشكل التالي.

وقد سلط هذا الضوء على عدم جدوى تخصيص الموارد الثابتة وقادنا إلى إدراك ضرورة وجود نظام ديناميكي لتخصيص الموارد (DRA). قبل أن نقترح حلاً، قمنا بجمع بيانات شاملة لفهم معالجة الدفعات لدينا بشكل كامل. كشف تحليل وقت خطوة المجموعة، باستثناء التزويد ووقت الخمول، عن رؤى مهمة: توزيع منحرف لليمين مع اكتمال أكثر من نصف عمليات سير العمل في 20 دقيقة أو أقل و10% فقط تستغرق أكثر من 60 دقيقة. وقد أرشد هذا التوزيع اختيارنا لحل حوسبة سريع التوفير، مما أدى إلى تقليل أوقات تشغيل سير العمل بشكل كبير. يوضح الرسم البياني التالي أوقات الخطوات (باستثناء التوفير ووقت الخمول) لـ EMR على مجموعات EC2 العابرة في أحد حسابات المعالجة المجمعة لدينا.

علاوة على ذلك، استنادًا إلى توزيع مهام سير العمل على مراحل (باستثناء وقت التوفير ووقت الخمول)، قمنا بتصنيف مهام سير العمل لدينا إلى ثلاث مجموعات:

• الجري بأستعجال - تستمر لمدة 20 دقيقة أو أقل
• المدى المتوسط – تستمر ما بين 20 – 60 دقيقة
• المدى الطويل – تتجاوز 60 دقيقة، وغالباً ما تمتد لعدة ساعات أو أكثر

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

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

تقييم EMR بدون خادم: دراسة حالة في GoDaddy

EMR Serverless هو خيار بدون خادم في Amazon EMR يزيل تعقيدات تكوين المجموعات وإدارتها وتوسيع نطاقها عند تشغيل أطر عمل البيانات الضخمة مثل Apache Spark وApache Hive. باستخدام EMR Serverless، يمكن للشركات الاستمتاع بالعديد من المزايا، بما في ذلك فعالية التكلفة، وتوفير أسرع، وتجربة مطور مبسطة، وتحسين المرونة في مواجهة حالات فشل منطقة توافر الخدمات.

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

منهجية المقارنة المعيارية

قمنا بتقسيم سير عمل البيانات لدينا إلى ثلاث فئات بناءً على إجمالي وقت الخطوة (باستثناء التزويد ووقت الخمول): التشغيل السريع (0-20 دقيقة)، والتشغيل المتوسط ​​(20-60 دقيقة)، والتشغيل الطويل (أكثر من 60 دقيقة). لقد قمنا بتحليل تأثير نوع نشر السجلات الطبية الإلكترونية (Amazon EC2 مقابل EMR Serverless) على مقياسين رئيسيين: فعالية التكلفة وإجمالي تسريع وقت التشغيل، والذي كان بمثابة معايير التقييم الشاملة لدينا. على الرغم من أننا لم نقم بقياس سهولة الاستخدام والمرونة رسميًا، إلا أنه تم أخذ هذه العوامل في الاعتبار طوال عملية التقييم.

الخطوات عالية المستوى لتقييم البيئة هي كما يلي:

1. إعداد البيانات والبيئة:
   1. اختر ثلاث إلى خمس وظائف إنتاج عشوائية من كل فئة وظيفة.
   2. تنفيذ التعديلات المطلوبة لمنع التدخل في الإنتاج.
2. تشغيل الاختبارات:
   1. قم بتشغيل البرامج النصية على مدار عدة أيام أو من خلال تكرارات متعددة لجمع نقاط بيانات دقيقة ومتسقة.
   2. قم بإجراء الاختبارات باستخدام EMR على EC2 وEMR بدون خادم.
3. التحقق من صحة البيانات وتشغيل الاختبار:
   1. التحقق من صحة مجموعات بيانات الإدخال والإخراج والأقسام وعدد الصفوف لضمان معالجة البيانات المتطابقة.
4. جمع المقاييس وتحليل النتائج:
   1. جمع المقاييس ذات الصلة من الاختبارات.
   2. تحليل النتائج لاستخلاص الأفكار والاستنتاجات.

نتائج المعيار

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

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

يعرض الجدول التالي عينة مقارنة للنتائج لنفس سير العمل الذي يتم تشغيله على خيارات نشر مختلفة لـ Amazon EMR (EMR على EC2 وEMR بدون خادم).

AWS Graviton2 على تقييم أداء EMR بدون خادم

بعد رؤية نتائج مقنعة مع EMR Serverless لأحمال العمل لدينا، قررنا إجراء مزيد من التحليل لأداء أوس جرافيتون2 بنية (arm64) داخل EMR بدون خادم. كان لدى AWS وقيم قم بتحفيز أعباء العمل على Graviton2 EMR Serverless باستخدام مقياس TPC-DS سعة 3 تيرابايت، مما يُظهر تحسنًا إجماليًا في أداء السعر بنسبة 27%.

لفهم فوائد التكامل بشكل أفضل، أجرينا دراستنا الخاصة باستخدام أعباء عمل الإنتاج في GoDaddy وفقًا لجدول يومي ولاحظنا تحسنًا مذهلاً في أداء السعر بنسبة 23.8% عبر مجموعة من الوظائف عند استخدام Graviton2. لمزيد من التفاصيل حول هذه الدراسة، انظر يؤدي قياس أداء GoDaddy إلى تحسين أداء السعر بنسبة تصل إلى 24% لأحمال عمل Spark الخاصة بهم باستخدام AWS Graviton2 على Amazon EMR بدون خادم.

استراتيجية اعتماد EMR Serverless

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

قمنا بتقسيم سير العمل لدينا إلى ثلاث مجموعات اعتماد رئيسية، كما هو موضح في الصورة التالية:

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

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

ملخص نتائج اعتماد الإنتاج

ولدت نتائج القياس المرجعي المشجعة واعتماد الكناري اهتمامًا كبيرًا باعتماد EMR Serverless على نطاق أوسع في GoDaddy. حتى الآن، لا يزال طرح EMR بدون خادم قيد التنفيذ. حتى الآن، نجحت في خفض التكاليف بنسبة 62.5% وتسريع إكمال سير العمل الإجمالي بنسبة 50.4%.

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

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

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

تم اعتماد نماذج سير العمل بدون خادم EMR

بالنسبة لسير عمل كبير تم ترحيله إلى EMR Serverless، كشفت مقارنة متوسطات 3 أسابيع قبل وبعد الترحيل عن وفورات مذهلة في التكلفة - انخفاض بنسبة 75.30% بناءً على أسعار البيع بالتجزئة مع تحسن بنسبة 10% في إجمالي وقت التشغيل، مما يعزز الكفاءة التشغيلية. ويوضح الرسم البياني التالي اتجاه التكلفة.

على الرغم من أن المهام السريعة حققت الحد الأدنى من التخفيضات في التكلفة لكل دولار، إلا أنها حققت أكبر نسبة من التوفير في التكلفة. ومع تشغيل الآلاف من مسارات العمل هذه يوميًا، فإن المدخرات المتراكمة كبيرة. يوضح الرسم البياني التالي اتجاه التكلفة لحمل العمل الصغير الذي تم ترحيله من EMR على EC2 إلى EMR Serverless. كشفت مقارنة متوسطات ما قبل وما بعد الهجرة لمدة 3 أسابيع عن توفير ملحوظ في التكاليف بنسبة 92.43% على أسعار البيع بالتجزئة حسب الطلب، إلى جانب تسارع بنسبة 80.6% في إجمالي وقت التشغيل.

الطبقة 7: تحسينات على مستوى النظام الأساسي

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

يوضح الرسم البياني التالي رسمًا توضيحيًا عالي المستوى لبنية الحوسبة الذكية.

الرؤى وأفضل الممارسات الموصى بها

يناقش القسم التالي الرؤى التي جمعناها وأفضل الممارسات الموصى بها التي قمنا بتطويرها خلال مراحل الاعتماد الأولية والأوسع.

إعداد البنية التحتية

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

• استخدم شبكات فرعية كبيرة عبر مناطق توافر الخدمات المتعددة – عند تشغيل أحمال عمل EMR بدون خادم داخل VPC، تأكد من أن الشبكات الفرعية تمتد عبر مناطق توافر خدمات متعددة وليست مقيدة بعناوين IP. تشير إلى تكوين الوصول إلى VPC و أفضل الممارسات لتخطيط الشبكة الفرعية للتفاصيل.
• تعديل الحد الأقصى لحصة vCPU المتزامنة - بالنسبة لمتطلبات الحوسبة الشاملة، يوصى بزيادة عدد الحد الأقصى لوحدات vCPU المتزامنة لكل حساب حصة الخدمة.
• توافق إصدار أمازون MWAA - عند اعتماد EMR Serverless، أدى النظام البيئي اللامركزي Amazon MWAA الخاص بـ GoDaddy لتنسيق خطوط البيانات إلى خلق مشكلات توافق من إصدارات موفري AWS المختلفة. كانت ترقية Amazon MWAA مباشرة أكثر كفاءة من تحديث العديد من DAGs. لقد سهلنا الاعتماد من خلال ترقية مثيلات Amazon MWAA بأنفسنا، وتوثيق المشكلات، ومشاركة النتائج وتقديرات الجهد من أجل التخطيط الدقيق للترقية.
• مشغل GoDaddy EMR - لتسهيل ترحيل العديد من Airflow DAGs من EMR على EC2 إلى EMR Serverless، قمنا بتطوير عوامل تشغيل مخصصة تتكيف مع الواجهات الحالية. سمح هذا بانتقالات سلسة مع الاحتفاظ بخيارات الضبط المألوفة. يمكن لمهندسي البيانات ترحيل خطوط الأنابيب بسهولة من خلال عمليات استيراد البحث والاستبدال البسيطة واستخدام EMR Serverless على الفور.

تخفيف السلوك غير المتوقع

فيما يلي السلوكيات غير المتوقعة التي واجهناها وما فعلناه للتخفيف منها:

• شرارة DRA التحجيم العدواني - بالنسبة لبعض الوظائف (8.33% من المعايير الأولية، 13.6% من الإنتاج)، زادت التكلفة بعد الترحيل إلى EMR Serverless. كان هذا بسبب قيام Spark DRA بتعيين عمال جدد بشكل مفرط لفترة وجيزة، مع إعطاء الأولوية للأداء على التكلفة. ولمواجهة ذلك، قمنا بتعيين الحد الأقصى لعتبات المنفذ عن طريق التعديل spark.dynamicAllocation.maxExecutor، مما يحد بشكل فعال من عدوانية التوسع بدون خادم EMR. عند الترحيل من EMR على EC2، نقترح ملاحظة الحد الأقصى لعدد النواة في Spark History UI لتكرار حدود الحوسبة المماثلة في EMR Serverless، مثل --conf spark.executor.cores و --conf spark.dynamicAllocation.maxExecutors.
• إدارة مساحة القرص للمهام واسعة النطاق - عند نقل المهام التي تعالج كميات كبيرة من البيانات مع عمليات خلط كبيرة ومتطلبات كبيرة للقرص إلى EMR Serverless، نوصي بتكوين spark.emr-serverless.executor.disk من خلال الإشارة إلى مقاييس وظيفة Spark الحالية. وعلاوة على ذلك، تكوينات مثل spark.executor.cores جنبا إلى جنب مع spark.emr-serverless.executor.disk و spark.dynamicAllocation.maxExecutors السماح بالتحكم في حجم العامل الأساسي وإجمالي مساحة التخزين المرفقة عندما يكون ذلك مفيدًا. على سبيل المثال، قد تستفيد المهمة التي تتطلب تشغيلًا عشوائيًا كثيفًا مع استخدام منخفض نسبيًا للقرص من استخدام عامل أكبر لزيادة احتمالية عمليات الجلب العشوائي المحلية.

وفي الختام

كما تمت مناقشته في هذا المنشور، كانت تجاربنا مع اعتماد EMR Serverless على الذراع 64 إيجابية للغاية. إن النتائج المبهرة التي حققناها، بما في ذلك انخفاض التكلفة بنسبة 60%، وتشغيل أسرع بنسبة 50% لأحمال عمل Spark المجمعة، والتحسين المذهل بمقدار خمس مرات في سرعة التطوير والاختبار، تتحدث كثيرًا عن إمكانات هذه التقنية. علاوة على ذلك، تشير نتائجنا الحالية إلى أنه من خلال اعتماد Graviton2 على نطاق واسع على EMR Serverless، يمكننا تقليل البصمة الكربونية بنسبة تصل إلى 60% لمعالجة الدفعات لدينا.

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

شكر خاص ل موكول شارما و بوريس برلين لمساهماتهم في المقارنة المرجعية. شكرا جزيلا ل ترافيس موهليستين (كدو)، أبهيجيت كوندو (نائب الرئيس المهندس)، فنسنت يونج (المدير الأول المهندس)، و واي كين لاو (المدير الأول لمهندس البيانات) لدعمهم المستمر.

حول المؤلف

براندون أبير هو مهندس بيانات رئيسي في مؤسسة البيانات والتحليلات (DnA) في GoDaddy. إنه يستمتع بكل ما يتعلق بالبيانات الضخمة. يستمتع في أوقات فراغه بالسفر ومشاهدة الأفلام وممارسة الألعاب الإيقاعية.

دينيش شارما هو مهندس بيانات رئيسي في مؤسسة البيانات والتحليلات (DnA) في GoDaddy. إنه شغوف بتجربة المستخدم وإنتاجية المطورين، ويبحث دائمًا عن طرق لتحسين العمليات الهندسية وتوفير التكلفة. في أوقات فراغه، يحب القراءة وهو من محبي المانجا المتحمسين.

جون بوش هو مهندس برمجيات رئيسي في مؤسسة البيانات والتحليلات (DnA) في GoDaddy. إنه متحمس لتسهيل قيام المؤسسات بإدارة البيانات واستخدامها لدفع أعمالها إلى الأمام. في أوقات فراغه، يحب المشي لمسافات طويلة والتخييم وركوب دراجته الإلكترونية.

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

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

• محتوى مدعوم من تحسين محركات البحث وتوزيع العلاقات العامة. تضخيم اليوم.
• PlatoData.Network Vertical Generative Ai. تمكين نفسك. الوصول هنا.
• أفلاطونايستريم. ذكاء Web3. تضخيم المعرفة. الوصول هنا.
• أفلاطون كربون، كلينتك ، الطاقة، بيئة، شمسي، إدارة المخلفات. الوصول هنا.
• أفلاطون هيلث. التكنولوجيا الحيوية وذكاء التجارب السريرية. الوصول هنا.
• المصدر https://aws.amazon.com/blogs/big-data/how-the-godaddy-data-platform-achieved-over-60-cost-reduction-and-50-performance-boost-by-adopting-amazon-emr-serverless/