Kontoavstämning är ett viktigt steg för att säkerställa att de finansiella rapporterna är fullständiga och korrekta. Närmare bestämt måste företag stämma av balansräkning konton som kan innehålla väsentliga eller väsentliga felaktigheter. Revisorer går igenom varje konto i huvudboken och kontrollerar att saldot som anges är fullständigt och korrekt. När avvikelser upptäcks undersöker revisorerna och vidtar lämpliga korrigerande åtgärder.

Som en del av Amazons FinTech-organisation erbjuder vi en mjukvaruplattform som ger de interna redovisningsteamen på Amazon möjlighet att utföra kontoavstämningar. För att optimera avstämningsprocessen kräver dessa användare högpresterande transformation med möjligheten att skala på begäran, samt förmågan att bearbeta varierande filstorlekar från så lite som några MB till mer än 100 GB. Det är inte alltid möjligt att passa in data på en enda maskin eller bearbeta dem med ett enda program inom en rimlig tidsram. Denna beräkning måste göras tillräckligt snabbt för att tillhandahålla praktiska tjänster där programmeringslogik och underliggande detaljer (datadistribution, feltolerans och schemaläggning) kan separeras.

Vi kan uppnå dessa samtidiga beräkningar på flera maskiner eller trådar med samma funktion över grupper av element i en datauppsättning genom att använda distribuerade databehandlingslösningar. Detta uppmuntrade oss att återuppfinna vår avstämningstjänst som drivs av AWS-tjänster, inklusive Amazon EMR och Apache Spark distribuerade bearbetningsramverk, som använder PySpark. Denna tjänst gör det möjligt för användare att bearbeta filer över 100 GB som innehåller upp till 100 miljoner transaktioner på mindre än 30 minuter. Avstämningstjänsten har blivit ett kraftpaket för databehandling och nu kan användare sömlöst utföra en mängd olika operationer, som t.ex. pivot, JOIN (som en Excel VLOOKUP-operation), aritmetisk operationer och mer, tillhandahåller en mångsidig och effektiv lösning för att stämma av stora datamängder. Denna förbättring är ett bevis på skalbarheten och hastigheten som uppnås genom införandet av distribuerade databehandlingslösningar.

I det här inlägget förklarar vi hur vi integrerade Amazon EMR för att bygga ett mycket tillgängligt och skalbart system som gjorde det möjligt för oss att köra en ekonomisk avstämningsprocess med stora volymer.

Arkitektur före migration

Följande diagram illustrerar vår tidigare arkitektur.

Vår äldre tjänst byggdes med Amazon Elastic Container Service (Amazon ECS) den AWS Fargate. Vi bearbetade data sekventiellt med Python. Men på grund av bristen på parallell bearbetningskapacitet var vi ofta tvungna att öka klusterstorleken vertikalt för att stödja större datamängder. För sammanhanget tog 5 GB data med 50 operationer cirka 3 timmar att bearbeta. Den här tjänsten konfigurerades för att skala horisontellt till fem ECS-instanser som hämtade meddelanden från Amazon enkel kötjänst (Amazon SQS), som matade omvandlingsförfrågningarna. Varje instans konfigurerades med 4 vCPU:er och 30 GB minne för att tillåta horisontell skalning. Vi kunde dock inte utöka dess prestandakapacitet eftersom processen skedde sekventiellt och plockade ut bitar av data från Amazon enkel lagringstjänst (Amazon S3) för bearbetning. Till exempel, en VLOOKUP-operation där två filer ska sammanfogas krävde att båda filerna lästes i minnet bit för bit för att få utdata. Detta blev ett hinder för användarna eftersom de var tvungna att vänta i långa perioder för att bearbeta sina datamängder.

Som en del av vår omarkitektur och modernisering ville vi uppnå följande:

• Hög tillgänglighet – Databehandlingsklustren bör vara högst tillgängliga och tillhandahålla tre 9:or av tillgänglighet (99.9 %)
• genomströmning – Tjänsten ska hantera 1,500 XNUMX körningar per dag
• Latens – Den ska kunna behandla 100 GB data inom 30 minuter
• Heterogenitet – Klustret bör kunna stödja en mängd olika arbetsbelastningar, med filer som sträcker sig från några MB till hundratals GB
• Fråga samtidigt – Implementeringen kräver förmågan att stödja minst 10 grader av samtidighet
• Tillförlitlighet för jobb och datakonsistens – Jobb måste köras tillförlitligt och konsekvent för att undvika att bryta servicenivåavtal (SLA)
• Kostnadseffektiv och skalbar – Det måste vara skalbart utifrån arbetsbelastningen, vilket gör det kostnadseffektivt
• Säkerhet och efterlevnad – Med tanke på informationens känslighet måste den stödja finkornig åtkomstkontroll och lämpliga säkerhetsimplementeringar
• Övervakning – Lösningen måste erbjuda end-to-end övervakning av klustren och jobben

Varför Amazon EMR

Amazon EMR är den branschledande cloud big data-lösningen för petabyte-skala databehandling, interaktiv analys och maskininlärning (ML) med ramverk med öppen källkod som t.ex. Apache Spark, Apache-bikupanoch Presto. Med dessa ramverk och relaterade projekt med öppen källkod kan du bearbeta data för analysändamål och BI-arbetsbelastningar. Amazon EMR låter dig transformera och flytta stora mängder data in och ut ur andra AWS-datalager och databaser, som Amazon S3 och Amazon DynamoDB.

En anmärkningsvärd fördel med Amazon EMR ligger i dess effektiva användning av parallell bearbetning med PySpark, vilket markerar en betydande förbättring jämfört med traditionell sekventiell Python-kod. Detta innovativa tillvägagångssätt effektiviserar distributionen och skalningen av Apache Spark-kluster, vilket möjliggör effektiv parallellisering på stora datamängder. Den distribuerade datorinfrastrukturen förbättrar inte bara prestanda, utan möjliggör också bearbetning av enorma mängder data med oöverträffade hastigheter. Utrustad med bibliotek underlättar PySpark Excel-liknande operationer på Dataramar, och den överordnade abstraktionen av DataFrames förenklar intrikata datamanipulationer, vilket minskar kodkomplexiteten. Kombinerat med automatisk klusterprovisionering, dynamisk resursallokering och integration med andra AWS-tjänster, visar sig Amazon EMR vara en mångsidig lösning som lämpar sig för olika arbetsbelastningar, allt från batchbearbetning till ML. Den inneboende feltoleransen i PySpark och Amazon EMR främjar robusthet, även i händelse av nodfel, vilket gör det till ett skalbart, kostnadseffektivt och högpresterande val för parallell databehandling på AWS.

Amazon EMR utökar sina möjligheter utöver grunderna och erbjuder en mängd olika distributionsalternativ för att tillgodose olika behov. Oavsett om det är det Amazon EMR på EC2, Amazon EMR på EKS, Amazon EMR-serverlös, eller Amazon EMR på AWS Outposts, kan du skräddarsy ditt tillvägagångssätt efter specifika krav. För de som söker en serverlös miljö för Spark-jobb, integrering AWS-lim är också ett genomförbart alternativ. Förutom att stödja olika ramverk med öppen källkod, inklusive Spark, ger Amazon EMR flexibilitet vid val av distributionslägen, Amazon Elastic Compute Cloud (Amazon EC2) instanstyper, skalningsmekanismer och många kostnadsbesparande optimeringstekniker.

Amazon EMR står som en dynamisk kraft i molnet och levererar oöverträffade möjligheter för organisationer som söker robusta big data-lösningar. Dess sömlösa integration, kraftfulla funktioner och anpassningsförmåga gör det till ett oumbärligt verktyg för att navigera i komplexiteten med dataanalys och ML på AWS.

Omarbetad arkitektur

Följande diagram illustrerar vår omarbetade arkitektur.

Lösningen fungerar under ett API-kontrakt, där klienter kan skicka in transformationskonfigurationer, som definierar uppsättningen operationer tillsammans med S3-datauppsättningsplatsen för bearbetning. Begäran köas via Amazon SQS och dirigeras sedan till Amazon EMR via en lambdafunktion. Denna process initierar skapandet av ett Amazon EMR-steg för implementering av Spark-ramverket på ett dedikerat EMR-kluster. Även om Amazon EMR rymmer ett obegränsat antal steg under ett långvarigt klusters livstid, kan endast 256 steg vara igång eller väntande samtidigt. För optimal parallellisering sätts stegens samtidighet till 10, vilket gör att 10 steg kan köras samtidigt. Om begäran misslyckas, Amazon SQS dödbokstavskö (DLQ) behåller händelsen. Spark bearbetar begäran och översätter Excel-liknande operationer till PySpark-kod för en effektiv frågeplan. Resilient DataFrames lagrar indata, utdata och mellanliggande data i minnet, optimerar bearbetningshastigheten, minskar disk I/O-kostnaderna, förbättrar arbetsbelastningsprestanda och levererar den slutliga utdata till den specificerade Amazon S3-platsen.

Vi definierar vår SLA i två dimensioner: latens och genomströmning. Latens definieras som hur lång tid det tar att utföra ett jobb mot en deterministisk datauppsättningsstorlek och antalet operationer som utförs på datauppsättningen. Genomströmning definieras som det maximala antalet samtidiga jobb som tjänsten kan utföra utan att bryta mot latens-SLA för ett jobb. Tjänstens övergripande SLA för skalbarhet beror på balansen mellan horisontell skalning av elastiska beräkningsresurser och vertikal skalning av individuella servrar.

Eftersom vi var tvungna att köra 1,500 2 processer per dag med minimal latens och hög prestanda, valde vi att integrera Amazon EMR i ECXNUMX-distributionsläget med hanterad skalning aktiverad för att stödja bearbetning av varierande filstorlekar.

EMR-klusterkonfigurationen ger många olika val:

• EMR-nodtyper – Primär-, kärn- eller uppgiftsnoder
• Exempel på köpalternativ – On-Demand-instanser, reserverade instanser eller spot-instanser
• Konfigurationsalternativ – EMR-instansflotta eller enhetlig instansgrupp
• Skalningsalternativ - Automatisk skalning eller Amazon EMR-hanterad skalning

Baserat på vår varierande arbetsbelastning konfigurerade vi en EMR-instansflotta (för bästa praxis, se Pålitlighet). Vi beslutade också att använda Amazon EMR-hanterad skalning för att skala kärn- och uppgiftsnoderna (för skalningsscenarier, se Scenarier för nodtilldelning). Till sist valde vi minnesoptimerat AWS Graviton instanser, som ger upp till 30 % lägre kostnad och upp till 15 % förbättrad prestanda för Spark-arbetsbelastningar.

Följande kod ger en ögonblicksbild av vår klusterkonfiguration:

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

prestanda

Med vår migrering till Amazon EMR kunde vi uppnå en systemprestanda som kan hantera en mängd olika datauppsättningar, allt från så låga som 273 B till så höga som 88.5 GB med en p99 på 491 sekunder (ungefär 8 minuter).

Följande figur illustrerar de olika filstorlekarna som behandlas.

Följande bild visar vår latens.

För att jämföra med sekventiell bearbetning tog vi två datauppsättningar innehållande 53 miljoner poster och körde en VLOOKUP-operation mot varandra, tillsammans med 49 andra Excel-liknande operationer. Detta tog 26 minuter att bearbeta i den nya tjänsten, jämfört med 5 dagar att bearbeta i den äldre tjänsten. Denna förbättring är nästan 300 gånger större jämfört med den tidigare arkitekturen när det gäller prestanda.

Överväganden

Tänk på följande när du överväger den här lösningen:

• Rätt storlek kluster – Även om Amazon EMR går att ändra storlek på är det viktigt att anpassa klustren till rätt storlek. Rätt storlek minskar ett långsamt kluster, om det är underdimensionerat, eller högre kostnader, om klustret är överdimensionerat. För att förutse dessa problem kan du beräkna antalet och typen av noder som kommer att behövas för arbetsbelastningarna.
• Parallella steg – Genom att köra steg parallellt kan du köra mer avancerade arbetsbelastningar, öka klusterresursutnyttjandet och minska den tid det tar att slutföra din arbetsbelastning. Antalet steg som får köras på en gång är konfigurerbart och kan ställas in när ett kluster startas och när som helst efter att klustret har startat. Du måste överväga och optimera CPU/minnesanvändningen per jobb när flera jobb körs i ett enda delat kluster.
• Jobbbaserade transient EMR-kluster – Om tillämpligt rekommenderas det att använda ett jobbbaserat transient EMR-kluster, som ger överlägsen isolering, som verifierar att varje uppgift fungerar inom sin dedikerade miljö. Detta tillvägagångssätt optimerar resursutnyttjandet, hjälper till att förhindra störningar mellan jobb och förbättrar övergripande prestanda och tillförlitlighet. Den övergående naturen möjliggör effektiv skalning, vilket ger en robust och isolerad lösning för olika databehandlingsbehov.
• EMR-serverlös – EMR Serverless är det perfekta valet om du föredrar att inte hantera hantering och drift av kluster. Det låter dig köra applikationer utan ansträngning med ramverk med öppen källkod som är tillgängliga inom EMR Serverless, vilket erbjuder en enkel och problemfri upplevelse.
• amason EMR på EKS – Amazon EMR på EKS erbjuder tydliga fördelar, såsom snabbare starttider och förbättrad skalbarhet för att lösa beräkningskapacitetsutmaningar – vilket är särskilt fördelaktigt för användare av Graviton och Spot Instance. Inkluderandet av ett bredare utbud av beräkningstyper ökar kostnadseffektiviteten, vilket möjliggör skräddarsydd resursallokering. Dessutom ger Multi-AZ-stöd ökad tillgänglighet. Dessa övertygande funktioner ger en robust lösning för att hantera big data-arbetsbelastningar med förbättrad prestanda, kostnadsoptimering och tillförlitlighet över olika datorscenarier.

Slutsats

I det här inlägget förklarade vi hur Amazon optimerade sin ekonomiska avstämningsprocess för stora volymer med Amazon EMR för högre skalbarhet och prestanda. Om du har en monolitisk applikation som är beroende av vertikal skalning för att bearbeta ytterligare förfrågningar eller datauppsättningar, kan det hjälpa att migrera den till ett distribuerat bearbetningsramverk som Apache Spark och välja en hanterad tjänst som Amazon EMR för beräkning. SLA, och kan också hjälpa till att minska den totala ägandekostnaden (TCO).

När vi anammar Amazon EMR för detta specifika användningsfall, uppmuntrar vi dig att utforska ytterligare möjligheter i din datainnovationsresa. Överväg att utvärdera AWS Glue, tillsammans med andra dynamiska Amazon EMR-distributionsalternativ som EMR Serverless eller Amazon EMR på EKS, för att upptäcka den bästa AWS-tjänsten skräddarsydd för ditt unika användningsfall. Framtiden för datainnovationsresan har spännande möjligheter och framsteg som ska utforskas ytterligare.

Om författarna

Jeeshan Khetrapal är en senior mjukvaruutvecklingsingenjör på Amazon, där han utvecklar fintech-produkter baserade på molnbaserade serverlösa arkitekturer för datoranvändning som ansvarar för företagens allmänna IT-kontroller, finansiella rapportering och kontroll av styrning, risk och efterlevnad.

Sakti Mishra är en Principal Solutions Architect på AWS, där han hjälper kunder att modernisera sin dataarkitektur och definiera sin heltäckande datastrategi, inklusive datasäkerhet, tillgänglighet, styrning och mer. Han är också författare till boken Förenkla Big Data Analytics med Amazon EMR. Utanför jobbet tycker Sakti om att lära sig ny teknik, titta på film och besöka platser med familjen.

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
• PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
• Platoesg. Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
• PlatoHealth. Biotech och kliniska prövningar Intelligence. Tillgång här.
• Källa: https://aws.amazon.com/blogs/big-data/how-amazon-optimized-its-high-volume-financial-reconciliation-process-with-amazon-emr-for-higher-scalability-and-performance/