Auswählen eines geeigneten Berechnungstyps

Wenn Sie mit Azure Databricks arbeiten, wirkt sich die Auswahl des richtigen Computetyps direkt auf Ihre Kosten, Leistung und betriebliche Komplexität aus. Jede Computeoption dient verschiedenen Arbeitsauslastungsmustern und verfügt über unterschiedliche Kompromisse bei Startzeit, Skalierbarkeit und Verwaltungsaufwand.

Wenn Sie diese Optionen verstehen, können Sie Computeressourcen an Ihre spezifischen Anforderungen anpassen. Sie können für schnelle Entwicklungszyklen optimieren, die Kosten für Produktionsaufträge minimieren oder beides für Analyseworkloads ausgleichen.

Serverloses Rechnen

Serverless Compute wird vollständig von Azure Databricks verwaltet. Sie stellen keine Infrastruktur bereit oder konfigurieren – Azure Databricks ordnet Ressourcen basierend auf Ihren Workloadanforderungen automatisch zu und skaliert sie. Diese Ressourcen werden im Azure-Abonnement von Databricks ausgeführt, nicht Von Ihnen, was bedeutet, dass keine virtuellen Computer oder Netzwerkkomponenten in Ihrem Abonnement angezeigt werden.

Bei serverloser Berechnung dauert der Start in der Regel 2 bis 6 Sekunden. Die Plattform skaliert schnell nach oben, wenn das Abfragevolumen zunimmt, und skaliert nach unten während leerlaufender Perioden, um die Kosten zu minimieren. Dadurch ist es nicht erforderlich, die Kapazität zu schätzen oder Clusterkonfigurationen zu verwalten.

Serverless Compute erfordert Unity-Katalog und ist verfügbar für:

• Notizbücher: Interaktive Python- und SQL-Entwicklung mit automatischer Ressourcenzuordnung
• Jobs: Automatisierte Workflows, die ohne Einrichtung einer Infrastruktur ausgeführt werden
• Pipelines: Deklarative Lakeflow Spark-Pipelines mit bedarfsgerechter Skalierung
• SQL Warehouses: Optimierte SQL-Abfrageausführung mit intelligenter Workloadverwaltung

Serverless eignet sich am besten für explorative Analysen, ETL-Pipelines, Business Intelligence-Workloads und Szenarien, in denen die Startlatenz wichtig ist. Die versionslose Laufzeit bedeutet, dass Azure Databricks automatisch Upgrades anwendet, sodass Sie immer ohne Migrationsaufwand auf den neuesten Features ausgeführt werden.

Serverless hat jedoch Einschränkungen. In Notebooks unterstützt Serverlos keine Skala-, R-Sprache, JAR-Bibliotheken oder RDD-APIs (Resilient Distributed Dataset). Benutzerdefinierte Spark-Konfigurationen sind ebenfalls eingeschränkt. JAR-Aufgaben in Lakeflow-Aufträgen auf serverloser Berechnung sind in der öffentlichen Vorschau verfügbar. Wenn Ihre Workload Scala- oder R-Notizbücher, RDD-APIs oder vollständige Spark-Konfigurationssteuerung erfordert, verwenden Sie stattdessen klassische Compute mit dediziertem Zugriffsmodus.

Auswählen eines serverlosen Leistungsmodus

Serverlose Berechnung für Aufträge und Pipelines bietet zwei Leistungsmodi, die die Startgeschwindigkeit gegen Kosten ausgleichen.

Der leistungsoptimierte Modus ist die Standardeinstellung. Azure Databricks verwaltet einen Pool an warmen Rechenressourcen, die Startvorgänge in Sekunden ermöglichen. Wählen Sie diesen Modus für interaktive Workloads, latenzabhängige Aufträge und Szenarien aus, in denen der schnelle Start kritisch ist.

Der Standardmodus ist für Kosten optimiert. Serverlose Workloads mit Standardleistungsmodus starten in der Regel innerhalb von 4 bis 6 Minuten. Der Standardmodus kann den DBU-Verbrauch im Vergleich zum leistungsoptimierten Modus um bis zu 70% reduzieren, sodass er gut für geplante Batchaufträge und Pipelines geeignet ist, bei denen die Startlatenz akzeptabel ist.

Sie konfigurieren den Leistungsmodus mithilfe des leistungsoptimierten Umschalters auf der Auftragsdetailseite. Der Standardmodus ist für fortlaufende Pipelines oder einmalige Ausführungen, die über den runs/submit API-Endpunkt übermittelt werden, nicht verfügbar. Für Laptops ist nur der leistungsoptimierte Modus verfügbar.

Klassisches Compute

Die klassische Berechnung bietet Ihnen die vollständige Kontrolle über die Clusterkonfiguration. Sie erstellen, größe und verwalten Computeressourcen, die direkt in Ihrem Azure-Abonnement ausgeführt werden, und bieten Ihnen Transparenz und Kontrolle über die zugrunde liegende Infrastruktur.

Der klassische Compute unterstützt zwei Zugriffsmodi, die bestimmen, wie Benutzer mit dem Cluster interagieren:

Der Standardzugriffsmodus ermöglicht es mehreren Benutzern, einen einzelnen Cluster gleichzeitig freizugeben. Lakeguard bietet Isolation zwischen Benutzer-Codes, verhindert, dass die Arbeit eines Benutzers die eines anderen beeinflusst. Dieser Modus eignet sich gut für die zusammenarbeitende Datenerstellung, gemeinsame Analyse und Kostenoptimierung durch Ressourcenpooling.

Der dedizierte Zugriffsmodus weist den Cluster ausschließlich einem einzelnen Benutzer oder einer gruppe zu. Mit dediziertem Zugriff erhalten Sie vollständige Berechtigungen auf Computerebene, die Sie für RDD-APIs, GPU-Workloads, R-Sprachunterstützung oder benutzerdefinierte Containerumgebungen benötigen.

Über Zugriffsmodi hinaus bietet klassische Compute verschiedene Clustermodi , die die Clusterarchitektur bestimmen:

Multiknotencluster bestehen aus einem Treiberknoten und einem oder mehreren Workerknoten. Der Treiber koordiniert die Ausführung, während Mitarbeiter verteilte Berechnungen parallel ausführen. Diese Architektur ermöglicht die horizontale Skalierung – Sie können Arbeitsknoten hinzufügen, um größere Datensätze zu verarbeiten oder die Parallelität zu erhöhen. Multiknotencluster funktionieren gut für Produktionsworkloads, die große Datenmengen verarbeiten oder hohen Durchsatz erfordern.

Einzelknotencluster enthalten nur einen Treiberknoten ohne Arbeitsknoten. Alle Berechnungen erfolgen auf dem Treiber, was bedeutet, dass Workloads nicht auf mehreren Computern verteilt werden können. Einzelknotencluster eignen sich für bestimmte Szenarien wie einfache Datenexploration, die Analyse kleiner Datensätze oder Experimente im Bereich des maschinellen Lernens, bei denen der Aufwand für das Shuffle-Verfahren die Vorteile der Verteilung übersteigen würde. Sie eignen sich besonders für ML-Workflows mit Frameworks wie Scikit-Learn, die nicht inhärent über Knoten verteilt werden, oder beim Testen von Notizbüchern mit kleinen Datenbeispielen.

Beachten Sie, dass Einzelknotencluster architektonische Einschränkungen aufweisen. Sie können nicht horizontal skaliert werden, um erhöhte Last zu verarbeiten, und alle Verarbeitungen basieren auf den Ressourcen eines einzelnen Computers. Verwenden Sie für Workloads, die verteilte Verarbeitung, parallele Aufgabenausführung über große Datasets oder Fehlertoleranz durch Redundanz erfordern, stattdessen Multiknotencluster.

Klassische Rechenressourcen bieten Flexibilität, erfordern jedoch mehr Verwaltung. Sie konfigurieren Instanztypen, automatische Skalierungsregeln und Laufzeitversionen. Die Startzeit reicht in der Regel von 3 bis 7 Minuten, je nach Clustergröße. Im Gegensatz zu Serverlosen wählen und verwalten Sie die Databricks-Runtime-Version selbst – wählen Sie aus, wann ein Upgrade von einer Version auf eine andere erfolgen soll (z. B. von Runtime 13.3 LTS auf 14.3 LTS). Während zugrunde liegende Betriebssystem- und Sicherheitsupdates automatisiert werden können, erfordern Laufzeitversionsänderungen eine manuelle Auswahl.

Dieser Computetyp eignet sich für Arbeitslasten, die Funktionen benötigen, die in einer serverlosen Umgebung nicht verfügbar sind, eine genaue Kontrolle über die Infrastruktur erfordern oder Compliance-Anforderungen bezüglich der Ressourcenisolation haben.

SQL-Warehouses

SQL-Lagerhäuser sind Computeressourcen, die speziell für SQL-Abfragen, Analysen und Business Intelligence optimiert sind. Sie kommen in drei Typen, jeweils mit unterschiedlichen Leistungsmerkmalen.

Serverlose SQL-Lagerhäuser bieten optimale Leistung und Kosteneffizienz. Sie beginnen in 2 bis 6 Sekunden, verwenden intelligentes Workload-Management, um Abfrageressourcenanforderungen vorherzusagen und Cluster dynamisch basierend auf Bedarf zu skalieren. Photon und Predictive IO beschleunigen die Abfrageausführung. Wählen Sie serverlose SQL-Lagerhäuser für die meisten SQL-Workloads aus – BI-Dashboards, ETL-Aufträge und Ad-hoc-Analysen.

Pro SQL Warehouses unterstützen Photon und Predictive IO, verfügen jedoch nicht über eine intelligente Workloadverwaltung. Sie benötigen ungefähr 4 Minuten zum Starten und skalieren weniger dynamisch als serverlose Architekturen. Sie verwenden Pro Warehouses, wenn Sie benutzerdefinierte Netzwerkkonfigurationen benötigen, z. B. das Herstellen einer Verbindung mit lokalen Datenbanken über den Partnerverbund oder die Integration mit Diensten in Ihrem virtuellen Netzwerk.

Klassische SQL-Lagerhäuser bieten nur eine SQL-Leistung auf Einstiegsebene mit Photon-Unterstützung. Sie beginnen in ca. 4 Minuten und umfassen einfaches automatisches Skalieren. Wählen Sie klassische Lagerhäuser nur aus, wenn serverlose und Pro-Optionen nicht verfügbar sind oder um eine einfache interaktive Erkundung mit minimalen Leistungsanforderungen zu ermöglichen.

Alle SQL Warehouse-Typen optimieren für SQL-Ausführungsmuster, aber serverless bietet die reaktionsschnellste Skalierung und den niedrigsten Betriebsaufwand.

Instanzenpools

Instanzpools verwalten eine Reihe leerer Instanzen virtueller Computer, die sofort verwendet werden können. Wenn Sie einen Cluster aus einem Pool erstellen, verringert sich die Startzeit, da Databricks Instanzen aus dem Pool zuordnet, anstatt neue Instanzen aus Azure anzufordern.

Pools verkürzen die Startzeit vieler Anwendungen von mehreren Minuten auf weniger als eine Minute. Sie konfigurieren die Mindestanzahl der Instanzen, die im Leerlauf warm gehalten werden sollen, sowie die maximale Poolkapazität. Wenn Cluster Instanzen freigeben, kehren diese Instanzen zur Wiederverwendung an den Pool zurück.

Sie bezahlen die Kosten für virtuelle Maschinen, während Instanzen im Pool inaktiv sind, aber nicht für Azure Databricks Computeeinheiten. Dies macht Pools kosteneffizient, wenn Sie Workloads häufig genug ausführen, sodass die reduzierte Startzeit die Kosten der Leerlaufinfrastruktur rechtfertigt.

Da serverloses Computing verfügbar ist, sind Pools in den meisten Szenarien weniger wichtig. Serverless startet schneller und skaliert effizienter, ohne dass Sie die Leerlaufkapazität beibehalten müssen. Pools bleiben jedoch nützlich, wenn Sie klassische Computefeatures benötigen und die Startzeit für häufig ausgeführte Workloads optimieren möchten.

Konfigurieren Sie Pools mit Spot-Instanzen für Workerknoten, um die Kosten zu senken, aber verwenden Sie On-Demand-Instanzen für Treiberknoten, um die Zuverlässigkeit zu erhalten.

Job Compute

Auftragsberechnung bezieht sich auf Cluster, die für automatisierte Workflows und nicht für die interaktive Entwicklung optimiert sind. Sie konfigurieren die Auftragsberechnung über Clusterrichtlinien, die bewährte Methoden für Produktionsworkloads erzwingen.

Auftragscluster werden nach Abschluss ihrer Aufgaben automatisch beendet und verhindern so unnötige Kosten durch ungenutzte Ressourcen. Wenn Sie einen Auftrag konfigurieren, wählen Sie zwischen serverloser und klassischer Auftragsberechnung aus.

• Serverlose Auftragsberechnung bietet schnelleres Starten, automatische Infrastrukturverwaltung und niedrigere Kosten für die meisten automatisierten Workloads.
• Classic Job Compute bietet mehr Konfigurationsoptionen für Workloads, die Funktionen benötigen, die von serverlosen Umgebungen nicht unterstützt werden.

Mit dem klassischen Job-Compute können Sie optimierte Einstellungen wie automatische Skalierung und Spot-Instanzen verwenden. Spotinstanzen (auch als Azure Spot-VMs bezeichnet) verwenden die übermäßige Kapazität von Azure bei erheblich reduzierten Kosten – häufig bis zu 90% billiger als normale On-Demand-Instanzen. Azure kann diese Instanzen mit einer Frist von nur 30 Sekunden zurückfordern, wenn die Kapazität wieder benötigt wird. Die integrierte Fehlertoleranz von Spark verarbeitet diese Unterbrechungen automatisch, indem fehlerhafte Vorgänge auf anderen verfügbaren Knoten wiederholt werden, wodurch Spotinstanzen eine kostengünstige Option für viele Batchverarbeitungs- und ETL-Workloads darstellen.

Die Job Compute-Richtlinie in Azure Databricks bietet eine Vorlage zum Erstellen von produktionsbereiten Auftragsclustern mit sinnvollen Standardwerten. Es erzwingt die neueste Laufzeitversion mit Langzeitunterstützung (LTS) und andere Zuverlässigkeitseinstellungen.

Vergleich von Computertypen

Unterschiedliche Computetypen eignen sich für unterschiedliche Szenarien. In der folgenden Tabelle werden die wichtigsten Merkmale verglichen, mit denen Sie fundierte Entscheidungen treffen können:

Computetyp	Empfohlen für	Startzeit	Verwaltungsaufwand	Kosteneffizienz	Schlüsseleinschränkung
Serverloses Rechnen	Interaktive Entwicklung, ETL-Aufträge, BI-Workloads	⚡ 2-6 Sekunden	👌 Minimal – vollständig verwaltet	 Hoch - Skaliert auf Null, Sie zahlen nur für die Nutzung	Keine RDD-APIs, R- oder JAR-Bibliotheken
Klassische Berechnung (Standard)	Kollaboratives Datenengineering, geteilte Analysen	⏱️ 3-7 Minuten	🔧 Moderat – Konfigurieren und Überwachen	 Moderat – Das Teilen unter mehreren Benutzern reduziert die Kosten pro Benutzer	Erfordert den Unity Katalog für die Verwaltung
Klassische Berechnung (dediziert)	RDD-Workloads, GPU-Aufträge, R-Sprache, benutzerdefinierte Container	⏱️ 3-7 Minuten	🔧 Moderat – Konfigurieren und Überwachen	🔴 Unten – nur einzelner Benutzer/Gruppe	Höhere Kosten als gemeinsam genutzte Ressourcen
Instanzenpools	Häufig ausgeführte klassische Workloads, die schnell starten müssen	🚀 <1 Minute	⚠— Höher – Leerlaufkapazität beibehalten	🔄 Variable – Leerkosten durch Nutzungshäufigkeit rechtfertigen	Sie zahlen für ungenutzte Instanzen
SQL-Warehouse (Serverlos)	SQL-Analyse, BI-Dashboards, Berichterstellung	⚡ 2-6 Sekunden	👌 Minimal – intelligentes Arbeitslast-Management	 Hoch - dynamische Skalierung mit Photon + Predictive IO	Nur SQL-Workloads
SQL Warehouse (Pro)	SQL mit benutzerdefiniertem Netzwerk und Föderation	⏱️ ~4 Minuten	🔧 Moderat – manuelle Skalierungskonfiguration	 Moderat - Photon + Predictive IO	Langsamere Skalierung als serverlos
SQL Warehouse (Klassisch)	SQL-Erkundung auf Einstiegsebene	⏱️ ~4 Minuten	🔧 Moderat – manuelle Skalierungskonfiguration	🔴 Unten - nur einfaches Photon	Eingeschränkte Leistungsfeatures
Auftragsberechnung (Serverlos)	Automatisierte Workflows, Produktions-ETL	⚡ 2-6 Sekunden	👌 Minimal – automatisch nach Abschluss beendet	 Hoch - keine Leerlaufkosten	Identisch mit serverlosem Compute
Auftragsberechnung (klassisch)	Aufträge, die benutzerdefinierte Konfigurationen erfordern	⏱️ 3-7 Minuten	🔧 Moderat – Richtlinien konfigurieren	 Moderat - automatische Beendigung verhindert Leerlaufverluste	Erfordert Infrastrukturverwaltung

Wählen Sie den richtigen Computertyp

Beginnen Sie Ihren Entscheidungsprozess, indem Sie Ihre Workloadmerkmale identifizieren. Das folgende Diagramm veranschaulicht einen Entscheidungsfluss, der Ihnen bei der Auswahl des geeigneten Berechnungstyps hilft:

Stellen Sie sich die folgenden Fragen:

Welche Art von Arbeit führen Sie aus? Wenn Sie interaktive Notizbücher schreiben, bietet die serverlose Berechnung den schnellsten Iterationszyklus. Für SQL-Abfragen und BI-Dashboards bieten serverlose SQL-Lagerhäuser eine optimale Leistung. Automatisierte Produktionsaufträge funktionieren gut mit serverlosen Auftragsberechnungen, es sei denn, Sie benötigen benutzerdefinierte Konfigurationen.

Verwendet Ihr Code bestimmte APIs oder Sprachen?RDD-APIs, R-Sprache oder GPU-Beschleunigung erfordern klassischen Compute mit dediziertem Zugriffsmodus. Python-, SQL- und Scala-Workloads werden entweder auf serverlosen oder klassischen Standardberechnungen ausgeführt.

Wie häufig wird dieser Workload ausgeführt? Seltene Workloads profitieren am meisten von serverlosen Workloads, da Sie nur während der Ausführung bezahlen. Wiederkehrende Workloads können Instanzpools rechtfertigen, wenn Sie klassische Compute verwenden, obwohl serverlose Server häufig immer noch eine bessere Wirtschaftlichkeit bieten.

Benötigen Sie benutzerdefinierte Netzwerke oder bestimmte Infrastruktur? Benutzerdefinierte virtuelle Netzwerke, lokale Konnektivität oder bestimmte Instanztypen erfordern klassische Compute- oder SQL-Lagerhäuser. Serverless arbeitet im databricks-verwalteten Abonnement ohne benutzerdefinierte Netzwerkintegration, sodass Ressourcen nicht in Ihrem Azure-Abonnement angezeigt werden.

Was sind Ihre Leistungsanforderungen? Bei latenzempfindlichen Workloads startet die serverlose Berechnung 2-4x schneller als klassische Optionen. Für eine vorhersehbare Leistung im großen Maßstab können sowohl Serverless als auch klassische Optionen die Anforderungen erfüllen, aber Serverless passt sich dynamischer an die Auslastungsvariationen an.

Beginnen Sie für die meisten Szenarien mit serverlosen Optionen. Sie minimieren den Betriebsaufwand, optimieren Die Kosten durch automatische Skalierung und bieten die schnellste Entwicklungserfahrung. Wechseln Sie nur dann zur klassischen Berechnung, wenn sie auf eine bestimmte Einschränkung stoßen, die serverlos nicht unterstützt wird.