Melhorando o processo de carga da tabela Fato no ETL.

Olá pessoal, tudo bem?!

Nestes dias estudando no Pentaho, comecei a fuçar algumas configurações apenas para entender o que ela desempenhava dentro da ferramenta e numa dessas fuçadas, descobri uma forma de podermos melhorar a carga na tabela fato.

ALTERANDO AS CONFIGURAÇÕES DE CARGA

Notadamente a tabela fato é a carga mais ‘pesada’ dentro de uma estrutura de ETL, independente da ferramenta. Claro, algumas lidam melhor e outras nem tanto.

Tentando otimizar o uso do Pentaho neste aspecto, descobri uma maneira de carregar mais rápido e quero compartilhar com vocês.

Este é o já conhecido pipeline da tabela fato. Peguei a transformação de maior carga para mostrar a melhora no processo.

Além deste pipeline, há o step table output para a carga, e veja que a configuração está default.

Veja que o commit size não está ‘alto’, ou seja, a cada 10000 linhas, o PDI irá commitar essas linhas para liberar mais espaço na memória e, por consequência, carregar mais linhas.

Com a execução ‘normal’ o processo como um todo demorou menos de um minuto. Veja no log da transformação.

E abrindo o Step Metrics, veja que corrobora com o log.

Agora, vamos ver como podemos alterar a configuração do PDI para melhorar essa carga.

O primeiro passo, dentro da sua transformação, é apertar junto ctrl + T e clicar na aba Miscellaneous.

Altere o valor da configuração Nr of rows in rowset. No meu primeiro teste, utilizei 30000 linhas.

Veja que o próprio PDI puxa 30000 linhas de uma única vez para processá-las na transformação.

E  a própria taxa de leitura, para o primeiro impacto, está alta.

Na imagem abaixo, veja o resultado da métrica desta transformação.

De cara já percebemos que após a alteração, a carga foi executada com muito mais velocidade e mais, lendo 1000 linhas a mais, o que produziu um ganho de 3s de vantagem em relação a outra.

E por último, fiz um teste com 60000 linhas no rowset e veja o resultado.

Perceba que à medida que os steps da transformação vão avançando, a quantidade de linhas processadas é sempre no valor do rowset, o que garante a agilidade no processo.

Até no step de carga dos dados no banco, batemos a marca de 8500 linhas processadas por segundo.

RECOMENDAÇÕES

Quando for alterar o valor do rowset, não marque a opção Make the transformation database transactional. Essa opção reduz muito a velocidade no processamento.

Essa queda acontece devido a transformação mudar de lote de dados para transação, o que passa a processar uma por uma, já que é assim que um banco transacional trabalha.

Não coloque o commit size da transformação table output diferente do rowset. Se for menor, irá diminuir a performance, se for maior, não há um ganho, pois o PDI não ‘libera’ espaço commitando para puxar mais blocos de linha. Iguale os valores.

Não esqueça de desativar as chaves e os índices quando for carregar os dados.

CONCLUSÃO

Podemos perceber que o recurso funciona e pode agilizar bastante suas cargas de dados, principalmente as massivas.

Houve um ganho real tanto de performance quanto no que tange ao tempo de processamento do ETL.

Particularmente gostei do recurso, principalmente em uma transformação com bastante lookup que tende a diminuir um pouco a performance do ETL. Claro que mais ajustes precisam ser feitos e vai depender do processamento da máquina.

E a última dica para melhorar ainda mais a performance é: ative o número de cópias no processamento do table output e acompanhe as métricas!! Neste post mostro como se faz.

Espero que gostem, saúde!!!