Multi-Source und Multi-View Konsistenz

Präsentation zum Thema: "Multi-Source und Multi-View Konsistenz"—  Präsentation transkript:

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

2 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 Multi-Source und Multi-View Konsistenz - Einführung

3 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 Multi-Source und Multi-View Konsistenz - Einführung

4 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 ... Multi-Source und Multi-View Konsistenz - Einführung

5 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 Multi-Source und Multi-View Konsistenz - Einführung

6 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 Multi-Source und Multi-View Konsistenz - Einführung

7 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 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

8 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 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

9 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 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

10 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 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

11 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 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

12 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 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

13 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 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

14 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 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

15 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 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

16 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 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

17 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 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

18 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 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

19 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 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

20 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 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

21 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 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

22 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 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

23 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 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

24 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 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

25 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 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

26 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 Multi-Source und Multi-View Konsistenz - Multi-Source Konsistenz

27 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 Multi-Source und Multi-View Konsistenz - Multi-View Konsistenz

28 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) Multi-Source und Multi-View Konsistenz - Multi-View Konsistenz

29 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 Multi-Source und Multi-View Konsistenz - Einordnen der Konsistenz-Begriffe

30 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 Multi-Source und Multi-View Konsistenz - Zusammenfassung

31 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. Multi-Source und Multi-View Konsistenz - Zusammenfassung