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!

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!