Introdução a Data Mining

No post Full Metal BI Itch eu coloquei uma pergunta:


E se você pudesse voltar um ano? O que faria?


Colocando de outra maneira, e se fosse possível saber hoje, agora, o que vai acontecer dentro de um ano? Que diferença isso faria na sua vida? E na vida de sua empresa ou organização?

Toda Ciência que busca criar um modelo abstrato a partir da realidade tem potencial para prever o futuro. Por exemplo, se você jogar uma pedra para o alto, a Física diz quanto tempo ela vai tomar para cair na sua cabeça, com um erro bem pequeno até. Economia, que anda tão em moda, oferece modelos de resposta ao que acontece quando se atua em certas variáveis e assim por diante – Química, Biologia, Medicina, Farmácia e por aí vai.

Essa é justamente a função central de BI, na minha opinião: estudar o presente para poder estimar o futuro com alguma precisão. Essa previsão pode, então, alimentar as ações do presente, de maneira até mesmo automática, como eu mostrei na série As Soluções Clássicas.

Eu sempre falo de Data Mining, mas nunca mostro. É complicado falar em poucas linhas de um tema tão complexo, tão vasto. Por isso eu decidi fazer um post com uma visão geral de como funciona um projeto de Data Mining. Assim, hoje vamos percorrer esse caminho, do início ao fim. Quem nunca mexeu ou viu o assunto de perto, e só ouviu falar, vai poder fazer uma idéia de como funciona um projeto desses na vida real.


Quanto mais experiente e mais safo é o profissional de Data Mining, o tal do – afffData Scientist, mais embolado fica o processo. Com experiência vem a velocidade e a economia de movimentos, o que torna as coisas mais rápidas e fases inteiras podem sumir na cabeça dele. Por isso não se impressione se vir alguém executando apenas uma ou outra etapa, ou mudando a ordem delas, pois provavelmente ele já tem conhecimento suficiente para isso. Ele atingiu o Shuhari.


Vou explicar em poucas palavras o meu cenário, só para não ficar tudo muito etéreo. Daí vamos entrar em Data Mining, com o SEMMA e botar esse lance na rua, usando-o para justificar o nosso (meu ;-) ) salário.


Esse post nasceu com 15 linhas. De tanto eu rever e mudar, acabou como uma verdadeira Introdução Rápida a Data Mining. Na boa, se quiser pular fique à vontade. Semana que vem eu devo trazer a segunda parte do BI Morreu!, que deve ser beeeeem mais curta e muito mais divertida. (Mentira, este aqui está mais. Por outro lado, vai ter Chaves. Putz, páreo duro…)

Você foi avisado. ;-)


Senta que lá vem história!

Zabbix & Data Vault

Estou apoiando a construção de um Data Vault para arquivar os dados de vários [Zabbix][zabbix_bitly]es e, de quebra, facilitar análises sobre eles.

Anteontem eu consegui completar uma transformação PDI que faz a carga de um satélite mais complicado, que captura um histórico que existe no sistema de origem. Ainda não sei se está mesmo certo, e só ontem eu consegui identificar esse tipo de satélite no padrão DV 2.0 e por isso não vou entrar nos seus detalhes.


Aos que, como eu, morrem de véspera: acho que é um tipo status. Assim que eu tiver certeza eu posto aqui uma explicação sobre ele.


E como funciona esse sistema? Bom, o Zabbix monitora um monte de medidas, de um monte de itens. Por exemplo, ele pode acompanhar a quantidade de memória RAM disponível em um servidor. Traduzindo em zabixxês, ele registra uma métrica (quantidade) de um item (RAM) de um host (servidor.) E ele faz isso dentro de um período pré-definido, como uma vez por minuto ou uma vez por segundo.

E o Zabbix faz isso com uma enormidade de tipos de hosts (computadores, roteadores, switchs, sensores etc. etc. etc.), medindo uma infinidade de itens (porta, memória, uso de CPU, disco, tensões, fluxos blá blá blá.)

Cada medida que chega é arquivada em uma tabela chamada history, que guarda a medida atômica. Em uma instalação de maior porte, como a na qual eu estou trabalhando, uma tabela dessas chega a acumular vários milhões de linhas por mês, com até centenas de milhares (ou mais) de novas linhas adicionadas diariamente. E são essas linhas que precisam ser arquivadas no Data Vault. Aliás, usando o jargão DV, é preciso arquivar esse histórico em um satélite.

O primeiro passo para conseguir isso foi descobrir, junto ao cliente, se ele precisa desse dado atômico, ou se contenta-se com uma agregação. Por exemplo, podemos agregar tudo, que às vezes está em segundos ou minutos, para horas. Daí cada item teria no máximo 24 pontos por dia, reduzindo em muito o volume de dados tratados.

E ele podia! Melhor ainda: o Zabbix possui uma tabela auxiliar chamada trends que acumula essa agregação, fazendo o grosso do trabalho com muito mais eficiência. A única coisa que sobreou, então, foi ler a tabela trends e levá-la para o satélite (que seria ligado a um item, que por sua vez tem um relacionamento com um host – ambos hubs):

Diagrama do modelo para Zabbix, hosts, itens e medidas.

Assim, o satélite Item 001 ficou os dados de cada item, o Item 003 com os nomes e o Item 002 com as coletas temporais de cada métrica. Meu trabalho foi justamente resolver o ETL desse satélite – mas esse é assunto para outro dia.

E isso é tudo que você precisa saber sobre o cenário.

Acabou!

… Só que não! Assim que eu versionei e botei o processo no ar, veio a pergunta:


Conversation with XXX on Ter 07 Mar 2017 16:19:37 BRT:

(16:19:37) XXX: Tem pespectiva de crescimento?


Duhn… Me pegou de surpresa. Não, eu não tenho a menor idéia! Mas faz assim: deixa rodar uma semana e extrapola! Que coisa…

Claro que eu não respondi isso. Até admito que isso me passou pela cabeça, mas um segundo depois eu lembrei que a tabela guarda, justamente, histórico! Ou seja, a carga inicial do satélite Item 002 já vem com um histórico! Neste caso, desde 2016. Como possui dados agregados na hora, temos aí pelo menos uns 300 dias de crescimento, carregados de uma talagada só.

Era tentador demais para eu deixar quieto, hehe.

Extrapolando

Ao contrário do que o nome sugere, extrapolar não é dar um pulo a mais, não é extra pular.

Nem tem nada a ver com um super frio, um frio extra-Polar.


Tá-dá-dum-tssssss!!


Fingindo que nada aconteceu, vamos de novo: todo nós fazemos extrapolações, corriqueiras e diárias. Por exemplo, sempre voltamos ao mesmo restaurante porque se ele estava lá ontem, deve continuar lá hoje – extrapolamos a continuidade temporal de uma empresa para o dia seguinte a partir do fato que ela esteve lá nos últimos X dias.

Eu só tinha que fazer a mesma coisa aqui: contar o número de linhas por dia, pegar algumas diferenças entre dois dias e tirar uma média de crescimento diário. Fácil… e extremamente sem-graça.

Para que simplificar, se podemos complicar, não? ;-)

O Problema & Sua Solução

Meu cliente tem um disco rígido com 600 GB reservados para o banco de dados. Comprar disco novo é – apesar de tudo – complicado, já que é um disco especial e coisa e tal. Logo, se o disco não for o bastante para o serviço, ele precisa saber antecipadamente quando vai lotar, para poder agir a tempo de substitui-lo sem interromper o processo de ETL. É um problema clássico da área de TI chamada Capacity Planning.

  1. Quanto tempo de coletas diárias esse HD comporta?
  2. Com que velocidade ele está enchendo?
  3. Quando ele vai estar a 75% da capacidade?
  4. Quando é que eu terei mais 6 meses até ele lotar completamente?

Note que essas perguntas têm uma resposta válida apenas se as condições atuais se mantiverem inalteradas. Por exemplo, a velocidade de ocupação do HD depende que o sistema de origem continue se comportando como vem fazendo até hoje, e que o cliente não inclua mais nada no Data Vault. Mesmo assim, ainda é uma medida com alguma imprecisão – é só pensar em arquivos temporários e auto-gestão do banco de dados (um Postgres, aliás), sistema operacional etc. etc. etc.

Como esse problema é resolvido?

De maneira simples, basta medir a variação de espaço ocupado de um dia para outro, ao longo de algum tempo, e tirar uma média. Por exemplo, suponha que esta tabela mostre a evolução do espaço ocupado dia-a-dia:

Dia Bytes Gastos
   1         1000 
   2         1100 
   3         1220 
   4         1310 
   5         1460 
         … 

Podemos “plotar”[^1] isso. Apelando para o bom e velho LibreOffice Calc/MS Office Excel:

Gráfico de consumo de bytes por dia no HD.

Isso quer dizer que do dia 1 para o dia 2 o HD teve 100 bytes gastos. Podemos fazer uma tabela:

Dia Delta Bytes
1-2         100 
2-3         120 
3-4          90 
4-5         150 
        … 

Somando tudo e dividindo por quatro, temos que cerca de 115 bytes são acrescidos a cada dia – em média. Essa é a velocidade média da ocupação do disco: 115 bytes/dia. Usando isto podemos responder as perguntas:

  1. Quanto tempo de coletas diárias esse HD comporta? R.: 600 GB / (115 bytes/dia) = 5.6e9 dias ~ 15.3 milhões de anos;
  2. Com que velocidade ele está enchendo? R.: 115 bytes/dia.
  3. Quando ele vai estar a 75% da capacidade? R.: 75% de 600 GB = 450 GB. 450×(1024^3)÷115 = daqui a 4.2 milhões de dias, ou 11.3 milhões de anos;
  4. Quando é que eu terei mais 6 meses até ele lotar completamente? R.: Esqueça, isso não vai acontecer nem durante a vida do seu tataraneto. :-)

Pegou a idéia?

Agora vamos tratar os dados que eu peguei do sistema, dentro do processo SEMMA.

SEMMA na Veia

O mundo é um lugar livre, e podemos seguir o caminho que quisermos. Se formos inteligentes, faremos o que outros já fizeram antes de nós e resultou em sucesso. Uma dessas coisas é o processo de garimpagem de dados. Existem dois mais famosos:

O primeiro é mais abrangente e engloba a parte que já fizemos, de entender o negócio e o problema. Ele foi desenvolvido por um consórcio de fornecedores e especialistas, e é bem legal.

O segundo possui essencialmente as mesmas partes, exceto as etapas de entender o problema, e foi criado pelo [SAS][sas_bitly] para suportar o Enterprise Miner, a ferramenta de DM deles. Ele é bem didático e direto e por isso vou usá-lo aqui.


Como sempre, melhor ou pior é algo flexível em BI. Métodos e ferramentas existem aos borbotões por aí e o truque é escolher aqueles que fazem o trabalho que você precisa, sem te aborrecer demais.


SEMMA significa:

  • Sample
  • Explore
  • Modify
  • Model
  • Assess

Funciona assim:

  1. Ao invés de pegar o dataset inteiro, escolha uma amostra. Isso é importante porque precisamos reservar uma parte dos dados que estão sendo analisados para testar o resultado, ou seja, para descobrir o quanto a nossa previsão, o nosso modelo, está dentro da realidade. O post A Nuvem Negra discorre um pouco sobre a importância dessa etapa. Os dados usados na modelagem são chamados de dados de treinamento, e o conjunto restante de dados de teste;
  2. De vez em quando temos uma idéia clara do que aqueles dados devem representar, outras vezes não. Por via das dúvidas, explore esses dados de algumas maneiras para tentar apreender o que está acontecendo ali, ou se a sua intuição está bem calibrada. Por exemplo, plote-os ou calcule uma estatística básica (média, mediana, dispersão etc.) sobre eles;
  3. O mundo real é sujo, e dados do mundo real são sujos da mesma forma. Como se isso não bastasse, ainda existem aquelas situações nas quais os dados precisam ser re-alinhados, digamos assim, ou traduzidos. Basta pensar num clássico dos clássicos: uma lista de perfis de compradores, em que o gênero não vem como M ou F, mas como 0 ou 1. Mesmo que possamos usar números, é muito mais prático (e para alguns modelos, imprescindível) traduzi-los para letras. Sempre precisamos olhar os nossos dados e verificar se é preciso modificá-los de alguma forma, e como;
  4. Só então é que podemos partir para os finalmentes: construir um modelo. É a parte mais divertida da bagaça: passar aquela renca de linhas numa regressão polinomial e ver se o Chi-Quadrado está baixo o bastante, é rodar uma clusterização e descobrir se existem grupos óbvios ou talvez nem tanto, e assim por diante. No exemplo de hoje eu vou tentar ajustar os dados a um modelo linear, ou seja, a uma descrição dos dados que se posicionam em uma organização retilínea;
  5. Pronto, certo? Não! É muita inocência acreditar que só porque o modelo mostrou um alto coeficiente R e uma baixa dispersão ele está correto, menos ainda pronto. Há muita coisa que pode (e boa parte vai) dar errado na sua modelagem. Só para começar, você pode sofrer de overfitting, uma situação em que seu modelo explica bem demais os pontos que você estudou, mas muito bem mesmo!, mas falha completamente em qualquer ponto fora da amostra. Por isso precisamos avaliar a adequação do modelo à realidade. É justamente para isso que serve separar o conjunto total de dados em pelo menos duas partes, o que é feito lá na primeira etapa: se os dados são uniformes, e as partições de dados equilibradas, o modelo ajustado em na amostra vai apresentar a mesma precisão na partição restante

Se o modelo ou o particionamento não forem bons o bastante, o ajuste do modelo ao dados de teste vai ser pior que aos dados de treinamento. Se isso acontecer – se o modelo não se mostrar tão bom quanto parecia – mas ainda assim for um resultado bom o bastante para seu uso, o trabalho acabou. Se, por outro lado, o ajuste do modelo aos dados de teste ficar muito ruim, precisamos recomeçar o processo do início: rever amostragem, explorar, modificar a amostra, modelar e testar de novo. Deu certo? Fim! Ainda está ruim? Repita de novo, e de novo até chegar no resultado que você quer, ou provar que não pode ir além daquilo.

Ao trabalho!

Sample

Temos uma tabela que aumenta a cada hora. Ela tem este layout:

Coluna Tipo
h_item_bk Bigint
s_item_002_ldts timestamp
s_item_002_rsrc Varchar
s_item_002_ledts timestamp
clock Bigint
num Integer
value_avg Number (16,4)
value_max Number (16,4)
value_min Number (16,4)

Dela nos interessa apenas a contagem de linhas por dia. Podemos usar a coluna s_item_002_ldts ou clock para fazer essa contagem, já que são as que guardam o tempo de cada medida. Como a coluna LDTS é do padrão do Data Vault, vamos deixá-la de lado e ficar com clock, que tem mais a ver com o assunto em si.


Só para constar, tanto faz a coluna que escolhermos já que ambas, s_item_002_ldts e clock, são iguais. A primeira é um timestamp no formato AAAA-MM-DD hh:mm:ss.mmm, enquanto que a segunda é a mesma data/hora representado em formato Unix Epoch (a quantidade de segundos desde 1 de janeiro de 1970.)


Quantas linhas são capturadas por hora? A consulta SQL abaixo nos dá essa lista:

SELECT clock,
SUM(1) AS qtd
FROM dv.s_item_002
GROUP BY clock
ORDER BY 1

O resultado é:

Clock      Qtd 
1456801200   65 
1456804800   68 
1456808400   57 
1456812000   57 
1456815600   63 
1456819200   53 
1456822800   62 
1456826400   56 
1456830000   56 
1456833600   50 
1456837200   60 
…          …

Vamos converter clock para data/hora só por curiosidade:

Data/Hora             Qtd
2016-03-01 00:00:00.0 65 
2016-03-01 01:00:00.0 68 
2016-03-01 02:00:00.0 57 
2016-03-01 03:00:00.0 57 
2016-03-01 04:00:00.0 63 
2016-03-01 05:00:00.0 53 
2016-03-01 06:00:00.0 62 
2016-03-01 07:00:00.0 56 
2016-03-01 08:00:00.0 56 
2016-03-01 09:00:00.0 50 
2016-03-01 10:00:00.0 60 
…                  

Ou seja, existe 65 linhas correspondentes a itens coletados entre a meia-noite e a uma da manhã de primeiro de março de 2016. Daí há 68 linhas na hora seguinte, e 57 logo depois e assim por diante.

O conjunto total que eu tinha para analisar possuía (neste exato instante já é maior) 8.774 linhas. É um conjunto pequeno, então eu poderia analisá-lo inteiramente, mas isso seria conceitualmente errado, e por isso eu vou escolher uma amostra.


Apenas “conceitualmente errado” porque um ajuste de reta tem muito pouco a ganhar separando o volume inteiro em datasets de treino e teste. No final das contas, para uma regressão linear, que é o modelo que eu estou buscando, o resultado acaba ficando até mais próximo da realidade incluindo todo mundo.


Como amostrar? Há diversas técnicas:

  • Percentual: sorteia-se um X % de linhas do dataset original;
  • Periódico: pega-se uma linha a cada X linhas;
  • Particionado: quebra-se o dataset em faixas e pega-se uma quantidade de cada faixa.

Como a intenção é apenas passar pela etapa e cumprir a tabela, vou apelar para uma amostragem simples: [Reservoir Sampling][reservoir_bitly]. A vantagem dessa técnica – para mim, hehe – é que o PDI possui um passo que faz isso. Assim, eu escrevi uma transformação bem simples que lê o dataset original, faz o “sampling” e devolve um dataset de amostra.

Amostragem “reservoir” no PDI.

Pronto, etapa concluída.

Explore

Hora de explorar esse dataset para ver se achamos algum comportamento ou algo que sugira uma abordagem em detrimento de outra.

Como o próprio nome sugere, essa etapa do SEMMA é voltada a examinar o conjunto de dados de várias formas, em busca de alguma pista sobre o quê informação eles guardam. Para isso vale de tudo:

  • Montar uma tabela com estatísticas básicas: média, mediana, dispersão, máximo, mínimo, esperança etc.
  • Plotar um gráfico simples, bi- ou tri-dimensional;
  • Contagens diversas ou construções de clusters.

Qualquer coisa vale, para ser sincero. Se você já está com um palpite, pode testá-lo. Se você acha que uma determinada variável é inútil, pode buscar evidências disso. O importante é que você ganhe um “sentimento de conhecer” o dataset em questão.

E quando você não souber o que usar, use tudo que souber. Cedo ou tarde você vai passar por um momento ah-ha! e a coisa via começar a ficar mais intuitiva.

Já passei algumas vezes por situações em que, de qualquer forma que eu olhasse os dados, nada aparecia. Não tem grilo: ausência de padrão não é um erro, mas um fato. Apenas certifique-se que fez o bastante e, neste caso, mire seu processo em provar que os dados não tem correlação útil. Esse resultado vai te levar a buscar mais dados, ou a abandonar de vez o problema.


Uma vez vi um amigo comentar que trabalhou por meses com uma grande companhia de Internet para tentar analisar os dados de navegação dos usuários. No final eles concluíram que não havia nada para concluir. :-D


Qualquer ferramenta serve, mas eu vou optar pelo [Weka][weka_bitly] porque é a ferramenta de Data Mining tradicionalmente associada ao Pentaho. Existem outras que, na minha opinião, são mais adequadas ao uso em produção (como RapidMiner) ou poderosas (como o R) e oferecem mais possibilidades, mas no momento o Weka basta – poderoso e fácil de usar.

Sem transformar este post em um tutorial, vale a pena dizer só que o Weka facilita o trabalho de explorar: rode-o, selecione o módulo Explorer, clique em Open File e depois em Visualize.

Plot de todas as variáveis contra todas as variáveis no Weka.

Hmm… Lembram-se que nossa intenção original era achar uma “velocidade” para o crescimento do volume de dados? Essa amostra oferece uma séria ameaça a esta idéia. Notou o quadrante superior esquerdo? Ele até acomoda uma reta, mas parece mais uma corcova. Não acredito que ali exista uma exponencial… muito menos uma assíntota.

Hora de pegar outro conjunto de dados: vamos usar tudo, de uma vez – podemo, afinal, já que é pequeno.

De novo, agora com o *dataset* completo.

Ô, diacho! Mesma coisa?!?

Isso quer dizer que 1) a amostra é muito boa, pois é praticamente a mesma coisa que o conjunto original e 2) o sistema exibe um comportamento de tendência a estabilidade. Lembrando que esses dados são a quantidade de dados por hora, vemos que no começo havia muita variação, e aos poucos vai se fortalecendo uma regularidade maior, com uma variabilidade menor.

Opa, descobrimos algo importante! E era isso que eu estava procurando. Agora podemos ver que o sistema está entrando em equilíbrio, e os dados do início são menos relevantes que os dados do final, que são muito mais regulares.

A consequência disso é que, se levarmos em conta TUDO, vamos acabar diluindo o comportamento atual do sistema com uma tendência que não existe mais! Logo, a nossa ação mais imediata é limar o dataset original para, vai, logo depois daquele degrau, quando o sistema ficou mais estável:

O X vermelho marca o início do comportamento atual.

Depois de procurar um pouco descobri que esse X vermelho está, mais ou menos, perto do ponto clock = 1474963200. Vou reaplicar a amostragem e remover tudo que vier antes dele. Também vou dividir o dataset (tirar uma amostra) em duas partes iguais. Eis o novo gráfico:

Plot da segunda amostra (50% de tudo que veio depois de 1474963200.)

Esse gráfico foi desenhado com o GNUPlot.


Beleza! Agora sim, temos um conjunto de dados bacana.

Modify

A etapa de modificação do SEMMA contempla todo tipo de tratamento dos dados para torná-los adequados ao estudo. Ou seja, remover outliers indesejados (sim, existem outrliers desejáveis!), agregar, quebrar, normalizar, traduzir, classificar e categorizar as inúmeras variáveis, tratar nulos, brancos, erros etc. etc. etc.

O nosso caso até que é bem comportado: duas colunas, X e Y, com números inteiros.

Por outro lado, olhe de novo: é uma lista de clocks! Quero dizer, de Unix Time!


Unix Time, também chamado de POSIX time ou epoch, é um sistema para descrever instantes no tempo, definido como o número de segundos passados desde a meia-noite de 1/1/1970 (uma quinta-feira, diga-se de passagem.)


Muito prático para medir e guardar tempo, mas inadequado para estimar variação de bytes por dia. Então aqui está a nossa modificação: trocar clock por dia!

Felizmente o PDI pode nos ajudar nisso de novo: basta converter clock para data e hora, e depois somar todos os pontos de um mesmo dia, isto é, agregar por dia. Atualizei a transformação e agora a amostra sai assim:

dia  qtd 
25/02/2017 657 
26/02/2017 1168
27/02/2017 730 
28/02/2017 876 
01/03/2017 1241
02/03/2017 730 
03/03/2017 730 
04/03/2017 949 
05/03/2017 803 
06/03/2017 730 

Que plotando dá:

Mesmo gráfico, agora agregado por dia.

Notou algo incomun?

Você, que aprendeu operações básicas na quarta série e funções na sétima, me diga: que operação algébrica leva uma data em um número? Ou então, se olharmos apenas para a primeira linha, que número, dividido por 657 é igual à 25/2/2017? Nenhum, não é? Claro! O tipo DATE não serve para operações matemáticas. Então, se quisermos achar uma equação que expressa a quantidade de linhas capturadas em função do dia, precisamos converter as datas em alguma outra coisa como, por exemplo, um número de dias.

Daí eu fiz a seguinte alteração: a primeira data é 0 e daí em diante cada data é alterada para o número do dia correspondente. A tabela acima fica, então, assim:

dia qtd 
  0  657 
  1  1168
  2  730 
  3  876 
  4  1241
  5  730 
  6  730 
  7  949 
  8  803 
  9  730 
  …    …  

Agora sim, podemos achar um função que leve x = {N} (x pertencente ao conjunto dos número Naturais) em y = {N}.


Atenção que a coisa agora ficou mais complicada.

Depois de todas essas alterações, o conjunto de dados está diferente do conjunto inicial. A lista que temos para trabalhar, agora, não reflete mais o comportamento do sistema. Antes, tínhamos uma amostra de linhas por hora. Escolhida aleatoriamente, uma linha qualquer representava o sistema naquele momento em que ela foi capturada.

Após converter a escala de horas para dias, precisamos fazer essa conversão sobre os dados originais. Não podemos fazer essa troca sobre a amostra!

Porquê? Por que o total de linhas capturadas num certo dia da amostra é menor que o mesmo total, naquele mesmo dia, sobre o volume inteiro!

Estando conscientes desta mudança, voltamos um passo atrás, geramos um dataset original de novo – agora convertido em dias – e só então é que poderíamos pegar uma amostra! Caso contrário, estaríamos olhando um sistema potencialmente diferente dos dados reais!


Só que o dataset, que começou com mais de oito mil pontos, caiu a 163 linhas. Se já era pequeno, agora está muito menor (uma ordem de grandeza menor, para ser mais preciso.)

Escolher uma amostra de um conjunto tão pequeno é mais que desnecessário, é perigoso, pois pode nos levar a um resultado enviesado. Só nos resta decidir entre acumular mais dados, e atrasar a análise, ou usar o dataset inteiro, e aceitar que nosso modelo estará sob risco de overfitting, entre outros.

Como este post é só uma visão geral, vamos aceitar os riscos inerentes a um dataset pequeno e seguir adiante.

Acabamos de modificar completamente nosso dataset. Podemos passar para a etapa seguinte? A rigor, não: precisaríamos retornar com esse novo conjunto de dados para a etapa de exploração e ver se algo mudou significativamente. O nosso caso é muito simples, então podemos seguir adiante sem preocupação, mas nunca tome essa decisão automaticamente, ok?

Model

YEAH!! Chegamos lá! :-D Agora é que a parte legal acontece, quando vamos realmente aplicar nossos cérebros em estudar os dados. Nosso objetivo, lembre-se, é tirar dali um modelo matemático, algo que explique o que está acontecendo e como está acontecendo. Com sorte tiramos até porque está acontecendo.

Mas vamos um passo de cada vez.

Antes de mais nada, entenda que aqui existe um pouco de chute. O exemplo de hoje é muito simples, diria até que não dá para ficar mais simples, mas raramente isso acontece. O mais comum é ter algum problema já tratado, uma combinações de problemas conhecidos, ou algo tão inédito que você talvez tenha que inventar algo novo.


Esse amigo meu, doutor em Física Nuclear, topou com um destes, numa entrevista de emprego Kobayashi Maur. O entrevistador passou um problema, com uma semana para resolver. Imagine: entrevista de emprego, prova, com prazo de uma semana para entregar. Daí você tem um grau do que é o topo da cadeia alimentar em Data Mining.[^2]


Existem classes de modelos mais ou menos aptos a cada tipo de problema. Assim, descobrir perfis de cliente sugere uso de clusters e árvores de decisão, enquanto que tendências sugerem algum tipo de regressão. Para quem está começando essa parte é o Inferno na Terra – de onde começar, raios? Como saber ao menos o que pode ser chutado como modelo??

Por isso que é imprescindível que o profissional aspirante a – arfff – Cientista de Dados (coça, coça) faça um curso de Estatística básica e, preferencialmente, um curso de Data Mining mesmo. O curso de Estatística serve para dar traquejo matemático, mas o que vai agregar valor é o curso de Data Mining, que é onde se aprende quais modelos existem, e como eles podem ser usados, em que situação etc.


Certos tipos de profissionais, como físicos e engenheiros, tem uma aptidão natural para Data Mining, já que muito do que se estuda nessas faculdades é criar e resolver modelos. Entretanto, nada libera ninguém de um tempo de trabalho na área até “pegar o jeito”, claro. Experiência conta muito!


Ok, agora vamos ao nosso caso. Sabemos – da etapa de exploração dos dados – que o sistema de origem dos dados está “em regime”, ou seja, está com um comportamento regular. Houve uma zona de ajustes, no início, quando a quantidade de linhas capturadas por hora variou bastante. Hoje isso não acontece mais e o volume de dados entrantes é praticamente constante.

Isso já é um modelo! O volume de dados novos amanhã será igual ao de hoje. Ou seja, velocidade constante de crescimento. Que velocidade? Podemos pegar o último ponto e repetir, por exemplo, ou pegar uma média de todos para dar um chute mais “educado”.

Quem estudou Cálculo I e Cálculo Numérico (ou fez alguma matéria de laboratório de Física I), conhece uma forma simples de avaliar comportamentos regulares: plotar os pontos em um gŕafico log ou log-log. Se nosso sistema tiver um comportamento linear próximo à constante, uma escala muito grande (10x) ou um gráfico semi-log vai mostrar os pontos alinhados muito perto de uma linha horizontal. Vejamos:

Plot semi-log dos dados da amostra limpa. Praticamente constante!

Primeiro: nossa hipótese foi comprovada, o sistema possui um comportamento próximo à constante ou, no mínimo, linear. Isso é mais que suficiente para consolidar o modelo. Só por via das dúvidas, vamos fazer a coisa com um pouco mais de Matemática, mas antes, cabe outra observação: notou os dois outliers? São o primeiro e último pontos do dataset. Devemos fazer algo?

Outliers, em quantidade ou deslocamento suficientes podem afetar intensamente o resultado do modelo, logo devemos tentar removê-los sempre que tivermos uma certeza boa de representarem um estado incorreto do sistema, ou de frequência desprezível (i.é., raro, improvável.) O importante é saber se removê-los vai melhorar o modelo ou piorá-lo, sempre.

Pensemos um pouco: porque estão ali? Porque são justamente o primeiro e o segudo ponto?

Uma hipótese razoável é que não representam o dia inteiro e por isso não correspondem ao comportamento regular do sistema. Se isso for verdade, podemos removê-los.

Ela se sustenta?

  • O último ponto representa o estado do sistema quando o ETL rodou pela primeira vez, durante o dia. Logo, sim, para o último ponto sustenta-se, sim. Podemos removê-lo;
  • O primeiro ponto representa um corte no dataset, bem no clock igual a 1474963200. Isso corresponde à data/hora 2016-09-27 05:00:00. Em outras palavras, o dataset começa no dia 27/9/2016, mas com dados apenas a partir das cinco horas da manhã! Tudo entre a meia-noite e as cinco foi descartado! Então não é um dia completo, e a hipótese, de novo, mostra-se correta. Por isso eliminamos também este ponto.

Note que, se tivéssemos retornado à etapa de exploração no final da etapa de modificação, já teríamos feito todas essas observações.


Beleza, então já sabemos que o sistema apresenta um comportamento de uma reta ao longo do tempo. Em Estatística existe uma técnica chamada Regressão Linear, que descobre modelos de retas a partir de observações. É uma idéia simples: traçar uma reta (= calcular o coeficiente de inclinação a e a intersecção com o eixo X, b) entre os pontos medidos, de tal forma que ela (a reta) fique à menor distância possível de todos os pontos, simultaneamente.

Dito ao contrário, uma regressão linear descobre o valor de a e b da equação f(x) = a.x + b que minimiza a soma de todas as distâncias de f(x) a cada ponto medido.

A distância entre a reta f(x) e o ponto y correspondente.

Traduzindo, e olhando a figura anterior: queremos achar a e b tais que a soma de todos os ds seja a menor possível. Pronto, acabou a teoria de regressão linear. Se quiser saber mais vá atrás deste link.

O LibreOffice e o Excel (e o Weka, e o RapidMiner e o R e o…) fazem isso. Para mostrar como, eu vou usar momentaneamente um conjunto de dados artificial, diferente do nosso problema, ok? Só para deixar mais claro como tudo funciona.

Primeiro, clique com o botão direito do mouse sobre um dos pontos do gráfico e escolha a opção Trend Line, conforme mostra a figura:

Como pedir uma regressão linear no LibreOffice.

Entre alguns parâmetros, como o nome da função e quais resultados você quer ver. Na imagem abaixo você vê que eu coloquei f(t) como nome da função e pedi para ser exibido a função em si e o coeficiente de relacionamento (R^2):

Parâmetros da regressão linear no LibreOffice.

Quando você dá Ok no diálogo acima, o Calc sumperimpõe a reta encontrada sobre seus pontos. Eu mexi um pouco mais e fiz com que ele mostrasse não apenas a reta sobre os pontos já medidos, mas também coloquei os pontos de cinco dias seguintes, extrapolando o crescimento do volume de dados:

Ajuste plotado sobre dados, extrapolando o futuro.

Ficou claro? É assim, aliás, que vamos usar o modelo.

Aplicando essa técnica ao dataset sem os outliers, temos:

![ Modelo de progressão do volume de linhas coletadas dia-a-dia. ][Figura 14]

Show! :-) A regressão linear deu o seguinte:

  • Reta: f(x) = 0,4334.x + 1700
  • Coeficiente de correlação ao quadrado: R^2 = 0,39

A interpretação desse modelo é o seguinte:

  • A cada dia, o sistema incorpora um número de linhas igual a 0,4334 x dias, mais 1700;
  • Esse relacionamento entre o dia e o volume de dados não é dos melhores, já que R^2 está distante de 1.

O R^2 é um indicador de “qualidade” do ajuste. Quanto mais perto de 1, mais ajustada é a reta que encontramos, e quanto mais perto de zero, pior é o ajuste. Como o R^2 do nosso caso está mais perto de zero do que de um, somos levados a concluir que o ajuste da reta não ficou tão bom quanto possível. Isso não significa que o Calc errou, ou mesmo que podemos melhorar nosso ajuste, mas antes implica que há uma dispersão entre os dados que torna questionável o resultado da nossa análise.

Assess

A última parte do SEMMA diz respeito a testar o modelo em relação à realidade. Como usamos o dataset completo para construir o modelo, temos duas opções para fazer essa avaliação de qualidade:

  1. Deixamos o sistema acumular pontos por mais algum tempo, como uma semana ou um mês, e usamos esses novos valores para testar o modelo;
  2. Voltamos atrás, dividimos o nosso (já exíguo) dataset em amostra de treinamento e amostra de teste e refazemos a regressão linear.

Em qualquer um dos dois casos, a medida de sucesso é o quanto o modelo acerto em relação à realidade. Há várias maneiras de fazer isso, que depende inclusive do modelo usado. Este caso, por exemplo, mostra como avaliar a qualidade do modelo em uma regressão múltipla (coeficientes lineares, várias variáveis.)

O nosso caso é muito simples, insisto, mas não quero deixar essa seção sem nada. Então vamos dividir o dataset em dois, regredir o primeiro e ver como a extrapolação casa com o segundo.

Primeiro, separei aquelas 161 (163 – 2 outliers) linhas de dados em dois conjuntos, um com 80% (128 linhas) para treinamento, e outro com 20%, ou 33 linhas, para teste.

Primeiro, eis o resultado da regressão:

Regressão sobre os primeiros 80% do dataset.

Interessantemente o bastante, o R^2 é maior neste conjunto que no conjunto total, o que torna este modelo melhor neste dataset que o primeiro, para todos os pontos. Isso, e o valor de a quase o dobro do primeiro modelo, sugerem que talvez exista algum outro comportamento embutido aqui, sutil o bastante para não aparecer em um simples plot. Se bobear, eu acertei um ponto de inflexão sem querer. Vixe.

Usando essa equação eu montei um segundo gráfico, no qual aparecem os 20% de pontos restantes, juntos com duas novas séries de pontos: em vermelho/diamante os pontos calculados a partir do modelo, e em nabla (triângulo invertido, uma letra grega) verde, a diferença entre o valor sugerido pelo modelo, para aquele dia, e o valor efetivamente medido. Veja:

Teste da regressão sobre os últimos 20% de dados.

E aí está: o erro, nabla verde, segue crescendo lentamente, mas sem dúvida nenhuma crescendo.

Erro do modelo em relação à realidade.

Respostas, Afinal!

Então nosso estudo, nossa garimpagem, produziu o seguinte resultado: (vou usar o primeiro modelo, só por gosto)


O banco de dados cresce a uma taxa de f(x) = 0,4334.x + 1700 linhas por dia.


Mas quanto representa isso em bytes? Afinal, o espaço em disco é medido em GB, não em linhas – ao menos não diretamente.

Eu rodei algumas consultas no Postgres e descobri que, a tabela inteira carregada só com esses dados, dava uma média de 120 bytes por linha. O que faz sentido, se lembrarmos do layout desta tabela:

Coluna Tipo Tamanho
h_item_bk Bigint 8
s_item_002_ldts timestamp 8
s_item_002_rsrc Varchar 64
s_item_002_ledts timestamp 8
clock Bigint 8
num Integer 4
value_avg Number (16,4) 20
value_max Number (16,4) 20
value_min Number (16,4) 20

O total dá 160, mas dos 64 bytes possíveis para o VARCHAR apenas 8, “ZABBIX000”, são usados. Somando um para o fim da string, o total cai para 105 bytes. Um pouco de overhead explica a média em 120 bytes, o que não é de todo inaceitável. Logo, multiplicamos a equação inteira por 120 e temos um modelo em bytes. Ah, e mais um detalhe que eu não havia contado: estamos coletando dados de 10 Zabbixes, logo o modelo final precisa ser multiplicado por dez, também.

Portanto nosso modelo deve ser:


O espaço em disco ocupado pela tabela cresce a uma taxa de f(x) = 520.x + 2040000 bytes por dia.


Não se esqueça que x = 0 é 27/9/2016 e tudo é medido a partir daí.

Pronto! Podemos FINALMENTE responder as perguntas com algum critério:

Quanto tempo de coletas diárias esse HD comporta?

Se ele tem 600GB de espaço, e mais nada acontecer ou for acrescentado:

600 GB = 520.x + 2040000
600 . 1024^3 = 520x + 2040000
520x = 644245094400 - 2040000
x = 1.238.928.951 dias, aprox.
= 3.394.325 de anos, aprox.

Bom, da primeira vez eu estava de brincadeira, mas agora estamos bem mais embasados: qualquer que seja o erro do nosso cálculo, ainda tem muuuuuuuuito tempo até encher isso tudo. Para mim, passou de 10 anos é infinito.

Com que velocidade ele está enchendo?

Basta resolver a equação para um dia:

f(x) = 520.x + 2040000
f(1) = 520.1 + 2040000
= 2.040.520 bytes/dia
= 1.993 KB/dia
= 1,9 MB/dia
= 0,002 GB/dia

Eu fui dividindo por 1024, no caso de você estar se perguntando.

Quando ele vai estar a 75% da capacidade?

Em 0,75 * 3,3 milhões de anos, ou 2,4 milhões de anos, aproximadamente. :-P

Quando é que eu terei mais 6 meses até ele lotar completamente?

Irrelevante, concordam?

Conclusão

Este post começou como o relato de um exercício que eu fiz, em cinco minutos, para tranquilizar os donos dos servidores de Data Vault, dizendo que não estávamos capturando tanta coisa assim, afinal. Era quarta-feira, eu ia escrever o post da semana e pensei, porque não? Eu estava postando muita coisa ousada ultimamente, e seria um post divertido de escrever (ainda que não tanto de ler.)

Mas, meus amigos e amigas, caramba!… Estou escrevendo há três dias!

Francamente, acho que valeu a pena. Até porque, que coisa doida, ontem apareceu este comentário no post do A Nuvem Negra, feito pelo Rafael:


(…)

Já que, como você diz, BI não existe (risos), por mais que a gente estude e trabalhe com, ficamos na dúvida sobre o que é ou não é BI. Olhar Business Intelligence como ciência pura me fez pensar o seguinte: BI e Ciência de Dados seriam a mesma coisa? Fico com a impressão de que Ciência de Dados está sendo vendida no Brasil mais como um chavão e relacionado especificamente com Big Data.

E sobre testar o que foi aprendido com o passado, isso se daria em ambiente de teste ou de produção?

(…)


Passem lá para olhá-lo, foi muito inteligente e acho que agrega muito lê-lo.

Bom, o que eu posso dizer? Eu acabei respondendo as perguntas dele, ainda que meio indiretamente. Se não, vejamos:

  • Ciência de Dados e BI são a mesma coisa? Resposta: não, Rafael. Se há alguma equivalência entre Ciência de Dados, um termo do qual eu não gosto, e alguma coisa, eu diria que Data Mining é essa alguma coisa. Juro para você, meu caro, quando você postou, eu já tinha escrito isso (está lá no começo, procure):

“Por isso que é imprescindível que o profissional aspirante a – arfff – Cientista de Dados (coça, coça) faça um curso de Estatística básica(…)”

Ou seja, para mim Data Science é o jargão da vez para Data Mining, assim como Data Discovery foi para OLAP.

  • E como testar o que aprendemos com o passado? Concorda comigo que foi exatamente essa pergunta que eu acabei respondendo hoje? O tal “aprender” pode ser entendido como “construir um modelo”. Levamos esse modelo “para produção” de diversas formas. Hoje eu mostrei como planejar a capacidade do seu ambiente usando Data Mining. No exemplo de hoje, levar o modelo para produção equivale a saber que tamanho de disco precisamos para aguentar até a próxima troca de hardware. Em outros casos, levar para produção pode ser programar o caixa eletrônico para mostrar uma oferta de crédito sempre que o cliente A ou B se registrar. Pode ser planejar uma plantação de eucaliptos para produção de papel, que só vai acontecer daqui a uma década. Pode ser construir um algoritmo de controle da injeção eletrônica em função de inúmeros fatores. Pode ser um monte de coisas!

Esse, aliás, é um bom tema para um post. Estou vendo outra série surgindo – explicando Data Mining ou, afff, Data Science. :-D

O nome original deste post era Prevendo o Futuro. Eu não tive como não alterá-lo para Introdução à Data Mining depois de tudo, e ainda mais depois do comentário do Rafael.

Aliás, Rafael, muito obrigado pelo comentário. Prometo que vou postar mais coisas daquele naipe. Aguarde o Bola Quadrada, hehe!

Então é isso.

Acabou? Sério? ALELUIA!

A-LE-LU-IA!!!!!

:-)

Parabéns por chegarem até aqui, e obrigado pela companhia.

Até a próxima. ;-)

 

A Culpa é do Cubo!

Em 12 de janeiro de 2017 eu estive no evento DBTalk Liderança Ágil, tocado pelo meu ídolo agilista Jorge “Kotick” Audy. Foi uma hora e meia sendo soterrado por avalanche atrás de avalanche de assunto sobre liderança, Ágil, organizações, modelos, psicologia…

Como todo bom evento, semelhante a um boi, nada se perdeu, tudo se aproveitou. Depois de tudo que veio na palestra, ainda tive chance de bater papo com ele e muitas outras figuraças que estavam por ali.


É sério, não percam esse evento, que ocorre frequentemente em Porto Alegre, sede da empresa, e com alguma frequência aqui em São Paulo. É do balacobaco.


Uma dessas conversas foi o espanto geral de que há pouco, em termos de Ágil, sendo feito em Inteligência de Negócios. Na verdade é pior que isso: o pouco que eles viram fui eu que levou – um zé ruela qualquer. Fora o que este vosso humilde servo-zé-ruela fez, eles mesmos confirmaram que nunca viram nada.

E porquê? Por que tão pouco existe sobre BI, com Ágil?

Eu descobri essa resposta há muito tempo, mas só ali a minha “Guernica” 1 BI-Ágil ficou completa, só ali é que a última peça fez clique no lugar.

Por causa do cubo.

Adoro Kimball, tanto que fiquei muito triste ao saber que se aposentou – acabou-se minha chance ter aulas com ele. Mas o enorme sucesso de suas idéias acabou levando a uma absurda prevalência da Modelagem Dimensional em projetos de dados para BI. Como em geral são projetos de DWs ou data marts, acabamos sendo levados a pensar tudo em termos de cubos.

Estão acompanhando? Atrelada a projetos de BI existe uma forte cultura de modelagem de dados à moda do Kimball. Assim, nos acostumamos a “pensar” os dados de projetos de BI como organizados em cubos multidimensionais.

E – na minha humilde opinião – esse é O problema. É esse o motivo para existir tão pouca coisa de Ágil para Inteligência de Negócios.

Não sei se vou conseguir passar, aqui, por escrito, a minha percepção do problema e como intuí a resposta, mas vamos tentar.

O Mundo Não é um Quadrado em 3D

Para começar, há muitas necessidades em BI para as quais um cubo é uma abordagem inadequada, quando não atravancadora.

Um exemplo fácil é Data Mining

Resumidamente, Data Mining ou Garimpagem de Dados na minha tradução favorita, é um processo que parte de uma questão de negócios, como o que fazer para aumentar as vendas em 5%? ou como decidir quanto crédito fornecer a cada cliente, e usa Matemática sobre os dados disponíveis para construir um modelo da realidade. Realidade esta que não se apresenta clara, límpida e cristalina nos bancos de dados da empresa, mas sim como uma massa bagunçada e suja de dados oriundos de inúmeras fontes – sistemas transacionais, pesquisas, bases externas, canais diversos etc.


O resultado do processo de garimpagem é um modelo matemático que descreve a realidade, e a realidade é suja.


Para fornecer um resultado com algum grau de confiabilidade, Data Mining precisa de dados crús.

Por outro lado, dados limpos, como os necessários para análises multidimensionais típica, não refletem a realidade completamente. Erros, vazios, nulos, tudo isso é descartado para levar ao cliente uma estrutura com dados claros, que permitam interpretação sobre o que sabemos, já que não adianta especular sobre o que não foi capturado.

Na melhor das hipóteses, dados sujos são disponibilizados para análise com alguma marcação, como “Não preenchido”, “Inválido” etc. Empresas que sofrem com qualidade de dados fazem isso porque assim conseguem um mínimo de certeza em suas respostas. E alguma informação é melhor que nenhuma, sempre.

Outro exemplo? Claro: painéis.

“Como assim!”, exclamarão vocês, “painéis se dão muito bem com cubos!”

É, não posso negar que se dão bem, vocês quase têm razão.

Quase.

Como é mesmo aquilo que dizemos sobre martelos? “Para um martelo, todo mundo é prego.” Se você quer montar um modelo de dados dimensional, para tudo, vai estar condicionando tudo a uma visão dimensão vs. fatos.

Painéis tendem a aglomerar diferentes visões sobre um dado aspecto da sua organização. Logo, não raro temos em um único painel widgets apontando para diferentes fontes de dados. Diferentes origens.

Diferentes cubos.

Vou escrever ao contrário para ver se fica mais claro:


Preparar dados para um painel usando um único cubo requer a consolidação de diferentes grãos em um único, que sirva para tudo.

Caso isso não seja possível, precisaremos de mais de um cubo.


Logo, uma visão de cubos te obriga a transformar toda sua realidade, em que as relações são mais complexas que as relações de um modelo dimensional, em vários pedaços. Isso acaba destruindo a produtividade porque para cada pedaço você precisa passar por todo processo de desenvolvimento de modelo dimensional!

É isso que redime o setor de Data Discovery, meu eternamente incômodo e aborrecido setor de ferramentas para Data Discovery.


Não tenho nada contra ferramenta nenhuma! Mas tenho contra argumentos frágeis e superficiais! Leia aqui!


O que está no centro de uma ferramenta de Data Discovery não é a capacidade de produzir resultado sem precisar de um DW. Caramba, uma ferramenta de DD não tem nada que uma de BI não tenha! São absolutamente iguais!

O que destaca DD da prática tradicional de BI é que Data Discovery prescinde do processo de modelar um cubo como intermediário para análise! Você nunca pode se livrar de um DW porque o Tempo é a variável mais importante de todas, mas em nenhum lugar está dito que é obrigatório ter um cubo para historiar dados! O que no fundo DD faz é abrir mão de um horizonte de tempo maior em prol de maior velocidade na geração de valor!

Worlds Collide!

Eis aqui o Manifesto Ágil:


Manifesto para o desenvolvimento ágil de software

Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:

> Indivíduos e interações mais que processos e ferramentas

> Software em funcionamento mais que documentação abrangente

> Colaboração com o cliente mais que negociação de contratos

> Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.


Esse é precisamente o ponto:

Indivíduos e interações mais que processos e ferramentas

O que é que acontece quando colocamos um cubo à frente de qualquer resultado? Resposta: estamos valorizando o processo e a ferramenta!!

Por que é que temos tão pouco de Ágil em BI?

Que tal analisar o que existe de Ágil para BI listando os livros que tocam no assunto?

Entrei na Amazon.com e coloquei BI e Agile. Deu nisso:

Ágil e BI na Amazon: livros sobre... DW?
Ágil e BI na Amazon: livros sobre… DW?

Depois do terceiro resultado tudo ficava mais ou menos confuso – ou tinha pouco/nada a ver com BI ou com Ágil ou com ambos. Fechei a busca, e coloquei Data Warehouse e Agile:

  • Agile Data Warehouse Design: Collaborative Dimensional Modeling, from Whiteboard to Star SchemaNov 24, 2011
  • Agile Data Warehousing for the Enterprise: A Guide for Solution Architects and Project LeadersOct 8, 2015
  • Better Data Modeling: An Introduction to Agile Data Engineering Using Data Vault 2.0Nov 21, 2015
  • Super Charge Your Data Warehouse: Invaluable Data Modeling Rules to Implement Your Data Vault (Data Warehouse…May 20, 2012
  • The Official Data Vault Standards Document (Version 1.0) (Data Warehouse Architecture)Sep 27, 2012
  • Data Architecture: A Primer for the Data Scientist: Big Data, Data Warehouse and Data VaultNov 26, 2014
  • Agile Data Warehousing Project Management: Business Intelligence Systems Using ScrumSep 28, 2012
  • Growing Business Intelligence: An Agile Approach to Leveraging Data and Analytics for Maximum Business ValueSep 21, 2016
  • Growing Business Intelligence: An Agile Approach to Leveraging Data and Analytics for Maximum Business ValueSep 19, 2016
  • Extreme Scoping: An Agile Approach to Enterprise Data Warehousing and Business IntelligenceAug 15, 2013
  • Agile Data Warehousing: Delivering World-Class Business Intelligence Systems Using Scrum and XPAug 5, 2008
  • Test-Driven Database Development: Unlocking Agility (Net Objectives Lean-Agile Series)Feb 21, 2013
  • Lean Analytics: Use Data to Build a Better Startup Faster (Lean Series)Mar 21, 2013

Ou seja: muita coisa sobre DW e Ágil, mas pouca sobre BI e Ágil.

Ora, bolas, é a Amazon! Eles vendem, e isso enviesa tudo. Vamos procurar uma coisa mais abrangente, mais neutra: o Google!

Ágil e BI, segundo o Google: ferramentas?!...
Ágil e BI, segundo o Google: ferramentas?!…

(Claro que eu sei que o Google também enviesa os resultados. Na verdade, enviesa tanto que eu precisei remover a renca de anúncios que vinha antes do quadro acima. Mas é mais aberto que a Amazon.com, não resta duvida.)

De novo, foco em ferramentas! Ou quase. Se seguimos o link para a Wikipédia, achamos algo mais próximo de Ágil:


Agile Business Intelligence (BI) refers to the use of the agile software development methodology for BI projects to reduce the time-to-value of traditional BI and helps in quickly adapting to changing business needs.(…)


Opa, agora sim! “Ágil BI refere-se ao uso da metodologia de desenvolvimento de software ágil para projetos de BI, para reduzir o tempo-até-valor”! Eles até citam a “metodologia” que nasceu para resolver problemas de desenvolvimento de software, mas focam no que é importante: rápida geração de valor para a organização.

Curiosamente, essa mesma definição tem como referência produtos de software para “fazer BI Ágil”, um tal de Consensus e outro, Logix – nunca havia ouvido falar de nenhum dos dois, o que para mim é suficiente para colocar esse artigo em quarentena. Vou lê-lo e estudar essas ferramentas com mais calma e decidir se é mais algum fornecedor querendo surfar hype, ou se me parece válido, sólido.

Vamos refazer nossa pergunta: por que é que temos tão pouco de Ágil em BI?

Resposta: não sei. Mas se eu precisasse chutar algo, diria que é porque todo mundo entende que o tratamento de dados vem no centro de todo projeto de BI, que por sua vez está perpetuamente voltado para o modelo dimensional.

Colocando de outra forma:


IMHO, temos pouco de Ágil para BI porque quem se dedica a este assunto acaba preso na questão de produzir dados e não de solucionar problemas.

E eu acredito que, também IMHO, isso acontece porque o enorme sucesso da Metodologia de Modelagem Dimensional, de Ralph Kimball, criou em nós uma associação automática entre BI e Cubo.


Conclusão?

Dificilmente isto aqui é uma conclusão, pois eu ainda não cheguei nela. O que eu tenho, por enquanto, é a forte sensação de que o problema de produzir dados para projetos de BI está polarizando a aplicação de técnicas ágeis para BI, causando foco excessivo no desenvolvimento de cubos, ou seja, de modelos multidimensionais.

Eu ainda não achei uma evidência forte de que isso bloqueia o desenvolvimento ágil, ou de como esse bloqueio atuaria, se existir. Intuitivamente eu percebo que um modelo dimensional não é algo muito difícil de ser atacado com métodos ágeis, e até por isso mesmo há tanto material sobre esse assunto. Me parece que o fato de termos um modelo dimensional no meio do caminho entre a necessidade de negócio e a solução de BI é que atravanca as coisas, que por sua vez é justamente a causa aparente do sucesso do Data Discovery. E não podemos ignorar a frequência de fracassos de projetos de DW.

Por exemplo, se um DW cresce pela colagem de um cubo em outro através de dimensões comuns ou conformadas – a tal Bus Matrix – então cada nova necessidade acaba criando algum retrabalho ou uma nova expansão do DW. Eu estou começando a achar que o Modelo Dimensional permite muito pouco reaproveitamento. Quase como se, a cada nova funcionalidade de um sistema fosse preciso duplicar um pedaço grande do sistema, e customizar essa nova parte.

Como lidar com um armazém de dados construído para um único propósito – análise multidimensional – em uma empresa que pode possuir n demandas de m tipos para os dados, em que cada demanda requer praticamente um cubo próprio? E pior: como lidar com as necessidades operacionais?

Confuso? Para mim também. :-(

Eu acho que encontrei a solução (sim, tem Data Vault envolvido, claro!), mas ainda não está madura o bastante para sair aqui. Mas assim que estiver, você será o primeiro a saber.

Até a próxima! ;-)


  1. Guernica é o nome de um famoso quadro sobre um episódio da Guerra Civil Espanhola, pintada por Pablo Picasso. Sua interpretação é muito controversa. Uma das que eu ouvi é que é cheio de partes que representam aspectos do conflito, e tenta capturar a dificuldade que é, para uma mente humana, abarcar uma realidade complexa, cheia de nuances e contradições. Baseado nessa visão eu estou rascunhando um post que tenta mostrar como BI se assemelha mais à Guerra Civil Espanhola, complexa e cheia de partes, que a uma coisa como Física, que é feita de partes interconectadas e articuladas entre si. 

As Soluções Clássicas – Atuarial

Lá em abril eu comecei uma série: As Soluções Clássicas. Até agora existem dois posts lá:

Algumas das soluções tradicionais de BI elencadas então foram:

  • CRM;
  • Crédito;
  • Seguros;
  • Supply Chain;
  • Fraude;
  • Risco.

Destas, além da introdução ao assunto, eu queria mostrar três: CRM, CS e Seguros. No meio do caminho a vida foi acontecendo e o assunto foi ficando de lado, mas hoje vou fechar a “primeira temporada” e mostrar a solução de BI para Seguradoras (e outros negócios.)

O Problema

Você conhece aquela piada de estatística sobre o consumo médio de frango assado?


Dizem que cada brasileiro come em média um frango assado por mês. Bom, então deve ter alguém comendo dois, porque com este preço eu não estou comendo nenhum!


Acho que nem estatísticos riem dessa porcaria, mas enfim, o ponto era chamar o assunto. :-)

A idéia toda baseia-se nos conceitos estatísticos embutidos na piada: se conhecemos a taxa de repetição de um evento, ou seja, se sabemos que em média, algum um certo tanto de eventos vai acontecer dentro de um certo período, podemos calcular a chance de esse evento acontecer de novo dentro de um certo tempo. E conforme conseguimos mais informação sobre esses eventos, podemos refinar o cálculo e obter indicações mais precisas sobre provável próxima ocorrência.

Por exemplo, dados coletados juntos ao Ministério da Saúde e ao Instituto do DPVAT indicam que mais ou menos 200.000 pessoas foram hospitalizadas devido a colisões de veículos em 2014. Dividindo por 12 meses temos que, em média, cerca de 16.700 pessoas se machucaram por mês em 2014.

Para simplificar o raciocínio, vamos extrapolar esse número para todos os anos seguintes e assumir que, em 2016, essa média se manteve.

Arredondando a população brasileira para 200 milhões de pessoas, podemos dizer que ao longo de um ano, ao menos uma pessoa a cada 1000 com certeza vai parar no hospital por motivo de colisão veícular.

E se soubermos mais sobre quem se acidentou, no passado, podemos melhorar a estimativa. Por exemplo, se sabemos que mais homens se acidentam que mulheres, podemos ter uma certeza razoável de que ser homem aumenta o risco, e ser mulher o diminui. E assim sucessivamente: faixa etária, localização geográfica, hora do dia em que sai de casa, estação do ano…


Sabendo que a cada mil pessoas, uma vai parar no hospital a cada ano, por colisão de veículo, qual é a chance que eu tenho de ser uma destas pessoas?


As chances mudam conforme a vida que eu levo:

  • Se eu NUNCA saio de casa, esse risco tende a zero;
  • Se eu dirijo o dia inteiro, esse risco tende ao máximo;
  • Se eu uso principalmente metrô para me deslocar na cidade, meu risco é mínimo, mas maior que se eu ficasse em casa o tempo todo;
  • Se eu sou homem, a minha imprudência natural tende a aumentar meu risco de acidentes, e se eu sou mulher, tende a diminuir.

E assim por diante. Esse é um tipo de análise Bayesiana, aliás! Cada nova informação que eu trago realoca as chances de cada evento. ;-)

Sempre que há algum risco envolvido em alguma ação, o ser humano busca minimizar esse risco ou proteger-se contra as consequências de sua realização. Assim levamos em viagem mais roupa de baixo que usaremos, compramos o dobro de cartuchos de tinta para imprimir o TCC e saímos de casa meia-hora mais cedo “para o caso de algo dar errado”.

Para que é que serve essa análise de risco? Ora, para um monte de coisas! Suponha que você vai construir uma estrada: que eventos podem comprometer esse projeto? Que risco cada um destes eventos apresenta? Se um destes dados riscos for muito grande, a prudência recomenda reter o projeto. E a mesma idéia se aplica a seguros e empreendimentos variados.

O Negócio

Em algum momento alguém sacou que essa necessidade representava uma oportunidade de negócios. É como um jogo de azar: aposto um tanto de dinheiro que nada de errado vai acontecer contigo. Se eu ganhar a aposta, eu mantenho o dinheiro. Se eu perder, eu banco o seus prezuíjo até um certo tanto.

Se eu for um bom apostador, isto é, se eu escolher bem as minhas apostas, eu ganho mais que perco, acumulando o dinheiro das apostas.

Se eu for um pusta pé-frio, perdendo mais apostas do que eu consigo bancar, vou à falência rapidinho e páro logo com isso.


Consta na Wikipedia que as primeiras compras de garantias datam do Século IV, e cobriam o transporte marítmo de bens.

O assunto é deveras fascinante e merece um bom estudo, pois ajuda a entender como chegamos até aqui. Aliás, se você tiver curiosidade, vale a pena estudar também a origem dos bancos. A idéia sempre foi a mesma: ser um ponto em que os recursos de vários pequenos investidores eram somados para alavancar negócios que, individualmente, nenhum deles conseguiriam. Os exemplos mais bacanas são as caravanas de comércio e a agricultura. Ou seja, sem bancos não temos crescimento econômico…


Divago, perdão.

Uma vez que chegamos neste ponto, tudo se torna uma questão matemática: acumular dados e fazer contas até chegar em valores que balanceiem o risco com o custo. Existe um profissional que estuda as técnicas para estimar esses riscos:


Atuário (…) é o (…) especialista em avaliar e administrar riscos.

(…) Este profissional é capaz de criar modelos matemáticos para planos de investimento e amortização, para seguro social e privado; efetuar cálculos de probabilidades de eventos, avaliar riscos, fixar valores de prêmios de seguro ou de indemnizações e, ainda, trabalhar em outras áreas coligadas ao tema de risco.1


Inteligência de Negócios Aplicado à Seguros

Quem já leu algum dos meus posts sobre Data Mining, como este aqui ou até mesmo o post que abre a série, já detectou nesta definição as palavrinhas mágicas “modelo matemático”.

E o que é que eu sempre digo sobre BI? Que, no fundo, Inteligência de Negócios é a aplicação do Método Científico para entender como a organização funciona e como extrapolar seu futuro a partir do seu passado. Isso é feito por meio de – tchan! tchan! tchan! tchaaaaan! – modelos matemáticos. Conclusão? Cálculos atuariais, que estimam riscos, são uma parte de BI. Mesmo que oficialmente ninguém afirme isso, não dá para escapar à essa conclusão: se A=B e B=C, então A=C, ponto.

Essa relação nos leva a uma outra conclusão: o analista de Data Mining que constrói modelos atuariais é um atuário. Como Analista de Data Mining hoje em dia é chamado de Cientista de Dados (pfff…) então um atuário é um tipo de Cientista de Dados!


Você pode querer argumentar que um Cientista de Dados pode ser um atuário, mas um atuário não é, necessariamente, um Cientista de Dados porque não traz todo rol de habilidades com dados habitualmente associado a Cientistas de Dados (=Analistas de Data Mining.) É, eu concordo com isso. Talvez a coisa que melhor separe as duas categorias, Analistas de Data Mining e Atuários, é que o segundo só faz cálculos atuariais, enquanto que o primeiro faz muito mais coisas – só que nada impede que ambos cresçam até englobar um o conhecimento do outro. ;-) Filosofia de mais, de volta à vaca fria!!


Ou seja, Atuária e BI são, essencialmente, uma categoria única. BI engloba muitas outras coisas, assim como Atuária, mas na hora de se aplicar uma ou outra, o rol de ferramentas é praticamente o mesmo.

Para uma visão mais geral, consulte esta página da Wikipedia. Ali você tem uma lista de várias das aplicações da Atuária. Eis uma pequena amostra:

  • Health insurance
  • Life insurance
  • Net premium valuation
  • Stochastic modelling
  • Asset liability modelling
  • Property insurance
  • Casualty insurance
  • Vehicle insurance
  • Ruin theory
  • Reinsurance
  • Investments & Asset Management
  • Dividend yield
  • PE ratio
  • Bond valuation
  • Yield to maturity
  • Cost of capital
  • Derivatives
  • Pensions
  • Stochastic modelling
  • Enterprise risk management

(Desculpem não traduzir – muito trabalho para bater o Google…)

A Solução

E que ferramentas são essas?

Ora, BI tem duas ferramentas, só:

  • Data Mining;
  • Data Warehouses.

Uma boa ferramenta de Data Mining, como SAS Enterprise Miner, e um bom projeto de DW bastam para aplicar todas as técnicas. Eventualmente, uma empresa desse ramo pode precisar comprar dados externos para poder desenvolver certos modelos matemáticos.

O próprio SAS possui pacotes prontos para esse tipo de problema – vem daí, aliás, o tema da série: soluções clássicas, soluções que de tanto serem aplicadas, acabaram empacotadas como produto.

Clicando aqui você pode conhecer a solução SAS para seguros. Já este link dá um panorama mais geral sobre as soluções baseadas em Atuária.


Note que qualquer ferramenta que faça as contas já serve. Excel, por exemplo, bem usado, pode fornecer resultados comparáveis ao próprio Enterprise Manager. O que acaba mudando, de uma ferramenta para outra, é a facilidade e praticidade da coisa.


Conclusão

Atuária é a ciência de estimar riscos. Seguros e Gerenciamento de Riscos são dois ramos de negócios assentados nessa tecnologia.

Por sua vez, BI engloba toda habilidade de acumular e analisar dados de uma organização para melhorar o negócio. Logo, Atuária e BI se interpõem, e ambos acabam formando parte do outro.

Nada mais natural, portanto, que exista um conjunto de ferramentas em BI desenhadas especialmente para lidar com problemas de Atuária. Esse conjunto de ferramentas é a tal da Solução de Inteligência de Negócios para Seguros e para Gerenciamento de Riscos. No miolo dessas soluções está sempre uma ferramenta de Data Mining, e os profissionais habilitados a usá-la. Ainda que não seja absolutamente imprescindível, o uso de um DW ajuda muito neste tipo de projeto.

Se você acredita que sua empresa pode se beneficiar desse tipo de solução, não tente fazer sozinho. Busque uma consultoria, um profissional do ramo, nem que seja só para se aconselhar. Arriscando-se sozinho você assume uma chance alta de obter conclusões erradas, e comprometer a sobrevivência de sua empresa. Melhor não economizar nisso, não é?


Estamos chegando ao final do ano, e este post conclui a primeira temporada da série Soluções Clássicas de BI. Gostaram? Acharam interessante? Ou um total despercício mútuo de tempo?


Considerando-se a piada da média de frangos, tenho medo de não ter valido nem pelas risadas… :-O


Essas são as mais fáceis de se mostrar e mais simples de se entender o uso, mas existem inúmeras outras soluções. Se eu conseguir aprender o bastante sobre alguma delas, eu voltarei ao tema. Duas que eu acho superlegais, mas que são relativamente complexas, é [SCM][scm_bitly], ou Supply Chain Management, e IT Capacity Planning. Quem sabe não são as primeiras da temporada dois?

Até a próxima! ;-)


  1. Extraído do verbete Atuário, da Wikipedia, em 12/12/16. 

Todo Dado É Estruturado

Trabalho na indústria de BI há 16 anos. Hoje em dia dá-se muito destaque a um tipo de dados considerados especiais, até meio místicos, como se guardassem a chave para as respostas de todas as perguntas não-formuladas. São os tais dos chamados dados não-estruturados.

Não vou debater semântica, ou nomenclatura, mas o fato é que esse tipo de dado existe desde sempre. Tanto é assim que há um campo inteiro dedicado a produzir conhecimento a partir de fontes hoje ditas “não-estruturadas”. Esse campo chama-se Text Mining, uma extensão do conceito de Data Mining. São as técnicas aplicadas em, por exemplo, soluções de análise de sentimento.

Assim como eu tenho algumas ressalvas com todo o hype em volta de BigData, também tenho minhas reservas quanto ao endeusamento desse tipo de dado. A minha bronca é que essa atitude não raro decorre de modismos, em geral carentes de significado mais concreto, cunhados a fim de encher a cabeça do cliente e ocasionalmente levá-lo a comprar alguma coisa.


Compra quem quer, deixa-se levar por modismos quem quer. Longe de mim atrapalhar a liberdade que cada um tem de se deixar convencer! Entretanto, eu não posso deixar de tocar no assunto. Encare este post como mais um argumento em um longo debate em busca da verdade. ;-)


A maior parte dos dados úteis para análises são justamente os que refletem algum processo, e por isso são capturados em sistemas transacionais ordinários. São dados que vivem em tabelas ou, no máximo, arquivos com algum layout padronizado. Já os tais dos dados não-estruturados não possuem “nenhuma” regularidade. Então tá, se sairmos desse domínio – se deixarmos os sistemas transacionais e suas tabelas padronizadas para trás – o que temos?

Vou ver um exemplo para ficar mais claro.

O Governo Federal tem a missão de gastar o dinheiro da melhor forma possível. Suponha que decidiu-se estabelecer a relação entre o atendimento do Bolsa-Família (BF) e a melhoria da educação. Isso é importante para permitir que a geração seguinte à suportada pelo BF possa almejar empregos de qualidade e melhorar de vida.

Como correlacionar esses dados? Uma opção é avaliar a relação entre demografia e os índices de escolaridade e frequência, e a cobertura geográfica do BF.

De onde virão esses dados? Dos sistemas de gestão escolar, por certo. Logo, esses dados são 100% estruturados. Estamos falando de capturar as listas de chamada, as notas, o resultado do ENEM, da Provinha Brasil, da concessão de BFs, de mapas… São todos dados estruturados. Mesmo que não venham de um único sistema, quiçá de uma única entidade, todos esses dados “vivem” em estruturas regulares. Com esses dados obtemos o conhecimento mais valioso que existe nos processos de gestão escolar.


Permitam-me colocar de outra forma: obtemos uma informação valiosa sem precisarmos de nenhum dado não-estruturado. E isso vale para a maioria do que está por aí, aguardando ser descoberto.


O dado não-estruturado serve para situações muito específicas, em condições muito particulares. É um nicho naturalmente pequeno – basta pensar quantas empresas/organizações grandes o bastante existem para puxar alguma inteligência dessas fontes, e o tamanho que essas fontes precisam ter para atribuir alguma confiança, estatisticamente falando, aos resultados.

Analiso Ergo Estruturo

Por outro lado, quais fontes de dados não-estruturadas existem por aí?

  • Textos (web e e-mail;)
  • Textos (posts em mídias sociais;)
  • Textos (documentos;)
  • Vértices de grafos (URLs – textos.)
Um punhado de dados não-estruturados.
Um punhado de dados não-estruturados.

Eu com certeza ignoro algumas outras categorias de dados não-estruturados, mas quais? Repassei a lista mas tudo que eu pensava tinha alguma estrutura mais ou menos óbvia, fixa:

  • Objetos XML: têm estrutura;
  • Transações entre empresas, como SWIFT: além de privados, têm estrutura;
  • Mapas: têm estrutura;
  • Etc…

Ora, o que é uma análise? Pode ser desde uma contagem ou uma média (quantas palavras o post possui, quantas palavras existe, em média, nos posts de cada autor?) a uma coisa mais sofisticada (qual é a chance, para cada assunto, de o autor possuir relação íntima com o dado assunto de seus textos?) Responder a essas perguntas envolve analisar frequências, distribuições, distâncias – números, números, números! Sempre precisamos quantificar em números e qualificar com uma descrição tudo aquilo que desejamos analisar.

Bom, mesmo o exemplo dado na figura 1 (e em geral naqueles elencados no início da sessão) possui alguma estrutura. Por exemplo:

  • Data e hora de publicação;
  • Ocasionalmente data e hora de criação e edição;
  • Versão (1, 2, 3… quando alguém edita o conteúdo e republica o item – doc, post etc.;)
  • Autor, e todos seus dados;
  • Tamanho;
  • Tipo de conteúdos (só texto, só imagem, mistura;)
  • Relacionamentos;
  • E, finalmente, o conteúdo em si.
O mesmo punhado de dados, estruturados.
O mesmo punhado de dados, estruturados.

Veja que, ignorando o conteúdo, podemos puxar muita coisa só olhando o restante! Dá para montar grafos diversos, por exemplo, acompanhando o timestamp e relacionamentos entre publicações em blogs e redes sociais. Dá para analisar o sentimento de um conjunto em relação a um assunto.


Análise impõe estrutura: para conduzir uma análise, os dados precisam ser estruturados de alguma forma. Se os dados não possuem estrutura, então não podem ser organizados e, imperiosamente, não permitem análise.


Logo, se os dados podem ser analisados, então eles possuem alguma estrutura. Isso gera confusão com o jargão de TI, que costuma chamar de “estrutura” um container ou padrão de armazenamento digital (isto é, que guarda os dados de uma forma mais ou menos organizada, como uma tabela, uma planilha ou um arquivo texto, representados por sequências de bytes em alguma mídia.)

Conclusão

O meu ponto é chamar a atenção para o hype em volta de dados não-estruturados. Afinal, para podermos conduzir qualquer análise é preciso poder representá-los matematicamente. Quero dizer, é preciso que eles possuam alguma estrutura, por mais incomum ou exótica que seja essa estrutura, ou por mais “escondida” que ela esteja.

Essa tabela mostra o exemplo da estrutura de dados do post em emu Facebook que aparece nas figuras anteriores:

Campo Conteúdo
Autor Fábio
Data Original 02/11/2016 20:30:00
Flag Editado Sim
Data Editado 02/11/2016 22:43:00
Conteúdo Original Há tanto sobre Big(…)
Conteúdo Editado Há tanto sendo escrito(…)
URLs https://geekbi.word(…)
Grupo Público
Curtido por Blad, Gisele
Curtido em 03/11/2016 10:15:00

Mesmo dados arquivados sob formatos exóticos (textos, e-mails, páginas web) possuem um mínimo de estrutura matemática apta a análises. Vem daí a afirmação que dá título a este post:


Todo dado (que seja útil para análise) é estruturado, de uma forma ou de outra.


Isso implica em dizer que não existem dados não-estruturados? Pode ser, tanto que esse era o título original deste post. Mas ainda não consigo afirmar isso com certeza.

Quem sabe um dia, não?

Até a próxima! ;-)

 

Data Vault: Como Usar – Errata

Meu grande amigo e co-autor do PnP, Cesar Domingos, me mandou um e-mail com duas dúvidas:

Fala Fábio,

Tudo bem?

Tô vendo uns posts seus sobre Data Vault e fiquei com dúvida em um.

https://geekbi.wordpress.com/2016/05/25/data-vault-como-usar/

Na parte do Modelo Completo, onde tem o desenho, a tabela s_l_empregados_pedidos não deveria estar linkada à tabela h_pedidos? Ou se não for na h_pedidos, não deveria existir uma tabela hub entre ela e a l_empregados_pedidos?

Fiquei meio perdido ali. Você tem algum exemplo com dados?

E uma outra pergunta. O que vai exatamente no campo Record Source? O nome da tabela de origem?

Abraços,

Cesar Domingos
Vida corrida de Cesar Domingos
Consultor Linux e BI
LPIC-3 e RHCE

Fui ver, e ele tem razão. Naquele post, a função da tabela s_l_empregados_pedidos não está clara, até porque existe um erro também. Neste post completo a explicação, explicitando o que eu queria fazer e mostro uma correção possível.

O Problema

A metodologia de modelagem de dados para Data Vault define três tipos principais de tabelas: hub, links e satélites. Hubs registram conceitos de negócio, como vendedor, cliente e produto. Links registram relacionamentos entre conceitos de negócios, ou seja, entre hubs. Por exemplo, se um vendedor cuida de um certo cliente, então podemos definir um link entre os hubs de vendedor e cliente.

Satélites guardam os atributos de hubs e links. Se o cliente é um hub, um satélite de cliente contém, por exemplo, seu endereço, sua data de nascimento, sua ocupação e outros dados.

A figura da qual o Cesar falou mostrava dois hubs, empregados e pedidos, e um link entre os dois:

As tabelas combinadas no modelo.
As tabelas combinadas no modelo.

Além disso, ela também mostra um satélite para hub empregados, e um para o link empregado-pedido. E isso está errado!

Sim, veja: satélites contêm atributos de um hub ou de um link. A tabela s_l_empregados_pedidos é um (s_)atélite pertencente ao (l_)ink empregados_pedidos. Mas olhe que atributos esse satélite tem:

  • data_pedido
  • pagamento_tipo

De quem são esses atributos? Data do pedido é um atributo do… pedido. E tipo de pagamento? Também! Ora, se são atributos do pedido – e não da relação entre pedido e vendedor – então esse satélite é do hub pedido, e não do link empregado-pedido! Por isso esse satélite está errado.

Para estar correto ele precisaria conter algum atributo da relação, do link. Esse modelo não é um bom caso para um exemplo de satélite de link, que era a minha intenção original.

A Solução

A mensagem que eu queria passar precisa de um modelo ligeiramente diferente:

O modelo corrigido.
O modelo corrigido.

Agora temos um novo hub, cliente. Poderíamos ter seu respectivo satélite, mas seria redundante, pois já temos um exemplo de satélite de hub.

Nesta empresa, cada cliente é atendido por um único vendedor ou gerente, que é o dono da conta, como acontece em um banco, por exemplo. Em um banco, todo cliente possui um gerente. Esse relacionamento aparece como um novo link, entre clientes e empregados.

Como dizia uma propaganda de banco, o tempo passa, o tempo voa. Um gerente muda de agência, outro muda de emprego, entram novos gerentes, chegam clientes de outras agências, clientes vão embora… Conforme o tempo passa, a relação cliente-gerente muda. Pior ainda: pode ir e voltar, ou seja, um cliente pode estar com um gerente hoje, outro daqui um mês e daí no ano seguinte volta a estar sob seu primeiro gerente.

O link não possui data de validade. Ele não possui nada além de data de criação e sistema de origem, aliás. Como, então, saber qual é o gerente atual de cada cliente? Ou que gerente teve que clientes durante um certo período?

Um satélite de link, justamente como mostrado na figura anterior, resolve essa situação: cada vez que o link sofre uma atualização, o satélite versiona sua data de validade. Resumindo:


Porque um link pode ter um satélite? Por que a relação entre dois hubs pode mudar ao longo do tempo, e a única forma de saber quais estão ativas, hoje, no sistema de origem é usando um satélite.


Evidentemente, um link pode ter outros atributos além de período de validade. Exemplo? Pense nos itens de um pedido, ou seja, os produtos que o cliente comprou naquele pedido. Esses itens são registrados no DV como um link entre o hub pedido e o hub produto. Agora, os detalhes de cada item, ou seja, a quantidade, o valor pago etc. são registrados como satélites desse link.

Record Source??

Quanto à segunda pergunta, o que vai no campo Record Source? Bom, o campo RSRC recebe o nome do sistema de origem, não da tabela. Como as tabelas, em princípio, fazem a integração dos dados, o campo indica em que sistema foi identificado aquele elemento – hub, link ou satélite – pela primeira vez. Como as tabelas hub e link são carregadas um sistema de cada vez, o campo RSRC indica, no fundo, que sistema foi carregado primeiro, já que ele não é atualizado mesmo que o campo seja encontrado em outro sistema, com o valor idêntico.

Esse campo tem um pouco mais de utilidade para satélites.

Já passei por situações em que era fundamental separar os dados dentro do satélite por sistema de origem. Foi com o Zabbix: um DV foi construído para integrar 11 Zabbixes. Como era tudo igual, tínhamos apenas uma tabela de satélite para cada item. Como o mesmo item podia aparecer em dois ou mais Zabbixes diferentes, o satélite do Zabbix 1 podia ser encerrado se o mesmo item existisse em qualquer outro Zabbix. O mesmo aconteceria com o segundo Zabbix a ser carregado e assim por diante e depois se repetindo desde o início. A única forma de resolver foi filtrando o satélite pelo RSRC, um para cada Zabbix. ;-)

Casos de Uso de Inteligência de Negócios

Inteligência de Negócios é a disciplina que busca a compreensão do funcionamento de uma organização (o conhecimento do negócio) mediante a aplicação do Método Científico. Além de insumo para aplicação do Método Científico, os dados de uma empresa prestam-se a um sem-número de funções, que podem ser realizadas por uma gama de ferramentas.

Algumas das formas de uso são notadas com maior frequência em uma organização ordinária. Vamos descrever algumas destas formas de uso de dados e ferramentas, os chamados Casos de Uso.

Caso de Uso

Um caso de uso (ou CDU para simplificar) é um modo de aplicação ou o propósito – o uso – de algo, como uma ferramentas ou uma técnica.

Como exemplo tome o caso de uso de uma panela de pressão: cozinhar alimentos a temperaturas superiores ao ponto de ebulição da água. Sempre que um alimento precisar de maior temperatura para ser adequadamente cozido, podemos usar uma panela de pressão.

Conversamente, sempre que um alimento pode ser cozido no ponto de ebulição da água, o uso de uma panela de pressão é desnecessário e pode até mesmo comprometer a qualidade do resultado.

A toda ferramenta corresponde um ou mais casos de usos com graus variados de adequação. Aplicar uma ferramenta a situações para as quais ela não possui uma adequabilidade mínima pode comprometer o resultado almejado, ou pior, pode entregar um resultado plausível enquanto oculta alguma falha intrínseca. Basta pensar no velho ditado “para martelo, tudo é prego” e imaginar que uma boa martelada pode engastar um parafuso na madeira: a qualidade da fixação será insuficiente e, mesmo aparentando estar “pregado” bem o bastante, o parafuso pode soltar-se e causar uma falha catastrófica.

Casos de Uso de Dados

Os dados produzidos nos sistemas informatizados de uma organização podem ser consumidos de várias formas e usados para várias finalidades.

Monitoração

Parte do trabalho de qualquer profissional, nos dias de hoje, é acompanhar eventos diários e responder a eles.

Entrou um novo ticket pedindo serviço? Surgiu um defeito? Um sistema sofreu pane?

Manter-se informado dos acontecimentos é parte da tarefa de monitorar o ambiente. Outra parte é examinar a situação, ou seja, os dados correntes, em busca de sinais que prenunciem o surgimento de uma situação específica. O exemplo mais banal é observar o dia no calendário: a aproximação de certas datas, que avizinham vencimentos de prazos, é uma forma de monitoração.

Algumas situações só podem ser monitoradas a partir de um conhecimento prévio, que precisa ser adquirido de antemão. Sabemos que a chance de chover aumenta quando o céu cobre-se de nuvens escuras porque tivemos a oportunidade de testemunhar a correlação entre chuva e céu nublado – com frequência o primeiro segue-se ao último – várias vezes.

Evidência

Situações surgem em que ocorrências passadas são questionadas. A forma mais prática de confirmar fatos é apresentar os dados que evidenciam o que aconteceu.

Por vezes essa evidência é direta, como um relatório de gastos ou uma lista de peças de um lote. Em outras situações a evidência é indireta. Se nenhum sistema registra a entrada do empregado em certo dia, por exemplo, e nenhum arquivo de sua estação de trabalho possui timestamp de acesso naquele dia, então é razoável supor que naquele dia ele não esteve em seu posto.

Análise

Pense no indivíduo que nunca testemunhou uma chuva na vida. Na primeira ocasião em que observar o céu escurecido – resultado da monitoração – ele não presumirá o risco maior de precipitação. Apenas depois de algumas ocorrências céu escuro/chuva é que ele poderá ser levado à concluir que a associação existe.

Essa é uma situação recorrente no funcionamento diário em qualquer organização: se não entendemos a relação entre causa e efeito, monitorar o quê? Se não temos um argumento a ser testado, provar o quê? Esse é o miolo da disciplina de Inteligência de Negócios, a que realmente agrega valor à organização ao produzir conhecimento explicitando a relação (e os parâmetros) entre causa e efeito. Essa é a mesma justificativa para erigirmos um DW, aliás.

Dados, além de servir para monitorar e para demonstrar fatos, ainda podem ser explorados e estudados em busca do conhecimento de negócio. Na minha opinião, essa classificação do uso dos dados em uma empresa explicita a separação entre os usos analíticos e operacionais.

Casos de Uso de Ferramentas de Dados

O termo genérico “ferramentas de dados” significa toda ferramenta que manuseia e/ou apresenta os dados dos sistemas informatizados de alguma maneira. Por exemplo, o próprio sistema informatizado, que produz os dados, é uma ferramenta de dados. Levado ao paroxismo, todo software é uma ferramenta de dados, já que todo software comanda uma CPU para tratar algum dado de alguma maneira. Para o propósito deste documento vamos restringir essa definição aos softwares que lidam com dados de negócio em sua forma operacional. Por exemplo, softwares que tabulam dados ou traçam gráficos.

Relatório

Uma das ferramentas mais simples para o manuseio dos dados é a exibição de listas. Esse CDU é conhecido pelo termo de relatório, pois relata, descreve, apresenta os dados. Um relatório é, por definição, uma lista de dados com rótulos nas colunas, que pode vir acompanhado de outros recursos.

Uma ferramenta de relatório pode incorporar uma quantidade de opções de apresentação, como títulos, cabeçalhos, números de páginas, gráficos ou sub-relatórios (relatórios dentro de relatórios.) Ferramentas de relatórios podem possuir alguma resposta dinâmica, como escolher o formato de saída (HTML, PDF e CSV entre outros), ou a aplicação de algum filtro em tempo de execução e até mesmo embutir URLs (links web) nos campos, tal que clicar sobre eles abrem páginas em navegadores web. Consta como tradicional a possibilidade de imprimir tais listas.

O acesso aos relatórios pode ser por meio do software instalado localmente ou via portal web e algumas soluções combinam a possibilidade de remeter um relatório renderizado diretamente para o e-mail de um usuário.

Painel de Dados

Um passo adiante do simples relatório, painéis são meios eminentemente gráficos, usados para apresentar diversas visões sobre dados em uma única área, em geral com alguma correlação entre si. Tradicionalmente associa-se à esta tecnologia a capacidade de algum tipo de interação. Por exemplo, um painel de vendas pode mudar para exibir os números por UF ao se clicar em um mapa do país.

A promessa dessa tecnologia é comunicar um volume maior de informações por meio de uma diagramação mais inteligente dos dados. Em outras palavras, um painel é a proverbial imagem que vale por mil palavras para a gestão da organização.

Análise Multidimensional

Uma ferramenta de análise multidimensional tem a capacidade de cruzar atributos em linhas e colunas, com os valores nas células resultantes desse cruzamento. Em comparação com uma ferramenta de relatório, uma ferramenta de análise multidimensional possui duas diferenças principais:

  • Exibir cabeçalhos tanto em linhas quanto em colunas, já mencionado;
  • Reorganizar a visão interativamente, com um tempo de espera mínimo.

Enquanto que ferramentas de relatórios estão limitadas a listas, que são renderizadas a partir de consultas, uma ferramenta de análise multidimensional pode criar planilhas, e respondem em segundos. Esse tipo de exploração de dados apóia processos de investigação de causa-raiz (ir de uma visão macro a uma visão micro, até achar a causa de um evento) e de entendimento de correlações entre os dados.

Se relatórios e painéis de dados sobressaem-se na apresentação dos dados, ferramentas de análises multidimensionais ajudam a descobrir o quê é interessante apresentar.

A sigla tradicional para análise multidimensional é OLAP, abreviação em inglês de Processamento Analítico On-Line.

Além da organização dos dados e da interatividade, ferramentas OLAP ainda oferecem controle sobre os níveis e o tipo de agregação. Por exemplo, podemos criar uma visão multidimensional mostrando, nas colunas, as UFs, e nas linhas os produtos. Cada célula dessa planilha indica, portanto, o total de venda de um certo produto numa certa UF. Podemos trocar UF por região, e a quantidade de colunas passará de 27 a 5. Mas também podemos manter a UF e fazer uma quebra por região, exibindo simultaneamente o UF e região para cada valor. Uma linha de células no topo (ou no fundo da planilha) pode, então, mostrar as agregações por região.

Data Mining

Esse pode ser considerado uma família de casos de uso mais do que um único CDU, cujo propósito genérico é apoiar o desenvolvimento de algum modelo matemático que “explique” os dados.

Ferramentas desta categoria costumam oferecer, entre outros recursos:

  • Estatísticas básicas: média, mediana, variância etc.;
  • Estatísticas avançadas: distribuições, ajustes de curvas, testes de regressão e hipóteses, por exemplo;
  • Análises sofisticadas, como Análise Baeysiana, clusterização, grafos, previsores como ARIMA e HoldWinters.

Ao contrário das outras ferramentas, as que implementam estes CDUs são voltadas para um público específico, dotado de habilidades específicas no tratamento de dados e construção de modelos empíricos. O nome corrente do profissional apto a aplicar este tipo de ferramenta é “cientista de dados”, mas já foi tratado por analista de data mining ou simplesmente “o estatístico”.

Os resultados de projetos para este caso de uso costumam se apresentar como algoritmos ou equações que, devidamente implementadas nos sistemas transacionais, podem operar decisões autônomas, sem supervisão humana. Um exemplo clássico dessa situação são as ofertas de crédito pré-aprovado exibidas por ATMs.

E o Pentaho?

A suite Pentaho implementa casos de uso de dados através de alguns casos de usos de ferramentas de dados.

O Pentaho oferece a possibilidade Monitorar, Reportar e Analisar dados.

Entre as ferramentas disponíveis na suite temos as capacidades de relatório (Report Designer), Painéis (BA Server) Análises Multidimensionais (Mondrian) e Data Mining (Weka.)

Cada CDU de ferramenta é implementada por um software específico. Cada CDU de dados é resultado da combinação de uma ou mais ferramentas, em geral com o BA Server no centro.

Conclusão

Os casos de uso de dados explicitam uma separação que eu fiz no primeiro post de 2016: o uso dos dados pode ser estratégico ou operacional. O CDU de Dados Análise é o único que realmente se encaixa em BI. Os outros dois podem consumir dados tanto de um DW quanto de bases transacionais, vivas. O CDU de Análise, não. A única forma de determinar a relação de causa e efeito é usando um DW e o Método Científico.

Olhando as demandas por dados que toda empresa experimenta através do ponto de vista de CDUs, podemos notar que a Suite Pentaho é uma solução completa, pois permite implementar todos os CDUs de dados através de todos os CDUs de ferramentas.

Mesmo que pareça o contrário, a intenção do post de hoje não era tecer loas ao Pentaho. Nunca escondi que sou fã da plataforma e se um dia eu decidir rasgar ceda para o Pentaho, eu o farei escancaradamente, sem pudores. Este post nasceu de um relatório que eu terminei hoje, que examinou a adequação de outra ferramenta, o [Spotfire][spotfire_bitly], à comunidade de usos e necessidades de certa empresa real. É justamente o fato de ser baseado em um relatório autêntico, de uma empresa real, que deu esse tom mais austero, mais academicista ao post. Espero que isso não espante vocês. Semana que vem volto ao modo galhofa de sempre. ;-)

Lamentavelmente para essa companhia, o Spotfire não possui uma adequabilidade tão grande às necessidades dela quanto outras ferramentas – como SAS e Pentaho – ainda mais em um patamar de custo benefício significativamente desvantajoso para o Spotfire.

Até a próxima. ;-)

Nadando em Lagos de Dados

Para escrever meu primeiro post sobre Data Lake eu pesquisei sobre o assunto. Abri o Firefox e saí fuçando o mundo com o Google. Achei alguns artigos interessantes, até que um deles matou o assunto e fiz o post. Eu peguei o restante das pesquisas, dei uma passada d’olhos e, como não achasse nada muito divergente daquilo, descartei.

Limpando meus papéis eu achei um dos artigo que eu separara para ler com mais calma, chamado – que criativo! – DataLake, publicado pelo Martin Fowler em pessoa, em fevereiro de 2015.


Ele se autodefine como “author, speaker, and loud-mouth on the design of enterprise software”, ou em bom português, “autor, palestrante e tagarela sobre o design de software corporativo”.

Eu sou um fã de seu trabalho e já li muitos livros dele e da série Signature, a maioria através Addison-Wesley. Ele é muito bom, e é preciso que se destaque isso: em desenvolvimento de software. Ele nunca publicou ou palestrou sobre BI. O mais perto que ele chegou foi um livro sobre NoSQL escrito em parceria e, pelo visto, este artigo. Por mais que eu o respeite em seu campo, não posso ter o mesmo sentimento quando ele atua fora de sua área. Neste caso o que ele escreve está mais para uma visão multidisciplinar e informada que um comentário de especialista no assunto.


E não é que tem ali uma coisa que eu não tinha notado? Algo que parcialmente redime o conceito de Data Lake e confirma a importância de Data Vault. Vou pegar o assunto do começo, desenvolver o tema e, na conclusão, mostro o que me escapou antes. Acredito que isso vai ajudar a entender melhor tanto o conceito e a utilidade de um Data Lake, quanto a verdadeira natureza de ambos – Data Lake e Data Vault.

Despensa, Cozinha e Salão

Não deixe de ler o artigo, que é muito bem escrito e é do próprio Martin Fowler. Ele começa:

Data Lake é um termo que apareceu nesta década para descrever um importante componente do encanamento analítico no mundo do Big Data. A idéia é ter um único depósito para todos os dados crus que qualquer um na organização possa precisar para análise. Normalmente o povo usa Hadoop para trabalhar os dados no lago, mas o conceito é mais amplo que meramente Hadoop.

Eu saí pulando pelo artigo, da primeira vez, e do meio dele achei o que eu queria ouvir (ler!):

O Data Lake não deve ser acessado diretamente com frequência. Pelo fato de os dados serem crús, você precisa de um bocado de habilidade para tirar qualquer sentido deles. Você tem relativamente pouca gente que trabalha no Data Lake, e conforme eles descobrem visões úteis genericamente, eles podem criar Data Marts cada um do qual com um modelo específico para um único bounded context. Daí, um número grande de usuários podem tratar esta “loja a beira-rio” como uma fonte de dados fidedigna para aquele contexto.

No original: The data lake shouldn’t be accessed directly very much. Because the data is raw, you need a lot of skill to make any sense of it. You have relatively few people who work in the data lake, as they uncover generally useful views of data in the lake, they can create a number of data marts each of which has a specific model for a single bounded context. A larger number of downstream users can then treat these lakeshore marts as an authoritative source for that context.

Neste ponto eu parei de ler e fui escrever aquele post. Quando eu retornei e reli este artigo inteiro, eu notei a primeira relação desta visão de Data Lake com um Data Vault: assim como o proposto aqui por Fowler, um Data Vault não é uma estrutura para acesso direto. Os dados de um DV precisam ser refinados para uma área de apresentação, para aí então serem consumidos. Usando a metáfora de restaurante do Kimball, um Data Vault é a despensa, e tanto o DV quanto o Data Lake precisam passar por uma cozinha que deve preparar os dados para consumo pela clientela.

Aff… Medo de perder o contato com a realidade com tantas metáforas… Enfim, em frente.

Uma Rosa por Qualquer Outro Nome

Não bastasse essa semelhança, existe um outro conceito amarrado ao Data Vault que aparece no post do Fowler: o bounded context, que corresponderia a um conceito meio obscuro em DV, o Unit of Work.

Primeiro, o que é bounded context? A imagem abaixo dá um exemplo:

Ilustração do conceito de contexto limitado - bounded context.
Ilustração do conceito de contexto limitado – bounded context.

Agora a definição de bounded context:

Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD‘s strategic design section which is all about dealing with large models and teams. DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.

Ou, em tradução livre, “contexto limitado é um padrão central em Domain-Driven Design. É o foco da estratégia de design, que mostra como lidar com grandes modelos e equipes. DDD lida com modelos grandes dividindo-os em diferentes contextos limitados, sendo explícito em seus inter-relacionamentos”.

Em outras palavras, o tal do “contexto limitado” que o Fowler usa para dar sentido aos dados consumidos do Data Lake é similar ao conceito de orientação a assunto, subject oriented, do Inmon e [Kimball][dmmanifesto_bitly]:

“(…)what a data warehouse is – a subject oriented, nonvolatile, integrated, time variant collection of data in support of management’s decisions(…)”

Como o próprio Linstedt (o criador do Data Vault) insiste na necessidade de um área de apresentação de dados, tanto o conceito de “orientação por assunto” ou “limitação de contexto” se aplicam ao Data Vault! Mas há algo mais: existe um conceito pouco mencionado chamado Unit of Work (UoW), ou “Unidade de Trabalho”.

Conceito de UoW ilustrado: cada circunferência representa uma "unidade", que se integra a conceitos vizinhos.
Conceito de UoW ilustrado: cada circunferência representa uma “unidade”, que se integra a conceitos vizinhos.

Eu revi os livros e fiz uma busca pela Internet, mas não achei nada definitivo sobre o assunto. Este post foi feito por um dos alunos do Hans Hultgren, que parece ter sido o único a avaliar o conceito do ponto de vista de modelagem. Isso seria a definição de UoW:

  • A Unit of Work defines a correlated set of data;
  • A Unit of Work keep things together;
  • A Unit of Work establishes consistency between arriving data and data stored in the Datavault links;
  • UOW should be consistent with the (Enterprise wide) business keys.

Resumindo e traduzindo, traduzindo e resumindo, uma Unidade de Trabalho segundo Hans Hultgren é:


Um conjunto de dados correlacionados entre si, que faz sentido apenas quando estão juntos e representam aspectos do negócio.


Nest link e neste outro link esse conceito aparece de novo, mas sempre jogados, sem aprofundamento.

Então temos três conceitos:

  • O clássico subject oriented, da área de DW;
  • O bounded context herdado da área de desenvolvimento de sistemas;
  • O misterioso Unit of Work, visto em textos de Data Vault.

E todos eles querem dizer praticamente a mesma coisa: um conjunto de dados relacionados entre si, que representam a realidade da organização tal como foi capturada pelos sistemas informatizados.

Romeu & Julieta. Quê?! Shakespeare de novo, uai! Peguei gosto. :-)
Romeu & Julieta. Quê?! Shakespeare de novo, uai! Peguei gosto. :-)

Esta bela imagem foi retirada da Wikipedia.

Juliet:

‘Tis but thy name that is my enemy;
Thou art thyself, though not a Montague.
What’s Montague? It is nor hand, nor foot,
Nor arm, nor face, nor any other part
Belonging to a man. O, be some other name!
What’s in a name? that which we call a rose
By any other name would smell as sweet;
So Romeo would, were he not Romeo call’d,
Retain that dear perfection which he owes
Without that title. Romeo, doff thy name,
And for that name which is no part of thee
Take all myself.

W. Shakespeare, Romeu and Juliet

Portanto temos mais um tema em comum entre a visão de Data Lake de Martin Fowler e os conceitos de um Data Warehouse: o conjunto de dados correlacionados entre si.

Mesmo Assim…

… Fowler comete alguns equívocos:

  • Ele afirma que modelar o dado na entrada é um beco sem saída. De fato, usando modelo dimensional ou a terceira forma normal, não há solução possível. Cedo ou tarde esses modelos abrem o bico e quebram. Eu já discuti isso aqui e a conclusão foi justamente que um Data Vault supera essa limitação;
  • Ele diz que qualidade de dados é um problema, primeiro porque pode ser difícil equalizar a qualidade entre fontes diversas, e depois porque Data Mining (ele não usa esse termo, mas é disso que ele fala) precisa dos dados sujos. Ele tem razão e está errado nos dois casos, pois um modelo dimensional, que é feito para apresentação, guarda dados limpinhos e cheirosos, mas não um Data Vault. Um DV guarda 100% dos dados tal como vêm dos sistemas de origem, tanto que uma das premissas é que possamos reconstruir o estado do sistema de origem usando o DV e ter 100% de auditabilidade;
  • Aceita que o sistema de origem pode e deve mudar, afirma que o Data Lake deve guardar tudo e nunca apagar nada, mas deixa em aberto como gerenciar a associação entre as diversas capturas ao longo do tempo e a variação de esquema no sistema de origem. Quer dizer, até entende essa necessidade – uma coisa básica em todo DW – mas não tem idéia de como deve ser feito. Apesar de um modelo dimensional e um na 3NF poderem assimilar essas mudanças, um Data Vault é a única modelagem que aguenta.

E, vamos reconhecer, ele diz uma coisa muito muito bacana: You should use a data lake for analytic purposes, not for collaboration between operational systems. Ele afirma que trocas de dados transacionais entre sistemas devem ser feitas usando tecnologias como chamadas HTTP RESTFul e não via DW/DL/WH(atever). Finalmente! Acredite se quiser, tem gente que vê essas tecnologias de BI/DW como respostas para toda e qualquer necessidade. Absurdo! Mais um ponto para o Sr. Fowler.

Conclusão

É isso que conseguimos quando pegamos profissionais inteligentes, altamente gabaritados e humildes1 como Martin Fowler. Ele conseguiu enxergar na definição do James Dixon, da Pentaho, um componente do cenário de análises de dados de uma organização. Até então, eu via no conceito Data Lake apenas um departamento de marketing forçando a barra para vender software.

Mas o resultado final do post do Fowler é muito maior que seu conteúdo:

Data Lake Data Vault
Dados crús Dados crús
Precisa destilar para consumir Precisa destilar para consumir
Context bounded Subject oriented

PQP DE RODINHA!!!

O que o artigo dele coloca é de uma obviedade cristalina, e por isso mesmo nós, gente comum, deixamos passar:


DATA LAKE = DATA VAULT


Só o gênio dele para trazer essa relação à tona.

Então, da próxima vez que aventarem um Data Lake do seu lado, responda: “show! me dê o curso do Linstedt, o Wherescape e vamos começar!”

;-)


  1. Para mim é inconcebível um cara da área dele falar sobre outro assunto com tanta propriedade sem ter estudado e se consultado com um monte de livros e pessoas e ter ouvido essas pessoas. A lista de agradecimentos dele, ao final de seu artigo, reforça minha certeza. 

Full Metal BI Itch

Outro dia assisti um filme de SciFi que eu adorei, No Limite do Amanhã, ou Edge of Tomorrow no original em inglês. (Clique aqui para ver o trailer.)1

Nele o herói “ganha” o poder de resetar o dia, ativado pela morte. Assim, cada vez que ele morre ele volta para o início de um certo dia – sempre o mesmo, sempre na mesma hora. Como o dia recomeçou, as coisas se repetem, sempre as mesmas, desde que ele tome as mesmas decisões. Logo ele percebe isso: os eventos futuros mudam em função das ações dele.

Por exemplo, na primeira “vida” ele é emboscado pelo inimigo logo que chega na praia. Na segunda, ainda sob o choque de ter morrido pela primeira vez, ele morre no mesmo lugar. Na terceira vida, quando ele chega na praia ele já sabe onde o inimigo vai estar, e acerta um tiro em cheio… e sobrevive! Apenas para morrer segundos depois, de novo, e reiniciar o dia pela quarta vez.

E assim ele vai: a cada vida que ele “revive” ele já sabe onde falhou da última, e avança mais um pouco.


Agora que eu parei para pensar um pouco, exatamente como em um video-game!


Amei aquele filme. Adoraria pode esquecê-lo só para poder vê-lo de novo e sentir a mesma emoção que eu senti da primeira vez.

E o que ele tem a ver com BI?

Guenta as pontas aí, já vou amarrá-las. Antes, um pouco sobre…

Técnicas de Garimpagem de Dados

Se você ainda não leu, leia. Esse deve ser o livro de BI mais de BI que existe:

O livro de BI mais de BI que existe. Leia!
O livro de BI mais de BI que existe. Leia!

Em sua introdução ele explica uma coisa chamada “ciclo virtuoso do Data Mining”, na minha tradução livre:


A promessa do data mining é encontrar padrões interessantes dormentes em todos esses bilhões e trilhões de bits jazendo em memórias computacionais. Meramente encontrar esses padrões não é o suficiente. Você deve responder aos padrões e agir sobre eles, em última instância transformando dados em informações, informações em ações e ações em valor. Esse é o ciclo virtuoso do data mining, resumidamente.


Capítulo 1, páginas 9 e 10 da terceira edição física, ou locação 676 para quem tem o livro no Kindle.

Acho que não preciso interpretar o que ele disse, não? É muito óbvio, certo?

Se é tão óbvio, seu projeto de BI deve estar fazendo, não?

Ah, não estão fazendo porque seu projeto é de Inteligência de Negócios, não de Data Mining? Entendi. ;-) Vamos ver o início do capítulo 3, então?

O que é que pode dar errado, não é mesmo?
O que é que pode dar errado, não é mesmo?

Este capítulo do livro vai esmiuçar um problema de Data Mining em suas partes e aspectos gerais e comuns entre várias técnicas. Não vou traduzir tudo que está escrito aqui, exceto por este trecho:


Data Mining is a way of learning from the past in order to make better decisions in the future.


Traduzindo mais ou menos ao pé-da-letra:


Garimpagem de Dados é uma forma de aprender com o passado a fim de tomar melhores decisões no futuro.


The Ultimate Past is The Future!

Vamos voltar ao filme: a cada vez que o herói morre, ele volta para o início do fatídico dia. Naquele momento, o futuro ainda não aconteceu mas, na cabeça dele, já. Ou seja, para ele, o passado é uma história que já aconteceu, e está para se repetir. Ele pode, portanto, usar o que aprendeu na sua “vida anterior” para tomar melhores decisões… no futuro!


Loucura, não? Filmes de Ficção Científica com viagem no tempo são mesmo de dar nós nas nossas cabeças. Enfim, adiante.


A esta altura acho que é impossível você não notar a ligação entre Data Mining/BI e o filme. Falam da mesma coisa!!

Isso não acontece na vida real, claro, mas… E se pudesse acontecer? E se você pudesse voltar um ano? O que faria? Mandaria alguém embora? Cancelaria uma venda ou faria mais pedidos de matéria-prima? Ou faria tudo igual, de novo?

Você há de concordar comigo que, se pudesse mesmo voltar um ano, muito provavelmente faria alguma coisa diferente. Duvido que você não tenha um único arrependimento sequer. Não? Mesmo? E o dólar?

A-há! Agora percebeu, né? Se pudesse voltar um ano, saberia quando comprar e vender moeda estrangeira e faria uma grana fácil!

Curiosamente, esse poder de “prever o futuro” existe hoje, mas raros usam-no. Quem dá a uma empresa o poder de prever o futuro é justamente Data Mining, em particular, e Inteligência de Negócios, em geral!

Claro que não é possível prever, com exatidão, o valor que o dólar vai ter amanhã, ou semana que vem, ou… Não se trata disso. Se trata de, sabendo como um negócio funciona, bolar uma equação matemática – um modelo matemático – que ajude a calcular as chances de determinadas situações acontecerem.

Daí, baseados nesse modelo, que é a informação tirada dos dados, podemos tomar decisões com chances melhors de sucesso. Evidentemente não é uma decisão garantida, mas entre optar por um caminho ao invés de outro por pura intuição, ou fazer uma escolha embasado no que já aconteceu, obviamente preferimos apostar no que já vimos acontecer.

O arriscamos no cara-ou-coroa, ou apostamos em algo mais sensato.

Odd Squad

Um bom exemplo de como Data Mining age sobre nossas decisões pode ser vista no seriado infantil Esquadrão Bizarro, episódio “Undercover Olive”.

Sem entrar nos detalhes desse seriado, que é divertido pra chuchu, a história é simples: os vilões roubaram o mapa para o quartel-general dos mocinhos – o tal Esquadrão Bizarro – e vão presenteá-lo a quem vencer o torneio de jan-ken-po do mal. Para impedir que esse mapa caia nas mãos de qualquer vilão, o Esquadrão Bizarro decide mandar uma agente, disfarcada (undercover) para participar do torneio e ganhar o mapa. Eles contam com uma vantagem: Oscar, cientista do grupo, analisou torneios anteriores e fez a contagem de cada movimento (pedra, papel ou tesoura) de cada vilão. Assim, quando a agente Olívia disputa um jogo, o Oscar “sopra” por rádio qual opção ela deve fazer para ter a maior chance de vitória.

O Esquadrão Bizarro: Oscar, Srta. O, Otto e Olívia.
O Esquadrão Bizarro: Oscar, Srta. O, Otto e Olívia.

No começo é fácil: a maioria dos vilões tem algum padrão, e eles usam esses padrões para ganhar. Mas quase no fim aparece um vilão que é aleatório! Ele sempre usa quantidades praticamente iguais de cada movimento, aleatoriamente. Não existe escolha mais provável, e a equipe fica em uma sinuca de bico: chutar qualquer coisa, e arriscar, ou se agarrar ao método que usaram até ali e fazer um chute calibrado?

É como Data Mining: pode ajudar muitas vezes, mas existe sempre o risco de errar pois não é uma previsão exata.


O Esquadrão Bizarro é um programa para crianças, que usa aquele fino humor britânico. É praticamente um Dr. Who para crianças, e usa uma pancada de clichès. Oscar, o cientista do Esquadrão, é obviamente inspirado no Q, o cientista do MI:6, das histórias do James Bond. O sistema de tubos é uma interpretação infantil dos teleportes de Star Trek, e assim por diante. E tem as galinhas-laser, uma birutice que não remete a nada, só piração mesmo. ;-) Meu filho de sete anos (e eu) adora(mos), mas o de dez acha uma chatice.


Ciclo Virtuoso do Conhecimento

Apesar de o livro tratar de Data Mining e por isso usar a expressão Ciclo Virtuoso do Data Mining, na minha opinião o correto seria falar Ciclo Virtuoso do Conhecimento ou Ciclo Virtuoso da Inteligência de Negócios, já que não é a garimpagem de dados que eleva a rentabilidade da empresa, mas sim o conhecimento gerado por meio de um processo de Data Mining que provê as melhorias.

Do início do terceiro capítulo, eis o ciclo:

  1. Identificar o problema;
  2. Transformar dado em informação;
  3. Tomar uma ação;
  4. Avaliar o resultado.

Auto-explicativo, não?

Conclusão

Comprar ferramentas, montar DWs, entregar dúzias de dashboards, etc. etc. etc. são ações tidas como “de BI”. São todas vazias, inúteis e até um desperdício de dinheiro se elas não forem construídas dentro do Ciclo Virtuoso do Conhecimento, no qual todos esses projetos e ferramentas são aplicados na construção de conhecimento, que depois é usado para tomar uma ação. Sem aplicar o conhecimento obtido em uma ação concreta, todo esse esforço terá sido desperdiçado, terá sido em vão.

Volto a frisar:


Se sua empresa não tem um problema para resolver, então não precisa de BI.


E se tem um problema, não começe comprando uma ferramenta bacana, ou subindo um projeto de “Data Lake”, ou coisa que o valha. Não.

Comece pelo começo: identifique o problema.

E sempre tome uma ação. Ou você vai viver todas as suas vidas repetindo os mesmos erros e morrendo no mesmo lugar.

Está sentindo essa coceira por BI?

Aquilo não é uma espada, é uma hélice de helicóptero!
Aquilo não é uma espada, é uma hélice de helicóptero!

Até a próxima! ;-)


  1. Há uma ligação entre o título do post e o filme. Assista-o e descubra. ;-) 

Santa Inquisição, Batman!

Um ex-aluno mandou um e-mail com uma pergunta simples, fácil até:


Olá professor como vai?
Fui seu aluno da última turma da 4linux de Pentaho e estou interessado em
usar o PDI como webservice e também em usá-lo para fazer stream de arquivos.
Você tem alguma referência sobre isso?


Uau, eu ministro esse curso há 7 anos e sempre aprendo coisas novas com meus alunos! PDI para stream? Quem pensaria nisso?

E porque ele pensou? Bom, eu respondi:


Vou bem, obrigado, e você? Tudo em riba? :-)

O PDI, especialmente combinado com um ESB ou mesmo com o BA Server, pode se tornar um provedor de webservices. Existe literatura sobre isso aqui e aqui.

Agora, sobre streaming é mais complicado. Já vi um exemplo de ler uma stream contínua do Twitter, mas nunca ouvi falar de servir streaming com o PDI. Procurei um pouco, mas não vi nada…


Só que não é assim que funciona. Veja, ninguém chega a um médico e pergunta “doutor, o ácido acetilsalicílico pode ser usado contra angina?”

Meu complemento:

Qual é, exatamente, seu caso de uso, sua necessidade?

E veio a resposta dele:


A questão do stream seria para transmitir arquivos entre servidores. Pensei em um webservice em C# que seria consumido pelo PDI, que enviaria arquivos através dessa sessão! O que acha? Ou usar um daqueles componentes de post para tentar enviá-los! Não sei bem ainda como pensar.


WTF?! Se você está coçando a cabeça, imagine eu.

O que eu consegui entender dali foi que existe um problema e ele imaginou que passar um arquivo por streaming resolveria esse problema. Note que já fomos do “dá para fazer X com Y?” para “preciso fazer Z, mas não sei bem como”.

Minha resposta:


Veja, transferir arquivos é o que você quer fazer. A questão é: que problema você resolve ao fazer isso? Qual é a “dor” que te motivou a buscar esse “remédio”? ;-)

É que, devido às normas de segurança, eu não posso usar métodos normais como compartilhamento entre máquinas ou sftp. Esses arquivos serão transmitidos pra outro servidor e redirecionados por email! Voce tem alguma outra sugestão? Eu pensei em stream porque lembrei daqueles servidores do Kazzar de transferência de música! A ideia era transmitir via stream e da memória mesmo, do outro servidor, passar por email.

É muita viagem? Heheheh


Sim, meu caro aluno, bastante! :-D Mas eu admito que foi muito criativo.

Notaram como agora estamos mais perto do problema, mas ainda não chegamos lá?

Pois foi o que eu disse:


Estamos chegando lá!

Pelo que você contou, o problema que você tem em mãos é resolvido com a transferência de arquivos, que não dá para ser feito por métodos mais ordinários, simples. Que problema é esse? Que necessidade é essa, que vai ser resolvida pela transferência de arquivos?

Transferir os arquivos, em si, é só a operacionalização da solução, não a solução do problema. O problema não é “como transferir arquivos”, mas sim o que requer que arquivos sejam transferidos.

Confuso? Vai melhorar, apenas pense um pouco mais. ;-)


Eu estou editando nossa correspondência para ficar mais clara e sucinta, mas confesso que eu mesmo não tenho bem certeza do que eu queria dizer naquele final… Enfim… ;-/

O fato é que surtiu efeito:


A necessidade é a seguinte professor!

Estou montando o BI aqui na empresa e temos muitos requisitos de segurança devido à norma PCI1.

Preciso prover relatórios por e-mail, o que é muito tranquilo de se fazer com Jobs e Transformations do PDI. O problema é que os arquivos serão gerados em uma máquina “interna”, que tem acesso ao banco de dados, mas essa máquina não pode falar com o servidor de e-mail, que está em um servidor “externo”, com acesso à Intranet.

A solução é enviar os arquivos de relatórios renderizados para um servidor intermediário, que daí os enviará por e-mail. Seria fácil se pudesse usar SFTP (que inclusive é um componente PDI), mas ainda não consegui a liberação para isso.

Por isso a ideia do stream: eu controlaria a transmissão do webservice a partir do “lado de fora”, onde montaria o e-mail com anexo para então enviar aos usuários.


U-la-lá! Envio de relatórios por e-mail, prejudicado por causa do bloqueio da rede por conta de normas de segurança! ESSE é o problema.

Meu comentário:


Ah! Agora sim! :-) Esse é o problema.


Foi o que eu disse…

No fundo o caso dele é uma situação complicada mais por conta da norma PCI1 que dos dados ou da tarefa em si. Na verdade, e se você ler a norma PCI vai entender isso, provavelmente o PDI vai poder fazer pouco por ele. É uma questão mais de administração e aderência a regras que ferramentas em si.

Por Quê Até Sangrar a Língua

O que eu queria trazer para divir com vocês era um caso real da dinâmica que rola em todo processo de levantamento de requisitos em BI. O mesmo ocorre em outros cenários, mas em BI isso é crítico: o cliente chega pedindo a receita do remédio para ele ir até a farmácia, comprá-lo e tomar sozinho. O cliente não está se reunindo com o analista de requisitos com quem vai ao médico e coloca uma situação, descrevendo os detalhes e perguntando o que fazer.

Não!

O clientes vão para sala de reunião dizer o que eles querem, e em 90% dos casos assumem que já bolaram a melhor solução, e que cabe ao projeto apenas implementá-la. Poucos carregam humildade o bastante para questionar a própria opinião ou, melhor ainda, oferecer o problema e pedir orientação.

Esse pequeno exercício de vai-e-vem, de abrir caminho no cipoal de achismos e “viagens” até pisar no cerne da questão, é o feijão-com-arroz do levantamento de requisitos em BI. Se você quer ajudar mais seu cliente, sofrer menos no desenvolvimento e passar menos frustrações, aprenda a perguntar porquê até não sobrar nada, até a língua sangrar!

Fábio, drama queen

:-D

Claro que a coisa precisa ser feita com um mínimo de tato e inteligência, ou vai virar uma patetada digna do Chaves.

Chamam isso de técnica dos “cinco porquês”, pois ao perguntar “por quê?” pelo menos cinco vezes chegamos à raiz de qualquer coisa. Este blog tem um texto mais detalhado.

Por Que Sim!

Fui vendedor de soluções de BI e depois de algum tempo percebi que 100% dos clientes pediam coisas que achavam que solucionariam o problema deles, mas que se eu vendesse o que eles pediam nunca daria certo.

Para entender o problema do cliente e descobrir o que resolve – ou seja, qual é a Solução de BI que ele precisa – é preciso um tempo de relacionamento, uma alma insatisfeita e muita paciência. Raramente você vai conseguir perguntar porquê? cinco vezes, de cara, na mesma reunião ou telefonema e sair com algo útil.

Por quê?…

Por que nem sempre o cliente tem paciência para isso.

?…

Por que ele sempre acha que já te respondeu e que você está sendo um chato.

?…

Por ele demora um tempo até perceber quão vazias são as respostas que ele está te dando – porque leva um tempo até a ficha cair.

?…

Por que raramente ele espera que o profissional de BI ajude com o problema dele.

?…

Por que quase todos clientes acham que vendedor de BI vende software, e não solução! ;-)

Até a próxima! ;-)

Por quê? Por que sim, pô! :-P


  1. PCI vem de Payment Card Industry Data Security Standard, ou padrão de segurança de dados da indústria de cartões de pagamento. 

ROI de Projetos de BI

Eu já falei um pouco sobre ROI de BI em dois posts:

O ponto nos dois casos era o mesmo: dinheiro voando pela empresa que foi recuperado com o uso de Inteligência de Negócios, comparado com o custo de cada solução. Como sempre, o ROI de projetos de BI é astronômico, é fora de escala. O primeiro se pagou em algumas semanas, e o outro deu um retorno de dezenas de vezes. Um exagero nos dois casos, não se importa como se examine a questão.

Em 8/8/16 (8+8=16! :-O ) meu grande amigo Rômulo me mandou um SMS:


Perguntas recorrentes: como avaliar o sucesso de uma implantação de ferramentas analíticas (BI); como medir, nesse caso, o ROI?


Eu prometi a ele responder com um post no blog, já que o assunto é extenso, interessante (e relevante) demais para um SMS.

Return On Investment

Em bom português, ROI significa “retorno do investimento”. Via de regra, ROI pode ser definido como, por exemplo, o tempo para um projeto pagar a si próprio ou o impacto do projeto sobre o faturamento ou o lucro anual.

E isso é óbvio, não é?

Toda Estrada Tem um Retorno Invisível

Pare um pouco. Respire, tire os olhos desta tela e olhe ao seu redor. De onde veio tudo que está por aí?

Do retorno esperado.

Por que você come quando está com fome? Porque espera que, em retorno ao seu ato de mastigar e ingerir, desapareça o incômodo da fome.

Por que compramos uma mesa, uma TV, pagamos um curso ou convidamos alguém para sair?

Por que trabalhamos? Por que uma empresa surge? Por que montamos projetos?

Fazemos tudo isso para obtermos um retorno, algo que vai aplacar uma vontade ou atender uma necessidade.

Tudo que fazemos, e por extensão tudo que uma empresa realiza, gera um retorno. É por isso que, às vezes, perceber o retorno de uma determinada ação é muito difícil, especialmente se é algo que pouco afeta sua realidade. Às vezes, o retorno de uma determinada ação só pode ser percebido quando aquela ação deixa de ser feita, como quando perdemos o emprego, ou quebra-se uma linha de produção. Neste momento vemos como é importante ter um salário, ou como uma peça que representam 10% dos custos de uma empresa pode ser responsável por mais da metade do dinheiro que entra.

Uma situação comum em que o ROI não é tão facilmente calculável é justamente a modernização de um recurso ou a manutenção de uma situação. Vamos bolar um cenário para um caso clássico, o ROI de um treinamento, e examinar algumas coisas.

Imagine um banco. Estamos em 2016 e nosso banco é uma empresa já estabelecida, operante. Fazemos uma pesquisa de opinião e descobrimos que nossos atendentes não gozam de boa reputação com a clientela. Ser mal-visto é ruim, e queremos diminuir essa percepção negativa. Decidimos, então, aplicar um treinamento de “atendimento qualidade total”.

Como medimos o ROI desse treinamento? Fácil: rodamos uma nova pesquisa e verificamos se a reputação melhou, certo?

NÃO! Errado!

É de ROI que estamos falando, de DINHEIRO, não de percepção subjetiva do atendimento pessoal.

Uma coisa é observar se o projeto – o treinamento – deu resultado. Outra, bem diferente, é descobrir quanto dinheiro ficou a mais com o banco por causa dessa capacitação!

Pense em outro cenário no mesmo negócio, o banco: um novo sistema interno vai entrar em operação, e a certa altura do roll-out é feito um treinamento no uso desse sistema. Seis meses mais tarde, com 100% dos usuários do novo sistema treinados e aprovados nas avaliações, a capacitação deu resultado? E o ROI, de quanto foi?

Talvez vocês conheçam essa anedota:

Ouvido na conversa entre dois empresários:

- Eu decidi que não vou treinar meu novo empregado. Imagine se eu invisto nele, preparo-o, e ele resolve ir embora?!

Ao que responde o outro empresário:

- É? E o que acontece se você não treiná-lo, e ele decidir ficar?

Vêem onde eu quero chegar?

Certos projetos oferecem uma dificuldade extra para calcular o ROI porque o retorno do projeto serve apenas para manter as coisas como estão, para evitar que piorem. Só conseguimos avaliar o quanto nos custaria não investir, como na anedota. Por extensão, podemos supor que o ROI desse tipo de projeto depende desse custo de não investir, do chamado custo de oportunidade.

Quadridimensional

Lá no começo dissemos que ROI pode ser, por exemplo, o dinheiro que o projeto gerou a mais, e aqui em cima mostramos que esse retorno pode não ser a mais e sim evitar uma perda, evitar um dinheiro “a menos”. Para fechar o assunto vamos apresentar umas equações simples, para ancorar o conceito na Matemática.

Uma das formas de calcular ROI é esta:

 

Definição simples de ROI.
Definição simples de ROI.

 

Aqui considera-se o ganho total de um investimento, contra seu custo. É uma fórmula válida para quando compramos ou vendemos alguma coisa, mas não quando mudamos algo na vida da empresa.

Quando um projeto é conduzido para mudar algo, precisamos considerar o impacto deste projeto ao longo do tempo. Basta pensar um pouco para entender o porquê: ao prevenir a interrupção da produção, por exemplo, você garante que o dinheiro vai continuar entrando. Se o projeto custa mais caro do que, digamos, um mês de produção, o ROI definido acima vai ser negativo se considerarmos o ganho do investimento apenas durante um mês, ou menos. Agora, este mesmo ROI se torna positivo – e cada vez maior – se considerarmos esses números a cada mês, ou dentro de um ano, por exemplo.

O chato de ver a questão sob este ponto de vista é que tudo passa a ter ROI, e não raro um grande ROI:

  • Se eu deixar de pagar meus empregados, eles param de trabalhar e eu paro de faturar. Então há um ROI aqui, que equivale a tudo que eu faturo!
  • Se eu deixar de pagar a eletricidade, ou a água, ou telefone, ou…, ou…, ou…, de novo, o dinheiro não vai entrar. Então, pagar tudo isso tem um ROI que é, de novo, igual a tudo que a empresa ganha!
  • Se eu deixar de investir na melhoria da empresa, meus clientes podem me abandonar, piorando meu faturamento. Logo, investir em melhorias tem ROI!

E asssim por diante. Esse raciocínio vai dar muita confusão se o levarmos adiante e por isso vamos manter o foco apenas nos projetos limitados no tempo. Esses projetos têm início e fim (um custo determinado), e normalmente mudam ou acrescentam algo na empresa (um impacto limitado.)

Ao considerarmos projetos e tempo, definimos o ROI como um retorno dentro de um período. Ou então como o tempo que o projeto leva para se pagar, em função de quanto esse projeto agregou de valor. Sob estas condições, a fórmula fica assim:

 

Definição de ROI com tempo.
Definição de ROI com tempo.

 

Leia: o ROI do projeto é medido em períodos, calculado como a razão entre o custo do projeto e quanto de dinheiro o projeto traz a mais. Se dissermos que período é mês, estamos calculando quantos meses o projeto leva para se pagar.

Essa é a fórmula de ROI que eu usei no post R$20M, e é o que nos interessa para responder a pergunta do Rômulo:


Em “uma implantação de ferramentas analíticas (…) como medir (…) o ROI?”


Ganha um bombom quem percebeu que essa é a fórmula para o famoso “vai levar X anos para se pagar”. ;-)

Só para completar, podemos calcular um percentual de retorno por período, deixando a equação semelhante à definição inicial:

Definição de ROI percentual, com tempo.
Definição de ROI percentual, com tempo.

Projetos de BI

Agora temos uma definição para ROI, e sabemos que o retorno pode ser tanto uma melhoria nos resultados quanto a prevenção de uma piora destes.

Antes de continuarmos, deixe-me esclarecer uma coisa sobre o meu amigo.


O Rômulo mora em uma cidade no estado do Rio de Janeiro e foi aluno meu numa das turmas de BI da 4Linux, à distância. Ele é muito gente fina e um dia, ao vir para um congresso em São Paulo, entrou em contato comigo e marcamos uma pizza. Conversa vai, conversa vem eu percebi que não era um aluno típico de BI. Ele estava terminando o doutorado e precisou de uma ferramenta de integração de dados, de relatórios etc. e por isso foi atrás do Pentaho. Daí optou pelo EAD da 4Linux etc. etc. etc.

Foi um certo choque para mim, quase tão grande quanto ter dado aula para o Prof. Fidelis – que ensina Data Mining há mais de 20 anos – e para o Grimaldi, do BI Com Vatapá, outro gigante nacional. Dar aulas para caras muito mais gabaritados do que eu me dá um tanto de medo, mas enfim.


Então quando o Rômulo faz perguntas, ele coloca a coisa em outro nível. Ele não diz simplesmente “ROI de BI”. Ele é preciso: “ROI da implantação de ferramentas analíticas”. E não faz isso por pedantismo ou para se exibidir – ele é gente fina, lembrem-se! – mas sim porque é precisamente essa a expressão.

O que é um projeto de “implantação de ferramentas analíticas”? É o que popularmente chamamos de “BI”, e mais recentemente de “Data Discovery”: é a disponibilização de dados, para análises ad hoc, por meio de alguma ferramenta de análise multidimensional.

Não BI, Mas Sim Ferramentas Analíticas

Quase lá!!

E o quê um projeto de “implantação de ferramentas analíticas” entrega? O que ele cria na instituição, na empresa? Que retorno ele traz?

Depende.

É isso mesmo que você leu: d-e-p-e-n-d-e. ;-)

Imagine que estivéssemos falando de Data Mining. O que um projeto de Data Mining entrega é um modelo matemático que vai ser usado para tomar decisões automaticamente. Esse tipo de projeto tem uma meta clara desde o começo. São sempre coisas como “aumentar X% as vendas”, “reduzir em 100 clientes/mês de perda por atrito”, “economizar K dinheiro na distribuição” e tals.

Mas e um projeto que coloca, nas mãos dos empregados, uma ferramenta para montar “relatórios”?

Depende: para que eram necessários esses “relatórios”?

Pode ser que sejam usados apenas para substituir um trabalho braçal feito todo mês, como consolidar o balanço da empresa.

Ou talvez o usuário esteja tentando bolar uma estratégia de cobrança para recuperar dinheiro de caloteiros.

Ou talvez para desafogar a TI, que gasta muito tempo só fazendo consultas triviais nas bases, servindo a empresa inteira.

Róidebiai

Esse subtítulo parece “pedro bial”, se lido bem rápido… :-)

O cálculo do retorno do investimento de um projeto de BI, em geral, ou de implantação de ferramentas analíticas, em particular, vai depender muito da clareza de objetivos do gestor que patrocinou o projeto.

Há um sério problema na indústria de BI hoje em dia porque nem todos entendem como usar os dados para gerar valor. Quando entendem do assunto, gestores patrocinam projetos de Data Mining, com metas claras e portanto ROI fácil de se calcular, ou então apoiam projetos que visam equipar a força de trabalho da empresa com um ferramental necessária para o trabalho diário. Neste caso, especificamente, a meta não é aumentar um faturamento, mas sim reduzir o esforço do trabalho como um todo, aliviar uma dificuldade sistêmica, azeitar melhor as engrenagens que mantém a organização eficiente, produtiva.

Calcular um ROI desse tipo de meta não é fácil, isso quando não é impraticável. É exatamente o caso de um projeto que não impacta criando algo novo, mas impedindo que se perca algo que já se tem, ou se tem pouco.

Assim, medir o ROI da implantação de ferramentas analíticas equivale a medir a produtividade dos beneficiados com essas ferramentas. Pode ser a redução do trabalho para gerar informações, pode ser uma maior velocidade na solução de problemas ou qualquer outra melhoria marginal, difusa pela empresa!

E, claro, temos casos pontuais no qual o cálculo do ROI é mais prático. Por exemplo, digamos que a tal ferramenta analítica foi trazida para um conjunto pequeno de profissionais, para resolver um problema pontual. Um projeto desses vai entregar alguma coisa muito definida, que facilita a medida de ROI.

Conclusão

Rômulo, você queria saber, em “uma implantação de ferramentas analíticas (…) como medir (…) o ROI?”

Depende! Que problema essa implantação mirava resolver? Resolveu? Agregou dinheiro ou apenas impediu o desperdício?

Essa é uma regra geral de BI que eu sempre reforço:


Projetos de Inteligência de Negócios resolvem problemas. Se sua instituição não tem um problema para resolver, então você não tem nenhuma necessidade de BI, não importa o que os vendedores de ferramenta digam em contrário.


Implantar recursos de Inteligência de Negócios sem ter claro que problema você vai resolver é uma coisa bem pouco inteligente. Se está muito difícil calcular o ROI do seu projeto de BI, pense duas vezes: precisa mesmo? Para fazer o quê? Para resolver que problema? Pode ser que você esteja no camiho errado!

Até a próxima! :-)