Per impostazione predefinita, Cloud Data Fusion utilizzava Autoscale come profilo di calcolo. Stimare il numero migliore di worker (nodi) del cluster per un carico di lavoro è difficile e una singola dimensione del cluster per un'intera pipeline spesso non è l'ideale. La scalabilità automatica di Managed Service for Apache Spark offre un meccanismo per automatizzare la gestione delle risorse cluster e consente la scalabilità automatica delle VM worker del cluster. Per saperne di più, consulta Scalabilità automatica.
Nella pagina Configurazione di Compute, dove puoi vedere un elenco di profili, è presente una colonna
Core totali, che indica il numero massimo di vCPU a cui il profilo può
fare lo scale up, ad esempio Up to 84.
Se vuoi utilizzare il profilo di calcolo di Managed Service per Apache Spark , puoi gestire le dimensioni del 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 effimeri, 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 l'utilizzo di memoria e 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à maggiori di memoria, devi utilizzare worker più grandi.
Per ridurre al minimo il tempo di esecuzione, assicurati che il cluster abbia nodi sufficienti per consentire la massima elaborazione parallela possibile.
Worker
Le sezioni seguenti descrivono gli aspetti del dimensionamento dei nodi worker.
CPU e memoria
Ti consigliamo di dimensionare i nodi di lavoro con almeno 2 CPU e 8 GB di memoria. Se hai configurato le pipeline in modo che utilizzino quantità maggiori di memoria, utilizza worker più grandi. Ad esempio, con un nodo worker con 4 CPU e 15 GB, ogni worker avrà 4 CPU e 12 GB disponibili per eseguire i container YARN. Se
la pipeline è configurata per eseguire 1 CPU, 8 GB di executor, YARN
non è in grado di eseguire più di un container per nodo worker. Ogni nodo worker avrebbe
3 CPU e 4 GB aggiuntivi che vengono sprecati perché non possono essere utilizzati per
eseguire nulla. Per massimizzare l'utilizzo delle risorse sul cluster, devi fare in modo che la memoria YARN e le CPU siano un multiplo esatto della quantità necessaria per ogni esecutore Spark. Puoi controllare la quantità di memoria riservata da ogni worker per YARN
controllando la proprietà yarn.nodemanager.resource.memory-mb in YARN.
Se utilizzi Managed Service for Apache Spark, la memoria disponibile per i container YARN sarà circa il 75% della memoria della VM. Anche la dimensione minima del container YARN viene modificata in base alle dimensioni delle VM worker. Alcune dimensioni comuni dei worker e le relative impostazioni YARN sono riportate nella tabella seguente.
| 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 di quella dell'executor
impostata per la pipeline e che YARN arrotonda per eccesso la quantità richiesta. Ad esempio, supponiamo di aver impostato la memoria dell'executor 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 a un multiplo esatto dell'allocazione minima di YARN. Quando viene eseguito su un nodo worker da 8 GB, poiché l'allocazione minima di YARN è 512 MB, viene arrotondata 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 di lavoro può essere
dimensionato in modo leggermente più piccolo oppure agli executor può essere assegnata 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 di YARN è 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 un contesto, la tabella seguente mostra le dimensioni dei worker consigliate per alcune dimensioni comuni degli executor.
| CPU executor | Memoria executor (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 dell'executor impostata su 4 GB, viene aggiunto 1 GB come overhead, il che significa 5 GB di container YARN per ogni executor. Ciò significa che il worker può eseguire quattro container senza risorse aggiuntive rimanenti. Puoi anche moltiplicare le dimensioni dei worker. Ad esempio, se la memoria dell'executor è impostata su 4096 GB, anche un worker con 8 CPU e 52 GB di memoria funzionerebbe 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 executor impostato per utilizzare 1 CPU e 8 GB di memoria utilizza 2 CPU e 26 GB di memoria sulla VM. Se invece gli executor sono configurati per utilizzare 2 CPU e 8 GB di memoria, tutte le CPU vengono utilizzate.
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 di disco in genere non influiscono in modo significativo sul rendimento. Se la pipeline rimescola molti dati, le prestazioni del disco faranno la differenza. Se utilizzi Managed Service for Apache Spark, ti consigliamo di utilizzare dimensioni del disco di almeno 1 TB, poiché le prestazioni del disco aumentano con le dimensioni del disco. Per informazioni sulle prestazioni del disco, vedi Configurare i dischi per soddisfare i requisiti di prestazioni.
Numero di worker
Per ridurre al minimo il tempo di esecuzione, devi assicurarti che il cluster sia abbastanza grande da poter eseguire il maggior numero possibile di operazioni in parallelo. Ad esempio, se l'origine della pipeline legge i dati utilizzando 100 suddivisioni, devi assicurarti che il cluster sia abbastanza grande da eseguire 100 executor contemporaneamente.
Il modo più semplice per capire se il cluster è sottodimensionato è osservare la memoria YARN in attesa nel tempo. Se utilizzi Managed Service for Apache Spark, puoi trovare un grafico nella pagina dei dettagli del cluster.
Se la memoria in attesa è elevata per lunghi periodi di tempo, puoi aumentare il numero di worker per aggiungere la capacità extra al cluster. Nell'esempio precedente, il cluster deve essere aumentato di circa 28 GB per garantire il raggiungimento del livello massimo di parallelismo.
Modalità di flessibilità avanzata (EFM)
EFM consente di specificare che solo i nodi worker principali siano coinvolti nello 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é i worker principali non vengono mai ridotti, il cluster viene ridimensionato con maggiore stabilità ed efficienza. Se esegui pipeline con shuffle su un cluster statico, ti consigliamo di utilizzare EFM.
Per saperne di più su EFM, consulta Modalità di flessibilità avanzata di Managed Service for Apache Spark.