Dimensionierung, automatische Skalierung und Warteschlangenverhalten von SQL-Warehouse

In diesem Artikel wird die Cluster-Dimensionierung, das Warteschlangenverhalten und die automatische Skalierung von SQL-Warehouses erläutert.

Dimensionierung eines serverlosen SQL-Warehouse

Beginnen Sie immer mit einer größeren T-Shirt-Größe für Ihr serverloses SQL-Warehouse, als Sie annehmen, für das Testen zu benötigen, und verkleinern Sie es bei Ihren Tests. Beginnen Sie nicht mit einer kleinen T-Shirt-Größe für Ihr serverloses SQL-Warehouse, und vergrößern Sie es dann. Beginnen Sie im Regelfall mit einem einzelnen serverlosen SQL-Warehouse, und lassen Sie Azure Databricks die richtige Dimensionierung durch serverlosen Clustern, Priorisierung von Workloads und schnellen Datenlesevorgängen ermitteln. Weitere Informationen finden Sie unter Serverlose automatische Skalierung und Abfragewarteschlangen.

• So verringern Sie die Abfragelatenz für ein bestimmtes serverloses SQL-Warehouse
  • Wenn Abfragen auf der Festplatte zu einem Überlauf führen, erhöhen Sie die T-Shirt-Größe.
  • Wenn die Abfragen sehr stark parallelisierbar sind, erhöhen Sie die T-Shirt-Größe.
  • Wenn Sie mehrere Abfragen gleichzeitig ausführen, fügen Sie für die automatische Skalierung weitere Cluster hinzu.
• Versuchen Sie, zum Senken der Kosten die T-Shirt-Größe zu reduzieren, ohne einen Überlauf auf der Festplatte zu erzeugen oder die Latenz erheblich zu erhöhen.
• Verwenden Sie die folgenden Tools, um die richtige Größe für Ihr serverlose SQL-Warehouse zu ermitteln:
  • Seite „Überwachung“: Sehen Sie sich die Spitzenanzahl für Abfragen an. Wenn der Spitzenwert in der Warteschlange häufig oberhalb von eins liegt, fügen Sie Cluster hinzu. Die maximale Anzahl von Abfragen in einer Warteschlange für alle SQL Warehouse-Typen beträgt 1.000. Siehe Überwachen eines SQL-Warehouse.
  • Abfrageverlauf Weitere Informationen finden Sie unter Abfrageverlauf.
  • Abfrageprofile (suchen Sie nach einem Wert für Byteüberlauf auf dem Datenträger über 1). Siehe Abfrageprofil.

Hinweis

Für serverlose SQL-Warehouses können die Clustergrößen in einigen Fällen andere Instanztypen verwenden als die in der Dokumentation für Pro und klassische Warehouses für eine entsprechende Clustergröße aufgeführten. Im Allgemeinen ist das Preis-Leistungsverhältnis der Clustergrößen für serverlose SQL-Warehouses ähnlich wie für Pro und klassische SQL-Warehouses.

Serverlose automatische Skalierung und Abfragewarteschlangen.

Die Intelligente Workloadverwaltung (IWM) bietet eine Reihe von Features, die die Fähigkeit von serverlosen SQL-Warehouses zum schnellen und kostengünstigen Verarbeiten großer Abfragemengen verbessern. Mit KI-basierten Vorhersagefunktionen zum Analysieren eingehender Abfragen und der Ermittlung der schnellsten und effizientesten Verfahren (prädiktive E/A) stellt IWM sicher, dass Workloads schnell die richtige Menge an Ressourcen erhalten. Der Hauptunterschied liegt in den KI-Funktionen in Databricks SQL, um dynamisch auf Workloadanforderungen zu reagieren, anstatt statische Schwellenwerte zu verwenden.

Diese Reaktionsfähigkeit stellt Folgendes sicher:

• Schnelles Hochskalieren, um bei Bedarf mehr Computeressourcen zu erhalten und eine niedrige Latenz aufrechtzuerhalten
• Abfragezugang näher an der Einschränkung der Hardware
• Schnelles Herunterskalieren, um Kosten zu minimieren, wenn die Nachfrage niedrig ist, und eine konsistente Leistung mit optimierten Kosten und Ressourcen bereitzustellen

Wenn eine Abfrage im Warehouse eintrifft, prognostiziert IWM die Kosten für die Abfrage. Gleichzeitig überwacht IWM die verfügbare Computekapazität des Warehouse in Echtzeit. Als Nächstes prognostiziert IWM mithilfe von Machine Learning-Modellen, ob die erforderliche Computeressourcen die eingehende Abfrage verfügbar sind. Wenn die erforderlichen Computeressourcen nicht verfügbar sind, wird die Abfrage in die Warteschlange gestellt. Wenn die erforderlichen Computeressourcen verfügbar sind, wird die Abfrage sofort ausgeführt.

IWM überwacht die Warteschlange ungefähr alle 10 Sekunden. Wenn die Warteschlange nicht schnell genug abnimmt, erfolgt eine automatische Skalierung, um schnell mehr Computeressourcen bereitzustellen. Nachdem neue Kapazität hinzugefügt wurde, werden die Abfragen in der Warteschlange an die neuen Cluster übertragen. Mit serverlosen SQL-Warehouses können schnell neue Cluster hinzugefügt werden, und es können gleichzeitig mehrere Cluster erstellt werden. Die maximale Anzahl von Abfragen in einer Warteschlange für alle SQL Warehouse-Typen beträgt 1.000.

Clustergrößen für SQL-Warehouses vom Typ „Pro“ und „Klassisch“

In der Tabelle in diesem Abschnitt werden die Clustergrößen von SQL-Warehouses der Treibergröße und Workeranzahl des Azure Databricks-Clusters zugeordnet. Die Treibergröße gilt nur für Pro und klassische SQL-Warehouses.

Clustergröße	Instanztyp für Treiber (gilt nur für Pro und klassische SQL-Warehouses)	Workeranzahl
2X-Small	Standard_E8ds_v4	1 x Standard_E8ds_v4
X-Small	Standard_E8ds_v4	2 x Standard_E8ds_v4
Klein	Standard_E16ds_v4	4 x Standard_E8ds_v4
Mittel	Standard_E32ds_v4	8 x Standard_E8ds_v4
Groß	Standard_E32ds_v4	16 x Standard_E8ds_v4
XL	Standard_E64ds_v4	32 x Standard_E8ds_v4
2X-Large	Standard_E64ds_v4	64 x Standard_E8ds_v4
3X-Large	Standard_E64ds_v4	128 x Standard_E8ds_v4
4X-Large	Standard_E64ds_v4	256 x Standard_E8ds_v4

Die Instanzgröße aller Workers ist „Standard_E8ds_v4“.

An jeden Treiber und Worker sind acht verwaltete Standard-LRS-Datenträger mit 128 GB angefügt. Angefügte Datenträger werden pro Stunde berechnet.

Erforderliches Azure vCPU-Kontingent für SQL-Warehouses vom Typ „Classic“ und „Pro“

Zum Starten eines SQL-Warehouse Classic oder Pro müssen Sie über ein entsprechendes Azure-vCPU-Kontingent für Standard_E8ds_v4-Instanzen in Ihrem Azure-Konto verfügen. Verwenden Sie die folgenden Richtlinien, um das erforderliche vCPU-Kontingent zu ermitteln:

• Wenn Sie nur über ein bis zwei SQL-Warehouses verfügen, achten Sie darauf, dass für jeden Kern im Cluster acht Azure-vCPUs verfügbar sind. Dadurch wird sichergestellt, dass Sie über ein ausreichendes Azure-vCPU-Kontingent verfügen, das auch das erneute Bereitstellen Ihres Warehouse (das ungefähr alle 24 Stunden erfolgt) unterstützt. Wenn Sie für Ihre SQL-Warehouses die automatische Skalierung oder den Lastenausgleich über mehrere Cluster verwenden, müssen Sie möglicherweise den Multiplikator erhöhen.
• Bei zunehmender Anzahl von SQL-Warehouses sollten Sie für jeden Kern im Cluster zwischen vier und acht Azure-vCPUs zulassen. Databricks empfiehlt, mit einer größeren Anzahl zu beginnen und die Stabilität zu überwachen.
• Von SQL-Warehouses verwendete Azure-vCPUs werden zusätzlich zu den Azure-vCPUs verwendet, die von Data Science und Entwickllung oder von Databricks-fremden Workloads genutzt werden.

Informationen zum Anfordern eines zusätzlichen Azure vCPU-Kontingents finden Sie in der Azure-Dokumentation unter Standardkontingent: Erhöhen der Grenzwerte nach VM-Serie.

Hinweis

Die Informationen in dieser Tabelle können je nach Produkt- oder Regionsverfügbarkeit und Arbeitsbereichstyp variieren.

Warteschlangen und automatische Skalierung für SQL-Warehouses vom Typ „Pro“ und „Klassisch“

Azure Databricks begrenzt die Anzahl von Abfragen in einem Cluster, der einem SQL-Warehouse zugewiesen ist, basierend auf den Kosten für die Berechnung ihrer Ergebnisse. Das Hochskalieren von Clustern pro Warehouse basiert auf dem Abfragedurchsatz, der Rate eingehender Abfragen und der Warteschlangengröße. Azure Databricks empfiehlt jeweils einen Cluster für zehn gleichzeitige Abfragen. Die maximale Anzahl von Abfragen in einer Warteschlange für alle SQL Warehouse-Typen beträgt 1.000.

Azure Databricks fügt Cluster auf Basis der für die Verarbeitung aller aktuell ausgeführten Abfragen, aller Abfragen in der Warteschlange sowie der in den nächsten zwei Minuten wahrscheinlich eingehenden Abfragen erforderliche Zeit hinzu.

• Weniger als 2 Minuten > keine Hochskalierung
• 2 bis 6 Minuten > 1 zusätzlicher Cluster
• 6 bis 12 Minuten > 2 zusätzliche Cluster
• 12 bis 22 Minuten > 3 zusätzliche Cluster

Ansonsten fügt Azure Databricks 3 Cluster plus 1 Cluster für alle weiteren 15 Minuten erwarteter Abfragelast hinzu.

Darüber hinaus wird ein Warehouse immer hochskaliert, wenn eine Abfrage fünf Minuten in der Warteschlange wartet.

Wenn die Last 15 Minuten lang niedrig ist, skaliert Azure Databricks das SQL-Warehouse herunter. Es werden jedoch genügend Cluster beibehalten, um die Spitzenlast in den letzten 15 Minuten zu verarbeiten. Wenn die Spitzenlast beispielsweise 25 gleichzeitige Abfragen beträgt, behält Azure Databricks drei Cluster bei.

Abfragewarteschlange für SQL-Warehouses vom Typ „Pro“ und „Klassisch“

Azure Databricks platziert Abfragen in der Warteschlange, wenn die Kapazität für Abfragen bei allen Clustern, die dem Warehouse zugewiesen sind, ausgeschöpft ist oder sich das Warehouse im Zustand STARTING befindet. Die maximale Anzahl von Abfragen in einer Warteschlange für alle SQL Warehouse-Typen beträgt 1.000.

Metadatenabfragen (z. B. DESCRIBE <table>) und zustandsändernde Abfragen (z. B. SET) werden nur in der Warteschlange platziert, wenn sich das Warehouse im Zustand STARTING befindet.