Per impostazione predefinita, Cloud Data Fusion utilizza la scalabilità automatica come profilo di calcolo. È difficile stimare il numero ottimale di worker (nodi) del cluster per un carico di lavoro e spesso una singola dimensione del cluster per un'intera pipeline non è ideale. La scalabilità automatica di Dataproc offre un meccanismo per automatizzare la gestione delle risorse cluster e consente la scalabilità automatica delle VM worker del cluster. Per ulteriori informazioni, consulta la sezione Scalabilità automatica
Nella pagina Configurazione Compute, dove puoi vedere un elenco di profili, è disponibile
Colonna Core totali, che contiene il numero massimo di v CPU che il profilo può
e lo scale up, ad esempio Up to 84.
Per 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 le applicazioni in esecuzione sul cluster. Se esegui le pipeline su temporanei, usa 2 CPU e 8 GB di memoria per il cluster nodi. Se utilizzi cluster permanenti, potresti aver bisogno di nodi master più grandi per tenere il passo con il flusso di lavoro. Per capire se hai bisogno di nodi master più grandi, consente di monitorare l'utilizzo della memoria e della CPU sul nodo. Ti consigliamo di determinare le dimensioni dei nodi worker con almeno 2 CPU e 8 GB di memoria. Se hai configurato le pipeline in modo da utilizzare maggiori quantità di memoria, devi usare ai lavoratori più grandi.
Per ridurre al minimo il tempo di esecuzione, assicurati che il cluster disponga di nodi sufficienti per consentire il maggior numero possibile di elaborazioni in parallelo.
Worker
Le sezioni seguenti descrivono gli aspetti relativi alla definizione delle dimensioni dei nodi worker.
CPU e memoria
Ti consigliamo di dimensionare i nodi worker con almeno 2 CPU e 8 GB
la memoria. Se hai configurato le pipeline per utilizzare quantità di memoria maggiori, usa
ai lavoratori più grandi. Ad esempio, con un nodo worker con 4 CPU e 15 GB,
avrà a disposizione 4 CPU e 12 GB per eseguire container YARN. Se la pipeline è configurata per l'esecuzione di 1 CPU e 8 GB di esecuzioni, YARN non è in grado di eseguire più di un contenitore per nodo di lavoro. Ogni nodo worker avrebbe 3 CPU e 4 GB in più che vengono sprecati perché non possono essere utilizzati per eseguire alcun programma. Per massimizzare l'utilizzo delle risorse nel cluster, la memoria YARN e le CPU devono essere un multiplo esatto della quantità necessaria per ogni Executor Spark. Puoi controllare la quantità di memoria che ogni worker ha riservato per YARN controllando la proprietà yarn.nodemanager.resource.memory-mb in YARN.
Se utilizzi Dataproc, la memoria disponibile per YARN dei container costituirà circa il 75% della memoria delle VM. Le dimensioni minime del contenitore YARN viene regolato anche in base alle dimensioni delle VM worker. Un worker comune le dimensioni e le impostazioni YARN corrispondenti sono indicate 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 di quella dell'esecutore
per la pipeline e lo YARN arrotonda l'importo richiesto. Ad esempio, supponiamo che tu abbia impostato la memoria dell'executor su 2048 MB e non abbia fornito 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 dello YARN
l'allocazione minima. Quando viene eseguito su un nodo worker da 8 GB, poiché l'allocazione minima di YARN è di 512 MB, viene arrotondata per eccesso a 2,5 GB. Ciò significa che ogni worker può eseguire due container, utilizzando tutte le CPU disponibili, ma lasciando inutilizzati 1 GB di memoria YARN (6 GB - 2,5 GB - 2,5 GB). Ciò significa che il nodo worker può essere
di piccole dimensioni oppure agli esecutori potrebbe essere data un po' più di memoria.
Quando viene eseguito su un nodo worker da 16 GB, 2048 MB + 1024 MB viene arrotondata 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 consigliate per i worker in base ad alcune dimensioni comuni degli executor.
| CPU dell'eseguitore | Memoria dell'executor (MB) | CPU del 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'esecutore impostata su 4 GB, 1 GB è viene aggiunto come overhead, il che significa container YARN da 5 GB per ogni esecutore. 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 di un esecutore è impostato su 4096 GB, un worker con 8 CPU e 52 GB di memoria funzionano bene. Le VM Compute Engine limitano la quantità di memoria che possono 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 esecutori sono configurati per utilizzare 2 CPU e 8 GB di memoria, sono in uso tutte le CPU.
Disco
Lo spazio su disco è importante per alcune pipeline, ma non per tutte. Se la tua pipeline non contiene shuffle, il disco verrà utilizzato solo quando Spark esaurisce la memoria e deve versare i dati sul disco. Per questi tipi di pipeline, le dimensioni e il tipo di disco in genere non influiscono molto sul rendimento. Se le tue durante lo shuffling di molti dati, le prestazioni del disco faranno la differenza. Se utilizzi Dataproc, ti consigliamo di usare dimensioni disco di almeno 1 TB, poiché le prestazioni del disco aumentano di pari passo con le dimensioni del disco. Per informazioni sulle prestazioni dei dischi, vedi Configurare i dischi per soddisfare i requisiti di prestazioni.
Numero di worker
Per ridurre al minimo i tempi di esecuzione, devi assicurarti che il cluster sia abbastanza grande da poter funzionare il più possibile in parallelo. Ad esempio, se l'origine della pipeline legge i dati utilizzando 100 suddivisioni, ti consigliamo di assicurarti sia abbastanza grande da eseguire 100 esecutori alla volta.
Il modo più semplice per capire se il cluster è sottodimensionato è osservare lo YARN in attesa di memoria nel tempo. Se utilizzi Dataproc, un grafico può 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 questa ulteriore capacità al tuo cluster. Nell'esempio precedente, il cluster dovrebbe 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 sono coinvolti solo i nodi worker principali durante lo shuffling e i dati di Google Cloud. Poiché i worker secondari non sono più responsabili dei dati di smistamento intermedio, quando vengono rimossi da un cluster, i job Spark non riscontrano ritardi o errori. Poiché non viene mai fatto lo scale down dei worker principali, lo scale down del cluster con maggiore stabilità ed efficienza. Se esegui pipeline con mescola su un cluster statico, ti consigliamo di utilizzare EFM.
Per ulteriori informazioni sulla modalità EFM, consulta Modalità di flessibilità avanzata di Dataproc.