Interview mit Davor Bonaci und Jean-Baptiste Onofré

„Apache Beam ist der Klebstoff, der Big-Data-Systeme zusammenhält“

Kypriani Sinaris

Jean-Baptiste Onofré and Davor Bonaci

Apache Beam hat den Inkubator verlassen und ist nun ein neues Top-Level-Projekt bei der Apache Software Foundation. Wir haben mit Davor Bonaci und Jean-Baptiste Onofré von der ASF über Apache Beam, den Weg zum Top-Level-Projekt und die Zukunft des APIs gesprochen.

JAXenter: Was ist die Idee hinter Apache Beam?

Davor Bonaci and Jean-Baptiste Onofré: Apache Beam ist ein Datenverarbeitungssystem, das sich unbegrenzt skalieren lässt. Das einheitliche Programmiermodell und die zugehörigen Software Development Kits (SDKs) ermöglichen es den Usern, ihre Batch- und Streaming-Data-Processing-Pipelines genau zu definieren. Beams Runner ermöglichen es den Usern zudem, diese Pipelines auf vielen Verarbeitungs-Engines auszuführen, wodurch einerseits Portabilität und Future-Proofing ermöglicht und andererseits Lock-ins in Bezug auf Engine, Anbieter und Cloud verhindert werden.

Das Ziel von Apache Beam ist es, das Abstraktionsniveau auf ein höheres Level als das bereits existierender Systeme zu steigern. Ebenfalls ein wichtiger Punkt dabei ist es, die Businesslogik des Users von der darunterliegenden Engine zu entkoppeln. Das wiederum erlaubt es dem Nutzer, seine Businesslogik auf jeder Engine laufen zu lassen.

Das wurde übrigens früher schon so gemacht. Vor zwanzig Jahren waren C/C++ moderne Programmiersprachen, aber die kompilierten Programmdateien konnten nur auf einem einzelnen Betriebssystem ausgeführt werden. Dann kam Java um die Ecke, hob die Abstraktionsebene, führte Bytecode ein und machte es möglich, kompilierte Anwendungen auf unterschiedliche Betriebssysteme zu portieren. Der Erfolg blieb nicht aus und das Konzept wurde für Programmiersprachen wie C#, Python, Scala und vielen anderen adaptiert. Was diese Systeme im Allgemeinen erreicht haben, will Beam in einem sehr engen Bereich nachvollziehen – wir konzentrieren uns ausschließlich auf perfekt-parallele, verteilte Datenverarbeitung.

JAXenter: Erzählt uns bitte ein wenig mehr darüber, was unter der Motorhaube des Projekts steckt: Wie funktioniert Beam?

Davor Bonaci and Jean-Baptiste Onofré: Auf oberster Ebene bietet Beam multiple SDKs. Die User nutzen sie, um ihre eigene Datenverarbeitungs-Pipeline zu konstruieren. Im nächsten Schritt bricht Beam diese Pipeline in individuelle Teile herunter und transformiert sie in eine engine- und (größtenteils) sprachenunabhängige Form. Anschließend wird die Pipeline an einen Runner übertragen, der sie zur weiteren Ausführung auf der gewählten Verarbeitungs-Engine vorbereitet. Auf gewisse Weise ist Beam der Klebstoff, der viele Big-Data-Systeme miteinander verbindet.

Was Java, C#, Scala und Python im generellen Sinn erreicht haben, versucht Beam in einem sehr speziellen zu erreichen.

JAXenter: Könnt ihr einen typischen Use-Case beschreiben, in dem sich die Vorteile Beams zeigen?

Davor Bonaci and Jean-Baptiste Onofré: Apache Beam kann für alle Formen der Datenverarbeitung verwendet werden – von der einfachen Batch-ETL-Pipeline bis zur komplexen Zeit-/Event-basierten Streaming Pipeline. Einige Beispiele dazu sind:

  • Pattern-Erkennung
  • Genom-Analyse
  • Betrugserkennung
  • Echtzeit-Gaming

… praktisch alles, was irgendeine Form der Datenverarbeitung benötigt.

Beams saubere Abstraktionen machen es einfach, derartige Datenverarbeitungs-Pipelines zu entwickeln. Die Ausführung solcher Pipelines auf einem lokalen Rechner, einem lokalen Cluster oder in der Cloud ist so einfach wie das Ausführen eines Befehls ohne Codeänderungen.

JAXenter: Erzählt uns etwas über die Geschichte von Beam. Wie hat das Projekt begonnen?

Davor Bonaci and Jean-Baptiste Onofré: Apache Beam geht auf das ursprüngliche MapReduce-System zurück, das Google 2004 in Form eines Papers veröffentlichte und das die Art und Weise, wie wir verteilte Datenverarbeitung nutzen, grundlegend verändert hat.

Bereits zu diesem Zeitpunkt divergierte die Entwicklung ein wenig. Intern arbeiteten Googles Ingenieure daran, die Kernmethodik weiter zu verfeinern und zu verbessern. Ihre Ergebnisse stellten Ergebnisse sie der breiten Community in wissenschaftlicheren Veröffentlichungen zur Verfügung. Außerhalb von Google erschuf die Open-Source-Community ihre eigene MapReduce-Implementierung für Apache Hadoop. Ein komplettes Ökosystem, das wir alle kennen und lieben, wurde in größten Teilen innerhalb der Apache Software Foundation entwickelt. Im Laufe der Zeit kam es in diesen geschwisterlichen Projekten zu erstaunlichen Innovationen und zu gelegentlichen wechselseitigen Einflüssen.

Apache Beam geht auf das ursprüngliche MapReduce-System zurück.

2014 launchte Google das Projekt Google Cloud Dataflow, das auf Technologien beruhte, die sich aus MapReduce entwickelt hatten. Es beinhaltete allerdings neuere Ideen, wie eine erhöhte Abstraktion und einen Fokus auf das Streaming sowie die Echtzeitausführung, also Konzepte, die man aus FlumeJava bzw. MillWheel kennt. Von Anfang an enthielt Google Cloud Dataflow sowohl ein neues Programmiermodell für das Schreiben von Datenverarbeitungs-Pipelines als auch einen vollständig verwalteten Dienst für deren Ausführung.

2016 spendeten Google und einige Partner dieses Programmiermodell der Apache Software Foundation als Inkubationsprojekt unter dem Namen Apache Beam. Seitdem hat Apache Beam die Inkubation abgeschlossen und ist zu einem neuen Top-Level-Projekt der ASF geworden.

JAXenter: Was sind die zukünftigen Pläne für das Projekt?

Davor Bonaci and Jean-Baptiste Onofré: Wir arbeiten an der Verbesserung der „End-to-End“ User Experience, um eine reibungslose Portabilität, die „einfach funktioniert“, garantieren zu können. Die Java-Community prägte den Satz „write once, run anywhere“, aber es dauerte eine Weile, bis das wirklich umgesetzt werden konnte. Ähnlich könnte es auch Beam ergehen.

Neben dem Polieren der UX wäre der nächste Meilenstein für das Projekt die Veröffentlichung einer ersten Version mit Abwärtskompabilität. Damit wäre es für den Einsatz in Unternehmen bereit.

Im Bezug auf Funktionalität planen wir, das Kernmodell weiterzuentwickeln und aus noch komplexeren Datenverarbeitungsmustern einfache und portable Abstraktionen abzuleiten. Zu guter Letzt wollen wir unsere Fähigkeit, mit verwandten Systemen und Communities zu kommunizieren, ausbauen. Einige Beispiele dafür sind:

  • Neue SDKs, wie z.B. Python
  • Neue DSLs, wie z.B. Scala oder SQL
  • Neue IOs, die unsere Fähigkeit, Daten von/auf mehreren Speicher-/Nachrichtensystemen zu lesen/schreiben, verbessert
  • Neue Runner, etwa Apache Gearpump (im Inkubator)

Mit diesem Ansatz wird Beam seiner Vision, jede Datenverarbeitungslogik auf jeder Engine laufen zu lassen, näher kommen.

JAXenter: Vielen Dank für das Interview!

Geschrieben von
Kypriani Sinaris
Kypriani Sinaris
Kypriani Sinaris studierte Kognitive Linguistik an der Goethe Universität Frankfurt am Main. Seit 2015 ist sie Redakteurin bei JAXenter und dem Java Magazin.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.