Masterarbeit MSTR-2019-38

Bibliograph.
Daten
Wagner, Matthias: Why-Not Provenance für geschachtelte Daten in Spark.
Universität Stuttgart, Fakultät Informatik, Elektrotechnik und Informationstechnik, Masterarbeit Nr. 38 (2019).
87 Seiten, deutsch.
Kurzfassung

Aktuell ist das Debugging von Verarbeitungsprozessen in Data Intensive Scalable Computing (DISC) Systemen wie Apache Spark schwierig und zeitaufwändig. In vielen Fällen sind daher die Entwickler bei der Fehlerbehebung gezwungen, sich mit der Auswertung von Logfiles und dem Ausprobieren zu behelfen. Den Prozess der Fehlerbehebung kann Provenance unterstützen. Allgemein beschreibt Provenance den Ableitungs- und Manipulationsprozess von Artefakten. Im Kontext von DISC Systemen beschreibt Provenance den Manipulationsprozess von Daten. Beim Debuggen von DISC Programmen ermöglicht die Provenance dem Benutzer das Programmverhalten und den Datenfluss im Detail zu verstehen. Why Provenance beschreibt den Manipulationsprozess von existierenden Daten. Why-Not Provenance erklärt das Fehlen von Daten. Why und Why-Not Provenance Lösungen existieren bereits für relationale Daten. Diese Lösungen helfen Entwicklern mit unterschiedlichen Erklärungen das Ergebnis besser zu verstehen und entsprechende Änderungen vorzunehmen. Für die Verarbeitung von geschachtelten Daten, wie XML oder JSON, in DISC Systemen beschränkt sich die Forschung bisher auf die Erläuterung existierender Ergebnisse. Die geschachtelten Daten auf DISC Systemen führen im Vergleich zu relationalen Daten zu neuen Herausforderungen. Bereits die Provenance Modelle für existierende Ergebnistupel auf geschachtelten Daten sind deutlich komplexer als die für relationale Modelle. Analog ist die Handhabung von Why-Not Provenance für geschachtelte Daten schwierig. Das System Pebble definiert Structural Provenance für existierende Ergebnisse für geschachtelte Daten im DISC System Spark. Dafür bringt es ein Daten- und Transformationsmodell für vorhandene Tupel mit. Dieses Modell fließt in das Modell für Why-Not Provenance für geschachtelte Daten dieser Arbeit ein. Das Modell für Why-Not Provenance verwendet das vorhandene Transformationsmodell und enthält ein Datenmodell, zur Sammlung von Informationen über fehlende Tupel. Auf Basis des Modells stelle ich zwei Why-Not Provenance Algorithmen zur Berechnung von Erklärungen vor. Der erste Why-Not Provenance Algorithmus ist der Forwardtracing Algorithmus. Er berechnet anfragebasierte Erklärungen für fehlende Ergebnisse eines Sparkprogramms über eine Dateninstanz. Er verfolgt zu dem fehlenden Ergebnis kompatible Tupel beginnend bei den Eingabedaten. Für die Berechnung der Nachfolger bzw. Vorgänger verwendet der Algorithmus die Structural Provenance von Pebble. Transformationen, bei denen diese Tupel keine Nachfolger haben, gibt der Algorithmus als Erklärungen aus. Der zweite Why-Not Provenance Algorithmus ist der Unbeendete Tupel Algorithmus. Er berechnet auch anfragebasierte Erklärungen. Die kompatiblen Tupel sucht der Algorithmus nur in unbeendeten Tupeln. Unbeendete Tupel sind in der Eingabe einer Transformation und haben keinen Nachfolger in der Ausgabe. Der Algorithmus sammelt die Structural Provenance der unbeendeten Tupel und überprüft diese auf Kompatibilität. Die Erklärungen sind die Transformationen, an denen die unbeendeten kompatiblen Tupel keinen Nachfolger haben. Die Evaluation vergleich den Unbeendete Tupel Algorithmus mit dem Forwardtracing Algorithmus. Die Unterschiede in den gefundenen Erklärungen lassen sich auf Einschränkungen im Unrestructuring zurückführen. Die Verwendung eines DISC Systems als Plattform erlaubt den Algorithmen effizient auf großen Datensätzen zu arbeiten. Die untersuchten Szenarien sind aus der Veröffentlichungsdatenbank DBLP mit 500 GB und 500 GB Tweets von Twitter. Der Unbeendete Tupel Algorithmus ist deutlich schneller als der Forwardtracing Algorithmus, wenn letzterer nicht früh die Berechnung beenden kann.

Abteilung(en)Universität Stuttgart, Institut für Parallele und Verteilte Systeme, Data Engineering
BetreuerHerschel, Prof. Melanie; Diestelkämper, Ralf
Eingabedatum12. August 2019
   Publ. Informatik