Quando Nuton Gritou Eureqa

Eu tento fazer com que todo texto seja fleugmático: interessante, mas controlado, sem deixar a empolgação subir à cabeça. Mas esse aqui vai ser difícil. Quando eu assisti o vídeo eu só conseguia pensar OMGWTFOMGWTF…

Funciona assim.

Data Mining é uma coisa manual. Não é possível fazer uma garimpagem de dados automática, por poucas e boas razões:

  1. Um modelo que represente um negócio (sazonalidade de vendas, por exemplo) é necessariamente muito complexo, e possui, necessariamente, muitas variáveis;
  2. A busca da equação mais adequada é um problema de combinatória: combinar N famílias de equações, parametrizadas por M variáveis;
  3. Dado o número de variáveis e as famílias de equações que podem servir como modelo, o número de combinações explode e a busca, mesmo com supercomputadores (que não estão disponíveis para qualquer um, diga-se de passagem), seria demorada demais para ser útil.

Tradicionalmente o analista de Data Mining faz uma avaliação dos dados, seleciona uma amostra e vira-a de tudo quanto é lado, tentando enxergar alguma possível relação entre as variáveis. A partir daí ele propõe alguns modelos e, paulitanemente, vai limando os menos adequados e melhorando as propostas iniciais. Isso repete-se até que o erro diminua para um patamar definido pelo negócio, e então testa-se o modelo contra o restante dos dados. Se passar, vai para produção, onde ele identificará possíveis clientes, prováveis fraudadores, relacionamentos em atrito etc. etc. etc.

Não dá para automatizar isso e obter um resultado dentro dos próximos milhões de anos, mesmo para pequenos conjuntos de dados, mesmo com problemas simples. Não dá, é uma impossibilidade combinatória. Sempre será necessário algum tipo de guia humano para ajudar a máquina a sair do outro lado.

Um bom programador pode olhar para isso e retrucar que “dá para fazer um programa pré-carregado com os modelos mais comuns e conhecidos”. Isso reduziria a busca no espaço de soluções a um volume muito menor que o espaço inteiro (que pode muito bem ser infinito) e assim semi-automatizar Data Mining. Ok, mas pouco prático, já que cada caso é um caso, e isso reflete-se em cada modelo é um modelo.

Qualquer um que estudou Computação Natural pode olhar para essa situação e intuir a existência de uma solução com Algoritmos Genéticos ou Computação Evolutiva. Eu mesmo, que fui aluno de algumas dessas matérias, cheguei a pensar se não seria possível um motor de Data Mining automático. Nunca levei a idéia a sério, até porque eu sou fraquinho com Matemática.

Mas não é que algém levou? E é isso que o Eureqa, da empresa Nutonian, faz: ele gera uma série de possíveis modelos, aleatoriamente, e evolue-os até um certo erro pré-definido. Nada mais óbvio, nada mais simples. Mas eles fizeram!!!!

Assistam os vídeos deste link para ter uma idéia de como funciona. O exemplo dado no primeiro vídeo (Through the Wormhole with Morgan Freeman) é o mais claro. Eu ainda acho que ele usou um caso muito simples, muito banal (um pêndulo duplo), mas mesmo assim é impressionante!

Pode parecer pouca coisa, ou besteirol científico, mas o simples fato de já existir um produto que faz isso torna a possibilidade de Data Mining automático muito mais próxima da realidade!

Uau!

Ler mais

Um Ponto Fita o Mundo

Sua empresa precisa de um Armazém de Dados? Vocês decidiram adotar Data Discovery, então seu primeiro impulso é esnobar respondendo “não, porque a ferramenta não precisa disso”. (Estou sendo sarcástico. ;-) )

Já faz algum tempo que eu publiquei um post sobre o assunto, no qual eu apresentava um argumento definitivo (na minha opinião) a favor da adoção de Armazém de Dados por qualquer empresa que deseje investir em BI. Não tenho nada acrescentar àquele argumento, mas recentemente cheguei a uma outra interpretação e pensei se não seria bacana dividi-la com vocês.

Eu sou formado em Física. Um dos jargões que aprendemos na faculdade é o verbo “fitar”, um estrangeirismo a partir do verbo inglês to fit. Em português podemos usar ajustar ou encaixar mas, como bons brasileiros, falamos fitar e boas.

Em Física queremos explicar a Naturza e por isso boa parte do nosso trabalho é, a partir da observação de um fenômemo, escolher uma função matemática para descrever esse fenômemo – esculpir um modelo matemático da realidade – e tentar encaixar a função nos dados experimentais. Quando nossa função – nosso modelo – encaixa-se sobre os dados, sabemos que ela serve para explicar a realidade, até onde nossos dados experimentais chegam. Todas as fórmulas da Física que você aprendeu na escola são resultado desse trabalho. Seja a Lei da Gravitação Universal, seja o Princípio da Conservação da Energia ou as Leis de Maxwell, tudo, tudo decorrente do teste de modelos matemáticos contra a realidade.

Tentar encaixar a função nos dados experimentais é, você adivinhou, fitar uma curva. A figura abaixo é um exemplo clássico: uma reta fitando os pontos.

Exemplo de uma reta "fitando" os pontos. Será que não existe nada melhor?
Exemplo de uma reta “fitando” os pontos. Será que não existe nada melhor?

E cá entre nós, ô fitizinho ruim! Me parece que uma Gausiana e uma reta modulando uma quádrica dá mais certo… Não acham? ;-)

BI vs. To Fit

Bom, na minha opinião (sempre!), Inteligência de Negócios é a administração científica de uma empresa, é o processo de levantar hipóteses e testá-las, e usar o resultado para decidir entre uma ação ou outra.

Uma forma diversa de falar “testar hipóteses” é “encaixar uma fórmula a um conjunto de pontos”. Em bom fisiquês, é fitar uma função num experimento. Se você quiser ir mais longe ainda, é a criação de um modelo matemático para explicar a realidade. Mas aí também é pedir demais da TI…

Voltando, pergunta retórica: que função você pode fitar em um experimento que coletou a medida de apenas um ponto?

Um ponto não fita nada. Ou melhor: fita tudo!
Um ponto não fita nada. Ou melhor: fita tudo!

Esse ponto pode ser qualquer coisa, medida instantâneamente. Ou seja, uma medida no momento e mais nada. Como as vendas de hoje, ou o total de pedidos de suporte, o quantos chamados um empregado abriu… Qualquer grão, mas em um único momento no tempo.

Oras, se você mediu seu experimento apenas uma vez – uma única vez – então você tem apenas UM ponto. Quem lembra das aulas de geometria deve se lembrar do lema “uma reta é determinada por dois pontos”. Com um só ponto você não define nada, absolutamente e rigorosamente NADA. Qualquer uma das funções ilustradas pelas linhas coloridas no gráfico acima pode ser ajustadas para passar sobre o ponto medido. Não podemos afirmar nada sobre aquele pontinho.

E este é precisamente o fulcro: como é que vamos testar uma hipótese contra um conjunto de dados que possui uma só medida? Não vamos! Não é possível fitar nada a um conjunto que tenha só um ponto!

Colocada de outra forma, pode-se dizer que é possível fitar um mundo de teorias e hipóteses em um ponto! Não dá para negar nenhuma delas em favor de outra! Qualquer modelo pode explicar aquele ponto!

Agora, se formos adiante e, de tempos em tempos, repetirmos o experimento e coletarmos um novo ponto, teremos uma evolução daquela variável (ou conjunto de) ao longo do tempo. Podemos ver o que aconteceu até agora e tentar enter como aconteceu dessa forma, e talvez o que vai acontecer a seguir.

Agora sim: com mais pontos podemos ver como o sistema se comporta.
Agora sim: com mais pontos podemos ver como o sistema se comporta.

O gráfico acima conta o final da história: para entender o que está acontecendo no meu sistema eu preciso de mais pontos. Só acumulando medidas do sistema ao longo do tempo é que podemos testar e descartar ou confirmar hipóteses.

E um Armazém de Dados é o sub-sistema da disciplina BI que resolve essa demanda por informação temporal. DW é mais que um banco de dados ou um cluster Hadoop: é uma técnica de coleta organização de dados com vistas a análises futuras. Por isso usamos um DW para soluções de BI: para não ter que reinventar a roda e cometer todos os erros de novo, só para sair com um conjunto temporal de dados do outro lado.

Tempo Não É Tudo

Alguém menos informado pode sentir-se tentado a argumentar que não é preciso coletar dados ao longo do tempo se as variáveis de interesse não incluem o tempo. Por exemplo, “que perfil de mutuário tem mais chance de não pagar o empréstimo?” Basta eu montar o perfil dos Mutuários em atraso hoje para descobrir isso.

Bom, esse argumento tem dois grandes furos:

  1. Sem uma análise da relação ao longo do tempo você não pode dizer que variável causou que consequência. Em termos técnicos, a ausência do tempo proíbe quase sempre a determinação do nexo causal;
  2. Sem uma análise ao longo do tempo você não tem como dizer se o valor medido é um outlier ou é o valor normalmente encontrado para aquela variável.

Imagine a consequência de conceder mais empréstimos justamente para o maior caloteiro, só por que, por acaso, conseguiu pagar a dívida em dia no mês passado, enquanto que o melhor pagador se atrasou para chegar ao banco!

Não há escapatória: até mesmo para saber que uma relação é constante no tempo é preciso analisá-la ao longo do tempo.

Conclusão

Resumindo, você precisa armazenar histórico dos dados da sua empresa porque “um ponto não fita nada!”

Explicar para alguém porque um DW é necessário em projetos de BI, usando só uma frase, é uma coisa bem difícil. Primeiro precisamos entender que BI é, resumidamente, a tomada de decisão a partir do teste de hipóteses. Se aceitarmos esse fato (nem todos aceitam), ainda temos que entender que o teste de hipóteses é, na verdade, um trabalho de encaixar uma explicação matemática a uma realidade mensurada.

No fundo, não “precisamos” de DW. Precisamos é armazenar a evolução dos parâmetros da empresa ao longo do tempo. Podemos fazer isso de várias formas: um estagiário anotando valores em um papel de pão, ou uma planilha Excel, ou dumps de bases em um cluster Hadoop. Ocorre que, por acaso, DW é a tecnologia adequada para isso.

Se alguém te disser que você não precisa de DW para “fazer” BI, você vai acreditar?


Ah, em português fitar significa olhar fixamente.

Testando o Vertica

Já há alguns anos eu quero testar um banco de dados colunar. Desde o Pentaho Day 2014 eu fiquei muito curioso para brincar com o HP Vertica, mas não tinha tido o tempo (nem um banco com volume) suficiente para todo o trabalho que isso implica.

No final de 2014 eu consegui instalar uma máquina virtual com o Vertica 7.1.1 (em um Ubuntu Server 14.04.1.) Construí uma dúzia de transformações que copiaram todos os cubos de um DW em Postgres para esse Vertica. Configurei um BI Server 5.1 com as duas fontes de dados, e um esquema Mondrian para cada uma dessas fontes. Ontem em consegui fazer e tabular um experimento simples: usando o jPivot, abri o maior dos cubos (14.095.514 de linhas) e fiz uma exploração simples: abri e fechei cada uma das seis dimensões principais. Todas elas tinham entre um e três membros no nível hierárquico superior, exceto por uma dimensão data, que tinha 11 membros no nível do ano.

O Experimento

Fiz essas navegações logo após o boot do servidor, com cache vazio, e com um esquema (=banco) de cada vez. Capturei o log MDX e SQL do Mondrian para cada caso. Elas foram tão idênticas que foi possível comparar até mesmo o SQL gerado entre os dois experimentos. Como o Vertica é um Postgres colunar, o SQL era idêntico até a última vírgula, e isso facilitou a comparação.

Veja, eu não estava fazendo um estudo milimetricamente planejado. Eu só queria obter um sentimento da relação de performance entre as duas tecnologias. Logo, o resultado vai refletir o preparo do experimento. A informação será mínima, binária: em plataformas de hardware parecidas, qual base é mais rápida?

Tempo total para fazer a mesma coisa.
Tempo total para fazer a mesma coisa.

É o Vertica, sem sombra de dúvida. A máquina virtual do Vertica tinha 2GB de RAM e uma CPU – um quarto do meu i7 2.4GHz. A máquina do Postgres é a minha máquina real, com 16GB de RAM além de toda a CPU disponível. A máquina virtual estava desligada, de modo que minha CPU não estava particionada no momento do teste do Postgres.

O gráfico anterior mostra o tempo total para repetir a mesma operação com o mesmo cubo, usando bases diferentes. Já o gráfico abaixo compara cada uma das operações – que por acaso são 15 – usando uma escala logarítmica no eixo Y.

Tempo por operação nas duas tecnologias.
Tempo por operação nas duas tecnologias.

Curiosamente, e talvez até previsivelmente, o Vertica teve um desempenho uniformemente melhor que o Postgres em todas as operações que levavam mais tempo, mas perdeu feio nas operações M e N, que duraram menos de 50 ms. Destas operações, a M é o pior resultado do Vertica: 42 ms a 0 ms para o Postgres. Ou seja, uma operação que durou mais de 40 ms no Vertica foi tão rápida no Postgres que o log do Mondrian não conseguiu medir.

Lendo a documentação do Vertica eu vi um tópico que discute exatamente isso: consultas menores tendem a ter um overhead proporcionalmente maior que bancos relacionais.

Legal.

Em compensação, o Vertica foi mais rápido em tudo que levou mais de 50 ms. Em alguns casos, como o O, ele chega a ter mais de uma ordem de grandeza de vantagem – 22 vezes mais rápido no caso da operação O.

A Conclusão…

… é óbvia: o Vertica parece ser muito interessante para exploração OLAP de fatos com milhões de linhas. Sendo um cientista, eu estou perfeitamente ciente do risco que seria generalizar essa conclusão para um “logo ele será bom para tudo”. Existe um caso de uso no qual eu estou particularmente interessado, um relatório (PRD) tabular construído sobre esse mesmo cubo. Meus próximos testes vão tentar determinar se é uma vantagem usar Vertica ou não.

E eu aposto que é.

Feliz Ano Novo!!