Nesta página, você verá como resolver problemas com o Cloud Data Fusion.
Resolver problemas de pipelines em lote
A orientação a seguir é para pipelines em lote.
O pipeline simultâneo está travado
No Cloud Data Fusion, executar 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 nas instâncias em execução na versão 6.6 e mais recentes.
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 (normalmente 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 de jobs 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 do Storage (
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 do coletor de várias tabelas do Google BigQuery).
O pipeline não para no limite de erro
Um pipeline pode não ser interrompido depois de vários erros, mesmo que você defina o limite
de erro como 1.
O limite de erro é destinado a quaisquer 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 erro não 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
no 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 levar a 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 momento da execução. A versão mais antiga do plug-in de origem em lote da Oracle mapeia o tipo de dados NUMBER do Oracle definido sem precisão e escala para o tipo de dados decimal(38,0) do CDAP, enquanto as versões 1.9.1, 1.8.5 e 1.8.4 e posteriores mapeiam os tipos de dados para string no ambiente de 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 do CDAP string no ambiente de execução. Se você tiver um coletor ou um estágio downstream que consuma o tipo de dados decimal do CDAP original (ao qual o tipo de dados NUMBER do Oracle definido sem precisão e escala foi mapeado), atualize-o 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
escolha o tipo de dados Oracle NUMBER definido sem precisão e dimensione como
o tipo de dados CDAP decimal(38,0), implante a versão 1.8.6 (para
Cloud Data Fusion 6.7.3) ou 1.9.2 (para Cloud Data Fusion 6.8.1) do
Hub e atualize os pipelines para usá-los.
Para mais informações, consulte a referência de fontes em lote da 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 recomendável: 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 no término do pipeline falhe.
Max Idle Time está disponível nas versões 6.4 e mais recentes do Cloud Data Fusion.
Recomendado: para versões anteriores à 6.6, defina Max Idle Time manualmente como 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:
Consiga cada ID do projeto em que os clusters foram criados:
Nos argumentos de ambiente de execução do pipeline, verifique se o ID do projeto do Dataproc está personalizado para a execução.
Se um ID de projeto do Dataproc não for especificado explicitamente, determine qual provisionador é usado e, em seguida, verifique o ID do projeto:
Nos argumentos do ambiente de execução do pipeline, verifique o valor
system.profile.name.
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.
Para cada projeto:
Abra o projeto no console do Google Cloud e acesse a página Clusters do Dataproc.
Ordene os clusters pela data de criação, do mais antigo ao mais recente.
Se o painel de informações estiver oculto, clique em Mostrar painel de informações e acesse a guia Rótulos.
Para cada cluster que não estiver em uso (por exemplo, se passou mais de um dia), verifique se há um rótulo de versão do Cloud Data Fusion. Isso indica que ele foi criado pelo Cloud Data Fusion.
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 executar 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 os pipelines falharem 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, faça upgrade para a revisão 6.8.3.1, 6.9.2.1 ou mais recente. Se não for possível fazer upgrade, remova os nós de trabalho secundários das maneiras a seguir.
Se você usar um provisionador temporário do Dataproc, resolva o erro com estas etapas:
- Acesse seu pipeline na interface da Web do Cloud Data Fusion.
- Nos argumentos do ambiente de execução do pipeline, defina
system.profile.properties.secondaryWorkerNumNodescomo0.
- Clique em Save.
- Se você usar um namespace, desative os workers secundários nele:
- Clique em Administrador do sistema > Namespaces e selecione o namespace.
- Clique em Preferências > Editar.
- Defina o valor de
system.profile.properties.secondaryWorkerNumNodescomo0.
- Clique em Salvar e fechar.
Se você usa um provisionador atual do Dataproc, resolva o erro com estas etapas:
No console do Google Cloud, acesse a página Clusters do Dataproc.
Selecione o cluster e clique em Editar.
No campo Nós de trabalho secundários, digite
0.
Clique em Save.