Stream Processing - Datenverarbeitung
Auf dem Weg zum Framework für Unified Data Processing
Ververcia erläutert Potentiale von Apache Flink
Das Apache Flink-Projekt verfolgt seit jeher einen einheitlichen Ansatz für die Batch- und Stream-Datenverarbeitung, der auf dem Kernparadigma der „kontinuierlichen Verarbeitung unbegrenzter Datenströme“ aufbaut. Wenn man darüber nachdenkt, passt die Offline-Verarbeitung von gebundenen Datensätzen natürlich zum Paradigma: Das sind nur Datenströme, die aufgezeichnet wurden und irgendwann enden.
Fabian Hüske, Software Engineer bei Ververica (vormals data Artisans), analysiert den Status Quo des Stream Processings und erläutert die Perspektive der Entwicklung hin zum Framework für Unified Data Processing. Es gibt neben Apache Flink andere Projekte in der Open-Source-Community, die „Streaming first, with batch as a special case of streaming“ umfassen, wie z.B. Apache Beam. Diese Philosophie wird oft als eine leistungsfähige Möglichkeit zitiert, die Komplexität von Dateninfrastrukturen durch den Aufbau von Datenanwendungen für Echtzeit- und Offline-Verarbeitung erheblich zu reduzieren.
Warum gibt es noch Batch-Prozessoren?
Die Möglichkeit, Batch als Sonderfall des Streamings zu verarbeiten, bedeutet nicht, dass jeder Stream-Prozessor jetzt das richtige Werkzeug für Anwendungsfälle der Batch-Verarbeitung ist oder dass Batch-Prozessoren obsolet geworden sind.
- Reine Stream-Verarbeitungssysteme sind ineffizient und langsam bei Batch-Verarbeitungs-Workloads. Niemand würde es für eine gute Idee halten, einen Stream-Prozessor zu verwenden, der Daten aus einer Nachrichtenwarteschlange aufnimmt, um große Mengen an statischen Daten zu analysieren.
- Unified APIs delegieren oft an unterschiedliche Laufzeiten, je nachdem, ob die Daten kontinuierlich oder gebunden sind. So sind beispielsweise die Implementierungen der Batch- und Streaming-Laufzeit von Google Cloud Dataflow unterschiedlich, um die gewünschte Leistung und Belastbarkeit für jeden Fall zu gewährleisten.
- Apache Flink verfügt über eine Streaming-API, die beschränkte und unbeschränkte Anwendungsfälle ausführen kann, bietet aber dennoch eine separate DataSet-API und einen Runtime-Stack, der für Batch-Anwendungsfälle schneller ist.
Bedeutet dies dann, dass das grundlegende Paradigma einer einheitlichen API für Batch- und Streaming-Datenverarbeitung offensichtlich falsch ist? Die Antwort ist nach Meinung von Fabian Hüske einfach: Es ist nichts falsch daran. Während die Batch-Prozessoren jedoch für diesen speziellen Zweck entwickelt wurden, bedeutet die wettbewerbsfähige Handhabung von Anwendungsfällen der Batch-Verarbeitung in einer einheitlichen Laufzeit, dass bestimmte Merkmale dieses „Sonderfalls“ genutzt werden müssen.
Batch zusätzlich zu einer Streaming-Laufzeit
Als die ursprünglichen Entwickler von Flink haben wir immer geglaubt, dass es möglich ist, eine Laufzeit zu haben, die dem neuesten Stand der Technik für die Stream-Verarbeitung und die Batch-Verarbeitung von Anwendungsfällen gleichzeitig entspricht; eine Laufzeit, die „Streaming first“ gerecht wird, aber genau die richtige Menge an speziellen Eigenschaften von gebundenen Streams nutzen kann, um für Batch-Anwendungsfälle genauso schnell zu sein wie dedizierte Batch-Prozessoren.
Dies ist der einzigartige Ansatz von Apache Flink: ein 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.
Aber… was fehlt noch?
„Obwohl wir im Laufe der Jahre bedeutende Fortschritte gemacht haben, müssen wir noch einige Schritte unternehmen, um Flink zu einem System für eine wirklich einheitliche, hochmoderne Stream- und Batch-Verarbeitung zu entwickeln“, erklärt Fabian Hüske von Ververica. „Wir werden einige weitere Verbesserungen einführen, darunter die folgenden Funktionen, die für die Verwirklichung unserer Vision entscheidend sind.“ Dazu gehören:
Ein wirklich 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.
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.
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. Wir planen, 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.
Präsentation von Blink
Blink ist ein Teil von Apache Flink, der ursprünglich in Alibaba entwickelt wurde, um das Verhalten des Frameworks für interne Anwendungsfälle zu verbessern. Vor kurzem hat Alibaba Blink zurück in das Apache Flink-Projekt eingebracht. Blink fügt eine Reihe von bedeutenden Verbesserungen und Integrationen hinzu. Viele davon überschneiden sich mit den oben genannten Funktionen als Schlüssel für ein einheitliches Streaming- und Batch-System. Angesichts der Vielzahl von Änderungen, die mit Blink vorgenommen wurden, hat die Community einen Fusionsplan erstellt, um eine reibungslose, unterbrechungsfreie Integration des bereitgestellten Codes zu gewährleisten. Dieser Plan konzentriert sich zunächst auf die Verbesserung der Batch-Verarbeitungsfunktionen von Flink, wenn man bedenkt, dass der SQL-Abfrageprozessor die Komponente ist, die sich im Vergleich zum neuesten Flink-Masterzweig am meisten entwickelt hat.
Einheitliche Stream-Operatoren
Blink erweitert das Flink-Streaming-Runtime-Operator-Modell, um selektives Lesen von verschiedenen Eingaben zu unterstützen, während das Push-Modell für eine sehr geringe Latenzzeit beibehalten wird. Diese Kontrolle über die Eingaben hilft nun, Algorithmen wie Hybrid-Hash Joins auf dem gleichen Operator- und Threading-Modell zu unterstützen, wie kontinuierliche symmetrische Joins über RocksDB, und bildet die Grundlage für zukünftige Features wie „Side Inputs“.
Tabellen-API und SQL-Suchabfrage-Prozessor
Während Flink Abfragen entweder in DataSet- oder DataStream-Programme übersetzt, je nach den Eigenschaften ihrer Eingaben, übersetzt Blink Abfragen in einen Datenfluss von Stream-Operatoren. Diese Stream-Operatoren sind aggressiver verkettet, und die gemeinsamen Datenstrukturen – Sorter, Hash-Tabellen – und Serialisierer werden erweitert, um noch weiter zu gehen, indem sie mit binären Daten arbeiten und Serialisierungs-Overhead sparen. Darüber hinaus werden dem SQL-Abfrageoptimierer eine größere Auswahl an Laufzeitoperatoren für gängige SQL-Operationen, wie Semi- und Anti-Join, und viele weitere Optimierungsregeln hinzugefügt, einschließlich, aber nicht beschränkt auf die Neuordnung von Joins.
Verbesserte Planung und Fehlerbehebung
Blink implementiert mehrere Verbesserungen für die Aufgabenplanung und Fehlertoleranz. Die Planungsstrategien nutzen die Ressourcen besser, indem sie die Verarbeitung der Eingabedaten durch die Bediener nutzen. Die Failover-Strategien werden entlang der Grenzen von persistenten Shuffles feinkörniger. Ein ausgefallener JobManager kann ersetzt werden, ohne eine laufende Anwendung neu zu starten. Das Open-Source-Projekt, das von Alibabas Beitrag von Blink profitiert, unternimmt den nächsten Schritt beim Aufbau einer einheitlichen Laufzeit und auf dem Weg zu einem Stream-Prozessor, der in der Lage ist, sich mit dedizierten Batch-Verarbeitungssystemen zu messen: Online Analytical Processing (OLAP) und SQL.
„Mit seiner Fähigkeit, Stapelverarbeitung, Echtzeit-Datenverarbeitung und ereignisgesteuerte Anwendungen auf genau die gleiche Weise zu modellieren und gleichzeitig hohe Leistung und Konsistenz zu bieten, glauben wir, dass die Stream-Verarbeitung mit Apache Flink die Grundlage für den Data Processing Stack der Zukunft sein wird“, fasst Fabian Hüske von Ververica abschließend zusammen.
