Como migrar jobs do Apache Spark para o Dataproc

Neste documento, descrevemos como mover jobs do Apache Spark para o Dataproc. Este documento é destinado a arquitetos e engenheiros de Big Data. Abordamos tópicos como a migração, preparação, migração de jobs e gerenciamento.

Observação: as informações e recomendações contidas neste documento foram coletadas em campo, com a colaboração de vários clientes e em diversos ambientes Agradecemos nossos clientes e parceiros por compartilhar suas experiências e ideias.

Informações gerais

Quando você quer mover as cargas de trabalho do Apache Spark de um ambiente local para o Google Cloud, recomendamos usar o Dataproc para executar clusters do Apache Spark/Apache Hadoop. O Dataproc é um serviço totalmente gerenciado e totalmente compatível oferecido pelo Google Cloud. Com ele, você separa o armazenamento e a computação, o que ajuda a gerenciar seus custos e a ser mais flexível no escalonamento das cargas de trabalho.

Quando um ambiente do Hadoop gerenciado não atender às suas necessidades, você tem opções como usar uma configuração diferente, executar o Spark no Google Kubernetes Engine (GKE), alugar máquinas virtuais no Compute Engine ou configurar um cluster do Hadoop ou Spark por conta própria. No entanto, considere que outras opções além do Dataproc são autogerenciadas e têm suporte apenas da comunidade.

Como planejar a migração

Há muitas diferenças entre executar jobs do Spark no local e executar jobs do Spark em clusters do Dataproc ou do Hadoop no Compute Engine. É importante observar atentamente a carga de trabalho e se preparar para a migração. Nesta seção, você verá o que precisa ser levado em conta e o preparo a ser feito antes da migração dos jobs do Spark.

Identificar os tipos de jobs e planejar clusters

Há três tipos de cargas de trabalho do Spark, conforme descrito nesta seção.

Jobs em lote com programação regular

Os jobs em lote com programação regular incluem casos de uso como ETLs diários ou por hora ou pipelines para treinar modelos de machine learning com o Spark ML. Para esses casos, recomendamos que você crie um cluster para cada carga de trabalho em lote e exclua o cluster após a conclusão do job. Você conta com a flexibilidade de poder configurar o cluster, ajustando separadamente a configuração para cada carga de trabalho. Após o primeiro minuto, os clusters do Dataproc são cobrados em incrementos de blocos de um segundo. Portanto, essa abordagem também é econômica, porque permite rotular os clusters. Para mais informações, consulte a página Preços do Dataproc.

É possível implementar jobs em lote com modelos de fluxo de trabalho ou seguindo estas etapas:

1. Crie um cluster e aguarde até que ele seja concluído. Monitore a operação usando uma chamada de API ou um comando da ferramenta gcloud. Se você executar o job em um cluster dedicado do Dataproc, talvez seja útil desativar a alocação dinâmica e o serviço de reprodução aleatória. O comando gcloud a seguir mostra as propriedades de configuração do Spark fornecidas quando você cria o cluster do Dataproc:

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

2. Envie o job ao cluster. Monitore o status do job usando uma chamada de API ou um comando da ferramenta gcloud. Exemplo:

   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. Exclua o cluster após a execução do job usando uma chamada de API ou um comando gcloud.

Jobs de streaming

Para jobs de streaming, você precisa criar um cluster do Dataproc de longa duração e configurá-lo para ser executado no modo de alta disponibilidade. Não recomendamos o uso de VMs preemptivas neste caso.

Cargas de trabalho específicas ou interativas, enviadas por usuários

Nos exemplos de cargas de trabalho específicas, são incluídos usuários que escrevem consultas ou executam jobs analíticos durante o dia.

Nesses casos, você precisa decidir se o cluster será executado no modo de alta disponibilidade, se quer usar VMs preemptivas e como gerenciar o acesso ao cluster. É possível programar a criação e a finalização do cluster, como por exemplo, caso nunca precise do cluster durante a noite ou em fins de semana, além de implementar o dimensionamento de acordo com a programação.

Identificar origens de dados e dependências

Cada job tem as próprias dependências, por exemplo, as origens de dados necessárias. Talvez outras equipes da empresa dependam do resultado desses jobs. Portanto, identifique todas as dependências e crie um plano de migração que inclua procedimentos para:

• Migração passo a passo de todas as suas fontes de dados para o Google Cloud. No início, é útil espelhar a fonte de dados no Google Cloud para que você a tenha em dois lugares.

• Migração job-by-job das cargas de trabalho do Spark para o Google Cloud assim que as fontes de dados correspondentes forem migradas. Assim como acontece com os dados, em algum momento, é possível que você tenha duas cargas de trabalho em execução paralelamente no ambiente antigo e no Google Cloud.

• Migração de outras cargas de trabalho que dependam da saída das suas cargas de trabalho do Spark. Ou simples replicação da saída de volta ao ambiente inicial.

• Encerramento de jobs do Spark no ambiente antigo, após as equipes dependentes confirmarem que eles não são mais necessários.

Escolher opções de armazenamento

Há duas opções de armazenamento para usar com os clusters do Dataproc: é possível armazenar todos os dados no Cloud Storage ou usar discos locais ou discos permanentes com os workers do cluster. A escolha correta depende da característica dos jobs.

Comparação entre o Cloud Storage e o HDFS

Cada nó de um cluster do Dataproc tem um conector do Cloud Storage instalado. Por padrão, o conector é instalado em /usr/lib/hadoop/lib. Ele é usado na implementação da interface FileSystem do Hadoop, o que torna o Cloud Storage compatível com o HDFS.

Como o Cloud Storage é um sistema de armazenamento de objeto binário grande (BLOB, na sigla em inglês), o conector emula os diretórios de acordo com o nome do objeto. Acesse seus dados usando o prefixo gs:// em vez do prefixo hdfs://.

O conector do Cloud Storage geralmente não requer personalização. Caso precise fazer alterações, siga as instruções sobre como configurar o conector. Uma lista completa de chaves de configuração também está disponível.

O Cloud Storage é uma boa opção quando:

• os dados em ORC, Parquet, Avro ou qualquer outro formato são usados por diferentes clusters ou jobs. Se o cluster for encerrado, você precisará ter permanência de dados;
• você precisa de uma capacidade alta, e os dados são armazenados em arquivos com mais de 128 MB;
• você precisa de durabilidade entre zonas para seus dados;
• é preciso que os dados estejam altamente disponíveis. Por exemplo, você quer eliminar o NameNode do HDFS como único ponto de falha.

O armazenamento HDFS local é uma boa opção quando:

• os jobs exigirem muitas operações de metadados. Por exemplo, você tem milhares de partições e diretórios, e o tamanho de cada arquivo é relativamente pequeno;
• você modifica os dados do HDFS com frequência ou renomeia os diretórios. Os objetos do Cloud Storage são immutable, portanto, a renomeação de um diretório é uma operação cara, que se resume em copiar todos os objetos para uma nova chave e excluí-los em seguida;
• você usar intensamente a operação de adicionar ao final em arquivos HDFS;

• há cargas de trabalho que envolvem E/S intensas. Por exemplo, há muitas gravações particionadas, como estas:

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

• há cargas de trabalho de E/S especialmente sensíveis à latência. Por exemplo, você requer latência de um dígito em milissegundos por operação de armazenamento.

Em geral, recomendamos o uso do Cloud Storage como origem de dados inicial e final em um pipeline do Big Data. Por exemplo, se um fluxo de trabalho contém cinco jobs do Spark em série, o primeiro job recupera os dados iniciais do Cloud Storage e grava dados aleatoriamente e a saída do job intermediário no HDFS. O job final do Spark grava os resultados no Cloud Storage.

Ajustar o tamanho do armazenamento

Usar o Dataproc com o Cloud Storage permite reduzir os requisitos de disco e economizar custos colocando seus dados lá em vez de no HDFS. Quando você mantém seus dados no Cloud Storage e não os armazena no HDFS local, pode usar discos menores para o cluster. Ao tornar seu cluster realmente sob demanda, você também separa o armazenamento e a computação, como observado anteriormente, o que reduz os custos de forma significativa.

Mesmo que você armazene todos os dados no Cloud Storage, o cluster do Dataproc precisa do HDFS para determinadas operações, como armazenamento de arquivos de controle e recuperação ou agregação de registros. Ele também precisará de espaço em disco local não HDFS para reprodução aleatória. Reduza o tamanho do disco por worker caso não esteja usando muito o HDFS local.

Estas são algumas opções para ajustar o tamanho do HDFS local:

• Reduza o tamanho total do HDFS local com a diminuição do tamanho dos discos permanentes principais para o mestre e os workers. O volume de inicialização e as bibliotecas do sistema também estão presentes nestes discos, portanto, aloque pelo menos 100 GB.
• Aumente o tamanho total do HDFS local com o aumento do tamanho do disco permanente principal para os workers. Avalie essa opção com cuidado. É raro que as cargas de trabalho tenham um desempenho melhor usando o HDFS com discos permanentes padrão em vez do Cloud Storage ou do HDFS local com SSD.
• Anexe até oito SSDs (375 GB cada) a cada worker e use esses discos para o HDFS. Essa é uma boa opção se você precisar usar o HDFS para cargas de trabalho com uso intensivo de E/S e precisar de latência de milissegundos de um dígito. Verifique se está sendo usado um tipo de máquina que tenha CPUs e memória suficientes no worker para comportar estes discos.
• Use SSDs de disco permanente (PD-SSDs) para o mestre ou os workers como disco principal.

Acessar o Dataproc

O acesso ao Dataproc ou ao Hadoop no Compute Engine é diferente do acesso a um cluster local. É preciso determinar as configurações de segurança e as opções de acesso à rede.

Rede

Todas as instâncias de VM de um cluster do Dataproc requerem rede interna entre si e as portas UDP, TCP e ICMP abertas. É possível permitir o acesso ao cluster do Dataproc de endereços IP externos usando a configuração de rede padrão ou uma rede VPC. Seu cluster do Dataproc terá acesso de rede a todos os serviços do Google Cloud (buckets do Cloud Storage, APIs etc.) em qualquer opção de rede usada. Para permitir o acesso de rede de ou para recursos locais, escolha uma configuração de rede VPC e configure as regras de firewall apropriadas. Para detalhes, consulte o guia Configuração de rede do cluster do Dataproc e a seção Acessar o YARN abaixo.

Gerenciamento de identidade e acesso

Além do acesso à rede, o cluster do Dataproc precisa de permissões para acessar recursos. Por exemplo, para gravar dados em um bucket do Cloud Storage, o cluster do Dataproc precisa ter acesso de gravação ao bucket. O acesso é estabelecido com o uso de papéis. Verifique seu código Spark e encontre todos os recursos que não são do Dataproc necessários e conceda os papéis corretos à conta de serviço do cluster. Além disso, verifique se foram concedidas as permissões corretas aos usuários que criarão clusters, jobs, operações e modelos de fluxo de trabalho.

Para mais detalhes e práticas recomendadas, consulte a documentação do IAM.

Verificar o Spark e outras dependências da biblioteca

Compare sua versão do Spark e as versões de outras bibliotecas com a lista das versões oficial do Dataproc e procure bibliotecas que ainda não estejam disponíveis. Recomendamos que você use versões do Spark oficialmente compatíveis com o Dataproc.

Caso seja preciso adicionar bibliotecas, faça o seguinte:

• Crie uma imagem personalizada de um cluster do Dataproc.
• Crie scripts de inicialização no Cloud Storage para o cluster. É possível usar scripts de inicialização para instalar outras dependências, copiar binários e assim por diante.
• Recompile o código Java ou Scala e empacote todas as outras dependências que não fizerem parte da distribuição básica como "fat jar" usando o Gradle, o Maven, o Sbt ou outra ferramenta.

Ajustar o tamanho do cluster do Dataproc

Em qualquer configuração de cluster, seja no local ou na nuvem, o tamanho do cluster é crucial para o desempenho do job do Spark. Um job do Spark, que não tenha recursos suficientes, será lento ou falhará, especialmente quando não tiver memória de executor suficiente. Para receber orientações sobre o que é preciso considerar ao dimensionar qualquer cluster do Hadoop, consulte a seção dimensionamento do cluster no guia de migração do Hadoop.

Nas próximas seções, mostraremos algumas opções para dimensionar o cluster.

Como receber a configuração de jobs atuais do Spark

Veja como os jobs atuais do Spark estão configurados e verifique se o cluster do Dataproc é grande o suficiente. Se você passar de um cluster compartilhado para vários clusters do Dataproc (um para cada carga de trabalho em lote), observe a configuração YARN de cada aplicativo para entender quantos executores são necessários, o número de CPUs por executor e a memória total do executor. Se as filas do YARN do cluster local estiverem configuradas, veja quais tarefas estão compartilhando os recursos de cada fila e identifique gargalos. Essa migração é a oportunidade de remover quaisquer restrições de recursos que você tiver no cluster local.

Como escolher os tipos de máquinas e opções de disco

Escolha o número e o tipo de VMs para atender às necessidades da sua carga de trabalho. Caso tenha decidido usar o HDFS local para armazenamento, verifique se as VMs têm o tipo e o tamanho de disco corretos. Não esqueça de incluir no cálculo as necessidades de recursos dos programas de driver.

Cada VM tem um limite de saída de rede de 2 Gbps por vCPU. A gravação em discos permanentes ou em SSDs permanentes é contabilizada nesse limite. Portanto, uma VM com um número muito baixo de vCPUs pode ser limitada pelo limite ao gravar nesses discos. É provável que isso aconteça na fase de reprodução aleatória, quando o Spark grava os dados aleatoriamente no disco e move esses dados pela rede entre os executores. Os discos permanentes requerem pelo menos 2 vCPUs para atingir o máximo desempenho de gravação e os SSDs permanentes, 4 vCPUs. Esses mínimos não consideram o tráfego, como a comunicação entre VMs. Além disso, o tamanho de cada disco afeta o desempenho máximo.

A configuração escolhida terá influência sobre o custo do cluster do Dataproc. O preço do Dataproc é adicionado ao preço por instância do Compute Engine para cada VM e outros recursos do Google Cloud. Para mais informações e para usar a calculadora de preços do Google Cloud para ter uma estimativa dos custos, consulte a página de preços do Dataproc.

Desempenho de comparativo de mercado e otimização

Ao terminar a fase de migração do job, mas antes de parar a execução das cargas de trabalho do Spark no cluster local, faça um comparativo de mercado dos jobs do Spark e leve em conta todas as otimizações. Lembre-se de que é possível redimensionar o cluster caso a configuração não seja a ideal.

Dataproc sem servidor para escalonamento automático do Spark

Use o Dataproc sem servidor para executar cargas de trabalho do Spark sem provisionar nem gerenciar o próprio cluster. Especifique parâmetros de carga de trabalho e envie a carga de trabalho para o serviço sem servidor do Dataproc. O serviço executará a carga de trabalho em uma infraestrutura de computação gerenciada, fazendo o escalonamento automático dos recursos conforme necessário. As cobranças sem servidor do Dataproc se aplicam somente ao momento em que a carga de trabalho está em execução.

Como executar a migração

Nesta seção, tratamos da migração dos dados, da alteração do código do job e da alteração do modo de execução dos jobs.

Migrar dados

Antes de executar qualquer job do Spark no cluster do Dataproc, é necessário migrar os dados para o Google Cloud. Para mais informações, consulte o Guia de migração de dados.

Migrar o código do Spark

Depois de planejar a migração para o Dataproc e mover as fontes de dados necessárias, será possível migrar o código do job. Se não houver diferenças nas versões do Spark entre os dois clusters e se você quiser armazenar dados no Cloud Storage em vez do HDFS local, basta alterar o prefixo de todos os caminhos do arquivo HDFS de hdfs:// para gs://.

Se você estiver usando diferentes versões do Spark, consulte as Notas de lançamento do Spark, compare as duas versões e adapte o código do Spark de forma adequada.

É possível copiar os arquivos jar dos aplicativos Spark para o bucket do Cloud Storage vinculado ao cluster do Dataproc ou a uma pasta HDFS. Na próxima seção, explicaremos as opções disponíveis para executar jobs do Spark.

Se você decidir usar modelos de fluxo de trabalho, recomendamos testar separadamente cada job do Spark que planeja adicionar. Em seguida, execute um teste final do modelo para garantir que o fluxo de trabalho do modelo esteja correto, sem perder os jobs de upstream, as saídas armazenadas nos locais corretos e assim por diante.

Executar jobs

A seguir, veja algumas maneiras possíveis de executar jobs do Spark:

• Usando o seguinte comando gcloud:

  gcloud dataproc jobs submit [COMMAND]

  em que:

  [COMMAND] é spark, pyspark ou spark-sql

  Defina as propriedades do Spark com a opção --properties. Para mais informações, consulte a documentação deste comando.

• Usando o mesmo processo usado antes de migrar o job para o Dataproc. O cluster do Dataproc precisa estar acessível no local, e você precisa usar a mesma configuração.

• Com o Cloud Composer. É possível criar um ambiente, ou seja, um servidor do Apache Airflow gerenciado, definir vários jobs do Spark como fluxo de trabalho do DAG e, em seguida, executar o fluxo de trabalho inteiro.

Para mais detalhes, consulte o guia Enviar um job.

Como gerenciar jobs após a migração

Depois de mover os jobs do Spark para o Google Cloud, é importante gerenciá-los usando as ferramentas e os mecanismos fornecidos pelo Google Cloud. Nesta seção, discutiremos a geração de registros, o monitoramento, o acesso a clusters, o escalonamento de clusters e a otimização de jobs.

Usar a geração de registros e o monitoramento do desempenho

No Google Cloud, o Cloud Logging e o Cloud Monitoring podem ser usados para visualizar e personalizar registros, assim como para monitorar jobs e recursos.

A melhor maneira de localizar o erro que causou falha no job do Spark é examinar a saída do driver e os registros gerados pelos executores do Spark.

Observação: o enviar o job do Spark por conexão direta ao nó mestre usando SSH, não será possível atingir a saída do driver.

Recupere a saída do programa de driver usando o Console do Google Cloud ou um comando gcloud. A saída também é armazenada no bucket do Cloud Storage do cluster do Dataproc. Para mais detalhes, consulte a seção sobre saída do driver do job na documentação do Dataproc.

Observação: quando você visualiza a saída do programa do driver no Console do Google Cloud, a barra de progresso é armazenada como uma linha longa sem uma nova linha no final. Portanto, a primeira coisa que o programa do driver imprimir aparecerá no final desta linha. Para visualizar essa saída com mais facilidade, clique em quebra de linha.

Todos os outros registros estão localizados em arquivos diferentes dentro das máquinas do cluster. É possível ver os registros de cada contêiner na IU da Web do aplicativo Spark ou do History Server, após o término do programa, na guia de executores. Para visualizar cada registro, é preciso navegar por cada contêiner do Spark. Se você gravar registros ou imprimir em stdout ou stderr no código do aplicativo, os registros serão salvos no redirecionamento de stdout ou stderr.

Em um cluster do Dataproc, o YARN é configurado para coletar todos esses registros por padrão e eles estão disponíveis no Cloud Logging. O Cloud Logging fornece uma visualização consolidada e concisa de todos os registros para que você não precise gastar tempo navegando entre os registros de contêiner para encontrar erros.

A figura a seguir mostra a página do Cloud Logging no Console do Google Cloud. Para ver todos os registros do cluster do Dataproc, selecione o nome do cluster no menu do seletor. Não esqueça de aumentar a duração no seletor de intervalo de tempo.

É possível acessar registros de um aplicativo Spark, filtrando pelo código correspondente que você consegue na saída do driver.

Criar e usar rótulos

Para encontrar registros com mais rapidez crie e use rótulos próprios para cada cluster ou para cada job do Dataproc. Por exemplo, é possível criar um rótulo com a chave env e o valor exploration e usá-lo para o job de exploração de dados. Em seguida, é possível receber registros de todas as criações de jobs de exploração filtrando com label:env:exploration no Cloud Logging. Observe que este filtro não retornará todos os registros deste job, apenas os de criação de recursos.

Configurar o nível do registro

É possível configurar o nível do registro do driver com o seguinte comando gcloud:

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

Configure o nível de registro para o restante do aplicativo no contexto do Spark. Exemplo:

spark.sparkContext.setLogLevel("DEBUG")

Monitorar jobs

O Cloud Monitoring pode monitorar a CPU, o disco, o uso da rede e os recursos YARN do cluster. Crie um painel personalizado para acessar gráficos atualizados para essas e outras métricas. O Dataproc é executado no Compute Engine. Para visualizar o uso da CPU, E/S de disco ou métricas de rede em um gráfico, selecione uma instância de VM do Compute Engine como tipo de recurso e filtre pelo nome do cluster. O diagrama abaixo mostra um exemplo da saída.

Para visualizar métricas de consultas, jobs, estágios ou tarefas do Spark, conecte-se à IU da Web do aplicativo Spark. A próxima seção explica como fazer isso. Para saber detalhes sobre como criar métricas personalizadas, consulte o guia Métricas personalizadas do agente.

Acessar o YARN

Acesse a interface da Web do gerenciador de recursos YARN fora do cluster do Dataproc configurando um túnel SSH. É melhor usar o proxy leve SOCKS do que o encaminhamento de portas local, porque isso facilita a navegação pela interface da Web.

Veja a seguir os URLs que são úteis para o acesso YARN:

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

• Servidor de histórico do Spark: http://[MASTER_HOST_NAME]:18080

Caso o cluster do Dataproc tenha apenas endereços IP internos, conecte-se por meio de uma conexão VPN ou de um host Bastion. Para mais informações, consulte Escolher uma opção de conexão para VMs somente internas.

Escalonar e redimensionar clusters do Dataproc

O cluster do Dataproc pode ser escalonado aumentando ou diminuindo o número de workers principais ou secundários (preemptivos). O Dataproc também é compatível com a desativação otimizada.

No Spark, a redução da necessidade de escalonamento é afetada por diversos fatores. Leve em conta o seguinte:

• Não recomendamos o uso de ExternalShuffleService, especialmente se você reduzir o cluster periodicamente. A reprodução aleatória usa os resultados gravados no disco local do worker após a fase de computação ter sido executada. Por isso, não há como o nó ser removido, mesmo que os recursos de computação não sejam mais consumidos.

• O Spark armazena em cache os dados em memória (RDDs e conjuntos de dados), e os executores usados para armazenamento em cache nunca saem. Portanto, caso um worker seja usado para armazenamento em cache, a desativação otimizada nunca será feita de maneira adequada. A remoção de workers à força influenciaria o desempenho geral, porque os dados armazenados em cache seriam perdidos.

• O Spark Streaming tem a alocação dinâmica desativada por padrão, e a chave de configuração que define esse comportamento não é documentada. Siga uma discussão sobre o comportamento de alocação dinâmica em uma conversa sobre problemas do Spark. Para usar o Spark Streaming ou o Spark Structured Streaming, também é preciso desativar explicitamente a alocação dinâmica (em inglês), conforme discutido anteriormente em Identificar tipos de jobs e planejar clusters.

Em geral, recomendamos que você evite reduzir a necessidade de fazer escalonamento de um cluster do Dataproc se estiver executando cargas de trabalho em lote ou de streaming.

Otimizar o desempenho

Nesta seção, abordamos maneiras de conseguir melhor desempenho e reduzir custos durante a execução de jobs do Spark.

Gerenciar tamanhos de arquivos do Cloud Storage

Para conseguir o desempenho ideal, divida seus dados no Cloud Storage em arquivos com 128 MB a 1 GB. O uso de muitos arquivos pequenos pode criar um gargalo. Caso você tenha muitos arquivos pequenos, pense na possibilidade de copiá-los para processamento no HDFS local e retornar com a cópia dos resultados.

Alternar para discos SSD

Para executar muitas operações de reprodução aleatória ou gravações particionadas, alterne para SSDs para melhorar o desempenho.

Colocar VMs na mesma zona

Para reduzir os custos de rede e melhorar o desempenho, use o mesmo local regional para os buckets do Cloud Storage usados nos clusters do Dataproc.

Por padrão, quando você usa endpoints globais ou regionais do Dataproc, as VMs do cluster são colocadas na mesma zona (ou em outra zona na mesma região que tenha capacidade suficiente) quando o cluster é criado. Você tem a opção de especificar a zona quando o cluster é criado.

Usar VMs preemptivas

O cluster do Dataproc pode usar instâncias de VM preemptivas como workers. Isso resulta em menores custos de computação por hora para as cargas de trabalho não críticas do que usar instâncias normais. No entanto, você deve avaliar alguns fatores quando utilizar VMs preemptivas:

• VMs preemptivas não podem ser usadas para armazenamento HDFS.
• Por padrão, as VMs preemptivas são criadas com um tamanho de disco de inicialização menor. Talvez você queira modificar essa configuração caso esteja executando grandes cargas de trabalho de ordem aleatória. Para mais detalhes, consulte a página sobre VMs preemptivas na documentação do Dataproc.
• Não é recomendável tornar preemptíveis mais da metade do total de workers.

• Quando você utilizar VMs preemptivas, é recomendável ajustar a configuração de cluster para ter mais tolerância a falhas de tarefas, porque a disponibilidade das VMs pode ser menor. Por exemplo, defina a configuração do YARN desta forma:

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

• É possível adicionar ou remover facilmente as VMs preemptivas do cluster. Para mais detalhes, consulte VMs preemptivas.

A seguir

• Consulte o guia sobre como migrar a infraestrutura do Hadoop local para o Google Cloud.
• Veja nossa descrição sobre a Vida útil de um job do Dataproc.
• Confira arquiteturas de referência, diagramas e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.