Kommentar von Fabian Hüske, Ververica

Stateful Stream Processing mit Apache Flink

| Autor / Redakteur: Fabian Hüske / Nico Litzel

Der Autor: Fabian Hüske ist Software Engineer bei Ververica , Apache-Flink-PMC-Mitglied, Member of the ASF & Autor bei O'Reilly.
Der Autor: Fabian Hüske ist Software Engineer bei Ververica , Apache-Flink-PMC-Mitglied, Member of the ASF & Autor bei O'Reilly. (Bild: Ververica)

Apache Flink ist für typische Geschäftsanwendungen gedacht, die bestimmte Geschäftslogiken auf kontinuierliche Datenflüsse in Echtzeit anwenden.

Der Einsatz von Stream Processing, also Stream-Verarbeitung, nimmt rasant zu und dehnt sich mit zunehmender Reife der Technologie auf immer mehr Anwendungsfälle aus. Während in der Anfangszeit Stream-Processing zur Berechnung von ungefähren Aggregaten verwendet wurden, sind die heutigen Lösungen in der Lage, präzise Analyseapplikationen zu betreiben und komplexe Geschäftslogik in Hochdurchsatz-Streams zu bewerten. Einer der wichtigsten Aspekte der Stream-Verarbeitung ist die Zustandsbehandlung, also die Erinnerung an vergangene Eingaben und deren Verwendung zur Beeinflussung der Verarbeitung zukünftiger Eingaben.

Grundlagen von Apache Flink

Apache Flink ist ein verteilter Datenprozessor, der speziell entwickelt wurde, um zustandsabhängige Berechnungen über Datenströme auszuführen. Die Laufzeit ist optimiert für die Verarbeitung unbegrenzter Datenströme sowie begrenzter Datensätze beliebiger Größe. Flink ist in der Lage, Berechnungen auf Tausende von Kernen zu skalieren und damit Datenströme mit hohem Durchsatz bei geringer Latenzzeit zu verarbeiten. Flink-Anwendungen können für Ressourcenmanager wie Hadoop YARN, Apache Mesos und Kubernetes oder für eigenständige Flink-Cluster bereitgestellt werden.

Fehlertoleranz ist ein sehr wichtiger Aspekt von Flink, wie bei jedem verteilten System. Flink kann in einem hochverfügbaren Modus ohne Single Point of Failure arbeiten und zustandsbehaftete (Stateful) Anwendungen aus Fehlern mit genau einmaligen Zustandskonsistenzgarantien wiederherstellen. Darüber hinaus bietet Flink viele Funktionen, um die betrieblichen Aspekte der laufenden Stream-Processing-Anwendungen in der Produktion zu erleichtern. Es lässt sich problemlos in die bestehende Protokollierungs- und Metrik-Infrastruktur integrieren und bietet eine REST-API zum Senden und Steuern laufender Anwendungen.

Flink bietet mehrere APIs mit unterschiedlichen Kompromissen für Aussagekraft und Prägnanz bei der Implementierung von Stream-Processing-Anwendungen. Die DataStream-API ist die Basis-API und bietet bekannte Primitive, die in anderen datenparallelen Verarbeitungs-Frameworks wie map, flatMap, split und union zu finden sind. Diese Primitive werden durch gängige Stream-Processing-Operationen ergänzt, wie z. B. Windowed-Aggregationen, Joins und einen Operator für asynchrone Anfragen an externe Datenspeicher.

Präzise Kontrolle über Zustand und Zeit

Die ProcessFunctions von Flink sind Low-Level-Schnittstellen, die eine präzise Kontrolle über Zustand und Zeit ermöglichen. So kann beispielsweise eine ProcessFunction implementiert werden, um jedes empfangene Ereignis in seinem Zustand zu speichern und einen Timer für einen zukünftigen Zeitpunkt zu registrieren. Später, wenn der Timer ausgelöst wird, kann die Funktion das Ereignis und möglicherweise andere Ereignisse aus seinem Zustand abrufen, um eine Berechnung durchzuführen und ein Ergebnis auszugeben. Diese feinkörnige Steuerung von Zustand und Zeit ermöglicht ein breites Anwendungsspektrum.

Schließlich bieten die SQL-Unterstützung und die Tabellen-API von Flink deklarative Schnittstellen zur Spezifikation einheitlicher Abfragen gegen Streaming- und Batch-Quellen. Dies bedeutet, dass die gleiche Abfrage mit der gleichen Semantik auf einem begrenzten Datensatz und einem Strom von Echtzeitereignissen ausgeführt werden kann. Sowohl ProcessFunctions als auch SQL-Abfragen können nahtlos in die DataStream-API integriert werden, was dem Entwickler maximale Flexibilität bei der Auswahl der richtigen API bietet.

Zusätzlich zu den Kern-APIs, verfügt Flink über domainspezifische Bibliotheken für die Grafikverarbeitung und Analytik, sowie für die komplexe Ereignisverarbeitung (CEP). Die CEP-Bibliothek von Flink bietet eine API zur Definition und Auswertung von Mustern auf Ereignisströmen. Diese Muster-API kann verwendet werden, um Prozesse zu überwachen oder Alarme bei unerwarteten Ereignisabläufen auszulösen.

Streaming-Anwendungen laufen nie als isolierte Dienste. Stattdessen müssen sie Ereignisströme aufnehmen und typischerweise auch ausstrahlen. Apache Flink bietet eine umfangreiche Bibliothek von Konnektoren für die am häufigsten verwendeten Stream- und Speichersysteme. Anwendungen können Streams von Apache Kafka und Amazon Kinesis aufnehmen oder veröffentlichen. Streams können auch durch das Lesen von Dateien aufgenommen werden, wie sie in Verzeichnissen erscheinen, oder durch das Schreiben von Ereignissen in Buckleted-Dateien persistiert werden. Flink unterstützt eine Reihe verschiedener Dateisysteme, darunter HDFS, S3 und NFS. Darüber hinaus können Flink-Anwendungen Daten über JDBC „versenken“ (d. h., in eine relationale Datenbank exportieren) oder in Apache Cassandra und Elasticsearch einfügen.

Auf dem Weg zum Framework für Unified Data Processing

Der einzigartige Ansatz von Apache Flink entspricht einem Network Stack, der sowohl Streaming-Datenaustausch mit niedriger Latenz und hohem Durchsatz als auch Batch-Shuffles mit hohem Durchsatz unterstützt. Obwohl Flink über Streaming-Laufzeitoperatoren verfügt, um kontinuierlich unbegrenzte Daten zu verarbeiten, gibt es auch spezialisierte Operatoren für beschränkte Eingaben, die bei der Auswahl der DataSet-API oder der Batch-Umgebung in der Tabellen-API verwendet werden. Aus diesem Grund hat Flink von Anfang an eine ziemlich beeindruckende Batch-Verarbeitungsleistung gezeigt.

Obwohl Flink im Laufe der Jahre bedeutende Fortschritte gemacht hat, sind noch einige Schritte erforderlich, um Flink zu einem System für eine wirklich einheitliche, hochmoderne Stream- und Batch-Verarbeitung zu entwickeln. Hierzu sollen einige weitere Verbesserungen eingeführt werden, darunter die folgenden Funktionen:

  • Ein einheitlicher Runtime-Operator-Stack. Derzeit haben die gebundenen und unbegrenzten Operatoren ein anderes Datenkonsum- und Threading-Modell und mischen sich nicht. In einem einheitlichen Stapel bilden Streaming-Operatoren die Grundlage. Diese erfassen kontinuierlich Daten von allen Eingaben, um sicherzustellen, dass die Verarbeitungslatenzen gering sind. Wird jedoch mit begrenzten Daten gearbeitet, kann die API oder der SQL-Abfrageoptimierer auch Operatoren auswählen, die für einen hohen Durchsatz und keine geringe Latenzzeit optimiert sind. Der Optimierer kann beispielsweise einen Hybrid-Hash-Join-Operator auswählen, der zuerst einen (begrenzten) Eingangsstrom vollständig verbraucht, bevor er den zweiten Eingangsstrom liest.
  • Die Nutzung von gebundenen Streams zur Reduzierung des Umfangs der Fehlertoleranz. Bei der Begrenzung von Eingangsdaten ist es möglich, Daten während des Shuffles (im Speicher oder auf der Festplatte) vollständig zu puffern und im Fehlerfall wiederzugeben. Die Pufferung von gemischten Daten macht die Wiederherstellung feinkörniger und damit wesentlich effizienter.
  • Die Nutzung der Eigenschaften von Stream-Operatoren für das Scheduling. Per Definition erfordert eine kontinuierliche, grenzenlose Streaming-Anwendung alle Bediener, die gleichzeitig arbeiten. Eine Anwendung mit begrenzten Daten kann Operationen nacheinander planen, je nachdem, wie die Operatoren Daten konsumieren, zum Beispiel: zuerst eine Hash-Tabelle aus einer Eingabe erstellen, dann die Hash-Tabelle aus der anderen Eingabe untersuchen. Eine intelligente Planung der Operatoren kann die Ressourcenauslastung und -effizienz deutlich verbessern.
  • Subsumieren der DataSet-API durch die DataStream-API. Die DataStream-API wird um das Konzept der Bounded Streams und Operationen erweitert, die die DataSet-API vollständig umfassen. Geplant ist, die DataSet-API zu verwerfen und schließlich zu entfernen.
  • Verbesserung der Performance und Abdeckung von Batch-SQL. SQL ist die De-facto-Standard-Datensprache. Um mit den besten Batch-Engines konkurrenzfähig zu sein, muss Flink mehr SQL-Funktionen und eine bessere Ausführungsleistung der Abfragen abdecken. Während die Kerndatenebene in Flink bereits sehr effizient ist, hängt die Geschwindigkeit der SQL-Ausführung letztendlich auch vom Query Optimizer, einer leistungsfähigen Operator-Implementierung und einer effizienten Code-Generierung ab

Bereits heute etabliert – mit Potenzial für die Zukunft

Mit Flink werden heute bereits geschäftskritische Anwendungen in vielen Unternehmen auf der ganzen Welt betrieben – und in vielen Branchen wie E-Commerce, Telekommunikation, Finanzen, Spiele und Unterhaltung. Benutzer berichten über Anwendungen, die auf Tausenden von Kernen laufen, einen Zustand in Terabyte-Größenordnung pflegen und Milliarden von Ereignissen pro Tag verarbeiten. Die Open-Source-Community, die Flink entwickelt, wächst kontinuierlich und gewinnt laufend neue Nutzer.

Dies zeigt: Apache Flink ist heute schon etabliert, wenn es um anspruchsvolle Anwendungsszenarien geht. Stream-Processing-Experten sehen daher großes Potenzial für die Zukunft. Flink hat die Fähigkeit, Stapelverarbeitung, Echtzeit-Datenverarbeitung und ereignisgesteuerte Anwendungen auf genau die gleiche Weise zu modellieren und gleichzeitig hohe Leistung und Konsistenz zu bieten. Alles deutet darauf hin, dass die Stream-Verarbeitung mit Apache Flink die Grundlage für den Data Processing Stack der Zukunft sein wird.

Ergänzendes zum Thema
 
Buchtipp

Kommentare werden geladen....

Kommentar zu diesem Artikel abgeben

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 46128765 / Infrastruktur)