„Chess Pieces“ nach Kimball im Lifecycle - fbi.h

Applied Data Warehousing
Belegnummer 002.22110 (NFE211)
Michael Cordes
Holger Oehring
Matthias Rein
Prolog
 Vorstellung
 Ablauf der Veranstaltung (Mikro & Makro)
 Teilnehmerliste (CNAM)
 Begleitende Literatur
2
2
Prolog
Vorstellung
Michael Cordes
 Architektur & Modellierung
Matthias Rein
 ETL
Holger Oehring
 Metadaten & Tools
3
3
Prolog
Ablauf der Veranstaltung
15.10.2016 MIC
Architektur
9:00 - 12:00 Uhr
4
22.10.2016 MIC
Datenmodellierung
9:00 - 15:00 Uhr
4+2
29.10.2016 MIC
Datenmodellierung
9:00 - 15:00 Uhr
4+2
05.11.2016 MIC
Datenmodellierung
9:00 - 15:00 Uhr
4+2
12.11.2016 MSR
ETL
9:00 - 15:00 Uhr
4+2
19.11.2016 MSR
ETL
9:00 - 15:00 Uhr
4+2
26.11.2016 MSR
ETL
9:00 - 15:00 Uhr
4+2
03.12.2016 HOE
Reporting
9:00 - 15:00 Uhr
4+2
10.12.2016 HOE
Metadaten
9:00 - 15:00 Uhr
4+2
14.01.2017 HOE
QA / Wiederholung
9:00 - 15:00 Uhr
4+2
9:00 - 12:00 Uhr
4
21.01.2017 MIC/MSR/HOE Prüfung (Klausur)
https://www.fbi.h-da.de/organisation/personen/cordes-michael-oehring-holger-rein-matthias.html
MIC
MSR
HOE
Michael Cordes
Matthias Rein
Holger Oehring
Raum
Labor
D14 / 111
D14 / 112
4
4
Begleitende Literatur
Ralph Kimball
 The Data Warehouse Lifecycle Toolkit
 The Data Warehouse Toolkit:
The Complete Guide to Dimensional Modelling
 The Data Warehouse ETL Toolkit
 KDT
http://www.kimballgroup.com/html/forms/sendmail.html?TrkID=DT128_SUBS
Larry English
 Improving Data Warehouse and Business Information
Quality: Methods for Reducing Costs and Increasing
Profits
Bill Inmon
 Managing the Data Warehouse
5
5
Warm-Up
 Begriffe rund um DWH
 Wozu überhaupt ein DWH?
 Das kann DWH in der Praxis sein
6
6
Warm-Up
Begriffe rund um DWH
 Liste mit 20 Fragen rund um‘s Data Warehousing
 Stichwörter ( Brainstorming)
 20 Minuten
 Keine Namen
7
7
Warm-Up
Wozu überhaupt ein DWH?
 Es sind doch alle Daten da!
… aber diese Daten:
 … sind verteilt
 … liegen in unterschiedlichen Strukturen vor
 … haben unterschiedliche Bedeutung
 … dürfen nicht von allen gelesen werden
 … müssen schnell abrufbar sein
 … müssen zeitlich & inhaltlich konsistent sein
 …
8
8
Warm-Up
Das kann DWH in der Praxis sein
9
9
Warm-Up
Das kann DWH in der Praxis sein
10
10
Warm-Up
Das kann DWH in der Praxis sein
RTB QA-Prozess
Workflow-Tool
JIRA
n
Ei
RP
Referenzdatenpfleger
be
ar
b
- neue Anforderungen
- Unterstützung/Eingabe
bzgl. Daten-QA
Maßnahmen entscheiden:
- Teillieferungen
- Korrekturlauf
- etc.
plant
QM
p
QA Manager rüft t
e ch
nis
t fac
p rü f
ch
be
ga
ft F
re i
ein
se n
/w
w
und ertet
his aus
tor
i si e
rt
h
e rt
eilt
OP
Operator
lic
alt
se
es t
o z ch
Pr rwa
t
rte be
sta nd ü
u
inh
Pa
r
d i e a me t
Pro er f
duk ür
tion
Checkliste
flie
s
n
vo
ng
n
ei igu en
ßt cht ng
flie ksi irku
üc lw
e r se
r B ch
te We
Operatingund
Resource-Plan
im
Scheduler
Analyst
SAS, SQL
BA
h
hlic Business Approver
QA-Monitor:
- Process M.
- Business M.
stellt a
uf
un
AV
Arbeitsvorbereiter
fließt ein
BIP - WEB
Anwender
rru
tiert
Regelprozeß
im
Prozeß Repository
sts
:
ts
es
qu rten
e
R sta ng
n
ru
vo l a u f d e
n
n
r
lle ktu enä
e
t
e
n s rr o d
Ei - Ko eth
-M
ide
me n
n/
mi g
ter un
fer fer
L i e e rl i e
nd
So
imple
Sonderprozess:
- Korrektur
- Archivierung
- Reorganisation
Re
e
qu
en
eit
:
ts
es
qu
Re e
n uf
vo r l ä n
n de ture
le
el on ek
st - S o r r
-K
PV
Prozessveantwortlicher
vorgelagerte Systeme
SI
SonderprozessImplementierer
Prozessprotokolle
technisch
is
Bas
für
e
technische Freigab
ltliche Freigabe
automatisierte inha
DK
Dokumentierer
BIP
Freigabefunktion
Veröffentlichung /
Dokumentation /
Archivierung
11
11
Inhalte
 Datenmodellierung (Block I)
 Architekturansätze
 Lebenszyklus
 Projektorganisation
 Anforderungsaufnahme
 Modellierung
 ETL (Block II)
 Analyse der Vorsysteme
 Datenqualität & Testen
 Schlüsselmanagement
 Analyse (Block III)
 Reporting & Analyse
 Speicherstrukturen & Datenbankkonzepte
 Metadaten
 QS
12
12
Ziele eines DWHs
 Informationen müssen
 einfach zugänglich sein
 zusammen passen (Konsistenz)
 geschützt sein
 Unterstützung des Entscheidungsprozesses
 Akzeptanz durch die Anwender
13
13
DWH – Eine Analogie
Verlagswesen
 Kenne deine Leser
 Veröffentliche die richtigen Themen
 Enttäusche (und täusche) die Leser nicht
 Themen (Eingaben) kommen aus verschiedenen
Quellen
 Bearbeitung hinsichtlich Qualität und Konsistenz
 Regelmäßige Veröffentlichung
 Der Erfolg lässt sich an den Lesern ablesen!
14
14
DWH – Eine Analogie
DWH
 Kenne Deine Anwender – den Fachbereich
 Veröffentliche die richtigen Daten
 Wichtig
 Verständlich
 Angemessene Zugriffszeit
 Kosten (TCO)
 Daten kommen aus verschiedenen Quellen
 Sicherstellung der Qualität
 Bedarfsgerechte Datenbereitstellung
 Der Erfolg lässt sich an den Nutzern ablesen!
15
15
Architektur
 Datenbereitstellung
 Extraktion
 Staging
 Transformation
 Berichtswesen & Analyse
 Projektdurchführung
 Anforderungsanalyse
 Datenmodellierung
 Projektmanagement
 …
16
16
Ansatzarten zur Datenbereitstellung
 Corporate Information Factory (CIF) nach Inmon
 „Chess Pieces“ nach Kimball im Lifecycle
17
17
Ansatzarten
Corporate Information Factory (CIF)
Präsentationsschicht
Data Staging
Extrakt
Enterprise
DWH
Extrakt
Extrakt
Load
Normalisiert
(3NF)
E
T
Load
Aggregierte
Daten
für
Geschäftsber
eiche
Auswertung
Zugriff auf Detaildaten
18
18
Ansatzarten
Corporate Information Factory (CIF)
 3NF, Datamarts werden abgeleitet
 Atomare Daten in der Regel nicht in den Datamarts,
sondern nur im EDW: Enterprise DWH
 atomare Daten: Enterprise DWH
 aggregierte Daten: Dimensional Models
19
19
Ansatzarten
„Chess Pieces“ nach Kimball
Data Staging
Präsentationsschicht
Auswertung
Services:
AdHoc SQL
Extrakt
ReportingTools
Datamarts
Data-Mining
Data Stores:
Extrakt
Auswertung
Load
Designziele:
Extrakt
Zugriff auf Detaildaten
Busarchitektur
20
20
Ansatzarten
„Chess Pieces“ nach Kimball im Lifecycle
 Data Staging & Presentation klar getrennt
 Zugriff ausschließlich auf Data Presentation
 Daten werden in Themenbereiche geclustert
 Atomare Daten in der Präsentationsschicht
21
21
Ansatzarten
Hybrid
Data Staging
Präsentationsschicht
Auswertung
Extrakt
Datamarts
Enterprise
DWH
Extrakt
Extrakt
Load
Normalisiert
(3NF)
E
T
Auswertung
Load
Busarchitektur
22
22
Ansatzarten
Hybrid
 Zugeständnis (Inmon):
 Enterprise DWH (persistente Staging Area in 3. NF)
 Aber: klare Trennung Data Staging & Presentation
 Atomare UND aggregierte Daten: Dimensional
Models
 Beide Ansätze werden „verheiratet:
 Prinzipiell Okay, aber teuer!
23
23
Projekt
Evolution eines DWHs
Ermittlung
des
AnalyseBedarfs
und der
Aktuellen
Datenversorgung
Technische
Architektur
Produktauswahl/
Entwicklung
Frontend/Backend
Modellierung
Definition Rahmenwerk
Datenextraktion
Transformation
Laden
Betrieb
Neue
Priorisierung
Begleitende organisatorische
Umsetzungsmaßnahmen
Projekt-Management
24
24
Häufigsten Fehler
1. Es gibt keinen echten Business-Sponsor
2. Erwartungen sind nicht zu erfüllen
3. Unterschätzung der politischen Komponente
4. Daten werden geladen nur weil sie da sind
5. Das DWH wird wie ein OLTP System entworfen
6. Der DWH Manager ist vor allem technisch ausgerichtet
7. Daten sind nicht ausreichend sauber definiert
8. Vertrauen in Performance- und
Skalierungsversprechen (der Hersteller)
9. Ein laufendes DWH wird es schon richten
10. Konzentration auf AdHoc-Reporting
25
25
Projekt
Evolution eines DWHs
Ermittlung
des
AnalyseBedarfs
und der
Aktuellen
Datenversorgung
Technische
Architektur
Produktauswahl/
Entwicklung
Frontend/Backend
Modellierung
Definition Rahmenwerk
Datenextraktion
Transformation
Laden
Betrieb
Neue
Priorisierung
Begleitende organisatorische
Umsetzungsmaßnahmen
Projekt-Management
26
26
Projekt aufsetzen
Definieren
 Bereitschaft abklären
 Senior Management Sponsor
 Business Motivation
 Durchführbarkeit
 Risiken einschätzen
 Datenqualität
 Zusammenarbeit
 Scope & Fahrplan
 Was, wann, wie?
 Business Case & Rechtfertigung
 Kosten & Erträge
 ROI
27
27
Projekt aufsetzen
Planen
 Projekt Identität: Namen
 Besetzen (Rollen)
 Business Sponsor / IT BI Manager
 Projektleiter Business / IT
 Business Analyst
 Data Steward (QS)
 Data Architect/Datenmodellierer/DBA
 Metadaten Manager
 ETL Architekt / Entwickler
 BI Architekt / Entwickler
28
28
Projekt aufsetzen
Planen
 Projektplan entwickeln
 Resourcen
 Aufwandschätzung mit Meilensteinen
 Status
 Abhängigkeiten
 Kommunikationsplan
 Statusmeetings
 JF
29
29
Projekt aufsetzen
Planen
 Projektverwaltung
 KickOff!
 Status überwachen
 Projektplan warten
 Projektdokumentation konsolidieren
 Scope im Auge behalten ( moving targets)
 CRs verwalten
 Warnsignale wahrnehmen und darauf reagieren
30
30
Projekt aufsetzen
 Schlüsselrollen
 Projektleiter Business & IT
 Business Sponsor
 Schlüsselergebnisse
 Projekt Scope & Fahrplan
 Business Case (Rechtfertigung)
 Qualität sichern
31
31
Projekt
Evolution eines DWHs
Ermittlung
des
AnalyseBedarfs
und der
Aktuellen
Datenversorgung
Technische
Architektur
Produktauswahl/
Entwicklung
Frontend/Backend
Modellierung
Definition Rahmenwerk
Datenextraktion
Transformation
Laden
Betrieb
Neue
Priorisierung
Begleitende organisatorische
Umsetzungsmaßnahmen
Projekt-Management
32
32
Anforderungen aufnehmen
Arten
 Interviews
 Workshops
 Unbedingt zu vermeiden: Attributlisten
33
33
Anforderungen aufnehmen
Interview vorbereiten
 Interview Team
 Verständnis für das Thema
 Partner auswählen
 Fragebogen
 Terminplan
 Partner vorbereiten
 Interview:Grundsätzliches
34
34
Anforderungen aufnehmen
Interview
 Durchführen
 abholen
 bedanken
 Aufbereiten
 Durchführender & Schreiber
 Review
 alle wichtigen Punkte erfahren?
35
35
Anforderungen aufnehmen
Anforderungen
 Veröffentlichen
 Priorisieren
 Anpassungen durchführen
36
36
Anforderungen aufnehmen
Schwierige Interviewpartner
 Typen
 ausgenutzt, komatös, übereifrig, allwissend, nicht
vorhanden
 Strategien
 gute Vorbereitung zum Thema/Inhalt, abholen
 in der vereinbarten Zeit das Beste daraus
machen, ggf. abbrechen
 gute Vorbereitung zum Thema/Struktur, lenken
 Zuhören, aber nicht blind alles glauben
 neues Projekt suchen
37
37
Projekt
Evolution eines DWHs
Ermittlung
des
AnalyseBedarfs
und der
Aktuellen
Datenversorgung
Technische
Architektur
Produktauswahl/
Entwicklung
Frontend/Backend
Modellierung
Definition Rahmenwerk
Datenextraktion
Transformation
Laden
Betrieb
Neue
Priorisierung
Begleitende organisatorische
Umsetzungsmaßnahmen
Projekt-Management
38
38
Technische Architektur
 Motivation
 „Da steht doch ein Datenbankserver …“
 Überblick
 Die Anforderungen sind die Basis
 Von der (Daten-)Quelle zum Analysten
 Features
 Metadatengesteuert
 Service Layers
 Evolution DW/BI Architektur
39
39
Technische Architektur
Back Room
Front Room
Quellsysteme
ETL System
Presentation
Server
RDBMS,
Textdateien, …
Extract
Clean
Conform
Deliver
Anhand konformer
Dimensionen
miteinander
verbundene
Datamarts
ETL Mgmt Services
BI Anwendungen
Standard-Reporting
AdHoc Analysen: SQL
Data Mining
BI Mgmt Services
Metadaten: technisch, fachlich, prozess
Infrastruktur und Zugriffsschutz
40
40
Technische Architektur
Back Room ("Die Küche")
 Generelle ETL Anforderungen
 Produktiv einsetzbar
 Usability
 Metadatengesteuert
 Selber machen oder kaufen?
41
41
Technische Architektur
Back Room ("Die Küche")
ETL Ablauf
 Quellsysteme
 ODS / Reporting ODS
 XML
 Log Files, ...
 Proprietäre Formate
 Extrahieren
 Bereinigen und Anpassen
 Beliefern
42
42
Technische Architektur
Back Room ("Die Küche")
ETL Ablauf bzw. Kimball‘s 34 Subsysteme
 Extrahieren
 Data profiling (1)
 Change Data Capture System (2)
 Extract System (3)
 Bereinigen und Anpassen (Achtung!)
 Data cleansing (4)
 Fehlerbehandlung (5)
 Audit Dimension (6)
 Duplikate erkennen (7)
 Konformität erstellen (8)
43
43
Technische Architektur
Back Room ("Die Küche")
ETL Ablauf (Forsetzung)
 Beliefern
 SCD Manager (9)
 ID Erzeugung (10)
 …
 OLAP Cube Builder (20)
 Datenverteiler (21)
 ETL Management Services
 Job Scheduler (22)
 …
 Metadaten Repository Manager (34)
44
44
Technische Architektur
Back Room ("Die Küche")
 Zusätzliche BR Services
 Datendienste (Verkäufer  Hersteller)
 Funktionale Dienste (ETL, Reporting)
 Lieferdienste (ERP anzapfen)
 ETL Data Stores
 Extrakte
 Lookup-Tabellen
 Stage
 ETL Metadata
 Technisch (Datenquelle, Job-Logik)
 Prozess (Job Startzeitpunkt, Dauer)
 Fachlich (Dateninhalte, -verteilung, Data Dictionary)
45
45
Technische Architektur
Presentation Server
 Anforderungen
 Jeder möchte alles sehen
 Vom Großen zum Kleinen
 Single Source of Truth
 Skalierung
 Vertikale Partitionierung auf verschiedene
Plattformen
 Horizontale Partitionierung auf verschiedene
Tabellen
 Komponente im DWH, die die Abfragezugriffe
verwaltet
46
46
Technische Architektur
Front Room ("Der Gastraum")
 Zugriffsarten
 Direkt per SQL
 Standardberichte
 Data Mining
 Operatives BI ( Inventarverwaltung)
47
47
Technische Architektur
Front Room ("Der Gastraum")
 BI Management Services
 Metadaten
 Zugriffsschutz
 Aktivitätsmonitoring
 Query-Verwaltung
 Enterprise Reporting
 Web-Zugriff
48
48
Technische Architektur
Front Room ("Der Gastraum")
 BI Data Stores
 Berichte
 Application Server Cache
 Lokale Benutzer-Datenbanken
 Schnittstelle für Ergebnisse aus analytischen
Anwendungen (z.B. Data Mining)
 Achtung: Zugriffsschutzthematik
49
49
Technische Architektur
Infrastruktur
Randbedingungen
 Datenvolumen
 Volatilität / Dynamik
 Anzahl der Nutzer
 Anzahl der Geschäftsprozesse (Datenquellen)
 Art der Nutzung
 Service Level Agreements
 Technische Machbarkeit
 Verfügbarkeit der Software
 Finanzieller Rahmen
50
50
Technische Architektur
Infrastruktur
Parallelverarbeitung
 Symmetric Multiprocessing (SMP)
 shared memory
 Massively Parallel Processing (MPP)
 shared nothing
 Commodity Hardware
 Hadoop
 Non-Uniform Memory Architecture (NUMA)
 hybrid
51
51
Technische Architektur
Metadaten zu Auswertung
Nutzen eines Metadaten-Datamarts
 Impact Analysis
 Revision und Dokumentation
 Metadatenqualität – und Management
52
52
Architekturplan & Produktauswahl
Architekturplan erstellen
In 8 Schritten zum Architekturplan:
1. Aufstellen einer Architektur Task Force
2. Architektur-bezogene Anforderungen sammeln
3. Vorläufiges Architektur-Implikations-Dokument
4. Architekturmodell erstellen
5. Architekturimplementierungsphasen festlegen
6. Subsysteme entwerfen und spezifizieren
7. Anwendungs-Architektur-Plan-Dokument erstellen
8. Review
53
53
Architekturplan & Produktauswahl
Produkte auswählen
In 8 Schritten zur Produktauswahl:
1. Wie funktioniert der Einkaufsprozeß
2. Erstellen einer Produkt-Evaluierungs-Matrix
3. Markterhebung durchführen
4. Auswahlmöglichkeiten reduzieren
5. Kandidaten evaluieren
6. Ein Produkt empfehlen
7. Trial
8. Kaufverhandlung
54
54