Herausforderungen in Multi-Cloud-Umgebungen, intelligentes Load Balancing und KI-gestützte Workflows: Databricks auf der SRECon 2026

Databricks-Infrastruktur-Ingenieure reisen zur SRECon 2026 nach Seattle am 24. März. Wir freuen uns, einige der Arbeiten vorzustellen, die wir zur Skalierung, zum Betrieb und zur Weiterentwicklung der Infrastruktur hinter der Databricks-Plattform geleistet haben. 

Begleiten Sie uns zu Gesprächen mit Ingenieuren unserer Infrastrukturteams, darunter Bricksters, die an Service Mesh, Traffic Routing, Konfigurationsmanagement und dem Betrieb zustandsbehafteter Dienste arbeiten. Dies ist eine großartige Gelegenheit, die größten Probleme zu erkunden, die Ingenieure lösen, und die Innovationen in der Infrastruktur, die sie vorantreiben.

Verpassen Sie außerdem nicht diese technischen Sitzungen!

Intelligentes Kubernetes Load Balancing bei Databricks

Databricks betreibt Tausende von Microservices über AWS, Azure und GCP. Bei dieser Skalierung stößt das Standard-Load-Balancing von Kubernetes an seine Grenzen. Das integrierte kube-proxy- und ClusterIP-Modell arbeitet auf Layer 4 und verteilt Verbindungen anstelle von Anfragen. Für gRPC-Dienste mit langlebigen HTTP/2-Verbindungen führt dies zu stark verzerrtem Traffic: Einige Pods werden überlastet, während andere untätig bleiben. Das Ergebnis sind Spitzen bei der Tail-Latenz, verschwendete Rechenleistung und unvorhersehbares Dienstverhalten.

Wir haben eine benutzerdefinierte Lösung entwickelt, um dieses Problem anzugehen. In diesem Vortrag werden wir die Architektur, die abgewogenen Entscheidungen (einschließlich der Gründe, warum wir uns gegen Istio oder ein vollständiges Service Mesh entschieden haben) und die Lektionen, die wir bei der Einführung in einer Multi-Cloud-Flotte gelernt haben, erläutern.

Weitere technische Details finden Sie in unserem früheren Blogbeitrag: Intelligentes Kubernetes Load Balancing bei Databricks.

Wie wir Tausende von Datenbanken mit KI debuggen

Databricks betreibt Tausende von OLTP-Datenbankinstanzen über drei Clouds und Hunderte von Regionen hinweg. Wenn etwas schiefgeht, mussten Ingenieure historisch Signale aus Grafana-Dashboards, CLI-Tools, Cloud-Provider-Konsolen und internen Runbooks zusammensetzen. Die Debugging-Erfahrung war fragmentiert, langsam und stark vom Wissen einzelner Personen abhängig. Neue Ingenieure konnten Wochen brauchen, um effektiv Datenbankprobleme zu diagnostizieren.

Wir haben eine KI-gestützte Plattform entwickelt, um dies zu ändern; angefangen bei einem Hackathon-Prototyp bis hin zu einem Produktionssystem. In diesem Vortrag teilen wir die Reise von Null auf Produktion, die architektonischen Entscheidungen, die sie ermöglicht haben, und was wir beim Aufbau von KI-gestützten operativen Werkzeugen in großem Maßstab gelernt haben.

Weitere Details finden Sie in unserem früheren Blogbeitrag: Wie wir Tausende von Datenbanken mit KI bei Databricks debuggen.

Networking-Event: Dicer Deep Dive

Anfang des Jahres haben wir Dicer quelloffen gemacht, unser Auto-Sharding-System für den Aufbau hochverfügbarer Sharding-Dienste mit geringer Latenz. Dicer adressiert eine grundlegende Spannung in verteilten Systemen: zustandslose Architekturen sind einfach, aber teuer (jede Anfrage trifft die Datenbank oder den Remote-Cache), während statisch geshardete Architekturen effizient, aber fragil sind (Neustarts führen zu Verfügbarkeitsausfällen, Hot Keys verursachen Ungleichgewichte und Skalierungen erfordern manuelle Eingriffe).

Dicer löst dies durch die kontinuierliche und dynamische Verwaltung von Shard-Zuweisungen. Es teilt überlastete Shards, führt unterausgelastete zusammen, repliziert kritische Daten für die Verfügbarkeit und verschiebt Shards während rollierender Neustarts, um die Cache-Trefferraten aufrechtzuerhalten. Bei Databricks treibt Dicer einige unserer kritischsten Dienste an: Unity Catalog erreicht mit Dicer 90-95 % Cache-Trefferraten, unsere SQL-Abfrage-Orchestrierungs-Engine eliminiert Verfügbarkeitsausfälle während Neustarts und unser Remote-Cache hält die Trefferraten auch bei rollierenden Deployments aufrecht.

Wir veranstalten während der SRECon ein spezielles Networking-Event, bei dem wir tiefer in Dicer eintauchen werden: wie es funktioniert, wie wir es in der Produktion einsetzen und wie Sie es in Ihrer eigenen Infrastruktur nutzen können. Dies ist eine interaktive Sitzung bei Getränken und Snacks, kein formeller Vortrag. Bringen Sie Ihre Fragen zu Sharding, Caching und dem Aufbau zustandsbehafteter Dienste in großem Maßstab mit.

Die Plätze sind begrenzt. Registrieren Sie sich hier: Databricks Networking Event @ SRECon 2026

Woran unsere Infrastrukturteams arbeiten

Über die Vorträge und das Networking-Event hinaus arbeiten unsere Infrastrukturteams an einigen der schwierigsten Probleme im Multi-Cloud-Betrieb. Einige Bereiche, auf die wir uns freuen:

Multi-Cloud Service Delivery: Databricks läuft gleichzeitig auf AWS, Azure und GCP. Jeder Dienst, jede Konfiguration, jede Deployment-Pipeline muss in allen drei Clouds und ihren jeweiligen Regierungs- und souveränen Regionen funktionieren. Unsere Teams entwickeln die Tools und Abstraktionen, die dies handhabbar machen, von einheitlichen Platzierungskonfigurationen, die definieren, wo Dienste ausgeführt werden, bis hin zu Deployment-Pipelines, die die Unterschiede zwischen den Cloud-Anbietern bewältigen.

Service Mesh und Traffic Routing: Mit wachsender Zahl unserer Dienste wird das effiziente und zuverlässige Routing von Traffic immer komplexer. Wir investieren in Service Discovery, Cross-Cluster- und Cross-Region-Routing sowie in die Integration zwischen unseren Load-Balancing- und Sharding-Systemen. Mit dem Wachstum unserer Flotte hat sich der Problembereich von der Optimierung des Traffics innerhalb eines einzelnen Clusters auf das Routing über Cluster, Regionen und sogar Cloud-Anbieter hinweg erweitert.

Konfigurationsmanagement im großen Maßstab: Die Verwaltung der Konfiguration über Tausende von Diensten, mehrere Clouds und verschiedene Umgebungen (Entwicklung, Staging, Produktion, Regierungsregionen) hinweg ist ein Problem, das sich mit jedem neuen Dienst und jeder neuen Region vervielfacht. Unsere Teams entwickeln Systeme, um Konfigurationsänderungen sicher, überprüfbar und konsistent zu gestalten. Sehen Sie sich unseren Blogbeitrag zu High-Availability Feature Flagging bei Databricks an.

Treffen Sie uns auf der SRECon

Databricks ist Silbersponsor. Finden Sie uns an Stand #214 auf der Ausstellungsfläche. Mehrere Ingenieure unserer Infrastrukturteams werden dort sein, darunter Bricksters, die an Service Mesh, Traffic Routing, Konfigurationsmanagement und dem Betrieb zustandsbehafteter Dienste arbeiten. Kommen Sie vorbei, um mit uns über die Probleme zu sprechen, die wir lösen, und die Systeme, die wir bauen.

Wenn Sie uns auf der SREcon verpassen und daran interessiert sind, unserem Team beizutreten, besuchen Sie unsere Karriereseite für die neuesten Stellenangebote.

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