Per impostazione predefinita, Cloud Data Fusion utilizza la scalabilità automatica come profilo di calcolo. Stimare il numero migliore di worker (nodi) del cluster per un carico di lavoro è difficile e una singola dimensione di cluster per un'intera pipeline spesso non è l'ideale. La scalabilità automatica di Dataproc offre un meccanismo per automatizzare la gestione delle risorse cluster. Per scoprire di più, consulta la sezione Scalabilità automatica.
Nella pagina Configurazione computing, dove puoi visualizzare un elenco di profili, è presente la colonna Core totali che include il numero massimo di vCPU fino a cui il profilo può fare lo scale up, ad esempio Up to 84.
Se desideri utilizzare il profilo Dataproc Compute , puoi gestire le dimensioni dei cluster in base alle dimensioni della pipeline.
Nodo master
I nodi master utilizzano risorse proporzionali al numero di pipeline o applicazioni aggiuntive in esecuzione sul cluster. Se esegui pipeline su cluster temporanei, utilizza 2 CPU e 8 GB di memoria per i nodi master. Se utilizzi cluster permanenti, potresti aver bisogno di nodi master più grandi per stare al passo con il flusso di lavoro. Per capire se hai bisogno di nodi master più grandi, puoi monitorare la memoria e l'utilizzo della CPU sul nodo. Ti consigliamo di dimensionare i nodi worker con almeno 2 CPU e 8 GB di memoria. Se hai configurato le pipeline per utilizzare quantità di memoria maggiori, devi utilizzare worker più grandi.
Per ridurre al minimo i tempi di esecuzione, assicurati che il cluster disponga di nodi sufficienti per consentire il maggior numero possibile di elaborazione parallela.
Worker
Le sezioni seguenti descrivono gli aspetti relativi al dimensionamento dei nodi worker.
CPU e memoria
Ti consigliamo di dimensionare i nodi worker con almeno 2 CPU e 8 GB
di memoria. Se hai configurato le pipeline per utilizzare quantità di memoria maggiori, scegli worker più grandi. Ad esempio, con un nodo worker con 4 CPU e 15 GB, ogni worker avrà a disposizione 4 CPU e 12 GB per eseguire container YARN. Se la pipeline è configurata per eseguire 1 CPU e 8 GB di esecutori, YARN non può eseguire più di un container per nodo worker. Ogni nodo worker avrebbe 3 CPU e 4 GB in più, perché non può essere utilizzato per eseguire nulla. Per massimizzare l'utilizzo delle risorse nel tuo cluster, è consigliabile che la memoria e le CPU YARN siano un multiplo esatto della quantità necessaria per esecutore di Spark. Puoi controllare la quantità di memoria riservata da ciascun worker a YARN
controllando la proprietà yarn.nodemanager.resource.memory-mb in YARN.
Se utilizzi Dataproc, la memoria disponibile per i container YARN sarà pari a circa il 75% della memoria delle VM. Anche la dimensione minima del container YARN viene regolata in base alle dimensioni delle VM worker. Alcune dimensioni dei worker comuni e le impostazioni YARN corrispondenti sono riportate nella seguente tabella.
| CPU worker | Memoria worker (GB) | Memoria nodo YARN (GB) | Memoria di allocazione minima YARN (MB) |
|---|---|---|---|
| 1 | 4 | 3 | 256 |
| 2 | 8 | 6 | 512 |
| 4 | 16 | 12 | 1024 |
| 8 | 32 | 24 | 1024 |
| 16 | 64 | 51 | 1024 |
Tieni presente che Spark richiede più memoria rispetto alla memoria dell'esecutore impostata per la pipeline e che YARN arrotonda la quantità richiesta. Ad esempio, supponi di aver impostato la memoria dell'esecutore su 2048 MB e di non aver
specificato un valore per spark.yarn.executor.memoryOverhead, il che significa che viene utilizzato
il valore predefinito di 384 MB. Ciò significa che Spark richiede 2048 MB + 384 MB
per ogni esecutore, che YARN arrotonda per eccesso a un multiplo esatto dell'allocazione minima
YARN. Quando è in esecuzione su un nodo worker da 8 GB, poiché l'allocazione minima
di YARN è di 512 MB, viene arrotondato a 2,5 GB. Ciò significa che ogni worker può eseguire due container, utilizzando tutte le CPU disponibili, ma lasciando 1 GB di memoria YARN (6 GB - 2,5 GB - 2,5 GB) inutilizzato. Ciò significa che il nodo worker può effettivamente
essere ridimensionato leggermente più piccolo, oppure agli esecutori può essere concessa un po' più di memoria.
Quando viene eseguito su un nodo worker da 16 GB, 2048 MB + 1024 MB vengono arrotondati a 3 GB, perché l'allocazione minima per YARN è di 1024 MB.
Ciò significa che ogni nodo worker è in grado di eseguire quattro container, con tutte le CPU e la memoria YARN in uso.
Per fornire il contesto, la tabella seguente mostra le dimensioni consigliate per i worker, in base ad alcune dimensioni comuni degli esecutori.
| CPU esecutore | Memoria esecutore (MB) | CPU worker | Memoria worker ( GB) |
|---|---|---|---|
| 1 | 2048 | 4 | 15 |
| 1 | 3072 | 4 | 21 |
| 1 | 4096 | 4 | 26 |
| 2 | 8192 | 4 | 26 |
Ad esempio, un nodo worker da 26 GB si traduce in 20 GB di memoria utilizzabile per l'esecuzione di container YARN. Con la memoria degli esecutori impostata su 4 GB, viene aggiunto 1 GB come overhead, il che significa container YARN da 5 GB per ogni esecutore. Ciò significa che il worker può eseguire quattro container senza che siano rimaste risorse aggiuntive. Puoi anche moltiplicare le dimensioni dei worker. Ad esempio, se la memoria dell'esecutore è impostata su 4096 GB, anche un worker con 8 CPU e 52 GB di memoria funzionerà bene. Le VM di Compute Engine limitano la quantità di memoria che la VM può avere in base al numero di core. Ad esempio, una VM con 4 core deve avere almeno 7,25 GB di memoria e al massimo 26 GB di memoria. Ciò significa che un esecutore impostato per utilizzare 1 CPU e 8 GB di memoria utilizza 2 CPU e 26 GB di memoria sulla VM. Se invece gli esecutori sono configurati per utilizzare 2 CPU e 8 GB di memoria, vengono utilizzate tutte le CPU.
Disco
Il disco è importante per alcune pipeline, ma non per tutte. Se la pipeline non contiene shuffle, il disco verrà utilizzato solo quando Spark esaurisce la memoria e deve trasferire i dati sul disco. Per questi tipi di pipeline, le dimensioni e il tipo del disco in genere non avranno un grande impatto sulle prestazioni. Se la tua pipeline esegue lo shuffling di molti dati, le prestazioni del disco faranno la differenza. Se utilizzi Dataproc, ti consigliamo di utilizzare dischi di almeno 1 TB, poiché le prestazioni del disco aumentano di pari passo con le dimensioni del disco. Per informazioni sulle prestazioni del disco, consulta Configurare i dischi per soddisfare i requisiti delle prestazioni.
Numero di worker
Per ridurre al minimo i tempi di esecuzione, assicurati che il cluster sia sufficientemente grande da poter essere eseguito il più possibile in parallelo. Ad esempio, se l'origine della pipeline legge i dati utilizzando 100 suddivisioni, dovrai assicurarti che il cluster sia abbastanza grande da eseguire 100 esecutori alla volta.
Il modo più semplice per capire se il cluster è sottodimensionato è esaminare la memoria YARN in attesa nel tempo. Se usi Dataproc, nella pagina dei dettagli del cluster troverai un grafico.
Se la memoria in attesa è elevata per lunghi periodi di tempo, puoi aumentare il numero di worker per aggiungere quella capacità in più al cluster. Nell'esempio precedente, il cluster dovrebbe essere aumentato di circa 28 GB per garantire il livello massimo di parallelismo.
Modalità di flessibilità avanzata (EFM)
EFM consente di specificare che sono coinvolti solo i nodi worker principali durante lo shuffling dei dati. Poiché i worker secondari non sono più responsabili dei dati di shuffling intermedi, quando vengono rimossi da un cluster, i job Spark non subiscono ritardi o errori. Poiché non viene mai fatto lo scale down dei worker principali, il cluster fa lo scale down con maggiore stabilità ed efficienza. Se esegui pipeline con shuffling su un cluster statico, ti consigliamo di usare EFM.
Per maggiori informazioni su EFM, consulta Modalità di flessibilità avanzata di Dataproc.