Konfigurationen von Apache Spark-Pools in Azure Synapse Analytics
Ein Spark-Pool stellt eine Gruppe von Metadaten dar, die die Anforderungen an Computeressourcen und die zugehörigen Verhaltensmerkmale definiert, wenn eine Spark-Instanz instanziiert wird. Zu diesen Merkmalen zählen unter anderem der Name, die Anzahl der Knoten, die Knotengröße, das Skalierungsverhalten und die Gültigkeitsdauer. Ein Spark-Pool selbst verbraucht keine Ressourcen. Beim Erstellen von Spark-Pools fallen keine Kosten an. Gebühren fallen nur an, wenn ein Spark-Auftrag für den Spark-Zielpool ausgeführt wird und die Spark-Instanz bei Bedarf instanziiert wird.
Informationen zum Erstellen eines Spark-Pools sowie alle verfügbaren Eigenschaften finden Sie unter Erstellen eines Apache Spark-Pools.
Isolated Compute
Die Option „Isolated Compute“ bietet weitere Sicherheitsfeatures für Spark-Computeressourcen aus nicht vertrauenswürdigen Diensten, indem die physische Computeressource einem einzelnen Kunden zugeordnet wird. Die Option „Isolated Compute“ eignet sich am besten für Workloads, die ein hohes Maß an Isolation von den Workloads anderer Kunden erfordern, beispielsweise um Compliance zu erzielen und gesetzliche Anforderungen zu erfüllen. Die Option „Isolate Compute“ ist nur mit der Knotengröße XXXLarge (80 vCPU/504 GB) und nur in den folgenden Regionen verfügbar. Die Option „Compute isolieren“ kann nach der Poolerstellung aktiviert oder deaktiviert werden, dabei muss die Instanz allerdings möglicherweise neu gestartet werden. Wenn Sie dieses Feature in Zukunft aktivieren möchten, stellen Sie sicher, dass Ihr Synapse-Arbeitsbereich in einer Region erstellt wird, die „Isolate Compute“ unterstützt.
- East US
- USA, Westen 2
- USA Süd Mitte
- US Gov Arizona
- US Government, Virginia
Nodes
Eine Instanz eines Apache Spark-Pools besteht aus einem Hauptknoten und zwei oder mehreren Workerknoten mit mindestens drei Knoten in einer Spark-Instanz. Der Hauptknoten führt zusätzliche Verwaltungsdienste wie Livy, YARN Resource Manager, Zookeeper und den Spark-Treiber aus. Auf allen Knoten werden Dienste wie Node Agent und YARN Node Manager ausgeführt. Auf allen Workerknoten wird der Spark Executor-Dienst ausgeführt.
Knotengrößen
Ein Spark-Pool kann mit Knotengrößen definiert werden, die von einem Serverknoten der Größe „Small“ mit 4 virtuellen Kernen und 32 GB Arbeitsspeicher bis hin zu einem Serverknoten der Größe „XXLarge“ mit 64 virtuellen Kernen und 432 GB Arbeitsspeicher pro Knoten reichen. Die Knotengrößen können nach der Poolerstellung geändert werden. Dabei muss die Instanz jedoch möglicherweise neu gestartet werden.
| Size | Virtueller Kern | Arbeitsspeicher |
|---|---|---|
| Klein | 4 | 32 GB |
| Medium | 8 | 64 GB |
| Groß | 16 | 128 GB |
| Extra groß | 32 | 256 GB |
| XXLarge | 64 | 432 GB |
| XXX Large (Isolated Compute) | 80 | 504 GB |
Autoscale
Mit der Autoskalierung für Apache Spark-Pools können Sie Computeressourcen basierend auf dem Aktivitätsumfang automatisch hoch- bzw. herunterskalieren. Wenn das Feature für die Autoskalierung aktiviert ist, legen Sie die minimale und die maximale Anzahl der zu skalierenden Knoten fest. Wenn das Feature deaktiviert ist, bleibt die Anzahl der festgelegten Knoten unverändert. Diese Einstellung kann nach der Poolerstellung geändert werden. Dabei muss die Instanz jedoch möglicherweise neu gestartet werden.
Elastischer Poolspeicher
Apache Spark-Pools unterstützen jetzt Poolspeicher für elastische Datenbanken. Poolspeicher für elastische Datenbanken ermöglicht es der Spark-Engine, den temporären Speicher von Workerknoten zu überwachen und bei Bedarf zusätzliche Festplatten anzufügen. Apache Spark-Pools verwenden temporären Plattenspeicher, während der Pool instanziiert wird. Spark-Aufträge schreiben Shuffle-Zuordnungsausgaben, Shuffle-Daten und Überlaufdaten auf lokale VM-Datenträger. Beispiele für Vorgänge, die lokale Datenträger verwenden können, sind Sortieren, Zwischenspeichern und dauerhaftes Speichern. Wenn der temporäre VM-Datenträger-Speicherplatz erschöpft ist, tritt bei Spark-Aufträgen möglicherweise der Fehler „Nicht genügend Speicherplatz“ (java.io.IOException: Kein Speicherplatz mehr auf Gerät) auf. Bei „Nicht genügend Speicherplatz“-Fehlern wird ein Großteil des Aufwands zur Verhinderung des Fehlschlagens von Aufträgen auf den Kunden verlagert, der die Spark-Aufträge (z. B. die Anzahl der Partitionen optimieren) oder Cluster (z. B. dem Cluster mehr Knoten hinzufügen) neu konfigurieren muss. Diese Fehler müssen nicht konsistent sein, und es kann darauf hinauslaufen, dass der Benutzer intensiv experimentieren muss, indem er Produktionsaufträge ausführt. Dieser Prozess kann für den Benutzer in vielerlei Hinsicht teuer sein:
- Vergeudete Zeit Kunden müssen intensiv durch Ausprobieren („Versuch und Irrtum“) mit Auftragskonfigurationen experimentieren und sollen die internen Metriken von Spark verstehen, um die richtige Entscheidung zu treffen.
- Verschwendete Ressourcen. Da Produktionsaufträge unterschiedliche Datenmengen verarbeiten können, können Spark-Aufträge nicht deterministisch fehlschlagen, wenn Ressourcen nicht überdimensioniert sind. Betrachten Sie beispielsweise das Problem der Datenschiefe, das dazu führen kann, dass einige Knoten mehr Speicherplatz benötigen als andere. Derzeit erhält in Synapse jeder Knoten in einem Cluster dieselbe Größe an Speicherplatz, und die Erhöhung des Speicherplatzes über alle Knoten hinweg ist keine ideale Lösung, die zu enormer Verschwendung führt.
- Verlangsamung der Auftragsausführung. In dem hypothetischen Szenario, in dem wir das Problem durch die automatische Skalierung von Knoten lösen (vorausgesetzt, die Kosten sind kein Problem für den Endbenutzer), ist das Hinzufügen eines Serverknotens immer noch teuer (dauert einige Minuten) im Gegensatz zum Hinzufügen von Speicher (dauert ein paar Sekunden).
Es ist keine Aktion Ihrerseits erforderlich, und es sollten als Ergebnis weniger Auftragsfehler auftreten.
Hinweis
Azure Synapse Elastischer Poolspeicher befindet sich derzeit in der öffentlichen Vorschau. Während der öffentlichen Vorschau ist die Nutzung von Poolspeicher für elastische Datenbanken kostenlos.
Automatische Pause
Die automatische Pausenfunktion gibt die Ressourcen nach einer bestimmten Leerlaufzeit frei, wodurch die Gesamtkosten eines Apache Spark-Pools gesenkt werden. Die Anzahl der Minuten der Inaktivitätsperiode kann festgelegt werden, sobald das Feature aktiviert wurde. Das Feature für automatische Pausen ist unabhängig vom Feature für die Autoskalierung. Ressourcen können angehalten werden, unabhängig davon, ob die Autoskalierung aktiviert oder deaktiviert ist. Diese Einstellung kann nach der Erstellung des Pools geändert werden, allerdings müssen dann die aktiven Sitzungen neu gestartet werden.