Bubble Chart

L’output finale fornito dal sistema di Auto Tuning è un bubble chart in cui ogni bubble rappresenta un aggregato e la sua grandezza è proporzionale alla copertura delle query che sono state effettuate sul data warehouse. Sull’asse delle ascisse è riportato il tempo, mentre in quello delle ordinate è riportato lo spazio.

63

Quindi ciascun aggregato sarà presente nel piano cartesiano con una bubble di grandezza proporzionale alla frequenza con cui sarà in grado di rispondere alle query, e sarà posizionata in corrispondenza dei valori stimati dall’engine. La figura 3.8 mostra un esempio di bubble chart fornito in output dal sistema.

L’aggregato ottimale, per migliorare le performance del data warehouse, è quello rappresentato dalla bubble con il diametro più grande che si trova il più vicino possibile all’origine. Questo significa che quell’aggregato sarà in grado di rispondere ad un elevato numero di query e

64

che sia lo spazio che il tempo necessario alla sua materializzazione non sono elevati.

È bene sottolineare che il sistema ha il solo scopo di suggerire in maniera proattiva la materializzazione di un aggregato, tuttavia la scelta finale e l’effettiva scrittura in memoria dell’aggregato è lasciata all’utente. La sua scelta sarà condizionata dai vincoli che dovrà rispettare sul proprio sistema che possono essere o relativi ad un limitato spazio libero in memoria, oppure all’impossibilità di attendere un tempo troppo elevato per la sua scrittura. Quest’ultimo caso si può verificare quando i tempi relativi ai processi ETL sono già molto elevati, infatti essi avvengono solitamente nel corso della notte ed in alcuni casi non è possibile prolungarli ulteriormente altrimenti gli utenti front-end non avrebbero la possibilità di consultare i dati aggiornati tempestivamente.

3.3

Informazioni Riguardanti lo Sviluppo

Durante questo progetto di tesi, l’implementazione ha riguardato il componente centrale del sistema di Auto Tuning, ovvero l’engine. Inoltre è stato sviluppato l’estrattore e la parte di interfaccia grafica riguardante la generazione del bubble chart in cui sono riportati gli aggregati ed i due sotto aggregati candidati alla materializzazione.

Il software è stato sviluppato con il linguaggio Java mediante l’utilizzo dell’editor NetBeans IDE 7.2.1.

65

Il livello fisico, che è stato utilizzato come riferimento durante tutto il processo di sviluppo, è stato il database Oracle DB 11g R2. Su di esso è stato creato il repository contenente tutte le tabelle necessarie al corretto funzionamento dell’intero sistema.

Oracle Database 11g R2 rappresenta il prodotto di Oracle più

conosciuto. Si tratta di un Object-Relational Database Management

System (ORDBMS) che negli anni è diventato una vera e propria

piattaforma arricchita da un esteso insieme di funzionalità di livello enterprise. Esse contribuiscono a creare un ambiente adatto per il data warehousing e la Business Intelligence, offrendo scalabilità, performance, security management, strumenti di analisi, integrazione, gestione della qualità dei dati e metodi di ottimizzazione come ad esempio partitioning, compression, in-memory parallel execution, cluster support, e cache management.

Per quanto riguarda l’implementazione dell’estrattore è stato preso come riferimento lo stesso database Oracle DB 11g R2, quindi il software utilizza il driver Oracle JDBC 1.5 per la connessione. L’estrattore preleva tutte le informazioni riguardanti le query che sono state lanciate sul database nell’ultimo mese e le memorizza nelle opportune tabelle descritte nel paragrafo 3.2.1.

Oracle DB è dotato di un meccanismo che consente di storicizzare automaticamente tutte le informazioni statistiche riguardanti le operazioni che avvengono sul database; questo componente si chiama Automatic

66

Workload Repository (AWR). Questo processo di memorizzazione dei dati

statistici viene ripetuto dall’AWR ad intervalli temporali regolari che prendono il nome di AWR snapshot. Il compito dell’estrattore per il data warehouse Oracle è quindi quello di recuperare queste informazioni dalle tabelle gestite dall’AWR ed inserirle nella tabella Sql_Extract_FullText.

Affinché l’AWR memorizzi tutte le query lanciate dagli utenti è necessario modificare i seguenti parametri di configurazione:

 SNAP_INTERVAL

 RETENTION

 TOPNSQL

Il parametro SNAP_INTERVAL configura l’intervallo temporale con cui l’AWR aggiorna le tabelle con le informazioni del database. È consigliato lasciare le impostazioni di default che raccolgono le informazioni statistiche ogni ora.

Il parametro RETENTION configura il tempo di conservazione delle snapshots all’interno delle tabelle gestite dall’AWR. Anche per questo parametro è consigliato lasciare l’impostazione di default di 30 giorni poiché la sua variazione può avere ripercussioni su altri componenti di Oracle DB come per esempio il Query Optimizer, componente che consente di ottimizzare l’esecuzione delle query considerando l’attuale carico di lavoro sul server.

67

Per far sì che il sistema di Auto Tuning funzioni correttamente è necessario modificare l’ultimo parametro di configurazione, ovvero il

TOPNSQL. Questo parametro indica il numero di query che devono essere

raccolte all’interno di ogni snapshot, è necessario quindi impostare il

TOPNSQL in maniera tale che venga tenuta traccia di tutte le query che

arrivano sul database; per far questo è necessario impostare tale parametro con il valore MAXIMUM.

Si tratta di parametri di configurazione molto delicati per Oracle database, è per questo motivo che è necessario loggarsi al database con le credenziali di amministratore del database (SYS).

I coefficienti α, β e γ del modello di regressione lineare, necessario per la stima del tempo di scrittura in memoria degli aggregati, sono stati determinati dal software statistico open source Gretl. I valori dei coefficienti vengono forniti in input al software manualmente poiché non è ancora stata sviluppata un’integrazione con quest’ultimo software.

L’output fornito dal software è un bubble chart che visualizza all’utente tutte le informazioni elaborate dall’engine in merito agli aggregati candidati alla materializzazione. Il plot di questo grafico viene realizzato mediante l’utilizzo della libreria grafica open source jFreeChart perfettamente integrata con il software poiché scritta con lo stesso linguaggio Java.

Vengono inoltre fornite in output informazioni che mostrano all’utente lo stato di avanzamento dell’analisi e vengono visualizzate le informazioni

68

dettagliate di tutti i parametri calcolati dall’engine. Nella figura 3.9 è riportato uno screenshot raffigurante le informazioni che vengono fornite all’utente insieme al bubble chart.

69

Testing

Il data warehouse dell’Azienda, su cui sono state effettuate le sperimentazioni per testare l’efficacia del sistema di Auto Tuning, è stato ben progettato e le sue performance, considerando la mole di interrogazioni a cui è quotidianamente sottoposto, sono soddisfacenti.

70

Tuttavia non tutti i report e le analisi che interessano gli utenti vengono eseguite in tempi rapidi, specialmente negli orari in cui il sistema è sottoposto a numerose interrogazioni da parte di un elevato numero di utenti. Come visualizzato nella figura 4.1, le prime ore lavorative mattutine sono quelle in cui vi è un elevato numero di query che vengono lanciate sul data warehouse. Inoltre i tempi di attesa sono più lenti anche perché sono sempre in corso i caricamenti ETL, i quali terminano l’aggiornamento di tutti i dati soltanto a metà mattinata.

Alcune dashboard vengono comunemente consultate attraverso dispositivi mobili come i tablet, quindi oltre ai tempi computazionali del data warehouse si devono aggiungere quelli relativi all’invio dei dati attraverso la rete. La sempre più crescente esigenza di avere il maggior numero di informazioni a portata di mano fa sì che si adottino soluzioni volte alla riduzione dei tempi di attesa.

71

Le query che andremo a testare sono quelle che hanno tempi di attesa superiori al minuto; la figura 4.2 mostra che esse sono la minoranza all’interno del sistema di BI dell’Azienda, tuttavia sono presenti e quindi è possibile ottenere un miglioramento delle loro prestazioni. L’obiettivo di questa fase di testing è quello di ridurre i tempi di risposta di alcune query posizionate nell’area gialla e rossa del grafico in figura 4.2.

4.1

Modello di Regressione Lineare per la