Solução de problemas

Nesta página, você verá como resolver problemas com o Cloud Data Fusion.

Resolver problemas de pipelines em lote

O pipeline simultâneo está travado

No Cloud Data Fusion, a execução de muitos pipelines em lote simultâneos pode sobrecarregar a instância, fazendo com que os jobs fiquem travados nos estados Starting, Provisioning ou Running. Como resultado, os pipelines não podem ser interrompidos pela interface da Web ou por chamadas de API. Quando você executa muitos pipelines ao mesmo tempo, a interface da Web pode ficar lenta ou não responder. Esse problema ocorre devido a várias solicitações UI feitas ao gerenciador HTTP no back-end.

Recomendação

Para resolver esse problema, controle o número de novas solicitações usando o controle de fluxo do Cloud Data Fusion, disponível em instâncias em execução na versão 6.6 e posteriores.

A conexão SSH expira durante um pipeline em execução

O seguinte erro ocorre quando você executa um pipeline em lote:

`java.io.IOException: com.jcraft.jsch.JSchException:
java.net.ConnectException: Connection timed out (Connection timed out)`

Recomendação

Para resolver o erro, verifique os seguintes problemas:

• Verifique se há uma regra de firewall ausente (geralmente a porta 22). Para criar uma nova regra de firewall, consulte Configuração de rede do cluster do Dataproc
• Verifique se o aplicador do Compute Engine permite a conexão entre a instância do Cloud Data Fusion e o cluster do Dataproc.

Código de resposta: 401. Erro: erro desconhecido

O seguinte erro ocorre quando você executa um pipeline em lote:

`java.io.IOException: Failed to send message for program run program_run:
Response code: 401. Error: unknown error`

Recomendação

Para resolver esse erro, conceda o papel Runner do Cloud Data Fusion (roles/datafusion.runner) à conta de serviço usada pelo Dataproc.

Falha no pipeline com o plug-in do BigQuery com erro Access Denied

Há um problema conhecido em que um pipeline falha com um erro Access Denied ao executar jobs do BigQuery. Isso afeta os pipelines que usam os seguintes plug-ins:

• Origens do BigQuery
• Coletores do BigQuery
• Coletores de várias tabelas do BigQuery
• Transformador pushdown

Exemplo de erros nos registros (pode variar conforme o plug-in que você está usando):

POST https://bigquery.googleapis.com/bigquery/v2/projects/PROJECT_ID/jobs
{
"code" : 403,
"errors" : [ {
"domain" : "global",
"message" : "Access Denied: Project xxxx: User does not have bigquery.jobs.create permission in project PROJECT_ID",
"reason" : "accessDenied"
} ],
"message" : "Access Denied: Project PROJECT_ID: User does not have bigquery.jobs.create permission in project PROJECT_ID.",
"status" : "PERMISSION_DENIED"
}

Neste exemplo, PROJECT_ID é o ID do projeto que você especificou no plug-in. A conta de serviço do projeto especificado no plug-in não tem permissão para realizar pelo menos uma das seguintes ações:

• Executar um job do BigQuery
• Ler um conjunto de dados do BigQuery
• Criar um bucket temporário
• Crie um conjunto de dados do BigQuery
• Criar a tabela do BigQuery

Recomendação

Para resolver esse problema, conceda os papéis ausentes ao projeto (PROJECT_ID) que você especificou no plug-in:

• Para executar um job do BigQuery, conceda o papel de usuário do job do BigQuery (roles/bigquery.jobUser).

• Para ler um conjunto de dados do BigQuery, conceda o papel de leitor de dados do BigQuery (roles/bigquery.dataViewer).

• Para criar um bucket temporário, conceda o papel de administrador de armazenamento (roles/storage.admin).

• Para criar um conjunto de dados ou uma tabela do BigQuery, conceda o papel de editor de dados do BigQuery (roles/bigquery.dataEditor).

Para mais informações, consulte a documentação de solução de problemas do plug-in (Solução de problemas de coletores de várias tabelas do Google BigQuery).

O pipeline não para no limite de erro

Um pipeline pode não ser interrompido após vários erros, mesmo que você defina o limite de erro como 1.

O limite de erro é destinado a todas as exceções geradas pela diretiva no caso de uma falha que não seja processada de outra forma. Se a diretiva já usar a API emitError, o limite de erros não vai ser ativado.

Recomendação

Para projetar um pipeline que falha quando um determinado limite é atingido, use a diretiva FAIL.

Sempre que a condição transmitida para a diretiva FAIL é atendida, ela é contabilizada em relação ao limite de erros, e o pipeline falha depois que o limite é atingido.

O plug-in de origem em lote do Oracle converte NUMBER em string.

Nas versões de origem em lote do Oracle 1.9.0, 1.8.3 e anteriores, o tipo de dados NUMBER do Oracle, com precisão e escala indefinidas, é mapeado para o tipo de dados decimal(38,0) do CDAP.

As versões 1.9.1, 1.8.4 e 1.8.5 do plug-in são incompatíveis com versões anteriores, e os pipelines que usam versões anteriores podem não funcionar após o upgrade para as versões 1.9.1, 1.8.5 e 1.8.4, se um estágio downstream no pipeline depender do esquema de saída da origem porque o esquema de saída foi alterado. Quando há um esquema de saída definido para o tipo de dados NUMBER do Oracle definido sem precisão e reduzir escalonamento horizontal versão anterior do plug-in, depois de fazer upgrade para as versões 1.9.1, 1.8.5 ou 1.8.4, o plug-in de origem em lote do Oracle gera o seguinte erro de incompatibilidade de esquema para os tipos: Schema field '<field name>' is expected to have type 'decimal with precision <precision> and scale <scale> but found 'string'. Change the data type of field <field name> to string.

As versões 1.9.1, 1.8.5 e 1.8.4 funcionam com um esquema de saída do tipo de dados string do CDAP para o tipo de dados NUMBER do Oracle definido sem precisão e escala. Se houver algum tipo de dados NUMBER do Oracle definido sem precisão e escala presentes no esquema de saída de origem do Oracle, não é recomendado usar a versão mais antiga do plug-in Oracle, porque isso pode causar erros de arredondamento.

O caso especial é quando você usa uma macro para o nome do banco de dados, o nome do esquema ou o nome da tabela, e se você não tiver especificado manualmente um esquema de saída. O esquema é detectado e mapeado no ambiente de execução. A versão mais antiga do plug-in de origem em lote do Oracle mapeia o tipo de dados NUMBER do Oracle definido sem precisão e dimensionamento para o tipo de dados CDAP decimal(38,0), enquanto as versões 1.9.1, 1.8.5 e 1.8.4 e posteriores mapeiam os tipos de dados para string no momento da execução.

Recomendação

Para resolver o possível problema de perda de precisão ao trabalhar com tipos de dados NUMBER do Oracle com precisão e escala indefinidas, faça upgrade dos pipelines para usar as versões 1.9.1, 1.8.5 ou 1.8.4 do plug-in de origem em lote da Oracle.

Após o upgrade, o tipo de dados NUMBER do Oracle definido sem precisão e escala é mapeado para o tipo de dados CDAP string no ambiente de execução. Se você tiver um cenário ou coletor downstream que consuma o tipo de dados decimal do CDAP original (para que o tipo de dados NUMBER do Oracle definido sem precisão e escala foi mapeado), atualize ou espere que ele consuma dados de string.

Se você entende o risco de possível perda de dados devido a erros de arredondamento, mas optar por usar o tipo de dados Oracle NUMBER definido sem precisão e escala como o tipo de dados CDAP decimal(38,0), implante a versão 1.8.6 (para o Cloud Data Fusion 6.7.3) ou 1.9.2 (para o Cloud Data Fusion 6.8.1) no Hub e atualize os pipelines para usá-los.

Para mais informações, consulte a referência de origem em lote do Oracle.

Excluir um cluster temporário do Dataproc

Quando o Cloud Data Fusion cria um cluster temporário do Dataproc durante o provisionamento de execução do pipeline, o cluster é excluído após a conclusão da execução do pipeline. Em casos raros, a exclusão do cluster falha.

Altamente recomendado: faça upgrade para a versão mais recente do Cloud Data Fusion para garantir a manutenção adequada do cluster.

Definir tempo máximo de inatividade

Para resolver esse problema, configure a opção Max Idle Time. Isso permite que o Dataproc exclua clusters automaticamente, mesmo que uma chamada explícita na conclusão do pipeline falhe.

Max Idle Time está disponível nas versões 6.4 e posteriores do Cloud Data Fusion.

Observação :no Cloud Data Fusion 6.6 e versões posteriores, Max Idle Time é definido como 30 minutos por padrão e nenhuma outra configuração é necessária.

Recomendado: para versões anteriores à 6.6, defina Max Idle Time manualmente para 30 minutos ou mais.

Excluir clusters manualmente

Se não for possível fazer upgrade da versão ou configurar a opção Max Idle Time, exclua os clusters desatualizados manualmente:

1. Consiga cada ID do projeto em que os clusters foram criados:

   1. Nos argumentos do ambiente de execução do pipeline, verifique se o ID do projeto do Dataproc está personalizado para a execução.

      

   2. Se um ID do projeto do Dataproc não for especificado explicitamente, determine qual provisionador é usado e verifique se há um ID do projeto:

      1. Nos argumentos do ambiente de execução do pipeline, verifique o valor system.profile.name.

         

      2. Abra as configurações do provisionador e verifique se o ID do projeto do Dataproc está definido. Se a configuração não estiver presente ou o campo estiver vazio, será usado o projeto em que a instância do Cloud Data Fusion está sendo executada.

   Importante: várias execuções de pipeline podem usar projetos diferentes. Verifique se você tem todos os IDs do projeto.

2. Para cada projeto:

   1. Abra o projeto no console do Google Cloud e acesse a página Clusters do Dataproc.

      Acessar Clusters

   2. Classifique os clusters pela data de criação, do mais antigo ao mais recente.

   3. Se o painel de informações estiver oculto, clique em Mostrar painel de informações e acesse a guia Rótulos.

   4. Para cada cluster que não estiver em uso, por exemplo, se tiver passado mais de um dia, verifique se há um rótulo de versão do Cloud Data Fusion. Isso é uma indicação de que ele foi criado pelo Cloud Data Fusion.

   5. Marque a caixa de seleção ao lado do nome do cluster e clique em Excluir.

Não foi possível criar uma instância do Cloud Data Fusion

Ao criar uma instância do Cloud Data Fusion, talvez você encontre o seguinte problema:

Read access to project PROJECT_NAME was denied.

Recomendação

Para resolver esse problema, desative e reative a API Cloud Data Fusion. Em seguida, crie a instância.

Os pipelines falham ao serem executados em clusters do Dataproc com workers secundários

Nas versões 6.8 e 6.9 do Cloud Data Fusion, ocorre um problema que faz com que os pipelines falhem se forem executados em clusters do Dataproc em que os workers secundários estão ativados:

ERROR [provisioning-task-2:i.c.c.i.p.t.ProvisioningTask@161] - PROVISION task failed in REQUESTING_CREATE state for program run program_run:default.APP_NAME.UUID.workflow.DataPipelineWorkflow.RUN_ID due to
Caused by: io.grpc.StatusRuntimeException: CANCELLED: Failed to read message.
Caused by: com.google.protobuf.GeneratedMessageV3$Builder.parseUnknownField(Lcom/google/protobuf/CodedInputStream;Lcom/google/protobuf/ExtensionRegistryLite;I)Z.

Recomendação

Para resolver o problema, remova os nós de trabalho secundários das seguintes maneiras.

Se você usa um provisionador temporário do Dataproc, resolva o erro com estas etapas:

1. Acesse seu pipeline na interface da Web do Cloud Data Fusion.
2. Nos argumentos do ambiente de execução do pipeline, defina system.profile.properties.secondaryWorkerNumNodes como 0.
3. Clique em Save.
4. Se você usa um namespace, desative workers secundários no namespace:
   1. Clique em Administrador do sistema > Namespaces e selecione o namespace.
   2. Clique em Preferências > Editar.
   3. Defina o valor de system.profile.properties.secondaryWorkerNumNodes como 0.
   4. Clique em Salvar e fechar.

Se você usa um provisionador atual do Dataproc, resolva o erro com estas etapas:

1. No console do Google Cloud, acesse a página Clusters do Dataproc.

   Acessar Clusters

2. Selecione o cluster e clique em Editar.

3. No campo Nós de trabalho secundários, digite 0.

4. Clique em Save.