Gestendo dataset di grandi dimensioni abbiamo due alternative da valutare: Scaling up e Scaling out.
Il nostro obiettivo è fare chiarezza a riguardo.
Prima però, un aggiornamento.
Nell’ultimo periodo, complice un’annosa pandemia, il nostro buon spirito marinaresco è andato scemando.
La bussola pare smarrita e la fioca luce delle stelle da cui un tempo traevamo preziose indicazioni fatica a trapassare il burrascoso cielo.
Non possiamo demordere.
Il detto è chiaro: un buon marinaio si conosce nelle tempeste.
Allora, ricordando a noi stessi il motivo della partenza, procediamo.
Senza indugio e timore, issiamo le vele; timone a dritta: la meta ci aspetta.
Oggi io e te, affrontiamo insieme le acque di un gelido mare.
Il mare d’insidie nascosto nella gestione di un dataset di grandi dimensioni.
Siamo bravi a romanzare.
Dataset Size: Scale Up or Scale Out
Parlando di cose serie, la gestione di dataset dalle piccole dimensioni è particolarmente facile.
Il più delle volte è sufficiente scaricare il file, un comma-separated values (CSV), importarlo nel nostro accogliente Jupyter Notebook e iniziare il processo di Exploratory Data Analysis.
Il mondo reale, lontano dal terreno battuto di Kaggle, è un tantino più complesso.
Quando le dimensioni sono significative, già nell’ordine dei GB, la complessità computazionale si palesa: persino una semplice operazione d’importazione inizia a richiedere diversi secondi.
I limiti della nostra macchina emergono e con essi un dilemma: scaling up o scaling out ?
In altri termini, intendiamo superare i limiti di memoria o di calcolo (RAM Bound vs CPU Bound).
Quali sono dunque, le reali alterative?
Scaling Up
La prima opzione per gestire dataset di grandi dimensioni e calcoli complessi è il ricorso a una macchina dalla potenza superiore: incrementiamo allora il numero di CPU, la memoria RAM e lo spazio di archiviazione.
Questo processo è definito di Scaling Up.
Preparati ad alzare i limiti della carta di credito.
Lo svantaggio primario di questo approccio è il costo: le macchine ad alte prestazioni hanno un preziario poco economico.
Aggiungiamo poi l’inutilità di avere una o più istanze attive 24 ore al giorno, poiché sarebbero perlopiù in IDLE, e anche la gestione dell’archiviazione si fa problematica.
L’idea per minimizzare i costi e massimizzare l’efficienza è sfruttare dei persistent storage collegati alle computer instance attive solo quando necessario.
Scaling Out
La soluzione precedente pare ragionevole per lavori (job) eseguibili su una singola macchina.
Qualora questi dovessero raggiungere i limiti fisici del sistema, occorrerebbe invece individuare una differente soluzione.
Possiamo allora decidere di configurare un job affinché sia scomposto in parti eseguite su altrettante macchine, in un processo definito di scaling out.
Un metodo di scaling out prevede la frammentazione dei dati e il loro salvataggio sulle memorie d’istanze multiple.
Ogni istanza può così compiere analisi su piccoli batch dati ad alta velocità: sono le operazioni definite map (map operation).
Il risultato delle operazioni compiute sui singoli pezzi (chunks) di dati può essere combinato, dopo opportune regole di confronto, su un diverso gruppo di nodi: sono le operazioni definite reduce (reduce operation).
Questo modello a due fasi successive è definito MapReduce e la sua logica è fondamentale in tutti quei sistemi per il calcolo distribuito e parallelo su diversi cluster in modo affidabile e tollerante i guasti.
Per approfondire questo concetto e comprendere come eseguire lavori di Data Science sulla Google Cloud Platform, ti esorto ad acquistare questo libro:
Per il momento è tutto.
Un caldo abbraccio, Andrea.
