Continuando a série de posts sobre joins onde começamos falando sobre Join Rows (cartesian), como ele funciona e as melhores práticas para obter uma boa performance.
Avançando um pouco mais, vamos falar sobre as operações de Merge que envolvem Joins no Pentaho e unificam dados de diferentes fontes em um único local.
ÍNDICE:
MERGE
Todas as operações de merge no PDI envolvem algum tipo de join – as bases são as mesmas da linguagem SQL.
Aqui não é diferente, dependendo do tipo de transformação de merge que escolhemos, temos um ou mais tipos, entre as opções de junção, para escolher.
Para mostrar o primeiro exemplo, vamos ver como o Merge Join funciona.
Primeiro criei uma transformação base, com uns dados dummy para efeito prático.
Antes que se perguntem dos Sort rows, as operações de join pedem um ordenamento prévio dos dados antes de passar pelo merge. Aqui no PDI não é obrigatório, porém, o resultado pode ser comprometido caso não esteja ordenado.
Para todas as operações de merge sempre adicione sort rows, sempre!
A configuração é bem simples, escolha apenas o campo chave que será igualado pelo step e o tipo de Join.
NOTA: se não conhece os conceitos de join, acesse esse link!
Como utilizei o right join, a operação pegará os dados da esquerda, irá comparar com os dados da direita. Retornando aqueles que possuem correspondência e os que não possuírem, retornará null.
Em vermelho, os dados correspondentes ao right join e em marrom, os que não possuem correspondência!
Uma importante situação que notei aqui é que assim como no join rows do post passado, alguns tipos de join utilizados aqui também se beneficiam com a lógica da prioridade da stream com maior volume.
Stream utilizada no teste específico destacada em vermelho.
Em alguns testes que rodei com todos os tipos de join permitidos a stream que possui maior quantidade de linhas, no caso, RGenR >> Rsort obteve um melhor desempenho no processo.
Corroborando com a ideia de sempre aplicar a menor quantidade de dados na maior quantidade.
NOTA: os testes foram básicos e não realizei uma análise apurada, apenas capturei o tempo de conclusão. Em testes futuros e específicos, farei uma análise completa.
O esquema final do teste, ficou desta forma.
A imagem abaixo mostra a forma de escolher a fonte prioritária de dados no merge join, ou seja, a que será utilizada como base.
- First Step – é o campo da stream prioritária, será a base.
- Second Step – é o campo da stream que será aplicada na base para comparação.
Todos os testes foram feitos sem aplicar a divisão de cópias do processo, sendo uma única task.
MULTIWAY MERGE JOIN
O Multiway Merge Join é uma transformação que não se limita apenas a duas fontes de dados como merge join comum, visto no tópico anterior.
É muito indicado para situações onde há múltiplas fontes que necessitam ser integradas em uma única base.
O uso do sort também é necessário para que o processo seja 100% correto e ordenado.
Essa foi a estrutura básica que utilizei para este exemplo.
A configuração do data grid e do sort são bem simples e na próxima imagem, como configurei o Multiway Merge.
O limitador desta transformação, é que ela só permite inner e full join ainda que na linguagem SQL seja possível utilizar outros tipos de joins com diversas tabelas.
Tentei buscar na documentação e além de estar off-line, não encontrei nada na internet que explique, mas, parece que a ordem não altera muito o resultado final. Fiz o teste com variedade de ordenamento no input step e obtive o mesmo resultado.
Somente reforço a atenção para fontes com muitos dados, o ideal é que estas tenham prioridade na stream.
E o resultado final, abaixo:
Uma situação que é preciso chamar atenção ao uso desta transformção é a seguinte: analisem o data grid abaixo.
Percebam que o grid com TH_ID e R_ID possuem correspondentes até o ID = 7, diferente do L_ID que possui apenas até o 6. Reparando no resultado acima, o retorno foi até o valor 6.
Isto ocorre porque a transformação só retorna os valores que possuem correspondentes entre todos os inputs passados. Como no exemplo a correspondência vai até o ID = 6, temos o resultado exibido acima.
Se quiser os valores não correspondentes também, basta utilizar o full outer. Veja.
Sublinhado em vermelho temos o resultado regular como no exemplo utilizando o inner join. E circulado em preto, o resultado proveniente do full outer.
Mesmo quando a coluna não possui ID, o seu valor textual é retornado e o contrário se aplica.
CONCLUSÃO
Este foi um post onde quis mostrar a diferença entre as duas principais transformações utilizando o Merge join.
Como podemos ver, elas possuem um comportamento até que similar, embora o Multiway tenha um modo de ação fora do padrão join – SQL. Ainda assim, esse é um importante step para se dominar, principalmente por facilitar o uso de diversas fontes para o tratamento.
Não se esqueça de avaliar qual fonte possui maior quantidade de dados e tentar priorizar para ter um processo de ETL mais ágil e performático.
Espero que tenham gostado, saúde.
Link para download, aqui!
ASSINE!
Olá, se chegou até aqui, gostou do conteúdo e quer se manter atualizado do que acontece nesse blog, assine a newsletter!
ManageBI 