CDC und Data Vault für den Aufbau eines DWH in der Automobilindustrie

Andreas BuckenhoferCDC und Data Vault für den Aufbau eines DWH in der Automobilindustrie

TDWI 2016, München

Daimler TSS GmbH

Zur Person

CDC und Data Vault für den Aufbau eines DWH in der Automobilindustrie / Analytics / 21.06.2016 / Seite 2

https://de.linkedin.com/in/buckenhofer

https://twitter.com/ABuckenhofer

https://www.xing.com/profile/Andreas_Buckenhofer2

Andreas Buckenhofer

Senior DB [email protected]

Seit 2009 bei Daimler TSS im Fachgebiet Big Data Business Unit Analytics

Daimler TSS GmbH

Interner IT-Partner für Daimler

Wir sind Spezialist und strategischer Business-Partner für

innovative IT-Gesamtlösungen im Daimler-Konzern.

Als 100%ige Daimler-Tochter leben wir die Kultur der Exzellenz

mit dem Anspruch der Innovations- und Technologieführerschaft.

Mit herausragender Technologie- und Methodenkompetenz

verstehen wir uns als Anbieter von wettbewerbs-

differenzierenden Dienstleistungen und sind

Impulsgeber in anspruchsvollen IT-Fragestellungen,

speziell in den Kernthemen Car IT und Mobility,

Information Security, Analytics und

Shared Services.


Daimler TSS GmbH

Standorte


Daimler TSS Deutschland

6 Standorte774 Mitarbeiter

Ulm (Hauptsitz)

Raum Stuttgart

Böblingen, Echterdingen,Leinfelden, Möhringen

Berlin

Daimler TSS India

Hub Bangalore19 Mitarbeiter

Daimler TSS China

Hub Beijing6 Mitarbeiter

Daimler TSS Malaysia

Hub Kuala Lumpur42 Mitarbeiter

Daimler TSS GmbH

DWH für die Bauzustandsdokumentation


Daimler TSS GmbH

Lösungsarchitektur


ETL Engine

Frontend

StandardReports

AdHocReportsLogs

TSM

IIDRReplEngine

Source

DatastoreSource

Spiegel DB

OLTPDB

IIDR ReplEngineSpiegel

DatastoreSpiegel

IIDR ReplEngineDWH

DatastoreDWH

DWH DB

Staging Layer

Core Layer / Data Vault

Mart Layer

Daimler TSS GmbH

Agenda – 1.) CDC und Spiegel


ETL Engine

Frontend

StandardReports

AdHocReportsLogs

TSM

IIDRReplEngine

Source

DatastoreSource

Spiegel DB

OLTPDB


DatastoreSpiegel

IIDR ReplEngineDWH

DatastoreDWH

DWH DB

Staging Layer


Mart Layer

Daimler TSS GmbH

Agenda – 2.) CDC und DWH Staging Layer


ETL Engine

Frontend

StandardReports

AdHocReportsLogs

TSM

IIDRReplEngine

Source

DatastoreSource

Spiegel DB

OLTPDB


DatastoreSpiegel

IIDR ReplEngineDWH

DatastoreDWH

DWH DB

Staging Layer


Mart Layer

Daimler TSS GmbH

Agenda – 3.) DWH Core Layer / Data Vault


ETL Engine

Frontend

StandardReports

AdHocReportsLogs

TSM

IIDRReplEngine

Source

DatastoreSource

Spiegel DB

OLTPDB


DatastoreSpiegel

IIDR ReplEngineDWH

DatastoreDWH

DWH DB

Staging Layer


Mart Layer

Daimler TSS GmbH

Agenda – 4.) DWH Mart Layer und Reporting


ETL Engine

Frontend

StandardReports

AdHocReportsLogs

TSM

IIDRReplEngine

Source

DatastoreSource

Spiegel DB

OLTPDB


DatastoreSpiegel

IIDR ReplEngineDWH

DatastoreDWH

DWH DB

Staging Layer


Mart Layer

Daimler TSS GmbH

Technische Herausforderungen für Spiegel und DWH


Quellsystem 6TBkomprimiert

Initial Loadder Datenmenge

Quellsystem hoch verfügbar

(keine Downtime)

Verarbeitung vonLastspitzen

Mehrere Tabellen mit Milliarden

von Datensätzen + 1TB große

Tabelle

Transaktions-muster

(Hibernate!)

Viele Schema-änderungen

Flexible Reaktion auf Änderungen

Komma-separierte Codelisten

End-2-End Monitoring

Daimler TSS GmbH

Verwendete Produkte

Komponente Tool

Betriebssystem Quelle: AIX 7.1; Ziel: Linux SLES 11SP4

Datenbank IBM DB2 LUW 10.5 AESE

Replikation IBM InfoSphere Data Replication (IIDR) 10.2.1

ETL Informatica Powercenter 9.6.1

Frontend IBM Cognos 10.2.1

Datenmodellierung SAP/Sybase Powerdesigner 16.5

DB Monitoring ITGAIN Speedgain 4.8


Daimler TSS GmbH

Agenda – CDC und Spiegel


ETL Engine

Frontend

StandardReports

AdHocReportsLogs

TSM

IIDRReplEngine

Source

DatastoreSource

Spiegel DB

OLTPDB


DatastoreSpiegel

IIDR ReplEngineDWH

DatastoreDWH

DWH DB

Staging Layer


Mart Layer

Daimler TSS GmbH

Warum Datenspiegel?


Entlastung Quellsystem bei AdHoc-Abfragen

RightTime-fähige Daten-

versorgung

Daten-bereitstellung für Fremdsysteme

Daimler TSS GmbH

Erkennung von Datenänderungen

CDC = Change Data Capture

•Verschiedene Verfahren zur Erkennung von Änderungen in der DB

Verfahren sind z.B.

•Full Load und Delta-Erkennung im DWH•Quellsystem-Trigger•Quellsystem-Tabellen mit Zeitstempel und/oder Statusfeldern (Achtung bei

Deletes)•DB-Log Scanner (logbasiertes CDC)•Standby-DB / DB2 HADR („High Availability Disaster Recovery“)


Daimler TSS GmbH

Logbasiertes CDC

Logbasiertes CDC ist „minimal-invasiv“

•Keine Änderungen der Applikation im Quellsystem•Geringe Belastung des Quellsystems•RightTime-fähig•Zieltabellen können abweichen von Quelltabellen (Indexe, Partitionierung)


Achtung I: keine no-logging/nonrecoverable Operationen in der QuelleAchtung II: CLOBS, BLOBS, User Defined Data Types werden von vielen Tools nur unzureichend unterstützt

Daimler TSS GmbH

Warum eigenständiges Tool wie IIDR und nicht HADR?

HADR („ High Availability Disaster Recovery“) hat viele Vorteile

+ kein weiteres Tool nötig, eingebaut in DB2

+ minimale DB Anpassungen / einfache Konfiguration

+ überträgt Daten und Schemaänderungen (Tabellenänderungen inkl. Indexe, Trigger, etc

sowie weitere Objekte)

+ keine separate Lizenzierung

ABER

Spiegel-DB kann nur im Modus „uncommitted read“ betrieben werden. Dirty Reads

möglich!


Daimler TSS GmbH

Architektur IBM InfoSphere Data Replication (IIDR)


DB

Management Console (GUI)

Access Server

DB-LogsDB2-ReplEngine DB2-ReplEngine

DataStoreDB-

Dateien DataStoreRefresh

Mirror

DBSubscriptions(Replication

Threads)

TCP/IP durch Firewall

Command Line (CHCCLP)

AccessAgent

AccessAgent

Metadaten

Metadaten

Daimler TSS GmbH

Subscriptions

Definieren Mappings zwischen Quelltabelle und Zieltabelle

Spaltenfilter

Alle Spalten übertragen?

Datenfilter

Alle Daten übertragen?

Transformation

Daten verändern?


Daimler TSS GmbH

Subscriptions und deren Tabellen


Daimler TSS GmbH

Mapping Methoden


StandardApply

AdaptiveApply

Live AuditApply

SummarizationApply

ConsolidationApply

Daimler TSS GmbH

Standard Apply Fahrzeug Mapping


Daimler TSS GmbH

Audit Apply Fahrzeug Mapping


Daimler TSS GmbH

Standard Apply und Audit Apply: Ausgangssituation

FIN Werknr

WDD1690071J236589 25


FIN Werknr

WDD1690071J236589 25

FIN Werknr Aud_type Aud_time

WDD1690071J236589 25 Insert 16.05.2016 17:00:10

Standard Apply

Audit Apply

Daimler TSS GmbH

Standard Apply und Audit Apply: insert und update


FIN Werknr

WDD1690071J236589 26

WDD1690071J227336 333

FIN Werknr Aud_type Aud_time

WDD1690071J236589 25 Insert 16.05.2016 17:00:10

WDD1690071J236589 26 Update After 16.05.2016 17:00:15

WDD1690071J227336 333 Insert 16.05.2016 17:00:18

FIN Werknr

WDD1690071J236589 26

WDD1690071J227336 333

Standard Apply

Audit Apply

Aud_type Spalte in IIDR:PT = Put (Insert)CL = Clear (Truncate)DL = DeleteUB = Update before imageUP = Update after imageRR, RS = Für Refresh

Daimler TSS GmbH

Ablauf Initial Refresh Spiegel

Quelltabellen in Ziel-DB anlegen, Subscriptions anlegen und Commit-Intervall hochsetzen (hier: 20 Mio.)

Generated always Spalten löschen

Ausgewählte Indexe löschen

Alle FKs ausschalten; PKs beibehalten

Start Refresh mit mehren parallelen Subscriptions

Start Mirroring sobald eine Subscriptionfertig ist

Überführung alle Subscriptions in eine Subscription

Gelöschte Indexe anlegen

FKs wieder einschalten

Daimler TSS GmbH

Monitoring Initial Load: CPU bei maximiertem Durchsatz


Daimler TSS GmbH

Monitoring Initial Load: I/O Requests weisen gute Antwortzeiten auf


Daimler TSS GmbH

End2End-Monitoring

Wie aktuell ist der Spiegel?


Daimler TSS GmbH

IIDR Management Console GUI: IIDR Performance Monitoring


Daimler TSS GmbH

IIDR Management Console Performanz Monitoring

GUI mit vielen Metriken, aber

Keine Verfügbarkeit historischer Performanzdaten

GUI muss zur Aufzeichnung geöffnet sein

Daten nur für begrenzten Zeitraum verfügbar

Latenz (Zeitdifferenz Quelle - Ziel) nur für beendete Transaktionen

Hohe Latenz = Ziel ist nicht

aktuell

Benötigt wird die Latenz für die

aktuell laufende Transaktion


Daimler TSS GmbH

Eigene Skripte zum Erfassen und Langzeit-Protokollieren


Daimler TSS GmbH

Eigene Skripte zum Erfassen und Langzeit-Protokollieren

Nutzung IIDR command Line Interface CHCCLP

Befehle zum Auslesen der Performanzdaten in eine Datei

Parsing der Datei und Speichern der Werte in Datenbank-Tabellen

Skript per crontab: Aufruf z.B. alle 5 min

Skript löst noch nicht das Problem, dass IIDR die Latenz für eine laufende Transaktion nicht übermittelt


Daimler TSS GmbH

Lösung Latenzbestimmung

Heartbeat-Tabelle in der Quelle mit einer Timestamp-Spalte

Timestamp-Spalte wird laufend aktualisiert, z.B. jede Minute

Aktualisierung wird in der Subscription übertagen

Latenz = Differenz aus aktueller Zeit und letzte Aktualisierung der gespiegelten Heartbeat-Tabelle (current_timestamp – Zieltabelle.timestamp)


Daimler TSS GmbH

Zusammenfassung CDC und Spiegel


Logbasiertes CDC zur minimal-invasiven Erkennung von Änderungen

Initial Load: Parallelisierung der Subscriptions und anschließende Zusammenführung

Standard Apply für DML (insert, update, delete)

Daimler TSS GmbH

Agenda – CDC und DWH Staging Layer


ETL Engine

Frontend

StandardReports

AdHocReportsLogs

TSM

IIDRReplEngine

Source

DatastoreSource

Spiegel DB

OLTPDB


DatastoreSpiegel

IIDR ReplEngineDWH

DatastoreDWH

DWH DB

Staging Layer


Mart Layer

Daimler TSS GmbH

Warum Staging Layer?


Entkopplung QuellDB – ZielDB

bzw weiterer Quellsysteme (Schnittstelle)

Temporäre Pufferung der

Daten-Änderungen aus

der Quell-DB

Berechnung von Hashwerten für Primärschlüssel und Vergleiche

Daimler TSS GmbH

Standard vs Audit Apply: Insert und Update/Delete


ETL Engine

Frontend

StandardReports

AdHocReportsLogs

TSM

IIDRReplEngine

Source

DatastoreSource

Spiegel DB

OLTPDB


DatastoreSpiegel

IIDR ReplEngineDWH

DatastoreDWH

DWH DB

Staging Layer


Mart Layer

INSERT

INSERT

INSERT

INSERT

UPDATE

UPDATE

INSERT

INSERT

Daimler TSS GmbH

Benötigte Daten im DWH verglichen mit Spiegel


Untermenge der Tabellen

Geringere Datenmenge

Initial Loadkein Problem

Daimler TSS GmbH

Row by Row = Slow by Slow (Tom Kyte)


Daimler TSS GmbH

Row by Row = Slow by Slow (Tom Kyte)


Row by Row

=

Slow by Slow

(Tom Kyte)

Daimler TSS GmbH

Lösung Initial Load DWH Staging Layer

• Audit Apply nutzt keinen DB2 Load für Initialbefüllung �

• IIDR Optimierungsmöglichkeiten für Audit Apply nicht ausreichend

• Workaround

• Standard Apply für Initial Load analog zum Spiegel, danach Audit Apply

• Vor dem Umschalten auf Audit Apply, Zurücksetzen des Bookmarks

Bookmark: Setzen des Lesepointers im Transaktionslog der Quell-DB


Daimler TSS GmbH

Transaktionsmuster Hibernate / Quellapplikation

CDC macht Transaktionsmuster sichtbar wie z.B.

• Dummy-Insert + danach Update

• Dummy-Insert + danach Update + danach Update


ID FIN Werknr Aud_type Aud_time

1111 Insert 16.05.2016 17:00:10

1111 WDD1690071J236589 26 Update 16.05.2016 17:00:10

ID FIN Werknr

1111 WDD1690071J236589 26

Audit Apply

Daimler TSS GmbH

Transaktionsmuster Hibernate / Quellapplikation

CDC und Data Vault für den Aufbau eines DWH in der Automobilindustrie / Analytics / 21.06.2016 /

• Dummy-inserts/updates sind fachlich nicht relevante Daten

• IIDR: Erkennung des gültigen Datensatzes (Timestamp nur sekundengenau)

• Einfügen von DB2 generated always-Spalten zur Erkennung der Reihenfolge und des

letzten Datensatzes

Seite 44

Daimler TSS GmbH

Tabellen im Staging Layer


• Keine PKs, FKs• Keine Indexe• Truncate der Daten nach

1 Woche

Daimler TSS GmbH

Indexe, Constraints und Partitionierung

DWH Layer Indexe? Constraints? Partitionierung?

Staging Keine Keine Ja, tageweise (truncate nach 1 Woche)

Core/Data Vault

Mart


Daimler TSS GmbH

Zusammenfassung CDC und Staging Layer


Logbasiertes CDC zur minimal-invasiven Erkennung von Änderungen

Initial Load: Standard Apply wegen Nutzung DB2 Load

Mirroring: Audit Apply für DML (insert, update, delete)

Daimler TSS GmbH

Agenda – DWH Core Layer / Data Vault


ETL Engine

Frontend

StandardReports

AdHocReportsLogs

TSM

IIDRReplEngine

Source

DatastoreSource

Spiegel DB

OLTPDB


DatastoreSpiegel

IIDR ReplEngineDWH

DatastoreDWH

DWH DB

Staging Layer


Mart Layer

Daimler TSS GmbH

Warum Core / Data Vault Layer?


HistorisierungIntegration mehrerer

Datenquellen

Laden aller Daten, keine fachlichen

Updates oder Deletes

Daimler TSS GmbH

Modellierungsalternativen im Core Layer

3NF

Star Schema

Head/Version

Data Vault

u.a.


Daimler TSS GmbH

Data Vault (Daniel Linstedt)

Data Vault ist optimiert für Anforderungen im Core Warehouse Layer mit folgenden

Eigenschaften:

• Skalierbarkeit

• Datenintegration, Automatisierung

• Datenhistorisierung

• Auditierbarkeit

• Flexibilität

• Agilität


Bill Inmon (DW 2.0: The Architecture for the Next Generation of DWH, 2008): “Data Vault is the optimal approach for modeling the EDW in the DW2.0 framework.”

Daimler TSS GmbH

Data Vault


Business Key

Beziehungen

KontextundHistorie

Data Vault:HUB

Data Vault:LINK

Data Vault:SAT

FINModellFarbeAusstattungBrancheProduktserieProduktionsbeginnLieferdatumBestelldatumKundeSteuergeräte

Fahrzeugdaten

Daimler TSS GmbH

HUB


Identifikation

durch

eindeutige

natürliche

Schlüssel

(Business Keys)

Daimler TSS GmbH

Struktur HUB-Tabellen


Daimler TSS GmbH

Typische Merkmale HUB-Tabellen

Business Keys sollten echte Geschäfts-IDs sein (z.B. Fahrzeug ID, Seriennummer des Steuergeräts) = natürliche Schlüssel

Business Keys sollten sich nie ändern

Business Keys, die über mehrere Datenquellen hinweg nicht eindeutig sind, müssen das Quellsystem für die Eindeutigkeit des Business Keys verwenden


Daimler TSS GmbH

LINK


Verbindungen

zwischen

Business Keys

(HUBs)

Daimler TSS GmbH

Struktur LINK-Tabellen


Daimler TSS GmbH

Typische Merkmale LINK-Tabellen

Ein LINK modelliert eine Beziehung. Die Beziehung ist immer n:m

Der zusammengesetzte Fremdschlüssel muss eindeutig sein

Eine Fremdschlüsselbeziehung ist führend („driving“)

Satelliten sind optional

Hierarchische Beziehungen durch einen LINK zwischen genau zwei HUBs. Arten von Beziehungen: SAL (same-as LINK) und HAL (parent-child LINK)


Daimler TSS GmbH

SAT


Beschreibende,

detaillierte,

aktuelle

und

historisierte

Daten

Daimler TSS GmbH

Struktur SAT-Tabellen


Daimler TSS GmbH

Typische Merkmale SAT-Tabellen

Enthält alle nicht-Schlüssel Daten

Ist genau einer HUB-Tabelle oder LINK-Tabelle zugeordnet

HUB-Tabellen oder LINK-Tabellen können (sollen) mehrere SAT-Tabellen enthalten, die nach Quellsystem, Datenänderungsrate, Datentypen, usw. entworfen werden können


Daimler TSS GmbH

Design von SAT Tabellen

Verschiedene Kriterien, um SAT-Tabellen zu entwerfen, z.B.

• Quellsystem

• Änderungshäufigkeit

• Datentypen (z.B. Auslagerung von CLOBS)

• Zerlegung inperformanter Quellsystemtabellen mit vielen Spalten


Daimler TSS GmbH

Design von SAT Tabellen

Änderungshäufigkeit der Daten zur Vermeidung redundanter Speicherung bei

Datenänderungen


Daten, die sich häufiger ändernDaten, die sich nicht ändern

Lieferdatum SW-Version Steuergerät

Diebstahlmeldung

Farbe KommentarAusstattungsmerkmale

Daimler TSS GmbH

Hash Keys statt Sequenzen für Primärschlüssel

Berechnung eines HKs aus den natürlichen Schlüsselattributen (Business Keys)

• Keine Lookups nötig: weitere Zunahme der Parallelisierbarkeit beim Load

• Vermeidung von Hot Spots (insb. sinnvoll bei sog. „Converged Systems“ wie Microsoft

APS, Exadata, Teradata, etc)

• Möglichkeit zur Verbindung relationaler DBs und Daten in Hadoop/NoSQL

• Jedoch: Gefahr einer Hash Key-Kollision

Anmerkung: UPPER für den Fall, dass die jeweilige Spalte case-insensitiv ist


HK = MD5_HASH (UPPER (TRIM (BK1)) || TRENNER || UPPER (TRIM (BK2)) …)

Daimler TSS GmbH

Hash Keys zur Beladung von Satelliten

Berechnung von Hash Keys für Attribute in Satelliten-Tabellen

• Vergleich Hash Keys neue Daten in Staging Layer und geladene Daten in Core Layer

�Effizienter

�Weniger Code

Anmerkung: UPPER für den Fall, dass die jeweilige Spalte case-insensitiv ist


HK = MD5_HASH (<HK Berechung BKs> || TRENNER || UPPER (TRIM (Spalte1)) || TRENNER || UPPER (TRIM (Spalte2)) || TRENNER ||

…)

Daimler TSS GmbH

Hash Keys und Kollision

Gefahr einer Kollision (jedoch insgesamt geringe Wahrscheinlichkeit)

• 2 Quellwerte erzeugen

den selben Hashwert

• Eingebaute DB2-Hashfunktion

reicht nicht aus

• Lösung:

https://github.com/tessus/db2-hash-routines

• UDF ist kompatibel mit Hash-Funktion

in Informatica


Daimler TSS GmbH

Wiederholbares Muster: Beladung HUB


Quelldaten

vorhanden

Business Keys distinkt laden

Business Key bereits im

HUB?

Datensatz in HUB eintragen

Konflikt bei PK HashKey-Kollision!

Nein

Datensatz verwerfen

Daten im HUB

vorhanden

Ja

Daimler TSS GmbH

Wiederholbares Muster: Beladung LINK


Quelldaten

vorhanden

Business Keys distinkt laden

Hash Key Beziehungen

bereits im LINK?

Datensatz in LINK eintragen

Konflikt bei PK HashKey-Kollision!

Nein

Datensatz verwerfen

Daten im Link

vorhanden

Ja

Daimler TSS GmbH

Wiederholbares Muster: Beladung SAT


Quelldaten

vorhanden

Quelldaten distinkt laden

MD5-HASH Diff gleich?

Datensatz in SAT eintragen

Nein

Datensatz verwerfen

Daten im SAT

vorhanden

Ja

Aktuellsten Datensatz aus

SAT-Tabelle laden

Daimler TSS GmbH

Parallelisierung der Beladung


HU

B g

elad

en

LIN

K u

nd H

UB

-

SAT

gela

den

LIN

K-S

ATge

lade

n

Da

ta V

au

lt

Lo

ad

Kla

ssis

ch

er

Lo

ad

?? ?

Integration neuer JobsZeitfenster für Beladungen 00:00-06:00

• Komplex

• Viele Abhängigkeiten

• Viele sequentielle Jobs

• Systematisch

• Wenige, definierte Abhängigkeiten

• Massiv parallel

Daimler TSS GmbH

Vorteile Data Vault

• Systematischer Ansatz

• Kleine, überschaubare Mappings

• Skalierbarkeit

• Flexibler Ansatz

• Automatisierung

• Volle Auditierbarkeit

• Keine fachlichen Update oder Delete-Operationen

• Support durch Tools

• Horizontale und vertikale Partitionierung

• Für relationale und Hadoop/NoSQL-Technologien


Daimler TSS GmbH

Nachteile Data Vault

• Mehr Tabellen

• Mehr Joins

• Alle Beziehungen sind modelliert als n:m (Dokumentation der Beziehungen nötig!)

• Bei der Beladung der HUBs, SATs, LINKs muss mehrfach auf dieselbe Quelltabelle

lesend zugegriffen werden

• Die Logik zur Befüllung der Data Marts kann komplex sein falls viele HUBs und deren

Satelliten beteiligt sind und die SQL-Logik Gültigkeitsdaten auflösen muss (Point in

Time oder Bridge-Tabellen verwenden!)


Daimler TSS GmbH

Tabellen im Core / Data Vault Layer


Daimler TSS GmbH

Anzahl Tabellen

Layer Anzahl Tabellen

Staging 57

Core / Data Vault 164

Mart 21+


Daimler TSS GmbH



Staging Keine Keine Ja, tageweise

Core/Data Vault Ja (1) Ja (2) Verschiedene, häufig nach Branche (PKW, LKW, Van, Bus)

Mart


• (1) so wenige wie möglich

• (2) für Leseperformanz; Constraints generell vorteilhaft für DB Optimierer

Keine Regel ohne Ausnahme! Obige Tabelle wurde in den meisten Fällen eingehalten.

Daimler TSS GmbH

Zusammenfassung DWH Core Layer / Data Vault


Data Vault zur Modellierung im Core Layer

HUB, LINK und SAT-Tabellen

Hohe Parallelität, robuste ETL-Verarbeitung

Daimler TSS GmbH

Agenda – DWH Mart Layer und Reporting


ETL Engine

Frontend

StandardReports

AdHocReportsLogs

TSM

IIDRReplEngine

Source

DatastoreSource

Spiegel DB

OLTPDB


DatastoreSpiegel

IIDR ReplEngineDWH

DatastoreDWH

DWH DB

Staging Layer


Mart Layer

Daimler TSS GmbH

Warum Mart Layer?


Standard Reporting:

Star Schema für performante

Analysen

AdHocReporting:

Zugriff auf Daten im DWH und im

Spiegel

Umsetzung Security im DWH: User

sehen nur die Daten, für die sie berechtigt sind

Daimler TSS GmbH

Performanz Aufbau Data Marts


Lange Laufzeiten trotz aktueller Objektstatistiken

Schlechte Ausführungspläne (u.a. Nested Loops)

Join von Tabellen mit Milliarden von Datensätzen

Komplexe SQL für Dimensionen und Fakten

Daimler TSS GmbH

Performanz-Tabellen: PIT und Bridge-Tabellen


DQ Fakt

Steuergerät Fakt

Ausstattung Fakt

Bridge-Tabellen

Fehlercode DimBranche Dim

Produkt DimDimensionen

Daimler TSS GmbH

PIT-Tabellen (Point in Time)

Eine PIT Tabelle beinhaltet Daten für einen performanten Zugriff auf Satelliten.

Eine PIT-Tabelle jeweils für HUBs bzw. LINKs

• HashKey vom HUB oder LINK (PK)

• Snapshot Date / Time (PK)

• Für jeden benötigten Satelliten:

SAT HashKey und (aktuelles = max) Load Date


Daimler TSS GmbH

Bridge-Tabellen

Eine Brückentabelle beinhaltet Daten für einen performanten Zugriff, um mehrere

HUBs und LINKs zu verknüpfen.

Eine Brückentabelle umfasst mehrere HUBs und LINKs.

• HashKey (PK)

• Snapshot Date / Time (PK)

• HUB und LINK HashKeys

• GGf. berechnete Werte / Aggegrationen für Fakten


Daimler TSS GmbH

Standard und AdHoc Reports

Standard-Reports basieren auf

• Faktentabellen und Dimensionen im DWH Mart Layer

• Security-Konzept

• Zukünftig Einsatz „spaltenorientierte In-Memory“ Option möglich

AdHoc-Reports basieren auf

• Spiegel

• DWH Mart Layer

• Für Superuser


Daimler TSS GmbH

Tabellen im Mart Layer: Fakten und Dimensionen


Daimler TSS GmbH



Staging Keine Keine Ja, tageweise

Core/Data Vault Ja (1) Ja (2) Verschiedene, häufig nach Branche (PKW, LKW, Van, Bus)

Mart Ja Ja (2) Ja, nach Branche (PKW, LKW, Van, Bus)


• (1) so wenige wie möglich

• (2) für Leseperformanz; Constraints generell vorteilhaft für DB Optimierer

Keine Regel ohne Ausnahme! Obige Tabelle wurde in den meisten Fällen eingehalten.

Daimler TSS GmbH

Zusammenfassung DWH Mart Layer und Reporting


Bridge und PIT-Tabellen waren notwendig, um Mart zu befüllen

Persistenter Data Mart, zukünftig ggf. Nutzung spaltenorientierter In-Memory Technologie

Standard Reporting (DWH) und Ad-hoc Reporting (DWH + Spiegel)

Daimler TSS GmbH

Zusammenfassung Lösungsarchitektur


ETL Engine

Frontend

StandardReports

AdHocReportsLogs

TSM

IIDRReplEngine

Source

DatastoreSource

Spiegel DB

OLTPDB


DatastoreSpiegel

IIDR ReplEngineDWH

DatastoreDWH

DWH DB

Staging Layer


Mart Layer

Daimler TSS GmbH

Datenintegration

“People have forgotten, or never truly understood, how complex data integration

actually is.”

Data Vault

• Robuste ETL Prozesse

• Kleine, wartbare Mappings

• Standardisierbarkeit / Wiederholbarkeit /Automatisierbarkeit

• Flexibilität

• Aber auch:

Viele Modellierungsoptionen = Viele Diskussionen

Quelle Zitat: http://db2portal.blogspot.de/2015/05/a-trip-report-from-2015-idug-db2-tech.html


Daimler TSS GmbH

Datenmodellierung

“Data modeling is the process of learning about the data, and regardless of

technology, this process must be performed for a successful application.”

Datenmodellierung, um

• Daten zu verstehen

• Performanz zu garantieren

• Entwicklung zu beschleunigen

• Qualität der Software zu verbessern

• Wartungskosten zu reduzieren

• Gemeinsames Verständnis zu fördern

• NoSQL Schema-on-read: Modellversionen auch nach Jahren noch verstehen

Quelle Zitat: Steve Hoberman: Data Modeling for Mongo DB, Technics Publications 2014


Daimler TSS GmbH

Methoden Know-how vs Produkt Know-how

Datenmodellierung macht jeder.

Methoden-Schulungen?

Fokus leider auf Schulung von Produkten / Tools.


Vielen Dank!

Daimler TSS GmbH

Wilhelm-Runge-Straße 11, 89081 Ulm / Telefon +49 731 505-06 / Fax +49 731 505-65 [email protected] / Internet: www.daimler-tss.com / Intranet-Portal-Code: @TSSSitz und Registergericht: Ulm / HRB-Nr.: 3844 / Geschäftsführung: Dr. Stefan Eberhardt (Vorsitzender), Steffen Bäuerle

Daimler TSS GmbH

Literatur


Daimler TSS GmbH

ETL tägliche Läufe: CPU vs logische Lesezugriffe


Daimler TSS GmbH

Lösung Schemaänderungen Quellsystem

Nur für wenige Änderungen geringer Aufwand, ansonsten

• Stoppen der Subscriptions

• Durchführung der Schemaänderungen im Ziel

• Herauslösung der Tabelle in eine eigene Subscription

• Initial Load

• Überführung der Subscription in die Gesamtsubscription


Daimler TSS GmbH

Warum IIDR und nicht HADR? 1(4)


Quell-DB Ziel-DB

Session 1

Session 2

Session 3

Ausgangszustand: Session 1 und Session 2 in der Quell-DB sowie Session 3 in der Ziel-DB zeigen die gleichen Daten an.

HADR

Daimler TSS GmbH



Quell-DB Ziel-DB

Session 1

Session 2

Session 3

In der Quell-DB wird eine Änderung (hier im Beispiel insert eines Datensatzes; für andere Operationen wie update oder delete gilt dasselbe) durchgeführt. Die Transaktion läuft noch, d.h. ein commit steht noch aus.

HADR

Daimler TSS GmbH



Quell-DB Ziel-DB

Session 1

Session 2

Session 3

Session 3 zeigt die geänderten Daten von Session 1 bereits an (uncommitted Read Modus bei HADR). Session 2 auf der Quell-DB sieht diese Änderungen korrekterweise noch nicht, d.h. auf der Ziel-DB sind ACID-Transaktionen aufgehoben.

HADR

Daimler TSS GmbH



Quell-DB Ziel-DB

HADR

Session 1

Session 2

Session 3

Session 1 führt kein commit durch sondern ein rollback z.B. aufgrund eines Fehlers. Die drei Sessions sind danach wieder synchron. Jedoch hatte Session 3 Daten angezeigt und potentiell weiterverarbeitet, die nicht existieren (Dirty Read).

Daimler TSS GmbH

IIDR Management Console: Fehlerauwertung


Daimler TSS GmbH

Nutzung von Performanz-Tabellen

Aufbau Data Vault-Tabellen

Aufbau Performanz-Tabellen• Schneller Zugriff auf aktuellste

SAT-Daten• Vorberechnete HUB und LINK-

Joins

Aufbau Mart-Tabellen• Änderungserkennung mit Hilfe

der Performanztabellen• Join Performanztabellen mit

Data Vault-Tabellen


Daimler TSS GmbH

Monitoring: Standardisierung Session Logging

Beladung des DWH mittels

• Informatica Powercenter

• Eigene Logs

• Workflow Monitor

• DB2 SQL PL (Stored Procedures)

• Per Default kein Logging

• SPs wurden gezielt für den Transport großer Tabellen verwendet

Vorgabe: Jedes Mapping und jede Stored Procedure trägt Start, Ende, verarbeitete

Zeilen, Fehler, u.ä. in eine Tabelle im DWH ein.


Daimler TSS GmbH

Session Logging in Informatica mit unconnected ProcedureTransformation


CDC und Data Vault für den Aufbau eines DWH in der Automobilindustrie

Data & Analytics

Transcript of CDC und Data Vault für den Aufbau eines DWH in der Automobilindustrie