vorheriger Artikel
Wie im ersten Teil erwähnt, werden wir in dieser Blogserie zunächst verschiedene Teile unserer Referenzarchitektur einer Cloud Data Platform vorstellen. Im Anschluss adaptieren wir diese auf die drei großen Cloud-Anbieter – Google Cloud Platform, AWS und Azure. Falls Du den ersten Blogbeitrag, der sich mit dem Ingestion-Teil unseres Modells beschäftigt, noch nicht gelesen hast, kannst Du das noch nachholen. Für alle anderen geht es nun mit dem Data-Lake-Teil der b.telligent Referenzarchitektur weiter, bevor wir uns in Teil 3 ausführlicher mit der Analytical Platform beschäftigen.
Damit Du immer den Überblick behältst, findest Du hier noch einmal alle Elemente der Referenzarchitektur auf einen Blick. Weiter gehtʼs!
Bis hierhin haben wir erfolgreich Daten in die Plattform eingespeist. In vielen Organisationen, mit denen wir zu tun haben, ist das allein schon eine große Herausforderung. Im nächsten Schritt müssen wir uns nun mit einer Vielzahl von Themen rund ums Datenmanagement auseinandersetzen. Insbesondere gilt es, Rohdatensätze in eine standardisierte und kuratierte Form umzuwandeln (Datenbereinigung, Datenqualität, DSGVO usw.) oder auf eingehende Ereignisse zu reagieren, wie beispielsweise bei durch Kontobewegungen ausgelösten Push Notifications.
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.
Damit endet Teil 2 von 3. Bevor wir zu den einzelnen anbieterspezifischen Versionen unseres Modells übergehen, tauchen wir in Teil 3 zunächst in die Analytics-Plattform und die Data-Warehouse- und BI-Elemente unserer Architektur ein. Hast Du bis hierhin noch Fragen? Dann wende Dich an unsere Cloud-Spezialisten.
