Molte aziende stanno faticando a trovare data analyst da inserire nel proprio organico. Molte posizioni si sono aperte in un periodo troppo breve per permettere a università, master e corsi specialistici di adeguare la propria offerta e cominciare a sfornare professionisti formati. Ragion per cui, spesso queste posizioni vengono ricoperte da persone a cui mancano parte delle competenze necessarie a creare il giusto mix, che è composto da robuste basi matematiche e la capacità di scrivere software, o quanto meno descriverne le funzioni a uno sviluppatore vero e proprio.

Negli scorsi mesi abbiamo più volte presentato Python come un linguaggio di programmazione particolarmente adatto a trattare dati a scopo di analisi o addestramento di modelli di intelligenza artificiale. Se il software rappresenta il motore di un progetto di analisi dei big data, la sua benzina però è rappresentata dai dati, che devono essere preparati, organizzati e resi disponibili sotto forma di database.

In questo articolo ci concentriamo sul linguaggio più utilizzato nelle interazioni con archivi Big Data organizzati e strutturati in tabelle relazionate tra loro. Per poter però apprezzare l’importanza di questa soluzione è necessario prima ripercorrere una panoramica sulle tipologie di sorgenti dati visto e considerato che i contesti Big Data contemplano informazioni organizzate in maniere molto differenti tra loro.

Tipologie di archivi di dati

Riassumendo per sommi capi, possiamo dire che gli archivi di dati possono essere classificati in tre famiglie principali:

Dati strutturati

Si tratta di una tipologia di dati estremamente comune e uno degli approcci più naturali che l’essere umano usa per organizzare le informazioni. Si tratta di archivi dove le informazioni sono chiaramente etichettate e organizzate in modo lineare. Per esempio, una tabella strutturata in righe che definiscono differenti entità (record) a cui corrispondono valori ben definiti organizzati nelle colonne (campi). Ogni campo avrà un proprio nome e una tipologia di dato che vi corrisponderà (numero intero, numero decimale, stringa, data eccetera). Tutto questo lavoro rappresenta la creazione di una struttura per i nostri dati.

Dati non strutturati

Sono caratterizzati dalla totale assenza di una struttura e possono pertanto ospitare informazioni in una maniera non prevista e non prevedibile all’origine. Tale impostazione appare assolutamente naturale per le moderne forme di archiviazione di informazioni come i Social Network dove ogni oggetto che viene rappresentato può essere costituito da testo, una o più immagini, video o file di altro genere, senza alcuna struttura predefinita.

Dati semistrutturati

Seguono una struttura di massima ma offrono delle deroghe per poter inserire ulteriori informazioni non prevedibili a priori. In tali casi si potrebbe per esempio avere una tabella in grado di rappresentare la strutturazione delle parti comuni dei vari oggetti dove le righe vengono collegate a ulteriori informazioni poste al di fuori di essa, magari collocate in file salvati su un archivio separato dalla tabella.

Quando usare una struttura dati e quando farne a meno

Queste tre tipologie di dati sono pertanto adeguate a scopi diversi. Con un po’ di esperienza, ogni volta che si affronta l’organizzazione di un archivio di dati viene piuttosto spontaneo intuire se sia più adeguata la via strutturata, quella non strutturata o una soluzione semistrutturata, sebbene ogni problema potrebbe spesso essere affrontato con soluzioni diverse.

Per esempio, se vogliamo creare delle informazioni all’interno delle quali sappiamo sistematicamente quali generi di dati verranno inseriti probabilmente il tipo di archiviazione strutturata sarà più consono.

Se pensiamo a dati finanziari come la registrazione dell’andamento giornaliero di un titolo azionario, ogni evento registrato rappresenterà una sua quotazione in una data specifica. Pertanto, i campi necessari saranno sempre gli stessi, potremmo supporre: data, prezzo di apertura, prezzo di chiusura nonché massimo e minimo della giornata. Nessuna registrazione di dati riserverà delle sorprese, ogni giorno avremo sempre e solo bisogno di queste informazioni: questo è un tipico esempio di dato strutturato.

Qualora volessimo piuttosto creare una app mobile per la registrazione di momenti, ricordi o esperienze attraverso i nostri dispositivi mobili probabilmente a seconda delle situazioni potrebbe interessarci salvare un pensiero o alcune foto o video. Quindi prevedere una struttura per un archivio di questo genere sarebbe non solo molto difficile ma anche limitante per l’applicativo stesso: casi simili sono perfetti per un approccio non strutturato.

Un ulteriore fattore da non dimenticare è che la scelta che viene operata al momento dell’organizzazione è spesso fortemente vincolante, non solo per la disposizione dei dati già esistenti ma anche per i futuri inserimenti nonché per le evoluzioni in generale del prodotto software.

I dati strutturati al giorno d’oggi

Nonostante al giorno d’oggi capiti spesso di porre l’accento sulla grandissima diffusione che hanno avuto i dati non strutturati e semistrutturati, i dati strutturati costituiscono ancora una buona parte degli archivi esistenti. Questo non solo perché i dati storici sono spesso ispirati a tale organizzazione, ma anche perché tanti fenomeni da monitorare, registrare e poi successivamente analizzare sono caratterizzati per loro natura da una struttura interna molto rigida.

Le tecnologie per Big Data sono nate con una fortissima attenzione alla potenziale diversità dei dati provenienti dalle varie sorgenti con la necessità spesso di integrarle tra loro. Una facile dimostrazione di ciò è la cosiddetta legge delle 3V che spesso si incontra all’inizio dello studio dei Big Data. Questa prende il nome da tre termini che iniziano tutti con la lettera V e che sono stati visti sin dall’inizio come fortemente caratterizzanti di molte situazioni nella nuova società dell’informazione:

  • velocità;
  • varietà;
  • volume.

Di questi termini quello centrale in questa trattazione è il secondo, la varietà ovvero la grandissima diversità che può caratterizzare gli archivi di dati che potrebbero essere classificati come fonti Big Data.

Linguaggi di programmazione e Big Data

Il linguaggio SQL rappresenta l’approccio più comune ai dati strutturati ed è uno dei linguaggi più conosciuti al mondo. Viene infatti studiato da programmatori di qualsiasi livello, utilizzato in suite di ufficio, impiegato in ogni genere di applicazione. Quando le aziende si trovano ad affrontare settori nuovi come può essere quello dei Big Data, tipicamente hanno necessità assoluta di formare risorse aziendali o assumerne di nuove che siano in grado di affrontare le sfide tecnologiche poste dagli scenari attuali.

Per quanto riguarda i Big Data, uno dei primi approcci con cui si affrontano le problematiche di analisi consiste nell’utilizzo di framework e librerie software dedicate all’interno di linguaggi di sviluppo. Tra i vari linguaggi di programmazione potremmo citarne alcuni tra i più diffusi:

  • Java, uno dei più utilizzati in questo ambito. Tanti framework per l’analisi di dati in contesti Big Data sono stati realizzati proprio su questa tecnologia;
  • Scala, altro linguaggio derivato da Java, è stato utilizzato per la realizzazione di Apache Spark uno dei framework più impiegati attualmente e sul quale torneremo a breve;
  • Python, linguaggio che come abbiamo visto è onnipresente nei contesti di sviluppo per l’analisi dati.

Tutte queste soluzioni sono tuttavia adeguate principalmente a un pubblico di informatici e che abbiano tra l’altro anche una certa esperienza nello sviluppo di software, in quanto non sempre un’applicazione per Big Data è spesso il miglior banco di prova per un programmatore alle prime armi.

A questo punto possiamo ben comprendere perché in questo scenario si affacci prepotentemente SQL che:

  • è estremamente diffuso nonché amichevole da imparare per chi non lo conoscesse ancora;
  • nasce espressamente per l’analisi dati a differenza di Java, Scala e Python che sono linguaggi general purpose;
  • è perfetto per dati strutturati;
  • è conosciuto da persone che, sebbene a livelli diversi, si sono sempre occupate di analisi dati.

SQL è stato infatti adottato ben presto da framework idonei all’uso di Big Data dove fossero presenti archivi di dati strutturati. Ne potremmo citare molti ma a titolo di esempio vogliamo presentarne uno che domina fortemente l’orizzonte attuale: Apache Spark.

Apache Spark e SQL

Apache Spark, nato come alternativa più efficiente a Hadoop (una delle prime importanti soluzioni del settore), si è distinto da subito per efficienza e modularità.

Offre API per i linguaggi Java, Scala e Python (con la distribuzione PySpark) nonché R, linguaggio statistico molto diffuso negli ambienti scientifici.

Offre inoltre il modulo SparkSQL, ideato appositamente per lavorare con dati strutturati distribuiti su cluster e pertanto idonei per contesti Big Data.

Supponiamo di avere un grande archivio di dati strutturati, immaginiamo tantissime righe dove ognuna riporti informazioni su specifiche persone. Un’elaborazione su di essa potrebbe essere qualcosa del genere:

SELECT
        name,
       surname,
        age,
        city

FROM people

 WHERE age >= 18;

Una porzione di codice così è assolutamente comprensibile da qualsiasi programmatore ma, essendo questo linguaggio nato con l’intento di usare statement somiglianti il più possibile a frasi in inglese, sarebbe probabilmente comprensibile a molte persone non particolarmente esperte di informatica.

La semplicità di tale sintassi si unisce però con la complessità di gestione dei dati, mascherata del tutto da Spark. Usando questo esempio in un normale database, people non sarebbe altro che una tabella dalle dimensioni del tutto gestibili ma in un contesto Big Data, people, può essere un grandissimo archivio, distribuito su più macchine di un cluster collegate in rete e orchestrate nel complesso da Spark.

L’effetto che produce l’impiego di SQL nei Big Data è proprio questo: grandissima semplicità di sintassi abbinata a una struttura di ingegneria dei dati altamente complessa ma al contempo del tutto oscurata agli occhi del programmatore e gestita in toto da Spark.

Altra importante opportunità che si ha in Spark è quella di poter usare il linguaggio SQL all’interno di normali programmi. Il trattamento dei dati in SparkSQL, sia condotto tramite SQL, sia condotto tramite un linguaggio generico come Python porta in entrambi i casi alla creazione di strutture dati distribuite dette DataFrame che, indipendentemente dal linguaggio che le ha generate, possono sempre essere utilizzate congiuntamente.

Per esempio, se il nostro programma su Spark viene scritto in Python perché permette di gestire meglio i vari passaggi di un algoritmo ma a un tratto dobbiamo fare accesso a dei dati strutturati per cui SQL sarebbe l’ideale possiamo usarli insieme con la funzione sql offerta dalla SparkSession (un oggetto che fa da ponte tra il nostro programma e il framework Spark) nell’esempio seguente rappresentato dal riferimento spark:

results = spark.sql(
                        " SELECT
                       name,
                       surname,
                       age,
                       city

FROM people

WHERE age >= 18")

Conclusioni

Un contesto articolato e nuovo come quello dei Big Data può generare perplessità sia nel neofita che vi muove i primi passi, sia nell’azienda che vi si affaccia cercando nuove opportunità, eppure la presenza di una soluzione come il linguaggio SQL può essere rassicurante per entrambi. Se pensiamo che analizzare dati è un lavoro del tutto diverso da quello di amministrazione del cluster e dei data lake, possiamo immaginare come chiunque abbia qualche esperienza con SQL possa essere impiegato rapidamente in progetti di Data Science senza alcuna preoccupazione di come quella grande quantità di dati andrà gestita.

Basteranno alcune informazioni di massima sulla struttura delle tabelle da interrogare e si potrà essere da subito operativi anche sui Big Data grazie a SQL.