تسعير Amazon EMR

هذا التسعير مقابل تطبيقات Amazon EMR التي تعمل على مجموعات Amazon EMR باستخدام مثيلات Amazon EC2.

يتم احتساب سعر Amazon EMR مضافًا إلى سعر Amazon EC2 (سعر الخوادم الأساسية)، وسعر Amazon Elastic Block Store (Amazon EBS) (في حالة إرفاق أحجام Amazon EBS). تُحرَّر لذلك أيضًا فاتورة بالثانية بحد أدنى يبلغ دقيقة. ثمة مجموعة متنوعة من خيارات تسعير EC2 يمكنك الاختيار من بينها، بما في ذلك خيار "عند الطلب" (الموضح أدناه)، و"المثيلات المحجوزة" لمدة عام وثلاثة أعوام، وخطط توفير السعة، ومثيلات Spot. تُعد مثيلات Spot سعة احتياطية لـ EC2 بخصم يصل إلى 90% مقارنة بأسعار المثيلات المتوفرة "عند الطلب". يمكنك مراجعة فرص التوفير في سعر مثيل Spot مقارنة بالمثيل المتوفر "عند الطلب" عن طريق التصفية حسب أنواع المثيلات المدعومة من EMR في صفحة Spot Instance Advisor.

هذا التسعير مقابل Amazon EMR على مجموعات Amazon EKS.

سعر Amazon EMR مضاف إلى تسعير Amazon EKS وأي خدمات أخرى مستخدمة مع EKS. يمكنك تشغيل EKS على AWS باستخدام إما EC2، أو AWS Fargate. إذا كنت تستخدم EC2 (بما في ذلك مجموعات العُقد المُدارة من EKS)، فستدفع مقابل موارد AWS (مثل: مثيلات EC2، أو وحدات تخزين EBS) التي تقوم بإنشائها لتشغيل العُقد المشغلة لـ Kubernetes. اطّلع على معلومات التسعير التفصيلية في صفحة تسعير EC2. إذا كنت تستخدم AWS Fargate، فسيتم احتساب قيمة التسعير بناءً على موارد vCPU والذاكرة المستخدمة منذ وقت بدء تحميل صورة حاويتك حتى إنهاء كابينة EKS مع التقريب لأقرب ثانية. يتم تطبيق أدنى حد للرسوم بمقدار دقيقة واحدة. اطّلع على معلومات التسعير التفصيلية في صفحة تسعير AWS Fargate.

يتم حساب تسعير Amazon EMR على Amazon EKS بناءً على موارد vCPU والذاكرة المستخدمة منذ وقت بدء تحميل صورة تطبيق EMR حتى إنهاء EKS Pod مع التقريب لأقرب ثانية. يستند التسعير إلى الموارد المطلوبة من vCPU والذاكرة للمهمة أو الكابينة.

لا يختلف تسعير Amazon EMR على AWS Outposts عن تسعير مثيلات EMR القائمة على السحابة. يُرجى الرجوع إلى صفحة تسعير AWS Outposts لمعرفة تفاصيل حول تسعير AWS Outposts.

مع EMR Serverless، لا توجد تكاليف مقدمة ولا تدفع إلا مقابل الموارد التي تستخدمها. تدفع مقابل وحدة المعالجة المركزية الافتراضية vCPU، والذاكرة، وموارد التخزين التي تستهلكها تطبيقاتك.

مع EMR Serverless، يمكنك إنشاء تطبيق باستخدام إصدار إطار عمل مفتوح المصدر وإرسال الوظائف للتطبيق. وكجزء من مواصفات الوظيفة، يمكنك توفير الحد الأدنى والحد الأقصى لعدد العمال المتزامنين، ووحدة vCPU، والذاكرة، والتخزين لكل عامل. تضيف EMR العمال تلقائيًا وتحذفهم بناءً على ما تتطلبه الوظيفة في نطاق حدودك المعينة. يمكن بطريقة مستقلة تكوين الأبعاد الثلاثة للحوسبة والذاكرة والتخزين الخاصة بالعمال. ويمكنك الاختيار من بين وحدة معالجة مركزية افتراضية (vCPU) واحدة، أو وحدتَي vCPU، أو 4 وحدات vCPU أو 8 وحدات vCPU أو 16 وحدة vCPU لكل عامل، وذاكرة تتراوح من 2 جيجابايت إلى 120 جيجابايت لكل عامل بزيادات تتراوح من 1 جيجابايت إلى 8 جيجابايت. بالنسبة لخيارات التخزين، يمكنك اختيار التخزين القياسي من 20 جيجابايت إلى 200 جيجابايت لكل عامل، أو اختيار التخزين المُحسَّن لعمليات التبديل من 20 جيجابايت إلى 2 تيرابايت لكل عامل.  مع التخزين دون خادم لخدمة EMR Serverless، لا يتم فرض أي رسوم تخزين على عمليات البيانات الوسيطة.

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

تفاصيل التسعير (الحوسبة والذاكرة)

التسعير مستند إلى وحدة vCPU والذاكرة وموارد التخزين التي استخدمها العمال، مجمعة من كل العمال.

تفاصيل التسعير (التخزين المؤقت)

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

التخزين المُحسَّن للتبديل: يتم احتساب التكلفة على كامل سعة التخزين المخصصة لكل عامل، بما في ذلك أول 20 جيجابايت.

تكوينات العمال المدعومة

المدة

تُحسب المدة من وقت جاهزية العامل لتشغيل عب العمل وحتى وقت انتهاءه، مع التقريب لأقرب ثانية بحد أدنى دقيقة واحدة.

الرسوم الإضافية

قد تتحمل رسومًا إضافية إذا كانت تطبيقاتك تستخدم خدمات AWS أخرى. على سيبل المثال، إذا كان تطبيقك يستخدم Amazon Simple Storage Service (S3) في تخزين البيانات ومعالجتها، فستتحمل التكلفة وفقًا لأسعار Amazon S3 القياسية. إذا قمت بنقل للبيانات من مصادر بيانات مثل Amazon S3 أو Amazon Relational Database Service (RDS) أو Amazon Redshift، تتحمل تكلفة الطلب القياسي وأسعار نقل البيانات. إذا كنت تستخدم Amazon CloudWatch، فستتحمل تكلفة الأسعار القياسية لـ CloudWatch Logs وCloudWatch Events.

تنطبق هذه التسعيرة على Amazon EMR في مجموعات EC2 التي تستخدم تطبيقات Apache HBase مع Amazon EMR WAL. يسمح سجل Apache HBase Write Ahead بتسجيل جميع التغييرات على البيانات على التخزين القائم على الملفات. مع Amazon EMR على EC2، يمكنك حفظ سجلات Apache HBase المسبقة في Amazon EMR WAL، وهي طبقة تخزين مُدارة ومتينة تدوم بعد انتهاء عمر المجموعة. في حال توقف المجموعة، أو في الحالات النادرة التي تصبح فيها منطقة التوفر غير مستقرة أو غير متاحة، يمكنك إنشاء مجموعة جديدة وتوجيهها إلى نفس الدليل الجذري في Amazon S3 ومساحة عمل Amazon EMR WAL، واستعادة البيانات الموجودة في WAL تلقائيًا خلال دقائق. لمزيد من المعلومات، راجع مستندات Amazon EMR WAL. 

ستدفع فقط مقابل استخدامك لخدمة EMR WAL. إذا كانت لديك مجموعة نشطة مُهيّأة لاستخدام WAL، فستُحتسب رسوم تخزين EMR WAL بناءً على الاستخدام بالفوترة كالتالي: EMR-WAL-WALHours للتخزين، وWriteRequestGiB للكتابة، وReadRequestGiB للقراءة.

EMR-WAL-WALHours: يقوم EMR WAL بإنشاء ملف WAL واحد لكل منطقة في Apache HBase. بعد إنهاء المجموعة، إذا كانت هناك بيانات لا تزال موجودة في EMR WAL ولم تُنقل إلى Amazon S3، يمكنك إما استعادتها عبر إنشاء مجموعة استرداد، أو تنظيف WAL بإنشاء مجموعة مؤقتة واستخدام واجهة سطر أوامر EMR WAL لحذف الموارد. إذا لم تقم بحذف بيانات EMR WAL يدويًا، فستظل البيانات محفوظة وسيتم فرض رسوم على أي بيانات غير مفلترة لمدة 30 يومًا. يمكنك مشاهدة مثال في الأسفل.

ReadRequestGiB وWriteRequestGiB: هذان البُعدان مخصصان لطلبات القراءة والكتابة. يتم احتساب مكالمات واجهة برمجة تطبيقات Apache HBase لكتابة البيانات في الجدول على مجموعة تستخدم EMR WAL كوحدات WriteRequestGiB. تتم عمليات الكتابة إلى EMR WAL لجميع عمليات الكتابة في Apache HBase مثل أوامر Put. يتم احتساب استدعاءات واجهة برمجة تطبيقات Apache HBase لقراءة البيانات من EMR WAL أثناء عمليات الاسترداد كوحدات ReadRequestGiB. تُحتسب رسوم عمليات القراءة والكتابة بناءً على حجم العناصر، مع حد أدنى للفوترة من 1 بايت في EMR.

يعتمد التسعير على تسعير منطقة شرق الولايات المتحدة الأمريكية - 1.

لنفترض أنك تشغل تطبيق Amazon EMR منشورًا على Amazon EC2، وأنت تستخدم واحدًا من مثيلات c4.2xlarge EC2 كعقدتك الرئيسة واثنين من مثيلات c4.2xlarge EC2 كعقدتيك الأساسيتين. ستُحاسَب على كل من عُقد EMR وEC2. إذا كنت تشغِّل المثيلات لمدة شهر واحد مع استخدام 100% في أثناء ذلك الشهر، وتستخدم التسعير عند الطلب لمثيلات EC2، فسيكون حسابك كالآتي:

العقدة الرئيسة:

رسوم EMR‏ = 1 مثيل × 0.105 USD بالساعة × (100 / 100 مستخدم/شهر) × 730 ساعة في الشهر = 76.65 USD (تكلفة عقدة EMR الرئيسة) رسوم EC2‏ = 1 مثيل × 0.398 USD بالساعة × 730 ساعة في الشهر = 290.54 USD (تكلفة عقدة EC2 الرئيسة)

العُقد الأساسية:

رسوم EMR‏ = 2 مثيل × 0.105 USD بالساعة × (100 / 100 مستخدم/شهر) × 730 ساعة في الشهر = 153.30 USD (تكلفة عقدة EMR الأساسية)

رسوم EC2‏ = 2 مثيل × 0.398 USD بالساعة × 730 ساعة في الشهر = 581.08 USD (تكلفة عقدة EC2 الأساسية)

إجمالي الرسوم = 76.65 USD‏ + 290.54 USD‏ + 153.30 USD‏ + 581.08 USD‏ = 1101.57 USD

يعتمد التسعير على تسعير منطقة شرق الولايات المتحدة الأمريكية - 1.

افترض أنك تشغل تطبيق Amazon EMR-Spark المُسْتَعْمَل على Amazon EKS. وفي هذه الحالة، تحصل خدمة EKS على قدرة الحوسبة باستخدام مثيلات r5.2xlarge EC2 (8 وحدات vCPU‏، 64 جيجابايت من ذاكرة الوصول العشوائي (RAM)). لنفترض أن مجموعة EKS تحتوي على 100 عقدة بإجمالي 800 وحدة vCPU و6400 جيجابايت من إجمالي الذاكرة. لنفترض أن التطبيق يستخدم 100 VCPU و300 جيجابايت من الذاكرة لمدة 30 دقيقة.

يكون إجمالي رسوم ترقية Amazon EMR لهذه المهمة:

إجمالي الترقية على vCPU‏ = (100 * 0.01012 USD * 0.5) = (عدد vCPU * السعر لكل vCPU في الساعة * مدة تشغيل المهمة في الساعة) = 0.506 USD       

إجمالي الترقية على الذاكرة = (300 * 0.00111125 USD‏ *0.5) = (مقدار الذاكرة المستخدمة * السعر لكل جيجابايت في الساعة * مدة تشغيل المهمة بالساعة) = 0.1667 USD       

إجمالي ترقية EMR لمهمة EMR‏ = 0.6727 USD

التكاليف الإضافية

تَدفع 0.10 USD في الساعة عن كل مجموعة من مجموعات Amazon EKS التي تنشئها. يمكنك استخدام مجموعة Amazon EKS واحدة لتشغيل تطبيقات متعددة من خلال الاستفادة من مساحات أسماء Kubernetes وسياسات أمان IAM. يمكنك تشغيل EKS على AWS باستخدام إما Amazon EC2، أو AWS Fargate.

إذا كنت تستخدم Amazon EC2 (بما في ذلك مجموعات العُقد المُدارة في Amazon EKS)، فستدفع مقابل موارد AWS (مثل مثيلات EC2، أو أحجام Amazon EBS) التي تنشئها لتشغيل عُقد عامل Kubernetes. أنت لا تدفع إلا مقابل ما تستخدمه، وكما تستخدمه. لا يوجد حد أدنى للرسوم ولا التزامات مسبقة. اطّلع على معلومات التسعير التفصيلية في صفحة تسعير EC2.

إذا كنت تستخدم AWS Fargate، فسيتم احتساب قيمة التسعير بناءً على موارد vCPU والذاكرة المستخدمة بداية من وقت تنزيل صورة حاويتك حتى انتهاء كابينة Amazon EKS مع التقريب لأقرب ثانية. يتم تطبيق أدنى حد للرسوم بمقدار دقيقة واحدة. اطّلع على معلومات التسعير التفصيلية في صفحة تسعير AWS Fargate.

لنفترض أنك ترسل أحد وظائف Spark إلى EMR Serverless. لنفترض أن الوظيفة مصممة لتستخدم أدنى حد من 25 عاملاً وأقصى حد من 75 عاملاً ومكوّن لكل عامل 4 وحدات VCPU وذاكرة بسعة 30 جيجابايت. وحينها يمكنك اعتبار أنه لم يتم تكوين تحزين مؤقت إضافي. إذا كانت وظيفتك تعمل لمدة 30 ثانية باستخدام 25 عاملاً (أو 100 وحدة vCPU) وتم توسيعه تلقائيًا لإضافة 50 عاملاً إضافيًا (200 وحدة vCPU إضافية) لمدة 15 دقيقة:

إجمالي تكلفة ساعات vCPU = (100 * 0.052624 USD * 0.5) + (200 * 0.052624 USD* 0.25) = (عدد vCPU * لكل معدل ساعات vCPU * وقت تشغيل العمل بالساعة) = 5.2624 USD

إجمالي ساعات الجيجيابايت = (750 * 0.0057785 USD * 0.5) + (1500 * 0.0057785 USD * 0.25) = (إجمالي جيجيابايت ذاكرة مكونة * لكل معدل ساعات الجيجابايت * مدة عمل الوظيفة بالساعات) = 4.333875 USD

إجمالي رسوم EMR Serverless ‏= 9.596275 USD

رسوم إضافية إذا استخدم تطبيقك خدمات AWS أخرى مثل Amazon S3، فسوف تتحمل تكاليف S3 القياسية.

لنفترض أنك أنشأت مجموعة Amazon EMR جديدة باستخدام Apache HBase واخترت إجراء نسخة احتياطية كاملة في منطقة شرق الولايات المتحدة (فرجينيا الشمالية). نظرًا لأن هذا مخصص لتطبيق جديد، فأنت لا تعرف أنماط حركة المرور الخاصة بك. لتبسيط الأمر، لنفترض أن المستخدم أنشأ 10 جداول HBase (بما في ذلك الجداول النظامية)، مع منطقتين HBase لكل جدول، وأن كل تفاعل مع التطبيق يكتب 1 كيبي بايت من البيانات. 

خلال فترة 10 أيام، تتلقى تطبيقك حركة مرور منخفضة، مما يؤدي إلى 10,000 عملية كتابة يوميًا. ولكن في اليوم الحادي عشر، ارتفعت حركة المرور على تطبيقك لتصل إلى 2,500,000 عملية كتابة في ذلك اليوم. تقرر أيضًا تحديث الشيفرة المخصصة على مجموعتك بالتزامن، مع جدولة فترة توقف ليلية للمستخدمين النهائيين في اليوم الحادي عشر. دعنا نفترض أن ذلك أدى إلى 1,000,000 عملية قراءة من EMR WAL ضمن عمليات استرداد HBase. يمكن تطوير تطبيقك لتقديم تجربة سلسة للمستخدمين. يستقر تطبيقك بعد ذلك في نمط حركة مرور أكثر انتظامًا يبلغ 50,000 عملية كتابة يوميًا حتى نهاية الشهر. 

يلخص الجدول التالي إجمالي الاستخدام الخاص بك خلال الشهر.

في نهاية الشهر، ستكون فاتورتك 26.52 USD، وتشمل إجماليًا 0.38 USD مقابل ReadRequestGiB وWriteRequestGiB، و25.92 USD مقابل EMR-WAL-WALHours.