Olá pessoal, tudo bem!?
Antes de começar o post de fato, quero esclarecer que decidi refazer todo o projeto do zero por ter achado algumas, para não dizer muitas, inconsistências nele. Então, repostarei todas as dimensões que eu já havia criado até o momento e darei continuidade nas que faltaram.
E a partir de agora, iremos utilizar o Pentaho para todas as operações de ETL! Sem mais delongas, vamos ao post.
CRIANDO A DIMENSÃO REGIÃO
A ideia da dimensão região é criarmos análises que nos garantam entender em quais locais nossas operações foram maiores e menores durante o ano e com isso, tomar decisões se devemos ou não continuar vendendo produtos para o público daquele local.
Além desse tipo de decisão, teremos a possibilidade de saber quais produtos agradam mais e menos aquela população e, baseado nisso, elaborar campanhas de marketing e promoções que possam alavancar e fortificar nosso Market share regional.
O primeiro passo para a criação da região será extrair do banco de dados AdventureWorks os registros das tabelas que contenham informações sobre as regiões para criarmos a dimensão.
Na query utilizei o left join para que a consulta retornasse dados que não possuíssem correspondência com a tabela Sales.territory. Assim saberemos em quais regiões os produtos não chegaram ou não venderam e daí, investigar as causas.
Agora que temos a query formada, vamos para o Pentaho extrair essas informações para carregarmos nosso banco de stage.
Primeiro passo é criar a conexão com o banco (se não fez, veja este post!).
Quando criar a conexão, adicione o step, table input.
Cole a query no input do step e crie a atribua a conexão com o banco desejado.
Clique em preview para conferir se está extraindo os dados certos, por questões de validação.
Agora que validamos os dados, podemos passar essa transformação para o stage. Como essa carga vai para o banco de stage, não vamos criar nenhuma transformação no momento.
Adicione o step select values para selecionar as colunas que iremos carregar para o stage. Veja as colunas selecionadas.
Após selecionar as colunas, clique em meta-data para configurar devidamente os campos. Estas são as configurações que utilizei.
É importante configurar o meta-data dos dados extraídos antes de enviarmos para o destino final. Esse processo ocorre para controle de versão e também, definir os tipos de dados corretos e seus tamanhos de armazenamento.
Lembre-se que em banco de dados basicamente tudo conta para performance. Ter o tipo e tamanho de dados correto, conta muito para execução das atividades do banco.
Configurado o step de seleção de colunas, vamos para o próximo que é enviar esses dados para o data warehouse de staging. Adicione na sua transformação o step table output.
Observe a configuração abaixo.
- Step name – nome do step na transformação;
- Connection – nome da conexão para o banco (stage, fonte ou dw);
- Target Schema – nome do schema da tabela, caso exista. Não é obrigatório, apenas recomendado;
- Target Table – nome da dimensão;
- Commit Size – quantidade de linhas que o banco terá de processar antes de executar o commit dos registros;
- Truncate table – toda carga que for executada nesta tabela, O Pentaho irá truncar antes de carregar os dados;
- Specify database fields – Nos permite escolher quais colunas vamos enviar para o banco de staging.
Após a pequena explicação, vamos especificar as colunas, já que habilitamos a opção. Clique em database fields e em get fields.
Perceba que o próprio Pentaho mapeia as colunas.
Depois de selecionar as colunas clique no botão SQL e o Pentaho irá gerar o comando SQL para criar esta tabela.
Veja que a criação está na mesma ordem que definimos quando extraímos na fonte e, podemos citar também que o schema e a tabela são os mesmos do início da configuração do step table output.
Antes de avançar, devo destacar que o Pentaho não utiliza o tipo nvarchar como está na imagem. Por padrão, todos os campos strings que a ferramenta atribui são varchar. Como algumas colunas possuem a chance de ter algum caractere especial, atribuí este data type.
Ao finalizar esta configuração, clique em execute.
EXTRA
Como garantia futura para caso de alguma perda ou falha de processo, recomendo a criação do hábito de criar um destino em formato de arquivo texto para suas cargas de stage e do dw principal. Deste modo, se houver alguma falha no processo ou perda de dados, já há uma economia de tempo.
A principal justificativa é a eliminação da necessidade de buscar os dados novamente na fonte, como fizemos no início. Principalmente se for em ambientes complexos.
- Filename – Nome e diretório onde o arquivo ficará salvo. No meu caso, criei uma variável com o path do diretório e especifico apenas o nome do arquivo.
- Do not create file at start – Configura o Pentaho a criar o arquivo somente no momento que a ferramenta escrever a primeira linha no txt.
- Include date in filename – inclui no final do nome do arquivo a data da carga.
NOTA: não configuro a janela content, deixo como padrão. Na aba fields, apenas clico em get fields.
Se clicar em show filename verá qual o nome do arquivo o Pentaho irá atribuir quando concluir a transformação.
CONFIGURANDO O ERROR HANDLING
Como visto no post anterior que mostrou como criar um tratamento de erros, vamos aplicar o conhecimento do tutorial nesta transformação.
Irei criar um tratamento para caso algum fator inesperado não passe despercebido e comprometa a consistência dos dados.
Neste exemplo, irei aprimorar um pouco mais o que criamos no primeiro tutorial. Primeiro, veja como ficou a minha transformação:
O primeiro passo foi escrever o erro no write to log, pois ali, conseguimos configurar o nível de detalhamento que iremos atribuir para coleta de erros. Veja na imagem.
No meu exemplo, escolhi o nível detailed. Quanto mais detalhado, mais demorado se torna o processo.
O step formula (farei um post sobre esse recurso mais a frente), adicionei apenas para pegar a data que ocorreu o erro e registrar no arquivo de erro que criaremos ao final.
Seguindo o fluxo, passamos para o step de seleção de colunas, aqui, vamos selecionar as colunas error_desc e error_date para enviar ao destino final que é a tabela de controle de erro.
Não esqueça de forçar o erro no primeiro select values.
Como destino final, vamos criar uma tabela para registrar todos os erros de todas as transformações para futuras auditorias.
Nota: antes de configurar o destino, crie o schema Audit no seu banco de dados.
E a configuração das colunas e do comando SQL gerado para criar a tabela.
Resultado final da demonstração com um select na tabela dentro do banco de dados.
Uma vez configurado e testado o error handling da transformação, vamos voltar para a conclusão da transformação.
Retorne o data type do primeiro select values da coluna city para string, verifique se a tabela dimensão foi criada, caso não, execute o comando SQL gerado pelo Pentaho e clique em ok.
Após, aperte o botão F9 para executar essa transformação e verifique se foi concluída com sucesso.
NOTA: é normal que todos os steps fiquem verde mesmo para o caminho do error handling. Indica que não houve erro e todo o processo foi finalizado.
CONCLUSÃO
Este foi o primeiro post refeito sobre o data warehouse.
Irei repostar os outros no mesmo estilo utilizando o Pentaho até chegar às novas dimensões e a tabela fato.
Espero que tenham gostado, saúde!
ManageBI 