I 7 progetti Hadoop e Spark più comuni

C'è un vecchio assioma che va più o meno così: se offri a qualcuno il tuo pieno supporto e sostegno finanziario per fare qualcosa di diverso e innovativo, finirà per fare quello che fanno tutti gli altri.

Così va con Hadoop, Spark e Storm. Tutti pensano di fare qualcosa di speciale con queste nuove tecnologie per i big data, ma non ci vuole molto per incontrare gli stessi schemi più e più volte. Le implementazioni specifiche possono differire in qualche modo, ma in base alla mia esperienza, ecco i sette progetti più comuni.

Progetto n. 1: consolidamento dei dati

Chiamalo "data hub aziendale" o "data lake". L'idea è che tu abbia origini dati disparate e desideri eseguire analisi su di esse. Questo tipo di progetto consiste nell'ottenere feed da tutte le fonti (in tempo reale o in batch) e inserirli in Hadoop. A volte questo è il primo passo per diventare una "azienda basata sui dati"; a volte vuoi semplicemente dei bei rapporti. I data lake di solito si materializzano come file su HDFS e tabelle in Hive o Impala. C'è un mondo nuovo e audace in cui gran parte di questo si manifesta in HBase e Phoenix, in futuro, perché Hive è lento.

Ai venditori piace dire cose come "schema su lettura", ma in verità, per avere successo, devi avere una buona idea di quali saranno i tuoi casi d'uso (quello schema Hive non avrà un aspetto molto diverso da quello che faresti in un data warehouse aziendale). La vera ragione per un data lake è la scalabilità orizzontale e il costo molto inferiore rispetto a Teradata o Netezza. Per l '"analisi", molte persone configurano Tableau ed Excel sul front-end. Le aziende più sofisticate con "veri data scientist" (fanatici della matematica che scrivono un Python pessimo) usano Zeppelin o iPython notebook come front-end.

Progetto n. 2: analisi specialistica

Molti progetti di consolidamento dei dati iniziano effettivamente qui, in cui hai un'esigenza speciale e inserisci un set di dati per un sistema che esegue un tipo di analisi. Questi tendono ad essere incredibilmente specifici del dominio, come le simulazioni di rischio di liquidità / Monte Carlo presso una banca. In passato, tali analisi specializzate dipendevano da pacchetti proprietari antiquati che non potevano scalare come i dati e spesso soffrivano di un set di funzionalità limitato (in parte perché il fornitore del software non poteva sapere tanto sul dominio quanto l'istituzione immerso in esso).

Nei mondi Hadoop e Spark, questi sistemi hanno più o meno lo stesso aspetto dei sistemi di consolidamento dei dati, ma spesso hanno più HBase, codice personalizzato non SQL e meno origini dati (se non solo una). Sempre più spesso sono basati su Spark.

Progetto n. 3: Hadoop come servizio

In qualsiasi grande organizzazione con progetti di "analisi specializzata" (e ironicamente uno o due progetti di "consolidamento dei dati") inizieranno inevitabilmente a provare la "gioia" (cioè il dolore) di gestire alcuni cluster Hadoop configurati in modo diverso, a volte da fornitori. Successivamente diranno: "Forse dovremmo consolidare questo e mettere in comune le risorse", invece di lasciare metà dei loro nodi inattivi per metà del tempo. Potrebbero passare al cloud, ma molte aziende non possono o non vogliono, spesso per motivi di sicurezza (leggi: politica interna e protezione del lavoro). Questo generalmente significa molte ricette di Chef e ora pacchetti container Docker.

Non l'ho ancora usato, ma Blue Data sembra avere la cosa più vicina a una soluzione pronta all'uso qui, che piacerà anche alle organizzazioni più piccole che non hanno i mezzi per distribuire Hadoop come servizio.

Progetto n. 4: analisi in streaming

Molte persone lo chiamerebbero "streaming", ma l'analisi dello streaming è piuttosto diversa dallo streaming dai dispositivi. Spesso l'analisi in streaming è una versione più in tempo reale di ciò che un'organizzazione ha fatto in batch. Prendi l'antiriciclaggio o il rilevamento delle frodi: perché non farlo sulla base della transazione e prenderlo come accade piuttosto che alla fine di un ciclo? Lo stesso vale per la gestione dell'inventario o qualsiasi altra cosa.

In alcuni casi si tratta di un nuovo tipo di sistema transazionale che analizza i dati un po 'alla volta mentre vengono trasferiti in un sistema analitico in parallelo. Tali sistemi si manifestano come Spark o Storm con HBase come il solito archivio dati. Si noti che l'analisi in streaming non sostituisce tutte le forme di analisi; vorrai comunque far emergere le tendenze storiche o guardare i dati passati per qualcosa che non hai mai considerato.

Progetto n. 5: elaborazione di eventi complessi

Qui stiamo parlando dell'elaborazione di eventi in tempo reale, dove contano i secondi. Sebbene non sia ancora abbastanza veloce per applicazioni a latenza ultra bassa (picosecondi o nanosecondi), come i sistemi di trading di fascia alta, puoi aspettarti tempi di risposta di millisecondi. Gli esempi includono la valutazione in tempo reale dei record di dati delle chiamate per le società di telecomunicazioni o l'elaborazione di eventi di Internet of Things. A volte, vedrai che tali sistemi usano Spark e HBase, ma generalmente cadono di faccia e devono essere convertiti in Storm, che si basa sul modello Disruptor sviluppato dallo scambio LMAX.

In passato, tali sistemi erano basati su software di messaggistica personalizzato, o prodotti di messaggistica client-server pronti all'uso ad alte prestazioni, ma i volumi di dati odierni sono troppo per entrambi. I volumi di scambio e il numero di persone con telefoni cellulari sono aumentati vertiginosamente da quando sono stati creati quei sistemi legacy e sensori medici e industriali pompano troppi bit. Non l'ho ancora usato, ma il progetto Apex sembra promettente e afferma di essere più veloce di Storm.

Progetto n. 6: streaming come ETL

A volte si desidera acquisire dati in streaming e archiviarli da qualche parte. Questi progetti di solito coincidono con il n. 1 o il n. 2, ma aggiungono il proprio ambito e le proprie caratteristiche. (Alcune persone pensano di fare il numero 4 o il numero 5, ma in realtà stanno scaricando su disco e analizzando i dati in un secondo momento.) Questi sono quasi sempre progetti Kafka e Storm. Viene utilizzato anche Spark, ma senza giustificazione, poiché non è realmente necessaria l'analisi in memoria.

Progetto n. 7: sostituzione o aumento di SAS

SAS va bene; SAS è carino. SAS è anche costoso e non stiamo acquistando scatole per tutti voi data scientist e analisti in modo che possiate "giocare" con i dati. Inoltre, volevi fare qualcosa di diverso da quanto SAS potrebbe fare o generare un grafico più carino. Ecco il tuo bel data lake. Ecco iPython Notebook (ora) o Zeppelin (più tardi). Forniremo i risultati in SAS e archiveremo i risultati da SAS qui.

Anche se ho visto altri progetti Hadoop, Spark o Storm, questi sono i tipi "normali" di tutti i giorni. Se stai usando Hadoop, probabilmente li riconosci. Alcuni dei casi d'uso per questi sistemi li ho implementati anni prima, lavorando con altre tecnologie.

Se sei un veterano troppo spaventato dal "grande" nei big data o dal "fare" in Hadoop, non esserlo. Più le cose cambiano e più rimangono le stesse. Troverai molti paralleli tra le cose che hai usato per distribuire e le tecnologie hipster che turbinano nell'Hadooposfera.