Ende Juni 2014 stellte Google auf der Entwicklerkonferenz Google I/O erstmals seinen neuen Managed Service Google Cloud Dataflow vor. Der Dienst richtet sich an Unternehmen jeder Grösse, die grosse, vor allem online generierte  Datenmengen analysieren und sich dabei keine Gedanken über die verwendete Infrastruktur machen wollen. Cloud Dataflow soll vor allem diese Aufgaben erleichtern:

Cloud Dataflow eignet sich etwa für die Marketingabteilung, die Twitter- oder Facebook-Streams auswerten will, für den Online-Shop oder die Bank, die Betrugs- oder Phishing-Attacken anhand von Verhaltensmerkmalen finden möchte, oder für IT-Verantwortliche, die aus den Log-Files eines Rechenzentrums Muster herausfiltern wollen. Mit Cloud-Diensten wie Google Cloud Dataflow werden diese Berechnungen auch für kleinere Unternehmen erschwinglich.

Dataflow kann parallele Daten-Pipelines erzeugen, verarbeiten, transformieren und analysieren, und das sowohl im Batch- als auch im Streaming-Modus. Programmcode und Ressourcen sollen dabei automatisch optimiert, zur Verfügung gestellt und verwaltet werden. Die eigentliche Berechnung erfolgt transparent im Hintergrund. Dataflow holt sich automatisch die Ressourcen und verteilt die Jobs, sodass die Analyse optimiert ablaufen kann.

Da sich der Service derzeit noch im Beta-Stadium befindet, gibt es keine genauen Aussagen über die Performance oder gar ausformulierte Service Level Agreements (SLA). Auf der Entwicklerkonferenz war aber von „wenigen Sekunden“ Latenz bei Streaming-Anfragen die Rede. Auch wenn alle Prozesse automatisch ablaufen, hat der Nutzer die Möglichkeit, sich per SSH (Secure Shell) mit den Servern beziehungsweise den virtuellen Maschinen zu verbinden und die Rechenvorgänge einzusehen.

„Cloud Dataflow macht es Anwendern einfach, geschäftskritische Informationen aus ihren Daten zu gewinnen, und das mit niedrigeren operativen Kosten und ohne den Aufwand, eine eigene Infrastruktur aufbauen, verwalten und skalieren zu müssen“, schreibt Greg DeMichillie vom Google Platform Team im Developers Blog des Unternehmens. Preise hat Goo­gle für Cloud Dataflow noch nicht veröffentlicht.

Datensätze werden in Dataflow unabhängig von ihrer Herkunft als sogenannte PCollections (Parallel Collections) repräsentiert. Eine PCollection kann aus Informationen im Hauptspeicher (In-Memory) bestehen, aus einem Cloud-Speicher gelesen werden, das Ergebnis einer Big-Query-Abfrage sein, aus einem Kommunikationsstrom stammen oder direkt das Ergebnis einer Berechnung auf dem jeweiligen Knoten sein. Die Verarbeitung erfolgt mit PTransforms (Pa­rallel Transforms), die vom Entwickler der Datenabfrage anpassbar und kombinierbar sind. Google stellt neben Basis-PTransforms wie ParDo (Parallel Do) oder GroupByKey ein spezielles Starter-Kit mit kombinierten Transformationen zur Verfügung, darunter Count, Top und Mean.

Dataflow lässt sich im Prinzip mit jeder geeigneten Programmsprache adressieren, ein erstes SDK (Software Development Kit) steht für Java zur Verfügung.

Wie erwähnt braucht sich ein Programmierer in Cloud Dataflow nicht um die technische Ausführung seiner Abfragen zu kümmern. Er definiert nur die Daten-Pipelines und ihre Transformationen.

Das System entscheidet dann je nach Datenquelle und Rechnerplattform, wie die Berechnung im Detail abläuft. So lässt sich beispielsweise eine Abfrage in einer Entwicklungsumgebung aufbauen und debuggen, um sie dann später ohne weitere Anpassungen auf Produktivsystemen mit Cloud Storage oder Streaming-Daten verwenden zu können.

Auch die Unterscheidung von Batch-Analysen, also Abfragen auf statische Datenbestände, und Streaming-Analysen auf Echtzeitdaten lässt sich allein über die Definition der Datenquelle steuern. Eine weitere Anpassung des Codes ist nicht notwendig.

Im Streaming-Modus kann man sehr einfach mit einer Zeile Code ein Zeitfenster für die Auswahl der zu untersuchenden Daten definieren, das sich ohne weiteren Aufwand auf dem Zeitstrahl mitbewegt, also etwa „die letzten 24 Stunden“, die letzten 60 Minuten“ oder „letzte Woche“.

Für das Analysieren von Echtzeitdaten hat Google ausserdem den Dienst Pub/Sub vorgestellt, einen Kommunikationskanal, der Eingabe-Streams verschiedenster Herkunft mit Ausgabe-Streams verknüpfen kann.

Laut Google ist Dataflow der Nachfolger von Map-Reduce, das gut ein Jahrzehnt das übliche Verfahren war, um grosse Datenmengen parallel zu verarbeiten. „Wir verwenden Map-Reduce eigentlich nicht mehr“, sagte Urs Hölzle, Senior Vice President Technical Infrastructure bei Google, anlässlich der Dataflow-Vorstellung in der Keynote der Entwicklerkonferenz. „Map-Reduce ist gut geeignet für einfache Aufgaben, aber sehr umständlich, wenn es um Daten-Pipelines geht, und jede Analyse ist heute eine Pipeline-Analyse“, so Hölzle weiter.

Jens Bussmann, Cloud Platform Lead DACH & CEE bei Google, relativiert diese Aussage allerdings: „Map-Reduce ist nicht ‚veraltet‘. Es gibt neue Technologien wie Dataflow, die das herkömmliche Map-Reduce für viele Entwickler ersetzen, aber Map-Reduce wird weiterhin genutzt und wir gehen davon aus, dass es auch noch lange genutzt werden wird.“ Map-Reduce ist ein ebenfalls von Google entwickeltes Programmiermodell, das die parallele Berechnung auf verteilten Systemen und über grosse Datenmengen erlaubt. Es läuft in zwei Phasen ab.

In Phase eins (Map) werden die Daten, bestehend aus einem Schlüssel und dessen Wert, in eine neue Schlüssel-Wert-Kombination umgewandelt. Dieser Vorgang kann parallel auf vielen Systemen ablaufen, sodass auch extrem grosse Datenmengen in kurzer Zeit bearbeitet werden können.

Phase zwei (Reduce) sammelt alle Schlüssel-Wert-Paare aus Phase eins und konsolidiert sie. Haben zwei Daten denselben Schlüssel, werden die Werte der Einträge addiert. Optional kann zwischen den Map- und den Reduce-Vorgang noch eine Combine-Phase geschaltet werden. Die Combine-Funktion läuft knotenweise und bildet so schon einmal Zwischensummen der einzelnen Schlüssel auf den jeweiligen Knoten.

Einer der grossen Vorteile von Map-Reduce ist, dass sich die Datenanalyse auf viele Knoten eines Clusters parallel verteilen lässt, ohne dass es zu Inkonsistenzen kommen kann. Jeder Knoten erhält eine Teilmenge des Datenbestands und analysiert diesen. Dies reduziert den Rechenaufwand im nachfolgenden Reduce-Schritt meist schon um mehrere Grössenordnungen. „Die entscheidenden Ideen hinter Map-Reduce – besonders das Handling von grossen Datenmengen in kleinen, individuellen Pools – werden weiterhin in Technologien wie Hadoop fortbestehen“, sagt Bussmann.

Da Map-Reduce im Batch-Modus ausgeführt wird, hat es allerdings immer dann Schwächen, wenn in iterativen Berechnungen ein Zwischenergebnis Ausgangspunkt einer neuen Berechnung ist.

In diesem Fall müssen alle Knoten zunächst alle Schlüssel-Wert-Paare erzeugt und kombiniert haben, um dann im zweiten Schritt erneut die Map-Reduce-Phase zu durchlaufen. Die Definition und das Management dieser Data Pipelines ist aufwendig und die Ausführung unflexibel.

Map-Reduce ist für den durchschnittlichen Entwickler nicht leicht zu nutzen, so Bussmann: „Auch wir bei Goo­gle haben viel Zeit damit verbracht, verschiedene Analysen zusammenzuführen und eine brauchbare Pipeline für Daten zu schaffen.“

Typische iterative Verfahren sind Algorithmen wie Page Rank und K-Means sowie logistische Regressionen. Mit ihnen lässt sich beispielsweise der Wert wissenschaftlicher Publikationen anhand der Häufigkeit von Zitatstellen berechnen oder ein selbstlernendes System implementieren, das Spam von seriösen E-Mail-Nachrichten unterscheiden oder Klimaveränderungen prognostizieren kann.

Auch bei interaktiven Datenanalysen stösst das Batch-Verfahren von Map-Reduce an seine Grenzen, etwa wenn grosse Mengen Log-Files zur Fehleranalyse nach Mustern durchsucht werden sollen.

Um diese Einschränkungen zu umgehen, verwendet Google in Dataflow die Java-Bibliothek Flume Java (nicht zu verwechseln mit Apache Flume, einem Service zum Sammeln, Aggregieren und Transferieren grosser Mengen an Log-Daten). Flume Java erlaubt es, komplexe Abfolgen von Map-Reduce-Berechnungen – die bereits erwähnten Pipelines – in einem einzigen Java-Programm zu implementieren.

Dataflow nutzt ausserdem das ebenfalls von Google entwickelte Framework Mill Wheel. Es ermöglicht die fehlertolerante, hochskalierbare Analyse grosser Datenmengen in Echtzeit. Mill Wheel zeichnet kontinuierlich Zwischenstände (Checkpoints) auf. Das Zwischenspeichern grosser Datenmengen während ihrer Verarbeitung ist daher nicht notwendig. Auf Zeitstempeln basierende Berechnungen sind ein integraler Bestandteil des Programmiermodells von Mill Wheel, was es für den Nutzer besonders einfach macht, Auswertungen nach Zeiträumen zu definieren (zum Beispiel wöchentliche oder monatliche Zugriffe).

Google Cloud Dataflow ist nicht die einzige Initiative, die die Beschränkungen von Map-Reduce aufheben will, sagt Tony Baer, Principal Analyst und Big-Data-Experte beim Markt­forschungsunternehmen Ovum: „Die Community ist sehr viel grösser geworden und es tauchen immer mehr Alternativen auf.“

Das derzeit vielversprechendste und meistdiskutierte Modell haben Matei Zaharia et al. 2012 vorgestellt: „Resilient Distributed Datasets“ (RDD) und die dafür eigens geschaffene Programmierschnittstelle Spark. „Spark bietet einen neuen Berechnungsansatz für Map-Reduce-artige, mehrstufige Analysen, der den I/O-Overhead massiv reduzieren oder sogar eliminieren kann“, so Ovum-Analyst Baer.

RDDs sind verteilte, schreibgeschützte Daten, die durch Transformationen aus Ursprungsinformationen oder anderen RDDs entstehen. Das Modell ermöglicht es, fehlertolerant Berechnungen auf grossen Clustern durchzuführen. Es hat ausserdem dann erhebliche Vorteile, wenn die Daten zur Berechnung im RAM der beteiligten Computer vorgehalten werden, der Flaschenhals des Lesens und Schreibens auf Festplatten oder SSDs also eliminiert wird. Diese sogenannten In-Memory-Systeme erzielen bei bestimmten Analysen enorme Geschwindigkeitsgewinne gegenüber einer herkömmlichen Implementierung von Apache Hadoop mit Map-Reduce und Datenzugriff über das Hadoop Distributed File System (HDFS).

Laut Zaharia können RDDs beziehungsweise Spark die Berechnung logistischer Regressionen gegenüber Apache Hadoop um das bis zu 25-Fache beschleunigen. Die interaktive In-Memory-Datenanalyse mit Spark erzielt im Vergleich zu diskbasierten Systemen ähnliche Geschwindigkeitsvorteile.

Wenn der Big-Data-Dienst Cloud Dataflow hält, was Google verspricht, dann wird er zu einer deutlichen Demokratisierung führen – und dazu, dass sich die Analyse extrem grosser Datenmengen verbreitet.

Allerdings besteht die Herausforderung bei Big Data nicht so sehr darin, das Datenmodell zu programmieren, sondern die richtigen Fragen zu stellen und die erzielten Ergebnisse interpretieren zu können. Dafür sind auch zukünftig etwas mehr als drei Zeilen Code notwendig.

Ob ein Unternehmen Services wie Google Cloud Dataflow sinnvoll einsetzen kann, hängt auch davon ab, wo die Daten herkommen. Die Analyse in der Cloud bietet sich immer dann an, wenn die Informationen ohnehin online generiert werden. Dies ist zum Beispiel bei Facebook-Posts, Twitter-Feeds oder Transaktionen in einem Online-Shop der Fall.

Für Offline-Daten ist Apache Hadoop sicher auch zukünftig die bessere Alternative, zumal die Programmierschnittstelle Spark viele Einschränkungen von Map-Reduce aufhebt.

Map-Reduce war schon immer für spezielle Aufgaben gedacht, nämlich komplexe Berechnungen auf sehr grossen Datenmengen durchzuführen. Beispiele sind der Aufbau von Such-Indizes oder die Aufbereitung von grossen Bilddatenbanken in der Röntgendiagnostik. Das Modell ist deshalb vom Grunddesign auf den Bereich Analytik fokussiert, nicht auf Echtzeit- oder Transaktionsverarbeitung.

Wir bei IBM entwickeln Map-Reduce schon eine ganze Weile weiter und adressieren zum Beispiel in unserer eigenen Hadoop-Distribution mit Adaptive Map-Reduce eine der Schwächen der ursprünglichen Implementierung, nämlich das Thema Scheduling, das heisst die Vergabe von Time Slots an einzelne Aufgaben. Es gibt aber auch Anwendungen, für die Map-Reduce einfach ungeeignet ist, etwa die Echtzeitanalyse. Dafür haben wir mit Info Sphere Streams ein eigenes Produkt im Angebot.

Im Open-Source-Bereich gibt es zwei wesentliche Initiativen, die die Schwächen von Hadoop adressieren. Die eine ist YARN (Yet Another Resource Negotiator), die Map-Reduce nicht ablöst, sondern flexibler macht. IBM hat für YARN bereits seine Unterstützung angekündigt. Die zweite Initiative, die derzeit viel Aufmerksamkeit bekommt, ist Spark, ein Ansatz, Streaming- und Batch-Anwendungen zu mischen. Erst vor Kurzem haben wir unsere Unterstützung auch für dieses Open-Source-Projekt angekündigt.

Was die Frage Cloud-Service oder Installation im eigenen Rechenzentrum angeht, so sind wir davon überzeugt, dass beide Modelle auch zukünftig ihre Berechtigung haben werden, je nachdem wo die Daten anfallen und wie die Sicherheitsanforderungen sind. Entscheidend ist unserer Ansicht nach, dass ein einfacher Wechsel zwischen den Modellen möglich ist. So kann ein Unternehmen beispielsweise Big-Data-Anwendungen in der Cloud entwickeln und testen, den Produktivbetrieb dann aber ohne grössere Anpassungen auf eigenen Systemen durchführen.

Serviceangebote wie Google Dataflow ergänzen die Big-Data-Analyse im eigenen Rechenzentrum, ersetzen sie aber nicht. Deshalb werden Lösungen wie Apache Hadoop weiterhin ihre Berechtigung haben und auch noch über Jahre hinweg fortentwickelt werden. Hadoop ist zudem kein fertiges Produkt, sondern ein Open-Source-Framework, das man vom Ansatz her mit Linux vergleichen könnte. Wie bei Linux kann man sich als Anwender aus den verfügbaren Modulen seine eigene Lösung zusammenstellen oder auf vorgefertigte Distributionen zurückgreifen, wie sie zum Beispiel Cloudera, Hortonworks oder MapR anbieten.

Map-Reduce ist zwar das bevorzugte Programmiermodell in Hadoop, aber längst nicht das einzige. Zudem gehören zur Big-Data-Analyse neben der eigentlichen Datenverarbeitung weitere Komponenten wie die Datenhaltung oder die Steuerung des Rechen-Clusters. Besonders wichtig ist uns die Frage der Datensicherheit. Das Ver- und Entschlüsseln sensibler Daten kann dabei nur auf den Cluster-Knoten direkt erfolgen, eine separate Appliance würde die Analyse erheblich behindern. Fragen des Datenschutzes spielen bei der Entscheidung Online-Service versus eigene Installation eine grosse Rolle. Genauso entscheidend ist meiner Ansicht nach allerdings auch, wo die Daten liegen, die analysiert werden sollen. Facebook-Aktivitäten, Twitter-Streams oder Online-Transaktionsdaten wertet man sinnvollerweise auch online aus. Informationen, die im eigenen Netzwerk anfallen, etwa bei der Machine-to-Machine-Kommunikation, müssten dagegen für eine Online-Analyse erst hochgeladen werden, was bei mehreren Hundert Gigabyte oder Terabyte ein erhebliches Problem darstellt.

Abschliessend möchte ich zu bedenken geben: Die Frage, wo und mit welchen Algorithmen grosse Mengen unstrukturierter Daten analysiert werden sollen, ist meines Erachtens zweitrangig. Die eigentliche Kunst liegt darin, die richtigen Fragen zu stellen und aus den erzielten Ergebnissen die richtigen Schlüsse zu ziehen.

Google Cloud Dataflow ist ein Service, der die Analyse grosser Datenmengen sowohl im Batch-Modus als auch im Streaming-Modus – also nahezu in Echtzeit – erlaubt. Die Hauptmerkmale sind:

Google Cloud Dataflow ist derzeit als Private Beta verfügbar, für die man sich anmelden kann. Wer sich unter der E-Mail-Adresse Cloud_Dataflow_announce@googlegroups.com registriert, erfährt am schnellsten, wenn es etwas Neues gibt. Eine Aufzeichnung der Präsentation zu Dataflow auf der Entwicklerkonferenz Google I/O ist bei Youtube zu finden.