Distribuited Enterprise Data Warehouse: Dimensionamento software e hardware

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...

Privacy Policy