Phase 2: Strategie für den Arbeitsbereichsentwurf

In dieser Phase entwerfen Sie Ihre Arbeitsbereichsarchitektur so, dass sie sich an die Struktur, die Sicherheitsanforderungen und die betrieblichen Anforderungen Ihrer Organisation richtet.

Arbeitsbereiche verstehen

Ein Azure Databricks-Arbeitsbereich ist die operative Grenze in einer Cloudregion, in der Teams Workloads entwickeln und ausführen. Sie enthält Artefakte für die Zusammenarbeit (z. B. Notizbücher, Aufträge, Dashboards und Repositorys) und Arbeitsbereichskonfigurationen, z. B. Arbeitsbereichsberechtigungen, Clusterrichtlinien, Geheime und SQL-Konfigurationen. Der Arbeitsbereich ist eine Ausführungs- und Zusammenarbeitsumgebung. Persistente Daten werden in der Regel in Clouddiensten gespeichert, z. B. Objektspeicher.

Administratoren erstellen und konfigurieren Arbeitsbereiche basierend auf den Zielen ihrer Organisation. Einige verwenden einen einzelnen Arbeitsbereich, während andere durch Domäne, Umgebung (Dev/Test/prod), Branchen-, Geografie- oder regulatorische Grenzen getrennt sind. Diese Auswahlmöglichkeiten bestimmen den Administrativen Radius, die Trennung von Aufgaben, die Kostenzuordnung und die Häufigkeit der Replikation. Mit einem kleinen Start mit Azure Databricks erfordert nur eine minimale Konfiguration, aber größere Bereitstellungen sollten zukünftige Anforderungen berücksichtigen und wie diese Ihre Fähigkeit zum Schutz von Daten beeinflussen, während sie gleichzeitig Teams ermöglichen.

Arbeitsbereichsstrategiediagramm.

Auswählen des Bereitstellungsmodells für Arbeitsbereiche

Es stehen zwei Arten von Azure Databricks-Arbeitsbereichen zur Verfügung:

Serverlose Arbeitsbereiche

Eine Arbeitsbereichsbereitstellung in Ihrem Azure Databricks-Konto, die mit serverlosem Compute und vordefiniertem Speicher vorkonfiguriert ist, um ein vollständig serverloses Erlebnis bereitzustellen.

Merkmale des serverlosen Arbeitsbereichs

  • Standardspeicher: Cloudspeicher im Cloudkonto von Azure Databricks in derselben Region wie der Arbeitsbereich.
    • Sie können weiterhin über serverlose Arbeitsbereiche eine Verbindung mit Ihrem Cloudspeicher herstellen.
  • Serverlose Berechnung: Vorkonfiguriert und sofort verfügbar.
  • Schneller Start: Keine Infrastrukturbereitstellung erforderlich.
  • Automatische Skalierung: Skaliert mit Workload-Nachfrage.

Klassische Arbeitsbereiche

Eine Arbeitsbereichsbereitstellung in Ihrem Azure Databricks-Konto, die Speicher- und Computeressourcen in Ihrem vorhandenen Cloudkonto bereitstellt. Serverloses Computing und Dienstangebote sind weiterhin in klassischen Workspaces verfügbar.

Merkmale des klassischen Arbeitsbereichs

  • Vom Kunden verwalteter Speicher: Speicher in Ihrem Cloudkonto.
  • Vom Kunden verwaltete Rechenressourcen: Computeinfrastruktur in Ihrem Cloudkonto.
  • Netzwerksteuerung: Vollständige Kontrolle über die VPC/VNet-Konfiguration.
  • Flexibilität: Serverlose Berechnung kann weiterhin zusammen mit der klassischen Berechnung verwendet werden.

Empfehlungen für das Bereitstellungsmodell für Arbeitsbereiche

Verwenden Sie diese Empfehlungen, um zu entscheiden, ob sie einen serverlosen oder klassischen Arbeitsbereich für Ihr Szenario bereitstellen möchten:

  • Vergewissern Sie sich, dass die Region, die Sie verwenden möchten, serverlose Arbeitsbereiche und serverlose Berechnung unterstützt, wenn Sie serverlos verwenden möchten.
  • Überprüfen Sie die Serverlosen Arbeitsbereichseinschränkungen, um sicherzustellen, dass sie Ihren Anforderungen entsprechen.
  • Bewerten Sie Ihre primären Anwendungsfälle (z. B. automatische Skalierung im Vergleich zu feinkörnigen Clustersteuerelementen), und wählen Sie serverlose oder klassische Arbeitsbereiche entsprechend aus.
  • Empfehlung: Beginnen Sie mit serverlosen Arbeitsbereichen für die betriebliche Effizienz.
  • Verwenden Sie klassische Arbeitsbereiche, wenn: Sie benötigen benutzerdefinierte Netzwerkkonfigurationen, lokale Konnektivität oder bestimmte Complianceanforderungen.

Strategie zur Aufteilung des Entwurfsarbeitsbereichs

Es gibt mehrere Gründe, ein Seehaus-Setup in verschiedene Arbeitsbereiche aufzuteilen. Berücksichtigen Sie diese Muster beim Entwerfen Ihrer Arbeitsbereichsarchitektur.

Gründe für das Teilen von Arbeitsbereichen

Isolieren von Arbeitsbereichen basierend auf Datenschutzanforderungen

Für stark regulierte Branchen mit strikter Durchsetzung der Datentrennung isolieren Sie Arbeitsbereiche, um die Implementierung von Kontrollen für vertrauliche Daten zu vereinfachen, ohne die Arbeitsströme mit geringerem Risiko zu beeinträchtigen.

Isolieren verschiedener Geschäftseinheiten

Stellen Sie sicher, dass keine Arbeitsbereichsressourcen in Azure Databricks zwischen Geschäftseinheiten gemeinsam verwendet werden, wenn Organisationsgrenzen eine vollständige Isolierung erfordern.

Isolieren von Teams mit unterschiedlichen Plattformanforderungen

Wenn verschiedene Teams Zugriff auf verschiedene Gruppen von Plattformfeatures benötigen (z. B. voller Zugriff auf alle Features für ein Zentraladministrationsteam, aber nicht für andere Teams oder Plattformtests), sollten diese Teams durch Arbeitsbereiche getrennt werden.

SDLC-Umgebungen im Softwareentwicklungslebenszyklus isolieren

Trennen Sie Dev-, Staging- und Prod-Umgebungen, wenn Sie strenge Isolationsanforderungen haben. Beispiel:

  • Einige Organisationen stellen Dev/Staging/Prod-Umgebungen in verschiedenen virtuellen Netzwerken bereit, sodass separate Arbeitsbereiche für jede Umgebung erforderlich sind.
  • Um neue Arbeitsbereichseinstellungen zu testen, bevor sie auf Prod angewendet werden (z. B. Aktivieren oder Einschränken von Features), muss Prod ein anderer Arbeitsbereich als Dev oder Staging sein.
  • Viele Unternehmen isolieren diese Umgebungen auch aus einer Speicher- und Computeperspektive, indem verschiedene Speichercontainer, virtuelle Netzwerke und Azure Databricks-Arbeitsbereiche verwendet werden.

Arbeiten in mehreren Cloudregionen

Wenn eine Organisation Benutzern dient oder Daten in mehreren Ländern oder Regionen sammelt, können Vorschriften oder interne Richtlinien erfordern, dass bestimmte Daten in der Region verbleiben, was die Notwendigkeit separater Arbeitsbereiche steuert, die in jeder Cloudregion bereitgestellt werden, die diese Daten verarbeiten oder speichern. Durch das Teilen von Arbeitsbereichen pro Region können Teams Azure Databricks-Bereitstellungen mit lokalen Speicherkonten und virtuellen Netzwerken ausrichten und gleichzeitig allgemeine Unternehmensstandards für Governance und Sicherheit befolgen.

Regionale Arbeitsbereiche tragen auch dazu bei, die Latenz für interaktive Analysen und Datenanwendungen zu verringern, indem Sie die Berechnung näher an lokale Benutzer und Datenquellen platzieren, wodurch die Benutzerfreundlichkeit und Abfrageleistung verbessert werden.

Aufteilen, um Ressourcenbeschränkungen zu überwinden

Cloudkonten (oder Abonnements) weisen Ressourcenbeschränkungen auf. Das Bereitstellen von Arbeitsbereichen in verschiedenen Konten ist eine Möglichkeit, sicherzustellen, dass ausreichende Ressourcen für jeden Arbeitsbereich verfügbar sind. Es gibt auch Beschränkungen in jedem Azure Databricks-Arbeitsbereich, z. B. die Anzahl der Aufgaben, die gleichzeitig oder die maximale Anzahl von Azure Databricks-Apps ausgeführt werden können. Durch das Teilen von Arbeitsbereichen wird sichergestellt, dass Arbeitsauslastungen in jedem Arbeitsbereich Zugriff auf weitere Ressourcen haben.

Ressourcenbeschränkungen für Cloudanbieter

Grenzwerte für Azure-Arbeitsbereiche

Um Grenzwerte auf Abonnementebene zu überwinden (z. B. maximale Speicherkonten oder maximale Anforderungsraten pro Sekunde), sollten Arbeitsbereiche mit hohen Ressourcenanforderungen in separaten Azure-Abonnements bereitgestellt werden.

Wichtige Grenzwerte

  • Azure-Abonnements und Dienstbeschränkungen.
  • Beschränkungen für Azure Databricks-Arbeitsbereiche.

Überlegungen für geteilte Arbeitsbereiche

Einschränkungen bei der Zusammenarbeit

Es gibt keine Notizbuchfreigabe (Zusammenarbeit) übergreifend über Arbeitsbereiche. Verwenden Sie Unity Catalog über Arbeitsbereiche hinweg, um die Datenfreigabe wo immer möglich zu erleichtern. Code kann mithilfe von GitHub über Arbeitsbereiche hinweg freigegeben werden.

Verwaltungsaufwand

Der Verwaltungsaufwand für eine große Anzahl von Arbeitsbereichen kann erheblich werden. Häufig können 100+ Arbeitsbereiche versehentlich zu verwaisten oder nicht verwalteten Arbeitsbereichen führen, die ein Kosten- und/oder Exfiltrationsrisiko darstellen können.

Automatisierungsanforderung

Für mehrere Arbeitsbereiche müssen sowohl Die Einrichtung als auch die Wartung vollständig automatisiert sein (mit Tools wie Terraform, cloudspezifischen Tools oder der REST-API). Dies ist besonders wichtig für Mobilitätszwecke und Notfallwiederherstellungsszenarien, in denen schnelle Bereitstellung von Arbeitsbereichen, Failover und Konfigurationsreplikation über Regionen oder Clouds hinweg wichtige betriebliche Anforderungen sind.

Kosten der Netzwerkinfrastruktur

Wenn jeder Arbeitsbereich auf der Netzwerkebene gesichert werden muss (z. B. zum Schutz vor Datenexfiltration), kann die erforderliche Netzwerkinfrastruktur sehr teuer werden, wenn Sie Hunderte von Arbeitsbereichen haben.

Featurebeschränkungen

Einige Features verfügen über eingeschränkte Arbeitsbereichsunterstützung, z. B. serverloses Berechnen mit serverlosen Ausgangssteuerelementen, die auf verwaltete Dienste des Unity-Katalogs zugreifen. Bestimmte Features wie KI-Features, Azure Private Link und Verschlüsselungsschlüssel werden auf Arbeitsbereichsebene definiert. Wenn das Unternehmen unterschiedliche Sicherheitssetups für andere Teams benötigt, definiert die Genehmigung dieser Features die Arbeitsbereichsteilung.

SDLC- und Geschäftseinheitsmatrix

Wenn Sie Arbeitsbereiche für Dev/Staging/Prod trennen und auch Geschäftseinheiten nach Arbeitsbereich trennen möchten, sollten Sie die Arbeitsbereichsgrenzen der verschiedenen Cloudanbieter berücksichtigen. Die Matrix kann schnell zu einer großen Anzahl von Arbeitsbereichen führen.

Grundlegendes zu Arbeitsbereichssicherheitsmodi

Arbeitsbereiche, die dem Unity-Katalog zugewiesen sind, unterstützen die folgenden Zugriffsmodi für Cluster:

Sicherheitsmodus Merkmale
Standard Mehrere Benutzer können an demselben Cluster arbeiten. Geeignet für allgemeine Workloads (z. B. ETL, Datensuche). Unterstützt nur SQL, Python und Scala. Unterstützt eine feinkörnige Zugriffssteuerung (FGAC), einschließlich ansichtsbasierter Berechtigungen und attributbasierter/tabellenbasierter Zugriffssteuerung (ABAC). Keine Unterstützung für machine Learning ML DBR (aber viele ML-Bibliotheken können auf dem Standard-DBR installiert werden).
Dediziert Unterstützt ML DBR und alle Sprachen. Reserviert für einen einzelnen Benutzer: Cluster kann nur von einem Benutzer (während der Clustererstellung zugewiesen) zugegriffen werden. Reserviert für eine einzelne Gruppe: Mehrere Benutzer derselben Gruppe können an demselben Cluster arbeiten (die Gruppe wird während der Clustererstellung zugewiesen).

Beispiele für Bereitstellungen von Arbeitsbereichen

Bei den ersten Schritten mit Azure Databricks stellen die meisten Organisationen ein Single-Tenant Lakehouse in einer einzelnen Cloudregion bereit. Da Ihre Organisation jedoch wächst, können Administratoren ihre Bereitstellungen so anpassen, dass sie ihren komplexen Anwendungsfällen entsprechen.

Einmandantenbereitstellung, Ein-Region-Bereitstellung

  • Ein Produktionsarbeitsbereich.
  • Ein Entwicklungsarbeitsbereich.
  • Alle Ressourcen in einer einzelnen Cloudregion.

Bereitstellung über mehrere Regionen hinweg

  • Produktionsarbeitsbereich in der REGION USA.
  • Produktionsarbeitsbereich in der EU-Region (für DSGVO-Compliance).
  • Freigegebener Entwicklungsarbeitsbereich.
  • Unity Catalog Metastore pro Region mit D2D-Delta-Sharing für regionsübergreifenden Datenzugriff.

Bereitstellung von Multi-Business-Einheiten

  • Ein Arbeitsbereich pro Geschäftseinheit (z. B. Vertrieb, Marketing, Engineering).
  • Freigegebener Entwicklungsarbeitsbereich für alle Teams.
  • Zentraler Unity-Katalog-Metastore mit Katalogebenen-Segregation.

Umgebungsbasierte Bereitstellung

  • Produktionsarbeitsbereich (alle Geschäftseinheiten).
  • Staging-Arbeitsbereich (Vorproduktionstests).
  • Entwicklungsarbeitsbereich (gemeinsame Entwicklung).
  • Trennen Sie Netzwerke und Speicher für jede Umgebung.

Definieren von Benennungskonventionen für Arbeitsbereiche

Richten Sie eine einheitliche Benennungskonvention für Arbeitsbereiche ein, um die Auffindbarkeit und Verwaltung zu verbessern.

Empfohlenes Benennungsmuster

{organization}-{environment}-{region}-{purpose}

Beispiele

  • acme-prod-us-west-analytics
  • acme-dev-shared
  • acme-prod-eu-west-gdpr
  • acme-staging-us-east-dataeng

Bewährte Methoden für die Benennung von Arbeitsbereichen

  • Verwenden Sie Kleinbuchstaben und Bindestriche.
  • Schließen Sie die Umweltbezeichnung ein (z. B. Prod, Staging, Dev).
  • Region für Bereitstellungen über mehrere Regionen hinweg einschließen.
  • Schließen Sie gegebenenfalls Geschäftseinheit oder Zweck ein.
  • Behalten Sie Namen unter 50 Zeichen bei.
  • Dokumentbenennungskonventionen in Ihrem Runbook.

Empfehlungen für Arbeitsbereichsstrategie

Recommended

  • Teilen Sie SDLC-Umgebungen in separate Arbeitsbereiche auf (mindestens Dev und Prod, aber möglicherweise mehr abhängig von den Anforderungen).
  • Verwenden Sie Automatisierungstools wie Terraform, wenn möglich, um menschliche Fehler zu minimieren und wiederholbare Bereitstellungsmuster einzurichten.
  • Beginnen Sie mit serverlosen Arbeitsbereichen, und wechseln Sie nur dann zu klassischen Arbeitsbereichen, wenn Sie bestimmte Netzwerk- oder Complianceanforderungen haben.
  • Strategie zur Aufteilung von Dokumentarbeitsbereichen und Namenskonventionen.
  • Erstellen Sie einen administrativen Arbeitsbereich pro Region zum Verwalten von Unity-Katalogressourcen.

Vermeiden Sie diese Muster

  • Erstellen Sie keine separaten Arbeitsbereiche für einzelne Teams oder kleine Projekte (verwenden Sie stattdessen Unity-Katalogkataloge und -Schemas zur Isolierung).
  • Stellen Sie nicht mehr als 50-100 Arbeitsbereiche ohne starke Begründung und robuste Automatisierung bereit.
  • Teilen Sie Arbeitsbereiche nicht unnötig auf (balancieren Sie den Bedarf an Isolation und die betriebliche Komplexität).
  • Vermeiden Sie die Ad-hoc-Arbeitsbereichserstellung, ohne die Benennungskonventionen zu befolgen.

Ergebnisse der Phase 2

Nach Abschluss der Phase 2 sollten Sie folgendes haben:

  • Ausgewähltes Arbeitsbereichsbereitstellungsmodell (serverlose und klassische Arbeitsbereiche).
  • Geteilte Arbeitsbereichsstrategie, die auf organisatorischen Anforderungen (z. B. Umgebung, Geschäftseinheit, Region, Compliance) ausgelegt ist.
  • Verständnis von Ressourcenlimits und Entschärfungsstrategien.
  • Definition der Benennungskonvention für Arbeitsbereiche.
  • Sicherheitsmodi verstanden (Standard vs dediziert).
  • Beispiel für die Bereitstellungsarchitektur, dokumentiert.
  • Geplante Automatisierungsstrategie für die Bereitstellung von Arbeitsbereichen.

Nächste Phase: Phase 3: Architektur des Unity-Katalogs entwerfen

  • Last updated on