Post on 01-May-2015
UNIVERSITA’ DEGLI STUDI DI MODENA E REGGIO EMILIA
Facoltà di Ingegneria – Sede di Modena
Corso di Laurea in Ingegneria Informatica
A BENCHMARKING ENVIRONMENT FOR VALIDATING
A DATA WAREHOUSE MAINTENANCE COST-MODEL
AMBIENTE DI BENCHMARKING PER LA VALIDAZIONE DI UN MODELLO DI COSTO
RELATIVO A POLITICHE DI MANUTENZIONE DI UN DATA WAREHOUSE
Relatore: Tesi di Laurea di: Chiar.ma Prof.ssa Bergamaschi Sonia Gelati Gionata Correlatore: Chiar.mo Prof. Bonfatti Flavio
Sviluppo di una applicazione software per verificare la correttezza di un modello di costo in ambito Data Warehouse
si è fatto riferimento al modello di costo pubblicato da Engström et al. la Tesi è stata svolta presso l’Università di Exeter (UK) e l’Università di Skövde (Svezia)
Sviluppo di una applicazione software per verificare la correttezza di un modello di costo in ambito Data Warehouse
si è fatto riferimento al modello di costo pubblicato da Engström et al. la Tesi è stata svolta presso l’Università di Exeter (UK) e l’Università di Skövde (Svezia)
Il problema affrontato
Gli elementi più significativi del modello di costo
Applicazione software
Esempi di risultati sperimentali
Il problema affrontato
Gli elementi più significativi del modello di costo
Applicazione software
Esempi di risultati sperimentali
Obiettivo della tesiObiettivo della tesi
PercorsoPercorso
Database Sorgente DB1
Database Sorgente DB1
Database Sorgente DB2
Database Sorgente DB2
Database Sorgente DBN
Database Sorgente DBN
..
Data WarehouseData Warehouse
Database sorgenteTabella
Database sorgenteTabella
Data WarehouseVista
Data WarehouseVista
Data WarehouseData Warehouse
Il sistema considerato nel modello di costoIl sistema considerato nel modello di costo
Update Query
Dati
Delta
Utenti Utenti
Update
ValidazioneSperimentale:
corrispondenza tra il comportamento di un sistema reale e le predizioni del
modello
Sistema reale+
Strumenti per eseguire
esperimenti
ValidazioneSperimentale:
corrispondenza tra il comportamento di un sistema reale e le predizioni del
modello
Sistema reale+
Strumenti per eseguire
esperimenti
Specifiche sulla qualità del servizio
Processo di selezione
basato su criteri
di valutazione
Caratteristiche del sistema
Politiche di manutenzione
Una politica
Il problema affrontatoIl problema affrontato nel Modello di costo nella Tesi
Il modello di costo (1)Il modello di costo (1)
Caratterizzazione delle proprietà della sorgente
CHAW (change aware)
La capacità di dire su richiesta quando l’ultimo cambiamento è stato effettuato
CHAC (change active)
La capacità di rilevare e riportare automaticamente che cambiamenti sono stati effettuati
DAW (delta aware)
La capacità di propagare i delta change (su richiesta o automaticamente)
Database sorgenteTempo di
esecuzione
Data WarehouseTempo di
esecuzione
Tempo di comunicazione
Misure tradizionali (esecuzione e comunicazione)
Misura staleness (Z)
DW
Istante in cui la query è posta
S1
S2
Risposta basata sullo stato 1 di S1 e 3 di S2
0 1
0 1 2 3
t
t
t
Il modello di costo (2) - Nuova metrica (qualitativa e quantitativa)Il modello di costo (2) - Nuova metrica (qualitativa e quantitativa)
Z
Applicazione software – Criteri guidaApplicazione software – Criteri guida
Per il linguaggio: portabilità, gestione della concorrenza, gestione connessioni a database;
Per l’architettura funzionale: chiara separazione tra le classi che modellano il sistema e le classi che si occupano di controllare e misurare lo stesso;
Per i benchmark: rilevanza delle grandezze osservate, scalabilità, chiarezza nell’esporre le caratteristiche dell’implementazione e nel presentare i risultati.
Applicazione software - ArchitetturaApplicazione software - Architettura
Saccess Interbase ACCESS
Row Table
Waccess Wrapperthread
Supdaterthread
Wquerierthread
Director Configuration
Data generator Gui
Entità del sistema Classi di benchmark
Database sorgente
Nuovi tipi di dato
Data warehouse
Emulazione del carico
Controllo e misurazione
Applicazione software – Implementazione (1)Applicazione software – Implementazione (1)Caratteristiche della sorgenteCaratteristiche della sorgente
La proprietà DAW
Supdater
DatabaseSorgente
Waccess
Aggiornamenti
Numero dell’ultimo update della sorgente che ha subito il commit
Le proprietà CHAC e CHAW
Tabella
sorgente
Tabella
DAWTrigger
UpdateInsertDelete
Wrapper
Se non DAW
Se DAW
Numero dell’ultimo update inviato al DWWrapper
confronto
Caratterizzazione degli updateBasata sull’analisi di Adelberg / Garcia-Molina:
Applicazione software – Implementazione (2)Applicazione software – Implementazione (2)Emulazione del carico di lavoroEmulazione del carico di lavoro
Update parziali
Frequenza aperiodica
Esecuzione immediata
Distribuzione di Poisson
Applicazione software – Implementazione (3)Applicazione software – Implementazione (3)Emulazione del carico di lavoroEmulazione del carico di lavoro
Esplorazione di nuovi algoritmi per produrre il flusso di update
Vincente:Algoritmo del Guide Attribute a run-timeAlgoritmo del Guide Attribute a run-time
Pre- schedulingPro: flusso di update pronto all’inizio di un esperimentoContro: numero di update comunque limitato
Run-timePro: flusso illimitato
Contro: attenzione ai ritardi introdotti
Validazione e VerificaValidazione e Verifica
Validazione: garantita dal modello di costo considerato
Verifica: svolta mediante controllo dei protocolli e del comportamento sotto carico
Verifica (1)Verifica (1) I protocolliI protocolli
Utilità:1) Controllare la corretta sequenza di operazioni nell’eseguire le politiche di manutenzione2) Verificare la effettiva indipendenza tra i processi concorrenti
Metodo:introduzione di un appropriato output di sistema
Here's Config Here's the Sync.Init ok! Here's WAccess Here's Wquerier Here's DBAccess Here's SAccess jdbc:interbase://vale.ida.his.se//db/chaffinch.gdb Here's Wrapper Here's SUpdater The SUpdate has been correctly set up Here's Datagenerator The Datagenerator has been correctly settup Delete successful! Here's MeasuresComputing Here's Monitor DAW Triggers Enabled Delete successful! SAccess: DAW deleted Source Setup ok Datagenerator:Table initialised! Initializing policy Source: sending the table in order of key for computing deltas Source: sending the table... Warehouse: view recomputed SAccess: DAW deleted Wrapper: initialisation successfully completed! Sync: Starting new thread for Wrapper Sync: Starting new thread for Source Updater SUpdater: thread effectevely started Sync: Supdater started.... Sync: Starting new thread for Warehouse Querier
Verifica (2)Verifica (2) Comportamento sotto caricoComportamento sotto carico
Utilità:1) Osservare la evoluzione del sistema nel tempo2) Controllare le proprietà statistiche degli algoritmi (es: dimensione della tabella sorgente e distribuzione dei valori dei GA)
Metodo: creazione di applicazioni esterne di supporto per il monitoraggio della dinamica del sistema
BenchmarkBenchmarkAmbiente di esecuzioneAmbiente di esecuzione
Piattaforma: Sun Ultra 5, Solaris 8, 128 MB, Interbase 6.0, Java 1.2, Codice bytecode 77 Kb
Tuning dei parametri di basso livello del sistema operativo e del Dbms
Ispezione della qualità dei risultati: si scartano i risultati ottenuti da esperimenti che non soddisfano i criteri di integrità definiti (es: overlapping update, overlapping query)
BenchmarkBenchmarkEsempi (1)Esempi (1)
Staleness al variare della frequenza di polling in caso di aggiornamenti periodici del data warehouse. Le due politiche offrono prestazioni sempre più simili al diminuire della frequenza di aggiornamento del DW.
P1 vs P2
020406080100120140160180
0 0,01 0,02 0,03 0,04 0,05 0,06
polling frequency (1/sec)
Z (s
ec)
Legenda
P1: ModificaIncrementale con DAW
(violetto)
P2: Modifica totale (blu)
Benchmark Benchmark Esempi (2)Esempi (2)
Costo integrato (esecuzione e comunicazione) al variare della frequenza di polling. L’evidenza sperimentale è in pieno accordo con le predizioni del modello anche in caso di configurazioni dei parametri estreme.
Risultati sperimentali( P1 blu, P2 violetto)
Predizioni del modello di costo(P1 nero, P2 verde)
P1 vs P2
0
20
40
60
80
100
120
140
160
0 0,02 0,04 0,06 0,08 0,1 0,12
polling frequency (1/sec)
IC (
se
c)
CONCLUSIONICONCLUSIONI
L’applicazione implementa tutti gli aspetti del modello di costo
Ha superato tutti i test di verifica
Gli esempi di benchmark hanno permesso di:
1) fornire conferma di taluni comportamenti del modello; 2) migliorare la nostra conoscenza sul suo comportamento;
3) evidenziare possibili punti di discussione per affinare il modello;
Sviluppi futuriSviluppi futuri
Caso distribuito (Java RMI)
Estensione al caso multisorgente
Considerazione di sorgenti non-relazionali (XML)