Skalierbare Datenanalysen überall mit Cloud-nativer Architektur ermöglichen

Die Architektur mit Kubernetes ist das unverzichtbare Kernstück, das Datenanalysen außergewöhnlich flexibel macht – sie können überall dort ausgeführt werden, wo der geschäftliche Bedarf besteht, und das in großem Maßstab, mit hoher Parallelität, Leistung, Effizienz und Verfügbarkeit.

Tausende von Unternehmen in Branchen von Finanzdienstleistungen und Versicherungen bis hin zu Fertigung und Gesundheitswesen stellen fest, dass sie öffentliche und private Clouds, Hybrid- und Edge-Bereitstellungen benötigen, um ihren Datenmanagement- und Analyseanforderungen am besten gerecht zu werden. Kein Wunder also, dass das Konzept der verteilten Cloud Teil der Reife der Cloud ist. Die Übertragung von Data Warehouses, Data Lakes und fortgeschrittener Analytik auf eine verteilte Cloud-Architektur ist der Richtung, in die sich die Märkte bewegen. Die Erweiterung dieser Architektur um Dienste für höherwertiges Datenmanagement und Analytik führt natürlich zur Idee einer verteilten Datencloud. Innerhalb einer verteilten Datencloud werden Unternehmens-Data-Warehouses nicht nur genutzt, um Analysen für einige hundert Business-Analysten oder Data Scientists im Unternehmen bereitzustellen, sondern letztendlich in der Lage sein, Echtzeit-Analyseanwendungen zu betreiben, die direkt von den Endkunden eines Unternehmens genutzt werden – die sich in die Zehntausende zählen. Die Daten sind sofort zugänglich – und liefern Erkenntnisse – überall.

Siehe auch: Cloud-Einführungstrends 2021 verstärken sich 2022

Das Ziel erkunden

Cloud-nativ ist ein Begriff, der oft verwendet wird, aber er hat eine echte Bedeutung, wenn Softwarearchitektur von Grund auf so entworfen wird, dass sie die Vorteile der verteilten Cloud nutzt. Ein voll ausgereiftes cloud-natives Data Warehouse sollte logischerweise eine verteilte Datencloud-Architektur nutzen. In weitestem Sinne bringt das Analysen zu den Daten, wo immer sie sich befinden (nicht umgekehrt), mindert Konzentrationsrisiken, steigert die Effizienz dramatisch und leitet Modernisierung für kontrollierte Kosten und einen Wettbewerbsvorteil ein.

Um es präziser zu formulieren: Eine cloud-native Datenmanagement- und Analysetechnologie sollte fünf Schlüsselmerkmale aufweisen, um mit dem Blueprint der verteilten Datencloud übereinzustimmen:

• Eine plattformagnostische Laufzeitumgebung, die die Bereitstellung von Daten und Analysen überall ermöglicht
• Eine einheitliche Benutzererfahrung überall
• Gemeinsame Sicherheits- und Governance-Funktionen auf jedem Bereitstellungsziel
• Kosten- und Technologieeffizienz überall, Minimierung von Ressourcen und Ermöglichung starker Kostenverwaltung (FinOps) und Ausgaben-Schutzmechanismen
• Eine einzige Steuerungsebene, die alle Bereitstellungen zusammenhält: öffentliche Cloud, On-Premises und am Netzwerkrand

Am Point-of-Need überall bereitstellbar, wird ein voll ausgereiftes cloud-natives Data Warehouse, das diesem Muster folgt, auch die Komplexität von Cloud-, On-Premises- und Netzwerkrand-Infrastruktur vor Endbenutzern abstrahieren. Der Punkt ist, sie von Infrastrukturdetails zu befreien und ihnen zu erlauben, sich auf die Wertschöpfung aus Analysen und das Datenmanagement zu konzentrieren, während sie dennoch die native Kraft der Cloud nutzen.

Den richtigen Weg wählen

Wie wird dieses Ziel erreicht? Kubernetes, das Open-Source-Container-Orchestrierungstool, bietet den populärsten Pfad zu Cloud-nativen Operationen. Während die Idee der Workload-Partitionierung in Unix seit den 1970er Jahren existiert, war es erst vor etwa einem Jahrzehnt, dass Container weit verbreitet implementiert wurden, um Anwendungsentwicklung einfacher, portabler und ressourceneffizienter zu machen. Doch die Bereitstellung von Hunderten oder Tausenden von Anwendungen über eine riesige Microservices-Architektur erwies sich als extrem knifflig. Während andere Optionen existieren, setzte sich Googles Open-Source-Kubernetes-Projekt, das nun von der Cloud Native Computing Foundation gepflegt wird, durch, um die Orchestrierung von Microservices-Anwendungen zu lösen – und Anwendungen in die Lage zu versetzen, auf generischer Infrastruktur zu laufen, auf standardisierte Weise überwacht und verwaltet zu werden und offene Standards für Authentifizierung zu nutzen.

Das ist gut und schön für Anwendungen. Aber was ist mit der Welt der Daten? Die gleiche grundlegende Container-Orchestrierung ist erforderlich, damit cloud-native Data Warehouses Elastizität und Bereitstellungsflexibilität über öffentliche und private Clouds, Netzwerkrand, Hybrid- und vollständig verteilte Clouds bieten können.

Cloud-native Re-Architektur für Scale-Out-Webanwendungen ist alltäglich, aber Datenbanken wurden meist nur „lift-and-shift“ in die Cloud-native Welt verschoben. Eine Datenbank in einen Container zu stecken, ermöglicht ihr, in moderner Infrastruktur zu laufen, bietet aber kein Erlebnis, das alle Vorteile der Cloud demonstriert. Die Software ist weitgehend ahnungslos, dass sie in einer Container-Umgebung läuft, und Operationen wie das Verwalten elastischer Cluster müssen umständlich von außerhalb der Datenbank per Hand mit Operatoren und dem Hacken von Helm-Charts gehandhabt werden. Funktionen wie das Erlauben mehrerer, elastischer On-Demand-Compute-Cluster, die dieselben zugrundeliegenden Daten im Objektspeicher teilen, sind oft nicht verfügbar. Nutzer, die geschäftlichen Nutzen aus einem elastischen, cloud-basierten Data Warehouse ziehen wollen, wollen nichts über Helm-Charts, Pods, Nodes oder Konfigurationsdateien wissen. Sie wollen einfach Data Warehouses bereitstellen, elastische Cluster verwalten und Erkenntnisse aus ihren Daten gewinnen.

Eine SQL-Schnittstelle über Kubernetes bereitzustellen, um mehrere, elastische Cluster on-demand bereitzustellen und Kubernetes-Komplexitäten vor DBAs und Endbenutzern zu verbergen, ist die Antwort.

Auf diese Weise können verschiedene Benutzer zugewiesen werden, Workloads auf verschiedenen Compute-Clustern auszuführen, und der verwendete Compute-Cluster kann zur Laufzeit über SQL geändert werden, vorbehaltlich der Berechtigung. Cluster können so konfiguriert werden, dass sie nach einer Leerlaufzeit automatisch angehalten und bei Bedarf wieder hochgefahren werden. Zum Beispiel könnte ein separater Compute-Cluster erstellt werden, um ETL-Prozesse auszuführen, wenn sie benötigt werden, einer für ad-hoc Business Intelligence (BI) und mehrere Data-Science-Cluster. Compute-Cluster können online während hoher Auslastung erweitert oder in ruhigen Perioden abgeschaltet werden, um Geld zu sparen. Cluster können für tägliche, wöchentliche oder monatliche Batch-Reporting-Aufgaben erstellt werden, die nur in diesen Zeiträumen aktiv sind. Sowohl die Größe der Nodes im Compute-Cluster als auch die Anzahl der Nodes sind in diesem Modell kontrollierbar, und Limits für den Ressourcenverbrauch können auf Instanzebene für Vorhersagbarkeit festgelegt werden. Ebenso ist es möglich, ein kostengünstiges Replikatsystem einzurichten, das Replikationsdatenverkehr von einer primären Data-Warehouse-Instanz empfängt und bei Bedarf hochskaliert werden kann, wenn das Replikat genutzt werden muss.

Diese Art von Elastizität wird nicht nur durch tiefe Integration mit Kubernetes implementiert, sondern indem SQL selbst als „Benutzeroberfläche“ für das Erstellen, Anhalten, Fortsetzen und Verwalten von Clustern anstelle von Entwicklertools verwendet wird. Kubernetes ist die autoritative Quelle der Wahrheit für den Zustand aller Cluster. Systemviews, die den Zustand der Cluster anzeigen, beziehen ihre Daten von Kubernetes über dessen APIs. Wenn Cluster-Management-SQL-Anweisungen eingegeben werden, wendet sich das cloud-native Data Warehouse an Kubernetes, um den gewünschten Zustand einer Instanz zu ändern; Kubernetes implementiert dann die notwendigen Änderungen. Wenn ein Node im Cluster ungesund wird, bringt Kubernetes einen Ersatz online.

Dies stellt eine einzigartige Inside-Out-Beziehung zu Kubernetes dar: Anstatt dass Kubernetes die „Benutzeroberfläche“ für die Steuerung des Clusterzustands ist, wird die Datenbank selbst, die von Kubernetes verwaltet wird, zur Benutzeroberfläche. Diese Architektur schafft eine symbiotische Beziehung, die ein einzigartiges, voll ausgereiftes Cloud-Erlebnis liefert. Die Macht und plattformübergreifende Flexibilität von Kubernetes wird für ein Data Warehouse verfügbar, vollständig über SQL gesteuert.

Da mehr Daten generiert und mehr Use Cases bereitgestellt werden, geraten Unternehmen leicht in einen Teufelskreis, in dem ihr Ökosystem zunehmend in einer bestimmten Cloud verankert wird. Systemische Risiken können in dieser einzelnen Cloud entstehen, die zu viel Exposition für kritische IT-Infrastruktur in stark regulierten Sektoren wie Finanzdienstleistungen und Versicherungen darstellen. Die Architektur mit Kubernetes ist nicht das einzige Kernkonzept, das ein voll ausgereiftes cloud-natives Data Warehouse zum Leben erweckt. Es ist nicht der einzige architektonische Bestandteil, der mit dem verteilten Datencloud-Muster übereinstimmt. Aber es ist das unverzichtbare Kernstück, das Datenanalysen außergewöhnlich flexibel macht – sie laufen überall am Point-of-Business-Need – und das in großem Maßstab, mit hoher Parallelität, Leistung, Effizienz und Verfügbarkeit. Das Ergebnis ist, dass Tausende von Nutzern in einem gegebenen Unternehmen, über verschiedene Geschäftsbereiche und geografische Regionen hinweg, extrem schnelle Entscheidungen treffen und Wert aus Analysen in Bewegung in Near-Realtime generieren können.