5.2
Riempimento del DWH
Per ogni fonte `e stata messa a punto una procedura che legge i csv presenti nel datalake in Hadoop (HDFS) e li elabora.
Le procedure sono tra loro separate perch`e elaborano file differenti, come origine e come forma: ogni procedura si occupa di adattare i dati raccolti a partire da una delle fonti alla struttura precedentemente scelta come comune per tutte.
Anche se le elaborazioni per i diversi social/blog saranno diverse, la struttura di ogni procedura pu`o essere ricondotta alla forma:
Staging: Per prima cosa ogni riga di ogni csv viene trascritta in una tabella di staging. Si tratta di tabelle intermedie, utilizzate per rendere le fasi successive pi`u pulite e veloci.
All’interno di ognuna delle tabelle di staging i dati saranno ridondanti e caotici, ma inizieranno ad avere una struttura: lato positivo di aver a che fare con una tabella piuttosto che con un file `e che rimane pi`u semplice e veloce da interrogare, in particolare possiamo definire delle query ad hoc per ripulire i dati, andando a correggere o ad eliminare quei record che non hanno il formato corretto, o che semplicemente sono duplicati.
La logica di riempimento delle tabelle di staging si basa sul concetto di voler riportare nella tabella stessa tutto il contenuto di tutti i files relativi al social o al blog.
Ci troveremo di fronte molti post duplicati. Per ovviare a questo problema ab- biamo utilizzato un campo intero autoincrement come chiave primaria della tabella: in questo modo sar`a possibile inserire anche i post duplicati senza che vadano a creare conflitti.
Sar`a semplice andare ad eliminare i post doppi, baster`a creare le giuste query con le distinct o i raggruppamenti necessari.
Per poter comporre le suddette query abbiamo individuato quali campi per ogni fonte saranno identificativi di un post:
• Blog: filename, link, title • Facebook : idpost
• Twitter : id • Instagram: id
Dimensioni: Prima di popolare i fatti, vanno popolate le dimensioni. Ogni foreing key di ogni fatto dovr`a avere una corrispondenza nella relativa dimensione, quindi per prima cosa si inserisce un record tappo in ognuna delle dimensioni. Questa corrispondenza verr`a utilizzata per coprire tutte le corrispondenze mancanti: ad esempio nei post dei blog verr`a usato il record tappo per le coordinate geografiche, la lingua e il tipo del post, ovvero in corrispondenza di quelle informazioni che sono assenti, in Twitter si user`a per il tipo del post e cos`ı via.
Per popolare il restante contenuto della dimensione si leggono i valori distinti del campo corrispondente nella tabella di staging e si inseriscono nella tabella della dimensione senza creare duplicati.
Fatti: Una volta popolate le dimensioni si pu`o passare a popolare le tabelle dei fatti, quindi i post e i tag. Sar`a necessario popolare prima i post, a partire da ognuno di essi estrapoleremo l’elenco dei tag da inserire nella relativa tabella
Anche se le elaborazioni e le dimensioni calcolate sono diverse per ogni fonte, possiamo ricondurre le procedure di popolamento dei post ad un job con forma:
Si inizia con il recupero dalla tabella di staging di tutti i fatti da salvare. Si procede alla classificazione del fatto in Gruppo 0 o Gruppo 1 con logiche diverse a seconda della fonte.
Sono poi necessari alcuni calcoli per ricavare informazioni sulla data, sull’utente, sulle coordinate geografiche (l`a dove questi dati esistono, altrimenti si impostano dei valori costanti), successivamente si va in giunzione con le dimensioni.
Una volta calcolati tutti i valori da inserire nel fatto si procede a salvare il record con un’operazione di Insert/Update per evitare di inserire righe duplicate.
5.2 Riempimento del DWH
Una seconda procedura si occuper`a di popolare la tabella dei tag: il job legge dalla tabella t post e per ogni riga recupera l’elenco degli hashtag presenti nel post, poi salva in t tag tutte le corripondenze < tag, rif erimento del post >.
Il campo del riferimento al post corrisponde al suo id, ma non avr`a funzione di chiave esterna, servir`a soltanto per evitare di inserire due volte lo stesso tag in corripondenza dello stesso post (`e strano, ma spesso accade che in un post appaia pi`u volte lo stesso tag).
Ogni inserimento, sia nelle dimensioni, sia nei fatti `e preceduto da una serie di controlli sul formato e sul valore di tutti i campi: abbiamo potuto sfruttare alcuni passi forniti dall’ETL per effettuare correzioni di formato e filtering sui dati utilizzando anche le espressioni regolari.
Grazie a tutti questi accorgimenti e controlli in ogni fase del caricamento pos- siamo essere sicuri che nelle tabelle delle dimensioni e dei fatti sono registrati tutti e soli i dati raccolti e nel corretto formato, pronti per essere analizzati.
Dal caos iniziale abbiamo rimesso ordine, strutturato e dato senso ai dati raccolti: rimossa l’entropia adesso possiamo creare i cubi e concentrarci sull’interpretazione dei report.
6.1
Creazione dei cubi
Creare un cubo significa costruire uno schema, una sorta di chiave di lettura dei dati presenti nel DWH.
Pentaho utilizza Mondrian, un OLAP engine in grado di interpretare query in linguaggio MDX. Mondrian in questo senso ha un ruolo da traduttore: riproduce le query MDX ricevute in query SQL e trasforma i risultati relazionali ottenuti in risposta all’esecuzione dell’SQL sul DB in risultati multi-dimensionali, il tutto basando l’interpretazione dei dati del DWH sullo schema che definisce i cubi, le dimensioni e le gerarchie.
Figura 16: Overview delle componenti di Pentaho legate ai metadati
Il client tool utilizzato in questa fase `e Pentaho Schema Workbench: esso offre un’interfaccia grafica per la creazione degli schemi Mondrian (matadati ), inoltre `e in grado di pubblicare lo schema stesso sul server Pentaho: una volta pubblicato lo schema `e utilizzabile da Mondrian.
Uno schema `e essenzialmente un documento xml che descrive uno o pi`u cubi multidimensionali. I cubi descrivono anche il mapping delle dimensioni e delle mi- sure su tabelle e colonne della base di dati. Attraverso lo schema si crea una sorta di ulteriore strutturazione dei dati, astratta e finalizzata ad elaborazioni analitiche.
In conformit`a con la struttura del DWH, in cui abbiamo individuato 2 fatti, anche in questo caso nello schema abbiamo definito 2 cubi, e per ognuno di essi sono state specificate una serie di misure e l’elenco delle dimensioni di analisi.
6.1 Creazione dei cubi
Figura 17: Schema: Cubi
Per quanto riguarda le dimensioni, nel nostro caso la maggior parte sono comuni tra i due cubi, quindi si `e scelto di trattarle come dimensioni condivise: ogni di- mensione `e stata creata esternamente ai cubi, ne sono state specificate le gerarchie e successivamente `e stata istanziata nei due cubi.
Nel caso della data abbiamo considerato la dimensione due volte in modo da tenere separate le gerarchie precedentemente individuate relative al giorno dell’anno e al giorno della settimana.
Figura 18: Schema: Dimensioni condivise
Unica dimensione non condivisa si trova all’interno del tag e riguarda il nome stesso del tag. In effetti notiamo che questo `e l’unico caso in cui la dimensione `e stata definita direttamente all’interno del cubo.
Questa dimensione ha natura degenere, come anche la lingua, il gruppo e il ti- po del post. Nonostante questa caratteristica tutte le dimensioni sono state gestite come quelle standard: individuarle nella schema come vere e trattarle come tali
permette non solo di poterle utilizzare e visualizzare nei report, ma soprattutto di dare allo schema un’impostazione di base pi`u flessibile, tale da permettere modifiche e aggiustamenti successivi agevoli.
Come possiamo notare, a questo livello ogni gerarchia `e gestita separatamente dalle altre, a prescindere che i dati siano fisicamente salvati nella stessa tabella. E’ stato necessario separare le gerarchie per permettere tramite l’Analyzer di utilizzarle ognuna in modo indipendente.