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.
Du willst den IoT Core durch eine Multi-Cloud-Lösung ersetzen und die Vorteile weiterer IoT-Services von Azure oder Amazon Web Services nutzen? Dann melde Dich bei uns und wir unterstützen Dich bei der Umsetzung mit unserer Expertise und dem b.telligent Partnernetzwerk.
Die Welt der mittelständischen Unternehmen bewegt derzeit vor allem ein Thema: Industrie 4.0. Denn der Druck wächst enorm, da der Anschluss an die Digitalisierung nicht verpasst werden darf, um auch langfristig erfolgreich am Markt interagieren zu können. Was die meisten Unternehmen aber nicht wissen: Es müssen nicht sämtliche internen Abläufe über Bord geworfen werden, um bei den Themen Big Data und Industrie 4.0 mithalten zu können. Viel wichtiger ist es, sich die Neugier seiner eigenen Mitarbeiter zu Nutze zu machen und die Datenkultur in alle Abteilungen zu tragen. Erfahren Sie in diesem Blogbeitrag, wie auch Sie den Wandel zur Digitalisierung Schritt für Schritt meistern können.
Hast Du schon mal darüber nachgedacht, wie die ideale Cloud-Data-Platform-Architektur aussehen sollte? Wir schon! In unserer kostenlosen Online-Event-Reihe Data Firework Days haben wir die b.telligent Referenzarchitektur für Cloud-Datenplattformen vorgestellt, einen Blueprint für den Aufbau einer erfolgreichen Datenplattform für Deine Analytics-, KI-/ML- oder DWH-Anwendungsfälle. Und wir sind noch einen Schritt weiter gegangen. Da wir alle wissen, dass es da draußen nicht die „eine“ Cloud gibt, haben wir unser Modell auch für die drei großen Cloud-Anbieter – Google Cloud Platform, AWS und Azure – adaptiert. In dieser Blogserie wollen wir in den ersten beiden Beiträgen zunächst unsere Referenzarchitektur beschreiben und uns dann, in den Teilen 4 bis 6, mit den Implementierungsmöglichkeiten für die einzelnen Anbieter beschäftigen. Los geht‘s, begleite uns auf unserer Reise durch die Cloud.
Herzlichen Glückwunsch, Du hast es geschafft und die bisherigen Ausführungen zu unserem Referenzarchitekturmodell unbeschadet überstanden! Der mühsamste und lästigste Teil liegt damit schon hinter uns. Falls Du gerade erst mit Teil 3 in unsere Blogserie einsteigst, kein Problem! Klicke einfach auf die Links zu Teil 1 und Teil 2. Dort erfährst Du mehr zu Ingestion und Data Lakes sowie der gesamten Referenzarchitektur.
