L'ETL open source

Ogni applicazione di Business Intelligence deve fondarsi su solide basi per produrre i risultati attesi. E' quindi importante che si appoggi su di un data warehouse ben progettato, ma anche correttamente caricato; infatti un'applicazione di BI non può prescindere dalla correttezza e certificazione dei dati che da essa vengono pubblicati. Esistono da anni strumenti che aiutano ad ottenere questi obiettivi, essi vengono chiamati strumenti ETL (Extract, Trasform and Loading). Tipicamente sono strumenti specializzati e molto o abbastanza costosi (IBM - Datastage, Oracle - ODI, ...), in alcuni casi sono forniti con il tool di analisi e reporting (Business Object - Data Integrator), oppure fanno parte del DBMS (Microsoft SQL Server - DTS). Esiste anche una proposta open source, si tratta di Pentaho Data Integration (ex Kettle), un tool che fa parte della ricca proposta Pentaho nel campo della BI.

Pubblico di seguito un documento che sintetizza gli aspetti principali dello strumento. Il documento è una sintesi realizzata da Beta 80 Group.

Che cos’è Pentaho Data Integration

Fornire una singola versione della verità, consistente, attraverso tutte le fonti informative dell’azienda è una delle più grandi sfide di una organizzazione IT al giorno d’oggi.

Pentaho Data Integration (PDI) dispone di potenti capacità di estrazione, trasformazione e caricamento (ETL - Extraction, Transformation and Loading), è composto da un insieme di strumenti che permettono di trasferire e manipolare i dati tra varie fonti, tipicamente DBMS e files nei vari formati. PDI utilizza un approccio innovativo basato sulla definizione di metadati per la descrizione ed il salvataggio dei processi di ETL, è indipendente dalla piattaforma ed ha un’architettura basata su standard internazionali. Dispone inoltre di un’interfaccia grafica di progetto molto intuitiva, di tipo “drag-and-drop”, a vantaggio della produttività.

PDI è strumento ETL completo, supporta trasformazioni complesse, dispone di:

• una ricca libreria di trasformazioni con più di 50 oggetti differenti;
• un supporto avanzato per i data warehouse, comprese dimensioni tempo invarianti e junk dimensions;
• un connettore specifico per SAP
• performance e scalabilità ai massimi livelli

PDI è uno strumento di 4° generazione, frutto di una ormai lunga evoluzione del software design:

• 1° generazione: programmazione manuale, grosse quantità di codice prodotte, difficile da mantenere e da rilasciare.
• 2° generazione: codice generato una sola volta, necessità di modifica manuale, facile da generare, difficile da mantenere e rilasciare.
• 3° generazione: generazione del codice a partire da un modello, facilità di generazione, facilità di manutenzione, ma ancora difficile da rilasciare
• 4° generazione: possibilità di eseguire attività (task) direttamente dal modello, facilità di generazione, di rilascio e di manutenzione.

A cosa serve PDI

PDI, come abbiamo detto, è uno strumento ETL progettato per:

• raccogliere dati da una grande varietà di fonti (più tipi di files e database nello stesso processo);
• muovere e modificare i dati (trasporto e trasformazione) mentre questi vengono “puliti”, denormalizzati, aggregati ed arricchiti;
• memorizzare i dati con una certa frequenza, tipicamente giornaliera, nella destinazione finale, solitamente un grande database, progettato in modalità dimensionale, ottimizzato per le attività di interrogazione: un data warehouse

Sebbene molti di questi concetti possono essere applicati a quasi tutte le attività di import / export di dati, l’ETL è più frequentemente utilizzato in un ambiente di data warehouse.

L’architettura di PDI

PDI è realizzato su un’architettura aperta, basata su standards. I maggiori benefici architetturali includono:

• sviluppato completamente in java con un ampio supporto sulle più diverse piattaforme;
• vastissima tipologia di fonti dati a cui può collegarsi, incluso applicativi di mercato, più di 25 database open source o proprietari, flat files, documenti Excel, ecc.;
• l’architettura estensibile consente un facile sviluppo di nuovi connettori e plug-in;
• l’utilizzo di un repository consente un facile riutilizzo di queries e di componenti di trasformazioni, oltre alla facile gestione di modelli, connessioni, log, ecc.;
• Performance e scalabilità a livello assoluto, compreso il pieno supporto di esecuzioni clustered di trasformazioni ETL.

Caratteristiche peculiari di PDI sono un approccio metadata-driven (basato sulla definizione di uno livello di metadati), model-driven (fondato sull’utilizzo di modelli) e repository-based (basato sull’utilizzo di un repository).

Un approccio basato su metadati significa che l’utente deve specificare CHE COSA vuole e non COME vuole fare. Nessun bisogno di realizzare codice personalizzato. Nessuna attività di programmazione, è un compito puramente dichiarativo.

I modelli possono essere salvati all’interno di un database relazionale o sotto forma di file XML. I vantaggi derivanti dall’uso di un repository sono molteplici: possibilità di gestire più modelli, i modelli sono salvati in un formato strutturato, il repository può essere interrogato liberamente, è possibile mantenere all’interno del repository i log delle singole operazioni effettuate.

I componenti di PDI

PDI è costituito da quattro distinte applicazioni:

SPOON

Strumento che consente di modellare, ad alto livello, il flusso dei dati dalla sorgente, attraverso le trasformazioni, fino alla destinazione utilizzando un’interfaccia grafica.

PAN

Strumento a linea di comando che consente di interpretare ed eseguire direttamente, in modalità batch, i modelli e le trasformazioni disegnate con Spoon, per esempio mediante uno scheduler.

CHEF

Consente di creare graficamente dei jobs. Un job consiste in una serie di operazioni come trasformazioni, FTP, downloads, etc. poste all’interno di un flusso di controllo. Un job automatizza ulteriormente il completamento di operazioni (task) di aggiornamento di un data warehouse permettendo il controllo sulla corretta esecuzione di ogni script, trasformazione o job.

KITCHEN

Si tratta di uno strumento a linea di comando utilizzato per lanciare l’esecuzione dei jobs disegnati con Chef in modalità batch.

PDI è OPEN SOURCE

PDI, dalla versone 2.2 è gratuito. I sorgenti completi sono rilasciati sotto la Lesser GNU Public License. Pentaho Data Integration non ha costi di licenza e consente una significante riduzione del TCO in confronto con soluzioni custom. A fronte di un abbonamento annuale viene inoltre fornito un supporto professionale e release certificate.

Alcuni esempi di PDI

Fig. 1: Semplice flusso

Fig. 2: Controllo dell'esecuzione

Fig. 3: Completamento dei dati del cliente con il CAP

Fig. 4: Flusso complesso con alert via email

Links

http://www.pentaho.com/products/data_integration/

http://kettle.pentaho.org/

Perchè la tua applicazione analitica su web non sta funzionando?

Tratto da The Intelligent Enterprise Weblog
Post: Why Isn't Your Web Analytics Tool Working?
Autore: Phil Kemelor

Questo articolo mi sembra interessante in quanto penso che in molti ci si possano riconoscere. Traduco in prima persona quello che dice l'autore.

Durante le mie presentazioni alle conferenze, spesso chiedo quanti, tra il pubblico, usano strumenti analitici web. La grande maggioranza dei presenti alza regolarmente la mano. Successivamente però, quando ho l'opportunità di parlare direttamente alle persone, spesso ricevo risposte del tipo:
Autore: Ma stai ricevendo un valore reale per il tuo business dalla tua soluzione analitica?
Manager (frustrato): No, lo strumento non funziona. Stiamo pensando di prendere qualcos'altro.
Autore: Ma sei sicuro che lo strumento non funziona? Forse il tuo personale non è abbastanza formato sull'utilizzo dello strumento.
Manager (riflessivo): beh, può essere. Al nostro reparto IT non piace supportare lo strumento e la persona che era il nostro "guru" se ne è andata. Non abbiamo nessuno formato sul prodotto.

Prima di spendere altri soldi sulla soluzione analitica, può essere saggio far verificare la propria implementazione e determinare se è sufficiente il supporto ed il livello di training delle opportune risorse. Esiste un processo per raccogliere, analizzare e presentare i dati in un modo da renderli utilizzabili?

L'autore conclude con l'esortazione a scrivergli la propria esperienza all'indirizzo email philkemelor@cmswatch.com.

Si tratta sicuramente di un caso comune, un'applicazione sviluppata senza grande budget, su richiesta di qualche manager, magari scavalcando l'IT e che l'IT disconosce e che non vuole prendere in carico.
Penso che il problema nasca soprattutto quando il progetto non è correttamente finanziato, in particolare a livello di manutenzione evolutiva. Un progetto di questo tipo non è mai una cosa statica che una volta realizzato rimane uguale a se stesso per anni, anzi al contrario è uno strumento in continua evoluzione, al passo con l'azienda e le sue strategie.
La mancanza di un finanziamento adeguato di questo tipo di progetti potrebbe essere dovuta ad uno scarso coinvolgimento del top managment, se vi è un forte mandato da parte di questi ultimi, in quanto convinti del vantaggi di questa tipologia di strumenti, non potrà mancare anche un adeguato e continuativo finanziamento.

Come affrontare una demo: un decalogo per il fornitore e anche per il cliente

Rielaborazione personale di articoli tratti da: The Intelligent Enterprise Weblog
Articoli di riferimento:
How Customers Should Prepare for Vendor Demos, Alan Pelz-Sharpe
Ten Steps to a Successful Vendor Demo, Tony Byrne

Spesso una demo è il risultato di una pre-selezione dei fornitori effettuata sulla base di proposte scritte. Purtroppo capita che a volte queste demo non funzionino molto bene. Qualche volta è il cliente che non si è preparato correttamente, altre volte, con maggiore frequenza, la colpa è del fornitore che le affossa. L'idea dietro questo scritto è che ciò è evitabile.

Le demo sono importanti per valutare i fornitori durante la fase finale di una selezione ed i clienti potrebbero beneficiarne maggiormente se queste fossero realizzate meglio.

Vediamo quindi 10 regole affiché i fornitori possano meglio inquadrare i propri prodotti secondo la prospettiva del cliente.

1. Arrivare presto. E' incredibile quanti fornitori arrivino in ritardo per una demo. E' vero, siamo tutti impegnatissimi, ma non è logico pretendere di conquistare la fiducia del cliente se non si è in grado poi di trattare il suo tempo con il rispetto che merita.

2. Scoprire quante persone saranno presenti e preparare una dispensa per ognuno. Se si pensa di fornire una brochure aziendale (tipicamente questa fase di presentazione non dovrebbe superare i 15 - 30 minuti iniziali della demo), allora è opportuno prepararne una copia per partecipante così che ognuno possa prendere delle note. Ovviamente la brochure deve essere un sommario dei punti principali.

3. Prevedere con anticipo eventuali problematiche di connettività. Se c'è il bisogno di una connessione ad Internet, è importante preparare in anticipo come questa può avere luogo e prevedere quali interventi siano necessari per attivarla: tipicamente una connessione wireless ha bisogno di autorizzazioni, se si usano porte particolari potrebbe essere necessario farle aprire, comunque potrebbe essere necessario transitare attraverso un proxy, ecc. Ricordiamoci poi di testarne il funzionamento prima della demo.

4. Investire in un laptop decente. Molto spesso, di fronte ad una clessidra troppo insistente, si sentono giustificazioni del tipo "sapete, con tutto quello che deve fare questo piccolo portatile ...". Se vuoi simulare un server, investi in una macchina che almeno prova ad agire come tale.

5. Non ignorare i bachi. I bachi sono parte delle demo, si parla spesso di "effetto demo", specialmente quando il cliente richiede una personalizzazione o comunque una variante alla demo standard. Se i partecipanti sono attenti come si vorrebbe che fossero, noteranno il più piccolo problema, così è bene non ignorarli. L'approccio più corretto è riconoscere i bachi, fermarsi a spiegarli e provare a fissarli durante la prima pausa. Nota per i compratori: pianificare sempre una pausa a metà demo in modo da poter fare il punto e lasciare al fornitore la possibilità di riorganizzarsi.

6. Testare il demo il giorno stesso. Si sa, è "l'effetto demo", se qualcosa può andare storto andrà storto: un conflitto con VMWare o un servizio che non vuole salire. Quindi ìl povero dimostratore si giustifica goffamente: "ma funzionava la scorsa notte nella mia camera di albergo!". L'unica cosa che si può fare per prevenire queste situazioni è verificare tutto prima della demo (ricordatevi di arrivare presto).

7. Non discutere al proprio interno. E' importante, per il fornitore, definire i ruoli in anticipo e la suddivisione del lavoro. Se questo non è stato preparato emergerà durante la demo. Paradossalmente gruppi numerosi di tecnici possono risultare più efficaci, in quanto più organizzati, di un team ridotto di due persone, il commerciale ed il tecnico di prevendita.

8. Fare attenzione a quello che il cliente chiede veramente. I fornitori tendono a profondere energie provando ad immaginarsi "quello che veramente il cliente vuole". Se il cliente ha scritto delle linee guida, use cases o altro materiale si può supporre che ci abbia fatto una buona riflessione. I fornitori tendono ad aggirare certe richieste complesse, puntando in fase di demo su quelli che potremmo definire "effetti speciali". Questi possono colpire il cliente durante la demo, lasciando credere al fornitore di aver messo a segno un gran colpo, successivamente però a mente fredda, qualcuno si ricorda che certi argomenti non sono stati mostrati loro. Cresce quindi il sospetto ed in quel momento il fornitore non è li presente per tranquillizzarli, il risultato è spesso nefasto per il fornitore.

9. Attenzione agli interventi da remoto. Spesso il team del fornitore può avere la necessità di affidarsi ad uno specialista che interviene per telefono o video conferenza. Nessun problema, ma in assenza di indicazioni visive e feedback questa persona ha la necessità di rimanere focalizzato, sintetico ed efficace. Fare attenzione se questo non avviene e se l'attenzione del cliente cala tragicamente. In questo caso il team leader del fornitore dovrebbe intervenire anche a costo di violare la regola 7.

10. Redigere una lista di domande non soddisfatte a cui rispondere entro un certo termine. Difficilmente un fornitore sarà in grado di fornire le risposte a tutte le domande del cliente in una seduta. E' importante che una persona tenga traccia di tutte le questioni aperte e, alla fine dell'incontro, dovrà essere indicata una data entro la quale verrà fornita una risposta.

Vediamo ora alcune regole che un cliente dovrebbe seguire affinché la demo abbia la sua massima efficacia:

1. Presenza di tutti i decision makers. Assicurarsi che tutti i decision makers, ovvero le persone che hanno voce in capitolo nella scelta, siano presenti. non c'è niente di peggio per un fornitore, dopo aver raggiunto a proprie spese la sede del cliente, che sentirsi dire "sfortunatamente Tizio o Caio (personaggi fondamentali) è occupato e non può essere presente oggi".

2. Se la decisione è già presa non perdete e non fate perdere tempo. Se sapete che vi state accingendo ad acquistare, non coinvolgete altri fornitori per divertimento o per simulare una situazione competitiva, semplicemente perché la procedura interna di acquisto dice che dovrebbe essere così. Non è giusto né etico.

3. Rifocalizzate il fornitore se necessario. Se il fornitore sta partendo per la tangente durante la presentazione, interrompetelo e riaffermate le vostre aree di interesse. Essi non possono leggere nella vostra mente.

In breve, da entrambe le parti dovrebbe esserci un rispetto reciproco, Come acquirente dovreste essere alla ricerca di un partner con cui lavorare. Mutuo rispetto, e francamente un po di buon senso da entrambe le parti, possono migliorare il rapporto.