Estimativas – Geek BI

Publicado em 11/03/201710/03/2017 por Fábio de Salles

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 – afff – Data 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.

Quanto tempo de coletas diárias esse HD comporta?
Com que velocidade ele está enchendo?
Quando ele vai estar a 75% da capacidade?
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:

Quanto tempo de coletas diárias esse HD comporta? R.: 600 GB / (115 bytes/dia) = 5.6e9 dias ~ 15.3 milhões de anos;
Com que velocidade ele está enchendo? R.: 115 bytes/dia.
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;
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:

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;
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;
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;
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;
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.

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á:

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:

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;
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.

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

Publicado em 02/11/2016 por Fábio de Salles

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

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!

Publicado em 17/02/201617/02/2016 por Fábio de Salles

Relatórios com Metamodelos – Complemento

Semana passada eu mostrei como montar um relatatório a partir de um metamodelo. Hoje eu vou encerrar o assunto com mais algumas dicas.

Concepts

Um dos pilares de um bom relatório é a qualidade da apresentação, e nesta qualidade inclui-se a consistência, ou seja, dados do mesmo tipo possuem a mesma aparência, ou no mínimo possuem algum padrão.

Um relatório ordinário, construído a partir de um SQL, tem seus campos formatados livremente. Se por um lado isso é bom, já que dá espaço irrestrito para o autor do relatório passar sua mensagem, por outra é ruim, porque obriga esse mesmo autor a uma formatação tediosa, repetitiva. Fora o aborrecimento de repetir sempre a mesma coisa, ainda podemos acabar esquecendo ou mudando algum detalhe ao longo do tempo.

Um concept, ou conceito, é um padrão de formatação definido dentro do metamodelo e obedecido integralmente pelo PRD. Acesse esta página para obter mais informações sobre concepts.

Vamos fazer um exercício: criaremos um conceito de texto destacado e aplicaremos ao relatório do post anterior. Primeiro, abrimos o PME e carregamos o metamodelo do Beltrano OLTP. Em seguida acessamos o editor de conceitos (concept editor):

Nele clicamos sobre o conceito Base e depois clicamos no sinal de + no canto superior direito dessa seção. Uma janela se abrirá, pedindo o nome do conceito – eu eu chamei de Destaque. Como criamos o novo conceito a partir do Base, Destaque herdou as propriedades deste. Caso contrário, se tívéssemos criado um conceito na raiz, ele teria nascido vazio e precisaria receber todos os atributos prentendidos.

Com o conceito Destaque selecionado, clique no elo ao lado do atributo Color of Text. Isso quebra a herança e nos permite redefinir aquele atributo, mantendo o restante:

Novo conceito: destaque (fonte em cor vermelha).

Dê ok e, de volta à interface principal do PME, localize um campo na camada de apresentação – Neste exemplo eu selecionei Autor. Clique com o botão da direita sobre ele e selecione Set Parent Concept… para escolher o conceito desejado. Selecione Destaque na janela que se abrirá e Ok para aplicar.

Feito! Quando o campo Autor for usado no relatório, ele aparecerá em cor vermelha, em destaque:

Notou a festa do caqui que está o layout do relatório, na parte de cima da figura? Mas como o PRD vai respeitar o definido no metamodelo, o relatório vai sair arrumadinho, apenas com o nome do autor em vermelho!

Outro exemplo: digamos que precisamos formatar a coluna da direita como um valor monetário, usando a máscara R$ #.###,00. Alteramos ou criamos um conceito no metamodelo, exportamos e reaplicamos o metamodelo à consulta previamente criada:

Altere um conceito para alterar o relatório.

Reaplicar o metamodelo a um relatório aberto no PRD é meio chato. Como o PRD não embute o metamodelo no relatório, bastaria purgar o cache ou fechar o relatório e recarregá-lo para forçar o PRD a reler o XMI. Por puro e simples hábito, eu apelo para força bruta: simplesmente apago e recrio a fonte e as consultas (apelando para um copy-paste básico, já que ninguém é de ferro…)

Para relatórios publicados no BA Server não é preciso nada: basta republicar o modelo a partir do PME, ou recarregá-lo no quadro Manage Data Sources e já está valendo. A série 5 do BA Server veio com purga e recarga automática de metamodelos na republicação.

Só essa simplicidade e praticidade, na minha opinião, já é o bastante para fazer valer a pena usar um MQL ao invés de SQL.

Prompts

Um recurso crucial para relatórios são os “prompts”, ou filtros, que permitem ao usuário escolher uma determinada fatia dos dados para apresentação. O PRD oferece esse recurso sob o nome de parameters. Um parameter – ou prompt – é uma variável preenchida pelo usuário em tempo de execução, que entra na consulta como algum tipo de restrição. Por exemplo, a consulta abaixo retorna todos os clientes de um determinado “tipo”, filtrando a consulta pelo conteúdo do prompt tipo_selecionado:

    SELECT cliente, estado, cidade
    WHERE tipo = ${tipo_selecionado}

Não é um mecanismo complicado, mas não é trivial o bastante para eu mostrá-lo aqui completamente. Assistam este vídeo que verão como fazer um prompt.

Quando usamos uma consulta MQL, de metadados, aplicar a restrinção é um pouco mais simples. Os passos são esses:

Construa um relatório com MQL, como o que fizemos no post passado;
Crie uma consulta (MQL, SQL, tanto faz) que retorne a lista de opções que o cliente pode selecionar;
Crie o parâmetro no PRD usando essa consulta como fonte;
Volte para a consulta principal e, usando a interface de criação de consultas, adicione o filtro e insira o parâmetro.

No nosso caso vamos filtrar o relatório de vendas do Alexandre por UF.

Primeiro, construímos uma consulta em MQL que traz a lista de estados:

Lista de UFs criada no construtor de consultas MQL.

O MQL dessa consulta é:

    <mql>
      <domain_type>relational</domain_type>
      <domain_id>BeltranoOLTP</domain_id>
      <model_id>BV_MODEL_1</model_id>
      <model_name>Beltrano OLTP</model_name>
      <options>
        <disable_distinct>false</disable_distinct>
        <limit>-1</limit>
      </options>
      <selections>
        <selection>
          <view>BC_CLIENTES_PF</view>
          <column>BC_ESTADOS_UF_2</column>
          <aggregation>none</aggregation>
        </selection>
      </selections>
      <constraints/>
      <orders>
        <order>
          <direction>asc</direction>
          <view_id>BC_CLIENTES_PF</view_id>
          <column_id>BC_ESTADOS_UF_2</column_id>
        </order>
      </orders>
    </mql>
    </pre>

Construímos um paramater alimentado por essa consulta, chamado UF:

Novo parâmetro UF, alimentado pela consulta Query 2 do metamodelo.

Depois inserimos esse parâmetro, UF, na consulta que popula o relatório: colocamos a coluna que vai ser filtrada na seção constraints e aplicamos uma igualdade para o parâmetro.

Inserindo o parâmetro na consulta principal com o editor de MQL.

O truque é envolver o parâmetro em chaves, { e }. Com isso o construtor de consultas reconhece que se trata de um parâmetro e não de um valor ordinário, e ajusta a consulta automaticamente. A título de comparação, observe o filtro para pegar apenas as vendas do Alexandre.

Ao adicionar um nome cercado por { e } nos filtros, o construtor de consulta realiza duas coisas:

Define um parâmetro no início da consulta

<mql>
  <domain_type>relational</domain_type>
  <domain_id>BeltranoOLTP</domain_id>
  <model_id>BV_MODEL_1</model_id>
  <model_name>Beltrano OLTP</model_name>
  <options>
    <disable_distinct>false</disable_distinct>
    <limit>-1</limit>
  </options>
  <parameters>
    <parameter defaultValue="XX" name="UF" type="STRING"/>
  </parameters>
  <selections>
    <selection>
      <view>BC_PEDIDOS</view>
<...restante da consulta...>

E usa esse parâmetro na seção conditions:

<...começo da consulta...>
  <constraints>
    <constraint>
      <operator>AND</operator>
      <condition>CONTAINS([BC_PEDIDOS.BC_VENDEDOR_NOME_COMPLETO];"Alexandre")</condition>
    </constraint>
    <constraint>
      <operator>OR</operator>
      <condition>[BC_CLIENTES_PJ.BC_ESTADOS_UF_3] = [param:UF]</condition>
    </constraint>
  </constraints>

Ao rodar o relatório o PRD cria e apresenta um controle do tipo drop-down, populado com a lista dos estados. Sempre que um estado é selecionado, o relatório é automaticamente filtrado:

Um bom uso dessas possibilidades é criar relatórios que se adequam a cada usuário: basta usar o parâmetro pré-definido env::username para filtrar a consulta pelo nome do usuário na plataforma desde que esse usuário possua um nome igual registrado no banco de dados.

Por exemplo, se eu registrar no Pentaho BA Server os vendedores com o mesmo nome que possuem no Beltrano OLTP, eu posso filtrar os dados montando uma constraint do tipo Vendedor CONTAINS {env::username}.

Experimente!

8.3 Segurança

Por fim, mas não menos importante, um metamodelo pode restringir o conteúdo de uma consulta em função das permissões de acesso – controle de segurança – dos dados.

Como sempre, a idéia é simples: definimos um filtro de dados no metamodelo que usa o nome do usuário e, eventualmente, seu papel, para montar um controle de exibição baseado no controle de acesso.

Como fazer:

No Pentaho BA Server, usando o papel de administrador, registre todos seus usuários. Eu fiz isso com os usuários da Beltrano;
Com Pentaho Metadata Editor edite o metamodelo e registre um filtro no nível do modelo de negócio, seção Data Constraints: qualquer consulta contra esse modelo de negócio vai embutir aquele filtro automaticamente. Salve e publique o metamodelo no servidor;
Registrando filtro no PME.
No PRD basta remover qualquer filtro local. Por exemplo, eu removi o filtro de usuário “Alexandre”, deixando o relatório trazer dados de todos os vendedores, indistintamente. Salvei e publiquei o metamodelo.

Feito! :-)

Para testar, acessei a plataforma com duas contas: Fábio e Alexandre. Como o relatório consome metadados, e os metadados são completamente filtrados por meio do atributo Data Constraints no Business Model, os dados apresentados já estão filtrados.

Resultado do filtro por controle de segurança.

8.4 Conclusão

“Nossa, Fábio! Que maravilha!”, dirão vocês, “e não tem nenhuma desvantagem?”

Sim, tem: justamente adicionar uma outra camada para manutenção. Se usamos apenas SQL, qualquer alteração no banco entra em efeito imediatamente para o relatório. Se usarmos um metamodelo vamos precisar atualizar a camada de metadados antes de poder sequer testar as mudanças no PRD. Fazer uma pequena alteração na formatação pode forçar o analista a quebrar o vínculo do campo com a metaconsulta, perdendo a vantagem do modelo centralizado, ou então obrigar a uma atualização do metamodelo, cascateando a publicação de uma nova versão.

Há uma segunda desvantagem, mas é mais sutil e, talvez, pior: aparentemente não há como fazer UNIONs! Isso não é um problema para modelos bem comportados, mas modelos como o do Beltrano – que nem é tão exótico assim – se quebram quando tentamos fazer certas combinações numa só consulta. Por exemplo, no modelo transacional, não é possível escrever um único SQL que traga todos os clientes PF e PJ. É preciso duas consultas, coladas a posteriori com UNION, para então chegar ao conjunto completo. E eu não achei como fazer isso com MQL.

Ou seja, as vantagens de uso de um metamodelo vêm com um preço: um processo de desenvolvimento com mais alguns passos. Se isso vai compensar no final é uma questão respondida projeto a projeto.

Até a próxima! :-)

Publicado em 03/02/201602/02/2016 por Fábio de Salles · 6 Comentários

OI vs BI – O Treinamento e o Rendimento

Há duas semanas eu coloquei minha interpretação do conflito entre as necessidades operacionais e estratégicas na exploração dos dados de uma empresa. Um dia antes de eu publicar aquele post, com ele já praticamente completo, me ligou um amigo de uma firma de grande porte, com um problema muito interessante: como medir o impacto de um treinamento sobre a empresa? Como saber que esta ou aquela iniciativa de educação corporativo deu algum resultado? Como descobrir de quanto foi esse resultado?

Que sorte! Sempre que eu começo a teorizar demais eu fico receoso de estar viajando na maionese e procuro evidências que corroborem ou neguem as minhas hipóteses, e esse caso vem bem à calhar porque demonstra claramente a diferença entre OI e BI.

Cenário

Eis o caso:

Companhia de grande porte espalhada pelo território nacional, com gestão de projetos tradicional (cascata), entendeu que precisava adotar práticas de gestão ágil. Um plano corporativo de educação foi desenhado e aplicado, e agora o alto escalão da empresa quer descobrir se deu certo, e quão certo deu.

Vale a pena notar, antes de começarmos, que essa empresa conseguiria medir o impacto do treinamento mais facilmente se tivesse estabelecido quais seriam os resultados pretendidos de antemão. Seria mais fácil se, ainda no planejamento da capacitção, tivessem declarado quais aspectos do negócio deveriam ser impactados, de que forma esperar-se-ia esse impacto, como ele seria medido etc. etc. etc. Não consigo atinar como alguém faz o [roll-out][rollout_bitly] de um projeto desse porte sem estabelecer metas, mas enfim, adiante.

Eu e meu amigo trocamos algumas idéias e no final a minha sugestão foi:

Oras, se a intenção era melhorar a gestão de projetos adotando Scrum, então basta você comparar os indicadores de qualidade de projeto antes e depois dos treinamentos (veja o comentário 1 abaixo.) Se houver uma certeza estatística de variação nesses indicadores (comentário 2), você terá uma evidência relativamente forte de que a capacitação foi a causa (comentário 3.)

Comentários:

Como essa é uma das medidas a ser acompanhada em um caso desses de qualquer forma, a falha de planejamento não comprometeu a análise dos resultados – pelo menos não para esta métrica;
O mundo real é dinâmico, e as coisas mudam com alguma aleatoriedade. Ao montar esse “experimento” o analista precisa se preocupar em não detectar “artefatos”, resultados que parecem legítimos e autênticos, mas no fundo não passam de um sinal transiente, ruído, problema metodológico ou puro e simples erro de medida;
Um experimento precisa controlar todas as variáveis, para saber qual está causando a diferença nos resultados. Ele só pode confiar nos dados dele se, durante o período de transição, a empresa tiver levado uma vida normal, como levou em todos os anos anteriores. Se acontecer alguma coisa anormal, como uma fusão ou uma crise das brabas no seu mercado, a relação entre o treinamento (causa) e as mudanças dos indicadores de qualidades (efeito) ficará nublada.

Fazendo Ciência

Já temos material para um TCC e ainda nem chegamos aos dados ou às ferramentas! Foi esse padrão de problemas de BI que acabou a me levando à minha definição particular de BI, e há algumas semanas me levou ao caso da Inteligência Operacional (alguém por favor invente um nome melhor!!)

Meu amigo então me explicou como os projetos são registrados e tratados, e a partir daí identificamos os parâmetros que comporiam as métricas. Eis os pontos do fluxo de trabalho da empresa que são importantes para a análise:

Os projetos são registrados em um sistema informatizado (um software de gestão de portfólio e projetos), que coleta datas (inicial prevista/realizada, final prevista/realizada) de cada etapa (demanda, desenvolvimento, homologação e entrega;)
O tamanho e duração de cada projeto são estimados por meio de fórmulas e fatores históricos. A troca da técnica de gestão alterou essas fórmulas, mas o processo em si permaneceu quase inalterado: o projeto é avaliado, dimensionado e encaixado em um cronograma. A partir daí ele faz parte da vida da equipe;
Todos os parâmetros do projeto são editáveis a qualquer momento. Ou seja, o gerente do projeto pode alterar datas e estimativas a qualquer instante;
Os membros de cada equipe possuem alguma mobilidade, e podem mudar de equipe ao longo do ano;
Cada equipe executa vários projetos simultaneamente (um equívoco clássico.)

Os indicadores de qualidade dele são meio complicados e por isso eu vou – de novo – simplificar para facilitar a discussão.

Grosso modo, a qualidade é entendida como promessas mantidas com os clientes. Sempre que uma promessa é mantida, o projeto é avaliado como de boa qualidade. Quando uma promessa é quebrada, a avaliação é que o projeto teve baixa qualidade. E como medimos uma promessa? Simples: se prometemos entregar o projeto em certa data, com certo custo, dizemos que a promessa foi mantida se o projeto foi entregue naquela data, com aquele custo. Se não, então a promessa foi quebrada.

Partindo disso, as métricas relacionadas à qualidade de um projeto são os deltas, ou diferenças, de um parâmetro no início e no fim do projeto:

Delta de datas: diferença, em dias, entre uma data planejada (prometida) e a data realizada;
Delta de esforços: diferença, em Pontos de Função (PFs), entre o esforço planejado (prometido) e o esforço gasto no projeto (realizado.)

Evidentemente não estamos falando de projetos em andamento, mas apenas dos que já chegaram ao fim.

Um exemplo dos dados no sistema daquela empresa estão nesta tabela:

ID Projeto	Data Início Prevista	Data Início Realizada	Data Conclusão Prevista	Data Conclusão Realizada	Esforço Previsto (PF)	Esforço Realizado (PF)
1	22/08/15	12/09/15	17/10/15	24/10/15	92	90
2	27/04/15	07/05/15	21/05/15	25/05/15	95	86
3	14/03/15	23/03/15	04/04/15	05/04/15	48	58
4	10/08/15	08/08/15	05/09/15	04/09/15	61	69
5	13/04/15	17/04/15	25/05/15	20/05/15	100	98
6	22/05/15	18/05/15	11/07/15	15/07/15	64	60
7	22/11/15	19/11/15	09/01/16	19/01/16	27	28
8	27/02/15	31/03/15	07/04/15	08/04/15	79	69
9	01/09/15	22/09/15	03/10/15	29/09/15	36	35
10	13/01/15	17/01/15	24/02/15	09/03/15	79	89

Calculamos os deltas entre cada par de parâmetros (datas e tamanho), e chegamos a uma tabela assim:

ID Projeto	Delta Início (Dias)	Delta Fim (Dias)	Delta Esforço (PF)
1	21	7	-2
2	10	4	-9
3	9	1	10
4	-2	-1	8
5	4	-5	-2
6	-4	4	-4
7	-3	10	1
8	32	1	-10
9	21	-4	-1
10	4	13	10

Esses números são, então, usados para calcular a média e o desvio-padrão de cada delta. Fazendo estas contas nas linhas da figura acima teríamos o seguinte resultado:

Medida	Delta Início (Dias)	Delta Fim (Dias)	Delta Esforço (PF)
Média	9,2	3,0	0,1
Desvio Padrão	11,4	5,5	6,9

A interpretação desses resultados é feita assim:

Em média, um projeto começa com um atraso de 9 dias, e termina com um atraso de 3 dias;
Em média, a estimativa de esforço está subestimando o tamanho do projeto em 7 pontos de função;
Pela Desigualdade de Chebyshev, há 75% de chance de um projeto começar entre 2 dias adiantado e 20 dias atrasado (2 desvios-padrão.)

Por favor, releve qualquer erro que encontrar neste último item. Interpretar desvio-padrão em distribuições não-normais é um treco trucoso e talvez nem sequer seja uma análise apropriada. Uso-o apenas por conta de ser uma medida comum, fácil de calcular e porque vai servir para demonstrar meu ponto.

Analisando a Eficácia

Até aqui eu expliquei o problema (medir eficácia do treinamento) e como resovê-lo (comparar métricas de qualidade antes e depois.) Agora vamos aplicar essa solução a um conjunto de dados para ver como ela mostraria a eficácia – ou falta de – do treinamento. Como eu obviamente não posso usar os dados da empresa, eu gerei um conjunto de dados – e isso significa que eles conterão qualquer verdade que eu queira. Prometo não forçar a barra. ;-)

Vamos dizer que, em 2015, a empresa realizou 100 projetos, e que a capacitação ocorreu durante junho. Vamos analisar os dados agrupados mês a mês e comparar antes de junho com depois de junho. Por exemplo, pegaremos todos os projetos que tinham previsão de começar em janeiro de 2015 e calcularemos o erro de previsão para data de início de cada projeto, depois calcularemos a média de erros e finalmente o desvio-padrão dessa média. Colocaremos esses dados em uma tabela e passaremos para fevereiro, depois março e assim por diante até dezembro de 2015.

Eis a lista dos projetos que tinham previsão para começar em janeiro de 2015, tirados da minha massa de dados artificiais:

ID Projeto	Data Início Prevista	Delta Início
12	04/01/15	11
10	13/01/15	4
33	17/01/15	15
92	17/01/15	-9
34	18/01/15	48
72	20/01/15	4
78	22/01/15	41
88	22/01/15	6
49	26/01/15	0

A média de erros de estimativa em janeiro é (11 + 4 + 15 – 9 + 48 + 4 + 41 + 6 + 0) / 9 = 13 dias (positivo), significando que os projetos em janeiro de 2015 atrasaram, em média, 13 dias, ou quase duas semanas. O desvio padrão dessa população é de 18 dias, indicando uma dispersão relativamente grande. Ou seja, a média de atrasos pode não ter sido tão grande – quase duas semanas – mas a dispersão foi, indicando que há projetos que erram por muito mais que a média. Vê-se facilmente isso: há dois projetos que se atrasaram mais de 40 dias, enquanto que existe só um que se adiantou (projeto 92, 9 dias), e os outros ficam entre menos que uma e até duas semanas de atraso.

Se o treinamento tiver surtido efeito, então os líderes de projeto farão melhores estimativas e, consequentemente, a média e o desvio-padrão serão menores para projetos começados depois do treinamento. Se não mudarem muito, então o treinamento não causou o efeito desejado. Se tiver piorado, bom, então a capacitação foi uma catástrofe completa.

Eis as métricas para o erro da data de início de projetos (Delta Início) para o ano de 2015 inteiro (dados artificiais, não se esqueça!):

Mês	Média	Desvio Padrão
1	13	18
2	10	13
3	24	10
4	7	8
5	24	18
6	33	13
7	20	19
8	20	20
9	14	20
10	14	14
11	14	16
12	14	13

Como ninguém é de ferro, vamos traçar um gráfico com estes números: colocaremos a média como um histograma e o desvio-padrão como uma linha, com os meses no eixo X:

Média dos erros de estimativa do início do projeto, com os respectivos desvios-padrão.

De cara vemos um gráfico conspicuamente aleatório: essas curvas não tem “cara” de nada. Se o treinamento tivesse funcionado, os cinco ou seis últimos pontos seriam mais parecidos entre si, com tendência a cair. Claro: se um dos impactos do Scrum é melhorar as estimativas, então o erro entre o previsto e realizado deve diminuir ao longo do tempo, até que passe a oscilar em torno de zero, significando que as promessas de datas estão sendo cumpridas com mais seriedade.

Olhando com um pouco de boa-vontade, até parece que algo aconteceu: de setembro em diante o erro teve um período de estabilidade em 14 dias. É um começo.

Se essa for uma tendência causada pelo treinamento, é razoável supor que o desvio-padrão também deve mostrar uma tendência de queda, ou no mínimo ter atingido algum patamar. Mais: se a precisão de estimativa está melhorando por causa do treinamento, então essa melhoria deve acontecer para todos os projetos criados depois de junho.

Antes de voltar ao desvio-padrão, vamos olhar a média de novo. A olho nú não notamos, no gráfico anterior, nenhuma tendência expressiva ou indubitável. Já que olhar não está ajudando, vamos partir para a Matemática: uma hipótese razoável é que se a média estiver melhorando, se estiver caindo, então uma simples regressão linear nestes pontos deve apresentar um coeficiente angular negativo (valores caem com o avanço do tempo.)

Eis o gráfico da regressão linear sobre as médias para o ano inteiro:

Regressão linear da média de erros ao longo de 2015: levemente negativa.

Ora! Levemente negativa? É pouco, mas pelo menos não é positiva! Como dizem no Mythbusters, o experimento está indo bem.

Como também não distinguimos a olho nu uma tendência no desvio-padrão, vamos aplicar-lhe a mesma técnica – regressão linear. A hipótese, de novo, é que se o treinamento tiver surtido efeito, então a dispersão dos pontos ao redor da média está caindo, o que seria evidenciado por um coeficiente angular negativo.

Regressão linear do desvio-padrão dos erros ao longo de 2015: positiva.

Positivo! Ou seja, conforme o tempo passa, o desvio-padrão tende a aumentar. Isso é ruim! Significa que as previsões estão ficando mais aleatórias, com erros cada vez mais irregulares.

Só que há um erro metodológico na conclusão acima – um artefato. O correto é aplicar uma regressão antes e outra depois do treinamento, já que em princípio devem haver comportamentos diferentes em cada lado. Ficaria assim:

Regressão linear para média e sigma (desvio-padrão) antes e depois da capacitação.

Ah-HÁ! Agora estão claras as tendências! Ou no mínimo menos ambíguas:

Antes do treinamento a empresa tinha uma tendência a errar cada vez mais, mas todo mundo junto (dispersão diminuindo;)
Depois do treinamento, a tendência da média do erro mudou de sinal e ficou negativa, indicando que o erro de estimativa começou a diminuir – e a dispersão passou a diminuir mais rapidamente.

E, finalmente, a mágica: resolvendo a equação para Média < 1 e Sigma < 1 descobrimos quantos meses até a empresa cair para um erro de estimativa menor que um dia.

Erro médio:

    Erro Médio em Dias = -1,35 * meses + 28,81 dias
    1 > -1,35 * meses + 28,81
    1 - 28,81 > -1,35 meses
    1,35 meses > 27,91
    meses > 20,7

Ou seja, contando de julho de 2015, se nada mais mudasse e tudo seguisse no mesmo ritmo, a empresa atingiria erro menor que um dia mais ou menos 21 meses depois, em abril de 2017. E coisa de um mês depois, em maio/17, atingiria uma dispersão menor que um dia:

    Desvio Padrão em Dias = -1,35 * meses + 29,91 dias
    1 > -1,35 * meses + 29,91
    1,35 meses > 28,91
    meses > 21,5

Agora Sim: OI vs. BI

Usando os dados disponíveis no sistema transacional da empresa pudemos avaliar a qualidade dos projetos antes e depois da aplicação do treinamento.

Suponha que aquele primeiro gráfico vá parar em um painel, e fique à disposição da diretoria. No primeiro dia os diretores olham o painel e está lá o gráfico:

Justamente por não ter forma nenhuma é que podemos entender que nada mudou – as coisas não parecem melhores depois do treinamento. Alarmados, eles começam a cutucar todo mundo: como assim o treinamento não surtiu efeito?

Se a análise tivesse sido feita comparando-se as tendências antes e depois, os diretores veriam imediatamente que surtiu efeito, e quanto. Mas os dados não foram analisados, eles foram colocados em um gráfico e contemplados a olho nu, meramente.

Bom, não dá outra, no dia seguinte o gráfico está assim:

Inclinações dos indicadores no dia seguinte: negativa!

Lembram-se que o sistema de gestão daquela empresa não trava nada? Lá no começo está anotado:

Todos os parâmetros do projeto são editáveis a qualquer momento. Ou seja, o gerente do projeto pode alterar datas e estimativas a qualquer instante.

Bastou um dia de rádio-corredor e os dados, que passaram um ano estáticos, mudaram como se nunca houvessem sido diferentes.

E tem mais! Ao longo de um projeto, um gerente super-zeloso pode entender que certos ajustes são necessários e – legitimamente – realizar esses ajustes. Como é um sistema transacional, e tipicamente esse tipo de sistema não arquiva histórico, uma vez que os parâmetros tenham sido ajustados, os valores anteriores se perderam! Logo, de um dia para outro, literalmente, o projeto passou de muito atrasado para pouco atrasado, de tamanho grande para tamanho médio, ou qualquer outra mudança.

Pense: se os dados que rolam pela organização são maleáveis, e eles deveriam refletir a realidade, então a realidade é maleável e muda ao sabor das opiniões! Por puro e simples contato com a dura realidade sabemos que isso não é verdade!

Note que eu não estou afirmando que se alguém puder forjar fatos para ficar melhor na fita, esse alguém vá adulterá-los. Não estou afirmando que olhar dados operacionais, correntes, é um risco porque o caráter humano, falho, de todos nós fatalmente vai nos levar a fraudar os dados. Longe disso!

Estou afirmando que, feita sobre dados vivos, a análise certeira de hoje vira o mico corporativo de amanhã e a falha estratégica de depois de amanhã. (Nesse ritmo, a organização vai à falência até a semana que vem.)

Primeira Diferença: Técnica de Análise

Nós começamos com uma tabela listando os vários parâmetros de todos os projetos de um ano inteiro, e terminamos com quatro funções lineares. Repare que, até o final, olhar o gráfico não contou nenhuma história. Ou melhor, contou sim: que não dava para entender nada só olhando. Contrário ao mantra das ferramentas de visualização de dados, que formam o miolo da Inteligência Operacional, “ver” os dados não criou nenhum valor. E quando os dados foram divididos em dois períodos, quando pudemos acreditar que havia uma inflexão na tendência dos indicadores, foi necessário aplicar uma regressão para poder extrair alguma conclusão melhor que “o treinamento surtiu efeito”. Responder quanto de melhoria foi obtida e poder estimar quanto tempo até zerar os erros partiu de uma análise trivial, mas nem um pouco gráfica.

Em que pese o fato de os dados terem sido gerados aleatoriamente (o resultado acima foi uma feliz coincidência, eu não entrei nada manualmente!), a realidade não é diferente. Na verdade, é ainda pior: eu isolei o problema em UMA variável (data de início do projeto) e DUAS métricas. Imagine analisar um problema com três ou quatro variáveis, cada qual com meia-dúzia de métricas? Só a estatística descritiva univariada já cobre isso: média, mediana, desvio-padrão, variância, moda e esperança.

Em última análise, nossa capacidade está limitada pela capacidade das ferramentas. Escolher a ferramenta adequada e saber manuseá-la representam metade da solução de qualquer problema.

Segunda Diferença: OLTP <> Histórico

E outra: demos sorte que o sistema dele registra esse monte de parâmetros. E se fosse um outro problema, um em que o sistema não registre esses milestones? Pense em um sistema que controla o estado de – digamos – um ticket de atendimento, mas não registra as datas dos estágios pelo qual o ticket passou. Como é que poderíamos saber se algum assunto vai-e-volta, se tudo que podemos olhar é o aqui e agora, se não podemos ver o histórico das mudanças?

Sem dados históricos não há análises estratégicas. Como não é parte da responsabilidade de sistemas transacionais acumular histórico, não podemos confiar nos dados vivos para conduzir análises estratégicas.

Terceira Diferença: Consistência

Neste exemplo, ao olharmos os dados de um ano para trás, estamos vendo o que aconteceu naquela época? Ou estamos vendo o resultado de ajustes feitos na melhor das boas intenções? Os dados mudaram ao longo do tempo?

As coisas mudam, e olhar dados vivos trazem riscos inerentes à esse fato. Não se pode analisar dados dinâmicos mais do que podemos mirar em um alvo que se desloca erraticamente: se não temos certeza do caminho que ele percorre, só vamos acertá-lo por pura sorte.

Conclusão

Uma organização faz perguntas sobre si própria continuamente. Ora é preciso saber o que está acontecendo agora, neste instante, ora é preciso entender como as coisas estão funcionando, aonde se está indo. O primeiro caso é a essência da “Inteligência Operacional”, enquanto que o segundo é “Inteligência de Negócios”. A importância em se distinguir as duas coisas resume-se aqui:

Desenhar um gráfico com pontos pode contar uma história invisível aos olhos, mas visível sob o microscópio da Matemática e da Estatística: aprenda a escolher a ferramenta adequada e a manuseá-la, ou você poderá acabar com as mãos vazias na melhor das hipóteses. Na pior, pode ser levado a acreditar em algo incorreto;
Aqueles que ignoram o passado estão condenados a repeti-lo: não se fie nos sistemas transacionais para guardar o histórico de dados, pois essa não é a função deles. Cuide você de arquivar os dados importantes;
As coisas mudam, os dados mudam. Analisar dados vivos, dinâmicos, é garantia de não se poder garantir nada;

Retomando o post que deu origem à série, olhemos a tabela que separava OI de BI:

Aspecto	Estratégico	Operacional
Ciclo de vida dos dados	Histórico	Vivos, quase tempo-real
Origem dos dados	Armazém de Dados	Sistema de origem
Velocidade de manuseio dos dados	Não é crítica	Crítica
Funcionalidade mais importante	Data Mining	Formas de visualizar os dados

Em qual coluna se encaixa o caso mostrado? Vejamos:

Ciclo de vida dos dados: o estudo dos indicadores de qualidade consumiu dados históricos, que idealmente deveriam ser estáveis;
Origem dos dados: por sorte o transacional arquivava os atributos importantes, como as datas de cada etapa do projeto, e as estimativas iniciais. Sem isso, a única forma de se dispor desses dados teria sido um DW;
Velocidade de manuseio dos dados: irrelevante, ou não-crítica, pois meu amigo tinha alguns dias para conseguir uma resposta, e o volume de dados é pequeno;
Funcionalidade mais importante: descrição estatística dos dados, o que não chega a ser Data Mining, mas é bem mais que só um gráfico. A mera visualização gerou apenas dúvidas.

Logo, esse caso clasifica-se (pela minha régua, claro!) como um caso de BI e não de OI.

Tente imaginar em que situação esse caso teria sido classificado como OI:

Se os dados necessários fossem os dados do OLTP, vivos;
Se quiséssemos comparar valores ou percentuais do total – ideal para ser feito por gráficos;
Se o volume de dados afetasse negativamente a navegação deles, deixando o processo de análise lento para uma demanda de resposta rápida.

Perguntas da cepa “estamos no segundo dia de treinamento; a frequência está boa? Tem muita gente faltando?” e assim por diante, se encaixam mais no paradigma de dados operacionais. Para começo de conversa, descartaríamos um DW logo de cara.

Espero que tenha deixado tudo mais claro.

Até a próxima! ;-)

Publicado em 02/07/201502/07/2015 por Fábio de Salles · 13 Comentários

DW na Nuvem

Até agora eu não consegui “fazer o caso” contra ou a favor da terceirização da infra-estrutura de soluções de BI – a.k.a. DW/BI “na nuvem”. Há pouco tempo, numa destas promoções da Amazon.com, eu consegui uma cópia gratuita do livro Getting Started with Amazon Redshift sobre o serviço homônimo, editado pela Packt em 2013.

O nome Redshift é uma referência ao deslocamento para o vermelho sofrido pela luz emitida de um corpo que está se afastando do observador. É um efeito observado no nosso Universo, que sugere que ele está se expandindo, ficando maior.

Ainda estou na metade, mas o que eu vi já é o suficiente para me esclarecer algumas coisas.

Para começo de conversa, a maior vantagem de infraestrutura “em nuvem” é, sem dúvida, a capacidade de escala normalmente disponível. O Redshift têm algumas opções de tamanho e preço, todas estupidamente potentes para a maioria das empresas:

Recurso	Nó XL	Nó 8XL
CPU Cores (Xeon E5)	2	16
RAM (GB)	15	120
Disco	3 HDs, 2TB	24 HDs, 16TB
E/S de Disco (GB/s)	0.5	4

Cada um destes nós é precificado em dois modelos:

Por hora: paga pelo uso, enquanto usar;
Por reserva: paga por um período, independente de usar ou não.

Tabela de preços em 2015: igual à de 2013, mas com Dense Computing. — Tabela de preços em 2015: igual à de 2013, mas com *Dense Computing*.

No formato por hora, como podemos ver na tabela acima, cada nó XL sai por US$0,85/hora, e um nó 8XL por US$6,80/hora.

Agora, se você fechar um contrato com eles por um tempo determinado, o custo por hora chega a sair por até 25% do preço cheio! Considerando-se que uma empresa não traça estratégias por períodos muito menores que um ano, especialmente em termos de BI, um nó Redshift XL básico sai por US$0,49/hora para o contrato de um ano, e US$0,213/hora para contratos por três anos.

Colocando ao contrário: seu custo de infraestrutura para manter um DW com 2TB por três anos é US$83,00/mês. No Brasil de hoje isso mal paga a eletricidade das máquinas, quanto mais custos de software, instalação e suporte!

Conclusão: montar um servidor de DW no Redshift, com DOIS TERABYTES de armazenamento e 15 GB de RAM, em dois cores Xeons, parece muito mais barato que montar uma estrutura local. Só isso, para mim, já vale uma investigação mais detida do assunto. Este post vai olhar o lado do DW em nuvem e em um post futuro eu tratarei dos outros aspectos, como servidor de exploração, custos de transferência etc.

A Casa d’Irene

A casa d’Irene si canta si ride

C’e gente che viene, c’e gente che va

A casa d’Irene bottiglie di vino

A casa d’Irene stasera si va

Veja, Armazéns de Dados são como a casa da Irene: é gente que vai e vem, o tempo todo, e é desse fluxo que dependemos para as coisas acontecerem. Se você não consegue manter um fluxo de dados suficiente na carga, seu DW vai levar muito tempo para ser atualizado, estourando os tempos de ETL, entupindo a rede. Da mesma forma, se a vazão de dados entre o disco e a CPU não for o suficiente, as consultas vão demorar demais porque grande parte do tempo vai ser gasto pelo servidor trazendo os dados do disco para memória.

Disco <-> RAM

Quando temos um servidor de DW na nuvem, precisamos passar os dados dos sistemas da empresa primeiro pela Internet, para dentro do cluster Redshift. Depois, quando formos consultar, os dados precisam fluir rapidamente do disco para a RAM.

Este segundo aspecto é garantido pela Amazon em 0,5GB/s no caso mais barato. Uma fato de 1.000.000.000 (isso, um bilhão de linhas), com 400 bytes por linha (dez chaves delegadas de 8 bytes cada e mais 10 métricas de 32 bytes) totaliza pouco mais de 370GB. Ler tudo isso leva uns 12 minutos no cluster mais simples. No cluster mais rápido dá um minuto e meio. Nada mal, mas isso é um caso extremo, já que são raras as fato que atingem esse volume e ainda servem cubos OLAP, que é a aplicação que demanda mais velocidade. Para fatos com dez milhões de linhas, por exemplo, o menor cluster Redshift consegue varrê-lo completamente em pouco menos de 8 segundos.

Ou seja, I/O dentro do Redshift não é uma preocupação.

Origem <-> Redshift

Mas o caminho dos dados até os nós Redshift é.

Uma técnica tradicional de ETL consulta os sistemas transacionais e o DW simultaneamente, batendo um contra o outro e carregando no DW apenas as novidades. Essa arquitetura tem um impacto insignificante quando os sistemas ficam todos na mesma rede, que em geral está geograficamente muito próximo. Porém, quando o DW tem uma Internet no meio do caminho, cheia de firewalls, roteadores etc., a coisa muda de figura e se torna inviável. O round-trip time, que é o tempo entre uma leitura de um lado receber a resposta do outra, fica muito alto e, mesmo que o processamento seja rápido, o overhead de transmissão mata a performance do processo de ETL.

A solução é diminuir o uso da rede entre o sistema de origem e o DW no Redshift o máximo possível. Por exemplo, podemos selecionar apenas as linhas que tiveram atualização na origem e despachá-las compactadas para um armazenamento na mesma rede do Redshift.

Isso não é um cenário exótico, afinal, pois empresas que possuem centros de dados dispersos por vários territórios já lidam com essa preocupação rotineiramente.

Redshift <-> Soluções de BI

Quando resolvermos a questão da carga do DW, restará a exploração desses dados. Podemos consumir esses dados em dois modos:

On-line: aplicações cujas consultas precisam retornar em segundos;
Off-line: aplicações que podem esperar minutos ou horas por uma resposta.

O primeiro caso engloba painéis, análises OLAP e alguns tipos de relatórios. O segundo caso é mais comum em projetos de Data Mining e relatórios renderizados em plano de fundo, que sabidamente tomam muito tempo.

Qualquer que seja o caso, porém, sempre estaremos preocupados com o volume de dados que flui entre os dois servidores. Consultas para o Redshift são feitas com SQL normal, já que ele é um derivado Postgres, e isso raramente passa de alguns kilobytes.

A volta, do Redshift para o cliente que fez a consulta, é quando a porca torce o rabo. Em alguns casos o SQL retorna umas poucas linhas, com dados já totalmente agregados. Em outras situações, o retorno pode ser grandes datasets, que serão processados no servidor de exploração (o Mondrian, servidor OLAP usado pelo Pentaho BA Server, se encaixa neste caso.)

A solução é desconfortavelmente simples: a melhor forma de evitar gargalo de rede entre o servidor de exploração e seu DW Redshift é colocar o servidor de exploração dentro da Amazon, como outro serviço!

Uma das configurações mais “confortáveis”, com menos gargalos potenciais, é montar tudo dentro da Amazon.com.

Chutando Tudo

Quanto custa o hardware e software da categoria XL mais simples, e quanto sai um Redshift dessa categoria por um ano?

Se fosse medir isso para minha empresa, eu tomaria um cuidado enorme, começando por pedir cotações de vários fornecedores, custos de instalação, fretes, softwares, suporte etc. etc. etc. Mas eu quero apenas saber se os valores são comparáveis ou não. Para mim, comparáveis são valores que têm uma diferença de no máximo 10% entre si.

Hardware

Eu fiz uma busca por um Intel Xeon E5 e, logo nos primeiros resultados, achei isso:

Continha rápida (dólar de 1/7/15):

    R$ 9.553,93 / 12 meses = 
    = (R$ 796/mês) / R$ 3,14
    = US$ 253,00/mês

Ele tem um quadro grande de especificações, mas nos interessa apenas essa:

    Fonte: Cougar
    Potência: 500 Watts
    Tensão de entrada: 110/220V

Software

Depois eu verifiquei o preço de um HP Vertica para três nós, até 1TB: gratuito, assim como um sistema operacional (o Vertica funciona em algumas versões de Linux, que podem ser instaladas sem custo de licença.)

PostgreSQL colunar para três nós e 1TB: na faixa!

Infraestrutura

Vamos lá: no mínimo precisamos de um departamento de TI para tomar conta da máquina:

Profissional de TI: R$ 5,000.00/mês de salário;
Mais R$ 5.000,00 de encargos trabalhistas;
Trabalhando 8×5;
Menos um mês de serviço por ano (por férias);
Mais riscos diversos (acidentes doenças, paternidade, “ser roubado” por outra empresa etc. etc. etc.) que reduzem a disponibilidade dele.

Podemos argumentar que um profissional não vai ficar 100% do tempo dele só com um produto – servidor de DW – e que ele vai fazer muitas outras coisas. Concordo. Para efeitos de proporção, então, vamos dizer que apenas um décido do serviço dele é gasto com esse recurso. Se por mês gastamos R$ 10.000,00, então R$ 1.000,00 é a parcela de custo do servidor de DW.

Servidor que, aliás, precisa ficar ligado 24×7. Os preços de eletricidade em São Paulo, SP, hoje (julho/2015 antes do aumento de 1/7/15) são:

Tarifas de energia elétrica em SP, julho de 2015.

Uma empresa é classificada como grupo B3:

Classes de fornecedimento de energia elétrica.

Juntando tudo ficamos com:

A fonte consome 500 Watts, que eu suspeito que seja Watt-hora. Por mês, ligado o tempo todo gastaria: (500 Watts x 24 horas x 30 dias)/1000 = 360 kWh/mês;
Em São Paulo a tarifa comercial está em R$ 0,25625/kWh;
Total mensal de R$ 92,25 e anual de R$ 1.107,00.

Somando os dois temos R$ 1.092,25/mês de custo de infraestrutura.

Comparando Alhos com Bugalhos

Resumindo, com a infraestrutura interna gastamos anualmente um mínimo de:

Item	Valor
Máquina	R$ 9.553,93
Software	R$ 0,00
Serviços	R$ 13.107,00
Total	R$ 22.660,93

Contra o valor integral da modalide de reserva, que você pode conferir na tabela adiante:

Para um ano: US$ 4.295,00 * R$ 3,14 = R$ 13.486,30 ;
Para três anos: US$ 5.605,00 * R$ 3,14 = R$ 17.599,7, ou R$ 5.866,56.

Conclusão

Se você conseguir comprar um servidor, fazê-lo ser entregue sem frete, instalar-se e conectar-se a tudo sozinho, nunca der pau e nem precisar ficar em algum lugar no mundo físico – como uma sala, que paga aluguel, luz, IPTU etc. etc. etc., então um servidor Redshift sai por no mínimo R$ 9.174,63 a menos, por um ano. Aliás, com o que você gastaria em um servidor físico (em um cenário irreal) você poderia pagar TRÊS ANOS de Redshift equivalente, e ainda sobraria dinheiro!

Tudo muito lindo, tudo muito bacana, mas toda análise que joga luz sobre algo, projeta sombras sobre outras coisas. Olhe de novo para minha análise e se pergunte: o que é que não está dito ali?

Algumas coisas não são ditas:

Uma instância Redshift XL é algo muuuuito grande para os padrões de uma empresa média. Bom, isso eu disse, mas isto não: uma empresa desse porte pode ser virar com um servidor muuuito menos potente (por exemplo, com 1TB de disco e 8GB de RAM, CPU i7), na faixa de R$ 5.000,00 ou menos;
Existem outros custos associados a manter um Redshift que eu não contei. Um destes é o balde S3. Um balde S3 ajuda no transporte dos dados dos sistemas de origem para o nó Redshift, e ele consome outro tanto de dinheiro – incluindo custo de transferência de dados, medidos em gigabytes/mês. Veja aqui esses valores e faça uma conta;
Eu disse que o Redshift funciona melhor com toda estrutura na Amazon, incluindo o servidor de exploração e ETL. Isso representa no mínimo uma nova máquina online, com custos de disco, memória e transferência que precisam ser levados em conta;
Trocar um ambiente local por um “na nuvem” requer um conjunto habilidades ainda raro no mercado brasileiro. Esse caminho pode ser um beco sem saída em termos de mão-de-obra;
Acesso à Internet e a própria Internet viram um fator a ser levado em conta no planejamento. A empresa vai precisar de links de respeito para usufruir da potência desse servidor.

O que o livro me trouxe foi um pouco mais de conhecimento técnico sobre o assunto, que por sua vez me permitiu entender que uma arquitetura de BI/DW em nuvem é viável desde que, pelo que tudo indica, a solução fique completamente na nuvem. Se hoje eu fosse contratado para montar um DW em uma empresa, eu consideraria muito seriamente a montagem de tudo na Amazon.com, o que fatalmente me levariam a considerar as mesmas opções em outros serviços “de nuvem”.

Este post é dedicado à memória de minha querida tia Irene Michelette. Na casa de Irene se canta e se ride! :-)

Publicado em 25/03/201506/05/2015 por Fábio de Salles · 4 Comentários

Re-Estimando Projetos de ETL

Em 2012 eu escrevi um post sobre como eu estimava o tempo gasto em projetos de ETL. Editorando a coletânea do GeekBI 2012 eu o reli, e fiquei horrorizado com os meus parâmetros: uma mísera estrela dava três meses! Tudo bem que eu incluía o tempo para implantação, estabelecimento do ambiente de desenvolvimento etc., mas mesmo assim é muito tempo para rodar a primeira iteração de um projeto. Em minha defesa, naquela época eu não via o mundo tão Scrum, e pensava ainda no formato cascata.

Hoje, quase três anos depois, eu já aprendi um monte sobre Scrum e Data Vault e não sou mais tão pessimista. Eu achava que não havia como algo não dar errado, e pior ainda, eu tinha certeza que construir as dimensões e fatos eram uma profissão de fé! Eu estava às voltas com coisas tão complexas, tão enroladas que eu realmente estava levando algumas semanas para construir uma transformação para carregar uma mera dimensão. Fatos, então, eram coisas aracnóides, de tantos ramos e ligações entre passos…

Vou refazer aquele mesmo processo, que eu continuo usando aliás, à luz dessas novidades. Vamos ver o que é que vai sair.

Introdução

Eu estimo a duração e o esforço necessários em projetos de BI baseado na minha experiência. Depois de alguns anos eu fiz uma nova auto-análise e separei passos que eu sigo mentalmente para chegar em um número inicial.

Coletando os Parâmetros

Antes eu ignorava intencionalmente a necessidade do cliente e encarava como parâmetro apenas a quantidade de dimensões e fatos – afinal elas traduzem fielmente a necessidade do cliente. Só que, à luz do Data Vault, descartar esse conhecimento “rouba” informações importantes, que são úteis para estimar o tamanho do projeto.

Por isso hoje eu começo coletando outras informações: uma maquete da necessidade do cliente (veja a figura abaixo.)

A função dessa maquete é ilustrar que dados serão puxados dos sistemas de origem. Essa informação dá números importantes: a quantidade de hubs e satélites necessários, bem como a provável quantidade de links entre cada hub. Apenas para facilitar: entre dois hubs costuma haver pelo menos um link.

Daí eu procuro descobrir o seguintes:

Quantos analistas você terá dedicados integralmente a construir o DW;
Quantas fontes de dados você terá que tratar. Fonte de dados é tudo que possa vir a alimentar o DW: bancos relacionais de sistemas transacionais, files Adabas, arquivos texto/excel, páginas web etc.;
Quantas fatos e quantas dimensões o MD precisa ter atender para atender a demanda inicial.Esse item, no primeiro post, era o mais propenso a erros. Eu discutia como estimar a quantidade de dimensões e fatos a partir dos processos de negócio da empresa, pois eu acreditava que um DW Corporativo deve ser montado como estrelas ligadas a um barramento dimensional. Minha visão mudou, e agora eu entendo que o DW Corporativo deve ser a combinação dos dados historiados em um Data Vault e explorados em estrelas dimensionais. Graças a isso agora é muito fácil estimar a quantidade de dimensões e fatos a partir do protótipo: cada hub (e seus atributos) representam uma dimensão, e cada conjunto de métricas implica em uma tabela fato.No nosso exemplo parecemos ter uma dimensão (Item, com três atributos: Nome, Tipo e Origem) e uma fato, com uma métrica (veja mais adiante);
Volume de dados. Pode ser o tamanho de todas as bases de origem, em bytes, e quanto essas bases crescem por dia ou mês. Preferencialmente, pode ser a quantidade de linhas iniciais e os incrementos regulares (por dia ou por mês);
Se os dados de origem estão limpos ou sujos, do ponto de vista do domínio de cada coluna/campo.
Se os dados de origem estão limpos ou sujos, do ponto de vista do relacionamento entre as fontes. Por exemplo: os dados do cliente estão divididos entre duas fontes (CPF, RG e nome numa, RG, endereço e estado civil em outra; ela é suja se houver lacunas ou diferenças de formato na chave, o RG.)

Completando o Cenário

Para nosso exemplo precisamos completar a história. A partir da figura anterior podemos supor que existe pelo menos um hub (Item) e um satélite (de onde tiramos Nome, Tipo e Origem.) Usando essa informação podemos supor que o diagrama abaixo representa um Data Vault que atenderia essa demanda:

150325_ReEstimandoProjetosDeETL_02 — Provável Data Vault para a necessidade anterior.

Veja esse post para saber mais sobre esses objetos de um Data Vault.

Um Data Vault serve para acumular dados, não como fonte para análises. Se queremos analisar os dados que estão em um DV devemos primeiro levá-los a uma forma mais amigável ao usuário final. Isso significa construir um tabelão ou uma estrela com os dados que o cliente quer ver. A estrela do diagrama abaixo, derivada do Data Vault acima, atende a necessidade do cliente:

150325_ReEstimandoProjetosDeETL_03 — Provável estrela deste caso.

O Processo de Estimativa

Pelo que eu tenho visto, em média:

Uma equipe entrosada monta o ambiente de desenvolvimento (servidores, programas de desenvolvimento, repositórios, bases de dados etc.) em uma semana. Uma equipe desconexa leva mais ou menos o dobro;
Uma equipe pode levar até uma semana a mais para montar a linha de produção de um Data Vault;
Os elementos do Data Vault têm um teto de 1h/artefato;
A partir de um Data Vault, um desenvolvedor PDI proficiente leva até uma semana por dimensão ou fato;

Da primeira vez eu considerei que a quantidade de fontes de dados acrescentaria mais alguns dias nesse número. Esse impacto tende a sumir quando usamos Data Vault porque os dados já entram integrados, e a fonte de dados é tratada automaticamente na linha de produção do ETL de carga do DV. Eu diria que mesmo dados originados em arquivos ou via webservices podem ser intermediados por um banco relacional, e assim cair de volta ao caso mais simples.

Há duas técnicas de carga de dados em dimensões e fatos: trunca-e-recarrega ou carga incremental. Truncar e recarregar exige menos trabalho de desenvolvimento e mais do ambiente de ETL, enquanto que a carga incremental tende a custar mais em termos de desenvolvimento e menos em termos de infra-estrutura. Eu aventava a possibilidade de o processo levar mais tempo no caso de ser necessário desenhar essa a carga incremental. De novo, com o Data Vault na parada esse fato tende a ser minimizado por quê podemos postergar o desenvolvimento da carga incremental até que uma limitação de infra-estrutura nos obrigue. Podemos começar usando trunca-e-recarrega e, quando a infra-estrutura não suportar mais isso, refatoramos o projeto para carga incremental.

Você pode argumentar que isso troca “seis” por “três mais três”, pois no final acabamos fazendo “6”. Bom, o fato é que uma carga incremental nem sempre é necessária. Quando montamos o DW com outro modelo que não o Data Vault, essa decisão via de regra precisa ser tomada antes, porque a refatoração é cara demais ou até mesmo inviável. A refatoração é fácil se temos um Data Vault, e postergar decisões não-críticas passa a ser uma boa estratégia.

Alguns modificadores:

Obviamente, à medida que essa experiência aumenta, o tempo cai, e vice-versa. Assim, dominar a ferramenta, conhecer o modelo e os dados e já ter executado algumas iterações é o máximo da proficiência. Na ponta oposta está o novato com o software, começando o primeiro projeto de DW com dados que ele nunca viu mais gordos;
Sujeira nos dados. Esse é o fator mais selvagem. Tradicionalmente ele afeta a entrada dos dados no DW e tende a aumentar a complexidade do processo de ETL.Só que um Data Vault aceita tudo, inclusive sujeira, sem sofrer nenhum impacto no ETL. Devido a isso, os dados precisam ser limpos apenas na saída para a base que vai servir para exploração. Meu sentimento é que dados muito sujos podem até dobrar o tempo de desenvolvimento da carga de uma fato ou dimensão. Mas de novo, podemos começar aceitando dados sujos para exploração, e limpar à medida que o usuário demandar isso.Como o impacto da limpeza de dados só vai ser conhecido no primeiro teste do processo, eu descarto esse fator para estimativas.

Finalmente, e só para ter um número para fazer as contas, vamos supor que um desenvolvedor seja capaz de entregar 4H de trabalho útil por dia. Vamos dizer que o modelo de dados (de DV e Dimensional) já estejam diagramados, faltando apenas serem levados ao banco.

Estimando…

Então, para nosso exemplo, estimando pelos tetos e arredondando para cima, temos:

1 semana para iniciação do projeto;

1 semana para estabelecimento da linha de produção do Data Vault;

ETL do Data Vaul: ( 1 hub + 1 satélite ) * 1 hora = 2 horas -> arredondando, 1 dia;

ETL do Data Mart (trunca e recarrega): (1 dimensão + 1 fato) * 1 semana = 2 semanas.

Total: 1 semana + 1 semana + 1 dia + 2 semanas ~ 4 semanas

Parece muito, e é. Veja que a carga da dimensão e a fato que usamos de exemplo precisam de muito pouco trabalho, e não devem levar uma semana cada. Eu diria que a complexidade do exemplo dá um dia para cada um. Mantendo a inicialização do projeto em duas semanas (estamos sendo muito precavidos aqui), o desenvolvimento mesmo levaria três a 5 dias, ou uma semana aproximadamente. Novo total: três semanas de trabalho. Tamanho da equipe: um desenvolvedor (e seu eventual gerente.)

Lembrando que para isso já tivemos levantamento de requisitos e primeiro desenho do modelo de dados – estamos tratando apenas do ETL!

No post anterior eu estimava como três semanas o tempo para dois analistas. Eu não dava tantos detalhes do cenário, e na minha cabeça era um caso mais complexo – e por isso era mais “cara”.

A melhor parte vem na iteração seguinte, quando o custo de inicialização já ficou para trás.

Estimando Mais Adiante

Suponha agora que o cliente pediu mais duas estrelas (duas fato), envolvendo um total de 9 dimensões, e que todas serão construídas a partir de um Data Vault com trunca-e-recarrega.

Se cada dimensão equivale, grosso modo, a um hub mais um satélite, e há links entre diversos hubs, então o diagrama abaixo representa o nosso caso:

150325_ReEstimandoProjetosDeETL_04 — Diagrama DV para nova necessidade.

Cada hub aparece ligado ao “vizinho” por meio de um link, isto é, temos um link para cada par de hubs.

Exemplos:

H1 – H2 = Link 1-2

H2 – H3 = Link 2-3

etc.

Há oito links óbvios: L12, L23, L34, L45, L56, L67, L78 e L89. Para encorpar o problema vamos supor que há um link os hubs 3 e 6 (L36) e entre os hubs 3 e 9 (L39).

Isso dá (1 hub + 1 satélite) * 9 + 10 Links = 28 objetos.

E quanto ao modelo de dados que o cliente vai explorar? Nele temos 9 dimensões e 2 fatos.

Finalmente nossa origem é um único banco relacional, nossos dados são 100% limpos e teremos dois analistas (mais um gerente).

Estimando:

28 Objetos DV * 1H/objeto = 28 horas -> 28/40 Semana = 0,7 Semana
9 Dimensões = 9 Semanas
2 Fatos = 2 Semanas

Isso é o tempo gasto por um desenvolvedor só: cerca de 12 semanas ou três meses. Como a criação do ETL de cada dimensão é um processo independente de outros desenvolvimentos, podemos paralelizar a criação das dimensões. Assumamos, para simplificar, que desenvolver o processo de carga de uma fato depende da existência do processo de carga das dimensões usadas. Trocando em miúdos, o ETL para as fatos pode ser desenvolvido em paralelo, mas apenas depois do ETL para as dimensões.

Com dois desenvolvedores o tempo estimado cairia de 3 meses para aproximadamente um mês e meio.

No primeiro post eu ainda triplicava minha estimativa inicial porque eu via esse fator se concretizando nos meus projetos. Tendo desenvolvido um pouco com Data Vault, eu não sinto necessidade de incluir essa gordura. Muito pelo contrário, como o desenvolvimento de dimensões a partir de um Data Vault é um treco repetitivo, eu acho que esse tempo é até demais. Eu não vou cortar a estimativa, mas eu vou dizer que agora (com Data Vault) eu sinto mais previsibilidade nos projetos.

Finalmente, um overhead de gerenciamento continua existindo. Eu colocaria um mês para esse fator – nunca subestimo a capacidade de a burocracia nos amarrar!

Conclusão

E esse é meu chute, atualizado em função do que eu aprendi usando Data Vault. Lembre-se que estou descontado o levantamento de requisitos, documentação etc. e que mesmo achando que minha precisão melhorou, eu nunca ignoro o fato que estou tratando de uma estimativa, e nunca de uma medida – variáveis desconhecidas podem mudar tudo completamente, de uma hora para outra.

Continua valendo a mesma sugestão que encerrava aquele post: a quantidade de variáveis desconhecidas e incertezas berram pela adoção de Scrum como técnica de gestão. A propósito, eu adotaria três semanas como tamanho inicial das sprints, simplesmente porque rodei durante um tempo com sprints de duas semanas e me senti pressionado demais, o tempo todo.

E agora, o que você achou? Deixe seu comentário!

Washignton, tá liberado para dizer que este post é muito complicado! ;-)

Publicado em 05/01/201527/12/2014 por Fábio de Salles · 9 Comentários

Testando o Vertica

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

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

O Experimento

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

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

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

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

Tempo por operação nas duas tecnologias.

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

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

Legal.

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

A Conclusão…

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

E eu aposto que é.

Feliz Ano Novo!!

Publicado em 25/06/201426/06/2014 por Fábio de Salles · 5 Comentários

O Que Leva à Alta Performance?

Michael Porter, da Harvards Business School, diz que o rendimento de uma empresa é empurrado por dois fatores: estratégia e execução.

Phil Rosenzweig escreveu em seu livro The Halo Effect (com a tradução Derrubando Mitos) que, se isso é verdade, então tocar uma empresa com sucesso é uma coisa arriscada pelo simples fato de que nada dá a menor garantia que escolheremos sempre a estratégia vencedora, ao invés de alguma outra estratégia furada.

Não bastasse a dificuldade na escolha da estratégia, a execução dela também é um desafio de porte semelhante. Coisas que funcioaram para uma empresa não necessariamente vão funcionar para outra. Coisas que deram certo no passado ou em outro mercado, podem não dar certo agora, para sua empresa. Ou seja, a execução é algo que também depende de sorte e de alguma experimentação. Claro que existem coisas que são atemporais e independente de mercados ou indústrias – gestão de pessoas, finanças, estoque, algumas automações etc. Uma empresa depende de tantos processos e de tanta gente para funcionar que uma parte dela, com certeza, será particular ou diferente do restante.

Não sei se consegui me fazer entender, e por isso aqui vai o resumo:

Duas das maiores e mais afinadas mentes científicas de nosso tempo argumentam que o sucesso de uma empresa depende de sua estratégia e da execução dessa;
Adotar uma estratégia é igual a descartar TODAS as outras estratégias possíveis;
Não é possível saber de antemão qual estratégia vai dar certo, e qual vai dar errado;
Implantar (executar) essa estratégia é algo que depende de conhecimento, experimentação e sorte.

Melhorou? Leiam o livro do Rosenzweig para uma iluminação maior, mas se você acha que entendeu a lista acima, beleza, consegui o que eu queria. Próxima pergunta:

Como Escolher uma Estratégia?

O Rosenzweig discute isso brevemente. Resumindo, não dá para competir com todo mundo, em todos os mercados, oferecendo todos os produtos para todos os clientes. É preciso fazer escolhas, é preciso tomar decisões, como por exemplo:

Em que mercado vamos atuar?
Que produto vamos oferecer?
Contra quem vamos concorrer?
Vamos vender por menos que a concorrência, ou cobrar um prêmio por mais qualidade/conteúdo/rendimento/etc?
Quanto os clientes estão dispostos a pagar?

Como Executar a Estratégia?

Larry Bossid disse que “Nenhuma estratégia entrega resultados a menos que convertida em ações específicas.” Uma vez que a estratégia foi escolhida, a execução precisa ser suficiente e isso implica em fazer mais escolhas. É irreal pretender executar 100% das atividades possíveis e ter 100% de qualidade em 100% das vezes. É preciso escolher no que investir tempo e recursos, e decidir que atividades serão deixadas de lado ou terão menos atenção.

A diferença entre a execução e a estratégia é que a estratégia depende muito do que está fora da empresa, e a execução depende quase que totalmente do que está dentro da empresa.

Ou seja, se a sua empresa ainda não existe, se ela é só um Plano de Negócios, você precisa de dados gerados por outrem. Você não tem nada, e precisa pesquisar tudo. Você ainda não sabe nada sobre seu (futuro) negócio, tudo são estimativas, chutes e palpites.

Você faz o melhor que pode para tirar a empresa do papel, e durante um tempo voa por instrumentos, meio às cegas, contando com a melhor informação que você conseguiu acumular e seu taco para o negócio.

Uma vez que sua empresa passou a existir, dados começaram a ser gerados – pedidos, itens produzidos, serviços prestados, clientes adquiridos e perdidos, lucratividade, competição, market share etc. etc. etc. A partir daí você pode avaliar se está indo bem ou não. Você consegue dizer se está executando bem, ou não, se sua estratégia está dando certo, ou não.

Inteligência de Negócios, Estragégia & Execução

Rosenzweig conclui, no capítulo nove do Halo Effect, que executar brilhantemente uma estratégia de sucesso pode levar uma empresa à falência. Se o mercado mudar, se a tecnologia mudar, se a concorrência mudar – se alguma coisa mudar o mundo no qual sua empresa existe – sua empresa vai ficar vulnerável, e a única forma de lidar com isso é estar sempre atento e, eventualmente, decidir mudar de estratégia, antes que seja tarde demais. No final deste capítulo, Rosenzweig cita Tom Peter de novo:

Para ser excelente, você precisa ser consistente. Quando você é consistente, você é vulnerável a ataques. Sim, é um paradoxo. Vire-se com isso.

E como você decide que é hora de mudar de estratégia? Como você descobre se o problema não é estratégia, mas sim execução? Ou o inverso?

Uma empresa é uma coisa viva, que existe em um mundo em constante mutação. Organizações podem ser entendidas em si, e em seu meio-ambiente, por um único indivíduo até certo tamanho: uma padaria, uma farmácia, uma escola – um supermercado, talvez. Acima de um certo tamanho, as interações dentro da empresa, e da empresa com o meio externo são tão numerosas e complexas que uma só pessoa não consegue abarcar em sua mente toda aquela informação e tirar sentido dela. A partir de um certo tamanho, repensar a estratégia e avaliar a execução passa a ser uma tarefa sobre-humana.

E é nesse ponto que se encontra o valor da Inteligência de Negócios. A captura e análise sistemática de todos os dados que sua empresa gera, e se possível, dados do mercado e dos clientes, só pode ser feita com ferramentas específicas. Essas ferramentas se separam em duas categorias: acúmulo de dados e análise de dados. Armazéns de Dados (Data Warehouses) cuidam do acúmulo. Ferramentas como OLAP e Data Mining cuidam da segunda. Recursos de apresentação, como painéis e relatórios, comunicam os resultados para a empresa, e servem como guias para avaliar o risco da estratégia atual, para avaliar a qualidade da execução em curso.

Inteligência de Negócios é a disciplina que habilita uma empresa a buscar alto rendimento.

Juntando à conclusão do post anterior:

Inteligência de Negócios é a disciplina que habilita uma empresa a buscar alto rendimento através da compreensão de seu negócios mediante a aplicação do Método Científico.

Fechou, é isso. Até a próxima.

Publicado em 06/12/201206/12/2012 por Fábio de Salles · 1 Comentário

A Vantagem do Visual

Recebi o pedido de um post:

Fábio, você poderia fazer um post sobre sua experiência no pentaho referente a performance? Desenvolvo um projeto onde eu prefiro realizar todas as transformações via query e percebi que você utiliza os componentes do pentaho para fazer o mesmo. Como tenho poucos dados de testes quando vou testar a performance de ambos acaba dando quase o mesmo resultado em questão de tempo.

E é claro que eu vou atender. ;-)

Comparar ou Não Comparar, Eis a Questão

Suponha que eu escolha, como um exemplo para medir essa performance, copiar uma tabela para outra, no mesmo banco:

A query ganharia, já que nada bate uma cópia interna, de uma tabela para outra, dentro do mesmo banco.
Se a cópia fosse entre dois bancos diferentes, na mesma máquina, ainda seria muito rápido, mas acho que precisaria apelar para uma linguagem do banco, ou algum recurso não-padrão para que o SELECT em um banco sirva de entrada para o INTO em outro. Imagino que a consulta ainda bateria o PDI.
Agora, se a cópia fosse entre duas máquinas diferentes, talvez houvesse um empate porque a rede entre as máquinas passaria a ser um gargalo. Como os dois recursos (query e PDI) normalmente são muito mais rápido que a maioria das redes, a velocidade final seria limitada pela velocidade da rede, e daria empate.

Se eu escolhesse ler um arquivo e carregar no banco, os fatores envolvidos seriam outros e os resultados desse caso não teriam nenhuma relação com os resultados do caso anterior, da cópia entre duas tabelas. Se fosse um join, outro resultado. Se fosse um lookup em banco a partir de um arquivo, outro resultado. Etc. etc. etc. e assim por diante.

Ou seja, os resultados de uma comparação desse tipo seriam inconclusivos, pois oscilariam entre vantagem ora de um método, ora de outro.

Vendo Vantagem

Então tanto faz? A performance, na média, vai ser sempre a mesma para qualquer tecnologia?

Nem de longe. A comparação direta de performance entre as duas técnicas (PDI e SQL) pode ser uma medida muito difícil, mas não deve ser importante para optar por uma ou por outra. O que deve nortear sua escolha é, como sempre, o custo-benefício.

Se as suas transformações só envolvem bancos de dados, todos do mesmo tipo, pode ser que seja mais fácil desenvolvê-las usando SQL – já está tudo ali mesmo, e rodar SQLs diretamente no banco pode dar muito menos trabalho que baixar o PDI, configurar uma máquina, desenvolver as transformações e agendâ-las em produção.

Se o seu processo envolve arquivos (talvez em um servidor remoto), bancos (de diversos tipos), uma área de transferência temporária (palco ou stage) etc. etc. etc., desenvolvê-lo usando SQL pode ser tão complexo quanto construir uma nova aplicação do zero. Num caso desses, usar o PDI pode até redundar na mesma performance, mas o desenvolvimento desse processo será – eu te garanto – muito menos trabalhoso. Sua produtividade tende a ser mais alta com o PDI que com uma linguagem de programação.

Conclusão

A performance de cada processo depende de um sem-números de fatores, e o critério para você fazer uma escolha entre as tecnologias possíveis, em princípio, é o custo de cada uma dessas opções, comparado com o retorno que elas vão te dar.

Como o PDI permite desenhar todo processo graficamente, “ligando os passos”, um analista produz muito mais usando o PDI que desenvolvendo um programa em alguma linguagem.

Mas e a performance, Fábio? Afinal, qual eu devo escolher se a performance for importante? PDI ou Query?

PDI, sem sombra de dúvida. Porquê? Porque o PDI oferece muitos mecanismos para melhoria da performance do processo e você fatalmente vai conseguir a performance que precisa, a uma fração da complexidade do desenvolvimento de queries.

É isso.

Publicado em 15/05/2012 por Fábio de Salles

Estimando Projetos de ETL

Eu estimo a duração e o esforço necessários em projetos de BI baseado na minha experiência. Eu fiz uma auto-análise e redigi abaixo os passos que eu sigo mentalmente para chegar em um número inicial.

Coletando os Parâmetros

A minha mecânica para estimar o trabalho de desenvolvimento do ETL de um DW é relativamente simples. Eu procuro descubrir os seguintes números:

Quantos analistas você terá dedicados integralmente a construir o ETL. (Além dos analistas você vai precisar de um gerente.)
Quantas origens de dados você terá que tratar. Fonte de dados é tudo que possa vir a alimentar o DW: bancos relacionais de sistemas transacionais, files Adabas, arquivos texto/excel, páginas web etc.
Quantas fatos e quantas dimensões o MD deve ter. É impossível responder essa pergunta com precisão antes de o MD ser efetivamente construído, mas você pode estimar esse número:
1. Qual é a quantidade de processos automatizados pelo seu sistema transacional? Cada um equivale grosso modo a uma fato.
2. Quais são os parâmetros que provavelmente filtrarão as análises? Daí conte o número de atributos que têm a resolução mais fina. Por exemplo, se você vai filtrar por ano, mês e dia, a maior resolução é obtida com dia. Ignore os outros atributos e conte um atributo só. Se as análises serão feitas contra bairro, cidade, estado, o atributo que dá a maior resolução é bairro. Como cidade e estado são do mesmo tipo (geográfica), conte mais um atributo. No final você vai ter uma lista inicial de dimensões.
3. Exemplo: se quisermos analisar o tempo de atendimento de balcão, você precisará medir a data e hora inicial (DHi), a data e hora final (DHf), posto (cidade-bairro-posto), atendente (sexo-idade-escolaridade-nome-cpf-etc.), demanda, resolução (resolvido/pendente), tipo (reclamação/elogio/pagamento/negociação/etc.), cliente (PF ou PJ, cada qual com sua lista de atributos). Temos uma fato (atendimento) e 8 dimensões (se cliente virar uma tabela só, ou 9 se for em duas.)
Volume de dados. Pode ser o tamanho de todas as bases em bytes e quanto ela cresce por tempo (dia ou mês), ou (preferível) quantidade de linhas iniciais adicionadas regularmente (dia ou mês) às fontes de dados.
Os dados de origem estão limpos ou sujos, do ponto de vista do domínio de cada coluna/campo.
Os dados de origem estão limpos ou sujos, do ponto de vista do relacionamento entre as fontes. Por exemplo: os dados do cliente estão divididos entre duas fontes (CPF, RG e nome numa, RG, endereço e estado civil em outra; ela é suja se houver lacunas ou diferenças de formato na chave, o RG.)

Definindo o Processo de Estimativa

Daí eu apela para a minha experiência. Supondo que um desenvolvedor seja capaz de entregar 4-5H de trabalho por dia: (alta produtividade!)

Um desenvolvedor PDI proficiente leva de uma a duas semanas para cada dimensão ou fato.
A medida que essa experiência cai, o tempo aumenta. Uma dimensão pode levar até mesmo um mês para ficar pronta se o analista começar o projeto sem conhecimento da ferramenta (ou mesmo com um curso.) Isso ocorre por que cada processo demanda um conjunto de truques particular, e o analista leva um tempo para internalizar a ferramenta e desenvolver seu repertório de macetes – como em qualquer outra ferramenta, aliás. Como passar do tempo esse número melhora, graças ao acúmulo de experiência do analista.
A quantidade de fontes de dados acrescenta mais alguns dias nesse número: de nada a alguns dias (até uma semana) a mais por fonte de dados. Isso ocorre por que pode ser necessário algum estudo para integrar as origens (pior caso) ou apenas um join pode ser suficiente (melhor caso.)
Volume de incremento no tempo: mais dois ou três dias para desenhar uma mecânica de tratamento de incrementos, que pode ser aplicada em todas as cargas. Esse tempo tende a sumir, diluído entre todos os processos de carga de dimensões e fato.

Sujeira: esse é o fator mais selvagem. Ele pode até dobrar o tempo de encerramento do desenvolvimento, a depender da quantidade de erros e sujeiras na base, e a capacidade do cliente em lidar com erros no DW (às vezes a sujeira não afeta a análise, às vezes a torna impossível.) Normalmente o impacto da limpeza de dados só vai ser conhecido no primeiro teste do processo e por isso não é usado para estimativas.

Estimando…

Então, para nosso exemplo com 8 dimensões, uma fato, com um banco relacional como única origem, dados 100% limpos e dois analistas (mais um gerente) você tem:

9 x 1 semana (cinco dias) / 2 analistas = 22,5 dias (~3 semanas).

É seguro triplicar esse número, para incluir todas as dificuldades não-previstas e adicionar um mês de overhead no início do projeto. Então temos 9 semanas + 1 mês = 13 semanas, o que dá uns três meses, mais ou menos, até a primeira versão beta do processo. Leva-se mais um ou dois meses entre ajustar o processo para produção e homologá-lo (controle de qualidade.)

Lembre-se que você vai precisar, também, estimar o tamanho da plataforma para entregar o refresh na latência requisitada por seu cliente.

Escrevendo na Pedra

Isso é só um parâmetro inicial, descontado o levantamento de requisitos, documentação etc. Com esse número em mãos eu reviso tudo que eu sei sobre o projeto antes de ele começar e uso minha intuição para ajustá-lo. Não raro eu entrevisto os analistas para entender o fator tarimba de cada um e verificar se eu fui otimista ou pessimista. Porém, esse número nunca é uma medida, mas sim apenas um chute elaborado (ou em bom inglês, um educated guess) – variáveis desconhecidas podem mudar tudo completamente.

Quem é do ramo já deve ter percebido que o volume de variáveis desconhecidas e incertezas sugerem o uso de Scrum para gerenciar o projeto. Como o tamanho de uma transformação é de duas ou três semanas, possivelmente eu adotaria isso como tamanho inicial das sprints, para fazer com que cada uma equivalha a entrega de uma transformação por analista. Após uma ou duas sprints a precisão desse número pode melhorar bastante.

O que você achou? Bate com o que você faz? Deixe seu comentário!