Dimensionierung, automatische Skalierung und Warteschlangenverhalten von SQL-Warehouse

In diesem Artikel wird erläutert, wie Sie Abfragewarteschlangen für Databricks SQL Warehouses skalieren, skalieren und verwalten, um die Leistung und die Kosten zu optimieren. Databricks empfiehlt die Verwendung eines serverlosen SQL-Warehouses für die meisten Workloads. Serverlose SQL-Lagerhäuser bieten die beste Leistung und Effizienz, indem Ressourcen für Ihre Abfragen dynamisch verwaltet werden.

Serverlose SQL-Lagerverwaltung

Serverlose SQL-Lagerhäuser verwenden intelligente Workload-Verwaltung (IWM), um Abfrageworkloads automatisch zu verwalten. IWM ist eine Reihe von KI-basierten Features, die Abfragen schnell und kosteneffizient verarbeiten, ohne dass Sie die Infrastruktur verwalten müssen.

Intelligente Workloadverwaltung und automatische Skalierung

IWM verwendet Machine Learning-Modelle zum dynamischen Verwalten von Computeressourcen:

• Wenn eine neue Abfrage eingeht, prognostiziert IWM die Ressourcenanforderungen und überprüft die verfügbare Kapazität.
  • Wenn kapazität vorhanden ist, wird die Abfrage sofort gestartet.
  • Wenn nicht, wird die Abfrage in einer Warteschlange platziert.
• IWM überwacht die Warteschlange kontinuierlich. Wenn die Wartezeiten steigen, stellt der Autoscaler schnell mehr Cluster bereit, um in die Warteschlange eingereihte Abfragen zu verarbeiten.
• Wenn die Nachfrage sinkt, skaliert IWM Ressourcen, um Die Kosten zu senken und gleichzeitig genügend Kapazität zur Bewältigung der letzten Spitzenlasten zu erhalten.

Dieser Ansatz bietet Folgendes:

• Schnelles Upscaling, um niedrige Abfragelatenz aufrechtzuerhalten.
• Hoher Durchsatz durch Zulassen von Abfragen, sobald Hardware verfügbar ist.
• Schnelles Herunterskalieren, um Kosten bei geringer Nachfrage zu sparen.

Größe eines serverlosen SQL-Lagerlagers

Die Clustergröße (z. B. X-Small, Medium, Large) bestimmt die für einen einzelnen Cluster verfügbaren Computeressourcen. Der Autoscaler fügt bei Bedarf Cluster dieser Größe hinzu oder entfernt sie.

Verwenden Sie die folgenden Richtlinien, um die richtige Größe auszuwählen:

• Beginnen Sie mit einem einzigen größeren Lagerhaus, und lassen Sie serverlose Features Parallelität und Leistung verwalten. Es ist in der Regel effizienter, sich bei Bedarf zu verkleineren, als klein zu beginnen und hochzuskalieren.
• Wenn Abfragen auf den Datenträger überlaufen, erhöhen Sie die Clustergröße. Überprüfen Sie im Abfrageprofil auf Überlauf.
• Konfigurieren Sie für Workloads mit vielen gleichzeitigen Abfragen eine ausreichende maximale Anzahl von Clustern, um Spitzenlasten zu verarbeiten. Überwachen Der Metrik "Spitzenwarteschlangenabfragen " auf der Seite "Lagerüberwachung".

Hinweis

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

Überwachen der Lagerleistung

Sie können jedes SQL-Lager mit diesen Tools überwachen und die richtige Größe haben. Die maximale Anzahl von Abfragen in einer Warteschlange für alle Lagertypen beträgt 1.000.

• Überwachungsseite: Überprüfen Sie auf der Registerkarte "SQL Warehouse-Überwachung" Spitzenabfragen in der Warteschlange. Ein konsistenter Wert über 0 gibt an, dass Sie möglicherweise eine größere Clustergröße oder mehr Cluster benötigen.
• Abfrageverlauf: Überprüfen Sie die Leistung der historischen Abfrage, um Engpässe zu identifizieren.
• Abfrageprofil: Überprüfen Sie Ausführungspläne auf Metriken wie Bytes, die auf den Datenträger übergelaufen sind, was angibt, dass die Lagergröße möglicherweise zu klein ist.

Klassische und pro SQL-Lagerhäuser

Klassische und Pro Warehouses verwenden ein manuelles Skalierungsmodell, in dem Sie die Anzahl der Cluster konfigurieren.

Größe und Clusterbereitstellung

Wenn Sie ein klassisches oder Pro Warehouse erstellen, wählen Sie eine Clustergröße aus, und legen Sie die mindeste und maximale Anzahl von Clustern fest. Diese SKUs haben eine feste Grenze von einem Cluster pro 10 gleichzeitigen Abfragen.

Clustergröße	Treiberinstanztyp	Workeranzahl
2X-Klein	Standard_E8ds_v4	1 x Standard_E8ds_v4
X-Klein	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-Groß	Standard_E64ds_v4	64 x Standard_E8ds_v4
3X-Groß	Standard_E64ds_v4	128 x Standard_E8ds_v4
4XL	Standard_E64ds_v4	256 x Standard_E8ds_v4

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

Jeder Fahrer und jeder Arbeiter hat einen verwalteten 256 GB Premium SSD LRS-Datenträger angeschlossen. Die angeschlossenen Datenträger werden stündlich in Rechnung gestellt.

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 oder zwei SQL-Lagerhäuser verfügen, stellen Sie sicher, dass 8 Azure vCPU für jeden Kern im Cluster verfügbar ist. Dadurch wird sichergestellt, dass Sie über ausreichend Azure vCPU verfügen, um die Erneute Bereitstellung Ihres Lagers zu ermöglichen, was ungefähr alle 24 Stunden geschieht. Möglicherweise müssen Sie den Multiplizierer erhöhen, wenn Ihre SQL-Lager einen automatischen Skalierungs- oder Multiclusterlastenausgleich verwenden.

• 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.
• Azure vCPUs, die von SQL-Warehouses verwendet werden, werden zusätzlich zu Azure vCPUs genutzt, die von Clustern verwendet werden, die durch Data Science & Engineering oder von Nicht-Databricks-Workloads verwendet 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.

Warteschlange und automatische Skalierungslogik

Bei klassischen und Pro Warehouses fügt die automatische Skalierung Cluster basierend auf der geschätzten Zeit hinzu, um alle ausgeführten und in die Warteschlange gestellten Abfragen zu verarbeiten:

• 2-6 Minuten Abfrageladevorgang: 1 Cluster hinzufügen.
• 6-12 Minuten: Fügen Sie 2 Cluster hinzu.
• 12-22 Minuten: Fügen Sie drei Cluster hinzu.
• Über 22 Minuten: Fügen Sie 3 Cluster plus 1 mehr für alle zusätzlichen 15 Minuten Ladezeiten hinzu.

Zusätzliche Regeln:

• Wenn eine Abfrage 5 Minuten lang in der Warteschlange wartet, wird das Lager nach oben skaliert.
• Wenn die Last für 15 aufeinander folgende Minuten niedrig bleibt, skaliert das Lager bis zum Mindestmaß, das für die Verarbeitung der Spitzenlast aus dieser Periode erforderlich ist.