Reconcilierea contului este un pas important pentru a asigura integralitatea și acuratețea situațiilor financiare. Mai exact, companiile trebuie să se împace bilanț conturi care ar putea conține denaturări semnificative sau semnificative. Contabilii parcurg fiecare cont din registrul general de conturi și verifică dacă soldul listat este complet și corect. Când se constată discrepanțe, contabilii investighează și iau măsurile corective adecvate.

Ca parte a organizației FinTech a Amazon, oferim o platformă software care dă putere echipelor interne de contabilitate de la Amazon să efectueze reconcilieri de cont. Pentru a optimiza procesul de reconciliere, acești utilizatori au nevoie de o transformare de înaltă performanță, cu capacitatea de a scala la cerere, precum și capacitatea de a procesa fișiere cu dimensiuni variabile, de la câțiva MB la mai mult de 100 GB. Nu este întotdeauna posibil să potriviți datele pe o singură mașină sau să le procesați cu un singur program într-un interval de timp rezonabil. Acest calcul trebuie făcut suficient de rapid pentru a oferi servicii practice în care logica de programare și detaliile subiacente (distribuția datelor, toleranța la erori și programarea) pot fi separate.

Putem realiza aceste calcule simultane pe mai multe mașini sau fire de execuție ale aceleiași funcții în grupuri de elemente ale unui set de date folosind soluții distribuite de procesare a datelor. Acest lucru ne-a încurajat să reinventăm serviciul nostru de reconciliere alimentat de serviciile AWS, inclusiv Amazon EMR si Apache Spark cadru de procesare distribuită, care utilizează PySpark. Acest serviciu permite utilizatorilor să proceseze fișiere de peste 100 GB care conțin până la 100 de milioane de tranzacții în mai puțin de 30 de minute. Serviciul de reconciliere a devenit o centrală puternică pentru procesarea datelor, iar acum utilizatorii pot efectua fără probleme o varietate de operațiuni, cum ar fi Pivot, JOIN (ca o operație Excel VLOOKUP), aritmetic operațiuni și mai mult, oferind o soluție versatilă și eficientă pentru reconcilierea unor seturi de date vaste. Această îmbunătățire este o dovadă a scalabilității și vitezei obținute prin adoptarea soluțiilor distribuite de procesare a datelor.

În această postare, explicăm cum am integrat Amazon EMR pentru a construi un sistem foarte disponibil și scalabil care ne-a permis să rulăm un proces de reconciliere financiară de mare volum.

Arhitectura înainte de migrare

Următoarea diagramă ilustrează arhitectura noastră anterioară.

Serviciul nostru moștenit a fost construit cu Serviciul Amazon de containere elastice (Amazon ECS) activat AWS Fargate. Am procesat datele secvenţial folosind Python. Cu toate acestea, din cauza lipsei capacității de procesare paralelă, a trebuit frecvent să creștem dimensiunea clusterului pe verticală pentru a suporta seturi de date mai mari. Pentru context, procesarea a 5 GB de date cu 50 de operațiuni a durat aproximativ 3 ore. Acest serviciu a fost configurat pentru a scala orizontal la cinci instanțe ECS de la care au interogat mesajele Serviciul de coadă simplă Amazon (Amazon SQS), care a alimentat cererile de transformare. Fiecare instanță a fost configurată cu 4 vCPU și 30 GB de memorie pentru a permite scalarea orizontală. Cu toate acestea, nu i-am putut extinde capacitatea de performanță, deoarece procesul s-a desfășurat secvenţial, culegând bucăţi de date din Serviciul Amazon de stocare simplă (Amazon S3) pentru procesare. De exemplu, o operație VLOOKUP în care două fișiere trebuie să fie unite a necesitat ca ambele fișiere să fie citite în memorie bucată cu bucată pentru a obține rezultatul. Acest lucru a devenit un obstacol pentru utilizatori, deoarece au trebuit să aștepte perioade lungi de timp pentru a-și procesa seturile de date.

Ca parte a rearhitecturii și modernizării noastre, ne-am dorit să realizăm următoarele:

• Valabilitate mare – Clusterele de procesare a datelor ar trebui să fie foarte disponibile, oferind trei 9 de disponibilitate (99.9%)
• tranzitată – Serviciul ar trebui să gestioneze 1,500 de rulări pe zi
• Latență – Ar trebui să poată procesa 100 GB de date în 30 de minute
• eterogenitatea – Clusterul ar trebui să poată suporta o mare varietate de sarcini de lucru, cu fișiere variind de la câțiva MB la sute de GB
• Interogarea simultană – Implementarea necesită capacitatea de a suporta un minim de 10 grade de concurență
• Fiabilitatea locurilor de muncă și consistența datelor – Lucrările trebuie să ruleze în mod fiabil și consecvent pentru a evita încălcarea acordurilor de nivel de serviciu (SLA)
• Cost-eficient și scalabil – Trebuie să fie scalabil în funcție de volumul de muncă, făcându-l rentabil
• Securitate și conformitate – Având în vedere sensibilitatea datelor, trebuie să suporte controlul de acces cu granulație fină și implementări adecvate de securitate
• Monitorizarea – Soluția trebuie să ofere monitorizare end-to-end a clusterelor și a locurilor de muncă

De ce Amazon EMR

Amazon EMR este soluția de big data în cloud lider în industrie pentru procesarea datelor la scară petabyte, analiză interactivă și învățare automată (ML) folosind cadre open source, cum ar fi Apache Spark, Apache Hive, și Presto. Cu aceste cadre și proiecte open-source aferente, puteți procesa date în scopuri de analiză și sarcini de lucru BI. Amazon EMR vă permite să transformați și să mutați cantități mari de date în și din alte baze de date și baze de date AWS, cum ar fi Amazon S3 și Amazon DynamoDB.

Un avantaj notabil al Amazon EMR constă în utilizarea eficientă a procesării paralele cu PySpark, marcând o îmbunătățire semnificativă față de codul Python secvențial tradițional. Această abordare inovatoare eficientizează implementarea și scalarea clusterelor Apache Spark, permițând paralelizarea eficientă pe seturi mari de date. Infrastructura de calcul distribuită nu numai că îmbunătățește performanța, dar permite și procesarea unor cantități mari de date la viteze fără precedent. Echipat cu biblioteci, PySpark facilitează operațiuni similare cu Excel Cadre de date, iar abstracția de nivel superior a DataFrames simplifică manipulările complicate ale datelor, reducând complexitatea codului. Combinat cu furnizarea automată a clusterelor, alocarea dinamică a resurselor și integrarea cu alte servicii AWS, Amazon EMR se dovedește a fi o soluție versatilă, potrivită pentru diverse sarcini de lucru, de la procesarea în loturi până la ML. Toleranța inerentă la erori în PySpark și Amazon EMR promovează robustețea, chiar și în cazul defecțiunilor nodurilor, făcându-l o alegere scalabilă, rentabilă și de înaltă performanță pentru procesarea paralelă a datelor pe AWS.

Amazon EMR își extinde capacitățile dincolo de elementele de bază, oferind o varietate de opțiuni de implementare pentru a răspunde nevoilor diverse. Fie că este Amazon EMR pe EC2, Amazon EMR pe EKS, Amazon EMR fără server, Sau Amazon EMR pe AWS Outposts, vă puteți adapta abordarea la cerințe specifice. Pentru cei care caută un mediu fără server pentru joburi Spark, integrare AWS Adeziv este, de asemenea, o opțiune viabilă. Pe lângă faptul că acceptă diverse cadre open-source, inclusiv Spark, Amazon EMR oferă flexibilitate în alegerea modurilor de implementare, Cloud Elastic de calcul Amazon (Amazon EC2), tipuri de instanțe, mecanisme de scalare și numeroase tehnici de optimizare care economisesc costuri.

Amazon EMR reprezintă o forță dinamică în cloud, oferind capabilități de neegalat pentru organizațiile care caută soluții robuste de date mari. Integrarea perfectă, caracteristicile puternice și adaptabilitatea îl fac un instrument indispensabil pentru navigarea în complexitățile analizei datelor și ML pe AWS.

Arhitectură reproiectată

Următoarea diagramă ilustrează arhitectura noastră reproiectată.

Soluția funcționează în baza unui contract API, în care clienții pot trimite configurații de transformare, definind setul de operațiuni alături de locația setului de date S3 pentru procesare. Solicitarea este pusă în coadă prin Amazon SQS, apoi direcționată către Amazon EMR printr-o funcție Lambda. Acest proces inițiază crearea unui pas Amazon EMR pentru implementarea cadrului Spark pe un cluster EMR dedicat. Deși Amazon EMR găzduiește un număr nelimitat de pași pe durata de viață a unui cluster de lungă durată, doar 256 de pași pot fi rulați sau în așteptare simultan. Pentru o paralelizare optimă, concurența pasului este setată la 10, permițând rularea simultană a 10 pași. În cazul eșecului cererii, Amazon SQS coada de scrisori moarte (DLQ) reține evenimentul. Spark procesează cererea, traducând operațiuni similare Excel în cod PySpark pentru un plan de interogare eficient. DataFrames rezistente stochează datele de intrare, de ieșire și intermediare în memorie, optimizând viteza de procesare, reducând costul I/O pe disc, îmbunătățind performanța încărcăturii de lucru și livrând rezultatul final în locația Amazon S3 specificată.

Ne definim SLA în două dimensiuni: latența și debitul. Latența este definită ca perioada de timp necesară pentru a efectua o lucrare în raport cu dimensiunea unui set de date determinist și numărul de operațiuni efectuate pe setul de date. Debitul este definit ca numărul maxim de joburi simultane pe care serviciul le poate efectua fără a încălca SLA de latență a unui job. SLA-ul global de scalabilitate al serviciului depinde de echilibrul dintre scalarea orizontală a resurselor de calcul elastice și scalarea verticală a serverelor individuale.

Deoarece a trebuit să rulăm 1,500 de procese pe zi cu o latență minimă și performanță ridicată, am ales să integrăm Amazon EMR în modul de implementare EC2 cu scalarea gestionată activată pentru a accepta procesarea dimensiunilor variabile ale fișierelor.

Configurația clusterului EMR oferă multe selecții diferite:

• Tipuri de noduri EMR – Noduri primare, de bază sau de activitate
• Opțiuni de cumpărare de exemplu – Instanțe la cerere, Instanțe rezervate sau Instanțe spot
• Opțiuni de configurare – Flotă de instanțe EMR sau grup uniform de instanțe
• Opțiuni de scalare - Scalare automată sau scalare gestionată Amazon EMR

Pe baza volumului nostru de lucru variabil, am configurat o flotă de instanțe EMR (pentru cele mai bune practici, consultați Încredere). De asemenea, am decis să folosim scalarea gestionată Amazon EMR pentru a scala nodurile de bază și de activitate (pentru scenariile de scalare, consultați Scenarii de alocare a nodurilor). În cele din urmă, am ales optimizarea memoriei AWS Graviton instanțe, care oferă până la Costuri mai mici cu 30% și performanță îmbunătățită cu până la 15% pentru sarcinile de lucru Spark.

Următorul cod oferă un instantaneu al configurației clusterului nostru:

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

Performanţă

Odată cu migrarea noastră la Amazon EMR, am reușit să obținem o performanță de sistem capabilă să gestioneze o varietate de seturi de date, variind de la 273 B până la 88.5 GB, cu un p99 de 491 de secunde (aproximativ 8 minute).

Figura următoare ilustrează varietatea de dimensiuni de fișiere procesate.

Figura următoare arată latența noastră.

Pentru a compara cu procesarea secvențială, am luat două seturi de date care conțineau 53 de milioane de înregistrări și am executat o operațiune VLOOKUP unul împotriva celuilalt, împreună cu alte 49 de operațiuni similare Excel. Procesarea a durat 26 de minute în noul serviciu, comparativ cu 5 zile pentru procesarea în serviciul moștenit. Această îmbunătățire este de aproape 300 de ori mai mare față de arhitectura anterioară în ceea ce privește performanța.

Considerații

Rețineți următoarele atunci când luați în considerare această soluție:

• Clustere de dimensiuni corecte – Deși Amazon EMR este redimensionabil, este important să dimensionați corect clusterele. Dimensiunea corectă atenuează un cluster lent, dacă este subdimensionat, sau costurile mai mari, dacă clusterul este supradimensionat. Pentru a anticipa aceste probleme, puteți calcula numărul și tipul de noduri care vor fi necesare pentru sarcinile de lucru.
• Pași paraleli – Executarea pașilor în paralel vă permite să rulați încărcături de lucru mai avansate, să creșteți utilizarea resurselor clusterului și să reduceți timpul necesar pentru finalizarea sarcinii de lucru. Numărul de pași permisi să ruleze simultan este configurabil și poate fi setat la lansarea unui cluster și în orice moment după ce clusterul a pornit. Trebuie să luați în considerare și să optimizați utilizarea CPU/memoriei per job atunci când mai multe joburi rulează într-un singur cluster partajat.
• Clustere EMR tranzitorii bazate pe locuri de muncă – Dacă este cazul, se recomandă utilizarea unui cluster EMR tranzitoriu bazat pe job, care oferă o izolare superioară, verificând dacă fiecare sarcină funcționează în mediul său dedicat. Această abordare optimizează utilizarea resurselor, ajută la prevenirea interferențelor între locuri de muncă și îmbunătățește performanța și fiabilitatea generală. Natura tranzitorie permite scalarea eficientă, oferind o soluție robustă și izolată pentru diverse nevoi de procesare a datelor.
• EMR fără server – EMR Serverless este alegerea ideală dacă preferați să nu vă ocupați de gestionarea și operarea clusterelor. Vă permite să rulați fără efort aplicații folosind cadre open-source disponibile în EMR Serverless, oferind o experiență simplă și fără probleme.
• Amazon EMR pe EKS – Amazon EMR pe EKS oferă avantaje distincte, cum ar fi timpi mai rapidi de pornire și scalabilitate îmbunătățită, rezolvând provocările legate de capacitatea de calcul, ceea ce este deosebit de benefic pentru utilizatorii Graviton și Spot Instance. Includerea unei game mai largi de tipuri de calcul îmbunătățește eficiența costurilor, permițând alocarea personalizată a resurselor. În plus, suportul Multi-AZ oferă o disponibilitate sporită. Aceste caracteristici convingătoare oferă o soluție robustă pentru gestionarea volumului de lucru de date mari, cu performanțe îmbunătățite, optimizare a costurilor și fiabilitate în diferite scenarii de calcul.

Concluzie

În această postare, am explicat modul în care Amazon și-a optimizat procesul de reconciliere financiară de volum mare cu Amazon EMR pentru scalabilitate și performanță mai ridicate. Dacă aveți o aplicație monolitică care depinde de scalarea verticală pentru a procesa solicitări sau seturi de date suplimentare, migrarea acesteia la un cadru de procesare distribuit, cum ar fi Apache Spark și alegerea unui serviciu gestionat, cum ar fi Amazon EMR pentru calcul, poate ajuta la reducerea timpului de execuție pentru a reduce livrarea. SLA și, de asemenea, poate ajuta la reducerea costului total de proprietate (TCO).

Pe măsură ce adoptăm Amazon EMR pentru acest caz particular de utilizare, vă încurajăm să explorați posibilități suplimentare în călătoria dvs. de inovare a datelor. Luați în considerare evaluarea AWS Glue, împreună cu alte opțiuni dinamice de implementare Amazon EMR, cum ar fi EMR Serverless sau Amazon EMR pe EKS, pentru a descoperi cel mai bun serviciu AWS adaptat cazului dvs. unic de utilizare. Viitorul călătoriei de inovare a datelor deține posibilități interesante și progrese care trebuie explorate în continuare.

Despre Autori

Jeeshan Khetrapal este inginer senior de dezvoltare software la Amazon, unde dezvoltă produse fintech bazate pe arhitecturi cloud computing fără server, care sunt responsabile pentru controalele generale IT ale companiilor, raportarea financiară și controlul pentru guvernanță, risc și conformitate.

Sakti Mishra este arhitect principal de soluții la AWS, unde îi ajută pe clienți să-și modernizeze arhitectura de date și să-și definească strategia de date end-to-end, inclusiv securitatea datelor, accesibilitatea, guvernanța și multe altele. El este și autorul cărții Simplificați Big Data Analytics cu Amazon EMR. În afara serviciului, lui Sakti îi place să învețe noi tehnologii, să vizioneze filme și să viziteze locuri cu familia.

• Distribuție de conținut bazat pe SEO și PR. Amplifică-te astăzi.
• PlatoData.Network Vertical Generative Ai. Împuterniciți-vă. Accesați Aici.
• PlatoAiStream. Web3 Intelligence. Cunoștințe amplificate. Accesați Aici.
• PlatoESG. carbon, CleanTech, Energie, Mediu inconjurator, Solar, Managementul deșeurilor. Accesați Aici.
• PlatoHealth. Biotehnologie și Inteligență pentru studii clinice. Accesați Aici.
• Sursa: https://aws.amazon.com/blogs/big-data/how-amazon-optimized-its-high-volume-financial-reconciliation-process-with-amazon-emr-for-higher-scalability-and-performance/