Teilen über

Erfolgsmethode für die Synapse-Implementierung: Bewerten der Umgebung

  • Artikel

Hinweis

Dieser Artikel gehört zu der Artikelserie Erfolg der Azure Synapse-Implementierung nach Design. Eine Übersicht über diese Serie finden Sie unter Azure Synapse-Implementierungserfolg nach Design.

Der erste Schritt bei der Implementierung von Azure Synapse Analytics besteht in einer Bewertung Ihrer Umgebung. Eine Bewertung bietet Ihnen die Möglichkeit, alle verfügbaren Informationen über Ihre bestehende Umgebung, Umgebungsanforderungen, Projektanforderungen, Einschränkungen, Zeitpläne und Probleme zu sammeln. Diese Informationen bilden die Grundlage für spätere Bewertungen und Prüfpunktaktivitäten. Es wird sich als unschätzbar erweisen, wenn es an der Zeit ist, die Projektlösung zu überprüfen und mit ihr zu vergleichen, während sie geplant, entworfen und entwickelt wird. Wir empfehlen Ihnen, sich viel Zeit zu nehmen, um alle Informationen zu sammeln und die notwendigen Gespräche mit den relevanten Gruppen zu führen. Zu den relevanten Gruppen können Projektbeteiligte, Benutzer, Lösungsentwickler und fachliche Ansprechpartner (SMEs) der bestehenden Lösung und Umgebung gehören.

Die Bewertung wird zu einem Leitfaden, der Ihnen hilft, den Lösungsentwurf zu bewerten und fundierte Technologieempfehlungen zur Implementierung von Azure Synapse zu geben.

Workloadbewertung

Die Workloadbewertung befasst sich mit der Umgebung, analytischen Workloadrollen, ETL/ELT, Netzwerk und Sicherheit, der Azure-Umgebung und dem Datenverbrauch.

Environment

Bewerten Sie in Bezug auf die Umgebung die folgenden Punkte.

  • Beschreiben Sie Ihre bestehende analytische Workload:
    • Was sind die Workloads (wie Data Warehouse oder Big Data)?
    • Wie hilft diese Workload dem Unternehmen? Was sind die Anwendungsszenarien?
    • Was sind die geschäftlichen Gründe für diese analytische Plattform und für eine mögliche Migration?
    • Sammeln Sie Details über die bestehende Architektur, den Entwurf und die Implementierungsoptionen.
    • Sammeln Sie Details über alle bestehenden und abhängigen Upstream- und Downstream-Komponenten und -Consumer.
  • Migrieren Sie ein bestehendes Data Warehouse (wie Microsoft SQL Server, Microsoft Analytics Platform System (APS), Netezza, Snowflake oder Teradata)?
  • Migrieren Sie eine Big Data-Plattform (wie Cloudera oder Hortonworks)?
  • Erfassen Sie die Architektur und die Dataflowdiagramme für die aktuelle analytische Umgebung.
  • Wo befinden sich die Datenquellen für Ihre geplanten analytischen Workloads (Azure, andere Cloudanbieter oder lokal)?
  • Wie groß ist die Gesamtgröße der vorhandenen Datasets (verlaufsbezogen und inkrementell)? Wie hoch ist die aktuelle Wachstumsrate Ihrer Datasets? Wie hoch ist die voraussichtliche Wachstumsrate Ihrer Datasets in den nächsten zwei bis fünf Jahren?
  • Verfügen Sie bereits über eine Data Lake-Instanz? Sammeln Sie so viele Details wie möglich über Dateitypen (wie Parquet oder CSV), Dateigrößen und Sicherheitskonfiguration.
  • Verfügen Sie über halbstrukturierte oder unstrukturierte Daten für die Verarbeitung und Analyse?
  • Beschreiben Sie die Art der Datenverarbeitung (Batch- oder Echtzeitverarbeitung).
  • Benötigen Sie eine interaktive Datenuntersuchung aus relationalen Daten, Data Lake oder anderen Quellen?
  • Benötigen Sie Echtzeit-Datenanalysen und -Untersuchungen aus operativen Datenquellen?
  • Was sind die Probleme und Einschränkungen in der aktuellen Umgebung?
  • Welche Tools für die Quellcodeverwaltung und für DevOps verwenden Sie heute?
  • Haben Sie einen Anwendungsfall, um eine Hybridanalyselösung (Cloud und lokal), eine reine Cloudanalyselösung oder eine Multicloudanalyselösung zu erstellen?
  • Sammeln Sie Informationen über die bestehende Cloudumgebung. Handelt es sich um einen Anbieter einer einzelnen oder von mehreren Clouds?
  • Sammeln Sie Pläne für die zukünftige Cloudumgebung. Wird es ein Anbieter einer einzelnen oder von mehreren Clouds sein?
  • Wie lauten die RPO/RTO/HA/SLA-Anforderungen in der bestehenden Umgebung?
  • Wie lauten die RPO/RTO/HA/SLA-Anforderungen in der geplanten Umgebung?

Analytische Workloadrollen

Bewerten Sie für die analytischen Workloadrollen die folgenden Punkte.

  • Beschreiben Sie die verschiedenen Rollen (Wissenschaftliche Fachkraft für Daten, technische Fachkraft für Daten, Datenanalyst und andere).
  • Beschreiben Sie die Anforderungen an die Zugriffssteuerung der analytischen Plattform für diese Rollen.
  • Identifizieren Sie den Besitzer der Plattform, der für die Bereitstellung von Computeressourcen und die Gewährung des Zugriffs verantwortlich ist.
  • Beschreiben Sie, wie die verschiedenen Datenrollen derzeit zusammenarbeiten.
  • Gibt es mehrere Teams, die auf derselben analytischen Plattform zusammenarbeiten? Wenn ja, wie lauten die Anforderungen an die Zugriffssteuerung und die Isolation für jedes dieser Teams?
  • Welche Clienttools verwenden die Benutzer, um mit der analytischen Plattform zu interagieren?

ETL/ELT, Transformation und Orchestrierung

Bewerten Sie für ETL/ELT, Transformation und Orchestrierung die folgenden Punkte.

  • Welche Tools verwenden Sie heute für die Datenerfassung (ETL oder ELT)?
  • Wo befinden sich diese Tools in der bestehenden Umgebung (lokal oder in der Cloud)?
  • Wie hoch sind Ihre derzeitigen Anforderungen an das Laden und Aktualisieren von Daten (Echtzeit, Microbatch, stündlich, täglich, wöchentlich oder monatlich)?
  • Beschreiben Sie die Transformationsanforderungen für jede Ebene (Big Data, Data Lake, Data Warehouse).
  • Wie sieht der aktuelle Programmieransatz für die Datentransformation aus (kein Code, wenig Code, Programmierung wie SQL, Python, Scala, C# oder andere)?
  • Welchen geplanten Programmieransatz bevorzugen Sie für die Datentransformation (kein Code, wenig Code, Programmierung wie SQL, Python, Scala, C# oder andere)?
  • Welche Tools werden derzeit für die Datenorchestrierung verwendet, um den datengesteuerten Prozess zu automatisieren?
  • Wo befinden sich die Datenquellen für Ihre bestehende ETL (Azure, andere Cloudanbieter oder lokal)?
  • Welche vorhandenen Datenverarbeitungstools (Berichte, BI-Tools, Open-Source-Tools) müssen in die analytische Plattform integriert werden?
  • Welche geplanten Datenverarbeitungstools (Berichte, BI-Tools, Open-Source-Tools) müssen in die analytische Plattform integriert werden?

Netzwerke und Sicherheit

Bewerten Sie für das Netzwerk und die Sicherheit die folgenden Punkte.

  • Welche gesetzlichen Anforderungen haben Sie an Ihre Daten?
  • Wenn Ihre Daten Kundeninhalte, Daten der Zahlungskartenbranche (Payment Card Industry, PCI) oder des Health Insurance Portability and Accountability Act von 1996 (HIPAA) enthalten, hat Ihre Sicherheitsgruppe dann Azure für diese Daten zertifiziert? Wenn ja, für welche Azure-Dienste?
  • Beschreiben Sie Ihre Anforderungen an die Autorisierung und Authentifizierung von Benutzern.
  • Gibt es Sicherheitsprobleme, die den Zugriff auf die Daten während der Implementierung einschränken könnten?
  • Gibt es Testdaten, die Sie bei der Entwicklung und beim Testen verwenden können?
  • Beschreiben Sie die Sicherheitsanforderungen des Unternehmens an den analytischen Compute und den Speicher (privates Netzwerk, öffentliches Netzwerk oder Firewalleinschränkungen).
  • Beschreiben Sie die Anforderungen an die Netzwerksicherheit für Clienttools für den Zugriff auf den analytischen Compute und Speicher (überwachtes Netzwerk, privater Endpunkt oder andere).
  • Beschreiben Sie die aktuelle Einrichtung des Netzwerks zwischen „lokal“ und „Azure“ (Azure ExpressRoute, Site-to-Site oder andere).

Verwenden Sie die folgenden Prüflisten mit möglichen Anforderungen, um sich bei Ihrer Bewertung zu orientieren.

  • Schutz von Daten:
    • Verschlüsselung während der Übertragung
    • Verschlüsselung ruhender Daten (Standardschlüssel oder kundenseitig verwaltete Schlüssel)
    • Datenermittlung und -klassifizierung
  • Zugangskontrolle:
    • Sicherheit auf Objektebene
    • Sicherheit auf Zeilenebene
    • Sicherheit auf Spaltenebene
    • Dynamische Datenmaskierung
  • Authentifizierung:
    • SQL-Anmeldename
    • Microsoft Entra ID
    • So funktioniert's: Azure Multi-Factor Authentication
  • Netzwerksicherheit:
    • Virtuelle Netzwerke
    • Firewall
    • Azure ExpressRoute
  • Bedrohungsschutz:
    • Bedrohungserkennung
    • Überwachung
    • Sicherheitsrisikobewertung

Weitere Informationen finden Sie unter Whitepaper zu Azure Synapse Analytics-Sicherheit.

Azure-Umgebung

Bewerten Sie in Bezug auf die Azure-Umgebung die folgenden Punkte.

  • Verwenden Sie derzeit Azure? Wird sie für Produktionsworkloads verwendet?
  • Wenn Sie Azure verwenden, welche Dienste nutzen Sie? Welche Regionen verwenden Sie?
  • Verwenden Sie Azure ExpressRoute? Wie groß ist dessen Bandbreite?
  • Verfügen Sie über eine Budgetgenehmigung für die Bereitstellung der erforderlichen Azure-Dienste?
  • Wie stellen Sie derzeit Ressourcen bereit und verwalten sie (Azure Resource Manager (ARM) oder Terraform)?
  • Ist Ihr Schlüsselteam mit Synapse Analytics vertraut? Ist ein Training erforderlich?

Nutzung der Daten

Bewerten Sie für den Datenverbrauch die folgenden Punkte.

  • Beschreiben Sie, wie und welche Tools Sie derzeit verwenden, um Aktivitäten wie Erfassung, Erkundung, Vorbereitung und Datenvisualisierung durchzuführen.
  • Geben Sie an, welche Tools Sie für Aktivitäten wie Erfassung, Erkundung, Vorbereitung und Datenvisualisierung verwenden möchten.
  • Welche Anwendungen sind für die Interaktion mit der analytischen Plattform geplant (Microsoft Power BI, Microsoft Excel, Microsoft SQL Server Reporting Services, Tableau oder andere)?
  • Identifizieren Sie alle Datenconsumer.
  • Identifizieren Sie die Anforderungen an den Datenexport und die Datenfreigabe.

Bewertung der Azure Synapse-Dienste

Die Bewertung der Azure Synapse-Dienste befasst sich mit den Diensten innerhalb von Azure Synapse. Azure Synapse verfügt über die folgenden Komponenten für Compute und Datenverschiebung:

  • Synapse SQL: Ein verteiltes Abfragesystem für Transact-SQL (T-SQL), das Data Warehousing- und Datenvirtualisierungsszenarien ermöglicht. Außerdem wird T-SQL erweitert, um Streaming- und ML-Szenarien (maschinelles Lernen) zu ermöglichen. Synapse SQL bietet sowohl serverlose als auch dedizierte Ressourcenmodelle.
  • Serverloser SQL-Pool: Ein verteiltes Datenverarbeitungssystem, das für umfangreiche Datenmengen und Berechnungsfunktionen konzipiert ist. Sie müssen keine Infrastruktur einrichten oder Cluster verwalten. Dieser Dienst ist für ungeplante oder Burst-Workloads geeignet. Zu den empfohlenen Szenarien gehören die schnelle Datenuntersuchung von Dateien direkt im Data Lake, das logische Data Warehouse und die Datentransformation von Rohdaten.
  • Dedizierter SQL-Pool: Stellt eine Sammlung von Analyseressourcen dar, die bei Verwendung von Synapse SQL bereitgestellt werden. Die Größe eines dedizierten SQL-Pools (vormals SQL DW) wird durch Data Warehouse-Einheiten (Data Warehouse Units, DWUs) bestimmt. Dieser Dienst eignet sich für ein Data Warehouse mit vorhersehbaren, leistungsstarken kontinuierlichen Workloads über Daten, die in SQL-Tabellen gespeichert sind. 
  • Apache Spark-Pool: Apache Spark, die beliebteste Open-Source-Big-Data-Engine, die für Datenaufbereitung, Datentechnik, ETL und ML verwendet wird, ist umfassend und nahtlos integriert.
  • Datenintegrationspipelines: Azure Synapse enthält die gleiche Engine für die Datenintegration und die gleichen Erfahrungen wie Azure Data Factory (ADF). Damit können Sie umfangreiche ETL-Pipelines im großen Stil erstellen, ohne Azure Synapse zu verlassen.

Um den besten SQL-Pooltyp (dediziert oder serverlos) zu bestimmen, sollten Sie die folgenden Punkte beachten.

  • Möchten Sie ein traditionelles relationales Data Warehouse erstellen, indem Sie die Verarbeitungsleistung für in SQL-Tabellen gespeicherte Daten reservieren?
  • Erfordern Ihre Anwendungsfälle eine vorhersehbare Leistung?
  • Möchten Sie ein logisches Data Warehouse auf der Grundlage eines Data Lake erstellen?
  • Möchten Sie Daten direkt aus einem Data Lake abfragen?
  • Möchten Sie Daten aus einem Data Lake untersuchen?

In der folgenden Tabelle werden die beiden Synapse SQL-Pooltypen verglichen.

Vergleich Dedizierter SQL-Pool Serverloser SQL-Pool
Wertversprechen Vollständig verwaltete Funktionen eines Data Warehouse. Vorhersehbare und hohe Leistung für kontinuierliche Workloads. Optimiert für verwaltete (geladene) Daten. Einfacher Einstieg und leichte Erkundung von Data Lake-Daten. Bessere Gesamtkosten für Ad-hoc- und zeitweilige Workloads. Optimiert für die Abfrage von Daten in einem Data Lake.
Arbeitsauslastungen Ideal für kontinuierliche Workloads. Das Laden steigert die Leistung, bei höherer Komplexität. Die Abrechnung pro DWU (bei geeigneter Dimensionierung) ist kostenwirksam. Ideal für Ad-hoc- oder zeitweilige Workloads. Es müssen keine Daten geladen werden, sodass Start und Ausführung einfacher verlaufen. Die Abrechnung nach Verbrauch wird kostenwirksam sein.
Abfrageleistung Bietet hohe Parallelität und geringe Wartezeit. Unterstützt umfangreiche Optionen für die Zwischenspeicherung, einschließlich materialisierter Sichten. Mithilfe der Workloadverwaltung (WLM) haben Sie die Möglichkeit, Kompromisse zu schließen. Nicht geeignet für Abfragen in Dashboards. Antwortzeiten im Millisekundenbereich sind nicht zu erwarten. Es funktioniert nur mit externen Daten.

Dedizierte SQL-Poolbewertung

Für die Bewertung des dedizierten SQL-Pools sollten Sie die folgenden Punkte der Plattform bewerten.

  • Welche ist die aktuelle Data Warehouse-Plattform (Microsoft SQL Server, Netezza, Teradata, Greenplum oder andere)?
  • Bestimmen Sie für eine Migrationsworkload die Marke und das Modell Ihrer Appliance für jede Umgebung. Geben Sie Details zu CPUs, GPUs und Arbeitsspeicher an.
  • Wann wurde die Hardware erworben, wenn es sich um eine Appliance-Migration handelt? Ist die Appliance bereits vollständig abgeschrieben? Wenn nicht, wann wird die Abschreibung enden? Und wie hoch sind die verbleibenden Investitionskosten?
  • Gibt es Diagramme zur Hardware- und Netzwerkarchitektur?
  • Wo befinden sich die Datenquellen für Ihr geplantes Data Warehouse (Azure, andere Cloudanbieter oder lokal)?
  • Welche Datenhostingplattformen werden für die Datenquellen für Ihr Data Warehouse (Microsoft SQL Server, Azure SQL-Datenbank, DB2, Oracle, Azure Blob Storage, AWS, Hadoop oder andere) verwendet?
  • Handelt es sich bei einer der Datenquellen um ein Data Warehouse? Wenn ja, welche?
  • Identifizieren Sie alle ETL-, ELT- und Datenladeszenarien (Batchfenster, Streaming, Quasi-Echtzeit). Identifizieren Sie bestehende Vereinbarungen zum Servicelevel (SLAs) für jedes Szenario, und dokumentieren Sie die erwarteten SLAs in der neuen Umgebung.
  • Wie groß ist das aktuelle Data Warehouse?
  • Welche Wachstumsrate des Datasets wird für den dedizierten SQL-Pool angestrebt?
  • Beschreiben Sie die Umgebungen, die Sie heute verwenden (Entwicklung, Test oder Produktion).
  • Welche Tools sind derzeit für die Datenverschiebung im Einsatz (ADF, Microsoft SQL Server Integration Services (SSIS), RoboCopy, Informatica, SFTP oder andere)?
  • Planen Sie, Daten in Echtzeit oder Quasi-Echtzeit zu laden?

Bewerten Sie die folgenden Datenbankpunkte.

  • Wie hoch ist die Anzahl der Objekte in jedem Data Warehouse (Schemata, Tabellen, Sichten, gespeicherte Prozeduren, Funktionen)?
  • Ist es ein Sternschema, ein Schneeflockenschema oder ein anderes Design?
  • Welche sind die größten Tabellen in Bezug auf Größe und Anzahl der Datensätze?
  • Welches sind die umfassendsten Tabellen in Bezug auf die Anzahl der Spalten?
  • Gibt es bereits ein Datenmodell für Ihr Data Warehouse? Handelt es sich um ein Kimball-, Inmon- oder Sternschema-Design?
  • Werden langsam veränderliche Dimensionen (Slowly Changing Dimensions, SCDs) verwendet? Wenn ja, welche Typen?
  • Soll eine semantische Ebene mithilfe von relationalen Data Marts oder Analysis Services (tabellarisch oder multidimensional) oder einem anderen Produkt implementiert werden?
  • Welche sind die Anforderungen an HA/RPO/RTO/Datenarchivierung?
  • Welche Anforderungen gibt es für die Replikation der Region?

Bewerten Sie die folgenden Workloadmerkmale.

  • Wie hoch ist die geschätzte Anzahl der gleichzeitigen Benutzer oder Aufträge, die während der Spitzenzeiten auf das Data Warehouse zugreifen?
  • Wie hoch ist die geschätzte Anzahl der gleichzeitigen Benutzer oder Aufträge, die außerhalb der Spitzenzeiten auf das Data Warehouse zugreifen?
  • Gibt es eine Zeitspanne, in der es keine Benutzer oder Aufträge geben wird?
  • Welche Leistung erwarten Sie bei der Ausführung interaktiver Abfragen?
  • Welche Erwartungen haben Sie an die Leistung beim täglichen/wöchentlichen/monatlichen Laden oder Aktualisieren von Daten?
  • Welche Erwartungen haben Sie an die Ausführung von Abfragen für Berichte und analytische Abfragen?
  • Wie komplex werden die am häufigsten ausgeführten Abfragen sein?
  • Wie viel Prozent der Gesamtgröße Ihres Datasets macht Ihr aktives Dataset aus?
  • Wie viel Prozent des Workloads wird voraussichtlich für das Laden oder Aktualisieren, die Batchverarbeitung oder Berichterstellung, die interaktive Abfrage und die analytische Verarbeitung benötigt?
  • Identifizieren Sie die datenaufwendigen Muster und Plattformen:
    • Aktuelle und geplante Berichterstellungsmethoden und -tools.
    • Welche Anwendungen oder Analysetools werden auf das Data Warehouse zugreifen?
    • Anzahl der gleichzeitigen Abfragen?
    • Durchschnittliche Anzahl der aktiven Abfragen zu einem beliebigen Zeitpunkt?
    • Welcher Art ist der Zugriff auf die Daten (interaktiv, Ad-hoc, Export oder andere)?
    • Datenrollen und vollständige Beschreibung ihrer Datenanforderungen.
    • Maximale Anzahl von gleichzeitigen Verbindungen.
  • SLA-Muster der Abfrageleistung nach:
    • Dashboardbenutzer
    • Batchberichterstellung
    • ML-Benutzer
    • ETL-Vorgang
  • Wie lauten die Sicherheitsanforderungen für die bestehende und die neue Umgebung (Sicherheit auf Zeilenebene, Sicherheit auf Spaltenebene, Zugriffssteuerung, Verschlüsselung und andere)?
  • Bestehen Anforderungen, um die Bewertung von ML-Modellen in T-SQL zu integrieren?

Serverlose SQL-Poolbewertung

Synapse Serverless SQL-Pool unterstützt drei wichtige Anwendungsfälle.

  • Grundlegende Ermittlung und Untersuchung: Unterschiedliche Datenformate (Parquet, CSV, JSON) in Ihrem Data Lake können zur Planung einer geeigneten Vorgehensweise für die Gewinnung von Erkenntnissen schnell und einfach analysiert werden.
  • Logisches Data Warehouse: Eine relationale Abstraktion auf der Grundlage unformatierter oder unterschiedlicher Daten ohne Datenverschiebung oder -transformation ermöglicht einen stets aktuellen Blick auf Ihre Daten.
  • Datentransformation: Eine einfache, skalierbare und leistungsfähige Möglichkeit zum Transformieren von Daten im Data Lake mithilfe von T-SQL, um die Daten für BI und andere Tools bereitzustellen oder in einen relationalen Datenspeicher (beispielsweise Synapse SQL-Datenbanken, Azure SQL-Datenbank oder andere) zu laden.

Verschiedene Datenrollen können von einem serverlosen SQL-Pool profitieren:

  • Technische Fachkräfte für Daten können den Data Lake erkunden, Daten mithilfe dieses Diensts transformieren und vorbereiten sowie ihre Datentransformationspipelines vereinfachen.
  • Wissenschaftliche Fachkräfte für Daten können dank Features wie OPENROWSET und automatischem Schemarückschluss schnell den Inhalt und die Struktur der Daten im Data Lake analysieren.
  • Datenanalysten können von technischen oder wissenschaftlichen Fachkräften für Daten erstellte Daten und externe Spark-Tabellen mithilfe von vertrauten T-SQL-Anweisungen oder ihren bevorzugten Abfragetools untersuchen.
  • BI-Experten können schnell Power BI-Berichte auf der Grundlage von Daten im Data Lake sowie Spark-Tabellen erstellen.

Hinweis

Die Sprache T-SQL wird sowohl im dedizierten SQL-Pool als auch im serverlosen SQL-Pool verwendet, allerdings gibt es einige Unterschiede bei den unterstützten Features. Weitere Informationen über die in Synapse SQL (dediziert und serverlos) unterstützten T-SQL-Features finden Sie unter In Azure Synapse SQL unterstützte Transact-SQL-Funktionen.

Werten Sie bei der Bewertung des serverlosen SQL-Pools die folgenden Punkte aus.

  • Haben Sie Anwendungsfälle, um Daten aus einem Data Lake mithilfe von relationalen Abfragen (T-SQL) zu entdecken und zu untersuchen?
  • Haben Sie Anwendungsfälle, um ein logisches Data Warehouse auf Grundlage eines Data Lakes zu erstellen?
  • Ermitteln Sie, ob es Anwendungsfälle gibt, in denen Daten in den Data Lake transformiert werden können, ohne dass sie zuvor aus dem Data Lake verschoben werden müssen.
  • Befinden sich Ihre Daten bereits in Azure Data Lake Storage (ADLS) oder Azure Blob Storage?
  • Wenn sich Ihre Daten bereits in ADLS befinden, verfügen Sie dann über eine gute Partitionsstrategie für den Data Lake?
  • Verfügen Sie über operative Daten in Azure Cosmos DB? Verfügen Sie über Anwendungsfälle für Echtzeitanalysen mit Azure Cosmos DB ohne Auswirkungen auf Transaktionen?
  • Identifizieren Sie die Dateitypen im Data Lake.
  • Identifizieren Sie die SLA für die Abfrageleistung. Erfordert Ihr Anwendungsfall vorhersehbare Leistung und Kosten?
  • Haben Sie ungeplante oder sprunghafte analytische SQL-Workloads?
  • Identifizieren Sie die datenaufwendigen Muster und Plattformen:
    • Aktuelle und geplante Berichterstellungsmethoden und -tools.
    • Welche Anwendungen oder Analysetools werden auf den serverlosen SQL-Pool zugreifen?
    • Durchschnittliche Anzahl der aktiven Abfragen zu einem beliebigen Zeitpunkt.
    • Welcher Art ist der Zugriff auf die Daten (interaktiv, Ad-hoc, Export oder andere)?
    • Datenrollen und vollständige Beschreibung ihrer Datenanforderungen.
    • Maximale Anzahl von gleichzeitigen Verbindungen.
    • Abfragekomplexität?
  • Wie lauten die Sicherheitsanforderungen (Zugriffssteuerung, Verschlüsselung und andere)?
  • Welche T-SQL-Funktionalität (gespeicherte Prozeduren oder Funktionen) ist erforderlich?
  • Identifizieren Sie die Anzahl der Abfragen, die an den serverlosen SQL-Pool gesendet werden sollen, sowie die Größe des Resultsets jeder Abfrage.

Tipp

Wenn Sie mit serverlosen SQL-Pools nicht vertraut sind, empfehlen wir Ihnen, den Lernpfad Erstellen von Datenanalyselösungen mithilfe von serverlosen SQL-Pools von Azure Synapse durchzuarbeiten.

Spark-Poolbewertung

Spark-Pools in Azure Synapse können in folgenden Schlüsselszenarien genutzt werden.

  • Datentechnik/Datenaufbereitung: Apache Spark enthält viele Sprachfunktionen zur Unterstützung der Aufbereitung und Verarbeitung großer Datenmengen. Durch Aufbereitung und Verarbeitung kann der Wert der Daten zunehmen und von anderen Azure Synapse-Diensten genutzt werden. Es wird über mehrere Sprachen (C#, Scala, PySpark, Spark SQL) und bereitgestellte Bibliotheken für die Verarbeitung und Konnektivität ermöglicht.
  • Maschinelles Lernen: Apache Spark wird mit MLlib geliefert, einer ML-Bibliothek, die auf Spark basiert und die Sie mithilfe eines Spark-Pools verwenden können. Zu den Spark-Pools gehört auch Anaconda, eine Python-Distribution, die verschiedene Pakete für Data Science einschließlich ML enthält. Darüber hinaus bietet Apache Spark auf Synapse vorinstallierte Bibliotheken für Microsoft Machine Learning, ein fehlertolerantes, elastisches und RESTful ML-Framework. In Kombination mit der integrierten Notebookunterstützung steht Ihnen eine umfangreiche Umgebung zum Erstellen von ML-Anwendungen zur Verfügung.

Hinweis

Weitere Informationen finden Sie unter Apache Spark in Azure Synapse Analytics.

Außerdem ist Azure Synapse mit Linux Foundation Delta Lake kompatibel. Delta Lake ist eine Open-Source-Speicherebene, die ACID-Transaktionen (Atomizität, Konsistenz, Isolation und Dauerhaftigkeit) in Apache Spark und Big Data-Workloads einführt. Weitere Informationen finden Sie unter Was ist Delta Lake?.

Werten Sie für die Bewertung des Spark-Pools die folgenden Punkte aus.

  • Identifizieren Sie die Workloads, die die Datentechnik oder Datenaufbereitung erfordern.
  • Definieren Sie eindeutig die Arten von Transformationen.
  • Stellen Sie fest, ob Sie unstrukturierte Daten verarbeiten müssen.
  • Wenn Sie von einer bestehenden Spark/Hadoop-Workload migrieren:
    • Welche Big Data-Plattform ist vorhanden (Cloudera, Hortonworks, Clouddienste oder andere)?
    • Wenn es sich um eine Migration von einem lokalen Standort handelt, ist die Hardware veraltet oder sind die Lizenzen abgelaufen? Wenn nicht, wann erfolgt die Abschreibung oder der Ablauf?
    • Welcher ist der vorhandene Clustertyp?
    • Welche Bibliotheken und Spark-Versionen sind erforderlich?
    • Ist es eine Migration von Hadoop zu Spark?
    • Welche sind die aktuellen oder bevorzugten Programmiersprachen?
    • Um welche Art von Workload handelt es sich (Big Data, ML oder andere)?
    • Welche Clienttools und Berichtsplattformen sind vorhanden und geplant?
    • Wie lauten die Sicherheitsanforderungen?
    • Gibt es aktuelle Probleme und Einschränkungen?
  • Planen Sie, Delta Lake zu verwenden, oder verwenden Sie es bereits?
  • Wie verwalten Sie heute Pakete?
  • Identifizieren Sie die erforderlichen Computeclustertypen.
  • Stellen Sie fest, ob eine Anpassung des Clusters erforderlich ist.

Tipp

Wenn Sie neu bei Spark-Pools sind, empfehlen wir Ihnen, den Lernpfad Ausführen von Datentechnik mit Azure Synapse Apache Spark-Pools zu durchlaufen.

Nächste Schritte

Im nächsten Artikel der Serie Mit dem richtigen Azure Synapse-Entwurf zum Erfolg erfahren Sie, wie Sie den Entwurf des Synapse-Arbeitsbereichs auswerten und überprüfen, ob er den Richtlinien und Anforderungen entspricht.