Сверка счетов является важным шагом для обеспечения полноты и точности финансовой отчетности. В частности, компании должны согласовать баланс отчеты, которые могут содержать существенные или существенные искажения. Бухгалтеры просматривают каждую учетную запись в главной книге счетов и проверяют, что указанный баланс является полным и точным. При обнаружении несоответствий бухгалтеры проводят расследование и принимают соответствующие корректирующие меры.

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

Мы можем добиться этих одновременных вычислений на нескольких машинах или потоках одной и той же функции в группах элементов набора данных, используя решения распределенной обработки данных. Это побудило нас заново изобрести нашу службу выверки данных на базе сервисов AWS, в том числе Амазонка ЭМИ и Apache Spark инфраструктура распределенной обработки, которая использует ПиСпарк. Этот сервис позволяет пользователям обрабатывать файлы размером более 100 ГБ, содержащие до 100 миллионов транзакций, менее чем за 30 минут. Служба сверки стала мощным инструментом обработки данных, и теперь пользователи могут беспрепятственно выполнять различные операции, такие как Стержень, РЕГИСТРАЦИЯ (например, операция ВПР в Excel), арифметика операции, и БОЛЕЕ , предоставляя универсальное и эффективное решение для согласования огромных наборов данных. Это улучшение является свидетельством масштабируемости и скорости, достигнутых за счет внедрения решений распределенной обработки данных.

В этом посте мы объясним, как мы интегрировали Amazon EMR для создания высокодоступной и масштабируемой системы, которая позволила нам запустить крупномасштабный процесс финансовой выверки.

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

Следующая диаграмма иллюстрирует нашу предыдущую архитектуру.

Наш устаревший сервис был создан с использованием Amazon Elastic Контейнерный Сервис (Amazon ECS) на АМС Фаргейт. Мы обрабатывали данные последовательно с помощью Python. Однако из-за отсутствия возможности параллельной обработки нам часто приходилось увеличивать размер кластера по вертикали для поддержки больших наборов данных. Для сравнения: обработка 5 ГБ данных с 50 операциями заняла около 3 часов. Эта служба была настроена для горизонтального масштабирования до пяти экземпляров ECS, которые опрашивали сообщения от Простой сервис очередей Amazon (Amazon SQS), который подавал запросы на преобразование. Каждый экземпляр был настроен с 4 виртуальными ЦП и 30 ГБ памяти для обеспечения горизонтального масштабирования. Однако мы не могли расширить его возможности по производительности, поскольку процесс происходил последовательно, отбирая фрагменты данных из Простой сервис хранения Amazon (Amazon S3) для обработки. Например, операция VLOOKUP, в которой необходимо объединить два файла, требовала, чтобы оба файла были прочитаны в памяти по частям, чтобы получить выходные данные. Это стало препятствием для пользователей, поскольку им приходилось долго ждать обработки своих наборов данных.

В рамках нашей реархитектуры и модернизации мы хотели добиться следующего:

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

Почему Amazon EMR

Amazon EMR — это ведущее в отрасли облачное решение для больших данных для обработки петабайтных данных, интерактивной аналитики и машинного обучения (ML) с использованием платформ с открытым исходным кодом, таких как Apache Spark, Апачский улейкачества Presto. С помощью этих платформ и связанных с ними проектов с открытым исходным кодом вы можете обрабатывать данные для целей аналитики и рабочих нагрузок 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 (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.

Мы определяем наше соглашение об уровне обслуживания в двух измерениях: задержка и пропускная способность. Задержка определяется как количество времени, затраченное на выполнение одного задания при детерминированном размере набора данных и количестве операций, выполняемых с набором данных. Пропускная способность определяется как максимальное количество одновременных заданий, которые служба может выполнять без нарушения соглашения об уровне обслуживания для одного задания. Общее соглашение об уровне обслуживания по масштабируемости зависит от баланса горизонтального масштабирования эластичных вычислительных ресурсов и вертикального масштабирования отдельных серверов.

Поскольку нам приходилось запускать 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 миллиона записей, и выполнили операцию ВПР друг против друга, а также 49 других операций, подобных Excel. Обработка в новой службе заняла 26 минут по сравнению с 5 днями в старой службе. Это улучшение почти в 300 раз превосходит предыдущую архитектуру с точки зрения производительности.

Соображения

При рассмотрении этого решения имейте в виду следующее:

• Кластеры правильного размера – Хотя размер Amazon EMR можно изменять, важно правильно подобрать размер кластеров. Правильный выбор размера снижает скорость работы кластера, если он слишком мал, или увеличивает затраты, если размер кластера слишком велик. Чтобы предвидеть эти проблемы, вы можете рассчитать количество и тип узлов, которые потребуются для рабочих нагрузок.
• Параллельные шаги – Параллельное выполнение шагов позволяет запускать более сложные рабочие нагрузки, повышать эффективность использования ресурсов кластера и сокращать время, необходимое для выполнения рабочей нагрузки. Количество шагов, которые разрешено выполнять одновременно, можно настроить и установить при запуске кластера и в любое время после запуска кластера. Вам необходимо учитывать и оптимизировать использование ЦП/памяти для каждого задания, когда в одном общем кластере выполняется несколько заданий.
• Переходные кластеры EMR на основе заданий – Если применимо, рекомендуется использовать временный кластер EMR на основе заданий, который обеспечивает превосходную изоляцию, проверяя, что каждая задача выполняется в своей выделенной среде. Такой подход оптимизирует использование ресурсов, помогает предотвратить помехи между заданиями и повышает общую производительность и надежность. Переходный характер обеспечивает эффективное масштабирование, обеспечивая надежное и изолированное решение для разнообразных потребностей в обработке данных.
• EMR без сервера – EMR Serverless – идеальный выбор, если вы предпочитаете не заниматься управлением и эксплуатацией кластеров. Он позволяет вам легко запускать приложения с использованием платформ с открытым исходным кодом, доступных в EMR Serverless, предлагая простой и беспроблемный опыт.
• Amazon ЭМИ на ЭКС – Amazon EMR на EKS предлагает явные преимущества, такие как более быстрое время запуска и улучшенная масштабируемость, решающая проблемы с вычислительной мощностью, что особенно полезно для пользователей Graviton и спотовых инстансов. Включение более широкого диапазона типов вычислений повышает экономическую эффективность, позволяя индивидуально распределять ресурсы. Кроме того, поддержка нескольких зон доступности обеспечивает повышенную доступность. Эти привлекательные функции обеспечивают надежное решение для управления рабочими нагрузками больших данных с улучшенной производительностью, оптимизацией затрат и надежностью в различных вычислительных сценариях.

Заключение

В этом посте мы объяснили, как 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. Вне работы Шакти любит изучать новые технологии, смотреть фильмы и посещать места с семьей.

• SEO-контент и PR-распределение. Получите усиление сегодня.
• PlatoData.Network Вертикальный генеративный ИИ. Расширьте возможности себя. Доступ здесь.
• ПлатонАйСтрим. Интеллект Web3. Расширение знаний. Доступ здесь.
• ПлатонЭСГ. Углерод, чистые технологии, Энергия, Окружающая среда, Солнечная, Управление отходами. Доступ здесь.
• ПлатонЗдоровье. Биотехнологии и клинические исследования. Доступ здесь.
• Источник: https://aws.amazon.com/blogs/big-data/how-amazon-optimized-its-high-volume-financial-reconciliation-process-with-amazon-emr-for-higher-scalability-and-performance/