Develop Like a Hero

Já reparam como, em todo filme de super-herói tipo gênio (Homem de Ferro, Homem-Aranha, Quarteto Fant, eles sempre produzem as traquitanas mais loucas e complexas da noite para o dia? Na boa, meus amigos, eu já construí robôs do zero, e posso garantir que não tem nada de fácil! Desde desenhar o circuito eletrônico, calculando todas as especificações, até codificar o programa de controle, passando por simplesmente tudo – desenhar a placa de circuito impresso, corroê-la, furá-la, comprar os componentes, soldar, montar a parte mecânica, calibrar, interfacear…

Não é nem remotamente fácil.

Mas tudo bem, certo? Afinal, é só fantasia, ficção, filmes.

Essas histórias contam com uma coisa chamada suspension of disbelief. Sem isso, veríamos a história na tela e pensaríamos “que bobagem!” Com a “suspensão da descrença” podemos ver o Tony Stark construir uma armadura voadora, e não achar mada demais. Mas tudo tem limites, mesmo uma coisa tão poderosa como esse sentimento de faz-de-conta. Se a história for muito sem pé-nem-cabeça, muito forçada, a coisa perde a graça. Você talvez já tenha assistido alguma destas comédias que tiram sarro dessas situações. Eu lembro de ter visto uma – não me lembro o nome – em que o cara passa por um mega-treinamento e aprende a fazer tudo. No final daquela cena que, normalmente, é um condensado de meses no tempo do filme, percebemos que passou-se apenas o tempo de tela, ou seja, alguns minutos. Bom, esses casos “forçam a barra”.

Para manter alguma credibilidade, esses filmes tentam mostrar como a coisa seria se fosse real, mesmo que apelando para outra coisa quase tão inverossímel quanto a primeira.

Quer um exemplo? Ainda no Homem de Ferro, o mesmo Tony Stark desenvolve a armadura e testa os vários subsistemas até chegar em um protótipo. Depois ele passa uma revisão no projeto e manda o Jarvis construir e montar a versão final. O que vemos é um cara designado como gênio usando ferramentas avançadas – incluindo um computador com a personalidade do Máximo e um braço mecânico com a inteligência do Babão – para apoiá-lo no processo. Essas ferramentas são tão inverossímeis quanto a própria armadura, mas aceitamos que, de posse delas, a possibilidade de uma super-roupa voadora é algo concreto.

Existe algo de muito valioso nessa massaroca fantasiosa: o conceito de automação no desenvolvimento.

Seja Preguiçoso

Como é seu processo de desenvolvimento? O tema do blog é BI, mas pode estender a pergunta a qualquer assunto: código, web design, marcenaria – o que for.

Muita gente faz tudo na mão, pelo menos as pessoas que eu tenho visto. A maioria sequer usa um repositório para versionar os artefatos, menos ainda qualquer outro recurso. Testes, então, espere o cliente reclamar. Não veio reclamação? Comita e era isso! :-)

Eu sempre digo que sou preguiçoso, er, prático. Eu prefiro dedicar minha energia a coisas que computadores não conseguem fazer, ainda, e deixar para eles coisas para os quais estão preparados, como tarefas repetitivas.

Quem já se envolveu em um projeto de Software Livre sabe como é que a banda toca (em geral): um repositório central de código é monitorado por vários sistemas de apoio. Há sistemas que partes do sistema sempre que um novo trecho de código é comissionado (commited, ou na corruptela “comitado”), e que periodicamente compilam o sistema inteiro (em geral à noite, gerando os tais nightly builds). Outros que, após a compilação parcial ou completa, rodam testes contra os resultados, e automaticamente registram os bugs encontrados, ou atestam o sucesso do build e assim por diante.

Até hoje eu não vi coisa equivalente para BI. Porquê? Não sei ao certo.

Existem três divisões principais que uma iniciativa de BI executa:

  • DW: processo de modelagem e ETL;
  • Bancada: é o termo genérico para descrever as interfaces de exploração de dados. Por exemplo, um esquema Mondrian para o Pentaho, um [projeto MicroStrategy][projetomicrost_bitly], um [universo do Business Object][bouniverse_bitly];
  • Data Mining: processos de organização, limpeza e análise de dados em busca de padrões.

Provavelmente não existe muita automação em projetos de BI porque esses três aspectos são difíceis de automatizar. Como automatizar, por exemplo, a construção de uma bancada MicroStrategy (só para sair um pouco fora do confortável mundo do Pentaho)? Como montar um teste para validar esse mapeamento?

Difícil…

tivas Tarefas Repetitivas Tarefas Repeti

… mas não impossível. Se observarmos o nosso trabalho diário de desenvolvedores de soluções de BI, vamos acabar percebendo tarefas que executamos várias vezes.


Vou usar o universo de coisas do Pentaho porque posso falar dele com mais propriedade, mas existem equivalentes em todas as outras ferramentas.


  • Rodar uma transformação, para ver se dá pau ou não;
  • Rodar o job de refresh, para saber se vai até o final, ou se pára em algum ponto;
  • Truncar ou dropar/recriar tabelas;
  • Subir a nova versão do esquema Mondrian/Metamodelo no servidor;
  • Testar essas novas versões, primeiro rodando uma consulta simples, para ver se tudo continua funcionando e depois uma coisa mais complexa, para testar os mapeamentos;
  • Medir os tempos de várias atividades e comparar com as médias das medidas anteriores, em busca de problemas de performance;
  • Subir o servidor, baixar o servidor;
  • Atualizar a produção com as novidades desenvolvidas.

E se estamos trabalhando em dois projetos mais ou menos ao mesmo tempo, a coisa fica ainda pior. Raramente projetos diferentes possuem as mesmas configurações, o que nos obriga a reconfigurar o ambiente de desenvolvimento para tratar cada projeto.

O fato é que muitas destas atividades, que levamos a cabo corriqueiramente, sem pensar duas vezes ou se importar com seu “custo”, podem ser automatizadas.

“E daí?”, perguntar-me-ão vocês. Que vantagem haveria em automatizar coisas tão simples ou rápidas? E daí que preciso de dois ambientes (representados em dois BI Servers) diferentemente configurados?

A resposta não é simples. Mas pense em como você fazia as coisas há uma década atrás. Lembra-se do barulho do modem? E hoje? Lembra-se dos clientes de e-mail? E hoje? Essas coisas não mudaram à toa. Ferramentas novas surgiram, novas formas de fazer as coisas vieram à luz. Ninguém pensaria por um segundo em voltar a viver como dez anos atrás.

E essa é a vantagem de você se preocupar com esses pequenos detalhes dos projetos, com as pequenas vantagens que podemos conquistar ao investir um esforço em fazer algo de forma diferente.

Ecossistema de Ferramentas

Existem diversas ferramentas que podem incrementar algum aspecto de projetos de BI. De novo eu vou recorrer ao Pentaho, para estudo de caso, mas reforço que qualquer ferramenta de BI pode ser tratada por essas técnicas.

Eis aqui duas idéias de como melhorar o desenvolvimento de projetos de Business Intelligence.

Servidores

O recurso de desenvolvimento mais trivial para um projeto de BI com Pentaho é o BA Server. O segundo recurso mais trivial é um banco de dados, que funciona como Data Warehouse. Cada projeto de BI com Pentaho requer um banco como DW e um servidor configurado particularmente.

A ferramenta Vagrant foi criada para melhorar a gestão de ambientes de desenvolvimento. Construída em cima de um hipervisor, como VirtualBox ou VMWare, podemos programar um ambiente de desenvolvimento, e ativá-lo/baixá-lo com um comando tão simples quanto vagrant up.

Podemos montar ambientes mono- ou multi-servidores. Com software livre ou proprietário, com qualquer combinação de programas e parâmetros. Podemos compartilhar uma configuração Vagrant via repositório, que pode ser recuperada por qualquer membro do projeto e ter exatamente a mesma configuração para QUALQUER membro do projeto.

Ainda melhor, podemos usar essa mesma configuração para provisionar servidores em produção.

Já pensou? Ambiente de produção 100% igual ao de desenvolvimento? Mais ainda: versionável?

Não é pouca coisa, vocês hão de convir.

Integração

Sempre que um pedaço do projeto é alterado, há um risco de algo se quebrar. Sempre que uma nova transformação é incluída no job de refresh do DW, algo pode espocar ali no meio – da memória da JVM à janela de ETL. Por isso sempre precisamos re-executar tanto os pedaços quanto o todo do processo.

Um Software Livre chamado Hudson pode nos ajudar com algo muito útil. Grosso modo ele monitora um repositório como Git ou SVN e, periodicamente, puxa todas as atualizações do repositório e executa operações sobre elas. Por exemplo, executa algum script ou compila algum código-fonte.

Ao invés de testar os jobs e transformações manualmente, deixamos que aplicativos como o Hudson, chamados de servidores de integração contínua ou CIS. Essa categoria de produtos pode não apenas gerar relatórios sobre a qualidade dos testes, mas também disparar avisos por e-mail para os donos das peças problemáticas.

Conclusão

Não é fácil olhar o que fazemos e enxergar como poderia ser feito melhor, pois sofremos de “vício”. É como escrever um texto e revisá-lo: podemos pegar algumas falhas, pois há coisas que são erros óbvio, mas raramente vamos pegar todos ou quase todos os problemas. Ficamos “cegos” para alguns erros ou escolhas ruins. É importante mantermos o canal de autocrítica aberto, pois só assim estaremos aptos a desencavar oportunidades de melhorias.

Uma área ainda inexplorada em projetos de BI é o desenvolvimento com apoio de automação (AAD? Automation Aided Development? Isso existe?) É prática comum em desenvolvimento de sofwares, mas pelo que eu testemunhei em várias empresas, não existe em BI.

E porque precisamos nos preocupar com isso?


Dê-me seis horas para cortar uma árvore, e eu passarei as quatro primeiras afiando o machado. Abrahan Lincoln


Não acredito que seja preciso responder essa pergunta, mas outra forma de colocá-la é entender que se você foca só no desenvolvimento, full steam ahead, e nunca cuida dos seus instrumentos e ferramentas, então sua produtividade vai cair, não aumentar. Se você quer estar em projeto que entrega valor, em grande velocidade, então trabalhe como o Homem de Ferro, e deixe os computadores fazerem o que eles fazem melhor. ;-)

O campo da automação no desenvolvimento de BI é, praticamente, virgem. Quem tiver uma boa idéia, ou mesmo só uma idéia, vai sair na frente e fazer escola.

Não trabalhe como um noob. Develop like a hero! ;-)

As Soluções Clássicas – CRM

Semana passada começamos a nova série no GeekBI: As Soluções Clássicas. Clique aqui para acessar aquele post.

Hoje veremos a primeira destas soluções: Gerenciamento do Relacionamento com o Cliente, ou em inglês Customer Relationship Management. Sim, você leu corretamente: C R M. O bom e velho, famigerado CRM.


Boa parte do que eu vou trazer aqui pode ser visto no livro Data Mining Techniques, seminal sobre CRM e Data Mining em geral. Se você quer estudar o assunto, esse é o livro.


Relacionamento com o Cliente

Direto ao ponto: antigamente todo mundo comprava tudo – comida, roupa e outras coisas – ao vivo. Ia-se a uma loja, apontava-se o produto, dava-se o dinheiro e saia com ele pela porta. Simples assim. Olhávamos todos uns nas caras dos outros. Íamos a uma loja e não na vizinha porque gostávamos mais desta que da outra. Víamos o dono por ali, conhecíamos os atendentes, confiávamos na procedência dos produtos.

Essa convivência acabava por criar um relacionamento. Você sabe, aquela coisa que sua cara-metade discute ocasionalmente contigo, em uma sessão DR. ;-)

Aos poucos o fornecedor passava a conhecer os gostos do cliente, e este passava a confiar no fornecedor. Esse relacionamento trazia vantagens para ambos: o cliente recebia um atendimento melhor, personalizado, e o fornecedor fidelizava o cliente, tendo mais facilidade para planejar seu negócio e mais oportunidades de vendas. Resumindo, o cliente podia contar com o fornecedor para suprir suas vontades, e o fornecedor via seu faturamento e sua lucratividade aumentar graças à fidelidade do cliente.

Lembram-se como falava-se (ainda se fala?) em fidelizar o cliente? Em atendimento personalizado?

Aos poucos o mercado cresceu e sofisticou-se, e a distância entre o consumidor e o fornecedor foi aumentando. A quantidade de clientes ficou maior, a variedade dos gostos aumentou e a complexidade da linha de produtos acompanhou essa tendência.

Décadas atrás isso era um problema: mesmo na década de 80, o mero volume de clientes e a efemeridade do seu contato eram tamanhos que ficou difícil saber quem era esse cliente, e como atendê-lo melhor. Pense um supermercado, uma padaria, um posto de gasolina etc. São negócios que envolvem um volume considerável de clientes, que recebem um atendimento rápido: pega-se o produto, enche-se o tanque, paga-se e vai-se embora. Não raro esses negócios – que são apenas um exemplo – têm mais de um caixa. É muito difícil para um gerente conhecer os seus clientes nesse ambiente. Não temos mais tempo para jogar conversa fora, ou demorar muito escolhendo os produtos. É vapt-vupt.

Agora pense em redes de supermercados, padarias e postos de combustíveis. Jogue nisso tudo a Internet e a explosão do comércio eletrônico. Se antes o contato com cliente era fugaz, ao menos era físico. Com o e-commerce (precedido pelas onda das vendas por catálogos), o cliente nem mesmo aparecia mais na loja. Nem sequer temos mais uma “loja” no sentido de coisa de tijolos e cimentos!

Como construir um relacionamento com um ser quase mítico, que para todos os efeitos é invisível e que se move à velocidade da luz?

Customer Relationship

Com Data Mining.

Antes de continuar vamos abrir um parênteses sobre a terminologia.

A idéia de “gerenciar” o relacionamento é usar o conhecimento sobre a clientela para tornar cada contato uma nova oportunidade de aumentar a proximidade/fidelidade do cliente, de fazê-lo consumir de você e não do seu concorrente, ao menos na maior parte das vezes.

O conceito de “gerenciamento de relacionamento” não é trivial. Pense no gerenciamento de recursos humanos: atribuir tarefas a pessoas, deslocar e direcionar times para as atividades da empresa e tudo mais. Troque “recursos humanos” por “relacionamento com o cliente” e estamos falando de reforçar um tipo de contato (por e-mail, chat, telefone) ou enfraquecer outro, de injetar dinheiro para propaganda neste e naquele segmento sobre este e aquele produto, ao invés de abrir um comercial na TV. De usar uma oportunidade de contato para incrementar as vendas ou a satisfação do cliente conosco.

Ou forma de pensar que ajuda a entender o termo é “alavancar”: através do gerenciamento dos relacionamentos com os clientes podemos alavancar (ajudar, empurrar) o crescimento da empresa. Usamos as interações para criar ações que movem a organização para mais próximo dos seus objetivos, da sua visão.

Depois de um tempo a frase parece fazer sentido, mas só com um pouco de familiariedade com uma grande operação voltada ao consumidor é que podemos abarcar completamente o conceito.


Continue pensando, uma hora sai! ;-)


Se você entendeu a idéia na seção anterior, que era aprender sobre o cliente para atendê-lo melhor, e com isso maximizar suas vendas, basta transpor isso para o mundo do cliente sem rosto, mas que interage com a empresa. Cada interação é uma oportunidade de conhecer melhor quem está do outro lado do balcão.

CRM = Data Mining

Vejamos: temos muitos clientes, muitos produtos e, mesmo que não individualmente falando, muitos contatos de clientes. O que são esses contatos?

  • Uma compra;
  • Uma re-compra (o cliente voltou para mais;)
  • Uma reclamação;
  • Um pedido de serviço;
  • Etc.

Cada vez que um cliente interage com a empresa, ele deixa um pouco dos seus dados – identificação, localização, interesses, valores, etc. São esses dados que, agregados e acumulados, dá uma montanha de dados que esconde um ouro. Ouro esse que pode ser desencavado com Data Mining. (Mais cliché impossível.)

E Aí?

Que resultados nos traz uma solução de CRM? O que ela consome?

Insumos

Uma solução de CRM analisa dados de todos os sistemas da empresa que tenham alguma interação com o cliente – e mesmo alguns que não têm. Os mais valiosos são aqueles que dão informação direta sobre o cliente: caixas (por isso é importante pedir o CPF, já que permite saber quem é o cliente), reclamações, trocas. Canais de atendimento, como call centers, também são valiosos (por isso que a maioria pede alguma identificação de quem liga.)

Os dados não precisam ser coletados em um DW – surpresa! – mas ajuda muito fazê-lo. Coletar dados históricos, integrá-los e limpá-los são os primeiros passos de qualquer projeto de Data Mining, e por isso mesmo são os primeiros passos do projeto de CRM. Se a empresa decide por uma iniciativa de coleta de dados isolada, estanque, descartando um DW, desperdiça boas oportunidades e gera alguns problemas:

  • DW é uma tecnologia estável, e projetos profissionais de DW consomem menos recursos, com melhores resultados. Nem preciso dizer que projetos amadores, de qualquer coisa, sempre dão dor-de-cabeça, né?
  • Gera retrabalho/duplicação de esforços: se apenas o projeto de CRM coleta e organiza os dados dos clientes, qualquer um que queira usar esses mesmos dados na empresa precisa atrapalhar o projeto de CRM, ou duplicar o trabalho em outro lugar;
  • Seria mais caro: a idéia de evitar o DW é – imagino – poupar o gasto com profissionais “do ramo” e ambientes especiais. Trocar um projeto profissional por outro amador tende a causar atrasos e dificuldades;
  • CRM é uma boa âncora para DWs corporativos. Como DWs podem ser usados pela empresa inteira, ter um bom argumento a favor de um DW – como o CRM – é um bom argumento para vender a idéia do DW;
  • CRMs tendem a dar bons resultados e ajudam a melhorar a imagem de todas as tecnologias de BI na empresa, facilitando a mudança de cultura necessária (um dia aborarei isso.)

E isso é parte do ponto de vista da tecnologia. A outra parte deste lado seriam as máquinas, que podem ser muito grandes em função dos volumes de dados envolvidos, e os softwares, que podem ser Software Livre ou proprietário, mas definitivamente são escolhas secundárias.

Olhando para o lado dos recursos humanos, um projeto de CRM requer um Analista de Data Mining com experiência em CRM. Como esse profissional é um bocado caro para ter na folha de pagamentos (primeiro pela especialização, segundo pelo uso relativamente limitado de suas maiores habilidades), o mais comum é recorrer a uma boutique de Data Mining para trazer esse especialista para o projeto, temporariamente. O time do projeto é completado, via de regra, por gente da casa, com membros da TI para ajudar na parte de coleta e tratamento dos dados, e gente do negócio para ajudar na priorização e construção dos modelos.

Entregáveis

Eu adoro dizer que o entregável de um projeto de Data Mining é dinheiro, muito dinheiro!!, mas isso costuma não colar. Pena. :-) A próxima melhor definição dos resultados entregues por uma solução de CRM é “incrementar o valor do cliente”, que é feito através de ações planejadas com o auxílio da inteligência obtida da análise dos dados. Mas com o que se parece, o que é essa “inteligência”? Qual é, concretamente, o entregável do projeto, qual é o produto?

Como eu já coloquei em outro post, o entregável de um projeto de Data Mining são modelos matemáticos. Cada um destes modelos automatiza o processo de decisão em relação à próxima interação com o cliente. Há tantos modelos possíveis que eles são agrupados em várias categorias: Sales Promotion, Survival Analysis, Churn Prevention etc. etc. etc. Vamos ver alguns dos modelos mais famosos.

Para começar, um dos modelos mais interessantes é o Lifetime Value do cliente, que é uma estimativa do valor do cliente por todo seu relacionamento ao longo do tempo, ou dentro de um horizonte, como alguns meses ou anos. De posse dessa estimativa podemos avaliar com mais clareza se vale a pena ou não manter um determinado freguês. Suponha que certo cliente peça um desconto. Vale a pena dar esse desconto para ele? Se fôssemos o dono da loja, sabendo tudo de tudo, seria fácil decidir:

  • Cliente novo?
    • Sim. Parece do tipo que dá lucro?
      • Sim: dê o desconto;
      • Não: recuse o pedido;
    • Não. Cliente valioso?
      • Sim: dê o desconto;
      • Não: ofereça um desconto menor.

Agora, como ajudar a moça do call center da Americanas.com a decidir? Montando o mesmo script baseado no Lifetime Value!

A saída dessa ação pode ser encaixada com os resultados dados por outros modelos, como os que atuam no incremento das vendas. Imagine se ao invés de recusar o desconto, ou simplesmente concedê-lo, a tal atendente ainda tenha no script ramificações para:

  • Up-selling: vender algo mais caro ou mais valioso (com maior lucratividade;)
  • Cross-selling: fazer o cliente comprar alguma outra coisa, não aparentemente relacionada;
  • Recomendações: recomendar algo mais do mesmo tipo, para aproveitar o desconto.

Cada uma destas ideias é um modelo que o CRM pode gerar.

E que estratégia a organização deve perseguir? Adquirir clientes, ou se esforçar para aumentar a lealdade dos já existentes? (Pegadinha: clientes novos custam muito mais caro que os já adquiridos, por isso é sempre importante investir na manutenção da sua clientela.) Um projeto de CRM ajuda a desenhar estratégias oferecendo modelos para:

  • Campanhas de retenção, para evitar perder o cliente para a concorrência;
  • Estímulo de uso, para fazer o cliente se lembrar que possui um serviço, ou se lembrar de voltar a nos procurar;
  • Programas de fidelidade, que estimulam o cliente a decidir por nós ao invés de pela concorrência;
  • Redução de atrito: já é difícil segurar o freguês, então pelo menos vamos tentar não empurrá-lo para longe, que é o objetivo deste modelo, de Churn Reduction.

E mesmo quando temos alguns desertores, há modelos que apoiam iniciativas reparadoras. Uma dessas chama-se Customer Reactivation que, como o nome mesmo diz, tenta motivar um freguês que não nos procura a voltar a entrar em contato. Um modelo mostra que cliente é mais propenso a ser recuperado por esta ou aquela ação.

Falando em problemas como clientes, outro conjunto de modelos lidam com o risco que um cliente representa e como manter baixo esse risco. Coisas que o departamento financeiro sempre quer saber como quem tem tantos porcento de falhar no pagamento? Dos clientes que estão atrasando ou deixando de pagar, quais têm maior propensão a pagar alguma coisa, e quanto?


Sempre que eu menciono um destes exemplos você pode tentar imaginar o que estaria acontecendo na proverbial lojinha. A reativação, por exemplo, pode ser uma visita ao cliente, só para bater papo, ou para levar algo que ele gosta. Um pouco de tato pode evitar vender fiado para quem sabemos que vai dar trabalho, e a redução de atrito pode ser um pedido de desculpas por uma burrada. E o estímulo ao uso? Que tal um brinde, que ele aproveitaria melhor se comprasse algo? Não estou brincando: o programa Cliente Mais do Pão-de-Açúcar me deu, uma vez, uma tigela para comer cereal. Fofo, não? (Deu certo, só para constar – por algum tempo eu passei a comprar cereais com mais regularidade.)


Não é Para o Meu Bico

Uma espécie de regra geral para projetos de Data Mining é “precisa de grandes volumes de dados”. Ainda que grande seja uma coisa relativa, hoje em dia nunca é menos de milhões de linhas – milhões de linhas de vendas, de interações com clientes, de produtos, de acessos etc. Isso é uma coisa natural, por que a maioria desses métodos são de inferência: fazem estimativas a partir de um comportamento observado. É como o caso da moeda: não dá para saber se ela é viciada com apenas um arremesso. Precisamos de uma quantidade que mostre a tendência para sair mais cara ou mais coroa, ou então termos uma certeza razoável de que é uma moeda “normal”. Quanto mais dados, menor ou mais delimitado é o erro em relação a uma estimativa. Inversamente, quanto menos dados, maior a incerteza da estimativa.

Essa necessidade de um certo volume de dados não é motivo para barrar análises com menos dados. O erro será maior, mas alguma informação sempre é melhor que nenhuma. Projetos de Data Mining, em geral, e de CRM em particular, podem ser encetados por sua organização mesmo que você não disponha de montanhas e montanhas de dados. Apenas seja mais precavido em relação às iniciativas que vão usar os resultados para alavancar o crescimento da empresa.

Para demonstrar isso, eu deixo vocês com um caso real. Há vários anos, numa das minhas turmas da 4Linux, tive um aluno dono de um supermercado, de São Carlos. Ele queria dispor de relatórios e análises sobre seus dados (principalmente dos caixas) e, como era muito caro contratar um projeto, decidiu fazer tudo ele mesmo. Eu fiquei impressionado, afinal ele era o dono do supermercado (acho que tinha algum sócio, não me lembro), que não era uma loja pequena. Assumir um projeto técnico com uma empresa inteira para tocar, não importa quão pequena, é um desafio e tanto. Bom, ele terminou o curso, e voltou para São Carlos.

No começo de 2015, estimulada pelo Caio Moreno, o Prof. Coruja, a comunidade de Pentaho de São Paulo se juntou para um Meetup. Qual não foi minha surpresa ao reencontrar esse empresário lá?! Já fiquei impressionado de vê-lo se deslocar para um encontro num final de dia, começo de noite, de uma quarta-feira em São Paulo, mas eu fiquei de queixo caído quando ele falou o que estava fazendo: não apenas implantou BI no supermercado, como agora estava atrás de Data Mining para fazer CRM!!! :-O A meta dele era simples, modesta até, mas mesmo assim seria capaz de melhorar a rentabilidade do negócio: se eu não me engano, ele queria reduzir perdas por vendas a prazo. O simples fato de passar da administração do risco de manual para automática já teria impacto positivo no negócio dele.

Nunca mais falei com ele, infelizmente, mas não tenho a menor dúvida que conseguiu, e que hoje deve estar fazendo mais alguma coisa surpreendente e inteligente.

Customer Intelligence

CRM é um termo que ficou meio desgastado – sabe, como OLAP, metadados e o próprio BI. Como o conceito de “gerenciamento do relacionamento” não é algo transparente, imediatamente apreensível, muitas empresas se apoderaram dele para usar em qualquer coisa e surfar a onda do mercado (de novo.) Daí hoje em dia temos CRM que maneja envio de e-mails (mala-direta), CRM que recebe/dispara teleatendimentos (call center), CRM que monitora redes sociais (social-thingamajig) blá blá blá. Nenhum destes casos responde pela “coisa”. Para se livrar desses mal-entendidos, a empresa líder de BI, o SAS, renomeou o campo como Customer Intelligence (“excelente” abreviação: SAS CI – entenderam? Sasci, Saci. Kkkk…)


Bom, o SAS já renomeou quase tudo de BI (incluindo BI, que virou BA), por isso não há nenhuma novidade aqui. Para mim, porém, o termo Customer Intelligence é tão opaco quanto Customer Relationship Management, o que sempre me conduz à mesma conclusão: a ideia não é ajudar, é ser dono exclusivo de buzzwords. SAS, SAS, tsc, tsc… Adiante.


A solução SAS é completa, com planejamento, estratégia, gerenciamento de campanhas, medida de eficiências etc. Não vou entrar nela porque o post é sobre CRM e não sobre o SAS e seus produtos, mas vale a pena conhecê-la. Se quiser ver um pouco mais da cara do resultado de um projeto de Data Mining, que fica por trás de um projeto de CRM, pode ler um pouco sobre o SAS/Enterprise Miner.

Conclusão

Uma forma de entender a disciplina BI é como uma ferramenta de apoio à decisão, ou de automação da decisão. Neste sentido, projetos de Data Mining produzem recursos empregados na automação das decisões de uma empresa, melhorando a precisão dessas decisões e aumentando a velocidade com que são tomadas. Em uma empresa moderna, que dependa de computadores no seu métier diário, minguém consegue manter tudo dentro da cabeça para conseguir entender o que precisa ser feito, e como. Só BI consegue isso, através de Data Mining, em geral, e CRM, em especial, no aspecto da clientela.

Gerenciamento do Relacionamento com Clientes, ou CRM, é um projeto que busca entender o Cliente para melhor atendê-lo.

Um projeto de CRM entrega modelos matemáticos que alimentam desde o planejamento estratégico até a implementação de iniciativas e ações na empresa, sempre com o objetivo de maximizar o valor do cliente, enquanto ajuda a organização a prestar um serviço de maior qualidade. Em outras palavras:


Um projeto de CRM dá ao cliente um atendimento melhor, personalizado, e ao fornecedor a maximização do valor de cada cliente.

Projetos de CRM são ganha-ganha.


Porque tão poucas empresas investem em Data Mining, para mim, é um mistério. Que quase nenhuma tenha um projeto de CRM, então, é um mistério envolto em um enigna.

No próximo post (que não será semana que vem): Credit Scoring. Até lá! ;-)

Dica: Atalhos do Pentaho em Linux

Uma coisa que eu sempre senti falta no Ubuntu era a facilidade de criar atalhos como a do Windows.

A criação de atalhos (ícones no menu principal do sistema operacional) é algo bem simples no Windows: clique com o botão da direita sobre o programa em questão e selecione a opção Send to -> Desktop (create shortcut).

Criando um atalho de programa no Windows.

Criando um atalho de programa no Windows.

Já no Ubuntu a coisa não é tão simples, mas também não é impossível. Primeiro instale um programa chamado A La Carte com este comando:

    sudo apt-get install alacarte

Para registrar um programa na interface gráfica do Ubuntu precisamos conhecer o caminho inteiro até o script, bem como o nome do script. Por exemplo, para o PDI o nome do script é spoon.sh. Ele sempre fica dentro do diretório ./data-integration, que por sua vez pode estar em qualquer lugar. Suponha que tenhamos instalado o PDI em /opt/pentaho. A linha de comando completa para o Spoon seria:

    /opt/pentaho/data-integration/spoon.sh

Agora monte uma linha de comando desta forma:

    bash -c "cd /<DIRETÓRIO>/ && ./<SCRIPT>.sh"

Usando o Spoon como exemplo, fica assim:

    bash -c "cd /opt/pentaho/data-integration/ && ./spoon.sh"

Estamos pronto para registrar o ícone. Faça assim:

  1. Abra o menu principal do Ubuntu, procure e rode o programa que você acabou de instalar, o A La Carte;
  2. Esse programa vai mostrar uma estrutura de pastas, representando as pastas do menu principal do Ubuntu. Você pode criar pastas e subpastas à vontade para organizar os ícones. Por exemplo, crie uma nova pasta na Raiz, como BI, e dentro dela uma outra pasta, como Pentaho. Para isso use o botão New Menu;
    Criando uma nova pasta no menu do Ubuntu.

    Criando uma nova pasta no menu do Ubuntu.

  3. Clique na nova pasta, para selecioná-la, e em seguida clique no botão New Item para criar um novo ícone;
  4. Vai se abrir uma janela para registrar o programa. Preencha-a assim:
    • Name: Spoon 4.8
    • Command: cole aqui a linha de comando montada anteriormente;
    • Comment: pode deixar em branco;
      Criando um atalho no menu do Ubuntu.

      Criando um atalho no menu do Ubuntu.

  5. Clique em Ok para salvar o novo item, e depois Close no A La Carte para salvar tudo.

Evidentemente os detalhes mudam a cada programa que você registrar: Report Designer, Schema Workbench etc.

Pronto! A partir de agora você pode chamar o programa sem precisar abrir um terminal e digitar tudo.

Voi-lá!

Categorias:Generalidades Tags: , ,

As Soluções Clássicas

Se você pudesse olhar para frente no tempo, para o futuro, o que iria querer ver?

Vamos deixar de lado coisas como “números da megasena”, “resultados de jogos de futebol” e outras opções pessoais, e focar apenas no seu lado profissional. Se seu trabalho fosse aumentar a lucratividade da sua organização, e você pudesse olhar o futuro, o que você iria querer ver?


Encare “lucratividade” como uma métrica de sucesso da organização – entregar mais por menos. Para uma fábrica é vender mais com um custo menor, para um hospital é atender mais gente gastando menos tempo e/ou dinheiro, para o governo é entregar o prometido dentro do prazo ao menor custo possível e assim por diante.


O preço do dólar? A demanda por laranjas? O valor das ações na Bolsa de Valores?

Primeira Lei de Newton

Talvez você não se dê conta, mas passamos o dia inteiro olhando para o futuro. Exemplos? Aos borbotões!

  • Saímos de casa pensando em fazer o mesmo caminho que fizemos ontem porque ontem funcionou;
  • Ou então planejamos um caminho diferente, porque ontem o de sempre estava ruim;
  • Assistimos jornal na TV sempre no mesmo horário, porque desde sempre aquele foi o horário do jornal;
  • Agendamos compromissos, fiando-nos em uma expectativa de que nada vai mudar de uma hora para outra;
  • Planejamos festas de aniversário mesmo sem saber se estaremos vivos daqui à pouco (uga, essa foi forte, sorry;)
  • Estudamos a matéria vista ontem para prova amanhã porque temos fortes motivos para acreditar que a prova vai discorrer sobre aquela matéria e não outra – mesmo nunca tendo enfrentado uma prova daquelas.

Eu poderia fazer isso o dia inteiro, mas acredito que já reforcei a idéia: se nada aparecer para mudar a rotina, a rotina continuará como sempre foi. Algo como a Primeira Lei de Newton, aplicada à nossa vida diária.


Primeira Lei de Newton: Todo corpo continua em seu estado de repouso ou de movimento uniforme em uma linha reta, a menos que seja forçado a mudar aquele estado por forças aplicadas sobre ele.


Agimos intuitivamente em relação ao futuro. Procuramos indícios, pistas, sobre como as coisas serão daqui a uma hora, a um mês. Olhamos para o céu para estimar a chance de chover quando estivermos andando na rua, olhamos o Waze para tentar saber se vamos nos atrasar ou não.

A parte curiosa disso é que não estamos, de fato, olhando para o futuro, mas sim avaliando a tendência atual e calculando onde estaremos se essa mesma tendência se mantiver. (Não precisamos parar por aí: podemos fazer uma análise da tendência que a tendência tem de mudar – chamamos de aproximação de segunda ordem. E depois de terceira ordem – tendência de mudar da tendência de tendência da mudança – quarta etc. etc. etc.)

Você está sentado na sua mesa de trabalho? Pode ver a empresa de onde está? Então olhe a seu redor. Consegue enxergar os pedidos chegando, as entregas saindo? Consegue ver o movimento que está fazendo essa organização na qual você trabalha? Claro que não: sua empresa se move em um plano invisível a olhos nús, o plano dos dados. Você pode até aprender a associar a entrada e saída de pessoas e veículos, o toque dos telefones e outros sinais à atividade da empresa, mas isso não seria nada além de um reflexo do que acontece de verdade.

Talvez não seja possível ver a empresa funcionando, mas se pudermos coletar os dados que fluem por ela, conseguiremos enxergar seus movimentos.

Dados são a nova realidade.

Dados são a nova realidade.

Seguindo na mesma linha da intuição com o dia-a-dia, entendendo o movimento dos dados podemos estimar a chance de algum evento ocorrer: ganhar ou perder uma venda, receber um chamado de manutenção, um equipamento apresentar falha.

Se o nosso dia-a-dia é resolvido, algo automaticamente, pelo nosso cérebro, como resolver o “dia-a-dia dos dados”?

Ciência & Futuro

Bom, o fato é que a resposta para essa questão já existe, e a vimos na escola: são as tais das “teorias”. Uma teoria é um conjunto de conhecimentos que explicam algo, e por explicar queremos dizer “prever um determinado resultado a partir de uma certa entrada”.

Um exemplo pode ajudar a entender o que eu quero dizer: o que acontece se você jogar alguma coisa para cima? Resposta: cai de volta (na sua cara, se você não tomar cuidado.) A repetição desse experimento várias e várias vezes nos dá uma certa segurança para afirmar que “coisas jogadas para cima, caem”. Essa é uma Teoria, que explica o que acontece com as coisas quando são jogadas para cima. Ela foi criada a partir da nossa observação. Usando essa teoria podemos prever o que vai acontecer se você jogar um sofá, uma bola ou uma vaca para cima: vão cair de volta.

Podemos sofisticar nossa Teoria de Coisas que Caem mais e mais, ao ponto de dizermos com que velocidade as coisas vão cair de volta, que distância vão percorrer e assim por diante. Podemos continuar fazendo experimentos e testando nossa teoria, chegando a formas cada vez mais genéricas.

O exemplo que começamos acima termina assim: Sir Isaac Newton estabeleceu uma lei chamada Lei da Gravitação Universal, que diz como qualquer coisa cai em relação a qualquer outra coisa, em qualquer lugar do Universo conhecido. Ei-la:

Lei da Gravitação Universal.

Lei da Gravitação Universal.

Lei da Gravitação Universal: Duas partículas quaisquer do Universo se atraem por meio de uma força na direção que atravessa seus centros de massa, diretamente proporcional ao produto de suas massas e inversamente proporcional ao quadrado da distância que as separa.

Através dessa equação podemos conhecer a força que age sobre quaisquer duas partículas. Usando a Segunda Lei de Newton, a famosa F = m.a, podemos calcular a aceleração que essas partículas sofrem. Com isso e a equação da posição de um corpo em função da velocidade e aceleração (S = S0 + V0.t + a.t^2/2 – conhece essa?) podemos determinar exatamente onde um corpo vai estar a partir de um momento inicial, desde que S0 e V0 sejam conhecidos.

Dadas as condições iniciais de dois corpos no Universo, em um dado momento, as Leis de Newton e a Lei da Gravitação Universal nos permitirão saber onde elas estarão, em um tempo futuro.

Estamos prevendo o futuro? Não, estamos apenas acompanhando a evolução da realidade com o que conhecemos a respeito de seu funcionamento. É como se a Ciência nos desse uma janela para o futuro, ainda que seja apenas a extrapolação do passado.

Data Mining & Negócios

Uma forma de descrever tudo isso é dizer que as leis criadas por Newton oferecem um modelo de interpretação do Universo. Todas as equações citadas formam um modelo matemático, que pode ser usado para extrapolar o presente para algum tempo no futuro.


Só para não deixar pontas penduradas: todas essas leis e teorias são conhecidas pelo nome coletivo de Mecânica Clássica. Dizemos, então, que a Mecânica Clássica é um modelo que explica a nossa realidade cotidiana.


Bom, e se pudéssemos fazer o mesmo com os dados da nossa empresa, da nossa organização? E se pudéssemos olhar para nossos dados passados e tirar deles uma relação matemática? Então poderíamos usar essa relação para estimar o que vai acontecer no futuro!

É exatamente isso que faz Data Mining: busca um padrão – um modelo matemático – nos dados.

Sabe aquela coisa de BI é para trás, BA é para frente? Bullshit. Data Mining é Inteligência de Negócios no seu máximo!

Voltando à nossa pergunta inicial, se você fosse responsável por uma empresa, e pudesse ver o futuro, o que você iria querer ver?

As Soluções Clássicas

Estamos em 2016. Faz quase cinquenta anos que o conceito de Armazém de Dados está por aí, outro tanto de anos para BI, e séculos que a Ciência, tal como a conhecemos, existe. Temos centenas e centenas de anos de técnicas, métodos, teorias e ferramentas para explorar a realidade ao nosso redor e tentar extrair dela o mecanismo que está por trás da Natureza.

Mais ainda: não é de hoje que tentamos analisar os dados de nossas organizações em busca de estimativas mais seguras do que vai acontecer. Desde que a primeira empresa coletou dados pela primeira vez, alguém tentou analisá-los para extrair vantagem de negócio (siga aquele link: aquela história é de 1865.) Temos décadas, minto, temos mais de um século (1911) de investidas formais nesse campo.

E o que é que já existe?

Este post inaugura uma nova série do GeekBI, na qual serão apresentadas as soluções de Business Intelligence hoje tidas como “clássicas”. De início eu planejei os seguintes posts:

  • CRM
  • Churn Detection
  • Credit Scoring
  • Atuarial
  • Supply Chain
  • Fraude
  • Risco

Tem alguma solução que você gostaria de conhecer? Deixe sua sugestão na área de comentários!


Todos esses casos são baseados em práticas do mercado de Data Mining e conhecimento comum de consultorias da área. Para não ficar só na teoria, no abstrato, eu vou buscar detalhes mais concretos com os maiores especialistas em BI e Data Mining do mundo, o SAS e tentar tornar tudo mais palpável.

Visão geral das soluções de BI do SAS.

Visão geral das soluções de BI do SAS.

Até a próxima!

Spam, Spam, Spam

Monty Phyton deve ser um caso único na história da Informática. Décadas antes de as coisas começarem a se parecer com o que temos hoje, eles faziam graça com as idéias mais bisonhas e bizarras que você pode imaginar. Essas maluquices foram tão marcantes para a geração que cresceu vendo Flying Circus que acabou em pelo menos dois casos notórios. Um deles é o nome da linguagem Python.


Assista Em Busca do Cálice Sagrado e A Vida de Brian para um curso-relâmpago em loucuro pitonesca, muito pitoresca.


O outro é a gíria spam.

Todo mundo hoje em dia sabe o que é spam: é mandar uma mensagem de e-mail, newsgroup etc. para muita gente ao mesmo tempo, indiscriminadamente. Eu estava lá, vendo essas coisas acontecerem: um belo dia um colega de facul (IFGW) contou dessa coisa que estava acontecendo, spam. E que o nome vinha de um programa de tevê da Inglaterra, que tinha uns vikings cantando “spam, spam, spam”.

Spam, Spam, Spam tem essa spam cara no spam Brasil. Bleagh!

Spam, Spam, Spam tem essa spam cara no spam Brasil. Bleagh!

Estávamos em 1991 e não existia wikis, fórum, Yahoo Answers – nada dessas coisas que hoje tomamos como garantidas. Era tudo, ainda, boataria, mas agora vinha pela Internet (e dizíamos hoax, não boato, :-) .) Não tínhamos youtube, e webcams eram uma brincadeira para saber quando o café estava pronto.


cooooof-cof-cof!!! Estou sufocando no meio de tanta naftalina! Arf! :-D (Os smileys são dessa época também! (ARGH!) )


Mas hoje nós temos. Clique aqui para assistir o famigerado sketch do Monty Python que deu origem à gíria. Depois volte aqui e continue lendo – vou relacionar isso com BI já, já.

Spam, Spam, Spam! Assista o vídeo, rache o bico.

Spam, Spam, Spam! Assista o vídeo, rache o bico.

Recobrou o fôlego? Vamos em frente.

A mensagem do sketch é simples, direta, genial: abusar de uma coisa boa a torna ruim. E não pense que isso é um exagero ou que estou forçando a barra. Água em excesso mata, oxigênio em excesso mata, comida em excesso mata! O excesso é prejudicial. Existe um outro aforismo, também muito famoso, sobre esse tema:

A diferença entre o remédio e o veneno é a dose.

Paracelsus

“Diacho, Fábio”, dirão vocês, “que é que isso tem a ver com BI??”

Hoje em dia? Tudo.

Dashmania

No post anterior eu contei um pouco do que eu vivi durante a época em que a idéia de visualizar os dados em um painel – um dashboard – ganhou força.

Faça uma busca, no Google mesmo, por BI. Só, mais nada. Depois explore os primeiros links patrocinados – não os resultados da busca, mas os patrocinados. Para mim, veio isso:

Resultados patrocinados da minha busca por BI no Google.

Resultados patrocinados da minha busca por BI no Google.

Eu segui esses links, para ter uma idéia do que anda pelo mercado ultimamente. Claro que não vou colocar tudo que vi aqui – seria maçante, e alguma destas empresas poderia interpretar mal a minha idéia.

Resumo da ópera: exceto no Manta, que parece ser uma ferramenta de otimização para ETL, aparecem todas a buzzwords, exceto (curioso…) BigData. Só que o suco de todas essas propagandas é “PAINEL”.

Só para confirmar, dei uma olhada de novo em todos os fornecedores “tradicionais” de BI, como MicroStrategy. (Caramba, dos “tradicionais” sobrou só o MicroStrategy. Hyperion, BO etc. etc. etc. foram todos absorvidos e sumiram…) E tem os novatos, como Tableau, Spotfire e o household name da área, QlikView. Painel, Painel, Painel.

O Mundo É Um Palco, Não Um Painel

Shakspeare disse:

All the world’s a stage,

And all the men and women merely players;

Na boa? Se Shakespeare vivesse hoje, aposto que ele diria:

All the world’s a dashboard,

And all the men and women merely KPI Widgets;

(Nossa, citei Shakespeare! Posso morrer agora porque nunca vou fazer nada melhor que isso! Kkkk…)

Painel, Pinel

Não tem como assistir Spam, Spam, Spam e depois de ver tanto Painel, Painel, Painel não dar uma risada… :-) Eu devia fazer um vídeo… Hmm….

Como seria o sketch do Monty Python para BI, hoje em dia?


  • Olá, meu bom homem. O que você tem de BI?
  • Bom, temos “Painel, Relatório, Integração de Dados“, “Analytics, Painel, Data Discovery Painel, Painel Discovery Analytics Painel“, “Painel, Relatórios Painel, Painel Painel Dados“, “Data Painel Discovery Painel Painel“…
  • Não quero painéis. Tem Relatórios sem Painel?
  • Painel Relatórios sem Painel? Quem iria querer isso? Bleagh!

:-D

Dashboards são boas ferramentas, como também são relatórios, OLAP e Data Mining. Mas assim como Spam, usar uma só ferramenta, o tempo todo, para tudo, é um desastre.

Conclusão

Como eu sempre digo, já tentou cozinhar feijão em uma frigideira? Ou fazer um bife em uma panela de pressão? Talvez você conseguisse feijão frito com carne de panela, mas nunca feijão e bife.

Se você precisa analisar dados em tempo real, você não precisa de BI. Olhe meu post Analítico ou Operacional para uma discussão do tema.

Se você precisa apresentar dados sumariados, atraentes, de maneira sexy, painéis são a tua ferramenta. E também o são para tarefas como acompanhamentos diversos.

Mas BI não é só painel. Putz, BI tem tanto a ver com painel como um carro tem a ver com um avião: em comum têm apenas o fato de serem meios de transporte, porque de resto são totalmente diferentes. Não dá para ir atá a padaria de avião, como não dá para chegar à Antártida de carro.

Não use só painéis, painéis para tudo, ou você vai ficar sem nada.

Spam, Spam, Painel, Spam, Painel, Painel, Painel, Spam, Painel, Painel!

Spam, Spam, Painel, Spam, Painel, Painel, Painel, Spam, Painel, Painel!

Até a próxima. ;-)

Balanced Scorecard & BI

A teoria do Balanced Scorecard por Norton e Kaplan, ou BSC para os íntimos, teve um impacto significativo no mundo do BI. Talvez, aliás, seja essa a raiz da mistura corrente entre OI e BI. Eu estava lá quando isso estava acontecendo, e vou dividir com vocês um pouco das minhas histórias sobre aqueles dias loucos.

O Mundo Até Então

Até meados do ano 2000, o top em BI de usuário era um DSS conhecido pelo acrônimo EIS, de Executive Information System. O EIS era composto por um DW e uma ferramenta OLAP, organizados de tal forma que um executivo poderia enxergar a empresa inteira a partir do topo, da maior agregação, e descer, seguindo o caminho que desejasse, até o nível mais baixo, da linha.

Assim, por definição, todo executivo ganhava o seu centro de controle ou painel de monitoração empresarial. O apelo do sistema é que ele dispensava o usuário de conhecer programação de qualquer tipo, pois um EIS era voltado para o nível gerencial, o nível tático-estrégico da organização.

Ao redor do EIS haviam uma gama de opções, entre produtos e soluções.

Por exemplo, o usuário poderia pedir um gerador de relatórios (um produto), para construir as listagens que bem entendesse, e quando desejasse. Ganhou alguma notoriedade, nesta época, o slogan “entregar o dado certo, no momento certo, para a pessoa certa”.

E haviam as soluções de BI (e ainda hão), que são pacotes fechados com um propósito definido. Soluções como CRM (gerenciamento da interação com cliente), Churn Detection (detecção e prevenção de atrito, como em call centers) ou Credit Scoring (concessão de crédito automatizado), eram desenvolvidas com uso de Data Mining sobre os dados das empresas.

E não esqueçamos dos DWs, projetos sempre complicados e difíceis, e quase sempre operando aos trancos e barrancos. A tecnologia de DWs passou por três momentos de inflexão: a criação de bancos de dados em dispositivos de acesso aleatório, por volta de 1960, foi o primeiro. DASDs habilitaram a existência de Bancos de Dados Relacionais, sem os quais não seria possível construir um serviço viável de exploração de dados – antes usavam-se fitas magnéticas, e qualquer coisa mais complexa que uma listagem agregada era um transtorno. Depois veio o Modelo Dimensional, no início dos anos 90, que resolveu a vida dos usuários ao montar os dados de uma forma inteligível, apta à exploração por analistas de negócios. Ainda faltava resolver o acúmulo de dados, que seguia também aos trancos e barrancos, atendido parcialmente por Modelagem Dimensional. O advento do Data Vault, já na década 2000, resolveu essa parte. Hoje em dia, DWs são problemas só para quem está desatualizado desde 2003.

Enquanto Isso, Na Sala de Monitoramento…

Quando alguém decide que quer gerenciar uma empresa quando crescer, esse alguém faz uma faculdade de Administração de Empresas. Dentro dessa especialidade existe um sem-número de técnicas e teorias voltadas a entender como uma empresa funciona e como tomar decisões para que ela cresca.

Dentro de Administração de Empresas existem subconjuntos de conhecimento que tratam do monitoramento de uma organização, bem como o planejamento estratégico dela. O termo “balanced scorecard” surgido durante a década de 90 refere-se, de maneira geral, a uma técnica de monitoramento de rendimento (performance) que usa indicadores financeiros e não-financeiros. Essa técnica acompanha a execução das atividades por grupos de profissionais e as consequências dessas atividades. Por algumas coincidências, e pelo movimento do mercado, criou-se a percepção que Robert Kaplan e David Norton criaram o conceito, o que não é verdade, pois a técnica já existia antes. Eles apenas desenvolveram um sistema de gerenciamento estratégico que usa a idéia de um balanced scorecard como pino central.

Balanced Scorecard

A premissa de um Balanced Scorecard é que uma empresa pode monitorar a execução de suas estratégias acompanhando certos indicadores-chaves. O Balanced Scorecard do Norton e Kaplan é uma formalização desse conceito em uma metodologia que, automatizada com auxílio da Informática, cristalizou-se em uma solução chamada Strategic Management System (SMS), ou Sistema de Gerenciamento Estratégico.

Essa metodologia está explicada no livro deles, o The Balanced Scorecard: Translating Strategy into Action. Em tese, qualquer um pode implementar o sistema em sua empresa, a partir deste livro. Eu consegui encontrar uma companhia, ESM, que vende tal sistema, aparentemente uma encarnação oficial das teorias da dupla. Eis alguns screenshots dele:

Exemplo de painel ESM.

Exemplo de painel ESM.

 

Exemplo de mapa estratégico ESM.

Exemplo de mapa estratégico ESM.

O grande truque, que deu fama e fortuna aos autores, é saber que parâmetros monitorar e entender como esses parâmetros surgem das métricas geradas pela empresa, como essas métricas se ligam aos objetivos estratégicos.

Exceto por toda essa teoria, um SMS é, nada mais, nada menos que uma coleção de painéis de instrumentos – os famigerados dashboards – com dados coletados dos sistemas da empresa.

So The Story Goes…

O livro deles saiu em 1996, mas eles já vinham fazendo sucesso com essas idéias desde 1992, quando saiu o primeiro paper sobre o tópico.

O mercado por SMS estava aquecido devido ao sucesso da dupla e suas idéias. Implementações desses conceitos começaram a surgir, e a face mais visível desses sitemas era… o dashboard! Mas não acabava aí, não! Os dados que eram apresentados nesses painéis vinham, em geral, dos sistemas informatizados da empresa.

  • BSC é voltado para administração empresarial;;
  • BI também;
  • BSC usa dados integrados;
  • DW, uma subseção de BI, integra dados da organização;
  • BSC apresenta dados em visualizações bacanas;
  • BI também.
  • Etc.

Entenderam o caminho que a coisa tomou? Até parece que BSC e BI estão ligados intimamente, mas o fato é que nem de longe BSC é uma solução de BI!

  • BSC foca em dados correntes e suas relações determinadas a priori, em monitorar os dados da empresa para aquilatar o consistência do planejamento estratégico e sua execução. Os dados são atualizados muito frequentemente (um dia ou menos) e, em boa parte das vezes, apenas a variação dos indicadores é acompanhada, não dos dados mais granulares. O histórico dos dados em si não é capturado, e portanto não é usado;
  • BI é voltado para acumular dados históricos e analisá-los para descobrir suas relações a posteriori, em busca de entender o negócio. Dizemos que os dados são usados para tentar modelar, matematicamente, o funcionamento da companhia. Fala-se em previsão, em estimativas, em correlações previamente ignordas entre as variáveis etc. etc. etc.

Não são coisas estranhas entre si, pois ambos usam dados gerados em sistemas informatizados (BSC menos, BI mais), mas não são a mesma coisa, ou sequer parentes próximos.

Mesmo assim formou-se, no mercado de BI, a percepção de que BSC faz parte de BI.

Ok, vamos relegar essa parte e focar na questão “empresas vendendo BSC, o pão quente do momento”. Imagine o que aconteceu: empresas de BSC, como a tal da ESM mencionada acima, tinham lá o seu produto, que era uma novidade então.

E as empresas que vendiam BI, tinham o quê para mostrar como sendo BSC? Coleta de dados e apresentação de dados – e a teoria do BSC em um livro! Quando vendedores de BSC mostravam seu produto, a aparência, a parte visual era importante. Quando os fornecedores de BI seguiam essa trilha, o que mais aparecia para os clientes eram… Os dashboards!!

Conclusão

Não posso afirmar, categoricamente, que a tecnologia de painéis de instrumentos foi incorporada ao BI por “culpa” do BSC. Mas eu posso contar para vocês que ao visitar clientes interessados em BSC, eu, gerente de soluções SAS, vendedor de BI, era cobrado para mostrar os painéis da solução SAS para BSC. Era contra esse aspecto que a solução oferecida pelo SAS era comparada.

Eu nunca consegui emplacar uma venda de BSC pelo SAS. O produto de BSC da concorrência (não-BI) era bom o bastante para anular as vantagens do SAS (integração de dados díspares e flexibilidade nos painéis) e conseguir o pedido, mesmo sendo mais caro. Na minha opinião, olhando para trás, eu diria que a concorrência tinha uma implementação formal de BSC, completa e pronta, enquanto que o SAS apenas tentava surfar nessa onda, reempacotando seu produto com outro público-alvo diferente do público regular de BI.

Só que, até então, painéis não eram coisas de BI. Caramba, não tinha nem no catálogo do SAS, que tem tudo!

Por isso, na minha humilde opinião, dashboards entraram para o rol de recursos de BI por contaminação do mercado de SMS, do qual o BSC Norton e Kaplan é um ilustre membro. Dashboards não são melhor ferramenta analítica que um cubo OLAP ou um projeto de Data Mining, mas são excelentes meios para levar informação e oferecer visões completas – para apresentação dos dados.

É isso. 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. ;-)

Categorias:DW, Software Tags: , , , ,
Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 146 outros seguidores