Bewährte Methoden: Clusterkonfiguration

Azure Databricks bietet beim Erstellen und Konfigurieren von Clustern eine Reihe von Optionen, mit denen Sie die beste Leistung zu den niedrigsten Kosten erzielen können. Diese Flexibilität kann jedoch herausforderungen, wenn Sie versuchen, optimale Konfigurationen für Ihre Workloads zu ermitteln. Wenn Sie sorgfältig überlegen, wie Benutzer Cluster verwenden, können Sie Konfigurationsoptionen beim Erstellen neuer Cluster oder Beim Konfigurieren vorhandener Cluster unterstützen. Bei der Bestimmung von Konfigurationsoptionen sind u. a. folgende Punkte zu berücksichtigen:

  • Welche Art von Benutzer verwendet den Cluster? Ein Data Scientist führt möglicherweise unterschiedliche Auftragstypen mit anderen Anforderungen als ein Data Engineer oder Data Analyst aus.
  • Welche Arten von Workloads werden Benutzer im Cluster ausführen? Beispielsweise haben ETL-Aufträge (Batch Extract, Transform, Load) wahrscheinlich andere Anforderungen als analytische Workloads.
  • Welche Vereinbarung zum Servicelevel (SLA) müssen Sie erfüllen?
  • Welche Budgeteinschränkungen gibt es?

Dieser Artikel enthält Empfehlungen zur Clusterkonfiguration für verschiedene Szenarien, die auf diesen Überlegungen basieren. In diesem Artikel werden auch die spezifischen Features von Azure Databricks-Clustern und die Überlegungen erläutert, die für diese Features zu berücksichtigen sind.

Ihre Konfigurationsentscheidungen erfordern einen Kompromiss zwischen Kosten und Leistung. Die Hauptkosten eines Clusters umfassen die vom Cluster verbrauchten Databricks-Einheiten (DBUs) und die Kosten der zugrunde liegenden Ressourcen, die zum Ausführen des Clusters erforderlich sind. Was möglicherweise nicht offensichtlich ist, sind die sekundären Kosten, z. B. die Kosten für Ihr Unternehmen, wenn eine SLA nicht erfüllt wird, eine geringere Mitarbeitereffizienz oder eine mögliche Verschwendung von Ressourcen aufgrund schlechter Kontrollen.

Clusterfeatures

Bevor Ausführlichere Clusterkonfigurationsszenarien erläutert werden, ist es wichtig, einige Features von Azure Databricks Clustern zu verstehen und zu verstehen, wie diese Features am besten verwendet werden.

Allzweckcluster und Auftragscluster

Wenn Sie einen Cluster erstellen, wählen Sie einen Clustertyp aus: einen Allzweckcluster oder einen Auftragscluster. Allzweckcluster können von mehreren Benutzern gemeinsam genutzt werden und eignen sich am besten für Ad-hoc-Analysen, Datenuntersuchung oder Entwicklung. Sobald Sie die Implementierung Ihrer Verarbeitung abgeschlossen haben und bereit sind, Ihren Code zu operationalisieren, wechseln Sie zur Ausführung in einem Auftragscluster. Auftragscluster werden beendet, wenn Ihr Auftrag beendet wird, wodurch die Ressourcennutzung und die Kosten reduziert werden.

Clustermodus

Azure Databricks unterstützt drei Clustermodi:Standard, Hohe Parallelität und Einzelner Knoten. Die meisten regulären Benutzer verwenden Standard- oder Einzelknotencluster.

  • Standardcluster eignen sich ideal für die Verarbeitung großer Datenmengen mit Apache Spark.
  • Einzelknotencluster sind für Aufträge vorgesehen, die kleine Datenmengen oder nicht verteilte Workloads wie Machine Learning-Bibliotheken mit einem Einzelnen Knoten verwenden.
  • Cluster mit hoher Parallelität eignen sich ideal für Benutzergruppen, die Ressourcen freigeben oder Ad-hoc-Aufträge ausführen müssen. Administratoren erstellen in der Regel Cluster mit hoher Parallelität. Databricks empfiehlt, die automatische Skalierung für Cluster mit hoher Parallelität zu aktivieren.

Bedarfs- und Spot-Instanzen

Um Kosten zu sparen, unterstützt Azure Databricks das Erstellen von Clustern mithilfe einer Kombination aus Bedarfs- und Spot-Instanzen. Sie können Spot-Instanzen verwenden, um ungenutzte Kapazität in Azure zu nutzen, um die Kosten für die Ausführung Ihrer Anwendungen zu senken, die Computekapazität Ihrer Anwendung zu erhöhen und den Durchsatz zu erhöhen.

Automatische Skalierung

Mit der automatischen Skalierung können Cluster die Größe basierend auf Workloads automatisch ändern. Die automatische Skalierung kann sowohl aus Kosten- als auch aus Leistungssicht von vielen Anwendungsfällen und Szenarien profitieren, aber es kann schwierig sein, zu verstehen, wann und wie die automatische Skalierung verwendet wird. Im Folgenden werden einige Überlegungen zum Bestimmen der Verwendung der automatischen Skalierung und zum Erzielen des größten Nutzens erläutert:

  • Die automatische Skalierung reduziert in der Regel die Kosten im Vergleich zu einem Cluster mit fester Größe.
  • Workloads mit automatischer Skalierung können im Vergleich zu einem nicht bereitgestellten Cluster mit fester Größe schneller ausgeführt werden.
  • Einige Workloads sind nicht kompatibel mit Clustern mit automatischer Skalierung, einschließlich Spark-Submit-Aufträgen und einigen Python-Paketen.
  • Bei Allzweckclustern mit nur einem Benutzer stellen Benutzer möglicherweise fest, dass die automatische Skalierung ihre Entwicklung oder Analyse verlangsamt, wenn die Mindestanzahl von Workern zu niedrig festgelegt ist. Dies liegt daran, dass die Befehle oder Abfragen, die sie ausführen, häufig mehrere Minuten voneinander entfernt sind und sich der Cluster im Leerlauf befindet und herunterskaliert werden kann, um Kosten zu sparen. Wenn der nächste Befehl ausgeführt wird, versucht der Cluster-Manager, hochzuskalieren. Der Abruf von Instanzen vom Cloudanbieter dauert einige Minuten. Während dieser Zeit können Aufträge mit unzureichenden Ressourcen ausgeführt werden, wodurch die Zeit zum Abrufen von Ergebnissen verlangsamt wird. Die Erhöhung der Mindestanzahl von Workern ist zwar hilfreich, erhöht aber auch die Kosten. Dies ist ein weiteres Beispiel, bei dem Kosten und Leistung ausgeglichen werden müssen.
  • Wenn Deltazwischenspeicherung verwendet wird, ist es wichtig zu beachten, dass alle zwischengespeicherten Daten auf einem Knoten verloren gegangen sind, wenn dieser Knoten beendet wird. Wenn die Beibehaltung zwischengespeicherter Daten für Ihre Workload wichtig ist, sollten Sie einen Cluster mit fester Größe verwenden.
  • Wenn Sie über einen Auftragscluster verfügen, auf dem eine ETL-Workload ausgeführt wird, können Sie den Cluster bei der Optimierung manchmal entsprechend dimensionieren, wenn Sie wissen, dass sich Ihr Auftrag wahrscheinlich nicht ändern wird. Die automatische Skalierung bietet Ihnen jedoch Flexibilität, wenn ihre Datengröße zunimmt. Es ist auch zu beachten, dass die optimierte automatische Skalierung die Kosten bei Aufträgen mit langer Ausführungsdauer reduzieren kann, wenn der Cluster in langen Zeiträumen nicht ausgelastet ist oder auf Ergebnisse eines anderen Prozesses wartet. Auch hier kann es bei Ihrem Auftrag zu geringfügigen Verzögerungen kommen, wenn der Cluster versucht, entsprechend zentral hochzuskalieren. Wenn Sie über strenge SLAs für einen Auftrag verfügen, ist ein Cluster mit fester Größe möglicherweise eine bessere Wahl, oder erwägen Sie die Verwendung eines Azure Databricks Pools, um die Startzeiten des Clusters zu reduzieren.

Azure Databricks unterstützt auch die automatische Skalierung des lokalen Speichers. Mit der automatischen Skalierung des lokalen Speichers überwacht Azure Databricks den freien Speicherplatz, der auf den Spark-Workern Ihres Clusters verfügbar ist. Wenn ein Worker langsam auf dem Datenträger ausgeführt wird, fügt Azure Databricks automatisch ein neues verwaltetes Volume an den Worker an, bevor nicht mehr genügend Speicherplatz verfügbar ist.

Pools

Pools reduzieren die Start- und Hochskalierungszeiten von Clustern, indem eine Reihe verfügbarer, einsatzbereiter Instanzen beibehalten wird. Databricks empfiehlt, Pools zu nutzen, um die Verarbeitungszeit zu verbessern und gleichzeitig die Kosten zu minimieren.

Databricks Runtime Versionen

Databricks empfiehlt die Verwendung der neuesten Databricks Runtime-Version für Alle-Zweck-Cluster. Die Verwendung der aktuellsten Version stellt sicher, dass Sie über die neuesten Optimierungen und die aktuellste Kompatibilität zwischen Ihrem Code und vorab geladenen Paketen verfügen.

Erwägen Sie bei Auftragsclustern, auf denen Betriebsworkloads ausgeführt werden, die Verwendung der LTS-Version (Long Term Support) Databricks Runtime. Die Verwendung der LTS-Version stellt sicher, dass keine Kompatibilitätsprobleme auftreten und Ihre Workload vor dem Upgrade gründlich getestet werden kann. Wenn Sie über einen erweiterten Anwendungsfall für Machine Learning oder Genomics verfügen, sollten Sie die spezialisierten Databricks Runtime Versionen in Betracht ziehen.

Clusterrichtlinien

Azure Databricks Clusterrichtlinien ermöglichen Es Administratoren, Steuerungen für die Erstellung und Konfiguration von Clustern zu erzwingen. Databricks empfiehlt die Verwendung von Clusterrichtlinien, um die in diesem Leitfaden beschriebenen Empfehlungen anzuwenden. Weitere Informationen zu Clusterrichtlinien finden Sie im Leitfaden zu bewährten Methoden für Clusterrichtlinien.

Automatische Beendigung

Viele Benutzer denken nicht, ihre Cluster zu beenden, wenn sie mit der Verwendung fertig sind. Glücklicherweise werden Cluster nach einem festgelegten Zeitraum automatisch beendet, wobei der Standardwert 120 Minuten beträgt.

Administratoren können diese Standardeinstellung beim Erstellen von Clusterrichtlinien ändern. Das Verringern dieser Einstellung kann die Kosten senken, indem die Zeit reduziert wird, in der sich Cluster im Leerlauf befinden. Denken Sie daran, dass bei Beendigung eines Clusters der gesamte Zustand verloren geht, einschließlich aller Variablen, temporären Tabellen, Caches, Funktionen, Objekte usw. All dieser Zustand muss wiederhergestellt werden, wenn der Cluster erneut gestartet wird. Wenn ein Entwickler eine 30-minütige Pause einlegt, wäre es verschwendung, die gleiche Zeit zu investieren, um ein Notebook wieder in den gleichen Zustand wie zuvor zu bringen.

Wichtig

Cluster im Leerlauf sammeln während des Inaktivitätszeitraums vor der Beendigung weiterhin DBU- und Cloudinstanzgebühren.

Garbage Collection

Obwohl es weniger offensichtlich als andere in diesem Artikel erläuterte Überlegungen sein kann, kann die Berücksichtigung der Garbage Collection dazu beitragen, die Auftragsleistung in Ihren Clustern zu optimieren. Die Bereitstellung einer großen Menge an RAM kann dazu beitragen, dass Aufträge effizienter ausgeführt werden, können aber auch zu Verzögerungen während der Garbage Collection führen.

Um die Auswirkungen langer Garbage Collection-Sweeps zu minimieren, vermeiden Sie die Bereitstellung von Clustern mit großen Ram-Mengen, die für jede Instanz konfiguriert sind. Wenn dem Executor mehr RAM zugeordnet ist, führt dies zu längeren Garbage Collection-Zeiten. Konfigurieren Sie stattdessen Instanzen mit kleineren RAM-Größen, und stellen Sie weitere Instanzen bereit, wenn Sie mehr Arbeitsspeicher für Ihre Aufträge benötigen. Es gibt jedoch Fälle, in denen weniger Knoten mit mehr RAM empfohlen werden, z. B. Workloads, die viele Shuffles erfordern, wie unter Überlegungen zur Cluster-Größenüberlegungenerläutert.

Clusterzugriffssteuerung

Sie können zwei Arten von Clusterberechtigungen konfigurieren:

  • Die Berechtigung Clustererstellung zulassen steuert die Fähigkeit von Benutzern, Cluster zu erstellen.
  • Berechtigungen auf Clusterebene steuern die Möglichkeit, einen bestimmten Cluster zu verwenden und zu ändern.

Weitere Informationen zum Konfigurieren von Clusterberechtigungen finden Sie unter Clusterzugriffssteuerung.

Sie können einen Cluster erstellen, wenn Sie entweder über Clustererstellungsberechtigungen oder Zugriff auf eine Clusterrichtlinie verfügen, mit der Sie einen beliebigen Cluster innerhalb der Richtlinienspezifikationen erstellen können. Der Clusterersteller ist der Besitzer und verfügt über Die Berechtigung Kann verwalten, wodurch er ihn für jeden anderen Benutzer innerhalb der Einschränkungen der Datenzugriffsberechtigungen des Clusters freigeben kann.

Informationen zu Clusterberechtigungen und Clusterrichtlinien sind wichtig, wenn Sie sich für Clusterkonfigurationen für gängige Szenarienentscheiden.

Clustertags

Mit Clustertags können Sie die Kosten von Cloudressourcen, die von verschiedenen Gruppen in Ihrer Organisation verwendet werden, problemlos überwachen. Sie können Tags beim Erstellen eines Clusters als Schlüssel-Wert-Zeichenfolgen angeben, und Azure Databricks diese Tags auf Cloudressourcen wie Instanzen und EBS-Volumes angewendet. Weitere Informationen zur Tagerzwingung finden Sie im Leitfaden zu bewährten Methoden für Clusterrichtlinien.

Überlegungen zur Clusterdimensionierung

Azure Databricks führt einen Executor pro Workerknoten aus. Daher werden die Begriffe Executor und Worker im Kontext der Architektur Azure Databricks verwendet. Die Clustergröße wird häufig in Bezug auf die Anzahl der Worker betrachtet, es gibt jedoch noch weitere wichtige Faktoren, die berücksichtigt werden müssen:

  • Executorkerne gesamt (Compute): Die Gesamtzahl der Kerne für alle Executors. Dadurch wird die maximale Parallelität eines Clusters bestimmt.
  • Executor-Gesamtspeicher: Die Gesamtmenge an RAM für alle Executors. Dies bestimmt, wie viele Daten im Arbeitsspeicher gespeichert werden können, bevor sie auf den Datenträger überlauft werden.
  • Lokaler Executor-Speicher: Typ und Menge des lokalen Datenträgerspeichers. Der lokale Datenträger wird hauptsächlich bei Überlauf während Shuffles und Zwischenspeichern verwendet.

Weitere Überlegungen umfassen den Typ und die Größe der Workerinstanz, die auch die oben genannten Faktoren beeinflussen. Berücksichtigen Sie beim Anpassen der Größe Ihres Clusters Folgendes:

  • Wie viele Daten werden von Ihrer Workload verbraucht?
  • Wie komplex ist die Berechnung Ihrer Workload?
  • Wo lesen Sie Daten?
  • Wie werden die Daten im externen Speicher partitioniert?
  • Wie viel Parallelität benötigen Sie?

Die Beantwortung dieser Fragen hilft Ihnen, optimale Clusterkonfigurationen basierend auf Workloads zu ermitteln. Bei einfachen Workloads im ETL-Stil, die nur schmale Transformationen verwenden (Transformationen, bei denen jede Eingabepartition nur zu einer Ausgabepartition beiträgt), konzentrieren Sie sich auf eine computeoptimierte Konfiguration. Wenn Sie viele Shuffles erwarten, ist die Menge an Arbeitsspeicher wichtig, und der Speicher ist wichtig, um Datenlecks zu berücksichtigen. Weniger große Instanzen können netzwerkbasierte E/A-Datenübertragungen zwischen Computern während shufflelastige Workloads reduzieren.

Es gibt einen Lastenausgleich zwischen der Anzahl der Worker und der Größe der Workerinstanztypen. Ein Cluster mit zwei Workern mit jeweils 40 Kernen und 100 GB RAM verfügt über die gleichen Compute- und Arbeitsspeicherressourcen wie ein Cluster mit acht Workern mit 10 Kernen und 25 GB RAM.

Wenn Sie viele neu gelesene Daten erwarten, können Ihre Workloads von der Zwischenspeicherung profitieren. Stellen Sie sich eine speicheroptimierte Konfiguration mit Delta Cache vor.

Beispiele für die Cluster größen

In den folgenden Beispielen werden Clusterempfehlungen basierend auf bestimmten Workloadtypen gezeigt. Diese Beispiele enthalten auch Konfigurationen, um zu vermeiden, und warum diese Konfigurationen für die Workloadtypen nicht geeignet sind.

Datenanalyse

Datenanalysten führen in der Regel Verarbeitung durch, die Daten aus mehreren Partitionen erfordert, was zu vielen Shufflevorgängen führt. Ein Cluster mit einer kleineren Anzahl von Knoten kann die Netzwerk- und Datenträger-E/A reduzieren, die für diese Shuffles erforderlich sind. Cluster A im folgenden Diagramm ist wahrscheinlich die beste Wahl, insbesondere für Cluster, die einen einzelnen Analysten unterstützen.

Cluster D bietet wahrscheinlich die schlechteste Leistung, da eine größere Anzahl von Knoten mit weniger Arbeitsspeicher und Speicher ein größeres Shuffling der Daten erfordert, um die Verarbeitung abschließen zu können.

Größen für Datenanalysecluster

Analytische Workloads erfordern wahrscheinlich wiederholtes Lesen der gleichen Daten. Daher werden empfohlene Workertypen mit aktivierter Deltacache-Funktion speicheroptimiert.

Weitere für analytische Workloads empfohlene Features sind:

  • Aktivieren Sie die automatische Beendigung, um sicherzustellen, dass Cluster nach einer Bestimmten Zeit der Inaktivität beendet werden.
  • Erwägen Sie die Aktivierung der automatischen Skalierung basierend auf der typischen Workload des Analysten.
  • Erwägen Sie die Verwendung von Pools, die es ermöglichen, Cluster auf vorab genehmigte Instanztypen zu beschränken und konsistente Clusterkonfigurationen sicherzustellen.

Features, die wahrscheinlich nicht nützlich sind:

  • Storage automatisch skalieren, da dieser Benutzer wahrscheinlich nicht viele Daten erzeugt.
  • Cluster mit hoher Parallelität, da dieser Cluster für einen einzelnen Benutzer ist, und Cluster mit hoher Parallelität eignen sich am besten für die gemeinsame Verwendung.

Einfache Batch-ETL

Einfache Batch-ETL-Aufträge, die keine breiten Transformationen erfordern, z. B. Joins oder Aggregationen, profitieren in der Regel von computeoptimierten Clustern. Für diese Workloadtypen sind alle Cluster im folgenden Diagramm wahrscheinlich akzeptabel.

Einfache Batch-ETL-Clustergröße

Computeoptimierte Workertypen werden empfohlen. diese sind kostengünstiger, und für diese Workloads ist wahrscheinlich kein signifikanter Arbeitsspeicher oder Speicher erforderlich.

Die Verwendung eines Pools kann einen Vorteil für Cluster bieten, die einfache ETL-Aufträge unterstützen, indem sie die Startzeiten des Clusters und die Gesamtlaufzeit beim Ausführen von Auftragspipelines verringern. Da diese Arten von Workloads jedoch in der Regel als geplante Aufträge ausgeführt werden, bei denen der Cluster nur lange genug ausgeführt wird, um den Auftrag abschließen zu können, bietet die Verwendung eines Pools möglicherweise keinen Vorteil.

Die folgenden Features sind wahrscheinlich nicht nützlich:

  • Deltazwischenspeicherung, da das erneute Lesen von Daten nicht erwartet wird.
  • Die automatische Beendigung ist wahrscheinlich nicht erforderlich, da es sich wahrscheinlich um geplante Aufträge handelt.
  • Die automatische Skalierung wird nicht empfohlen, da Compute und Speicher für den Fall vorkonfiguriert sein sollten.
  • Cluster mit hoher Parallelität sind für mehrere Benutzer vorgesehen und profitieren nicht von einem Cluster, der einen einzelnen Auftrag ausführen.

Komplexe Batch-ETL

Komplexere ETL-Aufträge wie die Verarbeitung, die Unions und Joins über mehrere Tabellen hinweg erfordert, funktionieren wahrscheinlich am besten, wenn Sie die Menge der gemischten Daten minimieren können. Da die Reduzierung der Anzahl von Arbeitsmitarbeitern in einem Cluster dazu beihilft, Shuffles zu minimieren, sollten Sie einen kleineren Cluster wie Cluster A im folgenden Diagramm über einen größeren Cluster wie Cluster D in Betracht ziehen.

Komplexe ETL-Cluster-Größen

Komplexe Transformationen können rechenintensiv sein, sodass für einige Workloads, die eine optimale Anzahl von Kernen erreichen, möglicherweise das Hinzufügen zusätzlicher Knoten zum Cluster erforderlich ist.

Wie einfache ETL-Aufträge werden computeoptimierte Workertypen empfohlen. diese sind kostengünstiger, und für diese Workloads ist wahrscheinlich kein signifikanter Arbeitsspeicher oder Speicher erforderlich. Ebenso wie bei einfachen ETL-Aufträgen ist das wichtigste zu berücksichtigende Clusterfeature Pools, um die Startzeiten des Clusters und die Gesamtlaufzeit beim Ausführen von Auftragspipelines zu verringern.

Die folgenden Features sind wahrscheinlich nicht nützlich:

  • Deltazwischenspeicherung, da das erneute Lesen von Daten nicht erwartet wird.
  • Die automatische Beendigung ist wahrscheinlich nicht erforderlich, da es sich wahrscheinlich um geplante Aufträge handelt.
  • Die automatische Skalierung wird nicht empfohlen, da Compute und Speicher für den Fall vorkonfiguriert sein sollten.
  • Cluster mit hoher Parallelität sind für mehrere Benutzer vorgesehen und profitieren nicht von einem Cluster, der einen einzelnen Auftrag ausführen.

Trainieren von Machine Learning-Modellen

Da anfängliche Iterationen beim Trainieren eines Machine Learning-Modells häufig experimentell sind, ist ein kleinerer Cluster wie Cluster A eine gute Wahl. Ein kleinerer Cluster verringert auch die Auswirkungen von Shuffles.

Wenn stabilität ein Problem ist oder für erweiterte Phasen, kann ein größerer Cluster wie Cluster B oder C eine gute Wahl sein.

Ein großer Cluster wie Cluster D wird aufgrund des Mehraufwands für das Shuffling von Daten zwischen Knoten nicht empfohlen.

Größen für Machine Learning-Cluster

Empfohlene Workertypen sind speicheroptimiert, wenn delta caching aktiviert ist, um wiederholte Lese- und Zwischenspeicherungen der gleichen Daten zu berücksichtigen und das Zwischenspeichern von Trainingsdaten zu ermöglichen. Wenn die von speicheroptimierten Knoten bereitgestellten Compute- und Speicheroptionen nicht ausreichen, ziehen Sie GPU-optimierte Knoten in Betracht. Ein möglicher Nachteil ist die fehlende Unterstützung der Deltazwischenspeicherung bei diesen Knoten.

Weitere für analytische Workloads empfohlene Features sind:

  • Aktivieren Sie die automatische Beendigung, um sicherzustellen, dass Cluster nach einer Bestimmten Zeit der Inaktivität beendet werden.
  • Erwägen Sie die Aktivierung der automatischen Skalierung basierend auf der typischen Workload des Analysten.
  • Verwenden Sie Pools, um Cluster auf vorab genehmigte Instanztypen zu beschränken und konsistente Clusterkonfigurationen sicherzustellen.

Features, die wahrscheinlich nicht nützlich sind:

  • Automatische Skalierung, da zwischengespeicherte Daten verloren gehen können, wenn Knoten entfernt werden, wenn ein Cluster herunterskaliert wird. Darüber hinaus nutzen typische Machine Learning-Aufträge häufig alle verfügbaren Knoten. In diesem Fall bietet die automatische Skalierung keinen Vorteil.
  • Storage automatisch skalieren, da dieser Benutzer wahrscheinlich nicht viele Daten erzeugt.
  • Cluster mit hoher Parallelität, da dieser Cluster für einen einzelnen Benutzer ist, und Cluster mit hoher Parallelität eignen sich am besten für die gemeinsame Verwendung.

Allgemeine Szenarios

Die folgenden Abschnitte enthalten zusätzliche Empfehlungen zum Konfigurieren von Clustern für gängige Clusternutzungsmuster:

  • Mehrere Benutzer, die Datenanalyse und Ad-hoc-Verarbeitung ausführen.
  • Spezielle Anwendungsfälle wie Machine Learning.
  • Unterstützung geplanter Batchaufträge.

Cluster mit mehreren Benutzer

Szenario

Sie müssen mehreren Benutzern Zugriff auf Daten bieten, um Datenanalysen und Ad-hoc-Abfragen ausführen zu können. Die Clusternutzung kann im Laufe der Zeit schwanken, und die meisten Aufträge sind nicht sehr ressourcenintensiv. Die Benutzer benötigen größtenteils schreibgeschützten Zugriff auf die Daten und möchten Analysen durchführen oder Dashboards über eine einfache Benutzeroberfläche erstellen.

Der empfohlene Ansatz für die Clusterbereitstellung ist ein Hybridansatz für die Knotenbereitstellung im Cluster zusammen mit der automatischen Skalierung. Ein Hybridansatz umfasst das Definieren der Anzahl von bedarfsbasierten Instanzen und Spot-Instanzen für den Cluster und das Aktivieren der automatischen Skalierung zwischen der minimalen und der maximalen Anzahl von Instanzen.

Szenario mit mehreren Benutzer

Dieser Cluster ist immer verfügbar und wird standardmäßig von den Benutzern gemeinsam genutzt, die zu einer Gruppe gehören. Durch aktivieren der automatischen Skalierung kann der Cluster je nach Last hoch- und herunterskaliert werden.

Benutzer haben keinen Zugriff zum Starten/Beenden des Clusters, aber die anfänglichen bedarfsbasierten Instanzen sind sofort verfügbar, um auf Benutzerabfragen zu reagieren. Wenn die Benutzerabfrage mehr Kapazität erfordert, stellt die automatische Skalierung automatisch mehr Knoten (meist Spot-Instanzen) bereit, um die Workload zu bewältigen.

Azure Databricks verfügt über weitere Features zur weiteren Verbesserung von Anwendungsfällen mit mehrstufiger Mandanz:

Bei diesem Ansatz werden die Gesamtkosten durch:

  • Verwenden eines freigegebenen Clustermodells.
  • Verwenden einer Mischung aus Bedarfs- und Spot-Instanzen.
  • Verwenden der automatischen Skalierung, um zu vermeiden, dass für nicht ausgelastete Cluster bezahlt wird.

Spezialisierte Workloads

Szenario

Sie müssen Cluster für spezielle Anwendungsfälle oder Teams in Ihrer Organisation bereitstellen, z. B. Data Scientists, die komplexe Algorithmen zum Erkunden von Daten und maschinellem Lernen ausführen. Ein typisches Muster ist, dass ein Benutzer einen Cluster für einen kurzen Zeitraum benötigt, um seine Analyse durchzuführen.

Der beste Ansatz für diese Art von Workload ist das Erstellen von Clusterrichtlinien mit vordefinierten Konfigurationen für Standard-, Feste und Einstellungsbereiche. Diese Einstellungen können die Anzahl von Instanzen, Instanztypen, Spot- und On-Demand-Instanzen, Rollen, zu installierende Bibliotheken usw. umfassen. Die Verwendung von Clusterrichtlinien ermöglicht Benutzern mit erweiterten Anforderungen das schnelle Einrichten von Clustern, die sie nach Bedarf für ihren Jeweiligen konfigurieren können, und die Erzwingung von Kosten und Einhaltung von Richtlinien.

Spezialisierte Workloads

Dieser Ansatz bietet Benutzern mehr Kontrolle und bietet gleichzeitig die Möglichkeit, die Kosten durch Vorabdefinieren von Clusterkonfigurationen unter Kontrolle zu halten. Dadurch können Sie auch Cluster für verschiedene Benutzergruppen mit Berechtigungen für den Zugriff auf unterschiedliche Datensätze konfigurieren.

Ein Nachteil dieses Ansatzes ist, dass Benutzer bei Änderungen an Clustern wie Konfiguration, installierten Bibliotheken usw. mit Administratoren zusammenarbeiten müssen.

Batchworkloads

Szenario

Sie müssen Cluster für geplante Batchaufträge bereitstellen, z. B. ETL-Produktionsaufträge zur Datenvorbereitung. Die empfohlene bewährte Methode besteht im Starten eines neuen Clusters für jede Auftragslauf. Die Ausführung jedes Auftrags in einem neuen Cluster hilft dabei, Fehler und verpasste SLAs zu vermeiden, die durch andere Workloads verursacht werden, die in einem freigegebenen Cluster ausgeführt werden. Abhängig vom Grad der Bedeutung für den Auftrag können Sie alle bedarfsbasierten Instanzen verwenden, um SLAs zu erfüllen oder ein Gleichgewicht zwischen Spot- und On-Demand-Instanzen zu erzielen, um Kosten zu sparen.

Geplante Batchworkloads