Eleições Inteligentes

Agora que estamos na época, diga-me: como você escolhe seu candidato às eleições?

Essa é uma escolha pessoal (mas de arrependimento coletivo :-) ) e não tem uma fórmula. Cada um vota de acordo com sua consciência e opinião.

Não deixa de ser curioso, portanto, os argumentos que cada político apõe à sua campanha. Um dos candidatos a vereador em São Paulo, por exemplo, promete acompanhar de perto os gastos públicos. Para dar um exemplo do que está falando, ele soltou uma lista das emendas aprovados na câmara dos vereadores, que geraram despesas.


Hmmm… Dados tabulados… Planilha…


É claro que eu não pude resistir e, morando em São Paulo, eu tinha que fazer um exame mais visual desses dados.

Assim Não Vai Rolar…

Eu poderia usar o Calc (=Excel do LibreOffice) ou qualquer outra ferramenta. Optei pelo [BA Server 5.4][ba54] que me permite importar um arquivo CSV e montar um cubo. Assim eu poderia examinar os dados e montar um post para o blog. Eu estava farejando um caso neste assunto.

Eu me propus a uma tarefa muito simples:


Examinar os gastos das emendas de vereadores, no período 2013-2015, contra as principais dimensões: Vereador, Destino da Verba e Tempo.


Não queria achar nenhum padrão oculto nem nada, apenas exercitar um pouco de ETL/OLAP com o Pentaho e aproveitar para ver como o dinheiro está sendo gasto.

Expertei a planilha para CSV e importei no BA Server usando o wizard de nova fonte de dados. Isso me deixou com um cubo OLAP, “pronto” para explorar.

Primeira Visão: Por Vereador

Coloquei entre aspas porque estava pronto coisíssima nenhuma. Vejam:

Valor de emenda aprovada, quebrado por vereador.
Valor de emenda aprovada, quebrado por vereador.

O nome do verador pode aparecer de mais de uma forma, resultando em linhas que não são agregadas. Assim parece que temos dois vereadores “tipo Netinho”, cada qual com um total de gastos, quando na verdade é um só político:

Vereador Gasto
Netinho de Paula 180.000,00
Netinho De Paula 660.000,00
Netinho de Paula”_” 560.000,00

O “_” é para indicar que o nome possui um espaço extra ao final, dando três “nomes” diferentes para a mesma pessoa.

E apesar de o objetivo ser examinar os valores por vereador, se eu quisesse ver por partido, quantidade de votos etc. não daria, pois essa informação não consta na planilha.

Segunda Visão: Por Objeto

Vamos lá:

Valor de emenda aprovada, quebrado por objeto, i.e. destino da verba.
Valor de emenda aprovada, quebrado por objeto, i.e. destino da verba.

Nossa, pior ainda! Até há um padrão de nomes, mas não é consistente (nomes duplicados de formas diferentes, como no caso dos vereadores) nem prático (não dá para analisar um gráfico com um item “Reforma do CDC Moinho Velho, no bairro do Ipiranga, incluindo troca do piso do salão de festas, do salão sede, do vestiário e sanitários, troca do telhado, instalação de forro de gesso no salão de festas, reforma da parte elétrica/luminárias, além de pintura geral – Rua Elba 980 – Ipiranga”!!)

E também não dá para separar por categorias, como Saúde, Esporte, Reforma, Compra etc. Até temos que orgão recebeu o dinheiro, mas não vai além disso. Não dá para, por exemplo, comparar os gastos de subprefeituras com secretarias municipais.

Terceira Visão: Por Ano

Até temos um padrão melhor, graças ao fato de termos uma coluna só para ano:

Valor de emenda aprovada, quebrado por ano.
Valor de emenda aprovada, quebrado por ano.

… mas não dá para quebrar por mês, por exemplo, ou para saber qual dia da semana tem mais aprovações.

Também não dá para quebrar por região da cidade ou qualquer outro parâmetro, como quantidade de eleitores, por exemplo. Imagine saber quais são os projetos que atendem mais pessoas? Será que tem algum padrão bairrista, onde somas vultosas são gastas com projetos populistas, mas de baixa serventia pública? Isto é, que é bonito pra chuchu, mas atende pouca gente?

Data Quality To The Rescue!

Eu sempre quis fazer um post com exemplos de Data Quality, e estava apostando que esta planilha seria um bom caso.

Há uma renca infinita de operações e técnicas de limpeza de dados, mas na maior parte dos projetos sempre usamos as mesmas técnicas. Duas destas técnicas mais frequentes são muito úteis, e se aplicam diretamente ao ETL: normatização e classificação dos dados.

Por exemplo, o “multi-vereador” que vimos acima passaria a ter um único nome, e as agregações passariam a funcionar. Isso é normatização: damos uma norma aos membros de um conjunto, que obtemos montando – manual ou automaticamente – um dicionário para traduzir todas as formas de cada elemento em uma forma só.

Já a classificação é uma técnica que automatica extrai atributos de um certo elemento. Por exemplo, podemos usar a data, que existe na planilha, para conseguir as informações de mês e dia da aprovação do gasto.

Em outro exemplo, podemos fazer buscas por textos específicos em cada linha tratada, e assim gerar uma classificação automática para os dados. Vou usar essa técnica para tratar os objetos de cada emenda, e descobrir se pertencem à área da Saúde, Esporte ou Cultura, se são Melhorias ou Compras e assim por diante.

Vamos lá.

Normatização com Dicionários

Com relação ao nome dos vereadores, precisamos montar um dicionário que “traduz” cada variação de nome para um padrão. E já que estamos nesta, podemos fazer um pouco mais: podemos enriquecer essa planilha com outros dados do vereador, como partido, quantidade de votos conquistados etc.

Na verdade podemos fazer a mesma coisa com tudo nesta planilha:

  • Orgão: tipo (Secretaria, Subprefeitura, Autarquia etc.);
  • Região da cidade atendida: Centro, Sul, Leste, Oeste, Norte;
  • Objeto: usufrutuário, prazos etc.

Imagino que a Câmara dos Vereadores registre esses e muitos outros atributos em seus sistemas, mas o que temos é só essa planilha e por isso não dá para extrapolar demais.


O nome do vereador na planilha original vem com maiúsculas e minúsculas. A primeira coisa mais fácil a fazer é mudar todos para caixa baixa ou alta – prefiro alta.

Daí podemos pegar o partido, votação etc. do vereador em algum site. Eu achei uma página do UOL sobre as eleições de 2012 que trazia tudo: nome do vereador, partido e quantidade de votos. Com isso tudo em mãos eu construí uma planilha Excel com o seguinte layout:

Coluna Função
VEREADOR_ORIGINAL Nome do vereador na planilha original
VEREADOR_CORRIGIDO Nome corrigido
PARTIDO Partido pelo qual ganhou a eleição
VOTOS Quantidade de votos recebidos pelo vereador
VOTOS PARTIDO Quantidade de votos recebidos pela legenda

A tabela abaixo mostra como essa tabela foi preenchida:

VEREADOR_ORIGINAL VEREADOR_CORRIGIDO PARTIDO VOTOS
Abou Anni ABOU ANNI PV 
Adilson Amadeu ADILSON AMADEU  PTB  40100
Adolfo Quintas ADOLFO QUINTAS PSDB 
Alessandro Guedes ALESSANDRO GUEDES PT 
Alfredinho Alfredo Alves Cavalcante (ALFREDINHO) PT  36634
Andrea Matarazzo ANDREA MATARAZZO  PSDB  117617

Porque há casos de nenhum voto? Não sei. Provavelmente é um vereador suplente, que não constava na lista que eu usei. Dá para corrigir, mas o propósito deste post é exemplificar algumas técnicas de Data Quality e por isso não me preocupa se sobrar algumas lacunas.


Depois eu fiz mais duas colunas: faixa_votos_1 e faixa_votos_2. A primeira qualifica o vereador em faixas de 10.000 em 10.000 votos. A segunda faz uma divisão em três categorias: menos de 50.000 votos, entre 50.000 e 100.000 votos, e uma última de mais de 100.000 votos.

Depois eu apliquei a mesma idéia para o orgão e criei este dicionário:

Coluna Função

| ORGAO_EXECUTOR_ORIGINAL | Orgão na planilha original |
| ORGAO_EXECUTOR_CORRIGIDO | Nome do orgão corrigido |
| TIPO_ORGAO | Tipo: secretaria, autarquia etc. |
| REGIAO_CIDADE | Região que atende, ou Geral quando não tem |

Que, preenchido à mão, ficou assim:

ORGAO_EXECUTOR_ORIGINAL ORGAO_EXECUTOR_CORRIGIDO TIPO_ORGAO REGIAO_CIDADE
Autarquia Hospitalar Municipal AUTARQUIA HOSPITALAR MUNICIPAL AUTARQUIA GERAL
Fundo de Preservação do Patrimônio Histórico e Cultural FUNDO DE PRESERVAÇÃO DO PATRIMÔNIO HISTÓRICO E CULTURAL FUNDO GERAL
Fundo Municipal de Assistência Social FUNDO MUNICIPAL DE ASSISTÊNCIA SOCIAL FUNDO GERAL
Secretaria Municipal de Coordenação das Subprefeituras SECRETARIA MUNICIPAL DE COORDENAÇÃO DAS SUBPREFEITURAS SECRETARIA MUNICIPAL GERAL
Secretaria Municipal do Verde e do Meio Ambiente SECRETARIA MUNICIPAL DO VERDE E DO MEIO AMBIENTE SECRETARIA MUNICIPAL GERAL
Serviço Funerário do Município de São Paulo SERVIÇO FUNERÁRIO DO MUNICÍPIO DE SÃO PAULO AUTARQUIA GERAL
Subprefeitura Pinheiros SUBPREFEITURA PINHEIROS SUBPREFEITURA OESTE
Subprefeitura Sé SUBPREFEITURA SÉ SUBPREFEITURA CENTRO
Subprefeitura Vila Mariana SUBPREFEITURA VILA MARIANA SUBPREFEITURA SUL
Subprefeitura Vila Maria/Vila Guilherme SUBPREFEITURA VILA MARIA/VILA GUILHERME SUBPREFEITURA NORTE
Subprefeitura Vila Prudente/Sapopemba SUBPREFEITURA VILA PRUDENTE SUBPREFEITURA LESTE

Classificação Automática

Resolvidas essas dimensões, restou apenas o objeto de cada emenda. O que contém a lista de objetos de emendas? Coisas assim:

  • Contenção Margem com Gabiões – Rua Magdeburgo – Processo nº 2013-0.102.577-8;
  • Readequação área de lazer Rua Constantino Cavafi – Processo nº 2013-0.102.541-7;
  • 26º Campeonato de Moto Aquática – Jet Ski – Associação Brasileira de Jet Ski Profissional e Não Profissional;
  • E172 – Realização de Duas Etapas da Copa São Paulo de Jet Ski na Represa do Guarapiranga;
  • Execução de Obras de microdrenagem nas Ruas Rodrigues dos Santos, joão Teodoro e Ruas limitrofes no Bairro do Brás;
  • Associação Beneficente Nossa Senhora do Pari – Melhorias e Ampliação de Atendimento para adequação, ampliação e reforma do mobiliário e equipamentos hospitalares referente ao setor de Nutrição e Dietética;

E assim por diante. A única forma de fazer uma classificação precisa, bem-feita, é manualmente. São quase 1.800 projetos aprovados. Se eu levar um minuto para qualificar cada um, são 1.800 minutos ou 30 horas trabalhando sem parar.

No $%#%!@% way.

Logo, ou achamos o sistema de origem e vemos o que mais dá para puxar, ou montamos uma aproximação. Por exemplo, podemos montar uma tabela com uma coluna para cada atributo, como “É uma compra de material/produto?”, “É um pagamento de serviço?”, “É um gasto com saúde?” e por aí vamos. Daí, para cada objeto que entrar nesta tabela na primeira coluna, respondemos as perguntas em outras colunas. No final teríamos algo assim:

Objeto Compra? Cultura? Saúde? Esportes?
E2538 – Fundação Antonio Prudente(…) Não Não Sim Não
Implantação de equipamento de Ginástica (…) Sim Não Não Sim
Realização de obras e pavimentação de vias, visando a melhoria (…) Não Não Não Não
Incentivo à pratica de esportes Não Não Não Sim

Isso permitiria uma classificação rudimentar, inicial, que desse ao menos uma visão geral. Com ela podemos responder perguntas como “quanto do gasto é compra de material novo, e quanto é manutenção?” Ou “quanto estamos alocando de dinheiro para Saúde, Educação e Lazer?”

Uma forma de se fazer seria colocar essas linhas em uma planilha Calc e uma coluna para cada pergunta. Daí, usando fórmulas como IF() e FIND(), buscamos as ocorrências de termos-chaves. Sempre que encontrarmos um, marcamos com “SIM”. Se não encontramos nada, com “NÃO”.

E, de fato, foi a primeira coisa que eu fiz:

Primeira tentativa de qualificar os objetos.
Primeira tentativa de qualificar os objetos.

Era uma solução muito tosca, mas me ajudou a entender a mecânica da coisa. Com isso eu pude subir para o nível seguinte: usar RegEx, isto é, Expressões Regulares para fazer essa detecção. Usando expressões regulares eu poderia montar um processo de detecção automático e mais robusto que uma planilha Excel.

Assim, aproveitei o que eu aprendi com o livro RegEx Com Python e, com o auxílio do passo Regex Evaluation consegui extrair essa informações do nome do objeto de cada emenda parlamentar.


Eu parei de criar atributos e de refinar minhas RegExes quando comecei a ter um resultado aproveitável, mas poderia ter ido mais longe e conseguido bem mais coisa – até mesmo reconstruir a descrição da emenda aprovada. Mas, de novo, não era essa a meta e por isso não avancei.


Transformação Eleições 2016

A figura abaixo dá a visão geral da transformação que lê a planilha e gera um CSV pronto para importação no BA Server:

Transformação que incrementa a qualidade dos dados da planilha.
Transformação que incrementa a qualidade dos dados da planilha.

Essa transformação, e todos os dicionários, resultados e um pouco mais, estão disponíveis para download aqui, como um zip. Descompacte em um diretório qualquer e abra os arquivos .KTR com o Spoon do PDI 5.4. Falarei mais sobre a outra transformação na Conclusão.

Agora Sim!

Muito bem, com um novo e melhorado conjunto de dados, recarreguei o CSV no BA Server e gastei um tempinho refinando o mapeamento. Vejamos o que podemos fazer agora.

Por Vereador: bem melhor! Agora dá para ver todo mundo, numa só posição.

Valores aprovados por vereadores em São Paulo, no termo 2012-2016.
Valores aprovados por vereadores em São Paulo, no termo 2012-2016.

Veja que existe apenas um vereador que aprovou menos de um milhão de Reais em emendas. Até dá para dizer que existe duas faixas:

  • Uma turma que libera muito, com totais sempre maiores que R$ 5.000.000,00;
  • E outra que é mais modesta, que fica entre os R$2M e R$4M.

Mesmo assim não temos nenhum “calombo”, que seriam vereadores que liberam (ui!) muito mais que a média (ai!). Eu diri até que eles se espalham em uma graduação mais ou menos suave.

Por Objeto: Agora sim! Mesmo sendo uma classificação incipiente, consegui ver que os dez maiores valores em gastos concentram-se em coisas que não é nem para Saúde, nem para Esportes ou para Cultura.

Valores aprovados por qualificação de objetos.
Valores aprovados por qualificação de objetos.

Os dois picos são muito curiosos… Daí eu fui olhar por orgão:

Valores aprovados por orgão.
Valores aprovados por orgão.

Uia. Quem mais recebe dinheiro de emenda parlamentar… é a Secretaria de Esportes e Lazer, mas os picos do gráfico anterior mostram que o grosso do dinheiro não vai para isso… Confuso! Com certeza culpa da classificação porca e apressada que minhas expressões regulares toscas.


Eu explorei essas visões um pouco mais do que eu vou mostrar aqui. A menos que eu tenha cometido um erro grosseiro, parece que há mesmo uma concentração de emendas para Secretaria de Esportes. Eu fiquei pensando sobre o quê explicaria isso, e bolei uma hipótese: eventos e ações voltadas para Esportes causam um impacto mais marcante, e não constumam ser caras. Assim, se um político precisa prometer algo que tenha condições de cumprir, prometer fazer um evento esportivo parece uma opção de boa relação custo-benefício.

Mas é só uma hipótese, sem nenhum embasamento sério nos fatos. Tipo assim, um chutão. ;-)


E eu continuei a cutucar os dados, até que me deparei com uma visão interessante:

Eleitores representados por gastos.
Eleitores representados por gastos.

Lemos esse gráfico assim: “O maior valor foi liberado para emendas criadas por parlamentares com representação menor que 50.000 votos”. Legal, não é? Como a maior quantidade de vereadores tem menos que 50.000 votos, ter a grana concentrada nessa parcela de políticos significa que o dinheiro está sendo empregado em projetos da maioria dos vereadores, e que são projetos de baixa representatividade, ou seja, tocados por políticos que representam poucos eleitores.


Eu sou partidário do voto distrital, e não da forma atual. Esse gráfico reforça meu viés pelo voto distrital, mas evitaria tomá-lo como uma prova inconteste da vantagem dessa opção.


Essa é uma visão difícil de ler, mas é bem curiosa:

Valores em ementas espalhados na área proporcional a cada orgão.
Valores em ementas espalhados na área proporcional a cada orgão.

Imagino que era para ser um gráfico de árvore, mas ficou meio estranho…

Ele representa o valor gasto por orgão, dentro de cada tipo (Fundo, Subprefeitura etc.) De novo, observe como parece haver alguma desproporção entre os valores alocados à Secretaria Municipal de Esporte e Lazer e, por exemplo, a de Saúde. Até a de Cultura é maior que a de saúde!

E o gasto ao longo do tempo? Não parece nada de mais, um comportamento quase aleatório:

Distribuição de valores nos meses de aprovação.
Distribuição de valores nos meses de aprovação.

Eu poderia prosseguir aqui até a próxima eleição… de 2018. Mas não é preciso tanto. ;-)

Conclusão

Diz o ditado: Lixo Entra, Lixo Sai. Análises de dados dependem de dados Limpos, bem tratados etc. Existem muitas formas de se cuidar dos dados para que eles possam nos contar a verdade por trás de si. O ramo que responde por essas técnicas chama-se Data Quality e costuma ser uma disciplina complexa.

Vimos que, mesmo sendo trabalhoso, qualquer melhoria pode render ganhos significativos. Por isso considere sempre fazer ao menos uma avaliação da qualidade dos seus dados que o cliente vai examinar.

Coceira…

Com os dados ali, prontinhos, e os assuntos separados em tópicos, eu fiquei com a mão coçando para andar mais um pouco e transformar aquilo em uma estrela dimensional. Como a melhor maneira de se livrar da tentação é ceder, eu cedi.

Peguei a transformação anterior e coloquei alguns passos que alimentam junk dimensions. Isso deu origem a dimensões instantâneas de Vereador e Orgão.

Modelo dimensional miojo: basta adicionar Junk Dimensions!
Modelo dimensional miojo: basta adicionar Junk Dimensions!

Depois eu juntei todos os atributos em uma dimensão junk de verdade, e mais adiante adicionei outra para os objetos das emendas. Eu poderia degenerá-lo mas, francamente, a idéia daquele texto todo na fato, uuhhh calafrios, não me agradou.

Por fim criei uma dimensão data completa, usando um passo Database Lookup. Pronto! Um Table Output no final, sair clicando em todos os botões SQL para criar tabelas, rodar e…. PIMBA! Tudo no ar!

Eu peguei o Power*Architect e fiz uma engenharia reversa no banco. Ajustei alguns detalhes (como os relacionamentos) e voilà! Modelo dimensional de valores de ementas!

Diagrama de tabelas da estrela Emendas Vereadores 2013-2015.
Diagrama de tabelas da estrela Emendas Vereadores 2013-2015.

Esse diagrama e a transformação que o alimenta estão no mesmo pacote deste post. Fique à vontade para brincar, explorar e descobrir. Apenas mantenha em mente o seguinte:


Eu, Fábio, não sou responsável pelo conteúdo de dados deste pacote, nem por qualquer interpretação que alguém tirar dele.

Me incluam fora dessa! ;-)


Até a próxima!

Configurando PDI para Enviar Relatórios

O Pentaho Data Integration (PDI, antigo Kettle) oferece uma quantidade de opções para se comunicar com o “mundo exterior”. Por exemplo, ele permite envio de e-mails tanto em transformações quanto em jobs por meio de passos nativos, ou mensagens por mensageria instantânea (Instant Messaging, IM) através de plug-ins.

Plug-in PDI que envia notificações a smartphones Apple ou Android.
Plug-in PDI que envia notificações a smartphones Apple ou Android.

Um uso clássico dessa capacidade é o envio de algum tipo de notificação ao final de um processo de ETL. O PDI pode mandar um e-mail para todos os interessados, informando se o processo transcorreu em ordem, ou se houve algum erro, e qual é o estado atual dos dados. Essa transformação faz isso:

Transformação que monta e envia e-mail com relatório para uma lista de destinatários.
Transformação que monta e envia e-mail com relatório para uma lista de destinatários.

Foi exatamente essa transformação que eu usei em um projeto recente, e ela funcionou perfeitamente!… Em desenvolvimento. Em outras palavras, rodava beleza quando eu a testava no Spoon, que é a interface gráfica do PDI, mas falhava fragorosamente ao rodar no ambiente de produção, via linha de comando. Depois de um pouco de tentativa e erro eu consegui resolver todos os problemas, soluções que eu divido com vocês no post de hoje.

Mudança de Ambientes

A primeira dificuldade é o fato de os bancos de dados, seus IPs, usuários e senhas serem diferentes em cada ambiente. Se em desenvolvimento o banco chama-se dw_corp, com usuário e senha postgres, em localhost:5432, em produção sem dúvida será diferente – no mínimo a política de segurança da empresa vai cuidar de ter usuário e senha “protegidos”, i.e., que só o gestor do processo em produção sabe qual é.

Resolvemos essa dificuldade parametrizando toda e qualquer referência ao banco de dados (e por extensão a diretórios, servidores de apoio etc.)

Conexão PDI

Parametrizar uma conexão PDI é simples: basta usar variáveis para registrar os valores de parâmetro de uma conexão. A figura abaixo mostra uma conexão com o banco Beltrano OLTP parametrizada:

Conexão PDI parametrizada.
Conexão PDI parametrizada.

Daí é só registrar essas variáveis e seus valores no arquivo kettle.properties, que fica dentro do diretório .kettle, na raiz do usuário. Seu ambiente de desenvolvimento terá valores para o PDI acessar os seus bancos, enquanto que em produção deve existir um arquivo análogo, configurado adequadamente para esse ambiente, pelo próprio gestor da máquina de produção.

Conexão PRD

Eu queria enviar relatórios bonitos, bem formatados, e não um simples arquivo texto com algumas contagens e por isso eu usei o Pentaho Report Designer. Daí, de cara eu sabia que teria o mesmo problema: valores de conexão diferentes para cada ambiente. Infelizmente, porém, o PRD não pode usar as mesmas variáveis que o PDI usa. Não dá para colocar o mesmo ${BELTRANO_OLTP_HOST} da conexão do PDI no PRD, mas dá para usar uma fonte de dados JNDI, que é um tipo de conexão disponível por meio do ambiente Java.


Eu tive sorte em descobrir como usar JNDI. Nem pense em me perguntar o que é ou como funciona…


Definir uma fonte JNDI no PRD é simples: apenas selecione esse tipo e forneça um nome:

Conexão JNDI no relatório PRD.
Conexão JNDI no relatório PRD.

E onde são registradas os parâmetros de uma conexão JNDI? No arquivo default.properties, dentro do diretório /home/<USUÁRI>/.pentaho/simple-jndi, neste formato:

NomeJNDI/type=javax.sql.DataSource
NomeJNDI/driver=org.postgresql.Driver
NomeJNDI/user=postgres
NomeJNDI/password=postgres
NomeJNDI/url=jdbc:postgresql://EnderecoServidor:5432/NomeDoBanco

Os itens driver e url são particulares de cada banco. O restante é sempre igual.

Parametrizando o PRD no PDI

Com a parametrização do PDI e do PRD eu conseguia montar e rodar processos e relatórios nos dois ambientes sem me preocupar com mais nada, desde que cada um rodasse independentemente do outro. Ou seja, uma transformação executada pelo PDI, e um relatório pelo PRD – no máximo dentro do servidor Pentaho.

Mas eu queria rodar o relatório a partir do PDI!

O primeiro obstáculo foi fácil: onde eu definiria a conexão JNDI do PDI, que – pela simples definição de JNDI – seria repassada a um PRD disparado a partir do PDI? No arquivo jdbc.properties, na pasta ./data-integration/simple-jndi. Basta copiar para ali a definição do outro default.properties, e lembrar de fazer a mesma coisa no ambiente de produção.

Parametrizando o Parametrizador

Ah, se fosse tudo tão lógico e simples!

Foi aqui que a porca torceu o rabo: em desenvolvimento, na interfave gráfica, todas as variáveis eram “vistas” pelo Spoon por default – todas as definições JNDI, por exemplo. Mas ao tentar rodar em produção apareceu uma mensagem nada a ver…

INFO 15-07 09:13:31,507 - Beltrano JNDI Postgres - New database connection defined
ERROR 15-07 09:13:31,534 - Count incomplete revisions - An error occurred, processing will be stopped:
Error occured while trying to connect to the database
java.io.File parameter must be a directory. [/home/users/kettle/CLIENT/simple-jndi]

Depois de cavocar o Google um pouco, eu descobri que, a partir da versão 4.1, o PDI passou a aceitar que o arquivo com as definições JNDI ficasse em qualquer lugar, e não apenas dentro do ./data-integration.

Trecho que chama o Java, dentro dos scripts. Note a variável -DKETTLE_JNDI_ROOT.
Trecho que chama o Java, dentro dos scripts. Note a variável -DKETTLE_JNDI_ROOT.

Para complicar a vida do desenvolvedor, o Spoon preenche essa variável automaticamente, apontando diretamente para o diretório que contém o arquivo de definições, mas o Kitchen e o Pan, não!

Essa modificação precisa ser feita pelo gestor do ambiente de ETL. Para definir a localização do arquivo de propriedades JNDI basta alterar a variável -DKETTLE_JNDI_ROOT,que é definida no final da chamada do Kitchen ou Pan (e até mesmo do Spoon, mas lembre-se que o Spoon faz coisa a mais), setando-o uma linha antes da chamada ao Java, desta forma:

KETTLE_JNDI_ROOT=/opt/pentaho/5.1/data-integration/simple-jndi

Note que eu apontei a variável para o meu diretório-padrão. Você deve inserir o diretório correto para sua instalação, não apenas copiar o exemplo acima, cegamente.

Pronto! Finalmente o PRD passou a rodar, parametrizado, dentro do PDI, tanto em desenvolvimento quanto em produção!


Veja este post no fórum internacional, aqui reproduzido parcialmente para o caso de ter sumido=.)*

Post do fórum Pentaho no qual é solucionado esse problema.
Post do fórum Pentaho no qual é solucionado esse problema.

Conclusão

Uma das eternas promessas da TI é oferecer gestão por exceção. Nesta modalidade, os gestores de alguma coisa são notificados quando esta alguma coisa assume um estado inadequado. Por exemplo, quando os valores de indicadores caem fora de certas faixas, ou quando um erro surge em algum sistema. Na gestão por exceção, o sistema não dá um pio enquanto tudo estiver certo, e dispara notificações quando as coisas saem dos trihos.

Ferramentas de ETL também carregam essa promessa. Dependendo do marketing, ora vende-se a idéia de avisar o gestor do processo de ETL tão cedo ocorra um erro, ou notificar os clientes que os dados foram carregados e estão pronto.

O PDI pode executar a tal gestão por exceção: basta incutir-lhe a lógica de notificação e os mecanismos de comunicação adequada. Como vimos neste post, dá para desenhar um relatório de alta qualidade, renderizá-lo em PDF e transmiti-lo por e-mail para um ou mais destinatários, sempre que uma condição desejada é atingida.

Colocar isso tudo para rodar, porém, são outros quinhentos. Neste post vimos como parametrizar tanto o relatório PRD quanto os artefatos PDI para garantir que o processo funcionará em desenvolvimento e em produção.

Até a próxima!

Analisando os Logs do PDI – Parte 3

No primeiro post da série vimos como configurar a captura de logs nos processos do PDI, e obter informações básicas sobre os resultados de um processo qualquer.

No segundo post eu mostrei como usar os dados de performance de uma transformação para “caçar” gargalos.

Na terceira e última parte vamos entender como usar as tabelas logging channel para montar um relatório que lista todas as transformações e jobs executados a partir de um job-pai.

Cenário

Eis um exemplo básico de ETL que carrega um Data Warehouse dimensional:

Job principal de refresh do DW Beltrano.
Job principal de refresh do DW Beltrano.

O job acima chama uma transformação que, como o nome diz, define as variáveis do processo, e depois segue chamando os subjobs, cada um com uma tarefa específica: atualizar dimensões, carregar fatos e por fim preencher as tabelas pré-agregadas para OLAP. Por último é chamada outra transformação que coleta informações sobre o estado do DW naquele dia.

Dentro de cada um daqueles subjobs temos uma sequência de transformações, como, por exemplo, a carga das dimensões:

Job de sequenciamento de carga das dimensões.
Job de sequenciamento de carga das dimensões.

E cada uma dessas transformações faz a real movimentação de dados:

Carga da dimensão Cliente.
Carga da dimensão Cliente.

Para sabermos se tudo funcionou precisamos consultar o log de cada uma delas. Como os jobs estão amarrados com avanços condicionais (setas verdes), se der algum problema, o processo inteiro é abortado. Isso dá alguma facilidade de monitoração. Rodando no Spoon, o erro fica aparente:

Problema no processamento das dimensões.
Problema no processamento das dimensões.

Só que em produção não temos Spoon, então precisamos examinar o log:

2016/03/19 10:44:20 - Spoon - Starting job...
2016/03/19 10:44:20 - Refresh DW Beltrano - Start of job execution
2016/03/19 10:44:20 - Refresh DW Beltrano - Starting entry [Seta Variáveis]
2016/03/19 10:44:20 - Seta Variáveis - Loading transformation from XML file [file:///home/beltrano/ETL_Beltrano/t_a_seta_variaveis.ktr]
2016/03/19 10:44:20 - BELTRANO - KTR - Seta Variáveis - Dispatching started for transformation [BELTRANO - KTR - Seta Variáveis]
2016/03/19 10:44:20 - Grava timestamp.0 - Connected to database [beltrano_dw] (commit=1000)
2016/03/19 10:44:20 - Recupera Timestamp do Refresh.0 - Finished processing (I=0, O=0, R=1, W=2, U=0, E=0)
2016/03/19 10:44:20 - Seta variável.0 - Setting environment variables...
2016/03/19 10:44:20 - Seta variável.0 - Set variable REFRESH_TIMESTAMP to value [2016/03/19 10:44:20.724]
2016/03/19 10:44:20 - Seta variável.0 - Finished after 1 rows.
2016/03/19 10:44:20 - Seta variável.0 - Finished processing (I=0, O=0, R=1, W=1, U=0, E=0)
2016/03/19 10:44:20 - Grava timestamp.0 - Finished processing (I=0, O=1, R=1, W=1, U=0, E=0)
2016/03/19 10:44:20 - Refresh DW Beltrano - Starting entry [Carga das Dimensões]
2016/03/19 10:44:20 - Refresh DW Beltrano - Carga das Dimensões - Starting entry [Dimensão Clientes]
2016/03/19 10:44:20 - Dimensão Clientes - Loading transformation from XML file [file:///home/beltrano/ETL_Beltrano/t_d_clientes.ktr]
2016/03/19 10:44:20 - Dimensão Clientes - Dispatching started for transformation [Dimensão Clientes]
2016/03/19 10:44:21 - Lê CNPJs.0 - Finished reading query, closing connection.
2016/03/19 10:44:21 - Lê CNPJs.0 - Finished processing (I=5000, O=0, R=0, W=5000, U=0, E=0)
2016/03/19 10:44:21 - Insere Tipo.0 - Finished processing (I=0, O=0, R=5000, W=5000, U=0, E=0)
2016/03/19 10:44:21 - Formata fluxo PJ.0 - Finished processing (I=0, O=0, R=5000, W=5000, U=0, E=0)
2016/03/19 10:44:21 - Lê CPFs.0 - Finished reading query, closing connection.
2016/03/19 10:44:21 - Lê CPFs.0 - Finished processing (I=50000, O=0, R=0, W=50000, U=0, E=0)
2016/03/19 10:44:21 - Insere Tipo e Cargo.0 - Finished processing (I=0, O=0, R=50000, W=50000, U=0, E=0)
2016/03/19 10:44:21 - Formata fluxo PF.0 - Finished processing (I=0, O=0, R=50000, W=50000, U=0, E=0)
2016/03/19 10:44:21 - Une fluxos.0 - Finished processing (I=0, O=0, R=55000, W=55000, U=0, E=0)
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 - ERROR (version 5.4.0.0-128, build 1 from 2015-06-03_13-41-59 by buildguy) : Unexpected error
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 - ERROR (version 5.4.0.0-128, build 1 from 2015-06-03_13-41-59 by buildguy) : org.pentaho.di.core.exception.KettleDatabaseException: 
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 - An error occurred executing SQL: 
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 - SELECT count(*) FROM d_clientes WHERE cliente_sk = 0
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 - ERROR: relation "d_clientes" does not exist
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 -   Position: 22
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 - 
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 -     at org.pentaho.di.core.database.Database.openQuery(Database.java:1722)
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 -     at org.pentaho.di.core.database.Database.openQuery(Database.java:1652)
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 -     at org.pentaho.di.core.database.Database.openQuery(Database.java:1648)
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 -     at org.pentaho.di.core.database.Database.openQuery(Database.java:1635)
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 -     at org.pentaho.di.core.database.Database.getOneRow(Database.java:2963)
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 -     at org.pentaho.di.trans.steps.dimensionlookup.DimensionLookup.checkDimZero(DimensionLookup.java:1681)
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 -     at org.pentaho.di.trans.steps.dimensionlookup.DimensionLookup.processRow(DimensionLookup.java:216)
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 -     at org.pentaho.di.trans.step.RunThread.run(RunThread.java:62)
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 -     at java.lang.Thread.run(Thread.java:745)
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 - Caused by: org.postgresql.util.PSQLException: ERROR: relation "d_clientes" does not exist
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 -   Position: 22
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 -     at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2198)
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 -     at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1927)
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 -     at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255)
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 -     at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:561)
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 -     at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:405)
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 -     at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:285)
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 -     at org.pentaho.di.core.database.Database.openQuery(Database.java:1711)
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 -     ... 8 more
2016/03/19 10:44:21 - Ordena lista.0 - Finished processing (I=0, O=0, R=55000, W=15882, U=0, E=0)
2016/03/19 10:44:21 - Dimensão Clientes - ERROR (version 5.4.0.0-128, build 1 from 2015-06-03_13-41-59 by buildguy) : Errors detected!
2016/03/19 10:44:21 - Estado.0 - Finished processing (I=28, O=0, R=6154, W=6154, U=0, E=0)
2016/03/19 10:44:21 - Carrega Dimensão Clientes.0 - Finished processing (I=0, O=0, R=1, W=0, U=0, E=1)
2016/03/19 10:44:21 - Dimensão Clientes - Transformation detected one or more steps with errors.
2016/03/19 10:44:21 - Dimensão Clientes - Transformation is killing the other steps!
2016/03/19 10:44:21 - Cidade.0 - Finished processing (I=9715, O=0, R=8553, W=8552, U=0, E=0)
2016/03/19 10:44:21 - Dimensão Clientes - ERROR (version 5.4.0.0-128, build 1 from 2015-06-03_13-41-59 by buildguy) : Errors detected!
2016/03/19 10:44:21 - Refresh DW Beltrano - Carga das Dimensões - Finished job entry [Dimensão Clientes] (result=[false])
2016/03/19 10:44:21 - Refresh DW Beltrano - Finished job entry [Carga das Dimensões] (result=[false])
2016/03/19 10:44:21 - Refresh DW Beltrano - Finished job entry [Seta Variáveis] (result=[false])
2016/03/19 10:44:21 - Refresh DW Beltrano - Job execution finished
2016/03/19 10:44:21 - Spoon - Job has ended.

Lendo o log descobrimos, facilmente, que o problema é a tabela d_clientes, que não foi criada no DW.

“Facilmente”?

Talvez em um processo simples, com poucos passos – e quando o erro aparece logo no começo. Mas achar o erro em um log desses, que pode chegar a vários megabytes, é qualquer coisa, menos “fácil”.

Você pode argumentar que basta fazer uma busca por ERROR. Verdade, mas precisaria fazer a busca no log inteiro, até o fim! E depois outra: onde é que apareceu mesmo esse erro? Examine o log outra vez: depois que achar o erro, você precisa seguir o log para cima, para descobrir em que arquivo (job ou transformação) ele ocorreu, ou para baixo, até encontrar o nome do job/transformação – mas não o nome do arquivo!

Resumindo: dá para fazer, mas é um porre.

Encontrando Nemo. Digo, Erros!

Eu sempre digo que sou um cara prático (preguiçoso é feio, ainda que seja mais franco, hehe) e gosto de usar computadores para fazer qualquer tarefa que possa ser feita por eles.

Uma forma mais fácil de encontrar erros é montar uma consulta como a do primeiro artigo e listar tudo que possuir o campo status igual a stop:

 (SELECT
       id_job,
       'Job' as tipo,
       jobname as nome,
       status,
       to_char(replaydate, 'DD/MM/YY HH24:MI:SS') as replaydate
  FROM job
  WHERE status='stop')
UNION
  (SELECT
       id_batch,
       'Transformação' as tipo,
       transname as nome,
       status,
       to_char(replaydate, 'DD/MM/YY HH24:MI:SS') as replaydate
  FROM transformation
  WHERE status='stop')
ORDER BY replaydate,nome

Resultado:

id tipo nome status replaydate
3 Job Popula Empresa-Case stop 23/02/16 20:48
8 Job Empresa-Case – Popula Tabelas Indepentes stop 23/02/16 20:55
2037 Transformação BELTRANO – KTR – Seta Variáveis stop 19/03/16 10:32
2039 Transformação Dimensão Clientes stop 19/03/16 10:33
2041 Transformação Dimensão Clientes stop 19/03/16 10:35
2043 Transformação Dimensão Clientes stop 19/03/16 10:44

Bem melhor, não? O problema aqui é que ele traz todo mundo. Ainda precisaríamos fazer algum filtro para pegar só o do dia anterior, ou até uma semana para trás, ou algo assim.

Mas podemos fazer melhor.

16.3 Árvore Genea-LOG-ica

Segundo Matt Casters, a tabela de logging channels surgiu como uma forma de amarrar os diversos logs: todas as coisas que são geradas no PDI ganham um ID particular, que é usado sempre que precisam – internamento ou no registro de log – se referir à aquele objeto. (Pelo menos foi o que eu entendi.) Isso é uma evolução em relação ao sistema antigo, que usava um ID sequencial para cada item, o que, convenhamos, é algo um tanto quanto noob.

O sistema de logs do PDI grava os canais de log em um tabela com o seguinte layout:

Coluna Tipo Descrição
id_batch int4 ID do lote
channel_id varchar ID do canal
log_date timestamp Data de registro nesta tabela
logging_object_type varchar Tipo do objeto: job, stransformação, banco de dados etc.
object_name varchar Nome do objeto
object_copy varchar Número da cópia do objeto
repository_directory varchar Caminho do objeto (repositório em banco)
filename varchar Diretório e nome do arquivo que contém este objeto
object_id varchar ID do objeto no repositório (repositório em banco)
object_revision varchar Versão do objeto (só para versão EE)
parent_channel_id varchar ID do canal do objeto-pai, que criou este objeto
root_channel_id varchar ID do canal do objeto-ancestral, que deu origem a todos os outros

O PDI pode salvar jobs e transformações em um sistema de arquivos, como um arquivo XML, ou em um repositório em banco de dados. As colunas da tabela que se referem a atributos válidos apenas para artefatos gravados no repositório em banco de dados recebem nulo quando o job ou transformação é gravado como um arquivo ordinário.


Pelo fato de os IDs serem gerados como um hash, o risco de colisão é próximo de nulo. Tanto é assim que as tabelas para canais de job e transformação tem o mesmo layout, e a Pentaho recomenda usar uma só tabela para registrar os dois.

Eis o conteúdo de algumas destas colunas:

Algumas colunas da tabela logging Channels.
Algumas colunas da tabela logging Channels.

Podemos usar essa tabela para listar todos os jobs e transformações envolvidos em um único processo. Depois, usando as tabelas de log de job e transformação, podemos adicionar o status e ordená-los pela data e hora de inicialização (replaydate.) Podemos montar um relatório com esse resultado. Daí poderemos revisar o processamento do dia e encontrar eventuais falhas muito mais – agora sim! – facilmente.

Vamos fazer isso, então.

Lista de Jobs-Raiz

Um job-raiz, por falta de um termo melhor, é um job que está na raiz de um processamento qualquer, e corresponde à lista de todos os tipos de objeto (coluna logging_object_type) JOB, cujo pai é nulo e que as tem a coluna root_channel_id igual à channel_id. Por exemplo, na figura anterior, o último job do ID_BATCH igual à 1023 é um job-raiz.

A consulta que traz isso é:

SELECT id_batch,
       channel_id,
       log_date,
       object_name
FROM job_logging_channels
WHERE logging_object_type = 'JOB'
      AND parent_channel_id IS NULL
      AND channel_id = root_channel_id

E eis o resultado:

id_batch channel_id log_date object_name
18 f411e0d2-… 2016-02-23 21:45:12.588 Popula Empresa-Case
22 9e142006-… 2016-02-23 22:27:00.323 Popula Tabelas de Pedidos
1023 b604142b-… 2016-03-19 10:27:20.576 Refresh DW Beltrano

Essa lista é o primeiro filtro do relatório: o conteúdo da coluna object_name será apresentado ao usuário como um prompt. E como cada job pode ter sido executado diversas vezes, um segundo prompt vai apresentar a lista de datas em que aquele processo foi executado, para que o usuário escolha que corrida analisar.

A lista de datas de execução é obtida com uma consulta na tabela de log do job, filtrada pelo object_name. Usando o job Popula Empresa-Case como exemplo, a lista de datas vem desta consulta:

SELECT DISTINCT
       channel_id,
       replaydate
FROM job
WHERE jobname = 'Popula Empresa-Case'

Usando essas consultas eu comecei o relatório:

Relatório de linhagem do job, com prompts de job e corrida.
Relatório de linhagem do job, com prompts de job e corrida.

Lista de Descendentes

A forma como a tabela de canais foi bolada permite construir uma consulta recursiva, para recuperar todas as partes de um processo, descendo até o último nível. Essa é a forma correta de consultar essa tabela. Porém, como eu não sei tanto SQL para poder construir uma consulta recursiva, vou apenas ser criativo e fazer de outra forma.

Os descendentes daquele job-raiz tem todos uma coisa em comum: o mesmo job-raiz (duhn.) Logo, podemos selecionar todos os elementos – jobs e transformações – que foram executados no mesmo pacote fazendo outra consutla à tabela de log. Eis como selecionar somente os jobs e transformações disparados pelo job principal:

SELECT channel_id,
       logging_object_type,
       object_name
FROM job_logging_channels
WHERE logging_object_type IN ('JOB','TRANS')
      AND root_channel_id = ${job_raiz}

O resultado, especificamente para o caso do job-raiz 9e142006-fb5d-4b28-8b87-1ff0c706919e, é:

channel_id logging_object_type object_name
d4d5227e-c07b-45d1-a6a9-715310de2e7e TRANS Gera Pedidos
56639da7-cb6d-435f-8d1e-c3a1f99c8687 TRANS Gera Parâmetros para Itens de Pedidos
06af3232-75ea-4b7f-b178-eab915e190df TRANS Seta Variáveis de Subitens
ee44ed8d-dbcc-431b-9b9d-d8220fe78838 TRANS Gera Pedidos Detalhes
aa0a4992-be94-4f8e-b0bf-98d14c0baaef JOB Popula Itens de Pedidos
957dc288-16e1-462c-9f1a-89efb026a2a2 TRANS Seta Variáveis de Subitens
4f2927bf-14c5-4b5a-a0d3-8a4c8eb597d7 TRANS Gera Pedidos Detalhes
a4dbea3e-6731-4fc3-92fb-1230888847d9 TRANS Seta Variáveis de Subitens
095dd255-20ec-4b96-a1d5-cf3a316f248d TRANS Gera Pedidos Detalhes
9e142006-fb5d-4b28-8b87-1ff0c706919e JOB Popula Tabelas de Pedidos

Pronto! Temos a nossa lista de jobs e transformações que compõe o job principal! Agora precisamos apenas dos detalhes de cada um deles, que estão nas respectivas tabelas de log de job e de transformação.

Detalhando a Lista

Como os detalhes de jobs e transformações estão em tabelas separadas, vamos fazer dois JOINs e depois reuni-los. Primeiro, os detalhes dos jobs:

SELECT logging_object_type,
       object_name,
       status,
       replaydate
FROM job_logging_channels, job
WHERE logging_object_type = 'JOB'
      AND job_logging_channels.channel_id = job.channel_id
      AND root_channel_id = ${job_raiz}

E agora os das transformações:

SELECT logging_object_type,
       object_name,
       status,
       replaydate
FROM job_logging_channels, transformation
WHERE logging_object_type = 'TRANS'
      AND job_logging_channels.channel_id = transformation.channel_id
      AND root_channel_id = ${job_raiz}

Unindo as duas consultas, temos o resultado completo:

Relatório completo, mostrando a linhagem de execução, ordenada por data/hora.
Relatório completo, mostrando a linhagem de execução, ordenada por data/hora.

Conclusão & Encerramento

O Pentaho Data Integration é uma das mais modernas e sofisticadas ferramentas de integração de dados disponíveis. Entre seus vários recursos estão a captura de logs muito detalhados, dos quais podemos extrair um gama de informaçôes sobre os processos executados por ele.

Nesta série vimos como configurar e usar o sistema de logs do PDI para obter uma visão simples, ainda que minimamente completa, sobre o que se passou em uma dada corrida (primeiro post).

No segundo post vimos como analisar os logs das transformações para detectar os gargalos, isto é, os pontos que puxam a velocidade da dita transformação para baixo.

Com este terceiro post concluímos a série. Vimos como usar um recurso fundamental do sistema de logs, a tabela de “canais” de log (logging channels), para montar uma listagem que sequencia todos os jobs e transformações executados em um processo (clique aqui para baixar o relatório.)

Esses três artigos formam um exemplo simples e prático para monitorar o processo diário, mas há muito que podemos fazer para melhorar a gestão de um DW. Por exemplo, temos todas as possibilidades de automação de detecção de erros e acionamentos por e-mail.

Até a próxima. ;-)

Analisando os Logs do PDI – Parte 2

No primeiro post da série Logs do PDI vimos como configurar as transformações e jobs do PDI para capturar os logs de processamento e como usá-los para monitorar as execuções. Neste segundo post veremos como usar esses dados para identificar gargalos.

Pias & Transformações

Imagine uma pia, na qual uma torneira despeja água. Se entrar mais água do que a pia consegue escoar, a água vai começar a se acumular. Se nada for feito, o nível de água na pia vai subir, e subir, até transbordar. Há duas formas de se evitar que a água transborde: reduzir a entrada ou aumentar a saída. Em termos mais genéricos, para evitar que a água transborde devemos condicionar a entrada à restrição. A “restrição” é justamente a válvula de escoamento da pia.

A velocidade de uma transformação, medida em linhas por segundo, l/s, está condicionada à restrição existente na transformação: a velocidade de uma transformação será igual à velocidade do seu passo mais lento. Esse passo mais lento é o gargalo.


Se uma transformação possuir passos de ordenação de linhas, agrupamentos etc., que represam linhas, a velocidade média da transformação perde essa relação direta. Ainda vai haver uma relação entre a velocidade da transformação e a velocidade do seu passo mais lento, apenas não será mais 1 para 1. Mas, para manter o didatismo do post, vamos assumir uma transformação perfeitamente esférica e sem atrito, na qual essa condição vale. ;-)


Para aumentar a velocidade de uma transformação, portanto, devemos aumentar a velocidade do fluxo (em l/s) no gargalo. Quando a velocidade no gargalo tiver subido o bastante, algum outro passo vai ser o responsável por restringir a velocidade da transformação, se transformando no novo gargalo. Removemos esse novo gargalo, aumentando a velocidade da transformação, e outro aparecerá, reiniciando o processo. Eventualmente, chegaremos num ponto de rendimento máximo da transformação, no qual uma nova mudança em qualquer passo não vai resultar em aumento de velocidade da transformação.

Simples, não?

Engarrafamento de Linhas

E como descobrimos gargalos em uma transformação?

Usando o Spoon para detectar gargalos: notou um pontilhado em volta de algum passo? É um gargalo!
Usando o Spoon para detectar gargalos: notou um pontilhado em volta de algum passo? É um gargalo!

Se você estiver rodando-a no Spoon, a interface gráfica do PDI, é muito fácil. O PDI detecta o gargalo, definido por ele como “o passo que recebe mais linhas do que é capaz de processar”, e faz com que o Spoon apresente um pontilhado animado em volta de cada passo identificado como gargalo. Esse monitoramento ocorre em tempo real, e causa efeitos curiosos: em certas situações o gargalo parece “pular” entre dois ou mais passos, e em outras vários passos são marcados como gargalos, simultaneamente. A dinâmica que causa isso está fora do escopo deste post, mas não é difícil de entender se você parar para pensar um pouco.

Para que seu Spoon mostre esse passo na sua transformação você precisa habilitar o checkbox Show bottleneck transformation steps, conforme visto na figura abaixo. Essa janela aparece quando selecionamos o item Options, no menu Tools.

Onde fica o checkbox que habilita a exibição do gargalo.
Onde fica o checkbox que habilita a exibição do gargalo.

Essa opção é muito boa durante o processo de desenvolvimento, mas o que fazer para transformações que rodamos em produção? É um ambiente diferente – memória diferente, disco diferente, carga (tarefas simultâneas) diferentes! Se bobear até o sistema operacional é diferente! Não dá para rodar uma por uma no Spoon e ficar olhando, esperando encontrar um passo-gargalo.

Você adivinhou: consultamos o log de performance.

Entendendo o Gargalo

Conforme o próprio PDI coloca, um gargalo (ou restrição) é “um passo que recebe mais linhas do que é capaz de processar”. Para entender isso você precisa saber um pouco sobre a estrutura interna de um passo.

Um passo possui, grosso modo, três partes:

  1. Buffer de entrada: onde são gravadas as linhas que chegam do passo anterior, e onde elas ficam esperando ser processadas;
  2. Motor do passo: retira uma linha do buffer de entrada, processa e grava o resultado no buffer de saída, repetindo esse processo enquanto o passo anterior estiver mandando linhas;
  3. Buffer de entrada: onde são gravadas as linhas processadas pelo passo, e onde elas aguardam até o engine do PDI movê-las para o passo seguinte.
Todo passo possui dois buffers: entrada e saída.
Todo passo possui dois buffers: entrada e saída.

Assim, se o motor do passo, o processamento em si, não for rápido o bastante, ele começa a ficar para trás: as linhas começam a se acumular no buffer de entrada. Se, além disso, se o passo seguinte for no mínimo tão rápido quanto o passo atual, as linhas processadas não “esquentam cadeira” no buffer de saída, e vão sendo levadas adiante. Por exemplo, na transformação simples mostrada abaixo, com três passos, o passo do meio é um gargalo:

O passo do meio é um gargalo: buffer de saída com menos linhas que o de entrada.
O passo do meio é um gargalo: buffer de saída com menos linhas que o de entrada.

Note que os buffers do passo do meio, representados pelas caixas de entrada e saída, aparecem vazio na saída e cheio na entrada. Essa é a condição de gargalo, ou de restrição. Se pudermos aumentar (elevar) a vazão dessa restrição, a velocidade da transformação, como um todo, aumentará.

Como vemos isso nos logs? Bom, quando rodamos uma transformação no Spoon, este monta um quadro de métricas dos passos, e atualiza-o conforme a transformação vai sendo executada, conforme as linhas vão sendo processadas.

Passos e seus parâmetros durante execução.
Passos e seus parâmetros durante execução.

A coluna input/output, última à direita na imagem anterior, exibe a relação entre a quantidade de linhas presentes no buffer de entrada, aguardando processamento, e quantidade de linhas no buffer de saída, aguardando transporte até o passo seguinte. Sempre que um passo possui mais linhas em sua entradas que em sua saída, ele está “segurando” a transformação. Para encontrarmos os gargalos de uma transformação, então, basta analisarmos os passos dela, em busca de buffers de entrada cheios e buffers de saída vazios (ou com bem menos linhas.)

Analisando Vazão em Transformações

O log que captura as métricas de cada passo, segundo a segundo, chama-se Performance. Veja como ativá-lo no primeiro post da série. Essa tabela possui as seguintes colunas:

  • id_batch
  • seq_nr
  • logdate
  • transname
  • stepname
  • step_copy
  • lines_read
  • lines_written
  • lines_updated
  • lines_input
  • lines_output
  • lines_rejected
  • errors
  • input_buffer_rows
  • output_buffer_rows

Reparou nas duas últimas? São as que nos interessam.


Não vou montar uma solução pronta, mas mostrar como usar essa tabela para desenhar algo que atenda à sua necessidade – e depois vou mostrar um exemplo do relatório que eu uso para “debugar” transformações em produção.


Precisamos de uma consulta que traga os buffers, por cada passo, por transformação. Além disso, como cada transformação pode ter sido executada várias vezes, precisamos filtrar também por lote (id_batch.) Essa consulta ficaria assim:

SELECT
  id_batch,
  transname,
  stepname,
  input_buffer_rows,
  output_buffer_rows
FROM transformation_performance
WHERE
  id_batch = X AND
  transname = 'x'

Filtrando para lote 2080 e transformação Carga da Lista de Clientes PF, temos:

id_batch transname stepname input_buffer_rows output_buffer_rows
2080 Carga da Lista de Clientes PF Gera strings aleatórias 224 276
2080 Carga da Lista de Clientes PF Cria CEP, Telefone e Fax 0 0
2080 Carga da Lista de Clientes PF Cria CEP, Telefone e Fax 0 0
2080 Carga da Lista de Clientes PF Lê nomes 0 0
2080 Carga da Lista de Clientes PF Cria as partes de CEP, Telefone e Fax 0 0
2080 Carga da Lista de Clientes PF Muda rnd_telefone/fax para string 0 0
2080 Carga da Lista de Clientes PF Seleciona endereço 2 0
2080 Carga da Lista de Clientes PF Lê sobrenomes 0 61
2080 Carga da Lista de Clientes PF Acerta tamanho das strings 0 0
2080 Carga da Lista de Clientes PF Seleciona sobrenome 61 0
2080 Carga da Lista de Clientes PF Lê lista de enderecos 0 0
2080 Carga da Lista de Clientes PF Seleciona nome 0 0
2080 Carga da Lista de Clientes PF Cria ID do Cliente 1560 225
2080 Carga da Lista de Clientes PF Insere cidade_id 1 3
2080 Carga da Lista de Clientes PF Limpa fluxo 0 0
2080 Carga da Lista de Clientes PF Cria índice do endereço 276 125
2080 Carga da Lista de Clientes PF Gerar linhas 0 2444
2080 Carga da Lista de Clientes PF Cria índices de nome 147 110
2080 Carga da Lista de Clientes PF String operations 3 1
2080 Carga da Lista de Clientes PF Absoluto de rnd_cpf 110 3
2080 Carga da Lista de Clientes PF Grava tabela 0 0
2080 Carga da Lista de Clientes PF Gera strings aleatórias 1778 5755
2080 Carga da Lista de Clientes PF Cria CEP, Telefone e Fax 0 0

E aí, consegue dizer se algum destes passos é um gargalo? Nem eu. Vamos melhorar nossa consulta: vamos agrupar por passo, remover o nome da transformação e lote da execução, já que ambos são previamente conhecidos (estão no filtro.) Fica assim:

SELECT
  stepname,
  sum(input_buffer_rows) as buffer_entrada,
  sum(output_buffer_rows) as buffer_saida
FROM transformation_performance
WHERE
  id_batch = 2080 AND
  transname = 'Carga da Lista de Clientes PF'
GROUP BY
  stepname
ORDER BY
  stepname

Resultado:

stepname buffer_entrada buffer_saida
Absoluto de rnd_cpf 4289 2770
Acerta tamanho das strings 10117 10100
Cria as partes de CEP, Telefone e Fax 100 10098
Cria CEP, Telefone e Fax 10101 20099
Cria ID do Cliente 21021 11892
Cria índice do endereço 15660 3458
Cria índices de nome 3483 4289
Gerar linhas 0 21902
Gera strings aleatórias 11889 15658
Grava tabela 20281 0
Insere cidade_id 202 259
Lê lista de enderecos 0 0
Lê nomes 0 0
Lê sobrenomes 0 61
Limpa fluxo 20099 20281
Muda rnd_telefone/fax para string 125 100
Seleciona endereço 258 714
Seleciona nome 714 100
Seleciona sobrenome 161 125
String operations 2770 202

Já dá para dizer se alguém é gargalo? Não! Veja, buffer de entrada e buffer de saída são métricas não-aditivas: somá-las ao longo do tempo não dá nenhuma informação sobre o processo. Nem somando-as ao longo dos passos, ou das transformações, nada! No máximo, como métricas não-aditivas, talvez uma média ao longo do tempo possa dar alguma idéia do que está acontecendo.

Mesmo assim, a média não ajudaria. Lembra-se que o monitoramento de gargalo do Spoon ocorre em tempo real? E que os gargalos podem pular de um passo para outro? Só conseguimos identificar um gargalo olhando o comportamento dele ao longo do tempo, momento a momento.

Incluíndo o tempo na consulta, temos:

SELECT
  stepname,
  logdate,
  sum(input_buffer_rows) as buffer_entrada,
  sum(output_buffer_rows) as buffer_saida
FROM transformation_performance
WHERE
  id_batch = 2080 AND
  transname = 'Carga da Lista de Clientes PF'
GROUP BY
  stepname,
  logdate
ORDER BY
  stepname

Vai nos dar a seguinte saída:

stepname logdate buffer_entrada buffer_saida
Absoluto de rnd_cpf 2016-02-21 16:34:41 110 3
Absoluto de rnd_cpf 2016-02-21 16:34:41 110 3
Absoluto de rnd_cpf 2016-02-21 16:34:42 87 100
Absoluto de rnd_cpf 2016-02-21 16:34:43 4092 2667
Absoluto de rnd_cpf 2016-02-21 16:34:44 0 0
Absoluto de rnd_cpf 2016-02-21 16:34:45 0 0
Absoluto de rnd_cpf 2016-02-21 16:34:46 0 0
Absoluto de rnd_cpf 2016-02-21 16:34:46 0 0
Acerta tamanho das strings 2016-02-21 16:34:41 0 0
Acerta tamanho das strings 2016-02-21 16:34:42 0 0
Acerta tamanho das strings 2016-02-21 16:34:43 120 100
Acerta tamanho das strings 2016-02-21 16:34:44 9997 10000
Acerta tamanho das strings 2016-02-21 16:34:45 0 0
Acerta tamanho das strings 2016-02-21 16:34:46 0 0
Acerta tamanho das strings 2016-02-21 16:34:46 0 0
Cria as partes de CEP, Telefone e Fax 2016-02-21 16:34:41 0 0
Cria as partes de CEP, Telefone e Fax 2016-02-21 16:34:42 0 0
Cria as partes de CEP, Telefone e Fax 2016-02-21 16:34:43 100 101
Cria as partes de CEP, Telefone e Fax 2016-02-21 16:34:44 0 9997
Cria as partes de CEP, Telefone e Fax 2016-02-21 16:34:45 0 0
Cria as partes de CEP, Telefone e Fax 2016-02-21 16:34:46 0 0
Cria as partes de CEP, Telefone e Fax 2016-02-21 16:34:46 0 0
Cria CEP, Telefone e Fax 2016-02-21 16:34:41 0 0
Cria CEP, Telefone e Fax 2016-02-21 16:34:42 0 0
Cria CEP, Telefone e Fax 2016-02-21 16:34:43 101 100
Cria CEP, Telefone e Fax 2016-02-21 16:34:44 10000 10000
Cria CEP, Telefone e Fax 2016-02-21 16:34:45 0 9999
Cria CEP, Telefone e Fax 2016-02-21 16:34:46 0 0

Agora podemos dizer, se em algum instante, um passo se comportou como um gargalo. Claro que examinar os dados assim é uma bobagem – podemos montar um gráfico com isso.

Relatório de Análise de Fluxos

Juntando essa consulta com os relatórios do primeiro post, montamos um relatório de análise de fluxo de transformações:

Relatório de análise de fluxo em transformações.
Relatório de análise de fluxo em transformações.

Esse relatório traça a velocidade daquele passo em linhas por segundo no gráfico de cima, e o volume de linhas presentes nos buffers, no gráfico de baixo, tudo instante a instante. O que vemos é que esse passo possui uma vazão boa, até, de 20.000 l/s, e que ele nunca esteve em condição de gargalo. Muito pelo contrário: no instante 5 ele teve o seu buffer de saída completamente cheio, sugerindo que o passo seguinte poderia ser um gargalo.

Eis o trecho da transformação que estamos analisando:

Trecho final da transformação de carga de clientes PF da Beltrano S/A.
Trecho final da transformação de carga de clientes PF da Beltrano S/A.

Os passos seguintes são um Select Values e um Table Output. Eis os buffers do Select Values:

Buffers do Select Values.
Buffers do Select Values.

E os do Table Output:

Buffers do Table Output.
Buffers do Table Output.

A-há! Veja ali, do momento 3 ao momento 6, como o buffer de entrada (a linha vermelha) sobe até atingir 10.000 linhas, enquanto o buffer de saída permanece em zero! Esse passo é um gargalo! Ele ficou com o buffer de entrada cheio, que fez com que as linhas “transbordassem” para o passo anterior, o Select Values. Tanto esse Select Values não é um gargalo que os dois buffers sobem e descem juntos. Mais ainda: foi justamente entre os momentos 3 e 6 (comuns a todos os passos, aliás, pois o log de performance captura todo mundo junto) que o buffer de saída do passo Cria CEP, Telefone e Fax saturou, isto é, atingiu seu limite de 10.000 linhas, e começou a se refletir no buffer de entrada, mesmo que por apenas um segundo (cada momento equivale a um segundo nesta escala.)

Conclusão

A partir da consulta mostrada podemos criar um relatório que exibe o estado dos buffers de cada passo momento a momento. Usando a transformação como guia, podemos analisar cada um dos passos em busca do sintoma de restrição de fluxo.

Essa não é a melhor análise, já que nos obriga a olhar um por um. Como você faria essa análise automaticamente? Como deixar para o Report Designer detectar os gargalos de uma transformação?

E apenas para fechar o problema encontrado neste exemplo: um gargalo em um passo que grava dados no banco significa que a rede e o banco é que são os gargalos. Dependendo da influência da rede e do banco na força da restrição, podemos levar o processamento para mais perto (reduzindo o custo da rede) ou melhorar o banco com, por exemplo, discos mais rápidos.

Na próxima semana terminaremos a série com um relatório de genealogia de um processo de ETL.

Até lá!


Novo Lançamento!

Sexta-feira, 11 de março de 2016, será o lançamento do meu novo livro, Autopublicação na Prática. Não deixe de passar por aqui, porque – como sempre – ele será lançado por R$ 0,00!

Analisando os Logs do PDI – Parte 1

O Pentaho Data Integration, antigamente conhecido por Kettle, é a ferramenta de integração de dados da Suite Pentaho. É, de longe, a ferramenta de maior sucesso deles e tanto é assim que fornecedores tradicionais desse mercado “sentiram o calor” da concorrência.

Neste post eu não vou falar sobre o PDI em si, mas sobre uma de seus recursos: o log.

Toco Cru

Em inglês, log significa “tora de madeira”.

Those are the logs.
Those are the logs.

Ou diário, como em captain’s log, o diário do capitão, ou lab log, que é aquele caderninho preto em que cientistas anotam o que aconteceu nos experimentos. :-) Quando dizemos que um programa gera logs, estamos querendo dizer que ele registra, em algum lugar, informações sobre o que está acontecendo. Podem ser erros, avisos ou simplesmente uma narração das ações do programa. Em geral, cada entrada no registro possui uma etiqueta de tempo, ou timestamp, para que seja possível saber quando tal evento ocorreu, e colocá-los em sequência, para estudo.

Transformações e jobs do PDI geram uma profusão de dados durante seu processamento, e a maioria dos usuários do PDI vê parte desses dados na saída do processamento:

geekbi@dw:/opt/pentaho/5.1/data-integration$ ./pan.sh -file=/home/Beltrano/00_Beltrano_1.0/ETL/t_d_date.ktr
2016/02/21 10:50:04 - Pan - Start of run.
2016/02/21 10:50:05 - Dimensão Data - Dispatching started for transformation [Dimensão Data]
2016/02/21 10:50:05 - d_date.0 - Connected to database [beltrano_dw] (commit=10000)
2016/02/21 10:50:05 - Days of week.0 - Finished processing (I=0, O=0, R=0, W=7, U=0, E=0)
2016/02/21 10:50:05 - Months.0 - Finished processing (I=0, O=0, R=0, W=12, U=0, E=0)
2016/02/21 10:50:05 - 10000 dias: 25 anos.0 - LineNr : 5000
2016/02/21 10:50:05 - Days_since.0 - linenr 5000
2016/02/21 10:50:05 - 10000 dias: 25 anos.0 - LineNr : 10000
2016/02/21 10:50:05 - 10000 dias: 25 anos.0 - Finished processing (I=0, O=0, R=0, W=10000, U=0, E=0)
2016/02/21 10:50:05 - Days_since.0 - linenr 10000
2016/02/21 10:50:05 - Days_since.0 - Finished processing (I=0, O=0, R=10000, W=10000, U=0, E=0)
2016/02/21 10:50:05 - Calc Date.0 - Linenr 5000
2016/02/21 10:50:05 - DayOfWeekDesc.0 - linenr 5000
2016/02/21 10:50:05 - MonthDesc.0 - linenr 5000
2016/02/21 10:50:05 - Select values.0 - linenr 5000
2016/02/21 10:50:05 - d_date.0 - linenr 5000
2016/02/21 10:50:06 - Calc Date.0 - Linenr 10000
2016/02/21 10:50:06 - Calc Date.0 - Finished processing (I=0, O=0, R=10000, W=10000, U=0, E=0)
2016/02/21 10:50:06 - Quarter.0 - Finished processing (I=0, O=0, R=10000, W=10000, U=0, E=0)
2016/02/21 10:50:06 - DayOfWeekDesc.0 - linenr 10000
2016/02/21 10:50:06 - DayOfWeekDesc.0 - Finished processing (I=0, O=0, R=10007, W=10000, U=0, E=0)
2016/02/21 10:50:06 - MonthDesc.0 - linenr 10000
2016/02/21 10:50:06 - MonthDesc.0 - Finished processing (I=0, O=0, R=10012, W=10000, U=0, E=0)
2016/02/21 10:50:06 - Select values.0 - linenr 10000
2016/02/21 10:50:06 - Select values.0 - Finished processing (I=0, O=0, R=10000, W=10000, U=0, E=0)
2016/02/21 10:50:06 - d_date.0 - linenr 10000
2016/02/21 10:50:06 - d_date.0 - Finished processing (I=0, O=10000, R=10000, W=10000, U=0, E=0)
2016/02/21 10:50:06 - Pan - Finished!
2016/02/21 10:50:06 - Pan - Start=2016/02/21 10:50:04.785, Stop=2016/02/21 10:50:06.757
2016/02/21 10:50:06 - Pan - Processing ended after 1 seconds.
2016/02/21 10:50:06 - Dimensão Data -
2016/02/21 10:50:06 - Dimensão Data - Step Days_since.0 ended successfully, processed 10000 lines. ( 10000 lines/s)
2016/02/21 10:50:06 - Dimensão Data - Step Calc Date.0 ended successfully, processed 10000 lines. ( 10000 lines/s)
2016/02/21 10:50:06 - Dimensão Data - Step DayOfWeekDesc.0 ended successfully, processed 10007 lines. ( 10007 lines/s)
2016/02/21 10:50:06 - Dimensão Data - Step MonthDesc.0 ended successfully, processed 10012 lines. ( 10012 lines/s)
2016/02/21 10:50:06 - Dimensão Data - Step Select values.0 ended successfully, processed 10000 lines. ( 10000 lines/s)
2016/02/21 10:50:06 - Dimensão Data - Step d_date.0 ended successfully, processed 10000 lines. ( 10000 lines/s)
2016/02/21 10:50:06 - Dimensão Data - Step Quarter.0 ended successfully, processed 10000 lines. ( 10000 lines/s)
2016/02/21 10:50:06 - Dimensão Data - Step Days of week.0 ended successfully, processed 7 lines. ( 7 lines/s)
2016/02/21 10:50:06 - Dimensão Data - Step Months.0 ended successfully, processed 12 lines. ( 12 lines/s)
2016/02/21 10:50:06 - Dimensão Data - Step 10000 dias: 25 anos.0 ended successfully, processed 10000 lines. ( 10000 lines/s)

Essa é só a narração dos eventos, mas muitos outros dados são capturado durante o processamento: quantidade de linhas lidas e gravadas em bancos e arquivos, quantidade de linhas processadas em cada passo, conteúdo de variáveis carregadas, conexões feitas, erros, aviso – o PDI captura tudo, tudo, até a vazão da pia da cozinha. Esses dados podem ser descarregados diretamente num banco, o que habilita o gestor do projeto a monitorar a carga minuciosamente. Por exemplo, podemos criar indicadores de performance e acompanhá-los diariamente, ou buscar informações sobre o que aconteceu durante uma corrida qualquer do ETL.

Está série é composta de três posts. Nesta primeira parte vamos mostrar como configurar o PDI para injetar os dados capturados em um banco de dados e como construir um relatório bem simples, com indicadores básicos sobre o processamento.

Na Parte 2 veremos como descobrir gargalos, que são pontos de lentidão no fluxo de dados. Por fim, na parte 3, veremos um relatório que dá a genealogia (quem chamou quem, a que horas e quanto tempo levou) de um job, uma informação crucial para o monitoramento da “saúde” do processo.

Ativando a Captura de Log

O PDI descarrega seu log apenas em bancos de dados. Por isso você precisa ter um banco de destino para gravar seus logs. Normalmente eu mantenho um esquema de log nos mesmos bancos dos DWs, pois isso simplifica tanto o desenvolvimento quanto a análise.

Uma vez que você tenha um banco/esquema, precisamos definir quais tabelas receberão os logs. De novo, eu adoto um padrão: trans_LOG para log das transformações, e job_LOG para jobs. Neste caso, LOG é o nome do log capturado na tabela.

Na versão 5.4 o PDI captura os seguintes logs (com o nome da tabela que eu uso entre parênteses):

  • Transformações:
    1. Transformation (transformation): registra uma linha por transformação, por corrida. O campo LOG_FIELD contém o log de texto do processamento;
    2. Step (transformation_steps): registra um sumário do processamento de cada passo, em cada transformação, por corrida, em uma linha por passo. Ligado à anterior pela coluna ID_BATCH;
    3. Performance (transformation_performance): mede a vazão de linhas através de cada passo, segundo a segundo, em cada corrida de uma transformação, uma linha por passo, por segundo. Ligado à tabela de log de transformações pela coluna ID_BATCH;
    4. Logging channels (transformation_lc): registra os nomes e propriedades dos “canais” de dados em uma transformação ou job;
    5. Metrics (não coleto esta): http://forums.pentaho.com/showthread.php?137582-Output-steps-metrics-How-to-use
  • Jobs:
    1. Jobs (jobs): equivalente à da transformação, registra os dados de cada execução de um job em uma linha. Assim como na transformação, o mesmo campo LOG_FIELD contém toda saída de texto do processamento;
    2. Job Entry (job_entry):
    3. Job Logginc Channels (job_lc): registra os nomes e propriedades dos “canais” de dados em uma transformação ou job. Possui o mesmo layout que a logging channels das transformações. Pelo que entendi, a “boa prática” é serem a mesma.

Eu simplifiquei um pouco essas descrições, ou a coisa viraria um livro. Por exemplo, cada log possui parâmetros de tempo de vida e latência de atualização. Consultem o Pentaho Infocenter, a Wiki, o Kettle Solutions ou o Pentaho na Prática para mais informações. Nosso foco hoje é aprender a capturar e usar.


Todos esses parâmetros são entrados na aba de log das janelas de propriedades das transformações…

Aba de logs de uma transformação.
Aba de logs de uma transformação.

 

… e jobs:

Aba de logs de um job.
Aba de logs de um job.

Para chamar essa janela clique com o botão direito sobre qualquer parte em branco de um job ou transformação e, no menu que aparecer, escolha Transformation settings (ou Job settings.)

Esses parâmetros podem ser preenchidos de três maneiras:

  1. Manualmente, entrando os nomes de tabelas e valores dos parâmetros um por um, em toda transformação e job que você criar. Essa alternativa é boa para testes e estudos, enquanto você não está em projeto, por que é mais rápida e prática. Só que, se estiver em um projeto e definir todos os valores manualmente, você vai ter um trampo cabuloso para mudar qualquer coisa, pois vai ter que editar todos os artefatos, um por um, do processo inteiro;
  2. Por meio de variáveis definidas pelo desenvolvedor: defina uma variável para cada parâmetro no arquivo kettle.properties e insira-as nos lugares adequados usando a sintaxe ${VARIÁVEL}. O início é tedioso, como na opção anterior, mas é mais flexível pois basta mudar a variável no kettle.properties para propagar seu valor por todo processo. É a melhor opção quando temos vários projetos, pois podemos criar lotes de variáveis para cada um;
  3. Definindo valores das variáveis-default do PDI: esse método é de longe o mais prático para quem lida com um só projeto, pois você não precisa alterar nada em nenhuma transformação ou job. Cada campo das definições de log possui uma variável default. Definindo o valor destas no kettle.properties, o PDI configura a captura do log automaticamente. Por outro lado, se você trabalhar em mais de um projeto, vai precisar trocar essas variáveis sempre que mudar de projeto.

Alguns truques facilitam a vida do desenvolvedor: ao invés de configurar manualmente o log em todos os artefatos, crie modelos de transformação e job já configurados. Daí, quando precisar criar uma nova transformação/job, use o modelo: duplique o arquivo ou abra e salve com outro nome e comece dali. Meus modelos não apenas possuem os logs pré-configurados, como ainda deixo notas e padrões de documentação pré-preenchidos.


As variáveis são definidas no arquivo <diretório do usuário>/.kettle/kettle.properties. O Spoon oferece uma interface para fazer essa edição sem precisar sair da interface gráfica: clique no menu Edit e escolha a opção Edit the kettle.properties file. Aparecerá uma janela listando todas as variáveis default, mesmo que estejam vazias, além de todas as variáveis definidas pelo desenvolvedor:

Janela de edição do conteúdo do arquivo kettle.properties (variáveis.)
Janela de edição do conteúdo do arquivo kettle.properties (variáveis.)

Lembre-se de fechar o Spoon antes de editar o arquivo diretamente. Caso contrário, não apenas ele não vai ver os novos valores e variáveis, como ainda corre-se o risco de elas serem apagadas.

Um último detalhe: quase todos os logs são capturados por default. Quase: o de performance de passo, que é o que mais gera linhas no banco, está desligado por default. Para ativá-lo marque o checkbox Enable step performance monitoring? na aba Monitoring (a última na versão 5.4) das propriedades da transformação:

Ligue o checkbox para capturar o rendimento de cada passo da transformação.
Ligue o checkbox para capturar o rendimento de cada passo da transformação.

Criando as Tabelas

Como tudo no Spoon, sempre que algo escreve em uma tabela, um botão que permite criar ou ajustar essa tabela automaticamente. Para criar qualquer tabela de log basta preencher seus dados de conexão e nome, e clicar no botão SQL no fundo da janela de propriedades:

Criando as tabelas de log de transformação com ajuda do botão SQL.
Criando as tabelas de log de transformação com ajuda do botão SQL.

Se você preencher todos os parâmetros antes e deixar o botão de SQL para o fim, o Spoon vai te dar um monte de janelas, uma para cada tabela. O mesmo vale os logs de jobs.

Analisando Logs

Para os exemplos vamos usar o log gerado pela repetição do processo de carga do Beltrano S/A, de mil pedidos. Esse backup está disponível aqui, como um pacote RAR. Consulte as instruções de restauração da base Beltrano, lembrando apenas de substituir o nome do arquivo para o do arquivo da base de logs.

Vamos ver dois relatórios tão simples quanto úteis:

  • Logs de jobs e transformações
  • Histórico de performance

Logs de Jobs e Transformações

Quem cuida de processos de ETL sabe que a principal pergunta que se faz é “Rodou? Deu certo? O que aconteceu?”

Ok, são três perguntas, mas no fundo todas elas querem saber a mesma coisa: se o processo funcionou ou não, e o que aconteceu, se tiver dado erro.

A forma mais simples de respondê-las seria olhar o log de texto, o relato de tudo que se passou durante o processamento. É o primeiro lugar que devemos olhar porque é ali que estão as mensagens de erros. Eu chamo esse tipo de relatório simplesmente de “Relatório de Log”: Log de Jobs e Log de Transformações. Ele mostra um cabeçalho com parâmetros do objeto sendo examinado, como datas, status e duração, e logo abaixo o conteúdo de texto do processamento. A consulta que eu uso é assim:

Transformação

SELECT
     'Duracao em Segundos' as categoria,
     id_batch,
     transname,
     status,
     lines_read,
     lines_written,
     lines_updated,
     lines_input,
     lines_output,
     lines_rejected,
     replaydate,
     logdate,
     extract(hour from (logdate - replaydate))*60*60 +
          extract(minute from (logdate - replaydate))*60 +
          extract(second from (logdate - replaydate)) as duracao,
     log_field
FROM
     transformation

Job

SELECT
     'Duracao em Segundos' as categoria,
     id_job,
     jobname,
     status,
     lines_read,
     lines_written,
     lines_updated,
     lines_input,
     lines_output,
     lines_rejected,
     replaydate,
     logdate,
     extract(hour from (logdate - replaydate))*60*60 +
          extract(minute from (logdate - replaydate))*60 +
          extract(second from (logdate - replaydate)) as duracao,
     log_field
FROM
     job

Note a diferença entre os nomes dos campos dos dois artefatos (job e transformação), mas como mesmo assim são parecidos.

Essas consultas retornam todos os logs, de todas as transformações e jobs, o que é uma coisa inútil – imagine ter que varrer centenas, milhares de páginas atrás de um job ou outro! Por isso eu filtro essa consulta com dois prompts: um para nome do artefato e outro para seu batch, ou lote. As consultas para nomes são assim:

Lista de nomes de transformações:

SELECT DISTINCT transname
FROM transformation
ORDER BY transname ASC

Lista de nomes de jobs:

SELECT DISTINCT jobname
FROM job
ORDER BY jobname ASC

Quando o prompt de nome é preenchido, o prompt de lote fica disponível. As consultas para lotes são:

Lista de lotes de transformações:

SELECT id_batch,replaydate
FROM transformation
WHERE transname=${nome_transformacao}
ORDER BY id_batch DESC

Lista de lotes de jobs:

SELECT id_job,replaydate
FROM job
WHERE jobname=${nome_job}
ORDER BY id_job DESC

Com os dois prompts preenchidos (que estão marcados como obrigatórios, a propósito), o relatório roda:

Relatório de log de transformação.
Relatório de log de transformação.

Histórico de Performance

O mesmo resultado é obtido no relatório de jobs e seria redundante mostrá-lo tal como está. Vamos avançar um pouco, e mostrar o relatório de jobs com um pouco mais de informações: um histórico de duração.

Depois de saber “se deu certo”, o aspecto mais importante do ETL é sua repetibilidade. Afinal, se montamos um processo acreditando que, todo dia, ele vai rodar em menos de uma hora, precisamos saber se isso está acontecendo ou não.

Poderíamos usar o relatório anterior e, manualmente, examinar os tempos de um mesmo job ou transformação, em várias corridas ao longo de um período – uma semana, por exemplo. Trabalhoso. Bom, nós somos o pessoal da Inteligência de Negócios ou não? Como seria um vexame ter tanto trabalho, vamos ser mais práticos: vamos colocar um gráfico das várias execuções.

Pegamos o mesmo relatório anterior e acrescentamos uma nova consulta: a lista da duração das últimas X execuções em ordem crescente:

SELECT * FROM
(SELECT
     'Duracao em Segundos' as categoria,
     id_job,
     to_char(replaydate, 'DD/MM/YY HH24:MI:SS') as replaydate,
     extract(hour from (logdate - replaydate))*60*60 +
     extract(minute from (logdate - replaydate))*60 +
     extract(second from (logdate - replaydate)) as duracao
FROM job
WHERE jobname=${nome_job}
ORDER BY id_job DESC
LIMIT 30) AS X
ORDER BY id_job ASC

O SELECT interno obtém uma lista das últimas 30 execuções do job nome_job (o nome do parâmetro que contém a seleção do usuário). O SELECT externo inverte a ordem para que o gráfico seja plotado corretamente. O resultado dessa consulta para, por exemplo, o job Popula Tabelas Dependentes, é:

categoria id_job replaydate Duracao
Duracao em Segundos 2 23/02/16 20:34:24 1.064
Duracao em Segundos 5 23/02/16 20:51:37 0.671
Duracao em Segundos 7 23/02/16 20:54:54 0.655
Duracao em Segundos 11 23/02/16 21:01:08 0.652
Duracao em Segundos 14 23/02/16 21:07:54 0.742

Como um relatório pode ter apenas uma consulta ativa, e o relatório tal como está já usa uma, precisamos adicionar um sub-relatório para poder usar essa nova query. Neste sub-relatório, que herda essa consulta, adicionamos apenas o elemento de chart. Eu usei um gráfico de linhas, mas poderíamos usar qualquer outro tipo – barras, bullets, área etc.

Sub-relatório com consulta e parâmetro herdados do relatório principal.
Sub-relatório com consulta e parâmetro herdados do relatório principal.

Rodando o relatório o PRD vai exibir o prompt, já visto na figura acima. Já ao selecionar um job o gráfico será preenchido. Após selecionarmos um dos lotes – uma das corridas ou execuções do job – aparece o log logo (hehe) abaixo do plot.

Resultado: log do job selecionado, com visão simultânea das últimas execuções.
Resultado: log do job selecionado, com visão simultânea das últimas execuções.

Você pode baixar esses relatórios neste link.


Todos os materiais foram criados com a suite 5.4 do Pentaho. Se você tentar usar, e não conseguir, deixe um comentário que eu tento te ajudar.


Conclusão

Com um pouco mais de trabalho – configurar a captura de log e criar os relatórios – o gestor de ETL pode conseguir uma riqueza de informações sobre seu processo. Entre outros benefícios, o gerente de ETL passa a ser capaz de dizer, em poucos minutos, com poucos cliques, se o processo rodou hoje, se demorou mais, se deu algum erro e vários outros detalhes (incluindo volume processado e tempo de cada processamento.)

Outra função importante servida pelos logs é apoio na melhoria do processo. No próximo post veremos como usar os dados de performance das transformações para analisar o perfil de processamento e identificar gargalos.

Até lá! ;-)

Primeiro Encontro do PenSaPUG – Pentaho São Paulo User Group


 

Ops! Parece que nem para copiar eu sirvo! :-) É às 19H00min, não às 18H00min!

http://www.meetup.com/Sao-Paulo-Pentaho-User-Group/events/219039104/


É hoje! às 19H00min nos reuniremos no Escritório Geek, a base da IT4Biz no centro de São Paulo (ao lado do Metrô São Bento) para bater um papo, comer um pão de queijo e trocar experiências.

Eu vou falar sobre os logs do PDI – como capturá-los e o que dá para fazer com eles. Depois eu vou postar aqui um artigo, com todos os detalhes.


P.S.: a abreviação PenSaPUG é invenção minha e em nada oficial. Só para constar, significa Pentaho o Paulo User Group. Se você tiver uma idéia melhor, estamos aceitando sugestões. Falando alto parece raça de cachorro – ou sapo…

Como um Data Vault Evolui

Ontem eu estava mexendo no meu projeto de DV de estimação (um aconselhamento que presto a um amigo) e descobri uma coisa: o satélite dos dados dos empregados tinha centenas de registros por empregado. Eu fui olhar de perto e descobri que não eram centenas, mas sim um por dia desde o início da captura dos dados. Para um DV, isso significa que a cada refresh (que é diário neste caso) o ETL está versionando o satélite de empregados. Como isso só aconteceria se todo dia houvesse alguma diferença para a última versão, eu decidi analisar os registros, comparando as versões de satélites para um empregado qualquer.

Eu vou mostrar algumas imagens para ilustrar o que eu fiz, mas saibam que todos os nomes foram mudados para coisas mais óbvias, e campos particulares (que possuíam detalhes da arquitetura do sistema) foram removidos. São ilustrações, não são o caso real, ok? Exceto por esse detalhe, todo o restante é a narração fiel do que eu fiz.

O satélite Empregado, mostrado na figura abaixo junto ao hub Empregado, tem cerca de 13 campos do sistema de origem, mais 4 de controle do DV.

Satélite empregado original, com todos os campos em uma única tabela.
Satélite empregado original, com todos os campos em uma única tabela.

Todos esses campos estão em uma única tabela no sistema de origem, de modo que a carga desse pedaço do modelo é feito por duas transformações: uma de hub e uma de satélite.

Eu descobri, depois de analisar o conteúdo do satélite, que três campos eram atualizados sempre que o empregado chegava para trabalhar e depois ia embora:

  • emp_ultimo_acesso
  • emp_ultimo_ip
  • emp_ultima_sessao

Na verdade, sempre que o empregado fazia login (e depois logoff) em qualquer computador na empresa, esses detalhes são atualizados. Resultado: todo dia eles estavam diferentes do dia anterior, a menos que o empregado tivesse faltado, ou o dia anterior fosse um feriado/fim-de-semana. Portanto, todo dia um novo satélite era carregado, e isso estava correto. O ETL estava fazendo o que havia sido programado para fazer.

Satélites Separados

Temos aqui uma situação clássica para Data Vault: o sistema de origem tem taxas de atualização diferente entre os atributos. Alguns são atualizados uma vez na vida e outra na morte, e outros são alterados todos os dias, quando não várias vezes por dia. Se capturarmos todos os registros na mesma tabela estaremos desperdiçando tempo e espaço em disco, tratando e gravando coisas duplicadas, desnecessariamente.

Neste caso optamos por quebrar um satélite em dois ou mais, em função de sua taxa de atualização: um satélite conterá apenas os três campos que mudam todos os dias, e o outro satélite ficará com os campos mais estáveis. Cada um terá sua própria transformação para carga. No final, nosso DV vai ficar assim:

Satélite Empregado, agora quebrado em duas tabelas em função da taxa de atualização.
Satélite Empregado, agora quebrado em duas tabelas em função da taxa de atualização.

Aplicando a Mudança

Antes havia um satélite (=uma tabela), com todos os campos, carregada por uma transformação. Depois teremos duas tabelas, cada qual com seu conjunto de campos, e cada qual carregada por sua transformação. Eis o passo-a-passo que eu passei para meu amigo aplicar em produção:

  1. Renomear o satélite original para s_empregado_antigo;
  2. Criar as duas novas tabelas, s_empregado e s_empregado_1;
  3. Popular cada uma com o histórico atual;
  4. Apagar o satélite original;
  5. Subir as duas novas transformações.

As novas tabelas foram criadas e populadas de uma só vez com um SELECT INTO (o DV está em Postgres, o que facilita tudo.) As transformações foram criadas semi-automaticamente (basta entrar os nomes das tabelas, campos e da transformação e um script parametrizado gera tudo sozinho.)

Pronto! Quinze minutos depois de diagnosticar o problema eu tinha desenhado a solução. Meu amigo avisou que aplicou e deu tudo certo e agora vai propagar a solução para outros satélites (ele tem vários desses com status instantâneo.)

(Bom, vá lá, eu demorei um pouco mais que quinze minutos porque deu um trabalhinho até eu acertar o SELECT – ele precisava manter o histórico, o que significa dois SELECT DISTINCTs, com ORDER BY etc. Mas agora eu já sei o macete, e da próxima vez vai ser só 15min mesmo!)

Outras Quebras

Outras opções de quebras para satélites são por sistema de origem, que dá a vantagem de integrar os dados já no DV, e por particionamento. Neste último podemos deslocar satélites estáveis para outras mídias (outros tablespaces), e continuar a carregar os novos em uma tabela menor.

O Que Kimball Faria?

Meu grande amigo Gurgel que me perdoe, mas eu não vou nem considerar essa situação na 3NF. Agora, como ficaria essa situação em um Modelo Dimensional?

Na verdade, ficaria muito bem, obrigado! Veja, Modelagem Dimensional é uma técnica resiliente e robusta, com muita flexibilidade. Teríamos praticamente a mesma abordagem: quebrar uma tabela (de dimensão) em duas, criar dois novos processos de cargas (duas novas transformações), e recriar a fato, agora com duas chaves no lugar de uma só.

Factível, viável e simples, sim. Interessante? Não tenho certeza: hoje esses dados não possuem nenhum interesse para o negócio do meu amigo. São dados que ele descartaria sem pensar duas vezes – e foi essa a primeira sugestão dele. Saber qual é a hora do último logoff de cada empregado não tem o menor impacto no rendimento da empresa, nem a menor relação com a produtividade desse empregado. É um dado pura e simplesmente inútil, e só entrou no satélite porque simplificamos o levantamento de requisitos ao mínimo essencial – o também clássico carrega tudo!.

O Que Linstedt Faria?

Tá bom, saber quando o empregado fez o último logoff do dia é inútil. Mas e saber o histórico completo de todos os logins e logoffs, interessa?

Veja, estamos falando de capturar todas as mudanças, até mesmo em tempo real se for necessário. Para conseguir isso, sem gastar muito, basta rodar apenas a transformação que carrega esse satélite (com um ajuste para a variável de tempo – detalhes que não vêm ao caso agora…) a cada hora ou minuto. Com algumas centenas de empregados esse processo seria muito leve.

No caso mais extremo, dá para agendar uma PROC no banco que faça isso, e descartar o PDI completamente, reduzindo ainda mais o impacto da captura de histórico.

Com esses dados, novas perguntas são possíveis:

  • Será que um empregado que entra e sai do sistema várias vezes produz menos?
  • Preciso me preocupar com isso?

Um modelo dimensional permite capturar isso se você quiser. Basta montar uma estrela só para isso, já que esse vai ser o processo de negócio em análise.

Agora, e aqui vem uma das coisas legais do DV, um Data Vault te permite capturar isso já integrado com os outros satélites, o hub e tudo o mais. Um bom desenhista dimensional sabe que a técnica do Kimball também te dá essa possibilidade. Mas quanto mais você extende seu DW Dimensional com esse tipo de recurso, mais chega perto de um modelo Data Vault! A quantidade de dimensões e inter-relações (o Bus Matriz) começa a crescer, e a gestão vai ficando cada vez mais difícil. Apesar de flexível, a Modelagem Dimensional não é pensada para acumular dados, mas para análisá-los e por isso, cedo ou tarde, se seu DW muda com frequẽncia, um DV vai se tornar uma alternativa interessante.

E então você vai testar, só para ver como seria. E, então, já será tarde demais. Você será fisgado, como eu fui.

Até a próxima! Fui! :-)

Packt Video Review – Building a DM with PDI

This video, Building a Data Mart with Pentaho Data Integration, teaches how to apply the Kimball Dimensional Modeling technique with Pentaho Data Integration tool. At the beggining it disclaim it will not teach Dimensional Modeling or how to use PDI. Considering how sophisticated Kimball’s technique is, the content is very usefull for anybody how has to assembly such Dimenional Data Marts.

I liked it very much:

  • The video has very high quality: 1920×1080 @ 25 fps and 44KHz audio stream.
  • The video capture is very fluid, very stable, no skipping. The machine on which it was recorded is blazing fast, and paired along Ubuntu it just screams – no loading times, no lags, only smooth movements. You can see it is not an edited video because most of the time the mouse cursor does not do leap around the screen;
  • The product is not only a video feed, it has a whole site with the video splitted in sections, make it easy and an ease to navigate, to play, stop and resume;
  • The narration is very concise and sparingly (no hums and ehhs or silences.) You can see it has been edited to reach this quality;
  • The product is very complete, with downloadable material;
  • It is totally based on FOSS community editions softwares, so no extra cost at all to follow it (although it does use Pentaho Analyzer, but a free limited feature license one – very high added value because this is a very usefull tool;)
  • It shows en passant how to use the EObjects Data Cleaner to achieve better data quality, which is a huge plus just by mere mentioning it;
  • It is a very good course because it address not only the promised subject with detail, but it also teaches a lot on important aspects of data warehousing, like using columnar databases, caring about data quality, file and database versioning etc.;
  • Most of the technical decisions are justified, which means you bask on the author experience.

I didn’t like it:

  • The narrator has an accent with gets in the middle sometimes (I could never fully understand the second part titles), but you get accostumed to it. Also, I believe they’ve changed narrators a couple of times or maybe changed the pitch – the guy sounds a bit different at some chapters. No big deal;
  • The sound has some volume and pitch wobling: sometimes (and quite frequently) it sounds like having skipped a frame or two and the voice goes into a higher pitch while decreasing the volume a bit. However, other than a little irritanting, it does not impair the hearing and you eventually also get accostumated to it;
  • The use of JNDI connections: PDI has variables which are better fit to make connections portable than JNDI. However, it is a technical option you don’t need to follow and it does not negativelly affect the video or the content and its usability;
  • On the Packt off-line video interface I missed very much some buttons to replay the video or go back a little, pause it and so on. When you download and play with your favorite media player everything is ok, tough.

Conclusion

I could go on and on listing things I liked about this video, but I’d became repetitive. On the other hand, the bad things are not really important. Besides the listed above, I could hardly find anything else.

Packt's video has very high quality.
Packt’s video has very high quality.

The content is rich, detailed, carefully organized and laid out, very usefull and very practical. The video itself is very good, worth an in person course, technically very well done, and with a nice off-line interface. The negative points amounts to some quirks of the audio and the offline interface navigation buttons that I miss, but none of them are really important and do not stand in the way for an enjoyable experience.

All in all, Building a Data Mart with Pentaho Data Integration is a buy if you need to learn how to use PDI to design an ETL process for loading a Dimensional Model.

Como Criar uma Dimensão Data

Em um Modelo Dimensional, o recurso mais valioso sem sombra de dúvida é uma boa dimensão Data. Ainda que uma estrela (um conjunto fato-dimensões) seja em si mesma um grande recurso analítico, ela é pouco útil se não agregar a capacidade de analisar os dados contra o tempo.

Kimball comenta o seguinte sobre a dimensão Data:

Kimball comenta sobre a dimensão Data.
Kimball comenta sobre a dimensão Data.

A sugestão é simples e muito prática: baixe este arquivo do site dele, copie a coluna com os INSERTs e cole num terminal SQL. Repare que, no comentário acima, ele ainda menciona a necessidade de se criar uma linha extra, com chave especial (zero?) para os fatos que ainda não tem data.

Usando o Pentaho Data Integration

No meu livro Pentaho na Prática há uma outra forma de se popular uma dimensão data, que é usando esta transformação do PDI:

Transformação para popular uma dimensão Data.
Transformação para popular uma dimensão Data.

Ela gera 10.000 linhas, a partir de 1/jan/1990, com dia da semana e mês, em inglês. Se você quiser traduzir, basta editar o conteúdo dos passos Days of week e Months. Porém, da mesma forma que a planilha do Kimball, essa transformação não cuida do registro zero – você deve inseri-lo manualmente.

Clique aqui para baixar o arquivo. Depois de descompactá-lo e abri-lo com o PDI, você precisa configurar apenas o último passo (figura abaixo: selecione uma conexão, informe o esquema se for necessário, e depois inserir o nome da tabela) e clicar no botão SQL para automagicamente criar a tabela.

Passo de saída para a transformação que popula a dimensão data.
Passo de saída para a transformação que popula a dimensão data.

Essa transformação vem na pasta de amostras do PDI 3.8. Infelizmente, as versões posteriores passaram a vir corrompidas.

Treinamento Pentaho BigData+Sparkl em Maio/2014

Logo após o Pentaho Day (que serão dois dias, na verdade), ocorrerá em São Paulo um treinamento oficial Pentaho sobre BigData e Sparkl.

Vocês podem ver os detalhes aqui. O preço é meio salgado, mas vale cada centavo: não apenas é um curso oficial, como será ministrado diretamente pelo inventor da tecnologia Sparkl, Pedro Alves, Sênior Vice-Presidente da Pentaho.

Eu ainda não consegui parar para estudar Sparkl, mas se tudo que eu ouvi tem a ver com a realidade, então vai ser o bicho. Imagine poder construir, ad hoc, um aplicativo de BI diretamente sobre qualquer base de dados INCLUSIVE BigData!!