Le rapprochement des comptes est une étape importante pour garantir l’exhaustivité et l’exactitude des états financiers. Concrètement, les entreprises doivent concilier bilan comptes susceptibles de contenir des anomalies significatives ou significatives. Les comptables examinent chaque compte du grand livre général et vérifient que le solde indiqué est complet et exact. Lorsque des écarts sont constatés, les comptables enquêtent et prennent les mesures correctives appropriées.

En tant que membre de l'organisation FinTech d'Amazon, nous proposons une plate-forme logicielle qui permet aux équipes comptables internes d'Amazon d'effectuer des rapprochements de comptes. Pour optimiser le processus de rapprochement, ces utilisateurs ont besoin d'une transformation hautes performances avec la possibilité d'évoluer à la demande, ainsi que la capacité de traiter des tailles de fichiers variables allant de quelques Mo à plus de 100 Go. Il n'est pas toujours possible de placer les données sur une seule machine ou de les traiter avec un seul programme dans un délai raisonnable. Ce calcul doit être effectué suffisamment rapidement pour fournir des services pratiques où la logique de programmation et les détails sous-jacents (distribution des données, tolérance aux pannes et planification) peuvent être séparés.

Nous pouvons réaliser ces calculs simultanés sur plusieurs machines ou threads de la même fonction sur des groupes d'éléments d'un ensemble de données en utilisant des solutions de traitement de données distribuées. Cela nous a encouragés à réinventer notre service de réconciliation alimenté par les services AWS, notamment Amazon DME et par Apache Spark cadre de traitement distribué, qui utilise PySparkName. Ce service permet aux utilisateurs de traiter des fichiers de plus de 100 Go contenant jusqu'à 100 millions de transactions en moins de 30 minutes. Le service de rapprochement est devenu un moteur de traitement des données et les utilisateurs peuvent désormais effectuer de manière transparente diverses opérations, telles que Pivoter, INSCRIPTION (comme une opération Excel VLOOKUP), des fonctions arithmétiques de bases opérations, et PLUS, fournissant une solution polyvalente et efficace pour réconcilier de vastes ensembles de données. Cette amélioration témoigne de l'évolutivité et de la rapidité obtenues grâce à l'adoption de solutions de traitement de données distribuées.

Dans cet article, nous expliquons comment nous avons intégré Amazon EMR pour créer un système hautement disponible et évolutif qui nous a permis d'exécuter un processus de rapprochement financier à volume élevé.

Architecture avant migration

Le diagramme suivant illustre notre architecture précédente.

Notre service existant a été construit avec Service de conteneur élastique Amazon (Amazon ECS) sur AWSFargate. Nous avons traité les données séquentiellement à l'aide de Python. Cependant, en raison du manque de capacité de traitement parallèle, nous avons souvent dû augmenter la taille du cluster verticalement pour prendre en charge des ensembles de données plus volumineux. Pour rappel, 5 Go de données avec 50 opérations ont pris environ 3 heures à traiter. Ce service a été configuré pour s'adapter horizontalement à cinq instances ECS qui ont interrogé les messages de Service Amazon Simple Queue (Amazon SQS), qui a alimenté les demandes de transformation. Chaque instance a été configurée avec 4 processeurs virtuels et 30 Go de mémoire pour permettre une mise à l'échelle horizontale. Cependant, nous ne pouvions pas étendre sa capacité en termes de performances, car le processus se déroulait de manière séquentielle, en sélectionnant des morceaux de données de Service de stockage simple Amazon (Amazon S3) pour le traitement. Par exemple, une opération RECHERCHEV dans laquelle deux fichiers doivent être joints nécessitait que les deux fichiers soient lus en mémoire morceau par morceau pour obtenir le résultat. Cela est devenu un obstacle pour les utilisateurs car ils ont dû attendre de longues périodes pour traiter leurs ensembles de données.

Dans le cadre de notre réarchitecture et de notre modernisation, nous souhaitions atteindre les objectifs suivants :

• La haute disponibilité – Les clusters de traitement de données doivent être hautement disponibles, offrant trois 9 de disponibilité (99.9 %)
• Cadence de production – Le service devrait gérer 1,500 XNUMX exécutions par jour
• Latence – Il devrait être capable de traiter 100 Go de données en 30 minutes
• Hétérogénéité – Le cluster doit être capable de prendre en charge une grande variété de charges de travail, avec des fichiers allant de quelques Mo à des centaines de Go
• Concurrence des requêtes – La mise en œuvre exige la capacité de prendre en charge un minimum de 10 degrés de concurrence
• Fiabilité des travaux et cohérence des données – Les tâches doivent s'exécuter de manière fiable et cohérente pour éviter de rompre les accords de niveau de service (SLA)
• Économique et évolutif – Il doit être évolutif en fonction de la charge de travail, ce qui le rend rentable
• Sécurité et conformité – Compte tenu de la sensibilité des données, elles doivent prendre en charge un contrôle d’accès précis et des mises en œuvre de sécurité appropriées.
• Le Monitoring – La solution doit offrir un suivi de bout en bout des clusters et des jobs

Pourquoi Amazon EMR

Amazon EMR est la solution Big Data cloud leader du secteur pour le traitement des données à l'échelle du pétaoctet, l'analyse interactive et l'apprentissage automatique (ML) à l'aide de frameworks open source tels que Apache Spark, Ruche Apacheet Presto. Avec ces frameworks et les projets open source associés, vous pouvez traiter les données à des fins d'analyse et pour les charges de travail BI. Amazon EMR vous permet de transformer et de déplacer de grandes quantités de données vers et depuis d'autres magasins de données et bases de données AWS, tels qu'Amazon S3 et Amazon DynamoDB.

Un avantage notable d'Amazon EMR réside dans son utilisation efficace du traitement parallèle avec PySpark, marquant une amélioration significative par rapport au code Python séquentiel traditionnel. Cette approche innovante rationalise le déploiement et la mise à l'échelle des clusters Apache Spark, permettant une parallélisation efficace sur de grands ensembles de données. L'infrastructure informatique distribuée améliore non seulement les performances, mais permet également le traitement de grandes quantités de données à des vitesses sans précédent. Equipé de bibliothèques, PySpark facilite les opérations de type Excel sur Cadres de données, et l'abstraction de niveau supérieur des DataFrames simplifie les manipulations de données complexes, réduisant ainsi la complexité du code. Combiné au provisionnement automatique des clusters, à l'allocation dynamique des ressources et à l'intégration avec d'autres services AWS, Amazon EMR s'avère être une solution polyvalente adaptée à diverses charges de travail, allant du traitement par lots au ML. La tolérance aux pannes inhérente à PySpark et Amazon EMR favorise la robustesse, même en cas de panne de nœud, ce qui en fait un choix évolutif, rentable et hautes performances pour le traitement parallèle des données sur AWS.

Amazon EMR étend ses capacités au-delà des bases, offrant une variété d'options de déploiement pour répondre à divers besoins. Que ce soit Amazon EMR sur EC2, Amazon EMR sur EKS, Amazon EMR sans serveurou Amazon EMR sur les avant-postes AWS, vous pouvez adapter votre approche à des exigences spécifiques. Pour ceux qui recherchent un environnement sans serveur pour les tâches Spark, intégrant Colle AWS est également une option viable. En plus de prendre en charge divers frameworks open source, notamment Spark, Amazon EMR offre une flexibilité dans le choix des modes de déploiement, Cloud de calcul élastique Amazon (Amazon EC2), les mécanismes de mise à l'échelle et de nombreuses techniques d'optimisation permettant de réduire les coûts.

Amazon EMR constitue une force dynamique dans le cloud, offrant des fonctionnalités inégalées aux organisations à la recherche de solutions Big Data robustes. Son intégration transparente, ses fonctionnalités puissantes et son adaptabilité en font un outil indispensable pour naviguer dans les complexités de l'analyse des données et du ML sur AWS.

Architecture repensée

Le diagramme suivant illustre notre architecture repensée.

La solution fonctionne dans le cadre d'un contrat API, dans lequel les clients peuvent soumettre des configurations de transformation, définissant l'ensemble des opérations ainsi que l'emplacement de l'ensemble de données S3 à traiter. La demande est mise en file d'attente via Amazon SQS, puis dirigée vers Amazon EMR via une fonction Lambda. Ce processus lance la création d'une étape Amazon EMR pour la mise en œuvre du framework Spark sur un cluster EMR dédié. Bien qu'Amazon EMR prenne en charge un nombre illimité d'étapes sur la durée de vie d'un cluster de longue durée, seules 256 étapes peuvent être en cours d'exécution ou en attente simultanément. Pour une parallélisation optimale, la simultanéité des étapes est définie sur 10, permettant à 10 étapes de s'exécuter simultanément. En cas d'échec de la demande, Amazon SQS file d'attente de lettres mortes (DLQ) conserve l’événement. Spark traite la demande, traduisant les opérations de type Excel en code PySpark pour un plan de requête efficace. Les DataFrames résilients stockent les données d'entrée, de sortie et intermédiaires en mémoire, optimisant la vitesse de traitement, réduisant les coûts d'E/S disque, améliorant les performances de la charge de travail et fournissant la sortie finale à l'emplacement Amazon S3 spécifié.

Nous définissons notre SLA en deux dimensions : la latence et le débit. La latence est définie comme le temps nécessaire pour effectuer une tâche sur une taille d'ensemble de données déterministe et le nombre d'opérations effectuées sur l'ensemble de données. Le débit est défini comme le nombre maximum de tâches simultanées que le service peut effectuer sans violer le SLA de latence d'une tâche. Le SLA d'évolutivité global du service dépend de l'équilibre entre la mise à l'échelle horizontale des ressources de calcul élastiques et la mise à l'échelle verticale des serveurs individuels.

Étant donné que nous devions exécuter 1,500 2 processus par jour avec une latence minimale et des performances élevées, nous avons choisi d'intégrer Amazon EMR sur le mode de déploiement ECXNUMX avec une mise à l'échelle gérée activée pour prendre en charge le traitement de tailles de fichiers variables.

La configuration du cluster EMR propose de nombreuses sélections différentes :

• Types de nœuds DME – Nœuds principaux, principaux ou de tâches
• Options d'achat d'instances – Instances à la demande, instances réservées ou instances ponctuelles
• Options de configuration – Flotte d’instances EMR ou groupe d’instances uniforme
• Options de mise à l'échelle - Mise à l'échelle automatique ou mise à l'échelle gérée par Amazon EMR

En fonction de notre charge de travail variable, nous avons configuré un parc d'instances EMR (pour les meilleures pratiques, voir Fiabilité). Nous avons également décidé d'utiliser la mise à l'échelle gérée par Amazon EMR pour faire évoluer les nœuds principaux et de tâches (pour les scénarios de mise à l'échelle, reportez-vous à Scénarios d'allocation de nœuds). Enfin, nous avons choisi une mémoire optimisée AWS Graviton instances, qui fournissent jusqu'à Coûts 30 % inférieurs et performances améliorées jusqu'à 15 % pour les charges de travail Spark.

Le code suivant fournit un instantané de la configuration de notre 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

Grâce à notre migration vers Amazon EMR, nous avons pu atteindre des performances système capables de gérer une variété d'ensembles de données, allant de 273 B à 88.5 Go avec un p99 de 491 secondes (environ 8 minutes).

La figure suivante illustre la variété de tailles de fichiers traitées.

La figure suivante montre notre latence.

Pour comparer avec le traitement séquentiel, nous avons pris deux ensembles de données contenant 53 millions d'enregistrements et avons exécuté une opération RECHERCHEV l'un contre l'autre, ainsi que 49 autres opérations de type Excel. Le traitement prenait 26 minutes dans le nouveau service, contre 5 jours dans l'ancien service. Cette amélioration est près de 300 fois supérieure à l'architecture précédente en termes de performances.

Considérations

Gardez à l’esprit les points suivants lorsque vous envisagez cette solution :

• Clusters de bonne taille – Bien qu'Amazon EMR soit redimensionnable, il est important de redimensionner les clusters. Le bon dimensionnement atténue la lenteur du cluster s'il est sous-dimensionné ou les coûts plus élevés si le cluster est surdimensionné. Pour anticiper ces problèmes, vous pouvez calculer le nombre et le type de nœuds qui seront nécessaires aux charges de travail.
• Étapes parallèles – L'exécution d'étapes en parallèle vous permet d'exécuter des charges de travail plus avancées, d'augmenter l'utilisation des ressources du cluster et de réduire le temps nécessaire pour terminer votre charge de travail. Le nombre d'étapes autorisées à s'exécuter simultanément est configurable et peut être défini au lancement d'un cluster et à tout moment après le démarrage du cluster. Vous devez prendre en compte et optimiser l'utilisation du processeur/de la mémoire par tâche lorsque plusieurs tâches sont exécutées dans un seul cluster partagé.
• Clusters DME transitoires basés sur l'emploi – Le cas échéant, il est recommandé d'utiliser un cluster EMR transitoire basé sur les tâches, qui offre une isolation supérieure, vérifiant que chaque tâche fonctionne dans son environnement dédié. Cette approche optimise l'utilisation des ressources, aide à prévenir les interférences entre les tâches et améliore les performances et la fiabilité globales. La nature transitoire permet une mise à l’échelle efficace, fournissant une solution robuste et isolée pour divers besoins de traitement de données.
• EMR sans serveur – EMR Serverless est le choix idéal si vous préférez ne pas vous occuper de la gestion et du fonctionnement des clusters. Il vous permet d'exécuter sans effort des applications à l'aide des frameworks open source disponibles dans EMR Serverless, offrant une expérience simple et sans tracas.
• Amazon DME sur EKS – Amazon EMR sur EKS offre des avantages distincts, tels que des temps de démarrage plus rapides et une évolutivité améliorée résolvant les problèmes de capacité de calcul, ce qui est particulièrement bénéfique pour les utilisateurs de Graviton et d'instance Spot. L'inclusion d'une gamme plus large de types de calcul améliore la rentabilité, permettant une allocation de ressources sur mesure. De plus, la prise en charge Multi-AZ offre une disponibilité accrue. Ces fonctionnalités intéressantes constituent une solution robuste pour gérer les charges de travail Big Data avec des performances améliorées, une optimisation des coûts et une fiabilité dans divers scénarios informatiques.

Conclusion

Dans cet article, nous avons expliqué comment Amazon a optimisé son processus de rapprochement financier de gros volumes avec Amazon EMR pour une évolutivité et des performances supérieures. Si vous disposez d'une application monolithique qui dépend d'une mise à l'échelle verticale pour traiter des requêtes ou des ensembles de données supplémentaires, sa migration vers un cadre de traitement distribué tel qu'Apache Spark et le choix d'un service géré tel qu'Amazon EMR pour le calcul peuvent aider à réduire le temps d'exécution afin de réduire votre livraison. SLA, et peut également contribuer à réduire le coût total de possession (TCO).

Alors que nous adoptons Amazon EMR pour ce cas d'utilisation particulier, nous vous encourageons à explorer d'autres possibilités dans votre parcours d'innovation en matière de données. Pensez à évaluer AWS Glue, ainsi que d'autres options de déploiement dynamique d'Amazon EMR telles que EMR Serverless ou Amazon EMR sur EKS, pour découvrir le meilleur service AWS adapté à votre cas d'utilisation unique. L’avenir du parcours d’innovation des données recèle des possibilités et des avancées passionnantes à explorer davantage.

À propos des auteurs

Jeeshan Khetrapal est ingénieur principal en développement logiciel chez Amazon, où il développe des produits fintech basés sur des architectures de cloud computing sans serveur qui sont responsables des contrôles généraux informatiques, des rapports financiers et du contrôle de la gouvernance, des risques et de la conformité des entreprises.

Shakti Mishra est architecte de solutions principal chez AWS, où il aide les clients à moderniser leur architecture de données et à définir leur stratégie de données de bout en bout, y compris la sécurité des données, l'accessibilité, la gouvernance, etc. Il est également l'auteur du livre Simplifiez l'analyse du Big Data avec Amazon EMR. En dehors du travail, Sakti aime apprendre de nouvelles technologies, regarder des films et visiter des lieux en famille.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
• PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
• PlatonESG. Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
• PlatoHealth. Veille biotechnologique et essais cliniques. Accéder ici.
• La source: https://aws.amazon.com/blogs/big-data/how-amazon-optimized-its-high-volume-financial-reconciliation-process-with-amazon-emr-for-higher-scalability-and-performance/