No more maintained.
Now just a test in a lab.
Datawarehouse
Logica, principi, applicazioni, design e realizzazione di datawarehouse
Architetture DWH - Inmon vs Kimball 3/3
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR
Punti di contatto e di distanza tra le due architetture di riferimento per la creazione di un data warehouse.
Non è semplice poter identificare un’architettura di riferimento che possa rappresentare un standard, tale impossibilità è però mitigata dal fatto che, pur nelle differenze di contenuti e rappresentazione, le due architetture riportate negli infobox collegati presentano molti punti in comune e come già evidenziato da Susan Gallas la sostanziale differenza sembra attribuibile principalmente a due soli punti, il primo di terminologia, il secondo di estensione del concetto di business intelligence alla presenza del livello ODS:
1. Le due architetture presentano una componente di raccolta dei dati che è definita come data warehouse nell’architettura CIF e staging area nell’architettura costituita da staging area e data warehouse, pur con le dovute differenze in entrambe le architetture è presente uno strato di raccolta e “pulizia” dei dati sorgente, fonte dati del sistema analitico front-end.
2. Nella prima architettura (CIF) il concetto di ODS assume importanza soprattutto nello strato relativo alle informazioni di tipo Business operations, nella seconda architettura l’ODS non è invece considerato sufficientemente orientato al business anche se possiede il vantaggio di essere sempre “in linea” temporalmente con i sistemi transazionali.
E’ il secondo punto che evidenzia una certa distanza fra i due paradigmi, Ralph Kimball, teorizzatore dell’architettura basata su area di staging e data warehouse, propone come linea guida di evitare l’incorporamento di ODS in una soluzione di data warehouse :
“If you have an operational data store in your systems environment, or in your plans, examine it carefully. If it is meant to play an operational, real-time role, then it truly is an operational data store and should have its own place in the systems world. If, on the other hand, it is meant to provide reporting or decision support, we encourage you to skip the ODS and meet these needs directly from the detailed level of the data warehouse.”
Di fatto, però, entrambe le soluzioni propongono metodologie che, se seguite con scrupolo, garantiscono il corretto sviluppo di progetti di business intelligence.
Architetture DWH - William Inmon 1/3
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR
La business intelligence negli ultimi 10 anni ha vissuto una crescita di interesse continuo, questo, accanto ad ovvi benefici, ha portato anche una componente di confusione che, in assenza di uno standard, influisce negativamente nella comprensione a tutto campo del concetto di business intelligence; tale confusione trae origine anche da alcuni paradigmi che si sono affermati negli ultimi anni e che rispecchiano filosofie e tecniche diverse per risolvere il medesimo problema : liberare le informazioni aziendali e fornirle in modo concreto e chiaro a coloro che in azienda prendono decisioni tattiche e strategiche.
Una visione, per quanto approssimativa, dei paradigmi di maggiore successo, può essere utile a chiarire differenze e punti in comune.
In questa prima parte affronteremo l'architettura suggerita e sviluppata da William "Bill" Inmon...
Corporate information factory
La corporate information factory (CIF) è un’architettura concettuale largamente accettata che descrive e categorizza le informazioni per definire e gestire una robusta infrastruttura di Business intelligence.
Tali informazioni supportano tre livelli di processi organizzativi :
Business operations: riguardano la gestione giorno per giorno delle informazioni relative alle attività operative del business, dipendono direttamente dai sistemi transazionali aziendali e sono informazioni fortemente automatizzate, che non evolvono ne cambiano nel tempo, sono informazioni puntuali e di dettaglio caratteristiche del controllo della “produzione” della propria azienda.
Business intelligence: riguardano le informazioni che vengono cercate all’interno dell’azienda per migliorare le prestazioni, per conoscere meglio i propri clienti, per analizzare le caratteristiche del proprio prodotto e la storia che lo coinvolge, rispetto al livello Business operations, sono informazioni di tipo dinamico, che evolgono continuamente nel tempo, per le loro caratteristiche hanno un fondamentale ruolo nelle decisioni strategiche aziendali.
Business management: è la funzione nella quale la conoscenza derivata dal livello Business intelligence viene istituzionalizzata e introdotta a tutti i livelli in azienda.
Le componenti principali che formano l’architettura CIF possono essere suddivise per maggiore chiarezza e semplicità in tre classi distinte :
1. I sistemi transazionali : che rappresentano tutte le applicazioni aziendali che costruiscono l’informazione operativa dell’azienda stessa, ne fanno parte tutti i software che gestiscono o producono dati aziendali: ERP, software di gestione ordini/acquisti, software di gestione delle risorse umane, della logistica, ecc. i dati raccolti da tali sistemi non sono informazioni di business: la loro struttura è compatibile con le caratteristiche dei sistemi che sono determinate da alcuni vincoli come la normalizzazione dei dati e l’assenza di ridondanza delle informazioni, la migliore gestione possibile di “inserimenti, modifiche e eliminazione” dei dati, la distribuzione di dati atomici in diversi punti degli archivi che li ospitano.
2. Il “contenitore” di dati per analisi e supporto alle decisioni “tattiche”: è rappresentato da una configurazione di dati chiamata Operational data store che fornisce informazioni, con uno scarto temporale minimo, dei sistemi transazionali tradotte in oggetti di business e organizzate per consentire analisi di dettaglio.
3. Il “contenitore” di dati per analisi e supporto alle decisioni “strategiche”: è rappresentato da una configurazione di dati chiamata data warehouse, che fornisce informazioni periodiche, storicizzate e riorganizzate secondo le regole aziendali che fornisce informazioni e oggetti di business per consentire analisi a supporto delle decisioni strategiche.
Architetture DWH - Ralph Kinball 2/3
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR
La business intelligence negli ultimi 10 anni ha vissuto una crescita di interesse continuo, questo, accanto ad ovvi benefici, ha portato anche una componente di confusione che, in assenza di uno standard, influisce negativamente nella comprensione a tutto campo del concetto di business intelligence; tale confusione trae origine anche da alcuni paradigmi che si sono affermati negli ultimi anni e che rispecchiano filosofie e tecniche diverse per risolvere il medesimo problema : liberare le informazioni aziendali e fornirle in modo concreto e chiaro a coloro che in azienda prendono decisioni tattiche e strategiche.
Una visione, per quanto approssimativa, dei paradigmi di maggiore successo, può essere utile a chiarire differenze e punti in comune, di seguito l'architettura teorizzata da Ralph Kimball.
Staging area e data warehouse
Un’architettura meno estesa dal punto di vista dei sistemi informativi aziendali, è rappresentata dalla definizione di due strati che riguardano specificamente le informazioni utili alla definizione di un sistema di business intelligence :
1. il primo strato è definito Data staging area è direttamente alimentato dai sistemi sorgente (ERP, ecc.) ed è il luogo dove i dati vengono estratti, trasformati e caricati seguendo le regole che definiscono gli oggetti di business necessari alle analisi, la staging area è una porzione dell’architettura “tecnica” non accessibile agli utenti finali e nella quale non vengono eseguite interrogazioni : i dati sono “preparati” perché possano essere importati nel data warehouse.
2. il secondo strato è definito come Data warehouse presentation servers : è il luogo dove viene fisicamente creato il data warehouse e dove i dati vengono esposti in maniera chiara e compatibile con le regole e gli oggetti di business, tale strato è accessibile agli utenti finali attraverso gli strumenti di queryng e di reporting, ed è costituito da un raggruppamento di “porzioni logiche” dei dati disponibili (datamart) organizzate e rese conformi attraverso un’architettura denominata “warehouse bus”.
Scelta del database - Costi e dimensionamenti
Tipo Infobox: TIPS - Skill: 2- JUNIOR
Oracle meglio di teradata ? Sybase meglio di DB2 ? e sql server ???
rogettare soluzioni di data warehouse è generalmente molto stimolante : individuazione dei requirements, modellazione della soluzione, individuazione delle politiche di ETL, implementazione della base dati, creazione della reportistica e dei contesti di analisi.
Un processo lungo, spesso insidioso, ma affascinante, in grado di creare valore per l’azienda.
In questo infobox vorrei concentrare l’attenzione su una problematica scottante :
Qual è il database che mi da una relazione costo/beneficio migliore? Oracle? Ms Sql 2000? Sybase IQ? Excel???
e soprattutto come posso misurare in maniera asettica le performance? chi mi fornisce un benchmark affidabile e “non inquinato”?
Devo fidarmi dei siti istituzionali dei database ?
Tante domande.
Troppe.
Per prima cosa non perdiamo tempo a navigare nei siti istituzionali, perché ogni database risulterà (per la particolare caratteristica sottintesa) il migliore : Teradata ! il database migliore per data warehouse oltre 1000 tera !! Ms sql server 2000 ! database migliore per data warehouse di dimensioni abbastanza notevoli !! (?) J
Concentriamoci invece sul “Transaction Processing Performance Council” on organo che nel suo tentativo di individuare uno standard per la misurazione delle performance dei database ha creato il benchmark TCP-H pensato per le soluzioni di data warehouse, concentrando l’attenzione sul costo orario di esecuzione di query ad hoc.
I risultati possono essere presi per indicazioni utili nella scelta del database :
Data warehouse da 100 giga
1° - Sybase IQ 12.5 – S.O. Sun solaris 9 – costo : 28$
2° - Microsoft sql server 2000 enterprise – S.O. win 2003 server – costo : 38$
3° - IBM DB2 – S.O. win 2003 server – costo : 70$
Data warehouse da 300 giga
1° - Sybase IQ 12.5 – S.O. Sun solaris 9 – costo : 27$
2° - Microsoft sql server 2000 enterprise – S.O. win 2003 server – costo : 43$
3° - IBM DB2 – S.O. win 2003 server – costo : 69$
Data warehouse da 1000 giga
1° - Microsoft sql server 2000 enterprise – S.O. win 2003 server – costo : 58$
2° - Sybase IQ 12.5 – S.O. Sun solaris 9 – costo : 104$
3° - Oracle 10g – S.O. Sun solaris 9 – costo : 156$
Data warehouse da 3000 giga
1° - Oracle 10g – S.O. HP UX 11i 64bit – costo : 109$
2° - Teradata 2R5 – S.O. MP-RAS 3.02.00 – costo : 213$
3° - IBM DB2 – S.O. win 2000 server – costo : 283$
Data warehouse da 10000 giga
1° - Teradata 2R5 – S.O. MP-RAS 3.02.00 – costo : 243$
1° - IBM DB2 – S.O. AIX 5L 5.2 – costo : 243$
ora non vi resta che fare la vostra scelta data warehouse architects…
Business Objects: come passare la group by e perchè...
Tipo Infobox: TIPS - Skill: 3- INTERMEDIATE
Sfruttare le avanzate caratteristiche dei motori DB settando opportunamente le misure in Business Objects.
Chi utilizza Business Objects può facilmente verificare che lo script sql generato dal motore BO non passa la GROUP BY, questo rappresenta un grosso problema per chi vuole utilizzare le materialized view di Oracle o le indexed views di Sql Server, i motori DB non sono in grado di pianificare la query execution sfruttando la presenza di tali viste (quindi deducendo la migliore FROM possibile).
Agite così per obbligare BO a passare la GROUP BY:
1 - nel modulo designer selezionate una per una tutte le misure definite.
2 - non definire formula di aggregazione e la misura nell'apposito pannello.
3 - esplicitare nella definizione la formula di aggregazione es: sum(importo) oppure avg(costo).
In questo modo BO passerà la GROUP BY e i motori DB saranno in grado di pianificare la query migliore.
Snowflake o no snowflake, questo è il problema...
Tipo Infobox: TIPS - Skill: 4- ADVANCED
Si discute di come il modello relazionale basato sul snowflake schema non sia, in generale, lo schema più adatto a un DW, si riporta comunque un esempio per il quale lo snowflaking delle dimensioni è opportuno.
Quando si giunge alla modellazione logica di tipo relazionale per realizzare la visione multidimensionale dei dati in oggetto, lo schema di maggiore successo ed efficienza è generalmente rappresentato dallo star schema (schema a stella), in soldoni lo star schema (SC) propone una tabella centrale (tabella dei fatti - FT) che determina l'oggetto dello studio e fornisce le singole transazioni analizzabili (fatti) e tante relazioni di appoggio, dette tabelle dimensionali (DT) , quante sono gli "oggetti di business" di analisi.
Le caratteristiche principali delle tabelle sono:
- Le chiavi delle DT sono surrogati
- Ogni DT contiene, oltre alla chiave, un attributo per ciascun attributo dimensionale o non dimensionale della gerarchia corrispondente.
- La chiave della FT è composta dalle chiavi importate dalle varie DT.
- La FT contiene, oltre alla chiave, un attributo per ciascuna misura.
Il modello rappresenta la naturale visione dei dati per le attività di tipo analitico ed è particolarmente leggibile vista la presenza di uniche join tra le tabelle dei fatti e le dimensioni.
Dal punto di vista maggiormente orientato all'engine database la presenza di un unico livello di join e una corretta indicizzazione (di tipo bitmap index) delle foreign key della tabella dei fatti è generalmente garanzia di alte prestazioni nel querying.
Generalmente, appunto...
Vorrei analizzare quelli che sono stati indicati come alcuni limiti per il modello SC e su questi fare qualche piccola considerazione :
-limite : l'utilizzo dello SC aumenta la dimensione delle tabelle
-considerazione : rispetto a cosa ? ai sistemi OLTP o ad altri modelli normalizzati OLAP ? spesso questo limite non viene specificato, o sopravvalutato, oggi grossi sistemi DW gestiscono centinaia o migliaia di gigabytes, personalmente non lo considererei come un reale limite (nel contesto di un certo tipo di progetto DW)
-limite : La Fact Table contiene tuple relative a diversi livelli di aggregazione
-considerazione : L'espressione artistica massima nel disegno di un SC passa proprio per la capacità di organizzare in modo chiaro tutta l'informazione necessaria all'analisi, la definizione di attributi gerarchici di una dimensione di analisi costruiti sulla decodifica di un campo indicizzato nella tabella dei fatti, rappresenta, a mio avviso, l'espressione massima di chiarezza nel disegno, non mi preoccupo di quali differenze sono ospitate nella stessa FT, ma della bassa complessità nella definizione degli attributi di analisi relativamente ai diversi dati aggregati presenti.
-limite : L’elevata dimensione della Fact Table incide sui tempi di accesso
-considerazione : Le FT sono sempre di elevata dimensione; l'attività di aggregazione, appunto, e l'uso sapiente dell'indicizzazione possono (in concerto con i potenti tools di oggi in grado di accedere in autonomia ad aggregazioni predefinite) risolvere qualunque tipologia di problema, inoltre, ripeto, le dimensioni di un DW non possono che essere spesso mostruose, è la costituzione di datamart aggregati che permette performance analitiche di valore.
Questo il breve elenco dei limiti principali che è possibile recuperare in diversi articoli, dal mio punto di vista è assente quello che rappresenta un vero, fastidioso limite.
Ossia: spesso le DT raggiungono notevoli dimensioni (pensiamo alla dimensione Cliente di una catena di supermercati, i singoli clienti potrebbero essere centinaia di migliaia o milioni), in questo caso lo SC può presentare qualche problema, soprattutto nel caso di dimensioni che hanno importanti attributi gerarchici a bassa cardinalità.
Facciamo un esempio :
Nella dimensione prodotto (formata da 300,000 records) sono presenti numerosissimi attributi (diciamo 100 campi di tipo descrittivo), da un punto di vista business, esiste in questa dimensione il concetto di Linea di prodotto che raggruppa una serie di articoli prodotto (che rappresentano la granularità minima e quindi il concetto di singolo prodotto), poniamo il caso che le linee prodotto siano 50 per i 300,000 articoli.
Cosa succede se il concetto di linea di prodotto è accompagnata da una serie di informazioni aggiuntive (ospitate per esempio da 20 campi nella dimensione) relative proprio alla linea di prodotto e non all'articolo ?
Beh, la bassa cardinalità del tipo di prodotto causerebbe nella denormalizzazione un'impressionante ridondanza di dati e i 20 campi descrittivi relativi al tipo di prodotto contribuirebbero (oltre che alla ridondanza) ad un possibile massiccio aumento di dimensioni che potrebbe influire negativamente sulle prestazioni rispetto ad un rinormalizzazione snowflake (non preoccupiamoci delle dimensioni, ma delle prestazioni).
Quella descritta risulta a mi avviso l'unica situazione che rende utile la rinormalizzazione snowflake, molte altre situazioni riportate dalla letteratura sui presunti pregi dello snowflaking sono state risolte grazie a diverse notevoli features che molti motori db mettono a disposizione (come i recenti indici bitmap).
il Real-time data warehouse e l'epopea di Gilgamesh
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE
Anticipare l'aggiornamento dei dati di un DW fino al real-time DW, alcune considerazioni in merito.
Tutto evolve.
In una sorta di selezione naturale tecnologica anche le tematiche inerenti il datawarehousing propongono molte mutazioni, la maggior parte muoiono così velocemente che spesso la comunità tecnico-scientifica nemmeno se ne accorge, altre (ovviamente) sopravvivono, si adattano spesso prosperano (per poi comunque estinguersi...).
Uno degli ultimi paradigmi (datato comunque "anno 2000") riguarda il concetto di real-time data warehouse (RTDW), paradigma indicante quasi una rivoluzione più che un'evoluzione.
Rimando al pluripremiato articolo di Michael Haisten "The Real time data warehouse: the next stage in data warehouse evolution" per un puntuale escursus sulla storia del data warehouse dal 1978 ad oggi.
Parlare di real-time data warehouse a chi è fortemente legato alla tradizione dei padri fondatori delle metodologie DW suona quasi come una simpatica burla, una ridicola contraddizione, qualcosa di insensato.
Suona così però solo di fronte ad un'analisi superficiale del concetto di RTDW.
Do per scontata la conoscenza di alcune caratteristiche tipiche del concetto di DW, e rimando il lettore al corretto topic di Openskill, non senza però sottolineare alcune caratteristiche relative all'acquisizione dei dati e al loro refresh, che permetteranno una migliore comprensione del RTDW.
La trasformazione di dati operazionali in dati utili all'analisi attraverso l'utilizzo di "oggetti di business" è il motivo generatore del DW dalla sua remota e primordiale ideazione; tutto (architettura, modellazione, tools di analisi, ecc.) ruota attorno a questo fondamentale requirement.
Al secondo posto (o al primo a pari merito ?) c'è la tempestività delle informazioni, la linfa vitale di qualunque analisi, oltre che una potenziale Sibilla Cumana in grado di prevedere il probabile andamento aziendale conseguentemente a scelte di business basate sull'analisi dei numeri...
Personalmente il progetto di DW con tempi di refresh più bassi sul quale abbia mai avuto modo di confrontarmi aveva tempi di aggiornamento di mezz'ora (il progetto doveva fornire dati di consumo di centrali elettriche e i tools di reporting dovevamo costruire una storia running dell'andamento con acquisizione di dati ogni mezz'ora) all'epoca sarebbe stato impossibile pensare di accorciare ulteriormente quei tempi e rimanere nel concetto corretto di DW, la classica architettura di riferimento semplicemente non è compatibile con un flusso di dati real-time da un sistema operazionale ad uno analitico (al netto di qualche sofisticato accrocchio ad hoc, del quale non posso evidentemente discutere qui); inoltre, tipicamente, i tempi di refresh vanno dall'aggiornamento quotidiano in su (settimanale, mensile, ecc.).
Se ci fermiamo a ragionare sul concetto di tempestività dell'informazione la necessità di un abbassamento dei tempi di aggiornamento fino al limite inferiore (il real time) sembra giustificato solo per certe tipologie di business e la necessità sembra si sia generata con l'avvento del Web su scala globale e il conseguente quantum leap che ha sovvertito e reinventato la definizione di "dato aggiornato, in linea e temporalmente conforme" che pare, in taluni casi appunto, essere stato ridotto di uno o due ordini di grandezza.
Comunque sia questa nuova esigenza è stata catturata, analizzata e ha prodotto un framework di riferimento (ancora giovane per la verità) con l'obiettivo di permettere un allineamento in tempo reale dei sistemi operazionali e analitici.
Il ribaltamento del paradigma passa attraverso lo strato applicativo di acquisizione dei dati che non può funzionare con attività batch gestita da tools di ETL (extraction, transformation e loading), ma attraverso l'utilizzo di tools di CTF (capture, transform e flow) che evidenziano una logica completamente diversa non solo nella gestione dei dati sorgenti, ma anche in tutta l'architettura del DW (anzi RTDW).
Un tool di CTF non funziona in modalità batch (come potrebbe ?) ma come un demone sempre attivo in grado di innescarsi come un trigger ad ogni cambio di dati nei sistemi operazionali (C), il cambio scatena una serie di eventi che recuperano i dati, i quali "galleggiano" su un flusso più o meno continuo dai sistemi transazionali a quelli analitici (F) passando attraverso le logiche definite di trasformazione (T).
Per questo un RTDW ha alcune peculiarità distintive: tutta l'eventuale parte batch di generazione di datamarts, indicizzazione, creazione di cubi multidimensionali deve essere smembrata e reingenierizzata affinchè il concetto di real-time possa essere effettivo, alcune attività tipiche di un DW saranno poi semplicemente incompatibili o irrealizzabili (do per scontato che non voglio considerare l'esistenza di un super hardware in grado eseguire in tempo infinitesimale l'attività batch ETL di un DW).
Temo inoltre, ma non ho un'esperienza diretta, che il rischio di dover gestire l'enorme complessità manutentiva di alcune soluzioni DW possa aumentare esponenzialmente nel caso di un RTDW (non solo dal punto di vista concettuale, ma anche dal punto di vista sistemistico).
Concludo infine con una considerazione che mi ricorda, con una forzata analogia, il destino di Gilgamesh alla ricerca dell'immortalità, sempre sfiorata ma mai raggiunta; la mia modesta opinione è che il RTDW per essere tale debba rinunciare ad una porzione di autentica creazione dell'informazione di business (risultato anche di complesse trasformazioni dei dati) a favore del real-time, tale rinuncia lo trasforma al limite in un elisir di lunga vita, ma non nella pozione per l'immortalità.
Nell'epopea di Gilgamesh, il re di Uruk rinuncia alla ricerca della pozione dell'immortalità accontentandosi proprio di una piccola pianta elisir di lunga vita, ma nel suo cammino di ritorno verso casa, distratto, la smarrirà...
Distribuited Enterprise Data Warehouse: Dimensionamento software e hardware
Tipo Infobox: TIPS - Skill: 4- ADVANCED
E' facile sottostimare le necessità elaborative di una soluzione Data warehouse distribuita, il Tip mostra un esempio reale di quale sforzo HW e SW sia stato richiesto nell'ambito di un importante progetto DW
Se ascoltate una chiacchierata fra data warehouse architect sicuramente ad un certo punto salterà fuori un bel discorso sulle dimensione dei propri data warehouse (DW) che si concluderà con frasi del tipo "il mio è più grosso del tuo".
Le dimensioni del DW sono decisamente un punto cruciale nel disegno della soluzione sia dal punto di vista dell'architettura generale del DW sia dal punto di vista dello sforzo HW e SW richiesto per prestazioni ottimali (dato per sottinteso che la modellazione del DW sia perfetta).
L'architettura distribuita sembra sempre di più la via migliore per la soluzione di problematiche inerenti il carico di lavoro delle macchine.
E' il caso dell'esempio che segue: un caso reale di una grossa realtà internazionale che, nell'ambito di uno strategico progetto di misurazione delle proprie performance, ha deciso di implementare una soluzione basata su un data warehouse enterprise.
Sorvoliamo sulle complesse attività di studio di fattibilità e analisi per giungere all'architettura di riferimento e al suo impatto nella scelta di hardware e software (necessariamente sorvoleremo anche sulle complessità relative alla manutenzione del sistema in produzione).
Le analisi effettuate hanno indicato le seguenti caratteristiche relativamente al DW:
- Dimensioni ipotizzate per 5 anni di dati storicizzati: minimo 1 terabyte di dati
- Utenti che hanno la necessità di accedere per effettuare interrogazioni: almeno 15.000 utenti
- Tecnologia per l'interrogazione dei dati: Web-enabled
Geograficamente l'azienda presenta 31 grosse filiali "centri di controllo" distribuite sul territorio e tra loro interconnesse (banda attuale dichiarata 2 Mbit/sec) il quartier generale è identificato con una filiale, centro di raccolta e smistamento dei dati necessari al DW.
I tempi di aggiornamento sono mensili, ma si vorrebbe avere la possibilità di avere in futuro anche aggiornamenti settimanali.
L'architettura della soluzione è a quattro livelli:
1 - Staging area services
2 - DB server
3 - Application server
4 - Presentation layer
La distribuzione della soluzione prevede per l'analisi dei dati un Dw principale, 30 nodi per i Dw secondari e per ogni Dw secondario un certo numero di datamart tematici sia di tipo relazionale che di tipo multidimensionale; mentre per la fornitura dei dati dai sistemi periferici (che possono essere N per ogni nodo) viene innescato un processo quindicinale di fornitura dati direttamente via FTP dalle sedi periferiche alla sede centrale.
La soluzione prevede la messa in produzione di 31 server per i primi due strati dell'architettura e altri 31 server per il terzo strato dell'architettura.
Dal punto di vista hardware le indicazioni sono le seguenti:
1 - Per la parte Staging Area a DW per il DW principale e alcuni nodi critici:
- Sistema operativo Unix;
- Processore risc 64 bit tecnologia smp con frequenza almeno 500 mhz - 4 cpu;
- Memoria ram 2 gigabytes;
- Memoria cache L2: 2 megabytes per cpu;
- Dischi interni 2 unita’ con tecnologia hot swap da minimo 108Gb configurati in raid-1, e’ richiesto che le unita’ hd siano connesse a canali ultra scsi separati;
- Interfacce i/o almeno 2;
- Connessioni Ethernet 10/100. Almeno 1 connessione per nodo Ethernet 1Gb se sono connesse in cluster;
- Ultra 2 scsi indipendenti dai controller per i dischi interni;
- 2 controller fibre channel per nodo per il collegamento al sottosistema dischi se presente;
- Slot di i/o non inferiori a 10 slot con tecnologia pci, espandibili almeno a più del doppio.
2 - La parte Staging Area a DW per gli altri DW secondari la configurazione è simile a quella per il DW principale anche se sono sufficienti 2 cpu
3 - La parte Application Server fornisce due servizi principali: lo strato web server e lo strato applicativo del tool di analisi entrambi ospitati da un unica macchina distribuita per ogni nodo (compreso il quartier generale), le caratteristiche dell'application server sono state così indicate:
- Sistema Operativo Windows 2000 Advanced Server
- Architettura di sistema 32 bit SMP
- Processori Almeno due Intel Pentium III Xeon 700 MHz, 1 MB - cache, espandibile fino a 4
- Memoria RAM MINIMO 512MB MASSIMO 2GB
- Affidabilità: I dispositivi critici all’interno devono essere ridondanti e sostituibili a caldo (i.e Alimentatore, Ventilazione)
- Interfacce di rete: 2 controller di rete 10/100 base TX
- Dispositivi di I/O Standard: CD-ROM. FLOPPY DISK, DAT
- Capacità disco interna: In generale non inferiore a 36 GB, con dotazione di almeno 2 dischi da 18 GB in configurazione mirror, con dischi sostituibili a caldo.
- Gestione remota: Software di gestione remota via Lan e/o modem integrabile con i principali software di system management (valutare Unicenter TNG)
4 - Per lo strato di Presentazione è sufficiente la presenza di un browser internet correttamente configurato per l'accesso via http.
Le indicazioni software sono le seguenti :
- DB server Oracle 9i (con Application Server Enterprise)
- OLAP Engine Oracle Olap server
- Tool di ETL Oracle Warehouse builder 9.0.3
- Web Server Internet Information Server 5.0
- Application Server Business Objects Webintelligence 2.7
- Presentation Internet Explorer o Netscape Navigator
- Tool di system e network management Unicenter TNG (con moduli per la gestione remota e il software delivery)
Molte sono le variazioni sul tema possibili: ogni progetto di DW ha i propri confini e le proprie caratteristiche, è impossibile indicare uno sforzo HW e SW preciso sulla base di alcune caratteristiche tipiche come le dimensioni e il numero di utenti, ma è sensato indicare verso quale dimensionamento è necessario spingersi in alcuni casi generalizzabili, lo scopo di queste righe è proprio questo: in certe situazioni, che possono essere sottovalutate, non si può pensare di affidare la soluzione ad un paio di server biprocessori...
Introduzione al data warehouse
Tipo Infobox: DESCRIPTION - Skill: 1- NOVICE
Esistono moltissime definizioni che identificano con precisione il concetto di Data Warehouse, in particolare ne possiamo citare due che ne sottolineano le caratteristiche peculiari:
“Una piattaforma sulla quale vengono archiviati e gestiti dati provenienti dalle diverse aree dell’organizzazione; tali dati sono aggiornati, integrati e consolidati dai sistemi di carattere operativo per supportare tutte le applicazioni di supporto alle decisioni ” (Gartner Group)
“Un insieme di dati subject oriented, integrato, time variant, non volatile costruito per supportare il processo decisionale”
(W.H.Inmon)
Il Data Warehouse è una collezione di dati a supporto del processo decisionale, attraverso il Data Warehouse il management ha l’opportunità concreta di trovare le risposte a tutte quelle domande che hanno un alto impatto sulle performance aziendali; chi ricopre ruoli decisionali deve avere la possibilità di usufruire di tutti gli strumenti che possono rendere la guida dell’azienda massimamente sicura.
Le tipiche problematiche del management relativamente alla fruizione di dati possono essere riassunte come segue:
- Assenza di sintesi nella reportistica
- Risultati diversi da fonti diverse per la stessa tematica
- Impossibilità di navigare nei dati ragionando con oggetti “business”
- Inaffidabilità di alcuni dati critici
- Costi elevati per sintetizzare report e analisi
- Scarsa “collaborazione” o impossibilità di comunicazione dei sistemi informativi transazionali per interrogare i dati
- Assenza di coerenza fra i dati.
- Lentezza nell’interrogazione di dati non ottimizzati per l’analisi
Queste problematiche sono così universali che possono essere considerate come requirements fondamentali per la costruzione di un sistema di Data Warehouse, il quale si poggia perciò su alcune caratteristiche molto importanti:
1- Il Data Warehouse deve consentire l’accesso a dati aziendali garantendo bassi tempi di attesa fra l’interrogazione dei dati e l’output di risultati.
2- I dati esposti devono essere consistenti: un particolare valore (le vendite del prodotto A nella città B nel periodo di tempo C) deve essere sempre lo stesso indipendentemente dal momento dell’interrogazione o dalla modalità di interrogazione dei dati.
3- I dati esposti possono essere ricombinati e separati rispetto agli oggetti di calcolo definiti dal business.
4- Nel concetto di data warehouse rientrano anche gli strumenti software necessari a facilitare l’interrogazione dei dati e a garantire una presentazione chiara della sintesi delle analisi.
5- Il Data Warehouse deve contenere dati coerenti e “ripuliti”: capita che fonti importanti di dati per il Data Warehouse trascinino errori di diverso genere che possono avere un impatto devastante sulla qualità dei dati stessi, parte fondamentale del processo di realizzazione di un sistema di Data Warehouse è rappresentata proprio da attività di recupero, trasformazione e pulitura dei dati.
6- La qualità del Data Warehouse può mettere in luce problematiche nascoste all’interno dei processi aziendali, tipicamente l’assenza di dati relativamente ad una particolare attività dovuta all’opzionalità di compilazione dei dati (causa principale dell’assenza di dati) può evidenziare, proprio grazie al Data Warehouse, la necessità di verificare a livello di processi aziendali l’opportunità di definirla come obbligatoria (e non opzionale).
7- Il Data Warehouse è un sistema in sola lettura, gli utenti non eseguono azioni di aggiunta, modifica o eliminazione dei dati.
Questi punti mettono in evidenza come sia necessario porre l’attenzione sull’esistenza di due universi completamente diversi nell’ambito del trattamento dei dati aziendali :
On line transaction processing (OLTP) è l’insieme dei sistemi transazionali pensati e ottimizzati per garantire la massima sicurezza nella gestione delle transazioni.
On line Analytical processing (OLAP) è l’insieme dei sistemi di analisi dei dati pensati e ottimizzati per garantire la massima performance e la massima “estensione” delle interrogazioni.
Il recente successo della “filosofia” OLAP (tanto elevato da rendere, in molte realtà, il data Warehouse una soluzione necessaria quasi quanto la presenza dei sistemi OLTP) è dovuto in parte alla disponibilità di potenza elaborativa per gestire grossi volumi di dati a basso costo e la possibilità di distribuzione delle informazioni tramite tecnologia intranet/Internet.
Dal punto di vista tecnico/architetturale la definizione di un ambiente data warehouse può essere così semplificata:
1- I dati sorgente, oggetto dell'analisi, vengono forniti dai sistemi transazionali e possono essere di varia natura (sistemi ERP, fogli excel database personali, dati core di applicazioni aziendali, ecc.).
2- Tali dati sono caricati nel data warehouse attraverso procedure di ETL (extraction, transformation e loading) (che possono essere il risultato dello sviluppo di un'interfaccia applicativa in SQL, C, ecc. o possono essere definite e costruite con complessi tool di ETL presenti sul mercato)
3- Nel data warehouse (sorvoliamo sulle complessità relative al disegno della struttura e alle aree di staging, della gestione dei metadati, ecc.) i dati sono presenti al massimo dettaglio e storicizzati e spesso raggiungono dimensioni comunque poco compatibili con l'interrogazione diretta attraverso tool di analisi: vengono così generati dal data warehouse aggregati tematici di dati (datamart) sui quali verranno scatenate le query per le analisi.
4- Un notevole numero di tool permettono di effettuare analisi di ogni tipo o di migliorare ulteriormente le performance delle interrogazioni, i server OLAP (database multidimensionali) possono precalcolare le possibili combinazioni analitiche e memorizzarle fisicamente in un file binario (con esplosione delle dimensioni), tool di analisi appositi possono interrogare i dati sfruttando puntatori che indicano la posizione del dato precalcolato anziché attendere i tempi di elaborazione del motore database. I server OLAP possono memorizzare i dati con diverse modalità utilizzando strutture relazionali (ROLAP) o multidimensionali (MOLAP), per database smisurati (centinaia di giga) spesso si utilizza una modalità ibrida (HOLAP); molti vendor decantano le doti dei loro Server OLAP, è certo comunque che in alcuni casi non è possibile evitare di porre troppa fiducia in chi vende il proprio motore OLAP spacciandolo per il più performante e che in breve si rivela soprattutto una SOLAP...
Approccio metodologico al data warehouse
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR
In ogni disciplina esiste un guru.
Nel frenetico mondo del data warehouse ne esistono almeno due: Ralph Kimball e Bill Inmon che proiettano le loro fosche ombre sulle scelte di ogni Data warehouse architect.
L’approccio metodologico relativo alla realizzazione di soluzioni di data warehouse dipende direttamente dall’organizzazione aziendale, dalla tipologia di utenti dall’architettura tecnica del sistema e dalle criticità evidenziate.
Nel corso del tempo sono stati suggeriti diversi approcci per la realizzazione dei progetti, poi rivisitati grazie al bagaglio di esperienze maturate da varie Organizzazioni.
"L’elevata mortalità delle prime implementazioni di soluzioni di data warehouse ha accelerato l’evoluzione di metodologie più focalizzate sul business, si parla pertanto di approccio top-down, approccio bottom-up, approccio incrementale, a cui corrispondono diverse topologie di data warehouse (Enterprise data warehouse, datamart, Multi-tier Warehouse)" scriveva qualcuno solo un paio di anni fa, ma si sa, anche nel campo della business intelligence due anni sono un'enormità, e oggi (metà del 2002) accanto ai classici approcci metodologici si inseriscono vere e proprie "filosofie di approccio metodologico" che aiutano a rendere ancora più confuso il mondo del data warehouse...
Approccio top down
L’approccio top-down è quello che prevede una implementazione estensiva del sistema, il cui disegno originale tiene in considerazione tutte le principali aree di interesse aziendale.
Si parla in questo caso di Enterprise data warehouse, che può essere successivamente suddiviso in un insieme di datamart, per motivi tecnici ed organizzativi, pur mantenendo rigorosamente accorpata la visione totalitaria d’insieme della soluzione.
I datamart dipendenti costituiscono un subset di dati aziendali altamente specializzati per aree di interesse o dipartimenti aziendali.
Il punto debole di questo approccio teoricamente rigoroso è nella difficoltà di gestione del progetto onnicomprensivo, che rischia di paralizzare l’attività e di fornire risultati troppo in avanti nel tempo, questo tipo di approccio (caldamente suggerito da Bill Inmon) rappresenta l'approccio migliore per la costituzione del data warehouse, va valutata la sua applicabilità relativamente allo sforzo che il cliente prevede di sostenere, se il sistema di data warehouse rappresenta (come dovrebbe) un progetto strategico per il cliente il budget non può che essere correttamente proporzionato.
Approccio bottom-up
L’approccio bottom-up prevede una implementazione non coordinata nella quale ogni datamart viene realizzato per rispondere ad uno specifico fabbisogno informativo di una utenza dipartimentale.
In questo caso l’Enterprise data warehouse è il risultato dell’insieme dei singoli datamart indipendenti, che si alimentano direttamente dai sistemi operazionali.
Il vantaggio di tale approccio pragmatico è unicamente conseguire risultati utili per l’utente in un arco temporale limitato con costi diretti relativamente contenuti.
Tale approccio può essere valutato solo per progetti con budget di sviluppo molto bassi e, soprattutto, il cliente deve essere ben informato sui rischi del costo di manutenzione di un data warehouse di tale tipo.
Approccio “incrementale” : Enterprise datamart Architecture (EDMA)
L’approccio “incrementale” combina i vantaggi dei due approcci sopra descritti (e vede in Ralph Kimball il primo sostenitore).
Alla base di questo approccio, definito in letteratura anche approccio “federato”, infatti, è la creazione di un modello informativo comune.
Dal modello informativo comune vengono sviluppati in maniera coerente modelli dati dell’Enterprise data warehouse e/o dei datamart; questi ultimi possono essere sia dipendenti che indipendenti.
L’implementazione prevede di mettere a fattor comune tra diversi progetti di datamart i processi di acquisizione di dati dai sistemi transazionali.
E' tuttavia fondamentale segnalare che è comunque opportuno consigliare l'eliminazione datamart indipendenti, non appena sviluppati quelli derivanti direttamente dall'ambiente integrato del data warehouse; è importante verificare tempi e costi dello sviluppo temporaneo di datamart indipendenti.
Il risultato dei processi di acquisizione viene centralizzato su aree di appoggio comuni (cosiddette aree di staging) su cui vengono svolti i successivi processi di trasformazione.
Il modello informativo comune e la fruizione delle aree di staging minimizza i problemi di integrazione tra datamart, l’utilizzo di un’architettura data warehouse Bus consente l’individuazione e la condivisione di dimensioni e fatti razionalizzate rispetto ai processi aziendali.
Il concetto di Warehouse Bus (partorito da Ralph Kimball) è l'uovo di Colombo che in molti casi consente un approccio incrementale paragonabile nei risultati a quello Top Down di Inmon.
Alla definizione di dettaglio nel data warehouse di un particolare processo basato sul concetto di dimensioni e fatti conformi è possibile rilasciare velocemente il datamart aggregato, certi che le successive attività a livello di data warehouse non potranno creare isole informative.
