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. 

A Nuvem Negra

Acabaram-se as férias! De volta ao trabalho!

Eu estava lendo um clássico de SciFi chamado The Black Cloud – sim, é daí que eu tirei o nome do post.

Este é uma daquelas histórias que deram a fama ao gênero: com cientistas e perigos intergalácticos, mas contada do ponto de vista da Humanidade, tal como nós a conhecemos. Eis um resumo: em 1963, um estudante de Astronomia detecta uma anomalia no céu [setentrional][setentrional_bitly]. Descobre-se, mais tarde, que essa “anomalia” é uma gigantesca nuvem de gás interestelar, deslocando-se a mais de 100 km/s (cem kilômetros por segundo! Conte 1… cem kilômetros!) em direção ao Sol. Essa nuvem provoca uma violenta catástrofe por aqui e, por muita, muita sorte, não destrói a Terra de uma vez. (Não vou dar spoiler! Leia, é do balacobado!)

Boa Ciência

Pouco depois do começo da história é formado um time de cientistas (físicos em sua imensa maioria) para estudar a Nuvem, a fim de orientar as decisões dos governos do mundo face à novidade. Eles prevêem um certo cenário, mas ele não acontece. Daí outro, e também a coisa não se passa como esperado, e mais um, e outro… Ou seja, erram um monte, pois a tal da Nuvem comportava-se de maneira “errada”. A certa altura, discutindo como interpretar um certo fenômeno impossível (mais um…), um dos cientistas solta o comentário:

Russo rosna...
Russo rosna…

Tradução “limpa”:

“Porcaria de Ciência ruim!”, rosnou Alexandrov. “Obter correlação após fato, Ciência de porcaria. Ciência só prever.”

Alxenadrov, como o nome sugere, é um russo, e por isso ele tem essa forma de expressão… crua, digamos assim. Ao “exclamar” esse comentário, ele contestava o debate, dizendo que adiantava nada achar uma explicação para os fatos. Se quisessem mesmo entender o que está acontecendo na Nuvem, era preciso testar essa explicação: se ela for capaz de prever o comportamento da Nuvem – que é o que mais interessava à eles – então você fez boa Ciência, gerou conhecimento e progrediu. Caso contrário, é uma explicação furada ou imperfeita e precisa ser revista ou melhorada.

Fazer o contrário, adotar uma explicação pós-fato e confiar nela porque explicou o que aconteceu, é o mesmo que apostar numa corrida de cavalos que já acabou (falam exatamente isso para explicar os termos do Alexandrov para as personagens não-cientistas.) Vem daí o “bloody science” do russo, que a educação manda traduzir por porcaria, mas que é melhor representada por outra palavra, também começada com P. :-)

E o que isso tem a ver com BI? Por que esse assunto tão nada a ver logo no começo do ano?

Já, já chego nisso. Antes, uma pequena revisão.

Inteligência de Negócios

No post Paz, Afinal III, eu defini BI pela última vez na minha vida com essa frase:


Inteligência de Negócios é a disciplina de busca da compreensão dos negócios de uma organização mediante a aplicação do Método Científico.


Revendo, acho dá para simplificar:


BI é o uso do Método Científico por uma organização para melhorar sua administração.


Daí, seguindo nesta trilha, no post Full Metal BI Itch eu desenvolvi o argumento de como a aplicação do Método Científico aos dados de uma empresa produzem valor. Eis o trecho relevante:


(…) 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?

(…) 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. (…)


Resumindo: BI é a aplicação do Método Científico para, a partir da observação de eventos passados, tentar prever (=tomar a melhor decisão) o que vai acontecer.

BI & Ciência

Acho que a relação entre a exclamação do Alexandrov e BI ficou evidente: são a mesma coisa.

Para que iríamos querer olhar os dados que já são passado? Apenas para explicar porque algo aconteceu como aconteceu? Seria muito estéril aplicar tanto esforço por um consolo intelectual.


Ah, fracassamos porque nossa taxa de falhas nos itens da linha de produção número um eram superiores a 1 em 10.000… Que peninha…


Claro que não é para entender, só entender! É para entender o quê levou as coisas a serem como foram, e então evitar que o mesmo problema se repita! Ou que as mesmas oportunidades sejam perdidas! Ou, ou, ou…

Alexandrov colocou de uma forma muito simples, clara e, bom, elegante (numa forma russa de ser, hehe) de se explicar o propósito do ramo da Inteligência de Negócios: fazer boa Ciência (com os dados da empresa!)

Uma Nuvem Negra

Na história, a certa altura, a Terra começa superaquecer (levando à morte milhões de pessoas) porque a Nuvem refletia o Sol e, ao chegar mais perto, mandava mais calor para a Terra.

Depois, quando a nuvem chega, ela obscurece o Sol, e a Terra cai em um inverno profundo, intenso, no qual outros milhões morrem.

IMHO, esses trechos da história também ecoam a realidade da indústria de BI.

Visto de longe, chegando, toda tecnologia associada ao jargão Business Intelligence, parece brilhar com luz própria, anunciando um futuro iluminado, onde nenhuma sombra será vista pairando sobre nosso conhecimento! A chegada das ferramentas de BI na sua organização trará uma nova era de conhecimento, rico e valioso conhecimento!

… Até que tudo é instalado e posto a funcionar e, pouco tempo depois, em muitos dos casos, tudo não parece mais tão claro. Não vou querer esticar esse paralelo ao ponto de dizer que todo projeto de BI acaba em mortes de milhões de inocentes, mas sim, quem já passou por um projeto desses sabe que o mundo real acaba sendo mais sombrio e complicado que a expectativa.

Se já é difícil fazer boa Ciência, imagine em um ambiente que não permite experimentos, como uma empresa.

O truque – que, me parece, cada um precisa aprender sozinho – é saber navegar o dia-a-dia da organização, atingindo expectativas, com um olho no futuro e outro no passado. Até mesmo por isso é que BI é um apoio para a estratégia da empresa. (O que me leva mais uma vez ao argumento contra BI em tempo real. Mas estou digredindo, vamos voltar.)

Bloody Conclusion

Ah, ano novo! Tantos clichês, tão pouco espaço… :-)

Eu queria que o primeiro post do ano trouxesse algo mais fundamental, mais na raiz do sucesso de projetos de BI, seja você da área de negócios ou TI. E, sucesso, é ajudar a organização a crescer e se manter.

BI é valioso. BI cria valor para a organização, e por valor eu quero dizer dinheiro, seja aumentando o faturamento, seja reduzindo custos ou melhorando a produtividade.

Se você quer que sua organização viceje e floresça, então você precisa aplicar o que os dados ensinam. A cultura de BI que experimentamos hoje, tal qual uma nuvem, suaviza os contornos da realidade e dá muita relevância às ferramentas, tendendo a deixar de lado o aspecto científico (=do conhecimento.), que é justamente o como as análises criam valor. E o mais complicado dessa situação é que ela não é óbvia. É preciso dar um passo para trás e tentar ver a bloody big picture para apreender como o conhecimento gerado pela análise de dados está sendo reinjetado na empresa, para melhorar seus resultados.

Quando aplicam-se conclusões que explicaram o passado, mas não foram testadas contra o futuro, BI falha em criar valor e, não raro, pode destruir valor na organização. Esse é o cuidado que temos que ter. Esforce-se em aprender a transformar o conhecimento em valor, através do estudo dos dados.

Isso, bloody comrade, é que é bloody BI. Bloody 2017 para todos nós! :-)

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. 

Livros

Mais ou menos uma vez por mês eu entro na Amazon, seção de livros, e digito “dw” ou “bi” ou “data mining” ou algum jargão da nossa área. Eu reviso a lista resultante e vou separando (clicando com o control apertado, para abrir em outras abas) todo e qualquer livro que eu ache interessante. Reviso essa seleção mais uma vez e escolho um ou dois para ler.

A última rodada me trouxe quatro livros do balacobaco.

Impossible Data Warehouse Situations

O mais divertido de todos, de longe, foi este:

Impossible Data Warehouse Situations.
Impossible Data Warehouse Situations.

É um livro antigo, do início dos anos 2000, que aborda um rosário de problemas comuns em implementações de DW. Por exemplo:

  • Quando o protótipo vira produção;
  • TI é o assassino;
  • Clientes não sabem o que querem, clássico dos clássicos!
  • A quem o time de DW deve se reportar? (CIO, gerência de departamento etc.)

Ou seja, problemas comuns. Por que, então, o título de situações impossíveis? Bom, justamente por serem comuns é que são impossíveis: impossíveis de se evitar, quase impossíveis de se resolver.

E nenhum destes problemas faz parte de nenhum curso de DW. Pode olhar, pode procurar. O máximo que você vai conseguir achar é um professor mais experiente que passou ou resolveu algumas destas situações, e vai te contar alguma coisa se você perguntar.

Dessa constatação temos o valor que esse livro possui: inestimável. Até porque não é um autor prescrevendo soluções mágicas, mas sim um painel de profissionais gabaritados que dão sua opinião a cada tópico.

Veja esta situação, como exemplo:

  • Should a line of business build its own DM?

Ou, no meu tradicional e macarrônico estilo de tradução, “um departamento deve construir seu próprio DW?” Ela é descrita, contextualizada e daí vários dos colaboradores do livro dão sua opinião. Alguns são bem rasantes, outros são mais acadêmicos, uns são pé-no-chão enquanto que outros, viajantes. Assim você acaba sempre com várias visões e idéias e propostas para o problema – uma riqueza enorme!

A resposta desse exemplo, para mim, vale ouro. Vários foram quadradinhos, “sim, porque o DW é a coleção dos Data Marts” ou “não, porque o DW é uma coisa centralizada”. Bah, isso eu já sei. Mas aí vem a Jill Diché, minha favorita: go togheter with IT. Ou seja, aproxime-se da TI e ofereça para dividir a carga: você colabora com profissionais e ganha, em troca, priorização. Como é você quem vai fazer a sua parte, você recebe antes. Isso deixa o departamento feliz, a TI feliz (porque tem mais mãos para trabalhar) e não aborrece os consumidores que competem com recursos! Gênio!

E o livro está cheio dessas!

Claro que, com essa idade, alguma coisa acaba datada, como essas duas “situações impossíveis” por exemplo:

  • O sistema de origem muda continuamente; ou uma variação
  • O sistema de origem está passando por uma mudança.

As soluções propostas são de gerenciamento, mitigação de riscos e fortalecimento dos padrões e do modelo dimensional. Hoje em dia temos outra opção (já sabe, né? Data Vaul!), mas mesmo assim não é uma mudança tão grande.

O livro fala sobre negócio (mal-entendidos, desinteres, motivação), times (disfuncional, prima-donas, encrenqueiros), clientes (chatos, ruins), chefes (burros, preguiçosos ou bagunçados), técnicas (metodologia, falta de conhecimento, de experiência), padrões (usados errados, sem padrões), ferramentas e qualidade dados, entre outros.

Como eu disse, adorei esse livro. Não consigo deixar de mencionar outros dois favoritos meus, dos padrões:

  • Os empregados usam a terminologia de maneira errada;
  • Tudo é Data Mining.

:-D

Clinical Intelligence

O nome inteiro do livro é enorme:

Clinical Intelligence: The Big Data Analytics Revolution in Healthcare: A Framework for Clinical and Business Intelligence

E ele fala exatamente isso: como usar os conceitos e idéias de BI aplicado ao campo da Saúde. Há algum exagero e um pouco de mal-entendidos, mas nada que prejudique a idéia central.

Por exemplo, ele separa BI e Analytics (item 1.2, paǵina 26), e classifica machine learning, pattern recognition e predictive modeling como motores (engines) e – não bastasse – ainda por cima diferentes. Como se um padrão não fosse um modelo preditivo, e coisas nessa linha. Dá para suspeitar um pouco se ele realmente chegou a entender tudo do que fala, mas – torno a insistir – não compromete o resultado final. Apenas leia com algum resguardo, pois ele não é da área de BI.

Já na parte que realmente interessa, meus caros, ele arrebenta.

E o que realmente interessa é o índice do capítulo 2:

Sumário do capítulo 2.
Sumário do capítulo 2.

(Peço perdão pela baixa qualidade da imagem. Puxei-a do site da Amazon, e ele não estava colaborando muito…)

Vêem? Ele mostra um tipo de análise para cada um dos vários assuntos médicos! Tem desde aspectos administrativos, como casos de uso, scorecards e indicadores diversos, a complexos modelos de atendimento clínico e previsões de custos, passando por modelos de predição de osteopatia e acompanhamento de antibióticos.

Na boa, esse é o livro de cabeceira de QUALQUER gestor de saúde. Quanto mais abrangente a responsabilidade desse gestor, mais importante se torna esse livro. Em outras palavras: leitura obrigatória para secretários e ministros da Saúde, ponto.

É uma leitura que eu passei meio por alto, afinal eu sou um alien para esse campo. Eu me detive apenas nas partes de BI (onde ele faz uma zona com alguns conceitos, acerta outros e se embanana todo com ainda outros) e matemática (em que ele, aparentemente, coleta trabalhos feitos por diversos outros times, uma coisa absolutamente normal, aceitável, afinal, só um ser sobrenatural poderia saber tanto sobre tanta coisa diversa.)

Agile Data Warehouse Design

Este livro tem uma proposta muito bacana: estabelecer uma metodologia para captura de requisitos para DW adequada a projetos ágeis, e ágil em si mesma.

Cara, ficou ruim. Deixe-me tentar de novo:


Este livro tem uma proposta muito bacana: explicar um método ágil de capturar requisitos para DW, requisitos estes adequados a projetos de gestão ágil.


Bem melhor!

Ágil como em ninja, não como em rápido.
Ágil como em ninja, não como em rápido.

E seria um livro excelente não fosse tão… poluído? Pesado? Foi difícil lê-lo do início ao fim, e eu falhei nisso – depois de um tanto saí pulando até onde aguentei. O método é interessante, parece que funciona e não é difícil. Acho que o maior galho dele é justamente ser uma receita de bolo. Ele tenta passar um conhecimento “situacional”, ou seja, de como agir em cada situação, e fica tão cheio de exemplos e detalhes e senões que a coisa toda fica pesada, trabalhosa.

A sensação é que, uma vez assimilado esse conhecimento, a coisa flui. Assimilá-lo é que parece mesmo um trabalho duro. E, já que estou no assunto, ele não resolve os problemas típicos de projetos, nem de projetos de DW, justamente como aqueles colocados no Impossible Situations – esse mesmo, sobre o qual escrevi acima.

Vale a pena ler? É, pode ser que sim. Se tiver tempo, com certeza. Mas não me parece uma daquelas técnicas que abalam o mundo, como – adivinhe? – Data Vault ou Análise Bayesiana. Mesmo assim, ele agrega.

Até porque eu cheguei numa técnica semelhante, muito mais modesta e de alcance muito menor, mas na mesma linha. ;-)

Variados

E esses eram livros que eu havia lido, mas sobre os quais ainda não falara nada. Além deles, em 2016 eu li alguns outros. Dessa leva de coisas da Amazon falei um pouco no post Férias = Livros!. Não custa relembrar (não custa mesmo, é só um copy-paste aqui, hehe):

Cada um deles é um primor de conteúdo e forma. O de expressões regulares eu deixei até separado, de tanto que eu uso. O de análise bayesiana eu leio e leio e leio e uma hora eu vou dominar!

Já o Building A Scalable DW, bom, pelamordedeus, leia! Ele e o DW Toolkit são a base para um DW Corporativo feliz e saudável! ;-)

Alguma Dica?

E isso fecha o meu ano de leitura. Agora estou procurando as coisas para 2017.

Alguma sugestão? ;-)

Exame & BigData

A revista exame publicou, em 5 de março deste ano (2016), um artigo comentando sobre o mercado de trabalho para “Cientistas de Dados”.

Eu sempre implico com nomes “da moda” porque, na minha opinião, eles desvalorizam o profissional sedimentado, experiente, abandonando expressões que funcionam por um palavreado mais colorido. Ocasionalmente a coisa muda, claro, e esses nomes precisam mudar junto, mas em TI há uma competição disfarçada para ver quem vem com a próxima buzzword. No final essa disputa acaba por atrapalhar a vida da TI porque tanta mudança forçada impede a construção de senso comum e de uma cultura particular.

Pergunte a um engenheiro mecânico o que é um carburador, ou se eles usam “camâras adiabáticas para oxiredução explosiva”. Ou para um financista se ele fala juros compostos, ou “taxa de interesse recursiva”.

Entendeu a idéia? Para quê mudar uma expressão se ela adequa-se perfeitamente?

Pior: uma pessoa errada, mas com muita certeza, vai levar outros a errar também. É preciso estar de posse de um conhecimento sólido para poder resistir à pressão do hype corrente.

Big Data, Hiper Hype

Nestas últimas semanas eu tenho escrito sobre BigData, mas ontem eu não tinha assunto. Eu não sabia sobre o que postar, e depois de um dia cheio e tela em branco, eu simplesmente desisti.

Sem inspiração? Que tal tocado como gado?
Sem inspiração? Que tal tocado como gado?

Hoje eu acordei e olhei de novo para minhas anotações e achei este rascunho aqui, sobre a Revista Exame, e vi um bom fechamento para a série. Junte-se a isso que eu repeti minha palestra sobre BigData para a Fatec Zona Sul, cujo foco era desfazer confusões antes de começarem.

Leia a reportagem, é interessante. Entretanto, lá no meio, quando tudo estava indo bem, algo dá errado:


“O big data não se resume a um processo de automação. Seu objetivo é entender melhor o que acontece numa empresa, o que os clientes querem e, assim, modificar o negócio”, diz Jorge Sanz, diretor do Centro de Business Analytics da Universidade Nacional de Singapura, um dos grandes centros de big data da Ásia. Esse processo requer softwares capazes de captar os dados relevantes — e, acima de tudo, pessoas treinadas para interpretá-los.


Eu copiei o parágrafo inteiro como está. Releia. Releu? Entendeu? De novo, devagar:

“O big data não se resume a um processo de automação.”

“O” big data? Agora é uma coisa só, um objeto que anda por aí, e não mais uma tecnologia, mas um objeto. Ok, vamos dar uma colher de chá, já que muitos profissionais ainda chamam BI de “O” BI.

“Não se resume a um processo”: então “big data” é um processo? Se ele diz “não se resume”, então ele já classificou o assunto como um processo; apenas vai adiante e diz que não é apenas um processo – mas implica que é um de qualquer forma. Ou seja, passou de tecnologia-objeto (que demanda o tal do artigo definido masculino singular, “O”) para uma coisa que também é um processo. Mais uma confusão, mas vamos relevá-la de novo, em favor da prosa da reportagem.

“De automação”: e de onde veio isso? Do parágrafo anterior no artigo, onde ele começa associando computadores a automação. Até são coisas relacionadas, mas chamar Hadoop de automação é um pouco demais. Mas mesmo assim, vamos em frente.

E aqui o assunto descarrilha de vez:

“Seu objetivo é entender melhor o que acontece numa empresa”

É um repórter competetente, entrevistando um executivo relevante de uma enorme instituição financeira nacional. Quer dizer, não é um par de manés, não! São profissionais experientes, gabaritados e entendidos no assunto…

… que meteram os pés pelas mãos. Há décadas existe um termo que usa como definição justamente essa frase – Seu objetivo é entender melhor o que acontece numa empresa: Inteligência de Negócios, vulgo BI.

O que ele fez foi chamar uma coisa de outra. Foi vender banana anunciando carambola, já ambas são compridas, amarelas, tem casca, são frutas… Só que não são a mesma coisa! É um esforço feito para dar ribalta a uma expressão da moda, dando um gancho (sigam este link, é hilário!) em outra!

Fora, Inteligência de Negócios! Agora queremos "o big data"!
Fora, Inteligência de Negócios! Agora queremos “o big data”!

Existe uma outra explicação, que é dizer que ele não sabia mesmo do que estava falando, mas isso é um pouco demais para aceitarmos. Afinal, é a maior revista de negócios do Brasil, não um panfleto de bairro. Não atribuiriam a um repórter uma tarefa que ele não conseguisse desempenhar adequadamente. Isso feriria a reputação de ambos – revista e repórter. A menos, claro, que seu público não fosse capaz de perceber a confusão, mas aí é demais para aceitarmos porque estamos falando de um público qualificado, líderes, executivos e profissionais de todos os ramos, conhecedores de assuntos mil…

Entenderam como funciona? Ninguém tem bem certeza do que é algo. Aí a moda vem, avassaladoramente, e sacode tudo junto. No final fica parecendo aquela piada:


O bêbado entra no ônibus, passa a roleta e vai para trás. De lá, grita:

  • Do lado direito todo mundo é palmeirense! Do lado esquerdo todo mundo é corintiano!

Ao ouvir isto, levanta um do lado direito e fala:

  • Eu não sou palmeirense!!!

E todo os passageiros começaram a xingar o bêbado e ameaçando cobri-lo de bolacha. O motorista, para evitar confusão, freia bruscamente e todos caem. Um dos passageiros se levanta, pega o bêbado pelo colarinho e pergunta:

  • Fala de novo, safado! Quem é palmeirense e quem é corintiano?!

  • Agora eu não sei mais. Misturou tudo…


Não dá mais para saber quem é quem, porque o jornalismo especializado misturou tudo.

Conclusão

A reportagem segue nesse mesmo ritmo, dando novos nomes a coisas já estabelecidas. Por exemplo, em certo momento ele diz que os cientistas de dados têm remuneração superior à dos técnicos, que até o surgimento do big data eram os responsáveis por cuidar da manutenção dos bancos de dados. Ele misturou DBAs com analistas de DW/ETL, com Analistas de Data Mining, com Hadoop, com Bancos Relacionais… Em metade de um parágrafo, em menos de 30 palavras, causou-se estrago para pelo menos três áreas:

  • DBAs fazem a mesma coisa que cientistas de dados se você não usar “big data”;
  • Cientistas de Dados são DBAs para “big data”;
  • A manutenção de um Hadoop, uma plataforma de clusterização escrita em Java, é feita por um cientista de dados, enquanto que a de um Oracle, um banco de dados relacional, é feita por um técnico, e são a mesma coisa do ponto de vista funcional;
  • E Data Mining?

Esse tipo de artigo confunde um número de conceitos complexos para uma audiência em geral leiga nestes mesmos tópicos. Por ser um veículo de projeção nacional e respeitado, bem-conceituado, muitos tomam o que sai ali por fato, por verdade canônica. Aos poucos essas confusões tomam o lugar das verdades nas empresas, impactando planejamento, contratações, e até debates. Como é que um cara qualquer, um joão-ninguém como eu pode argumentar com o “repórter da Exame”? A quem acreditam vocês que o público atribui maior conhecimento? :-)

E pior ainda: como é que um profissional recém-formado pode querer colaborar com a empresa, se tudo que ele fala é contestado pelo chefe que viu tudo diferente na revista de negócios mais famosa do Brasil?

Tem mais razão e está mais certo que fala com mais convicção? Não, né? Repasso aqui o conselho que dei àqueles alunos das FATECs:

Use sua inteligência para filtrar. Critique e questione tudo. ;-)
Use sua inteligência para filtrar. Critique e questione tudo. ;-)

É isso. ;-)

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! ;-)

 

Alhos, Bugalhos e BigData

Há tanto sendo escrito e falado e mostrado sobre BigData por aí que eu simplesmente não tenho muito o que agregar. Mesmo assim, nestas duas últimas semanas eu acabei fazendo posts sobre BigData:

O primeiro define BigData a partir de sua evolução, seguindo o caminho que a tecnologia percorreu até os dias atuais. Já o segundo é a minha opinião sobre o caminho que o assunto – não a tecnologia – vai tomar.

Eu sinto, porém, que há um último tópico a ser “passado a limpo”: a confusão entre o meio e a meta.

O Meio

A história toda começou com várias empresas e organizações buscando uma forma de aumentar a performance da indexação da World Wide Web, ou simplesmente “A Internet”. Esse esforço culminou no surgimento do Hadoop.

As possibilidades do Hadoop aguçaram os visionários de plantão e logo houve o big-bang do BigData. A coisa atingiu a mídia e o hype foi às alturas – tudo era BigData, BigData pra cá, BigData pra lá, BigData no almoço, café e jantar…


Isso dá samba :-)

BigData pra cá,
BigData pra lá,
BigData no almoço,
    café e jantar.


E essas possiblidades apareceram graças ao surgimento do Hadoop, que em si é uma arquitetura de ingestão e acesso de dados com limites muito superiores às que existiam até então. Cargas de dados, que requeriam caras combinações de hardware e software, puderam ser tratadas com investimentos muito menores, o que permitiu atacar problemas cuja soluções eram exclusividade de grandes empresas.

A Meta

Existem duas categorias de problemas solucionáveis pelo Hadoop:

  • Ingestão de dados;
  • Análises de dados.

Empresas como Facebook, Twitter, Amazon.com etc. são organizações que lidam, naturalmente, com um grande volume de dados, que surge e se modifica muito rapidamente. Capturar esses dados depende de uma infra-estrutura capaz de ler e estocar os dados disponíveis antes de novos dados aparecerem, ou a coisa toda vai por água abaixo.

Por outro lado, não surgiu nada de realmente novo em termos de análises de dados. Tudo que temos hoje foi inventado há décadas. Um ou outro algoritmo sofreu evolução, apareceu uma ou outra técnica mais esotérica, mas o grosso da caixa de ferramentas de análises de dados tem um bom tempo de estrada.

Como exemplo tome uma métrica famosa em Marketing, o Lifetime Value, que estima o valor que um cliente representa para o fornecedor ao longo da sua vida como consumidor. Saber o Customer Lifetime Value (CLV) de cada cliente ajuda, entre outras coisas, a decidir se vale a pena o esforço de mantê-lo, e quanto esse esforço pode ser.

As estimativas mais precisas do CLV são feitas usando-se o conceito de valor atual líquido, ou Net Present Value em inglês. Bom, o uso dessa metodologia remonta ao Século XIX: até mesmo Karl Marx citou esse conceito, cuja popularização aconteceu em 1907 – ou seja, o conceito ficou famoso no início do Século XX!

That Confounded Bridge

Vocês sabem o que acontece quando misturamos gente que fala muito, com coisas que não entendem? Isso mesmo: temos um palavrório que soa como se fizesse muito sentido, mas nem sempre faz. BigData é uma dessas coisas que nem todo mundo entende, mas sobre a qual muitos querem falar. O resultado é que, vira e mexe, alguém solta um “a tecnologia BigData permitirá estimar o valor do cliente para a empresa”.

Pronto: agora você não vai se confundir mais. ;-)
Pronto: agora você não vai se confundir mais. ;-)

Ora bolas, essa estimativa é feita desde o século XIX! Como assim “o BigData permitirá”? Não permitirá porcaria nenhuma – não tem nada a ver! Ele está misturando alhos com bugalhos!

Dando o crédito a uma eventual notícia dessas, pode ser que o uso de Hadoop vá baratear o cálculo do CLV a tal ponto que permita aumentar sua precisão ou incluir dados de outras fontes no algoritmo. Mas, em si, essa medida já existia, já era feita e não é nenhuma novidade, muito menos algo trazido pelo Hadoop e menos ainda coisa de “BigData”!!!

Conclusão

Hadoop é a tecnologia que deu origem ao mercado de BigData, e o centro dele ainda hoje. Hadoop não tem absolutamente nada a ver com Data Mining, que é um processo de extrair modelos matemáticos e outros quejandos dos dados. O casamento do Hadoop com as técnicas de Data Mining rende muito, mas…

Não confunda as coisas. Ou os Coisas. Que coisa confusa...
Não confunda as coisas. Ou os Coisas. Que coisa confusa…

:-)

Até a próxima!

O Fim do BigData

Em 20/10/2016 eu tive a honra e o privilégio de falar como keynote speaker no TechnoTalk de BI, BigData e Data Science da PUC do Rio Grande do Sul. Esse é um evento que ocorre com frequência, organizado pelo insuperável Jorge Audy, Agile Jedi. Já foram mais de 40 eventos, e contando!

TechnoTalk BI, BigData & DataMining.
TechnoTalk BI, BigData & DataMining.

Desta feita o Jorge havia convidado luminares de Data Mining, de BigData e eu, vosso modesto (ha-ha) escriba. Antes de mim falaram Sérgio Blum e João Gutheil, e depois falou o Irio Musskopf. Vou apresentá-los a vocês e contextualizar a discussão que vinha sendo feita e logo depois eu coloco o ponto que eu levantei no debate.

Casa cheia!
Casa cheia!

Sérgio Adriano Blum

Instrutor, gestor de projetos e consultor em Tecnologia da Informação pela White Cube, ele apresentou um painel com opções tecnológicas, ferramentas, cases e cenários do mundo BigData/Data Mining. Sigam este link para o post do Jorge, onde vocês podem baixar o material que ele disponibilizou em PPT. Você também pode entrar em contato com o Sérgio por meio de sua página LinkedIn

Um apanhado geral das tecnologias associadas a BigData.
Um apanhado geral das tecnologias associadas a BigData.

João Gutheil

O João é um conhecido meu de longa data – já batemos papo desde o começo de 2015. A apresentação do Gutheil ligou BigData com Data Mining, detalhando abordagens, valor entregue em diferentes áreas e segmentos de mercado, ferramentas e plataformas, fechando com cenários para futuro próximo.

Vale destacar que ele é um dos vice-coordenadores do Grupo de Usuários de BI (GUBI) da SUCESU-RS. Ou seja, o cara não é fraco, não.

Minha fala foi logo depois da dele, e eu usei o que ele explicou como ponto de partida. Mas segure aí – vamos terminar os convidades e eu já volto.

Irio Musskopf

O Irio é uma daquelas pessoas que tem a rara oportunidade de fazer algo de concreto e impactante para seu país. Ele falou sobre o desafio do uso de Machine Learning na Operação Serenata de Amor, que usa mineração de dados para mapear e destacar anomalias nas prestações de contas de políticos. Para custear esse projeto foi aberto uma conta na Catarse – não deixe de conhecer, é impressionante.

Usando Data Mining e Robôs para pegar malfeitos!
Usando Data Mining e Robôs para pegar malfeitos!

A CodeLand é uma empresa de desenvolvimento web ágil, especializada na liberação de novos negócios digitais.

Explodindo o BigData e Mostrando o Creeper!

Bom, quando eu entrei o Irio seria o próximo, e o João Gutheil tinha acabado de mostrar como BigData e Data Mining poderiam ser usados para resolver problemas reais, concretos, de empresas.

Eu falei sobre minha apresentação do dia anterior, na FATEC, quando eu fiz justamente uma introdução ao assunto. Comentei, então, que na minha opinião BigData é a mesma coisa que Hadoop e que é uma tecnologia útil para resolver problemas com um volume burral de dados – um volume que não cabe dentro de uma só máquina.

Eu coloquei minha primeira pergunta: onde está a maior parte dos dados que giram pelas empresas no Brasil?

Sabemos que a maior parte dos empregos, no Brasil, estão em empresas de médio e pequeno porte, e até menores. Será que o volume de dados tratado por essas empresas também se distribui segundo essa regra? Intuitivamente eu suspeito que não. Eu desconfio que a maior parte das empresas no Brasil recolhem apenas uma pequena parcela dos dados transacionados no país.

Daí eu comecei a levantar outros pontos, que há coisa de um ano começaram a despertar minha curiosidade:

  • Certos usos dos dados não se dão bem com o modelo de operação em lote (batch) do Hadoop. Cubos OLAP são um caso, relatórios são outro. Até porque uma coisa é coletar um volume monstruoso de dados, e outra é usar parte desse volume como fonte para um cubo;
  • Um volume muito grande de dados pode ser tratado usando-se algumas outras tecnologias, como por exemplo clusters de bancos de dados relacionais, e até mesmo clusters de bancos de dados colunares. Esse tipo de tecnologia cabe na descrição de “BigData” mas ainda não é Hadoop, e se presta a coisas como, de novo, cubos OLAP, que são um ponto fraco do Hadoop ainda;
  • Por fim, o volume de dados que justifica a adoção de Hadoop é realmente uma coisa fora-do-comum. Quantas empresas existem que lidam, que captam um volume de dados deste porte?
  • Mais ainda: das empresas que coletam um volume gargantuesco de dados crús, quantas possuem problemas que requerem uma parcela tão grande desses dados que esse subconjunto seja, por si sói, um problema de BigData?

Vocês hão de concordar comigo – como de fato concordaram na hora – que não é a maioria das empresas que possuem um volume de dados que sirvam para alguma coisa e que estejam na casa do Hadoop.

Minha intenção, eu expliquei, era conseguir deles a concordância para o seguinte ponto: “não é toda empresa que precisa usar Hadoop”. Eles concordaram, já que eu havia colocado uma dúvida razoável quanto à tecnologia necessária para o tratamento de dados na maior parte das empresas – se a maior parte de empresas de um país são pequenas e médias, e elas lidam com volumes de dados que dispensam Hadoop, então não é a maior parte de empresas que precisa de Hadoop. Simples e razoável, não?

Neste momento pedi ao Jorge que colocasse esse e-mail para a platéia:

Como resolver o problema de Hadoop dos seus usuários...
Como resolver o problema de Hadoop dos seus usuários…

Notaram como ele 1) presume que você tinha um problema de BigData que foi resolvido e 2) assume que ele não deu totalmente certo, porque ainda existe gente reclamando que não está vendo o que queria? Esse “now what?” é bem chatinho! Como assim, e agora o quê? Oras, de onde ele tirou a associação entre usuários finais e Hadoop? Quem disse que Hadoop resolveria 100% dos problemas de BI de uma empresa?

É muito chute em tão pouco espaço.

Outro ponto: contei-lhes que na apresentação da FATEC eu tive muitos espectadores de cursos hardcore de TI, como Análise de Sistemas, e Hardware. Mas eu tive a presença de vários alunos de Secretariado!

Me digam, pedi a eles, não é estranho que um curso tão “humanas” coloque no espírito do aluno inquietude o bastante para ele se arriscar em uma palestra técnica sobre Hadoop/BigData?

Mais: a lotação foi muito maior que a sala comportava, e era uma sala quase do tamanho da do TechnoTaks. Já não tinha mais espaço nem para sentar-se no chão… do corredor!! Era muita gente querendo ouvir sobre um treco que, ao cabo e ao fim, tem um uso muito restrito.

Tem uso mais restrito que Data Mining, aliás. Quase toda empresa pode se beneficiar de Data Mining. Mas poucas têm uso real para Hadoop, BigData e outros quejandos deste porte!

Vestido para detonar! Kkkkk...
Vestido para detonar! Kkkkk…

Eu participei do TT remotamente. No plano original eu estaria em um Hangout com a turma em Porto Alegre, e poderia ser visto. Por isso, considerando-se o que eu estava tramando soltar, vesti-me a caráter: com uma camiseta de Minecraft. Claro, pois se eu pretendia detonar boa parte do nosso senso-comum, nada tinha mais significado que me vestir de Creeper.

“Ora”, falei, me encaminhando para o fechamento:


“Se existe tanta propaganda sobre BigData/Hadoop, a ponto de mobilizar muita gente, e de áreas pouco relacionadas; se o assunto sempre vai estar restrito a um conjunto pequeno de empresas, com um subconjunto ainda menor de problemas aplacáveis com BigData/Hadoop, então essa exposição toda não passa de hype, de propaganda, de vapor. E se for isso mesmo, não há como sustentar o atual ritmo de destaque na mídia.”


Logo, na minha opinião,


O BigData vai sumir. Não vai demorar muito e tudo isso sobre o qual falamos não será mais um assunto tão quente, e essas tecnologias estarão de volta ao nicho de Data Mining ao qual pertencem.


Conclusão

Acabou, era só isso. Frustante? Pouco?

Eu queria ter estado lá, porque pelo pouco que eu percebi, remotamente, tinha gente louca de vontade para falar. Soube que algumas cabeças balançavam afirmativamente, outras meneavam e algumas sacudiam-se.

Só para dar um grau, eis um comentário que eu recebi no dia seguinte:


Quando começaste a falar, pensei: “o que esse maluco está dizendo?”, mas conforme foste expondo teus argumentos, vi que concordo contigo. Atualmente eu trabalho na Procergs, onde está se tentando utilizar sistemas de Big Data para análise e esse, sim, é um caso atipico, de governo, onde se processa notas fiscais de vários estados. Para se ter ideia, todas as notas fiscais são armazenadas e processadas em banco relacional SQL Server e possuem um volume de Terabytes de dados, mas que ainda assim a tecnologia que está no mercado há anos, dá conta. Parabéns pela iniciativa, conseguiste passar a mensagem! E obrigado, vou aproveitar o material. Abraço, Rodrigo Batista


E você, o que acha? Pirei de vez na batatinha? Concorda comigo? ;-)

Até a próxima! :-)

BigData

(Este post deveria ter sido publicado em 19/10/16, no dia seguinte ao evento. Não deu para completá-lo no dia, e para não ficar sem nada saiu apenas os links para download. Em todo caso, as referências a datas serão mantidas. Amanhã o blog volta ao ritmo normal.)

O conjunto das FATECs de São Paulo, capital, faz um congresso de tecnologia anual. Nesta semana está ocorrendo a décima oitava edição do evento, ao qual eu fui convidado para palestrar. A coordenação do evento me deixou livre para propor o tema e acabamos ficando com BigData. A apresentação foi ontem, 18/10/16, às 10H00min, com boa presença dos alunos e até mesmo de professores (!!). Conforme prometido a todos eles, eis aqui os links para download dos slides e notas, ambos em PDF:

Você pode clicar nestes links para download direto ou, se estiver lendo em papel ou outro meio não-digital, basta copiar os bit.lys no seu navegador. Ambos arquivos estão hospedados em uma conta [DropBox][dropbox_bitly] e, por causa disso, pode ser que apareça uma tela requisitando seu login para fazer o download. Não caia nessa! Não é preciso fazer login para baixar os arquivos: examine a tela com atenção que você vai acabar descobrindo algum texto do tipo “não obrigado, leve-me ao download”. O DropBox usa qualquer opoturnidade para ampliar sua base e por isso ele fica com essas “pegadinhas”.

O post de hoje é um resumo da apresentação. Bom proveito!

De Onde Veio?

Quando a Profa. Célia me convidou para participar do fórum ela me deixou à vontade para escolher o tema. Uau, que responsa…

Como a FATEC é uma escola técnica, de tecnologia, e voltada para o mercado profissional, eu propus apresentar um pouco sobre BigData, que tem sido um assunto “quente”. Acredito que uma palestra sobre esse tema possa abrir horizontes para vocês, alunos.

Vocês podem encontrar, pela web, toneladas de vídeos, livros e textos explicando o que é BigData, como montar uma fazenda Hadoop, porque Storm é o máximo e que Social Analytics é o bicho.

De que valeria um profissional do ramo vir até aqui e alugá-los por sessenta minutos para ler powerpoint e repetir o que existe por aí? Vocês não precisam de ninguém para se virar sozinhos, não é mesmo?

Minha meta, hoje, é dar a vocês uma visão calibrada do quê, de fato, essa tecnologia significa para o mercado de TI, o que ela pode fazer e para onde eu, Fábio, acredito que esse barco vai.

Com isso eu espero dar a vocês uma vantagem em sua vida profissional, em sua busca por emprego, que – todo mundo está careca de saber – não está fácil para ninguém, certo? ;-)


Notem que, exceto pela minha certificação Pentaho, eu não tenho nenhum diploma de BI ou pós-graduação em DW nem nada do gênero. O que eu vou contar aqui eu aprendi na lida diária, no contato com problemas e soluções que afligem toda empresa moderna.


Eu vou mostrar os conceitos do Hadoop em alto nível, sem entrar nos detalhes técnicos, e daí explorar as possibilidades que surgiram, que promessas estão sendo feitas e o quê é besteira nisso tudo.

O Céu é o Limite

Todo computador funciona da mesma forma: lê dados de algum lugar, realiza alguma operação e manda o resultado para algum outro lugar.

Computador conceitual.
Computador conceitual.

Um computador nada mais é que um circuito eletrônico. Aliás, era mecânico, daí a a válvula foi inventada e deu origem ao computador eletrônico. Mais tarde ela foi substituída por transístores, que foram combinados em circuitos integrados (CI), que começaram grandes, com poucos componentes. Conforme a eletrônica se sofisticou, a quantidade de transístores por CI aumentou, elevando a velocidade de processamento.

Exemplo de circuito integrado: o famoso 555.
Exemplo de circuito integrado: o famoso 555.

Essa tendência poderia ir adiante para sempre, se não fosse um porém: a Física, a própria Natureza, interpõe certos limites.

A resistividade de um condutor aumenta conforme sua secção diminui. Logo, com circuitos integrados na casa dos milhões de transístores em menos de um centímetro quadrado, os circuitos ficam muito pequenos, o que faz com a corrente através desses circuitos gere cada vez mais calor. Para piorar, o aquecimento em si também afeta a condutividade, “somando agressão à injúria”1. No final das contas, a redução de escala é barrada por um limite prático.

E mesmo que o problema de condutividade seja resolvido usando, digamos, supercondutores, efeitos quânticos limitam o tamanho dos transístores.

Se mesmo assim conseguíssemos superar essa barreira, lá no fim acabaremos trabalhando com átomos individuais, e não dá para ficar menor que um átomo. Dá para usar átomos menores, claro, mas trocar o material do chip nunca vai remover essa barreira, vai apenas empurrá-la para mais longe. E mesmo que pudéssemos avançar ininterruputamente crescendo o poder da CPU, estaríamos limitados velocidade de acesso de RAM, discos, redes.

Todo computador sempre terá um limite de capacidade e velocidade de processamento.


Os maiores computadores monolíticos, ou seja, cujo software é executado integralmente na mesma CPU, são os mainframes. O SERPRO usa mainframes para quase todos os processamentos de altos volumes, como tratamento do IR e o SISCOMEX (o sistema aduaneiro da RFB.)

Mainframes são o limite da máquina monolítica.
Mainframes são o limite da máquina monolítica.

Entretanto, enquanto a capacidade de cada máquina ficava cada vez maior, com valores proporcionais, tecnologias que se tornavam mais ordinárias se tornavam cada vez mais baratas. Ou seja, as grandes máquinas continuam caras como sempre, mas as máquinas baratas estão ficando cada vez mais poderosas, e isso abre uma possíbilidade interessante: paralelizar.

Custo do poder de processamento não cresce linearmente.
Custo do poder de processamento não cresce linearmente.

Superman & Batatas

Pense no seguinte: o Super-Homem é o cara mais forte e rápido do mundo. (Please, deixem o Flash fora disso…)

Suponha que um homem normal leva um minuto para descarcar uma batata, e que o Super-Homem leva, vai, um segundo. Isso quer dizer que ele pode descascar sessenta batatas no tempo que um homem normal descasca uma – e só! Nada além disso! Ele não consegue ficar mais rápido.

Bom, basta juntarmos 120 homens normais e teremos o dobro da velocidade do Super-Homem! Super-homens não existem por aí dando sopa, mas temos sete bilhões de humanos normais. Isso significa que, botando todos para descascar batatas, temos uma velocidade média de 116 milhões de batatas descascadas por segundo (million-peeled-potatoes-per-second, ou mppps kkkk…) Considerando-se que a produção mundial de batatas é de mais ou menos 1,88 trilhões de batatas (dados de 2013, supondo 200g de peso médio por batata), levaríamos aproximadamente 16.200 segundos para descascar tudo, ou quase cinco horas – menos de um dia de trabalho. A mesma tarefa feita pelo Super-Homem levaria mais de 520 milhões de horas, sem parar, ou quase um milhão e meio de anos!!

O mesmo pode ser feito com o processamento de dados: se uma máquina, sozinha, levaria um tempo X para realizar um processamento qualquer, duas máquinas iguais realizariam o dobro do processamento no mesmo tempo, ou poderiam completar a tarefa na metade do tempo.

Se podemos fazer isso, então nosso problema muda de figura: já não é mais como construir um computador super-rápido, mas sim como dividir nosso trabalho em pedaços iguais e processar esses pedaços em muitos computadores medianamente rápidos.

Construa seu próprio supercluster!
Construa seu próprio supercluster!

Bom, Bonito & Barato

E foi nesse problema que vários pesquisadores passaram a trabalhar na década de 2000. Em 2003, para vocês terem um idéia, ainda não existia nenhum “kit” pronto para processamento distribuído. Já existiam clusters, claro, mas eram coisas como o Beowulf, que nada mais eram que um monte de máquinas na mesma rede e alguns pacotes de software para ajudar a paralelizar a execução de determinado programa.

Nesse cenário o Internet Archive e a University of Washington se lançaram à busca de uma tecnologia que melhorasse a indexação de páginas web. Depois de algum tempo a equipe conseguiu produzir uma arquitetura clusterizada que dava uma performance superior em indexação, ainda que bem mequetrefe e instável, que acabou sendo chamada de Nutch. Segundo eles, era preciso uma pessoa ficar literalmente ao lado da aplicação o tempo todo, consertando os erros e defeitos.

… mas ao mesmo tempo outra empresa, uma com ainda poucos anos de vida, investia pesado em coisa semelhante.

Essa empresa, que não era ninguém menos que a Google, lançou dois papers, em 2003 e 2004, que se tornaram a fundação do que viria a ser o ecossistema de BigData. O primeiro falava sobre um cluster de sistemas de arquivo massivo, automatizado, o Google File System. O segundo propunha um modelo de programação para processamento paralelo, e expandia conceitos de uma tecnologia chamada programação funcional, desenvolvida no final da década de 1950 a partir dos conceitos de Cálculo Lambda, que por sua vez é da década de 1930. Esses conceitos resultaram em um framework, que é o segundo paper publicado, chamado de MapReduce. Esse paper mostrava como usar as operações funcionais de map() para distribuir a operação e reduce() para consolidar os resultados.

O gênio saíra da garrafa. :-)


A história toda é bem interessante, e vale a pena conhecer: clique aqui para ler a história inteira.


Eram os primeiros anos do Google, e uma outra empresa dominava então: o Yahoo. Buscadores de web (Google, Yahoo etc.) ganham dinheiro vendendo links e anúncios. Quanto mais páginas indexadas, maior sucesso nas buscas, e com maior sucesso, mais gente aparece querendo buscar. Quanto maior o público, a venda de anúncios cresce em número e valor.


Mais gente usando = maiores oportunidades de negócio.

Para aumentar o público, melhore seu produto = indexe mais.


Em 2006 o Yahoo investiu na reconstrução de seu motor de busca e começaram um projeto que incluíu os criadores da tecnologia que o Internet Archive estava desenvolvendo, o Nutch. O Nutch, que ainda existe aliás, era montado usando os conceitos do GFS e MapReduce. Quando o Yahoo encampou o projeto eles decidiram dividi-lo em dois pedaços: um webcrawler, que permaneceu com o nome Nutch, e uma infra-estrutura de clusterização, que englobava os pedaços trazidos do GFS e MapReduce. Já que eram tecnologias essencialmente diferentes, essa separação fazia todo sentido.

E que nome dar a este projeto?

Doug Cutting, que assumiu o projeto no Yahoo, nomeou-o a partir do elefante de pelúcia que seu filho chamava de, adivinhou, hadoop. Segundo Cutting, esse foi um bom nome porque era simples, sonoro, fácil de lembrar e sem nenhum significado em particular.

Ti fofu!!!! Had'oop!
Ti fofu!!!! Had’oop!

E o Que é BigData?

BigData é Hadoop, Hadoop é BigData. Ao menos no contexto geral, comercial, essa é a relação entre a tecnologia e o conceito: a tecnologia Hadoop ajudou a firmar o conceito de BigData, que por sua vez ganhou relevância conforme o Hadoop era aplicado em mais e mais casos de uso.

Em outras palavras, a maturação do Hadoop trouxe solução a uma classe de problemas normalmente fora do alcance. Esse sucesso turbinou o comércio dessas soluções, que acabaram sendo chamadas de BigData.

Hadoopen! Haduken! Shoriuken! Spining Round Kick-u-ken! Barbie e Ken!
Hadoopen! Haduken! Shoriuken! Spining Round Kick-u-ken! Barbie e Ken!

A certa altura o Hadoop ganhou status de cool, de pop, e caiu no gosto tanto dos capitalistas de risco. Daí surgiu uma leva de startups focadas em Hadoop, seus serviços, usos e todo o ecossistema tecnológico. E também caiu na graça da imprensa de tecnologia, que achou um nicho cheio de jargões fresquinhos e enigmas suficiente para uma década de reportagens.

Estamos agora em 2016 e, finalmentem, a força das buzzwords BigData/Hadoop está começando a esmaecer. Será preparação do palco para as próximas, como IoT?

O primeiro uso da expressão BigData foi em 1997, no artigo Application-controlled demand paging for out-of-core visualization para designar dados que não cabiam na memória do computador ou mesmo no disco. O resto é história: Hadoop acabou irreparavelmente associado ao termo. Apesar disso houve (e há) outras tecnologias para resolver problemas de “dados que não cabem na memória” do computador (e quase todas giram ao redor de clusterização.)

Por exemplo, existem bancos de dados especiais para aplicações computacionais intensas (muita conta e muito dado), como o Vertica e o Teradata. Ambos armazenam os dados de maneira diferente da de um banco relacional ordinário, e montam-se em clusters. Isso permite que distribuam as contas pelos nós, usando conjuntos locais de dados que depois se integram nos resultados em um nó mestre – que é exatamente a mesma idéia do Hadoop.

Pelo que vimos do histórico na primeira seção, existe um limite para o aumento da capacidade de processamento monomáquina, e portanto existe uma categoria de problemas que não pode ser tratada, dentro de tempos razoáveis, por esta arquitetura.

Resumindo:


Sempre que sua necessidade de processar dados extrapole a capacidade de uma só máquina e um tempo razoável, você está com um problema de BigData.


Podemos colocar de uma forma mais prática:

BigData é uma tecnologia de cluster de máquinas COTS2 para coleta e processamento de um grande volume de dados, dentro de um tempo razoável.

  • “Grande” é impreciso: qualquer coisa maior do que uma máquina simples consegue dar conta;
  • “Tempo Razoável”: mais imprecisão. Um tempo tal que os resultados são obtidos antes de tornarem-se inúteis.

Por exemplo, pode ser que os dados caibam todos no maior HD que você pode comprar, mas levariam anos sendo processados só para obter a primeira resposta – imagine as seguintes. Se você precisa da resposta em meses, anos é muito tempo. Se precisa de horas, semanas é muito tempo, e assim por diante.

Só que essa definição não é comercial, ela não “vende”. Foi quando começaram a surgir os acrônimos, sempre em tuplas de Vs, com cada vez mais vês: 3, 4, 5…

A primeira foi 3Vs: Volume, Velocity, Variety.

Alguns adicionaram um novo V, de veracidade, que queria dizer “qualidade”. Ou seja, não bastava acumular lixo, tinham que ser dados verdadeiros.

Outro colocou um V para valor, chegando a 5Vs, argumentando que se você não extrair valor dos dados, então não era BigData. E assim por diante.


Eu não consigo para de associar VVV com vai e volta, viu?, he he, ou com as variações. Por exemplo, meu primo usava 5 Vs: vai e volta voando, viu v******* ? :-D


Essa é a parte chata do mundo de TI, que tenta transformar conceitos e softwares em produtos com o mero balançar de beiços. Não caiam nessa! Só porque alguém escreveu uns slides (como eu fiz), montou um produto e está vendendo (que é quase o mesmo que estou fazendo…) não significa que ele está transmitindo um fato novo, uma verdade inegável ou algo supimpa. Use sua inteligência para filtrar o mundo.

No fundo tudo isso queria dizer a mesma coisa: problemas tão grandes que precisam de mais capacidade que uma só máquina pode fornecer.

Mas, ora vejam vocês, existem muitas opções para atender essa categoria de problemas!! Para começo de conversa existem máquinas SMP e multi-core. Existem clusters de bancos de dados, existem tecnologias de bancos de dados alternativos (como o Teradata ou o Vertica, que são colunares.)

Hadoop é uma destas tecnologias, que acabou ganhando fama por que seus limites situam-se muito acima dessas outras opções. (Mais imprecisão…)

Se precisássemos classificar os problemas pela capacidade de processamento requerido para resolvê-los, teríamos algo como isso:

  • Problemas normais: monomáquina;
  • Problemas grandes: Clusters de bancos (tradicionais e depois colunares;)
  • Problemas extremos: Hadoop.

Confuso? Complicado? Então guardem apenas isso:


BigData = Hadoop

Hadoop = BigData

BigData é a tecnologia de cluster de máquinas COTS2 para armazenamento e processamento de um volume de dados maior que cabe em uma só máquina, antes de o resultado ficar inútil.


Como sempre, essa definição é a minha, a partir do que eu aprendi. Você pode contestá-la (adoraria ouvir) ou achar outras. Como quase tudo em BI, vale a que você preferir. ;-)

Botando Para Rodar

Daí vem você e me diz: “Fábio, entendi patavinas do que você falou. Por analogia, algum destes temas tem a ver com o Hadoop/BigData?”

  • Inteligência de Negócios? Não mais que um banco de dados normal;
  • Armazém de Dados? De novo, mesma resposta (sem contar que projetos de DW incluem qualidade de dados e valor;)
  • PostgreSQL, Oracle etc? Esses são os famosos bancos relacionais, o que são bem diferentes – a começar pela forma de operação;
  • Sistemas transacionais (OLTP)? Os sistemas, em si, usam bancos transacionais. Como Hadoop é, grosso modo, um sistema que opera em lote, a resposta é não;
  • Linguagens de Programação? Não, nada a ver. Você pode implementar rotinas de MapReduce em algumas linguagens, mas Hadoop não é uma linguagem. Só para constar, programas MapReduce nativos são escritos em Java;
  • A Nuvem? De uma forma oblíquoa e não-relacionada, talvez. De maneira direta, nada a ver;
  • A Nuvem é BigData? Mesma resposta.

Se você precisa montar uma analogia para entender, meu caro, você está no sal, porque não existia nada como Hadoop antes. Pelo menos nada que fosse comum o bastante para ser um senso-comum. Sabe o que é Lustre? Já ouviu falar em MPI ou Beowulf? Pois é, Hadoop é uma mistura dessas coisas. ;-)

E todo mundo precisa de Hadoop? Ou de BigData? Não, claro que não. São raras as tecnologias que são aproveitadas indistintamente por qualquer organização. Hadoop não é uma dessas. Hadoop/BigData é uma tecnologia de nicho.


Veja que Hadoop(=BigData) é totalmente implementando com Software Livre. Logo qualquer um pode usar como e para o quê quiser, sem custos de licenças.


Como saber se você precisa? Fácil: sua organização enfrenta algum problema causado pelo mero volume dos dados? Se tem, pode ser que precise. Se não, então nem se dê ao trabalho. Simples assim.

Claro que podem existir problemas que você ainda não sabe que tem, e que podem vir a ser tratados com Hadoop, mas esses fazem parte de um conjunto mais ou menos pequeno. Vejamos um pouco sobre isso.

É Online?

Hadoop foi projetado para ser operado por meio de programas MapReduce. Isso é qualquer coisa, menos online. Problemas online, em geral, dizem respeito a registrar transações e hoje a melhor opção para isso ainda são bancos de dados relacionais. Em alguns casos, um mainframe é a única solução.

Por exemplo, caixas do Pão de Açúcar eram operadas por mainframe. Não sei como é hoje, mas até meados da década passada cada checkout do Pão de Açúcar era ligado a um mainframe, com operações de enorme volume de dados acontecendo em tempo real.

Isso não quer dizer que essa possibilidade está barrada ao Hadoop. Muito pelo contrário: existe muita pesquisa e desenvolvimento sendo conduzido para reduzir e até eliminar os overheads do Hadoop e colocá-lo em “modo online”. Em última análise, esse caminho vai nos levar até o ponto de processamento transacional, operacional.

Mas, hoje e pelos futuro próximo, Hadoop é algo que opera em batches, não online.

Se você precisa de operações online em grande volume (OLTP), como ERP, invista em grandes computadores e até mesmo em mainframes. Por enquanto, Hadoop não é uma tecnologia para esse tipo de aplicação. Um dia, quem sabe?

DataLake?

Esse é um conceito idealizado pela própria Pentaho. A meta deles era popularizar o uso do Hadoop, e com isso alavancar o consumo de Pentaho, já que esse tem enormes facilidades para lidar com Hadoop.

Em tese, DL é um substituto para um Data Warehouse, um armazém de dados. O problema é que, hoje, Data Lake é uma coisa bagunçada e crua. Para a empresa consumir os dados de um Data Lake é preciso que um profissional trabalhe os dados que estão lá e construa outras estruturas, normalmente fora do Hadoop, que serão consultadas pela comunidade de usuários da organização.

Só que ao fazer isso caímos de novo no modelo de Armazém de Dados, que faz exatamente a mesma coisa.

E se a dita empresa quiser se livrar desse profissional intermediário, ela terá que deixar cada cliente, cada usuário, construir seus próprios usos. O que vai requerer que esses usuário conheça não apenas o negócio, mas também conheça intimamente os dados – ou nada vai sair!

No fundo, DL, tal como se apresenta hoje, é uma tentativa de criar um produto comercial, de linha de frente, com um insumo que só funciona bem em certas situações, mas não em todas. Atualmente eu não vejo nenhuma vantagem nele – especialmente se considerarmos Data Vault.

Machine Learning

O termo Machine Learning é um tipo de expressão guarda-chuva para acomodar um monte de tecnologias. Grosso modo, Machine Learning, ou Knowledge Discovery etc., são termos relacionados à área de Data Mining.

Data Mining é o processo – não o software! o processo! – de examinar dados em busca de um modelo matemático que permita usar o passado para prever o futuro.

Um exemplo simples é a previsão do tempo: depois de analisar os dados meteorológicos acumulados por décadas, fomos capazes de construir uma equação – um modelo matemático – que dá a probabilidade de ocorrer ou não chuva em um determinado lugar, em um determinada dia e hora.

Podemos aplicar o mesmo tipo de técnica a coisas mais prosaicas como sugerir um produto para nosso cliente, oferecer um desconto para ajudá-lo a fazer uma compra ou negar qualquer desconto. Podemos analisar os dados de tráfego em uma cidade e descobrir uma sequência de acionamento de semáforos para reduzir congestionamentos. Podemos analisar os caminhos produtivos de uma fábrica e mudar seu layout para reduzir custos, aumentar a produtividade ou prevenir defeitos.

Machine Learning é justamente uma técnica de descoberta de um modelo que explique os dados. Como volume é uma variável crítica para o sucesso de técnicas de ML, Hadoop e BigData têm sido associados a ML, mas não são, de forma alguma, sinônimos.

NoSQL?

NoSQL já foi descrito como not SQL e mais recentemente como not only SQL, e refere-se de maneira geral ao mecanismo de consulta de uma base de dados. Hoje entende-se por NoSQL como uma expansão nas técnicas de manuseio de dados em bancos para além de mero SQL.

Hadoop, que é alimentado por operações de transferência de arquivos e consultado por MapReduce, é considerado uma tecnologia NoSQL. Entretanto, NoSQL não é sinônimo de Hadoop, da mesma forma que não é sinônimo de MonetDB, CouchDB e outros famosos bancos NoSQL.

Curiosamente, há um grande esforço para conseguir “equipar” Hadoop com SQL! Vai entender…

IoT?

Internet das Coisas, pelo que tudo indica, é a próxima BuzzWord a estourar nas paradas. E aí, qual é a relação entre IoT e Hadoop/BigData?

A visão trazida pelo conceito IoT diz que todos os eletrodomésticos e traquitanas terão, cada um, seu próprio IP e trocarão dados entre si e com computadores. Para que propósito, exatamente, é um tópico à parte. O que nos interessa, hoje, é notar que o volume de dados estima-se que será gerado é muito (muito (muito!)) maior que as maiores plataformas atuais trabalham. Logo, analisar esses dados será tarefa para Hadoop – até mesmo transacioná-los talvez venha a ser feito por uma plataforma similar.

Logo, IoT não é sinônimo de BigData, ainda que com certeza possuam uma forte ligação.

Que Problemas Resolve?

Vocês hão de concordar comigo que essa pergunta é um pouco boba. Afinal, se BigData trata de processar dados que não cabem na RAM ou no disco local, então BigData (que é o mesmo que falar “Hadoop”) resolve problemas… com dados demais!

O critério para saber se você – sua empresa, sua organização – precisa de uma solução de BigData não é o tipo de negócio, o porte da organização ou o alcance dela. O critério é ter coisa demais para processar e, mesmo com uma máquina maior, ainda continuar a ser coisa demais, ou nunca ser rápido o bastante.

Por isso, se algum fornecedor te pestear para oferecer BigData, ponha um pé atrás. Assista a apresentação dele e pergunte-se sempre, o tempo todo, “não dava para fazer com ( ) um banco tradicional? ( ) um banco colunar? ( ) um cluster? ( ) alguma outra coisa mais fácil ou barata? ( ) etc?”.

Voltando ao ponto, graças a paralelização massiva, Hadoop/BigData arquiva e processa dados com uma grande velocidade. Que categoria de problemas conhecemos, ao menos em BI, que causa grande processamento?

Relatório? Não, nem de de longe.

OLAP? Mais ou menos, talvez, mas via de regra, não.

Painéis? Menos ainda…

Data Mining?

Isso mesmo: Hadoop barateia Data Mining. Sempre que você precisar de Data Mining, e a performance do seu parque estiver abaixo do que você precisa, adotar Hadoop pode melhorar sua vida com uma relação custo-benefício sensivelmente melhor que outras tecnologias. Mas cuidado: melhor relação custo benefício olhando apenas hardware e software! Sem mão-de-obra qualificada, pode ser que seja tão difícil montar e operar um cluster Hadoop que outras soluções mais caras podem ter, no final, uma relação custo-benefício mais interessante!


SEMPRE considere a necessidade, o custo e a disponibilidade de mão-de-obra especializada!! SEMPRE!!!


E, claro, Hadoop é uma boa opção toda vez que for preciso arquivar um grande volume de qualquer coisa que não seja usado online, como arquivos, históricos, logs etc.

Profissional de BigData?

Gostou do que viu? Tem interesse em saber no quê trabalha, quanto ganha e que sofrimento passa um profissional dessa área? Enfim, é a sua vida… ;-)

Há duas grandes áreas: Infra-estrutura e Aplicação em si.

Como o próprio nome diz, montar e sustentar a infraestrutura de um cluster Hadoop requer conhecimento multidisciplinar: redes, sistemas operacionais, Linux (fundamental!) e assim por diante. Até ajuda saber programar Java, ou no mínimo entender o assunto, mas não é um pré-requisito. Invista em cursos de qualidade, começando por um sobre Hadoop e depois avançando nos sub-tópicos. Isso vai te dar capacidade para entender os problemas que assolam ambientes Hadoop e a fazer otimizações mais sofisticadas, te distinguindo no mercado de trabalho.

Agora, você gosta mesmo é de sujar as mãos escovando bit até deixar um algoritmo tinindo de brilhante, seu caminho no Hadoop é praticamente o mesmo de um Analista de Data Mining: é obrigatório conhecer bem e ter experiência com Estatística e Matemática. A partir daí é necessário saber transformar esse conhecimento em modelos matemáticos a partir dos dados disponíveis, o que é feito usando-se o ferramental de Data Mining, como R, RapidMiner, SAS Enterprise Miner, SPSS, Python e/ou similares.

Mas todo esse conhecimento é apenas para sua fundação. O profissional que vai fazer a diferença, que vai elevar seu salário à estratosfera é aquele que tiver visão de negócio e habilidades de desenvolvedor. É aquele que souber entender o negócio da empresa e traduzir aquilo em perguntas aos dados, e a moldar as respostas em conceitos que possam ser transformados em algoritmos.

Esse sempre foi, é e sempre vai ser O cara. ;-)

Hoje em dia essa função leva um nome vistoso, para o qual eu sempre torço o nariz: Cientista de Dados. No fundo, porém, o mesmo de sempre: Analista de Data Mining.

Conclusão

Meu propósito era ajudar os alunos da FATEC a entrar com o pé direito no tema. Não tenho como avaliar o resultado e saber se eu atingi ou não esse objetivo. O feedback dos alunos foi bastante positivo, e a recepção foi boa. No mínimo, portanto, eu atendi a um anseio deles.

Uma coisa que me chamou a atenção foi o fato de ter ali não apenas cursos de TI em geral, mas também alunos do curso de Secretariado Executivo. Porquê? Oras, se tem uma coisa que é distante de BigData, em uma empresa, é a disciplina de administração/secretariado/gestão em geral. Mesmo que se argumente que BigData é o futuro e que logo a estratégia da empresa vai estar calcada em resultados obtidos graças à essas tecnologias, me parece um exagero colocar o assunto em uma faculdade tão distante de TI quanto Secretariado. Na minha opinião, é o mesmo que ensinar bancos de dados transacionais para o pessoal de Biblioteconomia porque usam sistemas OLTP.

Essa observação alimentou minha palestra seguinte, na PUC do Rio Grande do Sul. Mas isso é o assunto do próximo post.

Até lá! ;-)


  1. Uma expressão inglesa, “to add insult to injury” 
  2. Common-Of-The-Shelf, ou “de prateleira”. Significa coisas padronizadas, baratas – algo como uma commodity