© Excellent backgrounds/Shutterstock.com
Java Magazin
Daten mit Kafka und Akka annehmen

Die Daten müssen irgendwie ins System

Vor der Analyse steht die Frage, wie Daten ins System kommen. Über die Jahre fanden hier verschiedene Technologien ihre Anwendung. Und so hat sich aus der Kombination von Kafka mit einem reaktiven Framework mittlerweile ein Quasistandard entwickelt.

Jochen Mader


Einer der größten Irrtümer der IT ist das Denken in Durchschnittswerten. Wir sehen uns allzuoft genötigt, Systeme in Bezug auf eine durchschnittliche Last zu bewerten und unsere Rechenzentren entsprechen auszustatten. In der Realität werden wir jedoch genau mit dem Gegenteil konfrontiert: Lange Ruhephasen werden von extremer Aktivität unterbrochen. In der Big-/Fast-Data-Welt sind das Datenmengen im gehobenen Gigabyte- bis Terabytebereich. Offensichtliche Ursachen für solche Lastspitzen können sein, dass Ergebnisse von Batch Jobs eingespielt werden oder ein System nach Verbindungsverlust wieder online kommt und die Daten der letzten Stunden/Tage liefern möchte. Eine weitere Ursache kann eine Kampagne sein, die live geschaltet wurde und unerwartet hohes Datenaufkommen verursacht, oder ein Sensornetzwerk, das überraschend schnell wächst. Alle diese Szenarien haben eines gemeinsam: Die liefernden Systeme können ihre Ergebnisse normalerweise nicht längerfristig puffern. Was wir nicht annehmen können, ist somit verloren.

Diese Lastspitzen werden zur Gefahr, wenn wir die gelieferten Daten nicht schnell genug wegschieben können. Um es noch prägnanter auszudrücken: Wir suchen den schnellsten Weg aus dem Hauptspeicher auf die Platte. Im SMACK-Stack fällt diese Aufgabe der Kombo (Abb. 1) aus Akka und Kafka zu.

Abb. 1: Ingestion: Akka und Kafka kombiniert

Akka bietet eine schwer zu übertreffende Kombination aus Resilienz, Skalierbarkeit und Komfort. Da wäre zum einen die von Erlang übernommene Idee der Aktorenhierarchie. Einzelne Arbeitsschritte werden in kleine Ausführungseinheiten verpackt, die miteinander über Message Passing kommunizieren. Sie formen eine Hierarchie, in der Aktoren, die andere Kindaktoren erzeugen, für deren Lebenszyklus verantwortlich sind. Diese Supervisor identifizieren „defekte“ Aktoren und entscheiden, was mit ihnen geschieht. Mit dieser Strategie lassen sich auch komplexe Fehlerszenarien vergleichsweise einfach abbilden und in ihren Auswirkungen auf das Gesamtsystem beschränken. Basierend auf diesem Konzept wurde das noch recht neue Reactive-Streams-API [1] umgesetzt. Mit diesem sollen die Probleme einer Consumer/Producer-Beziehung umgangen werden: Der Consumer stirbt, weil der Producer zu viele Daten liefert, oder der Consumer verhungert, weil der Producer zu wenige Daten liefert. Das Kernproblem hinter diesen Szenarien ist das Fehlen eines entsprechenden Regelmechanismus. Genau hier setzen die Reactive Streams an (Abb. 2).

Abb. 2: Einsat...

Java Magazin
Daten mit Kafka und Akka annehmen

Die Daten müssen irgendwie ins System

Vor der Analyse steht die Frage, wie Daten ins System kommen. Über die Jahre fanden hier verschiedene Technologien ihre Anwendung. Und so hat sich aus der Kombination von Kafka mit einem reaktiven Framework mittlerweile ein Quasistandard entwickelt.

Jochen Mader


Einer der größten Irrtümer der IT ist das Denken in Durchschnittswerten. Wir sehen uns allzuoft genötigt, Systeme in Bezug auf eine durchschnittliche Last zu bewerten und unsere Rechenzentren entsprechen auszustatten. In der Realität werden wir jedoch genau mit dem Gegenteil konfrontiert: Lange Ruhephasen werden von extremer Aktivität unterbrochen. In der Big-/Fast-Data-Welt sind das Datenmengen im gehobenen Gigabyte- bis Terabytebereich. Offensichtliche Ursachen für solche Lastspitzen können sein, dass Ergebnisse von Batch Jobs eingespielt werden oder ein System nach Verbindungsverlust wieder online kommt und die Daten der letzten Stunden/Tage liefern möchte. Eine weitere Ursache kann eine Kampagne sein, die live geschaltet wurde und unerwartet hohes Datenaufkommen verursacht, oder ein Sensornetzwerk, das überraschend schnell wächst. Alle diese Szenarien haben eines gemeinsam: Die liefernden Systeme können ihre Ergebnisse normalerweise nicht längerfristig puffern. Was wir nicht annehmen können, ist somit verloren.

Diese Lastspitzen werden zur Gefahr, wenn wir die gelieferten Daten nicht schnell genug wegschieben können. Um es noch prägnanter auszudrücken: Wir suchen den schnellsten Weg aus dem Hauptspeicher auf die Platte. Im SMACK-Stack fällt diese Aufgabe der Kombo (Abb. 1) aus Akka und Kafka zu.

Abb. 1: Ingestion: Akka und Kafka kombiniert

Akka bietet eine schwer zu übertreffende Kombination aus Resilienz, Skalierbarkeit und Komfort. Da wäre zum einen die von Erlang übernommene Idee der Aktorenhierarchie. Einzelne Arbeitsschritte werden in kleine Ausführungseinheiten verpackt, die miteinander über Message Passing kommunizieren. Sie formen eine Hierarchie, in der Aktoren, die andere Kindaktoren erzeugen, für deren Lebenszyklus verantwortlich sind. Diese Supervisor identifizieren „defekte“ Aktoren und entscheiden, was mit ihnen geschieht. Mit dieser Strategie lassen sich auch komplexe Fehlerszenarien vergleichsweise einfach abbilden und in ihren Auswirkungen auf das Gesamtsystem beschränken. Basierend auf diesem Konzept wurde das noch recht neue Reactive-Streams-API [1] umgesetzt. Mit diesem sollen die Probleme einer Consumer/Producer-Beziehung umgangen werden: Der Consumer stirbt, weil der Producer zu viele Daten liefert, oder der Consumer verhungert, weil der Producer zu wenige Daten liefert. Das Kernproblem hinter diesen Szenarien ist das Fehlen eines entsprechenden Regelmechanismus. Genau hier setzen die Reactive Streams an (Abb. 2).

Abb. 2: Einsat...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang