Fehlertoleranz und Robustheit von ETL-Prozessen Wie gestalten wir Abläufe möglichst widerstandsfähig. Christian Borghardt I BI Consultant

Transkript

1 Fehlertoleranz und Robustheit von ETL-Prozessen Wie gestalten wir Abläufe möglichst widerstandsfähig Christian Borghardt I BI Consultant

2 Über uns areto consulting gmbh Echter Business Intelligence Spezialist Standort Köln Gegründet 2007 > 25 Mitarbeiter

3 Agenda Fehler werden kommen Wie bereite ich mich auf potentielle Fehler vor Error-Tabellen Wiederanlauffähigkeit Wie gehe ich mit Fehlern im DWH um Wie bereite ich potentielle Fehler nach Fazit

4 Welche Fehler können auftreten Unterschied zwischen technischen und fachlichen Fehlern Technische Fehler Es werden keine Dateien angeliefert Es werden falsche Dateien angeliefert Fehlerhaft umgesetzte Prozesse Fachliche Fehler Fehlerhafte Einzelsätze Fehlerhafte Vorgabe in Prozessen

5 Zahlen und Fakten Datawarehouse liefert Zusammenführung von unterschiedlichen Quellen ~ 50% der erwarteten Arbeit im DWH durch Datenqualität Für 98% ist das DWH kritisch oder wichtig Quelle: BARC Institut, Würzburg, Juli 2011 Data Warehousing Status quo, Herausforderungen und Nutzen

6 Dokumentation von Fehlern Wie funktioniert Error-Logging Name Null Typ ID NOT NULL NUMBER PRODUKT VARCHAR2(10) Erzeuge Error-Tabelle DBMS_ERRLOG.CREATE_ERROR_LOG ( DML_TABLE_NAME => 'Tabellenname', ERR_LOG_TABLE_NAME => 'Tabellenname_ERR' );

7 Spalten in den Error-Tabellen ORA_ERR_NUMBER$ ORA_ERR_MESG$ ORA_ERR_ROWID$ ORA_ERR_OPTYP$ ORA_ERR_TAG$ Spalten aus Tabelle ohne Constraints und Typ Varchar2(4000)

8 Dokumentation von Fehlern Wie funktioniert Error-Logging INSERT INTO <Tabellenname> LOG ERRORS INTO <Tabellenname>_ERR ( <ORA_ERR_TAG> ) REJECT LIMIT UNLIMITED / <X>; Spalte Werte ORA_ERR_NUMBER$ ORA-12899: "ORA-01407: "ORA-00001: ORA-02291: Wert Integritäts-Constraint Aktualisieren Unique zu groß für von Spalte ("SYS"."TABELLENNAME"."ID") (SYS.TAB_UK) (SYS.TABELLEN_FK) verletzt verletzt ORA_ERR_MESG$ SYS"."TABELLENNAME"."PRODUKT" zu "- übergeordneter NULL nicht möglich Schlüssel nicht gefunden (aktuell: 16, maximal: 10) ORA_ERR_ROWID$ AAAUcAAABAAAXkhAAA (null) ORA_ERR_OPTYP$ U I ORA_ERR_TAG$ <ORA_ERR_TAG> Update Insert Neue Produkte neuer der aus Werte einfügen Vorgang: aus Quelle durch Ladung XY Procedure DWH YZ ID 12 Produkt Schokoladentafel Wasser

9 Vorteile durch das Error-Logging Fehleranalyse wird beschleunigt Historie von Fehlern ist dokumentiert Prozesse können auf unterschiedliche Arten von Fehlern andersartig reagieren SELECT ORA_ERR_NUMBER$, COUNT(*) FROM Tabellenname_ERR GROUP BY ORA_ERR_NUMBER$

10 Nachteile durch das Error-Logging Kein direct-path Insert mehr möglich, falls es Unique Constraints oder Index Fehler gibt ( /*+ APPEND */ ) Updates, die zu einer Unique Verletzung führen werden, sind ebenfalls nicht loggbar

11 Nachteile durch das Error-Logging Jetzt haben wir die Daten aber immer noch nicht in der gewünschten Tabelle, sondern nur in einer Error-Tabelle Routine zum Auslesen der Error-Tabellen nach der Beladung für Rückmeldung SELECT COUNT(*) FROM Tabellenname_ERR HAVING COUNT(*) > 0

12 Anbindung OWB Wie nutze ich Error-Tabellen im OWB Einstellung der Error-Tabelle im Mapping Anzahl der Fehler festsetzen

13 Verfahren zur Wiederanlauffähigkeit Slowly Changing Dimensions Typ 2 Historisierung mit SCD2 Gueltig_ab und Gueltig_bis Pro fachlichem Schlüssel nur ein Datensatz gültig mit <Datum> BETWEEN Gueltig_ab AND Gueltig_bis

14 Verfahren zur Wiederanlauffähigkeit Snapshot-Historisierung Snapshot-Historisierung Partitionieren nach Ladedatum Für Wiederanlauf kann die Partition für Ladedatum truncated werden ID Produkt Ladedatum 1 Schokolade Schokolade Erdbeeren Schokolade

15 Wo sollten Fehler abgefangen werden Je früher, desto besser Wenn die Möglichkeit besteht, dann nur eine Fehlerdokumentation Error-Tabellen sind Error-Logs ( z.b. externe Tabellen ) vorzuziehen Data Warehouse Datenquellen Staging Area Transformation Area Core Data Marts

16 Umgang mit fehlerhaften Daten im DWH Einzelne Zeilen werden nachträglich ins DWH geladen Komplette Tabelle wird erneut geladen Historisierung (SCD2, Snapshot) und Partitionierung werden genutzt Fehlerhafte Daten bleiben im DWH und werden abgeschlossen Fehlerhafte Daten werden gelöscht und neugeladen Wichtig: Sollten künstliche Schlüssel verwendet werden auf die referenziert werden, müssen diese in den referenzierten Tabellen aktualisiert werden!

17 Wie bereite ich Fehler nach Wenn Probleme durch technische Prozesse erzeugt werden, dann sollten die Prozesse angepasst werden Wenn Fehler durch fehlerhafte Quellen erzeugt werden, sollte am besten die Quelle angepasst Durch Error-Tabelle existiert Fehlerhistorie. Dies hilft zur Erkennung der Problem im Vorsystem

18 Fazit Error-Tabellen Protokollierung und Historie von Fehlern Es wird eine bestimmte Zahl an Fehlern toleriert Historisierung Wiederanlauffähigkeit wird gewährleistet Fehler können so systematisch wieder entfernt oder als ungültig gekennzeichnet werden Fehler an die Quelle melden, sodass Fehler dort bereinigt werden und nicht erst im DWH

19 Ausblick Wie können wir Fehler erkennen Prüfsummen Technische Abfragen nach Speicherplatz Wie gestalten wir die Historisierung so, dass wir jeden Tag nachladen können Dummy Datensätze und Embrios zur Steigerung der Robustheit Dashboard zum automatischem Auslesen von Error-Tabellen

20 Welche Fragen darf ich Ihnen noch beantworten? Christian Borghardt BI Consultant areto consulting gmbh Data Warehouse Business Intelligence Julius-Bau-Straße Köln