Benutzer mit den meisten Antworten
Best practices für Delta Load DWH für SQL Server 2014

Frage
-
Hallo zusammen,
aktuell machen wir in unserem nächtlichen Ladeprozess für alle Tabellen einen Full Load. Wir möchten nun evaluieren, ob für uns ein Delta Load lohnend ist. Primär geht es uns natürlich darum, den Aufwand für die Maschine zu reduzieren und unseren Ladeprozess schneller/früher abschließen zu können.Wer hat schon einen Delta Load entwickelt und kann davon berichten? Kennt jemand GUTE Quellen/Bücher, die sich mit dieser Materie auseinandersetzen? Ebenso bin ich für Tipps und Tricks dankbar.
Danke an euch :)
Viele Grüße Holger M. Rößler
Antworten
-
Die Daten kommen aus Flat Files (primär CSV, die aus unserem ERP kommen)
Wenn immer 100% in Flat Files exportiert werden, dann hast Du keine Chance, ein Delta zu bilden, das müsste bereits beim Export erfolgen.
Kleiner Nachtrag: Die von mir beschrieben Methode hat einen Nachteil, man kann keine gelöschten Daten ermitteln; allerdings löschen wir nie physikalisch Daten, sondern setzen nur ein Gelöscht-Flag (Soft Delete), was wieder ein Update ist und RowVersion hoch gesetzt wird.
Olaf Helper
[ Blog] [ Xing] [ MVP]- Als Antwort markiert Holger M. Rößler Donnerstag, 23. Oktober 2014 13:38
-
Ich sehe hier zwar keinen Walter im Thread,
aber Ja, Prüfsummen werden aufgrund Ihrer Effizienz sehr häufig eingesetzt.
in SSIS verwende ich dort i.d.R. eine Custom-Komponente, SSIS Multiple Hash, sofern der Kunde keine Eigenentwicklung wünscht - dann ist es auch nicht so schwierig, das in einer Script-Transaformation mit einer Hash-Function nach Wahl umzusetzen.
I.d.R. setze ich dort auf SHA_256
Andreas Wolter (Blog | Twitter)
MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com- Als Antwort markiert Holger M. Rößler Donnerstag, 23. Oktober 2014 13:38
Alle Antworten
-
Hallo Holger,
von woher werden den die Daten geladen, aus einer SQL Server Datenbank? Ich verwende häufig Delta Loads, da wir viel mit Massendaten zu tun haben.
Die Umsetzung ist recht einfach:
- Alle Quelltabellen haben ein Spalte vom Typ RowVersion, dadurch ist sichergestellt, das jeder geänderte Datensatz erkannt werden kann. Man kann auch DateTime verwenden, nur muss dann z.B. per Trigger sichergestellt werden, dass der Wert bei jedem Update auch aktualisiert wird.
- Es gibt eine Tabelle, in der der RowVersion Wert des letzten Importes gespeichert wird.
- Am Start des SSIS Paketes zum Transfer wird a) der letzte und b) der aktuelle RowVersion Wert ermittelt; b) am Anfang, damit später auch Daten ermittelt werden können, die während des Transfer geändert wurden.
- Darüber wird dann aus allen Tabellen ermittelt, welche Datensätze seit dem letzten Lauf geändert wurden und nur die werden übertragen. Auf der RowVersion Spalte ist ein Index drauf, damit es zügig geht; RowVersion zu indizieren wird zwar nicht empfohlen und ist in einem OLTP suboptimal, aber für diesen Fall hilft es.Bei einem kleinem Projekt mit nur 2 Tabellen lasse ich solch einen Job alle 5 Minuten laufen, um die Daten zeitnah im Zielsystem zu haben; läuft reibungsfrei.
Olaf Helper
[ Blog] [ Xing] [ MVP] -
Hallo Olaf,
vielen Dank für deine Antwort :)Die Daten kommen aus Flat Files (primär CSV, die aus unserem ERP kommen) die wir mittels SSIS Pakete in unsere Staging-Tabellen laden. Lässt sich sowas auch Versionieren, oder muss hier eine Erkennung (z.b. mittels Hashcode) erfolgen? @Edit: Unser Datenvolumen liegt bei mehreren Gigabyte / pro Nacht.
Vielen Dank!
Viele Grüße Holger M. Rößler
- Bearbeitet Holger M. Rößler Donnerstag, 23. Oktober 2014 10:06
-
Um sich in die Materie Datawarehousing einzuarbeiten, ist das Buch "The Data Warehouse Lifecycle Toolkit" von der Kimball Group sicher der Klassiker und Einstieg schlechthin.
Grundsätzlich sind Delta-Loads der Standard für Enterprise Datawarehouse-Systeme, da man ansonsten keine echte Histoirisierung/Archivierung betreiben kann, und auch keinerlei Möglichkeiten hat, sogenannte "Slowly Changing Dimensions" umzusetzen - also Datenänderungen über Zeit. Insofern gibt es dazu Erfahrungen zu Genüge.
Voraussetzung dafür ist eine Erkennung der Änderungen anhand der Business Keys und dem Abgleich mit dem, was bereits im DW liegt.
Hilfstechniken dafür können sein:
- Change Data Capture
- Checksummen verschiedener Art
- die erwähnte Rowversion wenn man Eingriffe im OLTP-Schema vornehmen darf
- Event Notifications & Service-Broker
Andreas Wolter (Blog | Twitter)
MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com -
Die Daten kommen aus Flat Files (primär CSV, die aus unserem ERP kommen)
Wenn immer 100% in Flat Files exportiert werden, dann hast Du keine Chance, ein Delta zu bilden, das müsste bereits beim Export erfolgen.
Kleiner Nachtrag: Die von mir beschrieben Methode hat einen Nachteil, man kann keine gelöschten Daten ermitteln; allerdings löschen wir nie physikalisch Daten, sondern setzen nur ein Gelöscht-Flag (Soft Delete), was wieder ein Update ist und RowVersion hoch gesetzt wird.
Olaf Helper
[ Blog] [ Xing] [ MVP]- Als Antwort markiert Holger M. Rößler Donnerstag, 23. Oktober 2014 13:38
-
Ich sehe hier zwar keinen Walter im Thread,
aber Ja, Prüfsummen werden aufgrund Ihrer Effizienz sehr häufig eingesetzt.
in SSIS verwende ich dort i.d.R. eine Custom-Komponente, SSIS Multiple Hash, sofern der Kunde keine Eigenentwicklung wünscht - dann ist es auch nicht so schwierig, das in einer Script-Transaformation mit einer Hash-Function nach Wahl umzusetzen.
I.d.R. setze ich dort auf SHA_256
Andreas Wolter (Blog | Twitter)
MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com- Als Antwort markiert Holger M. Rößler Donnerstag, 23. Oktober 2014 13:38