Data Warehousing und Data Mining

Transkript

1 Data Warehousing und Data Mining ETL: Extraction, Transformation, Load Ulf Leser Wissensmanagement in der Bioinformatik

2 Der ETL Prozess Qrtl. Qrtl. Qrtl. Qrtl. Extraction Transformation Load Ulf Leser: Data Warehousing und Data Mining 2

3 Inhalt dieser Vorlesung ETL: Extraction, Transformation, Load - Extraktion von Daten aus Quellen - Das Differential Snapshot Problem - Laden von Daten in das DWH Schemaheterogenität Transformation Datenqualität Ulf Leser: Data Warehousing und Data Mining 3

4 ETL - Übersicht Daten werden physikalisch bewegt Von den Quellen zur Staging Area Extraktion von Daten aus den Quellen Erstellen / Erkennen von differentiellen Updates Erstellen von LOAD Files Von der Staging Area zur Basisdatenbank Ziele Data Cleaning und Filtering Erstellung integrierter Datenbestände Höchstmögliche Aktualität des Datenbestands im DWH Sicherung der DWH Konsistenz bzgl. Datenquellen Bei maximaler Datenqualität Bei minimaler Belastung des DWH und der Quellsysteme Ulf Leser: Data Warehousing und Data Mining 4

5 1. Extraktion Extraktion von Änderungsdaten aus Quellen Überwindet Systemgrenzen Zugriff auf HOST Systeme BATCH Jobs, Reportwriter, Daten in non-standard Formaten DB-nahe Programmierung wie PL-1, COBOL, Natural, IMS,... Beliebig strukturierte Dateien, XML, Reports, etc. Verteiltes (Herrschafts-)Wissen Doppelbelegung von Feldern, sprechende Schlüssel, Fehlende Dokumentation Teilweise kommerzielle Tools vorhanden Insb. zum Zugriff auf Standardsoftware Adaptoren Riesenmarkt, siehe EAI Ulf Leser: Data Warehousing und Data Mining 5

6 Extraktion Zwei wichtige Eigenschaften Zeitpunkt Art der extrahierten Daten Unterscheidung Fakten / Dimensionen Fakten werden immer nur eingefügt Änderungen in Klassifikationsknoten müssen versioniert und eventuell erst erkannt werden Ulf Leser: Data Warehousing und Data Mining 6

7 Zeitpunkt der Extraktion Synchrone Extraktion: Quelle propagiert jede Änderung Asynchrone Extraktion Periodisch Push: Quellen erzeugen regelmäßig Extrakte (Reports) Pull: DWH fragt regelmäßig Datenbestand ab Ereignisgesteuert Push: Quelle informiert z.b. alle X Änderungen Pull: DWH erfragt Änderungen bei bestimmten Ereignissen Jahresabschluss, Quartalsabschluss, Anfragegesteuert Push: - Pull: DWH erfragt Änderungen bei jedem Zugriff auf die (noch nicht vorhandenen oder potentiell veralteten) Daten Ulf Leser: Data Warehousing und Data Mining 7

8 Art der Daten Snapshot: Quelle liefert Bestand zu festem Zeitpunkt Typisch für Klassifikationsknoten: Produktkatalog, Kundenliste Import erfordert Erkennen von Änderungen Differential Snapshot-Problem Alternative: Komplettes Überschreiben (aber IC!) Historie aller Änderungen kann nicht exakt abgebildet werden Log: Quelle liefert jede Änderung seit letztem Export Typisch für Fakten: Verkäufe etc. Kann relativ leicht importiert werden DWH speichert ggf. Ereignis und seine Stornierung Nettolog: Quelle liefert das Delta zum letzten Export Kann relativ leicht importiert werden Keine komplette Historie möglich Ulf Leser: Data Warehousing und Data Mining 8

9 Datenversorgung Quelle... Technik Aktualität DWH Belastung DWH Belastung Quellen... erstellt periodisch Exportfiles Reports, Snapshots Je nach Frequenz Eher niedrig Eher niedrig... pushed jede Änderung (Real-Time) Trigger, Changelogs, Replikation Hoch Hoch Hoch... erstellt Extrakte auf Anfrage (Pull) Vor Benutzung Schwierig Hoch Hoch Anwendungsgesteuert Je nachdem Je nach Frequenz Je nach Frequenz Je nach Anfragen Je nach Frequenz Ulf Leser: Data Warehousing und Data Mining 9

10 Inhalt dieser Vorlesung ETL: Extraction, Transformation, Load - Extraktion von Daten aus Quellen - Das Differential Snapshot Problem - Laden von Daten in das DWH Schemaheterogenität Transformation Datenqualität Ulf Leser: Data Warehousing und Data Mining 10

11 Differential Snapshot Problem [LGM96] Viele Quellen liefern immer den vollen Datenbestand Kundenlisten, Angestelltenlisten, Produktkataloge Problem: Die meisten Tupel ändern sich selten Ständiges (Neu-)Einspielen aller Daten ineffizient Führt zu vielen unnötigen Versionen Viele Probleme mit Foreign-Keys etc. Gesucht: Algorithmen zur Berechnung des Delta Annahmen: Quelle liefert Snapshots als Files F i Snapshot einer Tabelle Zeilen (Tupel) haben identische Struktur mit Attributen A 1, A n Jedes Tupel hat einen Schlüssel k File = ungeordnete Menge von Tupeln (K, A 1,... A n ) Ulf Leser: Data Warehousing und Data Mining 11

12 Differential Snapshot Problem (DSP) Definition Gegeben zwei Dateien F 1, F 2 gleicher Struktur mit f 1 = F 1, f 2 = F 2. Das Differential Snapshot Problem (DSP) besteht darin, die kleinste Menge O={INS, DEL, UPD}* zu finden für die gilt: O(F 1 ) = F 2 Bemerkung INS, DEL, UPD operieren jeweils auf genau einem Tupel identifiziert über Schlüssel k Sei t 1 F 1, t 2 F 2. Dann ist t 1 =t 2 gdw. T 1.k=t 2.k Siehe auch Vorlesung zu Duplikaterkennung O im Allgemeinen nicht eindeutig O 1 ={ (ins(x)),(del(x)) } {} Ähnlich zu Joins, aber Tupel ohne Match erzeugen INS / DEL Full outer Join Ulf Leser: Data Warehousing und Data Mining 12

13 Szenario Alter Snapshot K104, k,k,... K4, t,r,... K202, a,a,... K102, p,q,... INS K103 INS K3 DEL K4 UPD K202:... Neuer Snapshot K103, t,h,... K104, k,k,... K102, p,q,... K3, t,r,... K202, b,b,... DSP - Algorithmus DWH Ulf Leser: Data Warehousing und Data Mining 13

14 Annahmen Kostenmodell Wir zählen nur IO Alle Operationen im Hauptspeicher sind umsonst Das Lesen/Schreiben eines Tupels kostet 1 Keine Beachtung von Blockgrößen, sequentiellen Reads etc. Das Schreiben des DS ignorieren wir Immer gleich teuer (wenn wir das kleinste finden ) Hauptspeichergröße: m Tupel Files in der Regel wesentlich größer als Hauptspeicher Ulf Leser: Data Warehousing und Data Mining 14

15 1. Versuch: DS small - kleine Files Annahme: m>f 1 oder m>f 2 Algorithmus (sei m>f 1 ) DS small : F 1 komplett in den Hauptspeicher lesen Array A mit A =f 1 initialisieren F 2 sequentiell lesen. r F 2 r F 1 : O=O (UPD r) (oder ignorieren, wenn keine Änderung) r F 1 : O=O (INS r) A[r]=true r F 1 mit A[r]=false: O=O (DEL r) Anzahl IO: f 1 +f 2 Verbesserungen F 1 im Speicher sortieren schnellerer Lookup Hat keinen Effekt auf IO Ulf Leser: Data Warehousing und Data Mining 15

16 2. Versuch: DS naive Nested Loop Ab jetzt: m<<f 1 und m<< f 2 Algorithmus DS naive r F 1 r in F 2 suchen, dazu F 2 sequentiell lesen r nicht in F 2 : O=O (DEL r) r verändert in F 2 : O=O (UPD r) r unverändert in F 2 : ignorieren Aber: INS wird nicht gefunden Lösung Array A verwalten: r F 1 F 2 : A[r]=true r: A[r]=false : (INS r) Geht nur, wenn A in den Hauptspeicher passt Sonst: Zweiten Nested Loop mit F 1, F 2 vertauscht Ulf Leser: Data Warehousing und Data Mining 16

17 DS naive Analyse Kosten Worst-Case: f 1 *f 2 +INS-Erzeugung Average-Case: f 1 *f 2 /2+INS-Erzeugung Verbesserungen F 2 sortieren und mit bin-search suchen Zusätzliche Sortierphase Vergleichsphase kostet dann f 1 *log(f 2 ) Aber: Random Access IO, deutlich langsamer als sequentielles Lesen Jeweils Partition mit Größe m von F 1 laden Verbesserung der Kosten auf f 1 /m*f 2 Ähnlich zu Blocked-Nested-Loop Ulf Leser: Data Warehousing und Data Mining 17

18 Einschub: Sortieren auf Platte Wie sortiert man ein File F, das nicht in den Hauptspeicher passt? F in Partitionen P i mit P i =m lesen Alle P i im Hauptspeicher sortieren und als Runs F i schreiben Alle F i gleichzeitig öffnen und Dazu müssen wir vielleicht sehr viele Dateien öffnen Kann man umgehen (hierarchisches externes Sortieren) aus allen Files in Sort-Merge-Reihenfolge lesen und aktuelles Tupel jeweils in F sort schreiben Implementierung über Priority-Queues Kosten: f + f + f + f = 4*f Ist das Sortieren in linearer Zeit? Ulf Leser: Data Warehousing und Data Mining 18

19 3. Versuch: DS sort Sort-Merge F 1 und F 2 sortieren Naiv Beide sortieren: 4*f 1 + 4*f 2 Beide Files parallel öffnen und in Sort-Merge-Art lesen r in F 1 und F 2 : UPD r nur in F 1 : DEL r nur in F 2 : INS Zusammen: 5*f 1 + 5*f 2 Arbeit sparen Sortiertes F 2 aufheben (wird sortiertes F1 im nächsten Update- Zyklus) Kosten: f 1 +5*f 2 Ulf Leser: Data Warehousing und Data Mining 19

20 DS sort2 Verbesserung Idee: F 2 nicht erst komplett sondern nur halb sortieren F 2 in Partitionen P i mit P i =m lesen P i im Hauptspeicher sortieren und als F 2 i schreiben Alle F 2 i mergen und gleichzeitig mit F 1 vergleichen Dabei sortierte F 2 i für das nächste Mal schreiben F 1 ist noch vom letzten Mal sortiert Kosten: f 1 +4*f 2 Noch besser: Immer nur auf Runs arbeiten Kosten: f 1 +3*f 2 Braucht doppelt so viele File Handle Ulf Leser: Data Warehousing und Data Mining 20

21 4. Versuch: DS hash Partitioned Hash Sortierung der P i ist nicht wirklich notwendig Einzige Bedingung: Aufteilung in P i muss reproduzierbar sein Hash-basierter Algorithmus F 2 in Partitionen P i mit P i =m/2 hashen Schwierig: Sicherstellen der Platzobergrenze der Hash-Buckets F 1 liegt noch partitioniert vom letzten Mal vor Mit derselben Hashfunktion Damit hat man pro Hashkey zwei maximal m/2 große Partitionen Jeweils P 1,i und P 2,i parallel lesen und DS berechnen Anzahl IO: f 1 + 3*f 2 Ev. billiger als DS sort2, weil Sortierung im Speicher gespart wird Braucht aber mehr Partitionen und eine sehr gute Hashfunktion Ulf Leser: Data Warehousing und Data Mining 21

22 Warum nicht einfach... UNIX diff verwenden? diff erwartet / beachtet Umgebung der Records Hier: Records sind ungeordnet DSP in der Datenbank lösen? Wahrscheinlich dreimaliges Lesen jeder Relation notwendig INSERT INTO delta SELECT UPD,... FROM F1, F2 WHERE F1.K=F2.K AND K1.W F2.W UNION SELECT INS,... FROM F2 WHERE NOT EXISTS (...) UNION SELECT DEL,... FROM F1 WHERE NOT EXISTS (...) Ulf Leser: Data Warehousing und Data Mining 22

23 Vergleich - Eigenschaften IO Bemerkungen DS naiv f 1 * f 2 Außerdem INS-Datenstruktur notwendig Ds small f 1 + f 2 Nur für kleine Dateien Ds sort2 f 1 + 3*f 2 Viel sortieren im Hauptspeicher Muss sehr viele Files gleichzeitig öffnen Ds hash f 1 + 3*f 2 Braucht gleichverteilende Hashfunktion Kein Bucket darf größer m/2 sein Defensiv vorgehen - Platzverschwendung Ulf Leser: Data Warehousing und Data Mining 23

24 Weitere DS Verfahren Mehr Runs als mögliche Filehandles Hierarchische externe Sortierverfahren Files komprimieren Größere Partitionen / Runs Größere Chance, Vergleich in-memory durchzuführen In Realität schneller (bei unserem Kostenmodell nicht) Window Algorithmus Annahme: Files haben eine unscharfe Ordnung Merging mit sliding window über beide Files Liefert u.u. falsche INS-DEL Paare Deutlich schneller on average Ulf Leser: Data Warehousing und Data Mining 24

25 Inhalt dieser Vorlesung ETL: Extraction, Transformation, Load - Extraktion von Daten aus Quellen - Das Differential Snapshot Problem - Laden von Daten in das DWH Schemaheterogenität Transformation Datenqualität Ulf Leser: Data Warehousing und Data Mining 25

26 Load Effizientes Einbringen von externen Daten in DWH Kritischer Punkt: Load-Vorgänge blockieren ggf. das komplette DWH Schreibsperre auf der Faktentabelle und ihren Indexen Möglichkeiten Tupel für Tupel (SQL) BULK-Load Anwendungsspezifische Schnittstellen Aspekte Trigger, Integritätsconstraints, Indexaktualisierung Update oder Insert? Ulf Leser: Data Warehousing und Data Mining 26

27 Satzbasiert: Tupel für Tupel Standard-Schnittstellen: PRO*SQL, JDBC, ODBC,... Arbeiten im normalen Transaktionskontext Trigger, Indexe und Constraints bleiben aktiv Manuelle Deaktivierung möglich Nur Satzsperren Können durch Zwischen-COMMIT verringert werden In Oracle ist das weniger performant shadow memory Aber andere Prozesse erhalten wieder eine Chance Benutzung von Prepared Statements wichtig Sonst wird sehr oft die gleiche Anfrage optimiert Teilweise proprietäre Erweiterungen (Arrays) Ulf Leser: Data Warehousing und Data Mining 27

28 BULK Load Proprietäre Verfahren Viel schneller als satzbasiertes Einfügen Laufen in speziellem Kontext, nutzen eine spezielle, proprietäre, nicht offene API zum DBMS Oracle: sqlldr mit DIRECTPATH Option Komplette Tabellensperre Keine Beachtung von Triggern oder Constraints Indexe werden erst nach Abschluss aktualisiert Kein transaktionaler Kontext Kein Logging (d.h. kein Recovery etc.) Checkpoints zum Wiederaufsetzen Rasend schnell Ulf Leser: Data Warehousing und Data Mining 28

29 Beispiel: ORACLE sqlldr Controlfile LOAD DATA INFILE 'book.dat' REPLACE INTO TABLE book ( book_title POSITION(1) CHAR(35), book_price POSITION(37) ZONED(4,2), book_pages POSITION(42) INTEGER, book_id "book_seq.nextval" ) Quelle: Oracle 9.2, Dokumentation Ulf Leser: Data Warehousing und Data Mining 29

30 Optionen Behandlung von Ausnahmen (Badfile) Einfache Datentransformationen (im Konfig-File) Checkpoints (Wiederaufsetzen nach Abbruch) Optionale Felder Konditionales Laden in mehrere Tabellen Konditionales Laden von Records REPLACE oder APPEND Paralleles Laden (in parallele Datenbank) RT*M Ulf Leser: Data Warehousing und Data Mining 30

31 Direct Path oder nicht Quelle: Oracle 9.2, Dokumentation Ulf Leser: Data Warehousing und Data Mining 31

32 Quelle Arbeitsbereich - Basisdatenbank Quelle 1 RDBMS Quelle 2 IMS Rel. Schema Q1 Rel. Schema Q2 Cube; Integriertes Schema BULK Load für ersten Schritt in die Datenbank bringen Zweiter Schritt: Aus Staging Area in Cube INSERT INTO... SELECT... Logging ausschalten Parallelisierbar Ulf Leser: Data Warehousing und Data Mining 32

33 Transformationen beim Laden der Daten Extraktion der Daten aus Quelle mit einfachen Filtern Spaltenauswahl, keine Reklamationen,... Anwendung einfacher Konvertierungen Zahl String, Integer Real,... Transformation sind zeilenorientiert keine Buffer File für den BULK-LOADER erstellen while (read_line) parse_line if (f[10]=2 & f[12]>0) write(file, f[1], string(f[4]), f[6]+f[7], bulk_upload( file) Ulf Leser: Data Warehousing und Data Mining 33

34 Transformationen in Staging Area Benutzt SQL (mengenorientiert) Vergleiche über Zeilen hinaus möglich Schlüsseleigenschaft, Duplikaterkennung,... Vergleiche mit Daten in Basisdatenbank möglich Duplikate, Plausibilität (Ausreißer), Konsistenz (Artikel-Ids) Typisch: Tagging von Datensätzen durch Prüf-Regeln UPDATE newsales SET price=price/mwst; UPDATE newsales SET cust_name= (SELECT cust_name FROM customer WHERE id=cust_id);... UPDATE newsales SET flag1=false WHERE cust_name IS NULL;... INSERT INTO DWH SELECT * FROM newsales WHERE f1=true & f2=true &... Ulf Leser: Data Warehousing und Data Mining 34

35 Quelle Arbeitsbereich Cube Quelle -> Arbeitsbereich Arbeitsbereich -> Cube Art des Zugriffs Satzorientiert (file) Mengenorientiert (SQL) Zugriff auf Verfügbare Datensätze Typische Sprache für Transformation Typische Technik für Datenbewegung Eine Quelle Quellabhängig: Alle, alle Änderungen, Deltas Skripte: Perl, AWK,... Bulk-Loader Viele Quellen sowie Cube Alle Änderungen SQL, PL/SQL SQL, PL/SQL Ulf Leser: Data Warehousing und Data Mining 35

36 Inhalt dieser Vorlesung ETL: Extraction, Transformation, Load Schemaheterogenität Transformation Datenqualität Ulf Leser: Data Warehousing und Data Mining 36

37 Heterogenität DWH CRM- System Lagerverwaltung Produktionsplanung CRM-System der Tocherfirma Ulf Leser: Data Warehousing und Data Mining 37

38 Heterogenität Zwei Informationssysteme sind heterogen, wenn sie sich in Darstellung oder Modellierung der verwalteten Daten unterscheiden Schema, Modell, Format, Informationsintegration = Überbrückung von Heterogenität Erstellung eines homogenen Systems Materialisierte Integration Erweckung des Anscheins eines homogenen Systems Virtuelle Integration Ulf Leser: Data Warehousing und Data Mining 38

39 Übersicht Syntaktische Heterogenität Datenmodellheterogenität Strukturelle Heterogenität Semantische Heterogenität Sind keine disjunkten Konzepte Starke Überlappungen, keine klaren Abgrenzungen Ulf Leser: Data Warehousing und Data Mining 39

40 Syntaktische Heterogenität Unterschiedliche Darstellung derselben Fakten Dezimalpunkt oder komma Euro oder Comma-separated oder tab-separated HTML oder ASCII oder Unicode Notenskala 1-6 oder sehr gut, gut, Binärcodierung oder Zeichen Datumsformate (12. September 2006, , 9/12/2006, ) Überwindung in der Regel nicht problematisch Umrechnung, Übersetzungstabellen, Ulf Leser: Data Warehousing und Data Mining 40

41 Datenmodellheterogenität Typische Datenmodelle CSV, relational, XML, JSON Exotisch (ASN.1) Domänenspezifisch (ACeDB, EXPRESS, OPEN-GIS, ) Zweck: Datenaustausch oder Datenspeicherung XML als Speicherformat? Black-Box-Sicht was zählt, ist was die Quelle liefert Erfordert Konvertierung beim Load Spezielle Semantik muss relational modelliert werden XML-Schachtelung im relationalen Modell? Ulf Leser: Data Warehousing und Data Mining 41

42 Beispiel Fast dasselbe in verschiedenen Datenmodellen Ulf Leser: Data Warehousing und Data Mining 42

43 Strukturelle Heterogenität Gleiche Sachverhalte mit unterschiedlichen Schemata ausdrücken Andere Aufteilung von Attributen auf Tabellen Fehlende / neue Attribute Fast immer mit semantischer Heterogenität verbunden Spezialfall: Schematische Heterogenität Verwendung anderer Elemente eines Datenmodells Kann nur schwer durch SQL überwunden werden Ulf Leser: Data Warehousing und Data Mining 43

44 Spezialfall: Schematische Heterogenität ext_stud( Id, vorname, nachname) int_stud( Id, vorname, nachname) Relation vs. Attribut Relation vs. Wert person( Id, vorname, nachname, ext?, int?) person( Id, vorname, nachname, status) Attribut vs. Wert Ulf Leser: Data Warehousing und Data Mining 44

45 Exotische Probleme? Verleiher XYZ ACTORS als VARCHAR ORIGINAL? TITLE, YEAR, an drei Stellen ID-Räume DEUTSCH und ORIGINAL getrennt? Ulf Leser: Data Warehousing und Data Mining 45

46 Schema der IMDB ACTOR und ACTRESS in verschiedenen Tabellen Beteiligte in eigenen Tabellen (FD hat Tabelle FUNKTIONEN) Ulf Leser: Data Warehousing und Data Mining 46

47 Semantik Fremdwörterduden zu Semantik Teilgebiet der Linguistik, das sich mit den Bedeutungen sprachlicher Zeichen und Zeichenfolgen befasst Bedeutung, Inhalt eines Wortes, Satzes oder Textes Programmiersprachen Syntax: EBNF, Grammatiken Semantik: Wirkungen der Ausführung Operationale Semantik, Fixpunktsemantik, Syntaktisch falsch Ich esse Butterbrot ein IF (a==5) { } els { }; Semantisch falsch Ich esse einen Schrank A=B/0 ; Ulf Leser: Data Warehousing und Data Mining 47

48 Semantik von was? Name Extension Intension Realweltliche Objekte repräsentiert Konzept Ulf Leser: Data Warehousing und Data Mining 48

49 Synonyme Verschiedene Namen für dasselbe Konzept Und die selbe Menge von Objekten DB1: Angestellter( Id, Vorname, Name, ) DB2: Person( Id, Vorname, Nachname, ) Ulf Leser: Data Warehousing und Data Mining 49

50 Homonyme Gleiche Namen für verschiedene Konzepte Treten oft bei Überschreitung von Domänengrenzen auf DB1: Sekr., Sachbearbeiter, Bereichsleiter, etc. Angestellter( Id, Vorname, Name, m, w, Funktion) DB2: Protein( Id, Sequenz, organismus, Funktion, ) Transport, Katalyse, Signal, Ulf Leser: Data Warehousing und Data Mining 50

51 Inhalt dieser Vorlesung ETL: Extraction, Transformation, Load Schemaheterogenität Transformation Datenqualität Ulf Leser: Data Warehousing und Data Mining 51

52 Transformation Der Transformationsschritt muss Heterogenität zwischen Quellen und DWH Schema überbrücken Arten von Transformationen Schematransformation Datentransformation Transformationen möglich an zwei Stellen Transformation der Quell-Extrakte zu Load-Files Transformation von der Staging-Area in die Basis-DB Ulf Leser: Data Warehousing und Data Mining 52

53 Schematransformationen Transformation von Daten eines Schemas in ein anderes Schema Notwendig bei struktureller Heterogenität In SQL nur teilweise unterstützt INSERT hat(te) nur eine Zieltabelle SQL greift nur auf Daten zu Keine Überbrückung schematischer Heterogenität Transformation erfordert meistens Programmierung Ulf Leser: Data Warehousing und Data Mining 53

54 Beispiele quelle(id, name, strasse, plz, umsatz) kunde(id, name, umsatz) adresse(id, strasse, plz) Erfordert zwei Durchläufe der Quelltabelle - INSERT INTO kunde... SELECT - INSERT INTO adresse... SELECT premium_k(id, name, umsatz) normal_k(id, name, umsatz) Erfordert zwei Durchläufe der Quelltabelle - INSERT INTO premium_k... SELECT... WHERE umsatz>=x - INSERT INTO normal_k... SELECT... WHERE umsatz<x Ulf Leser: Data Warehousing und Data Mining 54

55 Vermeidung redundanter Durchläufe Multi-Table INSERT INSERT ALL WHEN umsatz < X THEN INTO normal_k WHEN umsatz >= X THEN INTO premium_k ELSE INTO normal_k SELECT id, name, umsatz FROM quelle; Alternative: PL/SQL (JDBC) Programmierung Durchlauf der Quelltabelle mit Cursor Conditionales Insert in Zieltabelle Cursor meistens langsamer als SQL (aber flexibler) Ulf Leser: Data Warehousing und Data Mining 55

56 Datentransformationen Umwandlung von Datenwerten Notwendig bei syntaktischer oder semantischer Heterogenität In SQL recht gut unterstützt Vielfältige Funktionen im Sprachstandard Stringfunktionen, Decodierung, Datumsumwandlung, Formeln, Systemvariable,... User Defined Functions Ulf Leser: Data Warehousing und Data Mining 56

57 Beispiele Leser, Ulf Leser, Ulf Naumann, Felix Naumann, Felix INSERT INTO kunden( nachname, vorname) SELECT SubStr(name, 0, instr(name,',')-1), SubStr(name, instr(name,',')+1) FROM rawdata; Leser, 12/20/1954 Leser, Naumann, 5/18/1954 Naumann, INSERT INTO kunden( name, geburtsdatum) SELECT name, to_char(to_date(birthday, MM/DD/YYYY ) DD.MM.YYYY ) FROM rawdata; Müller, m, sehr gut Müller 0 1 Meier, w, gut Meier 1 2 INSERT INTO schueler(name, geschlecht, klasse) SELECT name, decode( upper(sex), M, 0, 1), decode( grade, sehr gut, 1, gut, 2,...) FROM rawdata; Ulf Leser: Data Warehousing und Data Mining 57

58 Inhalt dieser Vorlesung ETL: Extraction, Transformation, Load Schemaheterogenität Transformation Datenqualität Data Cleansing Der Merge/Purge Algorithmus Ulf Leser: Data Warehousing und Data Mining 58

59 Datenqualität [Spiegel Online, ] Bundesagentur meldet zu geringe Arbeitslosenzahlen Die offiziellen Arbeitsmarktdaten der vergangenen Monate waren falsch. Knapp Arbeitslose sind nicht in die Statistik eingeflossen, gab die Bundesagentur für Arbeit heute zu. Ein ganzer Datensatz war einfach verloren gegangen. Nürnberg - Zwischen der amtlichen Statistik und der tatsächlichen Arbeitslosenzahl gab es eine Differenz, sagte der Vorstandsvorsitzende der Bundesagentur für Arbeit, Frank-Jürgen Weise, heute in Nürnberg bei der Vorstellung der aktuellen Zahlen. (mehr...) Wegen einer Panne bei der Datenübertragung habe die Bundesagentur monatelang zu niedrige Arbeitslosenzahlen gemeldet. Angefangen hat alles mit einem Fehler im Dezember Nach Angaben Weises waren damals knapp erfasste Arbeitslose nicht in die Arbeitsmarktstatistik eingeflossen. "Ein ganzer Datensatz ist nicht verarbeitet worden", sagte er. Besonders pikant: Das in solchen Fällen automatisch erstellte Fehlerprotokoll blieb von den Mitarbeitern der Bundesagentur unbeachtet liegen. Die Statistik vom Januar weist dadurch beispielsweise weniger Erwerbslose aus, als es tatsächlich gab. Die Differenz zwischen der amtlichen Statistik und der tatsächlichen Arbeitslosenzahl habe sich allerdings in den darauf folgenden Monaten nach und nach verringert und betrage im Mai nur noch 6000, sagte Weise. Der Grund sei, dass viele der nicht erfassten Jobsucher inzwischen eine Stelle gefunden hätten. "Die Differenz in der Arbeitslosenstatistik ändert aber nichts an unserer generellen Arbeitsmarkteinschätzung und dem Trend", sagte Weise. Die amtliche Statistik werde nun nachträglich korrigiert. Außerdem werde künftig bei auftauchenden Fehlermeldungen die Verarbeitung von Arbeitslosendaten sofort gestoppt. Weise zufolge deckte erst eine Plausibilitätskontrolle im April die Statistik-Lücke auf. Es sei aufgefallen, dass sich erfolgreiche Jobsucher bei den Arbeitsagenturen abgemeldet hätten, die statistisch gar nicht erfasst waren. Ulf Leser: Data Warehousing und Data Mining 59

60 Datenqualität Datenqualität: Fitness for use Folgen geringer Datenqualität können dramatisch sein Falsche Prognosen, verpasstes Geschäft, Schadensersatz, DWH besonders anfällig für Qualitätsprobleme Probleme akkumulieren Qualität der Ursprungsdaten (Eingabe, Fremdfirmen,...) Qualität der Quellsysteme (Konsistenz, Constraints, Fehler,...) Qualität des ETL-Prozess (Parsen, Transformieren,...) Viele Probleme treten erst bei Konsolidierung zu Tage DWH unterstützt strategische Entscheidungen: Hohe Folgekosten bei Fehlentscheidungen Ulf Leser: Data Warehousing und Data Mining 60

61 Beispiel: Kampagnenmanagement Probleme im CRM eines Multi-Channel Vertriebs Kunden doppelt geführt Kunden falsch bewertet Falsche Adressen Folgen False positives : Verärgerte Kunden durch mehrere / unpassende Mailings False negatives : Verpasste Gelegenheiten durch fehlende / falsche Zuordnung (Cross-Selling) Sinnlose Portokosten bei falschen Adressen Ulf Leser: Data Warehousing und Data Mining 61

62 Aspekte von Datenqualität Verletze Integrität: Schlüssel, Fremdschlüssel, NOT NULL, Wertebereiche, Fehlende Daten: Fehlende Werte, fehlende Tupel Falsche Daten Objektiv falsch: Negative Preise, , Unplausible Daten: Ausreißer, unerwartete Werte,... NULL Werte Wert möglich, aber unbekannt: Ist er Professor? Wert möglich, existiert aber nicht: Er ist kein Professor! Wert unmöglich: Kinder unter 18 haben keinen Titel Duplikate Schlechte / fehlende Dokumentation Ulf Leser: Data Warehousing und Data Mining 62

63 Data Cleansing Operationen Ziel: Verbesserung der Datenqualität Ergänzung fehlender Werte Korrektur durch Lookup, Neuberechnen, Runden,... Erkennen und Löschen unrettbarer Daten Kosten/Nutzen: 80/20 Regel Datenqualität muss (und kann) gemessen werden Datenqualitäts-Metriken Verbesserungen quantifizieren Domänenabhängiger Prozess Produkte gibt es vor allem für Adressdaten Ulf Leser: Data Warehousing und Data Mining 63

64 Nachvollziehbarkeit Daten im DWH müssen erklärbar sein Anwender: Da fehlt ein Produkt im Report, Die Umsatzzahl kann nicht stimmen, Da habe ich ganz andere Zahlen Analysewerkzeug fehlerhaft? Report falsch? Data Mart falsch? Basisdatenbank unvollständig? ETL Prozeduren fehlerhaft? ETL und DC müssen nachvollziehbar sein Protokollieren aller Verarbeitungsschritte Wiederholbarkeit aller Aktionen bei neuen Daten / Anfragen Programmieren, keine manuellen Änderungen Keine Ad-Hoc Verbesserungen Mühsam, aber notwendig zur Unterstützung kontinuierlicher Prozesse Ulf Leser: Data Warehousing und Data Mining 64

65 Inhalt dieser Vorlesung ETL: Extraction, Transformation, Load Schemaheterogenität Transformation Datenqualität Data Cleansing Duplikaterkennung und der Merge/Purge Algorithmus Ulf Leser: Data Warehousing und Data Mining 65

66 Duplikate Relationale Welt: Zwei Tupel einer Relation die identische Werte in allen Attributen besitzen Allgemein: Paar von Tupeln, die demselben Realweltobjekt entsprechen ( synonyme Objekte) Manchmal leicht, manchmal schwer Mit (globaler? lokaler?) ID: ISBN, EAN, Handelsregister Ohne ID: Personen, Orte, Produkte, Viele kommerzielle Tools (für Personen und Adressen) Duplikate von Duplikaterkennung Record Linkage, Object Identification, Deduplication, Entity Resolution, object reconcilation, Ulf Leser: Data Warehousing und Data Mining 66

67 Einspielen neuer Objekte Duplikatvermeidung: Vor dem Einfügen eines neuen Tuples prüfen, ob das Objekt schon vorhanden ist Typischer Ablauf FOR $new IN new_cust SELECT count(*) INTO c FROM cust WHERE name=$new; if (c == 0) INSERT INTO cust VALUES( $new, ); else // Daten ändern UPDATE cust SET WHERE name=$new; END FOR; Effizient? Für jedes UPDATE zwei Suchen nach $new in cust Ulf Leser: Data Warehousing und Data Mining 67

68 MERGE Besser: MERGE ( Upsert ) MERGE INTO cust C USING ( SELECT * FROM new_cust) N ON (C.name = N.name) WHEN MATCHED THEN UPDATE SET WHEN NOT MATCHED THEN INSERT VALUES ( ); Benötigt nur einen Zugriff Cursor ist implizit definiert Effizient, wenn Duplikaterkennung einfach ist (Schlüssel) Ulf Leser: Data Warehousing und Data Mining 68

69 Duplikate: Das formale Problem Gegeben: Tupel T={t 1,..,t m } mit Attributen A 1,,A k Kein identifizierenden Schlüssel Komplexere Modelle (Bäume, Graphen) möglich Tupel entsprechen Objekten O={o 1,,o n } (n<m) Gesucht: eine Funktion dup: TxT bool dup gibt true zurück, wenn Tupel t 1 und t 2 demselben Objekt o entsprechen Eine Möglichkeit: Hashing, Abbildung auf Schlüssel Definiere dedup: T N und dup(t 1,t 2 )= (dedup(t 1 )=dedup(t 2 )) Zwei Tupel bekommen dann und nur dann durch dedup() dieselbe Zahl zugeordnet, wenn sie Duplikate sind dedup() kann z.b. auf einen identifizierenden Schlüssel abbilden Nachname+Vorname+Alter+Augenfarbe+Geschlecht+ Ulf Leser: Data Warehousing und Data Mining 69

70 Duplikaterkennung Vorgehen: Ähnlichkeit zweier Tupel aus der Ähnlichkeit ihrer Attributwerte berechnen Z.B. (gewichtetes) Mittel In der Praxis verwendet man oft Domänenwissen, das man in Regeln kodiert Binär Ähnlichkeitsfunktion IF t.name=s.name AND phonsim(t.vorname,s.vorname)>0.5 AND edit(t.adresse, s.adresse)>0.9 THEN s~t; sim(s,t) := 0.6*edit(t.name=s.name) + 0,2*phonsim(t.vorname,s.vorname)+ 0.7*edit(t.adresse, s.adresse); if sim(s,t)>2.6 then s~t; Ulf Leser: Data Warehousing und Data Mining 70

71 Transitivität Im strengen Sinne ist die Duplikatrelation transitiv (dup(t 1,t 2 )=true dup(t 2,t 3 )=true) dup(t 1,t 3 )=true Im realen Leben muss man damit vorsichtig sein Man nimmt an, dass Duplikate sehr ähnlich sind Ähnlichkeit misst man durch eine Funktion sim: TxT [0,1] Typisch ist ein Schwellwert: dup sim (t 1,t 2 )=true gdw. sim(t 1,t 2 )>t Aber: Ähnlichkeit ist nicht transitiv Meier, Meyer, Mayer, Bayer, Bayes, Bades, Gut überlegen, wie man mit Transitivität umgeht Hängt ab vom Vertrauen in sim und in Schwellwert t Ulf Leser: Data Warehousing und Data Mining 71

72 Problem: Alle Duplikate Finden Input Tabelle mit n Tupeln Ähnlichkeitsmaß sim() Output: Cluster äquivalenter Tupel (= Duplikate) Problem: Es gibt O(n 2 ) viele Tupelpaare Das dauert zu lange Außerdem: Nur sehr wenige sind tatsächlich Duplikate Idee Partitioniere Tabelle geschickt Tupel werden nur noch innerhalb einer Partition verglichen Sprich: dedup berechnet eine Art Superschlüssel Ulf Leser: Data Warehousing und Data Mining 72

73 Sorted Neighborhood (Merge-Purge) [HS98] Algorithmus Sortiere Tupel so, dass Duplikate (hoffentlich) nahe beieinander liegen Merge-Phase: Fenster der Größe w über sortierte Liste schieben Nur Tupel innerhalb eines Fensters vergleichen Man hat also überlappende Partitionen Purge-Phase: Duplikate werden verschmolzen, gelöscht, In anderen Worten: dedup() bildet auf einen Bereich um den Rang des Objekts ab Komplexität (n Tupel) Sortieren ist O(n*log(n)) Anzahl Vergleiche ist O(n*w) Warum? Ulf Leser: Data Warehousing und Data Mining 73

74 Schlüsselerzeugung Sortierschlüssel zentral für Effektivität des Verfahrens Rang der Tupel bestimmt die Partitionen Leider ist überhaupt nicht klar, was ein guter Schlüssel zur Duplikaterkennung ist Implizite Priorisierung der Attribute durch Aufbau des Schlüssels Wieder: Domänenwissen Vorname Nachname Adresse ID Sal Stolpho 123 First St Mauricio Hernandez 321 Second Ave Felix Naumann Hauptstr Sal Stolfo 123 First Street Schlüssel STOSAL123FRST456 HERMAU321SCND123 NAUFEL11HPTSTR987 STOSAL123FRST456 Ulf Leser: Data Warehousing und Data Mining 74

75 Merge Vorname Nachname Adresse ID Mauricio Hernandez 321 Second Ave Felix Naumann Hauptstr Sal Stolpho 123 First St Sal Stolfo 123 First Street Schlüssel HERMAU321SCND123 NAUFEL11HPTSTR987 STOSAL123FRST456 STOSAL123FRST456 Ulf Leser: Data Warehousing und Data Mining 75

76 Problem Genauigkeit ist schlecht Sortierkriterium bevorzugt immer irgendein Attribut Sind erste Buchstaben wichtiger für Identität als letzte? Ist Nachname wichtiger als Hausnummer? Lösung 1: Fenster vergrößern Dominanz eines Attributes wird weniger entscheidend Laufzeit verschlechtert sich linear mit Fenstergröße Folge: Keine nennenswerte Verbesserung bei kleiner Vergrößerung und hohe Kosten bei großer Vergrößerung Anderer Vorschlag? Ulf Leser: Data Warehousing und Data Mining 76

77 Multipass Verfahren Merge-Purge mehrmals mit verschiedenen Schlüsseln laufen lassen Pro Lauf können kleine w und einfache Schlüssel verwendet werden Duplikatbeziehungen aller Läufe sind gleichwertig Weniger effizientes, aber deutliches effektiveres Verfahren als Single-Pass Ulf Leser: Data Warehousing und Data Mining 77

78 Literatur Rahm, Do (200). Data Cleaning: Problems and Current Approaches, IEEE Data Engineering Builletin Labio, W. and Garcia-Molina, H. (1996). "Efficient Snapshot Differential Algorithms for Data Warehousing". 22nd VLDB, Bombay, India. pp Leser, U. and Naumann, F. (2006). Informationsintegration, dpunkt.verlag Heidelberg M. Hernandez and S. Stolfo (1998). Realworld data is dirty: Data cleansing and the merge/purge problem. Data Mining and Knowledge Discovery, 2(1): 9-37 Ulf Leser: Data Warehousing und Data Mining 78

79 Selbsttest Was macht der SQL MERGE Befehl? Erklären Sie das Sorted-Neighborhood Verfahren. Was hat es für eine Komplexität? In was messen Sie Komplexität? Wie funktioniert externes Sortieren? Welche Varianten der Datenversorgung eines DWH gibt es? Warum kann das linear sein, obwohl doch n*log(n) die beweisbare untere Schranke für Sortieren ist? Warum sind BULK-Loader so viel schneller? Gibt es sowas bei MySQL? Ulf Leser: Data Warehousing und Data Mining 79