Planos para 2013

Com o excelente ano de 2012 acabando – e eu em merecidas férias – é hora de pensar no que fazer em 2013. Essa é uma pequena lista de coias que eu pretendo abordar no ano que vem:

  1. Data Vault: acabei de ler o livro e estou fazendo uns testes. Podem contar como um dos meus próximos tópicos.
  2. Banco colunar: o LuciDB é um banco de dados especial para Data Warehouses, e passou da hora de eu fazer alguns testes nele. Já tenho o post bolado, só preciso implementar e medir os resultados.
  3. PostgreSQL 9.2: ele veio com algumas mudanças interessantes para Data Warehouse. Vou testá-lo e compará-lo com o LuciDB.
  4. Infobright: outro banco colunar dedicado a Data Warehouses, mas derivado do MySQL. Mesma vontade: comparar com Postgres 9.2 e LuciDB.
  5. Bonita: eu mantenho um blog sobre o Bonita Open Solution, uma solução de BPM livre e fantástica – o Pentaho do BPMS. Eu estou trabalhando numa séries de posts para testá-lo e pretendo construir uma solução de BI sobre o meu processo.
  6. Pré-Agregadas: já faz uns anos que eu quero escrever um artigo completo sobre isso. Quem sabe dessa vez vai?

Isso é o que está na minha lista, mas outras coisas devem vir. Por exemplo, quero completar a solução de BI do Apache , li um livro sobre dashboards que me deixou com algumas idéias e estou lendo um livro sobre Data Mining do qual vou testar algumas coisas também. E, é claro, conto com sugestões de vocês sobre quaisquer assuntos relacionados à BI.

Feliz Natal e Próspero Ano Novo!

Até 2013!

Anúncios

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.