Freigeben über

Bewährte Methoden für die Kostenoptimierung

  • Artikel

In diesem Artikel werden bewährte Methoden zur Unterstützung der Prinzipien der Kostenoptimierung behandelt – strukturiert nach Prinzip.

1. Auswählen optimaler Ressourcen

Verwenden von leistungsoptimierten Datenformaten

Um die Databricks Data Intelligence Platform optimal nutzen zu können, müssen Sie Delta Lake als Speicherframework verwenden. Sie hilft beim Erstellen einfacherer und zuverlässigerer ETL-Pipelines und bietet zahlreiche Leistungsverbesserungen, mit denen Workloads im Vergleich zur Verwendung von Parkett, ORC und JSON erheblich beschleunigt werden können. Weitere Informationen finden Sie unter Optimierungsempfehlungen für Azure Databricks. Wenn die Workload auch auf einer Auftragsberechnung ausgeführt wird, wird dies direkt in kürzere Betriebszeiten von Computeressourcen übersetzt, die zu niedrigeren Kosten führen.

Verwenden der Auftragsberechnung

Ein Auftrag ist eine Möglichkeit, nicht interaktiven Code auf einer Databricks-Computeinstanz auszuführen. Beispielsweise können Sie eine ETL-Workload (Extrahieren, Transformieren und Laden) interaktiv oder nach einem Zeitplan ausführen. Natürlich können Aufträge auch interaktiv über die Notebook-Benutzeroberfläche ausgeführt werden. In Auftrags-Compute kosten die nicht interaktiven Workloads allerdings deutlich weniger als in universellen Compute Services. Vergleichen Sie „Jobs Compute“ und „All-Purpose Compute“ in der Preisübersicht.

Ein weiterer Vorteil für einige Aufträge besteht darin, dass jeder Auftrag oder Workflow auf einer neuen Computeinstanz ausgeführt werden kann und Arbeitslasten voneinander isolieren. Multitaskworkflows können jedoch auch Computeressourcen für alle Vorgänge wiederverwenden, sodass die Computestartzeit nur einmal pro Workflow erfolgt. Weitere Informationen finden Sie unter Konfigurieren von Compute für Jobs.

Verwenden eines SQL-Warehouse für SQL-Workloads

Für interaktive SQL-Workloads ist ein Databricks SQL-Warehouse die kostengünstigste Engine. Weitere Informationen finden Sie in der Preisübersicht. Alle SQL-Lagerhäuser sind standardmäßig mit Photon enthalten, wodurch Ihre vorhandenen SQL- und DataFrame-API-Aufrufe beschleunigt und die Gesamtkosten pro Workload reduziert werden.

Darüber hinaus unterstützen serverlose SQL-Warehouses das intelligente Workload-Management (IWM), eine Reihe von Funktionen, die die serverlose Fähigkeit von Databricks SQL verbessern, eine große Anzahl von Abfragen schnell und kostengünstig zu verarbeiten.

Verwenden aktueller Runtimes für Ihre Workloads

Die Azure Databricks-Plattform bietet verschiedene Runtimes, die für Datentechnikaufgaben (Databricks Runtime) oder Machine Learning Aufgaben (Databricks Runtime für Machine Learning) optimiert sind. Die Runtimes sind so konzipiert, dass sie die beste Auswahl an Bibliotheken für die Aufgaben bieten und sicherstellen, dass alle bereitgestellten Bibliotheken auf dem neuesten Stand sind und optimal zusammenarbeiten. Die Databricks Laufzeiten werden regelmäßig veröffentlicht und bieten Leistungsverbesserungen zwischen Hauptversionen. Diese Leistungsverbesserungen führen häufig zu Kosteneinsparungen aufgrund einer effizienteren Nutzung von Computeressourcen.

Beschränken der GPU-Verwendung auf die richtigen Workloads

Virtuelle Computer mit GPUs können Berechnungen für Deep Learning erheblich beschleunigen, sind aber wesentlich teurer als reine CPU-Computer. Verwenden Sie GPU-Instanzen nur für Workloads mit GPU-beschleunigten Bibliotheken.

Die meisten Workloads verwenden keine GPU-beschleunigten Bibliotheken und profitieren daher nicht von Instanzen mit GPU-Unterstützung. Arbeitsbereichsadministratoren können GPU-Computer und Computeressourcen einschränken, um unnötige Verwendung zu verhindern. Weitere Informationen finden Sie im Blogbeitrag Are GPUs Really Expensive? Benchmarking GPUs for Inference on Databricks Clusters.

Verwenden von serverlosen Diensten für Ihre Workloads

BI-Anwendungsfälle

BI-Workloads verwenden Daten in der Regel in Bursts und generieren mehrere gleichzeitige Abfragen. Beispielsweise kann jemand, der ein BI-Tool verwendet, ein Dashboard aktualisieren oder eine Abfrage schreiben und dann einfach die Ergebnisse ohne weitere Interaktion mit der Plattform analysieren. In diesem Szenario macht die Datenplattform folgendes:

  • Beendet leerlaufe Computeressourcen, um Kosten zu sparen.
  • Stellt die Rechenressourcen schnell bereit, wenn der Benutzer neue oder aktualisierte Daten mit dem BI-Tool anfordert.

Bei nicht serverlosen Azure Databricks SQL-Warehouses beträgt die Startzeit mehrere Minuten. Viele Benutzer*innen nehmen daher die höheren Kosten in Kauf und beenden sie während Leerlaufzeiten nicht. Serverlose SQL-Warehouses werden dagegen in wenigen Sekunden gestartet und zentral hochskaliert, sodass sowohl sofortige Verfügbarkeit als auch eine Beendigung während Leerlaufzeiten erreicht werden können. Dies führt zu einer hervorragenden Benutzererfahrung sowie insgesamt zu Kosteneinsparungen.

Darüber hinaus werden serverlose SQL-Warehouses früher herunterskaliert als nicht serverlose Warehouses, was nochmals Kosten spart.

ML- und KI-Modell

Die meisten Modelle werden als REST-API für die Integration in Ihre Web- oder Clientanwendung bereitgestellt. Das Modell, das den Dienst bedient, empfängt unterschiedliche Anforderungen im Laufe der Zeit, und eine Modelldienstplattform sollte immer ausreichende Ressourcen bereitstellen, aber nur so viele wie tatsächlich erforderlich (Upscaling und Downscaling).

Mosaic AI Model Serving verwendet serverlose Compute und bietet einen hochverwendbaren und niedrigen Latenzdienst für die Bereitstellung von Modellen. Der Dienst wird automatisch hoch- oder herunterskaliert, um Bedarfsänderungen zu erfüllen, was Infrastrukturkosten spart und gleichzeitig die Latenzleistung optimiert.

Verwenden des richtigen Instanztyps

Die Verwendung der neuesten Generation von Cloudinstanztypen bietet fast immer Leistungsvorteile, da sie die beste Leistung und die neuesten Features bieten.

Basierend auf Ihren Workloads ist es auch wichtig, die richtige Instanzfamilie auszuwählen, um das beste Leistungs-/Preisverhältnis zu erzielen. Einige einfache Faustregeln sind:

  • Für ML optimierter Arbeitsspeicher, schwere Shuffle- und Überlaufworkloads
  • Compute optimiert für strukturierte Streamingworkloads und Wartungsaufträge (z. B. Optimieren und Vakuum)
  • Speicher optimiert für Workloads, die von der Zwischenspeicherung profitieren, z. B. Ad-hoc- und interaktive Datenanalyse
  • GPU optimiert für bestimmte ML- und DL-Workloads
  • Allgemeiner Zweck ohne spezifische Anforderungen

Auswählen der effizientesten Berechnungsgröße

Azure Databricks führt einen Executor pro Workerknoten aus. Daher werden die Begriffe „Executor“ und „Worker“ im Kontext der Azure Databricks-Architektur synonym 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:

  • Gesamtzahl der Executorkerne (Compute): Die Gesamtanzahl von Kernen für alle Executors. Dies bestimmt die maximale Parallelität einer Compute-Instanz.
  • Gesamter Executorspeicher: Die Gesamtmenge des RAM für alle Executors. Bestimmt, wie viele Daten vor dem Überlauf auf einen Datenträger im Arbeitsspeicher gespeichert werden können.
  • Lokaler Executorspeicher: Der Typ und die Menge des lokalen Datenträgerspeichers. Der lokale Festplattenspeicher wird in erster Linie für den Fall verwendet, dass es bei Shuffles und Caching zu einem Überlauf kommt.

Weitere Überlegungen betreffen die Art und Größe der Workerinstanz, die sich ebenfalls auf die oben genannten Faktoren auswirken. Berücksichtigen Sie beim Dimensionieren der Compute-Services Folgendes:

  • Wie viele Daten wird Ihr Workload verbrauchen?
  • Wie komplex ist die Berechnung Ihres Workloads?
  • Woher lesen Sie Daten?
  • Wie werden die Daten im externen Speicher partitioniert?
  • Wie viel Parallelität wird benötigt?

Details und Beispiele finden Sie unter Überlegungen zur Computedimensionierung.

Bewerten leistungsoptimierter Abfragemodule

Photon ist ein leistungsfähiges Databricks-natives vektorisiertes Abfragemodul, das Ihre SQL-Workloads und DataFrame-API-Aufrufe beschleunigt (für Datenerfassung, ETL, Streaming, Data Science und interaktive Abfragen). Photon ist mit Apache Spark-APIs kompatibel, was den Einstieg sehr einfach macht. Es sind keine Codeänderungen erforderlich, und es gibt keine Abhängigkeiten.

Die beobachtete Beschleunigung kann zu erheblichen Kosteneinsparungen führen, und bei regelmäßig ausgeführten Aufträgen sollte überprüft werden, ob sie mit Photon nicht nur schneller, sondern auch kostengünstiger sind.

2. Dynamische Zuordnung von Ressourcen

Verwenden der Automatischen Skalierungsberechnung

Bei der automatischen Skalierung weist Databricks die Worker dynamisch neu zu, um die Merkmale Ihres Auftrags zu berücksichtigen. Bestimmte Abschnitte Ihrer Pipeline können rechenintensiver sein als andere, und Databricks fügt während dieser Phasen Ihres Auftrags automatisch zusätzliche Worker hinzu (und entfernt sie, wenn sie nicht mehr benötigt werden). Durch die automatische Skalierung können die Gesamtkosten im Vergleich zu einer Compute-Instanz mit fester Größe gesenkt werden.

Die automatische Computeskalierung hat Einschränkungen beim Herunterskalieren der Clustergröße für strukturierten Streaming-Workloads. Databricks empfiehlt die Verwendung von Delta Live Tables mit verbesserter automatischer Skalierung für Streaming-Workloads.

Verwenden der automatischen Beendigung

Azure Databricks bietet eine Reihe von Features zur Kostenkontrolle, mit denen Sie Ressourcen im Leerlauf verringern sowie steuern können, wann Computeressourcen bereitgestellt werden können.

  • Konfigurieren Sie die automatische Beendigung für alle interaktiven Compute-Ressourcen. Nach einer angegebenen Leerlaufzeit wird die Compute-Ressource heruntergefahren. Weitere Informationen finden Sie unter Automatische Beendigung.
  • Für Anwendungsfälle, in denen die Berechnung nur während der Geschäftszeiten erforderlich ist, können Computeressourcen mit der automatischen Beendigung konfiguriert werden, und ein geplanter Prozess kann die Berechnung neu starten (und ggf. vorwarnen Daten bei Bedarf), bevor Benutzer wieder auf ihren Desktops sind. Siehe CACHE SELECT.
  • Wenn die Berechnung der Startzeiten zu lang ist, sollten Sie die Verwendung von Clusterpools in Betracht ziehen, siehe bewährte Methoden zur Zusammenlegung. Azure Databricks-Pools sind einsatzbereite Instanzen im Leerlauf. Wenn Clusterknoten mithilfe der sich im Leerlauf befindenden Instanzen erstellt werden, werden die Start- und Autoskalierungszeiten des Clusters reduziert. Wenn die Pools keine Leerlaufinstanzen enthalten, wird er erweitert, indem eine neue Instanz vom Instanzenanbieter zugeordnet wird, um die Anforderung des Clusters zu erfüllen.

Solange sich Instanzen im Pool im Leerlauf befinden, werden in Azure Databricks keine Databricks Units DBUs berechnet, was zu Kosteneinsparungen führt. Abrechnung des Instanzenanbieters gilt.

Verwenden von Computerichtlinien zum Steuern von Kosten

Computerichtlinien können viele kostenspezifische Einschränkungen für Computeressourcen erzwingen. Weitere Informationen finden Sie im Artikel „Bewährte Methoden für optimalen Betrieb“ unter Verwenden von Computerichtlinien. Zum Beispiel:

3. Überwachen und Kontrollieren der Kosten

Überwachen der Kosten

Verwenden Sie Azure Cost Manager, um Azure Databricks-Kosten zu analysieren. Compute- und Arbeitsbereichstags werden auch an Azure Cost Manager übermittelt. Weitere Informationen finden Sie unter Markieren von Clustern für die Kostenzuordnung.

Markieren von Clustern für die Kostenzuordnung

Um die Kosten im Allgemeinen zu überwachen und die Azure Databricks-Nutzung korrekt den Geschäftseinheiten und Teams Ihrer Organisation für Rückbuchungszwecke zuzuordnen, können Sie Cluster, SQL-Lager und Pools kategorisieren. Diese Tags werden für die Kostenanalyse an detaillierte Databricks Units (DBU) und VM- und Blob Storage-Nutzung des Cloudanbieters weitergegeben.

Kostenkontrolle und -zuordnung müssen bereits bei der Einrichtung von Arbeitsbereichen und Clustern für Teams und Anwendungsfälle berücksichtigt werden. Dadurch wird das Tagging optimiert und die Genauigkeit der Kostenzuordnung verbessert.

Die Gesamtkosten umfassen den virtuellen DBU-Computer, den Datenträger und alle zugehörigen Netzwerkkosten. Für serverlose SQL-Lagerhäuser umfasst die DBU-Kosten bereits die Kosten für virtuelle Computer und Datenträger.

Die Tags von Azure Databricks-Ressourcen können in den Kostenanalysetools im Azure-Portal verwendet werden

Implementieren des Einblicks zum Nachverfolgen und Rückrechnen von Kosten

Bei der Arbeit mit komplexen technischen Ökosystemen ist das proaktive Verständnis des Unbekannten der Schlüssel zur Aufrechterhaltung der Plattformstabilität und der Kostenkontrolle. Der Einblick bietet eine Möglichkeit, Systeme basierend auf den von ihnen generierten Daten zu analysieren und zu optimieren. Dies unterscheidet sich von der Überwachung, die sich auf die Identifizierung neuer Muster und nicht auf das Nachverfolgen bekannter Probleme konzentriert.

Databricks bietet hervorragende Observability-Funktionen mithilfe von Systemtabellen, bei denen es sich um vom Databricks gehostete Analysespeicher der betrieblichen Daten eines Kundenkontos handelt, die im Systemkatalog enthalten sind. Sie bieten historische Einblicke für das gesamte Konto und umfassen benutzerfreundliche tabellarische Informationen in Plattformtelemetrie.

Siehe Blog: Intelligente Kostenoptimierung & Zuverlässigkeit auf Databricks

Regelmäßiges Teilen von Kostenberichten

Generieren Sie monatliche Kostenberichte, um das Verbrauchswachstum und Anomalien zu verfolgen. Geben Sie diese Berichte nach Anwendungsfall oder Team für die Teams frei, die die Workloads mit Clustertaggingbesitzen. Dadurch werden Überraschungen beseitigt und es Teams ermöglicht, ihre Workloads proaktiv anzupassen, wenn die Kosten zu hoch werden.

Überwachen und Verwalten der Kosten für ausgehende Delta Sharing-Daten

Im Gegensatz zu anderen Datenfreigabeplattformen erfordert Delta Sharing keine Datenreplikation. Dieses Modell bietet viele Vorteile, allerdings kann Ihr Cloudanbieter möglicherweise Gebühren für ausgehende Daten erheben, wenn Sie Daten cloud- oder regionsübergreifend freigeben. Siehe Überwachen und Verwalten von Kosten für den Delta-Freigabeausgang (für Anbieter), um Ausgangsgebühren zu überwachen und zu verwalten.

4. Entwerfen von kostengünstigen Workloads

Schaffen eines ausgewogenen Verhältnisses Balance zwischen Always-On und ausgelöstem Streaming

Im Zusammenhang mit Streaming denken Menschen meist an Begriffe wie „Echtzeit“, „rund um die Uhr“ oder „Always-On“. Wenn die Datenerfassung in Echtzeit erfolgt, müssen die zugrunde liegenden Computeressourcen 24/7 ausgeführt werden, was kostenaufwendige Kosten jede einzelne Stunde des Tages verursacht.

Nicht jeder Anwendungsfall, der auf einem kontinuierlichen Ereignisstrom basiert, erfordert jedoch, dass diese Ereignisse sofort dem Analysedatensatz hinzugefügt werden. Wenn die Geschäftsanforderung für den Anwendungsfall nur alle paar Stunden oder jeden Tag frische Daten erfordert, kann diese Anforderung nur mit wenigen Läufen pro Tag erfüllt werden, was zu einer erheblichen Verringerung der Arbeitsauslastungskosten führt. Databricks empfiehlt die Verwendung von strukturiertem Streaming mit dem Trigger AvailableNow für inkrementelle Workloads, bei denen es nicht auf kurze Wartezeiten ankommt. Weitere Informationen finden Sie unter Konfigurieren der inkrementellen Batchverarbeitung.

Schaffen eines ausgewogenen Verhältnisses zwischen On-Demand- und Kapazitätsüberschussinstanzen

Spotinstanzen nutzen übermäßige Ressourcen virtueller Computer in der Cloud, die zu einem niedrigeren Preis verfügbar sind. Um Kosten zu sparen, unterstützt Azure Databricks das Erstellen von Clustern mit Spot-Instanzen. Databricks empfiehlt, dass die erste Instanz (der Spark-Treiber) immer eine bedarfsgesteuerte virtuelle Maschine sein sollte. Spot-Instanzen sind eine gute Wahl für Workloads, bei denen eine längere Dauer akzeptabel ist, weil der Cloudanbieter eine Spot-Instanz (oder mehrere Spot-Instanzen) entfernt hat.