Wenn Ihre Quellen keine Änderungshistorie haben und die Daten täglich nur als Fullload liefern können, muss Ihr Data Warehouse immer unnötig viele Datensätze verarbeiten. Wenn sich nur 5% einer Tabelle geändert haben, würde man doch gerne die anderen 95% ignorieren. Haben Sie SCD Logik implementiert, können diese 95% richtig viel Zeit kosten. Das habe ich in meinem letzten Projekt auch gedacht und ein dynamisches Framework zur automatisierten Deltaberechnung entwickelt. Direkt nach der Datenlieferung im Stage erzeugt dieses mit Hilfe der Oracle Hashfunktion das neue Delta. Anschließend wird nicht mehr der komplette Bestand verarbeitet, sondern nur die geänderten Daten. Wie es funktioniert? Und warum mit Hash?

Berechnung und Verarbeitung des Deltas

Die eigentliche Deltaberechnung musste einigen Anforderungen genügen. Sie sollte performant sein und auch für sehr große Tabellen zuverlässig funktionieren, ohne dass beim Vergleich der Daten der TEMP platzt. Der zusätzliche Speicherverbrauch zum Vorhalten der benötigten Delta- und Vortagesdaten sollte minimal bleiben. Nach eingehender Evaluierungsphase habe ich mich für folgendes Vorgehen entschieden:

  • Deltabildung über Hashwert der Zeile statt über alle Daten
  • Verwendung der Oracle Funktion STANDARD_HASH
    • Parameter 1: Verkettung aller Spalten der Tabelle
    • Parameter 2: Hashmethode SHA1

Die darauf aufbauende Architektur verwendet den neuen Hashwert und benutzt diesen für Verarbeitung der Daten. Zu einer Stagingtabelle kommen folgende Objekte hinzu:

  • Virtuelle Spalte DWH_ROW_HASH_VIRT
    • Enthält den Hashwert über alle Spalten der Tabelle
  • Vortagestabelle
    • Besteht aus Natkey-Spalten und persistiertem Hashwert (DWH_ROW_HASH)
    • Enthält alle Datensätze der Vortageslieferung
  • Deltatabelle
    • Besteht aus Natkey-Spalten und Änderungsflag (DWH_IUD_FLAG)
    • Enthält nur neue(I), geänderte(U) und gelöschte(D) Sätze im Vergleich zum Vortag
  • Deltaview
    • Besteht aus allen Spalten der Quelltabelle und DWH_IUD_FLAG
    • Enthält die aktuelle Lieferung und zusätzlich die gelöschten Sätze
    • DWH_IUD_FLAG ist NULL bei nicht geänderten Datensätzen

Auf dem folgenden Bild können Sie an einem Beispiel den Aufbau der Objekte und die Reihenfolge der Ladeschritte erkennen. Nachdem die Daten von der Quelle geliefert wurden (1) wird unter Einbeziehung der neuen Daten(Stagingtabelle) und den Daten vom Vortag(Vortagestabelle) die Differenz berechnet und die Deltatabelle mit neuem Delta befüllt(2). Die Deltaview kombiniert die gelieferten Daten(Stagingtabelle) mit den Informationen des Deltas(Deltatabelle) und enthält alle Datensätze mit den entsprechenden Änderungskennzeichen(2*). Diese View wird nun verwendet, um die Änderungen im Cleanse und danach auch im Core einzupflegen(3). Als letzter Schritt müssen nun die aktuellen Daten in die Vortagestabelle kopiert werden, damit sie am nächsten Tag verwendet werden können(4).

Deltaframework

Jetzt wissen Sie, was ich gemacht habe. Bleibt noch die Frage: wie. Wenn über hundert Tabellen auf Deltaverarbeitung umgestellt werden, kostet es zu viel Zeit alle notwendigen Objekte und Prozesse zu erstellen (oder zu erweitern) und zu testen. Viel besser wäre, allgemeine übergeordnete Routinen zu entwickeln, die durch Konfiguration und Parametrisierung für jeden Einzelfall angewendet werden können. Damit hat man einen einmaligen Entwicklungs- und Testaufwand, die eigentliche Logik muss danach nur noch generiert werden. Genau das übernimmt das oben erwähnte Deltaframework. Was genau ist das?
Dabei handelt es sich um ein Datenbankpackage, welches mit Hilfe vom dynamischen SQL programmiert worden ist. Die notwendigen Informationen, wie z.B. natürliche Schlüssel der Tabellen bezieht das Framework aus dem Oracle Data Dictionary und den fachlichen Metatabellen. Funktionen des Frameworks sind parametrisiert nach Tabellenname und Quelle (da diese in der Namenskonvention der Tabellen verwendet wird) und erhalten die tatsächlichen Objektnamen erst zur Laufzeit. Eine Funktion des Frameworks baut zur Laufzeit die jeweiligen Statements auf und führt diese mit EXECUTE IMMEDIATE aus. Damit ist das Framework allgemeingültig und für jede beliebige Quelltabelle wiederverwendbar. Hier sehen Sie einige der Funktionen, die vom Deltaframework zur Verfügung gestellt werden:

Fazit

Die vorgestellte Lösung brachte im Kundenprojekt je nach Tabelle bzw. Anzahl der täglichen Änderungen eine Laufzeitreduktion von bis zu 90%. Das kann sich sehen lassen! Für mich persönlich ist aber viel wichtiger, welche Vorgehensmethode dabei gewählt wurde. Auch bei der manuellen Entwicklung hätte man die gleichen Performancevorteile erreichen können. Der Ansatz der Industrialisierung, den ich hier bewusst gewählt habe, reduziert aber jetzt und auch zukünftig Aufwände und spart Kosten. Er bietet dem Kunden die Möglichkeit, durch Konfigurierung und Generierung anstelle von Implementierung flexibel auf Neuanforderungen zu reagieren. Durch die eingeführte Standardisierung erhöht sich zudem die Wartbarkeit und Qualität des Systems. Nun, denken Sie darüber nach und viel Spaß beim Erkunden der Hashfunktion!

Jetzt teilen auf:

Jetzt kommentieren