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!

Categorias:Software Tags:, , ,

As Vantagens do Data Vault

Semana passada, 6/5/16, eu assisti uma palestra sobre uma empresa chamada Attunity, e suas ferramentas para Business Intelligence. Vendo as promessas do representante brasileiro eu me dei conta de que já escrevi bastante sobre DV, mas nunca escrevi especificamente sobre as vantagens trazidas pela adotação de Data Vault. Vamos corrigir isso hoje, partindo desta apresentação.


Você pode pular direto para a lista de vantagens clicando aqui.


Uma Nova Categoria

Estamos em 2016 e já lá se vão cerca de 40-50 anos desde que Bill Inmon começou o debate sobre Armazéns de Dados, e 24 anos desde seu livro Building the Data Warehouse. Muita água passou embaixo da ponte e todas suas idéias estão sedimentadas, firmes, sobre as quais se assenta a moderna indústria de DW. Um destes conceitos é a Corporate Information Factory, que agrupa as fontes de dados e seus consumidores como uma linha de produção.

Diagrama da Fábrica Corporativa de Informações.

Diagrama da Fábrica Corporativa de Informações.

Tal qual a revolução industrial fez com a manufatura, graus de automação sucessivamente maiores estão acelerando e simplificando o desenvolvimento, manutenção e gerenciamento de Data Warehouses. Instrumental para essa revolução foram tecnologias aparentemente irrelevantes, como modelos de dados e metodologias de desenvolvimento.

Metodologias como Scrum, Continuous Integrations e DevOps agem para diminuir a intervenção e variabilidade da ação humana, enquanto que outras, como Modelagem Dimensional e Data Vault, domam a confusão dos sistemas OLTP e permitem a criação de algoritmos. E é justamente essa criação de algoritmos que permite automatizar o processo de desenho, desenvolvimento e manutenção de DWs.

Uma nova categoria de ferramentas brotou desse fértil ambiente: ferramentas de automação de gestão de DW. Ainda não vi esse ramo ser tratado por um acrônimo, nem mesmo ter um nome mais comum, mas acho que, em Inglês, seria algo Data Warehouse Management Solutions, ou DWMS. Já sabem: se virem por aí, apareceu no GeekBI primeiro. ;-)

Continuando, essa categoria já tem alguns nomes internacionais:

Fazia tempo que eu não visitava o BI Ready, empresa de Ian Nicholson com quem já troquei umas idéias no LinkedIn. Surpresa! Ela foi adquirida pela Attunity e agora são um nome só. Não é à toa que, na apresentação, a Attunity declarou pertencer a essa turma – ela comprou “metade” das empresas dessa área!

Esse é o Ian Nicholson, fundador da BI Ready, fazendo a mesma cara que eu faria se tirasse essa foto.

Esse é o Ian Nicholson, fundador da BI Ready, fazendo a mesma cara que eu faria se tirasse essa foto.

Processos e Problemas

Um projeto de DW que hoje é chamado de “tradicional” (i.e., feito com metodologias de mais de 15 anos atrás) envolvia as seguintes etapas:

  1. Levantar os requisitos;
  2. Estudar os dados de origem;
  3. Desenhar o modelo dimensional;
  4. Desenhar o processo de ETL;
  5. Colocar em produção;
  6. Dar manutenção: propagar as mudanças dos sistemas de origem e adequar às novas necessidades do cliente.

Esse projeto em geral era tocado dentro de uma moldura PMI (a.k.a. Waterfall). Era um método tão certeiro e determinístico que até hoje todo mundo sabe que, feito assim, sempre falha.

Os problemas de um DW 'clássico'.

Os problemas de um DW ‘clássico’.


DW feito por cópia dos bancos de origem é a pior escolha possível, a menos que seja para uma padaria, uma farmácia, uma banca de jornais etc. ;-) Veja que não estou falando de palco (stage), mas de montar o DW como uma coleção de réplicas. Um modelo dimensional é o mínimo necessário para sobreviver aos problemas que serão apresentados ao final desta seção.


Com o advento do Manifesto Ágil e Data Vault, um projeto de DW moderno é tocado assim:

  1. Levantar os requisitos da próxima entrega (30 dias;)
  2. Estudar os dados de origem até encontrar o estritamente necessário para próxima entrega;
  3. Desenhar o DV;
  4. Gerar automaticamente o processo de ETL;
  5. Derivar dados para apresentação;
  6. Colocar em produção e reiniciar o ciclo.

A manutenção é incorporada nas sprints.

Veja que, grosso modo, o processo em si não mudou muito: de projeto waterfall passamos para Scrum, de modelo Dimensional no miolo do DW passamos para um Data Vault e o ETL principal é gerado automaticamente.

Os problemas que existem (existiam e vão continuar existindo) são:

  1. Integração: sem integrar e limpar 100% dos dados, todas as respostas são suspeitas. Ou você confiaria nos números sabendo que algo pode ter ficado de fora?
  2. Historiamento: não adianta montar um armazém que não guarda histórico. Fazer isso é cuidar de dados operacionais e jogar a água fora com o bebê – o maior valor dos dados está no histórico;
  3. Mudanças na origem: sistemas transacionais representam os processos que a empresa executa. Se a empresa muda, forçosamente os OLTPs precisam mudar, e o DW vai ter que ser adequado, sempre;
  4. Performance de ETL: a menos que a empresa esteja definhando, ela sempre vai crescer, sempre vai querer mais dados. O hardware para ETL sempre acaba ficando obsoleto, por um motivo ou outro, cedo ou tarde. O truque é extrair tudo que ele pode dar, e não desperdiçar nada;
  5. Velocidade de mudança: por fim, em cima de todos os problemas apresentados, temos o fato de que as coisas não estão ficando mais calmas, mais lentas, e sim mais rápidas, com mais demandas e mais complexidade.

Ferramentas…

As novas ferramentas de automação de DW se propõem a resolver esses problemas.

O Attunity propõe resolver um DW em dois passos:

  1. Usando o Attunity Replicate os dados são trazidos de diversas fontes de dados para um repositório centralizado;
  2. Daí, com o Attunity Compose, um DW é desenhado e carregado automaticamente.

Há um bom grau de magia negra envolvida (=coisas que acontecem sem entendermos claramente como), mas tudo faz um bom sentido. O Replicate se conecta aos bancos de dados de origem e fazem uma engenharia reversa total. Com essas informações ele vai ao banco de destino e recria o banco de origem, respeitando as diferenças de tecnologias. Por exemplo, ele pode replicar bancos MS SQL Server e Oracle para dentro de um único Postgres. Depois ele faz uma transferência inicial, em que replica as origem(ns) inteira(s) no(s) destino(s). A partir do final desta carga, o Attunity Replicate passa a ler o log de commits dos bancos de origem e replicar no destino, em tempo real.

Quem leu meu post Analítico ou Operacional? sabe que essa replicação não é um DW, e que fazer isso “não é BI”.

A Attunity também sabe, e dá o passo final em direção ao DW através do Compose. O que essa ferramenta faz é mais magia negra que a outra:

  1. Através de engenharia reversa e algoritmos especiais, o Compose “descobre” os relacionamentos entre as várias colunas de todas as tabelas das origens;
  2. Usando esse conhecimento, a ferramenta monta um DW – desenha um modelo de dados – automaticamente;
  3. Em seguida constrói (sempre automaticamente) o ETL para esse DW;
  4. Na última etapa ele monta uma área de apresentação de dados, seguindo indicações de que dados o cliente quer explorar.

A ferramenta ainda permite customizações e correções feitas pelo time de DW, de modo que qualquer interpretação incorreta pode ser ajustada.

Ou seja, ele automatizou 100% do processo moderno de desenvolvimento de DWs!!!! E digo mais: !!!!. Mas não pára por aí:

  • Esse DW guarda histórico;
  • A área de apresentação pode expor estrelas multidimensionais, com até mesmo SCDs tipo 2;
  • Ele detecta mudanças nas origens e ajusta o DW e o ETL;
  • Todas essas ferramentas são clusterizáveis, ou seja, podem ser escalonadas horizontalmente.

Isso são coisas que ouvi ou que perguntei durante a apresentação. Há coisas que eu não perguntei, mas presumo que também estejam no pacote, como tratamento de erros de ETL e monitoramentos diversos. Aliás, a parte de monitoramento é muito bacana, também – aprendi um negócio chamado “hot data, cold data”, sobre o qual vou fazer uns experimentos e, eventualmente, vou postar sobre.

… e Soluções

E como o Data Vault se encaixa nesse cenário? Simples: ele oferece tudo que as ferramentas oferecem, sem o custo monetário. Digo monetário explicitamente porque não existe almoço grátis, sempre precisamos pagar por algo. Se não é em dinheiro, vai ser em treinamento e capacitação, por exemplo, ou simplesmente mais trabalho.

DW 'moderno', re-organizado segundo DV.

DW ‘moderno’, re-organizado segundo DV.

Eis a lista de vantagens (ou problemas resolvidos) trazidos pela adoção de Data Vault no miolo do EDW:

  1. Velocidade de desenvolvimento: usar DV corta o tempo necessário para desenvolver e entregar em algumas ordens de grandeza. Por exemplo, coisas que levariam meses saem em dias;
    1. Modelo de dados: o diagrama de dados do Data Vault é construído através de regras simples, que capturam o negócio no modelo. Assim, uma vez que tenhamos a lista de esquemas, tabelas e colunas do sistema de origem, o ato de desenhar um DV é trivial e leva algumas horas, contra algumas semanas de outros formatos;
    2. Processo de ETL: usando o Pentaho Data Integration, o processo de ETL é gerado automaticamente, a partir do modelo elaborado anteriormente. Ainda é preciso juntar as partes (as diversas transformações) dentro de um job (pré-fabricado), mas isso é uma tarefa de minutos. O ETL inteiro sai em menos de um dia;
  2. Integração: o modelo de dados do Data Vault já arquiva os dados de maneira integrada. Ou seja, a integração ocorre via modelo, no momento em que os dados aterrisam no DV;
  3. Historiamento: 100% dos dados de um DV são historiados, automaticamente e por definição;
  4. Mudanças na origem: evidentemente não são tratadas automaticamente – um software pode fazer isso, não uma metodologia. Entretanto, esse impacto é mínimo:
    1. Qualquer mudança na origem não quebra o processo de ETL, ao contrário de DWs baseados em outros modelos;
    2. Mudanças na origem são resolvidas por um algoritmo simples, e qualquer manutenção leva praticamente o mesmo tempo de repetir o desenvolvimento (horas ao invés de semanas, portanto;)
    3. Nenhuma mudança na origem quebra a área de apresentação. A área de apresentação é reformada apenas em casos que afetem-na. Graças a esse fato, o impacto sobre a área de apresentação causada por mudanças nas origens é de mínimo a inexistente;
  5. Performance de ETL: várias vantagens ao usar um DV;
    1. Alta velocidade: por tratar apenas deltas (i.e., as diferenças) por meio de comparações simples, o processo é muito rápido;
    2. Paralelização: graças ao formato do ETL, todas as operações podem ser maciçamente paralelizadas, possibilitanto uso de hardware barato (COTS;)
    3. Resistente a erros: o ETL de um DV é auto-reinicializável por definição, e só é interrompido por falhas graves (hardware ou dados muito corrompidos;)
  6. Velocidade de mudança: é a mesma da velocidade de desenvolvimento – muito rápida.

Como vantagem extra, pelo fato de DV permitir atacar o problema por pedaços, ele se presta à:

  1. Modularização em sprints;
  2. Paralelização do desenvolvimento.

Por ser baseado em processos automatizados e algoritmos, a quantidade de erros é substancialmente menor, gerando projetos de qualidade maior, e mais padronizado.

Conclusão

Já há alguns anos a indústria de BI vem incorporando tecnologias que habilitam novas soluções de problemas complexos, como a construção, gerenciamento e manutenção de Armazéns de Dados. Essas tecnologias surgem como técnicas/metodologias e softwares.

Um software representante desta nova categoria é o Attunity, especificamente os módulos Replicate e Compose. O primeiro copia dados de diversas origens para um mesmo (ou vários) destino(s). O segundo modela um DW e cria o processo de ETL automaticamente a partir da réplica. Não sei com que qualidade, precisão e velovidade o Attunity entrega os resultados, mas a promessa é fantástica, para dizer o mínimo.

Esse produto é resultado de evoluções anteriores. Uma destas é a metodologia Data Vault, que oferece essa lista de vantagens:

  1. Alta velocidade de desenvolvimento: entrega em dia o que levava meses;
  2. Processo de ETL gerado automaticamente – maior velocidade, qualidade e padronização, com menos erros;
  3. Integração: dados são integrados na entrada;
  4. Historiamento: 100% dos dados de um DV são historiados;
  5. Mudanças: resiliente a mudanças na origem, processo de ETL não pára e impacto global (tanto ETL quanto usuários) é de mínimo a irrisório;
  6. ETL de alta performance, imune à erros, restartável e 100% paralelizável (é possível executar simultaneamente todas as etapas da carga do DV;)
  7. Adequado à processos de desenvolvimento ágil;
  8. Desenvolvimento do modelo (dada ferramenta adequada) e do ETL paralelizável.

Com um Data Vault podemos obter os mesmos resultados prometidos pelo Attunity, com menos automação, e com um custo diferente (menor?)

Clicando aqui você vê a lista dos meus posts marcados com Data Vault. Eis links para alguns do meus posts sobre o assunto:

E se você quiser ler sobre o assunto, o livro é este:

Livro sobre Data Vault.

Livro sobre Data Vault.


Só para não deixar vocês pendurados: eu ofereço os dois cursos, Requisitos Ágeis e Data Vault. Fazer essa propaganda dá impressão que eu montei um post para me auto-promover, mas juro que não é o caso deste aqui. Acredito no valor que esses cursos agregam e sentiria que estaria prejudicando você, meu leitor, ao evitar contar que eles existem. Quem me acompanha sabe que quando eu vou vender algo aqui, eu aviso no começo. ;-)


Até a próxima!

Resenha de Livro – Como Criar Ambientes com Vagrant

No post anterior eu comentei sobre as possibilidades que existem para melhorar a produtividade de um projeto de BI. Especificamente, falei de ferramentas que automatizam diversas tarefas, como testar o projeto e configurar ambientes.

O idéia para essa discussão veio de um livro que eu acabei de ler:

Creating Development Environments with Vagrant, pela Editora Packt.

Creating Development Environments with Vagrant, pela Editora Packt.

Acredito que a Packt dispensa apresentações – é uma das mais prolíficas editoras técnicas do mundo, com centenas de títulos, sobre os mais variados assuntos técnicos. Oferecem de livros sobre PHP a vídeos sobre BI, passando por “livros de receitas” (cookbooks) sobre tudo quanto é assunto – robótica, linguagens de programação, BPMS, BI (90% dos livros de Pentaho no mercado são deles), quase todos os Softwares Livres (ao menos quase todos daqueles que se estabeleceram) e muitos softwares propritetários, uma lista interminável. Todos de alta qualidade, excelente acabamento e muito cuidado na edição. Ou seja, se eles tiverem o livro que você precisa, compre. Dificilmente você vai encontrar algo tão bom quanto ou melhor.

Foi neste livro que eu comecei a entender as atividades de GCS que existem em um projeto de BI, e como elas tomam tempo. Vou falar um pouco sobre o conteúdo do livro e depois mostrar exemplos de como as coisas funcionam.

Resenha Creating Development Environments with Vagrant

Este é um daqueles livros da Packt que se encaixam na categoria de hands on. Há exercícios e coisas para fazer desde o início, sempre embasado com uma explicação que contextualiza a atividade e mostra os caminhos que existem a partir dali. Vamos por partes:

  • O livro tem sete capítulos e um apêndice, fora as partes que fazem o padrão Packt (prefácio, acesso ao material do livro, sobre o autor etc.)
  • Os sete capítulos tratam de como usar o Vagrant, e o apêndice mostra um exemplo completo, passo-a-passo, de como montar um servidor LAMP.

Os capítulos são os seguintes (os títulos são traduções livres, sem relação com o nome original:)

  1. Introdução: a idéia de ambientes de desenvolvimento é debatida, e o conceito do Vagrant é apresentado. Na prática esse capítulo apenas prepara o caminho.
  2. Gerenciando boxes Vagrant: neste capítulo efetivamente aprendemos a criar uma “caixa” (ou box) Vagrant, que é a gíria para máquina. Ele é auto-suficiente o bastante para que os apressadinhos pulem o capítulo 1 e caiam diretamente aqui (desde que tenham instalado o VirtualBox e o próprio Vagrant;)
  3. Puppet: o Puppet é um aplicativo para gerenciamento e “patrulhamento” (enforcement) de configuração. Por assim dizer, podemos controlar o ambiente de uma máquina inteira apenas descrevendo o que ela deve conter em termos de softwares e arquivos. Um dos usos do Puppet é garantir que uma máquina não tenha sua configuração alterada: se alguém apagar ou mudar algo, ou adicionar um novo programa, o Puppet vai lá e reseta a máquina para o estado definido;
  4. Chef: igual ao capítulo anterior, mas agora com um “concorrente” do Puppet, o Chef;
  5. Vagrant com provisionadores: provisionador é o nome genérico de softwares como Puppet e Chef. Este capítulo mostra como usar o Vagrant para acionar os provisionadores vistos nos capítulos anteriores e conseguir uma máquina tal qual desejarmos;
  6. Multimáquinas: até o capítulo 5 é mostrado como construir ambientes com uma só máquina virtual. Claro que se parasse ali seria muito pouco, pois não raro temos ambientes com uma máquina para cada pedaço do sistema. Aqui vemos justamente como construir um ambiente de desenvolvimento com mais de um servidor, aproveitando a capacidade de rede virtual fechada do VirtualBox;
  7. Uma caixa para chamar de sua: até aqui livro inteiro mostrou como usar boxes pré-fabricadas, mas um dos recursos básicos e mais importante do Vagrant é a capacidade de criar um padrão de máquina. No último capítulo do livro aprendemos como construir uma máquina adequada ao nosso ambiente e exportá-la, tal que possa ser usada em qualquer outro projeto.

The Good

Gostei da organização do livro. Na minha opinião, ele consegue manter um equilíbrio no ritmo de apresentação de funcionalidades com conceitos, e nunca pressupõe que você saiba algo que seja importante para avançar. Tanto é assim que os capítulos 3 e 4 são completamente dedicados a ferramentas que, por si só, já merecem outro livro. Mesmo assim ele não se perde em coisas desnecessárias, nem corta o assunto pela metade, sempre apresentando o necessário para aproveitamento do Vagrant e indicando como se aperfeiçoar, ou destacando o que é mais importante ou menos.

Também gostei muito da prosa do autor. Ele não é prolixo, floreando demais, nem é seco a ponta das frases ficarem telegráficas. Isso, aliás, é um traço dos livros da Packt: raramente vemos um texto tacanho ou enfadonho. Alguns são difíceis, mas difilmente mal-escritos.

Se você não tem muito tempo, os dois primeiros capítulos já matam o essencial. Eles te dão uma visão encorajadora do assunto e mostram exemplos fáceis, que servem para despertar o gostinho pela coisa, enquanto apresenta os comandos mínimos e o passo-a-passo para criar e subir seu primeiro ambiente. Só com isso já para arquitetar sua vida.

The Bad

Bom, como dizer? Há uma grande diferença entre entender como funciona e realmente fazer funcionar. “Ah, uma máquina Pentaho é um Ubuntu, com Java 7, Postgres e o BA Server.” Simples, não? Para entender como criar a máquina é suficiente ir até o capítulo 2. Para conseguir que ela tenha Postgres, por exemplo, um pouco de Puppet/Chef resolve. Mas é só falar de colocar Java, e depois o BA Server, que tudo começa a cair em casos especiais.

Trocando em miúdos, há um bom aprendizado de Puppet/Chef no meio do caminho até você conseguir produzir, sozinho, um servidor Pentaho básico. Ou seja, se por um lado o livro cobre bem Vagrant, chegando a ambiente multi-máquinas e criação de boxes próprios, por outro é preciso bem mais que Vagrant para esculpir um ambiente adequado, que dizer otimizado.

The Ugly

Eu gostei muito do livro. Raramente eu me enamoro por tecnologias de infra-estrutura, mas o Vagrant é tão bacana que é impossível – IMHO – não gostar dele. E como o livro é bem escrito e bem-feito, também seus problemas não são um incômodo.

E quais são esses problemas?

Em primeiro lugar ele abre muitos caminhos paralelos para tratar de cada assunto. Por exemplo, quando ele começa a criar o primeiro ambiente, ele não vai até o final e sobe tudo, mas sim discorre sobre os aspectos mínimos de cada configuração, comando, opções etc. Como eu disse, isso não chega a atrapalhar – não quebra o ritmo da leitura, nem prejudica a compreensão. Mas eu sou um cara mais linear, que gosta de ir até o fim em cada trilha, e depois percorrer os caminhos laterais. Coisa de macaco velho de RPG, que evita sair mergulhando no primeiro desvio e faz tudo sistematicamente (não sobrevivi a quase todos os Final Fantasy, Chrono Trigger e Dragon Quest correndo que nem um louco. ;-) )

Em segundo lugar, ele ensina sobre o Vagrant, e até bastante sobre o Vagrant. Só que é preciso saber mais coisas para preparar um bom servidor. Por exemplo, como é que instalamos e configuramos um programa qualquer? Resposta: usando o Puppet/Chef apt-get etc. E um Java? Uma configuração? Ou uma ação menos ortodoxa? O livro poderia trazer algumas receitas mais banais, para que o vagranteer incipiente não precise continuar estudando um bocado até começar a se virar. Só para comentar como isso afeta o meu caso especificamente (Pentaho), basta notar que o livro dá uma boa visão de gestão de usuários e grupos nas máquinas virtuais, mas não tão boa na parte de transferência e alteração de arquivos. Como muito das configurações do Pentaho BA Server são feitas por arquivos, eu vou ter que estudar mais para conseguir o mínimo.

Resumindo, e isso não é falha do livro, um uso proficiente do Vagrant requer um certo conhecimento paralelo, que não é muito fácil de conseguir. Uma melhoria interessante para a segunda edição seria entregar um pouco mais, como algumas “receitinhas”-padrão com Puppet/Chef. (Quanto aos caminhos meio tortuosos, podem não ser o máximo, mas não atrapalham. Eu deixaria como está.)

Ambiente Pentaho BA Server com Vagrant

Claro que eu não poderia terminar o post sem contar como foram minhas experiências com o Vagrant. E eu conto: foi muito boa. As coisas aconteceram exatamente como o livro mostrou – mais um ponto para ele! – e eu não fiquei perdido, como normalmente fico quando vou aprender alguma coisa nova do zero. Comparado com meu aprendizado do Git, por exemplo, foi muito mais fácil!

A porca torceu o rabo, porém, quando eu comecei a tentar titerear meu ambiente.


Titereiro(a) é a pessoa que mexe os fantoches – puppets – por meio de cabos e travessões. O ato de controlar as marionetes é chamado de titerear.


Falando claramente, me enrolei todo quando eu tentei escrever um script Puppet (scrupet?? kkkk.) No final das contas eu desisti e apelei o bom e velho vagrant ssh, acessando a máquina e instalando tudo na mão. Obviamente essa é a maneira mais burra de se gerenciar o ambiente Vagrant, mas deu para ter um gostinho de como pode ser.

A empresa que cuida do Vagrant, HashiCorp, oferece um repositório de caixas prontas. É um tributo à elegância do Vagrant o fato de que basta executar vagrant init com o nome do box e depois vagrant up para o programa fazer tudo sozinho. Já existe até mesmo dois ambientes Pentaho: Pentaho 4.8 e Pentaho 5.4. Eu tentei testá-los, mas não tive tempo até o fechamento deste post. No próximo post trarei minha experiência completa de configuração de um Pentaho BI Server 5.4 com Vagrant.

Conclusão

Vagrant é uma ferramenta muito bacana e com potencial para melhorar muito a qualidade do seu processo de desenvolvimento, seja de soluções de BI, seja de softwares tradicionais. A Packt oferece um excelente livro para isso, o Creating Development Environments with Vagrant.

Com o que o livro ensina eu consegui montar um ambiente Pentaho BI Server. Ainda não é o melhor servidor, porque, para conseguir isso, eu precisaria aprender ao menos um pouco sobre outra ferramenta: um provisionador chamado Puppet (ou Chef, mas eu gostei mais do Puppet.) Outro livro da Packt ajudaria: Puppet 3: Beginner’s Guide.

Puppet 3: Beginner’s Guide.

Puppet 3: Beginner’s Guide.

Aliás, eles oferecem vários sobre Puppet. Você pode consultar este artigo, da própria Packt, para algumas opções.

Existe um outro livro sobre Vagrant, mas de outra editora: Vagrant: Up and Running

Este livro é recomendado diretamente do site do Vagrant.

Este livro é recomendado diretamente do site do Vagrant.

Sabe brinquedo novo? Então, estou me sentindo assim com o Vagrant, tanto que estou dando um tempo na Soluções Clássicas! :-D

Categorias:Conceitos Tags:, ,

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!

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 150 outros seguidores