Manipulação de erros no Pentaho Data Integration (Error Handling)

Quando trabalhamos com dados, é muito difícil conseguir prever todas as situações que podemos encontrar. Tipos, tamanho e formatos ̶v̶ã̶o̶ podem ser diferentes. Por exemplo, suponhamos que seja necessário ler os dados de uma tabela_a e salvar numa tabela_b. As tabelas possuem as seguintes características:

tabela_a: origem e tabela_b: destino

Observando as duas tabelas, é possível notar facilmente que podemos ter alguns problemas:

  • Campo dt_registro varchar na origem e date no destino (máscaras diversas);
  • Nome com tamanho de 100 na origem e 50 no destino;
  • Sexo varchar na origem e bool no destino;
  • Sexo NULL na origem e NOT NULL no destino.

Para implementar o processo de ETL acima e tratar os possíveis erros dentro do PDI, vamos utilizar um funcionalidade chamada de Error Handling. Utilizaremos basicamente os seguintes steps:

  • Table Input: para ler os dados da tabela_a;
  • Select Values: para converter os campos de acordo com os tipos da tabela de destino (tabela_b);
  • Value mapper: para mapear o campo sexo (String -> bool);
  • Data Validator: principal tarefa é verificar a obrigatoriedade dos campos;
  • Insert/Update: salvar os dados na tabela de destino.

Utilizaremos os seguintes dados para realizar o processo:

Dados da tabela_a

No PDI, depois de criar uma transformação, iremos adicionar o step Table input. Selecione a conexão para o banco de dados (não vou entrar em detalhes sobre como criar uma conexão) e dê um select na tabela_a:

Ao executar a transformação (F9), podemos ver os dados na aba “Preview data”:

Note os tipos de dados que estão vindo da tabela_a clicando com o botão direito do mouse em cima do step Table Input e depois em “Mostra campos de saída”.

Precisamos converter os tipos de dados antes de enviá-los para a tabela_b. Primeiro, vamos tratar o campo sexo através do step “Value mapper”:

O que fizemos na imagem acima foi dizer que se o valor do campo for Masculino, vai ser substituído por 1 e ser for Feminino, por 0.

Além disso, é necessário converter alguns dos campos com o step “Select Values”. Na aba Meta-Data do step, vamos alterar os tipos dos campos dt_registro, nome e sexo da seguinte maneira:

Perceba que, como estamos alterando o campo dt_registro de String para date, precisamos informar a máscara “dd/MM/yyyy”. Alteramos os tamanho do campo nome para tamanho 50 e alteramos os campo sexo para Boolean.

Ao tentar executar a transformação, notamos que houve um erro. É importante sempre analisar o que foi exibido no log de erro, mas vou pular essa parte e ir logo para o que interessa: ERROR HANDLING.

Error Handling

Adicione um Dummy Step no Canvas, ligue o Select Values a ele e cliquem em “Error handling of step”:

Ao executar a transformação, ela vai ser executada com sucesso. Perceba que alguns registros foram enviados para o Dummy Step, esses registros foram os que o Select Values não conseguiu converter:

O Motivo dos erros

Qual foi o motivo desses registros não passarem no Select values? o PDI também consegue nos ajudar nesse aspecto. Ao clicar com o botão direito do mouse no Select Values e clicar em “Error Handlings…” teremos acesso a um pop-up que nos trará mais opções para trabalhar com a manipulação de erros. Adicione um novo field chamado de “descricao” da seguinte forma:

Ao executar a transformação, note que conseguimos ver a descrição dos erros que aconteceram no Select Values:

Através de descrição do erro, conseguimos saber que os erros aconteceram por causa da máscara que utilizamos para converter o campo dt_registro.

Isso pode ser corrigido no PDI adicionando um outro step Select Values e informando uma máscara adequada, no entanto, dependendo do projeto, talvez fosse uma opção solicitar para que o usuário do sistema de origem corrigisse essa informação na própria aplicação, aparentemente isso foi causado por um equívoco do usuário.

Campos obrigatórios

Para verificar a obrigatoriedade de campos, eu costumo usar o step “Data Validator”. Perceba que eu vou deixar o campo “Null Allowed” desmarcado para o campo sexo.

Adicione o error handling para um outro Dummy Step para o data Validator, assim como foi feito com o Select Values.

Note no gif acima que houve um registro de erro porque o PDI encontrou NULL num campo que não pode ser nulo. O tratamento desse problema também pode ser feito no próprio PDI mas, novamente, talvez o correto seja o próprio usuário corrigir essa informação na origem.

Inserindo na tabela de destino

Agora que convertemos os dados de acordo com o a tabela de destino e verificamos os campos que são obrigatórios ou não, podemos inserir os dados na tabela_b. Utilizaremos o step Insert/Update:

Para tratar os erros desse step, também vamos utilizar o Error Handling para um Dummy Step.

Perceba que no gif acima eu “forcei” um erro inserindo uma tabela que não existe no banco para que todos os registros fossem direcionados para o Dummy Step de erros a fim simular o problema. Ao corrigir o nome da tabela, os registros foram inseridos normalmente no banco:

Dessa maneira, podemos verificar como funciona o tratamento de erros dentro do Pentaho Data Integration. Caso não tivéssemos tratado os erros, o PDI iria parar a execução e conseguiria inserir nenhum registro na tabela de destino.

O que fazer com os erros?

Conforme mencionei anteriormente, é possível realizar a correção desses erros no próprio PDI. Entretanto, em muitos casos, a correção dessa “sujeira” pode ser feita pelo próprio usuário da aplicação. Geralmente gero relatórios com todos os erros identificados e envio para que os usuários providenciem a correção.

Tipos de erros

No Pentaho Data Integration, em um processo de ETL simples como o descrito acima, costumo categorizar os erros em:

  • Erros de conversão: erros acontecem quando tentamos converter sem sucesso um campo;
  • Erros de Validação: erros gerados pelo data validator. Geralmente se resumem a erros de campos obrigatórios.
  • Erros de banco de dados: erros gerados pelos steps que fazem inserções, atualizações ou deletes nas tabelas. São erros de estouram no banco de dados e geralmente tem análise um pouco mais complicada.
  • Erros de implementação: erros que não conseguimos tratar no PDI, eles fazem com que a transformação não seja executada e pare todo o processo.
  • Erros não controlados: também não conseguimos tratar esse tipo de erro no PDI. ele geralmente está relacionado a eventos externos ao PDI.

Erros que não conseguimos tratar no PDI

Infelizmente existem erros que não conseguimos tratar dentro do PDI podem fazer com que toda a transformação seja abortada. Por exemplo, se informarmos um field que não existe dentro de um Select Values, o PDI vai abortar todo o processo. Tudo bem… eu sei que é muito difícil acontecer isso de informar um campo inexistente, no entanto, acredite em mim, em projetos grandes, isso é perfeitamente comum (hehe).

Outro exemplo de erro que aborta uma transformação: quando o PDI não consegue achar uma conexão disponível com o banco de dados no pool de conexões. Horário comercial com toda a empresa trabalhando e o limite de conexões no banco é pequeno, não tem jeito: ou chora para os administradores de banco de dados aumentarem esse limite ou espera a madrugada pra rodar as transformações.

Arquivos disponibilizados no https://github.com/guidogabriel/medium/tree/master/error_handling