تطبیق حساب ها گام مهمی برای اطمینان از کامل بودن و صحت صورت های مالی است. به طور خاص، شرکت ها باید آشتی کنند ترازنامه حساب‌هایی که می‌توانند حاوی تحریف‌های مهم یا با اهمیت باشند. حسابداران هر یک از حساب ها را در دفتر کل حساب ها بررسی می کنند و بررسی می کنند که موجودی فهرست شده کامل و دقیق است. هنگامی که مغایرت ها پیدا می شود، حسابداران به بررسی و اقدامات اصلاحی مناسب می پردازند.

به عنوان بخشی از سازمان فین‌تک آمازون، ما یک پلتفرم نرم‌افزاری ارائه می‌دهیم که به تیم‌های حسابداری داخلی آمازون برای انجام تطبیق حساب‌ها قدرت می‌دهد. برای بهینه‌سازی فرآیند تطبیق، این کاربران به تغییر عملکرد بالا با قابلیت مقیاس‌بندی بر اساس تقاضا، و همچنین توانایی پردازش اندازه‌های فایل متغیر از چند مگابایت تا بیش از ۱۰۰ گیگابایت نیاز دارند. همیشه نمی‌توان داده‌ها را بر روی یک ماشین قرار داد یا آن‌ها را با یک برنامه واحد در یک بازه زمانی معقول پردازش کرد. این محاسبه باید به اندازه کافی سریع انجام شود تا خدمات عملی ارائه شود که در آن منطق برنامه نویسی و جزئیات زیربنایی (توزیع داده ها، تحمل خطا و زمان بندی) قابل تفکیک هستند.

ما می‌توانیم با استفاده از راه‌حل‌های پردازش داده‌های توزیع‌شده، به این محاسبات همزمان بر روی چندین ماشین یا رشته‌های یک تابع در بین گروه‌های عناصر یک مجموعه داده دست یابیم. این ما را تشویق کرد تا سرویس تطبیق خود را با پشتیبانی از خدمات AWS، از جمله، دوباره اختراع کنیم آمازون EMR و جرقه آپاچی چارچوب پردازش توزیع شده، که استفاده می کند PySpark. این سرویس به کاربران این امکان را می دهد تا فایل های بیش از 100 گیگابایت را که حاوی 100 میلیون تراکنش هستند در کمتر از 30 دقیقه پردازش کنند. سرویس آشتی به یک نیروگاه برای پردازش داده ها تبدیل شده است و اکنون کاربران می توانند به طور یکپارچه انواع عملیات مانند محور, بپیوندید (مانند عملیات Excel VLOOKUP)، ریاضی عملیات، و بیش، ارائه یک راه حل همه کاره و کارآمد برای تطبیق مجموعه داده های گسترده. این پیشرفت گواهی بر مقیاس پذیری و سرعت به دست آمده از طریق اتخاذ راه حل های پردازش داده های توزیع شده است.

در این پست، توضیح می‌دهیم که چگونه آمازون EMR را برای ایجاد یک سیستم بسیار در دسترس و مقیاس‌پذیر که ما را قادر می‌سازد یک فرآیند آشتی مالی با حجم بالا را اجرا کنیم، یکپارچه کردیم.

معماری قبل از مهاجرت

نمودار زیر معماری قبلی ما را نشان می دهد.

خدمات قدیمی ما با ساخته شده است سرویس کانتینر الاستیک آمازون (Amazon ECS) روشن است AWS Fargate. ما داده ها را به صورت متوالی با استفاده از پایتون پردازش کردیم. با این حال، به دلیل عدم توانایی پردازش موازی، ما اغلب مجبور بودیم اندازه خوشه را به صورت عمودی افزایش دهیم تا از مجموعه داده های بزرگتر پشتیبانی کنیم. برای زمینه، 5 گیگابایت داده با 50 عملیات حدود 3 ساعت طول کشید تا پردازش شود. این سرویس به گونه‌ای پیکربندی شده است که به صورت افقی به پنج نمونه ECS که پیام‌ها را از آن‌ها نظرسنجی می‌کنند، مقیاس‌بندی شود سرویس صف ساده آمازون (Amazon SQS)، که درخواست های تبدیل را تغذیه کرد. هر نمونه با 4 vCPU و 30 گیگابایت حافظه پیکربندی شده بود تا امکان مقیاس افقی را فراهم کند. با این حال، ما نتوانستیم ظرفیت آن را در عملکرد افزایش دهیم زیرا این فرآیند به صورت متوالی اتفاق افتاد و تکه‌هایی از داده‌ها را از سرویس ذخیره سازی ساده آمازون (Amazon S3) برای پردازش. به عنوان مثال، یک عملیات VLOOKUP که در آن دو فایل باید به یکدیگر متصل شوند، نیاز به خواندن هر دو فایل در حافظه تکه تکه برای به دست آوردن خروجی دارد. این به یک مانع برای کاربران تبدیل شد زیرا آنها مجبور بودند برای پردازش مجموعه داده های خود مدت زمان طولانی منتظر بمانند.

به عنوان بخشی از معماری مجدد و مدرن سازی، ما می خواستیم به موارد زیر دست یابیم:

• در دسترس بودن بالا - خوشه های پردازش داده باید بسیار در دسترس باشند و سه 9s در دسترس (99.9٪) را فراهم کنند.
• ظرفیت تولید - این سرویس باید 1,500 بار در روز را انجام دهد
• تاخیر - باید بتواند 100 گیگابایت داده را در 30 دقیقه پردازش کند
• ناهمگونی - خوشه باید بتواند طیف گسترده ای از بارهای کاری را با فایل هایی از چند مگابایت تا صدها گیگابایت پشتیبانی کند.
• همزمانی پرس و جو - پیاده سازی نیازمند توانایی پشتیبانی از حداقل 10 درجه همزمانی است
• قابلیت اطمینان مشاغل و سازگاری داده ها - برای جلوگیری از شکستن قراردادهای سطح خدمات (SLA) مشاغل باید به طور قابل اعتماد و مداوم اجرا شوند.
• مقرون به صرفه و مقیاس پذیر - باید بر اساس حجم کار مقیاس پذیر باشد و مقرون به صرفه باشد
• امنیت و انطباق - با توجه به حساسیت داده ها، باید از کنترل دسترسی دقیق و پیاده سازی های امنیتی مناسب پشتیبانی کند
• نظارت - راه حل باید نظارت کامل بر خوشه ها و مشاغل را ارائه دهد

چرا آمازون EMR

Amazon EMR راه حل ابر داده های بزرگ پیشرو در صنعت برای پردازش داده در مقیاس پتابایت، تجزیه و تحلیل تعاملی و یادگیری ماشینی (ML) با استفاده از چارچوب های منبع باز مانند جرقه آپاچی, آپاچی کندوو تند. با استفاده از این چارچوب‌ها و پروژه‌های منبع باز مرتبط، می‌توانید داده‌ها را برای اهداف تحلیلی و بار کاری BI پردازش کنید. آمازون EMR به شما امکان می دهد حجم زیادی از داده ها را به داخل و خارج از دیگر فروشگاه ها و پایگاه های داده AWS مانند Amazon S3 و آمازون DynamoDB.

مزیت قابل توجه آمازون EMR در استفاده موثر آن از پردازش موازی با PySpark است که نشان دهنده پیشرفت قابل توجهی نسبت به کدهای متوالی پایتون سنتی است. این رویکرد نوآورانه استقرار و مقیاس بندی خوشه های Apache Spark را ساده می کند و امکان موازی سازی کارآمد در مجموعه داده های بزرگ را فراهم می کند. زیرساخت محاسباتی توزیع شده نه تنها عملکرد را بهبود می بخشد، بلکه پردازش حجم وسیعی از داده ها را با سرعت بی سابقه ای امکان پذیر می کند. PySpark که به کتابخانه‌ها مجهز است، عملیات اکسل مانند را تسهیل می‌کند فریم های دادهو انتزاع سطح بالاتر DataFrames دستکاری های پیچیده داده را ساده می کند و پیچیدگی کد را کاهش می دهد. آمازون EMR همراه با تامین خودکار خوشه، تخصیص منابع پویا و ادغام با سایر سرویس‌های AWS، راه‌حلی همه کاره است که برای بارهای کاری متنوع، از پردازش دسته‌ای تا ML مناسب است. تحمل خطای ذاتی در PySpark و Amazon EMR استحکام را حتی در صورت خرابی گره افزایش می‌دهد و آن را به انتخابی مقیاس‌پذیر، مقرون‌به‌صرفه و با کارایی بالا برای پردازش داده‌های موازی در AWS تبدیل می‌کند.

آمازون EMR قابلیت‌های خود را فراتر از اصول اولیه گسترش می‌دهد و گزینه‌های استقرار مختلفی را برای رفع نیازهای مختلف ارائه می‌دهد. خواه این باشد آمازون EMR در EC2, آمازون EMR در EKS, آمازون EMR بدون سرور، یا آمازون EMR در Outposts AWS، می توانید رویکرد خود را بر اساس نیازهای خاص تنظیم کنید. برای کسانی که به دنبال یک محیط بدون سرور برای مشاغل Spark، یکپارچه سازی هستند چسب AWS همچنین یک گزینه قابل اجرا است. آمازون EMR علاوه بر پشتیبانی از چارچوب‌های منبع باز مختلف، از جمله Spark، انعطاف‌پذیری در انتخاب حالت‌های استقرار فراهم می‌کند. ابر محاسبه الاستیک آمازون انواع نمونه (Amazon EC2)، مکانیسم‌های مقیاس‌بندی و تکنیک‌های متعدد بهینه‌سازی صرفه‌جویی در هزینه.

آمازون EMR به عنوان یک نیروی پویا در فضای ابری می ایستد و قابلیت های بی نظیری را برای سازمان هایی که به دنبال راه حل های کلان داده قوی هستند ارائه می دهد. یکپارچه‌سازی یکپارچه، ویژگی‌های قدرتمند و سازگاری آن، آن را به ابزاری ضروری برای پیمایش پیچیدگی‌های تجزیه و تحلیل داده‌ها و ML در AWS تبدیل می‌کند.

معماری بازطراحی شده

نمودار زیر معماری بازطراحی شده ما را نشان می دهد.

این راه حل تحت یک قرارداد API عمل می کند، که در آن مشتریان می توانند پیکربندی های تبدیل را ارسال کنند و مجموعه ای از عملیات را در کنار مکان داده S3 برای پردازش تعریف کنند. درخواست از طریق Amazon SQS در صف قرار می گیرد، سپس از طریق تابع Lambda به Amazon EMR هدایت می شود. این فرآیند ایجاد یک مرحله آمازون EMR را برای اجرای چارچوب Spark بر روی یک خوشه اختصاصی EMR آغاز می کند. اگرچه آمازون EMR تعداد نامحدودی از مراحل را در طول عمر یک خوشه طولانی در نظر می گیرد، تنها 256 مرحله می توانند به طور همزمان در حال اجرا یا معلق باشند. برای موازی سازی بهینه، همزمانی گام روی 10 تنظیم شده است که به 10 مرحله اجازه می دهد همزمان اجرا شوند. در صورت عدم موفقیت درخواست، Amazon SQS صف نامه مرده (DLQ) رویداد را حفظ می کند. Spark درخواست را پردازش می کند و عملیات اکسل مانند را به کد PySpark برای یک طرح پرس و جو کارآمد ترجمه می کند. DataFrames ارتجاعی ورودی، خروجی و داده‌های میانی را در حافظه ذخیره می‌کند، سرعت پردازش را بهینه می‌کند، هزینه ورودی/خروجی دیسک را کاهش می‌دهد، عملکرد بار کاری را افزایش می‌دهد و خروجی نهایی را به مکان مشخص شده Amazon S3 تحویل می‌دهد.

ما SLA خود را در دو بعد تعریف می کنیم: تأخیر و توان عملیاتی. تأخیر به عنوان مقدار زمان صرف شده برای انجام یک کار در برابر اندازه مجموعه داده قطعی و تعداد عملیات انجام شده بر روی مجموعه داده تعریف می شود. توان عملیاتی به عنوان حداکثر تعداد کارهای همزمانی که سرویس می تواند بدون نقض SLA تأخیر یک کار انجام دهد، تعریف می شود. مقیاس پذیری کلی SLA سرویس به تعادل مقیاس افقی منابع محاسباتی الاستیک و مقیاس عمودی سرورهای جداگانه بستگی دارد.

از آنجایی که مجبور بودیم روزانه 1,500 فرآیند را با حداقل تأخیر و کارایی بالا اجرا کنیم، آمازون EMR را در حالت استقرار EC2 با مقیاس مدیریت شده فعال برای پشتیبانی از پردازش اندازه‌های متغیر فایل ادغام می‌کنیم.

پیکربندی خوشه EMR انتخاب های مختلفی را ارائه می دهد:

• انواع گره EMR - گره های اصلی، هسته یا وظیفه
• گزینه های خرید نمونه - نمونه های درخواستی، نمونه های رزرو شده یا نمونه های نقطه ای
• گزینه های پیکربندی - ناوگان نمونه EMR یا گروه نمونه یکنواخت
• گزینه های مقیاس بندی - مقیاس گذاری خودکار یا مقیاس پذیری مدیریت شده آمازون EMR

بر اساس حجم کاری متغیر خود، یک ناوگان نمونه EMR را پیکربندی کردیم (برای بهترین شیوه ها، نگاه کنید به قابلیت اطمینان). ما همچنین تصمیم گرفتیم از مقیاس بندی مدیریت شده آمازون EMR برای مقیاس بندی گره های هسته و وظیفه استفاده کنیم (برای سناریوهای مقیاس بندی، به سناریوهای تخصیص گره). در نهایت، ما حافظه بهینه شده را انتخاب کردیم AWS Graviton مواردی که تا 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

عملکرد

با مهاجرت خود به آمازون EMR، ما توانستیم به عملکرد سیستمی دست یابیم که قادر به مدیریت مجموعه داده های مختلف، از 273 B تا حداکثر 88.5 گیگابایت با p99 491 ثانیه (تقریباً 8 دقیقه).

شکل زیر تنوع اندازه فایل های پردازش شده را نشان می دهد.

شکل زیر تأخیر ما را نشان می دهد.

برای مقایسه در برابر پردازش متوالی، ما دو مجموعه داده حاوی 53 میلیون رکورد را انتخاب کردیم و یک عملیات VLOOKUP را به همراه 49 عملیات مشابه اکسل علیه یکدیگر اجرا کردیم. پردازش در سرویس جدید 26 دقیقه طول کشید، در مقایسه با 5 روز برای پردازش در سرویس قدیمی. این پیشرفت از نظر عملکرد تقریباً 300 برابر بیشتر از معماری قبلی است.

ملاحظات

هنگام بررسی این راه حل موارد زیر را در نظر داشته باشید:

• خوشه هایی با اندازه مناسب – اگرچه آمازون EMR قابل تغییر اندازه است، مهم است که خوشه‌ها را اندازه درست کنید. اندازه مناسب خوشه کند را کاهش می دهد، اگر اندازه آن کم باشد، یا هزینه های بالاتر را، اگر خوشه بزرگ باشد، کاهش می دهد. برای پیش‌بینی این مسائل، می‌توانید تعداد و نوع گره‌هایی را که برای بارهای کاری مورد نیاز خواهند بود، محاسبه کنید.
• مراحل موازی – اجرای موازی مراحل به شما امکان می دهد بارهای کاری پیشرفته تری را اجرا کنید، استفاده از منابع خوشه ای را افزایش دهید و زمان صرف شده برای تکمیل حجم کاری خود را کاهش دهید. تعداد مراحل مجاز برای اجرا در یک زمان قابل تنظیم است و می توان آن را هنگام راه اندازی یک خوشه و هر زمان پس از شروع خوشه تنظیم کرد. هنگامی که چندین کار در یک کلاستر مشترک در حال اجرا هستند، باید مصرف CPU/حافظه را در هر کار در نظر بگیرید و بهینه کنید.
• خوشه های گذرا EMR مبتنی بر شغل - در صورت امکان، توصیه می شود از یک خوشه EMR گذرا مبتنی بر کار استفاده کنید که جداسازی عالی را ارائه می دهد و تأیید می کند که هر وظیفه در محیط اختصاصی خود عمل می کند. این رویکرد استفاده از منابع را بهینه می کند، به جلوگیری از تداخل بین مشاغل کمک می کند و عملکرد و قابلیت اطمینان کلی را افزایش می دهد. ماهیت گذرا مقیاس بندی کارآمد را امکان پذیر می کند و راه حلی قوی و ایزوله برای نیازهای مختلف پردازش داده ارائه می دهد.
• EMR بدون سرور - اگر ترجیح می دهید مدیریت و عملیات خوشه ها را مدیریت نکنید، بدون سرور EMR انتخاب ایده آلی است. این به شما امکان می دهد بدون زحمت برنامه ها را با استفاده از چارچوب های منبع باز موجود در EMR Serverless اجرا کنید و تجربه ای ساده و بدون دردسر را ارائه دهید.
• آمازون EMR در EKS – آمازون EMR در EKS مزایای متمایزی مانند زمان راه‌اندازی سریع‌تر و بهبود مقیاس‌پذیری حل چالش‌های ظرفیت محاسباتی را ارائه می‌دهد – که به ویژه برای کاربران Graviton و Spot Instance مفید است. گنجاندن طیف وسیع تری از انواع محاسبات، کارایی هزینه را افزایش می دهد و امکان تخصیص منابع متناسب را فراهم می کند. علاوه بر این، پشتیبانی Multi-AZ افزایش دسترسی را فراهم می کند. این ویژگی های قانع کننده راه حلی قوی برای مدیریت حجم کاری داده های بزرگ با عملکرد بهبود یافته، بهینه سازی هزینه و قابلیت اطمینان در سناریوهای مختلف محاسباتی ارائه می دهد.

نتیجه

در این پست، توضیح دادیم که چگونه آمازون فرآیند تطبیق مالی با حجم بالا را با آمازون EMR برای مقیاس‌پذیری و عملکرد بالاتر بهینه کرد. اگر یک برنامه یکپارچه دارید که برای پردازش درخواست ها یا مجموعه داده های اضافی به مقیاس عمودی وابسته است، انتقال آن به یک چارچوب پردازش توزیع شده مانند Apache Spark و انتخاب یک سرویس مدیریت شده مانند آمازون EMR برای محاسبه ممکن است به کاهش زمان اجرا برای کاهش تحویل شما کمک کند. SLA، و همچنین ممکن است به کاهش هزینه کل مالکیت (TCO) کمک کند.

همانطور که ما آمازون EMR را برای این مورد خاص مورد استفاده قرار می‌دهیم، شما را تشویق می‌کنیم تا احتمالات بیشتری را در سفر نوآوری داده خود بررسی کنید. ارزیابی AWS Glue را به همراه سایر گزینه‌های استقرار پویا EMR آمازون مانند EMR Serverless یا Amazon EMR در EKS در نظر بگیرید تا بهترین سرویس AWS متناسب با موارد استفاده منحصر به فرد شما را کشف کنید. آینده سفر نوآوری داده، احتمالات و پیشرفت های هیجان انگیزی را در خود جای داده است که باید بیشتر مورد بررسی قرار گیرد.

درباره نویسنده

جیشان ختراپل مهندس توسعه نرم‌افزار Sr. در آمازون است، جایی که محصولات فین‌تک را بر اساس معماری‌های بدون سرور رایانش ابری توسعه می‌دهد که مسئولیت کنترل‌های عمومی فناوری اطلاعات، گزارش‌های مالی، و کنترل‌کننده‌های حاکمیت، ریسک و انطباق را بر عهده دارند.

ساکتی میشرا معمار راه حل های اصلی در AWS است، جایی که به مشتریان کمک می کند تا معماری داده خود را مدرن کنند و استراتژی داده سرتاسر خود را از جمله امنیت داده، دسترسی، حاکمیت و غیره تعریف کنند. وی همچنین نویسنده کتاب است تجزیه و تحلیل داده های بزرگ را با آمازون EMR ساده کنید. ساکتی خارج از محل کار از یادگیری فناوری های جدید، تماشای فیلم و بازدید از مکان ها با خانواده لذت می برد.

• محتوای مبتنی بر SEO و توزیع روابط عمومی. امروز تقویت شوید.
• PlatoData.Network Vertical Generative Ai. به خودت قدرت بده دسترسی به اینجا.
• PlatoAiStream. هوش وب 3 دانش تقویت شده دسترسی به اینجا.
• PlatoESG. کربن ، CleanTech، انرژی، محیط، خورشیدی، مدیریت پسماند دسترسی به اینجا.
• PlatoHealth. هوش بیوتکنولوژی و آزمایشات بالینی. دسترسی به اینجا.
• منبع: https://aws.amazon.com/blogs/big-data/how-amazon-optimized-its-high-volume-financial-reconciliation-process-with-amazon-emr-for-higher-scalability-and-performance/