Ho già scritto di hadoop 1.0 (mapreduce) e del principio base su cui funziona. Ora però è uscito Hadoop 2.0 e cambia tutto.
Hadoop 2.0 è una riscrittura completa della piattaforma Hadoop 1.0 (è retrocompatibile con i job map-reduce scritti per Hadoop 1.0). L’evoluzione la renderla un po’ meno “map-reduce” e un po’ più vera piattaforma distribuita di gestione informazioni di tipo “big data” compatibile con qualsiasi tipo di applicazione di data management.
L’architettura è più complessa, permette maggiori gradi di libertà e un maggior controllo delle risorse disponibili sul cluster, insomma le cose iniziano a farsi più serie: Hadoop 2.0 è un vero sistema di distributed computing.
Se con Hadoop 1.0 si è lanciato il seme dei nuovi datawarehouse, con Hadoop 2.0 si va in produzione!
L’ambiente di cluster management e gestione delle applicazioni, che in Hadoop 1.0 non aveva un nome (anche perchè c’era solo map-reduce), in Hadoop 2.0 si chiama YARN.
In sostanza quello che cambia è:
- HDFS è sostituito con HDFS2 che introduce funzionalità evolute da file system distribuito come la possibilità di fare snapshot, di federare tra loro più cluster HDFS e di mettere in alta affidabilità il NameNode (noto single point of failure del sistema)
- A differenza di Hadoop 1.0 dove si partiva dal concetto di “job map-reduce”, in YARN si parla di “applicazioni”. Una applicazione YARN è qualsiasi tipo di applicazione che possa sfruttare un sistema distribuito o parallelo. Map-reduce è una di queste possibili applicazioni, ma non l’unica. Quindi YARN implementa ANCHE map-reduce, ma lascia allo sviluppatore la libertà di scriversi qualsiasi tipo di applicazione distribuita. Un bel cambiamento!
L’architettura fisica è sempre a due livelli:
- Il resource manager (il master del sistema distribuito) che contiene a sua volta uno Scheduler e un Application manager. L’application manager è il componente che negozia con i Node manager le risorse per lanciare le applicazioni sui nodi del cluster
- Il node manager (in esecuzione su ogni nodo di calcolo del cluster escluso il resource manager) gestisce le risorse locali del nodo e crea dei “container” (delle sandbox in pratica) dove vengono fatte girare le applicazioni
Notare la differenza di denominazione rispetto a Hadoop 1.0, dove si parlava di Mapper e Reducer. In questo caso non c’è un ruolo specifico: un nodo di calcolo è un nodo di calcolo.
Dato che YARN è un puro e semplice ambiente di esecuzione per applicazioni distribuite, ogni applicazione deve essere auto contenuta, cioè deve essere in grado di lanciare le varie copie dei job in parallelo, ricevere i risultati delle sotto-elaborazioni, combinarli e restituirli al client. YARN non si occuperà di cosa faccia l’applicazione, ma solo di assegnargli le risorse sui nodi del cluster.
Le applicazioni sul cluster YARN hanno la seguente struttura di funzionamento:
- L’utente scrive la sua applicazione che prende il nome di “Application Master” e tramite il client YARN richiede al resource manager la possibilità di installare l’application master sul cluster
- Il resource manager richiede a un nodo del cluster la creazione di un container per eseguire l’application master. Il container è una sandbox con un determinato ammontare di risorse RAM e CPU, che limitano l’utilizzo da parte dell’applicazione per evitare di bloccare il nodo.
- L’application master viene quindi mandato in esecuzione sul container ottenuto (con ID 0)
- Una volta in esecuzione, il master si moltiplica, richiedendo a sua volta al resource manager (tramite le apposite API di YARN) altri container su altri nodi su cui lanciare le varie copie dell’applicazione distribuita.
- Ogni replica dell’applicazione viene lanciata quindi in un container e comunica con l’Application Master secondo quanto definito nel codice.
- L’application master a sua volta manda segnali di heartbeat al resource manager per indicare di essere ancora vivo e funzionante.
- Il resource manager si occupa di gestire le richieste di container da parte dei vari application master in esecuzione sul cluster. L’allocazione è dinamica (tramite lo scheduler), cioè ogni application master si troverà ad avere a disposizione più o meno container a seconda di quanto il cluster ha a disposizione.
- Il client a questo punto comunica direttamente con il suo Application master per avere i risultati dell’esecuzione dell’applicazione (di nuovo a seconda di come è scritto il codice, YARN non interviene su queste comunicazioni)
Un meccanismo a mio parere molto elegante e che apre la strada a una immensa quantità di nuove applicazioni di elaborazione dei dati.
Un esempio di una applicazione YARN è proprio MapReduce. In questo caso l’Application Master è il JobTracker mentre le varie repliche lanciate sui vari container sono i vari TaskTracker (mapper o reducer).
MapReduce è un Application Master già disponibile in YARN, in modo da mantenere un minimo di retro-compatibilità con Hadoop 1.0 (la retro compatibilità non è però garantita).
Detto fra noi, Hadoop 1.0, a parte nei soliti noti Yahoo/Facebook/Spotify/etc, non è che abbia un installato esattamente enorme. Quindi alle aziende che pensano di adottare un cluster Hadoop al posto dei vecchi datawarehouse, suggerirei di partire già da Hadoop 2.0 e fregarsene della retro compatibilità, cercando di capire bene quali applicazioni di analisi o gestione dei dati possano beneficiare di una esecuzione distribuita. Ripeto: il valore di YARN è la flessibilità di poter eseguire qualsiasi tipo di applicazione distribuita, non solo map-reduce.
Un’altra famosa applicazione YARN che vale la pena di citare è il misterioso Apache Spark, un sistema di in-memory computing distribuito che dà prestazioni di elaborazione 100 volte superiori a Map-Reduce, tant’è che la stessa Google ha ammesso che ormai sui suoi cluster utilizza quasi solo questa tecnologia rispetto al vecchio MapReduce. Ne parlo in un altro articolo, se lo merita tutto.