شعار زيفيرنت

كيف قامت أمازون بتحسين عملية التسوية المالية كبيرة الحجم مع Amazon EMR لزيادة قابلية التوسع والأداء | خدمات الويب الأمازون

التاريخ:

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

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

يمكننا تحقيق هذه الحسابات المتزامنة على أجهزة متعددة أو سلاسل عمليات لنفس الوظيفة عبر مجموعات من عناصر مجموعة البيانات باستخدام حلول معالجة البيانات الموزعة. وقد شجعنا هذا على إعادة اختراع خدمة التسوية لدينا المدعومة بخدمات AWS، بما في ذلك أمازون EMR و أباتشي سبارك إطار المعالجة الموزعة، والذي يستخدم بايسبارك. تتيح هذه الخدمة للمستخدمين معالجة الملفات التي يزيد حجمها عن 100 جيجابايت والتي تحتوي على ما يصل إلى 100 مليون معاملة في أقل من 30 دقيقة. أصبحت خدمة التسوية بمثابة قوة لمعالجة البيانات، ويمكن للمستخدمين الآن إجراء مجموعة متنوعة من العمليات بسلاسة، مثل محور, الانضمام (مثل عملية Excel VLOOKUP)، علم الحساب العمليات، و الأكثر من ذلك، مما يوفر حلاً متعدد الاستخدامات وفعالاً للتوفيق بين مجموعات البيانات الضخمة. يعد هذا التحسين بمثابة شهادة على قابلية التوسع والسرعة التي تم تحقيقها من خلال اعتماد حلول معالجة البيانات الموزعة.

في هذا المنشور، نوضح كيف قمنا بدمج Amazon EMR لبناء نظام متاح للغاية وقابل للتطوير مما مكننا من تشغيل عملية تسوية مالية كبيرة الحجم.

العمارة قبل الهجرة

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

تم إنشاء خدمتنا القديمة باستخدام خدمة الأمازون المرنة للحاويات (Amazon ECS) تشغيل AWS فارجيت. قمنا بمعالجة البيانات بالتسلسل باستخدام بايثون. ومع ذلك، نظرًا لافتقارها إلى القدرة على المعالجة المتوازية، اضطررنا في كثير من الأحيان إلى زيادة حجم المجموعة عموديًا لدعم مجموعات البيانات الأكبر حجمًا. للسياق، استغرقت معالجة 5 جيجابايت من البيانات مع 50 عملية حوالي 3 ساعات. تم تكوين هذه الخدمة للتوسع أفقيًا إلى خمس مثيلات ECS التي قامت باستقصاء الرسائل منها خدمة Amazon Simple Queue Service (Amazon SQS)، والتي غذت طلبات التحويل. تم تكوين كل مثيل باستخدام 4 وحدات معالجة مركزية افتراضية وذاكرة سعة 30 جيجابايت للسماح بالقياس الأفقي. ومع ذلك، لم نتمكن من توسيع قدرتها على الأداء لأن العملية حدثت بشكل تسلسلي، حيث تم التقاط أجزاء من البيانات من خدمة تخزين أمازون البسيطة (أمازون S3) للمعالجة. على سبيل المثال، تتطلب عملية VLOOKUP التي يتم فيها ضم ملفين قراءة كلا الملفين في الذاكرة قطعة تلو الأخرى للحصول على الإخراج. أصبح هذا عائقًا أمام المستخدمين لأنه كان عليهم الانتظار لفترات طويلة من الوقت لمعالجة مجموعات البيانات الخاصة بهم.

كجزء من إعادة هيكلتنا وتحديثنا، أردنا تحقيق ما يلي:

  • توافر عالية - ينبغي أن تكون مجموعات معالجة البيانات متاحة بدرجة كبيرة، مما يوفر ثلاث نقاط 9 من التوافر (99.9%)
  • الإنتاجية – يجب أن تتعامل الخدمة مع 1,500 عملية تشغيل يوميًا
  • كمون – يجب أن يكون قادرًا على معالجة 100 جيجابايت من البيانات خلال 30 دقيقة
  • عدم التجانس – يجب أن تكون المجموعة قادرة على دعم مجموعة واسعة من أحمال العمل، مع ملفات تتراوح من بضع ميغابايت إلى مئات الجيجابايت
  • تزامن الاستعلام - يتطلب التنفيذ القدرة على دعم ما لا يقل عن 10 درجات من التزامن
  • موثوقية الوظائف واتساق البيانات - يجب تشغيل الوظائف بشكل موثوق ومتسق لتجنب انتهاك اتفاقيات مستوى الخدمة (SLAs)
  • فعالة من حيث التكلفة وقابلة للتطوير – يجب أن تكون قابلة للتطوير بناءً على حجم العمل، مما يجعلها فعالة من حيث التكلفة
  • الأمن والامتثال - نظراً لحساسية البيانات، يجب أن تدعم التحكم الدقيق في النفاذ وتطبيقات الأمن المناسبة
  • مراقبة – يجب أن يوفر الحل مراقبة شاملة للمجموعات والوظائف

لماذا أمازون EMR

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

تكمن الميزة الملحوظة لـ Amazon EMR في استخدامها الفعال للمعالجة المتوازية مع PySpark، مما يمثل تحسنًا كبيرًا مقارنة بكود Python المتسلسل التقليدي. يعمل هذا النهج المبتكر على تبسيط نشر وتوسيع نطاق مجموعات Apache Spark، مما يسمح بالتوازي الفعال على مجموعات البيانات الكبيرة. لا تعمل البنية التحتية للحوسبة الموزعة على تحسين الأداء فحسب، بل تتيح أيضًا معالجة كميات هائلة من البيانات بسرعات غير مسبوقة. مزودًا بمكتبات، يسهل PySpark العمليات المشابهة لـ Excel إطارات البيانات، ويعمل التجريد عالي المستوى لـ DataFrames على تبسيط عمليات معالجة البيانات المعقدة، مما يقلل من تعقيد التعليمات البرمجية. إلى جانب التوفير التلقائي للمجموعات، والتخصيص الديناميكي للموارد، والتكامل مع خدمات AWS الأخرى، يثبت Amazon EMR أنه حل متعدد الاستخدامات مناسب لأعباء العمل المتنوعة، بدءًا من المعالجة المجمعة إلى تعلم الآلة. يعمل التسامح مع الأخطاء المتأصل في PySpark وAmazon EMR على تعزيز المتانة، حتى في حالة فشل العقد، مما يجعله خيارًا قابلاً للتطوير وفعالاً من حيث التكلفة وعالي الأداء لمعالجة البيانات المتوازية على AWS.

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

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

الهندسة المعمارية المعاد تصميمها

يوضح الرسم البياني التالي بنيتنا المعاد تصميمها.

يعمل الحل بموجب عقد واجهة برمجة التطبيقات (API)، حيث يمكن للعملاء إرسال تكوينات التحويل، وتحديد مجموعة العمليات إلى جانب موقع مجموعة بيانات S3 للمعالجة. يتم وضع الطلب في قائمة الانتظار من خلال Amazon SQS، ثم يتم توجيهه إلى Amazon EMR عبر وظيفة Lambda. تبدأ هذه العملية في إنشاء خطوة Amazon EMR لتنفيذ إطار عمل Spark على مجموعة EMR مخصصة. على الرغم من أن Amazon EMR يستوعب عددًا غير محدود من الخطوات على مدار عمر مجموعة طويلة التشغيل، إلا أنه يمكن تشغيل 256 خطوة فقط أو تعليقها في وقت واحد. لتحقيق الموازاة الأمثل، يتم ضبط تزامن الخطوات على 10، مما يسمح بتشغيل 10 خطوات بشكل متزامن. في حالة فشل الطلب، سيتم إرسال Amazon SQS طابور الرسائل الميتة (DLQ) يحتفظ بالحدث. تقوم Spark بمعالجة الطلب، وترجمة العمليات الشبيهة ببرنامج Excel إلى كود PySpark للحصول على خطة استعلام فعالة. تعمل إطارات البيانات المرنة على تخزين المدخلات والمخرجات والبيانات المتوسطة في الذاكرة، مما يعمل على تحسين سرعة المعالجة وتقليل تكلفة الإدخال/الإخراج للقرص وتحسين أداء عبء العمل وتسليم المخرجات النهائية إلى موقع Amazon S3 المحدد.

نحن نحدد اتفاقية مستوى الخدمة (SLA) الخاصة بنا في بعدين: زمن الوصول والإنتاجية. يتم تعريف زمن الوصول على أنه مقدار الوقت المستغرق لأداء مهمة واحدة مقابل حجم مجموعة بيانات محدد وعدد العمليات التي يتم إجراؤها على مجموعة البيانات. يتم تعريف الإنتاجية على أنها الحد الأقصى لعدد المهام المتزامنة التي يمكن للخدمة تنفيذها دون انتهاك اتفاقية مستوى الخدمة لزمن الاستجابة لمهمة واحدة. تعتمد قابلية التوسع الشاملة لاتفاقية مستوى الخدمة (SLA) للخدمة على توازن القياس الأفقي لموارد الحوسبة المرنة والتوسع الرأسي للخوادم الفردية.

نظرًا لأنه كان علينا تشغيل 1,500 عملية يوميًا بأقل زمن استجابة وأداء عالٍ، فقد اخترنا دمج Amazon EMR في وضع النشر EC2 مع تمكين التوسع المُدار لدعم معالجة أحجام الملفات المتغيرة.

يوفر تكوين مجموعة EMR العديد من الاختيارات المختلفة:

  • أنواع عقدة EMR - العقد الأساسية أو الأساسية أو المهمة
  • خيارات شراء المثيل – المثيلات عند الطلب، أو المثيلات المحجوزة، أو المثيلات الفورية
  • خيارات الإعداد – أسطول مثيل EMR أو مجموعة مثيلات موحدة
  • خيارات التحجيم - تحجيم تلقائي أو التوسع المُدار بواسطة Amazon EMR

استنادًا إلى عبء العمل المتغير لدينا، قمنا بتكوين أسطول مثيلات EMR (للاطلاع على أفضل الممارسات، راجع الموثوقية). قررنا أيضًا استخدام القياس المُدار بواسطة Amazon EMR لتوسيع نطاق العقد الأساسية وعقد المهام (للاطلاع على سيناريوهات القياس، راجع سيناريوهات تخصيص العقدة). وأخيرا، اخترنا الذاكرة الأمثل أوس جرافيتون الحالات، والتي توفر ما يصل إلى تكلفة أقل بنسبة 30% وأداء محسّن بنسبة تصل إلى 15% لأحمال عمل Spark.

توفر التعليمة البرمجية التالية لقطة لتكوين مجموعتنا:

Concurrent steps:10

EMR Managed Scaling:
minimumCapacityUnits: 64
maximumCapacityUnits: 512
maximumOnDemandCapacityUnits: 512
maximumCoreCapacityUnits: 512

Master Instance Fleet:
r6g.xlarge
- 4 vCore, 30.5 GiB memory, EBS only storage
- EBS Storage:250 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 1 units
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:250 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 1 units

Core Instance Fleet:
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 8 units
r6g.4xlarge
- 16 vCore, 122 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 16 units

Task Instances:
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 8 units
r6g.4xlarge
- 16 vCore, 122 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 16 units

الأداء

من خلال ترحيلنا إلى Amazon EMR، تمكنا من تحقيق أداء نظام قادر على التعامل مع مجموعة متنوعة من مجموعات البيانات، بدءًا من 273 بايت إلى 88.5 جيجابايت مع p99 491 ثانية (حوالي 8 دقائق).

يوضح الشكل التالي تنوع أحجام الملفات التي تمت معالجتها.

ويبين الشكل التالي الكمون لدينا.

للمقارنة مع المعالجة التسلسلية، أخذنا مجموعتي بيانات تحتويان على 53 مليون سجل وقمنا بتشغيل عملية VLOOKUP ضد بعضها البعض، بالإضافة إلى 49 عملية أخرى تشبه برنامج Excel. وقد استغرقت هذه العملية 26 دقيقة في الخدمة الجديدة، مقارنة بـ 5 أيام للمعالجة في الخدمة القديمة. وهذا التحسن أكبر بحوالي 300 مرة من البنية السابقة من حيث الأداء.

الاعتبارات

ضع في اعتبارك ما يلي عند النظر في هذا الحل:

  • مجموعات الحجم الصحيح – على الرغم من إمكانية تغيير حجم Amazon EMR، فمن المهم ضبط حجم المجموعات بشكل صحيح. يؤدي تحديد الحجم الصحيح إلى تخفيف المجموعة البطيئة، إذا كانت أصغر حجمًا، أو التكاليف الأعلى، إذا كانت المجموعة كبيرة الحجم. لتوقع هذه المشكلات، يمكنك حساب عدد ونوع العقد التي ستكون مطلوبة لأحمال العمل.
  • خطوات متوازية – يتيح لك تشغيل الخطوات بالتوازي تشغيل أحمال عمل أكثر تقدمًا، وزيادة استخدام موارد المجموعة، وتقليل مقدار الوقت المستغرق لإكمال عبء العمل الخاص بك. عدد الخطوات المسموح بتشغيلها في وقت واحد قابل للتكوين ويمكن ضبطه عند تشغيل المجموعة وفي أي وقت بعد بدء المجموعة. أنت بحاجة إلى مراعاة وتحسين استخدام وحدة المعالجة المركزية/الذاكرة لكل مهمة عند تشغيل مهام متعددة في مجموعة مشتركة واحدة.
  • مجموعات السجلات الطبية الإلكترونية المؤقتة القائمة على الوظيفة - إذا كان ذلك ممكنًا، فمن المستحسن استخدام مجموعة السجلات الطبية الإلكترونية العابرة القائمة على الوظيفة، والتي توفر عزلًا فائقًا، والتحقق من أن كل مهمة تعمل ضمن بيئتها المخصصة. يعمل هذا الأسلوب على تحسين استخدام الموارد، ويساعد على منع التداخل بين الوظائف، ويعزز الأداء العام والموثوقية. تتيح الطبيعة المؤقتة التوسع الفعال، مما يوفر حلاً قويًا ومعزولًا لاحتياجات معالجة البيانات المتنوعة.
  • EMR بدون خادم - يعد EMR Serverless الخيار المثالي إذا كنت تفضل عدم التعامل مع إدارة المجموعات وتشغيلها. فهو يتيح لك تشغيل التطبيقات بسهولة باستخدام أطر عمل مفتوحة المصدر متاحة ضمن EMR Serverless، مما يوفر تجربة مباشرة وخالية من المتاعب.
  • أمازون EMR على EKS - يوفر Amazon EMR على EKS مزايا مميزة، مثل أوقات بدء تشغيل أسرع وقابلية التوسع المحسنة لحل تحديات سعة الحوسبة - وهو أمر مفيد بشكل خاص لمستخدمي Graviton وSpot Instance. يؤدي تضمين نطاق أوسع من أنواع الحوسبة إلى تعزيز فعالية التكلفة، مما يسمح بتخصيص الموارد بشكل مخصص. علاوة على ذلك، يوفر دعم Multi-AZ زيادة في التوفر. توفر هذه الميزات الرائعة حلاً قويًا لإدارة أحمال عمل البيانات الضخمة مع تحسين الأداء وتحسين التكلفة والموثوقية عبر سيناريوهات الحوسبة المختلفة.

وفي الختام

في هذا المنشور، أوضحنا كيف قامت أمازون بتحسين عملية التسوية المالية كبيرة الحجم مع Amazon EMR لزيادة قابلية التوسع والأداء. إذا كان لديك تطبيق متجانس يعتمد على القياس الرأسي لمعالجة الطلبات أو مجموعات البيانات الإضافية، فإن ترحيله إلى إطار معالجة موزع مثل Apache Spark واختيار خدمة مُدارة مثل Amazon EMR للحوسبة قد يساعد في تقليل وقت التشغيل لتقليل التسليم اتفاقية مستوى الخدمة (SLA)، وقد تساعد أيضًا في تقليل التكلفة الإجمالية للملكية (TCO).

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


حول المؤلف

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

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

بقعة_صورة

أحدث المعلومات الاستخباراتية

بقعة_صورة