Reconciliatie van rekeningen is een belangrijke stap om de volledigheid en nauwkeurigheid van financiële overzichten te garanderen. Concreet moeten bedrijven zich verzoenen balans rekeningen die significante of materiële afwijkingen kunnen bevatten. Accountants doornemen elke rekening in het grootboek van rekeningen en verifiëren dat het vermelde saldo volledig en accuraat is. Wanneer er discrepanties worden geconstateerd, gaan accountants op onderzoek uit en nemen passende corrigerende maatregelen.

Als onderdeel van de FinTech-organisatie van Amazon bieden we een softwareplatform aan dat de interne boekhoudteams bij Amazon in staat stelt rekeningafstemmingen uit te voeren. Om het afstemmingsproces te optimaliseren, hebben deze gebruikers hoogwaardige transformatie nodig met de mogelijkheid om op aanvraag te schalen, evenals de mogelijkheid om variabele bestandsgroottes te verwerken, variërend van enkele MB's tot meer dan 100 GB. Het is niet altijd mogelijk om gegevens binnen een redelijke tijd op één enkele machine te plaatsen of met één enkel programma te verwerken. Deze berekening moet snel genoeg worden uitgevoerd om praktische diensten te bieden waarbij programmeerlogica en onderliggende details (gegevensdistributie, fouttolerantie en planning) kunnen worden gescheiden.

We kunnen deze gelijktijdige berekeningen uitvoeren op meerdere machines of threads met dezelfde functie over groepen elementen van een dataset heen door gebruik te maken van gedistribueerde gegevensverwerkingsoplossingen. Dit moedigde ons aan om onze verzoeningsservice, mogelijk gemaakt door AWS-services, opnieuw uit te vinden Amazon EMR en Apache Spark gedistribueerd verwerkingsframework, dat gebruik maakt van PySpark. Met deze service kunnen gebruikers bestanden van meer dan 100 GB met maximaal 100 miljoen transacties in minder dan 30 minuten verwerken. De afstemmingsservice is een krachtpatser geworden voor gegevensverwerking en nu kunnen gebruikers naadloos een verscheidenheid aan bewerkingen uitvoeren, zoals Spil, AANMELDEN (zoals een Excel VLOOKUP-bewerking), rekenkundig operaties, en meer, wat een veelzijdige en efficiënte oplossing biedt voor het afstemmen van enorme datasets. Deze verbetering is een bewijs van de schaalbaarheid en snelheid die wordt bereikt door de adoptie van gedistribueerde gegevensverwerkingsoplossingen.

In dit bericht leggen we uit hoe we Amazon EMR hebben geïntegreerd om een ​​zeer beschikbaar en schaalbaar systeem te bouwen waarmee we een grootschalig financieel afstemmingsproces konden uitvoeren.

Architectuur vóór migratie

Het volgende diagram illustreert onze vorige architectuur.

Onze oude service is gebouwd met Amazon Elastic Container-service (Amazon ECS) ingeschakeld AWS Fargate. We hebben de gegevens sequentieel verwerkt met behulp van Python. Vanwege het gebrek aan parallelle verwerkingscapaciteit moesten we de clustergrootte echter vaak verticaal vergroten om grotere datasets te ondersteunen. Ter context: de verwerking van 5 GB aan gegevens met 50 bewerkingen duurde ongeveer 3 uur. Deze service is geconfigureerd om horizontaal te schalen naar vijf ECS-instanties waaruit berichten zijn opgevraagd Amazon Simple Queue-service (Amazon SQS), die de transformatieverzoeken heeft gevoed. Elke instantie is geconfigureerd met 4 vCPU's en 30 GB geheugen om horizontale schaling mogelijk te maken. We konden de capaciteit op het gebied van prestaties echter niet uitbreiden, omdat het proces opeenvolgend plaatsvond en stukjes gegevens eruit plukte Amazon eenvoudige opslagservice (Amazon S3) voor verwerking. Voor een VLOOKUP-bewerking waarbij twee bestanden moeten worden samengevoegd, moesten beide bestanden bijvoorbeeld stuk voor stuk in het geheugen worden gelezen om de uitvoer te verkrijgen. Dit werd een obstakel voor gebruikers omdat ze lange tijd moesten wachten op het verwerken van hun datasets.

Als onderdeel van onze herarchitectuur en modernisering wilden we het volgende bereiken:

• Hoge beschikbaarheid – De dataverwerkingsclusters moeten in hoge mate beschikbaar zijn en drie negens beschikbaarheid bieden (9%)
• Doorvoer – De dienst zou 1,500 ritten per dag moeten verwerken
• Wachttijd – Het zou binnen 100 minuten 30 GB aan gegevens moeten kunnen verwerken
• heterogeniteit – Het cluster moet een breed scala aan werklasten kunnen ondersteunen, met bestanden variërend van enkele MB's tot honderden GB's
• Gelijktijdigheid van zoekopdrachten – De implementatie vereist de mogelijkheid om minimaal 10 graden gelijktijdigheid te ondersteunen
• Betrouwbaarheid van taken en gegevensconsistentie – Taken moeten betrouwbaar en consistent worden uitgevoerd om te voorkomen dat Service Level Agreements (SLA's) worden overtreden
• Kosteneffectief en schaalbaar – Het moet schaalbaar zijn op basis van de werklast, waardoor het kosteneffectief is
• Beveiliging en naleving – Gezien de gevoeligheid van gegevens moet deze een fijnmazige toegangscontrole en passende beveiligingsimplementaties ondersteunen
• Monitoren – De oplossing moet end-to-end monitoring van de clusters en banen bieden

Waarom Amazon EMR

Amazon EMR is de toonaangevende cloud-big data-oplossing voor gegevensverwerking op petabyteschaal, interactieve analyses en machine learning (ML) met behulp van open source-frameworks zoals Apache Spark, Apache-bijenkorf en Presto. Met deze raamwerken en gerelateerde open-sourceprojecten kunt u gegevens verwerken voor analysedoeleinden en BI-workloads. Met Amazon EMR kunt u grote hoeveelheden gegevens transformeren en verplaatsen naar en uit andere AWS-gegevensopslagplaatsen en -databases, zoals Amazon S3 en Amazon DynamoDB.

Een opmerkelijk voordeel van Amazon EMR ligt in het effectieve gebruik van parallelle verwerking met PySpark, wat een aanzienlijke verbetering betekent ten opzichte van traditionele sequentiële Python-code. Deze innovatieve aanpak stroomlijnt de implementatie en schaling van Apache Spark-clusters, waardoor efficiënte parallellisatie op grote datasets mogelijk wordt. De gedistribueerde computerinfrastructuur verbetert niet alleen de prestaties, maar maakt ook de verwerking van grote hoeveelheden gegevens met ongekende snelheden mogelijk. Uitgerust met bibliotheken vergemakkelijkt PySpark Excel-achtige bewerkingen op Dataframes, en de abstractie op een hoger niveau van DataFrames vereenvoudigt ingewikkelde gegevensmanipulaties, waardoor de complexiteit van de code wordt verminderd. Gecombineerd met automatische clusterprovisioning, dynamische toewijzing van bronnen en integratie met andere AWS-services blijkt Amazon EMR een veelzijdige oplossing te zijn die geschikt is voor uiteenlopende workloads, variërend van batchverwerking tot ML. De inherente fouttolerantie in PySpark en Amazon EMR bevordert de robuustheid, zelfs in het geval van knooppuntstoringen, waardoor het een schaalbare, kosteneffectieve en krachtige keuze is voor parallelle gegevensverwerking op AWS.

Amazon EMR breidt zijn mogelijkheden verder uit dan de basis en biedt een verscheidenheid aan implementatieopties om aan uiteenlopende behoeften te voldoen. Of het nu zo is Amazon EMR op EC2, Amazon EPD op EKS, Amazon EMR Serverloosof Amazon EMR op AWS-buitenposten, kunt u uw aanpak afstemmen op specifieke vereisten. Voor degenen die op zoek zijn naar een serverloze omgeving voor Spark-taken, integreren AWS lijm is ook een haalbare optie. Naast het ondersteunen van verschillende open-sourceframeworks, waaronder Spark, biedt Amazon EMR flexibiliteit bij het kiezen van implementatiemodi, Amazon Elastic Compute-cloud (Amazon EC2) instantietypen, schaalmechanismen en talrijke kostenbesparende optimalisatietechnieken.

Amazon EMR fungeert als een dynamische kracht in de cloud en levert ongeëvenaarde mogelijkheden voor organisaties die op zoek zijn naar robuuste big data-oplossingen. De naadloze integratie, krachtige functies en aanpasbaarheid maken het tot een onmisbaar hulpmiddel bij het navigeren door de complexiteit van data-analyse en ML op AWS.

Opnieuw ontworpen architectuur

Het volgende diagram illustreert onze opnieuw ontworpen architectuur.

De oplossing werkt onder een API-contract, waarbij klanten transformatieconfiguraties kunnen indienen, waarbij de reeks bewerkingen naast de S3-datasetlocatie voor verwerking wordt gedefinieerd. Het verzoek wordt in de wachtrij geplaatst via Amazon SQS en vervolgens via een Lambda-functie naar Amazon EMR geleid. Dit proces initieert de creatie van een Amazon EMR-stap voor de implementatie van het Spark-framework op een speciaal EMR-cluster. Hoewel Amazon EMR een onbeperkt aantal stappen mogelijk maakt gedurende de levensduur van een langlopend cluster, kunnen er slechts 256 stappen tegelijkertijd actief of in behandeling zijn. Voor optimale parallellisatie is de gelijktijdigheid van de stappen ingesteld op 10, waardoor 10 stappen gelijktijdig kunnen worden uitgevoerd. In het geval van mislukte verzoeken, zal de Amazon SQS wachtrij voor dode letters (DLQ) behoudt het evenement. Spark verwerkt het verzoek en vertaalt Excel-achtige bewerkingen naar PySpark-code voor een efficiënt queryplan. Veerkrachtige DataFrames slaan invoer, uitvoer en tussentijdse gegevens op in het geheugen, waardoor de verwerkingssnelheid wordt geoptimaliseerd, de I/O-kosten van de schijf worden verlaagd, de prestaties van de werklast worden verbeterd en de uiteindelijke uitvoer wordt afgeleverd op de opgegeven Amazon S3-locatie.

We definiëren onze SLA in twee dimensies: latentie en doorvoer. Latentie wordt gedefinieerd als de hoeveelheid tijd die nodig is om één taak uit te voeren bij een deterministische datasetgrootte en het aantal bewerkingen dat op de dataset wordt uitgevoerd. Doorvoer wordt gedefinieerd als het maximale aantal gelijktijdige taken die de service kan uitvoeren zonder de latentie-SLA van één taak te schenden. De algehele schaalbaarheids-SLA van de service is afhankelijk van de balans tussen horizontale schaling van elastische rekenbronnen en verticale schaling van individuele servers.

Omdat we 1,500 processen per dag moesten uitvoeren met minimale latentie en hoge prestaties, hebben we ervoor gekozen om Amazon EMR te integreren in de EC2-implementatiemodus, waarbij beheerde schaling is ingeschakeld om de verwerking van variabele bestandsgroottes te ondersteunen.

De EMR-clusterconfiguratie biedt veel verschillende selecties:

• EMR-knooppunttypen – Primaire, kern- of taakknooppunten
• Aankoopopties voor instanties – Instanties op aanvraag, gereserveerde exemplaren of spotexemplaren
• Configuratie-opties – EMR-instantievloot of uniforme instantiegroep
• Schaalopties - Automatische schaalverdeling of door Amazon EMR beheerde schaling

Op basis van onze variabele werklast hebben we een EMR-instantievloot geconfigureerd (voor best practices, zie Betrouwbaarheid). We hebben ook besloten om door Amazon EMR beheerde schaling te gebruiken om de kern- en taakknooppunten te schalen (voor schaalscenario's raadpleegt u Scenario's voor knooppunttoewijzing). Ten slotte hebben we gekozen voor geheugengeoptimaliseerd AWS Graviton exemplaren, die tot 30% lagere kosten en tot 15% betere prestaties voor Spark-workloads.

De volgende code biedt een momentopname van onze clusterconfiguratie:

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

Met onze migratie naar Amazon EMR zijn we erin geslaagd systeemprestaties te realiseren die in staat zijn een verscheidenheid aan datasets te verwerken, variërend van slechts 273 miljard GB tot wel 88.5 GB met een p99 van 491 seconden (ongeveer 8 minuten).

De volgende afbeelding illustreert de verscheidenheid aan verwerkte bestandsgroottes.

De volgende afbeelding toont onze latentie.

Ter vergelijking met sequentiële verwerking hebben we twee gegevenssets met 53 miljoen records genomen en een VLOOKUP-bewerking tegen elkaar uitgevoerd, samen met 49 andere Excel-achtige bewerkingen. De verwerking hiervan duurde 26 minuten in de nieuwe service, vergeleken met 5 dagen om te verwerken in de oude service. Deze verbetering is qua prestaties bijna 300 keer groter dan de vorige architectuur.

Overwegingen

Houd rekening met het volgende wanneer u deze oplossing overweegt:

• Clusters met de juiste grootte – Hoewel de grootte van Amazon EMR kan worden aangepast, is het belangrijk om de clusters op de juiste grootte te plaatsen. Door de juiste grootte te bepalen wordt een langzaam cluster, als het te klein is, of hogere kosten, als het cluster te groot is, beperkt. Om op deze problemen te anticiperen, kunt u het aantal en het type knooppunten berekenen dat nodig is voor de werklasten.
• Parallelle stappen – Door stappen parallel uit te voeren, kunt u geavanceerdere werklasten uitvoeren, het gebruik van clusterbronnen verhogen en de hoeveelheid tijd die nodig is om uw werklast te voltooien, verminderen. Het aantal stappen dat tegelijk mag worden uitgevoerd, is configureerbaar en kan worden ingesteld wanneer een cluster wordt gestart en op elk moment nadat het cluster is gestart. U moet het CPU-/geheugengebruik per taak overwegen en optimaliseren wanneer meerdere taken in één gedeeld cluster worden uitgevoerd.
• Op banen gebaseerde tijdelijke EMR-clusters – Indien van toepassing wordt aanbevolen om een ​​taakgebaseerd tijdelijk EMR-cluster te gebruiken, dat superieure isolatie biedt en verifieert dat elke taak binnen de daarvoor bestemde omgeving functioneert. Deze aanpak optimaliseert het gebruik van hulpbronnen, helpt interferentie tussen taken te voorkomen en verbetert de algehele prestaties en betrouwbaarheid. Het tijdelijke karakter maakt efficiënte schaalvergroting mogelijk en biedt een robuuste en geïsoleerde oplossing voor uiteenlopende gegevensverwerkingsbehoeften.
• EMR-serverloos – EMR Serverless is de ideale keuze als u het beheer en de exploitatie van clusters liever niet zelf doet. Hiermee kunt u moeiteloos applicaties uitvoeren met behulp van open-sourceframeworks die beschikbaar zijn binnen EMR Serverless, wat een eenvoudige en probleemloze ervaring biedt.
• Amazone EMR op EKS – Amazon EMR op EKS biedt duidelijke voordelen, zoals snellere opstarttijden en verbeterde schaalbaarheid, waardoor uitdagingen op het gebied van rekencapaciteit worden opgelost, wat vooral gunstig is voor Graviton- en Spot Instance-gebruikers. De opname van een breder scala aan rekentypen verbetert de kostenefficiëntie, waardoor op maat gemaakte toewijzing van middelen mogelijk wordt. Bovendien zorgt Multi-AZ-ondersteuning voor een verhoogde beschikbaarheid. Deze aantrekkelijke functies bieden een robuuste oplossing voor het beheren van big data-workloads met verbeterde prestaties, kostenoptimalisatie en betrouwbaarheid in verschillende computerscenario's.

Conclusie

In dit bericht hebben we uitgelegd hoe Amazon zijn grootschalige financiële afstemmingsproces met Amazon EMR heeft geoptimaliseerd voor hogere schaalbaarheid en prestaties. Als u een monolithische applicatie heeft die afhankelijk is van verticale schaalvergroting om aanvullende verzoeken of datasets te verwerken, kunt u deze migreren naar een gedistribueerd verwerkingsframework zoals Apache Spark en kiezen voor een beheerde service zoals Amazon EMR voor rekenkracht om de runtime te verkorten en uw levering te verlagen SLA, en kan ook helpen de Total Cost of Ownership (TCO) te verlagen.

Omdat we Amazon EMR omarmen voor dit specifieke gebruik, moedigen we u aan om verdere mogelijkheden in uw data-innovatietraject te verkennen. Overweeg om AWS Glue te evalueren, samen met andere dynamische Amazon EMR-implementatieopties zoals EMR Serverless of Amazon EMR op EKS, om de beste AWS-service te ontdekken die is afgestemd op uw unieke gebruiksscenario. De toekomst van het data-innovatietraject biedt opwindende mogelijkheden en verbeteringen die verder kunnen worden onderzocht.

Over de auteurs

Jeeshan Khetrapal is Sr. Software Development Engineer bij Amazon, waar hij fintech-producten ontwikkelt op basis van serverloze architecturen voor cloud computing die verantwoordelijk zijn voor de algemene IT-controles, financiële rapportage en controllerschap van bedrijven voor governance, risico's en compliance.

Sakti Mishra is een Principal Solutions Architect bij AWS, waar hij klanten helpt hun data-architectuur te moderniseren en hun end-to-end datastrategie te definiëren, inclusief databeveiliging, toegankelijkheid, governance en meer. Hij is ook de auteur van het boek Vereenvoudig Big Data-analyse met Amazon EMR. Buiten het werk houdt Sakti ervan om nieuwe technologieën te leren, films te kijken en plaatsen met familie te bezoeken.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
• PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
• PlatoESG. carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
• Plato Gezondheid. Intelligentie op het gebied van biotech en klinische proeven. Toegang hier.
• Bron: https://aws.amazon.com/blogs/big-data/how-amazon-optimized-its-high-volume-financial-reconciliation-process-with-amazon-emr-for-higher-scalability-and-performance/