Apache BI Parte 2

Bem-vindos de volta! Hoje veremos o resultado final do projeto, como funciona o processo de carga, e um link para baixá-lo. Mas antes, uma palavra de nosso patrocinador!

Open Source Solution

O conceito do SL é simples: eu faço para meu uso, e deixo quem quiser estudá-lo e usá-lo como bem entender.

Hoje já existe um conceito análogo para dados: Open Data, que diz que certos dados deveriam estar livres de restrição para uso e republicação. Um exemplo interessante do que seria Open Data são os dados do sistema de saúde do Brasil, o Data SUS. Eles são estatísticas sobre vários aspectos da saúde no país, como óbitos e nascimentos, casos de dengue etc. Qualquer um com um navegador pode acessar e recuperar uma cópia desses dados.

Mas depende de algum conhecimento extra para explorá-los. Mexer no Excel (ou no Calc) é o bastante para começar, mas vai até um certo ponto.

No Conisli de 2009 eu propus outro tipo de recurso livre: a solução de BI livre. Ela seria alimentada com dados livres e seria montada com software livre. Me faltava tempo e um certo propósito para começar um.

Apache BI

Até que o Edu me deu um motivo. Os dados que ele quer analisar são deles, mas são dados gerados por qualquer Apache! O Apache BI é, então, o primeiro projeto de BI livre que eu conheço (já que alguém pode ter feito a mesma coisa e eu não estou sabendo! Com tantos bilhões de páginas, alguém precisa ser humilde de vez em quando ;-) .)

No primeiro post eu mostrei o começo do trabalho, e consegui completá-lo (até onde eu havia me proposto) semana passada. No final do post há um link para o pacote, e abaixo estão as novidades!

Resultados

Para dar um gostinho do que ficou pronto, vejam essa figura:

Quantidade de acessos, na madrugada e manhã, entre março e abril de 2012

Essa figura mostra todos os acessos feitos de madrugada até o meio-dia, comparado entre março e abril. Se queremos ver só o diário de março, fazemos o drill-down no mês e pivoteamos os eixos da visão:

Quantidade de acessos da 1H às 12H, durante março de 2012.

E isso não pára por aí! Como eu tenho outros atributos em mês e hora, posso reagrupar esses dados de muitas maneiras diferentes, jogar o User Agent (mais ou menos o browser – que pode ser um bot ou qualquer outra coisa), tipo de acesso, quantidade de bytes servidos etc.

Por exemplo, esse é o gráfico de bytes servidos ao longo dos dias desses dois meses:

Quantidade de bytes servidos por dia, entre março e abril de 2012.

E etc. etc. etc… Acho que já deu para ter uma idéia, não?

Modelo Dimensional Completo

A proposta inicial pedia análise do serviço de página contra dia, User Agente e hora. O modelo atualizado dá conta disso, e exibe mais três dimensões degeneradas: código de retorno, versão HTTP e método (post, get etc.) Eventualmente essas dimensões degeneradas podem formar uma junk, sair da fato e assim melhorar a performance da estrela.

Modelo dimensional Apache BI 1.0, agora com dimensão hora.

Dimensão Hora

Criei a  transformação de carga e a tabela, a partir de uma dica nos fóruns da Pentaho. Surpreendentemente, a dimensão tem mais de 80.000 linhas, umas quatro vezes o tamanho da dimensão data. O dimensionamento contra ela é exatamente igual ao da data, via database look-up.

Carga da dimensão hora. Gera mais de 80.000 linhas!

Lendo de Arquivos

Como os logs Apache são gerados em arquivos, é mais prático lê-los diretamente desses. Antes eles eram passados para um balde S3 por um programa Python, e só depois eram lidos pelo PDI a partir da Amazon.

Processamento de arquivos de log Apache.

Processamento Incremental

Antes o processamento truncava tudo (incluindo fato) e recarregava do zero. Agora ela lê cada arquivo de log, carrega em uma tabela temporária previamente truncada e depois carrega na fato. O arquivo é então zipado para evitar reprocessamento e manter histórico.

Processo completo de carga do Apache BI.

Os dois primeiros passos contam a quantidade de arquivos disponíveis.

Trasnformação que conta arquivos disponíveis para carga.

Se for zero, encerra o processamento. Se for maior que zero, segue adiante. Logo depois da carga do log em tabela, o processamento se divide e dois, e o ramo de cima compacta os arquivos de log e verifica se algum novo User Agent foi identificado.

Transformação que identifica novos UAs nos arquivos processados.

O arquivo Excel gerado na transformação acima deve ser examinado e manualmente adicionado ao arquivo Excel que mapeia os UAs em seus atributos (não conseguimos algoritmo que fizesse isso, ainda, e por isso fazemos na mão.) O arquivo de mapeamento é consultado a cada nova carga, para determinar se alguma UA foi adicionada ou alterada.

Atualiza a dimensão User Agent. Curiosidade: essa é uma SCD1.

A fato é então processada:

Transformação que carrega os registros de log na fato.

Manual de Uso

Bom, está mais para um readme com passo-a-passo. Mas vai virar um manual (ODT, provavelmente), completo com figuras e tudo.

Download

Você pode baixar um ZIP com todas as transformações, jobs, arquivos de configuração e instruções no Sourceforge.net Open BI Solutions.

As instruções para colocar a solução no seu Apache estão no pacote, e não vou me repetir aqui. A página do projeto possui um fórum, uma wiki e um bugtracker. Eu ainda estou aprendendo a usar tudo isso mas vou procurar manter o projeto bem acompanhado. Em todo caso, podem postar comentários pedindo ajuda, comentando ou criticando aqui mesmo.

Próximos Passos

Com certeza é melhorar o mapa de-para da dimensão User Agent, mover as dimensões degeneradas para fora (eu detesto degeneradas, mas também não gosto de junks, o que torna essa decisão bem difícil), e provavelmente criar tabelas pré-agregadas, já que a quantidade de linhas, em menos de dois meses, já está em mais de 360.000 – e olha que o site dele é até bem paradinho… Imagine um site um pouco mais popular! Deve juntar milhões de acessos em alguns meses!

E Depois?

Bom, depois vem a parte que é BI de verdade. Lembram-se do post anterior, sobre Data Mining? Então, só de graça eu rodei o Weka sobre esses dados. Não é fácil descobrir nada assim, de cara, com pouco preparo e pouquíssimos dados, mas eu comecei uma atividade simples: descobrir se existe alguma correlação entre alguma dessas variáveis. O primeiro passo é gerar um arquivo no formato ARFF, carregá-lo no Explorer do Weka e examinar o cruzamento de tudo com tudo:

Existe alguma correlação aparente? Versão HTTP e Método?

Até a próxima!

O Andar Bêbado do Negócio

Bom, o lance é que estava em uma agradável tarde de sábado, lendo O Andar do Bêbado, um livro sobre como a aleatoriedade afeta nossa vida, e nós nem nos damos conta. Como eu ainda estava com o Nao É Bem Assim na cabeça, automaticamente as coisas se cruzaram: negócios sofrem aleatoriedades, e essas apresentam padrões. Daí o título desse post, uma mistura de bêbados e negócios. Mas é um post totalmente sóbrio “hic” acredita nimim… hic… :-)

E como é essa mistura? Veja esse trecho do livro, que interessante:

(…)o grande matemático francês Jules-Henri Poincaré empregou o método de Quételet para pegar um padeiro que estava enganando seus clientes. A princípio, Poincaré, que tinha o hábito de comprar pão todos os dias, notou, ao pesar seus pães, que tinham em média 950g, e não os mil gramas anunciados. Ele se queixou com a polícia, e depois disso passou a receber pães maiores. Ainda assim, teve a impressão de que alguma coisa naquele pão não cheirava bem. Então (…) pesou cuidadosamente seus pães durante o ano seguinte, todos os dias. Embora o peso se aproximasse de 1kg, se o padeiro houvesse sido honesto ao lhe dar pães aleatórios, o número de pães acima e abaixo da média deveria (…) diminuir de acordo com a curva normal. No entanto, Poncaré notou que havia poucos pães leves e um excesso de pães pesados. Assim, concluiu que o padeiro não deixara de assar pães mais leves que o anunciado; na verdade, estava apenas tentando apaziguá-lo, dando-lhe o maior pão que tivesse à mão. A polícia visitou novamente o padeiro trapaceiro, que, pelo que se conta, ficou surpreso e supostamente concordou em mudar seus hábitos.

Ele cita o trabalho de onde isso veio: What are the chances? p. 41-2.

Bom, isso foi há muio tempo, mas continua um método válido. Só para vocês entenderem como o Poincaré chegou a essa conclusão, vejam as figuras abaixo, exemplos de curvas normais, ou gaussianas. Elas foram desenhadas da seguinte forma:

  1. Divida uma linha horizontal em faixas, por exemplo, de 10 em 10 (que representam o peso). Comece com o 1000 no meio, e desenhe tracinhos até 900 para um lado, e 1100 do outro.
  2. Depois, a cada pão comprado, estique um tracinho vertical acima da sua faixa. Para o desenho não ficar muito grande, faça tracinhos de 0,5cm, por exemplo. Assim, se você comprar dois pães e o peso deles for 997g e 1002g, estique dois tracinhos sobre a faixa 1000.

Qualquer que seja a quantidade de pães comprados, e qualquer que seja o peso médio, a curva desenhada sempre vai ter o formato de um sino:

Figura 1: Uma gaussiana centrada em 0, média de 10 e variância de 1.

Poincaré, quando fez as primeiras medidas, achou a distribuição acima, só que o centro era 950g. Daí veio a primeira reclamação. Se o padeiro tivesse tomando tento e se alinhado, Poincaré teria visto a mesma curva, centrada em 1000g ao invés de em 950g. Mas quando mediu depois de reclamar, achou outro formato de curva:

Figura 2: Uma gaussiana distorcida.

(Para todos os efeitos, ignore os números nos eixos – ai tá rolando uma matemática braba…)

Conclusão: como a curva estava distorcida, ela estava sendo manipulada. A única coisa capaz de manipular essa curva para assumir esse formato seria a mão do padeiro. E não, mesmo que ele pesasse muito bem os ingredientes, e controlasse muito bem o preparo dos pães, a curva do sino ainda teria que aparecer. Faça o teste, se não acredita em Cardano, Fermat, Bayes, Pascal, Laplace e Gauss. ;-)

E aí, você sabe se seus clientes estão comprando sinos de você? (E o InMetro faz essas análises quando alguém reclama. Provavelmente o lance do pão ser vendido a quilo deve ter partido da constatação que seria impossível fiscalizar todas as padarias.)

Não É Bem Assim…

Tive a grata oportunidade de almoçar semana passada com dois grandes amigos, ambos grandes e experientes profissionais do ramo de BI. Trocando causos, chegamos a alguns pontos em comum nos projetos de ambos:

  • Toda teoria de Data Warehousing vai por água abaixo quando a empresa começa a gostar de ter um DW.
  • O que todos querem mesmo ver é dashboards.

Quando todos começam a ver que um DW atrelado a uma ferramenta de visualização é um negócio legal para caramba, todo mundo começa a pedir coisas. Pelas histórias que trocamos, esse processo culmina em uma estrutura de dados intermediária que foge muito de um DW, como um conjunto de scripts que livremente puxam e agregam dados em tabelas à parte, e uma interface de painel para visualização desses dados.

Lembrando em retrocesso, Pedro Alves comentou no curso C*Tools que ele também faz praticamente só dashboards.

Eu, que sou um cara teórico para caramba, fiquei encasquetado. A disciplina de DW resolve praticamente qualquer problema de acumulação de dados que uma empresa pode enfrentar. Analistas de negócios precisam de ferramentas e tempo para poder examinar o negócio, perguntar e descobrir oportunidades de crescimento da lucratividade. Como, então, parecia ser uma tendência em projetos de BI que DW vagueiem para a desorganização incremental, e BI resuma-se a um painel de “indicadores.” Como é que essa pressão poderia ser tão grande a ponto de comprometer a estrutura que vai agregar conhecimento sobre negócio à empresa? E o mais importante: o cenário descrito pelos meus amigos gerava mais ou menos lucros para suas empresas?

Gastei algum tempo pensando nisso, e comecei a perceber algumas coisas:

  • Dashboards são instrumentos usados para manter a empresa nos trilhos, pela descrição deles.
  • Os dados necessários para esses painéis vinham, no final das contas, dos sistemas transacionais.
  • Como o DW acaba ficando de fora dessa equação, sua importância percebida cai, sua prioridade diminui e o respeito aos modelos de dados se esvanece.

E isso leva junto o valor da exploração dos dados. Espere ai… Sem exploração? Como alguém sabe o que quer, sem explorar antes?

Como alguém pode tomar decisões sem antes conhecer o assunto? Como estabelecer metas e limites, sem saber como a empresa se comporta? E porque meus amigos não relataram seu envolvimento nos projetos de BI que alimentaram o conhecimento que definiu as metas e ajudou a desenhar os planos? Eu não perguntei isso naquela conversa, mas pelo andar da conversa, essas informações vieram prontas, sem a colaboração deles!

E de onde vieram? São esses dados que representam a própria Inteligência de Negócios. Projetos de BI servem justamente para os gestores entender como a empresa está operando, não para monitorá-la em tempo real. Eles não surgem do nada, ou da vivência de uma única pessoa dentro de uma empresa com dezenas de empregados (porte médio, que é o filão dos meus amigos.)

Óbvio! Esses gestores já sabiam como a empresa opera, já sabiam como funciona o negócio, e quais são os poucos dados críticos para operação diária! Eles já possuem a “inteligência do negócio!” E por isso BI vira uma “ferramenta de acesso a dados em forma visual”, e mais nada! Bingo!

E Daí?

De cara, vocẽ pode se sentir tentado a achar que isso está bem. Afinal, se eles já sabem como a empresa funciona, para que gastar dinheiro tentando descobrir isso de novo? Se “BI” está entregando o que ainda faltava, então beleza, certo?

Aqui eu começo a tatear. Li muito sobre BI enquanto estive no SAS, conversei com muitos especialistas, muitos implementadores, vendedores e desenvolvedores do SAS. Posso garantir com uma boa dose de certeza: se tem uma forma fácil de uma empresa ganhar dinheiro, é implementar uma solução de BI – CRM, SCM, Churn – o que for que lhe atenda.

Por um lado, as pequenas e médias empresas não são complexas o bastante para que ninguém saiba tudo sobre o negócio, o que é a regra em empresas de maior porte. Nas pequenas é médias é comum alguns poucos chefes deterem o conhecimento total. Sem perceber, eles acabam por prescindir de um projeto que dê-lhes a capacidade de aprender sobre o próprio negócio.

É isso que leva ao abandono do BI canônico (DW + Solução.) E isso não é exatamente ruim, mas também não é uma alavanca para o crescimento da empresa.

Conclusão

Uma solução de BI agrega valor mensurável à empresa – i.e. aumenta sua lucratividade. Criar dasboards pode tornar o trabalho mais fácil ou ágil, mas apenas melhora o que já se fazia. Se você quer usar BI para levar sua empresa adiante, para destacar no mercado, cresçer, não faça essa troca – dia-a-dia ao invés do histórico. Puxe os dados, entregue os dashboards, mas não deixe de explorar seu negócio. Descubra o que limita suas vendas, o que impede sua redução de custos, porque seus clientes estão indo embora ou não chegam com tanta frequência – descubra como seu negócio funciona. É esse conhecimento vai ser capaz de afetar sua lucratividade.

Dedicação Parcial é uma Ilusão

Aprendi um truque novo:

Tente esse joguinho:

1)Peça para alguém escrever em um quadro “dedicação parcial é uma ilusão”. Porém, conforme essa pessoa escreve a sentença, peça a ela que escreva um número embaixo de cada letra (de 1 a 26 – desconte os espaços.) Meça o tempo que ela leva para fazer isso.

Normalmente quem escreve reclama da frustração que é escrever números e letras ao mesmo tempo.

2)Segunda tentativa: a mesma pessoa deve repetir a mesma tarefa, mas uma coisa de cada vez: primeiro a frase, inteira, depois os números, de 1 a 26. De novo, meça o tempo que ela leva para fazer isso.

Compare os dois tempos e a quantidade de erros em cada exercício, e compare o humor da pessoa nessa segunda ação com o humor dela na primeira tarefa.

A genialidade é reconhecida nas coisas simples. Esse exercício, que pode ser feito em qualquer lugar, e até mesmo sozinho. Eu fiz. Eis os meus resultados:

  1. Fazendo os dois ao mesmo tempo: cometi quatro erros e levei 01:09 (um minuto e nove segundos.) Detalhe: eu me distraía volta e meia, parando para pensar o que era mesmo que eu tinha que fazer, e várias vezes tive que segurar o impulso para escrever uma palavra e depois os números correspondentes.
  2. Fazendo um de cada vez: nenhum erro e 00:29 (vinte e nove segundos.) Fiz direto, sem pensar em nada.

Imagine isso elevado ao tempo gasto em alguns projetos, multiplexados. Deixe-me reforçar: fiz as duas sequencialmente em menos da metade do tempo em paralelo!

Já há algum tempo eu venho em uma cruzada (solitária, pelo visto) para erradicar a dedicação parcial dos trabalhos profissionais. Quem faz duas coisas ao mesmo tempo não faz nada direito.

Existem exceções aceitáveis e até necessárias. Ocasionalmente é preciso fazer uma tarefa extra para resolver algo, mas não se pode conduzir a vida diária multiplexando-se à vontade – simplesmente não dá. Existem profissionais que dominam essa técnica ninja, mas são raros e não tenho certeza que isso possa ser ensinado – afinal, malabaristas deixam oito bolas no ar e ainda seguram mais duas nas mãos, mas isso é obtido com muito treino, e muitas bolas perdidas para o chão.

Então, da próxima vez que você fechar um projeto, pondere: é melhor dois no dobro do tempo, ou um depois do outro, na metade?

05/04/12 Complemento

Recebi alguns feedbacks sobre essa assunto de amigos, aqui no blog e no Facebook. Para esclarecer um pouco mais sobre esse meu ponto de vista:

  • Minha preocupação são com projetos, trabalhos que levam no mínimo uma semana e frequentemente mais para ficar pronto.
  • O prazo de entrega é importante.

Por exemplo, médicos e advogados não sofrem desse problema: um paciente em tratamento é visto uma vez por mês; assim como um processo em andamento, recebe atenção esporádica. Esse tipo de profissional vive de ter muita coisa em paralelo.

Isso é bem diferente de um projeto que dura um mês ininterruptamente: enquanto o resultado não for entregue, o profissional não está livre para fazer outra coisa. Por exemplo, construir uma casa, montar um carro ou escrever um software. Você pode dar tempo nesses trabalhos, mas pegar outra coisa durante não vai te tornar mais eficiente, vai na verdade atrasar dois projetos.

Apache BI

Outro dia um grande amigo meu me mandou um e-mail intitulado “consulta rápida Pentaho:”

Deixa eu abusar um pouco de sua boa vontade? Estou com uma necessidade interessante. Tenho meu servidor na Amazon hospedando os blogs e outros trecos. Desde setembro, tenho feito backup dos logs do Apache e pensei em começar a dar um destino útil para eles. (…) E eu comecei a pensar: seria interessante um cubo OLAP para fazer “drill down” de forma mais dinâmica. Então, eu precisava transformar os logs em uma tabela de fatos e fazer as dimensões a partir da URL, código de erro, etc.

Exatamente o tipo de desafio que eu gosto: BI, Pentaho e idéia nova! Na hora pulei dentro e começamos a trabalhar naquela mesma noite: ele setou um repositório Git, instalou um Postgres, um BI Server 4.0 e o PDI 4.2 na máquina Amazon dele. O truque todo era converter as linhas do log em colunas e tratá-las.

Na noite seguinte já tínhamos um protótipo: uma transformação que carregava uma tabelona com todos os atributos de um um modelo dimensional, além de algumas métricas. Mapeei isso num esquema Mondrian, publiquei e fiz um teste. Ele aprovou o protótipo:

Primeira versão do cubo Apache BI

Tínhamos um esquema Mondrian que permitia examinar a quantidade de bytes transferidos por tipo de conexão.

É por isso que eu acredito no Scrum: foi ai que a mágica aconteceu. Quando ele viu o que estava sendo feito e como a informação poderia ser apresentada, ele entendeu como pedir o que precisava. Ele montou um Jira, abriu uma conta para mim e eu registrei as histórias, dividindo as tarefas entre nós dois (ele aprende absurdamente rápido.) Em mais alguns dias tínhamos um projeto inteiro em andamento:

Backlog de produto, Apache BI, Sprint 1

A essa altura, o cubo monolítico evoluiu para um modelo dimensional mais completo:

Modelo Dimensional Apache BI v1.0

Com esse modelo podemos estudar os acessos por data, hora e agente do usuário. Como dá para perceber pelas colunas da fato (tabela do centro), ainda estamos evoluindo o tabelão. Claramente há uma dimensão junk (versão http com código de retorno) e talvez o cliente ainda descubra outras dimensões ou métricas.

Com esse modelo funcional, instalei o plugin do Saiku no BI Server e as visões OLAP ficaram mais bacanas:

Visão OLAP do cubo Apache BI
A visão anterior como um gráfico de barras.

Situação Atual & Próximos Passos

Ainda estamos andando com o projeto, mas já temos um futuro para ele. Assim que ficar completo, vamos macetear sua adaptação a qualquer Apache e soltá-lo com um projeto Open Source – provavelmente no SourceForge. Esse projeto vai ser a plataforma de lançamento de uma idéia que eu estou tentando tornar real já há algum tempo, que é…

Nah-nah!! Esperem e verão! :-)

Até a próxima!

02/04/12 – Atualização: o Edu colocou os arquivos em um diretório, de modo que vou passar para a próxima etapa: lê arquivos e fazer carga diferencial. Semana que vem terá post novo! Boa semana a todos!