Die Entwicklung der Daten-Pipeline

Druckfreundlich, PDF & E-Mail

Für die modernen datenintensiven Anwendungen ist die Daten-Pipeline der zentrale Pfeiler.Im ersten Beitrag dieser Serie werfen wir einen Blick auf die Geschichte der Daten-Pipeline und wie sich die damit verbundenen Technologien im Laufe der Zeit entwickelt haben. Nachfolgend erfahren Sie, wie einige dieser Systeme bei Barracuda zum Einsatz kommen und was bei der Evaluierung von Komponenten der Daten-Pipeline zu beachten ist. Desweiteren führen wir einige Beispiele neuartiger Anwendungen an, die Ihnen den Einstieg in die Entwicklung und die Bereitstellung dieser Technologien erleichtern.

 

MapReduce

2004 veröffentlichten Jeff Dean und Sanjay Ghemawat vom Unternehmen Google ihren Symposiumsbeitrag MapReduce: Simplified Data Processing on Large Clusters. Die beiden Experten beschrieben MapReduce wie folgt:

„[…] ein Programmiermodell samt Implementierung zur Verarbeitung und Erzeugung großer Datensätze.“ Benutzer legen sowohl eine Map-Funktion fest, die ein Schlüssel/Wert-Paar verarbeitet, um eine Reihe von Zwischen-Schlüssel/Wert-Paaren zu generieren, als auch eine Reduce-Funktion, die alle mit demselben Zwischenschlüssel verknüpften Zwischenwerte zusammenführt.“

Mit dem MapReduce-Modell konnten sie den parallelen Workload zur Generierung des Google Web-Index vereinfachen. Dieser Workload wurde einem Knoten-Cluster zugewiesen und bot eine Skalierbarkeit, die mit dem Web-Wachstum Schritt halten kann.

Eine wichtiger Aspekt von MapReduce ist, wie und wo Daten im Cluster gespeichert werden. Bei Google hat man sich hierbei auf den Namen Google File System (GFS) geeinigt. Eine Open-Source-Implementierung von GFS aus dem Apache-Nutch-Projekt wurde letztendlich in eine Open-Source-Alternative zu MapReduce namens „Hadoop“ umgewandelt. Hadoop ist 2006 aus Yahoo! hervorgegangen. (Der Name Hadoop geht übrigens auf einen Spielzeugelefanten zurück, der dem Sohn von Doug Cutting gehörte.)

Apache Hadoop: Eine Open-Source-Implementierung von MapReduce

Hadoop fand auf Anhieb großen Zuspruch, deshalb führten Entwickler schon bald Abstraktionen ein, um Jobs auf einer höheren Ebene zu beschreiben. Während die Funktionen der Jobs (inputs, mapper, combiner und reducer) zuvor mit viel Aufwand beschrieben wurden (in der Regel in Java), konnten Benutzer nun dank Cascading-Software Daten-Pipelines mit gängigen Quellen, Senken und Operatoren erstellen. Mit der Hadoop-Erweiterung Pig beschrieben Entwickler Jobs auf einem noch höheren Niveau mithilfe von „Pig Latin“, einer völlig neuen Domain-spezifischen Sprache. Vergleichen Sie hierzu die Wortzahl in Hadoop, Cascading (2007) und Pig (2008).

Apache Spark: Eine einheitliche Analyse-Engine für die Verarbeitung großer Datenmengen

2009  begann Matei Zaharia mit der Entwicklung von Spark im AMPLab der University of California in Berkeley. 2010 veröffentlichte sein Team die wissenschaftliche Arbeit Spark: Cluster Computing with Working Sets, die eine Methode zur Wiederverwendung eines Arbeitsdatensatzes über mehrere parallele Operationen hinweg beschreibt. Die erste öffentliche Version wurde im März desselben Jahres vorgestellt. Ein Nachfolgeprojekt aus dem Jahr 2012 mit dem Titel Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing wurde auf dem USENIX Symposium on Networked Systems Design and Implementation als beste Arbeit ausgezeichnet. In dieser Arbeit wird ein neuartiger Ansatz namens Resilient Distributed Datasets (RDDs) beschrieben, mit dem Programmierer In-Memory-Berechnungen nutzen können, um erhebliche im Vergleich zu ähnlichen Jobs auf Hadoop-Basis Leistungssteigerungen für iterative Algorithmen wie PageRank oder maschinelles Lernen erzielen.

Neben den Leistungsverbesserungen für iterative Algorithmen war die Fähigkeit, interaktive Abfragen durchzuführen, eine weitere bedeutende Innovation von Spark. Spark nutzt einen interaktiven Scala-Interpreter, der es Datenforschern ermöglicht, Schnittstellen zum Cluster einzurichten und viel unkomplizierter mit großen Datensätzen zu experimentieren, als das bisher möglich war. Zuvor musste ein Hadoop-Job erst kompiliert und eingereicht werden und anschließend wartete man auf die Ergebnisse.

Ein Problem blieb jedoch bestehen – die Eingabe in diese Hadoop- oder Spark-Jobs berücksichtigt nur Daten aus einer begrenzten Quelle (es werden keine neu eingehenden Daten während der Laufzeit des Jobs berücksichtigt). Der Job zielt auf eine Eingabequelle ab; bestimmt, wie der Job in parallelisierbare Datenblöcke oder Aufgaben zerlegt werden soll; führt die Aufgaben im gesamten Cluster gleichzeitig aus; und kombiniert schließlich die Ergebnisse und speichert die Ausgabe an irgendeinem Ort. Dieses Framework bewährte sich hervorragend bei der Generierung von PageRank-Indizes oder bei einer logistischen Regression. Für eine große Anzahl anderer Jobs, die es mit Daten aus einer unbegrenzten oder Streaming-Quelle zu tun hatten, wie z. B. Clickstream-Analysen oder Betrugsbekämpfungsmaßnahmen, war dies jedoch das falsche Framework.

Apache Kafka: Eine dezentrale Streaming-Plattform

2010 war das Engineering-Team von LinkedIn damit beschäftigt, das Fundament des beliebten sozialen Karrierenetzwerks neu aufzubauen [A Brief History of Kafka, LinkedIn's Messaging Platform]. Wie viele andere Websites wechselte LinkedIn von einer monolithischen Architektur auf eine Architektur mit vernetzten Microservices. Die Einführung einer neuen Architektur basierend auf einer universellen Pipeline, die auf einem dezentralen Commit-Log namens Kafka aufgebaut war, ermöglichte LinkedIn die Verarbeitung von Event-Streams in nahezu Echtzeit und in großem Umfang. LinkedIn-Chefentwickler Jay Kreps wählte den Namen „Kafka“, da es sich um ein System handelte, welches „für das Schreiben optimiert wurde“ und Kreps war stets ein Fan der Werke Franz Kafkas.

Die Hauptmotivation für die Einführung von Kafka bei LinkedIn lag darin, die bestehenden Microservices zu entkoppeln, damit sie sich freier und unabhängig voneinander entwickeln konnten. Zuvor hatte das Datenbankschema oder Kommunikationsprotokoll, das für die Service-übergreifende Kommunikation verwendet wurde, die Koevolution der Services eingeschränkt. Das Infrastruktur-Team bei LinkedIn erkannte die Notwendigkeit einer erhöhten Flexibilität, um eine unabhängige Weiterentwicklung der Services zu gewährleisten. Sie entwarfen Kafka, um die Kommunikation zwischen den Services mithilfe einer asynchronen und nachrichtenbasierten Lösung zu erleichtern. Kafka musste sowohl langlebig (Nachrichten dauerhaft auf Festplatten speichern) als auch resistent gegen Netzwerk- und Knotenausfälle sein, nahezu Echtzeiteigenschaften bieten sowie horizontal skalierbar sein, um für das Wachstum gerüstet zu sein. Kafka erfüllte diese Anforderungen, indem es ein dezentrales Log bereitstellte (siehe The Log: What every software engineer should know about real-time data's unifying abstraction).

Ab dem Jahr 2011  war Kafka als Open-Source-Software verfügbar und wurde von zahlreichen Unternehmen übernommen. Im Vergleich zu vorherigen ähnlichen Message-Queue- oder Pub-Sub-Abstraktionen wie RabbitMQ und HornetQ führte Kafka die folgenden Neuerungen ein:

  • Die Kafka-Topics (Queues) werden partitioniert, um sie über einen Cluster von Kafka-Knoten (die sogenannten Broker) zu skalieren.
  • Kafka verwendet ZooKeeper für die Cluster-Koordination, Hochverfügbarkeit und Ausfallsicherung.
  • Nachrichten werden für sehr lange Zeiträume auf der Festplatte gespeichert.
  • Nachrichten werden der Reihe nach gelesen.
  • Die Consumer behalten ihren eigenen Status bezüglich des Offsets der zuletzt gelesenen Nachricht bei.

Dank dieser Eigenschaften muss der Producer den Status hinsichtlich der Bestätigung jeder einzelnen Nachricht nicht beibehalten. Nachrichten konnten somit in hohem Maße in das Dateisystem gestreamt werden. Da die Consumer für das Beibehalten ihres eigenen Offsets im Topic zuständig sind, konnten Updates und Ausfälle effektiv von ihnen gehandhabt werden.

Apache Storm: Dezentrales Echtzeit-Berechnungssystem

Im Mai 2011 unterzeichnete Nathan Marz einen Vertrag mit Twitter zur Übernahme seiner Firma BackType. Bei BackType handelte es sich um ein Unternehmen, das „Analytics-Produkte herstellte, mit denen Unternehmen ihren Einfluss auf soziale Medien sowohl historisch als auch in Echtzeit nachvollziehen konnten“ [History of Apache Storm and Lessons Learned]. Eines der Vorzeigeprodukte von BackType war ein Echtzeitverarbeitungssystem namens „Storm“. Storm führte eine Abstraktion mit dem Namen „Topology“ ein, mit der Stream-Operationen vereinfacht wurden, ähnlich wie zuvor mithilfe von MapReduce die Stapelverarbeitung großer Datensätze erleichtert wurde. Storm wurde unter dem Beinamen „das Hadoop der Echtzeit“ bekannt und gelangte schnell an die Spitze von GitHub und Hacker News.

Apache Flink: Zustandsorientierte Berechnungen über Daten-Streams

Flink wurde im Mai 2011 erstmals der Öffentlichkeit vorgestellt. Flink geht auf ein Forschungsprojekt namens „Stratosphere“ zurück [http://stratosphere.eu/], das in Zusammenarbeit mit einer Handvoll deutscher Universitäten durchgeführt wurde. Stratosphere wurde mit dem Ziel entwickelt, „die Effizienz der massiv parallelen Datenverarbeitung auf Infrastructure-as-a-Service-Plattformen (IaaS-Plattformen) zu verbessern" [http://www.hpcc.unical.it/hpc2012/pdfs/kao.pdf].

Ebenso wie Storm bietet Flink ein Programmiermodell zur Beschreibung von Datenflüssen (die in der Flink-Sprache als "Jobs" bezeichnet werden), die eine Reihe von Streams und Transformationen enthalten. Flink umfasst eine Ausführungs-Engine, die den Job effektiv parallelisiert und einem verwalteten Cluster zuweist. Eine einmalige Eigenschaft von Flink ist, dass das Programmiermodell sowohl begrenzte als auch unbegrenzte Datenquellen unterstützt. Das bedeutet, dass nur ein minimaler Syntaxunterschied zwischen einem Run-Once-Job besteht, der Daten aus einer SQL-Datenbank bezieht (zuvor wäre dies wohl ein Batch-Job gewesen), und einem Run-Continuously-Job, der mit Streaming-Daten aus einem Kafka-Topic arbeitet. Flink trat im März 2014 in das Apache-Inkubationsprojekt ein und wurde im Dezember 2014 zum Top-Level-Projekt erhoben.

Im Februar 2013 wurde die Alpha-Version von Spark Streaming mit Spark 0.7.0 veröffentlicht. Im September 2013 stellte das LinkedIn-Team sein Framework für die Stream-Verarbeitung „Samza“ quelloffen mit diesem Beitrag bereit.

Im Mai 2014 wurde Spark 1.0.0 veröffentlicht und mit dieser Version wurde Spark SQL erstmalig eingeführt. Obwohl die aktuelle Spark-Version zu diesem Zeitpunkt nur eine Streaming-Funktion bot, die auf der Aufteilung von Datenquellen in "Micro-Batches" basierte, wurden mit dieser Version die Voraussetzungen für die Ausführung von SQL-Abfragen als Streaming-Anwendungen geschaffen.

Apache Beam: Ein einheitliches Programmiermodell für Batch- und Streaming-Jobs

2015 veröffentlichte ein Team von Google-Entwicklern die wissenschaftliche Arbeit The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing. 2014 wurde eine Implementierung des Dataflow-Modells auf der Google Cloud Platform vermarktet. Sowohl das Core-SDK dieser Arbeit als auch mehrere I/O-Konnektoren und ein lokaler Runner wurden an Apache gespendet und im Juni 2016 in die erste Version von Apache Beam umgemünzt.

Einer der Schwerpunkte des Dataflow-Modells (und von Apache Beam) basiert darauf, dass die Darstellung der Pipeline unabhängig von der Wahl der Ausführungs-Engine abstrahiert wird. Zum Zeitpunkt des Schreibens kann Beam denselben Pipeline-Code erstellen, um Flink, Spark, Samza, GearPump, Google Cloud Dataflow und Apex anzusprechen. Infolgedessen haben Benutzer die Möglichkeit, die Ausführungs-Engine zu einem späteren Zeitpunkt weiter zu entwickeln, ohne die Implementierung des Jobs abzuändern. Zum Testen und Entwickeln in der lokalen Umgebung steht außerdem eine „Direct Runner“-Ausführungs-Engine zur Verfügung.

2016 führte das Flink-Team Flink SQL ein. Im August 2017 wurde die Einführung von Kafka SQL angekündigt und im Mai 2019 stellte ein Team bestehend aus Entwicklern von Apache Beam, Apache Calcite und Apache Flink sein Projekt zur Entwicklung einer einheitlichen Streaming-SQL „One SQL to Rule Them All: An Efficient and Syntactically Idiomatic Approach to Management of Streams and Tables“ vor.

Ein Blick in die Zukunft

Die Tools, die den Softwarearchitekten für das Design der Daten-Pipeline zur Verfügung stehen, entwickeln sich mit zunehmender Geschwindigkeit weiter. Workflow-Engines wie Airflow und Prefect integrieren Systeme wie Dask, um Anwendern die Parallelisierung und Zuweisung massiver Machine-Learning-Workloads auf dem Cluster zu ermöglichen. Aufkommende Konkurrenzprodukte wie Apache Pulsar und Pravega kämpfen mit Kafka um die Übernahme der Speicher-Abstraktion des Streams. Des Weiteren beobachten wir, dass Projekte wie Dagster, Kafka Connect und Siddhi bestehende Komponenten integrieren und neue Ansätze zur Visualisierung und zum Design der Daten-Pipeline liefern. Die rasante Weiterentwicklung der Technologien in diesen Bereichen macht die Entwicklung datenintensiver Anwendungen gerade jetzt besonders spannend.

Wenn Sie Interesse daran haben, mit derartigen Technologien zu arbeiten, sollten Sie sich mit uns in Verbindung zu setzten. Wir suchen derzeit Mitarbeiter für zahlreiche Engineering-Positionen an mehreren Standorten.

Nach oben scrollen
Twittern
Teilen
Teilen