Die perfekte Ergänzung?

Innovatives Machine Learning mit dem Apache-Kafka-Ökosystem

Kai Wähner

@ Shutterstock / INGARA

Machine Learning (ML) ermöglicht es Anwendungen, versteckte Erkenntnisse zu gewinnen, ohne explizit dafür programmiert worden zu sein, worauf sie bei der Erkenntnisfindung achten müssen. So können unstrukturierte Daten analysiert, Bild- und Spracherkennung verbessert und fundierte Entscheidungen getroffen werden. In diesem Artikel werden wir vor allem neue Trends und Innovationen rund um Apache Kafka und Machine Learning diskutieren.

Machine Learning und das Apache-Kafka-Ökosystem sind eine hervorragende Kombination für das Training und die Bereitstellung skalierbarer analytischer Modelle. Kafka wird hierbei zum zentralen Nervensystem in der ML-Architektur, um analytische Modelle mit Daten zu füttern, zu trainieren, sie für Vorhersagen anzuwenden und zu überwachen. Das bringt enorme Vorteile mit sich:

  • Vereinfachung von Datenpipelines
  • Entkopplung des Aufbaus von analytischen Modellen von deren Wartung
  • Nutzung von Echtzeit oder Batch nach Bedarf
  • Einsatz von analytischen Modellen in einer performanten, skalierbaren und unternehmenskritischen Umgebung

Da Kunden heutzutage Informationen in Echtzeit erwarten, besteht die Herausforderung für Unternehmen darin, auf Kundenanfragen und kritische Momente zu reagieren, bevor es zu spät ist. Dafür reicht Batch Processing nicht mehr aus – es muss sofort reagiert werden können, besser noch: proaktiv. Nur so kann man sich vom Mitbewerber abheben. Durch Machine Learning können bestehende Geschäftsprozesse verbessert und datengetriebene Entscheidungen automatisiert getroffen werden. Beispiele für solche Anwendungsfälle sind Betrugserkennung, Cross Selling oder die vorausschauende Wartung von IoT-Geräten (Predictive Maintenance). Die Architektur solch unternehmenskritischer Echtzeitanwendungen, die das Apache-Kafka-Ökosystem als skalierbares und zuverlässiges zentrales Nervensystem für Ihre Daten nutzen, lässt sich wie in Abbildung 1 darstellen.

Abb. 1: Beispiel für unternehmenskritische Echtzeitanwendungen

Abb. 1: Beispiel für unternehmenskritische Echtzeitanwendungen

Deployment von analytischen Modellen

Sehr generell gesprochen besteht ein Lebenszyklus für maschinelles Lernen aus zwei Teilen:

  • Training des Modells: In diesem Schritt befüllen wir einen Algorithmus mit historischen Daten, um Muster aus der Vergangenheit zu lernen. Das Ergebnis ist ein analytisches Modell.
  • Erstellung von Prognosen/Vorhersagen: In diesem Schritt verwenden wir das analytische Modell, um Vorhersagen über neue Ereignisse basierend auf dem erlernten Muster zu treffen.

Machine Learning ist ein kontinuierlicher Prozess, bei dem das analytische Modell im Laufe der Zeit immer wieder verbessert und neu aufgesetzt wird. Prognosen können innerhalb einer Anwendung oder eines Microservice auf unterschiedliche Weise durchgeführt werden. Eine Möglichkeit besteht darin, ein analytisches Modell direkt in eine Stream-verarbeitende Anwendung einzubetten, wie beispielsweise eine Anwendung, die Kafka Streams verwendet. Sie können beispielsweise das TensorFlow for Java API verwenden, um Modelle zu laden und in Echtzeit anzuwenden (Abb. 2).

Abb. 2: Beispiel für die Verwendung des TensorFlow for Java API

Abb. 2: Beispiel für die Verwendung des TensorFlow for Java API

Alternativ können Sie die analytischen Modelle auf einem dedizierten Modellserver (z. B. TensorFlow Serving) bereitstellen und Remote Procedure Calls (RPC) von der Streaminganwendung zum Service verwenden (z. B. mit HTTP oder gRPC) (Abb. 3).

Abb. 3: Bereitstellung der analytischen Modelle auf einem dedizierten Modellserver

Abb. 3: Bereitstellung der analytischen Modelle auf einem dedizierten Modellserver

Beide Optionen haben ihre Vor- und Nachteile. Die Vorteile eines dedizierten Mailservers:

  • Einfache Integration in bestehende Technologien und Unternehmensprozesse
  • Einfacher zu verstehen, wenn Sie aus der „nicht-streamenden Welt“ kommen
  • Eine spätere Migration zu „echtem“ Streaming ist möglich
  • Modellverwaltung inkludiert den Einsatz verschiedener Modelle, einschließlich Versionierung, A/B-Tests etc.

Die Nachteile eines dedizierten Modellservers:

  • Häufig an spezifische ML-Technologien gebunden
  • Oft an einen bestimmten Cloud-Provider gebunden (Vendor Lock-in)
  • Höhere Latenzzeit
  • Komplexere Sicherheitskonzepte (Fernkommunikation über Firewalls und Berechtigungsmanagement)
  • Keine Offlineinferenz (Geräte, Kantenverarbeitung etc.)
  • Verbindet die Verfügbarkeit, Skalierbarkeit und Latenz/Durchsatz Ihrer Stream-Processing-Anwendung mit den SLAs der RPC-Schnittstelle
  • Nebeneffekte (z. B. im Störungsfall bei Netzwerkproblemen), die nicht durch die Kafka-Verarbeitung abgedeckt sind (z. B. Exactly-once Processing)

Wie analytische Modelle bereitgestellt werden, gilt es in jedem Szenario einzeln zu entscheiden – einschließlich Überlegungen zu Latenz und Sicherheit. Einige der nachfolgend diskutierten Trends wie hybride Architekturen oder Anforderungen mit niedriger Latenzzeit fordern ebenfalls Überlegungen zur Modellbereitstellung: Setzen Sie beispielsweise Modelle lokal in Edge-Komponenten wie Sensoren oder mobilen Geräten ein, um personenbezogene Daten zu verarbeiten, oder integrieren Sie externe AutoML-Dienste, um die Vorteile und Skalierbarkeit von Cloud Services zu nutzen? Um für Ihren Anwendungsfall und Ihre Architektur die beste Wahl zu treffen, ist es sehr wichtig, beide Optionen und die damit einhergehenden Kompromisse zu verstehen.

Modellbereitstellung in Kafka-Anwendungen

Kafka-Anwendungen sind Event-basiert und nutzen die Event Streams zur kontinuierlichen Verarbeitung von eingehenden Daten. Wenn Sie Kafka verwenden, können Sie ein analytisches Modell nativ in eine Kafka-Streams- oder KSQL-Anwendung einbetten. Es gibt verschiedene Beispiele für Kafka Streams Microservices, die Modelle einbinden, die mit TensorFlow, H2O oder Deeplearning4j nativ erstellt wurden.

Aus architektonischen, sicherheitstechnischen oder organisatorischen Gründen ist es nicht immer möglich oder machbar, analytische Modelle direkt einzubetten. Sie können auch RPC verwenden, um Modellinferenzen aus Ihrer Kafka-Anwendung durchzuführen (unter Berücksichtigung der oben beschriebenen Vor- und Nachteile).

Hybride Cloud- und On-Prem-Architekturen

Hybride Cloud-Architekturen werden oft als Machine-Learning-Infrastruktur gewählt. Das Training kann mit großen Mengen von historischen Daten in der Public Cloud oder in einem zentralen Data Lake innerhalb des eigenen Rechenzentrums erfolgen. Die Model-Bereitstellung, um Vorhersagen durchzuführen, kann überall durchgeführt werden.

In vielen Szenarien ist es durchaus sinnvoll, die Skalierbarkeit und Anpassungsfähigkeit von Public Clouds zu nutzen. So können beispielsweise neue große Berechnungsinstanzen erstellt werden, um ein neuronales Netzwerk für einige Tage zu trainieren, die dann einfach gestoppt werden können. Pay-as-you-go ist ein perfektes Modell, insbesondere für Deep Learning.

In der Cloud können Sie bestimmte Verarbeitungseinheiten nutzen, die im eigenen Rechenzentrum teuer wären und oft ungenutzt bleiben. So ist beispielsweise Googles TPU (Tensor Processing Unit) – eine anwendungsspezifische integrierte Schaltung (ASIC), die von Grund auf für das maschinelle Lernen entwickelt wurde – ein spezifischer Prozessor, der nur für Deep Learning entwickelt wurde. TPUs können eines gut: Matrix-Multiplikation – das Herzstück des Deep Learnings – zum Training von neuronalen Netzen.

Wenn Sie Daten aus der Public Cloud heraushalten müssen oder wenn Sie Ihre eigene ML-Infrastruktur für größere Teams oder Abteilungen im eigenen Rechenzentrum aufbauen möchten, können Sie speziell entwickelte Hardware/Software-Kombinationen für Deep Learning kaufen, wie z. B. Nvidia-DGX-Plattformen.

Wo immer Sie es benötigen, können Vorhersagen mit Hilfe des analytischen Modells unabhängig vom Modelltraining durchgeführt werden: in der Public Cloud, vor Ort in Ihren Rechenzentren oder auf Edge-Geräten wie Internet of Things (IoT) oder mobilen Geräten. Edge-Geräte haben allerdings oft eine höhere Latenzzeit, begrenzte Bandbreite oder schlechte Konnektivität.

Aufbau hybrider Cloud-Architekturen mit Kafka

Mit Apache Kafka kann eine Cloud-unabhängige Infrastruktur aufgebaut werden – sowohl Multi-Cloud- als auch Hybrid-Architekturen – und das, ohne an bestimmte Cloud-APIs oder proprietäre Produkte gebunden zu sein. Abbildung 4 zeigt ein Beispiel für eine hybride Kafka-Infrastruktur zum Trainieren und Bereitstellen von analytischen Modellen.

Abb. 4: Beispiel für eine hybride Kafka-InfrastruktuU+0072

Abb. 4: Beispiel für eine hybride Kafka-InfrastruktuU+0072

Apache-Kafka-Komponenten wie Kafka Connect können für die Dateneinspeisung verwendet werden, Kafka Streams oder KSQL für die Vorverarbeitung von Daten. Die Modellbereitstellung kann auch innerhalb eines Kafka-Clients wie Java, .NET, Python, Kafka Streams oder KSQL erfolgen. Oft wird auch das gesamte Monitoring der ML-Infrastruktur mit Apache Kafka durchgeführt. Dazu gehören technische Kennzahlen wie die Latenzzeiten und projektbezogene Informationen wie Modellgenauigkeit.

Häufig kommen die Datenströme aus anderen Rechenzentren oder Clouds. Ein häufiges Szenario ist die Verwendung eines Kafka-Replikationstools wie MirrorMaker oder Confluent Replicator, um die Daten aus den Quell-Kafka-Clustern zuverlässig und skalierbar in die Analyseumgebung zu replizieren.

Der Aufbau, die Konfiguration und der Betrieb eines zuverlässigen und skalierbaren Kafka-Clusters erfordern immer gerne ein solides Verständnis für verteilte Systeme und Erfahrung im Umgang mit diesen. Daher kann man auch alternativ einen Cloud Service wie Confluent Cloud nutzen, der Kafka-as-a-Service anbietet. Hier wird nur der Kafka-Client (z. B. Kafkas Java API, Kafka Streams oder KSQL) vom Entwickler erstellt und die Kafka-Serverseite als API verwendet. In eigenen Rechenzentren helfen Tools wie Confluent Operator für den Betrieb auf Kubernetes-Distributionen und Confluent Control Center bei der Überwachung, Bedienung und Verwaltung der Kafka-Cluster.

Streaminganalysen in Echtzeit

Eine primäre Anforderung innerhalb vieler Anwendungsfälle ist es, Informationen zu verarbeiten, während sie noch aktuell und relevant sind. Dies ist für alle Bereiche einer ML-Infrastruktur relevant:

  • Training und Optimierung analytischer Modelle mit aktuellen Informationen
  • Vorhersagen über neue Events in Echtzeit (oft innerhalb von Millisekunden oder Sekunden)
  • Überwachung der gesamten Infrastruktur auf Modellgenauigkeit, Infrastrukturfehler usw.
  • Sicherheitsrelevante Tracking-Informationen wie Zugriffskontrolle, Auditierung oder Herkunft

Der einfachste und zuverlässigste Weg, Daten zeitnah zu verarbeiten, ist die Erstellung von Echtzeitstreaminganalysen nativ auf Apache Kafka mit Kafka-Clients wie Java, .NET, Go oder Python. Neben der Verwendung eines Kafka Client APIs (d. h. Kafka Producer und Consumer) sollte man auch Kafka Streams in Betracht ziehen, das Stream-Processing-Framework für Apache Kafka. Hierbei handelt es sich um eine Java-Bibliothek, die es ermöglicht, einfache und komplexe Stream-Verarbeitung innerhalb von Java-Anwendungen durchzuführen.

Für diejenigen unter Ihnen, die kein Java oder Scala schreiben wollen oder können, gibt es KSQL, die Streaming-SQL-Engine für Apache Kafka. Mit ihr können Anwendungen zur Stream-Verarbeitung erstellt werden, die in SQL ausgedrückt werden. KSQL ist Online als Open-Source-Download verfügbar.

KSQL und Machine Learning zur Vorverarbeitung und Modellbereitstellung

Die Verarbeitung von Streamingdaten mit KSQL macht die Datenaufbereitung für Machine Learning einfach und skalierbar. Mit Hilfe der SQL-Anweisungen können Filterungen, Anreicherungen, Transformationen, Feature Engineering oder andere Aufgaben durchgeführt werden. Abbildung 5 zeigt nur ein Beispiel, um Sensordaten von mehreren Fahrzeugtypen für ein bestimmtes Fahrzeugmodell zur Weiterverarbeitung oder Analyse in Echtzeit zu filtern.

Abb. 5: Beispiel für Filterung von Sensordaten zur Weiterverarbeitung oder Analyse in Echtzeit

Abb. 5: Beispiel für Filterung von Sensordaten zur Weiterverarbeitung oder Analyse in Echtzeit

ML-Modelle können einfach in KSQL eingebettet werden, indem eine benutzerdefinierte Funktion (User-defined Function, UDF) erstellt wird. Im detaillierten Beispiel „Deep Learning UDF for KSQL for Streaming Anomaly Detection of MQTT IoT Sensor Data“ wird ein neuronales Netzwerk für die Sensoranalyse angewandt – genauer gesagt ein Autoencoder – um Anomalien zu erkennen (Abb. 6).

Abb. 6: Anwendung eines neuronalen Netzwerks für die Sensoranalyse

Abb. 6: Anwendung eines neuronalen Netzwerks für die Sensoranalyse

In diesem Beispiel verarbeitet KSQL kontinuierlich Millionen von Events von vernetzten Fahrzeugen über die MQTT-Integration zum Kafka-Cluster. MQTT ist ein Publish/Subscribe-Messaging-Protokoll, das für eingeschränkte Geräte und unzuverlässige Netzwerke entwickelt wurde. Es wird oft in Kombination mit Apache Kafka verwendet, um IoT-Geräte mit dem Rest des Unternehmens zu integrieren. Der Autoencoder wird für die vorausschauende Wartung verwendet.

Echtzeitanalysen in Kombination mit diesen Fahrzeugsensordaten ermöglichen es, Anomalien an ein Warn- oder Notsystem zu senden, um reagieren zu können, bevor der Motor ausfällt. Weitere Anwendungsfälle für intelligente vernetzte Autos sind optimierte Routenführung und Logistikplanung, der Verkauf neuer Features und Funktionen für ein besseres digitales Fahrerlebnis und Loyalty-Programme, die direkt mit Restaurants und Geschäften am Straßenrand korrespondieren.

Auch wenn eine KSQL-UDF ein wenig Code erfordert, muss dieser vom Entwickler nur einmal geschrieben werden. Danach kann der Endbenutzer die UDF einfach innerhalb seiner KSQL-Statements wie jede andere eingebaute Funktion verwenden. In Abbildung 7 sehen Sie die KSQL-Abfrage aus unserem Beispiel unter Verwendung des ANOMALY UDF, das im Hintergrund das TensorFlow-Modell anwendet.

Abb. 7: KSQL-Abfrage unter Verwendung des ANOMALY UDF

Abb. 7: KSQL-Abfrage unter Verwendung des ANOMALY UDF

Je nach Präferenz und Anforderung eignen sich sowohl KSQL als auch Kafka Streams perfekt für ML-Infrastrukturen, wenn es darum geht, Streaming-Daten vorzuverarbeiten und Modellinferenzen durchzuführen. KSQL senkt die Einstiegsbarriere und ermöglicht es, Streaminganwendungen mit einfachen SQL-Anweisungen zu realisieren, anstatt Quellcode schreiben zu müssen.

Skalierbare und flexible Plattformen für Machine Learning

Technologieriesen sind den traditionellen Unternehmen typischerweise einige Jahre voraus. Sie haben bereits das gebaut, was andere heute oder morgen bauen (müssen). Plattformen für Machine Learning bilden hierbei keine Ausnahme.

Das Paper Hidden Technical Debt in Machine Learning Systems erklärt, warum die Erstellung und Bereitstellung eines analytischen Modells viel aufwendiger ist, als nur ein bisschen Machine-Learning-Code mit Technologien wie Python und TensorFlow zu schreiben. Man muss sich auch um die Datenerfassung, die Extraktion von Merkmalen, die Bereitstellung der Infrastruktur, die Überwachung und andere Aufgaben kümmern – alles mit Hilfe einer skalierbaren und zuverlässigen Infrastruktur (Abb. 8).

Abb. 8: Die Bereitstellung eines analytischen Modells ist nicht unaufwendig

Abb. 8: Die Bereitstellung eines analytischen Modells ist nicht unaufwendig

Darüber hinaus zeigen Technologieriesen, dass ein einziges Machine Learning/Deep Learning-Framework wie TensorFlow für ihre Anwendungsfälle nicht ausreichend und maschinelles Lernen ein schnell wachsendes Feld ist. Eine flexible ML-Architektur muss verschiedene Technologien und Frameworks unterstützen. Außerdem muss sie gut skalierbar und zuverlässig sein, wenn sie für essenzielle Geschäftsprozesse eingesetzt wird. Deshalb haben viele Technologieriesen ihre eigenen Plattformen für Machine Learning entwickelt, wie Michelangelo von Uber, Meson von Netflix und die Betrugserkennungsplattform von Pay Pal. Diese Plattformen ermöglichen es den Unternehmen, leistungsfähige, skalierbare analytische Modelle aufzubauen und zu überwachen, sie bleiben aber auch flexibel bei der Wahl der richtigen Technologie für jeden Anwendungsfall.

Apache Kafka als zentrales Nervensystem

Einer der Gründe, warum Apache Kafka so erfolgreich ist, liegt in der schnellen Adaption und Akzeptanz durch viele Technologieunternehmen. Fast alle großen Silicon-Valley-Unternehmen wie LinkedIn, Netflix, Uber oder eBay bloggen und sprechen über ihre Nutzung von Kafka als Event-gesteuertem zentralem Nervensystem für ihre unternehmenskritischen Anwendungen. Viele konzentrieren sich auf die verteilte Streamingplattform für Messaging, aber es werden vermehrt Komponenten wie Kafka Connect, Kafka Streams, REST Proxy, Schema Registry und KSQL eingesetzt.

Wie bereits erläutert, ist Kafka eine logische Ergänzung zu einer ML-Plattform: Training, Überwachung, Bereitstellung, Inferenzen, Konfiguration, A/B-Tests etc. Wahrscheinlich nutzen deshalb auch Uber, Netflix und viele andere Kafka bereits als zentrale Komponente in ihrer Infrastruktur für maschinelles Lernen.

Kafka ermöglicht eine einfache und unkomplizierte Bereitstellung von Machine-Learning-Tasks, ohne dass ein weiterer großer Datencluster erforderlich ist. Und dennoch ist es flexibel in der Integration mit anderen Systemen. Wer sich auf seine Batchdatenverarbeitung in Hadoop verlassen oder ML-Processing z. B. mit Spark oder AWS Sagemaker durchführen möchte, verbindet diese einfach über Kafka Connect mit Kafka. Mit dem Kafka-Ökosystem als Basis einer ML-Infrastruktur ist niemand gezwungen, nur eine bestimmte Technologie einzusetzen (Abb. 9).

Abb. 9: Daten können aus dem verteilten Commit-Log heraus immer wieder neu konsumiert und verarbeitet werden

Abb. 9: Daten können aus dem verteilten Commit-Log heraus immer wieder neu konsumiert und verarbeitet werden

Sie können verschiedene Technologien für das Training analytischer Modelle verwenden, die Modelle für beliebige Kafka-native oder externe Clientanwendungen bereitstellen, ein zentrales Überwachungs- und Auditsystem aufbauen und für zukünftige Innovationen im Bereich des maschinellen Lernens vorbereitet sein und offen bleiben. Alles skalierbar, zuverlässig und fehlertolerant, da die entkoppelten Systeme lose mit Apache Kafka als Nervensystem verbunden sind.

In obigem Beispiel wird neben TensorFlow auch das AutoML-Framework DataRobot verwendet, um automatisch verschiedene analytische Modelle zu trainieren und das Modell mit der besten Genauigkeit bereitzustellen. AutoML ist ein aufstrebender Bereich, da es viele aufwendige Schritte beim Modelltraining wie Hyperparametertuning oder Algorithmusauswahl automatisiert. Bezüglich Integration mit dem Kafka-Ökosystem gibt es keine Unterschiede zu anderen ML-Frameworks, beides arbeitet gut zusammen.

Fazit

Apache Kafka kann als Schlüssel zu einer flexiblen und zukunftsfähigen Infrastruktur für modernes Machine Learning betrachtet werden. Das Ökosystem rund um Apache Kafka ist die perfekte Ergänzung zu einer ML-Architektur. Wählen Sie die Komponenten aus, die Sie benötigen, um eine skalierbare, zuverlässige Plattform aufzubauen, die unabhängig von einer bestimmten On-Prem/Cloud-Infrastruktur oder ML-Technologie ist.

Sie können eine Integrationspipeline für das Modelltraining aufbauen und die analytischen Modelle für Echtzeitvorhersagen und Überwachung innerhalb von Kafka-Anwendungen einsetzen. Dies ändert sich nicht mit neuen Trends wie Hybridarchitekturen oder AutoML. Im Gegenteil: Mit Kafka als zentraler, aber verteilten und skalierbaren Schicht bleiben Sie flexibel und sind bereit für neue Technologien und Konzepte der Zukunft.

Geschrieben von
Kai Wähner
Kai Wähner
Kai Wähner ist als Technology Evangelist bei Confluent tätig. Seine Schwerpunkte liegen in den Bereichen Big Data Analytics, Machine Learning, Messaging, Integration, Microservices, Internet of Things, Stream Processing and Blockchain. Außerdem ist er Autor von Fachartikeln, hält Vorträge auf internationalen Konferenzen und berichtet in seinem Blog (www.kai-waehner.de/blog) über Erfahrungen mit neuen Technologien. Feedback gerne via kontakt@kai-waehner.de / @KaiWaehner / LinkedIn.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: