Kapitel 1. Warum Apache Flink?
Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com
Wir verstehen am besten, wenn unsere Schlussfolgerungen mit den Beweisen übereinstimmen, und das ist am effektivsten, wenn unsere Analysen mit dem Leben übereinstimmen.
Viele der Systeme, die wir verstehen müssen - fahrende Autos, die GPS-Signale aussenden, Finanztransaktionen, der Austausch von Signalen zwischen Mobilfunkmasten und Menschen, die mit ihren Smartphones beschäftigt sind, Internetverkehr, Maschinenprotokolle, Messungen von Industriesensoren und tragbaren Geräten - laufen alle in einem kontinuierlichen Fluss von Ereignissen ab. Wenn du in der Lage bist, Streaming-Daten in großem Maßstab effizient zu analysieren, bist du in einer viel besseren Position, um diese Systeme zu verstehen, und zwar zeitnah. Kurz gesagt: Streaming-Daten passen besser zu unserer Lebensweise.
Es ist daher naheliegend, Daten als Strom von Ereignissen zu sammeln und als Strom zu verarbeiten, aber bisher war das nicht der Standardansatz. Streaming ist nicht völlig neu, aber es wurde als ein spezieller und oft schwieriger Ansatz betrachtet. Stattdessen wurde in der betrieblichen Dateninfrastruktur in der Regel davon ausgegangen, dass Daten als endliche Mengen mit Anfang und Ende organisiert sind, die irgendwann vollständig werden. Dies wurde vor allem deshalb so gehandhabt, weil diese Annahme die Entwicklung von Systemen zur Datenspeicherung und -verarbeitung vereinfacht, aber in vielerlei Hinsicht passt sie nicht zur Realität.
Die Verarbeitung von Daten in Form von Datenströmen ist also attraktiv, aber es war schon immer schwierig, dies gut zu machen, und die Herausforderungen sind jetzt noch größer, da die Menschen begonnen haben, mit Daten in sehr großem Maßstab in einer Vielzahl von Sektoren zu arbeiten. Es liegt in der Physik begründet, dass bei großen verteilten Systemen exakte Konsistenz und sichere Kenntnis der Reihenfolge von Ereignissen nur begrenzt möglich sind. Aber mit der Weiterentwicklung unserer Methoden und Technologien können wir uns bemühen, diese Beschränkungen in dem Maße unschädlich zu machen, wie sie unsere geschäftlichen und betrieblichen Ziele beeinflussen.
Hier kommt Apache Flink ins Spiel. Flink ist eine Open-Source-Software, die von einer offenen Community entwickelt wurde. Sie bietet Stream Processing für große Datenmengen und ermöglicht es dir, Batch-Analysen mit einer einzigen Technologie durchzuführen.
Es wurde entwickelt, um bestimmte Kompromisse zu überwinden, die die Effektivität oder Benutzerfreundlichkeit anderer Ansätze zur Verarbeitung von Streaming-Daten eingeschränkt haben.
In diesem Buch werden wir die potenziellen Vorteile der Arbeit mit Datenströmen untersuchen, damit du herausfinden kannst, ob ein Stream-basierter Ansatz für deine speziellen Geschäftsziele geeignet ist. Einige der Quellen von Streaming-Daten und einige der Situationen, in denen dieser Ansatz nützlich ist, werden dich vielleicht überraschen. Außerdem hilft dir das Buch dabei, die Technologie von Flink zu verstehen und herauszufinden, wie sie die Herausforderungen der Stream-Verarbeitung meistert.
In diesem Kapitel gehen wir der Frage nach, was die Menschen mit der Analyse von Streaming-Daten erreichen wollen und welche Herausforderungen dies in großem Maßstab mit sich bringt. Außerdem stellen wir dir Flink vor und werfen einen ersten Blick darauf, wie es genutzt wird, auch in der Produktion.
Die Folgen von schlechtem Streaming
Wer muss mit Streaming-Daten arbeiten? Zu den ersten Beispielen, die mir einfallen, gehören Sensormessungen oder Finanztransaktionen, und das sind sicherlich Situationen, in denen die Stream-Verarbeitung nützlich ist. Aber es gibt noch weitaus mehr Quellen für Streaming-Daten: Clickstream-Daten, die das Nutzerverhalten auf Websites widerspiegeln, und Maschinenprotokolle für dein eigenes Rechenzentrum sind zwei bekannte Beispiele. Tatsächlich sind Streaming-Datenquellen im Grunde genommen allgegenwärtig - nur gab es bisher in der Regel keine Verbindung zwischen Daten aus kontinuierlichen Ereignissen und der Nutzung dieser Daten in Form von Batch-Verarbeitung. Das ändert sich jetzt mit der Entwicklung neuer Technologien zur Verarbeitung großer Streaming-Daten.
Doch wenn es in der Vergangenheit eine Herausforderung war, mit Streaming-Daten in sehr großem Maßstab zu arbeiten, warum sollte man sich dann jetzt die Mühe machen, es zu tun, und zwar gut? Bevor wir uns ansehen, was sich geändert hat - die neue Architektur und die neuen Technologien, die die Arbeit mit Streaming-Daten unterstützen -, wollen wir uns zunächst die Konsequenzen ansehen, die entstehen, wenn das Streaming nicht gut funktioniert.
Einzelhandel und Marketing
In der modernen Einzelhandelswelt werden Verkäufe oft durch Klicks auf einer Website dargestellt, und diese Daten können in großem Umfang, kontinuierlich, aber nicht gleichmäßig anfallen. Es kann schwierig sein, diese Daten mit älteren Techniken in großem Umfang zu verarbeiten. Selbst der Aufbau von Batch-Systemen zur Verarbeitung dieser Datenströme ist eine Herausforderung - das Ergebnis kann ein enormer und komplizierter Workflow sein. Das Ergebnis können verloren gegangene Daten, Verzögerungen oder falsch zusammengestellte Ergebnisse sein. Wie könnte sich das auf das Geschäft auswirken?
Stell dir vor, du berichtest deinem Geschäftsführer über die Verkaufszahlen des letzten Quartals. Du willst nicht später widerrufen müssen, weil du die Ergebnisse auf der Grundlage ungenauer Zahlen zu hoch angegeben hast. Wenn du mit den Clickstream-Daten nicht richtig umgehst, kann es passieren, dass du den Website-Verkehr nicht richtig zählst - und das wiederum bedeutet, dass du die Anzeigenschaltung und die Leistungszahlen nicht richtig abrechnest.
Die Passagierdienste der Fluggesellschaften stehen vor einer ähnlichen Herausforderung: Sie müssen riesige Datenmengen aus vielen Quellen verarbeiten, die schnell und genau koordiniert werden müssen. Beim Einchecken der Passagiere müssen die Daten zum Beispiel mit den Reservierungsinformationen, der Gepäckabfertigung und dem Flugstatus abgeglichen werden, ebenso wie mit der Rechnungsstellung. In dieser Größenordnung ist es nicht einfach, Schritt zu halten, wenn man nicht über eine robuste Technologie zur Verarbeitung von Datenströmen verfügt. Die jüngsten Ausfälle bei drei der vier größten Fluggesellschaften lassen sich direkt auf Probleme bei der Verarbeitung von Echtzeitdaten in großem Umfang zurückführen.
Natürlich wurden viele damit zusammenhängende Probleme - wie z.B. die Wichtigkeit, Hotelzimmer oder Konzertkarten nicht doppelt zu buchen - traditionell mit Datenbanken gelöst, aber oft mit beträchtlichen Kosten und Aufwand. Die Kosten können in die Höhe schießen, wenn der Umfang der Daten wächst und die Antwortzeiten der Datenbanken für manche Situationen zu langsam sind. Die Entwicklungsgeschwindigkeit kann unter mangelnder Flexibilität leiden und in großen, komplexen oder sich entwickelnden Systemen ins Stocken geraten. Im Grunde genommen ist es schwierig, so zu reagieren, dass du mit dem Leben Schritt halten kannst und gleichzeitig die Konsistenz und Erschwinglichkeit in großen Systemen aufrechterhalten kannst.
Glücklicherweise können moderne Stream-Prozessoren diese Probleme oft auf neue Weise lösen, indem sie in großem Maßstab, zeitnah und kostengünstig arbeiten. Stream Processing lädt auch dazu ein, neue Dinge zu erforschen, wie z. B. die Entwicklung von Echtzeit-Empfehlungssystemen, die darauf reagieren, was die Leute gerade kaufen, um dann zu entscheiden, was sie wahrscheinlich noch wollen. Es geht nicht darum, dass Stream-Prozessoren Datenbanken ersetzen - im Gegenteil, sie können in bestimmten Situationen Aufgaben übernehmen, für die Datenbanken nicht gut geeignet sind. Dadurch werden Datenbanken auch für lokal spezifische Sichten auf den aktuellen Stand des Geschäfts genutzt. Diese Verschiebung wird in unserer Diskussion über die Stream-First-Architektur in Kapitel 2 genauer erläutert.
Das Internet der Dinge
Das Internet der Dinge (IoT) ist ein Bereich, in dem das Streaming von Daten weit verbreitet ist und in dem eine Datenübermittlung und -verarbeitung mit geringer Latenz sowie die Genauigkeit der Datenanalyse oft entscheidend sind. Sensoren in verschiedenen Geräten nehmen häufig Messungen vor und leiten diese an Rechenzentren weiter, wo Echtzeit- oder echtzeitnahe Verarbeitungsanwendungen Dashboards aktualisieren, Machine-Learning-Modelle ausführen, Warnungen ausgeben und Feedback für viele verschiedene Dienste liefern.
Die Verkehrsbranche ist ein weiteres Beispiel dafür, wie wichtig es ist, Streaming gut zu machen. Moderne Zugsysteme zum Beispiel basieren auf Sensordaten, die von den Gleisen an die Züge und von den Zügen an die Sensoren entlang der Strecke übermittelt werden. Gemessen werden u. a. die Geschwindigkeit und der Standort des Zuges sowie Informationen aus der Umgebung über den Zustand der Gleise. Wenn diese Datenströme nicht korrekt verarbeitet werden, können Anpassungen und Warnungen nicht rechtzeitig erfolgen, um sich auf gefährliche Bedingungen einzustellen und Unfälle zu vermeiden.
Ein weiteres Beispiel aus der Verkehrsbranche sind "intelligente" oder vernetzte Autos, die Daten über Mobilfunknetze an die Hersteller weitergeben. In einigen Ländern (z. B. in Skandinavien, Frankreich, Großbritannien und seit kurzem auch in den USA) liefern vernetzte Autos sogar Informationen an Versicherungsgesellschaften und senden im Falle von Rennwagen Informationen über eine Funkverbindung zur Analyse an die Box zurück. Einige Smartphone-Anwendungen liefern auch Echtzeit-Verkehrsinformationen, die von Millionen von Fahrern genutzt werden, wie in Abbildung 1-1 dargestellt.
Abbildung 1-1. Der Zeitwert von Daten spielt in vielen Situationen eine Rolle, auch bei IoT-Daten im Verkehrswesen. Echtzeit-Verkehrsinformationen, die von Millionen von Autofahrern genutzt werden, beruhen auf einer angemessen genauen Analyse von Streaming-Daten, die zeitnah verarbeitet werden. (Bildnachweis © 2016 Friedman)
Das IoT hat auch Auswirkungen auf die Versorgungsunternehmen. Versorgungsunternehmen beginnen, intelligente Zähler einzuführen, die regelmäßig (z. B. alle 15 Minuten) Updates über den Verbrauch senden und die alten Zähler ersetzen, die einmal im Monat manuell abgelesen werden. In einigen Fällen experimentieren die Versorgungsunternehmen mit Messungen alle 30 Sekunden. Dieser Wechsel zu intelligenten Zählern führt zu einer riesigen Menge an Datenströmen, und die potenziellen Vorteile sind groß. Zu den Vorteilen gehört die Möglichkeit, Modelle des maschinellen Lernens einzusetzen, um Anomalien im Verbrauch zu erkennen, die durch Geräteprobleme oder Energiediebstahl verursacht werden. Ohne effiziente Methoden zur Bereitstellung und genauen Verarbeitung von Streaming-Daten mit hohem Durchsatz und sehr geringen Latenzzeiten können diese neuen Ziele nicht erreicht werden.
Auch andere IoT-Projekte leiden darunter, wenn das Streaming nicht gut gemacht ist. Große Anlagen wie Turbinen in einem Windpark, Produktionsanlagen oder Pumpen in einem Bohrbetrieb - sie alle sind auf die Analyse von Sensormessungen angewiesen, um Fehlfunktionen zu melden. Wenn die Stream-Analyse in diesen Fällen nicht gut und mit einer angemessenen Latenzzeit durchgeführt wird, kann das kostspielige oder sogar katastrophale Folgen haben.
Telecom
Die Telekommunikationsbranche ist ein Spezialfall von IoT-Daten, da hier Streaming-Ereignisdaten für eine Vielzahl von Zwecken in geografisch verteilten Regionen genutzt werden. Wenn ein Telekommunikationsunternehmen Streaming-Daten nicht gut verarbeiten kann, schlägt es fehl, wenn es Nutzungsspitzen präventiv auf andere Mobilfunkmasten umleitet oder schnell auf Ausfälle reagiert. Die Erkennung von Anomalien bei der Verarbeitung von Streaming-Daten ist für diese Branche wichtig - in diesem Fall, um unterbrochene Anrufe oder Fehlfunktionen der Geräte zu erkennen.
Banken- und Finanzsektor
Die potenziellen Probleme, die durch eine unzureichende Verarbeitung von Datenströmen entstehen können, sind im Bank- und Finanzwesen besonders offensichtlich. Eine Privatkundenbank möchte nicht, dass sich Kundentransaktionen verzögern oder falsch gezählt werden und somit zu falschen Kontoständen führen. Der altmodische Begriff "Bankers' Hours" bezog sich auf die Notwendigkeit, eine Bank am frühen Nachmittag zu schließen, um die Aktivitäten einzufrieren, damit vor dem nächsten Geschäftstag eine genaue Abrechnung vorgenommen werden konnte. Diese Art von Batch-Geschäft ist längst überholt. Transaktionen und Berichte müssen heute schnell und genau erfolgen; einige neue Banken bieten sogar sofortige Push-Benachrichtigungen in Echtzeit und den Zugriff auf das mobile Banking jederzeit und überall an. In einer globalen Wirtschaft wird es immer wichtiger, die Anforderungen eines 24-Stunden-Geschäftszyklus erfüllen zu können.
Was passiert, wenn ein Finanzinstitut nicht über Anwendungen verfügt, die anomales Verhalten in den Nutzeraktivitätsdaten mit sensibler Erkennung in Echtzeit erkennen können? Die Erkennung von Betrug bei Kreditkartentransaktionen erfordert eine zeitnahe Überwachung und Reaktion. Die Fähigkeit, ungewöhnliche Anmeldemuster zu erkennen, die auf einen Online-Phishing-Angriff hindeuten, kann zu enormen Einsparungen führen, da Probleme rechtzeitig erkannt werden, um den Schaden zu begrenzen.
Hinweis
Da Daten in vielen Situationen einen hohen Zeitwert haben, ist die Verarbeitung von Datenströmen mit geringer Latenz oder in Echtzeit sehr wünschenswert, solange sie auch genau und effizient ist.
Ziele für die Verarbeitung kontinuierlicher Ereignisdaten
Die Fähigkeit, Daten mit sehr geringer Latenz zu verarbeiten, ist nicht der einzige Vorteil einer effektiven Stream-Verarbeitung. Auf der Wunschliste für die Stream-Verarbeitung steht nicht nur ein hoher Durchsatz bei geringer Latenz, sondern das Verarbeitungssystem muss auch mit Unterbrechungen umgehen können. Eine gute Streaming-Technologie sollte in der Lage sein, nach einem Ausfall so neu zu starten, dass sie genaue Ergebnisse liefert; mit anderen Worten, es ist von Vorteil, wenn sie fehlertolerant ist und eine Exact-once-Garantie bietet.
Außerdem sollte die Methode, mit der dieses Maß an Fehlertoleranz erreicht werden soll, möglichst keine hohen Kosten verursachen, wenn es keine Ausfälle gibt. Es ist sinnvoll, Sitzungen anhand des Zeitpunkts des Auftretens von Ereignissen und nicht anhand eines willkürlichen Verarbeitungsintervalls zu erkennen und die Ereignisse in der richtigen Reihenfolge zu verfolgen. Es ist auch wichtig, dass ein solches System für Entwickler/innen einfach zu bedienen ist, sowohl beim Schreiben von Code als auch beim Beheben von Fehlern, und es sollte leicht zu warten sein. Wichtig ist auch, dass diese Systeme korrekte Ergebnisse in Bezug auf die Zeit, in der die Ereignisse in der realen Welt eintreten, liefern - zum Beispiel, dass sie in der Lage sind, Ereignisströme zu verarbeiten, die nicht in der richtigen Reihenfolge eintreffen (eine unglückliche Realität), und dass sie in der Lage sind, Ströme deterministisch zu ersetzen (z. B. für Auditing- oder Debugging-Zwecke).
Entwicklung der Stream Processing Technologien
Die Trennung zwischen kontinuierlicher Datenproduktion und Datenkonsum in endlichen Batches erleichtert zwar die Arbeit der Systementwickler, hat aber die Komplexität der Verwaltung dieser Trennung auf die Nutzer der Systeme verlagert: die Anwendungsentwickler und DevOps-Teams, die diese Infrastruktur nutzen und verwalten müssen.
Um diese Trennung zu bewältigen, haben einige Nutzer ihre eigenen Stream-Processing-Systeme entwickelt. Ein Pionier der Stream-Verarbeitung im Open-Source-Bereich ist das Apache Storm-Projekt, das von Nathan Marz und einem Team des Start-ups BackType (später von Twitter übernommen) ins Leben gerufen wurde, bevor es in die Apache Software Foundation aufgenommen wurde. Storm ermöglichte die Verarbeitung von Datenströmen mit sehr geringer Latenz, aber diese Echtzeitverarbeitung war mit Kompromissen verbunden: Ein hoher Durchsatz war schwer zu erreichen, und Storm bot nicht den Grad an Korrektheit, der oft benötigt wird. Mit anderen Worten: Es gab keine "Exact-once"-Garantie für die Aufrechterhaltung eines korrekten Zustands, und selbst die Garantien, die Storm bieten konnte, waren mit einem hohen Overhead verbunden.
Hinweis
Um Werte zu berechnen, die von mehreren Streaming-Ereignissen abhängen, ist es notwendig, Daten von einem Ereignis zum nächsten zu speichern. Diese gespeicherten Daten werden als Status der Berechnung bezeichnet. Eine genaue Handhabung des Zustands ist für die Konsistenz der Berechnungen unerlässlich. Die Fähigkeit, den Zustand nach einem Ausfall oder einer Unterbrechung genau zu aktualisieren, ist ein Schlüssel zur Fehlertoleranz.
Es ist schwierig, eine fehlertolerante Stream-Verarbeitung mit hohem Durchsatz und sehr geringer Latenz aufrechtzuerhalten, aber die Notwendigkeit, einen genauen Zustand zu garantieren, führte zu einem cleveren Kompromiss: Was wäre, wenn der Datenstrom aus kontinuierlichen Ereignissen in eine Reihe kleiner, atomarer Batch-Aufträge aufgeteilt würde? Wenn die Batches klein genug sind - so genannte "Micro-Batches" - kann die Berechnung einem echten Streaming nahekommen. Die Latenzzeit würde nicht ganz Echtzeit erreichen, aber Latenzen von einigen Sekunden oder sogar Subsekunden für sehr einfache Anwendungen wären möglich. Diesen Ansatz verfolgt Apache Spark Streaming, das auf der Spark-Batch-Engine läuft.
Noch wichtiger ist, dass du mit Micro-Batching die Konsistenz des Zustands genau einmal garantieren kannst. Wenn ein Micro-Batch-Auftrag fehlschlägt, kann er erneut ausgeführt werden. Das ist viel einfacher als bei einem kontinuierlichen Stream-Processing-Ansatz. Eine Erweiterung von Storm, Storm Trident genannt, wendet Micro-Batch-Berechnungen auf den zugrunde liegenden Stream-Prozessor an, um Exakt-einmal-Garantien zu bieten, allerdings zu einem erheblichen Preis für die Latenz.
Die Simulation von Streaming mit periodischen Batch-Aufträgen führt jedoch zu sehr anfälligen Pipelines, die DevOps und Anwendungsentwicklung vermischen. Die Zeit, die ein periodischer Batch-Job braucht, um fertig zu werden, ist eng mit dem Zeitpunkt des Eintreffens der Daten gekoppelt, und jede Verzögerung kann zu inkonsistenten (d.h. falschen) Ergebnissen führen. Das grundlegende Problem bei diesem Ansatz ist, dass die Zeit nur implizit von dem Teil des Systems verwaltet wird, der die kleinen Aufträge erstellt. Frameworks wie Spark Streaming mildern die Anfälligkeit zwar etwas ab, aber nicht vollständig. Die Empfindlichkeit gegenüber der Zeit im Vergleich zu Batches führt immer noch zu schlechten Latenzzeiten und einer Benutzererfahrung, bei der man im Anwendungscode viel über die Leistung nachdenken muss.
Diese Kompromisse zwischen den gewünschten Fähigkeiten haben dazu geführt, dass immer wieder versucht wird, bestehende Prozessoren zu verbessern (z. B. die Entwicklung von Storm Trident, um einige der Einschränkungen von Storm zu überwinden). Wenn bestehende Prozessoren nicht ausreichen, liegt es an den Anwendungsentwicklern, die daraus resultierenden Probleme zu lösen. Ein Beispiel dafür ist das Micro-Batching, das keine gute Verbindung zwischen dem natürlichen Auftreten von Sessions in Ereignisdaten und der Notwendigkeit des Prozessors, Daten nur als Vielfaches der Batch-Zeit (Erholungsintervall) zu fenstern, herstellt. Mit weniger Flexibilität und Ausdruckskraft wird die Entwicklungszeit langsamer und die Abläufe erfordern mehr Aufwand, um sie richtig zu pflegen.
Das bringt uns zu Apache Flink, einem Datenprozessor, der viele dieser Kompromisse beseitigt und viele der gewünschten Eigenschaften vereint, die für eine effiziente Verarbeitung von Daten aus kontinuierlichen Ereignissen erforderlich sind. Die Kombination einiger Fähigkeiten von Flink ist in Abbildung 1-2 dargestellt.
Abbildung 1-2. Eine der Stärken von Apache Flink ist die Art und Weise, wie es viele wünschenswerte Fähigkeiten kombiniert, die in anderen Projekten bisher einen Kompromiss erforderten. Apache Storm hingegen bietet eine niedrige Latenzzeit, aber derzeit keinen hohen Durchsatz und unterstützt keine korrekte Behandlung des Zustands bei Ausfällen. Der Micro-Batching-Ansatz von Apache Spark Streaming bietet Fehlertoleranz und einen hohen Durchsatz, allerdings um den Preis einer sehr geringen Latenzzeit/Echtzeitverarbeitung, der Unfähigkeit, Fenster in natürlich auftretende Sitzungen einzupassen, und einiger Probleme mit der Aussagekraft.
Wie Storm und Spark Streaming bieten auch andere neue Technologien im Bereich der Streaming-Verarbeitung einige nützliche Funktionen, aber es ist schwer, eine mit der Kombination von Eigenschaften zu finden, die Flink bietet. Apache Samza zum Beispiel ist ein weiterer früher Open-Source-Prozessor für Streaming-Daten, aber auch er beschränkt sich auf einmalige Garantien und eine Low-Level-API. Auch Apache Apex bietet einige der Vorteile von Flink, aber nicht alle (z. B. ist es auf eine Low-Level-Programmier-API beschränkt, unterstützt keine Ereigniszeit und keine Batch-Berechnungen). Und keines dieser Projekte konnte eine Open-Source-Gemeinschaft anziehen, die mit der Flink-Gemeinschaft vergleichbar ist.
Schauen wir uns nun an, was Flink ist und wie das Projekt entstanden ist.
Erster Blick auf Apache Flink
Die Homepage des Apache Flink-Projekts beginnt mit dem Slogan: "Apache Flink ist eine Open-Source-Plattform für verteilte Stream- und Batch-Datenverarbeitung". Für viele ist es eine Überraschung, dass Flink nicht nur Echtzeit-Streaming mit hohem Durchsatz und Exact-once-Garantie bietet, sondern auch eine Engine für die Batch-Datenverarbeitung ist. Früher musste man sich zwischen diesen Ansätzen entscheiden, aber mit Flink kann man beides mit einer einzigen Technologie machen.
Wie wurde dieses Apache-Projekt auf höchster Ebene ins Leben gerufen? Flink hat seinen Ursprung im Stratosphere-Projekt, einem Forschungsprojekt, das zwischen 2010 und 2014 von drei Berliner Universitäten sowie anderen europäischen Universitäten durchgeführt wurde. Das Projekt hatte bereits eine breitere Community-Basis angezogen, zum Teil durch Präsentationen auf mehreren öffentlichen Entwicklerkonferenzen wie Berlin Buzzwords, NoSQL Matters in Köln und anderen. Diese starke Community-Basis ist einer der Gründe, warum das Projekt für eine Inkubation bei der Apache Software Foundation geeignet war.
Ein Fork des Stratosphere-Codes wurde im April 2014 als Inkubationsprojekt an die Apache Software Foundation gespendet, wobei die ersten Committer aus den Kernentwicklern des Systems bestanden. Kurz darauf verließen viele der Gründungsmitglieder die Universität, um ein Unternehmen zur Vermarktung von Flink zu gründen: Data Artisans. Während der Inkubationszeit musste der Projektname von Stratosphere geändert werden, da er mit einem anderen Projekt verwechselt werden konnte. Der Name Flink wurde gewählt, um den Stil dieses Stream- und Batch-Prozessors zu ehren: Das Wort "Flink" bedeutet auf Deutsch schnell oder wendig. Das Logo, das ein buntes Eichhörnchen zeigt, wurde gewählt, weil Eichhörnchen schnell und wendig sind und - im Fall der Eichhörnchen in Berlin - einen erstaunlichen rotbraunen Farbton haben, wie du in Abbildung 1-3 sehen kannst.
Abbildung 1-3. Links: Rotes Eichhörnchen in Berlin mit spektakulären Ohren. Rechts: Apache Flink Logo mit spektakulärem Schwanz. Seine Farben spiegeln die des Logos der Apache Software Foundation wider. Es ist ein Eichhörnchen im Apache-Stil!
Das Projekt schloss die Inkubationsphase schnell ab und im Dezember 2014 wurde Flink zu einem Top-Level-Projekt der Apache Software Foundation ernannt. Flink ist eines der 5 größten Big-Data-Projekte der Apache Software Foundation, mit einer Gemeinschaft von mehr als 200 Entwicklern auf der ganzen Welt und mehreren Produktionsinstallationen, einige davon in Fortune Global 500-Unternehmen. Zum Zeitpunkt der Erstellung dieses Artikels finden 34 Apache Flink-Meetups in Städten auf der ganzen Welt statt, und etwa 12.000 Mitglieder und Flink-Sprecher/innen nehmen an Big-Data-Konferenzen teil. Im Oktober 2015 veranstaltete das Flink-Projekt seine erste jährliche Konferenz in Berlin: Flink Forward.
Stapel- und Stream-Verarbeitung
Wie und warum verarbeitet Flink sowohl Batch- als auch Stream-Prozesse? Flink behandelt die Stapelverarbeitung - also die Verarbeitung statischer und endlicher Daten - als einen Spezialfall der Stream-Verarbeitung.
Das Kernstück von Flink, in Abbildung 1-4 als "Flink-Laufzeit" bezeichnet, ist ein verteiltes System, das Streaming-Dataflow-Programme annimmt und sie fehlertolerant auf einem oder mehreren Rechnern ausführt. Diese Runtime kann in einem Cluster, als Anwendung von YARN (Yet Another Resource Negotiator) oder bald in einem Mesos-Cluster (in Entwicklung) oder auf einer einzelnen Maschine laufen, was für das Debuggen von Flink-Anwendungen sehr nützlich ist.
Abbildung 1-4. Dieses Diagramm zeigt die wichtigsten Komponenten des Flink-Stacks. Beachte, dass die Benutzeroberfläche APIs für die Stream- und Batch-Verarbeitung enthält, so dass Flink ein einziges Tool für die Arbeit mit Daten in beiden Situationen ist. Zu den Bibliotheken gehören maschinelles Lernen (FlinkML), komplexe Ereignisverarbeitung (CEP) und Graphenverarbeitung (Gelly) sowie eine Tabellen-API für den Stream- oder Batch-Modus.
Programme, die von der Laufzeitumgebung akzeptiert werden, sind sehr leistungsfähig, aber langatmig und schwer direkt zu programmieren. Aus diesem Grund bietet Flink entwicklerfreundliche APIs, die auf die Runtime aufsetzen und diese Streaming-Dataflow-Programme erzeugen. Es gibt die DataStream API für die Stream-Verarbeitung und eine DataSet API für die Stapelverarbeitung. Obwohl die Laufzeit von Flink schon immer auf Streams basierte, ist die DataSet-API interessanterweise der DataStream-API vorausgegangen, da der Bedarf an der Verarbeitung unendlicher Streams in den ersten Jahren von Flink noch nicht so weit verbreitet war.
Die DataStream API ist eine fließende API für die Definition von Analysen auf möglicherweise unendlichen Datenströmen. Die API ist in Java oder Scala verfügbar. Die Nutzer arbeiten mit einer Datenstruktur namens DataStream, die verteilte, möglicherweise unendliche Datenströme darstellt.
Flink ist in dem Sinne verteilt, dass es auf Hunderten oder Tausenden von Rechnern laufen kann, indem es eine große Berechnung in kleine Chunks aufteilt, wobei jeder Rechner einen Chunk ausführt. Das Flink-Framework kümmert sich automatisch um die korrekte Wiederherstellung der Berechnung im Falle von Maschinen- oder anderen Ausfällen oder einer absichtlichen Neuverarbeitung, wie bei Bugfixes oder Versions-Upgrades. Dank dieser Fähigkeit muss sich der Programmierer nicht mehr um Ausfälle kümmern. Flink verwendet intern fehlertolerante Streaming-Datenströme, die es Entwicklern ermöglichen, unendliche Datenströme zu analysieren, die kontinuierlich produziert werden (Stream Processing).
Hinweis
Da Flink viele wichtige Aspekte wie Exact-Once-Garantien und Datenfenster in der Ereigniszeit behandelt, müssen Entwickler diese nicht mehr in der Anwendungsschicht unterbringen. Dieser Stil führt zu weniger Fehlern.
Die Teams nutzen die Zeit ihrer Ingenieure optimal, weil sie sich nicht um Probleme in ihrem Anwendungscode kümmern müssen. Dieser Vorteil wirkt sich nicht nur auf die Entwicklungszeit aus, sondern verbessert auch die Qualität durch Flexibilität und macht es einfacher, Arbeitsabläufe effizient durchzuführen. Flink bietet eine robuste Möglichkeit, dass eine Anwendung in der Produktion gut funktioniert. Das ist nicht nur Theorie - obwohl Flink ein relativ neues Projekt ist, wird die Software bereits in der Produktion eingesetzt, wie wir im nächsten Abschnitt sehen werden.
Flink in der Produktion
Dieses Kapitel wirft die Frage auf: "Warum Apache Flink?" Eine gute Möglichkeit, diese Frage zu beantworten, ist, sich anzuhören, was Menschen, die Flink in der Produktion einsetzen, darüber zu sagen haben, warum sie es ausgewählt haben und wofür sie es verwenden.
Bouygues Telecom
Bouygues Telecom ist der drittgrößte Mobilfunkanbieter in Frankreich und gehört zur Bouygues-Gruppe, die zu den "Global 500" von Fortune zählt. Bouygues nutzt Flink für die Echtzeit-Ereignisverarbeitung und -Analyse von Milliarden von Nachrichten pro Tag in einem System, das rund um die Uhr läuft. In einem Beitrag von Mohamed Amine Abdessemed im Juni 2015 auf dem Data Artisans Blog beschreibt ein Vertreter von Bouygues die Projektziele des Unternehmens und warum es sich für Flink entschieden hat, um diese zu erreichen.
Bouygues "... hat sich für Flink entschieden, weil das System echtes Streaming unterstützt - sowohl auf API- als auch auf Laufzeitebene - und uns die Programmierbarkeit und die geringe Latenz bietet, die wir gesucht haben. Außerdem konnten wir unser System mit Flink im Vergleich zu anderen Lösungen in einem Bruchteil der Zeit zum Laufen bringen, was dazu führte, dass mehr Entwicklerressourcen für die Erweiterung der Geschäftslogik im System zur Verfügung standen."
Über diese Arbeit wurde auch auf der Flink Forward Konferenz im Oktober 2015 berichtet. Bouygues wollte seinen Ingenieuren in Echtzeit Einblicke in das Kundenerlebnis, in das globale Geschehen im Netz und in die Entwicklung und den Betrieb des Netzes geben.
Zu diesem Zweck hat das Team ein System entwickelt, das die Protokolle der Netzwerkgeräte analysiert, um Indikatoren für die Qualität der Nutzererfahrung zu ermitteln. Das System verarbeitet 2 Milliarden Ereignisse pro Tag (500.000 Ereignisse pro Sekunde) mit einer erforderlichen End-to-End-Latenz von weniger als 200 Millisekunden (einschließlich der Veröffentlichung von Nachrichten durch die Transportschicht und der Datenverarbeitung in Flink). Dies wurde auf einem kleinen Cluster mit nur 10 Knoten und je 1 Gigabyte Speicher erreicht. Bouygues wollte auch, dass andere Gruppen die teilweise verarbeiteten Daten für eine Vielzahl von Business Intelligence (BI)-Zwecken wiederverwenden können, ohne sich gegenseitig zu behindern.
Das Unternehmen plante, die Stream-Verarbeitung von Flink zu nutzen, um Daten umzuwandeln und anzureichern. Die abgeleiteten Datenströme sollten dann an das Nachrichtentransportsystem zurückgegeben werden, um diese Daten für Analysen durch mehrere Verbraucher verfügbar zu machen.
Dieser Ansatz wurde ausdrücklich anstelle anderer Designoptionen gewählt, wie z. B. die Verarbeitung der Daten, bevor sie in die Nachrichtenwarteschlange gelangen, oder die Delegierung der Verarbeitung an mehrere Anwendungen, die von der Nachrichtenwarteschlange konsumieren.
Die Stream-Processing-Fähigkeit von Flink ermöglichte es dem Bouygues-Team, die Datenverarbeitungs- und -bewegungspipeline fertigzustellen und dabei die Latenzanforderungen zu erfüllen, und zwar mit hoher Zuverlässigkeit, hoher Verfügbarkeit und Benutzerfreundlichkeit. Das Flink-Framework ist zum Beispiel ideal für das Debugging und kann auf lokale Ausführung umgestellt werden. Flink unterstützt auch die Visualisierung von Programmen, damit man besser versteht, wie sie laufen. Außerdem sind die Flink-APIs sowohl für Entwickler/innen als auch für Datenwissenschaftler/innen attraktiv. Im Blogbeitrag von Mohamed Amine Abdessemed berichtet Bouygues über das Interesse anderer Teams an Flink für verschiedene Anwendungsfälle.
Andere Beispiele für Apache Flink in der Produktion
König.de
Es ist ziemlich wahrscheinlich, dass gerade irgendwo auf der Welt jemand ein Spiel von King online spielt. Das führende Online-Unterhaltungsunternehmen hat nach eigenen Angaben mehr als 200 Spiele entwickelt, die in mehr als 200 Ländern und Regionen angeboten werden.
Wie die King-Ingenieure beschreiben: "Mit über 300 Millionen monatlichen Nutzern und über 30 Milliarden Ereignissen, die jeden Tag von den verschiedenen Spielen und Systemen empfangen werden, wird jeder Anwendungsfall der Stream-Analyse zu einer echten technischen Herausforderung. Für unser Unternehmen ist es entscheidend, Werkzeuge für unsere Datenanalysten zu entwickeln, die diese massiven Datenströme verarbeiten können und gleichzeitig maximale Flexibilität für ihre Anwendungen bieten."
Das System, das das Unternehmen mit Hilfe von Apache Flink entwickelt hat, ermöglicht es den Datenwissenschaftlern bei King, in Echtzeit auf diese riesigen Datenströme zuzugreifen. Sie geben an, dass sie vom Reifegrad von Apache Flink beeindruckt sind. Selbst bei einer so komplexen Anwendung wie diesem Online-Spiel ist Flink in der Lage, die Lösung fast auf Anhieb zu bewältigen.
Zalando
Zalando ist eine führende Online-Modeplattform in Europa und hat weltweit mehr als 16 Millionen Kunden. Auf seiner Website beschreibt das Unternehmen, dass es mit "...kleinen, agilen, autonomen Teams" arbeitet (eine andere Möglichkeit, dies zu sagen, ist, dass es eine Architektur im Stil von Microservices verwendet).
Eine Stream-basierte Architektur unterstützt einen Microservice-Ansatz, und Flink bietet die Stream-Verarbeitung, die für diese Art von Arbeit benötigt wird, insbesondere für die Überwachung von Geschäftsprozessen und kontinuierliches Extrahieren, Transformieren und Laden (ETL) im Anwendungsfall von Zalando.
Otto Group
Die Otto Group ist der zweitgrößte Online-Händler der Welt im Endverbrauchergeschäft (B2C) und Europas größter Online-Händler im B2C-Mode- und Lifestyle-Geschäft.
Die BI-Abteilung der Otto Group hatte auf die Entwicklung einer eigenen Streaming-Engine zurückgegriffen, da sie bei der ersten Evaluierung der Open-Source-Optionen keine für ihre Anforderungen geeignete Lösung finden konnte. Nachdem die Abteilung Flink getestet hatte, stellte sie fest, dass es ihre Anforderungen an die Stream-Verarbeitung erfüllte, wie z. B. die Identifizierung des User-Agents durch die Crowd und die Identifizierung von Suchanfragen.
ResearchGate
ResearchGate ist das größte akademische soziale Netzwerk, gemessen an der Zahl der aktiven Nutzer. ResearchGate setzt Flink seit 2014 in der Produktion ein und nutzt es als eines der wichtigsten Tools in der Dateninfrastruktur sowohl für die Batch- als auch für die Stream-Verarbeitung.
Alibaba-Gruppe
Diese große E-Commerce-Gruppe arbeitet über ihr Webportal mit Käufern und Lieferanten zusammen. Die Online-Empfehlungen des Unternehmens werden von einer Variante von Flink (genannt Blink) erstellt. Einer der Vorteile der Arbeit mit einer echten Streaming-Engine wie Flink ist, dass Einkäufe, die während des Tages getätigt werden, bei den Produktempfehlungen für die Nutzer/innen berücksichtigt werden können. Das ist besonders wichtig an besonderen Tagen (Feiertagen), wenn die Aktivität ungewöhnlich hoch ist. Dies ist ein Beispiel für einen Anwendungsfall, bei dem eine effiziente Stream-Verarbeitung einen großen Vorteil gegenüber der Stapelverarbeitung darstellt.
Wo Flink hinpasst
Wir haben dieses Kapitel mit der Frage begonnen: "Warum Flink?" Eine größere Frage ist natürlich: "Warum mit Streaming-Daten arbeiten?" Die Antwort darauf haben wir bereits gegeben - viele der Situationen, die wir beobachten und analysieren wollen, beinhalten Daten aus kontinuierlichen Ereignissen. Streaming-Daten sind nichts Besonderes, sondern in vielen Situationen etwas ganz Natürliches - nur mussten wir in der Vergangenheit clevere Kompromisse eingehen, um mit ihnen auf eine etwas künstliche Art und Weise zu arbeiten, nämlich in Form von Stapeln, um den Anforderungen gerecht zu werden, die sich aus der Verarbeitung von Daten und Berechnungen in sehr großem Maßstab ergeben. Es geht nicht darum, dass die Arbeit mit Streaming-Daten völlig neu ist, sondern darum, dass wir neue Technologien haben, die uns dies in größerem Umfang, flexibler und auf natürliche und erschwinglichere Weise als bisher ermöglichen.
Flink ist nicht die einzige Technologie, die für die Verarbeitung von Datenströmen zur Verfügung steht. Es gibt eine Reihe von neuen Technologien, die entwickelt und verbessert werden, um diese Anforderungen zu erfüllen. Natürlich entscheiden sich die Menschen aus verschiedenen Gründen für eine bestimmte Technologie, z. B. wegen der vorhandenen Fachkenntnisse in ihren Teams. Aber die Stärken von Flink, die Einfachheit der Arbeit damit und die vielen Möglichkeiten, es vorteilhaft einzusetzen, machen es zu einer attraktiven Option. Das und eine wachsende und tatkräftige Community sprechen dafür, dass es sich lohnt, es zu prüfen. Vielleicht stellt sich heraus, dass die Antwort auf die Frage "Warum Flink?" lautet: "Warum nicht Flink?"
Bevor wir uns genauer ansehen, wie Flink funktioniert, werden wir in Kapitel 2 untersuchen, wie man eine Datenarchitektur entwirft, um den besten Nutzen aus der Stream-Verarbeitung zu ziehen, und wie eine Stream-First-Architektur weitreichendere Vorteile bietet.
Get Einführung in Apache Flink now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
