Apache Spark in Azure Machine Learning

Artikel
02/01/2024

Die Azure Machine Learning-Integration mit Azure Synapse Analytics bietet einfachen Zugang zu verteilten Rechenressourcen über das Apache Spark-Framework. Diese Integration bietet folgende Apache Spark-Computingumgebungen:

Serverloses Spark Compute
Angefügter Synapse Spark-Pool

Serverloses Spark Compute

Mit dem Apache Spark-Framework ist Azure Machine Learning serverloses Spark Compute der einfachste Weg, um verteilte Computing-Aufgaben in der Azure Machine Learning-Umgebung zu bewältigen. Azure Machine Learning bietet einen vollständig verwalteten, serverlosen und bedarfsgesteuerten Apache Spark-Computecluster. Seine Benutzer müssen keinen Azure Synapse-Arbeitsbereich und keinen Synapse Spark-Pool erstellen.

Benutzer können Ressourcen definieren, einschließlich Instanztyp und die Apache Spark-Runtimeversion. Sie können diese Ressourcen dann für den Zugriff auf serverloses Spark Compute in Azure Machine Learning Notebooks verwenden:

Zu berücksichtigende Punkte

Serverloses Spark-Compute eignet sich gut für die meisten Benutzerszenarien, die einen schnellen Zugriff auf verteilte Computingressourcen über Apache Spark erfordern. Für eine fundierte Entscheidung sollten Benutzer allerdings die Vor- und Nachteile dieses Ansatzes berücksichtigen.

Vorteile:

Keine Abhängigkeiten von der Erstellung anderer Azure-Ressourcen für Apache Spark (die Azure Synapse-Infrastruktur wird im Hintergrund ausgeführt).
Keine Abonnementberechtigungen für die Erstellung Azure Synapse-bezogener Ressourcen erforderlich
Keine SQL-Poolkontingente erforderlich

Nachteile:

Kein persistenter Hive-Metastore. Serverloses Spark Compute unterstützt nur In-Memory Spark SQL.
Keine verfügbaren Tabellen oder Datenbanken
Keine Azure Purview-Integration
Keine verfügbaren verknüpften Dienste
Weniger Datenquellen und Connectors
Keine Konfiguration auf Poolebene
Keine Bibliotheksverwaltung auf Poolebene
Nur teilweise Unterstützung für mssparkutils

Netzwerkkonfiguration

Um die Netzwerkisolation mit Azure Machine Learning und serverlosem Spark-Computing zu verwenden, verwenden Sie ein verwaltetes virtuelles Netzwerk.

Inaktivitätszeiträume und Löschmechanismus

Beim ersten Start kann eine serverlose Spark Compute-Ressource (Kaltstart) drei bis fünf Minuten benötigen, um die Spark-Sitzung selbst zu starten. Die automatische serverlose Spark Compute-Bereitstellung, die von Azure Synapse unterstützt wird, verursacht diese Verzögerung. Nach der Bereitstellung des serverlosen Spark Compute und dem Start einer Apache Spark-Sitzung tritt diese Verzögerung bei nachfolgenden Codeausführungen (Warmstart) nicht mehr auf.

Die Spark-Sitzungskonfiguration bietet eine Option, die ein Sitzungstimeout (in Minuten) definiert. Die Spark-Sitzung wird nach einem Inaktivitätszeitraum beendet, der über das benutzerdefinierte Timeout hinausgeht. Wenn in den nachfolgenden zehn Minuten keine weitere Spark-Sitzung gestartet wird, werden die für das serverlose Spark-Compute bereitgestellten Ressourcen entfernt.

Nachdem die serverlose Spark Compute-Ressource abgebaut wurde, ist für die Übermittlung des nächsten Vorgangs ein Kaltstart erforderlich. Die nächste Abbildung zeigt einige Zeiträume mit Sitzungsinaktivität sowie Szenarien für Clusterlöschungen:

Conda-Pakete auf Sitzungsebene

Eine YAML-Datei für Conda-Abhängigkeiten kann viele Conda-Pakete auf Sitzungsebene in einer Sitzungskonfiguration definieren. Das Timeout für eine Sitzung dauert länger als 15 Minuten, um die in der YAML-Datei definierten Conda-Pakete zu installieren. Es ist wichtig, zunächst zu überprüfen, ob ein erforderliches Paket bereits im Azure Synapse-Basisimage verfügbar ist. Dazu sollten Benutzer*innen dem Link folgen, um Pakete zu ermitteln, die im Basisimage für die verwendete Apache Spark-Version verfügbar sind:

Wichtig

Azure Synapse-Runtime für Apache Spark: Ankündigungen

Azure Synapse Runtime for Apache Spark 3.2:
- EOLA-Datum: 8. Juli 2023
- Datum für Supportende: 8. Juli 2024. Nach diesem Datum wird die Runtime deaktiviert.
Wenn Sie weiterhin Support erhalten und von optimaler Leistung profitieren möchten, empfehlen wir die Migration zu

Hinweis

Für ein Conda-Paket auf Sitzungsebene:

der Kaltstart benötigt etwa 10 bis 15 Minuten.
Der Warmstart mit demselben Conda-Paket dauert etwa eine Minute.
Der Warmstart mit einem anderen Conda-Paket dauert ebenfalls etwa 10 bis 15 Minuten.
Wenn das Paket, das Sie installieren, groß ist oder eine lange Installationszeit benötigt, kann es sich auf die Startzeit der Spark-Instanz auswirken.
Das Ändern der Version von PySpark, Python, Scala/Java, .NET oder Spark wird nicht unterstützt.
Docker-Images werden nicht unterstützt.

Verbessern der Kaltstartzeit von Sitzungen bei Verwendung von Conda-Paketen auf Sitzungsebene

Sie können die Kaltstartzeit von Spark-Sitzungen verbessern, indem Sie die Konfigurationsvariable spark.hadoop.aml.enable_cache auf true festlegen. Ein Kaltstart der Sitzung mit Conda-Paketen auf Sitzungsebene dauert in der Regel 10 bis 15 Minuten, wenn die Sitzung zum ersten Mal gestartet wird. Nachfolgende Sitzungskaltstarts dauern jedoch drei bis fünf Minuten. Sie definieren die Konfigurationsvariable auf der Benutzeroberfläche Sitzung konfigurieren unter Konfigurationseinstellungen.

Angefügter Synapse Spark-Pool

Ein in einem Azure Synapse-Arbeitsbereich erstellter Spark-Pool wird im Azure Machine Learning-Arbeitsbereich mit dem angefügten Synapse Spark-Pool verfügbar. Diese Option eignet sich ggf. für Benutzer, die einen vorhandenen Synapse Spark-Pool wiederverwenden möchten.

Für das Anfügen eines Synapse Spark-Pools an einen Azure Machine Learning-Arbeitsbereich sind weitere Schritte erforderlich, damit Sie den Pool in Azure Machine Learning für Folgendes verwenden können:

Ein angefügter Synapse Spark-Pool bietet Zugriff auf native Azure Synapse Features. Der Benutzer ist für die Bereitstellung, Anfügung, Konfiguration und Verwaltung des Synapse Spark-Pools verantwortlich.

Die Spark-Sitzungskonfiguration für einen angefügten Synapse Spark-Pool bietet auch eine Option zum Definieren eines Sitzungstimeouts (in Minuten). Das Sitzungstimeoutverhalten ähnelt der Beschreibung aus dem vorherigen Abschnitt, aber mit dem Unterschied, dass die zugeordneten Ressourcen nach Ablauf des Sitzungstimeouts nicht gelöscht werden.

Definieren der Spark-Clustergröße

In Spark-Aufträgen für Azure Machine Learning können Sie die Spark-Clustergröße mit drei Parameterwerten definieren:

Anzahl von Executors
Executorkerne
Executorarbeitsspeicher

Sie sollten einen Apache Spark-Executor für Azure Machine Learning als gleichwertig mit Azure Spark-Workerknoten betrachten. Diese Parameter werden anhand eines Beispiels erläutert. Angenommen, Sie haben sechs Executor (entspricht sechs Workerknoten), vier Executorkerne und 28 GB Executorarbeitsspeicher definiert. Ihr Spark-Auftrag hat dann Zugriff auf einen Cluster mit insgesamt 24 Kernen und 168 GB Arbeitsspeicher.

Sicherstellen des Ressourcenzugriffs für Spark-Aufträge

Spark-Aufträge können eine verwaltete Identität oder den Passthrough der Benutzeridentität verwenden, um auf Daten und andere Ressourcen zuzugreifen. In dieser Tabelle werden die Mechanismen zusammengefasst, die von Spark-Aufträgen für den Zugriff auf Ressourcen verwendet werden:

Spark-Pool	Unterstützte Identitäten	Standardidentität
Serverloses Spark Compute	Benutzeridentität, benutzerseitig zugewiesene verwaltete Identität, die dem Arbeitsbereich zugeordnet ist	Benutzeridentität
Angefügter Synapse Spark-Pool	Benutzeridentität, benutzerseitig zugewiesene verwaltete Identität, die dem angefügten Synapse Spark-Pool zugeordnet ist, systemseitig zugewiesene verwaltete Identität des angefügten Synapse Spark-Pools	Systemseitig zugewiesene verwaltete Identität des angefügten Synapse Spark-Pools

In diesem Artikel wird der Ressourcenzugriff für Spark-Aufträge beschrieben. In einer Notebook-Sitzung verwenden sowohl der serverlose Spark Compute als auch der angeschlossene Synapse Spark-Pool den Passthrough der Benutzeridentität für den Datenzugriff während des interaktiven Data Wranglings.