Звірка рахунків є важливим кроком для забезпечення повноти та точності фінансової звітності. Зокрема, компанії повинні узгоджуватися бухгалтерський баланс рахунки, які можуть містити значні або суттєві викривлення. Бухгалтери переглядають кожен рахунок у головній книзі рахунків і перевіряють, чи зазначений баланс є повним і точним. У разі виявлення невідповідностей бухгалтери проводять розслідування та вживають відповідних заходів щодо виправлення.

Як частина організації Amazon FinTech ми пропонуємо програмну платформу, яка дає змогу внутрішнім групам бухгалтерів Amazon проводити звірку рахунків. Для оптимізації процесу узгодження цим користувачам потрібна високопродуктивна трансформація з можливістю масштабування за вимогою, а також здатність обробляти файли змінних розмірів від кількох МБ до понад 100 ГБ. Не завжди можливо розмістити дані на одній машині або обробити їх за допомогою однієї програми за розумний проміжок часу. Це обчислення має виконуватися достатньо швидко, щоб надавати практичні послуги, де логіку програмування та базові деталі (розподіл даних, відмовостійкість і планування) можна розділити.

Ми можемо досягти цих одночасних обчислень на кількох машинах або потоках однієї функції в групах елементів набору даних за допомогою розподілених рішень обробки даних. Це спонукало нас переосмислити нашу службу звірки, включно з послугами AWS Amazon EMR і Apache Spark структура розподіленої обробки, яка використовує PySpark. Цей сервіс дозволяє користувачам обробляти файли розміром понад 100 ГБ, що містять до 100 мільйонів транзакцій, менш ніж за 30 хвилин. Служба узгодження стала потужним центром обробки даних, і тепер користувачі можуть безперешкодно виконувати різноманітні операції, як-от Стрижень, РЕЄСТРАЦІЯ (як операція Excel VLOOKUP), арифметика операції, і більше, що забезпечує універсальне та ефективне рішення для узгодження величезних наборів даних. Це вдосконалення є свідченням масштабованості та швидкості, досягнутої завдяки застосуванню рішень розподіленої обробки даних.

У цій публікації ми пояснюємо, як ми інтегрували Amazon EMR, щоб створити високодоступну та масштабовану систему, яка дала нам змогу запустити процес фінансової звірки великого обсягу.

Архітектура до міграції

Наступна схема ілюструє нашу попередню архітектуру.

Наша застаріла служба створена за допомогою Служба еластичних контейнерів Amazon (Amazon ECS) увімкнено AWS Fargate. Ми послідовно обробляли дані за допомогою Python. Однак через відсутність можливості паралельної обробки нам часто доводилося збільшувати розмір кластера по вертикалі, щоб підтримувати більші набори даних. Для контексту обробка 5 ГБ даних із 50 операціями зайняла близько 3 годин. Цю службу було налаштовано для горизонтального масштабування до п’яти примірників ECS, які опитували повідомлення Служба простої черги Amazon (Amazon SQS), який надсилав запити на перетворення. Кожен екземпляр було налаштовано з 4 vCPU і 30 ГБ пам’яті, щоб забезпечити горизонтальне масштабування. Однак ми не змогли розширити його продуктивність, оскільки процес відбувався послідовно, вибираючи фрагменти даних із Служба простого зберігання Amazon (Amazon S3) для обробки. Наприклад, операція VLOOKUP, у якій два файли повинні бути об’єднані, вимагала зчитування обох файлів у пам’яті фрагмент за фрагментом для отримання результату. Це стало перешкодою для користувачів, оскільки їм доводилося довго чекати, щоб обробити свої набори даних.

У рамках нашої реархітектури та модернізації ми хотіли досягти наступного:

• Висока доступність – Кластери обробки даних повинні бути високодоступними, забезпечуючи три дев’ятки доступності (9%)
• Пропускна здатність – Сервіс повинен обслуговувати 1,500 прогонів на день
• Затримка – Він повинен мати можливість обробити 100 ГБ даних протягом 30 хвилин
• Неоднорідність – Кластер повинен мати можливість підтримувати широкий спектр робочих навантажень із розміром файлів від кількох МБ до сотень ГБ.
• Одночасність запитів – Реалізація вимагає здатності підтримувати мінімум 10 ступенів паралельності
• Надійність завдань і узгодженість даних – Роботи мають виконуватися надійно та послідовно, щоб уникнути порушення угод про рівень обслуговування (SLA).
• Економічно ефективно та масштабовано – Він повинен бути масштабованим залежно від робочого навантаження, що робить його економічно ефективним
• Безпека та відповідність – Враховуючи конфіденційність даних, вони повинні підтримувати детальний контроль доступу та відповідні реалізації безпеки
• Моніторинг – Рішення має пропонувати наскрізний моніторинг кластерів і завдань

Чому Amazon EMR

Amazon EMR — це провідне в галузі хмарне рішення для великих даних для обробки петабайтних даних, інтерактивної аналітики та машинного навчання (ML) із використанням фреймворків з відкритим кодом, таких як Apache Spark, Вулик апачів та Престо. За допомогою цих фреймворків і відповідних проектів з відкритим кодом ви можете обробляти дані для цілей аналітики та робочих навантажень BI. Amazon EMR дозволяє трансформувати та переміщувати великі обсяги даних у та з інших сховищ даних і баз даних AWS, таких як Amazon S3 та Amazon DynamoDB.

Помітною перевагою Amazon EMR є ефективне використання паралельної обробки з PySpark, що є значним покращенням у порівнянні з традиційним послідовним кодом Python. Цей інноваційний підхід спрощує розгортання та масштабування кластерів Apache Spark, забезпечуючи ефективне розпаралелювання великих наборів даних. Розподілена обчислювальна інфраструктура не тільки підвищує продуктивність, але й дозволяє обробляти величезні обсяги даних з безпрецедентною швидкістю. Оснащений бібліотеками, PySpark полегшує операції, подібні до Excel Фрейми даних, а абстракція вищого рівня DataFrames спрощує складні маніпуляції з даними, зменшуючи складність коду. У поєднанні з автоматичним наданням кластерів, динамічним розподілом ресурсів та інтеграцією з іншими сервісами AWS Amazon EMR виявився універсальним рішенням, яке підходить для різноманітних робочих навантажень, починаючи від пакетної обробки й закінчуючи машинним навчанням. Внутрішня відмовостійкість PySpark і Amazon EMR сприяє надійності навіть у разі збою вузла, що робить його масштабованим, економічно ефективним і високопродуктивним вибором для паралельної обробки даних на AWS.

Amazon EMR розширює свої можливості за межі базових, пропонуючи різноманітні варіанти розгортання для задоволення різноманітних потреб. Чи так Amazon EMR на EC2, Amazon EMR на EKS, Amazon EMR без сервераабо Amazon EMR на AWS Outposts, ви можете пристосувати свій підхід до конкретних вимог. Для тих, хто шукає безсерверне середовище для завдань Spark, інтеграція Клей AWS також є життєздатним варіантом. Окрім підтримки різноманітних фреймворків з відкритим кодом, зокрема Spark, Amazon EMR забезпечує гнучкість у виборі режимів розгортання, Обчислювальна хмара Amazon Elastic (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 для ефективного плану запиту. Еластичні DataFrames зберігають вхідні, вихідні та проміжні дані в пам’яті, оптимізуючи швидкість обробки, зменшуючи вартість дискового вводу/виводу, підвищуючи продуктивність робочого навантаження та доставляючи кінцевий вихід у вказане розташування Amazon S3.

Ми визначаємо наш SLA у двох вимірах: затримка та пропускна здатність. Затримка визначається як час, необхідний для виконання однієї роботи з детермінованим розміром набору даних і кількістю операцій, виконаних над набором даних. Пропускна здатність визначається як максимальна кількість одночасних завдань, які служба може виконувати без порушення затримки SLA для одного завдання. Загальна масштабованість SLA служби залежить від балансу горизонтального масштабування еластичних обчислювальних ресурсів і вертикального масштабування окремих серверів.

Оскільки нам потрібно було запускати 1,500 процесів на день із мінімальною затримкою та високою продуктивністю, ми вирішили інтегрувати Amazon EMR у режим розгортання EC2 із увімкненим керованим масштабуванням для підтримки обробки змінних розмірів файлів.

Конфігурація кластера EMR надає багато різних варіантів вибору:

• Типи вузлів ЕМВ – Основні, основні або вузли завдань
• Варіанти придбання примірників – Екземпляри на вимогу, зарезервовані екземпляри або спотові екземпляри
• Параметри конфігурації – Парк екземплярів EMR або уніфікована група екземплярів
• Параметри масштабування - Автоматичне масштабування або кероване масштабування Amazon EMR

Базуючись на нашому змінному робочому навантаженні, ми налаштували парк екземплярів EMR (найкращі практики див. Надійність). Ми також вирішили використовувати кероване масштабування Amazon EMR для масштабування вузлів ядра та завдань (для сценаріїв масштабування див. Сценарії розподілу вузлів). Нарешті, ми вибрали оптимізовану пам’ять AWS Гравітон екземпляри, які забезпечують до На 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-кластер на основі завдань, який забезпечує чудову ізоляцію, перевіряючи, що кожне завдання працює у своєму спеціальному середовищі. Цей підхід оптимізує використання ресурсів, допомагає запобігти перешкодам між завданнями та підвищує загальну продуктивність і надійність. Перехідний характер забезпечує ефективне масштабування, забезпечуючи надійне та ізольоване рішення для різноманітних потреб обробки даних.
• EMR без сервера – EMR Serverless є ідеальним вибором, якщо ви не бажаєте займатися керуванням та роботою кластерів. Це дозволяє без особливих зусиль запускати програми за допомогою фреймворків з відкритим кодом, доступних у EMR Serverless, пропонуючи простий і безпроблемний досвід.
• Amazon EMR на EKS – Amazon EMR на EKS пропонує суттєві переваги, такі як швидший час запуску та покращена масштабованість, що дозволяє вирішити проблеми з обчислювальною потужністю, що особливо корисно для користувачів Graviton і Spot Instance. Включення ширшого діапазону типів обчислень підвищує економічну ефективність, дозволяючи індивідуально розподіляти ресурси. Крім того, підтримка Multi-AZ забезпечує підвищену доступність. Ці переконливі функції забезпечують надійне рішення для керування великими обсягами даних із покращеною продуктивністю, оптимізацією витрат і надійністю в різних обчислювальних сценаріях.

Висновок

У цій публікації ми пояснили, як Amazon оптимізувала свій процес фінансової звірки великих обсягів за допомогою Amazon EMR для підвищення масштабованості та продуктивності. Якщо у вас є монолітна програма, яка залежить від вертикального масштабування для обробки додаткових запитів або наборів даних, перенесення її на розподілену обробну структуру, як-от Apache Spark, і вибір керованої служби, як-от Amazon EMR, для обчислень може допомогти скоротити час виконання та зменшити доставку. SLA, а також може допомогти знизити загальну вартість володіння (TCO).

Оскільки ми використовуємо Amazon EMR для цього конкретного випадку використання, ми заохочуємо вас досліджувати подальші можливості на вашому шляху інноваційних даних. Розгляньте можливість оцінити AWS Glue разом з іншими динамічними варіантами розгортання Amazon EMR, такими як EMR Serverless або Amazon EMR на EKS, щоб знайти найкращий сервіс AWS, адаптований до вашого унікального випадку використання. Майбутнє інноваційної подорожі даних містить захоплюючі можливості та досягнення, які потрібно вивчати далі.

Про авторів

Джишан Кетрапал є старшим інженером з розробки програмного забезпечення в Amazon, де він розробляє фінтех-продукти на основі безсерверних архітектур хмарних обчислень, які відповідають за загальний контроль ІТ-компаній, фінансову звітність і контроль за управлінням, ризиками та відповідністю.

Шакті Мішра є головним архітектором рішень в AWS, де він допомагає клієнтам модернізувати їхню архітектуру даних і визначити їхню наскрізну стратегію даних, включаючи безпеку даних, доступність, управління тощо. Він також є автором книги Спростіть аналіз великих даних за допомогою Amazon EMR. Поза роботою Шакті любить вивчати нові технології, дивитися фільми та відвідувати місця з родиною.

• Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
• PlatoData.Network Vertical Generative Ai. Додайте собі сили. Доступ тут.
• PlatoAiStream. Web3 Intelligence. Розширення знань. Доступ тут.
• ПлатонЕСГ. вуглець, 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/