Note di Data Warehouse e Business Intelligence - Pensare "Agile"

Pensare «Agile» deve essere una metodologia, una filosofia

progettuale da applicare a tutto il ciclo di vita

del progetto.

INTRODUZIONE

Un progetto di Data Warehouse e Business Intelligence, è un lavoro lungo e complesso che richiede molti

mesi, spesso anni, sopratutto se parliamo di Enterprise Data Warehouse, per poter vedere la luce.

Anzi, penso che dovremmo smettere di chiamarlo progetto, ma dovremmo chiamarlo Processo. Però non è

un processo qualunque: è il processo che trasforma i dati in conoscenza, la conoscenza in previsione, la

previsione in azione. Applichiamo per fare un esempio, questo processo al mondo CRM (Customer

Relationship Management).

I dati grezzi dei clienti che giungono da sistemi diversi, si trasformano nella maggiore conoscenza dei clienti

e delle loro preferenze. Dalla conoscenza dei clienti possiamo prevedere le loro attitudini future. La

conoscenza del futuro ci permette di agire per cambiarlo o adattarlo. Questo è quello che ci permette il

processo di Data Warehouse e Business Intelligence.

Potete bene immaginare come questo processo sia indispensabile per ogni azienda che voglia competere

sul mercato globale. Purtroppo quello che spaventa di più gli investimenti in progetti di Data Warehouse è il

tempo. Infatti il fattore tempo è cruciale, e nella frenetica vita odierna, non si vuole attendere e si cercano

scorciatoie per avere i risultati attesi nel più breve tempo possibile. Ecco perchè si parla di Agile Data

Warehouse.

COSA È E COSA NON È L'AGILE DATA WAREHOUSE

Chiariamo subito cosa non dovrebbe essere.

Non deve essere un prodotto commerciale o un tool venduto da qualche società.

Non deve essere un Database o un diverso design della struttura tabellare logica o fisica.

Deve essere una metodologia, anzi una filosofia progettuale da applicare a tutto il ciclo di vita del processo.

Poichè mi piace essere pragmatico, provo subito a entrare nella realtà del processo.

2Micro ETL Foundation

Idealmente e, molto semplicemente,possiamo suddividere un processo di Data Warehouse in tre macrofasi

principali.

Sottolineo semplicemente,perchè dietro queste macrofasi, ci sono numerose fasi progettuali che

conosciamo bene (raccolta dei requisiti, analisi, programmazione,..).

Build: Tutta l'attività di caricamento che porta alla fase di test.

Test: Tutta l'attività di verifica e controllo che, prima e dopo il deploy in produzione, termina con

l'accettazione del sistema fatta dagli utenti finali.

Maintenance and Iterative evolution: tutta l'attività inerente alla gestione e alla crescita del Data

Warehouse.

Per realizzare con successo un Processo di Agile Data Warehouse, dobbiamo essere «agile» in ognuna di

queste componenti.


Build Test

Maintenance

and Iterative

evolution

BUILD

Dobbiamo essere agile nella fase di costruzione. C'è poco da spiegare. Questa necessità si comprende

facilmente.Dobbiamo cercare di ridurre il più possibile i tempi del processo ETL che, storicamente, è la fase

più time-consuming del processo.

TEST

Dobbiamo essere agile nella fase di test e collaudo. Questa fase è critica perchè è la fase in cui gli utenti

finali iniziano a vedere i dati e iniziano a valutare il risultato ottenuto.

Questo significa essere rapidi nei tempi di risposta agli utenti finali. Attenzione. Non sto parlando dei tempi

di risposta dei report o delle query sul Data Warehouse (questo lo dò per scontato) ma nei tempi di risposta

alle cause di anomalie e problemi. Mi spiego meglio.

Come affermato all'inizio, dobbiamo essere agile in tutto il ciclo di vita del Data Warehouse. Molti

penseranno che essere agile significa solamente giungere al deply in produzione in tempi brevi.

In pratica riuscire ad accelerare il più possibile il processo ETL al fine di mettere a disposizione degli

utenti finali i Data Mart per le loro analisi. Ma questa è solo una parte della storia.

A mio avviso, il momento più importante in cui dobbiamo essere “agile” è DOPO avere concluso la parte di

build. Il vero successo del Data Warehouse dipenderà da quanto saremo veloci nel rispondere alle

domande degli utenti finali, alla loro contestazione dei dati visualizzati, nell’identificare i problemi del

processo di caricamento, nel sapere dove sono avvenuti e perché.

E dobbiamo essere agile nella risoluzione dei problemi.

MAINTENANCE AND ITERATIVE EVOLUTION

Infine dobbiamo essere agile nella manutenzione ed evoluzione iterativa. Questo vuol dire che dobbiamo

rispondere velocemente alle richieste di modifica del sistema e sopratutto della sua evoluzione. Non

dimentichiamo che è un processo.


Non dimentichiamo che sulla base di un Data Warehouse iniziale, poco per volta si aggiungeranno, nel

tempo, nuove dimensioni di analisi e nuovi Data Mart da analizzare. E molto probabilmente sarà

necessario aggiungere nuove informazioni alle Dimensioni e ai fatti già costruiti.

Spero che ora sia chiaro cosa vogliamo ottenere quando parliamo di agile Data Warehouse. Ma il punto

essenziale è come raggiungere questi obiettivi. Come detto precedentemente, non è necessario un

prodotto, ma solo una buona metodologia. Ecco alcuni consigli personali dettati dall'esperienza.

Possiamo agire su vari aspetti, molti dei quali sono già stati oggetto di riflessioni sul mio Blog o su

Slideshare.

AGILE NEL BUILD - NAMING CONVENTION

Non mi stancherò mai di sottolineare l’importanza di impostare una precisa naming convention per tutti gli

oggetti del progetto. Lo dobbiamo fare subito, prima di creare qualunque tipo di struttura informativa.

Questo ci permetterà di avere una visione chiara e una gestione semplificata di tutte le componenti logiche

e fisiche (tabelle, sequenze, viste, files, documentazione, ecc.) che costituiscono il Data Warehouse.

Non solo. Seguire una precisa naming convention ci permette di creare degli automatismi di

configurazione,creazione e controllo molto velocemente.

AGILE NEL BUILD – RIDUZIONE DELLA CATENA ELABORATIVA

Un altro punto da considerare è la filosofia di modellazione del Data Warehouse. Anzi, probabilmente è la

prima cosa da considerare. Non voglio entrare nello storico dibattito relativo all'approccio Inmon e

all'approccio Kimball.

Entrambi sono validi con i loro punti di forza e di debolezza.


Però se parliamo di "agile", per me la scelta dell'approccio Kimball è fondamentale. Tutto quello che mi

permette di ridurre la catena elaborativa e strutturale presente nel processo ETL è senza dubbio un fattore

importante.

Penso che avere un ODS (Operational Data Store), cioè in pratica una duplicazione storicizzata di quasi

tutte le strutture già presenti in Staging Area, prima delle strutture dedicate all'analisi, è una attività che

costa tempo e denaro.

AGILE NEL BUILD – SEMPLIFICAZIONE DEI TIPI

Un altro modo per essere “agile” è una conseguenza della regola generale di pensare sempre in modo

semplificato. Dobbiamo ridurre al minimo i tipi di dati (nel senso di database) presenti nel Data Warehouse.

Un RDBMS come Oracle, e lo stesso discorso vale per gli altri produttori, ha più di 30 tipi di dati diversi

(NUMBER di vario tipo, CHAR, VARCHAR, DATE, ecc).

Non possiamo pensare di avere questa varietà di tipi nel Data Warehouse. Troppe complicazioni nel loro

trattamento e conversione.

Provate a pensare ai flussi di alimentazione: tranne alcuni casi particolari, sono tutti files di testo.

A lunghezza fissa o con terminatore di colonna, sono sempre files che potete facilmente aprire con un

qualsiasi editor di testo. Il massimo della semplicità. Il mio consiglio è di mantenere quasi intatta questa

semplicità imponendo nel Data Warehouse solo due tipi di dato.

Numerico – solo per dati di tipo importo, quantità, percentuale, ecc.

Alfanumerico – per tutti gli altri dati.

Manteniamo il tipo di dato DATE solo per campi tecnici, tipo data di inserzione, ultimo aggiornamento,ecc.

Anche se nei sistemi alimentanti i dati che rappresentano dei codici, indicatori, flag, sono numerici,

manteniamoli alfanumerici nel Data Warehouse. Tutte i dati che rappresentano delle date, trasformiamoli

in alfanumerico e in formato standard YYYYMMDD.


AGILE NEL BUILD – SEQUENZIALITA’

Dobbiamo cercare di pensare, e nel 90% dei casi si può fare, che ogni componente del processo sia

collegata a quella successiva, e che la loro esecuzione sequenziale porti al caricamento finale del Data

Warehouse.

Intendiamoci, non sto dicendo che non è possibile il parallelismo, ma individuare quali componenti siano fra

loro completamente indipendenti al punto da poter girare in parallelo, non è un compito facile; senza

contare tutti i ragionamenti necessari alla loro sincronizzazione.

Inoltre il parallelismo richiede anche configurazioni hardware particolari e impostazioni del database

particolari per beneficiare effettivamente di un miglioramento delle performance che, parlo per esperienza,

non è affatto scontato.

Certamente, le tabelle dimensionali potrebbero essere caricate in parallelo (se non ci sono collegamenti

logici fra di loro) ,ma in ottica "agile" dobbiamo cercare di ragionare in modo semplice e sequenziale.

Non dimentichiamo che il processo ETL, per sua natura è fisiologicamente sequenziale. Non si può

caricare un Data Mart di livello 2 se prima non si sono caricati quelli di livello 1. Il Data Mart di livello 1 non

è caricabile se prima non si sono caricate le Dimensioni di analisi, che a loro volta, non si possono caricare

se non sono state caricate le tabelle di staging area, e così via.

AGILE NEL BUILD – RIDUZIONE DEI TOOL ESTERNI

E’ una scelta progettuale, dipendente da molti fattori, se e quale strumento utilizzare per l’implementazione

del Data Warehouse. Ogni Company ha le sue regole e, soprattutto un budget disponibile. Se avete molto

denaro a disposizione (e sopratutto un sacco di tempo nell'imparare a usarli) comprate pure i tool.

Se il vostro budget è scarso, il mio consiglio è quello di utilizzare il minor numero possibile di strumenti.

Spesso si tende a cercare strumenti specifici per fare lavori come quadrature, controlli di processo, controlli

di qualità, schedulazione, ecc.


Non dimentichiamo che ognuno di essi ha strutture proprie, che devono poi dialogare con tutte le altre,

aumentando la complessità dell’intero sistema.

La mia opinione è qualla di investire molto di più nell’avere una ottima conoscenza del linguaggio di

programmazione del Database ,un buon editor e un buona interfaccia di accesso al Database.

Questi tre elementi, da soli, ci faranno risparmiare molto tempo.

AGILE NEL TEST - CONFIGURATIONE E LOG

Per essere agile in questa fase, dobbiamo avere costruito un'architettura di controllo molto precisa. Ho già

scitto molto su come segnalare automaticamente le anomalie e avere il controllo dei moduli di un processo

ETL. Il mio consiglio è di avere sempre presente la magica coppia di strutture (tabelle): configurazione e

log. Al minimo:

Configurazione del caricamento della Staging Area - Log del caricamento della Staging Area

Configurazione del caricamento delle tabelle dimensionali - Log del caricamento tabelle dimensionali

Configurazione del caricamento delle tabelle dei fatti - Log del caricamento tabelle dei fatti.

AGILE NEL TEST – DATA LINEAGE

Avere una struttura di Data Lineage significa essere in grado di percorrere tutto il cammino della

informazione vista dall'utente finale, a ritroso fino all'origine del dato. Complicato, non sempre possibile

(vedi i dati calcolati) ma essenziale per dimostrare la correttezza del processo di caricamento.

Per dirla in parole povere, dobbiamo poter dimostrare che l'anomalia era già presente nel flusso

alimentante. Quindi sarà necessario utilizzare alcune tabelle di metadata per gestire il Data Lineage


AGILE NELLA MAINTENANCE AND ITERATIVE EVOLUTION - MODULARITÀ (E INCERTEZZA)

Per essere agile in questa fase dobbiamo essere modulari. E' l'incertezza che ci costringe a essere

modulari. Incertezza non nel senso che è ammesso essere incerti su come procedere, ma nel senso di

essere certi che qualcosa cambierà. Mi spiego meglio.

In un processo di Data Warehouse, è raro che tutte le logiche siano ben definite già dall’inizio. Non

bisogna necessariamente pensare a carenze di analisi (che spesso ci sono) o a errori nella raccolta dei

requisiti: il problema è che le logiche si evolvono man mano che si procede nel lavoro. Lo ritengo un

processo naturale, legato alla complessità del sistema, con cui si deve fare i conti senza drammi.

I sistemi alimentanti forniscono dei dati che non è detto siano precisamente quelli attesi dall’analisi, sia

come formato che come contenuto.

Questo spesso lo si scopre dopo, quando i dati iniziano ad essere analizzati (e quindi dopo averli caricati).

Gli utenti di business cambiano idea, a volte il business stesso cambia indirizzo. Si scopre, dopo,

che serviva anche un altro dato non previsto dall’analisi. Gli utenti vogliono fare il confronto anche con

altri dati che non erano stati previsti, ecc..

Esiste un detto molto eloquente relativo alle esigenze degli utenti finali. Il detto è: “I will know when I will

see”. Saprò quello che voglio quando lo vedrò. Assolutamente vero.


Questo ci obbliga a modificare continuamente i programmi per venire incontro alle nuove esigenze

progettuali. Logiche (e quindi programmi) da aggiungere, da modificare, da togliere; logiche che sono da

aggiungere ma, fra due mesi saranno da togliere, insomma, chiunque abbia un po’ di esperienza, avrà

sicuramente dovuto affrontare queste situazioni.

Per limitare le conseguenze dell’incertezza, è fondamentale il principio della modularità. Ecco perché a

ogni esigenza di business o di processo deve corrispondere una unica unità elaborativa, semplice o

complessa che sia.

Se devo caricare una tabella di Staging Area, ci deve essere uno più moduli che lo fanno, e fanno solo

quello. Se devo eseguire un controllo di quadratura fra 3 tabelle, deve esserci un modulo che lo fa, e fa

solo quello. Quando poi si scopre che le tabelle da controllare sono 4, aggiungerò nuovi moduli.

Se devo aggiungere il calcolo del prezzo di un prodotto finanziario derivato, ci deve essere un modulo che

lo fa; non importa se quel modulo lo mando a sviluppare a un programmatore che vive in un’altra parte del

mondo. L’importante è la immediatezza con cui lo inserisco nel sistema.

In questo modo non pretendo di eliminare l’incertezza, ma con la modularità la gestisco meglio.

AGILE NELLA MAINTENANCE AND ITERATIVE EVOLUTION – INDIPENDENZA DAL CONTESTO

L'ultimo consiglio è l’indipendenza dal contesto, cioè la netta separazione fra il business e l'infrastruttura.

La avete già vista in azione in alcuni miei articoli precedenti. Le semplici tecniche esposte di messaggistica

e controllo sono indipendenti dal contesto. Sono infrastruttura, non business. Che il business legato al Data

Warehouse sia in ambito finanziario, automotive, o per la grande distribuzione organizzata, non influenza

minimamente l’utilizzo di quelle tecniche.

Esse utilizzano tabelle di configurazione e di log assolutamente indipendenti dal contesto in cui lavorano.

Questo ci permette, per esempio, di aggiungere un nuovo Data Mart concentrandoci esclusivamente sul

business legato al Data Mart ,riutilizzando tutto il software indipenedente dal contesto per il monitoraggio

del processo.



Build

Maintenance and

Iterative evolution

Test

Data Lineage

Modularità

Configuratione e log

Riduzione della catena

elaborativa

Naming Convention

Semplificazione dei tipi dato

Sequenzialità

Riduzione dei tool esterni

Indipendenza dal contesto

Agile

Agile

Agile


CONCLUSIONE

Essere agile in un processo o progetto di Data Warehouse e Business Intelligence è possibile. Bisogna

solo farsi guidare da una corretta metodologia che ho cercato di riassumere nei punti descritti.

RIFERIMENTI

http://www.slideshare.net/jackbim/tecniche-di-naming-convention-parte-1


http://www.slideshare.net/jackbim/note-di-data-warehouse-e-business-intelligence-il-sistema-di-messaggistica-1


http://www.slideshare.net/jackbim/recipe-9-techniques-to-control-the-processing-units-in-the-etl-process





http://www.slideshare.net/jackbim/recipe-9-techniques-to-control-the-processing-units-in-the-etl-process

Note di Data Warehouse e Business Intelligence - Pensare "Agile"

Technology

Transcript of Note di Data Warehouse e Business Intelligence - Pensare "Agile"