Questo post sul blog è stato pubblicato su Hortonworks.com prima della fusione con Cloudera. Alcuni collegamenti, risorse o riferimenti potrebbero non essere più accurati.
Un ringraziamento speciale a Bill Preachuk e Brandon Wilson per aver esaminato e fornito la loro esperienza
Introduzione
L'archiviazione a colonne è un argomento spesso discusso nel mondo dell'elaborazione e dell'archiviazione dei big data di oggi:esistono centinaia di formati, strutture e ottimizzazioni in cui è possibile archiviare i dati e ancora più modi per recuperarli a seconda di ciò che si intende fare con esso. Questa pletora di opzioni è nata dalla necessità non solo di acquisire rapidamente i dati utilizzando gli strumenti di elaborazione transazionale in linea (OLTP), ma anche dalla necessità di consumare e analizzare i dati con maggiore efficienza utilizzando l'elaborazione analitica in linea (OLAP) Strumenti. Migliaia di casi d'uso diversi hanno ciascuno le proprie esigenze specifiche e quindi sono emerse molte opzioni. Ad esempio, leggere i dati del mercato azionario richiede una mentalità completamente diversa rispetto all'analisi delle metriche di qualità in una linea di produzione. Con tutte queste scelte, è facile perdersi durante la navigazione verso il tuo obiettivo finale:scegliere uno strumento che funzioni per te.
HDP incorpora una serie di soluzioni di archiviazione, ognuna delle quali è realizzata su misura per casi d'uso specifici. Vogliamo iniziare questa serie di blog parlando dei seguenti tre strumenti/motori e dei formati di archiviazione associati:
- Apache Hive utilizza Apache ORC come un efficiente formato di archiviazione a colonne che consente prestazioni sia per l'elaborazione di query OLAP che per Deep SQL
- Apache Phoenix/Apache HBase insieme formano un database OLTP che consente query in tempo reale su miliardi di record e offre rapide ricerche casuali basate su chiavi e aggiornamenti
- Apache Druid è un datastore ad alte prestazioni che consente l'analisi di serie temporali in tempo reale su flussi di eventi e analisi OLAP su dati storici con latenza estremamente bassa
In questo articolo, intendiamo articolare quale strumento è appropriato per un determinato caso d'uso, confrontare e confrontare i vari strumenti e fornire una linea guida di base per la scelta dello strumento appropriato o della serie di strumenti per affrontare il tuo caso d'uso.
È molto simile a giocare a Tetris:ogni pezzo ha una nicchia diversa ma ognuno aggiunge un valore unico alla struttura più ampia
Elaborazione dei Big Data e sue somiglianze
I dati sono raggruppati per colonne nell'archiviazione perché spesso cerchiamo di restringere le somme, le medie o altri calcoli su una colonna specifica. Immagina di essere una compagnia aerea che cerca di capire quanto carburante dare a un aereo quando è attraccato:potresti voler calcolare le miglia medie percorse da ciascun volo da una tabella di dati di viaggio. Ciò richiederebbe l'esecuzione della funzione media su una singola colonna. Archiviamo questi dati in formato colonnare perché le letture sequenziali su disco sono veloci e ciò che vogliamo fare in questo caso è leggere un'intera colonna dalla tabella in sequenza (e quindi eseguire un calcolo medio).
Ci sono molte differenze tra questi motori, ma indipendentemente dal motore di elaborazione dati che scegli, trarrai vantaggio da alcuni punti in comune. Uno di questi è la caratteristica condivisa della memorizzazione nella cache. Ciascuno di questi tre motori lavora di pari passo con la memorizzazione nella cache in memoria per aumentare le prestazioni della sua elaborazione senza modificare il formato di archiviazione back-end, ottenendo tempi di risposta inferiori al secondo. HBase ha BlockCache, Hive ha il livello LLAP IO e Druid ha diverse opzioni di memorizzazione nella cache in memoria. Spesso, la parte costosa della gestione di una query comporta l'analisi della richiesta e l'accesso all'archivio persistente per recuperare il sottoinsieme di dati a cui l'utente è interessato. Tuttavia, l'intero passaggio può essere evitato quando si utilizza un meccanismo di memorizzazione nella cache in memoria poiché molti formati di archiviazione a colonne utilizzare, consentendo al processo di raggiungere la memoria per i dati precedentemente interrogati in frazioni di secondo. Torniamo al nostro esempio di calcolo del carburante:diciamo che ho appena chiesto le miglia medie percorse per tutti i voli della mia compagnia, ma mi rendo conto che i voli nazionali avranno requisiti di carburante molto diversi dai voli internazionali. Desidero quindi filtrare la mia query precedente con una clausola WHERE country='US' (o codice paese equivalente). Questo modello di query è molto comune per l'esplorazione dei dati. Poiché disponiamo già dei dati della query precedente in memoria, i risultati di questa query possono essere restituiti senza dover eseguire una costosa lettura del disco.
La struttura del livello LLAP di Hive:parte del suo spazio di memoria viene utilizzato per la memorizzazione nella cache, mentre l'archiviazione a lungo termine è su HDFS. HBase e Druid hanno anche un concetto simile di cache e storage.
Un'altra somiglianza esiste nelle scorciatoie che ciascuno di questi motori utilizza per azzerare i dati specifici che vengono interrogati. HBase ha un accesso casuale O(1) basato su HashMap, Druid usa indici bitmap invertiti per capire quali valori di colonna si trovano in quali righe e le tabelle Hive hanno statistiche, indici e partizionamento per abbreviare l'accesso ai dati. Queste funzionalità consentono ai motori di combinare il modo in cui i dati vengono archiviati con il modo in cui vi si accede, consentendo analisi rapide ottimizzando l'efficienza dell'hardware e sfruttando al massimo la CPU e la RAM disponibili.
L'ultima somiglianza è la prontezza aziendale di ciascuno di questi motori. Per quanto riguarda la ridondanza dei dati, tutti e tre questi motori utilizzano HDFS come meccanismo di archiviazione profonda; il fattore di replica HDFS di 3x assicura che le copie dei dati esistano altrove anche se due nodi si guastano contemporaneamente. I dati possono essere immediatamente replicati ancora una volta su nodi integri per mantenere la ridondanza. Sul tema della tolleranza ai guasti all'interno di un cluster, ogni strumento colma in qualche modo il divario. HBase offre la replica della regione, Druid ha la duplicazione dei componenti master e di lavoro, nonché un fattore di replica aumentato su HDFS e Hive ha HDFS insieme alla logica tollerante agli errori del framework YARN. La prontezza aziendale garantisce che questi motori siano resilienti ai guasti e pronti per funzionare in produzione sin dal primo giorno.
Le differenze tra i nostri motori di elaborazione dei big data
Qual è il modo migliore per assimilare i dati? Dopo aver acquisito i dati, come si ottengono rapidamente informazioni dettagliate? Diamo un'occhiata al modo in cui questi tre grandi motori di elaborazione dei dati supportano questo insieme di attività di elaborazione dei dati
Questi motori a volte sono raggruppati mentalmente insieme e pensati in modo simile a causa della loro capacità di archiviare ed elaborare Big Data, ma come scopriremo, vengono scelti per casi d'uso e scopi specificamente adatti ai loro punti di forza. Vedrai che la raccolta di strumenti contenuta nella piattaforma dati Hortonworks è adatta a qualsiasi carico di lavoro di big data, in particolare con HDP 3.0 e le funzionalità di database in tempo reale che abbiamo introdotto.
Hive è il motore OLAP rappresentativo della più ampia gamma di casi d'uso, che utilizza più comunemente Hadoop Distributed File System (HDFS) come livello di archiviazione per consentire l'archiviazione di qualsiasi tipo di dati. Può eseguire query, elaborare e analizzare dati di testo non strutturati, file CSV, XML, JSON semistrutturato, Parquet a colonne e una miriade di altri formati. Hive supporta anche supporti di archiviazione alternativi come Cloud storage, Isilon e altri. Lo standard di archiviazione de facto per Hive è ORC, che ottimizza in modo più efficiente e raccoglie i vantaggi dell'archiviazione colonnare. Una volta convertiti in ORC, i tuoi dati vengono compressi e le colonne nella tabella vengono archiviate in sequenza su disco, consentendo al livello di memorizzazione nella cache in memoria di Hive LLAP di estrarre i dati dal disco una volta e servirli dalla memoria più volte. La combinazione di Hive+LLAP viene utilizzata per analisi ad hoc, calcolo di aggregati di grandi dimensioni e reportistica a bassa latenza. Un ottimo caso d'uso per Hive è l'esecuzione quotidiana di una serie di rapporti dashboard per gli utenti; le query ripetitive non solo sfruttano la cache LLAP, ma anche la funzione "Query Results Cache", che restituisce risultati quasi istantanei se i dati non sono cambiati (a parte:la cache dei risultati delle query è una funzionalità disponibile in Hive 3.0 - rilasciata in HDP 3.0). Oltre a ciò, un Hive Data Warehouse è un ottimo uso dell'analisi ad hoc di cui è capace Hive; gli utenti possono unire i dati, eseguire query simultanee ed eseguire transazioni ACID. Considera Hive come un tuttofare SQL al riguardo, mentre gli altri due motori forniscono prestazioni estremamente veloci per casi d'uso di nicchia specifici.
Il nostro secondo motore, HBase, è un archivio di valori-chiave distribuito con funzionalità di lettura, scrittura, aggiornamento ed eliminazione casuali. HBase (una variante NoSQL) è progettato per essere un motore OLTP, che consente un'architettura di operazioni transazionali ad alto volume:pensa alle piattaforme di messaggistica con messaggi costanti scambiati tra utenti o transazioni generate in un sistema finanziario. HBase è estremamente efficiente nel portare rapidamente i dati, archiviarli e servirli nuovamente:inserimenti/aggiornamenti/eliminazioni casuali a latenza ultra-bassa. Ciò per cui non è progettato è l'aggregazione e l'unione dei dati:questa funzionalità viene eseguita tramite Phoenix, un livello SQL e un motore su HBase, ma non è consigliata per quantità maggiori di dati poiché i dati non sono strutturati in modo da ottenere risultati ottimali performance (usa invece Hive). Per riassumere, HBase è eccezionale nell'elaborazione di volumi elevati di operazioni di creazione-aggiornamento-eliminazione, ma non è all'altezza quando arriva il momento di presentare i dati in un formato di consumo per gli utenti.
Infine, Druid è il terzo motore adatto per carichi di lavoro di serie temporali OLAP a bassa latenza e per l'indicizzazione in tempo reale dei dati in streaming. Druid fornisce query OLAP a velocità cubica per il tuo cluster. La natura delle serie temporali di Druid è una pietra miliare del motore; è progettato in questo modo perché il tempo è un filtro primario quando vengono analizzati i dati basati sul tempo. Pensa a quando analizzi i tempi di volo per prenotare un viaggio:voglio conoscere il volo più economico per l'Italia in questo particolare arco di tempo di 2 settimane. Druid si adatta alla nicchia di essere molto veloce nell'ingerire i dati e nel localizzarli quando richiesto. D'altra parte, consente anche agli utenti aziendali e agli analisti di interrogare i dati e comprenderli attraverso Superset, un livello di visualizzazione strettamente legato a Druid. Druid eccelle nell'individuare una manciata di righe di dati tra centinaia di milioni o miliardi in meno di un secondo, ed eccelle anche nel calcolare i valori aggregati su quello stesso volume di dati in modo estremamente rapido. Tuttavia non esegue join e quindi non può essere utilizzato per combinare set di dati insieme per l'analisi. Se hai intenzione di analizzare una combinazione di set di dati in Druid, sarebbe saggio pre-unire i dati prima di inserirli in Druid o usare Hive (e tabelle Hive supportate da Druid) per eseguire unioni. Detto in altre parole, Druid si adatta bene al ruolo di essere l'ultima fermata per i tuoi dati dopo che sono stati elaborati e trasformati nel modo in cui gli utenti aziendali vi accederanno. Druid è ottimo per gli analisti aziendali in quanto possono accedere a Superset e visualizzare le metriche sotto forma di dashboard senza dover scrivere alcuna query; usano semplicemente una GUI per selezionare l'origine dati e i filtri della query. È anche ottimo come origine dati di supporto per dashboard di sistema, sia operativi che analitici, grazie ai suoi rapidi tempi di query.
Ecco un modo per scomporre il processo decisionale su quale strumento utilizzare per il tuo carico di lavoro:
| HBase | Alveare | Druido |
| Accesso casuale a latenza ultra bassa (ricerca basata su chiave) | ACID, database in tempo reale, EDW | OLAP a bassa latenza, query simultanee |
| OLTP di grandi volumi | Interfaccia SQL unificata, JDBC | Aggregazioni, approfondimenti |
| Aggiornamenti | Report, batch | Serie temporali |
| Elimina | Join, grandi aggregati, ad-hoc | Immissione in tempo reale |
SQL unificato
Abbiamo discusso di più sistemi fino a questo punto e ognuno ha i propri modi per accedere ai propri dati. Questo è fantastico quando i tuoi utenti sanno come funzionano tutti questi strumenti, ma potrebbero trovarsi in una curva di apprendimento prima di poter raggiungere la piena produttività se provengono da un mondo di SQL, SQL e più SQL come fa la maggior parte degli analisti. Questo è il motivo per cui abbiamo cercato di rendere questa interazione il più semplice possibile; con Hive 3.0 in HDP 3.0, puoi utilizzare la sintassi HQL simile a SQL di Hive per interagire con così tanti archivi dati diversi in questo spazio. Hive può essere utilizzato come portale per accedere e modificare Druid, HBase e tutto ciò che fornisce un'interfaccia e un driver JDBC. Hive può essere utilizzato per amministrare un'attività di ingestione di Druid che ascolta Kafka, fornendo un modo semplice per l'acquisizione in tempo reale. Infine, Hive può essere utilizzato per riunire tutto:archivia i tuoi dati dove ha più senso e accedi da un'unica posizione. Unisciti insieme, magari archivia anche quel nuovo risultato in un'altra posizione. Le possibilità sono molte, ma l'interfaccia è stata notevolmente semplificata in modo che la tua base di utenti possa dedicare meno tempo all'apprendimento di un altro strumento e più tempo a portare valore all'azienda.
Conclusione
Hive, Druid e HBase hanno tutti posizioni diverse in un'architettura dati, come abbiamo visto dall'analisi precedente. Sono comunque strumenti complementari; potresti ingerire dati transazionali con HBase con le sue ricerche veloci, spostare quei dati in Druid per un'analisi/aggregazione veloce e fare in modo che Hive integri i due insieme con i propri dati gestiti da Hive per consentire agli utenti di combinare i dati ovunque risiedano per una visione unica e una ricchezza di spunti. Con questo approccio, Druid memorizza i dati a cui è possibile accedere da solo, ma quella funzionalità è aumentata da Hive, che può estrarre i dati di Druid e unirli a dati aggiuntivi. Aggiungi a questo i principali miglioramenti che sono entrati in gioco con Hive 3.0, non ultimo dei quali sono le viste materializzate, le integrazioni migliorate con Druid e molti altri motori e una maggiore funzionalità simile al data warehouse, e hai un gruppo di strumenti in grado di risolvere qualsiasi caso d'uso.
Architetture come quella sopra menzionata apportano il meglio di ogni strumento per ottimizzare il flusso di lavoro e allo stesso tempo astrarre i dettagli per quegli utenti interessati solo ai dati. Gli architetti hanno impostato le pipeline, inserendo i dati a cui appartengono in base al caso d'uso. Ciò porta quindi agli analisti dei dati, che utilizzano Hive come interfaccia unica per acquisire conoscenze e approfondimenti. Sono in grado di trovare schemi interessanti nei dati piuttosto che preoccuparsi di dove sono archiviati i dati o imparare una nuova sintassi per accedervi:saresti sorpreso di scoprire quanto spesso lo vediamo nel mondo.
A questo punto abbiamo dimostrato i punti di forza, di debolezza e le migliori pratiche di ciascuno strumento; ci auguriamo che tu te ne vada con una migliore comprensione di ciò che si adatta a dove, nonché il quadro più ampio di combinare tutti e tre per ottenere i migliori risultati.
