Data Mining Papo Reto

Está lá na Wikipedia:

Data mining (…) is the computational process of discovering patterns in large data sets involving methods at the intersection of artificial intelligence, machine learning, statistics, and database systems. The overall goal of the data mining process is to extract information from a data set and transform it into an understandable structure for further use.

Ou em tradução livre:

Garimpagem de dados é o processo computacional de descoberta de padrões em grandes conjuntos de dados envolvendo métodos na intersecção de inteligência artificial, aprendizado de máquina, estatística e sistemas de bancos de dados. O objetivo dominante do processo de garimpagem de dados é extrair informação de um conjunto de dados e transformá-la em uma estrutura inteligível para uso subsequente.

Correto, claro, e sem dúvida eu concordo com isso. É o que falam no SAS (meu marco zero de BI – vem do SAS, é BI) e é o que se fala “por aí”.

Mas é uma pílula dourada.

Pílula Dourada

Dourar a pílula é tornar algo (tipicamente desconfortável) mais deglutível, mais fácil de engolir. A definição de Data Mining propalada aos quatro ventos por toda comunidade internacional de BI é um texto para tentar fazer algo insosso, insípido, incoloro e inodoro, mas muito grande e espinhoso, ser engolido por consumidores de BI. No fundo, Data Mining nada mais é que a boa e velha Ciência em ação. Na cabeça do não-cientista, Ciência e “ganhar dinheiro” não se misturam. Mesmo quando alguém  funda uma companhia sem uma única linha de produção física, sem mover um único grama de nada para fora dos seus muros baseado apenas em um algoritmo computadorizado, ninguém nota que Ciência foi usada para “ganhar dinheiro”.

Ciência & Grana

Que coisa, não?A palvra diz tudo: Ciência = Saber = Poder.

Como então Ciência não tem relação com dinheiro? Talvez Ciência pura não gere produtos comercializáveis imediatamente (vide Mecânica Quântica), mas o nosso mundo é construído a base de MUITA Ciência: da água que bebemos, expelimos e é tratada, ao descanso da mente (Lazer), passando por comida (morra de raiva, Malthus!), Saúde, vestuário, Educação, Habitação etc. etc. etc.

(Como alguém pode estar vivo hoje e achar que vai se dar bem sem estudar??)

Inteligência de Negócios em última análise é mero “saber”, mera “ciência” da realidade da empresa e do mundo. O problema é simples quando você tem poucos dados – poucos clientes, produtos e vendas, poucos alunos, poucos cidadãos, poucos crimes – mas piora cada vez mais rapidamente quando o volume de dados aumenta. Quando você é a Amazon e tem mihões de clientes, milhões de vendas e centenas de milhares de produtos, então, isso vira um pesadelo.

Quem te salvará? A Ciência.

Modelos, Modelos, Modelos

Nenhum um único ser vivente na face da Terra jamais viu e jamais verá um átomo. É uma impossibilidade biológica, física. Mas não resta muita dúvida sobre o fato de que átomos devem existir. Como? Ora, se você presumir que existem átomos, que eles devem se comportar assim e assado, e devem reagir desta ou daquela forma, então podemos montar experimentos e testar nossa pré-suposição. E foi o que aconteceu: cientistas ao longo de décadas executaram inúmeros experimentos que comprovam a existência de alguma coisa invisível a olho nu, que organiza a matéria ao nosso redor.

Permitam-me frisar: uma suposição pode ser confirmada ou rejeitada por meio de testes. Como chegamos a uma suposição?

Olhando! Cutucando! Pensando!

Todos nós conhecemos a história da maçã que bateu no cocoruto de Newton, que então estalou os dedos e disse “Gravidade!” – hehe. Quanto mais precisos se tornam nossos instrumentos, mais precisas se tornam nossas análises. Quanto mais minucioso se torna nosso exame de algo, mais oportunidades aparecem. O fato é que nunca se sabe o que virá pela frente, mas a persistência na investigação cedo ou tarde traz algum resultado – mesmo que seja “não há nada aí”.

E é isso que é Garimpagem de Dados: uma investigação cuidadosa, sistemática e minuciosa da realidade tal como o “negócio” a vê, através de instrumentos e métodos especiais para o assunto. Data Mining não é nada mais, nada menos que o trabalho de se construir um modelo matemático que permita inferir coisas ainda ignoradas sobre a realidade. Só.

Bateia, Riacho, Pepita

Um cientista mete-se num laboratório e observa um evento. Ele repete a experiência, anotando os resultados, de novo e de novo. Depois ele se senta com papel e lápis e começa a desenhar: será que o peso da amostra muda o resultado? Sim? Não? Por quanto? Será que a luz muda o resultado?

As perguntas vêm da mera convivência com o assunto. Coulomb intuiu sua lei partindo de uma correlação entre campo elétrico e campo gravitacional, massa e carga e finalmente apostando que deveria haver uma lei para campos elétricos semelhante a que já se conhecia sobre a Gravitação. Ele supôs, testou e – bing! – mais uma lei da Física!

Na Corrida do Ouro dos EUA as pessoas compravam bateias e sumiam dentro do território, passando dias, semanas, meses, garimpando os riachos da Califórnia. Cuidadosamente, dedicadamente, catavam o cascalho do fundo dos rios em busca de ouro. De repente, sorte grande, um canto do rio dava uma, duas, dezenas de pepitas e o sortudo enriquecia de uma hora para outra, literalmente.

Bom, “fazer” Data Mining é exatamente isso: continuamente uma bateia, feita de bancos de dados, técnicas de modelagem matemática, conhecimento de negócio e intuição, pega o cascalho de dados do fundo do mar de dados de uma empresa e vai jogando fora o que não presta. Na maior parte das vezes vai tudo embora e o processo recomeça, mas de repente BINGO! Um veio de dados rico em significado, capaz de ser modelado e usado para prever o futuro é encontrado.

Troque cientista por cientista (hehe), laboratório por DW e experimento por venda, e releia o parágrafo do início desta seção. Entendeu?

Serra Pelada vs. Alaska

Há uma grande diferença entre o processo industrializado de extrair mineral de minas como as que vemos aqui no Brasil, em que caminhões saem carregados de minério de dentro de túneis mastodônticos, e o processo manual, lento e trabalhoso de garimpar o fundo de um rio, ou cavar uma daquelas minas que normalmente aparecem em desenhos animados. Os fornecedores de ferramentas de Data Mining querem que você acredite que é só meter a pá, peneirar e conseguir ouro em pó do chão sujo. Mas a pílula dourada do começo do post diz que na verdade você vai é ter muito trabalho, e do tipo “muito especializado”, para arrancar qualquer pequena pepita que seja. E dificilmente vai ser do chão sujo.

Há os tais dos “low hanging fruits”, os frutos ao alcance da mão, mas esses normalmente tem pouco valor ou precisam de algum modelo matemático. Exemplo? Fácil: grandes sazonalidades, visíveis em um gráfico de meses ao longo do ano. Ou grandes grupos – homens gostam de futebol, mulheres de novela, crianças de desenhos animados.

Mas se você quiser prever a demanda de televisores de alta definição em cada cidade, ou a chance de fraude, ou o risco de um empréstimo, ou o impacto da campanha do Facebook sobre as suas vendas em lojas físicas, nada vai te ajudar a não ser conhecimento hard core (isto é, um cientista – e não um de dados, um de verdade: Físico, Estatístico, Matemático etc.) e know-how (afinal, a teoria na prática é outra.)

Conclusão

Data Mining é o processo de criar um modelo matemático que explique uma realidade observada dentro da empresa.

Quem cria modelos matemáticos são cientistas hard-core, daqueles de jalecos com seis canetas no bolso (a maioria traja roupas sociais, mas é um disfarce!)

Qualquer um pode fazer Data Mining? Claro, todo mundo pode cozinhar. Todo mundo pode usar uma ferramenta. Ser um Adrian, saber usar e saber fazer, porém, já e outra coisa. Requer formação especializada e prática. Usar uma ferramenta não vai te tornar um cozinheiro de mão cheia, mas no máximo um chapeiro de marca.

É isso! ;-)

Cruzando Duas Hierarquias da Mesma Dimensão

Em 7/2/14, Camila Botelho postou uma curiosa pergunta:

Camila pergunta sobre análises em duas hierarquias da mesma dimensão.
Camila pergunta sobre análises em duas hierarquias da mesma dimensão.

Eu respondi com curiosidade:

Eu não sei... ainda! :-)
Eu não sei… ainda! :-)

O teste era simples: primeiro, criar a hierarquia gênero no esquema e, segundo, espetar cliente de novo no cubo. O resultado é este aqui:

Nova hierarquia no cubo Beltrano, mostrando o Cliente espetado duas vezes.
Nova hierarquia no cubo Beltrano, mostrando o Cliente espetado duas vezes.

Até agora, tudo lógico e razoável. Teste de fogo: dá para criar uma análise de Gênero do Cliente por Estado do Cliente? Resposta:

Duas hierarquias cruzadas entre si no Saiku.
Duas hierarquias cruzadas entre si no Saiku.

Sim! A visão da figura anterior está filtrada por tipo de cliente (exibe apenas PF, já que PJ não possui gênero), e em cada eixo (coluna e linha) eu tenho um atributo de cara hierarquia da dimensão Cliente. O Saiku não expôs o nome da dimensão setada com Dimension Usage (Cliente H1 e Cliente H2), mas oferece o cliente duas vezes.

A pergunta que não quer calar é “peraí! A cada hierarquia que eu queira cruzar, preciso espetar a dimensão no cubo de novo?” Bom, se você usar o Pentaho Analyzer (EE), não. Caso contrário, por enquanto, sim. Eventualmente, consultas MDX não possuem essa limitação – indicando que é um ponto a ser melhorado no cliente OLAP, e não no Mondrian:

SELECT
NON EMPTY Hierarchize(Union(CrossJoin({[Cliente H2.Genero].[F]}, {[Measures].[Quantidade]}),
                             CrossJoin({[Cliente H2.Genero].[M]}, {[Measures].[Quantidade]}))) ON COLUMNS,
NON EMPTY {Hierarchize({[Cliente H1].[Estado].Members})} ON ROWS
FROM [Pedidos]

É isso. Respondido, Camila?

Gravar Fato com Dimension Lookup/Update

Inteligência e criatividade já foram definidas como misturar coisas com um propósito e atingir outro. Eu tive o melhor exemplo disso há pouco, durante uma aula.

Explicando a gravação de uma fato, e peculiariedades de cada tipo de fato (snapshot, acumulating etc.), ela me perguntou:

Ah, então eu posso gravar a fato com a Table Output, e se quiser atualizar uso um Dimension Lookup/Update?”

De cara eu não entendi a pergunta – “Comparar table output com dimension lookup/update? Mas não tem nada a ver…” – foi quando eu parei para pensar e vi que era não só uma pergunta lógica, como óbvia.

Sim, claro, o D L/U (Dimensio Lookup/Update) é um passo dedicado a gravar dimensões, mas a lógica dele se presta a qualquer gravação/atualização que envolva uma chave composta e “coisas” (métricas!) que variem (ou não.)

Eu resolvi fazer um teste. Essa é a transformação que grava a fato pedido da Beltrano S/A, tirada do meu livro Pentaho na Prática:

Transformação que carrega a fato, usando passo "normal" Insert/Update.
Transformação que carrega a fato, usando passo “normal” Insert/Update.

Eu então troquei o Update no final por um D L/U – e não mexi em mais nada:

Transformação que carrega a fato, usando passo D L/U.
Transformação que carrega a fato, usando passo D L/U.

E essa ficou sendo a configuração do passo (eu tratei o tipo de pagamento como uma degeneração, mas sem querer coloquei como métrica):

Configuração do passo D L/U para gravar uma fato.
Configuração do passo D L/U para gravar uma fato.

Resultado? Bom, depois que eu criei a fato com o botão de SQL do D L/U e carreguei, ela ficou assim:

Fato gravada pelo passo D L/U. Repare que todos campos de controle da dimensão foram chamados de fut_ext_x (futuras extensões), e que agora ela possui uma chave primária.
Fato gravada pelo passo D L/U. Repare que todos campos de controle da dimensão foram chamados de fut_exp_x (futuras extensões), e que agora ela possui uma chave primária.

Ou seja, é a fato, mas com os campos de controle da dimensão. Eu nomeie todos eles como futuras expansões (fut_exp). A chave delegada também está lá, mas agora na função de uma chave primária! Compare com a fato “normal”:

A tabela fato gravada com um passo normal. (As chaves zeradas são um bug da minha transformação, que está bagunçada (sabe como é, próxima versão do livro...)
A tabela fato gravada com um passo normal. (As chaves zeradas são um bug da minha transformação, que está bagunçada (sabe como é, próxima versão do livro…)

Os zeros nas chaves decorrem do fato de a minha transformação estar em mudança – por algum motivo eu não recuperei as chaves (pau do banco?) – mas normalmente dá certo. Por favor, releve como ruído no material do livro, que está sendo revisado.

Conclusão? Dá certo! (Claro que dá, mas… como é que eu nunca pensei nisso antes???) Será que é alguma vantagem usar o D L/U para isso? Será que simplifica alguma lógica? A ver!

Genial! :-)

Paz, Afinal

Screenshot da introdução do The DW Toolkit, 2a. Edição.
Screenshot da introdução do The DW Toolkit, 2a. Edição. Os destaques em amarelo são meus.

Repararam nos destaques em amarelo na figura acima? Eu demorei uns anos para entender o que estava escrito. Se você entendeu, vai ler algo mais ou menos assim:

Modelagem Dimensional é o padrão de facto para APRESENTAÇÃO de dados para o cliente. E também é a única arquitetura para sistemas de DW DISTRIBUÍDOS.

Que raios é distribuído? Como eu levei uns dois anos para perceber isso? Kimball nunca disse que Modelagem Dimensional era a melhor ferramenta para desenhar DWs. Ele disse muitas coisas, mas essa ele nunca disse! Nem escreveu (espertinhos…)

Como foi que eu nunca notei? Acho que eu não estava querendo ver o óbvio.

Desde que comecei a ler o livro do Hans Hultgren, Modeling the Agile Data Warehouse with Data Vault, aprendi algumas coisas. Primeiro, hub pode ter chave de negócio composta – nem fazia idéia. Segundo, link precisa relacionar coisas no menor grão possívl (grosso modo, é mais complexo que isso.) Mas o mais importante, de longe, foi a prova definitiva da necessidade do Data Vault.

Eu sempre me debati com a idéia – sempre há o risco de ser só uma moda, o mais novo brinquedo etc. Eu nunca dormi tranquilo. E se eu estiver errado? E se eu levar outros a cometer o mesmo erro? Seria ruim estar errado, mas causar a ruína de outrem, levar uma empresa a um caminho furado, bom, seria o meu fim como profissional.

Eu acreditava estar certo, mas sempre foi uma aposta com riscos calculados.

Não mais – agora eu tenho certeza que DV é uma peça importante, central. E por um motivo óbvio, que eu mesmo já havia destacado aqui. Eu só não tinha um argumento mais sofisticado para apresentar, tinha apenas minha própria intuição.

O argumento do Hultgren tem a simplicidade dos gênios: cada necessidade tem uma solução adequada.

  • Para atender a necessidade de sistemas transacionais de realizar muitas transações pequenas, em pouco tempo, usamos a 3NF (Terceira Forma Normal);
  • Apresentar dados para o usuário final explorá-los, de maneira fácil e intuitiva, é melhor feito com um Modelo Dimensional;
  • Acumular os dados da empresa ao longo do tempo, para poder recuperar qualquer campo, de qualquer assunto, a qualquer momento – construir um EDW – não pode ser bem resolvido usando-se soluções que são boas para outros casos.

Isso mesmo: se a 3NF resolve bem os transacionais, e o Modelo Dimensional resolve bem a exploração analítica, como esperar que qualquer uma destas técnicas resolva um problema diferente destes dois?

É preciso um modelo de dados específico para a criação de EDW (DW Corporativo.) Uma das opções que cobre esse nicho é justamente o Data Vault.

E por isso, sem sombra de dúvidas, Data Vault é uma boa opção para EDW, enquanto que nem Modelagem Dimensional nem 3NF são adequadas para isso. Data Vault foi pensado para ser um modelo de dados de Data Warehouses – acúmulo de dados, não análise, nem transações.)

Paz, afinal.