Basisarchitektur von Azure Data Factory für Azure-Zielzonen

In diesem Artikel wird beschrieben, wie Sie ein Medallion Lakehouse-Designmuster für einen lösungsorientierten Anwendungsfall implementieren. Die Lösung verwendet eine Hub-and-Spoke-Netzwerktopologie mit Zielzonen, die den bewährten Methoden von Cloud Adoption Framework für Azure folgen.

Wesentliche Entwurfsentscheidungen

Dieses Design deckt die mittelgroße bis große Organisation Contoso ab, die sich mit Unterstützung der Automatisierung auf den Weg in die Azure-Cloud macht. Contoso verfügt über eine etablierte Azure Cloud-Basis mit einer Zielzone für Unternehmen. Führungsqualität bereitet sich darauf vor, ihre ersten Datenworkloads in die Cloud zu bringen, die vom Azure Well-Architected Framework geleitet werden.

Dieser erste Anwendungsfall umfasst die folgenden Szenarien:

• Die Daten stammen aus einem lokalen Finanzbetriebssystem.
• Daten werden für analytische Anwendungsfälle in die Cloud kopiert.
• Contoso richtet eine Data Science-Funktion für Unternehmen ein.

Schlüsselanfoderungen

• Die Finanzabteilung und andere Unternehmensfunktionen nutzen die Lösung in erster Linie als analytisches und als Berichtserstellungssystem.

• Das lokale Quellsystem verfügt über die folgenden Eigenschaften:

  • Eine Größe von einem Terabyte (TB) mit einem erwarteten jährlichen Wachstum von 5 %.

  • Ein Batchaktualisierungsprozess, der jeden Abend ausgeführt wird und in der Regel vor 3:00 Uhr endet, mit Ausnahme der Finanzupdates am Ende des Jahres.

• Die Lösung muss ihre Auswirkungen auf das Quellsystem minimieren.

• Finanzbenutzer sollten die Möglichkeit haben, den Status der Daten zu einem bestimmten Zeitpunkt anzuzeigen.

• Der erste Anwendungsfall zielt auf die Analyse- und Managementberichterstellung mit Self-Service-Funktionen ab. Dieses Lösungsdesign sollte auch als Grundlage für die Erstellung einer Data Science-Funktion für Unternehmen dienen.

• Die Daten werden als vertraulich eingestuft, sodass die Lösung effektive Sicherheitskontrollen und -überwachungen sowohl für die Komponenten als auch für den Zugriff auf die Daten oder die Verwendung haben muss. Sichern Sie alle Daten mit starker Verschlüsselung ruhender Daten und Daten während der Übertragung.

• Das Unternehmensdatenmodell von Contoso enthält eine Teilmenge speziell für Finanzdaten. Die wichtigsten Datenelemente müssen bereinigt, modelliert und den verschiedenen Berichtshierarchien entsprechen, bevor sie für die Berichterstellung bereitgestellt werden.

• Erfasste Quelldaten, die derzeit nicht dem Enterprise-Modell zugeordnet sind, müssen aufbewahrt und für zukünftige Analyse- und Anwendungsfälle zur Verfügung gestellt werden.

• Die Lösung muss täglich basierend auf der Verfügbarkeit von Quellfeeds aktualisiert werden und eine flexible Compute-Optionalität aufweisen, die auf weniger als 90 Minuten für ein End-to-End-Lösungsupdate ausgerichtet ist.

• Die Lösung muss die folgenden Vereinbarungen zum Servicelevel unterstützen (SLAs):

  • 99,5 % zielen auf die Betriebszeit oder ca. 1 Tag und 20 Stunden Ausfallzeiten innerhalb eines Jahres ab.

  • Ziel des Wiederherstellungspunkts: drei Tage.

  • Ziel der Wiederherstellungszeit: ein Tag.

• Die Lösung sollte für die Zukunft entwickelt werden, um zukünftige Wachstums- und Funktionserweiterungen ohne grundlegende Neugestaltung zu unterstützen.

• Die Lösung muss die folgende erwartete Verwendung unterstützen:

  • 200 Manager, Finanzcontroller und Analysten, die mit der Finanzabteilung verbunden sind, mit einem geschätzten Wachstum von weniger als 5 % jährlich.

  • 100 Analysten, die mit anderen Unternehmensfunktionen verbunden sind, mit einem geschätzten Wachstum von weniger als 5 % jährlich.

  • Nur Contoso-Mitarbeiter können auf die Lösung zugreifen. Dieses Steuerelement schließt explizit alle direkten Zugriffe durch Nicht-Contoso oder externe Parteien aus.

• Die Lösung muss über Folgendes verfügen:

  • End-to-End-Überwachung und Auditpfade.

  • Aktivierte Warnungen in Bezug auf Zuverlässigkeit, Leistung und Kostenmetriken.

• Die Lösung sollte Folgendes priorisieren:

  • Nutzung vorhandener Fähigkeiten statt Entwicklung neuer Fähigkeiten. Diese Strategie reduziert Komplexität, Risiko und Kosten.

  • Moderne Clouddienstebenen. Zum Beispiel sollte die Lösung, wann immer dies möglich ist, Platform-as-a-Service-Lösungen (PaaS) verwenden, um den Verwaltungsaufwand und das Risiko zu reduzieren und die Kostenkontrolle zu erleichtern.

  • Komponenten, die marktreif und leicht zu finden sind. Contoso plant, Techniker im gesamten Lebenszyklus der Softwareentwicklung (SDLC) auszubilden.

• Die Lösung sollte für die nichtfunktionellen Anforderungen (nonfunctional requiremets, NFRs) in der folgenden Reihenfolge optimiert werden:

  1. Die Kosten für die Entwicklung und Ausführung der Lösung.

  2. Die Leistung der Lösung.

  3. Die Verwaltbarkeit der Lösung.

Wesentliche Entwurfsentscheidungen

Die moderne Analysearchitektur mit Azure Databricks ist die Grundlage für das Lösungsdesign. Dieses Design ist eine natürliche Erweiterung der Unternehmensarchitektur der Azure-Zielzone. Sie verwendet viele grundlegende Komponenten aus der Unternehmensarchitektur der Azure-Zielzone, z. B. Microsoft Entra ID und Azure Monitor. Es sind nur lösungsspezifische Konfigurationsupdates erforderlich.

• Dieses Design passt problemlos zu den erwarteten Volumen- und Verarbeitungsanforderungen, einschließlich der Anforderungen an die automatische Skalierung.

• Delta Lake unterstützt die Point-in-Time-Anforderungen und erweiterte Datenversionsverwaltung, Schemaerzwingung und Zeitreise. Delta Lake bietet Atomarität, Konsistenz, Isolation und Dauerhaftigkeit (ACID).

• Ausgereiftes Marktangebot, hohe Verfügbarkeit von Fachkräften und starke Weiterbildung und Schulungen sind verfügbar.

• Unterstützt den strategischen Wunsch nach einer Data Science-Funktion für Unternehmen, indem Rohzugriff oder validierter Lake-Zugriff in Azure Databricks verwendet wird.

• Azure Data Lake Storage und Azure Databricks bieten eine effiziente mittelgroße Datenspeicherung und -verarbeitung.

• Unterstützt die Anforderungen für Leistung, Zuverlässigkeit und Dienstresilienz.

• Durch die Auswahl von PaaS-Diensten wird ein Großteil der operativen Belastung auf Microsoft verlagert, im Gegenzug erhält man weniger Kontrolle.

• Aufgrund der ersten Lösungsversion wird empfohlen, die Power BI Pro-Lizenzierung als Lizenzierungsoption zu verwenden. Diese Wahl hat einen expliziten Kompromiss zwischen Betriebskosten und Power BI Premium-Leistung.

• Die wichtigsten Änderungen für diese Lösung:

  • Aufgrund des erwarteten Datenvolumens, der Reduzierung neu eingeführter Komponenten und der Wiederverwendung vorhandener Kenntnisse wird für die Datenmodellierung Ure SQL verwendet.

  • Da die Lösung batchbasiert ist, wird Data Factory gemäß funktionaler Übereinstimmung, Kosten und Einfachheit verwendet.

  • Das Design ist erweiterbar, um Streamingerfassung zu unterstützen.

  • Für die lokale Datenerfassung ist eine selbst gehostete Data Factory-Integrationslaufzeit (Self-Hosted Integration Runtime, SHIR) erforderlich, was Azure Site Recovery für die Dienstresilienz erfordert.

  • Microsoft Purview Data Governance ist Teil der Basisschicht, die Transparenz, einen Datenkatalog und Governance-Funktionen bietet.

Aufbau

Datenfluss

Diese Lösung verwendet Data Factory mit einem SHIR, um Daten aus dem lokalen Quellsystem in Data Lake Storage aufzunehmen. Data Factory koordiniert auch Azure Databricks-Notebooks, um die Daten in Data Lake Storage gehosteten Delta Lake-Tabellen zu transformieren und zu laden.

Delta Lake ist mit Power BI gekoppelt, das verwendet wird, um Senior Leadership Dashboards und Analysen über den Delta Lake-Tabellen zu erstellen. Azure Databricks bietet auch Rohzugriff bzw. validierten Lake-Zugriff für Data Science- und Machine Learning-Workloads.

Der folgende Dataflow entspricht dem vorherigen Diagramm:

1. Daten werden von einem lokalen Quellsystem in Data Lake Storage mithilfe von Data Factory mit einem SHIR aufgenommen. Data Factory bietet außerdem Prozess-Orchestrierung für Azure Databricks-Notebooks zum Transformieren und Laden der Daten in Delta Lake-Tabellen, die auf Data Lake Storage gespeichert sind, sowie SQL Server-Extraktions- , Transformations- und Ladeprozesse.

2. Delta Lake bietet eine offene Formatebene, die Datenversionsverwaltung unterstützt, Schemas erzwingt, Zeitreisen ermöglicht und die ACID-Compliance gewährleistet. Daten werden in den folgenden Schichten organisiert:

   • Die Bronzeschicht enthält alle Rohdaten.

   • Die Silberschicht enthält gereinigte und gefilterte Daten.

   • Die Goldschicht speichert aggregierte Daten, die für Geschäftsanalysen nützlich sind.

Data Lake Storage unterstützt Delta Lake aufgrund seiner Fähigkeit, alle Datentypen effizient zu speichern. Diese Flexibilität unterstützt Workflows mit unterschiedlichen Geschwindigkeiten und sorgt für Kosteneffizienz.

1. SQL Server wird verwendet, um die Anforderungen für die Unternehmensdatenmodellierung zu unterstützen, einschließlich hierarchischer Konformität.

2. Power BI wird verwendet, um Verwaltungsinformationsdashboards aus dem Enterprise-Modell zu erstellen. Dieser Dienst bietet eine konsistente, standardisierte und leistungsfähige Ansicht von Daten. Power BI kann die Analysearbeit auch direkt über Delta Lake mithilfe von Azure Databricks aktivieren.

3. Die Lösung fügt zwei weitere Komponenten zu den grundlegenden Azure-Diensten hinzu, die Zusammenarbeit, Governance, Zuverlässigkeit und Sicherheit ermöglichen:

   • Microsoft Purview Data Governance bietet Datenermittlungsdienste, einen Datenkatalog und Governance-Erkenntnisse für die gesamte Plattform.

   • Site Recovery unterstützt die Sicherung und Wiederherstellung der virtuellen Computer, die den Compute für den Data Factory SHIR bereitstellen, der zum Aufnehmen von Daten aus der lokalen Umgebung erforderlich ist.

Für die folgenden Basisdienste ist eine Erweiterung erforderlich, um diese Lösung zu unterstützen:

• Azure DevOps bietet Continuous Integration und Continuous Deployment (CI/CD) sowie andere integrierte Features zur Versionskontrolle.

• Azure Key Vault verwaltet Geheimnisse, Schlüssel und Zertifikate sicher.

• Microsoft Entra ID bietet einmaliges Anmelden (Single Sign-On, SSO) über den Stapel hinweg, einschließlich Azure Databricks und Power BI-Benutzern.

• Azure Monitor sammelt und analysiert Azure-Ressourcentelemetriedaten, die Überwachung und Warnungen bereitstellen. Durch die proaktive Identifizierung von Problemen maximiert dieser Dienst Leistung und Zuverlässigkeit.

• Microsoft Cost Management bietet Finanzgovernancedienste für Azure-Workloads.

Netzwerkdesign

Laden Sie eine Visio-Datei dieser Architektur herunter.

• Sie können Azure-Firewalls verwenden, um die Netzwerkkonnektivität zwischen Ihrer lokalen Infrastruktur und dem virtuellen Azure-Netzwerk zu sichern.

• Sie können einen SHIR auf einem virtuellen Computer (VM) in Ihrer lokalen Umgebung oder in Azure bereitstellen, wobei letzteres empfohlen wird. Sie können einen SHIR verwenden, um eine sichere Verbindung mit lokalen Datenquellen herzustellen und Datenintegrationsaufgaben in Data Factory auszuführen.

• Es wird eine private Verbindung und private Endpunkte implementiert, mit denen Sie den Dienst in Ihr virtuelles Netzwerk übertragen können.

• Um die Machine Learning-unterstützte Datenbeschriftung zu nutzen, müssen Sie ein neues Speicherkonto erstellen, das sich von dem Standardspeicherkonto für den Azure Machine Learning-Arbeitsbereich unterscheidet. Sie können das neue, nicht standardmäßige Speicherkonto an dasselbe virtuelle Netzwerk wie den Arbeitsbereich binden. Wenn Sie es vorziehen, das Speicherkonto getrennt zu halten, können Sie es in einem anderen Subnetz in diesem virtuellen Netzwerk platzieren.

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

• Die Verwendung von Azure Databricks Delta Lake bedeutet, dass Sie die Azure Storage-Konten der Archivebene nicht verwenden können, denn diese Ebene ist praktisch ein Offlinespeicher. Diese Designauswahl ist ein Kompromiss zwischen Funktionalität und Kosten.

• Wenn Sie einen neuen Azure Databricks-Arbeitsbereich erstellen, wird die Standardredundanz für das verwaltete Speicherkonto (Azure Databricks-Dateisystem oder Databricks-Dateisystemstamm) als georedundanter Speicher (GRS) festgelegt. Sie können die Redundanz in lokal redundanten Speicher (LRS) ändern, wenn eine Georedundanz nicht erforderlich ist.

• Im Allgemeinen gilt, dass Data Warehouses mit weniger als einem TB in Azure SQL-Datenbank besser funktionieren als in Synapse. Synapse zeigt eine Leistungssteigerung, wenn das Data Warehouse mehr als 1 bis 5 TB beträgt. Dieser Leistungsunterschied ist der Hauptfaktor für die Auswahl von Azure SQL anstelle von Synapse.

Alternativen

Microsoft Fabric verfügt über Data Factory, Azure Databricks und Power BI als einzelne Lösung. Da Fabric ein relativ neuer Dienst ist, gibt es möglicherweise einige Funktionen, die derzeit nicht mit dem der in diesem Szenario verwendeten Dienste übereinstimmen. Es kann auch eine Lernkurve für Operatoren geben.

Azure Synapse Analytics ist eine Alternative für die Speicherverarbeitungsschicht. Dieser Dienst ist für das in diesem Artikel beschriebene Szenario nicht gut geeignet, da Azure Databricks eine ausgereifte, funktionale Übereinstimmung ist und auf dem Markt Qualifizierungsmöglichkeiten bietet.

Die folgenden Dienste stellen Alternativen für die Speichermodellierungsebene dar:

• Azure Synapse Analytics: Dieser Dienst ist für das in diesem Artikel beschriebene Szenario aufgrund von Datenvolumes und funktionaler Überlappung mit Azure Databricks nicht gut geeignet.

• Azure SQL Managed Instance: Dieser Dienst eignet sich nicht gut für das in diesem Artikel beschriebene Szenario, da es an Migrationsanforderungen und höheren Betriebskosten mangelt.

• Azure-Datenbank für PostgresSQL: Dieser Dienst eignet sich nicht gut für das Szenario, das in diesem Artikel beschrieben wird, weil die vorhandenen Kenntnisse und Einstellungen von Contoso die Einführung neuer Technologien minimieren, wodurch Kosten und Komplexität reduziert werden.

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Zuverlässigkeit.

So halten Sie die Zuverlässigkeitsziele für ein Business-Intelligence-Analyse- und Berichtssystem ein:

• Die standardmäßigen Azure-SLAs in der gesamten Lösung erfüllen die Anforderungen, sodass keine Hochverfügbarkeit oder multiregionale Unterstützung erforderlich ist.

• Die Architektur verwendet eine Wait for Microsoft-Notfallwiederherstellungsstrategie aufgrund der geringen Dienstkritikalität der Lösung und der Verwendung von PaaS-Diensten.

• Die folgenden systemeigenen Funktionen adressieren Datensicherungen:

  • Azure Databricks Delta Lake-Tabellenverlauf.

  • SQL Server-Standardsicherungen.

  • Die Bronzeschicht des Delta Lake, die alle aufgenommenen Quelldaten in einem Nur-Anfügbar-Format speichert. Diese Funktionalität ermöglicht eine vollständige Wiedergabe der Lösung ohne erneute Erfassung aus dem Quellsystem.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Sicherheit.

Diese Architektur befasst sich mit der Sicherheit über die Konfiguration der ausgewählten Infrastruktur sowie der implementierten Steuerungs- und Datenebenensteuerungen. Diese Designoptionen basieren auf dem Zero Trust-Modell und den Grundsätzen des Zugriffs mit den geringsten Rechten. Systemeigene Komponenten verwenden die folgenden Sicherheitssteuerelemente:

• Lösungskomponenten verwenden verwaltete Identitäten für die Authentifizierung und Autorisierung, wodurch eine konsistente rollenbasierte Zugriffssteuerung ermöglicht wird.

• Im Key Vault werden alle Anwendungsgeheimnisse und -zertifikate sicher gespeichert.

• Komponentenspezifische integrierte Rollen ermöglichen eine präzise Steuerung für die Autorisierung auf der Steuerungsebene.

  • Aufgrund des Umfangs werden diese spezifischen Rollen gegenüber den allgemeinen Rollen bevorzugt.

  • Benutzerdefinierte Rollen werden aufgrund fortlaufender Lebenszyklusverwaltungs-Anforderungen explizit ausgeschlossen.

• Eine Gruppe von domänenspezifischen Microsoft Entra-Gruppen steuert den Zugriff auf Daten in der gesamten Lösung, was das Datenklassifizierungsframework von Contoso widerspiegelt. Einzelne Lösungskomponenten verwenden diese Gruppen, um Steuerelemente auf Datenebene anzuwenden. Beispielsweise unterstützen die dynamische Datenmaskierung und Power BI-Sicherheit auf Zeilenebene von SQL Server dieses Design.

  • Dieses Design ermöglicht es, Zugriff auf eine Komponente zu gewähren, während die Möglichkeit, die Daten in der Komponente anzuzeigen, verweigert wird. Um Zugriff auf Daten zu erhalten, muss der Benutzer auch über Komponentenzugriff verfügen.

  • Diese Lösung erstellt die Gruppen, z. B. Finanzen, auf Domänenebene, um die Wiederverwendung zu ermöglichen. Das Datenklassifizierungsframework beschränkt die Häufung lösungsspezifischer Gruppen.

Kostenoptimierung

Bei der Kostenoptimierung geht es um Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Kostenoptimierung.

Um die Kosten zu optimieren, bietet diese Architektur:

• Starke Verknüpfung der SKU-Auswahl mit den Anforderungen, wodurch der Build vermieden wird und sie dem Antipattern entsprechen. Diese Lösung plant regelmäßige Überprüfungen von Metriken, um die richtige Größe und Verwendung von Microsoft Copilot in Azure zu aktivieren.

• Implementiert praktische Betriebskosteneinsparungen als Teil eines umfassenderen Finanzbetriebsframeworks, z. B.:

  • Azure-Reservierungen für stabile Workloads und Sparpläne für dynamischen Workloads für die maximale Dauer in der gesamten Lösung.

  • Reservierte Data Factory-Kapazität für Datenflüsse.

  • Log Analytics-Mindestabnahmen

• Verfügt über Komponentenkonfigurationen, die den Kompromiss zwischen Kosteneinsparungen und sofortiger Reaktion berücksichtigen:

  • Azure Databricks Serverloses Computing.

  • Speicherkonto-Zugriffsebenen, automatisiert durch die Konfiguration der Lebenszyklusverwaltungs-Richtlinien. Sie können die Archivebene in Delta Lake nicht verwenden.

  • Log Analytics-Arbeitsbereiche für die Datenaufbewahrung und -archivierung und Azure Monitor.

• Verwendet den Azure-Hybridvorteil, um die Kosten für die SQL Server-Lizenzierung zu senken.

• Implementiert Kosten- und Budgetwarnungen durch Kostenmanagement und Schutzmaßnahmen für Ausgaben.

Operative Exzellenz

Operational Excellence deckt die Betriebsprozesse ab, mit denen eine Anwendung bereitgestellt und in der Produktion ausgeführt wird. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung des optimalen Betriebs.

Die operative Exzellenz wird durch Automatisierung, Überwachung und Audits im gesamten SDLC ermöglicht. Diese Lösung beinhaltet Folgendes:

• Azure Monitor- und Log Analytics-Arbeitsbereiche als Überwachungskernkomponenten.

• Eine Taggingstrategie, die Transparenz in allen Lösungskomponenten ermöglicht.

• Die folgenden Komponenten für die Entwicklung:

  • Alle Produktionsbereitstellungen verwenden Azure DevOps über die Konfiguration als Code, der in einem Quellcodeverwaltungs-Repository gespeichert wird, z. B. Azure Repos oder GitHub. Diese Konfiguration bietet einen vollständigen Überwachungspfad der Bereitstellung und ermöglicht moderne Bereitstellungsmethoden, Rollbacks und Wiederherstellung.

  • Das Testen von Frameworks wie PSRule stellt sicher, dass Bereitstellungen den Richtlinien für Well-Architected Framework entsprechen.

  • Mit Azure Policy werden Organisationsstandards erzwungen und es wird auf Bewertungen der bedarfsabhängigen Konformität zugegriffen. Azure Governance Visualizer bietet konfigurierbare, präzise Einblicke in die technische Implementierung.

Überwachung

Die Überwachung ist ein wichtiger Bestandteil jeder Lösung auf Produktionsebene. Unterstützen Sie Azure-Lösungen mit einer Überwachungsstrategie als Teil der End-to-End-Observability-Strategie.

Azure Databricks bietet stabile Funktionen für die Überwachung von benutzerdefinierten Metriken, das Streamen von Abfrageereignissen und Anwendungsprotokollmeldungen. Azure Databricks kann diese Überwachungsdaten an verschiedene Protokollierungsdienste senden. Sie können Azure Monitor verwenden, um Data Factory-Pipelines zu überwachen und Diagnoseprotokolle zu schreiben. Azure Monitor stellt grundlegende Metriken und Protokolle der Infrastruktur für die meisten Azure-Dienste bereit. Weitere Informationen finden Sie unter Überwachung von Azure Databricks.

Die empfohlene Warnungsbasis umfasst:

• Kosten- und Budgetwarnungen für den Azure Databricks-Computecluster, die Data Factory SHIRs und SQL Server.

• Prozesse mit langer Ausführungsdauer in der gesamten Lösung.

• SQL Server-Verbindungsverweigerungen.

• Power BI-Nutzung und ggf. Power BI Premium-Kapazitätseinschränkung.

• Log Analytics-Arbeitsbereiche für den Zeitpunkt, zu dem die Datensammlung hoch ist.

Leistungseffizienz

Die Leistungseffizienz ist die Fähigkeit Ihrer Arbeitsauslastung, die anforderungen, die die Benutzer auf effiziente Weise an sie stellen, zu erfüllen. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Leistungseffizienz.

Um die Leistungseffizienz zu beheben, verfügt diese Architektur über Folgendes:

• Die Standarddienstebenen verschiedener Komponentenversionen basierend auf den Anforderungen. Sie können diese Ressourcen bei Bedarf ohne Unterbrechung der Servicelevels skalieren. Sie sollten die automatische Skalierung vor der Produktionsfreigabe streng testen .

• Eine Basislinie von Computeoptionen, die cloudeigene Features verwenden, um die Nachfrage zu unterstützen, z. B.:

  • Automatische Skalierung von Azure Databricks.

  • SQL Server-Skalierung nach oben und nach unten.

  • Data Factory-Auftragskonfigurationen für Leistung und Skalierbarkeit.

Wenden Sie Anleitungen in den folgenden Optimierungsleitfäden für die gesamte Lösung an, z. B.:

• Azure Databricks:

• Data Factory-Datenflüsse und SHIR.

• SQL Server.

• Power BI:

Beachten Sie, dass die Leistung von Datenlösungen in der Regel mit der Zeit abnimmt. Richten Sie die Kapazität für eine kontinuierliche Leistungsoptimierung ein, und führen Sie proaktive technische Überprüfungen durch, um sicherzustellen, dass die Lösung zweckmäßig bleibt.

Antimuster

• Die lokale Denkweise: Clouddienste behandeln traditionelle Einschränkungen wie Beschaffungszeit, Funktionalität und Kapazität. Diese Dienste stellen auch den entscheidenden Bedarf an Kostenmanagement im gesamten SDLC vor. Wenn Sie diesen Faktor für Personen, Prozesse und Technologien vernachlässigen, führt dies häufig zu unerwarteten Kosten- und Stakeholderreibungen.

• Begrenzungssteuerelemente sind die Antwort: Clouddienste, insbesondere PaaS, haben die Identität als die primäre Steuerung, die implementiert und ordnungsgemäß geregelt werden muss. Während Netzwerk- und Grenzsteuerelemente wichtig sind, sind sie nur Teil der Lösung und nicht die vollständige Antwort.

• Festlegen und vergessen: Cloudlösungen erfordern regelmäßige Überprüfungen, um die aktuelle Nutzung und Leistung zu bewerten. Diese Rezensionen sollten alle funktionalen und Preisänderungen in Azure berücksichtigen. Ohne diese Überprüfungen kann sich der Wert und die Wirksamkeit der Lösungen im Laufe der Zeit verringern.

Bereitstellen dieses Szenarios

Befolgen Sie zum Bereitstellen dieser Architektur die Schritt-für-Schritt-Anweisungen im GitHub-Beispiel.

Verwenden Sie zum Bereitstellen einer SHIR auf einer Azure-VM die Schnellstartvorlage.

Nächste Schritte

• Azure-Zielzonen
• Microsoft Cloud Adoption Framework
• Entscheiden zwischen einem Sparplan und einer Reservierung

Zugehörige Ressourcen

• Für Unternehmen gehärtete Data Factory-Architektur
• Geschäftskritische Data Factory