Migrazione di job Apache Spark a Dataproc

Questo documento descrive come spostare i job di Apache Spark in Dataproc. Il documento è destinato a data engineer e architetti di big data. e tratta argomenti quali le considerazioni relative a migrazione, preparazione, migrazione del lavoro e gestione.

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 supportato da Google Cloud. Consente di separare archiviazione e calcolo per 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 di un cluster Hadoop o Spark autonomamente. Tuttavia, tieni presente che le opzioni diverse dall'utilizzo di Dataproc sono autogestite e hanno solo il supporto della community.

Pianificazione della migrazione

Esistono 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 considerare attentamente il carico di lavoro e prepararti alla migrazione. In questa sezione delineiamo le considerazioni da tenere in considerazione e i preparativi da intraprendere prima di eseguire la migrazione dei job Spark.

Identificare i tipi di prestazioni e pianificare i cluster

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

Job batch pianificati regolarmente

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

Puoi implementare job batch con i 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 job su un cluster Dataproc dedicato, potrebbe essere utile disattivare l'allocazione dinamica e il servizio di shuffle esterno. Il seguente comando gcloud mostra le proprietà di configurazione Spark che vengono 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 tuo job utilizzando una chiamata API o un comando gcloud). Ad esempio:

    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 che il job è stato eseguito utilizzando una chiamata API o un comando gcloud.

Job di streaming

Per i job di flusso, devi creare un cluster Dataproc a lunga esecuzione e configurare il cluster in modo che venga eseguito in modalità ad alta disponibilità. In questo caso, non è consigliabile utilizzare VM prerilasciabili.

Carichi di lavoro ad hoc o interattivi inviati dagli utenti

Tra i carichi di lavoro ad hoc possono essere inclusi utenti che scrivono query o eseguono job di analisi nel corso della giornata.

In questi casi, devi decidere se eseguire il cluster in modalità ad alta disponibilità, se utilizzare le VM prerilasciabili e le modalità di gestione dell'accesso al cluster. Puoi pianificare la creazione e la terminazione del cluster (ad esempio, se non hai mai bisogno del cluster durante la notte o nei fine settimana) e puoi implementare la scalabilità di scale up e scale down in base alla pianificazione.

Identifica origini dati e dipendenze

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

  • Migrazione passo passo di tutte le origini dati in Google Cloud. All'inizio è utile eseguire il mirroring dell'origine dati in Google Cloud in modo che sia accessibile in due punti.

  • Migrazione job-by-job dei tuoi carichi di lavoro Spark in Google Cloud non appena viene eseguita la migrazione delle origini dati corrispondenti. Come con i dati, in un determinato momento potresti avere due carichi di lavoro in esecuzione in parallelo sia nel tuo vecchio ambiente che 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.

  • La chiusura dei job Spark nel vecchio ambiente dopo che tutti i team dipendenti hanno confermato di non richiedere 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 puoi 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

Su 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. Per accedere ai dati, puoi utilizzare 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 tuoi dati in ORC, Parquet, Avro o 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 per i tuoi dati.
  • Hai bisogno di dati a disponibilità elevata, ad esempio vuoi eliminare NameNode dell'HDFS come single point of failure.

L'archiviazione HDFS locale è una buona opzione se:

  • I tuoi job richiedono molte operazioni sui metadati, ad esempio migliaia di partizioni e directory e ogni dimensione di file è relativamente piccola.
  • Puoi modificare i dati HDFS di frequente o rinominare le directory. Gli oggetti Cloud Storage sono immutabili, quindi la ridenominazione di una directory è un'operazione costosa perché consiste nel copiare tutti gli oggetti in una nuova chiave ed eliminarli successivamente.
  • Utilizzi fortemente l'operazione di aggiunta nei file HDFS.
  • Hai carichi di lavoro che richiedono un elevato I/O. Ad esempio, hai molte scritture partizionate, come le seguenti:

    spark.read().write.partitionBy(...).parquet("gs://")
  • Hai carichi di lavoro I/O particolarmente sensibili alla latenza. Ad esempio, hai bisogno di una latenza di un millisecondo a una cifra per ogni 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 nella serie, il primo job recupera i dati iniziali da Cloud Storage e poi scrive i dati in ordine casuale e l'output del job intermedio in HDFS. Il job Spark finale scrive i risultati in Cloud Storage.

Regola 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 tuoi dati invece che nell'HDFS. Quando conservi i tuoi dati su Cloud Storage e non li archivi sull'HDFS locale, puoi utilizzare dischi più piccoli per il tuo cluster. Rendendo il tuo cluster davvero on demand, potrai anche separare archiviazione e calcolo, come indicato in precedenza, in modo da ridurre notevolmente 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 di file di controllo e ripristino o l'aggregazione dei log. Richiede inoltre spazio su disco non HDFS locale per l'ordinamento dei contenuti. Puoi ridurre la dimensione del disco per worker se non utilizzi in modo massiccio l'HDFS locale.

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

  • Riduci le dimensioni totali dell'HDFS locale diminuendo 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 dell'HDFS locale aumentando le dimensioni del disco permanente principale per i worker. Valuta con attenzione questa opzione: è raro che ci siano carichi di lavoro che ottengono prestazioni migliori utilizzando HDFS con dischi permanenti standard rispetto a Cloud Storage o HDFS locale con SSD.
  • Collega fino a otto SSD (375 GB ciascuna) a ciascun worker e utilizza questi dischi per la HDFS. Questa è una buona opzione se hai bisogno di utilizzare l'HDFS per carichi di lavoro ad alta intensità di I/O e la latenza di un millisecondo a una sola cifra. Assicurati di utilizzare un tipo di macchina con CPU e memoria sufficienti sul worker per supportare questi dischi.
  • Utilizza SSD (SSD) permanenti per il master o i worker come disco primario.

Accedere 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 l'utilizzo di una rete VPC. Il cluster Dataproc avrà accesso di rete a tutti i servizi Google Cloud (bucket Cloud Storage, API e così via) in qualsiasi opzione di rete utilizzata. Per consentire l'accesso di rete a o da risorse on-premise, scegli una configurazione di rete VPC e configura le regole firewall appropriate. Per maggiori dettagli, consulta la sezione sulla configurazione della rete di cluster Dataproc e la sezione Accedere a YARN di seguito.

Gestione di identità e accessi

Oltre all'accesso di rete, il cluster Dataproc deve disporre delle 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. Puoi stabilire l'accesso utilizzando 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 cluster, job, operazioni e modelli di flusso di lavoro dispongano delle autorizzazioni corrette.

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 quella di altre librerie con l'elenco delle versioni ufficiale di Dataproc e cerca le librerie non ancora disponibili. Ti consigliamo di utilizzare versioni Spark ufficialmente supportate da Dataproc.

Se devi aggiungere librerie, puoi procedere come segue:

  • 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 codice Java o Scala e pacchettizza tutte le dipendenze aggiuntive che non fanno parte della distribuzione di base come "fat jar" utilizzando Gradle, Maven, Sbt o un altro strumento.

Regola dimensioni cluster Dataproc

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

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

Recupero della configurazione dei job Spark correnti

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), osserva la configurazione YARN per ciascuna applicazione, in modo da comprendere 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 individua i colli di bottiglia. Questa migrazione è un'opportunità per rimuovere eventuali restrizioni applicate alle risorse nel cluster on-premise.

Scelta dei tipi di macchina e delle opzioni di disco

Scegli il numero e il tipo di VM per soddisfare le esigenze del tuo carico di lavoro. Se hai deciso di utilizzare HDFS locali per l'archiviazione, assicurati che le VM dispongano del tipo e della dimensione del disco corretti. Non dimenticare di includere nel calcolo le esigenze in termini di risorse dei programmi di driver.

Ogni VM ha un limite di traffico di rete in uscita di 2 Gbps per vCPU. La scrittura su dischi permanenti o su dischi permanenti conteggia per questo limite, quindi una VM con un numero molto basso di vCPU potrebbe essere limitata dal limite quando scrive su questi dischi. Questo accade probabilmente nella fase di riproduzione casuale, quando Spark scrive i dati in ordine casuale su disco e li trasferisce sulla rete tra gli esecutori. I dischi permanenti richiedono almeno 2 vCPU per raggiungere le massime prestazioni in scrittura, mentre gli SSD 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 che scegli 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 di 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

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

Eseguire la migrazione

Questa sezione illustra la migrazione dei dati, la modifica del codice del job e la modifica del modo in cui vengono eseguiti i job.

Migrazione dei dati

Prima di eseguire qualsiasi job Spark nel tuo cluster Dataproc, devi eseguire la migrazione dei tuoi dati in 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 una delle origini dati richieste, puoi eseguire la migrazione del codice del job. Se non ci sono differenze nelle versioni 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 di Spark diverse, consulta le note di rilascio di Spark, confronta le due versioni e adatta il codice di Spark di conseguenza.

Puoi copiare i file jar per le tue applicazioni Spark nel bucket Cloud Storage associato al cluster Dataproc o a una cartella HDFS. La prossima sezione 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. Quindi puoi eseguire un'esecuzione di test finale del modello per assicurarti che il flusso di lavoro del modello sia corretto (nessun job a monte mancante, gli output sono archiviati nelle località corrette e così via).

Esegui job

Puoi eseguire i 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 di eseguire la migrazione del job a Dataproc. Il cluster Dataproc deve essere accessibile da 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.

Utilizza il logging e il monitoraggio delle prestazioni

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

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

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

Tutti gli altri log si trovano in file diversi all'interno delle macchine del cluster. È possibile visualizzare i log per ciascun container dall'interfaccia utente web dell'app Spark (o dal server di cronologia al termine del programma) nella scheda esecutori. Devi esplorare ogni 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 offre una visualizzazione consolidata e concisa di tutti i log, così non devi dedicare tempo a sfogliare i log dei container per trovare errori.

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

Pagina di Cloud Logging nella console

Puoi ottenere i log da un'applicazione Spark filtrando in base all'ID. Puoi recuperare l'ID applicazione dall'output del driver.

Creare e utilizzare le etichette

Per trovare i log più velocemente, puoi creare e utilizzare le tue etichette per ogni cluster o per ogni 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 creazioni 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 quelli 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 Spark. Ad esempio:

spark.sparkContext.setLogLevel("DEBUG")

Monitora job

Cloud Monitoring può monitorare le risorse di CPU, disco, utilizzo di rete e YARN del cluster. Puoi creare una dashboard personalizzata per ricevere 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.

Pagina di monitoraggio nella console

Per visualizzare le metriche relative a query, job, fasi o attività Spark, connettiti all'interfaccia utente web dell'applicazione Spark. Nella sezione seguente è spiegato come eseguire questa operazione. Per i dettagli su come creare metriche personalizzate, consulta la guida Metriche personalizzate dall'agente.

Accedi a YARN

Puoi accedere all'interfaccia web del gestore di risorse YARN dall'esterno del cluster Dataproc configurando un tunnel SSH. È preferibile utilizzare il proxy SOCKS leggero anziché il port forwarding locale, perché la navigazione tramite l'interfaccia web è più semplice in questo modo.

I seguenti URL sono utili per l'accesso YARN:

  • Gestore risorse 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 tramite un bastion host. Per scoprire di più, consulta Connessione a istanze che non hanno indirizzi IP esterni.

Scalabilità e ridimensionamento dei cluster Dataproc

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

Il scale down di Spark è influenzato da diversi fattori. Considera quanto segue:

  • Sconsigliamo di utilizzare ExternalShuffleService, soprattutto se esegui il downgrade del cluster periodicamente. Il riordinamento utilizza i risultati che sono stati scritti sul disco locale del worker dopo l'esecuzione della fase di calcolo, quindi il nodo non può essere rimosso anche se le risorse di calcolo non vengono più utilizzate.

  • Memorizza nella cache i dati in memoria (sia RDD sia set di dati) ed esecutori utilizzati per la memorizzazione nella cache non si discostano mai. Di conseguenza, se un worker viene utilizzato per la memorizzazione nella cache, non verrà mai disattivato. La rimozione forzata dei worker avrebbe influito negativamente sulle prestazioni complessive, perché i dati memorizzati nella cache andrebbero persi.

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

In generale, ti consigliamo di evitare il scale down di un cluster Dataproc se stai eseguendo carichi di lavoro in modalità batch o flusso.

Ottimizzazione del rendimento

Questa sezione illustra i modi per ottenere prestazioni migliori e ridurre i costi durante l'esecuzione di 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 molti 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 e poi copia i risultati.

Passa ai dischi SSD

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

Colloca le VM nella stessa zona

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

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

Utilizzo di VM prerilasciabili

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

  • 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 potresti voler eseguire l'override di questa configurazione se esegui carichi di lavoro pesanti. Per maggiori dettagli, consulta la pagina sulle VM prerilasciabili nella documentazione di Dataproc.
  • Sconsigliamo di rendere prerilasciabile più della metà dei lavoratori totali.
  • Quando utilizzi VM prerilasciabili, consigliamo di modificare la configurazione del cluster in modo che sia più tollerante agli errori delle attività, perché le VM potrebbero essere meno disponibili. Nella configurazione YARN, ad esempio, puoi configurare impostazioni come le seguenti:

    yarn.resourcemanager.am.max-attempts
    mapreduce.map.maxattempts
    mapreduce.reduce.maxattempts
    spark.task.maxFailures
    spark.stage.maxConsecutiveAttempts
  • Puoi facilmente aggiungere o rimuovere VM prerilasciabili dal cluster. Per maggiori dettagli, consulta la pagina relativa alle VM prerilasciabili.

Passaggi successivi