Capitolo 8: Ecosistema Apache Hadoop & Calcolo Distribuito

L’ottavo modulo del corso esamina l’ecosistema open-source Apache Hadoop, il framework di riferimento per l’archiviazione e l’elaborazione distribuita di grandi volumi di dati (Big Data). Più che un singolo software monolitico, Hadoop costituisce un’architettura modulare e altamente configurabile che integra file system distribuiti (HDFS), motori di calcolo parallelo (MapReduce, YARN, Spark), database NoSQL (HBase, Cassandra, MongoDB), cataloghi di metadati (HCatalog) e interfacce di interrogazione ad alto livello (Pig, Hive).

---

1. Panoramica Generale: RDBMS vs. Hadoop (Schema-on-Read)

Quando occorre elaborare moli massive di dati senza ricorrere a costosissimi supercomputer centralizzati, Hadoop consente di distribuire sia l’archiviazione sia il calcolo su un cluster di nodi standard (commodity hardware), operando in modo nativo come un Data Lake basato sul paradigma Schema-on-Read.

Confronto Strutturale: RDBMS Tradizionali vs. Hadoop (Slide 3)

Dimensione di Confronto	RDBMS (Database Relazionali)	Apache Hadoop
Paradigma dello Schema	Schema-on-Write: lo schema rigoroso dei dati deve essere progettato e creato prima che i dati stessi possano essere caricati.	Schema-on-Read: i dati vengono semplicemente copiati nel file system così come sono; nessuna trasformazione preventiva è richiesta.
Trasformazione del Dato	Ogni singolo dato da caricare deve essere preventivamente convertito e validato nella struttura tabellare interna del database.	I dati e le colonne vengono estratti, omogeneizzati e strutturati solo durante la fase di lettura/interrogazione.
Evoluzione e Nuove Sorgenti	Nuove colonne devono essere aggiunte esplicitamente allo schema prima di poter caricare i relativi dati.	Nuovi dati e nuove fonti (una, dieci o cento sorgenti) possono essere aggiunti ed estratti in qualsiasi momento in modo trasparente, potendo persino differire a un momento successivo la configurazione di lettura.

Architettura Complessiva dell’Ecosistema Hadoop (Slide 4)

L’architettura modulare di Hadoop si articola in livelli sovrapposti affiancati da servizi verticali di coordinamento:

Architettura Stratificata dell'Ecosistema Apache Hadoop (Slide 4):

           ┌───────────────────────┐  ┌───────────────────────┐
           │        MAHOUT         │  │  R (RHIVE - RHADOOP)  │
           └───────────────────────┘  └───────────────────────┘
┌────────┐ ┌─────────┐ ┌──────────┐ ┌──────────┐ ┌────────────┐ ┌─────────┐
│        │ │         │ │   HIVE   │ │          │ │   FLUME    │ │         │
│        │ │   PIG   │ │ (HiveQL) │ │ HCatalog │ ├────────────┤ │ZOOKEEPER│
│        │ │         │ │          │ │          │ │   SQOOP    │ │         │
│        │ └─────────┘ └──────────┘ └──────────┘ └────────────┘ │    &    │
│ AMBARI │ ┌──────────────────────────────────────────────────┐ │         │
│        │ │                    MAPREDUCE                     │ │  OOZIE  │
│(Wizard,│ └───────────────────────────────────┐              │ │         │
│ GUI &  │ ┌───────────┐ ┌────────┐ ┌──────────┤              │ │ (Sync & │
│ Alert) │ │ Cassandra │ │ HBase  │ │ HCatalog │     YARN     │ │Workflow)│
│        │ │  MongoDB  │ │        │ │          │              │ │         │
│        │ └───────────┘ └────────┘ └──────────┴──────────────┘ │         │
│        │ ┌──────────────────────────────────────────────────┐ │         │
│        │ │      HDFS (Hadoop Distributed File System)       │ │         │
└────────┘ └──────────────────────────────────────────────────┘ └─────────┘

---

2. HDFS (Hadoop Distributed File System)

Al livello più basso dell’architettura (sotto i database NoSQL) risiede HDFS (Hadoop Distributed File System), il file system distribuito di Hadoop che organizza i file in una struttura gerarchica di cartelle distribuita su più server, nascondendone la complessità fisica agli strati superiori.

Architettura Master/Slave: NameNode e DataNode

Un cluster HDFS funziona secondo una rigorosa logica Master/Slave (che richiama concettualmente il modello di indicizzazione Key-Value) basata su due tipologie di nodi:

NameNode (Master — Server Principale)

È l’applicazione centralizzata che governa l’intero file system:

• Gestisce il namespace, ossia l’elenco gerarchico dei nomi dei file, delle directory e dei blocchi;
• Controlla l’accesso ai file eseguendo le operazioni di apertura, chiusura e modifica dei nomi;
• Determina come i blocchi dati sono distribuiti sui nodi del cluster e governa la strategia di replica, mantenendo in memoria la mappa completa degli indirizzamenti (data una chiave/file, sa esattamente su quali nodi fisici si trovano i suoi blocchi).

DataNode (Slave — Nodi Operativi)

Sono le applicazioni distribuite che girano sui singoli nodi periferici del cluster (generalmente un DataNode per ciascun server fisico):

• Gestiscono fisicamente lo storage locale del proprio nodo;
• Eseguono materialmente le operazioni di lettura e scrittura dei blocchi su istruzione del NameNode.

Frammentazione in Blocchi da 64 MB, Replicazione e Teorema CAP

Quando un file viene importato all’interno di HDFS:

1. Viene suddiviso automaticamente in blocchi di piccole dimensioni da 64 MB;
2. Ciascun blocco viene assegnato e copiato in modo ridondato su più DataNode distinti, mentre il NameNode registra nella propria mappa tutti gli indirizzamenti.

Perché i blocchi vengono replicati su più nodi? La ridondanza assolve a due funzioni essenziali:

• 1. Continuità operativa e tolleranza ai guasti (Fault Tolerance): garantisce l’accesso ininterrotto a tutti i dati anche qualora uno o più DataNode (o i relativi collegamenti di rete) subiscano un guasto;
• 2. Efficienza e velocità di lettura (Data Locality): quando un client richiede la lettura di un dato, HDFS soddisfa la richiesta scegliendo il nodo fisicamente o topologicamente più vicino al client, riducendo al minimo i tempi di trasferimento sulla rete.

HDFS e il Teorema CAP: Sacrificio della Consistenza

Applicando le categorie del Teorema CAP (di Brewer) a HDFS, il sistema privilegia nettamente Availability (Disponibilità) e Partition Tolerance (Tolleranza alle partizioni) a scapito della Consistency (Coerenza) immediata.
Poiché i dati sono replicati su molti nodi soggetti a possibili latenze o cadute di linea e il sistema risponde sempre interrogando il nodo più vicino al client, è possibile che — se un aggiornamento non si è ancora propagato su tutte le repliche — venga restituita una versione non ancora allineata del dato: in scenari Big Data si preferisce tuttavia una risposta immediata dal nodo più vicino piuttosto che il blocco o il ritardo del servizio.

---

3. MapReduce e YARN: Il Calcolo Distribuito

Il Paradigma MapReduce

Mentre HDFS governa lo storage, MapReduce è il modello di programmazione funzionale (functional programming) dedicato all’elaborazione distribuita: esso scompone un’operazione di calcolo complessa in $N$ sotto-operazioni indipendenti che vengono assegnate ed eseguite in parallelo dai diversi nodi che ospitano i dati, per poi ricomporre (ridurre) i risultati parziali in un unico output finale.

1. Dati di Input su HDFS
   Il job riceve in ingresso i blocchi di dati memorizzati nel file system distribuito HDFS.

2. Funzione Map (Mappatura e Parallelizzazione)
   Il sistema suddivide il calcolo e assegna i task ai nodi che detengono le partizioni del dato (o ai nodi più vicini). La funzione Map elabora localmente i dati e li trasforma in una serie di coppie intermedie (chiave, valore).

3. Ordinamento e Raggruppamento per Chiave (Shuffle & Sort)
   Tutte le coppie intermedie prodotte dai vari nodi Map vengono ordinate e raggruppate per chiave identica, formando liste del tipo (chiave1, v1, v2, v3, ...).

4. Funzione Reduce e Scrittura dell’Output su HDFS
   Per ciascuna chiave, la funzione Reduce elabora e fonde l’elenco dei valori associati generando una o più coppie (chiave, valore) finali, che vengono scritte in un file di output su HDFS.

Flusso di Esecuzione di MapReduce (Slide 12):

              ┌────────────┐
           ┌─►│Funzione Map├─(chiave,valore)────┐
           │  └────────────┘                    ▼
           │                                 ┌──────────────────┐   ┌───────────────┐
           │  ┌────────────┐                 │                  ├──►│Funzione Reduce│
┌────────┐ ├─►│Funzione Map├─(chiave,valore)►│   Ordinamento    │   └───────────────┘
│Dati di │ │  └────────────┘                 │ e Raggruppamento │   ┌───────────────┐
│ Input  ├─┤                                 │    per chiave    ├──►│Funzione Reduce│
│ (HDFS) │ │  ┌────────────┐                 │                  │   └───────────────┘
└────────┘ ├─►│Funzione Map├─(chiave,valore)►│ (chiave1,v1,v2…) │   ┌───────────────┐
           │  └────────────┘                 │                  ├──►│Funzione Reduce│
           │                                 └──────────────────┘   └───────────────┘
           │  ┌────────────┐                    ▲
           └─►│Funzione Map├─(chiave,valore)────┘
              └────────────┘

Il Limite Critico di MapReduce: Il Nodo Più Lento e l’Inadeguatezza al Real-Time

MapReduce non è adatto a elaborazioni in tempo reale (real-time) a causa di due colli di bottiglia strutturali evidenziati a lezione:

1. Dipendenza dalla velocità del nodo più lento (Straggler Problem): poiché la fase Reduce deve attendere che tutti i nodi abbiano restituito il proprio risultato parziale prima di poter ricomporre l’output finale, la velocità complessiva dell’intero cluster è pari alla velocità del suo nodo più lento (a cui si somma la latenza di rete). Paradossalmente, su un cluster di 100 nodi è preferibile avere 100 nodi di prestazioni medie e uniformi piuttosto che 99 nodi ultraveloci e 1 solo nodo lentissimo (motivo per cui lo scheduler di MapReduce cerca di escludere i nodi rilevati come troppo lenti).
2. Overhead di distribuzione e I/O su disco: oltre al costo di coordinamento per scomporre e ricomporre i task, MapReduce legge e scrive su disco HDFS ad ogni singolo passaggio.

---

YARN (Yet Another Resource Negotiator)

Acronimo di Yet-Another-Resource-Negotiator (“Un altro negoziatore di risorse”), YARN è il framework di orchestrazione e negoziazione delle risorse di calcolo distribuito di Hadoop:

• Svincola l’ecosistema Hadoop dall’uso esclusivo di MapReduce: MapReduce è infatti solo uno dei possibili modelli di calcolo sviluppabili sopra YARN;
• Consente agli architetti di progettare e configurare schemi alternativi di distribuzione delle funzioni e delle transazioni sui nodi, continuando a utilizzare HDFS e tutte le altre componenti di Hadoop.

---

4. Governance dei Metadati, Sincronizzazione e Amministrazione

HCatalog: Il Catalogo dei Metadati e la Vista Tabellare

HCatalog è il livello di gestione delle tabelle e delle strutture dati di Hadoop in cui vengono archiviati centralmente tutti i metadati (data about data — dati sui dati) associati agli archivi importati:

• Ruolo vitale dei metadati nei sistemi Schema-on-Read: poiché in un Data Lake / HDFS i file grezzi non sono omogeneizzati a monte, i metadati sono l’unico strumento che attribuisce al dato il suo significato semantico, la codifica, la fonte di origine, la data di aggiornamento e la versione. Senza metadati, durante una query il sistema non saprebbe nemmeno in quali banche dati andare a cercare le informazioni (es. individuare tutti gli archivi che trattano “articoli di magazzino”);
• Quando si associano i metadati?: la struttura del catalogo viene creata all’atto dell’istituzione del Data Lake e i metadati vanno censiti non appena si prevede di integrare una nuova banca dati nel sistema (prima ancora di qualsiasi pulitura o lettura), aggiornandoli poi in caso di modifiche allo schema;
• Vista Tabellare Unificata: grazie all’omogeneità dei metadati, HCatalog espone agli utenti e ai motori di query (come HiveQL) una vista logica tabellare intuitiva dei dati presenti in HDFS, indipendentemente dal formato fisico grezzo o NoSQL sottostante.

ZooKeeper e Ambari

Apache ZooKeeper (Sincronizzazione)

Fornisce un’infrastruttura centralizzata per mantenere sincronizzati gli oggetti e le configurazioni comuni su tutti i nodi del cluster.
Quando un dato o un parametro viene aggiornato su un nodo, ZooKeeper propaga la modifica a tutti gli altri nodi: questo meccanismo è stato introdotto proprio per minimizzare il rischio di inconsistenza del dato durante l’intervallo di riallineamento delle repliche.

Apache Ambari (Gestione & Monitoraggio)

Fornisce un’interfaccia grafica Web (GUI) ad alto livello per amministrare il cluster Hadoop senza dover operare esclusivamente da riga di comando:

• “Wizard” guidato per la procedura di installazione e configurazione;
• Strumenti centralizzati per avviare e fermare i servizi su ciascun nodo;
• Dashboard di monitoraggio in tempo reale affiancata da un sistema automatico di Alert.

---

5. Piattaforme di Alto Livello, Database NoSQL e Apache Spark

Linguaggi di Astrazione: Apache Pig e Apache Hive

Per evitare agli sviluppatori e agli analisti la complessità di scrivere codice Java a basso livello per MapReduce o navigare manualmente le cartelle di HDFS, Hadoop mette a disposizione due piattaforme di astrazione:

Componente	Linguaggio	Funzione e Caratteristiche Principali
Apache Pig (logo del maialino)	Pig Latin	Piattaforma procedurale di alto livello per creare e configurare programmi MapReduce. Astrae l’idioma Java MapReduce in una notazione ad alto livello (simile a SQL) e permette di configurare la distribuzione del carico sui nodi, la dimensione delle partizioni e le priorità di esecuzione.
Apache Hive	HiveQL	Infrastruttura di Data Warehouse costruita sopra Hadoop per fornire riepilogo dei dati, query e analisi (organizzando i dati in database, tabelle, partizioni o cluster). Grazie a HiveQL (linguaggio dichiarativo SQL-like, analogo nell’uso a client come Toad), consente di interrogare complesse strutture distribuite key-value emulando la semplicità di un database relazionale.

---

Il Livello Database su HDFS (HBase, Cassandra, MongoDB) e Apache Spark

HBase, Cassandra e MongoDB

Lo Strato Database NoSQL sopra HDFS Sopra il file system HDFS si appoggia il livello di gestione database NoSQL, scelto in base ai requisiti del progetto:

• Apache HBase: è il database distribuito nativo di Hadoop che archivia i dati su HDFS utilizzando una struttura Key/Value orientata alle famiglie di colonne (Column-Family);
• Apache Cassandra: basato anch’esso su meccanismo Key/Value e colonne, viene scelto quando il requisito primario è l’altissima velocità di elaborazione e il processamento real-time;
• MongoDB: database a documenti, leggermente più lento rispetto a Cassandra ma ideale quando occorre gestire dati caratterizzati da un’estrema variabilità nella struttura dei singoli oggetti.

Apache Spark (Calcolo In-Memory)

Apache Spark: Il Superamento dei Limiti di MapReduce Apache Spark è il framework open-source per il calcolo distribuito che risolve i problemi di lentezza e di coerenza di MapReduce:

• Elaborazione In-Memory (RAM) vs. Disco HDFS: mentre MapReduce ad ogni step legge il file di input da HDFS e riscrive il file di output sullo stesso disco HDFS (impiegando moltissimo tempo in operazioni di I/O su disco), Spark utilizza la scrittura e l’elaborazione direttamente in memoria RAM, eseguendo le query in parallelo a velocità nettamente superiori;
• Controllo della Coerenza e Proprietà ACID: come analizzato nel modulo sul Delta Lake, Spark interviene anche in fase di lettura per controllare eventuali duplicazioni, ridondanze o disallineamenti tra le repliche distribuite, consentendo di ripristinare le garanzie ACID sui sistemi Big Data.

Indicazione del Docente per la Preparazione dell'Esame

Come precisato a lezione in chiusura del modulo, ai fini dell’esame non è richiesto memorizzare ogni singolo modulo secondario dell’ecosistema, ma è fondamentale padroneggiare:

1. La filosofia generale di Hadoop come sistema Schema-on-Read rispetto ai database relazionali;
2. Il funzionamento di HDFS (architettura Master/Slave con NameNode e DataNode, blocchi da 64 MB, doppio scopo della replica e sacrificio della Consistency nel Teorema CAP);
3. La logica del paradigma MapReduce (fasi Map, ordinamento per chiave e Reduce, e il limite del nodo più lento che lo rende inadatto al real-time) e il vantaggio prestazionale di Apache Spark (calcolo in-memory);
4. L’importanza strategica dei metadati (HCatalog) e i criteri di scelta dei database NoSQL (HBase / Cassandra / MongoDB).