Add Sequence

Como o próprio nome diz, este step adiciona uma sequencia numérica ao fluxo de dados da transformation.

Veremos rapidamente neste post como utilizar o step Add Sequence, e em quais casos seria interessante a utilização do mesmo.

Observe que existem duas maneiras de obtermos esta sequencia.   A primeira é através de uma sequence existente no banco de dados.    Marcando o checkbox com a descrição "Usa BD para obter a sequencia", você poderá recuperar uma sequence existente em um schema do banco de dados.

A opção mais utilizada neste step é a criação de uma sequence pelo próprio Kettle.    Marcando o checkbox "Use o contador para calcular a sequencia", voce poderá definir o valor inicial da sequence gerada, seu incremento e valor máximo.

Para deixarmos claro estas últimas opções, caso escolhamos o valor 10 como inicial, 2 como incremento e 30 como valor máximo, teremos uma sequencia iniciando com o 10 na primeira linha do fluxo que passar neste step, crescendo de 2 em 2 (10, 12, 14, 16..) e que será reiniciada quando chegar no valor 30 (ex: 26, 28, 30, 10, 12..).

A primeira e mais óbvia utilidade deste step é a geração de uma sequence para popular uma tabela do banco de dados que não tenha uma sequence automática.     Esta abordagem também pode ser útil para criar sequences e deixar mais claro o número da linha ao popularmos um arquivo xls, csv ou txt.

Outra utilidade para este step, que também pode ser feita com outros steps, é o controle do fluxo.   Em determinado contexto, poderia ser necessário exportar para um arquivo uma lista com os 1000 produtos mais vendidos durante determinado mês.   Para isso, poderíamos obter a quantidade de vendas de cada produto (utilizando o step Group by), ordenar o fluxo pelos produtos mais vendidos (Sort Rows), numerar as linhas com o Add Sequence e utilizar qualquer step de controle (Filter Rows, Switch/Case, etc) para manter os mil primeiros registros até o final.

Conforme falado anteriormente, esta segunda abordagem apresentada também pode ser realizada sem a geração de uma sequence, pois o step "Sample Rows", na guia "Statistics", também é capaz de realizar este controle.

De qualquer forma, todas as vezes que for necessário controlar o fluxo e gravar o número das linhas, seja para adicioná-las em tabelas, para retirar registros desnecessários, identificar o número de linhas, identificar o número do último registro escolhido, etc, poderemos nos beneficiar da funcionalidade do step Add Sequence.

Exemplo de utilização do Add Sequence abordado neste post

Merge Join

O uso deste step e seu entendimento fica extremamente simples para aqueles que possuem alguma experiência com a linguagem SQL.     

O resultado deste componente é semelhante a um comando JOIN entre duas tabelas, porém no ETL ele faz a junção entre dois (e apenas dois) fluxos diferentes.

Para incluir a junção entre mais de dois fluxos, deverão ser utilizados outros componentes iguais na sequência do fluxo.

Observe através da figura acima que estamos juntando exatamente dois fluxos.   O primeiro tem origem em um step de ordenação, enquanto o segundo vem diretamente de um Table Input.    Independente das origens, precisaremos especificá-las dentro do step, decidindo qual será a primeira e a segunda fonte.

Esta definição será importante para o uso do LEFT, RIGHT ou FULL OUTER JOIN.   No caso de um INNER JOIN, a definição do primeiro ou segundo step influenciará apenas na ordem das colunas, porém não no resultado.

Para deixarmos claro o porquê desta definição, caso decidamos utilizar o LEFT JOIN, o resultado do step são todos os registros da primeira fonte, juntamente com os registros da segunda fonte onde haja correspondência entre os campos chave - key fields - de comparação .  Caso não haja correspondência, as colunas da segunda fonte retornarão nulas.

Não pretendemos demonstrar os tipos de resultados - através de prints - que são obtidos através deste step, já que, tendo ficado claro o conceito explicado no parágrafo acima, o retorno esperado será o mesmo que o retorno obtido através de uma query SQL.

Premissas e Cuidados

Observe que, ao clicar no botão Ok após a configuração do step, o Kettle exibirá a seguinte mensagem:

Esta mensagem alerta sobre uma premissa básica para o correto funcionamento do Join, que é a ordenação dos campos chave usados na comparação.   Esta premissa explica o step de ordenação que colocamos em nosso exemplo.   Neste exemplo, estamos ordenando o campo ID, que será comparado ao campo ISSUE proveniente do Table Input denominado CUSTOMFIELDVALUE.     Como é possível perceber, não colocamos outro step de Sort Rows após o Table Input porque já podemos ordenar os campos na própria query SQL.    

O Kettle exige estas ordenações pela forma que o step realiza o Join, ou seja, para garantirmos o funcionamento 100% correto, assim como o resultado esperado, devemos seguir esta instrução.

O último cuidado que devemos tomar ao utilizarmos este step, é o mesmo de quando utilizamos o Filter Rows, ou seja, não podemos esquecer de especificar corretamente a primeira e a segunda fonte (deixar o campo em branco), ou de trocá-los quando inserirmos outro step antes do Merge Join.   Isso é bem comum quando realizamos alterações no fluxo após a inserção do Merge Join.     Caso alguma das fontes fique em branco ou esteja apontando um step errado, a execução será interrompida por causa deste erro.

Movimentando dados entre várias transformations

Todos aqueles que já tiveram a oportunidade de trabalhar com os jobs no Kettle, perceberam a necessidade de comunicação entre as transformations que o compõem.   Isso acontece, obviamente, porque nem sempre as transformations são completamente independentes entre si, ou seja, apesar de processos diferentes, elas podem possuir uma sequencia de comandos e transformações em cima dos mesmos dados.

Para garantirmos que os dados de saída de uma transformation sirvam como insumo para a execução da próxima, precisaremos dos steps "Copy rows to result" e "Get rows from result", localizados na pasta Job.

Copy rows to result

Este step não possui qualquer propriedade a ser definida.   O fato de inserirmos o Copy rows to result em qualquer parte do fluxo, indica que todos os registros e todas as colunas do fluxo até aquele momento serão passadas adiante, ou seja, para a próxima transformation.

Por este motivo, o mais provável é que este step seja alocado ao final do fluxo, já que, na etapa final da transformation, os dados já estarão devidamente tratados e manipulados.

Get rows from result


Para que a próxima transformation recupere os dados enviados pela transformation anterior, usaremos este step para definir quais campos serão inseridos nesta transformation.

Caso a transformation anterior tenha terminado com 120 linhas e com as colunas id_fornecedor e nome_fornecedor, estamos definindo, de acordo com a imagem acima, que apenas as colunas id e nome do fornecedor entrarão nesta transformation.   Apesar de podermos escolher os campos, não podemos definir a quantidade de linhas de input.   Para chegarmos a este nível de controle, precisaríamos controlar a saída dos registros na transformation anterior, ou tratá-las em steps posteriores nesta nova transformation.

Sendo assim, podemos considerar o step Copy rows to result basicamente como um step de output, em virtude do seu comportamento, enquanto o step Get rows from result pode ser considerado como um step de input, não sendo necessário haver outro step de input para que a transformation inicie corretamente.

As imagens abaixo ilustram duas transformations que contêm os steps mencionados acima, em uma aplicação prática dos mesmos.

Índice de Postagens

Acabei de criar um pequeno índice para organizar melhor as postagens, confome o link exibido à direta da tela (Índice de Postagens).

A medida que postar qualquer conteúdo, atualizarei o respectivo tópico na listagem de postagens.

Dessa forma, esperamos que todos encontrem o conteúdo desejado com mais facilidade e rapidez.

Input e Output Fields

Como posso saber quais campos estão passando pelo fluxo e entrando ou saindo de um step?

Existe uma forma simples de fazê-lo.   Entre as opções apresentadas no menu que aparece ao clicarmos sobre o step com o botão direito do mouse, temos as opções "Mostra campos de entrada" e "Mostra campos de saída", conforme mostra a figura abaixo:

• Mostra campos de entrada: campos que estão passando pelo fluxo até o step selecionado;
• Mostra campos de saída: campos que estão passando pelo fluxo, inclusive os que foram gerados no step selecionado;

No caso da imagem acima, clicamos com o botão direito sobre o step "Database Lookup".   Este é um componente típico de recuperação de dados em uma tabela, ou seja, procuramos um valor dentro da tabela especificada cujo ID da linha (ou qualquer outro campo comparativo) seja igual a um ID proveniente do fluxo.   Se os valores baterem, ele retorna a coluna desejada da tabela, senão, traz um valor nulo ou default para esta coluna.

No caso desta transformation, se eu escolher a opção "Mostra campos de entrada", saberemos todos os campos que saíram do step Table Input com o nome de Get Vendas.    Se escolhermos a opção "Mostra campos de saída", visualizaremos os campos que vieram do Table Input juntamente com os campos gerados no componente Databse Lookup, neste caso, o campo codigo_funcionario.

 Campos de entrada / Campos de saída

Quando você abrir a janela com os campos de entrada ou saída, observe ainda que, além do nome das colunas, há várias outras informações sobre as colunas, inclusive o step em que aquele campo/coluna foi gerado.   Isso poderá ser extremamente útil quando tivermos transformations complexas, com muitos steps, e estivermos procurando a origem de alguma falha relacionada a um campo.

O botão "Edit origin step" o levará diretamente ao step que originou o campo escolhido.

Fique atento às próximas dicas rápidas do Kettle Beginners e trabalhe com mais eficiência no PDI.

Executando um processo no modo Preview

Executar um processo no modo Preview permite que o usuário visualize quais registros (dados) estão passando por cada step de nosso ETL.

O modo Preview só está disponível para as transformations, ou seja, só podemos ver os dados que estão trafegando durante a execução de uma transformation, e não de um job.

O modo Preview é executado pelo botão 

Ao executarmos a transformation neste modo, precisamos definir em qual step a execução será interrompida e os dados serão exibidos, o que fica claro através da figura abaixo.

Note pela figura acima que, antes de executarmos o preview, selecionamos o step Select Values.  Além disso, o campo Number of rows to retrieve está preenchido com o número 1000.    Isto indica que queremos visualizar as 1000 primeiras linhas que passarem pelo step Select Values, e apenas após a visualização destas poderemos decidir entre visualizar os próximos mil registros ou parar o preview.

Caso tenhamos executado o preview sem selecionar um step específico, poderemos fazê-lo selecionando um dos steps na lista à esquerda da janela.

Observe também que é possível definir uma outra condição de pausa, além do número de linhas.    Se marcarmos o checkbox “Pause transformation on condition”, poderemos definir uma ou mais condições onde nosso processo será interrompido, seguindo o mesmo padrão de condições do step “Filter Rows”, cujo funcionamento já foi visto em nosso blog.

Caso a execução de nosso ETL dependa de variáveis, parâmetros ou argumentos que são provenientes de um job ou de outra transformation, podemos definir valores para estes parâmetros/variáveis/argumentos clicando no botão “Configure”.

Ao apertarmos o botão “Configure”, a mesma janela do modo de execução “Run”, que é a execução normal do ETL, será exibida.   A figura abaixo nos mostra exatamente onde preencheremos estes valores, caso sejam necessários.

Tendo em vista estes conceitos, podemos realizar testes com mais eficiência, encontrar problemas e prever diversas situações ao enxergamos com facilidade os dados que estão trafegando em um determinado momento (específico) de nosso processo.

Get System Info

Este é um step da categoria de "Input", que nos ajuda a recuperar algumas informações do sistema, tais como a data do sistema, o primeiro e último dia do mês, o nome de uma transformation existente, o hostname e ip da máquina, além de dezenas de outras informações que podem ser inseridas rapidamente no fluxo.

Além disso, podemos receber um valor externo ao PDI.   Particularmente, costumo utilizar bastante o tipo "command line argument" para receber um ou mais parâmetros de uma xaction, e executar o processo de ETL recebendo estes valores externos dinamicamente.

Sabendo que é possível, por exemplo, utilizar um ETL para gerar um resultado para um relatório criado no Pentaho Report Designer, podemos receber parâmetros que seriam os filtros a serem utilizados em um select, ou qualquer outro valor que o usuário entenda como importante e que precisará ser considerado na execução do job ou da transformation.

A coluna “Name” define o nome que será dado ao valor recebido ou extraído do sistema, enquanto a coluna Type define o tipo de informação que será extraída do sistema.

Como temos dezenas de tipos de informações disponíveis na coluna Type, sugiro que acessem o endereço  http://wiki.pentaho.com/display/EAI/Get+System+Info  para que entendam melhor a função de cada um.

Tendo uma boa compreensão do funcionamento deste step, estaremos dando um importante passo na utilização conjunta das diversas ferramentas da suíte Pentaho de BI, já que é muito interessante a integração que é possível realizar com estas ferramentas.