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:
Chiar.ma Prof.ssa Bergamaschi Sonia
Correlatore:
Chiar.mo Prof. Bonfatti Flavio
Tesi di Laurea di:
Gelati Gionata
Obiettivo della tesi
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)
Percorso
Il problema affrontato
Gli elementi più significativi del modello di costo
Applicazione software
Esempi di risultati sperimentali
Data Warehouse
Database
Sorgente DB1
Database
Sorgente DB2
..
Database Sorgente
DBN
Data Warehouse
Il sistema considerato nel modello di costo
Database sorgente
Tabella
Dati
Data Warehouse
Vista
Delta
Update
Utenti
Query
Utenti
Il problema affrontato
nel Modello di costo
nella Tesi
Validazione
Sperimentale:
corrispondenza tra
il comportamento
di un sistema reale
e le predizioni del
modello
Specifiche sulla
qualità del servizio
Update
Politiche di
manutenzione
Processo di
selezione
basato
su criteri
di valutazione
Caratteristiche del sistema
Una politica
Sistema reale
+
Strumenti per
eseguire
esperimenti
Il modello di costo (1)
CHAW
(change
aware)
CHAC
(change
active)
DAW
(delta
aware)
La capacità di dire su richiesta
quando l’ultimo cambiamento è
stato effettuato
La capacità di rilevare e
riportare automaticamente che
cambiamenti
sono
stati
effettuati
La capacità di propagare i delta
change
(su
richiesta
o
automaticamente)
Caratterizzazione delle proprietà della sorgente
Il modello di costo (2) - Nuova metrica (qualitativa e quantitativa)
Istante in cui la query è
posta
Risposta basata sullo
stato 1 di S1 e 3 di S2
t
Z
DW
t
S1
0
1
t
S2
0
1
2
3
Misura staleness (Z)
Database
sorgente
Tempo di
esecuzione
Tempo di comunicazione
Data
Warehouse
Tempo di
esecuzione
Misure tradizionali (esecuzione e comunicazione)
Applicazione 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 - Architettura
Saccess
Interbase
ACCESS
Database sorgente
Supdater
thread
Wquerier
thread
Emulazione del carico
Row
Table
Nuovi tipi di dato
Director
Waccess
Wrapper
thread
Configuration
Data generator
Gui
Data warehouse
Controllo e misurazione
Entità del sistema
Classi di benchmark
Applicazione software – Implementazione (1)
Caratteristiche della sorgente
Tabella
Database
Sorgente
sorgente
Aggiornamenti
Supdater
Wrapper
Numero
dell’ultimo
update inviato
al DW
Tabella
Trigger
DAW
Update
Insert
Delete
Se
DAW
Se non
DAW
confronto
Waccess
Numero dell’ultimo
update della sorgente che
ha subito il commit
Le proprietà CHAC e CHAW
Wrapper
La proprietà DAW
Applicazione software – Implementazione (2)
Emulazione del carico di lavoro
Caratterizzazione degli update
Basata sull’analisi di Adelberg / Garcia-Molina:
Update parziali
Frequenza aperiodica
Esecuzione immediata
Distribuzione di Poisson
Applicazione software – Implementazione (3)
Emulazione del carico di lavoro
Esplorazione di nuovi algoritmi per produrre
il flusso di update
Pre- scheduling
Pro: flusso di update
pronto all’inizio di un
esperimento
Contro: numero di
update comunque
limitato
Run-time
Pro: flusso illimitato
Contro: attenzione ai
ritardi introdotti
Vincente:
Algoritmo del Guide Attribute a run-time
Validazione e Verifica
Validazione:
garantita dal modello di costo considerato
Verifica:
svolta mediante controllo dei protocolli e
del comportamento sotto carico
Verifica (1)
I protocolli
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
DAWTriggers Enabled
Delete successful!
SAccess: DAWdeleted
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: DAWdeleted
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
Metodo:
introduzione di
output di sistema
un
appropriato
Utilità:
1) Controllare la corretta sequenza
di operazioni nell’eseguire le
politiche di manutenzione
2) Verificare la effettiva
indipendenza tra i processi
concorrenti
Verifica (2)
Comportamento sotto carico
Metodo:
creazione di applicazioni esterne di
supporto per il monitoraggio della
dinamica del sistema
Utilità:
1) Osservare la evoluzione del
sistema nel tempo
2) Controllare le proprietà
statistiche degli algoritmi
(es: dimensione della tabella
sorgente e distribuzione dei
valori dei GA)
Benchmark
Ambiente 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)
Benchmark
Esempi (1)
P1 vs P2
Z (sec)
Legenda
180
160
140
120
100
80
60
40
20
0
P1: Modifica
Incrementale con DAW
(violetto)
0
0,01
0,02
0,03
0,04
polling frequency (1/sec)
0,05
0,06
P2: Modifica totale (blu)
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.
Benchmark
Esempi (2)
P1 vs P2
160
140
IC (sec)
120
100
80
60
40
20
0
0
0,02
0,04
0,06
0,08
0,1
0,12
polling frequency (1/sec)
Risultati sperimentali
( P1 blu, P2 violetto)
Predizioni del modello di costo
(P1 nero, P2 verde)
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.
CONCLUSIONI
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 futuri
Caso distribuito (Java RMI)
Estensione al caso multisorgente
Considerazione di sorgenti non-relazionali (XML)