Von Lambda zu Kappa: Ein Leitfaden zu Echtzeit-Big Data-Architekturen

Von Lambda zu Kappa: Ein Leitfaden zu Echtzeit-Big Data-Architekturen

Was Echtzeit-Big Data-Architekturen angeht, haben Sie inzwischen mehrere Optionen. Heute steht Ihnen mehr als nur Lambda zur Auswahl. In dieser Blog-Serie beschäftige ich mich mit ein paar dieser Optionen und vergleiche sie mit relevanten Anwendungsfällen. Wie also können wir die richtige Architektur für Ihr Echtzeit-Projekt ausfindig machen? Legen wir los.

Echtzeit-Anforderungen

Bevor wir uns intensiver mit der Architektur auseinandersetzen, sollten wir uns mit einigen wichtigen Anforderungen von Echtzeit-Datenverarbeitungssystemen in Big Data-Szenarien beschäftigen.

Die offensichtlichste Anforderung hat ganz klar damit zu tun, dass die Daten in Bewegung sind. Anders ausgedrückt: Es handelt sich um einen kontinuierlichen, uneingeschränkten Datenfluss. Somit ist der Zeitpunkt, an dem Sie die Daten analysieren, extrem wichtig. Wenn Sie Antworten suchen, die auf eine aktuelle Momentaufnahme Ihrer Daten basieren, oder wenn Sie für bestimmte Anforderungen eine geringe Latenz brauchen, dann sprechen wir vermutlich über ein Echtzeit-Szenario.

Darüber hinaus sind häufig Deadlines einzuhalten. Gäbe es für Echtzeit-Analysen keine Konsequenzen – wie z. B. eine Servicebeeinträchtigung oder einen Serviceausfall – könnte man die Daten auch in Batches verarbeiten.

Da wir über Big Data sprechen, erwarten wir zudem, die Grenzen hinsichtlich der Menge, Geschwindigkeit und eventuell sogar der Vielfalt an Daten zu verschieben.

Die Echtzeit-Datenverarbeitung erfordert häufig Eigenschaften wie Skalierbarkeit, Fehlertoleranz und Planbarkeit. Außerdem muss sie mit Unstimmigkeiten im Datenstrom zurechtkommen und erweiterbar sein.

Neue Architekturen für die New Data-Ära

Not macht erfinderisch und so wurden neue Architekturen entwickelt, um diese Anforderung zu erfüllen.

Die Lambda-Architektur, die Nathan Marz zugeschrieben wird, ist eine der gängigsten Architekturen bei der Echtzeit-Datenverarbeitung. Sie wurde entwickelt, um Lesevorgänge und Updates mit niedriger Latenz linear skalierbar und fehlertolerant zu bewältigen.

Der eingehende Datenstrom wird gleichzeitig in den Batch- und in den Speed-Layer übertragen.

Im Batch-Layer werden die eingehenden Rohdaten gespeichert und die Batchansichten für die Nutzung berechnet. Batchprozesse werden in bestimmten Abständen durchgeführt und sind für längere Zeitfenster ausgelegt, die von einigen Stunden bis hin zu mehreren Jahren reichen können.

Im Speed-Layer werden die Echtzeit-Ansichten berechnet, um die Batchansichten zu ergänzen.

Für Ihre Abfragen können Sie ein umfassendes Bild erhalten, wenn Sie Daten sowohl von den Batchansichten als auch von den Echtzeitansichten abrufen. So bekommen Sie das Beste aus beiden Welten. Die Batchansichten werden möglicherweise mit komplexeren oder aufwändigeren Regeln verarbeitet und haben eventuell eine bessere Datenqualität und weniger Verzerrungen, während Echtzeitansichten Ihnen einen momentgenauen Zugriff auf die aktuellstmöglichen Daten bieten. Mit der Zeit verlieren Echtzeit-Daten an Aktualität und werden mit Daten aus den Batchansichten ersetzt.

Des Weiteren hat Lambda den Vorteil, dass Sie die gleichen eingehenden Daten erneut laden und bei Code- oder Formeländerungen neue Ansichten erstellen können.

Der größte Nachteil dieser Architektur besteht darin, dass zwei verschiedene (und möglicherweise komplexe) Systeme erforderlich sind, um sowohl den Batch- als auch den Speed-Layer zu erstellen. Zum Glück ist dies mit Spark Streaming (Abstraktionsschicht) oder Talend (Spark Batch- und Streaming-Codegenerator) ein deutlich geringeres Problem ... Wobei der operative Aufwand trotzdem noch besteht.

Als Nächstes sprechen wir über die Kappa-Architektur.

Die Kappa-Architektur wurde zuerst von Jay Kreps beschrieben. Sie konzentriert sich darauf, Daten nur als Strom zu verarbeiten und ist kein Ersatz für die Lambda-Architektur – außer bei geeigneten Anwendungsfällen. Bei dieser Architektur werden eingehende Daten über ein Echtzeit-Layer gestreamt und die Ergebnisse davon im Serving-Layer für Abfragen abgelegt.

Die Idee dahinter ist, sowohl die Echtzeit-Datenverarbeitung als auch die kontinuierliche Wiederverarbeitung in einer einzigen Streamverarbeitungsengine zu bewältigen. Denn richtig, die Wiederverarbeitung erfolgt aus dem Stream. Daher ist es wichtig, dass der eingehende Datenstrom (sehr schnell) neu geladen werden kann, entweder ganz oder ab einer bestimmten Stelle. Bei Codeänderungen würde ein zweiter Streamprozess alle vorherigen Daten mit der aktuellsten Echtzeit-Engine neu laden und die im Serving-Layer gespeicherten Daten ersetzen.

Diese Architektur behält zur Vereinfachung nur eine Codebasis, statt wie in der Lambda-Architektur jeweils eine für den Batch- und Speed-Layer zu verwalten. Zudem erfolgen Abfragen nur an einem Serving-Ort, statt in zwei Ansichten (Batch und Speed).

Das Komplizierte an dieser Architektur ist, dass diese Daten in einen Strom verarbeitet werden müssen, z.B. bei doppelten Ereignissen, Ereignis-Querverweisen oder Bestellungen, welche mit Batchverarbeitung generell einfacher zu handhaben sind.

Keine Universallösung

Für viele Echtzeit-Anwendungsfälle ist eine Lambda-Architektur gut geeignet. Das kann man allerdings nicht von der Kappa-Architektur sagen. Wenn Batch- und Streaming-Analysen identisch sind, ist Kappa wahrscheinlich die beste Lösung. In manchen Fällen kann der Zugriff auf einen kompletten Datensatz in einem Batchfenster jedoch für gewisse Optimierungen sorgen, sodass Lambda besser funktionieren würde und vielleicht sogar einfacher zu implementieren wäre.

Zudem gibt es hochkomplexe Situationen, in denen Batch- und Streaming-Algorithmen sehr unterschiedliche Ergebnisse generieren (mit ML-Modellen, Expertensystemen oder grundsätzlich sehr aufwendigen Prozessen, die in Echtzeit unterschiedlich durchgeführt werden müssen), sodass sie den Einsatz von Lambda erfordern.

Damit haben wir die zwei beliebtesten Echtzeit-Datenverarbeitungsarchitekturen behandelt. Im nächsten Artikel dieser Serie beschäftigen wir uns noch intensiver mit den jeweiligen Architekturen und sprechen über konkrete Anwendungsfälle sowie häufig in diesen Architekturen eingesetzte Technologien.

Referenzen:

„How to beat the CAP theorem“ (So widerlegen Sie das CAP-Theorem) von Nathan Marz
http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html

„Questioning the Lambda Architecture“ (Kritische Fragen zur Lambda-Architektur) von Jay Kreps
https://www.oreilly.com/ideas/questioning-the-lambda-architecture

„Big Data“ von Nathan Marz, James Warren
https://www.manning.com/books/big-data

An der Diskussion teilnehmen

0 Comments

Hinterlasse eine Antwort

Your email address will not be published. Required fields are marked *