A reconciliação de contas é uma etapa importante para garantir a integridade e a precisão das demonstrações financeiras. Especificamente, as empresas devem conciliar balancete contas que possam conter distorções significativas ou relevantes. Os contadores examinam cada conta do razão geral de contas e verificam se o saldo listado está completo e preciso. Quando são encontradas discrepâncias, os contadores investigam e tomam as medidas corretivas apropriadas.

Como parte da organização FinTech da Amazon, oferecemos uma plataforma de software que capacita as equipes de contabilidade interna da Amazon a conduzir reconciliações de contas. Para otimizar o processo de reconciliação, esses usuários exigem transformação de alto desempenho com capacidade de escalabilidade sob demanda, bem como capacidade de processar tamanhos de arquivos variáveis, desde alguns MBs até mais de 100 GB. Nem sempre é possível encaixar os dados em uma única máquina ou processá-los com um único programa em um período de tempo razoável. Este cálculo deve ser feito com rapidez suficiente para fornecer serviços práticos onde a lógica de programação e os detalhes subjacentes (distribuição de dados, tolerância a falhas e escalonamento) possam ser separados.

Podemos realizar esses cálculos simultâneos em múltiplas máquinas ou threads da mesma função em grupos de elementos de um conjunto de dados usando soluções de processamento de dados distribuídos. Isso nos incentivou a reinventar nosso serviço de reconciliação desenvolvido com serviços da AWS, incluindo Amazon EMR e os votos de Apache Spark estrutura de processamento distribuído, que usa PySparkGenericName. Este serviço permite aos usuários processar arquivos acima de 100 GB contendo até 100 milhões de transações em menos de 30 minutos. O serviço de reconciliação tornou-se uma potência para o processamento de dados e agora os usuários podem realizar facilmente uma variedade de operações, como articulação, Cadastre-se (como uma operação VLOOKUP do Excel), aritmética operações, e mais, fornecendo uma solução versátil e eficiente para reconciliar vastos conjuntos de dados. Essa melhoria é uma prova da escalabilidade e da velocidade alcançadas através da adoção de soluções distribuídas de processamento de dados.

Nesta postagem, explicamos como integramos o Amazon EMR para construir um sistema altamente disponível e escalável que nos permitiu executar um processo de reconciliação financeira de alto volume.

Arquitetura antes da migração

O diagrama a seguir ilustra nossa arquitetura anterior.

Nosso serviço legado foi construído com Serviço Amazon Elastic Container (Amazon ECS) em AWS Fargate. Processamos os dados sequencialmente usando Python. No entanto, devido à falta de capacidade de processamento paralelo, frequentemente tivemos que aumentar o tamanho do cluster verticalmente para suportar conjuntos de dados maiores. Para contextualizar, 5 GB de dados com 50 operações levaram cerca de 3 horas para serem processados. Este serviço foi configurado para escalar horizontalmente para cinco instâncias do ECS que pesquisavam mensagens de Serviço de fila simples da Amazon (Amazon SQS), que alimentou as solicitações de transformação. Cada instância foi configurada com 4 vCPUs e 30 GB de memória para permitir escalabilidade horizontal. No entanto, não pudemos expandir sua capacidade de desempenho porque o processo acontecia sequencialmente, selecionando pedaços de dados de Serviço de armazenamento simples da Amazon (Amazon S3) para processamento. Por exemplo, uma operação VLOOKUP em que dois arquivos deveriam ser unidos exigia que ambos os arquivos fossem lidos na memória, pedaço por pedaço, para obter a saída. Isso se tornou um obstáculo para os usuários porque eles tinham que esperar longos períodos para processar seus conjuntos de dados.

Como parte da nossa rearquitetura e modernização, queríamos alcançar o seguinte:

• Alta disponibilidade – Os clusters de processamento de dados devem estar altamente disponíveis, proporcionando três 9s de disponibilidade (99.9%)
• Produtividade – O serviço deve realizar 1,500 execuções por dia
• Latência – Deve ser capaz de processar 100 GB de dados em 30 minutos
• Heterogeneidade – O cluster deve ser capaz de suportar uma ampla variedade de cargas de trabalho, com arquivos variando de alguns MBs a centenas de GBs
• Consultar simultaneidade – A implementação exige a capacidade de suportar um mínimo de 10 graus de simultaneidade
• Confiabilidade dos trabalhos e consistência dos dados – Os trabalhos precisam ser executados de forma confiável e consistente para evitar quebras de acordos de nível de serviço (SLAs).
• Econômico e escalonável – Deve ser escalonável com base na carga de trabalho, tornando-o econômico
• Segurança e conformidade – Dada a sensibilidade dos dados, deve suportar controle de acesso refinado e implementações de segurança apropriadas
• do Paciente – A solução deve oferecer monitoramento ponta a ponta dos clusters e jobs

Por que o Amazon EMR

O Amazon EMR é a solução de big data em nuvem líder do setor para processamento de dados em escala de petabytes, análises interativas e aprendizado de máquina (ML) usando estruturas de código aberto, como Apache Spark, Colmeia Apache e Presto. Com essas estruturas e projetos de código aberto relacionados, você pode processar dados para fins analíticos e cargas de trabalho de BI. O Amazon EMR permite transformar e mover grandes quantidades de dados para dentro e para fora de outros armazenamentos de dados e bancos de dados da AWS, como Amazon S3 e Amazon DynamoDB.

Uma vantagem notável do Amazon EMR reside no uso eficaz do processamento paralelo com PySpark, marcando uma melhoria significativa em relação ao código Python sequencial tradicional. Essa abordagem inovadora agiliza a implantação e o dimensionamento de clusters Apache Spark, permitindo paralelização eficiente em grandes conjuntos de dados. A infraestrutura de computação distribuída não só melhora o desempenho, mas também permite o processamento de grandes quantidades de dados a velocidades sem precedentes. Equipado com bibliotecas, o PySpark facilita operações semelhantes às do Excel em Quadros de dados, e a abstração de nível superior de DataFrames simplifica manipulações intrincadas de dados, reduzindo a complexidade do código. Combinado com provisionamento automático de cluster, alocação dinâmica de recursos e integração com outros serviços da AWS, o Amazon EMR prova ser uma solução versátil adequada para diversas cargas de trabalho, desde processamento em lote até ML. A tolerância a falhas inerente ao PySpark e ao Amazon EMR promove robustez, mesmo no caso de falhas de nós, tornando-o uma opção escalonável, econômica e de alto desempenho para processamento paralelo de dados na AWS.

O Amazon EMR amplia seus recursos além do básico, oferecendo diversas opções de implantação para atender a diversas necessidades. Quer seja Amazon EMR no EC2, Amazon EMR no EKS, Amazon EMR sem servidorou Amazon EMR no AWS Outposts, você pode adaptar sua abordagem a requisitos específicos. Para aqueles que buscam um ambiente sem servidor para trabalhos do Spark, a integração Cola AWS também é uma opção viável. Além de oferecer suporte a diversas estruturas de código aberto, incluindo o Spark, o Amazon EMR oferece flexibilidade na escolha dos modos de implantação, Amazon Elastic Compute Nuvem (Amazon EC2), mecanismos de escalonamento e diversas técnicas de otimização com economia de custos.

O Amazon EMR se destaca como uma força dinâmica na nuvem, oferecendo recursos incomparáveis ​​para organizações que buscam soluções robustas de big data. Sua integração perfeita, recursos poderosos e adaptabilidade o tornam uma ferramenta indispensável para navegar pelas complexidades da análise de dados e ML na AWS.

Arquitetura redesenhada

O diagrama a seguir ilustra nossa arquitetura redesenhada.

A solução opera sob um contrato API, onde os clientes podem enviar configurações de transformação, definindo o conjunto de operações juntamente com o local do conjunto de dados S3 para processamento. A solicitação é enfileirada por meio do Amazon SQS e, em seguida, direcionada ao Amazon EMR por meio de uma função Lambda. Esse processo inicia a criação de uma etapa do Amazon EMR para implementação da estrutura Spark em um cluster EMR dedicado. Embora o Amazon EMR acomode um número ilimitado de etapas durante a vida útil de um cluster de longa execução, apenas 256 etapas podem estar em execução ou pendentes simultaneamente. Para uma paralelização ideal, a simultaneidade de etapas é definida como 10, permitindo que 10 etapas sejam executadas simultaneamente. Em caso de falhas na solicitação, o Amazon SQS fila de mensagens mortas (DLQ) mantém o evento. O Spark processa a solicitação, traduzindo operações semelhantes às do Excel em código PySpark para um plano de consulta eficiente. DataFrames resilientes armazenam dados de entrada, saída e intermediários na memória, otimizando a velocidade de processamento, reduzindo o custo de E/S de disco, melhorando o desempenho da carga de trabalho e entregando a saída final ao local especificado do Amazon S3.

Definimos nosso SLA em duas dimensões: latência e taxa de transferência. A latência é definida como a quantidade de tempo necessária para executar um trabalho em relação a um tamanho determinístico do conjunto de dados e o número de operações executadas no conjunto de dados. A taxa de transferência é definida como o número máximo de trabalhos simultâneos que o serviço pode executar sem violar o SLA de latência de um trabalho. O SLA de escalabilidade geral do serviço depende do equilíbrio entre o escalonamento horizontal de recursos de computação elásticos e o escalonamento vertical de servidores individuais.

Como precisávamos executar 1,500 processos por dia com latência mínima e alto desempenho, optamos por integrar o Amazon EMR no modo de implantação do EC2 com escalabilidade gerenciada habilitada para suportar o processamento de tamanhos de arquivos variáveis.

A configuração do cluster do EMR oferece muitas seleções diferentes:

• Tipos de nós EMR – Nós primários, principais ou de tarefa
• Opções de compra de instância – Instâncias sob demanda, instâncias reservadas ou instâncias spot
• Opções de configuração – Frota de instâncias EMR ou grupo de instâncias uniformes
• Opções de escala - Escalonamento automático ou escalabilidade gerenciada do Amazon EMR

Com base em nossa carga de trabalho variável, configuramos uma frota de instâncias EMR (para práticas recomendadas, consulte Confiabilidade). Também decidimos usar a escalabilidade gerenciada do Amazon EMR para escalar os nós principais e de tarefas (para cenários de escalabilidade, consulte Cenários de alocação de nós). Por último, escolhemos com otimização de memória AWS Graviton instâncias, que fornecem até Custo 30% menor e desempenho até 15% melhorado para cargas de trabalho Spark.

O código a seguir fornece um instantâneo da configuração do nosso cluster:

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

Performance

Com nossa migração para o Amazon EMR, conseguimos alcançar um desempenho de sistema capaz de lidar com uma variedade de conjuntos de dados, variando de 273 B a 88.5 GB com um p99 de 491 segundos (aproximadamente 8 minutos).

A figura a seguir ilustra a variedade de tamanhos de arquivo processados.

A figura a seguir mostra nossa latência.

Para comparar com o processamento sequencial, pegamos dois conjuntos de dados contendo 53 milhões de registros e executamos uma operação VLOOKUP um contra o outro, junto com outras 49 operações semelhantes ao Excel. O processamento no novo serviço levou 26 minutos, em comparação com 5 dias no serviço legado. Esta melhoria é quase 300 vezes maior em relação à arquitetura anterior em termos de desempenho.

Considerações

Tenha em mente o seguinte ao considerar esta solução:

• Clusters de dimensionamento correto – Embora o Amazon EMR seja redimensionável, é importante dimensionar corretamente os clusters. O dimensionamento correto atenua um cluster lento, se for subdimensionado, ou custos mais elevados, se o cluster for superdimensionado. Para antecipar estes problemas, pode calcular o número e o tipo de nós que serão necessários para as cargas de trabalho.
• Etapas paralelas – A execução de etapas em paralelo permite executar cargas de trabalho mais avançadas, aumentar a utilização de recursos do cluster e reduzir o tempo necessário para concluir sua carga de trabalho. O número de etapas permitidas para execução ao mesmo tempo é configurável e pode ser definido quando um cluster é iniciado e a qualquer momento após o início do cluster. Você precisa considerar e otimizar o uso de CPU/memória por trabalho quando vários trabalhos estão em execução em um único cluster compartilhado.
• Clusters EMR transitórios baseados em trabalho – Se aplicável, recomenda-se usar um cluster EMR transitório baseado em trabalho, que oferece isolamento superior, verificando se cada tarefa opera dentro de seu ambiente dedicado. Essa abordagem otimiza a utilização de recursos, ajuda a evitar interferências entre trabalhos e melhora o desempenho e a confiabilidade gerais. A natureza transitória permite um escalonamento eficiente, fornecendo uma solução robusta e isolada para diversas necessidades de processamento de dados.
• EMR sem servidor – O EMR Serverless é a escolha ideal se você preferir não lidar com o gerenciamento e operação de clusters. Ele permite que você execute aplicativos sem esforço usando estruturas de código aberto disponíveis no EMR Serverless, oferecendo uma experiência simples e descomplicada.
• Amazon EMR em EKS – O Amazon EMR no EKS oferece vantagens distintas, como tempos de inicialização mais rápidos e escalabilidade aprimorada para resolver desafios de capacidade computacional, o que é particularmente benéfico para usuários de instâncias Graviton e Spot. A inclusão de uma gama mais ampla de tipos de computação aumenta a eficiência de custos, permitindo a alocação personalizada de recursos. Além disso, o suporte Multi-AZ proporciona maior disponibilidade. Esses recursos atraentes fornecem uma solução robusta para gerenciar cargas de trabalho de big data com melhor desempenho, otimização de custos e confiabilidade em vários cenários de computação.

Conclusão

Nesta postagem, explicamos como a Amazon otimizou seu processo de reconciliação financeira de alto volume com o Amazon EMR para obter maior escalabilidade e desempenho. Se você tiver um aplicativo monolítico que depende de escalabilidade vertical para processar solicitações ou conjuntos de dados adicionais, migrá-lo para uma estrutura de processamento distribuído, como o Apache Spark, e escolher um serviço gerenciado, como o Amazon EMR para computação, poderá ajudar a reduzir o tempo de execução para diminuir sua entrega. SLA e também pode ajudar a reduzir o Custo Total de Propriedade (TCO).

À medida que adotamos o Amazon EMR para esse caso de uso específico, incentivamos você a explorar outras possibilidades em sua jornada de inovação de dados. Considere avaliar o AWS Glue, juntamente com outras opções dinâmicas de implantação do Amazon EMR, como EMR Serverless ou Amazon EMR no EKS, para descobrir o melhor serviço da AWS adaptado ao seu caso de uso exclusivo. O futuro da jornada de inovação de dados traz possibilidades e avanços interessantes a serem explorados ainda mais.

Sobre os autores

Jeeshan Khetrapal é engenheiro sênior de desenvolvimento de software na Amazon, onde desenvolve produtos fintech baseados em arquiteturas de computação em nuvem sem servidor que são responsáveis ​​pelos controles gerais de TI das empresas, relatórios financeiros e controladoria para governança, risco e conformidade.

Shakti Mishra é arquiteto de soluções principal na AWS, onde ajuda os clientes a modernizar sua arquitetura de dados e definir sua estratégia de dados ponta a ponta, incluindo segurança de dados, acessibilidade, governança e muito mais. Ele também é o autor do livro Simplifique a análise de Big Data com o Amazon EMR. Fora do trabalho, Sakti gosta de aprender novas tecnologias, assistir filmes e visitar lugares com a família.

• Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
• PlatoData.Network Gerativa Vertical Ai. Capacite-se. Acesse aqui.
• PlatoAiStream. Inteligência Web3. Conhecimento Amplificado. Acesse aqui.
• PlatãoESG. Carbono Tecnologia Limpa, Energia, Ambiente, Solar, Gestão de resíduos. Acesse aqui.
• PlatoHealth. Inteligência em Biotecnologia e Ensaios Clínicos. Acesse aqui.
• Fonte: https://aws.amazon.com/blogs/big-data/how-amazon-optimized-its-high-volume-financial-reconciliation-process-with-amazon-emr-for-higher-scalability-and-performance/