Infrastruttura di rete Spark e pianificazione dei cluster

Questo articolo offre indicazioni pratiche per la pianificazione della capacità e del calcolo per i carichi di lavoro Spark in Microsoft Fabric, che illustra scenari di sviluppo, migrazione e produzione.

Linee guida per il ridimensionamento

Questa sezione offre indicazioni pratiche per dimensionare e configurare i carichi di lavoro Spark in Fabric. Copre scenari come nuovi sviluppi, migrazione da Azure Synapse e ottimizzazione della capacità per uso in produzione.

Scenario: non si ha familiarità con Fabric e sono necessarie indicazioni sulla pianificazione della capacità.

Iniziare con capacità di prova: Se non si ha familiarità con Fabric, iniziare con la capacità di prova. Offre capacità F4 (4 unità di capacità) o capacità F64 (64 unità di capacità) per 60 giorni. Questa configurazione è ideale per lo sviluppo e il test dei carichi di lavoro Spark. Per stimare la capacità necessaria, vai su Pianifica la dimensione della tua capacità e il Fabric SKU Estimator (anteprima).

Scelta del pool iniziale e pool personalizzato: 

Pool di avvio: In genere si vogliono usare i pool di avvio per i carichi di lavoro Spark. Fabric pre-provisiona questi pool, garantendo tempi di avvio delle sessioni rapidi. Sono ideali per gli ambienti di sviluppo in cui non sono necessarie librerie personalizzate, endpoint privato gestito (MPE) o collegamento privato (PL). I pool di avvio possono migliorare significativamente la produttività degli sviluppatori.

Pool personalizzati: Usare pool personalizzati quando si abilita l'endpoint privato gestito (MPE) o il collegamento privato (PL). 

Per ulteriori informazioni sui pool starter e personalizzati, consultare la documentazione di calcolo Apache Spark per Ingegneria dei Dati e Data Science.  

Profilatura dei notebook di Spark: 

• Per monitorare le applicazioni Spark in Fabric, è possibile usare:

  • Server cronologia Spark: per approfondire i dettagli di un'applicazione singola e dettagli di fase più granulare, livello di attività, sbilanciamenti, piano logico, piano fisico.

  • Interfaccia utente utilizzo risorse: per analizzare l'utilizzo degli executor e il ridimensionamento del loro numero verso l'alto o verso il basso dopo ogni fase.

  • Interfaccia utente di monitoraggio: metriche dei 30 giorni relative alla definizione ad alto livello dei lavori Notebook/Spark (SJD) e ai dettagli di esecuzione delle pipeline, come tempo di esecuzione, stato, inviato da, ecc. L'interfaccia utente di monitoraggio è utile per la visibilità trasversale tra applicazioni.

  • Estensione dell'emettitore di diagnostica: per generare log a destinazioni come Azure Log Analytics, Archiviazione di Azure e Hub eventi di Azure. Questo è ottimo per l'analisi delle tendenze a lungo termine.

• In genere, avviare la profilatura dell'applicazione con i pool starter (pool spark medi (8 vCore e 64 GB di memoria)). Iniziare con un minimo di un nodo e osservare il tempo di esecuzione. 

• Per osservare l'utilizzo delle risorse, passare all'interfaccia utente di utilizzo delle risorse Spark. Nell'interfaccia utente di utilizzo delle risorse, se le istanze allocate sono inferiori alle istanze massime nella fase con il numero massimo di attività, ridurre il numero massimo di nodi nella scalabilità automatica di Spark in modo che corrisponda alle istanze allocate.  

  

• Se le istanze massime e allocate si sovrappongono, è consigliabile aumentare la configurazione massima dei nodi per migliorare il parallelismo e migliorare le prestazioni. 

  

Gestione dell'asimmetria dei dati:

• Se si rileva un'asimmetria dei dati, l'aggiunta di altre risorse potrebbe non essere utile. Risolvere gli sfasamenti usando tecniche come il ripartizionamento quando la distribuzione dei dati non uniforme causa l'asimmetria.
• Per guida sull'identificazione e l'affrontare delle discrepanze, vedere l'articolo sviluppo e monitoraggio di questa serie. 

Valutazione dell'utilizzo: Usare l'app Capacity Metrics per valutare l'utilizzo e stimare le dimensioni ottimali della capacità per i carichi di lavoro. Per ulteriori dettagli, consultare la documentazione sul monitoraggio del consumo di capacità di Apache Spark. Dopo aver analizzato l'utilizzo della capacità di prova, scegliere la capacità con pagamento in base al consumo appropriata per le Prove di concetto (PoC) e quindi passare alla capacità supportata da una prenotazione (RI) o da scaling automatico della fatturazione. L'istanza riservata è un anno di impegno lungo. Una capacità con pagamento in base al consumo può essere annullata in qualsiasi momento. RI offre circa il 40% di sconto rispetto alla capacità con pagamento in base al consumo.

Scenario: esecuzione di carichi di lavoro Spark nella capacità con pagamento in base al consumo. Qual è il modello di capacità ottimale da scegliere?

Se si eseguono carichi di lavoro Spark in una capacità con pagamento in base al consumo, prendere in considerazione la transizione alla scalabilità automatica. La scalabilità automatica offre la stessa flessibilità contrattuale del pagamento in base al consumo, ma con il vantaggio di rimuovere il rischio di limitazione. I lavori, tuttavia, verranno accodati se ci sono risorse insufficienti e con un costo inferiore.

È anche possibile prendere in considerazione un modello ibrido usando una prenotazione per carichi di lavoro stabili e scalabilità automatica per carichi di lavoro più variabili. Le prenotazioni offrono prestazioni di costo ottimali, purché le capacità rimangano ben utilizzate (superiori a 75% in media per il periodo di validità del contratto).

In generale, non ci sono molti motivi per cui potresti preferire il pagamento in base al consumo sulle opzioni descritte in precedenza:

• Si dispone già di una capacità con pagamento in base al consumo che esegue carichi di lavoro non Spark con più spazio disponibile per eseguire i processi Spark. Il costo marginale dell'aggiunta di un altro processo a una capacità è 0, anche se aggiungendone troppi si potrebbe rallentare la capacità. Anche qui, anche se si dovrebbe prendere in considerazione la prenotazione per un anno a un costo ridotto, se possibile.

• Hai un progetto a breve termine di Proof of Concept o di sviluppo, in cui la prevedibilità dei costi è più importante dell'efficienza dei costi. Paghi un importo fisso ogni mese per una capacità. Se si usa eccessivamente la capacità, non si subiscono costi aggiuntivi, ma si viene limitati. Con la scalabilità automatica, gli addebiti sono basati sull'uso, il che potrebbe causare sforamenti di budget se viene eseguito codice errato nell'ambiente di sviluppo. Per un progetto di sviluppo con un budget strettamente gestito, questo potrebbe essere un compromesso utile.

Per ottimizzare ulteriormente l'utilizzo delle risorse:

• È possibile eseguire più notebook Spark in una singola sessione Spark a concorrenza elevata per ottimizzare l'utilizzo delle risorse.

• Abilitare il motore di esecuzione nativo (NEE) per migliorare significativamente le prestazioni.

Scenario: stai migrando carichi di lavoro da Azure Synapse a Fabric.

Se stai migrando carichi di lavoro da Azure Synapse a Fabric, potresti chiederti quali cambiamenti, cosa rimane invariato e se puoi riutilizzare la dimensione esistente di Synapse. 

Migrazione e ottimizzazione: 

• Usa l'utility di migrazione Azure Synapse to Fabric per spostare i carichi di lavoro. 

• Abilitare la fatturazione Autoscale per Spark. Se l'ambiente e la casa del lago sono gli stessi, esegui i notebook o le pipeline in modalità concorrenza alta (una funzione non disponibile in Synapse) per migliorare le prestazioni. 

• Profila i notebook utilizzando il Native Execution Engine (NEE) per ottimizzare le prestazioni dei tuoi carichi di lavoro. 

Linee guida generali sulla configurazione del calcolo: 

Contenuti correlati

• Panoramica delle procedure consigliate di Fabric Spark
• Infrastruttura Spark Security
• Sviluppo e monitoraggio