Scegliere un tipo di calcolo appropriato

Quando si lavora con Azure Databricks, la selezione del tipo di calcolo corretto influisce direttamente sui costi, sulle prestazioni e sulla complessità operativa. Ogni opzione di calcolo offre modelli di carico di lavoro diversi e offre compromessi distinti in termini di tempo di avvio, scalabilità e sovraccarico di gestione.

La comprensione di queste opzioni consente di trovare le corrispondenze tra le risorse di calcolo e le esigenze specifiche. È possibile ottimizzare i cicli di sviluppo rapidi, ridurre al minimo i costi per i processi di produzione o bilanciare entrambi i carichi di lavoro di analisi.

Calcolo serverless

Il calcolo serverless viene gestito interamente da Azure Databricks. Non si effettua il provisioning o si configura l'infrastruttura. Azure Databricks alloca e ridimensiona automaticamente le risorse in base alle esigenze del carico di lavoro. Queste risorse vengono eseguite nella sottoscrizione di Azure di Databricks, non nella propria, il che significa che nella sottoscrizione non sono presenti macchine virtuali o componenti di rete.

Con il calcolo serverless, l'avvio richiede in genere 2-6 secondi. La piattaforma aumenta rapidamente quando il volume di query aumenta e riduce le prestazioni durante i periodi di inattività per ridurre al minimo i costi. In questo modo si elimina la necessità di stimare la capacità o gestire le configurazioni del cluster.

L'ambiente di calcolo serverless richiede il catalogo unity ed è disponibile per:

• Notebook: sviluppo interattivo di Python e SQL con allocazione automatica delle risorse
• Processi: flussi di lavoro automatizzati eseguiti senza configurazione dell'infrastruttura
• Pipeline dichiarative di Lakeflow Spark con scalabilità su richiesta
• SQL Warehouses: Ottimizzazione dell'esecuzione di query SQL con la gestione intelligente del carico di lavoro

Serverless è ideale per l'analisi esplorativa, le pipeline ETL, i carichi di lavoro di business intelligence e gli scenari in cui la latenza di avvio è importante. Il runtime senza versione indica che Azure Databricks applica automaticamente gli aggiornamenti, quindi è sempre possibile eseguire le funzionalità più recenti senza eseguire alcuna operazione di migrazione.

Tuttavia, serverless presenta limitazioni. Nei notebook, la modalità serverless non supporta Scala, linguaggio R, librerie JAR o API RDD (Resilient Distributed Dataset). Sono limitate anche le configurazioni di Spark personalizzate. Le attività JAR nei processi Lakeflow nell'elaborazione serverless sono disponibili in anteprima pubblica. Se il carico di lavoro richiede notebook Scala o R, API RDD o controllo di configurazione Spark completo, usare invece il calcolo classico con la modalità di accesso dedicata.

Scegliere una modalità di prestazioni serverless

Il calcolo serverless per processi e pipeline offre due modalità di prestazioni che bilanciano la velocità di avvio rispetto ai costi.

La modalità ottimizzata per le prestazioni è l'impostazione predefinita. Azure Databricks gestisce un pool di risorse di calcolo pre-riscaldate, abilitando l'avvio in pochi secondi. Scegliere questa modalità per carichi di lavoro interattivi, processi sensibili alla latenza e scenari in cui l'avvio rapido è fondamentale.

La modalità Standard è ottimizzata per i costi. I carichi di lavoro serverless che usano la modalità di prestazioni standard vengono in genere avviati entro 4-6 minuti. La modalità Standard può ridurre il consumo di DBU fino a 70% rispetto alla modalità ottimizzata per le prestazioni, adatta per i processi batch pianificati e le pipeline in cui la latenza di avvio è accettabile.

Configuri la modalità prestazioni usando l'interruttore Prestazioni ottimizzate nella pagina dei dettagli dell'attività. La modalità Standard non è disponibile per le pipeline continue o le esecuzioni monouso inviate tramite l'endpoint runs/submit API. Per i notebook, è disponibile solo la modalità ottimizzata per le prestazioni.

Calcolo classico

Il calcolo classico offre il controllo completo sulla configurazione del cluster. È possibile creare, ridimensionare e gestire le risorse di calcolo eseguite direttamente nella sottoscrizione di Azure, offrendo visibilità e controllo sull'infrastruttura sottostante.

Il calcolo classico supporta due modalità di accesso che determinano il modo in cui gli utenti interagiscono con il cluster:

La modalità di accesso standard consente a più utenti di condividere un singolo cluster contemporaneamente. Lakeguard garantisce l'isolamento tra il codice utente, impedendo al lavoro di un utente di interferire con un altro. Questa modalità è ideale per la progettazione collaborativa dei dati, l'analisi condivisa e l'ottimizzazione dei costi tramite il pool di risorse.

La modalità di accesso dedicato assegna il cluster esclusivamente a un singolo utente o gruppo. Con l'accesso dedicato si ottengono privilegi completi a livello di computer, necessari per API RDD, carichi di lavoro GPU, supporto per il linguaggio R o ambienti contenitore personalizzati.

Oltre alle modalità di accesso, il calcolo classico offre diverse modalità cluster che determinano l'architettura del cluster:

I cluster a più nodi sono costituiti da un nodo driver e uno o più nodi di lavoro. Il driver coordina l'esecuzione mentre i worker eseguono calcoli distribuiti in parallelo. Questa architettura consente il ridimensionamento orizzontale: è possibile aggiungere nodi di lavoro per elaborare set di dati di dimensioni maggiori o aumentare il parallelismo. I cluster a più nodi funzionano bene per i carichi di lavoro di produzione che elaborano grandi volumi di dati o richiedono una velocità effettiva elevata.

I cluster a nodo singolo contengono solo un nodo driver senza nodi di lavoro. Tutto il calcolo avviene sul driver, il che significa che i carichi di lavoro non possono essere distribuiti tra più computer. I cluster a nodo singolo sono adatti per scenari specifici, come l'esplorazione leggera, l'analisi di set di dati di piccole dimensioni o la sperimentazione di machine learning in cui il sovraccarico di shuffle supera i vantaggi della distribuzione dei carichi. Sono particolarmente utili per i flussi di lavoro di apprendimento automatico con framework come scikit-learn che non sono progettati per essere distribuiti tra i nodi, o quando si testano notebook con piccoli campioni di dati.

Tenere presente che i cluster a nodo singolo presentano limitazioni dell'architettura. Non possono essere ridimensionati orizzontalmente per gestire un carico maggiore e tutte le elaborazioni si basano sulle risorse di un singolo computer. Per i carichi di lavoro che richiedono l'elaborazione distribuita, l'esecuzione parallela di attività tra set di dati di grandi dimensioni o la tolleranza di errore tramite ridondanza, usare invece cluster multinodo.

Il calcolo classico offre flessibilità, ma richiede una gestione maggiore. È possibile configurare i tipi di istanza, le regole di scalabilità automatica e le versioni di runtime. Il tempo di avvio varia in genere da 3 a 7 minuti a seconda delle dimensioni del cluster. A differenza del serverless, è possibile selezionare e gestire manualmente la versione di Databricks Runtime, scegliendo quando eseguire l'aggiornamento da una versione a un'altra, ad esempio da Runtime 13.3 LTS a 14.3 LTS. Anche se gli aggiornamenti del sistema operativo e della sicurezza sottostanti possono essere automatizzati, le modifiche alla versione di runtime richiedono una selezione manuale.

Questo tipo di calcolo si adatta ai carichi di lavoro che necessitano di funzionalità non disponibili nel serverless, richiedono un controllo preciso sull'infrastruttura o hanno requisiti di conformità per l'isolamento delle risorse.

Magazzini SQL

I warehouse SQL sono risorse di calcolo ottimizzate in modo specifico per query SQL, analisi e business intelligence. Sono disponibili in tre tipi, ognuno con caratteristiche di prestazioni diverse.

I warehouse SQL serverless offrono prestazioni ottimali ed efficienza dei costi. Iniziano in 2-6 secondi, usano Intelligent Workload Management per stimare le esigenze delle risorse di query e ridimensionare i cluster in modo dinamico in base alla richiesta. Foton e I/O predittivo accelerano l'esecuzione delle query. Scegliere i data warehouse SQL serverless per la maggior parte dei carichi di lavoro SQL, come dashboard BI, processi ETL e analisi ad hoc.

I warehouse Pro SQL supportano Photon e I/O predittivo, ma non la gestione intelligente del carico di lavoro. Impiegano circa 4 minuti per avviarsi e scalano in modo meno dinamico rispetto a soluzioni serverless. È possibile usare i data warehouse pro quando sono necessarie configurazioni di rete personalizzate, ad esempio la connessione ai database locali tramite la federazione o l'integrazione con i servizi nella rete virtuale.

I warehouse SQL classici offrono prestazioni SQL di livello di base solo con supporto Photon. Iniziano in circa 4 minuti e includono la scalabilità automatica di base. Scegliere i warehouse classici solo quando le opzioni serverless e pro non sono disponibili o per l'esplorazione interattiva di base con requisiti minimi di prestazioni.

Tutti i tipi di SQL Warehouse ottimizzano i modelli di esecuzione SQL, ma serverless offre il ridimensionamento più reattivo e il sovraccarico operativo più basso.

Pool di istanze

I pool di istanze mantengono un set di istanze di macchine virtuali inattive pronte per l'uso immediato. Quando si crea un cluster da un pool, il tempo di avvio diminuisce perché Databricks alloca le istanze dal pool anziché richiederne di nuove da Azure.

I pool riducono il tempo di avvio da minuti a meno di un minuto in molti casi. È possibile configurare il numero minimo di istanze inattive in modo da mantenere calda e la capacità massima del pool. Quando i cluster rilasciano istanze, tali istanze tornano al pool per il riutilizzo.

Si paga per i costi delle macchine virtuali mentre le istanze si trovano inattive nel pool, ma non per le unità di calcolo di Azure Databricks. Ciò rende i pool convenienti quando si eseguono carichi di lavoro abbastanza frequentemente che il tempo di avvio ridotto giustifica il costo dell'infrastruttura inattiva.

Con il calcolo serverless disponibile, i pool sono meno importanti per la maggior parte degli scenari. Serverless inizia più velocemente e ridimensiona in modo più efficiente senza che sia necessario mantenere la capacità inattiva. Tuttavia, i pool rimangono utili quando sono necessarie funzionalità di calcolo classiche e vogliono ottimizzare il tempo di avvio per i carichi di lavoro eseguiti di frequente.

Configurare i pool con istanze spot per i nodi di lavoro per ridurre i costi, ma usare istanze su richiesta per i nodi driver per mantenere l'affidabilità.

Computazione dei lavori

Job compute si riferisce ai cluster ottimizzati per i flussi di lavoro automatizzati anziché per lo sviluppo interattivo. È possibile configurare il calcolo dei processi tramite i criteri del cluster che applicano le procedure consigliate per i carichi di lavoro di produzione.

I cluster di lavoro terminano automaticamente dopo aver completato le attività, impedendo costi non necessari a causa di risorse inattive. Quando si configura un lavoro, è possibile scegliere tra il calcolo serverless e quello classico.

• Il calcolo dei processi serverless offre avvio più rapido, gestione automatica dell'infrastruttura e costi inferiori per la maggior parte dei carichi di lavoro automatizzati.
• Classic job compute offre più opzioni di configurazione per i carichi di lavoro che necessitano di funzionalità che il serverless non supporta.

Con il calcolo dei processi classico, è possibile usare impostazioni ottimizzate come la scalabilità automatica e le istanze spot. Le istanze spot (dette anche macchine virtuali spot di Azure) usano la capacità in eccesso di Azure a costi notevolmente ridotti, spesso fino a 90% meno costosi rispetto alle normali istanze su richiesta. Azure può recuperare queste istanze con un preavviso di soli 30 secondi quando ha bisogno di riottenere la capacità. La tolleranza di errore predefinita di Spark gestisce automaticamente queste interruzioni ritentando le attività non riuscite in altri nodi disponibili, il che rende le istanze spot un'opzione redditizia per molti carichi di lavoro di elaborazione batch ed ETL.

I criteri di calcolo dei processi in Azure Databricks offrono un modello per la creazione di cluster di processi pronti per la produzione con impostazioni predefinite sensibili. Applica la versione di runtime LTS (Long Term Support) più recente e altre impostazioni di affidabilità.

Confrontare i tipi di calcolo

Diversi tipi di calcolo soddisfano diversi scenari. La tabella seguente confronta le caratteristiche chiave per prendere decisioni informate:

Tipo di ambiente di calcolo	Consigliati per	Ora di avvio	Overhead di gestione	Efficienza dei costi	Limitazione principale
Calcolo serverless	Sviluppo interattivo, processi ETL, carichi di lavoro BI	⚡ 2-6 secondi	👌 Minimo - completamente gestito	 Alto livello - riduzione automatica a zero, paghi solo per ciò che usi	Nessuna API RDD, R o librerie JAR
Calcolo classico (Standard)	Progettazione collaborativa dei dati, analisi condivisa	⏱️ 3-7 minuti	🔧 Modera - Configurare e monitorare	 Moderate - La condivisione multiutente riduce i costi per utente	Richiede il catalogo unity per la governance
Calcolo classico (dedicato)	Carichi di lavoro RDD, processi GPU, linguaggio R, contenitori personalizzati	⏱️ 3-7 minuti	🔧 Modera - Configurare e monitorare	🔴 Inferiore - solo utente singolo/gruppo	Costo più elevato rispetto alle risorse condivise
Pool di istanze	Eseguire spesso carichi di lavoro classici che richiedono l'avvio rapido	🚀 <1 minuto	⚠️ Maggiore - mantenere la capacità inattiva	🔄 Variabile: giustificare il costo di inattività con frequenza di utilizzo	Pagamento per istanze inattive
Il Magazzino SQL (Serverless)	Analisi SQL, dashboard BI, reportistica	⚡ 2-6 secondi	👌 Gestione minima del carico di lavoro intelligente	 Elevata scalabilità dinamica con Photon + I/O predittivo	Solo carichi di lavoro SQL
SQL Warehouse (Pro)	SQL con rete personalizzata, federazione	⏱️ ~4 minuti	🔧 Moderato - Configurazione manuale del ridimensionamento	 Moderate - Photon + I/O predittivo	Ridimensionamento più lento rispetto a serverless
SQL Warehouse (versione classica)	Esplorazione SQL a livello di base	⏱️ ~4 minuti	🔧 Moderato - Configurazione manuale del ridimensionamento	🔴 Inferiore - solo Foton di base	Funzionalità di prestazioni limitate
Calcolo processo (Serverless)	Flussi di lavoro automatizzati, ETL di produzione	⚡ 2-6 secondi	👌 Minimo : terminazione automatica dopo il completamento	 Alto - Nessun costo di inattività	Uguale all'ambiente di calcolo serverless
Calcolo dei processi (versione classica)	Processi che richiedono configurazioni personalizzate	⏱️ 3-7 minuti	🔧 Modera - Configurare i criteri	 Moderato - la terminazione automatica impedisce sprechi da inattività	Richiede la gestione dell'infrastruttura

Scegliere il tipo di calcolo corretto

Avviare il processo decisionale identificando le caratteristiche del carico di lavoro. Il diagramma seguente illustra un flusso decisionale che consente di selezionare il tipo di calcolo appropriato:

Considerare queste domande:

Quale tipo di lavoro stai eseguendo? Se stai scrivendo notebook interattivi, il calcolo serverless offre il ciclo di iterazione più veloce. Per le query SQL e i dashboard bi, i data warehouse SQL serverless offrono prestazioni ottimali. I processi di produzione automatizzati funzionano bene con l'elaborazione di job serverless, a meno che non siano necessarie configurazioni personalizzate.

Il codice usa API o linguaggi specifici?Le API RDD, il linguaggio R o l'accelerazione GPU richiedono un calcolo classico con modalità di accesso dedicato. I carichi di lavoro Python, SQL e Scala vengono eseguiti in calcolo classico serverless o standard.

Con quale frequenza viene eseguito questo carico di lavoro? I carichi di lavoro poco frequenti traggono il massimo vantaggio dal serverless perché si paga solo durante l'esecuzione. I carichi di lavoro ricorrenti possono giustificare i pool di istanze se si usa il calcolo classico, anche se spesso i serverless offrono un'economia migliore.

È necessaria una rete personalizzata o un'infrastruttura specifica? Le reti virtuali personalizzate, la connettività locale o tipi di istanza specifici richiedono il calcolo classico o i data warehouse SQL pro. Serverless opera nella sottoscrizione gestita da Databricks senza integrazione di rete personalizzata, quindi le risorse non vengono visualizzate nella sottoscrizione di Azure.

Quali sono i requisiti di prestazioni? Per i carichi di lavoro sensibili alla latenza, il calcolo serverless inizia da 2 a 4 volte più veloce rispetto alle opzioni classiche. Per prestazioni prevedibili su larga scala, sia serverless che classico possono soddisfare i requisiti, ma serverless si adatta in modo più dinamico alle variazioni di carico.

Per la maggior parte degli scenari, iniziare con le opzioni serverless. Riducono al minimo il sovraccarico operativo, ottimizzano i costi tramite il ridimensionamento automatico e offrono l'esperienza di sviluppo più rapida. Passare al calcolo classico solo quando si verifica una limitazione specifica non supportata dal serverless.