Questo sito web utilizza cookie tecnici e, previo Suo consenso, cookie di profilazione, nostri e di terze parti. Chiudendo questo banner, scorrendo questa pagina o cliccando qualunque suo elemento acconsente all'uso dei cookie. Leggi la nostra Cookie Policy per esteso.OK

Gli strumenti SQL-on-Hadoop aiutano le aziende a gestire i Big Data

pittogramma Zerouno

Analisi SQL

Gli strumenti SQL-on-Hadoop aiutano le aziende a gestire i Big Data

L’uso di Hadoop per l’elaborazione dei Big Data è limitato solo ai programmatori con specifiche competenze, ma l’integrazione di strumenti SQL sta aprendo il sistema a una più vasta schiera di sviluppatori e analisti di dati

08 Giu 2016

di TechTarget

Gli strumenti SQL-on-Hadoop offrono alle aziende un modo familiare per elaborare e analizzare i dati in cluster Hadoop. A spiegarlo è Craig Stedman, autore di un e-book intitolato SQL tools offer users easier entry into Hadoop Data

Secondo l’esperto, oggi gli utenti possono scegliere tra più di una dozzina di strumenti SQL-on-Hadoop, sia open source che commerciali. Molti non sono sufficientemente maturi e nemmeno così semplici da utilizzare: per questo è importante capire le caratteristiche e gli usi ottimali di ognuno. Il rapido ritmo di sviluppo su Hadoop e le relative tecnologie stanno aiutando a colmare questo divario, ma ciò per le aziende significa tenere il passo con frequenti aggiornamenti.

Per ora, nonostante il crescente interesse verso i Big Data, l’adozione di strumenti SQL-on-Hadoop rimane bassa. In un sondaggio del 2015 condotto da TDWI, solo il 16% degli intervistati ha dichiarato che la propria azienda stava utilizzando un motore commerciale SQL-on-Hadoop come parte delle applicazioni di BI e analisi, mentre a seguito di un’altra domanda il 22% degli intervistati ha risposto di aver utilizzato sistemi SQL-on-Hadoop per la gestione dei dati. Entro i prossimi tre anni  la maggior parte degli utenti Hadoop implementerà anche il software SQL-on-Hadoop. Vediamo tre esempi concreti tratti dall’e-book di Stedman.

Il caso di Progressive Insurance

Nel libri biene citato il caso di Progressive Insurance, un assicuratore di auto con sede a Mayfield Village, in Ohio: la società ha cominciato a utilizzare un cluster Hadoop basato su Hortonworks verso la fine del 2013 per elaborare e analizzare i dati telematici raccolti dalle automobili dei clienti, come parte di un programma di assicurazione chiamato Snapshot; il cluster detiene anche i dati di ricerca e sviluppo utilizzati per determinare il prezzo dei prodotti assicurativi, oltre ai registri delle attività dal sito web della società.

La maggior parte dei processi ETL e le query di analisi che vengono eseguiti sui dati del cluster sono creati con Hive, uno strumento open source SQL-on-Hadoop.

“I business analysts e i data scientist della società – ha spiegato Pawan Divakarla, data and analytics business leader di Progressive – sono già utenti esperti di SQL, così abbiamo voluto mantenere per loro la stessa struttura di dati. Abbiamo un’intera comunità di utenti che utilizza i dati e non aveva senso fare loro imparare qualcosa di diverso”.

Progressive ha riscontrato alcuni bug in Hive subito dopo la distribuzione, ma ora la tecnologia è più stabile e soddisfa quasi interamente le esigenze aziendali. Per contribuire ad aumentare le prestazioni del Hive e consentirle di supportare l’esecuzione di query interattive, la società di assicurazioni ha implementato Tez, un framework applicativo open source che originato da Hortonworks per ottimizzare il trattamento dei dati nei sistemi Hadoop. Inoltre, la maggior parte degli analisti di Progressive lavorano con Hive tramite software di BI Tableau o tramite Hue, un’interfaccia utente Cloudera sviluppata per le applicazioni Web.

Zoosk ha scelto una soluzione integrata

Il sito di incontri online Zoosk utilizza una combinazione di Hive per ETL e Impala per le analisi anche con Hue e Tableau sul front-end per facilitare la codifica ai propri analisti. La società di San Francisco implementato un cluster Hadoop Cloudera-based nel 2012, inizialmente per elaborare i grandi volumi di dati relativi alle attività degli utenti e ai system log generati dal sito web, per poi passare le visualizzazioni aggregate delle informazioni a un enterprise data warehouse costruito su database Microsoft SQL Server. Martin Lam, senior director of analytics and data science presso Zoosk, ha detto che gli sviluppatori hanno inizialmente cercato di programmare in MapReduce per poi scoprire che stavano impiegando molto più tempo rispetto a quanto richiesto dall’utilizzo di SQL (un paio d’ore per scrivere e testare un lavoro, rispetto a un paio di minuti).

Così l’azienda ha implementato Hive per supportare l’elaborazione ETL nel cluster. Tuttavia, Hive si è rivelato troppo lento per supportare l’analisi ad hoc dei dati di Hadoop e per questo motivo l’azienda non ha scelto questa piattaforma di analisi. Le cose sono cambiate dopo che Cloudera ha rilasciato una versione beta di Impala, alla fine del 2012: le prestazioni del motore per le query hanno reso più fattibile l’analisi dei dati grezzi Hadoop. Lam ha riferito che, per esempio, in combinazione con Parquet (un formato di archiviazione a colonne per Hadoop che Zoosk aggiunto alla sua architettura a metà del 2015 – NdR) Impala può eseguire una query tipica sulle interazioni degli utenti sul sito Web in otto secondi, a fronte dei circa otto minuti necessari a completare l’operazione con il solo Hive e dei quasi sei minuti con Hive e Parquet insieme.

Le velocità più elevate hanno anche permesso l’aggiunta di applicazioni di analisi più avanzate: in particolare, di una applicazione di matchmaking comportamentale, che ha lo scopo di prevedere le possibili corrispondenze tra gli utenti Zoosk in base al loro utilizzo del sito. Zoosk rimane legato ad Hive sul lato ETL, nonostante l’elaborazione delle centinaia di milioni di righe di dati che cattura dal sito web ogni giorno, pari a circa 200 terabyte di informazioni nel cluster.

“Impala offre maggiore velocità – ha riferito Lam –  ma può essere imprevedibile se non si sta attenti. È più facile garantire che sarà Hive a finire un lavoro”.

Impala, inoltre, secondo l’esperto è ancora carente di alcune funzionalità SQL standard, come il supporto per le funzioni XML e JSON e per i tipi di dati non scalari come le mappe e gli array.

Una soluzione di analisi dei dati veloce per Fishbowl

Sanjog Gad, CTO di Fishbowl racconta nel libro di Stedman di aver notato grandi miglioramenti nelle prestazioni di elaborazione delle query di Apache Drill, un motore SQL-on-Hadoop open source supportato da MapR. In alcuni casi, le query inizialmente occupavano quindici minuti per l’esecuzione in Drill (che Fishbowl ha iniziato ad utilizzare nel 2015 come parte di un progetto di proof-of-concept con Hadoop), ma a seguito di continui miglioramenti della tecnologia di Drill i tempi oggi sono di circa venti secondi e Gad ritiene che diventeranno meno di dieci entro la metà del 2016.

Fishbowl, che raccoglie e analizza i dati dei clienti per catene di ristoranti, ha superato l’implementazione di prova di Hadoop e costruito un cluster MapR-based per supportare nuove applicazioni analitiche avanzate. Gad ha raccontato che l’azienda  Alexandria, con sede in Virginia, sta incanalando nel cluster dati da circa quindici diverse fonti, compresi point-of-sale, prenotazioni, ordini online, programmi di fidelizzazione e dati delle carte di credito. Entro la fine di quest’anno, il CTO di Fishbowl si aspetta di avere fino a 60 TB di dati nel sistema Hadoop e di espanderlo da dieci nodi di elaborazione a sessanta o più, via via che un maggior numero di ristoranti si registreranno per utilizzare il nuovo servizio di analisi.

La squadra di Gad non ha completamente voltato le spalle MapReduce. I processi ETL sui feed di dati giornalieri sono tutti effettuati attraverso il framework di batch processing, ritenuto dal team una tecnologia affidabile e scalabile per questo scopo. Ma il sistema SQL-on Hadoop è stato il modo più ovvio per operare sul fronte delle analisi, sia per motivi di prestazioni che di personale. “I data analyst e gli operatori della BI – ha soncluso Gad – sono tutti pratici di SQL e non capiscono molto di Hadoop e MapReduce”.

 

TechTarget

Articolo 1 di 5