Gravar Fato com Dimension Lookup/Update

Inteligência e criatividade já foram definidas como misturar coisas com um propósito e atingir outro. Eu tive o melhor exemplo disso há pouco, durante uma aula.

Explicando a gravação de uma fato, e peculiariedades de cada tipo de fato (snapshot, acumulating etc.), ela me perguntou:

Ah, então eu posso gravar a fato com a Table Output, e se quiser atualizar uso um Dimension Lookup/Update?”

De cara eu não entendi a pergunta – “Comparar table output com dimension lookup/update? Mas não tem nada a ver…” – foi quando eu parei para pensar e vi que era não só uma pergunta lógica, como óbvia.

Sim, claro, o D L/U (Dimensio Lookup/Update) é um passo dedicado a gravar dimensões, mas a lógica dele se presta a qualquer gravação/atualização que envolva uma chave composta e “coisas” (métricas!) que variem (ou não.)

Eu resolvi fazer um teste. Essa é a transformação que grava a fato pedido da Beltrano S/A, tirada do meu livro Pentaho na Prática:

Transformação que carrega a fato, usando passo "normal" Insert/Update.
Transformação que carrega a fato, usando passo “normal” Insert/Update.

Eu então troquei o Update no final por um D L/U – e não mexi em mais nada:

Transformação que carrega a fato, usando passo D L/U.
Transformação que carrega a fato, usando passo D L/U.

E essa ficou sendo a configuração do passo (eu tratei o tipo de pagamento como uma degeneração, mas sem querer coloquei como métrica):

Configuração do passo D L/U para gravar uma fato.
Configuração do passo D L/U para gravar uma fato.

Resultado? Bom, depois que eu criei a fato com o botão de SQL do D L/U e carreguei, ela ficou assim:

Fato gravada pelo passo D L/U. Repare que todos campos de controle da dimensão foram chamados de fut_ext_x (futuras extensões), e que agora ela possui uma chave primária.
Fato gravada pelo passo D L/U. Repare que todos campos de controle da dimensão foram chamados de fut_exp_x (futuras extensões), e que agora ela possui uma chave primária.

Ou seja, é a fato, mas com os campos de controle da dimensão. Eu nomeie todos eles como futuras expansões (fut_exp). A chave delegada também está lá, mas agora na função de uma chave primária! Compare com a fato “normal”:

A tabela fato gravada com um passo normal. (As chaves zeradas são um bug da minha transformação, que está bagunçada (sabe como é, próxima versão do livro...)
A tabela fato gravada com um passo normal. (As chaves zeradas são um bug da minha transformação, que está bagunçada (sabe como é, próxima versão do livro…)

Os zeros nas chaves decorrem do fato de a minha transformação estar em mudança – por algum motivo eu não recuperei as chaves (pau do banco?) – mas normalmente dá certo. Por favor, releve como ruído no material do livro, que está sendo revisado.

Conclusão? Dá certo! (Claro que dá, mas… como é que eu nunca pensei nisso antes???) Será que é alguma vantagem usar o D L/U para isso? Será que simplifica alguma lógica? A ver!

Genial! :-)

Anúncios

Novo Livro: Pentaho Data Integration Cookbook – Segunda Edição

Um cookbook é um livro de receitas (recipes), e normalmente se vale de o leitor possuir algum conhecimento sobre o assunto (culinária via de regta) para ensinar algumas receitas. Por exemplo, para aprender a fazer um bolo você precisa saber quebrar ovos, que é algo que ninguém te ensina – um dia você viu alguém quebrar ovos para cozinhar e pronto, hora da receita (Recipe Time!)

Eu ganhei da Packet mais um livro sobre Pentaho para resenhar, o Pentaho Data Integration Cookbook (Segunda Edição), lançado há algumas semanas. Ele não ensina como instalar o PDI, ou rodá-lo, nem explica o que é uma transformação, um job e como criar um novo de cada. Isso é tarefa para outros livros, como o também excelente Pentaho 3.2 Data Integration: Beginner’s Guide.

O PDI Cookbook te ensina receitas, pequenos how-to, para mais de 100 objetivos. Ele tem receitas para ensinar a conectar uma transformação a um banco de dados, e como parametrizá-la (e porquê), uma para ler dados de tabelas em bancos relacionais, outra para construir e usar sub-transformações e ainda outras sobre como gravar os dados em clusters Hadoop, manusear o fluxo e os metadados de transformações, executar análises de dados, gerar relatórios, executar dentro do BI Server e assim por diante. Ele não esgota as possibilidades, mas chega bem perto de. Você pode consultar a página do livro na Packt, aba Table of Contents, para ver a lista completa.

Estou com o livro há duas semanas e ainda não li o livro todo, mas olhei uma boa parte delas e fiz questão de ler com cuidado algumas receitas sobre coisas que eu conheço (como conexões parametrizadas, leitura de dados, lookups e fluxos) e algumas sobre coisas que eu nem imagino como sejam (como ler e gravar dados do Salesforce.com e do Hadoop.)

Cada receita demanda algum conhecimento prévio do leitor, mas tem informação o bastante para não deixar dúvidas para os iniciantes, sem aborrecer o leitor mais experiente. As figuras são usadas com parcimônia, notadamente quando os autores sentem necessidade delas para explicar melhor algum detalhe ou comunicar uma configuração com mais precisão. Se por um lado isso torna o livro menor (e ele já um bom catatau, com mais de 400 páginas), por outro força o leitor a prestar mais atenção e requer mais familiariedade com os termos envolvidos. Ele não dá tudo mastigadinho, mas tem boa didática e os textos são bem escritos (mais sobre isso daqui a um parágrafo.)

Muitas (se não todas) receitas trazem dicas sobre eventuais opções ou formas alternativas de se obter o mesmo resultado, ou ainda alguma variação sobre o tema. Em várias das receitas que eu li há comparações entre métodos (como o lookoup de dados, que explicita a diferença entre Database Lookup e Database Join, por exemplo) e em geral há comentários sobre impactos de performance quando são significativos. A location 400 traz um dos meus favoritos, pela engenhosidade: usar bancos de dados em memória (como HSQDB ou H2) para montar lookups transitórios de alta performance.

Claro que, como a maioria dos livros da Packt é escrita em inglês por não-nativos, a linguagem do livro é por vezes menos fluída que o inglês de um norte-americano ou britânico (ou mesmo um aussie.) Acho que essa é única coisa do livro que é mais… desconfortável, mas decididamente não afeta o resultado final.

Enfim, o livro é um verdadeiro baú do tesouro, com grande valor para desenvolvedores novatos ou experientes. Se você já sabe mexer com o PDI, e quer se aprofundar nele, esse livro é uma boa escolha. Se você quer aprender a mexer no PDI, procure antes algo como o PDI Begginer’s Guide, e depois não deixe de investir no PDI Cookbook (mas a segunda edição; a primeira ainda tinha espaço para melhorar, tanto que foi o que fizeram.)

É isso, grande leitura! ;-)

Acesso ao Log do BI Server, Quick & Dirt Parte 2 – Usando XActions

No post anterior eu mostrei como implementar a genial idéia do Gerson Tessler para acessar os logs do BI Server via o próprio BI Server usando um relatório PRD e uma transformação. Agora vamos ver outra técnica (que eu prefiro porque tem um overhead menor): como expor o log do BI Server (ou qualquer outro) usando a mesma transformação e uma XAction.

Primeiro você precisa instalar e configurar o Pentaho Design Studio. Acesse a página de links do site companheiro do livro Pentaho na Prática e baixe o capítulo de degustação. Olhe nas páginas 3, 5 e 17 como instalar o PDS. Depois baixe este guia rápido e configure um projeto para seu BI Server 4.8. Teste e brinque um pouco com o BI Server e o PDS, até sacar a mecânica da coisa (atualizações feitas com o PDS sobre XACTIONs aparecem no BI Server depois de um refresh do repositório, a menos que você use um repositório em arquivo.)

Pronto? Vamos lá:

  1. No PDS clique com o botão da direita sobre a Beltrano e escolha a opção BI Platform e depois New Action Sequence;
  2. Na janela que aparecer deixe o campo Container como está e modifique o nome no campo File name de untiltled.xaction para log.xaction;
  3. Aba General: não mexa em nada e pule para a aba seguinte, Define Process;
  4. Na aba Define Process clique no ícone de mais azul que fica na seção Process Actions. Vai se abrir um menu: escolha Get Data From e depois Pentaho Data Integration;
  5. Usando a Figura 1 como guia, preencha:
    1. Name: não precisa mudar nada;
    2. Input Section: Transformation File deve apontar para a transformação (preencha com solution:le_log_biserver.ktr ou use o botão Browse – mas ele nunca funciona comigo…). Depois digite em Transformation Step o nome do passo que o BI Server deve drenar para receber as linhas lidas pela transformação, que é Saida;
    3. Output Section: preencha apenas o campo Output Rows Name com resultado, que é um nome da variável para receber as linhas drenadas da transformação;
  6. Para “imprimir” o que foi lido, adicione a variável resultado à seção Process Outputs (basta clicar no ícone de mais azul e selecioná-la).
Figura 1: configurando a execução de uma transformação no PDS. (Clique para tamanho natural.)
Figura 1: configurando a execução de uma transformação no PDS. (Clique para tamanho natural.)

E está pronto. Salve a XAction, mude para o BI Server, faça login, depois um refresh do repositório. A Xaction deve aparecer – execute-a com um duplo clique. Se tudo deu certo você vai ver o mesmo resultado do post anterior, feito com PRD, mas agora sem a “cara” de um relatório (Figura 2.)

Figura 2: exibindo o log do BI Server com XAction e transformação. (Clique para tamanho natural.)
Figura 2: exibindo o log do BI Server com XAction e transformação. (Clique para tamanho natural.)

Como da outra vez você pode baixar o pacote no site do Open BI Solutions: https://sourceforge.net/projects/openbisolutions/files/Logs/.

Até a próxima!

Acesso ao Log do BI Server, Quick & Dirt

Qualquer desenvolvedor de soluções com o BI Server precisa ter acesso ao(s) log(s). Na maioria das empresas os desenvolvedores simplesmente têm acesso direto ao BI Server e podem examinar os arquivos de log diretamente. Em outras empresas, porém, isso não é possível – não me pergunte porquê, mas existem empresas nas quais o desenvolvedor é proibido de acessar o ambiente de desenvolvimento. De produção, então, nem pensar!

Gerson Tessler, meu colega de trabalho e amigo, que mexe com Pentaho desde 2008, deu uma solução genial para esses desenvolvedores desafortunados: usar o próprio BI Server para examinar qualquer log. Fácil, simples, óbvio – a marca da genialidade!

Vamos fazer como um laboratório:

  1. Monte um BI Server e remova as pastas de demonstração;
  2. Crie uma pasta vazia. Como eu sempre uso a Beltrano S/A para tudo, minha pasta se chamará Beltrano;
  3. Abra o PDI e crie a transformação da Figura 1 (adicione um passo Text File Input e um Dummy, ligando o primeiro ao segundo):

    Figura 1: Layout de passos da transformação.
    Figura 1: Layout de passos da transformação. (Clique para tamanho normal.)
  4. Configure o Text File Input:
    1. Insira ${Internal.Transformation.Filename.Directory}/../../tomcat/logs/pentaho.log no campo File/Directory da seção Selected Files, aba File (Figura 2);

      Figura 2: configurando o arquivo. (Clique para tamanho normal.)
      Figura 2: Configurando o arquivo. (Clique para tamanho normal.)
    2. Aba Content (Figura 3), campo Filetype: CSV; campo Separator: §§§ (ou qualquer coisa que dificilmente aparecerá no log); desligar o checkbox Header; Format Unix (Linux e Mac) ou DOS (Windows); Encoding UTF-8;

      Figura 3: configurando a interpretação do arquivo. (Clique para tamanho normal.)
      Figura 3: Configurando a interpretação do arquivo. (Clique para tamanho normal.)
    3. Aba Fields (ignore todas as outras): registre um campo chamado log_line como Type String, deixando todos os outros parâmetros vazios.
  5. Dummy: apenas mude o nome para Saida (sem acento);
  6. Salve dentro da pasta Beltrano, em ./biserver-ce/pentaho-solutions/Beltrano.

Essa transformação vai ler o arquivo de log independentemente de onde estiver o BI Server, porque se refere ao arquivo de maneira relativa, apontando para o ./tomcat/logs a partir de dois diretórios acima do pentaho-solutions /beltrano. (Nota: talvez no Windows seja preciso reverter a barra, mas teste antes.)

Segunda parte: executando a transformação a partir do BI Server, para o qual temos duas opções. A primeira e mais trivial é usando um relatório criado com o PRD:

  1. Rode o PRD e crie um novo relatório e salve-o (já, senão pode dar erro) na mesma pasta da transformação, ou seja, na Beltrano dentro do BI Server;
  2. Clique com o botão da direita no cilindro amarelo (aba Data) e selecione Pentaho Data Integration;
  3. Na janela que se abrirá (Figura 4) clique em Browse e selecione a transformação – que deve estar no mesmo diretório;

    Selecionando uma transformação como fonte do relatório.
    Figura 4: Selecionando uma transformação como fonte do relatório.
  4. No que a janela de seleção se fechar, os passos da transformação serão listados. Clique em Saida e depois em Ok;
  5. Voltamos à lona, para construir o relatório (Figura 5). Sem estresse: arraste o campo log_field para a banda Details;

    Posicionando e configurando o campo. (Clique para tamanho natural.)
    Figura 5: Posicionando e configurando o campo. (Clique para tamanho natural.)
  6. Posicione o campo no extremo esquedo e alargue-o até ocupar a folha inteira;
  7. Com o campo selecionado, mude para a aba Structure, sub-aba Style. Localize a propriedade Dynamic Height e sete-a para TRUE;
  8. Para ficar bonito, acesse o menu File, opção Report Properties (e aba Descriptio na janela que se abrir) e preencha o título (algo como “Log”, mas sem as aspas… ;-) );
  9. Salve, faça login no BI Server, comande um refresh e execute o relatório.

Se tudo deu certo vai aparecer a Figura 6:

Examinando o log do BI Server via relatório dentro do BI Server.
Examinando o log do BI Server via relatório dentro do BI Server.

Veja que estamos acessando um dos arquivos do diretório de logs do BI Server e que podemos usar o mesmo método para qualquer arquivo. Não apenas isso, mas como estamos usando uma transformação em um relatótio, podemos combinar as capacidades dos dois e adicionar (por exemplo), filtros por data e hora, horizonte (quanto do log mostrar) etc.

A outra maneira é rodando uma XAction, que eu vou publicar em em 15/8/13. Até lá você pode obter o pacote relatório + transformação no site de projetos de BI livres: https://sourceforge.net/projects/openbisolutions/files/Logs/. Basta descompactar o arquivo dentro do seu pentaho-solutions/Beltrano (ou qualquer outra pasta) e atualizar seu BI Server. Deixe um comentário aqui se tiver algum problema.

Exportando Dados com BI Server

O Pentaho é uma plataforma de construção de soluções de BI. Ele atende muitas necessidades, cada qual de uma maneira. Para quem está acostumado com o MicroStrategy, por exemplo, pode ficar um pouco chocado – como, não é só fazer um relatório? Pois é, o Pentaho faz bem mais coisas que “relatórios” e hoje eu vou mostrar aqui um truque eu aprendi com o (blog do) Nicholas Goodman, neste post. O site do blog dele, aparentemente, sumiu e esse é um dos motivos que me levou a postar aqui a mesma coisa. Repare que esse mesmo post também existe no fórum da Pentaho, neste link, ainda que sem as imagens ou arquivos.

O Problema

… é simples: seu usuário precisa “extrair os dados” da sua base (um DW, possivelmente) para usá-los em alguma outra atividade. Bom, seu cliente deveria gastar mais tempo com você e desenharem juntos uma solução com o Pentaho. Mas já que ele prefere ter mesmo tudo nas próprias mãos, vamos dar a ele a solução Pentaho que faz exatamente isso: baixa um pacotão com os dados extraídos do(s) banco(s).

A Solução

… é simples, também: vamos criar uma XAction no BI Server que, ao ser executada, baixa um arquivo de dados formatos em CSV. O “projeto” da solução é o seguinte:

  1. Usando o Spoon construa uma transformação que recupera os dados desejados. Por isso eu escrevi fontes de dados, no plural: com o PDI você pode combinar quantas quiser e ainda montar alguma coisa em cima;
  2. Crie a área de depósito, ou landing zone, na qual vamos deixar o arquivo que o usuário vai recuperar.
  3. Vá até o BI Server e crie uma nova solução (pasta de nível zero);
  4. Coloque a transformação dentro desta pasta;
  5. Construa a XAction que executa a transformação e devolve o arquivo.

A Implementação

Vamos passo-a-passo, mas eu preciso partir de um mínimo. Eu vou assumir que você:

  • Já sabe usar o PDI (a.k.a. Kettle) para construir transformações;
  • Consegue configurar e usar um BI Server, incluindo adicionar drivers;
  • Sabe usar o Pentaho Design Studio para construir e implantar XActions.

Se você ainda não sabe alguma dessas coisas deixe um comentário que darei algumas dicas, ou me procure no Linkedin (Fábio de Salles).

Primeira Passo: Construindo a Consulta

Digamos que meu cliente, que é o Analista de Data Mining da Beltrano S/A (a empresa que usamos no livro) e quer uma listagem com todos os atributos dos pedidos, extraídos diretamente da base transacional (beltrano_oltp). Ele me deu o SQL, que é:

SELECT
pedidos.data_pedido,
pedidos.cliente_tipo,
pedidos.pagamento_tipo,
pedidos_detalhes.quantidade,
pedidos_detalhes.desconto,
pedidos_detalhes.total_item,
pedidos_detalhes.preco_unitario,
turmas.data_turma,
cursos.curso_nome,
cursos.duracao_total,
cursos.duracao_aula,
cursos.vagas,
cursos.preco_vaga,
pedidos.cliente_id,
pedidos.pedido_id
FROM
public.cursos,
public.pedidos,
public.turmas,
public.pedidos_detalhes
WHERE
pedidos.pedido_id = pedidos_detalhes.pedido_id AND
turmas.curso_id = cursos.curso_id AND
pedidos_detalhes.turma_id = turmas.turma_id;

De posse desse SQL eu crio uma transformação que executa-o e grava o resultado em um arquivo CSV, zipado para ocupar menos espaço e testo: (ops! minha base estava vazia quando eu fiz esse screenshot!)

Transformação pronta e funcionando!
Transformação pronta e funcionando!

Beleza, funcionou, etapa um pronta.

Segundo Passo: Preparando o BI Server

Em uma instalação padrão do BI Server (estou usando a 4.8), equipado com driver para meu banco (um Postgres), eu crio o diretório que vai receber o arquivo. Meu BI Server fica em /opt/pentaho/4.8/biserver-ce. Entro em tomcat, webapps e crio uma pasta chamada lz:

Pasta lz criada.
Pasta lz criada.

Agora eu subo o BI Server, faço login como joe e crio uma solução (=nome de pasta no nível zero):

Criada a solução na qual o cliente vai recuperar os dados.
Criada a solução na qual o cliente vai recuperar os dados.

Finalmente, eu volto à transformação e coloco como diretório do arquivo de saída a nova pasta lz, /opt/pentaho/4.8/biserver-ce/tomcat/webapps/lz:

Incluído diretório de saída da extração.
Incluído diretório de saída da extração.

Pronto, segunda etapa feita.

Terceira Etapa – XAction exporta_dados

Abra o Design Studio (estou usando o 4.0.0), aponte para o pentaho-solutions do BI Server 4.8 e crie uma nova XAction:

  1. Configure o PDS para apontar para ./biserver-ce/pentaho-solutions;
  2. Na pasta (solução) Exportacao de Dados crie uma nova XAction: clique com o botão da direita na pasta e selecione BI PlatformNew Action Sequence. Dê um nome (eu chamei de exporta_dados);
  3. Preencha a ficha de identificação com o que bem entender, apenas evite acentos e cedilhas;
  4. Mude para aba 2 (Define Process);
  5. Clique com o botão da direita sobre Inputs e selecione AddString;
    1. Nomeie a nova variável como redirect_uri;
    2. Ligue o check-box Has default value;
    3. Preencha o valor dela com o caminho do arquivo dentro da solução lz: /lz/dados.zip;
  6. Clique com o botão da direita sobre a área das Process Actions e selecione AddGet Data FromPentaho Data Integration;
    1. Clique sobre a nova Process Action e altere seu nome; eu mudei para Extrai para arquivo.
    2. Coloque o caminho da transformação em relação à solução (solution:/exporta_dados.ktr), no campo Transformation file;
    3. Ajuste apenas o Kettle logging level. Eu deixei em Minimal;
  7. Finalmente, adicione o comando que vai redirecionar o navegador para o arquivo que a transformação vai criar:
    1. Clique o sinal de + azul que existe na seção Process Outputs, e selecione a variável que criamos antes: redirect_uri;
    2. Clique sobre a variável, para selecioná-la, e clique no sinal de + azul, na folha de propriedades da variável de saída, e selecione response: redirect_uri;
    3. Dê um duplo-clique sobre redirect_uri e altere para redirect, apenas;
  8. Salve.
Adicionando saída que redireciona o navegador.
Adicionando saída que redireciona o navegador.

Para não ficar dúvidas:

Variável de saída redirect_uri.
Variável de saída redirect_uri.

E

Configuração da Action Sequence de transformação.
Configuração da Action Sequence de transformação.

Atualize o BI Server, para ele recarregar a XAction. Dê um duplo clique nela e veja a mágica acontecer: seu navegador vai dizer que tem um arquivo ZIP para baixar.

Dados, Trasnformação, Ação!
Dados, Trasnformação, Ação!

Voi là! Abra o arquivo e veja seu conteúdo: um CSV com os dados pedidos.

Conclusão

Por ser uma plataforma de BI e não uma ferramenta de visualização de dados OU de ETL OU de Data Mining OU … OU … etc., o Pentaho pode entregar muito mais que só relatórios. Certifique-se realizar uma entrevista detalhada e de explorar a necessidade e o uso que seu cliente vai dar ao projeto de BI, pois há muito mais ações entre o DW e os Dashboards que supõem nossos vãos relatórios.

Acidentalmente F2 Kettle Properties

De vez em quando um acidente nos dá um presente. Eu ia apertar “2” no teclado e meu embotado cérebro de fim-de-ano levou o dedo direto no “F2.” No milisegundo entre me tocar do erro e algo acontecer eu esperava que nada ocorresse, ou viesse uma mensagem de erro. Mas não, o que aconteceu foi o Spoon me mostrar essa tela:

Tela de entrada e edição de variáveis de ambiente no Spoon
Tela de entrada e edição de variáveis de ambiente no Spoon

É isso mesmo! Apertar F2 no Spoon (a interface gráfica do Pentaho Data Integration – ambos eternamente confundidos com o Kettle, antigo nome do PDI) mostra uma tela para editar as variáveis de ambiente do PDI! Basta clicar com o botão da direita do mouse sobre qualquer linha e selecionar “Insert before…” para criar uma nova variável. Assim que o Spoon é fechado, o arquivo de variáveis é regravado, e inclui quaisquer novas variáveis que você tenha criado.

Quaisquer novas variáveis usadas pelo PDI devem ser incluídas no kettle.properties. Quando estamos criando algo e descobrimos a necessidade por uma nova variável, devemos incluí-la no kettle.properties e recarregar o Spoon, para que ela seja carregada. Ou então devemos entrar a variável na tela de lançamento da transformação (que aparece quando você clica o botão de play ou aperta F9.) O primeiro te obriga a reabrir o Spoon quando precisar de uma nova variável. O segundo enche a paciência de cara, por te obrigar a (no mínimo) colar o mesmo parâmetro todas as vezes em que testar a tranformação.

Usando a tecla F2 Escapamos de editar o kettle.properties e restartar o Spoon, e da chateação que é inserir a variável o tempo todo na tela de execução da transformação!

E foi um acidente!

A Vantagem do Visual

Recebi o pedido de um post:

Fábio, você poderia fazer um post sobre sua experiência no pentaho referente a performance? Desenvolvo um projeto onde eu prefiro realizar todas as transformações via query e percebi que você utiliza os componentes do pentaho para fazer o mesmo. Como tenho poucos dados de testes quando vou testar a performance de ambos acaba dando quase o mesmo resultado em questão de tempo.

E é claro que eu vou atender. ;-)

Comparar ou Não Comparar, Eis a Questão

Suponha que eu escolha, como um exemplo para medir essa performance, copiar uma tabela para outra, no mesmo banco:

  • A query ganharia, já que nada bate uma cópia interna, de uma tabela para outra, dentro do mesmo banco.
  • Se a cópia fosse entre dois bancos diferentes, na mesma máquina, ainda seria muito rápido, mas acho que precisaria apelar para uma linguagem do banco, ou algum recurso não-padrão para que o SELECT em um banco sirva de entrada para o INTO em outro. Imagino que a consulta ainda bateria o PDI.
  • Agora, se a cópia fosse entre duas máquinas diferentes, talvez houvesse um empate porque a rede entre as máquinas passaria a ser um gargalo. Como os dois recursos (query e PDI) normalmente são muito mais rápido que a maioria das redes, a velocidade final seria limitada pela velocidade da rede, e daria empate.

Se eu escolhesse ler um arquivo e carregar no banco, os fatores envolvidos seriam outros e os resultados desse caso não teriam nenhuma relação com os resultados do caso anterior, da cópia entre duas tabelas. Se fosse um join, outro resultado. Se fosse um lookup em banco a partir de um arquivo, outro resultado. Etc. etc. etc. e assim por diante.

Ou seja, os resultados de uma comparação desse tipo seriam inconclusivos, pois oscilariam entre vantagem ora de um método, ora de outro.

Vendo Vantagem

Então tanto faz? A performance, na média, vai ser sempre a mesma para qualquer tecnologia?

Nem de longe. A comparação direta de performance entre as duas técnicas (PDI e SQL) pode ser uma medida muito difícil, mas não deve ser importante para optar por uma ou por outra. O que deve nortear sua escolha é, como sempre, o custo-benefício.

Se as suas transformações só envolvem bancos de dados, todos do mesmo tipo, pode ser que seja mais fácil desenvolvê-las usando SQL – já está tudo ali mesmo, e rodar SQLs diretamente no banco pode dar muito menos trabalho que baixar o PDI, configurar uma máquina, desenvolver as transformações e agendâ-las em produção.

Se o seu processo envolve arquivos (talvez em um servidor remoto), bancos (de diversos tipos), uma área de transferência temporária (palco ou stage) etc. etc. etc., desenvolvê-lo usando SQL pode ser tão complexo quanto construir uma nova aplicação do zero. Num caso desses, usar o PDI pode até redundar na mesma performance, mas o desenvolvimento desse processo será – eu te garanto – muito menos trabalhoso. Sua produtividade tende a ser mais alta com o PDI que com uma linguagem de programação.

Conclusão

A performance de cada processo depende de um sem-números de fatores, e o critério para você fazer uma escolha entre as tecnologias possíveis, em princípio, é o custo de cada uma dessas opções, comparado com o retorno que elas vão te dar.

Como o PDI permite desenhar todo processo graficamente, “ligando os passos”, um analista produz muito mais usando o PDI que desenvolvendo um programa em alguma linguagem.

Mas e a performance, Fábio? Afinal, qual eu devo escolher se a performance for importante? PDI ou Query?

PDI, sem sombra de dúvida. Porquê? Porque o PDI oferece muitos mecanismos para melhoria da performance do processo e você fatalmente vai conseguir a performance que precisa, a uma fração da complexidade do desenvolvimento de queries.

É isso.

Hackeando Transformações

Ocasionalmente precisamos alterar o volume de linhas lido de um banco por um Table Input, numa tranformação, para testar o processo inteiro. Se você tem apenas uma transformação, isso é fácil – basta abrir a transformação com o Spoon, alterar e testar.

E quando você acabou de montar o ETL inteiro, criou o job e ele vai levar algumas horas para rodar completamente? Cada teste de ponta-a-ponta pode levar algumas horas, e nós nunca queremos esperar horas para descobrir um erro numa RegEx no meio da última transformação. Não, especialmente quando não dá para rodar uma só de cada vez, mas precisamos rodar todas na sequência. E foi isso que me aconteceu: eu precisava testar a carga de certas variáveis e ver se todas as transformações de um ETL estavam tratando as variáveis corretas.

Eu poderia deixar o processo rodar e, a cada erro (que poderia ou não existir) eu corrigiria e reiniciaria tudo. Bummer! Horas para descobrir se havia erro, e mais horas para ter certeza que o consertara! Não, precisava haver uma forma melhor.

Como os arquivos eram todos texto (eu sempre salvo meus ETL em arquivo, raramente uso o repositório do PDI), eu tinha outra saída: um comando de linha que alterasse cada arquivo, mudando o limite de leitura de cada Table Input de 0 (infinitas linhas) para, por exemplo, 1000. Pedi ajuda a um grande e famoso (Wikipedia!!) amigo, Júlio Neves, que me deu o seguinte comando:

sed -i ‘s-<limit>0</limit>-<limit>1000</limit>-‘ *.ktr

Ele usa o Sed para alterar o parâmetro diretamente nos arquivos das transformações. Assim, com um comando de uma única e miseravelmente curta linha eu alterei o projeto todo!

Depois de finalizado o teste, o comando “reverso” leva o projeto de volta a seu estado original:

sed -i ‘s-<limit>1000</limit>-<limit>0</limit>-‘ *.ktr

Ou eu poderia simplesmente jogar as novas transformações fora e puxar do repositório de novo.

Observação: o Sed é um programa que faz parte da maioria (se não de todas) as distribuições Linux/Unix. Mas você pode tê-lo no Windows também. Basta instalar o Cygwin. É um pouco chato, para quem nunca mexeu com Linux, mas o poder que ela traz é proporcional. Vale a pena!