Definition Was ist das Dataflow Model?

Anbieter zum Thema

INFOMOTION GmbH

Confluent Germany GmbH

Fivetran Germany GmbH

Das Dataflow Model ist ein von Google entworfenes Datenverarbeitungsmodell und ein praktischer Ansatz zur Verarbeitung großer, ungebundener und unsortierter Datenmengen. Es ist in dem im Jahr 2015 veröffentlichten Paper „The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing“ im Detail beschrieben.

Dataflow Model ist der Name eines von Google entworfenen Modells und praktischen Ansatzes, mit dem sich unter Ausbalancierung von Genauigkeit, Latenz und Aufwand große ungebundene und unsortierte Datenmengen verarbeiten lassen. Genauer beschrieben ist das Dataflow Modell in dem im Jahr 2015 veröffentlichten Paper mit dem englischen Titel „The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing“. Das Dokument kann über den Link https://research.google/pubs/pub43864/ abgerufen werden und steht unter Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License zur Verfügung. Im Dataflow Modell wird bewusst keine Unterscheidung zwischen Batch-, Micro-Batch und Stream-basierter Verarbeitung der Daten getroffen. Ersteller von Datenpipelines profitieren dadurch von einer gesteigerten Flexibilität bei der Abbildung ihrer spezifischen Use Cases.

Grundsätzliche Beschreibung der Problemstellung moderner Datenverarbeitungsaufgaben

Immer öfter müssen im heutigen Geschäftsumfeld riesige Mengen ungeordneter und ungebundener Daten verarbeitet werden. Beispiele für solche Daten sind Weblogs, Daten von Sensornetzwerken oder Nutzungsstatistiken aus dem Internetumfeld. Hinsichtlich des Event-Time Orderings, des von den Dateneigenschaften abhängigen Windowings und der Geschwindigkeit, mit der die Ergebnisse bereitgestellt werden, bestehen bei der Verarbeitung dieser Daten hohe Anforderungen.

Die besonderen Anforderungen an Genauigkeit, Latenz und Aufwand der Datenverarbeitung sind nur bis zu einem bestimmten Level auszubalancieren. Nicht selten führen die gestellten Anforderungen zu sehr unterschiedlich realisierten Lösungen und Systemen. Mit konventionellen Datenverarbeitungsmodellen lassen sich viele Use Cases nur sehr eingeschränkt umsetzen. Beispielsweise haben Batch-basierte Systeme wie MapReduce, Hadoop Pig und Hive, FlumeJava oder Spark Probleme mit der Realisierung der Latenzanforderungen. Streaming-Systeme kämpfen unter Umständen mit der Umsetzung der Windowing-Anforderungen, der Fehlertoleranz, der Genauigkeit und der Skalierbarkeit.

Google schlägt im Dataflow Model im Vergleich zu klassischen Modellen einen fundamental anderen Ansatz vor. Anstatt ungebundene Daten für endliche Datenverarbeitungsvorgänge und Informationspools aufzubereiten, sollen die Daten unter der Annahme prozessiert werden, dass nicht bekannt ist, wann und ob überhaupt alle Daten jemals sichtbar werden.

Begriffsklärung Unbounded/Bounded, Time Domains und Windowing

In der Beschreibung des Dataflow Models verwendet Google einige grundlegende Begriffe. Die Entwickler verzichten bewusst darauf, von Stream- und Batch-basierter Datenverarbeitung zu sprechen. Diese Art von Unterscheidung findet nicht statt. Stattdessen ist im Paper von bounded und unbounded (begrenzten und unbegrenzten bzw. gebundenen und ungebundenen) Datasets die Rede. So soll vermieden werden, dass die Verwendung einer bestimmten Datenverarbeitungs-Engine impliziert wird. Denn unbegrenzte Daten lassen sich nicht nur Stream-basiert und begrenzte Daten nicht nur Batch-basiert verarbeiten. Beispielsweise sind durch wiederholtes Ausführen von Batch-Systemen auch unbounded Daten prozessierbar. Mit passend gestalteten Streaming-Systemen lassen sich bounded Daten verarbeiten. Aus Sicht des Dataflow Models ist die Unterscheidung zwischen Streaming und Batch irrelevant.

Das Windowing unterteilt Datasets in begrenzte Datenblöcke, die sich als Gruppe verarbeiten lassen. Für die Verarbeitung ungebundener Daten ist Windowing für bestimmte, aber nicht für alle Arbeitsvorgänge notwendig. Für begrenzte Daten kann das Windowing ebenfalls eine sinnvolle Option darstellen. Windowing arbeitet zeitbasiert und findet gerichtet oder ungerichtet statt. Grundsätzlich wird bei der Verarbeitung von ungebundenen Daten zwischen den drei Window-Typen fixed (fest), sliding (gleitend) und Session-basiert unterschieden.

Bei der Verarbeitung von Event-abhängigen Daten kann zwischen zwei Time Domains unterschieden werden. Diese beiden Time Domains sind Event Time und Processing Time. Event Time ist die Zeit, zu der ein Event auftritt. Die Event Time eines Ereignisses verändert sich niemals. Bei der Processing Time handelt es sich um die Zeit, zu der ein Event an irgendeiner Stelle der Datenpipeline verarbeitet wird. Die Processing Time ändert sich mit jedem Datenverarbeitungsvorgang eines Events entlang der Datenpipeline. Mit sogenannten Watermarks lässt sich der Versatz zwischen den beiden Time Domains Event Time und Processing Time darstellen.

Bestandteile des Dataflow Models

Das Paper „The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing“ ist in mehrere Abschnitte unterteilt. Wichtige Bestandteile der Beschreibung des Dataflow Models sind:

• ein Satz an Designprinzipien

• eine kurze Diskussion der Erfahrungen von Google bei der Verarbeitung von großen, ungebundenen und unsortierten Datenmengen, die Google zur Entwicklung des Dataflow Models motivierten

• ein Windowing-Modell inklusive einfacher API

• ein Triggering-Modell mit einer flexiblen, deklarativen API

• ein inkrementelles Processing-Modell

• skalierbare Implementierungen der Modelle auf Basis der MillWheel-Streaming-Engine und der FlumeJava-Batch-Engine

(ID:48411250)