Bewährte Methoden für Leistungseffizienz

Dieser Artikel behandelt bewährte Methoden für die Leistungseffizienz – strukturiert nach Architekturprinzipien in den folgenden Abschnitten.

1. Vertikale Skalierung, horizontale Skalierung und lineare Skalierbarkeit

Bevor wir uns mit den bewährten Methoden vertraut machen, sehen wir uns einige verteilte Computerkonzepte an: horizontale Skalierung, vertikale Skalierung und lineare Skalierbarkeit.

• Vertikale Skalierung: Skalieren Sie vertikal, indem Sie Ressourcen von einem einzelnen Computer, in der Regel CPUs, Arbeitsspeicher oder GPUs, hinzufügen oder entfernen. Dies bedeutet in der Regel, dass die Workload beendet, auf einen größeren Computer verschoben und neu gestartet wird. Es gibt Grenzen für die vertikale Skalierung: Es gibt möglicherweise keine größere Maschine, oder der Preis der nächsten größeren Maschine ist unertragbar.
• Horizontale Skalierung: Horizontal skalieren, indem Knoten aus einem verteilten System hinzugefügt oder entfernt werden. Wenn die Grenzen der vertikalen Skalierung erreicht werden, besteht die Lösung darin, horizontal zu skalieren: Verteiltes Computing verwendet Systeme mit mehreren Computern (als Cluster bezeichnet), um Workloads auszuführen. Wichtig ist hierbei, dass dies nur möglich ist, wenn die Workloads für die parallele Ausführung vorbereitet sind (unterstützt von den Engines von Databricks Data Intelligence Plattform, Apache Spark und Photon). Auf diese Weise können mehrere kostengünstige Maschinen in ein größeres Computersystem kombiniert werden. Wenn mehr Computeressourcen benötigt werden, fügt die horizontale Skalierung dem Cluster weitere Knoten hinzu und entfernt sie wieder, wenn sie nicht mehr erforderlich sind. Technisch gibt es keine Grenze (und das Spark-Modul übernimmt den komplexen Teil des Lastenausgleichs), aber große Anzahl von Knoten erhöhen die Verwaltungskomplexität.
• Lineare Skalierbarkeit bedeutet, dass die Beziehung zwischen Durchsatz und verwendeten Ressourcen linear ist, wenn Sie einem System weitere Ressourcen hinzufügen. Das ist nur möglich, wenn die parallelen Aufgaben unabhängig sind. Andernfalls werden Zwischenergebnisse einer Gruppe von Knoten für die weitere Berechnung in einer anderen Gruppe von Knoten im Cluster benötigt. Dieser Datenaustausch zwischen Knoten beinhaltet die Übertragung der Ergebnisse über das Netzwerk an eine andere Gruppe von Knoten, was zeitaufwendig ist. Im Allgemeinen fällt bei verteiltem Computing immer ein gewisser Mehraufwand für die Verwaltung der Verteilung und für den Austausch von Daten an. Daher können kleine Datasetworkloads, die auf einem einzelnen Knoten analysiert werden können, noch langsamer sein, wenn sie in einem verteilten System ausgeführt werden. Die Data Intelligence Platform von Databricks bietet flexibles Computing (einzelner Knoten und verteilt), um die individuellen Anforderungen Ihrer Workloads zu erfüllen.

2. Verwenden serverloser Architekturen

Verwenden von serverlosem Computing

Mit dem serverlosen Compute auf der Databricks Data Intelligence Platform wird die Computeebene im Azure Databricks-Konto des Kunden ausgeführt. Die Dienste werden von Databricks vollständig verwaltet und kontinuierlich verbessert. Zusätzlich zu Kunden, die nur für ihre Nutzung bezahlen, führt dies zu einer verbesserten Produktivität:

• Cloudadministratoren müssen keine komplexen Cloudumgebungen mehr verwalten, z. B. das Anpassen von Kontingenten, das Erstellen und Verwalten von Netzwerkressourcen und das Herstellen einer Verbindung mit Abrechnungsquellen. Sie haben mehr Zeit für wichtigere Projekte, anstatt Cloudkomponenten auf niedriger Ebene verwalten zu müssen.
• Benutzer profitieren von fast null Clusterstartlatenz und verbesserter Abfragekoncurrency.

Databricks bietet verwaltete Dienste für verschiedene Workloads:

• Serverlose SQL-Lagerhäuser für SQL-Workloads

  Arbeitsbereichsadministrator*innen können serverlose SQL-Warehouses erstellen, die sofort Computevorgänge ermöglichen und von Databricks verwaltet werden. Sie können mit Databricks-SQL-Abfragen auf die gleiche Weise verwendet werden wie normalerweise bei den ursprünglichen Databricks-SQL-Warehouses. Serverloses Computing zeichnet sich durch eine sehr schnelle Startzeit für SQL-Warehouses aus, und die Infrastruktur wird von Databricks verwaltet und optimiert.

• Serverlose Aufträge für effiziente und zuverlässige Workflows

  Serverloses Computing für Aufträge ermöglicht Ihnen, Ihren Databricks-Auftrag auszuführen, ohne Infrastruktur zu konfigurieren und bereitzustellen. Beim serverlosen Computing können Sie sich auf die Implementierung Ihrer Datenverarbeitungs- und Analysepipelines konzentrieren, während Databricks die Computeressourcen effizient verwaltet, einschließlich der Optimierung und Skalierung des Computings für Ihre Workloads. Die automatische Skalierung und Photon werden automatisch für die zur Ausführung Ihres Auftrags verwendeten Computeressourcen aktiviert.

  Sie können die Kosten von Aufträgen überwachen, die serverloses Computing für Aufträge verwenden, indem Sie die Systemtabelle für abrechenbaren Verbrauch abfragen.

• Serverloses Computing für Notebooks

  Wenn Ihr Arbeitsbereich für die serverlose interaktive Berechnung aktiviert ist, haben alle Benutzer im Arbeitsbereich Zugriff auf serverlose Berechnung für Notebooks. Es sind keine zusätzlichen Berechtigungen erforderlich.

Verwenden eines Diensts auf Unternehmensniveau

Mosaic AI Model Serving bietet eine einheitliche Schnittstelle zum Bereitstellen, Steuern und Abfragen Ihrer bereitgestellten KI-Modelle. Jedes von Ihnen bereitgestellte Modell ist als REST-API verfügbar, die Sie in Ihre Web- oder Clientanwendung integrieren können.

Die Modellbereitstellung bietet einen hochverfügbaren Dienst mit niedriger Latenz 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. Diese Funktionalität verwendet serverloses Compute.

3. Entwerfen von Workloads für die Leistung

Verstehen von Datenerfassungs- und Datenzugriffsmustern

Im Hinblick auf die Leistung verhalten sich Datenzugriffsmuster (z. B. „Aggregationen im Vergleich zu Punktzugriff“ oder „Scan im Vergleich zur Suche“) je nach Datengröße unterschiedlich. Große Dateien sind effizienter für Scanabfragen, und kleinere Dateien sind besser für Suchvorgänge, da Sie weniger Daten lesen müssen, um die spezifischen Zeilen zu finden.

Für Erfassungsmuster werden häufig DML-Anweisungen verwendet. DML-Anweisungen sind am leistungsfähigsten, wenn die Daten gruppiert sind, und der Datenabschnitt kann problemlos isoliert werden. Es ist wichtig, die Daten bei der Erfassung gruppiert und isolierbar zu halten. Behalten Sie ggf. eine natürliche Zeitsortierreihenfolge bei, und wenden Sie so viele Filter wie möglich auf die Erfassungszieltabelle an. Bei Erfassungsworkloads mit reiner Anfügung oder mit Überschreibung gibt es nicht viel zu beachten, da es sich hierbei um einen relativ günstigen Vorgang handelt.

Die Erfassungs- und Zugriffsmuster deuten häufig auf ein offensichtliches Datenlayout und auf eine entsprechende Gruppierung hin. Wenn nicht, entscheiden Sie, was für Ihr Unternehmen wichtiger ist, und konzentrieren Sie sich darauf, wie Sie dieses Ziel besser erreichen können.

Verwenden von paralleler Berechnung, wenn dies vorteilhaft ist

Bei der Arbeit mit Daten ist die Amortisationszeit eine wichtige Größe. Während viele Anwendungsfälle auf einem einzigen Computer (kleine Daten, wenige und einfache Rechenschritte) problemlos implementiert werden können, gibt es häufig Anwendungsfälle, die große Datasets verarbeiten müssen, lange Laufzeiten aufgrund komplizierter Algorithmen haben oder 1000 und 1000 Mal wiederholt werden müssen.

Die Clusterumgebung der Databricks-Plattform eignet sich sehr gut, um diese Workloads effizient zu verteilen. Sie parallelisiert SQL-Abfragen automatisch auf allen Knoten eines Clusters und stellt Bibliotheken für Python und Scala bereit, um dasselbe zu tun. Im Hintergrund analysieren die Engines Apache Spark und Photon die Abfragen, bestimmen die optimale Art der parallelen Ausführung und verwalten die verteilte Ausführung auf resiliente Weise.

Genau wie Batchaufgaben verteilt strukturiertes Streaming Streamingaufträge auf den gesamten Cluster, um eine optimale Leistung zu erzielen.

Eine der einfachsten Möglichkeiten, paralleles Computing zu verwenden, sind Delta Live Tables. Sie deklarieren Aufgaben und Abhängigkeiten eines Auftrags in SQL oder Python, und Delta Live Tables übernimmt die Ausführungsplanung, effiziente Infrastruktureinrichtung, Auftragsausführung und Überwachung.

pandas ist ein Python-Paket für wissenschaftliche Fachkräfte für Daten, das benutzerfreundliche Datenstrukturen und Datenanalysetools für die Python-Programmiersprache bereitstellt. Allerdings kann Pandas nicht für Big Data aufskaliert werden. Die Pandas-API in Spark schließt diese Lücke durch die Bereitstellung von Pandas-äquivalenten APIs, die mit Apache Spark kompatibel sind.

Darüber hinaus verfügt die Plattform über parallelisierte Machine Learning-Algorithmen in der Standard-Machine Learning-Bibliothek MLlib. Es unterstützt die sofort einsatzbereite Multi-GPU-Nutzung. Deep Learning kann auch mit dem DeepSpeed-Verteiler oder mit TorchDistributor parallelisiert werden.

Analysieren der gesamten Ausführungskette

Die meisten Pipelines oder Nutzungsmuster verwenden eine Kette von Systemen. Bei BI-Tools wird die Leistung beispielsweise durch mehrere Faktoren beeinflusst. Hierzu zählen:

• Das BI-Tool selbst
• Der Connector, der das BI-Tool und die SQL-Engine miteinander verbindet
• Das SQL-Modul, an das das BI-Tool die Abfrage sendet.

Um eine optimale Leistung zu erzielen, muss die gesamte Kette berücksichtigt und ausgewählt/optimiert werden, um eine optimale Leistung zu erzielen.

Bevorzugen großer Cluster

Planen Sie für größere Cluster – insbesondere, wenn die Workload linear skaliert wird. In diesem Fall ist die Verwendung eines großen Clusters für eine Workload nicht teurer als die Verwendung eines kleineren Clusters. Es ist lediglich schneller. Der Schlüssel ist, dass Sie den Cluster für die Dauer der Workload mieten. Wenn Sie also zwei Workercluster starten und es eine Stunde dauert, zahlen Sie die volle Stunde für diese Worker. Analog dazu gilt: Wenn Sie einen Cluster mit vier Workern starten und es nur eine halbe Stunde dauert (hier kommt die lineare Skalierbarkeit ins Spiel), sind die Kosten gleich. Wenn bei einer sehr flexiblen SLA die Kosten im Vordergrund stehen, ist ein Cluster mit automatischer Skalierung normalerweise die günstigste Lösung, aber nicht unbedingt die schnellste.

Hinweis

Das Bevorzugen großer Cluster ist für die serverlose Berechnung nicht erforderlich, da Cluster automatisch verwaltet werden.

Verwenden nativer Spark-Vorgänge

Benutzerdefinierte Funktionen (User Defined Functions, UDFs) eignen sich sehr gut, um den Funktionsumfang von Spark SQL zu erweitern. Verwenden Sie jedoch keine Python- oder Scala-UDFs, wenn eine native Funktion vorhanden ist:

• Spark SQL
• PySpark

Gründe:

• Serialisierung ist für die Übertragung von Daten zwischen Python und Spark erforderlich. Dadurch werden Abfragen erheblich verlangsamt.
• Erhöhter Aufwand zum Implementieren und Testen von Funktionen, die bereits auf der Plattform vorhanden sind.

Wenn native Funktionen fehlen und als Python-UDFs implementiert werden sollen, verwenden Sie pandas-UDFs. Apache Arrow stellt sicher, dass Daten effizient zwischen Spark und Python übertragen werden.

Verwenden von nativen Plattformmodulen

Photon ist die Engine in Azure Databricks, die eine hohe Abfrageleistung zu niedrigen Kosten direkt in Ihrem Data Lake bietet – von Datenerfassung über ETL, Streaming und Data Science bis hin zu interaktiven 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.

Photon ist Teil einer High-Performance-Runtime, mit der Ihre vorhandenen SQL- und DataFrame-API-Aufrufe schneller ausgeführt und die Gesamtkosten pro Workload reduziert werden. Photon wird standardmäßig in Databricks SQL-Warehouses verwendet.

Verstehen Ihrer Hardware und Ihres Workloadtyps

Nicht alle virtuellen Cloudcomputer sind gleich. Die Unterschiede zwischen den verschiedenen Computerfamilien von Cloudanbietern sind groß genug, um relevant zu sein. Es gibt offensichtliche Unterschiede (RAM und Kerne) und weniger offensichtliche Unterschiede wie Prozessortyp und -generation, garantierte Netzwerkbandbreite und lokalen Hochgeschwindigkeitsspeicher bzw. lokale Datenträger oder Remotedatenträger. Auch gibt es Unterschiede bei den Spot-Märkten. Diese müssen klar sein, bevor Sie sich für den besten VM-Typ für Ihre Workload entscheiden.

Hinweis

Dies ist für die serverlose Berechnung nicht erforderlich, da die serverlose Berechnung automatisch Cluster verwaltet.

Verwenden von Zwischenspeicherung

Zwischenspeichern von häufig aufgerufenen Daten in einem schnelleren Medium, wodurch die zum Abrufen erforderliche Zeit im Vergleich zum Zugriff auf die ursprüngliche Datenquelle reduziert wird. Dies führt zu einer geringeren Latenz und schnelleren Reaktionszeiten, die die Gesamtleistung und Benutzererfahrung einer Anwendung erheblich verbessern können. Durch die Minimierung der Anzahl der Anforderungen an die ursprüngliche Datenquelle trägt die Zwischenspeicherung dazu bei, den Netzwerkdatenverkehr und die Datenübertragungskosten zu reduzieren. Dieser Effizienzgewinn kann besonders für Anwendungen von Vorteil sein, die auf externen APIs oder Pay-per-Use-Datenbanken basieren. Er kann dazu beitragen, die Last gleichmäßiger über das System zu verteilen, Engpässe und potenzielle Ausfallzeiten zu verhindern.

In Azure Databricks stehen mehrere Arten von Zwischenspeicherung zur Verfügung. Nachfolgend sind die Merkmale der einzelnen Typen aufgeführt:

• Verwenden von Datenträgercaches

  Im Datenträgercache (ehemals „Delta-Cache“) werden Kopien von Remotedaten auf den lokalen Datenträgern der VMs gespeichert (z. B. auf einer SSD). Er kann zwar die Leistung einer Vielzahl von Abfragen verbessern, aber nicht verwendet werden, um die Ergebnisse beliebiger Unterabfragen zu speichern. Der Datenträgercache erkennt automatisch, wenn Datendateien erstellt oder gelöscht werden, und aktualisiert seine Inhalte entsprechend. Der empfohlene (und einfachste) Weg, Datenträgercaching zu verwenden, ist die Auswahl eines Workertyps mit SSD-Volumes, wenn Sie Ihr Cluster konfigurieren. Solche Worker sind für Datenträgercaching aktiviert und konfiguriert.

• Vermeiden der Spark-Zwischenspeicherung

  Der Spark-Cache (durch Verwendung von .persist() und .unpersist()) kann das Ergebnis beliebiger Unterabfragedaten sowie Daten speichern, die in anderen Formaten als Parquet gespeichert sind (z. B. CSV, JSON und ORC). Wenn sie jedoch an den falschen Stellen in einer Abfrage verwendet wird, kann sie den gesamten Arbeitsspeicher verbrauchen und sogar Abfragen erheblich verlangsamen. Als Faustregel gilt: Vermeiden Sie die Spark-Zwischenspeicherung, es sei denn, Sie kennen die genauen Auswirkungen.

• Cache für Abfrageergebnisse

  Clusterspezifische Zwischenspeicherung von Abfrageergebnissen für alle Abfragen über SQL-Warehouses. Um von der Zwischenspeicherung von Abfrageergebnissen profitieren zu können, sollten Sie sich auf deterministische Abfragen konzentrieren, die z. B. keine Prädikate wie = NOW() verwenden. Wenn eine Abfrage deterministisch ist und die zugrunde liegenden Daten im Deltaformat vorliegen und unverändert sind, geben SQL-Warehouses das Ergebnis direkt aus dem Cache für Abfrageergebnisse zurück.

• Zwischenspeicherung auf der Databricks SQL-Benutzeroberfläche

  Benutzerspezifische Zwischenspeicherung aller Abfrage- und Legacy-Dashboardergebnisse auf der Databricks SQL-Benutzeroberfläche.

Verwenden von Komprimierung

Delta Lake in Azure Databricks kann die Geschwindigkeit von Leseabfragen aus einer Tabelle verbessern. Eine Möglichkeit besteht darin, kleine Dateien in größere Dateien zusammenzugliedern. Sie lösen die Komprimierung aus, indem Sie den Befehl OPTIMIZE ausführen. Siehe Optimieren des Datendateilayouts.

Delta Lake bietet Optionen zum automatischen Konfigurieren der Zieldateigröße für Schreibvorgänge und für OPTIMIZE Vorgänge. Databricks stimmt viele dieser Einstellungen automatisch ab und aktiviert Features, die die Tabellenleistung automatisch verbessern, indem sie nach Dateien mit der richtigen Größe suchen:

• Bei der automatischen Komprimierung werden kleine Dateien in Delta-Tabellenpartitionen kombiniert, sodass kleine Dateiprobleme automatisch reduzier werden. Die automatische Komprimierung tritt auf, nachdem ein Schreibvorgang in eine Tabelle erfolgreich war, und wird synchron auf dem Cluster ausgeführt, der den Schreibvorgang ausgeführt hat. Bei der automatischen Komprimierung werden nur Dateien komprimiert, die zuvor noch nicht komprimiert wurden.
• Optimierte Schreibvorgänge verbessern die Dateigröße, während Daten geschrieben werden, und nutzen nachfolgende Lesevorgänge in der Tabelle. Optimierte Schreibvorgänge sind für partitionierte Tabellen am effektivsten, da sie die Anzahl der kleinen Dateien reduzieren, die in jede Partition geschrieben werden.

Siehe Konfigurieren von Delta Lake zum Steuern der Datendateigröße für weitere Details.

Überspringen von Daten

Das Überspringen von Daten kann die Abfrageleistung erheblich verbessern, indem Daten übersprungen werden, die nicht den Abfragekriterien entsprechen. Dadurch wird die Datenmenge reduziert, die gelesen und verarbeitet werden muss, was zu schnelleren Abfrageausführungszeiten führt.

Hierzu werden automatisch Informationen zur Überspringung von Daten gesammelt, wenn Sie Daten in eine Delta-Tabelle schreiben. (Standardmäßig sammelt Delta Lake in Azure Databricks Statistiken für die ersten 32 Spalten, die in Ihrem Tabellenschema definiert sind). Delta Lake in Azure Databricks nutzt diese Informationen (Mindest- und Höchstwerte) zur Abfragezeit, um schnellere Abfragen zu ermöglichen. Weitere Informationen finden Sie unter Überspringen von Daten für Delta Lake.

Die folgenden Techniken können für das Überspringen von Daten angewendet werden:

• Z-Sortierung, eine Technik zum Zusammensetzen verwandter Informationen in derselben Gruppe von Dateien. Diese Colocation wird in Azure Databricks automatisch von den Delta Lake-Algorithmen zum Überspringen von Daten genutzt. Dieses Verhalten reduziert die Menge der Daten, die Delta Lake lesen muss.

• Liquid Clustering vereinfacht Datenlayoutentscheidungen und optimiert die Abfrageleistung. Sie ersetzt Partitionierung und Z-Sortierung im Laufe der Zeit. Databricks empfiehlt Liquid Clustering für alle neuen Delta-Tabellen. Liquid Clustering bietet die Flexibilität, Clusteringschlüssel neu zu definieren, ohne vorhandene Daten neu zu schreiben, sodass Datenlayouts im Laufe der Zeit mit analytischen Anforderungen weiterentwickelt werden können. Databricks empfiehlt Liquid Clustering für alle neuen Delta-Tabellen.

  Tabellen mit den folgenden Merkmalen profitieren von flüssiger Clusterung:

  • Gefiltert nach Spalten mit hoher Kardinalität.
  • Mit deutlich schiefer Datenverteilung.
  • Das wächst schnell und erfordert Wartungs- und Optimierungsaufwand.
  • Mit gleichzeitigen Schreibanforderungen.
  • Mit Zugriffsmustern, die sich im Laufe der Zeit ändern.
  • Bei denen ein typischer Partitionsschlüssel dazu führen kann, dass die Tabelle zu viele oder zu wenige Partitionen hat.

Weitere Details und Techniken finden Sie im umfassenden Leitfaden zum Optimieren von Databricks-, Spark- und Delta Lake-Workloads.

Aktivierung Prädiktive Optimierung für Delta Lake

Durch die prädiktive Optimierung entfällt die Notwendigkeit, Wartungsvorgänge für Deltatabellen in Databricks manuell zu verwalten. Wenn die prädiktive Optimierung aktiviert ist, identifiziert Databricks automatisch Tabellen, die von Wartungsvorgängen profitieren würden und führt diese für die Benutzer*innen aus. Wartungsvorgänge werden nur nach Bedarf ausgeführt, wodurch sowohl die unnötige Ausführung von Wartungsvorgängen als auch der Aufwand für die Nachverfolgung und Problembehandlung sowie die damit zusammenhängende Leistung entfallen.

Vermeiden von übermäßige Partitionierung

In der Vergangenheit war Partitionieren die gängigste Methode zum Überspringen von Daten. Die Partitionierung ist jedoch statisch und manifestiert sich als Dateisystemhierarchie. Es gibt keine einfache Möglichkeit, Partitionen zu ändern, da sich die Zugriffsmuster im Laufe der Zeit verändern. Die Partitionierung führt häufig zu einer übermäßigen Partitionierung (zu viele Partitionen mit zu kleinen Dateien), wodurch sich wiederum die Abfrageleistung verschlechtert.

Databricks empfiehlt, keine Partitionstabellen unter 1 TB Größe zu partitionieren und nur nach einer Spalte zu partitionieren, wenn Sie erwarten, dass die Daten in jeder Partition mindestens 1 GB groß sind.

In der Zwischenzeit ist eine bessere Wahl als die Partitionierung Z-Sortierung oder das neuere Liquid Clustering (siehe oben).

Optimieren der Leistung beim Verknüpfen

• Erwägen Sie die Optimierung von Bereichsverknüpfungen.

  Ein Bereichsjoin tritt auf, wenn zwei Beziehungen mithilfe eines Punkts im Intervall oder einer Intervallüberlappungsbedingung verbunden werden. Die Unterstützung der Optimierung von Bereichsverknüpfungen in Databricks Runtime kann zu einer deutlichen Verbesserung der Abfrageleistung führen, erfordert jedoch eine sorgfältige manuelle Optimierung.

• Nutzen Sie Ausführung von adaptiven Abfragen.

  Die adaptive Abfrageausführung (Adaptive Query Execution, AQE) ist eine erneute Optimierung von Abfragen, die während der Abfrageausführung erfolgt. AQE umfasst vier Hauptfunktionen:

  • Dynamische Änderung von Sort-Merge-Join in Broadcast-Hash-Join.
  • Koppelt Partitionen dynamisch nach dem Shuffle-Austausch.
  • Behandelt dynamisch schiefe Sortierzusammenführungsverknuppung und Shuffle-Hashverknügung.
  • Dynamische Erkennung und Weitergabe von leeren Beziehungen.

  Es wird empfohlen, AQE aktiviert zu lassen. Verschiedene Features können separat konfiguriert werden.

Weitere Details finden Sie im umfassenden Leitfaden zur Optimierung von Databricks-, Spark- und Delta Lake-Workloads.

Ausführen von ANALYZE TABLE zum Sammeln von Tabellenstatistiken

Die ANALYZE TABLE Anweisung sammelt Statistiken zu Tabellen in einem angegebenen Schema. Diese Statistiken werden vom Abfrageoptimierer verwendet, um einen optimalen Abfrageplan zu generieren, den richtigen Verknüpfungstyp auszuwählen, die richtige Buildseite in einer Hashverknüpfung auszuwählen oder die Verknüpfungsreihenfolge in einer multidirektionalen Verknüpfung zu kalibrieren.

Die Predictive Optimization führt automatisch den Befehl ANALYZE (Public Preview) zum Sammeln von Statistiken in den vom Unity Catalog verwalteten Tabellen aus. Databricks empfiehlt die Aktivierung der prädiktiven Optimierung für alle verwalteten Tabellen im Unity-Katalog, um die Datenwartung zu vereinfachen und die Speicherkosten zu reduzieren. Weitere Informationen finden Sie unter Prädiktive Optimierung für verwaltete Unity Catalog-Tabellen.

4. Ausführen von Leistungstests im Bereich der Entwicklung

Testen mit Daten, die für Produktionsdaten repräsentativ sind

Führen Sie Leistungstests für Produktionsdaten (schreibgeschützt) oder ähnliche Daten durch. Bei Verwendung ähnlicher Daten sollten Merkmale wie Volume, Dateilayout und Datenschiefe den Merkmalen der Produktionsdaten entsprechen, da dies erhebliche Auswirkungen auf die Leistung hat.

Berücksichtigen Sie das Vorwarnen von Ressourcen

Unabhängig vom Abfrage- und Datenformat ist die erste Abfrage eines Clusters immer langsamer als nachfolgende Abfragen. Dies liegt daran, dass alle verschiedenen Subsysteme gestartet und alle benötigten Daten gelesen werden. Das „Vorwärmen“ wirkt sich erheblich auf die Leistungstestergebnisse aus:

• Cluster vorwärmen: Clusterressourcen müssen auf mehreren Ebenen initialisiert werden. Es ist möglich, Cluster „vorzuwärmen“: Databricks-Pools sind eine Reihe von leerlauffähigen, einsatzbereiten Instanzen. Wenn Clusterknoten mithilfe der sich im Leerlauf befindenden Instanzen erstellt werden, werden die Start- und Autoskalierungszeiten des Clusters reduziert.
• Caches vorwärmen: Wenn das Setup eine Zwischenspeicherung beinhaltet, stellt die erste Ausführung sicher, dass sich die Daten im Cache befinden, wodurch nachfolgende Aufträge beschleunigt werden. Caches können vorgewärmt werden, indem bestimmte Abfragen ausgeführt werden, um Caches zu initialisieren (z. B. nach einem Clusterneustart). Dies kann die Leistung der ersten Abfragen erheblich verbessern.

Testen Sie daher die Leistung der ersten Ausführung (mit und ohne Vorwärmung) sowie der nachfolgenden Ausführungen, um das Verhalten für die verschiedenen Szenarien zu verstehen.

Identifizieren von Engpässen

Engpässe sind Bereiche in Ihrer Workload, die die Gesamtleistung beeinträchtigen könnten, da die Auslastung in der Produktion zunimmt. Diese zur Entwurfszeit zu identifizieren und mit höheren Workloads zu testen, trägt dazu bei, dass die Workloads in der Produktion stabil bleiben.

5. Überwachen der Leistung

Überwachen der Abfrageleistung

Die Überwachung der Abfrageleistung hilft Ihnen zu verstehen, wie Ressourcen von verschiedenen Abfragen verwendet werden. Sie können Abfragen identifizieren, die langsam ausgeführt werden, sodass Sie Leistungsengpässe in Ihrem System anheften können. Sie können auch Abfragen identifizieren, die erhebliche Systemressourcen verbrauchen, was möglicherweise zu Instabilität oder Ausfallzeiten führt. Diese Informationen helfen Ihnen, die Ressourcenzuordnung zu optimieren, Abfälle zu reduzieren und sicherzustellen, dass Ressourcen effizient verwendet werden.

Die Databricks Data Intelligence Platform verfügt über verschiedene Überwachungsfunktionen (siehe Operational Excellence – Einrichten von Überwachung, Alarmierung und Protokollierung), von denen einige zur Leistungsüberwachung verwendet werden können:

• Abfrageprofil: Verwenden Sie das Abfrageprofilfeature, um Leistungsengpässe während der Abfrageausführung zu beheben. Es stellt die Visualisierung jeder Abfrageaufgabe und zugehöriger Metriken bereit, z. B. zeitverwendete Zeit, Anzahl der verarbeiteten Zeilen und verwendete Arbeitsspeicher.
• SQL Warehouse Monitoring: Überwachen von SQL-Lagerhäusern durch Anzeigen von Livestatistiken, Spitzenabfragezählungsdiagrammen, Ausführen von Clusterdiagrammen und Abfrageverlaufstabelle

Überwachen von Streamingworkloads

Mithilfe der Streamingüberwachung können Sie Daten analysieren und Probleme erkennen, sobald sie auftreten, und bietet Einblicke in Echtzeit in die Leistung und das Verhalten Ihres Systems. Durch die Analyse von Streamingdaten können Sie Trends, Muster und Optimierungsmöglichkeiten identifizieren. Dies kann Ihnen helfen, Ihr System zu optimieren, die Ressourcenauslastung zu verbessern und Kosten zu senken.

Verwenden Sie für Streamingabfragen die integrierte Überwachung des strukturierten Streamings in der Spark-Benutzeroberfläche oder Pushmetriken an externe Dienste mithilfe der Apache Spark Streaming Query Listener-Schnittstelle.

Überwachen der Auftragsleistung

Mit der Auftragsüberwachung können Sie Probleme in Ihren Databricks-Aufträgen identifizieren und beheben, z. B. Fehler, Verzögerungen oder Leistungsengpässe. Die Auftragsüberwachung bietet Einblicke in die Auftragsleistung, sodass Sie die Ressourcenauslastung optimieren, die Verschwendung reduzieren und die Gesamteffizienz verbessern können.