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. 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 ungefähr alle 10 Sekunden. Wenn die Warteschlange nicht schnell genug abnimmt, erfolgt eine automatische Skalierung, um schnell mehr Computeressourcen bereitzustellen. 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.
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.