DataSkills è una realtà che opera a tutto campo nel mondo della data science

Storage e ingestion di Big Data: le alternative ad Hadoop

big-data-thumb

Storage e ingestion di Big Data: le alternative ad Hadoop

2 gennaio 2018
|
0 Comments
|

Hadoop è senza dubbio lo strumento di cui abbiamo parlato in modo più esaustivo per quanto concerne lo storage e ingestion dei Big Data. Tuttavia, non è l’unico e ne esistono altri che permettono l’implementazione di un’architettura capace di elaborare dati che presentivo le caratteristiche tipiche dei Big Data, ossia:

  • Volume
  • Velocità
  • Varietà

Finora abbiamo lasciato da parte queste soluzioni perché, in alcuni casi, non rispettano gli importanti concetti di convenienza economica e di fattibilità tecnica così fortemente legati al concetto stesso di Big Data che stiamo esplorando in dettaglio.

In ogni caso, è possibile individuare tre tipologie di soluzioni che racchiudono tutte le tecnologie alternative ad Hadop:

  1. Spark; si tratta di uno strumento free e open source che, di conseguenza, comporta un investimento economico esclusivamente in termini di acquisizione di competenze, consulenze e hardware necessario alla creazione del cluster
  2. Database appliance: conosciute anche con la denominazione di data warehouse appliance
  3. Soluzioni alternative: quando sfruttano tecnologie hardware e software per il raggiungimento di elevati livello di capacità di storage e velocità di elaborazione

Possiamo definire le appliance come dispositivi costituiti da hardware – ossia da server, memoria, storage e canali di input e output – e software preconfigurati capaci di gestire carichi di lavoro gravosi. Nell’ambito dei database, le appliance sono utilizzate come piattaforme per il data warehousing, tanto che si parla proprio di data warehouse appliance. Se invece le applichiamo al contesto dei Big Data, le appliance sono interessanti nel momento in cui i dati da trattare presentano un volume elevato a fronte di una struttura rappresentabile in database relazionali.

Per quanto riguarda il parametro del volume, è importante ricordare che sebbene alcune di queste appliance possano gestire dati nell’ordine dei petabyte, ciò avviene generalmente a fronte di costi molto elevati. In termini di Total Cost of Ownership, ossia costo complessivo di proprietà, l’appliance è però meno costosa rispetto ai tradizionali sistemi RDBMS, sebbene il suo costo aumenti in modo direttamente proporzionale alla quantità di dati da gestire.

Continuando a paragonare le appliance ai sistemi tradizionali, oltre al loro minor costo vanno poi elencati ulteriori vantaggi:

  • Una piena integrazione tra le componenti hardware e software
  • Una pre-configurazione delle componenti finalizzata alla massimizzazione della performance
  • Facilità di gestione grazie a minimi compiti amministrativi

Questi sistemi permettono anche di attuare la cosiddetta database consolidation, ossia la migrazione sull’appliance di vari database relazionali ospitati su diversi server. Anche in questo caso, l’azione ha l’obiettivo di diminuire i costi in termini di hardware, software, manutenzione e gestione.

Le soluzioni di tipo appliance sono attualmente proposte da tutti i principali vendor di sistemi di warehousing: di norma si tratta di RDBMS su architetture MPP accompagnate da soluzioni che includono anche Hadoop. In questo modo, i principali produttori possono includere nella loro offerta anche l’analisi di dati non strutturati, talvolta addirittura con vere e proprie appliance dedicate ad Hadoop o, in alternativa, tramite integrazione tra questo e RDBMS.

Tra le altre soluzioni alternative vanno poi inclusi i database cosiddetti “GPU based”. Le Graphic Processing Unit sono processori nati con lo scopo di gestire la grafica, ma altrettanto utili anche in ambiti in cui la potenza di calcolo è particolarmente importante. La loro struttura permette infatti che singole operazioni siano eseguite su blocchi di dati molto più grandi rispetto a quelli normalmente elaborati dalle classiche CPU, col risultato di garantire un maggiore throughput. Nei database che rientrano in questa categoria, operazioni di calcolo come aggregazioni e filtri che sono tipiche di una RDBMS sono realizzate sfruttando proprio la potenza di calcolo delle GPU che, peraltro, si occupano anche della gestione della compressione colonnare. La tipologia di Database è relazionale, ossia destinata a ospitare dati strutturati – sebbene alcune implementazioni offrano la possibilità di gestire anche dati semi-strutturati o con strutture complesse come XML e JSON. Anche in questo caso, i costi di queste architetture sono inferiori rispetto a quelli delle database appliance.

Scarica il primo capitolo

Qualche parola sui servizi Cloud

Come abbiamo accennato, la creazione on-premises di un cluster Hadoop o l’acquisto di una appliance comportano costi legati a una serie di fattori. Il costo d’acquisto di alcune appliance può ad esempio rivelarsi elevato, così come i costi di gestione (dall’energia elettrica all’amministrazione di sistema). Per quanto riguarda invece i già citati Hadoop e Spark, i costi di acquisto dell’hardware sono più contenuti e il software è gratuito o comunque proposto a prezzo conveniente, anche nel caso in cui si optasse per una distribuzione con relativa consulenza. È il caso di Cloudera, Hortonworks e MapR. I costi che invece possono essere sorprendente elevati sono invece, ovviamente, quelli legati all’acquisizione del know-how e alla gestione, sia essa tramite personale interno che consulenti esterni. Tuttavia, tutti questi investimenti sommati risultano essere comunque più convenienti rispetto all’acquisto di una appliance. In ogni caso, se i costi iniziali, quelli di gestione e di manutenzione ponessero un freno all’acquisto di queste soluzioni, si potrebbe optare per una piattaforma cloud. Non a caso, la realizzazione sulle piattaforme cloud di sistemi prevalentemente Hadoop e Spark è ormai diffusa: l’offerta di queste soluzioni avviene con il meccanismo pay-per-use, ossia privo di costo iniziale. La creazione del cluster on-demand e l’amministrazione di sistema ha poi l’ulteriore vantaggio di essere totalmente demandata al servizio cloud. La creazione di un cluster Hadoop con varie componenti già configurate è molto rapida e altrettanto lo è la sua distruzione. Inoltre, nel cloud sono disponibili anche servizi che mettono a disposizione l’equivalente delle database appliance, ossia RDBMS molto efficienti e basati su hardware MPP, pre-configurati e ottimizzati. Nuovamente, il sistema è completamente gestito dal provider e l’offerta è pay-per-use, e dunque priva di costo iniziale.

Come già detto, Hadoop dispone di un’architettura molto sensibile e permette la realizzazione di motori di calcolo distribuito facilmente innestabili nella piattaforma. Bisogna però specificare anche che HDFS non è altro che un file system, ossia un sistema di organizzazione dei dati che, per sua stessa natura, non può replicare di certo le funzionalità di un database. Ecco perché Hadoop dispone anche, all’interno del proprio ecosistema, di applicazioni come HBase che sono database a tutti gli effetti.

In alternativa ad Hadoop, è possibile lavorare su dati con strutture variabili e non adatti a una rappresentazione tabellare con i tanti sistemi facenti parte dei database NoSQL: Cassandra, Berkeley DB, MongoDB, Neo4J, per fare qualche esempio. Ciascuno di essi è un motore database che non aderisce al modello relazionale, che vede invece gli RBDMS (Relational Database Management Systems) strutturati attorno al concetto matematico di relazione, altrimenti detta “tabella”.

Concludiamo parlando delle tecnologie Big Data relative al processo di trasformazione e analisi dei dati.

Sebbene queste due ultime operazioni si svolgano in momenti diversi e con scopi diversi, si verifica una sorta di sovrapposizione tra gli strumenti utilizzati.

Lo strumento nativo di Hadoop per la realizzazione di trasformazioni dei dati, calcoli e analisi si chiama MapReduce: complesso e non alla portata di tutti gli utilizzatori della piattaforma, necessita di una profonda conoscenza del linguaggio Java per poter essere utilizzato al meglio.

Per interagire con i dati in Hadoop è possibile tuttavia utilizzare altri strumenti, quali ad esempio Pig, che è caratterizzato da un approccio procedurale e da un linguaggio (Pig Latin) simile all’SQL per diversi aspetti. In buona sostanza, Pig Latin permette di scrivere sequenze di operazioni di trasformazione in modo semplice, convertendo direttamente dalla piattaforma i comandi nelle rispettive fasi MapReduce. Dettaglio non di poco conto: Pig può essere utilizzato sia per la realizzazione di operazioni di data ingestion che per l’analisi e l’elaborazione dei dati.

I dati possono poi essere preparati con Hive, definito come il sistema di “data warehousing” di Hadoop: consente di aggregare dati, eseguire query e analizzare grandi dataset utilizzando il linguaggio HiveQL, che ormai quasi del tutto sovrapponibile all’SQL.

Se invece le operazioni da compiere sui Big Data sono più complesse, bisognerà mettere da parte i due strumenti finora elencati e favorire Mahout, proveniente da Apache e ideale ad esempio per l’esplorazione dei dati con tecniche di analisi predittiva. Mahout è una piattaforma machine learning dedicata in particolare alla costruzione di recommendation engine, al clustering e alla classificazione.

L’ultimo tool di calcolo distribuito che vogliamo citarvi è infine Spark, che racchiude in sé svariate, interessanti funzionalità, tra cui:

  • Data ingestion (per esempio via streaming)
  • Elaborazione e trasformazione dei dati
  • Analisi attraverso un’interfaccia SQL
  • Analisi avanzata tramite la libreria di machine learning

Sempre più spesso Spark viene utilizzato in combinazione con Hadoop per la sua efficacia nella gestione dei Big Data.

Big Data Analytics. Il manuale del data scientist

Big Data Analytics. Il manuale del data scientist

Compra su Amazon