DWH Integrität

Die Datenbestände in einer Datenbank sollen integer sein. Also keine verwaisten Schlüssel, keine halb geladenen Transaktionen, die durch Programmabstürze zwar die Soll-Bucghung enthalten, aber nicht die Haben Buchung. Derartige Fehler sind für Anwendungen äußerst kritisch und sollten unbedingt vermieden werden. Das gilt für Online-Transaktionsverarbeitung (OLTP), aber auch für Data Warehouse (DWH) und Online Analytical Processing (OLAP).

Die Mechanismen in den Datenbank-Managment-Systemen, um diesen erwünschten Zustand sicherzustellen, sind Tansaktionsmechanismen, deklarative referenzielle Integrität (DRI) und DB-Trigger. Damit kann unabhängig vom Anwendungsprogramm garantiert werden, dass die somit abgesicherten Integritätsanforderungen erfüllt sind. Selbstredend sind hiermit fachliche Integrität und Plausibilität nicht abzusichern – ggf. teilweise durch Triggerprogrammierung.

All diese Mechanismen haben sich in OLTP bestens bewährt und sind dort als Standard anzusehen. Im Bereich DWH und OLAP haben sich diese Standards als eher nachteilig erwiesen. Warum?

  1. Die DWH Befüllung ist gekennzeichnet von umfangreichen Ladeprozeduren, die große Zahlen von Datensätzen in einem Ladevorgang lädt und die Daten transformiert. Man nennt diesen Typus auch ETL (Extract-Transform-Load) oder ELT (Extract -Load-Transform), für den sich eine ganze Klasse von Werkzeugen am Markt etabliert haben.
  2. Die Integrität wird am Ende des ETL-Prozesses erwartet. Eine vollständige Integrität der Daten während des Laufes des Prozesses ist normalerweise nicht gefordert.
  3. Teilweise wird gerade keine Integrität vorausgesetzt, sondern das DWH als Instrument verstanden, um auch gerade Fehler zu analysieren, die aus Mangel an Daten-Integrität her rühren.
  4. Die ETL Prozesse müssen sicher und schnell ihre Aufgabe erledigen. Programmabbrüche wegen fehlender Integrität oder Mangel an Ressourcen sind unbedingt zu vermeiden.
  5. Oft wird eine erweiterte Integrität und Plausibilisierung auf fachlicher Ebene benötigt, die sich mit den Standard-DB-Mechanismen alleine nicht sicherstellen lassen.

Probleme der RDBMS für den ETL-Bedarf

All diese Punkte zeigen, dass sich die Standard-DB-Mechanismen für die Aufgabe nicht nur wenig eignen, sondern behindern:

  1. Transaktionssicherung erfordert Verarbeitungszeit und vor allem Speicherressourcen. Z.B. verwendet Oracle Rollback-Segmente, die die komplette Transaktion mit protokollieren. Sehr große Transaktionen erfordern sehr viel Platz – ansonsten brechen sie wegen Überlauf ab.
  2. Referenzielle Integrität (DRI und Trigger) erfordert ebenfalls Zeit der Überprüfung auf Satzebene. Was tun im Fehlerfall? In der Regel erfolgt ein Abbruch mit Fehlermeldung. Meist ist die Fehlermeldung zudem Unspezifisch und zeigt nicht den Datensatz unter Millionen, der zur Abbruch-Bedingung geführt hat.
  3. Referenzielle Integrität erfordert die Nutzung von DB-Indexen, die in OLAP-Anwendungen oftmals nicht oder in geringerem Umfang benötigt werden. Die Verwalung dieser Indexe zur Ladezeit kostet Ressourcen.

Lösungsvarianten

Um diese Probleme zu lösen, haben sich verschiedene Strategien etabliert, die teils alternativ, teils komplementär zum Einsatz kommen:

  • Transaktionsorientiertes Laden auf Satzebene: Ähnlich wie bei OLTP werden die Vorgänge einzeln geprüft und geladen. Vorteil: Einfaches Fehlermanagement, eingeschränkte Datenkonsistenz auch während des Ladevorganges, Keine Resourcenüberläufe, Commit nach jedem Objekt .Nachteile: Komplizierte Programmierung, sehr lange Verarbeitungszeit.
  • Nutzung von Ladeutilities am Transaktionsschutz vorbei. Z.B. Oracle Loader mit Direct Path.. Dies erfordert aber eine vorherige oder nachgelagerte Transformation und Konsistenzprüfung.
  • Vorgelagerte Transformation und Konsistenzprüfung: Häufig wird mit ETL-Tools und / oder Scripten (Shell, Perl, AWK etc) die Daten vor dem Laden in die DB transformiert. Dies Entspricht logisch gesehen einem Verzicht auf Transaktionssicherung während der Verarbeitung. Die Verarbeitung (Script etc.) muss sicherstellen, dass ihre Verarbeitung (Stage) komplett und integer abgearbeitet wird – de facto wird durch die Auslagerung der Verarbeitung die DB-Mechanismen ausgehebelt. Dabei kann sie sich nicht oder nur Eingeschränkt auf die Referenzierung von Datenbeständen der Datenbank bezogen werden.
  • Nachgelagerte Transformation und Konsistenzprüfung: Ein ‚roher’ ungeprüfter Datenbestand wird darin in die DB geladen. Dort setzen Transformationsprozesse auf. Aus bekannten Gründen (Fehlerhandlichng, Pufferüberlauf) wird anstelle mit mengenorientierten SQL-DML Anweisungen mit Stored Procedures gearbeitet, die nach einer begrenzten Anzahl – z.B. 10 000 – jeweils ein Commit setzen. Zur Erinnerung: Ein Commit nach jedem Satz ist langsam, ein Commit erst nach sehr vielen Sätzen – z.B. 1 Mio. – kann zum Abbruch wegen Überlauf führen.
  • Ausschalten von DB-Optionen: Verzicht auf DRI und Trigger Programmierung. Realisierung der Transformation und Integritätssicherung über Stored Procedures, Third Party Tools oder Scripts. Problem: Hersteller der ‚großen’ DBMS – ORACLE, DB2, SQL-Server – lassen ein Ausschalten der Transaktionsschicht nur sehr eingeschränkt zu (Direct Path, Truncate). Möglich und praktiziert ist ausschalten von DRI und Trigger, ggf. Index rebuild.
  • Die Mechanismen zur Transaktionssicherungen in den DBMS sind im DWH nicht hilfreich, Eine Überprüfung, einschließlich fachlicher Plausibilisierung ist in der Regel prozedural ohnehin unvermeidbar. Eleganter ist darum, eine DB zu wählen, die keine Transaktionsschnicht benötigt, im Besonderen MySQL.
  • Die Definition von Foreign Keys ist auf der Design-Ebene sinnvoll, jedoch muss dies nicht zwingend durch Constraints abgebildet werden. In der Regel ist eine Batch-Prüfung nach Ladeprozess effektiver,.

Fazit

Eine einheitliche Lösung der hier genannten Probleme gibt es nicht. Allerdings sollten potentielle Problemen vorher per Variantenentscheid weitgehend vermieden werden. Ein dumpfes verfahren, das an OLTP orientiert ist, führt meist nicht zu den benötigten Erwartungen.