DataSkills è una realtà che opera a tutto campo nel mondo della data science

Big Data aziendali: i tipi di supporto e i tipi di struttura

big-data-thumb

Big Data aziendali: i tipi di supporto e i tipi di struttura

25 luglio 2017
|
0 Comments
|

Nel corso del nostro ultimo articolo abbiamo introdotto l’ampio e complesso discorso dei dati aziendali, focalizzandoci soprattutto sulla loro importanza “economica” a patrimoniale per l’impresa ma parlando anche delle fonti, interne ed esterne, che quotidianamente li generano.

In questo nuovo contributo vi racconteremo invece quali sono i tipi di supporto e di struttura sui quali i dati aziendali sono normalmente ospitati, in modo da avere un quadro ancora più completo della loro varietà, quantità e importanza.

Cominciamo innanzitutto con l’illustrare le tipologie di supporto di questi Big Data.

La premessa da fare è che sia i dati interni che quelli esterni sono ospitati su supporti diversi. Per quanto riguarda invece le fonti operazionali, sono di solito contenute (eccezioni – poche – a parte) all’interno di database relazionali. Cosa sono questi ultimi? I database relazionali sono costituiti da tabelle (dette anche “relazioni”) realizzate secondo i principi della teoria relazionale, ossia che utilizza un insieme di termini matematici per definire concetti comunemente conosciuti con termini prelevati dalla tecnologia SQL.

Di norma, seppure al netto delle differenze che intercorrono tra la varie tecnologie e i vari vendor, le fonti operazionali dunque sono facilmente accessibili tramite le più classiche interrogazioni SQL. Vi sono tuttavia casi più complessi, generalmente legati all’utilizzo di mainframe, ossia di tecnologie legacy e di norma si riferiscono all’ambito bancario. In queste circostanze, non è raro che i dati siano esposti tramite la produzione di file di testo in vari formati quali CSV, TSV o record a lunghezza fissa.

Per quanto riguarda invece i data warehouse, questi si trovano esclusivamente su RDBMS, sia con tecnologia SMP che MPP. I cosiddetti SMP (Symmetric MultiProcessing) sono i sistemi che generalmente vengono impiegati per ospitare RDBMS e sono costituiti da una serie di processori che condividono il medesimo sistema operativo, la medesima RAM e lo stesso bus di Input/Output: non a caso si definiscono “shared everything”.

I sistemi SMP si rivelano estremamente efficienti nelle applicazioni OLTP ma presentano criticità quando vengono utilizzati per l’elaborazione di grandi quantità di dati, a causa del sovraccarico del bus di sistema che diventa, ahinoi, un vero e proprio collo di bottiglia. Al contrario, i sistemi MPP (Massive Parallel Processing) sono caratterizzati dal fatto che tutti i processori utilizzano risorse a loro dedicate (“shared nothing”) e comunicano tra loro tramite un’interfaccia di messaging. Ecco dunque che, proprio in funzione di queste specifiche peculiarità, questi sistemi sono decisamente più adeguati per la gestione di importanti masse di dati.

Per quanto riguarda infine le basi dati ad hoc, queste potrebbero essere ospitate sia in database relazionali che in fogli di calcolo e, in quest’ultimo caso, la loro lettura potrebbe risultare difficoltosa.

Scarica il primo capitolo

Struttura dei dati aziendali: presente, assente o a metà strada

Passiamo ora ai tipi di struttura, che rappresentano un altro parametro importante in base al quale possiamo classificare i dati aziendali. In realtà, più corretto sarebbe riferirsi piuttosto alla presenza o assenza di struttura per un’agevole e rapida identificazione di ogni attributo. Proprio in funzione di quest’ultima specifica, possiamo distinguere diverse tipologie:

  1. Dati strutturati: sono rappresentabili in formato tabellare all’interno di un database relazionale oppure presentano formati quali JSON e XML. Questi ultimi, assieme ai dati contengono anche metadati in grado di definire sia i nomi dei campi che la loro struttura. Quando i dati sono definibili come “rappresentabili in formato tabellare” non significa che debbano per forza trovarsi all’interno di un database, ma che potrebbero essere contenuti anche in file di testo in formato CSV – che permette una agevole e chiara divisione dei singoli campi.
  2. Dati non strutturati: generalmente sono quelli che non ha senso rappresentare in formato tabellare, seppure potrebbero essere inclusi in un database relazionale. Questi dati non hanno una struttura e dunque sarebbero contenuti come un intero blocco all’interno di una singola tabella, rendendo di fatto completamente inutile l’intera struttura. I dati non strutturati più classici sono ad esempio il contenuto testuale di un’email, di un pdf, di un tweet o di un post blog oppure i byte di un contenuto multimediale come un’immagine, un video o un file audio.
  3. Dati semi-strutturati: come suggerisce il nome, presentano sia una parte strutturata che una parte non strutturata. Un esempio calzante potrebbe essere un documento Word o pdf che contiene metadati ottimamente strutturati quali il titolo, l’autore, la data e via discorrendo, ma anche un “corpo” costituito essenzialmente da un testo. Allo stesso modo, anche le immagini presentano metadati specifici che identificano per esempio le coordinate GPS dello scatto, la data, l’ora e talvolta anche le impostazioni della fotocamera.

Da quanto spiegato finora risulta dunque evidente che lavorare con i dati non strutturati equivale necessariamente a trasformarli in modo che possano possedere una struttura.

Vogliamo fare un esempio pratico? Immaginiamo di dover svolgere un’analisi del sentiment di uno specifico pubblico attraverso una serie di tweet. Dopo una serie di operazioni preliminari finalizzate a “ripulire”, in linea di massima, il testo, si potrà procedere all’analisi tramite sistemi predittivi soltanto attraverso la creazione della cosiddetta document-term matrix. In pratica, si tratta di una matrice che riporta, sulle righe, i singoli tweet (documenti) e sulle colonne le singole parole (term). Nel punto di incrocio tra documento e parola comparirà un numero che indica le occorrenze di quella parola in quello specifico documento.

In definitiva, la costruzione della document-term matrix equivale alla produzione di un dataset strutturato di dati inizialmente non strutturati, fondamentale per una comprensione “automatica” del sentiment dei nostri tweet.

In conclusione di questo contributo vale la pena spendere qualche parola su un’ulteriore classificazione che distingue i dati: si tratta della provenienza, che differenza le informazioni generate dalle persone e quelle generate dalle macchine.

Ai dati generati dalle persone corrispondono sia dati esterni (come quelli provenienti dalle piattaforme social o dai siti di ecommerce), sia alcuni dati interni imputati manualmente tramite operazioni di data entry. Per quanto riguarda invece i dati generati dalle macchine, questi comprendono numerose casistiche:

  • Dati provenienti da strumenti di misurazione
  • Valori prodotti dai sensori
  • Dati di log di web server e router
  • Sistemi di calcolo
  • Device di lettura di codici a barre o sistemi analoghi

Va da sé che i dati generati in modo automatico siano meno soggetti a problemi di qualità, ma bisogna sempre e comunque tenere presente che anche i dispositivi elettronici possono essere soggetti ad anomalie.

Nel nostro prossimo contributo passeremo all’analisi degli attori aziendali nella produzione dei dati aziendali: non smettete di seguirci.

Big Data Analytics. Il manuale del data scientist

Big Data Analytics. Il manuale del data scientist

Compra su Amazon