Portfólio – Dimensão Loja

Olá pessoal, como estão?

Continuando a série de posts na construção do portfólio, hoje quero mostrar para vocês o meu processo de criação na dimensão loja.

Diferente do post anterior que foi mais simples, essa transformação foi um pouco mais complicada e aqui, mostro uma das formas que encontrei para remover duplicatas que existiam na fonte.

Além deste processo, vamos ver como podemos implementar o Slowly Changing dimension tipo 2.

PROCESSO DE ETL

Como estabelecido no post anterior, continuarei utilizando um arquivo local em csv ou txt para carga no data warehouse, lembrando que é uma extração direta do banco staging.

Esse foi o meu pipeline geral criado. A minha principal linha de raciocínio aqui foi deixar a dimensão loja o mais conforme e completa possível para obter melhores análises e insights.

A primeira grande dificuldade que obtive no processo foi o que diz respeito mais uma vez ao endereço. Até o momento, não tinha um padrão estabelecido e precisei repetir a transformação diversas vezes até que a transformação estivesse satisfatória.

Essa é a parte um, achei melhor dividir a etapa em duas para além de não confundir, garantir que não houvesse conflito ou erro.

Abaixo, apenas uma demonstração da parte um com alguns dos registros que foram alterados.

E aqui, a parte dois complementando e servindo mais como um ajuste fino ao processo criado. Para ambas as transformações utilizei o step replace in string.

Outro ponto que acho legal destacar aqui foram os dois steps que utilizei para calcular o tempo de funcionamento que as lojas possuem baseado no seu ano de abertura. Para isso, utilizei duas transformações:

1.       Formula.

2.       Calculator

Na transformação formula, utilizei duas funções, uma aninhada na outra, para pegar o ano atual do sistema; uma espécie de getdate dentro do Pentaho.

Já a calculator, utilizei para calcular a diferença de ano entre abertura e a data atual, obtendo assim o tempo de funcionamento de cada loja. 

Com isso, é possível avaliar quantos anos a empresa funciona e baseado nisso, desenvolver parcerias duradouras com valores mais customizados para cada um.

O passo seguinte foi remover os valores duplicados. Para isso, pensei em duas categorias de lojistas:

1.   Lojistas ativos e;

2.   Lojistas inativos.

E por que inativos se são valores teoricamente duplicados?

Por algum motivo vindo do banco, alguns registros possuíam pequenas alterações em seu cadastro. Então, para saber qual era o cadastro atual, cruzei os dados com a tabela SalesOrderHeader o stream lookup que retornava apenas os registros que fizeram compra.

Dessa forma, não precisaria pesquisar um por um no banco, quais eram e quais não eram. Esse pequeno trecho destacado é o que foi elaborado para remover as duplicatas.

Minha preocupação foi na configuração do stream lookup pois não queria tornar o processo mais lento. Para isso, coloquei a stream com maior quantidade de dados como referência de busca para a minha transformação, veja. 

Após, utilizei a transformação filter rows para filtrar a coluna que não possui correspondência com a tabela de vendas. Lembrando que essa tabela pega todo o período registrado, logo, nenhuma data ficou de fora.

Após, bastou enviar os dados que não corresponderam ao filtro para o step Unique rows para eliminar os valores duplicados.

IMPLEMENTANDO O SLOWLY CHANGING TYPE 2

O SCD do tipo 2 talvez seja o mais completo dentro do PDI no que tange ao controle de mudanças no data warehouse.

Este além de atualizar a dimensão, mantém registro histórico dos dados atualizados. Essa transformação no PDI permite configurações específicas para cada coluna da tabela, podendo escolher qual irá manter um histórico e qual não irá.

Na imagem abaixo, temos a primeira parte da configuração que por sinal, é muito similar ao insert/update visto anteriormente.

Aqui também podemos escolher se o step irá atualizar ou não, marcando a caixa “update the dimension”.

Muito cuidado com o Enable the cache pois ele ativo e o cache size 0, irá ocupar bastante memória podendo causar lentidão no processo. Sempre trabalhe com lotes menores.

Na imagem acima temos dois campos: Key & Fields. O campo key é o campo de comparação dos dados da stream com a dimensão e o campo field é onde configuramos as ações da transformação.

1. Update – simplesmente atualiza o registro corrigindo com base na última atualização
2. Punch through – é o scd tipo 1. simplesmente sobrescreve o novo registro no antigo
3. Insert – é o scd tipo 2 propriamente dito. Cria o registro histórico para aquela coluna, atualizando inclusive a versão do ETL.

E o último ponto de configuração para esta transformação, diz respeito ao gerenciamento de chaves nas colunas e dos controles de mudança.

Abaixo, a descrição dos campos mais importantes.

• Technical key – é basicamente o campo que irá virar surrogate key
• Creation of technical key – é configuração que a surrogate key terá quando os valores forem inseridos. Podemos utilizar uma sequence, identity ou um count do número da tabela. 
• Version field – campo numérico que informa em qual versão aquele determinado valor se encontra após sofrer um modificação; depende do tipo de configuração da transformação.
• Date star/end field – é o campo de controle com as datas de atualização. Quando uma coluna é atualizada, a sua “End_date” e “Start_date” são iguais, pois essa data marca o fim do antigo valor e início do novo com outra versão.

Estes são os campos básicos que utilizei para criar esta dimensão, em próximos irei explorar as outras opções.

No primeiro exemplo, vamos ver como funciona o slowly type 2 na prática. 

CRIANDO REGISTRO DE MUDANÇAS – INSERT

Para este, fiz uma pequena alteração no csv onde alterei o nome da loja, banco e ano de abertura

Em vermelho, os campos que foram alterados manualmente por mim na fonte csv com uma nova surrogate key para este registro.

Já na coluna VersionLoadETL temos a atual versão deste lojista, que após a mudança, consta como segunda versão e em azul, as datas em que ocorreram as alterações e a nova data de validade para a segunda versão.

TESTANDO O UPDATE NO SCD TIPO 2

Entendendo como o modo de insert na transformação funciona, vamos avaliar quando configuramos os mesmos campos, mas desta vez com o modo de update.

Fiz um truncate table e realizei uma nova carga com os dados originais vindo da área de stage. Irei alterar apenas o arquivo csv com as mesmas modificações feitas no tópico anterior.

Os campos configurados como  update no step dimension/lookup.

Quando configuramos o update, ele atualiza normalmente. Mas, como existem outras colunas que possuem outros modelos de controle no scd, acaba que o registro continua sendo controlado da mesma forma.

Realizando um novo teste e desta vez colocando todas as colunas como update, fiz um novo truncate e nova carga na tabela.

Veja que agora, não há um controle de versão, apenas a atualização pura e simples.

Veja que voltando o banco ao seu estado original sem truncar a tabela, não há alteração alguma nas colunas de controle.

A mesma aplicação e o mesmo cenário são válidos quando temos o modelo Punch Through para controle; apenas sobrescreve sem manter um histórico.

E se por acaso desmarcar a caixa “update the dimension”, a transformação dimension/lookup passa a funcionar como um insert no banco qualquer, ignorando qualquer mudança.

Mesmo sendo a primeira carga, algumas linhas possuem mais de uma versão vindo direto da fonte, tais versões não são duplicadas por erros de inserção, veja este exemplo.

Desse modo, sempre que for realizar uma carga, confira na tabela se há mais de uma versão para os registros.

CONCLUSÃO

Este foi um assunto que eu particularmente tinha dúvidas quanto a sua prática em si e como implementar. Mas vendo e aplicando percebi que não é tão difícil.

O que pode dificultar é escolher quais tabelas vão receber este tipo de controle como serão gerenciadas.

Ainda não dominei a ferramenta de forma satisfatória, então, fiz essa implementação básica para mostrar como configurar e utilizar.

Existem ainda outras três formas de controle que são gerenciadas pela data que irei estudar mais a fundo para entender como utilizá-las da melhor maneira.

Outra situação que não ficou clara é se é possível utilizar um modelo híbrido ou não; Me parece que tendo uma simples coluna com insert, todo a tabela passa para o tipo 2.

Espero que tenham gostado, deus os abençoe!

Saúde!