Per quanto percepita come tecnologia innovativa, è bene sottolineare che ormai l’elefantino Hadoop ha già compiuto 12 anni. Trattandosi di una soluzione complessa, nata per archiviare ed elaborare dati multi-formato, certamente non è stata adottata in modo così diffuso, anzi quando è stata introdotta in scenari inappropriati è stato controproducente. Nel 2017 Gartner ha infatti stimato che il 60% dei progetti Big Data (di cui verosimilmente gran parte basati su Hadoop) è stato fallimentare.
Sicuramente in tale circostanza l’investimento in termini di know-how, ma anche infrastrutturale per la gestione di un cluster, vanno ad aggravare la situazione.
La tecnologia alla base di Hadoop, infatti, comporta l’adozione di un cluster di macchine particolarmente efficiente su BareMetal anziché virtual machine.
Il principio di data locality su cui si fonda il processing in Hadoop comporta che lo storage e l’elaborazione insistano sugli stessi nodi del cluster per lavorare in modo ottimale senza traffico di dati in rete, sfruttando il fatto che i dati da elaborare devono risiedere nei nodi (data node) del cluster in cui vengono eseguiti i task computazionali. Inoltre un tipico cluster Hadoop deve essere per definizione composto da nodi con la stessa configurazione hardware per avere la garanzia di uniformità nelle prestazioni.
Queste caratteristiche hanno per lungo tempo dettato le regole del deployment, portando quasi a sconsigliarne l’adozione in Cloud, nonostante le potenzialità offerte in termini di fast provisioning e scalabilità.
Richiesta di elasticità
Molto appetibili sono in questo periodo tutte le tecnologie abilitanti architetture a microservizi e DevOps, quali le soluzioni per la containerizzazione come Docker e la loro orchestrazione (ad esempio Kubernetes), in quanto consentono di scalare elasticamente i processi su più istanze, che ben si prestano anche a meccanismi di continuos integration CI e deployment CD.
Analogamente nel mondo del Cloud Computing l’elasticità è la capacità automatizzata di scalare in modo trasparente le risorse IT, come richiesto in risposta alle condizioni di runtime o come predefinito dal Cloud Provider o dal consumer. L’elasticità è spesso considerata una giustificazione fondamentale per l’adozione del Cloud, principalmente in virtù del fatto che è strettamente associata al vantaggio di riduzione degli investimenti iniziali e alla garanzia di costi proporzionali.
Da quanto esposto fin qui forse si iniziano a intravedere dei percorsi comuni e uno scenario condiviso, a cui anche Hadoop sta avvicinandosi, supportando l’esecuzione dei containers YARN all’interno di Docker containers nel cluster, seppur questa tecnologia sia ancora in forma sperimentale.
Altra strada percorsa ormai dai diversi cloud provider è quella di garantire la fruibilità di Hadoop in modalità PaaS (Platform as a Service) grazie al disaccoppiamento dello storage dalla componente deputata all’elaborazione.
Come si può scardinare la data locality senza compromettere le performance di Hadoop?
I provider di servizi Cloud hanno aumentato la loro capacità di rete a 10 Gbps o più fino a raggiungere frequentemente i 40 Gbps. Grazie a questa rinnovata capacità di banda il traffico di dati in rete, che si verifica con la separazione dei layers di storage e processing in Hadoop, non è più un problema così insormontabile dal punto di vista delle prestazioni. Inoltre l’avvento di Object Stores a basso costo, come S3 di Amazon Web Services, Azure Blob Storage di Microsoft, IBM Cloud Object Storage o ancora Google Cloud Storage, per fare alcuni esempi, ha ulteriormente segnato il passo. Questi storage sono difatti compatibili con le API di HDFS (Hadoop Distributed File System) e consentono di abbassare ulteriormente i costi di infrastruttura.
Ma perché disaccoppiare? Qual è l’asso nella manica?
Questa tecnica ha un numero significativo di vantaggi in termini di flessibilità, scalabilità, manutenibilità ed economicità. In particolare è possibile ottimizzare l’infrastruttura in funzione dei carichi di lavoro per cui viene predisposta o per gestire dei picchi elaborativi. Mentre in un tradizionale cluster Hadoop On Premises il calcolo è strettamente legato all’archiviazione e se si ha l’esigenza di aumentare le risorse dedicate al calcolo, sarà comunque necessario aggiungere nodi dati (DataNode) che devono avere una componente di disco, anche se accrescere lo storage non è necessario per i volumi gestiti.
Viceversa se il cluster necessita di lavorare con dataset molto grandi, bisogna acquistare più DataNodes per memorizzare i dati. Ogni nodo dovrà includere costose risorse di RAM e CPU, anche se le esigenze di calcolo complessive del cluster sono già soddisfatte dai nodi esistenti. Questo in particolare si verifica per cluster che gestiscono petabyte di dati, che hanno spesso molti dati freddi (cold data), che non richiederebbero risorse computazionali per il loro trattamento.
Altra considerazione riguarda il tema trattato precedentemente, ossia l’elasticità: l’aggiunta e la rimozione di DataNodes in base alla domanda in tempo reale determinano un significativo lavoro di riequilibrio di HDFS per rintracciare tutte le informazioni relative alla nuova allocazione dei blocchi in cui sono suddivisi i file, sprecando a tal scopo le risorse elaborative utilizzabili.
Lo scenario descritto riguarda le soluzioni PaaS, da cui Hadoop trae maggior beneficio nei termini suddetti, ma esistono altri modelli di delivery in Cloud, di cui il più comune è quello IaaS (Infrastructure as a Service) laddove Hadoop è installato su VM gestite dal Cloud Provider. In questo scenario la scalabilità orizzontale ha comunque dei vantaggi, in quanto l’aggiunta di nodi al cluster è un’operazione che può essere effettuata in pochi click, mentre in termini di elasticità si può auspicare a un “graceful decommissioning”, quando si desidera diminuire il numero di nodi, operazione ben più onerosa della precedente, al contrario di quello che si potrebbe pensare.
Le differenze tra le varie soluzioni offerte dal Cloud sia esso pubblico, privato o ibrido, stanno influenzando anche le scelte evolutive dei sistemi Big Data, delle distribuzioni Hadoop (ad esempio Cloudera e Hortonworks hanno sviluppato dei moduli appositi per il provisioning dei cluster, la semplificazione della creazione e dell’esecuzione dei workloads in Cloud) e di Hadoop medesimo nelle sue componenti più caratterizzanti.
Monica Franceschini
