Der Cloud-native Weg zu Daten überall

Die Architektur mit Kubernetes ist das unverzichtbare Herzstück, das Datenanalysen außergewöhnlich flexibel macht und überall dort ausgeführt werden kann, wo es erforderlich ist – und dies in großem Umfang und mit hoher Parallelität, Leistung, Effizienz und Verfügbarkeit.

Tausende von Unternehmen in Branchen wie Finanzdienstleistungen und Versicherungen bis hin zu Fertigung und Gesundheitswesen stellen fest, dass sie öffentliche und private Cloud-, Hybrid- und Edge-Bereitstellungen benötigen, um ihre Datenverwaltungs- und Analyseanforderungen optimal zu erfüllen. Daher ist es nicht verwunderlich, dass das Konzept der verteilten Cloud Teil der Reifung der Cloud ist. Data Warehouses, Data Lakes und Advanced Analytics in eine verteilte Cloud-Architektur zu bringen, ist die Richtung, in die sich die Märkte bewegen. Die Erweiterung dieser Architektur um übergeordnete Datenverwaltungs- und Analysedienste führt natürlich zu der Idee einer verteilten Datenwolke . Innerhalb einer verteilten Datenwolke werden Unternehmens-Data Warehouses nicht nur dazu verwendet, Analysen für einige hundert Business-Analysten oder Datenwissenschaftler in einem Unternehmen bereitzustellen, sondern werden letztendlich in der Lage sein, Echtzeit-Analyseanwendungen zu betreiben, die direkt von einem Unternehmen verwendet werden Kunden, die in die Zehntausende gehen. Die Daten sind sofort verfügbar – und liefern Einblicke – überall.

Siehe auch: Cloud-Akzeptanztrends von 2021 verstärken sich im Jahr 2022

Das Ziel erkunden

Cloud-nativ ist ein Begriff, der viel herumgeworfen wird, aber er hat eine echte Bedeutung, wenn Softwarearchitektur von Grund auf neu entwickelt wird, um die Vorteile der verteilten Cloud zu nutzen. Ein vollständig realisiertes Cloud-natives Data Warehouse sollte logischerweise eine verteilte Daten-Cloud-Architektur nutzen. Im weitesten Sinne bringt dies Analysen zu den Daten, wo immer sie sich befinden (nicht umgekehrt), verringert das Konzentrationsrisiko, erhöht die Effizienz drastisch und leitet eine Modernisierung für kontrollierte Ausgaben und einen Wettbewerbsvorteil ein.

Genauer gesagt, eine Cloud-native Datenverwaltungs- und Analysetechnologie sollte fünf Hauptmerkmale aufweisen, die mit dem Entwurf einer verteilten Datenwolke in Einklang stehen:

• Eine plattformunabhängige Laufzeit, die die Bereitstellung von Daten und Analysen überall ermöglicht
• Überall eine gemeinsame Benutzererfahrung
• Gemeinsame Sicherheits- und Governance-Funktionen auf jedem Bereitstellungsziel
• Kosten- und Technologieeffizienz überall, Minimierung von Ressourcen und Ermöglichung eines starken Kostenmanagements (FinOps) und Ausgabenbegrenzungen
• Eine einzige Steuerungsebene, die alle Bereitstellungen miteinander verbindet, in der öffentlichen Cloud, vor Ort und am Netzwerkrand

Ein vollständig realisiertes Cloud-natives Data Warehouse, das diesem Muster folgt und überall dort eingesetzt werden kann, wo es benötigt wird, wird auch die Komplexität der Cloud-, On-Premises- und Network-Edge-Infrastruktur von den Endbenutzern abstrahieren. Der Punkt ist, sie von Infrastrukturdetails zu befreien und es ihnen zu ermöglichen, sich auf die Generierung von Wert aus Analysen und die Verwaltung von Daten zu konzentrieren und gleichzeitig die native Leistungsfähigkeit der Cloud zu vermitteln.

Die Wahl des richtigen Reiseführers

Also, wie wird dieses Ziel erreicht? Kubernetes, das Open-Source-Container-Orchestrierungstool, bietet den beliebtesten Weg zu Cloud-nativen Operationen. Während die Idee der Partitionierung von Workloads in Unix seit den 1970er Jahren existiert, wurden Container erst vor etwa einem Jahrzehnt in großem Umfang implementiert, um die Anwendungsentwicklung einfacher, portabler und effizienter in der Ressourcennutzung zu machen. Aber die Bereitstellung von Hunderten oder Tausenden von Anwendungen in einer riesigen Microservices-Architektur erwies sich als äußerst schwierig. Während es andere Optionen gibt, gewann das Open-Source-Kubernetes-Projekt von Google, das jetzt von der Cloud Native Computing Foundation verwaltet wird, an Bedeutung, um die Orchestrierung von Microservices-Anwendungen zu lösen – Anwendungen können auf einer generischen Infrastruktur ausgeführt, auf standardmäßige Weise überwacht und verwaltet und mit authentifiziert werden offene Standards.

Das ist gut und gut für Bewerbungen. Aber was ist mit der Welt der Daten? Dieselbe grundlegende Container-Orchestrierung ist für Cloud-native Data Warehouses erforderlich, um Elastizität und Bereitstellungsflexibilität über öffentliche und private Clouds, Netzwerk-Edge-, Hybrid- und vollständig verteilte Clouds hinweg zu bieten.

Die Cloud-native Neuarchitektur für Scale-out-Webanwendungen ist an der Tagesordnung, aber Datenbanken wurden meist nur in die Cloud-native Welt „gehoben und verschoben“. Das Plonen einer Datenbank in einen Container ermöglicht die Ausführung in einer modernen Infrastruktur, bietet jedoch keine Erfahrung, die alle Vorteile der Cloud demonstriert. Dass sie in einer Containerumgebung läuft, ist der Software weitgehend unbekannt, und Operationen wie das Verwalten von elastischen Clustern müssen umständlich von außerhalb der Datenbank per Hand mit Operatoren und dem Hacken von Helm-Charts erledigt werden. Funktionen wie die Möglichkeit, dass mehrere elastische On-Demand-Rechencluster dieselben zugrunde liegenden Daten im Objektspeicher gemeinsam nutzen können, sind häufig nicht verfügbar. Benutzer, die geschäftlichen Nutzen aus einem elastischen, Cloud-basierten Data Warehouse ziehen möchten, wollen nichts über Helm-Diagramme, Pods, Knoten oder Konfigurationsdateien wissen. Sie möchten nur Data Warehouses bereitstellen, elastische Cluster verwalten und Erkenntnisse aus ihren Daten gewinnen.

Die Bereitstellung einer SQL-Schnittstelle über Kubernetes zur Bereitstellung mehrerer elastischer Cluster nach Bedarf und zum Verbergen der Kubernetes-Komplexität vor DBAs und Endbenutzern ist die Antwort.

Auf diese Weise können verschiedene Benutzer zugewiesen werden, um Workloads auf verschiedenen Compute-Clustern auszuführen, und der verwendete Compute-Cluster kann zur Laufzeit über SQL geändert werden, vorbehaltlich einer Genehmigung. Cluster können so konfiguriert werden, dass sie nach einer Leerlaufzeit automatisch angehalten und bei Bedarf wieder hochgefahren werden. Beispielsweise könnte ein separater Rechencluster erstellt werden, um bei Bedarf ETL-Prozesse auszuführen, einer für Ad-hoc-Business-Intelligence (BI) und mehrere Data-Science-Cluster. Compute-Cluster können in Zeiten starker Nutzung online erweitert oder in Ruhezeiten abgeschaltet werden, um Geld zu sparen. Cluster können erstellt werden, um tägliche, wöchentliche oder monatliche Stapelberichtsaufgaben auszuführen, die nur während dieser Zeiträume aktiv sind. Sowohl die Größe der Knoten im Compute-Cluster als auch die Anzahl der Knoten sind in diesem Modell steuerbar, und aus Gründen der Vorhersagbarkeit können auf Instanzebene Grenzen für den Ressourcenverbrauch festgelegt werden. Ebenso ist es möglich, ein kostengünstiges Replikatsystem einzurichten, das Replikationsdatenverkehr von einer primären Data Warehouse-Instanz empfängt, die dann bei Bedarf hochskaliert werden kann, wenn das Replikat verwendet werden muss.

Diese Art von Elastizität wird nicht nur durch eine tiefe Integration mit Kubernetes implementiert, sondern durch die Verwendung von SQL selbst als „Benutzeroberfläche“ zum Erstellen, Anhalten, Fortsetzen und Verwalten von Clustern anstelle von Entwicklertools. Kubernetes ist die maßgebliche Quelle der Wahrheit für den Zustand aller Cluster. Systemansichten, die den Status der Cluster anzeigen, beziehen ihre Daten von Kubernetes mithilfe seiner APIs. Wenn SQL-Anweisungen für die Clusterverwaltung eingegeben werden, wendet sich das Cloud-native Data Warehouse an Kubernetes, um den gewünschten Status einer Instanz zu ändern. Kubernetes implementiert dann die notwendigen Änderungen. Wenn ein Knoten im Cluster fehlerhaft wird, bringt Kubernetes einen Ersatz online.

Dies stellt eine einzigartige, von innen nach außen gerichtete Beziehung zu Kubernetes dar:Anstatt dass Kubernetes die „Benutzeroberfläche“ zum Steuern des Zustands des Clusters ist, wird die Datenbank selbst, die von Kubernetes verwaltet wird, zur Benutzeroberfläche. Diese Architektur schafft eine symbiotische Beziehung, die ein einzigartiges, vollständig realisiertes Cloud-Erlebnis bietet. Die Leistung und plattformübergreifende Flexibilität von Kubernetes wird für ein Data Warehouse verfügbar, das vollständig durch SQL gesteuert wird.

Da immer mehr Daten generiert und mehr Anwendungsfälle bereitgestellt werden, geraten Unternehmen leicht in einen Teufelskreis, in dem sich ihr Ökosystem zunehmend in einer bestimmten Cloud festsetzt. Systemrisiken können in dieser einzelnen Cloud entstehen, die für kritische IT-Infrastrukturen in stark regulierten Sektoren wie Finanzdienstleistungen und Versicherungen zu viel Risiko darstellt. Die Architektur mit Kubernetes ist nicht das einzige Kernkonzept, das ein vollständig realisiertes Cloud-natives Data Warehouse zum Leben erweckt. Es ist nicht die einzige Architekturkomponente, die auf das Muster der verteilten Datenwolke ausgerichtet ist. Aber es ist das unverzichtbare Herzstück, das Datenanalysen außergewöhnlich flexibel macht und überall dort ausgeführt werden kann, wo es geschäftlich erforderlich ist – und dies in großem Umfang und mit hoher Parallelität, Leistung, Effizienz und Verfügbarkeit. Das Ergebnis ist, dass Tausende von Benutzern in jedem beliebigen Unternehmen, über verschiedene Geschäftsbereiche und geografische Regionen hinweg, extrem schnelle Entscheidungen treffen und nahezu in Echtzeit einen Mehrwert aus laufenden Analysen generieren können.