Limitazioni di AWS Glue per l’elaborazione dati real-time

In un contesto di governance dei dati in rapido mutamento, la capacità di elaborare informazioni in modo tempestivo ed efficiente è cruciale per il successo aziendale. Spesso le organizzazioni si trovano a fronteggiare sfide legate alla rigidità e ai costi imprevedibili dei processi di elaborazione batch, che possono generare frustrazioni e inefficienze. 

Segnali quali la necessità di interventi manuali per gestire flussi di dati non programmati o ritardi nell'aggiornamento delle informazioni sono chiari indicatori di un problema latente.

Dal punto di vista del FinOps, questi problemi non sono solo problemi tecnici, ma rappresentano sprechi di risorse cloud e una scarsa visibilità sui costi operativi. Ogni esecuzione manuale e ogni ora di ritardo hanno un impatto finanziario diretto che deve essere misurato e gestito.

In questo articolo esploriamo insieme una sfida comune nell'ingestione e trasformazione dei dati, mostrando una soluzione agile e scalabile che trasforma la reattività operativa, riducendo i costi e migliorando l'efficienza.

Il Contesto

In molti contesti aziendali moderni, la gestione e l'analisi di grandi volumi di dati rappresentano una sfida cruciale. Spesso, questi dati provengono da sistemi legacy consolidati, come i flussi di elaborazione basati su SAS, un potente software per l'analisi statistica e la gestione dei dati. Per superare i limiti di scalabilità e flessibilità di questi sistemi, le aziende adottano sempre più architetture di data warehousing e analytics basate su cloud. Un esempio sono le soluzioni che sfruttano i servizi di Amazon Web Services (AWS) per modernizzare l'elaborazione di dati provenienti da sistemi SAS: il punto di partenza del processo è il deposito dei dati grezzi in un data lake basato su Amazon Simple Storage Service (S3), servizio di object storage altamente scalabile, durevole e sicuro. S3 memorizza i dati come oggetti all'interno di bucket, contenitori globalmente unici in cui è possibile archiviare quantità praticamente illimitate di dati.

Nel caso descritto, i file di testo (con estensione .txt) generati dai processi SAS vengono caricati periodicamente (ad esempio, mensilmente) in un bucket S3 dedicato. Questi file, che rappresentano tabelle di dati, vengono poi elaborati da specifici job AWS Glue, servizio di ETL (Extract, Transform, Load) completamente gestito. I job di Glue leggono il file, applicano trasformazioni (pulizia dei dati, arricchimento, normalizzazione, selezione di colonne specifiche) e salvano i dati in formato Parquet compresso con algoritmo Snappy in un'apposita cartella nel bucket S3. Un workflow orchestrato si occupa di avviare tutti questi job in un giorno specifico, dopo il termine del caricamento di tutti i file .txt provenienti da SAS. 
 

Il Problema

La configurazione attuale descritta, sebbene funzionale per l'elaborazione mensile programmata, presenta significative limitazioni quando i file .txt vengono caricati in S3 in giorni diversi da quelli previsti. In questi scenari, l'esecuzione manuale dei soli job AWS Glue interessati diventa un processo oneroso e impegnativo. Le caratteristiche specifiche di questo problema sono qui elencate.

• Rigidità temporale - Il workflow è vincolato a una finestra temporale specifica, rendendo difficile la gestione di eventi asincroni.
• Intervento manuale - Ogni volta che un file arriva fuori programma, è richiesto un intervento umano per identificare e avviare i job Glue pertinenti. Questo aumenta il rischio di errori e l'onere operativo.
• Inefficienza operativa - La necessità di far partire manualmente solo i job coinvolti per ogni caricamento fuori programma si traduce in un dispendio di tempo e risorse, rallentando l'aggiornamento dei dati e potenzialmente impattando la disponibilità di informazioni cruciali per il business.
• Costi nascosti - Il tempo impiegato dal team per la gestione manuale si traduce in costi operativi aggiuntivi e distoglie le risorse da attività a maggior valore.

Gli Obiettivi

Per superare le problematiche descritte, gli obiettivi da raggiungere sono chiari e mirano a una maggiore automazione e tempestività nelle operazioni. Eccoli in dettaglio.

• Automazione completa - Eliminare la necessità di interventi manuali per l'avvio dei processi di trasformazione dati.
• Elaborazione real-time: Consentire l'elaborazione immediata dei file non appena vengono depositati in S3, indipendentemente dalla data di caricamento.
• Efficienza operativa - Ottimizzare l'utilizzo delle risorse e ridurre il tempo di attesa per la disponibilità dei dati trasformati.
• Scalabilità - Garantire che la soluzione possa gestire un numero crescente di file e tabelle senza un proporzionale aumento della complessità gestionale.
• Ottimizzazione costi/performance - Scegliere lo strumento più adatto (Lambda o Glue) in base alle caratteristiche specifiche di ogni file e trasformazione.

La Soluzione

La strategia più opportuna per raggiungere questi obiettivi consiste nell'adottare un modello event-driven e serverless che, in modo intelligente, sa scegliere lo strumento più adatto per ogni tipo di elaborazione: AWS Lambda (servizio di calcolo serverless che consente di eseguire codice senza l’onere della gestione dell’infrastruttura sottostante) per i carichi leggeri e il già citato AWS Glue per quelli più complessi. Questo approccio ibrido offre massima flessibilità, automazione, scalabilità e un'ottimizzazione senza precedenti dei costi e delle performance.

La soluzione proposta al problema sin qui esposto si articola come segue.

1. Trigger S3. Viene configurato un trigger S3 che, non appena un nuovo file .txt viene depositato nel bucket di input, avvia automaticamente una prima funzione AWS Lambda. Questo elimina completamente la necessità di monitoraggio manuale o di workflow schedulati per i file ad-hoc.
2. Lambda Orchestrator. Questa prima Lambda, definita orchestrator, riceve come input l'evento S3, che include il percorso (path) del file .txt appena caricato. Il suo ruolo è quello di analizzare il path del file per estrarre informazioni cruciali, come il nome della tabella corrispondente, la dimensione del file e potenzialmente la complessità delle trasformazioni richieste per quella tabella.
3. Logica di Routing Intelligente. Basandosi sulla dimensione del file e/o la complessità delle trasformazioni determinate, la Lambda Orchestrator decide dinamicamente quale strumento utilizzare per l'elaborazione:
   • Per file poco pesanti e trasformazioni semplici. La Lambda Orchestrator invoca una seconda funzione AWS Lambda, la worker. Questa Lambda worker è progettata per essere generica e riutilizzabile. In base ai parametri di input ricevuti dall'Orchestrator (nome della tabella, path del file, ecc.), applica le trasformazioni specifiche alle colonne di quella determinata tabella. Infine, scrive i file Parquet compressi con algoritmo Snappy nella cartella S3 di destinazione appropriata. Per la maggior parte dei casi (ad esempio, per  30 su 35 file), questo approccio garantisce costi minimi e latenza quasi zero.
   • Per file più pesanti o trasformazioni complesse. La Lambda Orchestrator invoca un job AWS Glue esistente o ne avvia uno nuovo. Questi job Glue, pur mantenendo la loro logica specifica per le trasformazioni più onerose, possono essere parametrizzati per elaborare il singolo file appena arrivato. Per i file che richiedono la potenza di calcolo distribuito di Spark, questo approccio garantisce che la complessità sia gestita efficacemente, pur mantenendo l'automazione in tempo reale.

Il Compromesso Ottimale

L'adozione di un'architettura ibrida, dove un'unica Lambda orchestratrice indirizza i carichi di lavoro verso Lambda worker o job Glue a seconda delle esigenze, rappresenta un compromesso eccellente. Questo approccio permette di ottenere alcuni importanti risultati.

• Massimizzare l'efficienza dei costi. Utilizzando Lambda per la maggior parte dei carichi di lavoro leggeri e irregolari, si riducono drasticamente i costi operativi associati ai cold start e alla fatturazione minima dei job Glue. Si paga solo per ciò che si usa per i file più comuni.
• Garantire le performance. Le Lambda offrono una latenza quasi istantanea per i file che possono essere gestiti in modo leggero, mentre i job Glue, pur con la loro latenza di avvio, assicurano la potenza necessaria per le trasformazioni più esigenti.
• Mantenere la flessibilità. L'architettura è adattabile e può evolvere. Se la complessità delle trasformazioni o la dimensione dei file cambiano, la logica della Lambda orchestrator può essere facilmente aggiornata per re-indirizzare il traffico.
• Ridurre la complessità di gestione. Un unico punto di ingresso (la Lambda orchestrator) gestisce il routing, semplificando la visione d'insieme del processo, pur delegando la vera elaborazione agli strumenti più idonei. Per i file leggeri (circa l’80%) un'unica Lambda worker generica riduce notevolmente il numero di job da mantenere rispetto a un job Glue per ogni tabella.

 

Confronto Architetture ETL

Analisi comparativa tra l'approccio iniziale, un'alternativa con Lambda e la soluzione ibrida proposta per ottimizzare costi e performance.

Aspetto	AWS Glue (Approccio Iniziale)	AWS Lambda	Soluzione Ibrida (Proposta)
Trigger	Workflow schedulato (mensile)	Event-driven (S3 trigger)	Event-driven (S3 trigger)
Esecuzione	Batch, programmata	Real-time, on-demand	Real-time, ottimizzata
Flessibilità	Bassa per eventi asincroni	Alta per eventi asincroni	Molto alta, adattiva
Intervento manuale	Elevato per fuori programma	Minimo/Nullo	Minimo/Nullo
Scalabilità	Richiede configurazione	Automatica, serverless	Automatica, intelligente
Costi	Basati su istanze e tempo di esecuzione	Basati su esecuzioni/GB-secondi	Ottimizzati (Glue per file pesanti, Lambda per file leggeri)

 

I Risultati

L'implementazione di questa soluzione ibrida basata su AWS Lambda e AWS Glue consente di raggiungere pienamente gli obiettivi prefissati, trasformando radicalmente il processo di elaborazione dati.

• Riduzione dell'intervento manuale. L'automazione end-to-end elimina la necessità di monitorare e avviare manualmente i job, liberando risorse del team IT per attività più strategiche.
• Elaborazione real-time mirata. I dati vengono trasformati e resi disponibili quasi istantaneamente dopo il loro caricamento in S3, con la garanzia che ogni file sia gestito dallo strumento più appropriato per performance e costi.
• Maggiore efficienza operativa. Il processo diventa più snello e meno propenso a errori umani, garantendo una maggiore affidabilità e consistenza, gestendo in modo efficiente la diversità dei carichi di lavoro.
• Ottimizzazione dei costi. Il modello di pricing "pay-per-use" di AWS Lambda per la maggior parte dei file e l'uso mirato di AWS Glue per i carichi più pesanti assicura che si paghi solo per l'effettivo utilizzo delle risorse, portando a un significativo risparmio sui costi operativi.
   

Le Raccomandazioni Conclusive

La transizione da un modello di elaborazione dati rigido e basato su scheduling a un'architettura ibrida e intelligente con AWS Lambda e AWS Glue rappresenta un passo fondamentale verso una maggiore agilità ed efficienza operativa. Questo articolo dimostra come l'adozione di soluzioni serverless possa risolvere problematiche comuni legate alla gestione dei dati, garantendo processi più fluidi, costi ottimizzati e una maggiore reattività alle esigenze di business. La capacità di combinare strategicamente i punti di forza di diversi servizi AWS è la chiave per architetture cloud veramente resilienti ed economiche.
Miriade è il partner tecnologico ideale per supportare le aziende in questa e altre sfide di trasformazione digitale. Con una profonda esperienza nell'architettura cloud e nelle soluzioni serverless, Miriade può guidarti nell'implementazione di sistemi robusti e scalabili che massimizzano il valore dei tuoi dati.