Architektur von Data Warehouse-Systemen

2. Architektur von Data Warehouse-Systemen
„
R f
Referenzarchitektur
hi k
–
–
–
–
„
„
Scheduler
q
Datenquellen
Datenextraktion
Transformation und Laden
Abhängige vs.
vs unabhängige Data Marts
Metadatenverwaltung
– Klassifikation von Metadaten (technische vs.
vs fachliche Metadaten)
– CWM: Common Warehouse Model
– Interoperabilitätsmechanismen
„
„
Operational
O
i l Data
D S
Store (ODS)
Master Data Managemnet (MDM)
SS08, © Prof. Dr. E. Rahm
y
y
y
2-1
DW-Referenzarchitektur
Datenquelle
Extraktion
Arbeitsbereich
Data
Warehouse
Laden
Laden
Monitor
Laden
Transformation
Datenquelle
Data
Mart
Dt
Data
Mart
Analyse
Analyse
Extraktion
DataWarehouseManager
Metadaten
Manager
Monitor
Datenfluss
Kontrollfluss
Repository
Data-Warehouse-System
SS08, © Prof. Dr. E. Rahm
2-2
y
y
y
Phasen des Data Warehousing
1. Überwachung der Quellen auf Änderungen durch Monitore
2 Kopieren der relevanten Daten mittels Extraktion in temporären
2.
Arbeitsbereich
3. Transformation der Daten im Arbeitsbereich
((Bereinigung,
g g Integration)
g
)
4. Kopieren der Daten ins Data Warehouse (DW) als Grundlage für
verschiedene
hi d
Analysen
A l
5. Laden der Daten in Data Marts (DM)
6. Analyse: Operationen auf Daten des DW oder DM
SS08, © Prof. Dr. E. Rahm
2-3
y
y
y
Datenquellen
„
„
Lieferanten
Li
f
der
d Daten
D
für
fü das
d Data
D Warehouse
W h
(gehören
( hö
nicht
i h
direkt zum DW)
M k l
Merkmale
–
–
–
–
„
intern (Unternehmen) oder extern (z.B. Internet)
ggf. kostenpflichtig
i.a. autonom
i.a. heterogen bzgl. Struktur, Inhalt und Schnittstellen (Datenbanken, Dateien)
Qualitätsforderungen:
–
–
–
–
–
–
–
–
Verfügbarkeit von Metadaten
Konsistenz (Widerspruchsfreiheit)
K
Korrektheit
kth it (Üb
(Übereinstimmung
i ti
mit
it R
Realität)
lität)
Vollständigkeit (z.B. keine fehlenden Werte oder Attribute)
Aktualität
V ä dli hk i
Verständlichkeit
Verwendbarkeit
Relevanz
SS08, © Prof. Dr. E. Rahm
2-4
y
y
y
Data-Warehouse-Manager/Scheduler
„
„
Ablaufsteuerung:
Abl
f
IInitiierung,
i ii
S
Steuerung und
d Üb
Überwachung
h
der
d
einzelnen Prozesse
I itii
Initiierung
ddes D
Datenbeschaffungsprozesses
t b h ff
und
d Üb
Übertragung
t
der
d
Daten in Arbeitsbereich
– in regelmäßigen
ege
ge Zeitabständen
e bs de (jede Nacht,
c , am Woc
Wochenende
e e de eetc.)
c.)
– bei Änderung einer Quelle: Start der entsprechenden Extraktionskomponente
– auf explizites Verlangen durch Administrator
„
„
Fehlerfall: Dokumentation von Fehlern,
Fehlern
Wiederanlaufmechanismen
Zugriff auf Metadaten aus dem Repository
– Steuerung des Ablaufs
– Parameter der Komponenten
SS08, © Prof. Dr. E. Rahm
2-5
y
y
y
Datenextraktion
„
Monitore:
M
i
E
Entdeckung
d k
von D
Datenmanipulationen
i l i
in
i einer
i
Datenquelle
– interne Datenquellen: aktive Mechanismen
– externe Datenquellen: Polling / periodische Abfragen
„
Extraktionskomponenten: Übertragung von Daten aus Quellen in
Arbeitsbereich
b i b i h
–
–
–
–
„
„
„
„
periodisch
auf Anfrage
ereignisgesteuert (z.B. bei Erreichen einer definierten Anzahl von Änderungen)
sofortige Extraktion
unterschiedliche Funktionalität der Quellsysteme
Nutzung von Standardschnittstellen (z.B. ODBC) oder
Eigenentwicklung
Performance-Probleme bei großen Datenmengen
A t
Autonomie
i der
d Quellsysteme
Q ll t
ist
i t zu wahren
h
SS08, © Prof. Dr. E. Rahm
2-6
y
y
y
Datenextraktion: Strategien
„
„
Snapshots:
S
h
periodisches
i di h Kopieren
K i
des
d Datenbestandes
D
b
d in
i Datei
D i
Trigger
– Auslösen von Triggern bei Datenänderungen und Kopieren der geänderten Tupel
„
Log-basiert
– Analyse von Transaktions
Transaktions-Log-Dateien
Log Dateien der DBMS zur Erkennung von Änderungen
„
Nutzung von DBMS-Replikationsmechanismen
Autonomie
Performanz
Nutzbarkeit
Snapshot
Log
Trigger
Replikation
SS08, © Prof. Dr. E. Rahm
2-7
y
y
y
Datentransformation und Laden
„
Ab b
Arbeitsbereich
h (engl.:
( l Staging
S
A
Area))
–
–
–
–
„
Temporärer Zwischenspeicher zur Integration und Bereinigung
g
Abschluss der Transformation
Laden der Daten ins DW erst nach erfolgreichem
Keine Beeinflussung der Quellen oder des DW
Keine Weitergabe fehlerbehafteter Daten
Transformationskomponente: Vorbereitung der Daten für Laden
– Vereinheitlich von Datentypen, Datumsangaben, Maßeinheiten, Kodierungen etc.
– Data Cleaning und Scrubbing: Beseitigung von Verunreinigungen, fehlerhafte oder fehlende
Werte, Redundanzen,
d d
veralteten
l
Werte
– Data Auditing:Anwendung von Data-Mining-Verfahren zum Aufdecken von Regeln und
Aufspüren von Abweichungen
„
Ladekomponente: Übertragung
Ü
der bereinigten und aufbereiteten
(z.B. aggregierten) Daten in DW
– Nutzung spezieller Ladewerkzeuge (z.B.
(z B Bulk Loader)
– Historisierung: zusätzliches Abspeichern geänderter Daten anstatt Überschreiben
– Offline vs. Online-Laden (Verfügbarkeit des DW während des Ladens)
SS08, © Prof. Dr. E. Rahm
2-8
y
y
y
Data Marts
„
W ist
Was
i eine
i Data
D Mart?
M ?
– eine Teilmenge des Data Warehouse
p oder Geschäftsbereich
– inhaltliche Beschränkungg auf bestimmten Themenkomplex
„
„
führt zu verteilter DW-Lösung
Gründe für Data Marts
– Performance: schnellere Anfragen, weniger Benutzer, Lastverteilung
– Eigenständigkeit, Datenschutz
– ggf.
ggf schnellere Realisierung
„
Probleme
– zusätzliche Redundanz
– zusätzlicher Transformationsaufwand
– erhöhte Konsistenzprobleme
„
Varianten
– Abhängige Data Marts
– Unabhängige Data Marts
SS08, © Prof. Dr. E. Rahm
y
y
y
2-9
Abhängige Data Marts
SSoouurrccee 11
SSoouurrccee 22
S a le s M a r t
D a ta
W areh o u se
C u s tto m e r S e r v iic e
M a rt
SSoouurrccee 33
„
„
F in a n c ia l M a r t
„NabeNabe und Speiche“
Speiche“-Architektur
Architektur (hub and spoke)
Data Marts sind Extrakte aus dem zentralen Warehouse
– strukturelle Ausschnitte (Teilschema
(Teilschema, z.B.
z B nur bestimmte Kennzahlen)
– inhaltliche Extrakte (z.B. nur bestimmter Zeitraum, bestimmte Filialen ...)
– Aggregierung (geringere Granularität), z.B. nur Monatssummen
„
Vorteile:
il
– relativ einfach ableitbar (Replikationsmechanismen des Warehouse-DBS)
y
auf Data Marts sind konsistent mit Analysen
y
auf Warehouse
– Analysen
„
Nachteil: Entwicklungsdauer (Unternehmens-DW zunächst zu erstellen)
SS08, © Prof. Dr. E. Rahm
2-10
y
y
y
Unabhängige Data Marts
„
Source11
Source
Sales Mart
Source11
Source
Sales Mart
Source22
Source
Financial Mart
Source22
Source
Financial Mart
Source33
Source
Customer Service
Mart
Source33
Source
Customer Service
Mart
Data
Warehouse
Variante 1: kein zentrales, unternehmensweites DW
–
–
–
–
–
wesentlich einfachere und schnellere Erstellung der DM verglichen mit DW
Datenduplizierung zwischen Data Marts, Gefahr von Konsistenzproblemen
Aufwand wächst proportional zur Anzahl der DM
schwierigere Erweiterbarkeit
keine unternehmensweite Analysemöglichkeit
„
Variante 2: unabhängige DM + Ableitung eines DW aus DM
„
Variante 3: unabhängige DM + Verwendung gemeinsamer Dimensionen
SS08, © Prof. Dr. E. Rahm
2-11
y
y
y
Metadaten-Verwaltung
„
A f d
Anforderungen
an M
Metadaten-Verwaltung
d
V
l
/ Repository
R
i
–
–
–
–
–
„
vollständige Bereitstellung aller relevanten Metadaten auf aktuellem Stand
g
g
((DB-basiert)) über mächtige
g Schnittstellen
flexible Zugriffsmöglichkeiten
Versions- und Konfigurationsverwaltung
Unterstützung für technische und fachliche Aufgaben und Nutzer
ve Nutzung
u u g für
ü DW-Prozesse
W o esse (Datentransformation,
( e
so
o , Analyse)
yse)
aktive
Realisierungsformen
– werkzeugspezifisch: fester Teil von Werkzeugen
– allgemein einsetzbar: generisches und erweiterbares Repository-Schema (Metadaten-Modell)
„
„
zahlreiche proprietäre Metadaten-Modelle
S d di i
Standardisierungsbemühungen
b üh
– Open Information Model (OIM): Metadata Coalition (MDC) - wurde 2000 eingestellt
) Object
j Management
g
Groupp (OMG)
(
)
– Common Warehouse Metamodel ((CWM):
„
häufig Integration von bzw. Austausch zwischen dezentralen
Metadaten-Verwaltungssystemen notwendig
SS08, © Prof. Dr. E. Rahm
2-12
y
y
y
Metadaten: Beispiel
SS08, © Prof. Dr. E. Rahm
y
y
y
2-13
Metadaten im Data Warhouse-Kontext
Transformations-Jobs
Job-Scheduling,
-Ausführung
Datenqualitäts- Warehouse-schema, Konzeptionelle,
statistiken
-tabellen, attribute Multidimensionale
Datenmodelle
Transformationsregeln,
Cleaning-Regeln
Geschäftsbeschr.
von Entities
Entities, Attr.,
Attr
Dim., Kennzahlen
Business Terms
Vokabulare
Datenbankschemas,
Flatfile Formate
Flatfile-Formate
Reports,
p ,Q
Queries
Quellspezifika
((DBMS,, IP,, URL))
Zugriffsmuster,
-statistics
Nutzerprofile,
-rolle, -rechte
Authorisierung
(Name, Password)
SS08, © Prof. Dr. E. Rahm
2-14
y
y
y
Klassifikation von DW-Metadaten
USERS
technical users
business users
d t marts
data
t
DATA
data warehouse
metadata
data warehouse
operational
design populate admin
Technical User
USER
analyze
PROCESSES
Business User
takes part in
PROCESSES
Design
Populate
Administer
Analyze
involves data in
DATA
O
Operational
i l
SS08, © Prof. Dr. E. Rahm
D W
Data
Warehouse
h
D M
Data
Marts
2-15
y
y
y
Technische Metadaten
„
S h
Schemata
– Datenbank-Schemata, Dateiformate
„
Quell Ziel-Systeme
Quell-,
Ziel Systeme
– technische Charakteristika für Zugriff (IP, Protokoll, Benutzername und Passwort, etc.)
„
Datenabhängigkeiten: (technische) Mappings
– Operationale Systeme <-> Data Warehouse, Data Marts: Datentransformations-Regeln
– Data Warehouse, Data Marts <-> Datenzugriff-Tools: Technische Beschreibung von Queries,
Reports Cubes (SQL
Reports,
(SQL, Aggregation
Aggregation, Filters
Filters, etc
etc.))
„
Warehouse-Administration (Datenaktualisierung, -archivierung,
p
g)
Optimierung)
– Systemstatistiken (Usage Patterns, nutzer-/gruppenspezifische CPU-/ IO-Nutzung, ...) für
Resourcenplanung und Optimierung
g
(Scheduling),
(
g), Logging-Information,
gg g
, Job-Ausführungsstatus
g
– Häufigkeit
– Regeln, Funktion für Datenselektion für Archivierung
SS08, © Prof. Dr. E. Rahm
2-16
y
y
y
Business-Metadaten
„
„
„
„
„
IInformationsmodelle,
f
i
d ll konzeptuelle
k
ll Datenmodelle
D
d ll
Unternehmens-/Branchen-spezifische Business Terms,
V k b l
Vokabulare,
T
Terminologien
i l i
Abbildungen zwischen Business Terms und Warehouse/Data
Mart Elementen (Dimensionen,
Mart-Elementen
(Dimensionen Attribute,
Attribute Fakten)
Geschäftsbeschreibung von Queries, Reports, Cubes, Kennzahlen
D t
Datenqualität
lität
– Herkunft (lineage): aus welchen Quellen stammen die Daten? Besitzer?
g
((accuracy):
y) welche Transformation wurden angewendet?
g
– Richtigkeit
– Aktualität (timeliness): wann war der letzte Aktualisierungsvorgang?
„
Personalisierung
– B
Beziehungen
i h
zw. Nutzer,
N
Nutzerrollen,
N
ll Informationsobjekten,
I f
i
bj k
Interessengebieten
I
bi
undd
Aktivitäten
– Zuordnung von Nutzer zu Rollen, von Rollen zu Aktivitäten bzw. zu Interessengebieten, und
von
on Akti
Aktivitäten
itäten zu Informationsobjekten und
nd Interessengebieten
SS08, © Prof. Dr. E. Rahm
2-17
y
y
y
Business Metadaten: Beispiel
„
B i
Business
Terms
T
für
fü Versicherungsindustrie
V i h
i d i
Liability Insurance:
Insurance covering the legal liability of the insured resulting from injuries to a third party to their body
or damage
g to their pproperty.
p y
Life Insurance:
Insurance providing payment of a specified amount on the insured
insured'ss death
death, either to his or her estate or
to a designated beneficiary.
Liquor Liability Insurance:
Provides protection for the owners of an establishment that sells alcoholic beverages against liability
arising out of accidents caused by intoxicated customers.
Long-Term Disability Insurance:
Insurance to provide a reasonable replacement of a portion of an employee's earned income lost through
serious illness or injury during the normal work career:
SS08, © Prof. Dr. E. Rahm
2-18
y
y
y
Business Metadaten: Beispiel
SS08, © Prof. Dr. E. Rahm
y
y
y
2-19
Common Warehouse Metamodel (CWM)
„
„
umfassende
f
d UML
UML-basierte
b i
Metadaten-Modelle
M d
M d ll für
fü Data
D
Warehousing
Warehouse
Warehouse
Warehouse
OMG St d d
OMG-Standard
Management
Process
Operation
– CWM 1.0: 2001
– CWM 1.1: 2002
Analysis
ObjectOriented
Resources
Relational
(ObjectModel)
Foundation
Data
Information
Business
Mining Visualization Nomenclature
Transformation OLAP
RecordOriented
Multi
Dimensional
XML
Business Data
Keys
Type
Software
Expressions
Information Types
Index Mapping Deployment
ObjectModel
(Core, Behavioral, Relationships, Instance)
„
„
Web-Infos: www.omg.org/cwm , www.cwmforum.org
geringe Produktunterstützung
SS08, © Prof. Dr. E. Rahm
2-20
y
y
y
CWM: Relationales Teilmodell
/constraint
/constrainedElem ent
CheckConstraint
*
deferrability : DeferrabilityT ype
{ordered}
*
Colum n
*
/co nstran t
Colum nSet
precision : Integer
scale : Integer
/feature isNullable : NullableT ype
0..1
length : Integer
/owner
* collationNam e : String
{ordered} characterSetNam e : String
/ optionScopeColum nSet : Nam edColum nSet
/ referencedT ableT ype : SQLStructuredT ype
*
/structuralFeature
/type
1
SQLDataType
typeNum
yp
ber : Integer
g
Nam edColum nSet
/ optionScopeColum n : Colum n
/ type : SQLStructuredT ype
/ usingT rigger : T rigger
SQLD istinctT y pe
length : Integer
precision : Integer
scale : Integer
/ sqlSim pleT ype : SQLSim pleT ype
/constrainedElem ent
Qu eryC olum nSet
query : QueryExpression
sqlDi stinctT ype
*
*
SQLSim pleT ype
{ordered}
T able
isT em porary : Boole an
temporaryScope : S tring
/ trigger
ti
: Trigg
T i er
isSystem : Boolean
characterM axim um Length : Integer
characterOctetLength : Integer
1
num ericPrecision : Integer
sql Sim pleT ype num ericPrecisionRadix : Integer
num ericScale : Integer
dateT im ePrecision : Integer
View
isReadOnly : Boolean
p
: Boolean
checkOption
queryExpression : QueryExpression
SS08, © Prof. Dr. E. Rahm
y
y
y
2-21
Metadaten: Architekturalternativen
Tool A
Tool B
Tool C
„
– keine Metadaten-Replikation
gg
zu zentralem Repository
p
y auch
– Abhängigkeit
für lokale Metadaten
– unzureichende Autonomie
Central Repository
„
Tool A
Tool C
Local
Repository
Local
Repository
Local
Repository
Tool B
Tool C
Local
Repository
Local
Repository
Shared Metadata
SS08, © Prof. Dr. E. Rahm
verteilte Repositories
– maximale Unabhängigkeit
– schneller Zugriff auf lokale Metadaten
– zahlreiche
hl i h Verbindungen
bi d
zum
Metadatenaustausch
– großer Grad an Metadaten-Replikation
– schwierige
h i i Synchronisation
S h i ti
Local
Repository
Tool B
Tool A
zentrales
l Repository
R
i
„
föderiert (shared repository)
– einheitliche Repräsentation gemeinsamer
Metadaten
– lokale Autonomie
Metadaten Austausch
– begrenzter Umfang an Metadaten-Austausch
– kontrollierte Redundanz
Shared Repository
2-22
y
y
y
Interoperabilitätsmechanismen
„
D i
Dateiaustausch
h
– kein Repository-Zugriff
plattform-unabhängig,
g g, einfach realisierbar , asynchron
y
– p
– Standardformate: MDIS, CDIF, XML
„
Application Programming Interface (API)
– direkter Repository-Zugriff, synchron
– derzeit proprietär und aufwendig zu nutzen
– Standards für Daten- und Metadatenzugriff: ODBC, OLEDB for OLAP
„
Metadaten-Wrapper
Tool A
– Abbildung zwischen
unterschiedlichen Metadaten- Local
Repository
Repräsentationen
– entweder asynchron
(Dateiaustausch) oder synchron
W1
(API-basiert)
– nur proprietäre, tool-/repositoryp
Produkte,
spezifische
Anbieterabhängigkeit
– Beispiele: Ardent MetaBroker
SS08, © Prof. Dr. E. Rahm
Tool B
Tool C
Local
Repositor
Repository
Local
Repository
i
W2
Shared Metadata
W3
Publishers /
Subscribers
M d
Metadata
Wrappers
W
Shared Repository
2-23
y
y
y
Kommerzielle Repository-Produkte
„
T l
Tool-spezifische
ifi h Repositories:
R
i i
– ETL-Tools: Informatica PowerMart, PowerCenter, ...
g
Sybase
y
PowerDesigner,
g , Oracle Designer,
g , CA Erwin ...
– Modellierungs-Tools:
„
“Generische” Repositories
– flexible und erweiterbare Metadatenmodelle, breitere Einsatzgebiete, Tool-Integration
– Bsp.: IBM DataGuide, Microsoft Repository, Sybase, UniSys Universal Repository
„
Meist proprietäre Metadaten-Modelle (realisiert über interne
Datenbank) und eingeschränkte Interoperabilität
– Import: Schema-Metadaten aus CASE-Tools / DBMS; Transformationsmetadaten aus ETLTools
– Export:
E
t: Querying-,
Q e i
Re ti
Reportingundd OLAP-Tools
OLAP T l
„
v.a. passive Nutzung von Metadaten (Systemdokumentation,
Nutzerinformation)
– keine Query-Übersetzung zwischen Business-Terms und Datenbankschemata
– kaum Unterstützung für Metadaten-/ Schemaintegration und automatische MetadatenSynchronisation
SS08, © Prof. Dr. E. Rahm
2-24
y
y
y
Operational Data Store (ODS)
„
optionale Komponente einer DW-Architektur zur Unterstützung
operativer (Realzeit-) Anwendungen auf integrierten Daten
– grössere
ö
D
Datenaktualität
t kt lität als
l Warehouse
W h
– direkte Änderbarkeit der Daten
– geringere Verdichtung/Aggregation, da keine primäre Ausrichtung auf Analysezwecke
„
Probleme
– weitere Erhöhung
der Redundanz
– geänderte Daten im ODS
Ad hoc-Abfragen
O A
OLAP
D
Data
mining
i i
Operational
Data Store (ODS)
Kern-Data
Kern
Data W arehouse
SS08, © Prof. Dr. E. Rahm
Real-time
Anwendungen
y
y
y
2-25
Master Data Management (MDM)
„
Nutzung iintegrierter
N
i
M
Masterdaten
d
(R f
(Referenzdaten,
d
S
Stammdaten)
d
)
nicht nur für Analysezwecke, sondern auch für operative
Anwendungen und Geschäftsprozesse
– CDI: Customer Data Integration
– Produktdaten,, Konten,,
Mitarbeiterdaten, …
„
MDM-Erstellung ähnelt
DWH E ll
DWH-Erstellung,
jedoch
j d h unterschiedliche Nutzungsrollen
– Replikation (Caching) von Masterdaten in
Anwendungen mit Änderungsmöglichkeit
„
MDM-Unterstützung im Rahmen
von Anwendungsarchitekturen
A
d
hit kt
(SOA), z.B.
– SAP NetWeaver , IBM , Oracle , Microsoft .…
„
MDM muß skalierbar und erweiterbar sein
SS08, © Prof. Dr. E. Rahm
2-26
Quelle: IBM
y
y
y
MDM-Architektur
„
„
Materialisierte
M
i li i
oder
d virtuelle
i
ll Realsierung
R li
eines
i
MDM-Hubs
MDM H b
Beispiel einer Hub-Architektur (Quelle: Microsoft*)
*R. Wolter: Master Data Management
(MDM) Hub Architecture.
Architecture MSDN Article,
Article
April 2007
SS08, © Prof. Dr. E. Rahm
2-27
y
y
y
Zusammenfassung
„
K
Komponenten
dder R
Referenzarchitektur
f
hi k
–
–
–
–
–
–
Datenquellen
ETL-Komponenten (Extraktion, Transformation, Laden) inklusive Monitoring und Scheduling
Arbeitsbereich
b i b i h (staging
(
i area))
Data Warehouse und Data Marts
Analyse-Tools
Metadaten Verwaltung
Metadaten-Verwaltung
„
Extraktionsansätze: Snapshot, Trigger, Log-Transfer, DBMSReplikationsverfahren
„ Abhängige vs. unabhängige Data Marts
„ Systematische Verwaltung von DW-Metadaten notwendig
–
–
–
–
„
Technische Metadaten vs.
vs Business Metadaten,
Metadaten ...
derzeit: Ko-Existenz lokaler Repositorien mit proprietären Metadaten-Modellen
CWM-Standard: UML-basiert, umfassend, unzureichende Produktunterstützung
Metadaten-Interoperabilität
Metadaten
Interoperabilität v.a. über Dateiaustausch und Low
Low-Level
Level Repository APIs
Unterstützung operativer Anwendungen auf integrierten Daten
– ODS: Online Data Store
– MDM: Master Data Management
SS08, © Prof. Dr. E. Rahm
2-28
y
y
y