Kontoavstemming er et viktig skritt for å sikre fullstendigheten og nøyaktigheten til regnskapet. Konkret må bedrifter forsone seg balanse kontoer som kan inneholde vesentlig eller vesentlig feilinformasjon. Regnskapsførere går gjennom hver konto i hovedboken og kontrollerer at saldoen som er oppført er fullstendig og nøyaktig. Når det oppdages avvik, undersøker regnskapsførere og iverksetter passende korrigerende tiltak.

Som en del av Amazons FinTech-organisasjon tilbyr vi en programvareplattform som gir de interne regnskapsteamene i Amazon mulighet til å utføre kontoavstemminger. For å optimere avstemmingsprosessen krever disse brukerne transformasjon med høy ytelse med muligheten til å skalere på forespørsel, samt muligheten til å behandle variable filstørrelser som strekker seg fra så lave som noen få MB til mer enn 100 GB. Det er ikke alltid mulig å tilpasse data på en enkelt maskin eller behandle dem med ett enkelt program i en rimelig tidsramme. Denne beregningen må gjøres raskt nok til å gi praktiske tjenester der programmeringslogikk og underliggende detaljer (datadistribusjon, feiltoleranse og planlegging) kan skilles.

Vi kan oppnå disse samtidige beregningene på flere maskiner eller tråder med samme funksjon på tvers av grupper av elementer i et datasett ved å bruke distribuerte databehandlingsløsninger. Dette oppmuntret oss til å gjenoppfinne vår avstemmingstjeneste drevet av AWS-tjenester, inkludert Amazon EMR og Apache Spark distribuert behandlingsrammeverk, som bruker PySpark. Denne tjenesten gjør det mulig for brukere å behandle filer over 100 GB som inneholder opptil 100 millioner transaksjoner på mindre enn 30 minutter. Avstemmingstjenesten har blitt et kraftsenter for databehandling, og nå kan brukere sømløst utføre en rekke operasjoner, som f.eks. Pivot, BLI (som en Excel VLOOKUP-operasjon), aritmetikk operasjoner, og mer, som gir en allsidig og effektiv løsning for å forene enorme datasett. Denne forbedringen er et vitnesbyrd om skalerbarheten og hastigheten som oppnås gjennom bruk av distribuerte databehandlingsløsninger.

I dette innlegget forklarer vi hvordan vi integrerte Amazon EMR for å bygge et svært tilgjengelig og skalerbart system som gjorde det mulig for oss å kjøre en høyvolums økonomisk avstemmingsprosess.

Arkitektur før migrasjon

Følgende diagram illustrerer vår tidligere arkitektur.

Vår eldre tjeneste ble bygget med Amazon Elastic Container Service (Amazon ECS) på AWS Fargate. Vi behandlet dataene sekvensielt ved hjelp av Python. På grunn av mangelen på parallellbehandlingsevne, måtte vi imidlertid ofte øke klyngestørrelsen vertikalt for å støtte større datasett. For kontekst tok 5 GB data med 50 operasjoner rundt 3 timer å behandle. Denne tjenesten ble konfigurert til å skalere horisontalt til fem ECS-forekomster som pollet meldinger fra Amazon enkel køtjeneste (Amazon SQS), som matet transformasjonsforespørslene. Hver forekomst ble konfigurert med 4 vCPUer og 30 GB minne for å tillate horisontal skalering. Vi kunne imidlertid ikke utvide ytelseskapasiteten fordi prosessen skjedde sekvensielt, og plukket ut biter av data fra Amazon enkel lagringstjeneste (Amazon S3) for behandling. For eksempel, en VLOOKUP-operasjon der to filer skal slås sammen krevde at begge filene ble lest i minnet bit for bit for å få utdata. Dette ble en hindring for brukerne fordi de måtte vente i lange perioder med å behandle datasettene sine.

Som en del av vår re-arkitektur og modernisering ønsket vi å oppnå følgende:

• Høy tilgjengelighet – Databehandlingsklyngene bør være svært tilgjengelige, og gi tre 9-er med tilgjengelighet (99.9 %)
• gjennomstrømming – Tjenesten skal håndtere 1,500 kjøringer per dag
• Ventetid – Den skal kunne behandle 100 GB data innen 30 minutter
• heterogenitet – Klyngen skal kunne støtte et bredt utvalg av arbeidsbelastninger, med filer fra noen få MB til hundrevis av GB
• Søk samtidig – Implementeringen krever evnen til å støtte minimum 10 grader av samtidighet
• Pålitelighet av jobber og datakonsistens – Jobbene må kjøres pålitelig og konsekvent for å unngå brudd på servicenivåavtaler (SLAer)
• Kostnadseffektiv og skalerbar – Det må være skalerbart basert på arbeidsmengden, noe som gjør det kostnadseffektivt
• Sikkerhet og samsvar – Gitt sensitiviteten til data, må de støtte finmasket tilgangskontroll og passende sikkerhetsimplementeringer
• Overvåking – Løsningen skal tilby ende-til-ende overvåking av klyngene og arbeidsplassene

Hvorfor Amazon EMR

Amazon EMR er den bransjeledende cloud big data-løsningen for petabyte-skala databehandling, interaktiv analyse og maskinlæring (ML) ved bruk av åpen kildekode-rammeverk som f.eks. Apache Spark, Apache Hiveog Presto. Med disse rammeverkene og relaterte åpen kildekode-prosjekter kan du behandle data for analyseformål og BI-arbeidsbelastninger. Amazon EMR lar deg transformere og flytte store mengder data inn og ut av andre AWS-datalagre og -databaser, som Amazon S3 og Amazon DynamoDB.

En bemerkelsesverdig fordel med Amazon EMR ligger i dens effektive bruk av parallell prosessering med PySpark, som markerer en betydelig forbedring i forhold til tradisjonell sekvensiell Python-kode. Denne innovative tilnærmingen effektiviserer distribusjonen og skaleringen av Apache Spark-klynger, noe som muliggjør effektiv parallellisering på store datasett. Den distribuerte datainfrastrukturen forbedrer ikke bare ytelsen, men muliggjør også prosessering av enorme mengder data med enestående hastigheter. Utstyrt med biblioteker, letter PySpark Excel-lignende operasjoner på Datarammer, og abstraksjonen på høyere nivå av DataFrames forenkler intrikate datamanipulasjoner, og reduserer kodekompleksiteten. Kombinert med automatisk klyngeklargjøring, dynamisk ressursallokering og integrasjon med andre AWS-tjenester, viser Amazon EMR seg å være en allsidig løsning som passer for ulike arbeidsbelastninger, alt fra batchbehandling til ML. Den iboende feiltoleransen i PySpark og Amazon EMR fremmer robusthet, selv i tilfelle nodefeil, noe som gjør det til et skalerbart, kostnadseffektivt og høyytelsesvalg for parallell databehandling på AWS.

Amazon EMR utvider sine muligheter utover det grunnleggende, og tilbyr en rekke distribusjonsalternativer for å imøtekomme ulike behov. Enten det er Amazon EMR på EC2, Amazon EMR på EKS, Amazon EMR-serverløseller Amazon EMR på AWS Outposts, kan du skreddersy din tilnærming til spesifikke krav. For de som søker et serverløst miljø for Spark-jobber, integrering AWS Lim er også et levedyktig alternativ. I tillegg til å støtte ulike open source-rammeverk, inkludert Spark, gir Amazon EMR fleksibilitet i valg av distribusjonsmoduser, Amazon Elastic Compute Cloud (Amazon EC2) instanstyper, skaleringsmekanismer og en rekke kostnadsbesparende optimaliseringsteknikker.

Amazon EMR står som en dynamisk kraft i skyen, og leverer uovertruffen kapasitet for organisasjoner som søker robuste big data-løsninger. Den sømløse integrasjonen, kraftige funksjonene og tilpasningsevnen gjør den til et uunnværlig verktøy for å navigere i kompleksiteten til dataanalyse og ML på AWS.

Redesignet arkitektur

Følgende diagram illustrerer vår redesignede arkitektur.

Løsningen opererer under en API-kontrakt, der klienter kan sende inn transformasjonskonfigurasjoner, og definere settet med operasjoner ved siden av S3-datasettet for behandling. Forespørselen settes i kø gjennom Amazon SQS, og sendes deretter til Amazon EMR via en Lambda-funksjon. Denne prosessen initierer opprettelsen av et Amazon EMR-trinn for implementering av Spark-rammeverk på en dedikert EMR-klynge. Selv om Amazon EMR har plass til et ubegrenset antall trinn over en langvarig klynges levetid, kan bare 256 trinn kjøres eller ventes samtidig. For optimal parallellisering settes trinnsamtiden til 10, slik at 10 trinn kan kjøres samtidig. I tilfelle forespørselsfeil, Amazon SQS dødbokstavkø (DLQ) beholder hendelsen. Spark behandler forespørselen og oversetter Excel-lignende operasjoner til PySpark-kode for en effektiv spørringsplan. Resilient DataFrames lagrer input, output og mellomliggende data i minnet, optimaliserer prosesseringshastigheten, reduserer disk I/O-kostnadene, forbedrer arbeidsbelastningsytelsen og leverer den endelige utgangen til den spesifiserte Amazon S3-lokasjonen.

Vi definerer vår SLA i to dimensjoner: latency og throughput. Latens er definert som hvor lang tid det tar å utføre én jobb mot en deterministisk datasettstørrelse og antall operasjoner utført på datasettet. Gjennomstrømning er definert som det maksimale antallet samtidige jobber tjenesten kan utføre uten å bryte ventetid SLA for én jobb. Tjenestens generelle SLA for skalerbarhet avhenger av balansen mellom horisontal skalering av elastiske dataressurser og vertikal skalering av individuelle servere.

Fordi vi måtte kjøre 1,500 prosesser per dag med minimal latens og høy ytelse, valgte vi å integrere Amazon EMR i EC2-distribusjonsmodus med administrert skalering aktivert for å støtte behandling av variable filstørrelser.

EMR-klyngekonfigurasjonen gir mange forskjellige valg:

• EMR-nodetyper – Primær-, kjerne- eller oppgavenoder
• Forekomst av kjøpsalternativer – On-Demand-forekomster, reserverte forekomster eller spot-forekomster
• Konfigurasjonsalternativer – EMR-instansflåte eller enhetlig instansgruppe
• Skaleringsalternativer - Automatisk skalering eller Amazon EMR-administrert skalering

Basert på vår variable arbeidsmengde konfigurerte vi en EMR-forekomstflåte (for beste praksis, se Pålitelighet). Vi bestemte oss også for å bruke Amazon EMR-administrert skalering for å skalere kjerne- og oppgavenodene (for skaleringsscenarier, se Scenarier for nodetildeling). Til slutt valgte vi minneoptimalisert AWS Graviton instanser, som gir opp til 30 % lavere kostnad og opptil 15 % forbedret ytelse for Spark-arbeidsbelastninger.

Følgende kode gir et øyeblikksbilde av klyngekonfigurasjonen vår:

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

Ytelse

Med vår migrering til Amazon EMR var vi i stand til å oppnå en systemytelse som er i stand til å håndtere en rekke datasett, fra så lave som 273 B til så høye som 88.5 GB med en p99 på 491 sekunder (omtrent 8 minutter).

Følgende figur illustrerer variasjonen av filstørrelser som behandles.

Følgende figur viser ventetiden vår.

For å sammenligne med sekvensiell behandling, tok vi to datasett som inneholder 53 millioner poster og kjørte en VLOOKUP-operasjon mot hverandre, sammen med 49 andre Excel-lignende operasjoner. Dette tok 26 minutter å behandle i den nye tjenesten, sammenlignet med 5 dager å behandle i den eldre tjenesten. Denne forbedringen er nesten 300 ganger større enn den forrige arkitekturen når det gjelder ytelse.

betraktninger

Husk følgende når du vurderer denne løsningen:

• Klynger i riktig størrelse – Selv om Amazon EMR kan endre størrelsen, er det viktig å rette størrelsen på klyngene. Riktig størrelse reduserer en langsom klynge, hvis den er underdimensjonert, eller høyere kostnader, hvis klyngen er overdimensjonert. For å forutse disse problemene, kan du beregne antall og type noder som vil være nødvendig for arbeidsbelastningene.
• Parallelle trinn – Ved å kjøre trinn parallelt kan du kjøre mer avanserte arbeidsbelastninger, øke klyngresursutnyttelsen og redusere tiden det tar å fullføre arbeidsmengden. Antall trinn som tillates å kjøre på en gang er konfigurerbart og kan angis når en klynge startes og når som helst etter at klyngen har startet. Du må vurdere og optimalisere CPU/minnebruken per jobb når flere jobber kjører i en enkelt delt klynge.
• Jobbbaserte forbigående EMR-klynger – Hvis det er aktuelt, anbefales det å bruke en jobbbasert forbigående EMR-klynge, som gir overlegen isolasjon, som bekrefter at hver oppgave fungerer innenfor sitt dedikerte miljø. Denne tilnærmingen optimaliserer ressursutnyttelsen, bidrar til å forhindre forstyrrelser mellom jobber og forbedrer den generelle ytelsen og påliteligheten. Den forbigående naturen muliggjør effektiv skalering, og gir en robust og isolert løsning for ulike databehandlingsbehov.
• EMR-serverløs – EMR Serverless er det ideelle valget hvis du foretrekker å ikke håndtere administrasjon og drift av klynger. Den lar deg enkelt kjøre applikasjoner ved å bruke åpen kildekode-rammeverk tilgjengelig i EMR Serverless, og tilbyr en enkel og problemfri opplevelse.
• Amazon EMR på EKS – Amazon EMR på EKS tilbyr distinkte fordeler, som raskere oppstartstider og forbedret skalerbarhet som løser utfordringer med beregningskapasitet – noe som er spesielt fordelaktig for Graviton- og Spot Instance-brukere. Inkluderingen av et bredere spekter av datatyper øker kostnadseffektiviteten, og muliggjør skreddersydd ressursallokering. Videre gir Multi-AZ-støtte økt tilgjengelighet. Disse overbevisende funksjonene gir en robust løsning for å håndtere store data-arbeidsmengder med forbedret ytelse, kostnadsoptimalisering og pålitelighet på tvers av ulike databehandlingsscenarier.

konklusjonen

I dette innlegget forklarte vi hvordan Amazon optimaliserte sin høyvolums økonomiske avstemmingsprosess med Amazon EMR for høyere skalerbarhet og ytelse. Hvis du har en monolittisk applikasjon som er avhengig av vertikal skalering for å behandle flere forespørsler eller datasett, kan det å migrere den til et distribuert prosesseringsrammeverk som Apache Spark og velge en administrert tjeneste som Amazon EMR for compute bidra til å redusere kjøretiden for å redusere leveringen. SLA, og kan også bidra til å redusere totalkostnaden for eierskap (TCO).

Når vi omfavner Amazon EMR for denne spesielle brukssaken, oppfordrer vi deg til å utforske ytterligere muligheter i din datainnovasjonsreise. Vurder å evaluere AWS Glue, sammen med andre dynamiske Amazon EMR-distribusjonsalternativer som EMR Serverless eller Amazon EMR på EKS, for å finne den beste AWS-tjenesten som er skreddersydd for ditt unike bruksområde. Fremtiden for datainnovasjonsreisen har spennende muligheter og fremskritt som skal utforskes videre.

Om forfatterne

Jeeshan Khetrapal er Sr. Software Development Engineer hos Amazon, hvor han utvikler fintech-produkter basert på cloud computing-serverløse arkitekturer som er ansvarlige for selskapers generelle IT-kontroller, finansiell rapportering og kontroller for styring, risiko og overholdelse.

Sakti Mishra er en Principal Solutions Architect hos AWS, hvor han hjelper kunder med å modernisere dataarkitekturen og definere deres ende-til-ende datastrategi, inkludert datasikkerhet, tilgjengelighet, styring og mer. Han er også forfatter av boken Forenkle Big Data Analytics med Amazon EMR. Utenom jobben liker Sakti å lære nye teknologier, se filmer og besøke steder med familien.

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
• PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
• PlatoESG. Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
• PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
• kilde: https://aws.amazon.com/blogs/big-data/how-amazon-optimized-its-high-volume-financial-reconciliation-process-with-amazon-emr-for-higher-scalability-and-performance/