Skalieren von Analysen auf Cloudebene in Azure
Eine skalierbare Datenplattform ist entscheidend, um die schnelle Zunahme der Datenmengen zu unterstützen. Jede Sekunde werden auf der Welt große Datenmengen generiert. Die Menge der verfügbaren Daten wird in den nächsten Jahren voraussichtlich weiter exponentiell ansteigen. Da sich die Datengenerierungsrate erhöht, erhöht sich auch die Geschwindigkeit der Datenverschiebung.
Benutzer möchten schnell Abfrageantworten erhalten – ganz gleich, wie viele Daten Sie haben. Sie möchten Ergebnisse innerhalb von Minuten erhalten und nicht mehrere Stunden auf sie warten. In diesem Artikel erfahren Sie, wie Sie Ihre Azure-Analyselösung auf Cloudebene skalieren können, um auch weiterhin die Geschwindigkeitsanforderungen der Benutzer zu erfüllen.
Einführung
Viele Unternehmen verfügen über große monolithische Datenplattformen. Diese Monolithen werden um ein einzelnes Azure Data Lake Gen2-Konto und manchmal ein einzelner Speichercontainer aufgebaut. Ein einzelnes Azure-Abonnement wird häufig für alle datenplattformbezogenen Aufgaben verwendet. Die Skalierung der Abonnementebene ist in den meisten architekturbasierten Plattformen nicht vorhanden, wodurch die Fortsetzung der Azure-Einführung verhindert werden kann, wenn Benutzer in einem der Azure-Abonnement- oder Dienstebenenbeschränkungen ausgeführt werden. Einige der Einschränkungen sind zwar weiche Grenzwerte, trotzdem kann es erhebliche negative Auswirkungen auf Ihre Datenplattform haben, wenn sie erreicht werden.
Berücksichtigen Sie bei der Strukturierung Ihrer Datenplattform die Struktur Ihrer Organisation. Beachten Sie den Datenbesitz und die funktionsbezogene Zuständigkeiten Ihrer Teams. Wenn Ihr Unternehmen den Teams ein hohes Maß an Autonomie und verteilter Verantwortung zugesteht, ist eine Data Mesh-Architektur die beste Option.
Vermeiden Sie Situationen, in denen unterschiedliche Teams für die verschiedenen Aufgaben einer Lösung verantwortlich sind. Beispiele für solche Aufgaben wären etwa Erfassung, Bereinigung, Aggregation und Bereitstellung. Die Abhängigkeit von mehreren Teams kann zu erheblichen Geschwindigkeitseinbußen führen. Wenn Ihre Datenconsumer auf der Dienstebene beispielsweise neue Datenressourcen integrieren oder funktionsbezogene Änderungen für eine bestimmte Datenressource implementieren müssen, müssen sie einen mehrstufigen Prozess durchlaufen. In diesem Beispiel sind die Schritte:
- Der Datenconsumer übermittelt ein Ticket an jedes Team, das für eine Datenpipelinephase verantwortlich ist.
- Die Teams müssen synchron zusammenarbeiten, da die Ebenen miteinander verbunden sind. Für die neuen Dienste müssen Änderungen an der Datenbereinigungsschicht durchgeführt werden, die zu Änderungen an der Datenaggregationsschicht führen, was wiederum zu Änderungen an der Bereitstellungsschicht führt. Die Änderungen können sich auf jede Pipelinephase auswirken.
- Für die Teams ist es schwierig, die potenziellen Auswirkungen von Verarbeitungsänderungen zu erkennen, da sie keinen Überblick über den gesamten End-to-End-Lebenszyklus haben. Sie müssen gemeinsam einen klar definierten Releaseplan erstellen, der die Auswirkungen auf vorhandene Consumer und Pipelines minimiert. Diese Abhängigkeitsverwaltung erhöht den Verwaltungsaufwand.
- Die Teams sind in der Regel keine Experten für das Datenobjekt, das der Datenconsumer anfordert. Um neue Datasetfeatures oder Parameterwerte zu verstehen, müssen sie einen Experten konsultieren.
- Nach der Implementierung aller Änderungen wird der Datenconsumer benachrichtigt, dass das neue Datenobjekt verwendet werden kann.
Große Organisationen verfügen jeweils über Tausende von Datenconsumern. Ein komplizierter Prozess wie der hier beschriebene führt in großen Architekturen zu erheblichen Geschwindigkeitseinbußen, da zentralisierte Teams zu einem Engpass für Geschäftseinheiten werden. Dies resultiert in weniger Innovationen und eingeschränkter Effektivität. Geschäftseinheiten können ggf. entscheiden, den Dienst zu verlassen und stattdessen ihre eigene Datenplattform aufzubauen.
Methoden zur Skalierung
Analysen auf Cloudebene tragen mithilfe von zwei Kernkonzepten zur Bewältigung der Herausforderungen bei der Skalierung bei:
- Verwendung von Datenzielzonen für die Skalierung
- Verwendung von Datenprodukten oder Datenintegrationen für die Skalierung, um verteilten und dezentralen Datenbesitz zu ermöglichen
Sie können eine einzelne Datenzielzone oder auch mehrere Datenzielzonen bereitstellen. Datenzielzonen ermöglichen es Ihnen, Daten zu entdecken und zu verwalten, indem Sie eine Verbindung mit einer Zielzone für die Datenverwaltung herstellen. Jede Zielzone für die Datenverwaltung befindet sich in einem einzelnen Azure-Abonnement.
Abonnements sind Azure-Einheiten der Verwaltung, Abrechnung und Skalierung. Sie sind in Ihrem Plan für eine umfangreiche Azure-Einführung von entscheidender Bedeutung.
Skalierung mit Datenlandungszonen
Die zentralen Konzepte der Analysen auf Cloudebene sind die Datenverwaltungs-Zielzone und die Datenzielzone. Sie sollten jeweils in einem eigenen Azure-Abonnement platziert werden. Diese Trennung ermöglicht eine klare Aufgabentrennung, die Befolgung des Prinzips der geringsten Rechte und zumindest teilweise die Behandlung der weiter oben erwähnten Probleme auf Abonnementebene. Eine minimale Einrichtung der Analysen auf Cloudebene umfasst eine einzelne Datenzielzone und eine einzelne Datenverwaltungs-Zielzone.
Eine minimale Einrichtung reicht jedoch nicht für große Datenplattformbereitstellungen aus. Unternehmen bauen umfangreiche Plattformen auf und investieren nach und nach in eine konsistente und effiziente Skalierung ihrer Daten und Analysen. Zur Überwindung von Einschränkungen auf Abonnementebene werden bei Analysen auf Cloudebene Abonnements als Skalierungseinheit verwendet, wie unter Was ist eine Azure-Zielzone? erläutert. Dadurch können der Architektur weitere Datenzielzonen hinzugefügt werden, um die Datenplattform zu vergrößern. Die Einführung dieser Technik behandelt auch das Problem der Verwendung einer einzelnen Instanz von Azure Data Lake Gen2 für eine gesamte Organisation, da jede Datenzielzone drei Data Lakes beinhaltet. Projekte und Aktivitäten aus mehreren Bereichen können auf mehrere Azure-Abonnements verteilt werden, was eine bessere Skalierbarkeit ermöglicht.
Entscheiden Sie, wie viele Datenzielzonen Ihre Organisation benötigt, bevor Sie eine Analysearchitektur auf Cloudebene implementieren. Die richtige Entscheidung ist das Fundament einer effektiven und effizienten Datenplattform.
Wie viele Datenzielzonen benötigt werden, hängt von vielen Faktoren ab. Hierzu zählen insbesondere:
- Organisationsausrichtung (z. B. wie viele Geschäftseinheiten ihre eigene Datenzielzone benötigen)
- Betriebliche Überlegungen (z. B. wie Ihre Organisation Betriebsressourcen und geschäftsbereichsspezifische Ressourcen ausrichtet)
Die Verwendung eines geeigneten Datenzielzonenmodells minimiert den zukünftigen Aufwand bei der Verschiebung von Datenprodukten und -ressourcen zwischen Zielzonen. Außerdem lassen sich dadurch Big Data- und Analyseprojekte zukünftig effektiv und konsistent skalieren.
Berücksichtigen Sie bei der Entscheidung, wie viele Datenzielzonen bereitgestellt werden sollen, die folgenden Faktoren:
| Faktor | BESCHREIBUNG |
|---|---|
| Organisationsstruktur und Datenbesitz | Berücksichtigen Sie die Struktur Ihrer Organisation sowie die Zuständigkeit für Daten in Ihrer Organisation. |
| Region und Standort | Entscheiden Sie bei einer Bereitstellung in mehreren Regionen, von welchen Regionen die Datenzonen gehostet werden sollen. Erfüllen Sie alle Datenresidenzanforderungen. |
| Kontingente | Abonnementkontingente sind keine Kapazitätsgarantien und beziehen sich auf die jeweilige Region. |
| Datenhoheit | Aufgrund von Datenhoheitsbestimmungen müssen Daten in einer bestimmten Region gespeichert werden und regionsspezifischen Richtlinien folgen. |
| Azure-Richtlinien | Datenzielzonen müssen die Anforderungen verschiedener Azure-Richtlinien erfüllen. |
| Verwaltungsgrenze | Abonnements stellen eine Verwaltungsgrenze für Governance und Isolation bereit, wodurch eine klare Trennung von Zuständigkeiten erreicht wird. |
| Netzwerk | Jede Zielzone verfügt über ein virtuelles Netzwerk. Da sich ein virtuelles Netzwerk in einer einzelnen Region befindet, wird für jede neue Region eine neue Zielzone benötigt. Die virtuellen Netzwerke müssen virtuelle Peernetzwerke sein, um eine domänenübergreifende Kommunikation zu ermöglichen. |
| Grenzwerte | Für Abonnements gelten Grenzwerte. Durch die Verwendung mehrerer Abonnements lässt sich die Gefahr, diese Grenzwerte zu erreichen, minimieren. |
| Kostenzuteilung | Überlegen Sie, ob gemeinsam genutzte Dienste wie zentral bezahlte Speicherkonten nach Geschäftsbereichen oder Domänen aufgeteilt werden sollten. Die Verwendung eines separaten Abonnements erstellt eine Grenze für die Kostenzuweisung. Sie können die gleiche Funktionalität mithilfe von Tags erreichen. |
| Datenklassifizierungen und streng vertrauliche Daten | Sicherheitsmechanismen können sich auf die Datenproduktentwicklung und die Benutzerfreundlichkeit einer Datenplattform auswirken. Berücksichtigen Sie Datenklassifizierungen, und entscheiden Sie, ob streng vertrauliche Datasets eine besondere Behandlung erfordern, z. B. Just-In-Time-Zugriff, kundenseitig verwaltete Schlüssel (customer managed keys, CMK), differenzierte Netzwerkkontrollen oder mehr Verschlüsselung. |
| Sonstige rechtliche oder sicherheitsrelevante Aspekte | Berücksichtigen Sie, ob es sonstige rechtliche oder sicherheitsrelevante Aspekte gibt, die eine logische oder physische Trennung von Daten erfordern. |
Wenn Sie eine Data-Mesh-Architektur implementieren, müssen bei der Entscheidung, wie Sie Ihre Datenzielzonen und Datendomänen verteilen, folgende Faktoren berücksichtigt werden:
| Faktor | BESCHREIBUNG |
|---|---|
| Datendomänen | Berücksichtigen Sie die von Ihrer Organisation verwendeten Datendomänen, und entscheiden Sie, welche sich auf Ihrer Datenplattform befinden sollen. Berücksichtigen Sie die Größe Ihrer einzelnen Datendomänen. Weitere Informationen finden Sie unter Was sind Datendomänen?. |
| Latency | Domänen, die an großen Datenmengen zusammenarbeiten, können große Datenmengen über Zielzonen hinweg übertragen. Ziehen Sie die Zuweisung Ihrer Domänen in derselben Zielzone oder Region in Betracht. Ihre Trennung erhöht die Wartezeit und kann die Kosten in regionsübergreifenden Domänen erhöhen. |
| Sicherheit | Einige Dienstbereitstellungen oder Konfigurationen erfordern erhöhte Rechte in einem Abonnement. Wenn einem Benutzer diese Rechte in einer Domäne gewährt werden, erhält er implizit die gleichen Rechte in anderen Domänen innerhalb desselben Abonnements. |
Weitere Überlegungen finden Sie im Leitfaden zur Cloud-Einführung für Abonnements.
Viele Organisationen benötigen eine effiziente Skalierung für ihre Unternehmensdatenplattform. Geschäftseinheiten sollten ihre eigenen Datenlösungen und -anwendungen erstellen können, um ihre individuellen Anforderungen zu erfüllen. Die Bereitstellung dieser Fähigkeit kann eine Herausforderung sein, da viele vorhandene Datenplattformen nicht auf den Konzepten der Skalierbarkeit und des dezentralen Besitzes aufgebaut sind. Dieses Manko zeigt sich deutlich in der Architektur, der Teamstruktur und dem Betriebsmodell dieser Datenplattformen.
Datenzielzonen erstellen keine Datensilos innerhalb Ihrer Organisation. Die empfohlene Netzwerkkonfiguration für Analysen auf Cloudebene ermöglicht einen sicheren und direkten Datenaustausch über Zielzonen hinweg, was wiederum Innovationen über Datendomänen und Geschäftseinheiten hinweg ermöglicht. Weitere Informationen finden Sie unter Überlegungen zur Netzwerkarchitektur.
Das gleiche gilt für die Identitätsebene. Wenn Sie einen einzigen Microsoft Entra-Mandanten verwenden, können Sie Identitäten Zugriff auf Datenbestände in mehreren Datenzielzonen gewähren. Weitere Informationen zum Benutzer- und Identitätsautorisierungsprozess finden Sie unter Bereitstellen von Sicherheit für Analysen auf Cloudebene in Azure.
Hinweis
Wenn Sie über mehrere Datenzielzonen verfügen, kann jede Zone eine Verbindung mit Daten in anderen Zonen herstellen. Dadurch können Gruppen in Ihrem Unternehmen zusammenarbeiten.
Analysen auf Cloudebene verwenden eine gemeinsame Architektur, um konsistente Governance zu fördern. Ihre Architektur definiert grundlegende Funktionen und Richtlinien. Alle Datenzielzonen unterliegen der gleichen Überwachung und denselben Kontrollen. Ihre Teams können Datenpipelines erstellen, Quellen erfassen und Datenprodukte, z. B. Berichte und Dashboards, erstellen. Teams können außerdem nach Bedarf Spark-/SQL-Analysen durchführen. Sie können die Funktionen der Datenzielzonen erweitern, indem Sie ihnen in der Richtlinie Dienste hinzufügen. Ein Team kann z. B. eine Graph-Engine eines Drittanbieters hinzufügen, um eine geschäftliche Anforderung zu erfüllen.
Bei Analysen auf Cloudebene sind eine zentrale Katalogisierung und Klassifizierung wichtig, um Daten zu schützen und verschiedenen Gruppen das Auffinden von Datenprodukten zu ermöglichen.
Achtung
Wir empfehlen, Daten nicht regionsübergreifend abzufragen. Stellen Sie stattdessen sicher, dass sich die Daten in der Nähe der Computeressource befinden, die sie verwendet. Beachten Sie dabei allerdings regionale Grenzen.
Die Architektur von Analysen auf Cloudebene und das Konzept der Datenzielzonen ermöglichen es Ihrer Organisation, die Größe der Datenplattform im Laufe der Zeit mühelos zu erhöhen. Sie können schrittweise weitere Datenzielzonen hinzufügen. Ihre Kunden müssen zunächst nicht über mehrere Zielzonen verfügen. Priorisieren Sie bei der Einführung dieser Architektur einige Datenzielzonen und die enthaltenen Datenprodukte. Eine ordnungsgemäße Priorisierung trägt zum Erfolg Ihrer Bereitstellung von Analysen auf Cloudebene bei.
Skalierung mit Datenprodukten oder Datenintegrationen
Innerhalb der einzelnen Zielzonen kann Ihre Organisation mithilfe von Datenanwendungen skalieren. Datenanwendungen sind Einheiten oder Komponenten Ihrer Datenarchitektur, die Funktionen kapseln, die leseoptimierte Datenprodukte für die Nutzung durch andere Datenanwendungen bereitstellen. In Azure sind Datenanwendungen Umgebungen in Form von Ressourcengruppen, mit denen funktionsübergreifende Teams Datenlösungen und Workloads implementieren können. Ein zugeordnetes Team kümmert sich um den End-to-End-Lebenszyklus der Datenlösung. Dies umfasst Erfassungs-, Bereinigungs-, Aggregations- und Bereitstellungsaufgaben.
Analysen auf Cloudebene tragen zur Behandlung der weiter oben erläuterten Probleme im Zusammenhang mit Datenintegration und -zuständigkeit bei. Anstelle von monolithischen funktionalen Zuständigkeiten für die Tabellenerfassung und die Quellsystemintegration bietet das Referenzdesign eine verteilte, von Datendomänen gesteuerte Architektur. Funktionsübergreifende Teams übernehmen die funktionale End-to-End-Verantwortung und sind für den Datenbereich zuständig.
Anstelle eines zentralisierten technischen Stapels und eines Teams, das für alle Aufgaben Ihres Datenverarbeitungsworkflows verantwortlich ist, können Sie die End-to-End-Verantwortung auf mehrere autonome, funktionsübergreifende Datenintegrationsteams verteilen. Jedes Team ist für eine Domänen- oder Unterdomänenfunktion zuständig und kann Datasets nach Bedarf für Datenconsumer bereitstellen.
Diese architektonischen Unterschiede führen zu einer erhöhten Geschwindigkeit innerhalb Ihrer Datenplattform. Ihre Datenconsumer sind nicht mehr von einer Reihe zentralisierter Teams abhängig und müssen nicht mehr um die Priorisierung ihrer angeforderten Änderungen kämpfen. Da kleinere Teams Ihren End-to-End-Integrationsworkflow übernehmen, ist die Feedbackschleife zwischen Datenanbieter und Datenconsumer viel kürzer. Dieser Ansatz sorgt für eine schnellere Priorisierung, schnellere Entwicklungszyklen und einen agileren Entwicklungsprozess. Ihre Teams müssen Prozesse und Releasepläne nicht mehr untereinander abstimmen, da das funktionsübergreifende Datenintegrationsteam einen umfassenden Überblick über den gesamten technischen Stapel und über die Auswirkungen von Änderungen hat. Es kann Softwareentwicklungsmethoden anwenden, um Komponenten- und Integrationstests durchzuführen und so die Auswirkungen auf die Consumer insgesamt zu minimieren.
Im Idealfall ist das für die Datenintegrationssysteme zuständige Team auch für die Quellsysteme zuständig. Dieses Team sollte Datentechniker, die an den Quellsystemen arbeiten, fachliche Ansprechpartner (subject matter experts, SMEs) für die Datasets, Cloudtechniker und Datenproduktverantwortliche umfassen. Der Aufbau eines solchen funktionsübergreifenden Teams reduziert die erforderliche Kommunikation mit externen Teams und ist für die Entwicklung Ihres gesamten Stacks (von der Infrastruktur bis zu den eigentlichen Datenpipelines) unerlässlich.
Die Grundlage Ihrer Datenplattform sind Datasets, die aus den Quellsystemen integriert werden. Diese Datasets ermöglichen es Ihren Datenproduktteams, geschäftliche Faktentabellen zu überarbeiten und die Entscheidungsfindung und Geschäftsprozesse zu verbessern. Ihre Datenintegrationsteams und Ihre Datenproduktteams sollten Kunden SLAs anbieten und sicherstellen, dass alle Vereinbarungen eingehalten werden. Die angebotenen SLAs können sich auf Datenqualität, Aktualität, Fehlerraten, Uptime und andere Aufgaben beziehen.
Zusammenfassung
Durch die Nutzung der Skalierungsmechanismen Ihrer Architektur für Analysen auf Cloudebene kann Ihre Organisation ihren Datenbestand innerhalb von Azure im Laufe der Zeit erweitern und dabei bekannte technische Einschränkungen vermeiden. Beide in diesem Artikel beschriebenen Skalierungsmethoden helfen Ihnen dabei, verschiedene technische Komplexitäten zu überwinden, und können auf einfache und effiziente Weise eingesetzt werden.