Multi-Source und Multi-View Konsistenz Seminar Data Warehousing und Mining Christoph Burki Begrüssung

Inhalt Einführung Multi-Source Konsistenz Multi-View Konsistenz STROBE Algorithmus SWEEP Algorithmus Multi-View Konsistenz Painting Algorithmus Einordnen der Konsistenzbegriffe Zusammenfassung Inhalt Ausgangslage Definitionen 14.05.2018 Multi-Source und Multi-View Konsistenz - Einführung

Architektur eines Data Warehouses Ausgangslage Architektur eines Data Warehouses Data Warehouse Integrator Data Warehouse: Enthält zusammengefügte Informationen von mehreren verteilten Daten-Quellen Quellen: verteilte Daten-Quellen Monitor: erkennen Änderungen in den Quellen und melden sie nach oben Integrator:empfängt die Nachrichten von den Quellen und veranlasst nötige Änderungen im Warehouse. Verantwortlich für die Konsistenz des Warehouses) Warehouse-Ebene: Daten auf denen Benutzeranfragen ausgeführt werden. Monitor Monitor Monitor Monitor . . . Quelle 1 Quelle 2 Quelle 3 Quelle n 14.05.2018 Multi-Source und Multi-View Konsistenz - Einführung

Datenzugriff via Warehouse Warehouse V1 = R x S; V2 = S x T Views definieren periodische Wiederberechnung der Views incrementelles updaten der Views Wichtig: Konsistenzerhaltung Datenmanagement kann auf verschiedene Arten passieren: ( Daten ins Warehouse kopieren: Speicherintensiv Anfragen weiterleiten: Kommunikationsintensiv) Ich konzentriere mich auf Variante, wo Materialisierte Views im Warehouse gebildet werden und darauf Anfragen kreiert werden: zwei Varianten: periodisches oder incrementelles Updaten wichtig dabei, Einhalten der Konsistenz: Beispiel Beispiel: 1. zwei Views: V1 = R x S und V2 = S x T 2. Update auf Relation S 3. Updaten von View 1 V1 = R x S* 4. Inkonsistenter Zustand zwischen V1 und V2 R S T ... 14.05.2018 Multi-Source und Multi-View Konsistenz - Einführung

Konsistenz-Begriffe im Data Warehouse Multi-View-Konsistenz alle Views im Warehouse sind konsistent mehrere vom gleichen Update betroffene Views müssen gleichzeitig neu berechnet werden. Multi-Source-Konsistenz alle Quellen weisen einen konsistenten Zustand auf jedes Update von der Quelle muss mit Daten von anderen Quellen in die View eingefügt werden während der Berechnung der neuen View dürfen keine neuen Updates dazwischenfunken MVC wann tritt auf: mehrere Views im WH Bedingung, damit Konsistenz herrscht: mehrer … MSC Änderung der Quelle muss mit den anderen Relationen einer View gejoint werden, bevor sie in die View eingefügt werden kann 14.05.2018 Multi-Source und Multi-View Konsistenz - Einführung

Konsistenz-Begriffe Drei Konsistenz-Stufen Convergence: Nach allen Updates entspricht die Sicht auf der Warehouse-Ebene der Quellen-Ebene. Strong consistency: Für jeden Zustand auf der Warehouse-Ebene gibt es einen konsistenten Zustand der Quellen. Completeness: Für jeden Zustand auf der Quellen-Ebene gibt es einen konsistenten Zustand der Warehouse-Ebene. Convergence: Nach Ausführen aller Updates und anpassen der View auf der Warehouse-Ebene sind die beiden Sichten konsitenz. Zwischendurch kann es nicht konsistente Sichten auf der WH-Ebene geben, aber am Ende muss Sicht konsistent sein. Strong consistency: Zu jeder Sicht der Warehouse-Ebene muss es eine konsistente Sicht der Quellen-Ebene geben. Completeness: Zu jeder Sicht der Quellen-Ebene muss es eine konsistente Sicht der Warehouse-Ebene geben. Jeder Update in einer Quelle ergibt eine Änderung der Warehouse-Sicht. Die drei Staten sind aufbauend 14.05.2018 Multi-Source und Multi-View Konsistenz - Einführung

Multi-Source Konsistenz Annahmen: relationales System View entspricht einem Project-Select-Join über allen Relationen das Updaten eines Tupels einer Quelle und das resultierende Senden einer Message erfolgt atomar Messages sind geordnet: bei einer Quelle entspricht die Sendereihenfolge der Ankunftsreihenfolge Es gibt keine Ordnung für das Senden von Nachrichten von verschiedenen Quellen Annahmen erklären Message: Kommunikation zwischen Quelle und Warehouse 14.05.2018 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

STROBE-Algorithmus Warehouse Datenstruktur View = r1 x r2 x r3 = {} Action Liste = {} Unbeantwortete Queries = {} Warehouse Ausgangslage: View = Join über r1 bis r3. Weil r2 leer -> View leer Action List: Liste, die alle nötigen Änderungen der View aufgrund der Updates enthält. Richtet sich auf View Unbeantwortete Queries: - Jedes Update bevor in View gejoint mit anderen Relationen die in View enthalten sind - dazu wird eine Query generiert, die an Quelle geschickt wird und - solange Query nicht vollständig abgearbeitet, in UQ enthalten x y z A B B C C D r1: r2: r3: 1 2 - - 3 4 14.05.2018 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

STROBE-Algorithmus Warehouse Datenstruktur View = {} Action Liste = {} Unbeantwortete Queries = {} Warehouse 2 3 U1 Update1 = Insert vom Tupel (2,3) in r2 und melden von Quelle y an Warehouse x y z A B B C C D r1: r2: r3: 1 2 - - 3 4 14.05.2018 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

STROBE-Algorithmus Warehouse Datenstruktur View = {} Action Liste = {} Unbeantwortete Queries = {Q1} Q1 = r1 x [(2,3)] x r3 Pending(Q1) = {} Warehouse Aktionen im Warehouse: Query generieren zum berechnen der Änderungen hervorgerufen durch U1 Pending-Liste für Query generieren: Darin enthalten, alle Delete-Updates, die während abarbeiten der Query, im Warehouse eintreffen. Konsequenzen, falls nicht vorhanden sehen wir noch am Ende dieses Beispiels Einfügen von Q1 in Unbeantwortete Queries x y z A B B C C D r1: r2: r3: 1 2 2 3 3 4 14.05.2018 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

STROBE-Algorithmus Warehouse Datenstruktur View = {} Action Liste = {} Unbeantwortete Queries = {Q1} Q1 = r1 x [(2,3)] x r3 Q11 = r1 x [(2,3)] Pending(Q1) = {} Warehouse Q11 Dann: Query aufsplitten in Teilqueries für die einzelnen Quellen Q11 zur Berechnung an r1 senden x y z A B B C C D r1: r2: r3: 1 2 2 3 3 4 14.05.2018 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

STROBE-Algorithmus Warehouse Datenstruktur View = {} Action Liste = {} Unbeantwortete Queries = {Q1} Q1 = r1 x [(2,3)] x r3 Q11 = r1 x [(2,3)] Pending(Q1) = {} Warehouse A11 Danach: berechnete Antwort wird von Source x an Warehouse zurückgeschickt x y z A B B C C D r1: r2: r3: 1 2 - - 2 3 3 4 14.05.2018 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

STROBE-Algorithmus Warehouse Datenstruktur View = {} Action Liste = {} Unbeantwortete Queries = {Q1} Q1 = r1 x [(2,3)] x r3 Q11 = r1 x [2,3] Q12 = [(1,2,3)] x r3 Pending(Q1) = {} Entspricht A11 Warehouse Dann: Mit der Antwort A11 und der Query Q1 wird Q2 für r3 generiert und ... x y z A B B C C D r1: r2: r3: 1 2 - - 2 3 3 4 14.05.2018 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

STROBE-Algorithmus Warehouse Datenstruktur View = {} Action Liste = {} Unbeantwortete Queries = {Q1} Q1 = r1 x [(2,3)] x r3 Q12 = [(1,2,3)] x r3 Pending(Q1) = {} Warehouse Q12 Dann: an Quelle z geschickt. Gleichzeitig kommt eine Delete-Message von der Quelle y ans Warehouse. U2 = löschen des Tupels (2,3) aus der Relation r2 U2 x y z A B B C C D r1: r2: r3: 1 2 2 3 3 4 14.05.2018 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

STROBE-Algorithmus Warehouse Datenstruktur View = {} Action Liste = {Del(r2;(2,3))} Unbeantwortete Queries = {Q1} Q1 = r1 x [(2,3)] x r3 Q12 = [(1,2,3)] x r3 Pending(Q1) = {Del1} {Del 1} Warehouse A12 Aktionen im Warehouse: Delete-Updates werden anders behandelt als Insert-Updates Einfügen in alle Pending-Listen: Hier nur eine Einfügen in Action Liste Antwort von Q22 wird zurück geschickt x y z A B B C C D r1: r2: r3: 1 2 - - - - 3 4 14.05.2018 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

STROBE-Algorithmus Warehouse Datenstruktur View = {} Action Liste = {Del(r2;(2,3))} Unbeantwortete Queries = {Q1} A1 = {[(1,2,3,4)]} Pending(Q1) = {Del1} Warehouse Query wurde vollständig abgearbeitet -> Antwort = A1 Q1 wird aus Unbeantwortete Queries gelöscht x y z A B B C C D r1: r2: r3: 1 2 - - - - 3 4 14.05.2018 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

STROBE-Algorithmus Warehouse Datenstruktur 2. einfügen View = {} Action Liste = {Del(r2;(2,3)), Ø} Unbeantwortete Queries = {} A1 = {[(1,2,3,4)]} 1. Anwenden auf Pending(Q1) = {Del1} Warehouse Dann: Pending-Liste von Q1 auf A1 anwenden und danach A1 in Action-Liste einfügen hier sieht man gut, wenn Pending-Queue nicht existieren würde -> einfügen dieses Tupels -> unkonsistenter Zustand x y z A B B C C D r1: r2: r3: 1 2 - - - - 3 4 14.05.2018 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

STROBE-Algorithmus Datenstruktur In View einfügen, wenn unbeantworteten Queries = {} ist View = {} Action Liste = {Del(r2;(2,3)), Ø} Unbeantwortete Queries = {} Schwachpunkt: System muss ruhen zum updaten der View Warehouse Falls keine unbeantworteten Queries mehr existieren, kann View anhand der Action-Liste geändert werden. -> Schwachpunkt: System muss ruhen zum updaten der View Falls Frage: Wieso folgendes Szenario: auf Quellenebene auf Warehouse-Ebene I1 I2 D1 nach Algorithmus jedoch: I1 und D1 I2 x y z A B B C C D r1: r2: r3: 1 2 - - - - 3 4 14.05.2018 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

Nested SWEEP-Algorithmus Datenstruktur View = r1 x r2 x r3 = {} UpdateQueue = {U1} Warehouse 2 3 U1 Zweiter Multi-Source-Konsistenz-Algorithmus: Sweep-Alg. Wie funktioniert: Am besten am fast gleichen Beispiel wie vorher Insert-Update U1 von r2 von Quelle y an Warehouse UpdateQueue: Liste mit den eingetroffenen aber noch nicht bearbeiteten Updates. x y z A B B C C D r1: r2: r3: 1 2 - - 3 4 14.05.2018 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

Nested SWEEP-Algorithmus Datenstruktur Q1 = r1 x [(2,3)] x r3 View = {} UpdateQueue = {U1} Q11 = r1 x [(2,3)] Warehouse Q11 Löscht Update 1 aus UpdateQueue Warehouse kreiert wiederum Q1 und daraus Q11 für die Quelle x Danach sendet es Q11 an Quelle x x y z A B B C C D r1: r2: r3: 1 2 2 3 3 4 14.05.2018 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

Nested SWEEP-Algorithmus Datenstruktur Q1 = r1 x [(2,3)] x r3 View = {} UpdateQueue = {U2} Q11 = r1 x [(2,3)] Warehouse U2 A11 Bevor Warehouse Antwort A11 von x erhält erfolgt Delete-Update U2 Im Warehouse U2 in UpdateQueue einfügen x y z A B B C C D r1: r2: r3: 1 2 2 3 3 4 14.05.2018 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

Nested SWEEP-Algorithmus Datenstruktur Q1 = r1 x [(2,3)] x r3 View = {} UpdateQueue = {U2} Q11 = r1 x [(2,3)] Q2 = r1 x [-(2,3)] x r3 Q21 = r1 x [-(2,3)] Warehouse A11 Noch bevor A11 eintrifft wird Q2 und Q21 erzeugt und U2 aus UpdateQueue gelöscht x y z A B B C C D r1: r2: r3: 1 2 - - 3 4 14.05.2018 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

Nested SWEEP-Algorithmus Datenstruktur Q1 = r1 x [(2,3)] x r3 View = {} UpdateQueue = {} A11 = [(1,2,3)] Q2 = r1 x [-(2,3)] x r3 Q1 wartet, bis Q2 aufgeholt hat Q21 = r1 x [-(2,3)] Warehouse Q21 Q21 wird an Quelle x geschickt A11 ist unterdessen im Warehouse eingetroffen. Q1 weiss, dass unterdessen ein neues Update im Warehouse eingetroffen ist. -> {Enter} wartet Q1 bis Q2 aufgeholt hat, damit sobald beide gleich weit sind, Q1 und Q2 verschmelzen können zu einer Query x y z A B B C C D r1: r2: r3: 1 2 - - 3 4 14.05.2018 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

Nested SWEEP-Algorithmus Datenstruktur Q1 = r1 x [(2,3)] x r3 View = {} UpdateQueue = {} A11 = [(1,2)] x [(2,3)] Q2 = r1 x [-(2,3)] x r3 Q21 = r1 x [-(2,3)] Warehouse A21 Als nächstes A21 kommt von Quelle x zurück, auf die Antwort alle warten x y z A B B C C D r1: r2: r3: 1 2 - - 3 4 14.05.2018 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

Nested SWEEP-Algorithmus Datenstruktur Q1 = r1 x [(2,3)] x r3 View = {} UpdateQueue = {} A11 = [(1,2,3)] Q2 = r1 x [-(2,3)] x r3 A21 = [-(1,2,3)] Warehouse verschmelzen Q1* = [()] x r3 = {} Sobald A21 im Warehouse eingetroffen ist, werden Q1, A11, Q2 und A21 zu einer neuen Abfrage Q1* verschmolzen Weil sich daraus eine leere Abfrage ergibt, beendet der Algorithmus und View wird nicht erneuert. Falls nun Q1* nicht gleich {}, würde Query weiter an Quelle x geschickt und weiter ausgewärtet. x y z A B B C C D r1: r2: r3: 1 2 - - 3 4 14.05.2018 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

Vergleich der beiden Algorithmen Strobe-Algorithmus Konsistenz: Strong Message-Aufwand: O(n) unterschiedliche Behandlung von Inserts und Deletes braucht Ruhezustand zum updaten der View Nested Sweep-Algorithmus Konsistenz: Strong Message-Aufwand: O(n) behandelt Inserts und Deletes gleich kann View jederzeit konsistent updaten einfacher zu implementieren Vergleich 14.05.2018 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

Painting Algorithmus Aktionen im Warehouse: Warehouse Warehouse mit View1 = RxS und View2 = SxT Aktionen im Warehouse: Warehouse U(S) 1. Warehouse empfängt Update für Relation S Ausführen des Painting Algorithmus 4. Painting Algorithmus: Gemeinsames Ausführen der aus dem Mulit-Source resultierenden Action- Liste unter Einhaltung der Update-Reihenfolge Bestimmen der betroffenen Views und der Reihenfolge 2. Evaluieren welche Views davon betroffen sind und Update-Reihenfolge bestimmen MSA für V2 MSA für V1 3. Ausführen eines Multi-Source Algorithmus Zum garantieren der Multi-View-Konsistenz: Painting Algorithmus konzeptuell vorstellen 1. … 2. View bestimmen und an die dafür zuständigen Multi-Source Algorithmen schicken. Update-Reihenfolge wichtig, damit die Views in der Reihenfolge der Updates erneuert werden. 3. Z.B. Strobe- oder Sweep-Algorithmus Painting Algorithmus (auch bereits Punkt zwei): mittels einer Matrix x y Quelle x mit Relation R und S Quelle y mit Relation T 14.05.2018 Multi-Source und Multi-View Konsistenz - Multi-View Konsistenz

Anwendung von MVC Warehouse View = R x S x T x Q MergeProzess2 Action Liste Action Liste MergeProzess1 Anwndung: Action-Lists aufteilen, falls ein MergeProzess nicht genug schnell die eingehenden Actionen verarbeiten kann Z.B. Q sendet viel mehr updates als S und T. Somit S und T zusammenfassen und erst am Schluss mit der Action Liste von Q zusammenfügen. Action Liste Action Liste ViewManger (R,S) ViewManger (S,T) ViewManger (T,Q) 14.05.2018 Multi-Source und Multi-View Konsistenz - Multi-View Konsistenz

Einordnenen der Konsistenz-Begriffe Multi-View-Konsistenz . . . Warehouse View-1 View-2 View-m View-Konsistenz was versteht man darunter: folgende Situation. Hier aufgezeichnet alle verschiedene Ebenen, wo Konsistenz wichtig ist. Source-Konsistenz: Quellen innerhalb und gegeneinander konsistent sind View-Konsistenz: Überschneidet sich mit Source-K. View gegenüber eingeschlossenen Quellen konsistent Multi-View-Konsistenz: Dass auch die verschiedenen Views gegeneinander konsistent sind. (bereits gesehen an einführendem Beispiel) Source-Konsistenz Quellen x y z 14.05.2018 Multi-Source und Multi-View Konsistenz - Einordnen der Konsistenz-Begriffe

Zusammenfassung Zwei Algorithmen zur Erhaltung der Konsistenz bei mehreren Quellen Strobe-Algorithmus linearer Aufwand behandelt Insert- und Delete-Updates nicht gleich braucht Ruhezustand Sweep-Algorithmus behandelt Insert- und Delete-Updates gleich Painting Algorithmus zur Erhaltung der Multi-View Konsistenz 14.05.2018 Multi-Source und Multi-View Konsistenz - Zusammenfassung

Quellenangabe Efficient View Maintenance at Data Warehouses D. Agrawal, A. El Abbadi, A. Singh, T. Yurek Proc. of the ACM-SIGMOD Conference on Management of Data, 1997. The Strobe Algorithmus für Multi-Source Warehouse Consistency Yue Zhuge, Hector Garcia-Molina, Janet L. Wiener Standford University, 1996. Multi-View Consistency for Data Warehousing Yue Zhuge, Janet L. Wiener, Hector Garcia-Molina Stanford University, 1997. 14.05.2018 Multi-Source und Multi-View Konsistenz - Zusammenfassung