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)

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 DB2

Database Sorgente DBN..

Data Warehouse

Database sorgenteTabella

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

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 (s

ec)

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)