1

Applied Data Warehousing

Belegnummer 002.22110 (NFE211)

Michael Cordes

Holger Oehring

Matthias Rein

0

2

bersicht1. Einleitung

2. Planung

3. Extraktion

4. Tools

5. Stage Load (Arbeitsbereich)

6. Transformationl Schematransformationl Datentransformation

7. Conform

8. Technische QA

9. Datenmodell Load

10. Aggregate

291

3

Einleitung

392

4

ETL?l Vorkenntnisse der Studierenden

42

5 5

Projekt: Evolution eines DWHs

Projekt-Management

Ermittlungdes

Analyse-Bedarfsund der

AktuellenDaten-

versorgung

Produktauswahl/Entwicklung

Frontend/Backend

TechnischeArchitektur

ModellierungDefinition Rahmenwerk

DatenextraktionTransformation

LadenBetrieb

NeuePriorisierung

Begleitende organisatorischeUmsetzungsmanahmen

3

6

Die ETL-Bibel

6

Practical Techniques forExtracting, Cleaning,Conforming, and DeliveringDataISBN:

6

7 7

Back Room / Front Room

7

8

ETL-Prozess 1

Aufwndiger Teil des Data Warehousingl Vielzahl der Datenquellen

l Heterogenitt (Daten / Inhalte)

l hohes Datenvolumen

l Komplexitt der Transformationl Schema- und Instanzintegrationl Datenbereinigung

l Keine durchgngige Methoden- und Systemuntersttzung

l Unterschiedliche Werkzeuge vorhanden

89

9 9

ETL-Prozess 2Extraktion:

l Selektion und Projektion eines Ausschnitts der Daten aus den Quellsystemen und Bereitstellung fr die Transformation

Transformation:

l Anpassen der Daten an die Schema- und Qualittsanforderungen

Laden:l Physisches Einbringen der Daten aus dem Arbeitsbereich (Staging Area) in das Data

Warehouse (einschlielich notwendiger Aggregationen)

24

10

ETL-Prozess 3oder auch

1025

11

Planung

1193

12

ETL-Planung

12

Anforderung &

Wirklichkeit

Architektur

Umsetzung

Test&

Release

ETL-Architekt

ETL-Entwickler

10

13

ETL-Architekturl Datenquellen

l Staging Tabellen

l Meta-Daten

l Transformationsregeln

l Feldzuordnung (Quelle Ziel)

l Zielschema Belieferungl Dimensionen

l Art der Historisierung (SCD)l Faktenl Aggregate

l

13

Ziel: ETL Master-Blue-Print11

14

ETL-Planung - Stagel Stage Tabellen Kennzahlen (staging tables volumetric)

l Tabellennamel Update Strategie (lschen & laden / nur einfgen)l Ladefrequenz (tglich / monatlich / bei Bedarf)l ETL-Jobsl Anzahl Datenstze (Initial)l Durchschnittliche Zeilenlngel Wachstumstreiber (z.B. neue Kunden)l Erwartete Datenstze (monatlich)l Erwartete Daten (in Byte / Monat)l Initiale Tabellengre (in Bytes)l Tabellen Gre nach 6 Monaten (in MB / TB)

1412

15

ETL-Planung log. Transformationl logische Daten-Landkarte (logical data map)

l Quelle (aus Stage-Bereich)l Tabellennamel Spaltennamel Datentypl Tabellentyp (Dimension / Fakt)l SCD-Typ (1 / 2 )

l Ziel (im Zieldatenmodell)l Database Namel Tabellen Namel Spaltennamenl Datentyp

l Beschreibung der Transformationl Umgangssprachlichl pseudo Code

1513

16

ETL-Planung Systembersichtl bersicht ber die Quellsysteme

(source system tracking report)l Themengebietl Name der Schnittstellel Projektnamel Priorittl Abteilung oder Nutzung (z. B. Personal Abteilung)l Fachlicher Verantwortlicherl Technischer Verantwortlicherl Datenbank System (Oracle / DB2 / )l Plattform (Windows / Linux / z/OS / AIX auf RS/6000 / )l Anzahl tglicher Nutzerl Datenbankgre (in GB/TB)l Anzahl tglicher Transaktionenl Allgemeine Kommentare

1614

17

Extraktion

1795

18

Extraktion

Aufgabe:l Regelmige Extraktion von (nderungs-)Daten aus den Datenquellenl Datenversorgung des DWHs

Wesentliche Aspektel Zeitpunkt(e) der Extraktionl Art der extrahierten Daten

1826

19

Extraktionszeitpunkte

l synchrone Benachrichtigungl Quelle bewirkt jede nderung

l asynchrone Benachrichtigungl periodisch

l Quellen erzeugen regelmig Extraktel DWH fragt regelmig Datenbestand ab

l ereignisgesteuertl DWH erfragt nderungen

z.B. vor dem Jahresabschlussl Quelle informiert, wenn bestimmte Anzahl an nderungen vorliegt

l anfragegesteuertl DWH erfragt nderungen vor jedem tatschlichen Zugriff

1927

20

Datenextraktionen

l Snapshots: Quelle liefert immer kompletten Bestand bzw. alle Transaktionen seit der letzten Belieferungl z.B. alle Kunden, alle Telefonverbindungenl Historische Daten sichern, komplette Daten bernehmen

l Logs: Quelle liefert jede nderungl Transaktionslogs, Anwendungsgesteuertes Loggingl nderungen sind effizient einzuspielen

l Netto Logs: Quelle liefert netto nderungenl z.B. Preislisten- / Produktnderungenl Effizienzerhhung durch Einspielen von Inkrementen

2028

21

Datenversorgung

l Viele Bestandsfhrenden-Systeme sind nicht online zugreifbar, so dass z.B. das direkte Einfgen von nderungen nicht immer mglich ist.

l Non-Standard-DBs ermglichen keine standardisierte Datenbernahme.

l Quellsysteme haben hufig unklare Semantik. Mitunter sind Felder mehrfach belegt

l Zugriff erfolgt auf andere DWH-Daten. Wobei die Daten bereits einmal transformiert wurden.

l Die synchrone Extraktion kann zu einer starken Belastung der operativen Systeme fhren, dass diese erheblich gestrt wird, ist also i.d.R. nicht mglich

l Fr die anfragegesteuerte Extraktion existieren keine technisch effizienten Verfahren

2129

22

Datenformatenl Je nach eingesetzter Technik knnen folgende Datenformate durch das Quellsystem zur

Verfgung gestellt werden:l DB-Unloads (DB2, ORACLE, ) l sequentielle Dateien (Textdateien) aus Schnittstellenprogramm

l Mit festem Satzaufbaul Mit Vor- und Endsatzl Mit unterschiedlichen Satzarten

l CSV-Dateienl XML-Dateienl XLS-Dateienl

l Vorsicht bei allen Dateien kann der Zeichensatz OS-Spezifisch ausfallen (EBCDIC vs. ASCII).

l Deutsche Sonderzeichen wie , , , , werden ggf. bereits beim Transport nicht richtig bertragen.

2230

23

Datenformate Beispielel DB2 Unload ber Entladekarte

l SQL Definition aus Cobol Copy Strecke

l Cobol Copy Streckel Unterschiedliche Satzartenl Definitionen

l Fest definierte Schnittstelle (feste Positionen)

2331

24 24

Extraktion in Kooperationl Quellsystem liefert normalerweise die bentigten Daten

l Umfang der Schnittstelle definierenl Art der Datenlieferung bestimmen

l Zeitpunkte definierenl Prfen: Existiert bereits eine Exportschnittstelle, die genutzt werden kann?

l Definierte Schnittstelle kapselt alle nderungen im Quellsystem

l Fehlerhafte Daten resultieren ggf. aus falschem Schnittstellenprogramml Bei 1:1 Kopien schlagen nderungen in der Quelle 1:1 ins DWH durch (Kopplung der

Physik)

32

25

ETL Tool

2594

26

ETL-Tool & Auswahll Marktbersicht

l kommerzielle Produkte (eine Auswahl)l Open Source Projekte (ein Beispiel)

l Auswahl eines Produktsl Vor- und Nachteile

l Zusammenfassung

Im Praktikum wird Pentaho Data Integration (Spoon / Kettle) genutzt.

2615

27 27

ETL Toolsl Beispiele:

l Informatica http://www.informatica.com/de/knowledge_center/Pages/white_papers_reports.aspxl SAS Data Integration http://www.sas.com/technologies/dw/etl/index.htmll Microsoft SSIS / DTS http://technet.microsoft.com/en-us/library/cc917721.aspxl ORACLE OWB http://www.oracle.com/technetwork/developer-tools/warehouse/overview/introduction/index.htmll

l Siehe Wikipedia: l http://de.wikipedia.org/wiki/Business_Intelligence

l Unter DI / ETL Tools gibt es Open Source Softwarel Pentaho

l Homepage - http://www.pentaho.com/l Community - http://community.pentaho.com

l Talend Open Studiol Homepage - http://www.talend.com/l Community - http://community.talend.com/

16

28

ETL Tool SAS Data Integration

2817

29

ETL Tool Microsoft SSIS

2918

30

ETL Tool ORACLE OWB

3019

31

Pentaho

3120

33 33

Make or Buy

l Projektanforderung wird zu 100% erfllt (custom code)

l komplette Nachvollziehbarkeit ist gegeben (Source Code)

l keine Lizenzkostenl kann vollstndig in existierenden

SW-Stack integriert werden

pro contra

mak

ebu

y

l Kosten (Lizenz, Wartung, Schulung)l Abhngigkeit zu Herstellerl ggf. Migrationskosten bei einer neuen

Versionl es wird ein grerer Funktionsumfang

geliefert, als bentigt wirdl ggf. kein Audit mglich (Datenmodell,

Code, ) liegt nicht vorl fehlende Funktionalitt kann ggf. nicht

selbst hinzugefgt werdenl teure SW-Evaluierung notwendig, um

das richtige Werkzeug zu finden

l graphische Benutzeroberflchel viele fertige Komponentenl Framework / Vorgehensmodell

werden geliefertl Logging ist Teil der Lsungl Zeitersparnis bei der Entwicklung l schnelle Einarbeitungl Es werden keine

Entwicklerkapazitten gebundenl es werden i.d.R. weniger

allgemeine Fhigkeiten (Skills) bentigt

l Entwicklungszeit fr Framework und konkrete Anforderung

l Wissen ist ggf. nur bei einer Key-Resource vorhanden

l Dokumentation ggf. nicht existent oder mangelhaft

die Listen haben keinen Anspruch auf Vollstndigkeit22