Freigeben über

SQL Warehouse-Typen

Databricks SQL unterstützt serverlose, pro und klassische Typen. In diesem Artikel werden die für jeden Typ verfügbaren Features beschrieben und die Leistung und Features verglichen.

Leistungsfunktionen nach Typ

Jeder SQL Warehouse-Typ verfügt über unterschiedliche Leistungsfunktionen. In der folgenden Tabelle sind die Leistungsfeatures aufgeführt, die von jedem SQL Warehouse-Typ unterstützt werden.

Lagertyp Photon-Modul Vorhersage-E/A Intelligentes Workload-Management
Serverlos X X X
Vorteil X X
Klassisch X

In der folgenden Liste werden die einzelnen Leistungsfeatures beschrieben:

  • Photon: Das integrierte vektorisierte Abfragemodul auf Databricks. Dadurch werden Ihre vorhandenen SQL- und DataFrame-API-Aufrufe schneller ausgeführt und die Gesamtkosten pro Workload reduziert.

  • Predictive IO: Eine Reihe von Features zum Beschleunigen selektiver Scanvorgänge in SQL-Abfragen. Predictive IO kann eine breite Palette an Leistungsverbesserungen bieten.

  • Intelligente Workloadverwaltung (IWM): Eine Reihe von Features, die die Fähigkeit von Databricks SQL Serverless zum schnellen und kostengünstigen Verarbeiten großer Abfragen verbessern. Mit KI-basierten Vorhersage- und dynamischen Verwaltungstechniken kann IWM sicherstellen, dass Workloads schnell über die richtige Menge an Ressourcen verfügen. Der Hauptunterschied liegt in den KI-Funktionen in Databricks SQL, um dynamisch auf Arbeitsauslastungsanforderungen zu reagieren, anstatt statische Schwellenwerte zu verwenden.

    Hinweis

    Die Preise für jeden Lagertyp und einen detaillierten Funktionsvergleich finden Sie unter Databricks SQL. Informationen zu den neuesten Databricks SQL-Features finden Sie in den Sql-Versionshinweisen zu Databricks.

Leistungsunterschiede zwischen SQL Warehouse-Typen

Jeder SQL Warehouse-Typ weist unterschiedliche Leistungsmerkmale auf.

Serverlose SQL-Warehouses

Mithilfe der serverlosen Azure Databricks-Architektur unterstützt ein serverloses SQL-Warehouse alle Leistungsfeatures von Databricks SQL. Mit einem serverlosen SQL Warehouse und seinen Leistungsfeatures erhalten Sie Folgendes:

  • Schnelle Startzeit (in der Regel zwischen 2 und 6 Sekunden).
  • Schnelles Upscaling, um bei Bedarf mehr Rechenleistung zu erhalten, um eine niedrige Latenz zu gewährleisten.
  • Die Abfrageannahme befindet sich näher an der Einschränkung der Hardware als an der der virtuellen Maschine.
  • Schnelles Herunterskalieren, um die Kosten zu minimieren, wenn die Nachfrage niedrig ist, und dabei konsistente Leistung mit optimierten Kosten und Ressourcen sicherzustellen.

Wählen Sie ein serverloses SQL-Warehouse für die beste Startleistung, die effizienteste E/A, eine intelligentere Verarbeitung stark schwankender Abfragenachfragen und schnelles automatisches Skalieren, wenn es zu einer Abfragewarteschlange kommt. Weitere Informationen finden Sie unter Serverlose automatische Skalierung und Abfragewarteschlangen.

Ein serverloses SQL Warehouse bietet eine gute Leistung mit diesen Arbeitsauslastungstypen:

  • ETL
  • Geschäftsanalytik
  • Explorative Analyse

Von Bedeutung

SQL-Lagerhäuser unterstützen keine Passthrough für Anmeldeinformationen. Databricks empfiehlt die Verwendung des Unity-Katalogs für die Datenverwaltung. Siehe Was ist Unity Catalog?.

Pro SQL Warehouses

Ein pro SQL Warehouse unterstützt Photon und Predictive IO, unterstützt aber keine intelligente Workloadverwaltung. Bei einem pro SQL Warehouse (im Gegensatz zu einem serverlosen SQL Warehouse) ist die Computeebene in Ihrem Azure-Abonnementkonto und nicht in Ihrem Azure Databricks-Konto vorhanden. Ohne intelligentes Workload-Management sind Lagerhäuser weniger reaktionsfähig für die Abfragenachfrage, die im Laufe der Zeit stark variiert und nicht so schnell wie ein serverloses SQL-Lagerhaus automatisch skalieren kann. Ein Pro-SQL-Warehouse benötigt mehrere Minuten, um zu starten (in der Regel ca. 4 Minuten) und skaliert hoch und herunter mit geringerer Reaktionsfähigkeit als ein serverloses SQL-Warehouse. Weitere Informationen finden Sie unter Warteschlangen und automatische Skalierung für klassische und Pro-SQL-Warehouses.

Verwenden Sie ein pro SQL Warehouse, wenn:

  • Serverlose SQL-Lagerhäuser sind in einer Region nicht verfügbar.
  • Sie verfügen über benutzerdefinierte Netzwerke und möchten eine Verbindung mit Datenbanken in Ihrem Netzwerk in der Cloud oder lokal für den Partnerverbund oder eine Hybridarchitektur herstellen. Verwenden Sie z. B. ein PRO SQL Warehouse, wenn Sie andere Dienste in Ihr Netzwerk aufnehmen möchten, z. B. einen Ereignisbus oder Datenbanken, oder Sie möchten Ihr Netzwerk mit Ihrem lokalen Netzwerk verbinden.

Klassische SQL-Lagerhäuser

Ein klassisches SQL-Warehouse unterstützt Photon, unterstützt jedoch keine Predictive IO- oder intelligente Workload-Verwaltung. Bei einem klassischen SQL-Warehouse (im Gegensatz zu einem serverlosen SQL Warehouse) ist die Computeebene in Ihrem Azure-Abonnementkonto und nicht in Ihrem Azure Databricks-Konto vorhanden. Ohne Unterstützung für Predictive IO oder Intelligent Workload Management bietet ein klassisches SQL-Warehouse nur die Leistung auf Einstiegsebene und weniger Leistung als ein serverloses oder ein pro SQL Warehouse. Ein klassisches SQL-Datenlager benötigt ebenfalls mehrere Minuten für den Start (in der Regel ungefähr 4 Minuten) und skaliert mit geringerer Reaktionsfähigkeit als ein serverloses SQL-Lager. Weitere Informationen finden Sie unter Warteschlangen und automatische Skalierung für klassische und Pro-SQL-Warehouses.

Verwenden Sie ein klassisches SQL Warehouse, um interaktive Abfragen zur Datenexploration mit Leistung auf Einstiegsebene und Databricks SQL-Funktionalitäten auszuführen.

Hinweis

Informationen zur Größenanpassung Ihres SQL-Lagers und zur Skalierung als Reaktion auf abfragewarteschlangen finden Sie unter Warteschlangen und automatische Skalierung für pro- und klassische SQL-Lagerhäuser.

Was sind die Standardeinstellungen für lagertyp?

Für Arbeitsbereiche in Regionen , die serverlose SQL-Lagerhäuser unterstützen und die Anforderungen erfüllen:

  • Bei Verwendung der Benutzeroberfläche ist der standardmäßige SQL Warehouse-Typ serverlos.

  • Mit der SQL Warehouses-API mit Standardparametern ist der Standard-SQL-Lagerlagertyp klassisch. Um serverlos zu verwenden, legen Sie den enable_serverless_compute Parameter auf true und warehouse_type auf pro. Wenn dieser Arbeitsbereich die SQL Warehouses-API zum Erstellen eines Lagers zwischen dem 1. November 2022 und dem 19. Mai 2023 verwendet hat und den Anforderungen für serverlose SQL-Lagerhäuser entspricht, bleibt die Standardeinstellung auf festgelegt true. Um Mehrdeutigkeiten zu vermeiden, insbesondere für Organisationen mit vielen Arbeitsbereichen, empfiehlt Databricks, dieses Feld immer festzulegen.

  • Wenn der Arbeitsbereich einen älteren externen Hive-Metaspeicher verwendet, werden serverlose SQL-Lagerhäuser nicht unterstützt. Der standardmäßige SQL-Warehouse-Typ entspricht dem Typ, der verwendet wird, wenn die serverlose Berechnung deaktiviert ist, was in der Benutzeroberfläche als pro und über die API als klassisch bezeichnet wird. Wenden Sie sich auch an Ihr Azure Databricks-Kontoteam, um mehr über Unity-Katalog oder andere Optionen zu erfahren.

Für Arbeitsbereiche, die keine serverlosen SQL-Lagerhäuser unterstützen: