Scalabilità automatica di Serverless per Apache Spark
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questo documento fornisce informazioni sulla scalabilità automatica di Google Cloud Serverless per Apache Spark.
Quando invii il carico di lavoro Spark, Serverless for Apache Spark
può scalare dinamicamente le risorse del carico di lavoro, ad esempio il numero di esecutori,
per eseguire il carico di lavoro in modo efficiente. La scalabilità automatica di Serverless per Apache Spark è il comportamento predefinito e utilizza l'allocazione dinamica delle risorse di Spark per determinare se, come e quando scalare il workload.
Scalabilità automatica V2 di Serverless per Apache Spark
La versione 2 (V2) della scalabilità automatica di Serverless per Apache Spark aggiunge funzionalità e miglioramenti
alla versione 1 (V1) predefinita per aiutarti a gestire i workload Serverless per Apache Spark, migliorare
le prestazioni dei workload e ridurre i costi:
Ridimensionamento asincrono dei nodi: la scalabilità automatica V2 sostituisce il ridimensionamento sincrono di V1 con il ridimensionamento asincrono. Utilizzando la riduzione delle risorse asincrona, Serverless per Apache Spark riduce le risorse del carico di lavoro senza attendere che tutti i nodi completino la migrazione dello shuffle. Ciò significa che i nodi long-tail che vengono fare lo scale down lentamente
non bloccheranno l'upscaling.
Selezione intelligente dei nodi per lo scale down: la scalabilità automatica V2 sostituisce la selezione casuale dei nodi della V1 con un algoritmo intelligente che identifica i nodi migliori per fare lo scale down. Questo algoritmo prende in considerazione fattori come le
dimensioni dei dati di shuffling e il tempo di inattività del nodo.
Comportamento configurabile di ritiro controllato e migrazione shuffle di Spark:
Autoscaling V2 ti consente di utilizzare le proprietà Spark standard per configurare il ritiro controllato e la migrazione shuffle di Spark. Questa funzionalità può aiutarti
a mantenere la compatibilità della migrazione con le proprietà Spark personalizzate.
Funzionalità di scalabilità automatica di Serverless per Apache Spark
Funzionalità
Scalabilità automatica di Serverless per Apache Spark V1
Scalabilità automatica V2 di Serverless per Apache Spark
Riduzione delle dimensioni dei nodi
Sincrona
Asincrona
Selezione dei nodi per la riduzione delle risorse
Casuale
Soluzione intelligente
Avvia la rimozione controllata di Spark e la migrazione shuffle
Se utilizzare l'allocazione dinamica delle risorse, che aumenta e diminuisce il numero di executor in base al workload.
Se imposti il valore su false, la scalabilità automatica viene disattivata
per il carico di lavoro. Predefinito: true.
true
spark.dynamicAllocation.initialExecutors
Il numero iniziale di esecutori allocati al workload. Dopo l'avvio del
carico di lavoro, la scalabilità automatica potrebbe modificare il numero di esecutori attivi.
Il valore minimo è 2, il valore massimo è 2000.
2
spark.dynamicAllocation.minExecutors
Il numero minimo di esecutori a cui ridurre il workload.
Il valore minimo è 2.
2
spark.dynamicAllocation.maxExecutors
Il numero massimo di esecutori a cui scalare il carico di lavoro.
Il valore massimo è 2000.
1000
spark.dynamicAllocation.executorAllocationRatio
Personalizza lo scale up del workload Spark. Accetta un valore compreso
tra 0 e 1. Un valore di 1.0
offre la massima capacità di scalabilità e aiuta a ottenere il massimo
parallelismo. Un valore di 0.5 imposta la capacità di scalabilità e
il parallelismo a metà del valore massimo.
0.3
spark.reducer.fetchMigratedShuffle.enabled
Se impostato su true, consente di recuperare la posizione dell'output di shuffling dal driver Spark dopo che il recupero non è riuscito da un executor ritirato a causa dell'allocazione dinamica di Spark. Ciò riduce
gli errori ExecutorDeadException causati dalla migrazione dei blocchi di rimescolamento
dagli executor ritirati a quelli attivi e riduce i tentativi di ripristino dello stage
causati da errori FetchFailedException (vedi
FetchFailedException causata da
ExecutorDeadException).
Questa proprietà è disponibile in Serverless per Apache Spark
versioni del runtime Spark1.1.12 e successive e 2.0.20 e successive.
false
Metriche di allocazione dinamica di Spark
I carichi di lavoro batch Spark generano le seguenti metriche relative all'allocazione dinamica delle risorse Spark (per ulteriori informazioni sulle metriche Spark, consulta Monitoraggio e strumentazione).
Metrica
Descrizione
maximum-needed
Il numero massimo di esecutori necessari con il carico attuale per soddisfare
tutte le attività in esecuzione e in attesa.
running
Il numero di esecutori in esecuzione che eseguono attività.
Problemi e soluzioni relativi all'allocazione dinamica di Spark
FetchFailedException causata da ExecutorDeadException
Causa: quando l'allocazione dinamica di Spark riduce le dimensioni di un executor, viene eseguita la migrazione del file di shuffle agli executor attivi. Tuttavia, poiché l'attività di riduzione di Spark su un executor recupera l'output di shuffle dalla posizione impostata dal driver Spark all'avvio dell'attività di riduzione, se un file di shuffle viene migrato, il reducer può continuare a tentare di recuperare l'output di shuffle da un executor ritirato, causando errori ExecutorDeadException e FetchFailedException.
Soluzione: attiva il recupero della posizione di shuffling impostando
spark.reducer.fetchMigratedShuffle.enabled su true quando esegui il
workload batch Serverless per Apache Spark (vedi
Impostare le proprietà del workload batch Spark).
Quando questa proprietà è abilitata, l'attività di riduzione recupera nuovamente la posizione dell'output di shuffle dal driver dopo che un recupero da un esecutore ritirato non riesce.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-04 UTC."],[[["\u003cp\u003eDataproc Serverless for Spark uses dynamic resource allocation to automatically scale workload resources, such as the number of executors, for efficient processing.\u003c/p\u003e\n"],["\u003cp\u003eAutoscaling V2 is an improved version of the default V1 and offers asynchronous node downscaling, intelligent node selection for downscaling, and configurable Spark graceful decommissioning and shuffle migration behavior.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003espark.dataproc.scaling.version\u003c/code\u003e property controls whether autoscaling V1 or V2 is active, and setting it to \u003ccode\u003e2\u003c/code\u003e enables V2's enhanced features.\u003c/p\u003e\n"],["\u003cp\u003eVarious Spark dynamic allocation properties, such as \u003ccode\u003espark.dynamicAllocation.minExecutors\u003c/code\u003e and \u003ccode\u003espark.dynamicAllocation.maxExecutors\u003c/code\u003e, can be configured to control autoscaling behavior when submitting a batch workload.\u003c/p\u003e\n"],["\u003cp\u003eSetting \u003ccode\u003espark.reducer.fetchMigratedShuffle.enabled\u003c/code\u003e to \u003ccode\u003etrue\u003c/code\u003e mitigates \u003ccode\u003eExecutorDeadException\u003c/code\u003e and \u003ccode\u003eFetchFailedException\u003c/code\u003e errors by allowing reducers to refetch shuffle output locations after an executor is decommissioned.\u003c/p\u003e\n"]]],[],null,["# Serverless for Apache Spark autoscaling\n\nThis document provides information about Google Cloud Serverless for Apache Spark autoscaling.\nWhen you submit your Spark workload, Serverless for Apache Spark\ncan dynamically scale workload resources, such as the number of executors,\nto run your workload efficiently. Serverless for Apache Spark autoscaling is the\ndefault behavior, and uses\n[Spark dynamic resource allocation](https://spark.apache.org/docs/latest/job-scheduling.html#dynamic-resource-allocation)\nto determine whether, how, and when to scale your workload.\n\nServerless for Apache Spark autoscaling V2\n------------------------------------------\n\nServerless for Apache Spark autoscaling version 2 (V2) adds features and improvements\nto default version 1 (V1) to help you manage Serverless for Apache Spark workloads, improve\nworkload performance, and save costs:\n\n- **Asynchronous node downscaling**: Autoscaling V2 replaces V1's synchronous downscaling with asynchronous downscaling. Using asynchronous downscaling, Serverless for Apache Spark downscales workload resources without waiting for all nodes to finish shuffle migration. This means that long-tail nodes that scale down slowly won't block upscaling.\n- **Intelligent scaling down node selection**: Autoscaling V2 replaces V1's random node selection with an intelligent algorithm that identifies the best nodes to scale down first. This algorithm considers factors such as the node's shuffle data size and idle time.\n- **Configurable Spark grace decommission and shuffle migration behavior**: Autoscaling V2 lets you use standard Spark properties to configure Spark graceful decommissioning and shuffle migration. This feature can help you maintain migration compatibility with your customized Spark properties.\n\n| **Note:** Set the `spark.dataproc.scaling.version=2` property to enable Serverless for Apache Spark autoscaling V2 when you [submit a Spark batch workload](/dataproc-serverless/docs/quickstarts/spark-batch#submit_a_spark_batch_workload).\n\n### Serverless for Apache Spark autoscaling features\n\nSpark dynamic allocation properties\n-----------------------------------\n\nThe following table lists\n[Spark Dynamic Allocation](https://spark.apache.org/docs/latest/configuration.html#dynamic-allocation)\nproperties that you can set when you submit a batch workload to control autoscaling (see\n[how to set Spark properties](/dataproc-serverless/docs/concepts/properties)).\n| **Note:** Also see [Spark properties](/dataproc-serverless/docs/concepts/properties), which describes additional properties that you can set when you submit a Serverless for Apache Spark Spark batch workload.\n\nSpark dynamic allocation metrics\n--------------------------------\n\nSpark batch workloads generate the following metrics related to Spark dynamic\nresource allocation (for additional information on Spark metrics, see\n[Monitoring and Instrumentation](https://spark.apache.org/docs/latest/monitoring.html)).\n| **Note:** See [Spark metrics](/dataproc-serverless/docs/concepts/metrics), which describes properties you can set to control the collection of Spark metrics.\n\nSpark dynamic allocation issues and solutions\n---------------------------------------------\n\n- **FetchFailedException caused by ExecutorDeadException**\n\n Cause: When Spark dynamic allocation scales down an executor, the shuffle file is migrated to\n live executors. However, since the Spark reducer task on an executor fetches shuffle\n output from the location set by the Spark driver when the reducer task started, if\n a shuffle file is migrated, the reducer can continue to attempt to\n fetch shuffle output from a decommissioned executor, causing `ExecutorDeadException`\n and `FetchFailedException` errors.\n\n Solution: Enable shuffle location refetching by setting\n the `spark.reducer.fetchMigratedShuffle.enabled` to `true` when you run your\n Serverless for Apache Spark batch workload (see\n [Set Spark batch workload properties](/dataproc-serverless/docs/concepts/properties#set_spark_batch_workload_properties)).\n When this property is enabled, the reducer task refetches the shuffle output\n location from the driver after a fetch from a decommissioned executor fails."]]
