Datenherkunft - Data lineage

Datenherkunft enthält die Daten Herkunft, was mit ihm geschieht und wo es sich bewegt Zeit über. Die Datenherkunft bietet Transparenz und vereinfacht gleichzeitig die Möglichkeit, Fehler in einem Datenanalyseprozess bis zur Ursache zurückzuverfolgen .

Es ermöglicht auch die Wiedergabe bestimmter Teile oder Eingaben des Datenflusses zum schrittweisen Debuggen oder zum Regenerieren verlorener Ausgaben. Datenbanksysteme verwenden solche Informationen, die als Datenherkunft bezeichnet werden , um ähnliche Validierungs- und Debugging-Herausforderungen anzugehen. Die Datenherkunft bezieht sich auf Aufzeichnungen der Eingaben, Entitäten, Systeme und Prozesse, die die interessierenden Daten beeinflussen, und bietet eine historische Aufzeichnung der Daten und ihrer Herkunft. Die generierten Beweise unterstützen forensische Aktivitäten wie Datenabhängigkeitsanalyse, Fehler-/Kompromisserkennung und -wiederherstellung, Auditing und Compliance-Analyse. "Die Abstammung ist eine einfache Art der Herkunft ."

Die Datenherkunft kann visuell dargestellt werden , um den Datenfluss/die Datenbewegung von seiner Quelle zum Ziel über verschiedene Änderungen und Sprünge auf seinem Weg in der Unternehmensumgebung zu entdecken, wie die Daten dabei transformiert werden, wie sich die Darstellung und die Parameter ändern und wie die Daten teilen oder konvergieren nach jedem Hop. Eine einfache Darstellung der Datenherkunft kann mit Punkten und Linien dargestellt werden, wobei Punkt einen Datencontainer für Datenpunkte darstellt und Linien, die sie verbinden, die Transformationen darstellen, die der Datenpunkt zwischen den Datencontainern durchläuft.

Die Darstellung hängt im Wesentlichen vom Umfang des Metadatenmanagements und dem Referenzpunkt von Interesse ab. Die Datenherkunft stellt Quellen der Daten und Zwischendatenflusssprünge vom Referenzpunkt mit Rückwärtsdatenherkunft bereit , führt zu den Datenpunkten des endgültigen Ziels und seinen Zwischendatenflüssen mit Vorwärtsdatenherkunft . Diese Ansichten können mit einer End-to-End-Linie für einen Referenzpunkt kombiniert werden, der einen vollständigen Audit-Trail dieses Datenpunkts von Interesse von den Quellen bis zu seinen endgültigen Zielen bereitstellt. Mit zunehmenden Datenpunkten oder Sprüngen wird die Komplexität einer solchen Darstellung unverständlich. Somit wäre das beste Merkmal der Datenherkunftsansicht in der Lage zu sein, die Ansicht durch vorübergehendes Maskieren unerwünschter peripherer Datenpunkte zu vereinfachen. Tools mit Maskierungsfunktion ermöglichen die Skalierbarkeit der Ansicht und verbessern die Analyse mit der besten Benutzererfahrung sowohl für technische als auch für geschäftliche Benutzer. Data Lineage ermöglicht auch Unternehmen , um Spurenquellen spezifischer Geschäftsdaten für Zwecke der Fehlerverfolgung, Implementierung Änderungen in Prozessen und Umsetzung Systemmigrationen erhebliche Mengen an Zeit und Ressourcen zu sparen und dadurch enorm verbessern BI Effizienz.

Der Umfang der Datenherkunft bestimmt die Menge an Metadaten, die zur Darstellung der Datenherkunft erforderlich ist. Normalerweise bestimmen Data Governance und Datenmanagement den Umfang der Datenherkunft basierend auf ihren Vorschriften , der Strategie für das Unternehmensdatenmanagement, den Auswirkungen auf die Daten, den Berichtsattributen und den kritischen Datenelementen der Organisation.

Die Datenherkunft stellt den Prüfpfad der Datenpunkte auf der höchsten granularen Ebene bereit , aber die Darstellung der Herkunft kann in verschiedenen Zoomstufen erfolgen, um die umfangreichen Informationen zu vereinfachen, ähnlich wie bei analytischen Webkarten. Data Lineage kann basierend auf der Granularität der Ansicht auf verschiedenen Ebenen visualisiert werden. Auf einer sehr hohen Ebene gibt die Datenherkunft an, mit welchen Systemen die Daten interagieren, bevor sie das Ziel erreichen. Wenn die Granularität zunimmt, steigt sie auf die Datenpunktebene, wo sie die Details des Datenpunkts und sein historisches Verhalten, Attributeigenschaften sowie Trends und Datenqualität der Daten bereitstellen kann, die durch diesen bestimmten Datenpunkt in der Datenherkunft geleitet werden.

Data Governance spielt eine Schlüsselrolle im Metadatenmanagement für Richtlinien, Strategien, Richtlinien, Implementierung. Datenqualität und Stammdatenmanagement tragen dazu bei, die Datenherkunft mit mehr Geschäftswert anzureichern. Auch wenn die endgültige Darstellung der Datenherkunft in einer Schnittstelle bereitgestellt wird, kann die Art und Weise, wie die Metadaten gesammelt und der grafischen Benutzeroberfläche der Datenherkunft zugänglich gemacht werden, völlig unterschiedlich sein. Daher kann die Datenherkunft basierend auf der Art und Weise, wie Metadaten gesammelt werden, grob in drei Kategorien unterteilt werden: Datenherkunft mit Softwarepaketen für strukturierte Daten, Programmiersprachen und Big Data .

Datenherkunftsinformationen umfassen technische Metadaten, die Datentransformationen beinhalten. Angereicherte Datenherkunftsinformationen können Datenqualitätstestergebnisse, Referenzdatenwerte, Datenmodelle , Geschäftsvokabular , Datenverwalter , Programmverwaltungsinformationen und Unternehmensinformationssysteme umfassen, die mit den Datenpunkten und Transformationen verknüpft sind. Die Maskierungsfunktion in der Visualisierung der Datenherkunft ermöglicht es den Tools, alle für den jeweiligen Anwendungsfall relevanten Erweiterungen zu integrieren. Um unterschiedliche Systeme in einer gemeinsamen Ansicht darzustellen, kann eine "Metadaten-Normalisierung" oder Standardisierung erforderlich sein.

Begründung

Verteilte Systeme wie Google Map Reduce , Microsoft Dryad, Apache Hadoop (ein Open-Source-Projekt) und Google Pregel bieten solche Plattformen für Unternehmen und Nutzer. Aber auch mit diesen Systemen kann die Durchführung von Big-Data- Analysen allein aufgrund der damit verbundenen Datenmengen mehrere Stunden, Tage oder Wochen dauern. Beispielsweise dauerte die Ausführung eines Bewertungsalgorithmus für die Netflix Prize-Herausforderung auf 50 Kernen fast 20 Stunden, und eine groß angelegte Bildverarbeitungsaufgabe zur Schätzung geografischer Informationen dauerte mit 400 Kernen 3 Tage. "Das Large Synoptic Survey Telescope soll jede Nacht Terabyte an Daten generieren und schließlich mehr als 50 Petabyte speichern, während im Bioinformatiksektor die größten Genom-12-Sequenzierungshäuser der Welt jetzt jeweils Petabyte an Daten speichern." Für einen Data Scientist ist es sehr schwierig, ein unbekanntes oder unerwartetes Ergebnis zu verfolgen.

Big-Data-Debugging

Big Data Analytics ist der Prozess der Untersuchung großer Datensätze, um versteckte Muster, unbekannte Korrelationen, Markttrends, Kundenpräferenzen und andere nützliche Geschäftsinformationen aufzudecken. Sie wenden maschinelle Lernalgorithmen usw. auf die Daten an, die die Daten transformieren. Aufgrund der enormen Größe der Daten können unbekannte Merkmale in den Daten enthalten sein, möglicherweise sogar Ausreißer. Für einen Datenwissenschaftler ist es ziemlich schwierig, ein unerwartetes Ergebnis tatsächlich zu debuggen.

Der enorme Umfang und die unstrukturierte Natur von Daten, die Komplexität dieser Analysepipelines und die langen Laufzeiten stellen erhebliche Herausforderungen bei der Verwaltung und Fehlerbehebung. Selbst ein einzelner Fehler in diesen Analysen kann äußerst schwierig zu identifizieren und zu beseitigen sein. Sie können sie zwar debuggen, indem Sie die gesamte Analyse erneut durch einen Debugger für das schrittweise Debuggen ausführen, dies kann jedoch aufgrund des Zeit- und Ressourcenaufwands teuer sein. Auditing und Datenvalidierung sind weitere große Probleme aufgrund des immer einfacheren Zugangs zu relevanten Datenquellen für die Verwendung in Experimenten, des Datenaustauschs zwischen wissenschaftlichen Gemeinschaften und der Verwendung von Daten Dritter in Unternehmen. Diese Probleme werden nur größer und akuter, wenn diese Systeme und Daten weiter wachsen. Daher sind kosteneffizientere Methoden zur Analyse von Data Intensive Scalable Computing (DISC) von entscheidender Bedeutung für ihre anhaltende effektive Nutzung.

Herausforderungen beim Big-Data-Debugging

Massiver Maßstab

Laut einer EMC/IDC-Studie:

• 2,8 ZB Daten wurden im Jahr 2012 erstellt und repliziert,
• das digitale Universum wird sich bis 2020 alle zwei Jahre verdoppeln, und
• Im Jahr 2020 wird es für jede Person ungefähr 5,2 TB an Daten geben.

Die Arbeit mit dieser Datenmenge ist sehr anspruchsvoll geworden.

Unstrukturierte Daten

Unstrukturierte Daten beziehen sich normalerweise auf Informationen, die sich nicht in einer herkömmlichen Zeilen-Spalten-Datenbank befinden. Unstrukturierte Datendateien enthalten oft Text- und Multimedia-Inhalte. Beispiele sind E-Mail-Nachrichten, Textverarbeitungsdokumente, Videos, Fotos, Audiodateien, Präsentationen, Webseiten und viele andere Arten von Geschäftsdokumenten. Beachten Sie, dass diese Art von Dateien zwar eine interne Struktur haben kann, aber dennoch als "unstrukturiert" betrachtet wird, da die darin enthaltenen Daten nicht sauber in eine Datenbank passen. Experten schätzen, dass 80 bis 90 Prozent der Daten in jedem Unternehmen unstrukturiert sind. Und die Menge an unstrukturierten Daten in Unternehmen wächst deutlich, oft um ein Vielfaches schneller als strukturierte Datenbanken. " Big Data können sowohl strukturierte als auch unstrukturierte Daten umfassen, aber IDC schätzt, dass 90 Prozent der Big Data unstrukturierte Daten sind."

Die grundlegende Herausforderung von unstrukturierten Datenquellen besteht darin, dass sie für nicht-technische Geschäftsanwender und Datenanalysten gleichermaßen schwer zu entpacken, zu verstehen und für die analytische Verwendung vorzubereiten sind. Jenseits von Strukturproblemen ist die schiere Menge dieser Art von Daten. Aus diesem Grund lassen aktuelle Data-Mining-Techniken oft wertvolle Informationen aus und machen die Analyse unstrukturierter Daten mühsam und teuer.

Lange Laufzeit

Im heutigen wettbewerbsintensiven Geschäftsumfeld müssen Unternehmen die relevanten Daten, die sie benötigen, schnell finden und analysieren. Die Herausforderung besteht darin, die Datenmengen zu durchsuchen und auf die erforderliche Detailebene zuzugreifen, und das alles mit hoher Geschwindigkeit. Die Herausforderung wächst nur mit zunehmender Granularität. Eine mögliche Lösung ist Hardware. Einige Anbieter verwenden mehr Arbeitsspeicher und parallele Verarbeitung, um große Datenmengen schnell zu verarbeiten. Eine andere Methode besteht darin, Daten in den Speicher zu legen, jedoch mit einem Grid-Computing- Ansatz, bei dem viele Maschinen verwendet werden, um ein Problem zu lösen. Beide Ansätze ermöglichen es Unternehmen, riesige Datenmengen zu untersuchen. Selbst bei dieser anspruchsvollen Hard- und Software dauern nur wenige der Bildverarbeitungsaufgaben im großen Maßstab einige Tage bis einige Wochen. Das Debugging der Datenverarbeitung ist aufgrund der langen Laufzeiten extrem schwierig.

Ein dritter Ansatz fortschrittlicher Data-Discovery-Lösungen kombiniert Self-Service-Datenvorbereitung mit visueller Data Discovery und ermöglicht es Analysten, Daten gleichzeitig in einer interaktiven Analyseumgebung, die von den neueren Unternehmen Trifacta , Alteryx und anderen angeboten wird, gleichzeitig vorzubereiten und zu visualisieren .

Eine weitere Methode zum Verfolgen der Datenherkunft sind Tabellenkalkulationsprogramme wie Excel, die Benutzern eine Herkunft auf Zellenebene oder die Möglichkeit bieten, zu sehen, welche Zellen von anderen abhängig sind, aber die Struktur der Transformation geht verloren. In ähnlicher Weise bieten ETL- oder Mapping-Software eine Abstammungslinie auf Transformationsebene, jedoch zeigt diese Ansicht normalerweise keine Daten an und ist zu grobkörnig, um zwischen logisch unabhängigen Transformationen (z. B. Transformationen, die mit unterschiedlichen Spalten arbeiten) oder abhängigen zu unterscheiden.

Komplexe Plattform

Big-Data- Plattformen haben eine sehr komplizierte Struktur. Die Daten werden auf mehrere Maschinen verteilt. Typischerweise werden die Jobs auf mehrere Maschinen abgebildet und die Ergebnisse werden später durch reduzierte Operationen kombiniert. Das Debuggen einer Big-Data- Pipeline wird aufgrund der Natur des Systems sehr schwierig. Für den Datenwissenschaftler wird es keine leichte Aufgabe sein, herauszufinden, welche Maschinendaten Ausreißer und unbekannte Merkmale aufweisen, die dazu führen, dass ein bestimmter Algorithmus unerwartete Ergebnisse liefert.

Vorgeschlagene Lösung

Datenherkunft oder Datenherkunft kann verwendet werden, um das Debuggen von Big Data- Pipelines zu vereinfachen. Dies erfordert die Erhebung von Daten über Datentransformationen. Im folgenden Abschnitt wird die Datenherkunft genauer erläutert.

Datenherkunft

Die Datenherkunft bietet eine historische Aufzeichnung der Daten und ihrer Herkunft. Die Provenienz von Daten, die durch komplexe Transformationen wie Workflows generiert werden, ist für Wissenschaftler von erheblichem Wert. Daraus kann man die Qualität der Daten anhand ihrer Ahnendaten und Ableitungen ermitteln, Fehlerquellen zurückverfolgen, eine automatisierte Nachstellung von Ableitungen zur Aktualisierung von Daten ermöglichen und eine Zuordnung von Datenquellen vornehmen. Provenienz ist auch für den Geschäftsbereich von entscheidender Bedeutung, da sie verwendet werden kann, um die Datenquelle in einem Data Warehouse aufzuschlüsseln , die Entstehung von geistigem Eigentum zu verfolgen und einen Prüfpfad für regulatorische Zwecke bereitzustellen.

Die Verwendung der Datenherkunft wird in verteilten Systemen vorgeschlagen, um Datensätze durch einen Datenfluss zu verfolgen, den Datenfluss auf einer Teilmenge seiner ursprünglichen Eingaben wiederzugeben und Datenflüsse zu debuggen. Um dies zu tun, muss man die Menge der Eingaben für jeden Operator verfolgen, die verwendet wurden, um jede seiner Ausgaben abzuleiten. Obwohl es verschiedene Formen der Provenienz gibt, wie etwa Kopie-Provenienz und Wie-Provenienz, ist die Information, die wir brauchen, eine einfache Form der Warum-Provenienz oder Abstammung , wie von Cui et al.

Abstammungserfassung

Intuitiv besteht die Abstammung für einen Operator T, der die Ausgabe o erzeugt, aus Tripletts der Form {I, T, o}, wobei I die Menge der Eingaben für T ist, die verwendet werden, um o abzuleiten. Das Erfassen der Herkunft für jeden Operator T in einem Datenfluss ermöglicht es Benutzern, Fragen zu stellen wie "Welche Ausgaben wurden durch eine Eingabe i von Operator T erzeugt?" und "Welche Eingaben erzeugten in Operator T die Ausgabe o?" Eine Abfrage, die die Eingaben findet, die eine Ausgabe ableiten, wird als Rückwärtsverfolgungsabfrage bezeichnet, während eine Abfrage, die die von einer Eingabe erzeugten Ausgaben findet, als Vorwärtsverfolgungsabfrage bezeichnet wird. Die Rückwärtsverfolgung ist zum Debuggen nützlich, während die Vorwärtsverfolgung zum Verfolgen der Fehlerausbreitung nützlich ist. Tracing-Abfragen bilden auch die Grundlage für die Wiedergabe eines ursprünglichen Datenflusses. Um die Abstammung in einem DISC-System jedoch effizient zu nutzen, müssen wir in der Lage sein, die Abstammung auf mehreren Ebenen (oder Granularitäten) von Operatoren und Daten zu erfassen, eine genaue Abstammung für DISC-Verarbeitungskonstrukte zu erfassen und in der Lage sein, mehrere Datenflussstufen effizient zu verfolgen.

Das DISC-System besteht aus mehreren Ebenen von Operatoren und Daten, und verschiedene Anwendungsfälle der Abstammung können die Ebene bestimmen, auf der die Abstammung erfasst werden muss. Die Abstammung kann auf der Ebene des Jobs erfasst werden, indem Dateien verwendet werden und Abstammungstupel der Form {IF i, M RJob, OF i } angegeben werden. Die Abstammung kann auch auf der Ebene jeder Aufgabe erfasst werden, indem Datensätze verwendet und angegeben werden, zum Beispiel: Linientupel der Form {(k rr, v rr ), map, (km, vm )}. Die erste Form der Abstammung wird als grobkörnige Abstammung bezeichnet, während die zweite Form als feinkörnige Abstammung bezeichnet wird. Durch die Integration der Herkunft über verschiedene Granularitäten hinweg können Benutzer Fragen stellen wie „Welche Datei, die von einem MapReduce-Job gelesen wurde, hat diesen bestimmten Ausgabedatensatz erzeugt?“ und kann beim Debuggen über verschiedene Operator- und Datengranularitäten innerhalb eines Datenflusses hinweg nützlich sein.

Um die End-to-End-Linie in einem DISC-System zu erfassen, verwenden wir das Ibis-Modell, das den Begriff der Eindämmungshierarchien für Operatoren und Daten einführt. Insbesondere schlägt Ibis vor, dass ein Operator in einem anderen enthalten sein kann, und eine solche Beziehung zwischen zwei Operatoren wird als Operatoreindämmung bezeichnet . "Operator-Containment impliziert, dass der enthaltene (oder untergeordnete) Operator einen Teil der logischen Operation des enthaltenden (oder übergeordneten) Operators ausführt." Beispielsweise ist eine MapReduce-Aufgabe in einem Job enthalten. Ähnliche Eindämmungsbeziehungen existieren auch für Daten, die als Dateneindämmung bezeichnet werden. Dateneinschluss impliziert, dass die enthaltenen Daten eine Teilmenge der enthaltenden Daten (Übermenge) sind.

Vorschreibende Datenherkunft

Das Konzept der präskriptiven Datenherkunft kombiniert sowohl das logische Modell (Entität), wie diese Daten fließen sollen, mit der tatsächlichen Herkunft für diese Instanz.

Datenherkunft und -herkunft bezieht sich normalerweise auf die Art und Weise oder die Schritte, die ein Dataset zu seinem aktuellen Zustand gebracht hat Datenherkunft sowie alle Kopien oder Derivate. Es ist jedoch in bestimmten Fällen des Datenmanagements fehlerhaft, nur auf Audit- oder Log-Korrelationen zurückzublicken, um die Abstammung aus forensischer Sicht zu bestimmen. Ohne das Logikmodell lässt sich beispielsweise nicht mit Sicherheit feststellen, ob der Weg eines Datenworkflows richtig oder konform war.

Nur durch die Kombination eines logischen Modells mit atomaren forensischen Ereignissen können geeignete Aktivitäten validiert werden:

1. Autorisierte Kopien, Joins oder CTAS- Operationen
2. Zuordnung der Verarbeitung zu den Systemen, auf denen diese Prozesse ausgeführt werden
3. Ad-hoc versus etablierte Verarbeitungssequenzen

Viele zertifizierte Compliance-Berichte erfordern die Herkunft des Datenflusses sowie die Endzustandsdaten für eine bestimmte Instanz. Bei solchen Situationen muss jede Abweichung vom vorgeschriebenen Pfad berücksichtigt und möglicherweise behoben werden. Dies ist ein Umdenken von einem reinen Rückblickmodell hin zu einem Framework, das besser geeignet ist, um Compliance-Workflows zu erfassen.

Aktive versus faule Abstammung

Lazy Lineage Collection erfasst in der Regel nur grobkörnige Lineages zur Laufzeit. Diese Systeme verursachen aufgrund der geringen Menge an Herkunft, die sie erfassen, einen geringen Erfassungs-Overhead. Um jedoch detaillierte Tracing-Abfragen zu beantworten, müssen sie den Datenfluss für alle (oder einen großen Teil) seiner Eingaben wiedergeben und während der Wiedergabe eine detaillierte Herkunft erfassen. Dieser Ansatz eignet sich für forensische Systeme, bei denen ein Benutzer eine beobachtete fehlerhafte Ausgabe debuggen möchte.

Aktive Erfassungssysteme erfassen die gesamte Herkunft des Datenflusses zur Laufzeit. Die Art von Abstammung, die sie erfassen, kann grobkörniger oder feinkörniger sein, aber sie erfordern keine weiteren Berechnungen des Datenflusses nach seiner Ausführung. Aktive feinkörnige Erfassungssysteme verursachen höhere Erfassungs-Overheads als faule Erfassungssysteme. Sie ermöglichen jedoch eine ausgeklügelte Wiedergabe und Fehlersuche.

Schauspieler

Ein Akteur ist eine Entität, die Daten transformiert; Dabei kann es sich um einen Dryad-Vertex, einzelne Map- und Reduce-Operatoren, einen MapReduce-Job oder eine ganze Datenflusspipeline handeln. Akteure fungieren als Blackboxen und die Eingaben und Ausgaben eines Akteurs werden angezapft, um die Abstammung in Form von Assoziationen zu erfassen, wobei eine Assoziation ein Triplett {i, T, o} ist, das eine Eingabe i mit einer Ausgabe o für einen Akteur in Beziehung setzt T . Die Instrumentierung erfasst somit die Abstammung in einem Datenfluss einen Akteur nach dem anderen und ordnet sie für jeden Akteur in eine Reihe von Assoziationen zusammen. Der Systementwickler muss die Daten erfassen, die ein Akteur liest (von anderen Akteuren) und die Daten, die ein Akteur schreibt (an andere Akteure), erfassen. Ein Entwickler kann beispielsweise den Hadoop Job Tracker als Akteur behandeln, indem er die von jedem Job gelesenen und geschriebenen Dateien aufzeichnet.

Verbände

Assoziation ist eine Kombination aus Eingaben, Ausgaben und der Operation selbst. Die Operation wird in Form einer Blackbox, auch Akteur genannt, dargestellt. Die Assoziationen beschreiben die Transformationen, die auf die Daten angewendet werden. Die Assoziationen werden in den Assoziationstabellen gespeichert. Jeder eindeutige Akteur wird durch seine eigene Assoziationstabelle repräsentiert. Eine Assoziation selbst sieht wie {i, T, o} aus, wobei i die Menge der Eingaben an den Akteur T und o die Menge der vom Akteur erzeugten Ausgaben ist. Assoziationen sind die Grundeinheiten von Data Lineage. Einzelne Assoziationen werden später zusammengefügt, um den gesamten Verlauf der Transformationen zu konstruieren, die auf die Daten angewendet wurden.

Die Architektur

Big-Data- Systeme skalieren horizontal, dh erhöhen die Kapazität durch Hinzufügen neuer Hardware- oder Softwareeinheiten zum verteilten System. Das verteilte System agiert auf der logischen Ebene als eine einzelne Einheit, obwohl es mehrere Hardware- und Softwareeinheiten umfasst. Das System sollte diese Eigenschaft auch nach der horizontalen Skalierung beibehalten. Ein wichtiger Vorteil der horizontalen Skalierbarkeit besteht darin, dass sie die Möglichkeit bietet, die Kapazität im laufenden Betrieb zu erhöhen. Der größte Pluspunkt ist, dass die horizontale Skalierung mit handelsüblicher Hardware erfolgen kann.

Die horizontale Skalierungsfunktion von Big-Data- Systemen sollte bei der Erstellung der Architektur des Lineage Store berücksichtigt werden. Dies ist unabdingbar, da auch der Lineage Store selbst parallel zum Big-Data- System skalieren können soll. Die Anzahl der Assoziationen und die Speichermenge, die zum Speichern der Abstammung erforderlich ist, werden mit der Zunahme der Größe und Kapazität des Systems zunehmen. Die Architektur von Big-Data- Systemen macht die Verwendung eines einzelnen Lineage Stores nicht angemessen und unmöglich zu skalieren. Die unmittelbare Lösung für dieses Problem besteht darin, den Herkunftsspeicher selbst zu verteilen.

Im besten Fall wird für jede Maschine im verteilten Systemnetzwerk ein lokaler Herkunftsspeicher verwendet. Dadurch kann der Herkunftsspeicher auch horizontal skaliert werden. Bei diesem Entwurf wird die Herkunft der Datentransformationen, die auf die Daten auf einer bestimmten Maschine angewendet werden, im lokalen Herkunftsspeicher dieser bestimmten Maschine gespeichert. Der Herkunftsspeicher speichert normalerweise Assoziationstabellen. Jeder Akteur wird durch seine eigene Assoziationstabelle repräsentiert. Die Zeilen sind die Assoziationen selbst und die Spalten repräsentieren Ein- und Ausgänge. Dieses Design löst 2 Probleme. Es ermöglicht die horizontale Skalierung des Herkunftsspeichers. Wenn ein einzelner zentraler Herkunftsspeicher verwendet wurde, mussten diese Informationen über das Netzwerk übertragen werden, was zusätzliche Netzwerklatenz verursachen würde. Die Netzwerklatenz wird auch durch die Verwendung eines verteilten Herkunftsspeichers vermieden.

Datenflussrekonstruktion

Die in Form von Assoziationen gespeicherten Informationen müssen irgendwie kombiniert werden, um den Datenfluss eines bestimmten Jobs zu erhalten. In einem verteilten System wird ein Job in mehrere Tasks zerlegt. Eine oder mehrere Instanzen führen eine bestimmte Aufgabe aus. Die Ergebnisse, die auf diesen einzelnen Maschinen erzeugt wurden, werden später zu einem Job zusammengefügt. Aufgaben, die auf verschiedenen Computern ausgeführt werden, führen mehrere Transformationen der Daten auf dem Computer durch. Alle Transformationen, die auf die Daten auf einem Computer angewendet werden, werden im lokalen Herkunftsspeicher dieser Computer gespeichert. Diese Informationen müssen miteinander kombiniert werden, um die Abstammung des gesamten Jobs zu erhalten. Die Herkunft des gesamten Jobs sollte dem Datenwissenschaftler helfen, den Datenfluss des Jobs zu verstehen, und er/sie kann den Datenfluss verwenden, um die Big-Data- Pipeline zu debuggen . Der Datenfluss wird in 3 Stufen rekonstruiert.

Assoziationstabellen

Die erste Stufe der Datenflussrekonstruktion ist die Berechnung der Assoziationstabellen. Die Zuordnungstabellen sind für jeden Akteur in jedem lokalen Herkunftsspeicher vorhanden. Durch Kombination dieser einzelnen Assoziationstabellen kann die gesamte Assoziationstabelle für einen Akteur berechnet werden. Dies geschieht im Allgemeinen mit einer Reihe von Gleichheitsverknüpfungen, die auf den Akteuren selbst basieren. In einigen Szenarien können die Tabellen auch unter Verwendung von Eingaben als Schlüssel verknüpft werden. Indizes können auch verwendet werden, um die Effizienz eines Joins zu verbessern. Die verknüpften Tabellen müssen auf einer einzelnen Instanz oder einem Computer gespeichert werden, um die Verarbeitung fortzusetzen. Es gibt mehrere Schemata, die verwendet werden, um eine Maschine auszuwählen, auf der ein Join berechnet wird. Die einfachste ist die mit minimaler CPU-Last. Bei der Auswahl der Instanz, in der der Join erfolgen soll, sollten auch Platzbeschränkungen berücksichtigt werden.

Assoziationsgrafik

Der zweite Schritt bei der Datenflussrekonstruktion ist die Berechnung eines Assoziationsgraphen aus den Abstammungsinformationen. Das Diagramm stellt die Schritte im Datenfluss dar. Die Akteure fungieren als Vertices und die Assoziationen als Kanten. Jeder Akteur T ist im Datenfluss mit seinem vor- und nachgelagerten Akteur verbunden. Ein vorgeschalteter Akteur von T ist einer, der die Eingabe von T erzeugt, während ein nachgeordneter Akteur einer ist, der die Ausgabe von T konsumiert. Containment-Beziehungen werden beim Erstellen der Links immer berücksichtigt. Der Graph besteht aus drei Arten von Links oder Kanten.

Explizit angegebene Links

Die einfachste Verbindung ist eine explizit spezifizierte Verbindung zwischen zwei Akteuren. Diese Links sind explizit im Code eines Machine-Learning-Algorithmus angegeben. Wenn ein Akteur seinen genauen vor- oder nachgelagerten Akteur kennt, kann er diese Informationen an die Abstammungs-API übermitteln. Diese Informationen werden später verwendet, um diese Akteure während der Ablaufverfolgungsabfrage zu verknüpfen. In der MapReduce- Architektur kennt beispielsweise jede Karteninstanz die genaue Datensatzleserinstanz, deren Ausgabe sie konsumiert.

Logisch abgeleitete Links

Entwickler können jedem logischen Akteur Datenfluss- Archetypen zuordnen. Ein Datenfluss-Archetyp erklärt, wie sich die Kindertypen eines Akteurtyps in einem Datenfluss anordnen. Mit Hilfe dieser Informationen kann man eine Verbindung zwischen jedem Akteur eines Quelltyps und eines Zieltyps herleiten. In der MapReduce- Architektur ist beispielsweise der Map-Akteurtyp die Quelle für Reduce und umgekehrt. Dies leitet das System aus den Datenfluss-Archetypen ab und verknüpft Karteninstanzen ordnungsgemäss mit Reduce-Instanzen. Es können jedoch mehrere MapReduce- Jobs im Datenfluss vorhanden sein, und das Verknüpfen aller Karteninstanzen mit allen Reduce-Instanzen kann zu falschen Verknüpfungen führen. Um dies zu verhindern, sind solche Links auf Akteurinstanzen beschränkt, die in einer gemeinsamen Akteurinstanz eines enthaltenden (oder übergeordneten) Akteurtyps enthalten sind. Map- und Reduce-Instanzen werden also nur dann miteinander verknüpft, wenn sie zum gleichen Job gehören.

Implizite Links durch gemeinsame Nutzung von Datensätzen

In verteilten Systemen gibt es manchmal implizite Links, die bei der Ausführung nicht angegeben werden. Beispielsweise besteht eine implizite Verknüpfung zwischen einem Akteur, der in eine Datei geschrieben hat, und einem anderen Akteur, der daraus liest. Solche Links verbinden Akteure, die einen gemeinsamen Datensatz zur Ausführung verwenden. Der Datensatz ist die Ausgabe des ersten Akteurs und die Eingabe des darauffolgenden Akteurs.

Topologische Sortierung

Der letzte Schritt bei der Datenflussrekonstruktion ist die topologische Sortierung des Assoziationsgraphen. Der im vorherigen Schritt erstellte gerichtete Graph wird topologisch sortiert, um die Reihenfolge zu erhalten, in der die Akteure die Daten geändert haben. Diese Vererbungsreihenfolge der Akteure definiert den Datenfluss der Big-Data-Pipeline oder -Aufgabe.

Verfolgung und Wiedergabe

Dies ist der wichtigste Schritt beim Big Data- Debugging. Die erfasste Abstammung wird kombiniert und verarbeitet, um den Datenfluss der Pipeline zu erhalten. Der Datenfluss hilft dem Data Scientist oder einem Entwickler, tief in die Akteure und deren Transformationen zu schauen. Dieser Schritt ermöglicht es dem Datenwissenschaftler, den Teil des Algorithmus herauszufinden, der die unerwartete Ausgabe generiert. Eine Big-Data- Pipeline kann auf zwei Arten schiefgehen. Die erste ist die Anwesenheit eines verdächtigen Akteurs im Datenfluss. Der zweite ist die Existenz von Ausreißern in den Daten.

Der erste Fall kann durch das Verfolgen des Datenflusses debuggt werden. Durch die gemeinsame Verwendung von Herkunfts- und Datenflussinformationen kann ein Datenwissenschaftler herausfinden, wie die Eingaben in Ausgaben umgewandelt werden. Dabei können Akteure, die sich unerwartet verhalten, abgefangen werden. Entweder können diese Akteure aus dem Datenfluss entfernt oder durch neue Akteure ergänzt werden, um den Datenfluss zu verändern. Der verbesserte Datenfluss kann wiederholt werden, um seine Gültigkeit zu testen. Das Debuggen fehlerhafter Akteure umfasst das rekursive Ausführen einer grobkörnigen Wiedergabe an Akteuren im Datenfluss, was bei langen Datenflüssen ressourcenintensiv sein kann. Ein anderer Ansatz besteht darin, Herkunftsprotokolle manuell zu überprüfen, um Anomalien zu finden, was in mehreren Phasen eines Datenflusses mühsam und zeitaufwändig sein kann. Darüber hinaus funktionieren diese Ansätze nur, wenn der Datenwissenschaftler schlechte Ergebnisse entdecken kann. Um Analysen ohne bekannte fehlerhafte Ergebnisse zu debuggen, muss der Datenwissenschaftler den Datenfluss im Allgemeinen auf verdächtiges Verhalten analysieren. Häufig kennt ein Benutzer jedoch das erwartete normale Verhalten nicht und kann keine Prädikate angeben. Dieser Abschnitt beschreibt eine Debugging-Methodik für die retrospektive Analyse der Abstammung, um fehlerhafte Akteure in einem mehrstufigen Datenfluss zu identifizieren. Wir glauben, dass plötzliche Änderungen im Verhalten eines Akteurs, wie etwa seine durchschnittliche Selektivität, Verarbeitungsrate oder Ausgabegröße, charakteristisch für eine Anomalie sind. Die Abstammung kann solche Veränderungen im Verhalten von Akteuren im Laufe der Zeit und über verschiedene Akteurinstanzen hinweg widerspiegeln. Daher kann das Mining-Lineage zum Identifizieren solcher Änderungen nützlich sein, um fehlerhafte Akteure in einem Datenfluss zu debuggen.

Das zweite Problem, dh die Existenz von Ausreißern, kann ebenfalls identifiziert werden, indem der Datenfluss schrittweise ausgeführt und die transformierten Ausgaben betrachtet werden. Der Datenwissenschaftler findet eine Teilmenge von Ausgaben, die nicht mit den übrigen Ausgaben übereinstimmen. Die Eingaben, die diese schlechten Ausgaben verursachen, sind die Ausreißer in den Daten. Dieses Problem kann gelöst werden, indem der Satz von Ausreißern aus den Daten entfernt und der gesamte Datenfluss wiederholt wird. Es kann auch gelöst werden, indem der Algorithmus des maschinellen Lernens modifiziert wird, indem Akteure im Datenfluss hinzugefügt, entfernt oder verschoben werden. Die Änderungen im Datenfluss sind erfolgreich, wenn der wiedergegebene Datenfluss keine schlechten Ausgaben erzeugt.

Herausforderungen

Auch wenn die Verwendung von Data-Lineage-Ansätzen eine neuartige Methode zum Debuggen von Big-Data- Pipelines ist, ist der Prozess nicht einfach. Zu den Herausforderungen zählen die Skalierbarkeit des Herkunftsspeichers, die Fehlertoleranz des Herkunftsspeichers, die genaue Erfassung der Herkunft für Blackbox-Betreiber und vieles mehr. Diese Herausforderungen müssen sorgfältig abgewogen und Kompromisse zwischen ihnen bewertet werden, um ein realistisches Design für die Erfassung der Datenherkunft zu erstellen.

Skalierbarkeit

DISC-Systeme sind in erster Linie Batch-Verarbeitungssysteme, die für einen hohen Durchsatz ausgelegt sind. Sie führen mehrere Jobs pro Analyse aus, mit mehreren Aufgaben pro Job. Die Gesamtzahl der Operatoren, die zu einem beliebigen Zeitpunkt in einem Cluster ausgeführt werden, kann je nach Clustergröße zwischen Hunderten und Tausenden liegen. Die Abstammungserfassung für diese Systeme muss sowohl auf große Datenmengen als auch auf zahlreiche Operatoren skaliert werden können, um einen Engpass für die DISC-Analyse zu vermeiden.

Fehlertoleranz

Abstammungserfassungssysteme müssen auch fehlertolerant sein, um ein erneutes Ausführen von Datenflüssen zum Erfassen der Abstammung zu vermeiden. Gleichzeitig müssen sie auch Fehler im DISC-System berücksichtigen. Um dies zu tun, müssen sie in der Lage sein, eine fehlgeschlagene DISC-Aufgabe zu identifizieren und das Speichern doppelter Abstammungskopien zwischen der von der fehlgeschlagenen Aufgabe erzeugten Teil-Abstammung und der von der neu gestarteten Aufgabe erzeugten doppelten Abstammung zu vermeiden. Ein Abstammungssystem sollte auch in der Lage sein, mehrere Instanzen lokaler Abstammungssysteme, die ausfallen, ordnungsgemäß zu handhaben. Dies kann erreicht werden, indem Replikate von Abstammungszuordnungen auf mehreren Computern gespeichert werden. Die Replik kann wie ein Backup fungieren, falls die echte Kopie verloren geht.

Black-Box-Betreiber

Abstammungssysteme für DISC-Datenflüsse müssen in der Lage sein, eine genaue Abstammung über Black-Box-Operatoren hinweg zu erfassen, um ein detailliertes Debugging zu ermöglichen. Aktuelle Ansätze dazu sind Prober, das versucht, den minimalen Satz von Eingaben zu finden, der eine bestimmte Ausgabe für einen Black-Box-Operator erzeugen kann, indem der Datenfluss mehrmals wiederholt wird, um den minimalen Satz abzuleiten, und dynamisches Slicing, wie es von Zhang . verwendet wird et al. um die Abstammung für NoSQL- Operatoren durch binäres Umschreiben zu erfassen , um dynamische Slices zu berechnen. Obwohl solche Techniken eine sehr genaue Abstammung erzeugen, können sie einen erheblichen Zeitaufwand für die Erfassung oder Verfolgung verursachen, und es kann vorzuziehen sein, stattdessen eine gewisse Genauigkeit gegen eine bessere Leistung einzutauschen. Somit besteht ein Bedarf an einem Abstammungserfassungssystem für DISC-Datenflüsse, das die Abstammung von beliebigen Operatoren mit angemessener Genauigkeit und ohne erheblichen Mehraufwand bei der Erfassung oder Verfolgung erfassen kann.

Effizientes Tracing

Die Ablaufverfolgung ist für das Debugging unerlässlich, bei dem ein Benutzer mehrere Ablaufverfolgungsabfragen ausgeben kann. Daher ist es wichtig, dass die Rückverfolgung schnelle Durchlaufzeiten hat. Ikedaet al. können effiziente Rückwärts-Tracing-Abfragen für MapReduce-Datenflüsse durchführen, sind jedoch nicht generisch für verschiedene DISC-Systeme und führen keine effizienten Vorwärtsabfragen durch. Lipstick, ein Abstammungssystem für Pig, ist zwar in der Lage, sowohl Rückwärts- als auch Vorwärtsverfolgung durchzuführen, ist jedoch spezifisch für Pig- und SQL-Operatoren und kann nur grobkörnige Verfolgung für Blackbox-Operatoren durchführen. Somit besteht ein Bedarf an einem Abstammungssystem, das eine effiziente Vorwärts- und Rückwärtsverfolgung für generische DISC-Systeme und Datenflüsse mit Black-Box-Operatoren ermöglicht.

Anspruchsvolle Wiedergabe

Die Wiedergabe nur bestimmter Eingaben oder Teile eines Datenflusses ist entscheidend für ein effizientes Debuggen und Simulieren von Was-wäre-wenn-Szenarien. Ikedaet al. präsentieren eine Methodik für die linienbasierte Aktualisierung, die selektiv aktualisierte Eingaben wiedergibt, um betroffene Ausgaben neu zu berechnen. Dies ist beim Debuggen nützlich, um Ausgaben neu zu berechnen, wenn eine fehlerhafte Eingabe behoben wurde. Manchmal möchte ein Benutzer jedoch die fehlerhafte Eingabe entfernen und die Herkunft der zuvor von dem Fehler betroffenen Ausgaben wiederholen, um fehlerfreie Ausgaben zu erzeugen. Wir nennen das exklusive Replay. Eine weitere Verwendung von Replay beim Debuggen besteht darin, fehlerhafte Eingaben zum schrittweisen Debuggen wiederzugeben (als selektive Replay bezeichnet). Aktuelle Ansätze zur Verwendung von Abstammungslinien in DISC-Systemen gehen diese nicht an. Somit besteht ein Bedarf an einem Abstammungssystem, das sowohl exklusive als auch selektive Wiederholungen durchführen kann, um unterschiedliche Debugging-Anforderungen zu erfüllen.

Anomalieerkennung

Eines der Hauptprobleme bei der Fehlersuche in DISC-Systemen besteht darin, fehlerhafte Operatoren zu identifizieren. Bei langen Datenflüssen mit mehreren Hundert Bedienern oder Aufgaben kann die manuelle Prüfung mühsam und unerschwinglich sein. Selbst wenn Herkunft verwendet wird, um die zu untersuchende Teilmenge der Operatoren einzugrenzen, kann die Herkunft einer einzelnen Ausgabe dennoch mehrere Operatoren umfassen. Es besteht ein Bedarf an einem kostengünstigen automatisierten Fehlerbeseitigungssystem, das die Menge potenziell fehlerhafter Bediener mit angemessener Genauigkeit wesentlich eingrenzen kann, um den Umfang der erforderlichen manuellen Untersuchung zu minimieren.

Siehe auch

• Gerichteter azyklischer Graph

Verweise