Datenverarbeitung: Apache Flink 1.13 skaliert automatisch und sucht Datenstaus

Das Stream-Processing-Framework passt beim Reactive Scaling die parallele Verarbeitung selbsttätig den verfügbaren Ressourcen an.

In Pocket speichern vorlesen Druckansicht
Eichhörnchen

(Bild: Elli Stattaus, gemeinfrei (Creative Commons CC0))

Lesezeit: 3 Min.

Das Team hinter Apache Flink hat Version 1.13 des Frameworks zur Verarbeitung von Datenströmen freigegeben. Das Release bietet ein automatisiertes Ressourcenmanagement für den langfristigen Betrieb von Apache Flink im Cluster. Außerdem erweitert es die Performanceanalyse zum Auffinden von Rückstaus bei der Datenverarbeitung.

Version ein 1.13 führt einen reaktiven Skalierungsmodus ein, der das Ressourcenmanagement abstrahiert. Bei der bisher üblichen aktiven Skalierung setzen Admins die Flink-Anwendung über Orchestratoren wie Kubernetes auf, worauf Flink die verfügbaren Ressourcen aktiv verwaltet und die sogenannten Worker zur Datenverarbeitung passend bereitstellt. Die Applikation passt sich den Anforderungen an, was vor allem für Batch-Jobs oder SQL-Abfragen sinnvoll ist, bei denen jeweils für kurze Zeit möglichst viele Ressourcen bereitstehen sollen. Grundlegend bestimmt die Anforderung nach Parallelverarbeitung die Zahl der angeforderten Worker.

Die reaktive Skalierung zielt vor allem auf lange laufende Anwendungen wie die dauerhafte Verarbeitung von Datenströmen. Hierbei erhält jeder Job alle Ressourcen, die im Cluster zur Verfügung stehen, und Flink nutzt stets die maximal mögliche parallele Verarbeitung. Hierbei bestimmt somit die Zahl der bereitstehenden Worker den Grad der parallelen Ausführung. Wenn Flink neue Ressourcen im Cluster bekommt oder welche abgeben muss, startet es den Job ab dem letzten Checkpoint neu. Im reaktiven Modus kann ein externer Service die Metriken wie CPU-Auslastung oder Verzögerungen überwachen und die Ressourcen nach Bedarf bereitstellen.

Das Team hat zudem die Performance-Monitoring-Funktionen erweitert. Das aktuelle Release soll vor allem das Auffinden von Rückstaus im System vereinfachen und führt dafür mit dem sogenannten Task Mailbox Timing eine neue Metrik ein. Auf die Weise sollen sich Engpässe leichter aufspüren lassen, die dort auftreten, wo Teile der Verarbeitungspipeline so stark ausgelastet sind, dass sie einen Rückstau verursachen. Zusätzlich bringt das Release eine neue grafische Darstellung der Verarbeitungsprozesse in der Pipeline mit, die unterschiedliche Farben für die Auslastung und Rückstaus verwendet.

Flink 1.3 nutzt unterschiedliche Farben zum Visualisierung der Auslastung der einzelnen Operatoren in der Verarbeitungspipeline.

(Bild: Apache)

Außerdem bietet Flink 1.3 eine Flame-Graph-Darstellung, um die Auslastung der CPU für die besonders beschäftigten Operatoren zu visualisieren. Auf die Weise lässt sich erkennen, welche Methoden besonders viele Ressourcen benötigen und welche Aufrufe im Stack die betroffenen Methoden nutzen.

Flink von Berlin nach China

(Bild: Apache Software Foundation)

Das Projekt mit dem Eichhörnchen als Maskottchen hat seine Ursprünge in der deutschen Hauptstadt. Es entstand 2010 im Rahmen des Stratosphere-Forschungsprojekt an der TU Berlin, der Humboldt-Universtät zu Berlin und dem Hasso-Plattner-Institut in Potsdam.

Seit 2014 ist das Projekt unter dem Dach der Apache Software Foundation aufgestellt, wo es Anfang 2015 zum Top-Level-Projekt aufgestiegen ist. 2016 erschien Version 1.0 des Stream-Processing-Frameworks, das unter anderem bei Netflix und Uber zum Einsatz kommt.

Einige Flink-Projektbeteiligte haben 2014 das Start-up data Artisans gegründet, das seit 2019 eine Tochter von Alibaba ist. Kurz nach der Übernahme durch den chinesischen Cloud-Anbieter änderte data Artisans seinen Namen in Ververica.

Weitere Neuerungen in Flink 1.13 lassen sich der offiziellen Ankündigung entnehmen. Demnach haben insgesamt 200 Personen zum aktuellen Release beigetragen und zusammen 1000 Issues bearbeitet. Die Software steht auf der Download-Seite bereit, und der Sourcecode findet sich auf GitHub.

(rme)