Architektur für eine einheitliche Datenplattform

Dieser Artikel hilft Entscheidungsträgern, Architekturentscheidungen für ihre Azure-Zielzonen zu treffen, um eine einheitliche Datenplattform zu erstellen.

Organisationen müssen bestimmen, welche Updates ihre Plattform-Zielzone erfordert und wie Azure Workloads in die einheitliche Datenplattform integriert werden sollen. Ohne eine klare Architektur können Daten über Workloads und Plattformen hinweg isoliert bleiben oder ohne konsistente Governance und Sicherheit zwischen ihnen verschoben werden. Dieser Artikel enthält Anleitungen zum Aktualisieren der Plattform-Landing Zone und zum Entwerfen von Workload-Landing Zones, sodass Azure Workloads Daten für Microsoft Fabric erzeugen und verwaltete Daten daraus nutzen können.

Architekturen und Entscheidungsbaum

Konzeptionell

Konzeptionelle Architektur einer einheitlichen Datenplattform für KI und Analysen.

Detailliert

Detaillierte konzeptionelle Architektur einer einheitlichen Datenplattform für KI und Analysen.

Entscheidungsstruktur

Der Fluss stellt eine Reihe von Ja-or-no Fragen. Jedes "Ja" führt zu spezifischen Anleitungen. Die erste Frage stellt, ob die Organisation Hilfe beim Verständnis von Datenprioritäten oder beim Erstellen von Fähigkeiten benötigt, um mehr Wert von Daten zu erhalten. Wenn ja, besteht die Anleitung darin, Personen durch Rollen, Schulungen und Bereitschaftsaktivitäten vorzubereiten. Die zweite Frage stellt fest, ob die Organisation eine einheitliche Möglichkeit benötigt, um auf Daten über Clouds und Workloads hinweg zuzugreifen, um Analysen und KI zu unterstützen. Wenn ja, besteht die Anleitung darin, Microsoft Fabric als einheitliche Datenplattform zu verwenden. Die dritte Frage stellt fest, ob die Organisation Hilfe bei der Umwandlung von Betriebsdaten in Geschäftswert benötigt oder daten sicher in KI-Systeme wie Microsoft Foundry einspeist. Wenn ja, besteht die Anleitung darin, Azure-Dienste in Fabric zu integrieren. Die vierte Frage stellt fest, ob die Organisation Hilfe bei der Steuerung des Zugriffs auf Daten oder bei der konsistenten Sicherung von Daten benötigt. Wenn ja, besteht die Anleitung darin, Governance- und Sicherheitsgrundwerte mithilfe von Microsoft Purview und verwandten Steuerelementen festzulegen. Fünfte Frage stellt fest, ob die Organisation Hilfe bei der Festlegung konsistenter Organisatorischer Standards benötigt, um Datenprodukte für Analysen und KI zu verarbeiten, zu sichern und zu nutzen. Wenn ja, besteht die Anleitung darin, betriebliche Standards für Datenprodukte, Sicherheit und Lebenszyklusverwaltung festzulegen. Der Fluss endet, indem er auf die Einführung von KI und die Einführung von KI-Agents zeigt, sobald die einheitliche Datenplattform und -standards vorhanden sind.

Microsofts Entscheidungsbaum als Orientierungshilfe für Ihre einheitliche Datenplattform.

1. Azure-Zielzone

Wie sollten wir unsere Azure Landing Zone aktualisieren? Die einheitliche Datenplattform sollte die vorhandene Azure Landing-Zone-Architektur der Organisation verwenden. Die Organisation sollte keine separate Azure Architektur nur für Microsoft Fabric- oder Datenworkloads erstellen.

1.1. Plattform-Landingzone-Updates

Welche Änderungen sind für die Platform Landing Zone erforderlich? Die Plattform-Landing Zone sollte weiterhin die gemeinsam genutzten Azure-Funktionen bereitstellen, die in der gesamten Organisation verwendet werden. Die Organisation sollte ihre vorhandene Managementgruppenhierarchie beibehalten, es sei denn, eine neue behördliche, Sicherheits-, Datenhoheits- oder operative Anforderung erfordert einen anderen Richtlinienumfang.

Governance-Baseline: Das Plattformteam sollte jeden von der einheitlichen Datenplattform eingeführten Azure-Dienst anhand der vorhandenen Richtlinien-Baseline auswerten. Die Überprüfung sollte ermitteln, ob vorhandene Kontrollen gelten und ob zusätzliche Kontrollen erforderlich sind. Relevante integrierte Richtlinienverweise umfassen:

• Azure Databricks
• Azure Machine Learning
• Azure Data Lake Storage
• Virtuelle Computer (Compute)
• Zulässige Speicherorte

1.2. Workload-Zielzonen

Was sollten wir in Workload-Landing Zones setzen? Azure Ressourcen, die die einheitliche Datenplattform unterstützen, sollten sich in Workload-Landing Zones befinden, es sei denn, sie bieten eine zentrale Azure-Plattformfunktion, die von der Azure Landing-Zone-Architektur der Organisation definiert wird.

Service	Typische Anordnung von Verwaltungsgruppen
Microsoft Purview	Zielzone für interne Workload
Microsoft Fabric-Kapazität	Zielzone für interne Workload
Azure Workload (mit Nutzung eines Datenprodukts oder von KI)	Zielzone für interne, Online- oder lokale Workload
Azure Datenbanken	Zielzone für interne, Online- oder lokale Workload
Azure Databricks	Zielzone für interne Workload
Azure Machine Learning	Zielzone für interne Workload
Azure Data Lake-Speicher	Zielzone für interne Workload
KI-Infrastruktur (Schulungen/GPUs)	Zielzone für interne Workload

1.3 Fabric-Integration

Wie sollten Azure Workloads in Microsoft Fabric integriert werden? Azure Workloads sollten in Microsoft Fabric über genehmigte organisationsweite Muster integriert werden, um Daten über OneLake verfügbar zu machen und governierte Datenprodukte zu nutzen. Die Integration mit Fabric sollte die Platzierung der Workload nicht verändern.

Die Architektur sollte Datenprodukte unterstützen, die in Fabric erstellt wurden, und Datenprodukte, die über andere genehmigte Plattformen erstellt wurden, z. B. Azure Databricks. Das Integrationsmuster sollte das maßgebende Datensatzsystem identifizieren und unnötige Duplizierung von Verarbeitung oder Daten vermeiden. Siehe Azure Databricks Integration in OneLake und Azure Data Lake Storage (ADLS) Gen2-Verknüpfung.

Die Organisation sollte die unterstützten Integrationsmuster durch ihre betrieblichen Standards definieren.

2. Microsoft Fabric Architektur

Wie sollte die Organisation Microsoft Fabric konzipieren? Microsoft Fabric sollte die freigegebene Plattform bereitstellen, über die Datendomänen Datenprodukte erstellen, veröffentlichen und nutzen. Die Organisation sollte eine gemeinsame Fabric Architektur einrichten, bevor Datendomänen Produktionsdatenprodukte bereitstellen.

2.1 Fabric-Kapazitätsbereitstellung

Wie sollten wir Fabric Kapazitäten bereitstellen? Jede Datendomäne sollte ihre Fabric-Kapazitäten über das festgelegte Abonnement der Workload-Landingzone bereitstellen. Die Datendomäne sollte ihre Fabric Kapazität innerhalb ihres genehmigten Budgets und organisationsweiten Standards verwalten.

• Kapazitätsanforderungen: Eine Datendomäne sollte Fabric Kapazität hinzufügen, wenn vorhandene Ressourcen keine genehmigte Leistung, Isolation, regionale oder Lebenszyklusanforderung erfüllen können. Die Datendomäne sollte eine Fabric-Kapazität nicht nur zuweisen, um Datenprodukte oder -teams zu organisieren.

• Azure-Abonnementanforderungen: Eine Datendomäne sollte nur ein anderes Abonnement der Workload-Zielzone verwenden, wenn eine unterschiedliche Azure-Governance oder administrative Grenze erforderlich ist. Ein anderer Arbeitsbereich, eine Umgebung oder ein Datenprodukt rechtfertigt allein kein anderes Abonnement.

• Freigegebene Fabric-Kapazitäten: Mehrere Datendomänen können eine Fabric Kapazität gemeinsam nutzen, wenn gemeinsam genutzte Ressourcen eine akzeptable Leistung und eine bessere Ressourcenauslastung bieten.

• Regionale Bereitstellung: Die Organisation sollte eine Standard-Azure Region für Fabric Kapazität einrichten. Datendomänen sollten die Region verwenden, es sei denn, eine genehmigte Anforderung rechtfertigt eine andere Region. Zu den zulässigen Ausnahmen gehören rechtlicher Wohnsitz, Datenhoheit, Latenz, Fabric-Featureverfügbarkeit oder ein genehmigtes Notfallwiederherstellungsdesign. Komfort oder Teamstandort sind keine ausreichenden Gründe für eine andere Region. Siehe Multi-Geo-Unterstützung für Fabric und Fabric Bereitstellungsmuster.

• Ausnahmegenehmigung: Die Organisation sollte definieren, wer eine andere Region oder eine Fabric-Kapazität genehmigt, die datendomänenübergreifend gemeinsam genutzt wird. Eine Ausnahmeanforderung sollte die Anforderung, betroffene Datenprodukte, erwartete Kosten und Ausgangsbedingungen identifizieren.

2.2 Arbeitsbereiche in Fabric

Wie sollten Arbeitsbereiche verwendet werden? Fabric-Arbeitsbereiche sollten die Arbeitsgrenzen angeben, über die Datendomänen Datenprodukte in Microsoft Fabric erstellen und verwalten. Jede Datendomäne sollte ihre Arbeitsbereichsstruktur innerhalb organisationsweiter Standards bestimmen.

• Verwendung von Arbeitsbereichen: Erstellen Sie einen separaten Arbeitsbereich, wenn Fabric Elemente eine andere administrative, Zugriffs-, Bereitstellungs- oder Netzwerkgrenze erfordern.

• Arbeitsbereichsorganisation. Datendomänen sollten verwandte Arbeitsbereiche mit Fabric-Domänen verknüpfen. Fabric Domänen gruppieren logisch Fabric Arbeitsbereiche und unterstützen delegierte Governance, die Domänenzuweisung bestimmt jedoch keinen Zugriff auf Fabric Elemente. Siehe bewährte Methoden zum Planen und Erstellen von Domänen in Microsoft Fabric.

3. Microsoft Purview Architektur

Wie sollten wir Microsoft Purview gestalten? Die Microsoft Purview-Architektur sollte die Datendomänen der Organisation widerspiegeln, ohne Purview-Governance-Domänen, Data Map-Domänen, Sammlungen oder Fabric-Domänen austauschbar zu behandeln.

3.1 Microsoft Purview Kontoplatzierung

Wo sollten wir das Purview-Konto bereitstellen? Die Organisation sollte die Microsoft Purview Azure Ressource in einer internen Workload-Zielzone platzieren. Das ausgewählte Abonnement und die ausgewählte Region sollten die gesetzlichen und betrieblichen Anforderungen der Organisation erfüllen.

Die Organisation sollte die Verantwortung für den Purview-Dienst zentral zuweisen. Datendomänen sollten delegierte Befugnisse für ihre Metadaten und Geschäftskonzepte über genehmigte Purview-Rollen erhalten. Sie sollten keine separaten Purview-Umgebungen nur bereitstellen, um administrative Autonomie zu erhalten.

Weitere Informationen finden Sie unter Microsoft Purview häufig gestellten Fragen.

3.2 Aufbau von Purview

Wie sollten wir Purview strukturieren? Die Organisation sollte ihre Governancedomänen und die Data-Map-Struktur einrichten, bevor Datendomänen beginnen, Datenquellen zu registrieren und Datenprodukte zu veröffentlichen.

• Governancedomänen: Governancedomänen stellen den Geschäftskontext für Datenprodukte und verwandte Konzepte bereit. Sie können Glossarbegriffe, Ziele und Schlüsselergebnisse sowie kritische Datenelemente enthalten. Governancedomänen sollten zunächst mit den Datendomänen der Organisation übereinstimmen. Verwenden Sie einen andere Grenze, wenn das Governance-Eigentum dies erfordert. Siehe Governance-Domänen.

• Data-Map-Struktur: Data-Map-Domänen sollten technische Administrations- oder Lebenszyklusgrenzen auf oberster Ebene darstellen. Da Data-Map-Domänen eingeschränkt sind, verwenden Sie sie für breite technische Verwaltungsgrenzen, anstatt Organisationsdatendomänen zu spiegeln.

• Sammlungen: Sammlungen sollten einen differenzierteren Verwaltungs- und Metadatenzugriff innerhalb einer Data-Map-Domäne ermöglichen. Die Organisation sollte Sammlungen verwenden, wenn operative Teams delegierte Verantwortung für die Registrierung und das Scannen von Datenquellen benötigen. Sammlungen können auch Produktions- und Nichtproduktionsquellen trennen, wenn diese Quellen keine andere Data-Map-Domäne rechtfertigen. Jede Datenquelle muss in einer Sammlung innerhalb einer Data-Map-Domäne registriert werden. Objekte, die aus dieser Quelle gescannt wurden, bleiben dieser Struktur zugeordnet. Daher sollte die Organisation Regeln für die Quellplatzierung vor dem allgemeinen Onboarding definieren.

Siehe Governancedomänen und Domänenempfehlungen und Microsoft Purview Architektur und Bewährte Methoden für Domänen und Sammlungen.