Progettazione del Sistema di Auto Tuning
2. Individuazione degli aggregati: attraverso l’identificazione dei campi maggiormente interrogati, il sistema dovrà
suggerire possibili nuovi aggregati. Essi dovranno essere individuati attraverso un algoritmo di ricerca che consideri diversi fattori, come ad esempio:
Numero di query coperte;
Tempo necessario alla costruzione dell’aggregato;
28
2.2 Progettazione
Il sistema di Auto Tuning è stato concepito fin dalla sua progettazione come uno strumento stand-alone, basato su un proprio
repository in grado di supportare data warehouse di diverse tecnologie.
Questo è un aspetto fondamentale che consente di utilizzare questo strumento sui diversi data warehouse già esistenti nelle varie realtà aziendali. Inoltre non vincola la scelta di una tecnologia per poter sfruttare le sue funzionalità, poiché è in grado di connettersi ai data warehouse sviluppati dai vari vendor presenti sul mercato.
Il sistema di Auto Tuning deve operare a livello di tabelle fisiche di un data warehouse modellato secondo la tipologia ROLAP. Un’altra caratteristica fondamentale, che è stata tenuta in considerazione sin dalla fase di progettazione, è quella che Auto Tuning è in grado di funzionare sia sui data warehouse modellati come star schema che in quelli costruiti secondo il modello snowflake. Tale caratteristica amplia il campo di applicazione del sistema e soprattutto non influenza la scelta del modello da utilizzare durante la fase di progettazione di un nuovo data warehouse.
La tipologia di tuning che si intende realizzare è diversa dal tuning del database, non è definita quindi a livello di indici, partizioni o statistiche ma deve poter valutare il grado di copertura delle query. Il punto di partenza del sistema sarà quindi quello di analizzare le query che vengono effettuate
29
sul data warehouse, in modo tale da identificare a quale livello di aggregazione vengono interrogati più frequentemente i dati.
Una volta individuati i livelli di aggregazione più interrogati per ciascuna dimensione, il sistema deve proporre una serie di aggregati che saranno in grado di rispondere a tutte le query più frequentemente interrogate da parte dei sistemi di analisi front-end utilizzati degli utenti.
L’utente di Auto Tuning dovrà quindi valutare se è conveniente scrivere questa tabella aggregata in memoria oppure no. Questa decisione verrà presa tenendo in considerazione non solo la frequenza con cui l’aggregato verrebbe interrogato, ma verranno considerati anche altri fattori che caratterizzano l’intero sistema informativo in cui è presente il data warehouse. In particolare dev’essere valutato lo spazio di memoria libero presente nel data warehouse, poiché la dimensione delle tabelle aggregate varia in base al livello in cui sono stati aggregati i dati. Per esempio, la scelta potrebbe ricadere sulla materializzazione di un aggregato che viene interrogato con una frequenza minore ma che occupa minor spazio in memoria.
Un altro vincolo che l’amministratore del data warehouse deve considerare è quello relativo al tempo legato alla creazione di questa nuova tabella in memoria. Il processo ETL impiega generalmente un tempo molto lungo e rappresenta inoltre la fase più critica all’interno della manutenzione dell’intero data warehouse. Per questi motivi, uno degli obiettivi dell’amministratore del data warehouse è quello di minimizzare i suoi tempi,
30
cercando di limitare il più possibile sia il numero delle tabelle all’interno del data warehouse sia il numero degli attributi all’interno di ciascuna tabella. La criticità del processo ETL è data dal fatto che nel caso in cui esso fallisca, gli utenti finali degli strumenti di analisi front-end non hanno la possibilità di consultare i dati aggiornati. Inoltre è possibile visualizzare tali dati aggiornati soltanto al termine dell’intero processo di aggiornamento, che deve essere eseguito nel minor tempo possibile.
Dunque l’utente di Auto Tuning è tenuto a considerare anche quanto la costruzione dell’aggregato inciderà sulla durata temporale del processo ETL. Infatti, se il processo ETL già implementato sul data warehouse ha tempi di esecuzione molto lunghi, l’utente non potrà selezionare quegli aggregati che comportano un aumento significativo del tempo di tale processo.
Tutte queste considerazioni possono essere effettuate soltanto dall’amministratore del data warehouse o dagli addetti alla sua manutenzione, poiché devono essere considerati fattori relativi all’utilizzo che viene fatto del sistema Business Intelligence. Ci sono inoltre altre decisioni che possono essere prese congiuntamente a quella di costruire un nuovo aggregato in memoria, come per esempio quella di acquistare un nuovo componente hardware.
Il sistema di Auto Tuning è stato progettato considerando tutte queste esigenze che sono presenti all’interno di ciascun sistema di Business
31
Intelligence. Esso ha come obiettivo quello di fornire un supporto offrendo preziose informazioni in merito ai vincoli che devono essere considerati.
Per ciascun aggregato che il sistema genera dovranno essere fornite le seguenti informazioni:
Frequenza con cui l’aggregato viene interrogato;
Tempo necessario alla costruzione dell’aggregato;
Spazio occupato in memoria dall’aggregato.
Questi valori consentono all’utente di selezionare l’aggregato che più soddisfa le esigenze del data warehouse su cui viene effettuata l’analisi, tenendo in considerazione tutti i vincoli presenti sul sistema.
Nel data warehouse possono essere già presenti tabelle aggregate e attraverso questo strumento è possibile determinare la loro reale efficacia. Infatti possono essere state materializzate in memoria tabelle aggregate che in realtà non vengono consultate dagli utenti, pertanto è necessario individuare la causa del loro inutilizzo. Un errore sull’aggregazione anche di una singola dimensione può rendere inefficace la presenza dell’aggregato all’interno del data warehouse, peggiorando quindi le performance dell’intero sistema.
Tutte le funzionalità del sistema di Auto Tuning sono illustrate nel diagramma dei casi d’uso modellato attraverso il linguaggio UML (Unified
32
Il diagramma dei casi d’uso, riportato in figura 2.1, mostra le funzionalità offerte dall’intero sistema ad un alto livello di astrazione, non viene quindi tenuto in considerazione il linguaggio con cui verrà implementato il sistema.
33
38