Gli ingegneri dell'infrastruttura Databricks si stanno recando a SRECon 2026 a Seattle il 24 marzo. Siamo entusiasti di condividere parte del lavoro che abbiamo svolto per scalare, operare ed evolvere l'infrastruttura dietro la Piattaforma Databricks.
Unisciti a noi per chiacchierare con gli ingegneri dei nostri team di infrastruttura, inclusi i Bricksters che lavorano su service mesh, routing del traffico, gestione della configurazione ed esecuzione di servizi stateful. Questa è una grande opportunità per esplorare i problemi più grandi che gli ingegneri stanno risolvendo e le innovazioni infrastrutturali che stanno guidando.
Inoltre, non perderti queste sessioni tecniche!
Databricks esegue migliaia di microservizi su AWS, Azure e GCP. A questa scala, il bilanciamento del carico predefinito di Kubernetes non è sufficiente. Il modello integrato kube-proxy e ClusterIP opera a Livello 4, distribuendo connessioni piuttosto che richieste. Per i servizi gRPC con connessioni HTTP/2 di lunga durata, ciò porta a un grave squilibrio del traffico: alcuni pod vengono sovraccaricati mentre altri rimangono inattivi. Il risultato sono picchi di latenza di coda, spreco di risorse computazionali e comportamento imprevedibile del servizio.
Abbiamo creato una soluzione personalizzata per affrontare questo problema e in questa presentazione illustreremo l'architettura, i compromessi che abbiamo considerato (incluso il motivo per cui abbiamo scelto di non adottare Istio o una service mesh completa) e le lezioni che abbiamo imparato implementandola su una flotta multi-cloud.
Per maggiori dettagli tecnici, consulta il nostro precedente post sul blog: Bilanciamento Intelligente del Carico Kubernetes in Databricks.
Databricks gestisce migliaia di istanze di database OLTP su tre cloud e centinaia di regioni. Quando qualcosa va storto, gli ingegneri storicamente dovevano mettere insieme segnali da dashboard Grafana, strumenti CLI, console dei provider cloud e runbook interni. L'esperienza di debug era frammentata, lenta e fortemente dipendente dalla conoscenza interna. I nuovi ingegneri potevano impiegare settimane per diventare efficaci nella diagnosi dei problemi dei database.
Abbiamo creato una piattaforma assistita dall'IA per cambiare questo scenario; partendo da un prototipo di hackathon e facendolo crescere fino a diventare un sistema di produzione. In questa presentazione, condivideremo il percorso da zero alla produzione, le decisioni architetturali che l'hanno resa funzionante e ciò che abbiamo imparato sulla creazione di strumenti operativi potenziati dall'IA su larga scala.
Per maggiori dettagli, consulta il nostro precedente post sul blog: Come Debugghiamo Migliaia di Database con l'IA in Databricks.
All'inizio di quest'anno abbiamo rilasciato Dicer come open-source, il nostro sistema di auto-sharding per la creazione di servizi sharded altamente disponibili e a bassa latenza. Dicer affronta una tensione fondamentale nei sistemi distribuiti: le architetture stateless sono semplici ma costose (ogni richiesta colpisce il database o la cache remota), mentre le architetture sharded staticamente sono efficienti ma fragili (i riavvii causano cali di disponibilità, le chiavi calde causano squilibri e lo scaling richiede interventi manuali).
Dicer risolve questo problema gestendo continuamente e dinamicamente le assegnazioni di shard. Suddivide gli shard sovraccarichi, unisce quelli sottoutilizzati, replica dati critici per la disponibilità e sposta gli shard durante i riavvii rolling per mantenere i tassi di cache hit. In Databricks, Dicer alimenta alcuni dei nostri servizi più critici: Unity Catalog raggiunge tassi di cache hit del 90-95% con Dicer, il nostro motore di orchestrazione delle query SQL elimina i cali di disponibilità durante i riavvii e la nostra cache remota mantiene i tassi di hit anche durante i deployment rolling.
Stiamo ospitando un evento di networking dedicato durante SRECon in cui approfondiremo Dicer: come funziona, come lo usiamo in produzione e come puoi usarlo nella tua infrastruttura. Questa è una sessione interattiva con bevande e stuzzichini, non una presentazione formale. Porta le tue domande su sharding, caching e sulla creazione di servizi stateful su larga scala.
Lo spazio è limitato. Registrati qui: Evento di Networking Databricks @ SRECon 2026
Oltre alle presentazioni e all'evento di networking, i nostri team di infrastruttura stanno affrontando alcuni dei problemi più difficili nelle operazioni multi-cloud. Alcune aree che ci entusiasmano:
Consegna di servizi multi-cloud: Databricks viene eseguito contemporaneamente su AWS, Azure e GCP. Ogni servizio, ogni configurazione, ogni pipeline di deployment deve funzionare su tutti e tre i cloud e nelle loro rispettive regioni governative e sovrane. I nostri team stanno costruendo gli strumenti e le astrazioni che rendono questo gestibile, dalle configurazioni di posizionamento unificate che definiscono dove vengono eseguiti i servizi, alle pipeline di deployment che gestiscono le differenze tra i provider cloud.
Service mesh e routing del traffico: Man mano che la nostra flotta di servizi cresce, instradare il traffico in modo efficiente e affidabile diventa sempre più complesso. Stiamo investendo nella service discovery, nel routing cross-cluster e cross-region e nell'integrazione tra i nostri sistemi di bilanciamento del carico e di sharding. Man mano che la nostra flotta è cresciuta, lo spazio del problema si è ampliato dall'ottimizzazione del traffico all'interno di un singolo cluster all'instradamento tra cluster, tra regioni e persino tra provider cloud.
Gestione della configurazione su larga scala: La gestione della configurazione su migliaia di servizi, più cloud e diversi ambienti (dev, staging, produzione, regioni governative) è un problema che si aggrava con ogni nuovo servizio e ogni nuova regione. I nostri team stanno costruendo sistemi per rendere le modifiche alla configurazione sicure, verificabili e coerenti. Vedi il nostro post sul blog su Feature Flagging ad Alta Disponibilità in Databricks.
Databricks è uno Sponsor Silver. Trovaci allo Stand #214 nell'Expo Floor. Diversi ingegneri dei nostri team di infrastruttura saranno presenti, inclusi i Bricksters che lavorano su service mesh, routing del traffico, gestione della configurazione ed esecuzione di servizi stateful. Vieni a trovarci per parlare dei problemi che stiamo risolvendo e dei sistemi che stiamo costruendo.
Se ci perdi a SREcon e sei interessato a unirti al nostro team, visita il nostro sito Carriere per le ultime opportunità.
(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale
