La riconciliazione dei conti è un passo importante per garantire la completezza e l’accuratezza dei rendiconti finanziari. Nello specifico, le aziende devono riconciliarsi bilancio conti che potrebbero contenere inesattezze significative o rilevanti. I contabili esaminano ciascun conto nella contabilità generale dei conti e verificano che il saldo elencato sia completo e accurato. Quando vengono rilevate discrepanze, i contabili indagano e adottano le azioni correttive appropriate.

Nell'ambito dell'organizzazione FinTech di Amazon, offriamo una piattaforma software che consente ai team contabili interni di Amazon di condurre riconciliazioni dei conti. Per ottimizzare il processo di riconciliazione, questi utenti richiedono una trasformazione ad alte prestazioni con la capacità di scalabilità su richiesta, nonché la capacità di elaborare dimensioni di file variabili che vanno da pochi MB a più di 100 GB. Non sempre è possibile inserire i dati in un'unica macchina o elaborarli con un unico programma in un arco di tempo ragionevole. Questo calcolo deve essere eseguito abbastanza velocemente da fornire servizi pratici in cui la logica di programmazione e i dettagli sottostanti (distribuzione dei dati, tolleranza agli errori e pianificazione) possono essere separati.

Possiamo ottenere questi calcoli simultanei su più macchine o thread della stessa funzione su gruppi di elementi di un set di dati utilizzando soluzioni di elaborazione dati distribuite. Ciò ci ha incoraggiato a reinventare il nostro servizio di riconciliazione basato sui servizi AWS, incluso Amazon EMR e la Apache Spark framework di elaborazione distribuita, che utilizza PySpark. Questo servizio consente agli utenti di elaborare file superiori a 100 GB contenenti fino a 100 milioni di transazioni in meno di 30 minuti. Il servizio di riconciliazione è diventato un punto di forza per l'elaborazione dei dati e ora gli utenti possono eseguire senza problemi una serie di operazioni, come ad esempio Perno, ISCRIVITI (come un'operazione CERCA.VERT di Excel), aritmetica operazioni, e Scopri di più, fornendo una soluzione versatile ed efficiente per riconciliare vasti set di dati. Questo miglioramento testimonia la scalabilità e la velocità raggiunte attraverso l'adozione di soluzioni di elaborazione dati distribuite.

In questo post spieghiamo come abbiamo integrato Amazon EMR per creare un sistema altamente disponibile e scalabile che ci abbia consentito di eseguire un processo di riconciliazione finanziaria ad alto volume.

Architettura prima della migrazione

Il diagramma seguente illustra la nostra architettura precedente.

Il nostro servizio legacy è stato creato con Servizio di container elastici Amazon (Amazon ECS) su AWS Fargate. Abbiamo elaborato i dati in sequenza utilizzando Python. Tuttavia, a causa della mancanza di capacità di elaborazione parallela, spesso dovevamo aumentare verticalmente le dimensioni del cluster per supportare set di dati più grandi. Per contestualizzare, l'elaborazione di 5 GB di dati con 50 operazioni ha richiesto circa 3 ore. Questo servizio è stato configurato per scalare orizzontalmente fino a cinque istanze ECS da cui viene eseguito il polling dei messaggi Servizio Amazon Simple Queue (Amazon SQS), che ha alimentato le richieste di trasformazione. Ogni istanza è stata configurata con 4 vCPU e 30 GB di memoria per consentire la scalabilità orizzontale. Tuttavia, non siamo riusciti ad espandere la sua capacità in termini di prestazioni perché il processo è avvenuto in sequenza, selezionando blocchi di dati da Servizio di archiviazione semplice Amazon (Amazon S3) per l'elaborazione. Ad esempio, un'operazione CERCA.VERT in cui due file devono essere uniti richiedeva che entrambi i file venissero letti in memoria pezzo per pezzo per ottenere l'output. Ciò è diventato un ostacolo per gli utenti perché hanno dovuto attendere lunghi periodi di tempo per elaborare i propri set di dati.

Nell'ambito della nostra riarchitettura e modernizzazione, volevamo ottenere quanto segue:

• Alta disponibilità – I cluster di elaborazione dati dovrebbero essere altamente disponibili, fornendo tre 9 di disponibilità (99.9%)
• Throughput – Il servizio dovrebbe gestire 1,500 corse al giorno
• Latenza – Dovrebbe essere in grado di elaborare 100 GB di dati entro 30 minuti
• Eterogeneità – Il cluster dovrebbe essere in grado di supportare un’ampia varietà di carichi di lavoro, con file che vanno da pochi MB a centinaia di GB
• Concorrenza delle query – L'implementazione richiede la capacità di supportare un minimo di 10 gradi di concorrenza
• Affidabilità dei lavori e coerenza dei dati – I lavori devono essere eseguiti in modo affidabile e coerente per evitare di infrangere gli accordi sul livello di servizio (SLA)
• Conveniente e scalabile – Deve essere scalabile in base al carico di lavoro, rendendolo conveniente
• Sicurezza e conformità – Data la sensibilità dei dati, è necessario che supportino un controllo capillare degli accessi e implementazioni di sicurezza adeguate
• Controllo – La soluzione deve offrire un monitoraggio end-to-end dei cluster e dei lavori

Perché Amazon EMR

Amazon EMR è la soluzione per big data nel cloud leader del settore per l'elaborazione dei dati su scala petabyte, l'analisi interattiva e l'apprendimento automatico (ML) utilizzando framework open source come Apache Spark, Alveare di Apachee Presto. Con questi framework e i relativi progetti open source, puoi elaborare i dati per scopi di analisi e carichi di lavoro BI. Amazon EMR ti consente di trasformare e spostare grandi quantità di dati dentro e fuori altri datastore e database AWS, come Amazon S3 e Amazon DynamoDB.

Un notevole vantaggio di Amazon EMR risiede nell'uso efficace dell'elaborazione parallela con PySpark, che segna un miglioramento significativo rispetto al tradizionale codice Python sequenziale. Questo approccio innovativo semplifica l'implementazione e la scalabilità dei cluster Apache Spark, consentendo una parallelizzazione efficiente su set di dati di grandi dimensioni. L'infrastruttura informatica distribuita non solo migliora le prestazioni, ma consente anche l'elaborazione di grandi quantità di dati a velocità senza precedenti. Dotato di librerie, PySpark facilita le operazioni simili a Excel su DataFramee l'astrazione di livello superiore dei DataFrames semplifica le complesse manipolazioni dei dati, riducendo la complessità del codice. In combinazione con il provisioning automatico dei cluster, l'allocazione dinamica delle risorse e l'integrazione con altri servizi AWS, Amazon EMR si rivela una soluzione versatile adatta a carichi di lavoro diversi, dall'elaborazione batch al machine learning. La tolleranza agli errori intrinseca di PySpark e Amazon EMR promuove la robustezza, anche in caso di guasti dei nodi, rendendolo una scelta scalabile, conveniente e ad alte prestazioni per l'elaborazione parallela dei dati su AWS.

Amazon EMR estende le sue capacità oltre le nozioni di base, offrendo una varietà di opzioni di distribuzione per soddisfare esigenze diverse. Che si tratti di Amazon EMR su EC2, Amazon EMR su EKS, Amazon EMR senza server, o Amazon EMR su AWS Outposts, puoi adattare il tuo approccio a requisiti specifici. Per coloro che cercano un ambiente serverless per i lavori Spark, in integrazione Colla AWS è anche un'opzione praticabile. Oltre a supportare vari framework open source, incluso Spark, Amazon EMR offre flessibilità nella scelta delle modalità di distribuzione, Cloud di calcolo elastico di Amazon (Amazon EC2), meccanismi di scalabilità e numerose tecniche di ottimizzazione per il risparmio dei costi.

Amazon EMR rappresenta una forza dinamica nel cloud, offrendo funzionalità ineguagliabili per le organizzazioni che cercano solide soluzioni per Big Data. La sua perfetta integrazione, le potenti funzionalità e l'adattabilità lo rendono uno strumento indispensabile per affrontare le complessità dell'analisi dei dati e del ML su AWS.

Architettura ridisegnata

Il diagramma seguente illustra la nostra architettura riprogettata.

La soluzione opera nell'ambito di un contratto API, in cui i clienti possono inviare configurazioni di trasformazione, definendo l'insieme di operazioni insieme alla posizione del set di dati S3 per l'elaborazione. La richiesta viene accodata tramite Amazon SQS, quindi indirizzata a Amazon EMR tramite una funzione Lambda. Questo processo avvia la creazione di una fase Amazon EMR per l'implementazione del framework Spark su un cluster EMR dedicato. Sebbene Amazon EMR consenta un numero illimitato di passaggi nel corso della durata di un cluster di lunga durata, solo 256 passaggi possono essere in esecuzione o in sospeso contemporaneamente. Per una parallelizzazione ottimale, la concorrenza dei passaggi è impostata su 10, consentendo l'esecuzione simultanea di 10 passaggi. In caso di richieste non riuscite, Amazon SQS coda di lettere non recapitabili (DLQ) conserva l'evento. Spark elabora la richiesta, traducendo operazioni simili a quelle di Excel in codice PySpark per un piano di query efficiente. I dataframe resilienti archiviano input, output e dati intermedi in memoria, ottimizzando la velocità di elaborazione, riducendo i costi di I/O del disco, migliorando le prestazioni del carico di lavoro e distribuendo l'output finale nella posizione Amazon S3 specificata.

Definiamo il nostro SLA in due dimensioni: latenza e throughput. La latenza è definita come la quantità di tempo necessaria per eseguire un lavoro rispetto a una dimensione deterministica del set di dati e al numero di operazioni eseguite sul set di dati. Il throughput è definito come il numero massimo di lavori simultanei che il servizio può eseguire senza violare lo SLA di latenza di un lavoro. Lo SLA di scalabilità complessiva del servizio dipende dall'equilibrio tra la scalabilità orizzontale delle risorse di calcolo elastiche e la scalabilità verticale dei singoli server.

Poiché dovevamo eseguire 1,500 processi al giorno con latenza minima e prestazioni elevate, abbiamo scelto di integrare Amazon EMR in modalità di distribuzione EC2 con dimensionamento gestito abilitato per supportare l'elaborazione di file di dimensioni variabili.

La configurazione del cluster EMR offre molte selezioni diverse:

• Tipi di nodi EMR – Nodi primari, fondamentali o di attività
• Opzioni di acquisto delle istanze – Istanze on demand, Istanze riservate o Istanze Spot
• Opzioni di configurazione – Parco istanze EMR o gruppo di istanze uniforme
• Opzioni di ridimensionamento - Ridimensionamento automatico o scalabilità gestita da Amazon EMR

In base al nostro carico di lavoro variabile, abbiamo configurato un parco istanze EMR (per le best practice, consulta Affidabilità). Abbiamo inoltre deciso di utilizzare la scalabilità gestita di Amazon EMR per scalare i nodi principali e delle attività (per gli scenari di scalabilità, fare riferimento a Scenari di allocazione dei nodi). Infine, abbiamo scelto l'ottimizzazione della memoria Gravitone AWS istanze, che forniscono fino a Costi ridotti del 30% e prestazioni migliorate fino al 15% per i carichi di lavoro Spark.

Il codice seguente fornisce un'istantanea della configurazione del nostro 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

Prestazione

Con la migrazione ad Amazon EMR, siamo stati in grado di ottenere prestazioni di sistema in grado di gestire una varietà di set di dati, da un minimo di 273 B a un massimo di 88.5 GB con un p99 di 491 secondi (circa 8 minuti).

La figura seguente illustra la varietà di dimensioni dei file elaborati.

La figura seguente mostra la nostra latenza.

Per fare un confronto con l'elaborazione sequenziale, abbiamo preso due set di dati contenenti 53 milioni di record e abbiamo eseguito un'operazione CERCA.VERT l'uno contro l'altro, insieme ad altre 49 operazioni simili a Excel. L'elaborazione nel nuovo servizio ha richiesto 26 minuti, rispetto ai 5 giorni del servizio legacy. Questo miglioramento è quasi 300 volte maggiore rispetto all'architettura precedente in termini di prestazioni.

Considerazioni

Tieni presente quanto segue quando consideri questa soluzione:

• Cluster di giusta dimensione – Sebbene Amazon EMR sia ridimensionabile, è importante dimensionare correttamente i cluster. Il corretto dimensionamento mitiga un cluster lento, se sottodimensionato, o costi più elevati, se il cluster è sovradimensionato. Per anticipare questi problemi, puoi calcolare il numero e il tipo di nodi che saranno necessari per i carichi di lavoro.
• Passi paralleli – L'esecuzione di passaggi in parallelo consente di eseguire carichi di lavoro più avanzati, aumentare l'utilizzo delle risorse del cluster e ridurre la quantità di tempo necessaria per completare il carico di lavoro. Il numero di passaggi consentiti per l'esecuzione simultanea è configurabile e può essere impostato all'avvio di un cluster e in qualsiasi momento dopo l'avvio del cluster. È necessario considerare e ottimizzare l'utilizzo di CPU/memoria per lavoro quando più lavori sono in esecuzione in un singolo cluster condiviso.
• Cluster EMR temporanei basati sul lavoro – Se applicabile, si consiglia di utilizzare un cluster EMR transitorio basato sul lavoro, che offre un isolamento superiore, verificando che ciascuna attività operi all'interno del proprio ambiente dedicato. Questo approccio ottimizza l'utilizzo delle risorse, aiuta a prevenire le interferenze tra i lavori e migliora le prestazioni e l'affidabilità complessive. La natura transitoria consente una scalabilità efficiente, fornendo una soluzione solida e isolata per diverse esigenze di elaborazione dei dati.
• EMR senza server – EMR Serverless è la scelta ideale se preferisci non occuparti della gestione e del funzionamento dei cluster. Ti consente di eseguire facilmente applicazioni utilizzando framework open source disponibili all'interno di EMR Serverless, offrendo un'esperienza semplice e senza problemi.
• Amazon EMR su EKS – Amazon EMR su EKS offre vantaggi distinti, come tempi di avvio più rapidi e una migliore scalabilità per risolvere i problemi di capacità di elaborazione, il che è particolarmente vantaggioso per gli utenti di Graviton e Spot Instance. L’inclusione di una gamma più ampia di tipi di elaborazione migliora l’efficienza in termini di costi, consentendo un’allocazione delle risorse su misura. Inoltre, il supporto Multi-AZ garantisce una maggiore disponibilità. Queste interessanti funzionalità forniscono una soluzione solida per la gestione dei carichi di lavoro dei big data con prestazioni migliorate, ottimizzazione dei costi e affidabilità in vari scenari informatici.

Conclusione

In questo post, abbiamo spiegato come Amazon ha ottimizzato il suo processo di riconciliazione finanziaria per volumi elevati con Amazon EMR per ottenere scalabilità e prestazioni più elevate. Se disponi di un'applicazione monolitica che dipende dalla scalabilità verticale per elaborare richieste o set di dati aggiuntivi, la migrazione a un framework di elaborazione distribuito come Apache Spark e la scelta di un servizio gestito come Amazon EMR per l'elaborazione può aiutare a ridurre il tempo di esecuzione per abbassare la consegna SLA e può anche contribuire a ridurre il costo totale di proprietà (TCO).

Mentre adottiamo Amazon EMR per questo particolare caso d'uso, ti invitiamo a esplorare ulteriori possibilità nel tuo percorso di innovazione dei dati. Valuta la possibilità di valutare AWS Glue, insieme ad altre opzioni di distribuzione dinamica di Amazon EMR come EMR Serverless o Amazon EMR su EKS, per scoprire il miglior servizio AWS su misura per il tuo caso d'uso specifico. Il futuro del percorso di innovazione dei dati riserva interessanti possibilità e progressi da esplorare ulteriormente.

Informazioni sugli autori

Jeeshan Khetrapal è un ingegnere di sviluppo software senior presso Amazon, dove sviluppa prodotti fintech basati su architetture serverless di cloud computing che sono responsabili dei controlli generali IT delle aziende, della rendicontazione finanziaria e della controllership per governance, rischio e conformità.

Shakti Mishra è Principal Solutions Architect presso AWS, dove aiuta i clienti a modernizzare l'architettura dei dati e a definire la strategia dei dati end-to-end, inclusa la sicurezza dei dati, l'accessibilità, la governance e altro ancora. È anche l'autore del libro Semplifica l'analisi dei big data con Amazon EMR. Al di fuori del lavoro, a Sakti piace imparare nuove tecnologie, guardare film e visitare luoghi con la famiglia.

• Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
• PlatoData.Network Generativo verticale Ai. Potenzia te stesso. Accedi qui.
• PlatoAiStream. Intelligenza Web3. Conoscenza amplificata. Accedi qui.
• PlatoneESG. Carbonio, Tecnologia pulita, Energia, Ambiente, Solare, Gestione dei rifiuti. Accedi qui.
• Platone Salute. Intelligence sulle biotecnologie e sulle sperimentazioni cliniche. Accedi qui.
• Fonte: https://aws.amazon.com/blogs/big-data/how-amazon-optimized-its-high-volume-financial-reconciliation-process-with-amazon-emr-for-higher-scalability-and-performance/