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.
Dimensionierungsübersicht
SQL-Lagerhäuser sind in serverlosen, pro und klassischen Typen verfügbar, die unterschiedliche Leistungsfeatures und Optimierungen aufweisen, die sich auf die Abfrageleistung in Ihrem Lager auswirken können. Siehe SQL-Warehouse-Typen. Databricks empfiehlt die Verwendung serverloser SQL-Warehouses, wenn verfügbar.
Für jeden Lagertyp wählen Sie eine Clustergröße für die Berechnungsressourcen aus. Das Optimieren ihrer Databricks SQL Warehouse-Größe erfordert mehr als nur die Berücksichtigung der Datenmenge oder der Benutzeranzahl. Die Abfragekomplexität und die Anzahl gleichzeitiger Abfragen sind auch wichtige Faktoren bei der Leistung.
Databricks SQL Warehouses verwenden dynamische Parallelität, um diese Anforderungen zu verarbeiten. Im Gegensatz zu lagerinternen Kapazitäten passt Databricks SQL Computeressourcen in Echtzeit an, um gleichzeitige Lasten zu verwalten und den Durchsatz zu maximieren. Jede Lagergrößenkategorie verfügt über eine feste Berechnungskapazität pro Einheit, aber das System skaliert die Anzahl der Ressourcen, um unterschiedliche Anforderungen zu erfüllen.
Clustergrößen für SQL-Lagerhäuser
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.
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.
| 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. 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.
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. Die Upscaling von Clustern pro Lager basiert auf dem Abfragedurchsatz, der Rate eingehender Abfragen und der Warteschlangengröße. Databricks empfiehlt einen Cluster für alle 10 gleichzeitigen 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.
Serverlose automatische Skalierung und Abfragewarteschlangen.
Intelligente Workloadverwaltung (IWM) ist eine Reihe von Features, die die Fähigkeit von serverlosen SQL-Warehouses verbessern, große Anzahl von Abfragen schnell und kosteneffizient zu verarbeiten. Sie verwaltet die Workloads dynamisch, indem sie mithilfe von Machine Learning-Modellen den Ressourcenbedarf eingehender Abfragen vorhersagt und gleichzeitig die verfügbare Rechenkapazität des Lagers in Echtzeit überwacht. Die Verfolgung dieser und anderer Signale im Lager ermöglicht es IWM, auf Änderungen der Workloadanforderungen zu reagieren.
Diese dynamische Verwaltung ermöglicht dem IWM Folgendes:
- Schnelles Upscaling von Daten, um niedrige Latenzzeiten beizubehalten.
- Ermöglichen Sie die Abfrage von Raten, die näher an den Grenzen der Hardware liegen.
- Rasches Herunterskalieren, um die Kosten zu minimieren, wenn die Nachfrage gering ist.
Wenn eine Anfrage im Lager eingeht, sagt IWM die Kosten voraus. 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 er über die erforderliche Rechenleistung verfügt, wird die Abfrage sofort ausgeführt.
IWM überwacht die Warteschlange in Echtzeit. Wenn die Warteschlange nicht schnell genug abnimmt, stellt die automatische Skalierung mehr Rechenkapazität bereit. Nachdem neue Kapazitäten hinzugekommen sind, werden Abfragen in der Warteschlange für die neuen Rechenressourcen zugelassen. Mit serverlosen SQL-Warehouses kann neue Rechenleistung schnell hinzugefügt werden. Die maximale Anzahl von Abfragen in einer Warteschlange für alle SQL Warehouse-Typen beträgt 1.000.
Dimensionierung eines serverlosen SQL-Warehouse
Beginnen Sie mit einer größeren Kapazität für Ihr serverloses SQL-Warehouse, als Sie denken, dass Sie benötigen werden, und passen Sie sie während der Tests nach unten an. Beginnen Sie nicht mit einer kleinen Größe für Ihr serverloses SQL Warehouse und gehen Sie nach oben. 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.
- Um die Kosten zu reduzieren, versuchen Sie, die Größe zu verringern, ohne auf den Datenträger zu überlaufen oder die Latenz erheblich zu erhöhen.
Tools zum Überwachen und Bewerten der Leistung
Um die richtige Anpassung Ihres SQL-Datenspeichers zu unterstützen, verwenden Sie die folgenden Tools:
- Überwachungsseite: Überprüfen Sie die Spitzenabfrageanzahl. 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.