Migrazione dei job Apache Spark a Dataproc

Questo documento descrive come spostare i job Apache Spark in Dataproc. Il documento è destinato a tecnici e architetti di big data. e tratta argomenti quali considerazioni su migrazione, preparazione, migrazione lavorativa e gestione.

Nota: le informazioni e i consigli contenuti in questo documento sono stati raccolti grazie alla collaborazione con una varietà di clienti e ambienti sul campo. Ringraziamo i nostri clienti e partner per aver condiviso le loro esperienze e informazioni.

Panoramica

Quando vuoi spostare i carichi di lavoro Apache Spark da un ambiente on-premise a Google Cloud, ti consigliamo di utilizzare Dataproc per eseguire i cluster Apache Spark/Apache Hadoop. Dataproc è un servizio completamente gestito e completamente supportato da Google Cloud. Consente di separare spazio di archiviazione e calcolo, in modo da gestire i costi e aumentare la flessibilità nella scalabilità dei carichi di lavoro.

Se un ambiente Hadoop gestito non soddisfa le tue esigenze, puoi anche utilizzare una configurazione diversa, come l'esecuzione di Spark su Google Kubernetes Engine (GKE) o il noleggio di macchine virtuali su Compute Engine e la configurazione autonoma di un cluster Hadoop o Spark. Tuttavia, bisogna tenere conto del fatto che le opzioni diverse dall'utilizzo di Dataproc sono autogestite e prevedono l'assistenza della community.

Pianificazione della migrazione

Ci sono molte differenze tra l'esecuzione di job Spark on-premise e l'esecuzione di job Spark su cluster Dataproc o Hadoop su Compute Engine. È importante guardare attentamente al carico di lavoro e prepararti per la migrazione. In questa sezione illustreremo le considerazioni da tenere presenti e i preparativi da prendere prima di eseguire la migrazione dei job Spark.

Identificare i tipi di prestazione e i cluster di piano

Sono descritti tre tipi di carichi di lavoro Spark, come descritto in questa sezione.

Job batch regolari

I job batch pianificati regolarmente includono casi d'uso come ETL ETL giornalieri o orari oppure pipeline per l'addestramento di modelli di machine learning con Spark ML. In questi casi, ti consigliamo di creare un cluster per ogni carico di lavoro batch, quindi di eliminare il cluster al termine del job. Puoi configurare il tuo cluster in modo flessibile, perché puoi regolare la configurazione per ogni carico di lavoro separatamente. I cluster Dataproc vengono fatturati con incrementi di un secondo dopo il primo minuto, quindi questo approccio è anche conveniente, perché puoi etichettare i tuoi cluster. Per ulteriori informazioni, consulta la pagina Prezzi di Dataproc.

Puoi implementare job batch con modelli di flusso di lavoro o seguendo questi passaggi:

1. Crea un cluster e attendi che venga creato. Puoi monitorare se il cluster è stato creato utilizzando una chiamata API o un comando gcloud. Se esegui il tuo job su un cluster Dataproc dedicato, potrebbe essere utile disattivare l'allocazione dinamica e il servizio di shuffling esterno. Il seguente comando gcloud mostra le proprietà di configurazione Spark fornite quando crei il cluster Dataproc:

   dataproc clusters create ... \
       --properties 'spark:spark.dynamicAllocation.enabled=false,spark:spark.shuffle.service.enabled=false,spark.executor.instances=10000'

2. Invia il tuo job al cluster. (puoi monitorare lo stato del job utilizzando una chiamata API o un comando gcloud). Ecco alcuni esempi:

   jobId=$(gcloud --quiet dataproc jobs submit pyspark \
       --async \
       --format='value(reference.jobId)' \
       --cluster $clusterName \
       --region global \
       gs://dataproc-examples-2f10d78d114f6aaec76462e3c310f31f/src/pyspark/hello-world/hello-world.py)
   
   gcloud dataproc jobs describe $jobId \
       --region=global \
       --format='value(status.state)'

3. Elimina il cluster dopo l'esecuzione del job utilizzando una chiamata API o un comando gcloud.

Job in modalità flusso

Per i job di inserimento di flussi, devi creare un cluster Dataproc a lunga esecuzione e configurare il cluster per l'esecuzione in modalità ad alta disponibilità. Sconsigliamo di utilizzare VM prerilasciabili per questo caso.

Carichi di lavoro ad hoc o interattivi inviati dagli utenti

Esempi di carichi di lavoro ad hoc possono includere gli utenti che scrivono query o eseguono job di analisi durante il giorno.

In questi casi, devi decidere se è necessario eseguire il cluster in modalità ad alta disponibilità, se vuoi utilizzare le VM prerilasciabili e come intendi gestire l'accesso al cluster. Puoi pianificare la creazione e la terminazione dei cluster (ad esempio, se non hai mai bisogno di un cluster durante la notte o nei fine settimana) e puoi implementare la scalabilità su e giù in base alla pianificazione.

Identifica le origini dati e le dipendenze

Ogni job ha le sue dipendenze (ad esempio, le origini dati di cui ha bisogno) e altri team della tua azienda potrebbero dipendere dal risultato dei job. Pertanto, devi identificare tutte le dipendenze, quindi creare un piano di migrazione che includa le procedure per:

• Migrazione dettagliata di tutte le origini dati in Google Cloud. All'inizio, è utile rispecchiare l'origine dati in Google Cloud in modo da averla in due posizioni.

• Migrazione job dei tuoi carichi di lavoro Spark a Google Cloud non appena è stata eseguita la migrazione delle origini dati corrispondenti. Come per i dati, ad un certo punto potresti avere due carichi di lavoro in esecuzione in parallelo nel tuo vecchio ambiente e in Google Cloud.

• Migrazione di altri carichi di lavoro che dipendono dall'output dei carichi di lavoro Spark. Oppure potresti semplicemente replicare l'output nell'ambiente iniziale.

• L'arresto dei job Spark nell'ambiente precedente dopo che tutti i team dipendenti hanno confermato che non richiedono più i job.

Scegli le opzioni di archiviazione

Esistono due opzioni di archiviazione da utilizzare con i cluster Dataproc: puoi archiviare tutti i dati in Cloud Storage o utilizzare dischi locali o dischi permanenti con i worker del cluster. La scelta corretta dipende dal carattere dei tuoi job.

Confronto tra Cloud Storage e HDFS

In ogni nodo di un cluster Dataproc è installato un connettore Cloud Storage. Per impostazione predefinita, il connettore è installato in /usr/lib/hadoop/lib. Il connettore implementa l'interfaccia Hadoop FileSystem e rende Cloud Storage compatibile con HDFS.

Poiché Cloud Storage è un sistema di archiviazione di oggetti binari di grandi dimensioni (BLOB), il connettore emula le directory in base al nome dell'oggetto. Puoi accedere ai dati utilizzando il prefisso gs:// anziché il prefisso hdfs://.

In genere il connettore Cloud Storage non richiede alcuna personalizzazione. Tuttavia, se devi apportare modifiche, puoi seguire le istruzioni per la configurazione del connettore. È disponibile anche un elenco completo delle chiavi di configurazione.

Cloud Storage è una buona opzione se:

• I dati in ORC, Parquet, Avro o in qualsiasi altro formato verranno utilizzati da cluster o job diversi e sarà necessaria la persistenza dei dati se il cluster termina.
• Hai bisogno di una velocità effettiva elevata e i tuoi dati vengono archiviati in file di dimensioni superiori a 128 MB.
• Hai bisogno di una durabilità tra zone diverse per i tuoi dati.
• Devi disporre di dati ad alta disponibilità, ad esempio per eliminare l'HDFS NameNode come single point of failure.

L'archiviazione HDFS locale è una buona opzione se:

• I tuoi job richiedono molte operazioni sui metadati, ad esempio hai migliaia di partizioni e directory e ogni dimensione di file è relativamente piccola.
• Puoi modificare di frequente i dati HDFS o rinominare le directory. Gli oggetti Cloud Storage sono immutabili, pertanto la ridenominazione di una directory è un'operazione costosa, poiché consiste nel copiare tutti gli oggetti in una nuova chiave e in seguito eliminarli.
• Devi fare un uso intensivo dell'operazione di aggiunta sui file HDFS.

• Hai carichi di lavoro che comportano un I/O pesante. Ad esempio, hai molte scritture partizionate, come il seguente:

  spark.read().write.partitionBy(...).parquet("gs://")

• Hai carichi di lavoro di I/O particolarmente sensibili alla latenza. Ad esempio, richiedi una latenza di una sola cifra in millisecondi per operazione di archiviazione.

In generale, consigliamo di utilizzare Cloud Storage come origine iniziale e finale dei dati in una pipeline di big data. Ad esempio, se un flusso di lavoro contiene cinque job Spark in serie, il primo job recupera i dati iniziali da Cloud Storage e poi scrive i dati di shuffle e l'output del job intermedio in HDFS. Il job Spark finale scrive i risultati in Cloud Storage.

Regolare le dimensioni dello spazio di archiviazione

L'uso di Dataproc con Cloud Storage ti consente di ridurre i requisiti del disco e di risparmiare sui costi inserendo i dati al suo interno anziché nell'HDFS. Quando conservi i tuoi dati su Cloud Storage e non li archivi sull'HDFS locale, puoi usare dischi più piccoli per il tuo cluster. Creando il cluster effettivamente on demand, puoi anche separare l'archiviazione e il calcolo, come indicato in precedenza, per ridurre significativamente i costi.

Anche se memorizzi tutti i tuoi dati in Cloud Storage, il tuo cluster Dataproc ha bisogno di HDFS per determinate operazioni, come l'archiviazione dei file di controllo e di recupero o l'aggregazione dei log. Ha anche bisogno di spazio su disco locale non HDFS per eseguire shuffling. Puoi ridurre le dimensioni del disco per worker se non utilizzi in modo intensivo l'HDFS locale.

Ecco alcune opzioni per regolare le dimensioni dell'HDFS locale:

• Riduci le dimensioni totali dell'HDFS locale riducendo le dimensioni dei dischi permanenti principali per il master e i worker. Il disco permanente principale contiene anche il volume di avvio e le librerie di sistema, quindi alloca almeno 100 GB.
• Aumenta le dimensioni totali dell'HDFS locale aumentando le dimensioni del disco permanente principale per i worker. Valuta con attenzione questa opzione: è raro avere carichi di lavoro che ottengono prestazioni migliori utilizzando HDFS con dischi permanenti standard rispetto all'utilizzo di Cloud Storage o HDFS locale con SSD.
• Collega fino a otto SSD (375 GB ciascuna) a ciascun worker e utilizza questi dischi per l'HDFS. Questa è una buona opzione se hai bisogno di utilizzare l'HDFS per carichi di lavoro ad alta intensità di I/O e hai bisogno di una latenza di un millisecondo a una sola cifra. Assicurati di utilizzare un tipo di macchina con CPU e memoria sufficienti per il worker per supportare questi dischi.
• Utilizza SSD (SSD) a disco permanente per il master o i worker come disco primario.

Accesso a Dataproc

Accedere a Dataproc o Hadoop su Compute Engine è diverso dall'accesso a un cluster on-premise. Devi determinare le impostazioni di sicurezza e le opzioni di accesso alla rete.

Networking

Tutte le istanze VM di un cluster Dataproc richiedono una rete interna tra loro e richiedono porte aperte UDP, TCP e ICMP. Puoi consentire l'accesso al cluster Dataproc da indirizzi IP esterni utilizzando la configurazione di rete predefinita o utilizzando una rete VPC. Il cluster Dataproc avrà accesso in rete a tutti i servizi Google Cloud (bucket Cloud Storage, API e così via) in qualsiasi opzione di rete che utilizzi. Per consentire l'accesso di networking da o verso le risorse on-premise, scegli una configurazione di rete VPC e configura le regole firewall appropriate. Per maggiori dettagli, consulta la guida sulla configurazione della rete del cluster Dataproc e la sezione Accedere a YARN di seguito.

Gestione di identità e accessi

Oltre all'accesso alla rete, il cluster Dataproc ha bisogno di autorizzazioni per accedere alle risorse. Ad esempio, per scrivere dati in un bucket Cloud Storage, il cluster Dataproc deve avere accesso in scrittura al bucket. Per stabilire l'accesso puoi utilizzare i ruoli. Analizza il tuo codice Spark e trova tutte le risorse non Dataproc necessarie al codice e concedi i ruoli corretti all'account di servizio del cluster. Assicurati inoltre che gli utenti che creano modelli, job, operazioni e flussi di lavoro abbiano le autorizzazioni giuste.

Per ulteriori dettagli e best practice, consulta la documentazione di IAM.

Verificare le dipendenze di Spark e di altre librerie

Confronta la tua versione di Spark e delle versioni di altre librerie nell'elenco delle versioni ufficiale di Dataproc e cerca eventuali librerie non ancora disponibili. Ti consigliamo di utilizzare versioni di Spark supportate ufficialmente da Dataproc.

Se devi aggiungere librerie, puoi:

• Crea un'immagine personalizzata di un cluster Dataproc.
• Crea script di inizializzazione in Cloud Storage per il cluster. Puoi utilizzare gli script di inizializzazione per installare dipendenze aggiuntive, copiare i programmi binari e così via.
• Ricompila il tuo codice Java o Scala e pacchettizza tutte le dipendenze aggiuntive che non fanno parte della distribuzione di base come un "grasso jar" utilizzando Gradle, Maven, Sbt o un altro strumento.

Regola dimensioni cluster Dataproc

In qualsiasi configurazione del cluster, sia on-premise che nel cloud, le dimensioni del cluster sono fondamentali per le prestazioni dei job Spark. un job Spark senza risorse sufficienti sarà lento o non riuscito, soprattutto se non dispone di memoria esecutore sufficiente. Per consigli sugli aspetti da considerare per il dimensionamento di un cluster Hadoop, consulta la sezione sul ridimensionamento del cluster della guida alla migrazione a Hadoop.

Le seguenti sezioni descrivono alcune opzioni per le dimensioni del cluster.

Recupero della configurazione dei job Spark attuali

Controlla come sono configurati i tuoi job Spark attuali e assicurati che il cluster Dataproc sia abbastanza grande. Se passi da un cluster condiviso a più cluster Dataproc (uno per ogni carico di lavoro batch), esamina la configurazione YARN per ogni applicazione in modo da capire quanti esecutori hai bisogno, il numero di CPU per esecutore e la memoria totale degli esecutori. Se nel tuo cluster on-premise sono configurate code YARN, scopri quali job condividono le risorse di ogni coda e identifica i colli di bottiglia. Questa migrazione è un'opportunità per rimuovere eventuali restrizioni delle risorse presenti nel cluster on-premise.

Scelta dei tipi di macchina e delle opzioni del disco

Scegli il numero e il tipo di VM per soddisfare le esigenze del tuo carico di lavoro. Se hai deciso di utilizzare HDFS locale per l'archiviazione, assicurati che le VM dispongano del tipo e delle dimensioni del disco corretti. Non dimenticare di includere nel calcolo le esigenze relative alle risorse dei programmi dei driver.

Ogni VM ha un limite di traffico in uscita dalla rete di 2 Gbps per vCPU. La scrittura su dischi permanenti o su SSD permanenti viene conteggiata per questo limite, quindi una VM con un numero molto basso di vCPU potrebbe essere limitata dal limite quando scrive su questi dischi. È probabile che questo avvenga nella fase di shuffling, quando Spark scrive i dati di shuffle sul disco e li sposta sulla rete tra esecutori. I dischi permanenti richiedono almeno 2 vCPU per raggiungere le massime prestazioni di scrittura, mentre i dischi permanenti richiedono 4 vCPU. Tieni presente che questi valori minimi non tengono conto del traffico in uscita dalla rete, come la comunicazione tra le VM. Inoltre, le dimensioni di ogni disco influiscono sulle prestazioni di picco.

La configurazione scelta avrà un impatto sul costo del tuo cluster Dataproc. I prezzi di Dataproc si aggiungono al prezzo per istanza di Compute Engine per ogni VM e ad altre risorse Google Cloud. Per ulteriori informazioni e per utilizzare il Calcolatore prezzi di Google Cloud per una stima dei costi, consulta la pagina dei prezzi di Dataproc.

Benchmarking delle prestazioni e ottimizzazione

Al termine della fase di migrazione dei job, ma prima di interrompere l'esecuzione dei carichi di lavoro Spark nel cluster on-premise, confronta i job Spark e valuta eventuali ottimizzazioni. Ricorda che puoi ridimensionare il tuo cluster se la configurazione non è ottimale.

Scalabilità automatica Dataproc per Spark

Utilizza Dataproc Serverless (https://cloud.google.com/dataproc-serverless/docs/overview){: track-type="solution" track-name="internalLink" track-metadata-position="body" } per eseguire carichi di lavoro Spark senza eseguire il provisioning e gestire il tuo cluster. Specifica i parametri del carico di lavoro, quindi invia il carico di lavoro al servizio Dataproc Serverless. Il servizio eseguirà il carico di lavoro su un'infrastruttura di computing gestita, risorse di scalabilità automatica secondo necessità. Gli addebiti di Dataproc Serverless si applicano solo al momento in cui il carico di lavoro è in esecuzione.

Eseguire la migrazione

Questa sezione illustra la migrazione dei dati, la modifica del codice job e la modifica delle modalità di esecuzione dei job.

Migrazione dei dati

Prima di eseguire qualsiasi job Spark nel cluster Dataproc, devi migrare i dati a Google Cloud. Per ulteriori informazioni, consulta la Guida alla migrazione dei dati.

Esegui migrazione del codice Spark

Dopo aver pianificato la migrazione a Dataproc e spostato le origini dati richieste, puoi eseguire la migrazione del codice del job. Se non ci sono differenze nelle versioni di Spark tra i due cluster e se vuoi archiviare i dati su Cloud Storage anziché sull'HDFS locale, devi solo modificare il prefisso di tutti i percorsi dei file HDFS da hdfs:// a gs://.

Se utilizzi versioni Spark diverse, consulta le note di rilascio di Spark, confronta le due versioni e adatta il codice Spark di conseguenza.

Puoi copiare i file jar per le tue applicazioni Spark nel bucket Cloud Storage collegato al tuo cluster Dataproc o a una cartella HDFS. La sezione successiva spiega le opzioni disponibili per l'esecuzione dei job Spark.

Se decidi di utilizzare modelli di flusso di lavoro, ti consigliamo di testare separatamente ogni job Spark che prevedi di aggiungere. Dopodiché puoi eseguire un'ultima esecuzione di test del modello per assicurarti che il flusso di lavoro del modello sia corretto (non mancano job upstream, gli output sono archiviati nelle posizioni corrette e così via).

Eseguire job

Puoi eseguire job Spark nei seguenti modi:

• Utilizzando il seguente comando gcloud:

  gcloud dataproc jobs submit [COMMAND]

  dove:

  [COMMAND] è spark, pyspark o spark-sql

  Puoi impostare le proprietà Spark con l'opzione --properties. Per ulteriori informazioni, consulta la documentazione per questo comando.

• Utilizzando la stessa procedura utilizzata prima della migrazione del job a Dataproc. Il cluster Dataproc deve essere accessibile on-premise e devi utilizzare la stessa configurazione.

• Utilizzando Cloud Composer. Puoi creare un ambiente (un server Apache Airflow gestito), definire più job Spark come flusso di lavoro DAG, quindi eseguire l'intero flusso di lavoro.

Per ulteriori dettagli, consulta la guida Invia un job.

Gestione dei job dopo la migrazione

Dopo aver spostato i job Spark in Google Cloud, è importante gestirli utilizzando gli strumenti e i meccanismi forniti da Google Cloud. In questa sezione parleremo di logging, monitoraggio, accesso ai cluster, scalabilità dei cluster e ottimizzazione dei job.

Usa il logging e il monitoraggio delle prestazioni

In Google Cloud, puoi utilizzare Cloud Logging e Cloud Monitoring per visualizzare e personalizzare i log e monitorare job e risorse.

Il modo migliore per trovare l'errore che ha causato un errore del job Spark è esaminare l'output del driver e i log generati dagli esecutori di Spark.

Nota: se invii il job Spark connettendoti direttamente al nodo master tramite SSH, non è possibile ottenere l'output del driver.

Puoi recuperare l'output del programma del driver utilizzando la console Google Cloud o il comando gcloud. L'output è archiviato anche nel bucket Cloud Storage del cluster Dataproc. Per ulteriori dettagli, consulta la sezione sull'output del driver del job nella documentazione di Dataproc.

Nota: quando visualizzi l'output del programma del driver nella console Google Cloud, la barra di avanzamento viene archiviata come una lunga riga senza una nuova riga alla fine. Pertanto, la prima cosa che il programma del driver viene visualizzata alla fine di questa riga. Per visualizzare più facilmente questo output, puoi fare clic su A capo.

Tutti gli altri log si trovano in file diversi all'interno delle macchine del cluster. È possibile visualizzare i log di ciascun container dalla UI web dell'app Spark (o dal server di cronologia al termine del programma) nella scheda esecutori. Devi visualizzare ciascun container Spark per visualizzare ciascun log. Se scrivi i log o stampi in stdout o stderr nel codice dell'applicazione, i log vengono salvati nel reindirizzamento di stdout o stderr.

In un cluster Dataproc, YARN è configurato per raccogliere tutti questi log per impostazione predefinita e sono disponibili in Cloud Logging. Cloud Logging fornisce una visione consolidata e concisa di tutti i log, per non doverti dedicare alla navigazione tra i log dei container per trovare errori.

La figura seguente mostra la pagina Cloud Logging nella console Google Cloud. Puoi visualizzare tutti i log dal tuo cluster Dataproc selezionando il nome del cluster nel menu del selettore. Non dimenticare di espandere la durata nel selettore dell'intervallo di tempo.

Puoi ottenere i log da un'applicazione Spark filtrando per ID. Puoi ottenere l'ID applicazione dall'output del driver.

Creare e utilizzare le etichette

Per trovare i log più rapidamente, puoi creare e utilizzare le tue etichette per ciascun cluster o per ciascun job Dataproc. Ad esempio, puoi creare un'etichetta con la chiave env e il valore exploration e utilizzarla per il tuo job di esplorazione dei dati. Puoi quindi ottenere i log per tutte le creazione dei job di esplorazione filtrando con label:env:exploration in Cloud Logging. Tieni presente che questo filtro non restituirà tutti i log per questo job, ma solo i log di creazione delle risorse.

Imposta il livello di log

Puoi impostare il livello di log del driver utilizzando il seguente comando gcloud:

gcloud dataproc jobs submit hadoop --driver-log-levels

Puoi impostare il livello di log per il resto dell'applicazione dal contesto di Spark. Ecco alcuni esempi:

spark.sparkContext.setLogLevel("DEBUG")

Monitora job

Cloud Monitoring può monitorare CPU, disco, utilizzo della rete e risorse YARN del cluster. Puoi creare una dashboard personalizzata per ottenere grafici aggiornati per queste e altre metriche. Dataproc viene eseguito su Compute Engine. Se vuoi visualizzare l'utilizzo della CPU, l'I/O del disco o le metriche di rete in un grafico, devi selezionare un'istanza VM di Compute Engine come tipo di risorsa e quindi filtrare in base al nome del cluster. Il seguente diagramma mostra un esempio dell'output.

Per visualizzare le metriche per query, job, fasi o attività Spark, connettiti all'interfaccia utente web dell'applicazione Spark. La sezione successiva spiega come farlo. Per i dettagli su come creare le metriche personalizzate, consulta la guida Custom Metrics from the Agent.

Accedi a YARN

Puoi accedere all'interfaccia web di Resource Manager YARN dall'esterno del cluster Dataproc configurando un tunnel SSH. È preferibile utilizzare il proxy SOCKS anziché il port forwarding locale, perché navigare nell'interfaccia web è più semplice in questo modo.

I seguenti URL sono utili per l'accesso tramite YARN:

• Resource Manager YARN: http://[MASTER_HOST_NAME]:8088

• Server di cronologia Spark: http://[MASTER_HOST_NAME]:18080

Se il cluster Dataproc ha solo indirizzi IP interni, puoi connetterti tramite una connessione VPN o un bastion host. Per ulteriori informazioni, consulta Scegliere un'opzione di connessione per le VM solo per uso interno.

Scala e ridimensiona i cluster Dataproc

Il cluster Dataproc può essere scalato aumentando o diminuendo il numero di worker primari o secondari (prerilasciabili). Dataproc supporta anche il ritiro elegante.

Il downscaling in Spark è influenzato da una serie di fattori. Considera quanto segue:

• Non è consigliabile utilizzare ExternalShuffleService, in particolare se esegui il downgrade periodico del cluster. Il shuffling utilizza i risultati scritti nel disco locale del worker dopo l'esecuzione della fase di computing, quindi non è possibile rimuovere il nodo anche se le risorse di computing non vengono più utilizzate.

• Spark cache i dati in memoria (sia RDD che set di dati) ed esecutori utilizzati per la memorizzazione nella cache non escono mai. Di conseguenza, se un worker viene utilizzato per la memorizzazione nella cache, non verrà mai ritirato. La rimozione forzata dei worker influenzerebbe notevolmente le prestazioni complessive, in quanto i dati memorizzati nella cache andrebbero persi.

• L'allocazione dinamica dei flussi di dati è disattivata per impostazione predefinita e la chiave di configurazione che imposta questo comportamento non è documentata. Puoi seguire una discussione sul comportamento di allocazione dinamica in un thread dei problemi di Spark. Se utilizzi Spark Streaming o Spark Structured Streaming, devi anche disattivare esplicitamente l'allocazione dinamica come descritto in precedenza in Identificare i tipi di job e i cluster di piano.

In generale, consigliamo di evitare il scale down di un cluster Dataproc se esegui carichi di lavoro in batch o in flussi.

Ottimizzazione del rendimento

Questa sezione illustra alcuni modi per ottenere prestazioni migliori e ridurre i costi durante l'esecuzione dei job Spark.

Gestire le dimensioni dei file di Cloud Storage

Per ottenere prestazioni ottimali, suddividi i dati in Cloud Storage in file con dimensioni comprese tra 128 MB e 1 GB. L'utilizzo di grandi file di piccole dimensioni può creare un collo di bottiglia. Se hai molti file di piccole dimensioni, valuta la possibilità di copiare i file per l'elaborazione nell'HDFS locale, quindi copia i risultati.

Passa ai dischi SSD

Se esegui molte operazioni di shuffling o scritture partizionate, passa alle unità SSD per migliorare le prestazioni.

Posiziona le VM nella stessa zona

Per ridurre i costi di networking e aumentare le prestazioni, utilizza la stessa località a livello di regione per i bucket Cloud Storage che utilizzi per i cluster Dataproc.

Per impostazione predefinita, quando utilizzi endpoint Dataproc globali o a livello di area geografica, le VM del cluster vengono posizionate nella stessa zona (o in un'altra zona della stessa area geografica con capacità sufficiente) al momento della creazione del cluster. Puoi anche specificare la zona quando viene creato il cluster.

Utilizzo di VM prerilasciabili

Il cluster Dataproc può utilizzare istanze VM prerilasciabili come worker. Il risultato è una riduzione dei costi di calcolo orari per i carichi di lavoro non critici rispetto all'uso delle istanze normali. Tuttavia, devi tenere in considerazione alcuni fattori quando utilizzi le VM prerilasciabili:

• Le VM prerilasciabili non possono essere utilizzate per l'archiviazione HDFS.
• Per impostazione predefinita, le VM prerilasciabili vengono create con un disco di avvio di dimensioni inferiori e ti consigliamo di eseguire l'override di questa configurazione se esegui carichi di lavoro di sovraccarico. Per i dettagli, consulta la pagina sulle VM prerilasciabili nella documentazione di Dataproc.
• Non è consigliabile rendere prerilasciabile più della metà dei worker totali.

• Quando utilizzi VM prerilasciabili, consigliamo di modificare la configurazione del cluster in modo che sia più tollerante agli errori delle attività, poiché le VM potrebbero essere meno disponibili. Ad esempio, configura impostazioni come le seguenti nella configurazione YARN:

  yarn.resourcemanager.am.max-attempts
  mapreduce.map.maxattempts
  mapreduce.reduce.maxattempts
  spark.task.maxFailures
  spark.stage.maxConsecutiveAttempts

• Puoi aggiungere o rimuovere facilmente le VM prerilasciabili dal tuo cluster. Per ulteriori dettagli, consulta VM prerilasciabili.

Passaggi successivi

• Consulta la guida su come eseguire la migrazione dell'infrastruttura Hadoop on-premise a Google Cloud.
• Consulta la nostra descrizione di Life of a Dataproc Job.
• Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Dai un'occhiata al nostro Centro di architettura cloud.