Come avevamo previsto nel Focus di febbraio e marzo, il 2015 si sta dimostrando l’anno in cui SQL su Hadoop sta guadagnando livelli incredibili di interesse e impatto, oltre a emergere – ed esplodere – sul mercato
Considerato che un numero sempre maggiore di aziende passa dai metodi di business intelligence tradizionali di query, analisi e reporting dei dati verso il modello altamente iterativo e interattivo di data discovery, con nuovi dati di struttura e volumi più diversi – sta diventando sempre più critica la capacità di caricare, accedere, integrare ed esplorare i dati. E mentre Hadoop si sta conquistando l’accettazione e l’adozione come sistema di data management costruito da zero per essere conveniente, scalabile e capace di lavorare in maniera flessibile con i dati – SQL – cioè lo Structured Query Language, è diventato la chiave per svelare il reale valore di business all’interno della nuova data discovery con un metodo tradizionale.
Maggiore è il numero degli utenti che possono prendere parte al processo di discovery, maggiore è il valore che può essere realizzato. I pochissimi data scientist in azienda, e anche gli utenti esperti abilitati, possono solo scalfire la superficie del valore di business della discovery, e anche questo alla fine si appiattirà nel corso del tempo. Invece, è bene posizionare questi utenti come gli abilitatori per gli utenti occasionali in azienda che hanno bisogno di accesso (gli scopritori che “sanno quando lo vedono”) e che beneficiano maggiormente dall’avere la capacità di interagire ed esplorare i dati in modo familiare e autosufficiente.
Oggi, l’analista autosufficiente richiede la capacità di accedere ai dati, caricarli su Hadoop, esplorarli in modo iterativo e ricorrere al “fail fast” per scoprire insight nascoste all’interno dei dati. Questo sfida la gestione dei dati e i data warehouse tradizionali principalmente tramite schemi e controlli. Tuttavia, l’utilizzo di SQL per la discovery sfrutta decenni di familiarità, adozione e maturità esistenti all’interno degli strumenti già installati negli ecosistemi tecnologici di oggi. Per esempio, molti dei formati raw dei dati e degli strumenti di visualizzazione intuitivi dei fogli tipo Excel sono fortemente dipendenti da SQL. Pertanto, gli analisti e gli utenti beneficiano immediatamente dall’avere capacità SQL altamente iterative e con elevate prestazioni all’interno di Hadoop.
Sbloccare il valore dei big data nella discovery dipende molto dalla capacità di eseguire SQL, perché è già così pervasivo, accoppiato con funzionalità che hanno prestazioni e capacità. Tuttavia, non tutti i motori SQL sono creati uguali, e maturano tutti in modo diverso, con una storia o un DNA differente. Non solo: alcuni hanno iniziato da poco, mentre altri stanno capitalizzando su anni di funzionalità di database. Ecco perché nelle tre aree seguenti vi sono considerazioni da fare al momento di valutare la potenza di SQL su Hadoop.
Funzionalità SQL – Al primo posto, c’è la funzionalità SQL. Abbiamo imparato dai database relazionali già esistenti che non tutti gli SQL sono uguali: ce ne sono alcuni specifici per vendor, e mentre i vendor possono eseguire SQL, questi possono essere di numerose versioni, come SQL 99 o SQL 92, oppure di funzioni analitiche successive come ANSI SQL. Se si dispone di strumenti esistenti e report che si intende connettere a Hadoop, non si desidera riscrivere le istruzioni SQL e assicurarsi che funzioneranno in strumenti e le applicazioni esistenti.
La compatibilità con il SQL standardizzato, o con SQL più maturi e avanzati, riduce al minimo le rilavorazioni. E, senza la funzionalità SQL e la maturità, molte funzioni analitiche non saranno in grado di operare in ogni caso. Tenendo presente questo, bisogna guardare alla roadmap del vendor per capire quali funzioni analitiche hanno a disposizione per uno o due anni.
Scalabilità – La seconda area è quella della scalabilità. Con un ampio cluster formato da molti nodi, vi è l’assunto che il motore SQL operi su tutti i nodi del cluster, ma bisogna tuttavia essere consapevoli di alcune limitazioni. Per esempio, se si hanno 100, 500, o migliaia di nodi, forse il motore SQL non è in grado di funzionare su tutto questo ed è limitato per funzionare solo su 16 o 32 nodi alla volta. Tra i primissimi utilizzatori, alcuni hanno isolato aree dei cluster per poter eseguire SQL su motori Hadoop, realizzando di conseguenza un’architettura a più livelli in singoli cluster.
Inoltre, bisogna essere consapevoli della duplicazione di dati determinata dal formato dei file di dati all’interno di HDFS. I dati sono all’interno di un file aperto, quale un ORC (Optimized Row-Column) o un Parquet, o richiedono l’estrazione da questi file in un formato di file proprietario che non può essere letto da altri motori all’interno di Hadoop? Quindi attenzione alla duplicazione di dati al fine di alimentare il motore SQL su Hadoop.
Velocità – Infine, è tutta una questione di velocità. La velocità ha importanza, soprattutto in termini di tempo di risposta, e ancor di più dalla prospettiva della discovery, dove l’obiettivo è quello di scoprire in fretta attraverso un “fail fast” iterativo. Se si sa che si incontreranno fallimenti 99 volte prima di trovare il primo insight, si cerca di spostarsi attraverso quelle 99 iterazioni il più rapidamente possibile. Attendere 700 secondi per la risposta a una query o per un processo batch può essere una forma dolorosa di analisi, nella quale è possibile scoprire i propri livelli di pazienza prima di qualsiasi approfondimento dei dati.
Pensare a lungo termine – Quando si sceglie un SQL su motore Hadoop, bisogna prendere in considerazione, con una visione ampia, le proprie strategie e architetture dati, assicurandosi che siano allineate. L’architettura per SQL su Hadoop continuerà a evolversi: è già passata dal batch-oriented Hive su MapReduce in Hadoop versione 1 all’Hadoop versione 2 dell’anno scorso, che ha aggiunto i benefici dei file ORC con Hive e TEZ per operare su YARN nelle query vettorializzate che ha portato notevoli incrementi di prestazioni a Hive 13. Oggi, vediamo “SQL architetturale”, con Hive e TEZ in esecuzione su YARN all’interno dei cluster, e possiamo anche iniziare a portare altri motori eseguiti direttamente con HDFS. L’architettura è un elemento di differenziazione tra SQL sui motori di Hadoop che sono già compatibili con YARN e quelli che incrementano le prestazioni andando direttamente con HDFS e cercando compatibilità in strategie a lungo termine.
In ultima analisi, SQL sta diventando sempre più parte della storia dell’unificazione delle piattaforme dati. Grazie a SQL, si possono mettere insieme i dati aziendali, gli analytics di fascia alta e i set di big data che vivono in Hadoop, potendo quindi iniziare a lavorare con tutti questi attraverso un linguaggio unificante.
John O’Brien
La combinazione dei diversi ruoli che ha svolto come professionista, consulente e vendor, rendono unico e originale il suo punto di vista. Con 25 anni di esperienza nei settori Data Warehousing e come esperto riconosciuto nel settore BI, ha pubblicato numerosi articoli ed è intervenuto come speaker in importanti conferenze negli Stati Uniti e in Europa. Oggi, John O’Brien svolge attività di ricerca e offre servizi di strategic advisory, per guidare le aziende verso la nuova generazione dell’Information Management.
John O’Brien presenterà a Roma per Technology Transfer i seminari “Data Discovery in Action” nei giorni 18 e 19 novembre 2015 e “Modern Data Visualizations and Story Telling” il 20 novembre 2015.
