Práticas recomendadas do Dataproc para produção

Este documento discute as práticas recomendadas do Dataproc que podem ajudar você a executar jobs de processamento de dados confiáveis, eficientes e úteis em clusters do Dataproc em ambientes de produção.

Especificar versões de imagem do cluster

O Dataproc usa versões de imagem para agrupar sistemas operacionais, componentes de Big Data e conectores Google Cloud em um pacote implantado em um cluster. Se você não especificar uma versão de imagem ao criar um cluster, o Dataproc usará a versão de imagem estável mais recente por padrão.

Para ambientes de produção, associe o cluster a uma versão específica da imagem do Dataproc major.minor, conforme mostrado no comando da CLI gcloud a seguir. 

gcloud dataproc clusters create CLUSTER_NAME \
    --region=region \
    --image-version=2.0

O Dataproc resolve a versão major.minor para a versão secundária mais recente (2.0 é resolvido para 2.0.x). Observação: se você precisar usar uma versão secundária específica para seu cluster, especifique-a. Por exemplo, --image-version=2.0.x. Consulte Como funciona o controle de versões para mais informações.

Versões de imagem de prévia do Dataproc

Novas versões secundárias de imagens do Dataproc estão disponíveis em uma versão preview antes do lançamento na faixa padrão de versão secundária da imagem. Use uma imagem de prévia para testar e validar seus jobs com uma nova versão secundária da imagem antes de adotar a versão secundária padrão em produção. Consulte Controle de versões do Dataproc para mais informações.

Use imagens personalizadas quando necessário

Se você tiver dependências para adicionar ao cluster, como bibliotecas nativas do Python ou software de proteção contra vírus ou reforço de segurança, crie uma imagem personalizada com base na imagem mais recente na sua faixa de versão secundária de destino. Essa prática permite atender aos requisitos de dependência ao criar clusters usando sua imagem personalizada. Ao recriar sua imagem personalizada para atualizar os requisitos de dependência, use a versão de imagem subsecundária mais recente disponível na faixa de imagem secundária.

Enviar jobs para o serviço Dataproc

Envie jobs ao serviço Dataproc com uma chamada jobs.submit usando a CLI gcloud ou o console Google Cloud . Defina permissões de job e cluster concedendo papéis do Dataproc. Use papéis personalizados para separar o acesso ao cluster das permissões de envio de jobs.

Benefícios de enviar jobs para o serviço Dataproc:

  • Não são necessárias configurações de rede complicadas. A API é amplamente acessível.
  • Fácil de gerenciar permissões e papéis do IAM
  • Acompanhe o status do job com facilidade. Não há metadados do job do Dataproc para complicar os resultados.

Em produção, execute jobs que dependem apenas de dependências no nível do cluster em uma versão secundária fixa da imagem (por exemplo, --image-version=2.0). Agrupe as dependências com os jobs quando eles forem enviados. Enviar um uber jar para o Spark ou o MapReduce é uma maneira comum de fazer isso.

  • Exemplo: se um jar de job depender de args4j e spark-sql, com args4j específico do job e spark-sql uma dependência no nível do cluster, agrupe args4j no uber jar do job.

Controlar os locais das ações de inicialização

Com as ações de inicialização, é possível executar scripts ou instalar componentes automaticamente ao criar um cluster do Dataproc. Consulte o repositório dataproc-initialization-actions do GitHub para ver ações de inicialização comuns do Dataproc. Ao usar ações de inicialização de cluster em um ambiente de produção, copie os scripts de inicialização para o Cloud Storage em vez de extraí-los de um repositório público. Essa prática evita a execução de scripts de inicialização sujeitos a modificação por terceiros.

Monitore as notas da versão do Dataproc

O Dataproc lança regularmente novas versões secundárias de imagens. Consulte ou inscreva-se nas notas da versão do Dataproc para ficar por dentro dos lançamentos mais recentes da versão de imagem do Dataproc e de outros anúncios, mudanças e correções.

Ver o bucket de staging para investigar falhas

  1. Analise o bucket de preparo do cluster para investigar mensagens de erro do cluster e do job. Normalmente, o local do bucket de staging do Cloud Storage é mostrado em mensagens de erro, como no texto em negrito na seguinte mensagem de erro de exemplo:

    ERROR:
(gcloud.dataproc.clusters.create) Operation ... failed:
...
- Initialization action failed. Failed action ... see output in: 
gs://dataproc-<BUCKETID>-us-central1/google-cloud-dataproc-metainfo/CLUSTERID/<CLUSTER_ID>\dataproc-initialization-script-0_output

  2. Use a CLI gcloud para conferir o conteúdo do bucket de staging: 

    gcloud storage cat gs://STAGING_BUCKET
    Exemplo de saída: 
    + readonly RANGER_VERSION=1.2.0
... Ranger admin password not set. Please use metadata flag - default-password

Receber suporte

OGoogle Cloud oferece suporte às suas cargas de trabalho de produção de OSS e ajuda você a cumprir os SLAs comerciais com níveis de suporte. Além disso,os Serviços de consultoria do Google Cloudpodem orientar sobre as práticas recomendadas para implantações de produção da sua equipe.

Para mais informações