Big Data Tech

In ambito Hadoop e file system i file Parquet sono frequentemente utilizzati. I file Parquet sono un file in formato colonnare. Può eseguire compressione e offre ottime performance nelle query. In Parquet nuove colonne possono essere aggiunte alla fine della struttura. Parquet è supportato da Cloudera e ottimizzato per Cloudera Impala. È importante ricordare che i nomi di colonna di Parquet siano lowercase. Se il file Parquet contiene nomi con maiuscole e minuscole, Hive non sarà in grado di leggere le colonne e ritornerà valori nulli nelle queries.

La scelta di un corretto formato di file per le applicazioni è estremamente importante. L'uso di formati di file inefficienti, ad esempio il formato TextFile e l'archiviazione dei dati senza compressione aggrava il problema dei file di piccole dimensioni, influendo sulle prestazioni e sulla scalabilità in diversi modi.

La lettura di dati da tabelle molto ampie (tabelle con un numero elevato di colonne) archiviate in formati non colonnari (TextFile, SequenceFile, Avro) richiede che ogni record sia letto completamente dal disco, anche se sono necessarie solo poche colonne. I formati di colonne, come Parquet, consentono la lettura di sole colonne dal disco, il che può migliorare significativamente le prestazioni.

L'uso di formati di file inefficienti, specialmente quelli non compressi, aumenta l'utilizzo dello spazio HDFS e il numero di blocchi che devono essere tracciati da NameNode. Se i file sono di piccole dimensioni, significa che i dati vengono suddivisi in un numero maggiore di file, aumentando così la quantità di metadati associati da archiviare.

La scelta di un formato di file dipende da diversi fattori:

-       come evolverà la struttura dei dati

-       con quali strumenti saranno elaborati

-       se sarà utilizzato SQL per l’interrogazione

-       se saranno eseguite estrazioni/esportazioni batch da Hadoop verso database esterni o altre piattaforme?

-       se i requisiti di storage sono un fattore significativo

In Hive esiste una interessante caratteristica che consente di scomporre i dati su più files in HDFS. Questa viene chiamata Bucketing. In pratica HIVE è in grado di scomporre i dati in "contenitori" in maniera piuttosto randomica basandosi sui valori della colonna rispetto alla quale si imposta questa caratteristica. Viene calcolato un valore hash basato sui valori di colonna.Con il comando di creazione tabella che segue:

CREATE TABLE orders_bucketed (order_id INT, cust_id INT, order_date TIMESTAMP)  CLUSTERED BY (order_id) INTO 20 BUCKETS;

si stabilisce che i valori presenti nella colonna order_id vengono presi come riferimento per salvare i record di tabella in uno dei 20 buckets. Ciascun bucket conterrà quindi all'incirca il 5% dei record presenti nella tabella. Sfruttando questa impostazione si possono ottenere dei miglioramenti di performance nelle join se tutte le colonne delle tabelle vengono impostate a bucket.

I database NoSQL sono stati sviluppati in risposta alle necessità di scalabilità di diverse moderne applicazioni. NoSQL è un termine piuttosto esteso che generalmente si riferisce a database non –relazionali e comprende un’ampia raccolta di modelli di collezione dati quali database a grafo, database documentali, database chiave/valore, database di famiglie di colonne.

Fra questi, HBase è classificato come database di famiglie di colonne, modellato sull’architettura BigTable di Google. Questa architettura consente ad HBase di fornire:

• Accesso random read/write a basso livello
• Consistenza robusta
• Modellazione dati flessibile o senza schema

La caratteristica “senza-schema” è il risultato di come HBase approcci la modellazione dei dati, che è molto differente dalla impostazione del modello relazionale. HBase organizza dati in tabelle che contengono righe. Entro una tabella le righe sono identificate da una chiave che non possiede un tipo di dato ma che è immagazzinato e trattato come un array di byte. Le chiavi di riga sono simili al concetto di chiave del database relazionale, vengono automaticamente indicizzate. In HBase le righe di tabella vengono ordinate per la loro chiave e dal momento che sono array di byte, qualsiasi elemento può essere utilizzato per comporre la chiave, dalle stringhe a strutture di dati qualsiasi.

HBase immagazzina i propri dati come coppie chiave/valore e tutte le descrizioni di tabella sono recuperate tramite la chiave di riga cioè tramite l’identificatore univoco. I dati all’interno del record sono raggruppati in famiglie di colonne e ciascuna famiglia contiene colonne fra di loro in relazione logica. Visivamente, si può rappresentare una tabella di HBase come l’insieme dei dati di un censimento della popolazione, dove ogni riga rappresenta una persona ed è accessibile con l’ID chiave unica, con famiglie di colonne che contengono i dati personali per nome e indirizzo, i dati demografici per sesso e data di nascita.

Archiviare dati in colonne piuttosto che in righe offre particolari benefici per i data warehouse e per i database analitici dove le aggregazioni sono calcolate su un set elevato di dati con potenziali valori “sparsi”, dove non tutte le colonne sono valorizzate. Sebbene le famiglie di colonne siano molto flessibili, in pratica una famiglia di colonne non è completamente senza schema. Le famiglie di colonne sono definite all’inizio prima di permettere l’inserimento dati all’interno di righe e colonne, in quanto impattano sulla modalità di immagazzinamento dei dati in HBase. Ad ogni modo le colonne che compongono un record possono essere create sulla base delle necessità. Di fatto ogni riga può possedere un differente insieme di colonne.

Un’altra interessante caratteristica di HBase e dei database orientati a colonne è che le singole celle, intersezioni di righe e colonne, vengono versionate per timestamp, archiviate come long integer che rappresenta i millisecondi dal 1 gennaio 1970. HBase viene così descritto come essere una mappa multidimensionale dove il tempo costituisce la terza dimensione. La dimensione tempo viene indicizzata in ordine descrescente, così quando viene letta da HBase  i valori più recenti sono rintracciati per primi. Il contenuto di una cella è referenziato come una tupla {riga, colonna, timestamp}, oppure possiamo ricercare per valori di cella entro un intervallo di tempo.

Generazione dello schema

Nel generare uno schema in HBase è importante pensare in termini di struttura di famiglie di colonne nel modello dei dati e come interessa la modalità di accesso ai dati. Mentre la definizione dello schema nei modelli relazionali tradizionali è guidata da una accurata rappresentazione di entità e relazioni, e sulle impostazioni delle performance basate su join e indici, una definizione vincente dello schema di HBase tende ad essere guidata dai casi d’uso dell’applicazione. Inoltre, dal momento che HBase non supporta joins e fornisce una sola chiave di riga, dobbiamo prestare attenzione che lo schema sia in grado di garantire tutti i casi d’uso. Spesso questo comporta una de-normalizzazione e una duplicazione dei dati con entità innestate. La buona notizia è che, poichè HBase permette la definizione dinamica delle colonne a run-time, abbiamo ulteriore flessibilità anche dopo la creazione delle tabelle per scalare ulteriormente lo schema.

Una intelligente opzione fornita da Pig è costituita dal comando ILLUSTRATE il quale produce in maniera automatica, esaminando lo script che si desidera mettere sotto test, un set di records che consente una verifica più completa delle proprie procedura.

Il comando ILLUSTRATE di Pig esegue un efficace campionamento di dati sull'intero data set con queste caratteristiche:

- esamina il codice per determinare quali dati sono necessari

- genera un set di record che in maniera appropriata esercitano il codice Pig realizzato

A differenza del comando SAMPLE che estrae dal data set un insieme percentuale su base casuale, ILLUSTRATE opera in maniera più intelligente e raccoglie un insieme di record più adatto al test.