Über unsMediaKontaktImpressum
Fabian Hueske 10. September 2019

Anwendungen von Apache Flink und Ausblick in die Zukunft

Stream Processing mit Apache Flink entwickelt sich zur Grundlage für den Data Processing Stack der Zukunft. Mit Flink werden heute bereits geschäftskritische Anwendungen in vielen Unternehmen auf der ganzen Welt betrieben – in Branchen wie E-Commerce, Telekommunikation, Finanzen, Spiele und Unterhaltung. Benutzer berichten über Anwendungen, die auf Tausenden von Kernen laufen, Zustandsgrößen im Terabyte-Bereich bewältigen und Milliarden von Ereignissen pro Tag verarbeiten. Die Open-Source-Community, die Flink entwickelt, wächst kontinuierlich und gewinnt neue Nutzer. Drei bedeutende Anwendungsbeispiele verdeutlichen das Potenzial von Apache Flink – aktuell und mit Blick auf die Zukunft.

Apache Flink unterstützt Airbus bei der Umsetzung eines Echtzeit-Big-Data-Projekts

Angesichts neuer Anforderungen der Internationalen Zivilluftfahrt-Organisation (ICAO) und des wachsenden Luftverkehrsaufkommens benötigen die Beteiligten in der Luftfahrt zunehmend eine Echtzeitanalyse auf globaler Ebene, die effektive Entscheidungen unterstützt. Das Flugdaten-Analysesystem AirSense von Airbus verarbeitet mehr als 2.000 Nachrichten pro Sekunde von Flugzeugen rund um den Globus. Es nutzt Microsoft Azure Managed Services wie Event Hubs und Azure Managed Kubernetes sowie Open-Source-Technologien – wie eben Apache Flink. Flink bietet die Möglichkeit, Ausfälle besser zu handhaben, ohne den gesamten Zustand wiederholen zu müssen. Das Flink-Cluster mit dem Kubernetes-Dienst zu betreiben, ist der empfohlene Lösungsweg der ursprünglichen Entwickler von Apache Flink.

Mitte 2018 hat Airbus Defence and Space mit AirSense eine fortschrittliche Analyselösung auf den Markt gebracht, die Multi-Source-Überwachungsdaten nutzt, die auf globalen ADS-B-Daten (Automatic Dependent Surveillance Broadcast) basieren. AirSense wird gespeist von verschiedenen Daten-Feeds für Flugzeugpositionen und bringt Daten aus mehreren Quellen in Echtzeit zusammen. Die Menge und Größe der Daten, mit denen Airbus zu tun hat, die sehr hohe Anzahl der pro Sekunde recherchierten Nachrichten und auch die daraus zu extrahierenden Analysen sind sehr anspruchsvolle Aufgaben. Hier kommen Mustererkennung, maschinelles Lernen und viele fortschrittliche Analyseapplikationen zum Einsatz.

Derzeit bedient Airbus die gesamte Luftfahrtindustrie und den gesamten Luftverkehrsbereich mit rund 56.000 Strecken weltweit, auf denen rund 3,6 Milliarden Passagiere befördert werden. Airbus muss seine Flugzeuge in der Luft halten, insgesamt 69 Millionen Flugstunden pro Jahr. Aus diesen Flugbewegungen stammen die riesigen Mengen an Daten, mit denen Airbus arbeitet, woraus einige Herausforderungen resultieren. So sendet ein Flugzeug sein Signal mindestens zweimal pro Sekunde. Insgesamt wird das Datenvolumen aus 10.000 bis 15.000 Flügen generiert, die zu einem bestimmten Zeitpunkt durchgeführt werden. Das gesamte weltweit verfügbare Nachrichtenvolumen beträgt also 24.000 Nachrichten pro Sekunde. Da immer mehr Flugzeuge eingesetzt werden, steigt die Zahl der Nachrichten kontinuierlich.

Airbus AirSense nutzt mehrere Datenanbieter und muss alle diese Daten sinnvoll zusammenfassen. Die Daten müssen verarbeitet und Datenfehler herausgefiltert werden. Hierbei verwendet Airbus einige interne Modelle zur Verbesserung der Datenqualität und funktionsspezifische Modelle, um beispielsweise den Treibstoffverbrauch zu bestimmen – Daten, die für Analysten relevant sind. Am Ende müssen Informationen an die Kunden verteilt werden, ebenso in Echtzeit und im Umfang von Tausenden von Nachrichten pro Sekunde.

"Wir erhalten etwa 2.000 Nachrichten pro Sekunde von einem unserer Datenlieferanten. Hierzu haben wir eine Datenpipeline aufgebaut, über die AirSense rund zwei Milliarden Ereignisse pro Tag – mit einem Datenvolumen von 100 Gigabyte – in Echtzeit verarbeitet und analysiert. Das ist eine immense Big-Data-Herausforderung. Wir benötigen die entsprechenden Tools und müssen über das nötige Engineering verfügen, um diese Datenmengen bewältigen zu können. Unsere Mission ist es, das Reiseerlebnis für Endkunden zu verbessern und die verfügbaren Ressourcen weltweit besser zu nutzen. Wir wollen Engpässe beheben, die Luftfahrt sicher halten, die Umweltauswirkungen reduzieren und insgesamt eine bessere Leistung erbringen. Das ist die Chance, die wir mit diesem Projekt haben", erklärte Heiko Udluft, Data Scientist & Digital Product Development Tech-Team Lead, Airbus AirSense.

Es gibt verschiedene Möglichkeiten, diese Daten zu verarbeiten. Airbus AirSense hat sich für Apache Flink entschieden. Die Daten werden von Ereignis-Hubs kommend, in Echtzeit mit Flink verarbeitet. Diese Art der Verarbeitung ist wichtig, denn nur so können die erforderlichen Analysen durchgeführt werden. Echtzeit-Analysen in großem Maßstab sind sehr anspruchsvoll, weil es auf Zustandsvollständigkeit und Echtzeit-Shuffle-Ausgänge ankommt.

Udluft fügt hinzu: "Für die Batch-Verarbeitung ist Apache Spark ein guter Weg, aber sobald die Dinge in Echtzeit erledigt werden müssen und Echtzeitanforderungen gestellt werden, denken wir, dass Flink ein wesentlich besserer Weg ist. So ist die Latenzzeit für uns wirklich entscheidend und wichtig. Apache Flink liefert unserer Ansicht nach die beste Stateful-Unterstützung, die sehr anspruchsvoll ist und uns auch die Möglichkeit bietet, Abfragen zu stellen. Wir können tatsächlich einen Zustand abfragen und eine Antwort erhalten, was für uns überaus interessant ist."

Stream-Verarbeitung mit hoher Kardinalität und großem Zustand bei Klaviyo

Klaviyo, Anbieter einer Marketingautomatisierungs- und E-Mail-Plattform für E-Commerce, hat auf der Flink Forward San Francisco 2019 kürzlich seinen Anwendungsfall von Apache Flink vorgestellt. Das Entwicklungsteam nutzt Apache Flink, um das Echtzeit-Analytiksystem des Unternehmens zu skalieren, das über eine Million Ereignisse dedupliziert und über eine Million Zähler pro Sekunde mit Kardinalität im Milliardenbereich aktualisiert. Klaviyo ist ein datengesteuertes Unternehmen mit der Mission, E-Commerce-Marken dabei zu unterstützen, schneller zu wachsen. Das Herzstück des Lösungsportfolios ist Klaviyos Analyseplattform, die täglich Milliarden von Ereignissen aufnimmt und in nahezu Echtzeit verarbeitet. Heute bewältigt Klaviyo Tausende von Ereignistypen mit einer Geschwindigkeit von fast 100.000 pro Sekunde für mehr als 200.000 Anwenderunternehmen.

Einige der technischen Herausforderungen, denen sich das Entwicklungsteam stellen musste, waren die folgenden:

  • Mit über einer Milliarde Benutzerprofilen erhöht sich die Datensatzgröße (Kardinalität) des Systems erheblich.
  • Die Plattform hält den großen Zustand – mehr als 1,5 TB – aufrecht, hauptsächlich für die Erkennung von Duplikaten.
  • Es liegt ein sehr hohes Fan-Out-Verhältnis vor, von einer bis zu Hunderten von Dimensionen für ein einziges Ereignis.
  • Aufgrund der bereits erwähnten hohen Kardinalität und Fan-Out-Raten müssen Millionen von Ereignissen pro Sekunde aggregiert werden.

Während der Evaluierungsphase erprobte das Team die gängigen Stream-Processing-Technologien, darunter unter anderem Apache Spark, Apache Storm, Apache Flink und In-Memory DB, z.B. VoltDB. Flink wurde wegen seiner einzigartigen Kombination von Attributen gewählt:

  1. Stateful: Die Fähigkeit des Frameworks, den Zustand intern effizient zu verwalten, ist für den Erfolg unerlässlich, da das externe Zustandsmanagement die Hauptursache für die Nicht-Idempotenz des Workloads ist.
  2. Hochverfügbar:  Wenn das Aggregationssystem nicht verfügbar ist, betrifft es alle Produkte und Kunden von Klaviyo. Das Streaming-Framework muss ausfallsicher sein.
  3. Einfach zu skalieren:  Die Aufnahmelast von Klaviyo variiert stark im Laufe des normalen täglichen Betriebs sowie bei großen Ereignissen. Zum Beispiel nimmt während des Black Friday das gesamte Ereignis mehr als das Dreifache auf und es kommt zu Spitzen von über dem 10-Fachen der vorherigen Höchststände. Es ist von entscheidender Bedeutung, dass das Framework es ermöglicht, leicht zu skalieren. Für Klaviyo hat die Skalierbarkeit zwei wesentliche Aspekte. Eine davon ist die Skalierbarkeit in Bezug auf Durchsatz. Der Systemdurchsatz sollte durch einfaches Hinzufügen weiterer Knoten leicht erhöht werden können. Ein weiterer ebenso wichtiger Aspekt ist die Skalierbarkeit der Datenspeicherung. Es sollte trivial sein, die Datenmenge, die das System speichern kann, zu erhöhen.
  4. Echtzeit:  Nachfolgende Aufgaben beruhen darauf, dass die Aufnahme von Ereignissen innerhalb einer Sekunde erfolgt, um genaue Geschäftslogik-Aktionen wie Segmentierung und Flow Sending durchzuführen.

Flink war die einzige Technologie, die die Attribute besaß, die Klaviyo in einem Framework benötigte. Hinzu kam, dass die Flink-Community schnell wuchs und die Dokumentation der Software hinreichend detailliert war. Um die Herausforderungen der ersten Version des Echtzeit-Ereignisaggregationssystems bei Klaviyo wirklich zu meistern, haben sich die Entwickler entschieden, es in eine moderne Streaming-Anwendung namens Abacus umzuwandeln, die Apache Flink als Core-Stream-Processing-Framework nutzt.

Abacus wurde in zwei Iterationen erstellt; die erste konzentrierte sich auf die Aggregation von Ereignissen und das Schreiben von Deltas in eine Datenbank, während Cassandra weiterhin den oben erwähnten Zählerdatentyp verwendet, um bestehende Datenspeicher und APIs zu nutzen. Die zweite Iteration aggregiert die Endzählungen und setzt die Ergebnisse in Cassandra (oder einer anderen verteilten Datenbank) fort. Die zweite Iteration beinhaltet das Redesign der API-Schicht zur Abfrage von Daten und die Migration aller historischen Daten in das neue System. Nach dieser zweiten Iteration hat sich das Entwicklerteam dann von Cassandras Zählerdatentyp entfernt.

Um Abacus mit den Leistungserwartungen des spezifischen Workloads bei Klaviyo in Einklang zu bringen, haben die Entwickler eine Reihe von Code-Änderungen und Optimierungen vorgenommen, um die Leistung zu verbessern, einschließlich des Tunings von RocksDB. Die Herausforderung bei der Suche nach den richtigen Werten liegt hierbei in der Balance zwischen Schreibleistung, Leseleistung, Festplattenleistung, Wiederherstellungszeit und verfügbarem Speicher. Werden die Werte für den Block-Cache und die Schreibpuffer zu hoch eingestellt, besteht die Gefahr, dass der Speicherplatz knapp wird, was den Job zerstört. Wenn die Werte zu niedrig sind, kann es zu viel höheren IOPs auf der Festplatte kommen und den Durchsatz verlangsamen, wenn die Speicherhardwarekapazität gesättigt wird.

Flink erstellt für jede zustandsabhängige Operator-Subtask eine RocksDB-Instanz, die jeweils einen eigenen Block-Cache und Schreibpuffer hat. Das bedeutet, dass die Gesamtmenge an Speicher, die von RocksDB genutzt werden kann, nicht von der Anzahl der TaskManager abhängt, sondern von der Summe aller zustandsbehafteten Operatorparallelismen. Der beste Weg, um die Speicherkapazität von RocksDB in Flink zu planen, ist, einen repräsentativen Workload zu verwenden, um den Job mit gesättigten Block-Caches und Schreibpuffern zu testen.

Eine weitere Folge der RocksDB-Instanzen pro Subtask ist, dass der TaskManager-Prozess eine große Anzahl von offenen Datei-Deskriptoren verwenden kann. Ein Mangel an Datei-Deskriptoren zur Laufzeit wäre ein fataler Fehler, daher wird empfohlen, die Begrenzung des Prozessdatei-Deskriptors höher als erforderlich einzustellen und nach dem Benchmarking zurückzuschalten oder sogar unbegrenzt einzustellen, wenn viele zustandsabhängige Operatoren im Job sind.

Von Apache Flink zu Alibaba Blink

Alibaba wird von rekordverdächtigem Datenverkehr regelrecht überflutet. Millionen von Kunden greifen auf die E-Commerce-Plattform zu. Gleichzeitig müssen mehrere periphere Szenarien unterstützt werden – von Mega-Media-Displays bis hin zu Echtzeit-Business-Intelligence für Händler. Wie also kann sich die zugrundeliegende Infrastruktur in dieser Größenordnung so effizient über Wasser halten sowie Second-Level-Latenzzeiten und eine hohe Rechengenauigkeit nutzen?

2017 hat sich Alibaba für Apache Flink als Kernstück seiner Datenpipeline-Architektur entschieden und damit die Stream-Verarbeitungsfähigkeit im Durchschnitt um das Fünffache erhöht. Apache Flink betreibt verschiedene Anwendungen für das "Singles Day"-Shopping-Event des Unternehmens, darunter Echtzeit-Dashboards mit Aggregationsergebnissen hinter den Medienanzeigen sowie die Such- und Empfehlungsmaschine, die je nach Aktivität des Käufers optimiert sind. Mit Alibabas Stream-Processing-Plattform werden Daten innerhalb von Millisekunden nach ihrer Erzeugung berechnet, um eine überlegene Benutzererfahrung zu schaffen und den Wert von Geschäftsinformationen zu maximieren, die über mehrere Kanäle abgeleitet und übertragen werden können.

Darauf aufbauend hat Alibaba unter dem Namen Blink seine eigene Variante von Apache Flink als Core-Stream-Framework des Unternehmens entwickelt. Blink ist ein Teil von Apache Flink, der ursprünglich konzipiert wurde, um das Verhalten des Frameworks für interne Anwendungsfälle bei Alibaba zu verbessern. Blink verarbeitet kontinuierlich produzierte inkrementelle Daten, um datengesteuerte Echtzeitanwendungen und die Datenanforderungen mehrerer Interessengruppen zu unterstützen. Xiaowei Jiang, der die StreamCompute-Plattform für AliCloud leitet, hielt einen Vortrag auf der Flink Forward Berlin 2018, in dem er erläuterte, wie Alibaba diesen Ansatz nutzt, um eine einheitliche Engine für Streaming-, Batch- und KI-Workloads gleichzeitig aufzubauen. Der Erfolg von Alibaba am Singles Day 2018 ist nur eines der zahlreichen Beispiele für Unternehmen, die auf Echtzeit umsteigen, in Stream Processing investieren, Apache Flink als bevorzugtes Datenverarbeitungs-Framework einsetzen und ihre Anwendungen in die nächste Ära verschieben.

Mit Blink kam eine Reihe von bedeutenden Verbesserungen und Integrationen hinzu, mit dem Ziel ein einheitliches Streaming- und Batch-System zu realisieren. Angesichts der Vielzahl von Änderungen, die mit Blink vorgenommen wurde, hat die Community einen Fusionsplan erstellt, um eine reibungslose, unterbrechungsfreie Integration des bereitgestellten Codes von Blink in Flink zu gewährleisten. Dieser Plan konzentriert sich zunächst auf die Verbesserung der Batch-Verarbeitungsfunktionen von Flink, da der SQL-Abfrageprozessor die Komponente ist, die sich im Vergleich zum neuesten Flink-Masterzweig am meisten entwickelt hat.

  • Einheitliche Stream-Operatoren. Blink erweitert das Streaming-Runtime-Operator-Modell von Flink, 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 der 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 der Neuordnung von Joins.

  • Verbesserte Planung und Fehlerbehebung. Blink implementiert mehrere Verbesserungen für die Aufgabenplanung und Fehlertoleranz. Die Planungsstrategien schonen die Ressourcen, 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 zusätzlich zu den eigenen Stärken mit dedizierten Batch-Verarbeitungssystemen zu messen: Online Analytical Processing (OLAP) und SQL.

Ausblick: Flink avanciert 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 demonstriert.

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 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.

  • 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

Apache Flink ist bereits heute weltweit etabliert, wenn es um anspruchsvolle Anwendungsszenarien geht. Stream-Processing-Experten sehen 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.

Autor

Fabian Hueske

Fabian Hueske ist Committer und PMC-Mitglied des Apache Flink-Projekts und hat seit seinen frühesten Tagen zu Apache Flink beigetragen. Fabian ist Mitbegründer und Software Ingenieur bei Ververica, einem Berliner Start-up.
>> Weiterlesen
Das könnte Sie auch interessieren
botMessage_toctoc_comments_9210