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 datengetrieben arbeiten, Prozesse optimieren oder innovative Technologien nutzen? Unser Blog gibt Dir wertvolle Impulse – aber Deine spezifischen Fragen klären wir am besten direkt.
Sprich mit uns – wir sind nur einen Klick entfernt!
Domain Lead Cloud Transformation & Data Infrastructure
Domain Lead Cloud Transformation & Data Infrastructure
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.
Du willst Deine Infrastruktur mit Terraform verwalten, aber dann passiert es doch, dass Änderungen manuell gemacht wurden – und Du eine Lösung dafür finden musst. Der Umgang damit unterscheidet sich von Fall zu Fall.
Es ist eine große Stärke von Terraform, dass es mit Änderungen außerhalb der von ihm verwalteten Ressourcen umgehen kann. Die Stichworte sind: data, import, removed, ignore_changes, lock, variables.
Viele Security-Überlegungen rund um Azure drehen sich primär um die Netzwerksicherheit. Welche weiteren Security-Säulen im Kontext von Microsoft Fabric betrachtet werden sollten, wird im Folgenden aufgezeigt.
Wie kann ich Datenquellen, die über Private Endpoints abgesichert sind, in Fabric einbinden? Wie gehe ich mit Azure Data Lakes hinter einer Firewall um? Der Blog-Beitrag zeigt auf, welche Möglichkeiten Fabric nativ bietet.
Kein vorheriger Beitrag
Kein nächster Beitrag
