Effektives Delta Laden DOAG SID Data Warehouse. Ziele Welche CDC Methoden gibt es? Typische Fallen Verschiedene Lösungsansätze praktische Beispiele.

Präsentation zum Thema: "Effektives Delta Laden DOAG SID Data Warehouse. Ziele Welche CDC Methoden gibt es? Typische Fallen Verschiedene Lösungsansätze praktische Beispiele."—  Präsentation transkript:

1 Effektives Delta Laden DOAG SID Data Warehouse

2 Ziele Welche CDC Methoden gibt es? Typische Fallen Verschiedene Lösungsansätze praktische Beispiele

3 Möglichkeiten des CDCs CDC Full replacement Incremental CDC Source-based Target-based Timestamps Log Data EAI based

4 Timestamp Beispiel Letzter Ladelauf war: Um 2:00 Uhr Letzter Datensatz geladen war von 1:10 Zwei Sätze wurden nach 2:00 Uhr hinzugefügt KeyNameDatumUhrzeit 1Meier1.1.9901:10 2Müller1.1.9902:12 3Schmidt1.1.9902:39 Target Status table Source KeyNameDatumUhrzeit 1Meier1.1.9901:10 1.1.9901:10

5 Timestamp Beispiel… nächster Ladelauf ist um 3:00 Uhr Select * from source where datum > ‘1.1.99 01:10’ Update status table set datum = ‘1.1.99 02:39’ KeyNameDatumUhrzeit 1Meier1.1.9901:10 2Müller1.1.9902:12 3Schmidt1.1.9902:39 Target Status table Source 1.1.9901:10 KeyNameDatumUhrzeit 1Meier1.1.9901:10 2Müller1.1.9902:12 3Schmidt1.1.9902:39

6 Lücken beim Laden Es können Daten verloren gehen wenn: man von einer statischen Timestamp abhängt und Daten in der Quelle geändert werden - gleichzeitig zum Extrahieren Problem ist das man zum Extrahieren der Daten Zeit benötigt…

7 Wo soll das Extrahieren beginnen? 1:00 2:00 3:00 Lauf 2 Lauf 1 Welche Daten sind bereits geladen? Lauf 3 Ladelauf dauert von 01:00 to 01:15

8 Presampling 1:00 2:00 3:00 Lauf 2 Lauf 1 Der Ladelauf lädt nie Daten aus der Grauzone Lauf 3 Ladelauf dauert von 01:00 to 01:15

9 Quelltabelle sperren 1:00 2:00 3:00 Lauf 2 Lauf 1 Es gibt keine Änderungen in der Quelltabelle Lauf 3 Ladelauf dauert von 01:00 to 01:15

10 Pre-Delete 1:00 2:00 3:00 Lauf 2 Lauf 1 Lösche alle eventuell bereits vorhandenen Daten und lade alles neu Lauf 3 Ladelauf dauert von 01:00 to 01:15

11 Offene Transaktionen Transaktionen die noch nicht commited sind unsichtbar Timestamp ist vom Einfügezeitpunkt und nicht von commit Zeitpunkt!

12 Pre-Delete 1:00 2:00 3:00 Lauf 2 Lauf 1 Lösche alle eventuell bereits vorhandenen Daten und lade alles neu Lauf 3 Ladelauf dauert von 01:00 to 01:15

13 Pre Delete, Version 2

14 Change Logs Änderungen stehen nicht in der Quelltabelle, aber vielleicht in einer anderen Tabelle Gleiches Vorgehen, gleiche Probleme wie bei Timestamps KeyVornameNachname 1WalterMüller 2ChristianMeier 3NorbertSchmidt KeyGeändert am 12.4.99 10:34 12.4.99 11:50 25.7.99 16:32

15 Change Logs

16 EAI Daten Änderungen werden in einem Message Bus an alle Interessierten in Echtzeit verteilt, hoffentlich kann das ETL Tool diese empfangen

17 Problem No 1 Viele Tabellen zusammengenommen ergeben eine Data Warehouse Tabelle Jede einzelne der Quelltabellen kann sich ändern

18 Jede Quelle kann sich ändern!

19 Jede Quelle kann sich verändern...

20 Wirklich jede Quelle? Wie erkennt man Änderungen in jeder einzelnen Quelltabelle? Wie erkennt man neue Orders? Kann sich der Auftraggeber wirklich nachträglich ändern? Bewirkt eine Statusänderung das Setzen des Änderungsdatums im Orderheader?

21 Wirklich jede Quelle? Kann sich jedes Order ändern? oder nur solche die noch nicht den Status „Abgeschlossen“ haben? Wie wäre es dann alle offenen Orders jeden Tag zu laden?

22 Target Based CDC Es gibt keinen Indikator im Quellsystem? Dann lese alles aber lade nur Änderungen! Speziell wenn komplexe Transformation notwendig wären...

23 Full Refresh Die Tabelle einfach zu leeren und völlig neu aufzubauen ist ebenfalls sehr schnell Nur inserts – daher höchste Anzahl Sätze pro Sekunde, aber lädt eben alle Sätze, nicht nur das Delta und alte Sätze dürfen niemals aus der Quelle gelöscht worden sein, sonst hat man Buchungen zu Stammdaten die es nicht mehr gibt...

24 Und was wenn alles nicht hilft? Kreativ sein Datenmodell überdenken Und erst als allerletzten Ausweg das Quellsystem anpassen Ist die Quelle eine RDBMS kann ein Trigger hinzugefügt werden: Verhältnismäßig billig und vor allem sicher Bei anderen Systemen, wie etwa SAP schnell mal eine IDOC hinzuzufügen bedeutet großen Aufwand

25 Verhalten im Fehlerfall Was muss im Fehlerfall getan werden? Bei Full Refresh, Target Based CDC und Pre-Delete gar nichts – einfach den Datenfluss neu starten! Gutmütiges Verhalten gehört zu den Designforderungen.

26 Summary: Anforderung an Datenflüsse von/bis Datum parametrisierbar extrem hohe Ladeperformance Jede in dem Projekt (und in Zukunft) anzutreffende Quelle soll unterstützt sein (z.B. EAI)