Neudenken Verteilter Systeme für Serverless-Leistung und Zuverlässigkeit

Der Aufbau einer wirklich serverlosen Compute-Umgebung für Apache Spark erforderte die Lösung grundlegender architektonischer Herausforderungen, die seit der Einführung von Spark bestehen. Die Komplexität geht weit über die bloße Erstellung von Warm-Pools von Maschinen oder die Implementierung einer grundlegenden Autoskalierung hinaus. Es erforderte ein Überdenken der Kernannahmen über die Funktionsweise verteilter Computersysteme.

Traditionelle Spark-Bereitstellungen legen die Infrastruktur direkt den Benutzern offen, was eine enge Kopplung zwischen Anwendungen und Compute schafft. Workloads konkurrieren um gemeinsame Ressourcen, kleine Ineffizienzen können zu Kaskadenfehlern führen, und Benutzer sind gezwungen, Leistung, Kosten und Zuverlässigkeit manuell auszugleichen. Wenn sich die Nachfrage ändert, haben Systeme Schwierigkeiten, sowohl eine hohe Auslastung als auch eine vorhersehbare Leistung aufrechtzuerhalten.

Serverless Compute verfolgt einen anderen Ansatz, indem es die Infrastruktur vollständig verwaltet, sodass sich der Benutzer auf Daten und Erkenntnisse konzentrieren kann. Stabilität wird zu einer Systemeigenschaft statt einer Benutzerverantwortung, ermöglicht durch Architekturen, die Workloads isolieren, intelligent platzieren und Ressourcen dynamisch anpassen.

Serverless Compute wurde entwickelt, um Stabilität, Leistung und betriebliche Einfachheit zu verbessern. Drei Kernsysteme machen dies möglich:

1. Spark Connect, das Benutzeranwendungen von der Compute-Infrastruktur trennt
2. Das Serverless Gateway, das Workloads intelligent über Compute-Ressourcen routet
3. Ein adaptiver Autoscaler, der die Clustergröße kontinuierlich für Leistung und Kosten optimiert

Zusammen ermöglichen diese Systeme ein Modell, bei dem Leistung durch die Sicherstellung der Systemstabilität erreicht wird.

Spark Connect: Stabilität durch Isolation

Spark Connect stellt die bedeutendste architektonische Transformation in der Geschichte von Spark dar, eine vollständige Abkehr vom monolithischen Design, das verteiltes Computing seit über einem Jahrzehnt prägt. In traditionellen Architekturen laufen Benutzeranwendungen direkt auf derselben Maschine wie der Spark-Treiber, was eine enge Kopplung schafft, die kritische Einschränkungen mit sich bringt. Wenn mehrere Anwendungen um Ressourcen auf demselben Cluster konkurrieren oder wenn Benutzercode übermäßigen Speicher oder CPU verbraucht, wird das System instabil, was zu Fehlern führt, die sich über Workloads hinweg ausbreiten können.

Spark Connect führt eine Client-Server-Architektur ein, bei der Anwendungen über gRPC mit dem Spark-Treiber kommunizieren und der Treiber Abfragen im Namen des Clients ausführt, anstatt Benutzerprozesse direkt auszuführen. Dies verlagert die Ausführungseinheit von Anwendungsprozessen auf Abfragen und ermöglicht eine klare Trennung zwischen Benutzeranwendungen und Infrastruktur.

Diese Entkopplung verbessert die Zuverlässigkeit erheblich und ermöglicht es der Plattform, Treiber unabhängig von Benutzer-Workloads zu verwalten. Durch die Isolation von Anwendungen vom Compute schafft Spark Connect die Grundlage für eine stabile Multi-Tenant-Ausführung und ermöglicht ein fortschrittlicheres Ressourcenmanagement im gesamten System.

Diese Architektur ermöglicht es Databricks, mehr als 25 große Spark-Laufzeit-Upgrades pro Jahr mit einer Erfolgsquote von 99,998 % über mehr als 4,5 Milliarden Workloads bereitzustellen, ohne dass Benutzer eingreifen müssen.¹

Das Gateway: Effizienz und Vorhersehbarkeit ausbalancieren

Verteilte Systeme stehen seit langem vor einem grundlegenden Spannungsfeld zwischen Effizienz und Vorhersehbarkeit. Die Maximierung der Auslastung führt oft zu Ressourcenkonflikten, während die Isolation von Workloads zu einer unzureichend genutzten Kapazität führen kann. Traditionelle Cluster-Modelle zwingen Benutzer dazu, diesen Kompromiss manuell zu steuern, was oft zu unvorhersehbarer Leistung oder unzuverlässiger Ausführung führt, wenn sich Workloads ändern.

Stellen Sie sich vor, was passiert, wenn Dutzende von Abfragen gleichzeitig eintreffen: einige kleine explorative Scans, die gegen Beispieldaten laufen, andere große Produktions-ETL-Jobs, die Hunderte von Gigabyte verarbeiten. Ein naiver Router behandelt sie identisch, zwingt große Jobs, hinter kleinen zu warten, oder lässt Workloads um denselben Cluster konkurrieren, was zu unvorhersehbarer Leistungsverschlechterung führt. Diese Dynamik erschwert es, sowohl hohe Auslastung als auch konsistente Leistung in gemeinsamen Umgebungen zu liefern.

Das Databricks Gateway routet jede Workload, indem es drei Echtzeitsignale auswertet: die geschätzte Abfragegröße (abgeleitet vom logischen Plan), die aktuelle Auslastung des Cluster-Pools und das Latenzprofil: ob eine Sitzung interaktiv und latenzempfindlich ist oder ein Batch-Job, der auf Durchsatz optimiert ist. Eine kleine explorative Abfrage wird an einen schwach ausgelasteten Cluster geleitet, der in Sekunden antworten kann; ein großer ETL-Job wird an einen Cluster mit verfügbarem Spielraum für sein Datenvolumen geleitet, oder der Autoscaler wird angewiesen, einen bereitzustellen. Wenn sich die Bedingungen ändern (ein Cluster füllt sich, ein langlaufender Job wird beendet, ein neuer Cluster geht online), bewertet das Gateway die Platzierungen kontinuierlich neu und korrigiert das Routing ohne Benutzereingriff. Das Ergebnis: Workloads sind voneinander isoliert. Eine außer Kontrolle geratene Abfrage auf einem Cluster verzögert keine Abfragen auf einem anderen, und das System behält eine hohe Auslastung bei, ohne die Vorhersehbarkeit zu opfern.

Autoscaling: Optimierung der Kosten-Leistungs-Kurve

Die dynamische Cluster-Größenanpassung ist der primäre Mechanismus zur Optimierung des Preis-Leistungs-Verhältnisses in verteilten Systemen, aber die Bestimmung der optimalen Compute-Menge ist von Natur aus komplex. Die optimale Konfiguration hängt von den Workload-Eigenschaften, der Datengröße und der relativen Bedeutung von Latenz gegenüber Kosten ab, wobei keine einzelne Konfiguration für alle Szenarien funktioniert. Databricks Serverless bietet zwei Modi, um unterschiedlichen Anforderungen gerecht zu werden: Standard, der weniger Compute verwendet, um Kosten zu senken, und Performance-Optimized, der schnellere Start- und Ausführungszeiten für zeitkritische Workloads liefert.

Der Start ist für uns eine Priorität, und serverlose Notebooks und Workflows haben einen großen Unterschied gemacht. Serverless Compute für Notebooks macht es mit nur einem Klick einfach. — Chiranjeevi Katta, Data Engineer bei Airbus

Databricks half uns, auf serverloses Computing umzusteigen und gleichzeitig redundante Workflows zu eliminieren. Diese Effizienzsteigerungen versetzten uns in die Lage, die Betriebskosten um 25 % zu senken. Pipelines auf unserer alten Infrastruktur benötigten zuvor Stunden zur Verarbeitung. Jetzt laufen sie 2- bis 5-mal schneller. — Evan Cherney, Senior Data Science Manager bei Unilever

Traditionelle Autoscaling-Ansätze basieren auf statischen Regeln und reaktiven Schwellenwerten, die diese Nuancen oft nicht erfassen. Infolgedessen sind Cluster häufig unter- oder überprovisioniert, was zu Ineffizienz, Instabilität oder beidem führt.

Serverloses Autoscaling verfolgt einen adaptiveren Ansatz. Durch die kontinuierliche Analyse von Workload-Mustern und systemweiten Signalen positioniert der Autoscaler jede Workload auf der optimalen Kosten-Leistungs-Kurve, wo die meisten manuell konfigurierten Cluster versagen, was zu schlechterer Leistung und höheren Kosten führt, da die korrekte Dimensionierung verteilter Systeme schwierig ist. Es passt die Compute-Kapazität dynamisch an, indem es bei Bedarf horizontal und vertikal skaliert, um Out-of-Memory-Fehler zu verhindern und die Stabilität bei wachsenden Workloads aufrechtzuerhalten. Wenn eine Aufgabe einen Out-of-Memory-Fehler feststellt, erkennt der Autoscaler dies automatisch, startet die Aufgabe auf einer größeren VM neu und setzt den Job ohne manuelles Eingreifen oder Jobfehler fort.

Die Auswirkungen sind messbar. CKDelta berichtete, dass Jobs in 20 Minuten abgeschlossen wurden, die zuvor 4–5 Stunden liefen. Unilever verzeichnete Pipelines, die 2–5x schneller liefen, mit um 25 % gesenkten Betriebskosten. HP erzielte Cloud-Einsparungen von über 32 % und reduzierte die kombinierte Job-Laufzeit um 36 %.

Zusammen ermöglichen Spark Connect, das Gateway und der Autoscaler ein grundlegend anderes Betriebsmodell für Spark. Workloads werden isoliert, intelligent platziert und dynamisch mit Ressourcen versorgt, ohne Benutzereingriff. Durch die Adressierung der Stabilität auf architektonischer Ebene kann serverloses Computing eine starke Leistung bei gleichzeitiger Zuverlässigkeit liefern, sodass sich Benutzer auf den Aufbau von Daten- und KI-Workloads konzentrieren können, anstatt die Infrastruktur zu verwalten.

¹ Justin Breese et al., „Blink Twice: Automatic Workload Pinning and Regression Detection for Versionless Apache Spark using Retries“, SIGMOD/PODS '25, S. 103–106. https://doi.org/10.1145/3722212.3725084

Starten Sie Ihre Serverless-Reise noch heute

• Registrieren Sie sich für ein Serverless Databricks-Konto
• Serverless Compute für Notebooks, Lakeflow-Jobs und deklarative Spark-Pipelines
• Praktischer Leitfaden für Serverless Compute

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag