Der Stream-Processing-Dienst verarbeitet eingehende Ereignisse aus der Message Queue auf Ereignis- oder Micro-Batch-Basis und wendet Transformationen, Lookups oder andere Umwandlungen an. Dadurch verringert sich der Footprint dieser Dienste, was wiederum zu niedrigeren CPU- und RAM-Anforderungen führt. Unabhängig davon, ob es sich um eine verwaltete Lösung (Software-as-a-Service) oder einen serverlosen Service (serverless) handelt, müssen zwei Optionen berücksichtigt werden: Kaltstarts, bei denen es einige Sekunden oder gar Minuten dauern kann, bis die Ressourcen im Hintergrund bereitgestellt sind und das erste Ereignis verarbeitet wird. Und Zeitüberschreitungen, da nicht alle Dienste für lang laufende Prozesse geeignet sind. Eine weitere Möglichkeit ist der Betrieb einer Self-managed Stream Processing Engine (wie z. B. Spark). Wie so oft muss dabei allerdings abgewogen werden: Rechtfertigen die erhöhten betrieblichen Anforderungen die gewonnene Konfigurationsfreiheit? Solltest Du aber bereits über bestehende Streaming-Pipelines in Spark verfügen und diese für einen schnellen Lift-and-Shift bereithalten wollen, dann ist ein verwalteter Big-Data-Cluster-Dienst eindeutig die beste Wahl.

Die Batch-Verarbeitung spiegelt die zuvor genannten Eigenschaften fast wider. Sie arbeitet typischerweise mit großen Datenmengen und erfordert daher mehr Aufmerksamkeit bei der CPU- und RAM-Konfiguration, während Kaltstarts und Timeouts außer Acht gelassen werden. Da die Verarbeitungszeit im Minuten- oder Stundenbereich liegt, hat die parallele Verarbeitung mit hoher Verfügbarkeit und Persistenz der Zwischenergebnisse Vorrang – Stichwort: Hadoop. Nun wird vielleicht bereits deutlich: Das Einrichten eines Clusters, das noch vor ein paar Jahren als langwierige Arbeit galt, wird in der cloud-nativen Welt zu einer Sache von nur wenigen Minuten. Das Ergebnis: Automatisiert gestartete Cluster, die nach Erledigung des Jobs wieder gelöscht werden, sind relevanter geworden als allgemeine 24/7-Cluster.

Nachdem wir unsere Daten final verarbeitet haben, müssen wir die Ergebnisse in einem persistenten Mehrzweckspeicher, einem Data Lake, speichern. Technisch gesehen umfassen die Anforderungen an diesen komponentenskalierbaren und zuverlässigen Speicherdienst Funktionen wie Geofencing, Encryption-at-rest, detaillierte Sicherheitsrichtlinien usw. Aus logischer Sicht können wir unseren Data Lake in Bereiche strukturieren, die auf der Datenverarbeitungsstufe basieren (z. B. von einer Rohdaten- hin zu einer standardisierten, kuratierten und vertrauenswürdigen Schicht) und darüber hinaus auf Geschäftsdimensionen wie beispielsweise dem jeweiligen Land bei international vertretenen Unternehmen. Am wichtigsten ist, dass unser Data Lake Service eng mit anderen Cloud-Diensten integriert ist, damit KI-/ML-, Business- oder DWH-Teams mit konsistenten und zuverlässigen Datensätzen arbeiten können.