Orientação sobre erros comuns

Esta página descreve alguns erros comuns que você pode encontrar ao executar seu job do Dataflow e sugere alguns cursos de ação para lidar com esses erros.

Mensagens do job:

Erros de envio de job:

Logs de worker (Stackdriver):

Mensagens de job

"O job falhou porque um item de trabalho falhou quatro vezes"

Se uma única operação fizer com que o código do worker falhe quatro vezes porque o código gerou uma exceção ou falha, o Dataflow falhará no job e a mensagem a work item failed 4 times será exibida.

Procure nos registros do job no Stackdriver pelas quatro falhas individuais. Busque entradas de registro de Nível de erro ou Nível fatal nos registros de worker que mostram exceções ou erros. Você verá pelo menos quatro dessas exceções ou erros.

Erros de codificação, IOExceptions ou comportamento inesperado no código do usuário.

Os SDKs do Apache Beam e os workers do Dataflow dependem de componentes comuns de terceiros. Esses componentes importam mais dependências. Os conflitos de versão podem resultar em um comportamento inesperado no serviço. Se você estiver usando qualquer um desses pacotes em seu código, esteja ciente de que algumas bibliotecas não são compatíveis com versões futuras. Talvez seja necessário marcar as versões listadas que estarão no escopo durante a execução. As dependências do SDK e do worker contêm uma lista com as dependências e as respectivas versões necessárias.

Jobs que eram executados sem problemas agora falham com "O pacote preparado... é inacessível"

Verifique se o intervalo do Cloud Storage usado na preparação não tem configurações de TTL que possam excluir os pacotes preparados.

Erros de envio de job

"413 Entidade de solicitação muito grande" / "O tamanho da representação JSON serializada do pipeline excede o limite permitido"

Se você se deparar com um erro sobre payload do JSON ao enviar o job, significa que a representação JSON do pipeline excede o tamanho máximo de solicitação, que é 20 MB. Esses erros podem aparecer como uma destas mensagens no Console ou na janela de terminal:

  • 413 Request Entity Too Large
  • "O tamanho da representação JSON serializada do canal excede o limite permitido"
  • "Falha ao criar um job de fluxo de trabalho. Payload do JSON inválida"
  • "Falha ao criar um job de fluxo de trabalho. Payload de solicitação excede o limite permitido"

O tamanho do job está associado especificamente à representação JSON do pipeline. Um pipeline maior significa uma solicitação maior. Atualmente, o Dataflow tem uma limitação que restringe as solicitações a 20 MB.

Para estimar o tamanho da solicitação JSON do pipeline, execute-o com a seguinte opção:

Java: SDK 2.x

--dataflowJobFile=< path to output file >

Python

--dataflow_job_file=< path to output file >

Java: SDK 1.x

Esse comando grava uma representação JSON do job em um arquivo. O tamanho do arquivo serializado é uma boa estimativa do tamanho da solicitação. O tamanho real é um pouco maior em função de algumas informações extras incluídas na solicitação.

Certas condições no pipeline podem fazer com que a representação JSON exceda o limite. As condições mais comuns são as seguintes:

  • Uma transformação Create que inclui uma grande quantidade de dados na memória.
  • Uma grande instância de DoFn que é serializada para transmissão a workers remotos.
  • Uma DoFn como uma instância de classe interna anônima que, possivelmente de forma não intencional, extrai uma grande quantidade de dados para serem serializados.

Para evitar essas condições, reestruture seu pipeline.

"O gráfico de job é muito grande. Tente novamente com um gráfico menor ou divida o job em dois ou mais jobs menores."

O tamanho do gráfico do job não pode exceder 10 MB. Determinadas condições no pipeline podem fazer com que o gráfico do job exceda o limite. Algumas condições mais comuns são as seguintes:

  • Uma transformação Create que inclui uma grande quantidade de dados na memória.
  • Uma grande instância de DoFn que é serializada para transmissão a workers remotos.
  • Uma DoFn como uma instância de classe interna anônima que, possivelmente de forma não intencional, extrai uma grande quantidade de dados para serem serializados.

Para evitar essas condições, reestruture seu pipeline.

"O número total de objetos BoundedSource gerados pela operação splitIntoBundles() é maior do que o limite permitido" ou "O tamanho total dos objetos BoundedSource gerados pela operação splitIntoBundles() é maior do que o limite permitido"

Java: SDK 2.x

Esse erro pode ser gerado em caso de leitura de um número muito grande de arquivos por meio de TextIO, AvroIO ou alguma outra fonte baseada em arquivo. O limite específico depende dos detalhes da fonte (por exemplo, o esquema de incorporação em AvroIO.Read permitirá menos arquivos), mas é aproximadamente de dezenas de milhares de arquivos em um pipeline.

Esse erro também poderá ocorrer se você tiver criado uma fonte de dados personalizada para o pipeline e o método splitIntoBundles dela retornar uma lista de objetos BoundedSource que ocupam mais de 20 MB quando serializados.

O limite permitido de tamanho total dos objetos BoundedSource gerados pela operação splitIntoBundles() da fonte personalizada é de 20 MB. Para contornar essa limitação, modifique sua subclasse BoundedSource personalizada para que o tamanho total dos objetos BoundedSource gerados seja menor que o limite de 20 MB. Por exemplo, a fonte pode gerar menos divisões inicialmente e contar com o Reequilíbrio dinâmico de trabalho para dividir ainda mais entradas sob demanda.

Java: SDK 1.x

Logs de worker (Stackdriver):

"Processamento parado na etapa <step_id> por pelo menos <time_interval> sem retorno ou conclusão no estado final em <stack_trace>"

Se o Dataflow gastar mais tempo executando um DoFn que o tempo especificado em <time_interval> sem retornar, essa mensagem será exibida.

Esse erro tem duas causas possíveis:

  • O código DoFn é simplesmente lento ou está aguardando que alguma operação externa lenta seja concluída. Nesse caso, ignore o aviso.
  • O código DoFn pode estar travado, entrou em um impasse ou apresenta uma lentidão anormal para concluir o processamento. Se você acha que esse é o caso, expanda a entrada de registro do Stackdriver para ver um rastreamento de pilha do código travado.

É possível investigar a causa do código travado se seu pipeline for criado na Máquina Virtual Java (JVM, na sigla em inglês), usando Java ou Scala. Para isso, pegue um despejo completo de linha de execução de toda a JVM (não apenas a linha de execução travada) seguindo estas etapas:

  1. Anote o nome do worker na entrada de registro.
  2. Na seção Compute Engine do Console do Cloud, encontre a instância do Compute Engine com o nome do trabalhador que você anotou.
  3. Conecte à instância com esse nome por SSH.
  4. Execute este comando:

    curl http://localhost:8081/threadz
        

Exceções de tempo limite de RPC, exceções "DEADLINE_EXCEEDED" ou erros de "servidor sem resposta"

Se ocorrerem tempos limites de RPC, exceções de DEADLINE_EXCEEDED ou erros de Server Unresponsive durante a execução do job, eles geralmente indicam um dos dois problemas:

  • A rede VPC usada para o job pode estar sem uma regra de firewall. A regra de firewall precisa permitir todo o tráfego TCP entre as VMs na rede VPC que você especificou nas opções do pipeline. Consulte Como especificar rede e sub-rede para mais detalhes.

  • O job está vinculado à reprodução aleatória. Pense em uma das linhas de ação a seguir ou uma combinação delas:

    Java: SDK 2.x

    • Adicione mais workers. Defina --numWorkers com um valor mais alto ao executar o pipeline.
    • Aumente o tamanho do disco anexado para os workers. Defina --diskSizeGb com um valor mais alto ao executar o pipeline.
    • Use um disco permanente com SSD. Defina --workerDiskType="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd" ao executar o pipeline.

    Python

    • Adicione mais workers. Defina --num_workers com um valor mais alto ao executar o pipeline.
    • Aumente o tamanho do disco anexado para os workers. Defina --disk_size_gb com um valor mais alto ao executar o pipeline.
    • Use um disco permanente com SSD. Defina --worker_disk_type="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd" ao executar o pipeline.

    Java: SDK 1.x


Uma chamada do agente de worker em Java para uma DoFn do Python falhou apresentando o erro <error message>

Se uma DoFn implementada no Python falhar e gerar uma exceção, uma mensagem de erro pertinente será exibida.

Expanda a entrada de registro de erros do Stackdriver e examine a mensagem de erro e o rastreamento. Ele mostra qual código falhou para que você possa corrigi-lo se necessário. Se você acredita que isso é um bug no Apache Beam ou no Dataflow, informe o bug.

Não há espaço livre no dispositivo

Se um job embaralhar uma grande quantidade de dados ou gravar dados temporários em discos locais, o armazenamento permanente do worker poderá ficar sem espaço livre.

Se aparecer uma mensagem informando que não há espaço no dispositivo, aumente o tamanho dos discos permanentes dos workers definindo a opção de pipeline apropriada. No caso dos jobs em Java, use a sinalização --diskSizeGb. Para os jobs em Python, use --disk_size_gb.

Erros de espaço em disco, como "RESOURCE_EXHAUSTED: erro de E/S: sem espaço no disco"

Esses erros geralmente indicam que você alocou espaço em disco local insuficiente para processar o job. Se você estiver executando o job com as configurações padrão, ele utilizará três workers, cada um com 25 GB de espaço em disco local, sem escalonamento automático. Modifique as configurações padrão para aumentar o número de workers disponíveis no job, aumentar o tamanho de disco padrão por worker ou ativar o escalonamento automático.

Avisos de "solicitação inválida" nos registros do shuffler

Durante a execução de um job do Dataflow, os registros do Stackdriver podem exibir uma série de avisos semelhantes a:

Unable to update setup work item <step_id> error: generic::invalid_argument: Http(400) Bad Request
    Update range task returned 'invalid argument'. Assuming lost lease for work with id <lease_id>
    with expiration time: <timestamp>, now: <timestamp>. Full status: generic::invalid_argument: Http(400) Bad Request
    

Os avisos de "solicitação inválida" aparecem porque as informações de estado do worker estão desatualizadas ou fora de sincronia devido a atrasos no processamento. Muitas vezes, o job do Dataflow será bem-sucedido, apesar desses avisos de “solicitação inválida”. Se esse for o caso, ignore-os.

Uma chave com uso intenso foi detectada na etapa <step_id> com o tempo de <time_interval>s

Esses erros indicam que você tem uma chave com uso intenso. Uma chave com uso intenso é uma chave com elementos suficientes para afetar negativamente o desempenho do pipeline. Essas chaves limitam a capacidade do Dataflow de processar elementos em paralelo, o que aumenta o tempo de execução.

Verifique se seus dados estão distribuídos de maneira uniforme. Se uma chave tiver muitos valores de forma desproporcional, realize uma das ações a seguir: