Architettura Hadoop

Abbiamo visto che l’incremento del volume dei dati che possono essere generati in numerose applicazioni richiede un cambio radicale nel paradigma di gestione ed elaborazione dei dati. Fino agli inizi degli anni 2000, le applicazioni software assumevano che i dati risiedessero su memoria secondaria, e nel corso della elaborazione delle applicazioni fossero trasferiti dalla memoria secondaria ai nodi di elaborazione.

A causa dei volumi e della latenza della rete Internet, dove sono sempre più spesso eseguite applicazioni software, questo paradigma non è più funzionale alle nuove esigenze elaborative; di conseguenza, è stato sviluppato da Google, una delle aziende che tra le prime hanno sperimentato le criticità derivanti dal volume dei dati da gestire, una modalità di elaborazione dati completamente diversa.

La nuova modalità di elaborazione distribuita prevede non più il trasferimento dei dati verso i nodi di elaborazione, ma il viceversa, lo spostamento della capacità computazionale verso le risorse dove sono memorizzati i dati, ribaltando così il precedente paradigma. Per ottenere questo risultato sono disponibili almeno tre componenti architetturali:

- un file system, cioè un sistema di gestione dei file (o dataset) di dati in grado di distribuire i dati su più nodi di elaborazione.

- un motore di calcolo in grado di distribuire le elaborazioni fra nodi diversi. - un sistema di gestione dell’intera infrastruttura.

Questi componenti architettural costituiscono la base della piattaforma Hadoop3, sviluppata originariamente da Google e poi rilasciata in formato open source alla comunità di sviluppatori. I tre componenti sopra menzionati sono rispettivamente chiamati, Hadoop Distributed File System (HDFS), Map-Reduce e YARN.

3 Il nome è stato scelto da Doug Cutting responsabile del progetto di sviluppo usando il nome dell'elefante giallo di pezza di suo figlio.

114

4.1 Hadoop Distributed File System

HDFS è l’evoluzione di un progetto analogo sviluppato da Google denominato GDFS (Google Distributed File System), riguardante la costruzione di un file system distribuito; il sistema è stato pensato per funzionare con hardware poco costoso in grado di scalare orizzontalmente. Alla base del funzionamento di HDFS vi è l’idea di dividere i file, di solito di enorme dimensione, in frammenti (chunk) più piccoli e di memorizzare ogni chunk in un nodo. Per migliorare la disponibilità dei dati, ogni singolo chunk è replicato in almeno altri due nodi, seguendo così le buone pratiche di gestione dei dati.

Lo schema architetturale di HDFS è mostrato nella Figura 14. Ogni frammento di file è memorizzato in un nodo della rete di elaboratori, gestito da un componente software denominato HDFS datanode. Per gestire l’insieme dei datanode esiste un secondo componente denominato HDFS namenode, secondo una classica architettura client server. Il namenode contiene in memoria centrale la visione logica del file system compresa l’alberatura delle directory nei vari nodi, e per ogni file l’elenco dei datanode che gestiscono i frammenti del file.

Figura 14 – Schema architetturale di HDFS

*tratto da https://data-flair.training/blogs/hadoop-hdfs-architecture/(

Ogni volta che un client vuole accedere a un file o a una sua porzione, effettua una richiesta al namemode che restituisce al client l’elenco dei datanode coinvolti. Il client può successivamente effettuare direttamente ai datanode le richieste di lettura o scrittura di dati. Come si può notare, l’architettura è relativamente semplice e, come tutte le architetture client server, il namenode è l’elemento più significativo dell’architettura.

Per evitare che una perdita del namenode renda il sistema inusabile, è prevista un namemode secondario che può intervenire se il namenode primario non è più disponibile. Il namenode esegue un insieme di funzionalità per garantire il corretto funzionamento dell’infrastruttura HDFS, come ad esempio la verifica periodica dello stato dei datanode, attraverso la ricezione di messaggi detti heartbeat, l’eventuale copia di frammenti (chunk) nel caso di malfunzionamento di un singolo datanode, e così via.

115

È importante segnalare che HDFS è stato pensato soprattutto per file di grandi dimensioni che crescono continuativamente, come ad esempio i file di log delle applicazioni, che abbiamo visto nel Paragrafo 3.2. Originariamente HDFS è stato pensato per applicazioni che prevedono prevalentemente operazioni in sola lettura, in cui le operazioni di scrittura consistono unicamente di inserimenti e non di modifiche, e in modalità batch, consistenti cioè di operazioni che possono essere effettuate in sequenza e che non sono caratterizzate da esigenze di tempo reale, cioè di esecuzione in tempi molto brevi. Nel corso degli anni, HDFS è stato utilizzato anche per file di dimensioni contenute e con un alto tasso di aggiornamenti anche di modifica, mettendo così in luce i limiti di questa architettura.

4.2 Map Reduce

Map Reduce è un motore di esecuzione di operazioni distribuite. L’idea alla base di questo paradigma è relativamente semplice ed è particolarmente efficace quando il problema consente di eseguire inizialmente in parallelo, cioè contemporaneamente, operazioni locali sui dati, e successivamente di aggregare i risultati della ricerca.

Figura 15 – Flusso delle attività in Map Reduce (tratta da Ha et al. 2015)

Si consideri ad esempio il problema consistente nell’effettuare una sentiment analysis di messaggi di un social network, in cui si vuole cioè determinare la percentuale di messaggi positivi, negativi o neutri rispetto ad un determinato tema o evento. L’analisi può essere suddivisa in due fasi. È necessario prima valutare per ogni messaggio se esso ha un sentimento positivo e neutro; ciò può essere fatto con tecniche anche raffinate, ciò che interessa ai fini del calcolo è che l’analisi riguarda i singoli messaggi, indipendentemente l’uno dall’altro. Una volta che tutti i messaggi sono stati così elaborati, è possibile contare i messaggi classificati come positivi, negativi o neutri. Map Reduce abilita questa analisi scomponendo il problema in due fasi (si veda la Figura 15).

116

Nella fase di Map (o Partiton) il problema del calcolo del sentiment viene partizionato in modo che ogni nodo locale possa elaborare un sottoinsieme dei messaggi da analizzare e restituire il numero dei messaggi positivi, negativi o neutri che ha elaborato. Questa attività può facilmente essere distribuita su più nodi (detti worker) ognuno dei quali può eseguire lo stesso algoritmo su porzioni di dati diversi. Una volta terminata questa fase si può procedere alla fase di Reduce (o Combine). In questa seconda fase i dati prodotti dai risultati della fase di Map sono aggregati (ad esempio ordinati, sommati etc.) e restituiti.

La libreria di programmi di gestione di Map Reduce, che è disponibile nella soluzione Hadoop per diversi ambienti e linguaggi di programmazione, si occupa di tutti i problemi infrastrutturali, quali ad esempio identificare i nodi liberi dove poter svolgere le elaborazioni, monitorare e gestire i processi di elaborazione, identificare eventuali nodi non più disponibili, è cosi via, in modo da lasciare al programmatore la scrittura delle sole funzioni di Map e Reduce. La libreria si occupa di spostare l’esecuzione delle funzioni sui nodi dove sono memorizzati i dati, realizzando così quel cambiamento di paradigma di calcolo indicato all’inizio della sezione. Map Reduce insieme con HDFS consentono dunque di eseguire calcoli anche complessi su un insieme molto grande di dati, soprattutto se il tipo di problema non prevede, come abbiamo discusso, una interdipendenza fra i dati.

Nonostante la potenza del motore Map Reduce, risolvere un problema individuando le fasi di Map e Reduce e la loro implementazione può essere molto complesso e a rischio di errori. Per tale motivi sono disponibili sistemi di analisi più semplici come ad esempio Pig e il suo linguaggio chiamato Pig Latin, che astraggono dalla difficoltà tecniche traducendo i programmi scritti nel linguaggo Pig Latin in una o più funzionalità da “mappare” su Map Reduce. Di fatto, al giorno di oggi i programmatori tendono a non scrivere direttamente in Map Reduce; usano piuttosto strumenti di più alto livello che successivamente traducono le proprie istruzioni in funzionalità Map Reduce. Ad esempio, è possibile interrogare una base di dati HBase con un linguaggio di interrogazione simile a SQL, la cui esecuzione non è altro che una serie di funzionalità Map Reduce.

4.3 Yet Another Resource Negotiation

Come visto per HDFS e per Map Reduce, la complessità dell’insieme di funzionalità software che gestiscono le varie componenti di una rete di nodi elaborativi è molto elevata. A queste complessità se ne aggiungono altre, relative alla topologia della rete e ai vari carichi applicativi che ogni nodo deve eseguire.

A partire dalla versione 2 di Hadoop è stato sviluppato un componente aggiuntivo in grado di gestire in maniera efficace le risorse disponibili, separando questo compito dalle funzionalità svolte dalle altre librerie per Map Reduce. Yet Another Resource Negotiator (YARN), come dice il suo nome, è un negoziatore di richieste in ambiente distribuito. Il suo compito fondamentale è decidere quali nodi allocare ai processi che richiedono di eseguire delle attività. Nella Figura 16 si mostrano i componenti fondamentali dell’architettura funzionale Yarn.

117

Figura 16 – Componenti della architettura funzionale Yarn

(tratto da https://www.slideshare.net/GabrieleLombari/hadoop-in-action)

Il cuore del sistema è il modulo di Resource manager (Gestore delle risorse), che dialoga costantemente con i Node manager installati sui nodi elaborativi slave dell’infrastruttura; in tal modo, il Resource manager ha sempre lo stato aggiornato dell’uso delle risorse. Quando un client, per esempio un gestore di attività map reduce, chiede risorse, effettua una richiesta al Resource manager, che controlla le disponibilità e autorizza l’installazione di un Application master (il gestore di una singola attività Map-Reduce) e dei Container (cioè, le porzioni di memoria assegnate alle singole attività Map Map-Reduce).

5. Conclusioni

L’evoluzione delle tecnologie informatiche per memorie di dati consente di poter immagazzinare quantità sempre più grandi di dati anche di tipologie diverse. Le tecnologie relazionali che negli ultimi 40 anni erano state le protagoniste assolute nel settore della gestione dati stanno lasciando il passo a nuovi modelli di dati e nuove soluzioni tecnologiche. Tali cambiamenti sono legati alle nuove esigenze applicative, sia per applicazioni tradizionali sia per nuove applicazioni nate con l’avvento di Internet. I nuovi modelli e i relativi sistemi di gestione riprendono quanto già investigato nella ricerca scientifica, con soluzioni tecnologiche moderne che consentono di rendere questi modelli utilizzabili anche per le sfide di oggi e future. Questo ampliarsi dello spazio delle possibili soluzioni tecnologiche per i problemi di gestione dati offre grande libertà di scelta ai progettisti di architetture dati; la loro semplicità d’uso rende l’utilizzo di queste nuove tecnologie accessibili a moltissime persone.

Va sottolineato come spesso le soluzioni NoSQL siano state promosse dai giganti del Web come Google, Facebook, Amazon etc. e che queste aziende non vendono tecnologie o infrastrutture hardware ma, in alcuni casi, offrono servizi basati su tali tecnologie. È importante sottolineare questo aspetto, in quanto se nel 1970 l’IBM sviluppava il modello relazionale per poi offrire prodotti proprietari sul mercato a titolo oneroso, al giorno di oggi le aziende rilasciano il software di gestione secondo il paradigma open

118

source, preoccupandosi di continuare a manutenerlo. Le motivazioni di questa scelta strategica, che può sembrare controintuitiva (come se i progettisti della scuderia Ferrari rendessero pubblici e usabili da chiunque i disegni dei motori delle monoposto di Formula 1) si può spiegare considerando due aspetti:  il rilascio di software in formato open source ne abilita la diffusione e consente più velocemente a molti di individuare eventuali errori nel software, arrivando più rapidamente alla ingegnerizzazione del prodotto software.

 La spesa dei clienti e quindi i ricavi da parte delle aziende si riorientano verso i servizi di gestione e manutenzione, e verso lo sviluppo di nuove applicazioni.

Le tecnologie per la gestione di grandi quantità di dati con formati eterogenei e dei relativi modelli non sono ancora giunte ad un punto di maturazione, e anzi sono in continua evoluzione, questo per almeno due aspetti. Il primo è relativo alla continua ricerca e innovazione nel settore, che si integra sempre di più con le soluzioni applicative di analisi dati, il secondo è la continua evoluzione del linguaggio SQL e del software di gestione per basi di dati relazionali “tradizionali”, per essere in grado di competere con i nuovi sistemi descritti in questo capitolo. Infine, sembra delinearsi per i nuovi prodotti lo sviluppo di sistemi di gestione ibridi, ovvero sistemi in grado di modellare dati secondo paradigmi diversi (per esempio documentale e a grafo).

Anche il settore industriale della gestione dati è in continua evoluzione; nel settembre del 2018 è stata annunciata la fusione delle due aziende Cloudera e Hortnworks che sviluppavano e gestivano piattaforme Hadoop, segno di una maturazione del mercato big data. Le soluzioni cloud dei principali fornitori di tecnologie dati si stanno orientando verso la costruzione di ecosistemi digitali per i quali è semplice rendere interoperabili, cioè far convivere, applicazioni diverse dello stesso provider ovvero integrare soluzioni di provider diversi.

A una grande disponibilità di soluzioni corrisponde una grande responsabilità da parte dei progettisti di sistemi informativi che utilizzano big data, in quanto è necessario scegliere con attenzione la migliore soluzione possibile rispetto al contesto applicativo in cui si agisce. Va sottolineato che le nuove esigenze di scalabilità, accennate in questo capitolo, così come le soluzioni cloud oggi esistenti e gli ecosistemi digitali che si stanno costituendo attorno ai grandi fornitori di tecnologie, impongono una attenta e non banale analisi su come risolvere un determinato problema applicativo che utilizzi grandi quantità di dati. E’ anche cruciale la possibilità di utilizzare per lo stesso problema applicativo diversi paradigmi, passando da un modello ad un altro in maniera flessibile e veloce.

119

Riferimenti

E.F. Codd - A Relational Model of Data for Large Shared Data Banks.Communication of ACM 13,6 pp. 377-387, 1970

T. Brewer - Towards Robust Distributed System, PODC, 2000

I. Ha, B. Back, B. Ahn - Map Reduce Functions to Analyze Sentiment Informationfrom Social Big Data” Hindawi Publishing Corporation, International Journal of Distributed Sensor Networks, Volume 2015. G. Harrison / Next Generation Databases, Apress, 2015

121

Capitolo 5 – La qualità dei dati e la grande sfera opaca