Bola Redonda

Contrabalançando o post Bola Quadrada, neste aqui eu vou mostrar como bater um bolão, redondo, usando BI.

SAS Customer Intelligence Forum ’17.

Hoje, 17-5-17, aconteceu um evento do SAS, a maior empresa de BI do mundo, sobre aplicações de Marketing, o SAS Customer Intelligence Forum. O evento foi gravado: assista neste link. A primeira palestra é em inglês e não tem legendas, mas o restante é todo em português.

Vamos por partes.

Marketing Analítico

A primeira palestra foi feita pela Vice-Presidente Sênior de Marketing do SAS, Adele Sweetwood. Ela é autora de um livro, que aparentemente vende muito bem: The Analytical Marketer.

The Analytical Marketer.

O conceito, em si, é simples: há tantos dados disponíveis, e tanto poder de processamento, que novas formas de entender o cliente estão surgindo, e mais partes de uma empresa pode agir com base em dados. Ela mostra um monte de exemplos de novos usos dos dados para marketing, e fecha com um comentário digno de nota:


O uso dos dados para marketing está movendo a prática de marketing de “campanha” para “interação contínua”.


Não são exatamente essas as palavras, mas o sentido é esse. Central nesse admirável mundo novo é a evolução dos diversos canais, como e-mail, mídias sociais, rádio, revistas etc., para um único e grande canal: o [omnichannel][omnichannel_bitly], ou omnicanal. Assim, ao invés de termos uma campanha para e-mail, uma para WhatsApp, outra para chat, outra para telefone e assim por diante, devemos ter interação uniforme, orquestrada em todos esses canais. Caso contrário, se você mantiver esses canais separados e competindo entre si pela atenção do cliente, vai gerar desgaste e, no limite, espanar o cliente.


Coincidentemente, saindo do evento eu liguei o rádio no carro e, momentos depois, passou o anúncio de um evento sobre omnichannel aqui em São Paulo. Uau, isso foi rápido!


Ela destaca que é muito, muito importante, haver liderança na empresa para que essa evolução possa aparecer. É preciso existir um profissional com visão, energia e conhecimento capaz de conduzir a iniciativa de marketing e unir todas as formas de interação com o cliente em um continuum mercadológico.

Aliás, uma das máximas que ela, e outros repetiram, é “garantir que a experiência do meu cliente seja homogênea entre todos os canais”. Por exemplo, pode acontecer de eu olhar o preço de um produto na web usando o smartphone, depois conversar pelo chat com uma vendedora via laptop e sair, de carro, para ir até um shopping visitar a loja física e comprar o produto lá. Para que todas essas interações agreguem e fortaleçam a marca com o cliente, é preciso que sejam consistentes. Imagine, ver um preço na web, ir até a loja e encontrá-lo por outro valor lá?!

Outros

Em seguida veio o case de Marketing de canais da Natura. Interessante, mas meio livro-texto – nada realmente inédito ou impactante.

Teve uma palestra da startup Qedu, que me parece que vende análises de dados do sistema educacional público. A proposta é subsidiar o Estado com dados sobre seus alunos, para poder melhorar a educação. Hoje os dados são coletados a cada dois anos (o último conjunto é de 2015), e a meta é conseguir atualizar ao menos uma vez por mês, ou idealmente uma vez por semana, e alimentar as análises com isso. Interessante até, mas eu possuo uma opinião pessoal sobre essa idéia e preciso me abster de comentá-la.

Depois veio o primeiro painel, sobre a transformação digital do Marketing. Interessante pelo que expõe das engrenagens internas de cada empresa e como pensam, mas nada digno de destaque. Achei curioso as diferenças de perfil, nítidas entre consumidores de serviços de BI (a GE e o Sonda) e os fornecedores desse serviço (SAS e Mood/TDWA.) Assistam ao vídeo para entender.

Veio, então, a palestra do Pactual-BTG, sobre sua transformação de banco físico em digital, e logo depois uma fala do Aluizio Falcão Filho, do Círculo Millenium. Esse eu queria que tivesse falado mais – de novo, por motivos pessoais, não profissionais.

Ih! Olha eu aí! (4:01:37)

Ele contou uma ótima: já ouviram falar do Bebê Johnson & Johnson? Pois é, segundo o Aluizio, a primeira foto de um bebê J&J foi feita do filho recém-nascido de um dos envolvidos – não sei do marketeiro, ou do empresário da Johnson & Johnson à época. Adivinha quem era?

O JOÃO DORIA!!! :-D Sim, o prefeito!!! Ele foi o primeiro bebê! Devia ter se chamado era Aparecido, mesmo… kkkkkk (pode parecer teoria conspiratória, mas justamente este trecho, que começa em 3:42:30, não foi gravado. Eu procurei referências a isso na web, mas não achei confirmações. Se um dia eu tiver uma chance, confirmarei essa história.)


A Bola, Finalmente

E então chegou o último painel. O SAS, alimentado por idéias de marketing, criou uma linha de produtos de “Analytics” para os esportes. Primeiro eles falaram sobre o filme Moneyball, que veio do livro homônimo:

Moneyball, o livro.

Pelo trailer pareceu muito legal, e eu vou assistir: um time de baseball, que havia sido rebaixado no último campeonato, decide que vai se reerguer e acaba sendo salvo por um sujeito que tabulou estatísticas de inúmeros jogadores. De posse desses dados, esse analista conseguiu encontrar bons jogadores, que estavam subvalorizados, possibilitando montar um time barato, de qualidade, que finalmente alcança o sucesso.

Isso é que é Data Mining de raiz!

Outro livro mencionado no mesmo momento foi o Soccernomics, que vai na mesma linha de análise de dados, agora no futebol.

Soccernomics, Freakonimics de soccer. Duhn, óbvio.

O nome é uma referência a outro ótimo livro, que expõe contudentemente o valor que uma análise calcada em fatos pode ter, o Freakonomics. Esse eu li, e adorei.

O palestrante, então, monta o painel, chamando os outros três participantes, e começam a bater-papo sobre o assunto.

Acho que deixaram o mais legal para o final.

Sabia que existe uma empresa que registra todas as estatísticas de ações de jogadores em campo? Sabia que existem empresas de Data Mining que analisam esses dados e traçam perfis e estratégias? Meu, é um mundo de coisas que são feitas com BI nos esportes em geral – e no futebol, especificamente – que você nem imagina!

A conclusão desse painel, para mim, foi o ponto mais alto de um lance que já estava lambendo a estratosfera de coisas legais: a Paula Baeta, da Analysis, pegou os dados coletados pela Footstats, do Romanini, e montou um modelo explicativo (não preditivo) para identificar que variáveis explicam a classificação de cada time na última temporada. (Não me peçam detalhes – assistam ao vídeo!)

Daí ela pegou esse modelo e saiu trocando os valores de cada métrica (eram 6: uma positiva, e 5 negativos) entre os times. Por exemplo, ela pegava a quantidade de cartões amarelos do melhor time e colocou no pior, para ver se, de acordo com o modelo, algo teria sido diferente. Ela fez isso umas três vezes, com três times. Muito legal! Se você gosta de futebol, assista, vai se divertir!

Conclusão

O mercado de BI martela “ferramenta” nas nossas orelhas o tempo todo. Todo mundo quer ferramenta.

Quando uma empresa que está no mercado há quarenta anos, que cresce anualmente sempre na faixa dos dois dígitos, vem a público contar as suas histórias, pode ter certeza que vamos ter uma chance de aprender coisas novas. Descartada a parte comercial, que está ali para vender o produto, a parte de negócio, mesmo pequena ainda é extremamente valiosa.

Tocar uma bola redonda, com BI, é usar os dados para impactar a lucratividade de uma organização. Assista ao vídeo, ouça a mensagem e aprenda com essas idéias. Deixe a bola quadrada para a competição selvagem do mercado de software, e abra-se para o imenso mercado, de grandes valores, que existe para quem conseguir tocar uma bola redonda no gramado do BI.

É isso. Até a semana que vem. ;-)

 

Pentaho Day 2017 – BI E.V.A.

Neste exato momento estou assistindo a uma palestra do Pentaho Day 2017, ao qual eu tive a honra de ser convidado como palestrante. Minha palestra foi ontem, dia 11/5/17, e chamava-se BI E.V.A. – Enxuto, Valioso, Ágil. Ela teve uma recepção muito boa, acima do que eu esperava, e estou muito feliz de ter podido proporcionar aos participantes algo que eles tenham gostado.

Neste link você pode baixar um PDF das notas, que traz os slides e todos os comentários que eu “fiz”.

BI E.V.A.

O clipe do começo pode ser assistido neste link, para o Youtube. É o videoclipe Houdini, do Foster The People.

Foster The People – Houdini.

Eu estava salvando minhas (poucas) idéias para o Pentaho Day 2017. Agora que passou, voltarei a postar com mais frequência, focando justamente os temas de valor, agilidade e lean em BI.

É bom estar de volta. :-)

BI Morreu Parte II – A Bola Quadrada

O sonho de consumo do Kiko.

Um ex-aluno meu me mandou um e-mail sobre o post BI Morreu, Vida Longa ao BI!:

Bola quadrada

Lembra-se do episódio do Chaves em que o Kiko pediu ao Prof. Girafales uma bola quadrada? Tirando a parte cômica, que obviamente era a intenção, muitos devem ter ficado a imaginar que sujeito chamaria de “bola” um objeto quadrado.

A minha percepção do mercado de BI é que tem um monte de gente discutindo “bola quadrada”. Alguns o fazem intencionalmente (marketing/buzzwords) outros por não ter a noção de que uma “bola” (BI) precisa ter um formato esférico (coleta de dados, transformação e análise visando a administração do negócio.)

E isso só é possível, na minha humilde opinião, por caudas dos seguintes fatores:

Definição

Bolas são objetos físicos. É muito fácil saber quando uma bola não é uma bola. Quando alguém aponta um cubo e o chama de bola, todo mundo corrigi-lo-á (kk) porque os atributos fisicos de uma bola são muito comuns e fáceis de se observar. Em BI, apesar de termos uma definição, não estamos falando de um objeto fisico, e isso complica tudo, sem falar que cada um tenta definir BI à sua maneira.

Palavras só tem sentido porque acreditamos nelas.

“E daí que estão chamando uma rosa por outro nome? Ela ainda é uma rosa”, dirão muitos.

E por falar em rosa, imagine um mundo onde todos têm a palavra “rosa” apagada da mente. Nesse mundo, quem por um acaso encontrar uma rosa, chama-la-ia de quê? De BI? Datalake? Rosalake? RSRSRs.

Uma coisa/objeto só tem um nome porque convencionamos que eles assim o teriam… Se, nos próximos mil anos, o nome do objeto que hoje chamamos de rosa mudar para fruta e o que chamamos de fruta para flor, não fará diferença – desde que todos concordem, ou sejam, desde que todos passem a usar isso na prática.

Empresas visam o sucesso

Por óbvio. Ninguém monta um negócio para perder dinheiro. Como sabemos, BI já foi chamado de SAD (Sistemas de Apoio a Decisão), de Inteligência Empresarial, de DW (!) etc.

Vejo essa fluidez das definições como uma estratégia da indústria para continuar vendendo suas “soluções”, pois sempre que algo dá muito errado – e projetos de BI tendem a dar errado por sua complexidade e por tocar na fonte do poder das organizações, que são as informações – “eles” (o mercado, a indústria, chame como quiser) trocam o nome do “BI”.srsrs

Francamente, eu não tenho o que adicionar. Esse post, aliás, é só para mostrar o que ele escreveu: muito obrigado, meu caro.

Eu estou nesse mercado desde 2000, e em abril completo 17 anos lidando com BI. Eu testemunhei isso várias vezes, em primeira mão até. É só olhar quem levou o termo BA ao mercado: o SAS. A expressão BI estava ficando queimada de tanto que todos chamavam tudo indiscriminadamente de BI. Como a proposta do SAS é muito mais sofisticada que uma apenas ferramenta ou uma caixa preta qualquer, eles se movimentaram para lançar um termo novo – aí por 2004-2006. Colou, até certo ponto, já que muitos hoje preferem falar Analytics a BI.

Uma coisa que acabou saindo nessa conversa é um novo significado para Kiko: “aquele que pede uma bola quadrada”. Minha jornada pessoal, dia-a-dia, é fugir de ser o Kiko. Por mais que isso possa parecer irrelevante, para mim entender como as coisas funcionam é importante. Eu me esforço para entender que coisa é que coisa, e que coisa é outra coisa.

Que coisa confusa…

Eu luto todo dia para não ser um Kiko. Talvez um dia eu consiga ganhar. ;-)

Até a próxima!

Introdução a Data Mining

No post Full Metal BI Itch eu coloquei uma pergunta:


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


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

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

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

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


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


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


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

Você foi avisado. ;-)


Senta que lá vem história!

Zabbix & Data Vault

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

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


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


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

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

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

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

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

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

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

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

Acabou!

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


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

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


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

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

Era tentador demais para eu deixar quieto, hehe.

Extrapolando

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

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


Tá-dá-dum-tssssss!!


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

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

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

O Problema & Sua Solução

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

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

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

Como esse problema é resolvido?

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

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

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

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

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

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

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

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

Pegou a idéia?

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

SEMMA na Veia

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

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

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


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


SEMMA significa:

  • Sample
  • Explore
  • Modify
  • Model
  • Assess

Funciona assim:

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

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

Ao trabalho!

Sample

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

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

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


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


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

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

O resultado é:

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

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

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

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

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


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


Como amostrar? Há diversas técnicas:

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

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

Amostragem “reservoir” no PDI.

Pronto, etapa concluída.

Explore

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

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

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

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

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

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


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


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

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

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

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

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

De novo, agora com o *dataset* completo.

Ô, diacho! Mesma coisa?!?

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

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

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

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

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

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

Esse gráfico foi desenhado com o GNUPlot.


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

Modify

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

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

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


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


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

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

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

Que plotando dá:

Mesmo gráfico, agora agregado por dia.

Notou algo incomun?

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

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

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

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


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

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

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

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

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


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

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

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

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

Model

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

Mas vamos um passo de cada vez.

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


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


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

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


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


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

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

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

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

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

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

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

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

Ela se sustenta?

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

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


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

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

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

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

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

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

Como pedir uma regressão linear no LibreOffice.

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

Parâmetros da regressão linear no LibreOffice.

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

Ajuste plotado sobre dados, extrapolando o futuro.

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

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

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

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

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

A interpretação desse modelo é o seguinte:

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

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

Assess

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

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

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

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

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

Primeiro, eis o resultado da regressão:

Regressão sobre os primeiros 80% do dataset.

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

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

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

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

Erro do modelo em relação à realidade.

Respostas, Afinal!

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


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


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

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

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

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

Portanto nosso modelo deve ser:


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


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

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

Quanto tempo de coletas diárias esse HD comporta?

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

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

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

Com que velocidade ele está enchendo?

Basta resolver a equação para um dia:

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

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

Quando ele vai estar a 75% da capacidade?

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

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

Irrelevante, concordam?

Conclusão

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

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

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


(…)

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

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

(…)


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

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

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

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

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

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

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

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

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

Então é isso.

Acabou? Sério? ALELUIA!

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

:-)

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

Até a próxima. ;-)

 

BI Morreu, Vida Longa ao BI!

“BI”, como um acrônimo que define uma tecnologia, mudou de significado? Morreu sua tradução clássica e significa outra coisa? Ou pior ainda, não significa mais nada?

Como vocês devem ter notado no post A Culpa é do Cubo, minha grande amiga Gisele comentou:


Quando aparece um problema para analisar ou resolver, ou ter uma visão do que está acontecendo com um processo, eu faço meu BI em cima dos dados crus que coleto na base de dados e depois de fazer todos os cruzamentos de dados e conseguir obter a resposta e fazer uma análise do cenário, aí sim, penso que esse resultado e essa análise poderá ser insumo para um Cubo(…)


Naquela mesma semana eu fui ao aniversário de outro grande amigo, que fez um comentário análogo. Eu não aguentei e perguntei:


  • E o que é que você chama de BI, hoje em dia?

  • De visualização de dados.


Uau.

Uau o caramba! Eu me recusei a ver isso por anos, mas a verdade é que o mercado de ferramentas de visualização de dados, que é um cisco da cadeia de valor de soluções de Inteligência de Negócios, tanto bateu, esbofeteou e massacrou a expressão “BI”, que ela mudou de significado!

Aplicando a “caneta des-hype-zadora” ao que se fala hoje em dia, temos um pequeno dicionário da língua do BI:

  • “Meu BI faz isso.” Tradução: “minha ferramenta de visualização de dados faz isso”;
  • “Instalei um BI no meu departamento”, ou seja, estou tabulando dados com Excel (hehe, ok, foi maldade – mas você entendeu o ponto, não é?)
  • “Preciso comprar o BI”, ou seja, preciso ter uma ferramenta para visualizar os dados que eu quero investigar.

Ah, Fábio, dirão vocês, seu preciosismo teórico é uma besteira. O nome não importa.

É verdade, concordo, eu sou um cara preciosista e nomes não importam.

Almoço de Hoje: Plantas e Bichos Mortos

Faça um experimento. Convide alguém para jantar falando assim:


“Oi, vamos mastigar e engolir no começo da noite um alimento à base de plantas maceradas e gaseificadas com fermentação de levêdos a partir de amidos e glicose, leite coagulado e fungos, tudo queimado pelo calor de árvores incineradas dentro de um buraco de pedra?”


É ruim, hein?! Acho que nem o Dr. Sheldon Cooper encararia essa numa boa…

Vamos trocar aquelas coisas que não importam, os nomes, por outras coisas que não importam, outros nomes? ;-)


“E aí, topas jantar uma pizza de funghi, em forno à lenha?”


Agora sim, né não? Quem recusaria uma pizza, ainda mais de cogumelo? (Bom, eu não recusaria, mas pensaria duas vezes – cogumelo não é a minha praia…)

Então vamos parar com essa relativização frescurenta. Não sou contra a evolução da língua, até porque ela muda sem dar a menor peteca para a opinião de ninguém, muito menos a minha, mas palavras e nomes importam sim, e muito.

Show Me The Numbers

Sendo um cara da Ciência, o mínino que eu precisava fazer era olhar ao meu imediato redor. Por isso eu aproveitei a confusão da semana passada e deixei uma enquete simples no blog:

Fale aí, eu quero saber: o que é que você entende por BI?
Fale aí, eu quero saber: o que é que você entende por BI?

Nem fiz muita propaganda. Apenas pedi para um ou outro conhecido ir lá responder, por curiosidade minha mesmo. Eis os resultados:

A voz do povo é a voz da média.
A voz do povo é a voz da média.

Ora vejam só. A maioria acha que é “uma área do conhecimento”, seguido de perto por “Uso de dados para administração” mas, que curioso, temos um voto para “é uma ferramenta”!

Se eu fosse um cara com uma vontade louca de achar justificativa para minhas opiniões, eu generalizaria esse resultado e descartaria aquele único voto como uma parcela ignorante da minha audiência – como aquele cara que detesta o que eu escrevo, mas lê só para me ver escrever bobagem e pagar mico.


Sim, é feio, mas admito: eu faço isso. Só que eu nunca vou contar que sites. ;-)


Só que eu não sou esse tipo. Eu gosto de testar minhas hipóteses até conseguir descartá-las. Só quando eu não consigo é que eu começo a ponderar a possibilidade de eu estar certo.

Assim sendo, o primeiro fato a ser levado em consideração para entender essa minúscula pesquisa é: quem lê meu blog acaba necessariamente tendo alguma identificação comigo. Logo, o resultado é mais que natural: é esperado. Muito provavelmente, as mesmas perguntas colocadas com outras palavras, em outro contexto, teriam respostas distribuídas de maneira diferente. Logo, de saída, este resultado não prova nada, a não ser que estamos entre os nossos. ;-)

Estando consciente dessa tendência a se auto-confirmar, ou viés de confirmação, e de acordo com um livro muito bacana chamado Como Medir Qualquer Coisa, esse único ponto, dentro do pequeno universo de respondentes, tem um peso muito grande. Ele indica que existe uma parcela significativa de pessoas que entende que Inteligência de Negócios é, sim, uma ferramenta. Só isso bastaria para concluir que o significado do termo mudou, ou no mínimo está ainda mais nebuloso que antes.

Mas podemos ir um pouco além e considerar que ele significa ainda mais. (Ou seja, que eu estou ainda mais equivocado que eu esperava.)

A pesquisa aceitava até duas respostas por participação. Então, um participante poderia escolher quaisquer duas combinações de respostas.

Agora, olhe de novo a pesquisa. Releia as opções com atenção. Notou algo? Veja estas declarações:

  • O uso de dados para administração pode ser interpretado como Uma área do conhecimento;
  • A visualização de dados pode ser interpretado como Uma ferramenta.

Você concorda ou discorda das comparações acima? Agora veja essas outras:

  • A visualização de dados pode ser interpretado como Uma área do conhecimento;
  • O uso de dados para administração pode ser interpretado como Uma ferramenta.

Para mim é fácil concordar com estas afirmações. E você? Ainda temos uma última comparação possível:

  • O uso de dados para administração pode ser interpretado como A visualização de dados;
  • Uma ferramenta pode ser interpretado como Uma área do conhecimento.

E agora? Para mim, é mais difícil concordar com estas frases que com as combinações anteriores.

Essas sensações de que as coisas “se casam” ou “não batem” indicam que, nas nossas cabecinhas pensantes, há uma correlação intuitiva entre “visualização de dados” e “ferramenta”. Logo, é razoável supor que quem marcou “visualização” tende a ver BI mais como uma ferramenta que como uma ciência.

Aceitando essa equivalência intuitiva como algo real, podemos usá-la para transformar as quatro categorias que receberam votos em duas. E isso faz com que o resultado mude um pouco:

Um ponto bem maior do que parece.
Um ponto bem maior do que parece.

Conclusão: Vamos Bater no Autor!

Bom, meu blog, minhas encanações. Eu sempre escrevo para mim mesmo, antes de mais nada, e torço para que você ache algum valor nestas mal-traçadas. A pergunta do dia era “o termo Inteligência de Negócios, ou BI, mudou de significado?”

Em primeiro lugar, qual era o significado original? Existiu uma primeira definição?

Sim: em 1958 apareceu um artigo chamado A Business Inteligence System, publicado por um pesquisador da IBM. Você pode visitar o link e ler o abstract, ou até mesmo comprar o paper (US$33,00 – carácoles!), mas em resumo ele propõe um “sistema de inteligência de negócios” que visava montar um processo para capturar o conteúdo de documentos (em papel mesmo, era 1958) daí, automaticamente, produzir um resumo (abstract) e distribuir o conteúdo para os devidos “pontos de ação”.

Isso é só um tantinho distante da nossa idéia contemporânea, tal como consta na Wikipedia:


Inteligência de negócios (…) refere-se ao processo de coleta, organização, análise, compartilhamento e monitoramento de informações que oferecem suporte a gestão de negócios.


A minha definição vai na mesma direção, mas pelo lado da Ciência:


Inteligência de Negócios é a aplicação do Método Científico para administração de uma organização.


Mesmo assim, existe uma palavra-chave comum entre todas elas: processo.

Então sim, existe uma idéia original associada à expressão Business Intelligence: um processo de coleta e análise de dados.

Portanto, se em poucos dias, eu consigo coletar um resultado que, levados em consideração os vieses presentes, ainda mostra um número não-desprezível de opiniões dizendo que BI é, sim, uma ferramenta, não nos resta outra opção a não ser aceitar que essa mudança aconteceu. Mesmo que não seja massiva, avassaladora, o acrônimo BI perdeu parte do seu significado original e hoje é usado com outro significado, com uma alta frequência.

Pior ainda: dado o altíssimo nível dos meus amigos, eu diria que a mudança atingiu massa crítica, e virou senso-comum, até.

Resultado? Ora, se BI não é mais o que BI costumava ser, precisamos de um novo nome para o que BI era e não é mais.

E qual usar? BA? Analytics? BigData? Data Mining? Data Discovery? Business Discovery?

Affff… :-(

Uma definição é assim tão importante? Por quê? Não podemos só chamar tudo de “uga” e viver felizes para sempre?

Uga Uga Uga Uga Uga Uga Uga Uga Uga.

Traduzindo: não.

Definições são parte básica de qualquer coisa na vida de um ser humano. Pai e mãe são definições, das fortes, aliás. Amigos, emprego, comida, felicidade, problemas. Problema não é o mesmo que felicidade, que não é o mesmo que amigo etc. etc. etc.

Se não sabemos nem sequer do que estamos falando, pombas, estamos falando de alguma coisa?

A minha proposta é simples: ao vinagre com essa barulheira, com todas essas buzzwords! Vamos repensar nossas organizações do nosso ponto de vista, do trabalho que temos a fazer, dos problemas que temos a resolver, e rejeitar o ponto de vista de quem está do lado de fora, tentando nos ganhar pelo impacto, pela surpresa, pela forma.

Vamos focar no conteúdo ao invés de no contorno.

Se BI, em 2017, quer dizer “ferramenta de visualização de dados”, temos que decidir: ou a antiga definição não servia para nada, e por isso morreu e agora tudo é só visualização de dados, ou existe algum valor a ser tirado de todos os dados que nossas organizações produzem e precisamos de um nome para isso.

Nem pense em BigData! Muito menos em Analytics!

Na minha opinião, na minha humilde, modesta e irrelevante opinião, essa expressão é Inteligência de Negócios. Porque eu me recuso a igualar uma expressão que junta coisas tão grandes e abertas como inteligência e negócio a um mero pacote de software. Ainda mais levando em conta que inteligência, em si mesmo, é um campo vastíssimo de debate e estudos. Me recuso a diminuir uma das expressões máximas do que é ser um Humano a uma mera buzzword de uma indústria, não importando o tamanho dessa indústria. Nunca vai ser maior que “inteligência”.

E só para não deixar negócio no vazio, vamos lembrar que se não fossem os negócios não teríamos Capitalismo, e sem o Capitalismo ainda viveríamos em cavernas. Nada do que o Capitalismo criou, desde toda tecnologia que hoje nos cerca até a imprecedente redução da pobreza da nossa era, existiria se não fosse a instituição humana, natural, de trocas voluntárias, de negociar, de fazer negócios.

E daí que estão chamando uma rosa por outro nome? Ela ainda é uma rosa.


BI morreu.

Vida longa a BI!!


E daí que estão chamando uma rosa por outro nome? Ela ainda é uma rosa.

Mas estou aberto a sugestões, claro.

Até a próxima. ;-)

Coletânea GeekBI 2016 a Caminho & Pesquisa

Quem ouviu as notícias do final do dia, hoje, talvez tenha ficado sabendo que as nuvens sobre São Paulo tiveram um episódio de… piriri hídrico, digamos assim, por falta de um termo mais educado, parando a cidade, inundando tudo. Resultado? Sentei para escrever o post de hoje e são 22:22.

Ohhh, a hora mais legal do dia!

Enfim, não deu para terminar o post que eu comecei para hoje. Para não desperdiçar sua viagem até aqui, que tal responder uma pesquisa rápida? ;-)

Conte-me Tudo, Não me Esconda Nada

O tema do post desta semana era (e vai ser, semana que vem) a transformação do acrônimo BI em algo diferente do que ele designava quando foi criado, na década de 50 e a minha resistência em aderir a essa… evolução.

Por isso, já que eu não consegui terminá-lo hoje, queria saber, eu pouquíssimas palavras, o que você acha?

Dá para escolher até duas respostas, se você achar uma só limitante demais.

Mantenha seu cadastro em dia

Eu sempre quis dizer isso, hehe.

O livro com a coletânea dos posts de 2016 já está na Amazon, e vou lançá-lo. Como eu prometi, meus leitores terão um descontaço (de graça!) para levá-lo, mas para isso eu preciso me comunicar diretamente com eles – com você. Como eu vou usar uma ferramenta de mala-direta para fazer esse (e outros) contato, precisarei confirmar os dados de vocês.

Você, que fez o cadastro no blog, vai receber um e-mail para confirmar esses dados. Se você preferir saber das novidades apenas pelo aviso-padrão do WordPress (a ferramenta que gerencia o blog), basta ignorar o contato.

Quem confirmar vai ficar em uma lista prioritária, e ser avisado antes de todos.

Estou tentando, mas reescrevi esse trecho dez vezes e ainda estou parecendo/me sentindo uma propaganda da Polishop… Desculpa aí, ó.

Dica: se você comprou o livro Pentaho na Prática, e atualizou, não deixe de ler o final, depois da biografia!!

Finalmente, se você se cadastrou como um outro blog, considere adicionar seu e-mail também, já que eu não consigo contatá-los apenas por esse vínculo.

Por hoje é só isso mesmo. Até semana que vem! :-)

A Culpa é do Cubo!

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

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


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


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

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

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

Por causa do cubo.

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

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

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

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

O Mundo Não é um Quadrado em 3D

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

Um exemplo fácil é Data Mining

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


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


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

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

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

Outro exemplo? Claro: painéis.

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

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

Quase.

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

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

Diferentes cubos.

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


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

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


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

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


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


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

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

Worlds Collide!

Eis aqui o Manifesto Ágil:


Manifesto para o desenvolvimento ágil de software

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

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

> Software em funcionamento mais que documentação abrangente

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

> Responder a mudanças mais que seguir um plano

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


Esse é precisamente o ponto:

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

Colocando de outra forma:


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

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


Conclusão?

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

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

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

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

Confuso? Para mim também. :-(

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

Até a próxima! ;-)


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

MDX Para Quê?

Por que alguém precisaria aprender MDX? É o que eu pretendo justificar aqui.

Preparado?

Get set, ready, go!

M-D-OQ?

MultiDimensional Expressions é uma linguagem para construção de visões de dados multidimensionais (i.e. com cabeçalhos em linhas e colunas) inventada pela Microsoft, a partir da meta simples de levar BI para as massas.

MDX é muito parecido com SQL, no sentido de que é uma consulta que “constrói” uma “tabela”, exceto por alguns fatos:

  • O resultado tem uma forma mais semelhante a uma planilha que a uma lista;
  • O motor que trata consultas MDX não é um banco de dados relacional tradicional, mas um servidor de dados multidimensional;
  • MDX não possui uma DDL, que é um conjunto de comandos para definir estruturas de dados. Em SQL, por exemplo, CREATE TABLE é um comando DDL;
  • E não tem esses comandos justamente porque o propósito do MDX é fazer consultas, não transações. Mesmo assim, criou-se uma coisa chamada writeback, que permite escrever dados de volta para o servidor multidimensional.

Se você ainda não adivinhou, MDX é uma linguagem de consulta de cubos OLAP. Daí você entende facilmente que MDX é apenas parte de uma arquitetura maior, que engloba um servidor OLAP, ou multidimensional (do qual o Mondrian é um tipo), e algum tipo de processo de atualização de dados.

Há dois bons livros para aprender sobre OLAP e MDX:

O Problema

Vamos deixar MDX de lado um pouco, e examinar o problema desta semana. Para (não) variar, é um problema que eu vim a enfrentar ao tentar resolver uma situação muito ordinária, apresentada por um colega de trabalho.

Esse colega trabalha no marketing da empresa e fez uma pesquisa com nossos empregados. De maneira geral, a pesquisa tinha dois tipos de perguntas:

  • Perguntas com respostas únicas, como sim/não ou uma lista de opções do qual somente uma podia ser escolhida. Por exemplo, setor do empregado (uma opção de uma lista), e se conhecia a estratégia da empresa (sim ou não;)
  • Perguntas que podiam ter nenhuma resposta, uma resposta ou mais de uma resposta. Exemplos: qual é seu meio preferido de comunicação (cite até três).

Para simplificar, assuma que esses dados eram coletados em uma planilha com este layout:

ID P1 P2.A P2.B P2.C
1 Sim E-mail
2 Não Cartaz Reunião
3 Sim

Obviamente a pesquisa era bem maior que isso, e tínhamos várias perguntas de cada tipo. O que é importante guardar aqui é que existe uma pergunta que gera uma resposta em uma única coluna, como a P1, e perguntas que geravam suas respostas em n colunas – duas, três, dez.

Como analisamos esses dados? Bom, por exemplo, podemos perguntar quantas pessoas conhecem a estratégia da empresa, que é a P1. A resposta é obtida somando-se todos os SIMs da lista de respostas. Um simples SELECT COUNT('SIM') AS conheco FROM pesquisa traria a resposta. Ou falando em termos de Excel, basta colocar uma função de contagem para totalizar a coluna da P1.

Outra pergunta pode ser: quantas pessoas têm no e-mail seu meio de comunicação preferido? A resposta, de novo, é obtida com relativa facilidade: contamos quantas vezes a expressão E-mail aparece na coluna P2.A.

Mas é claro que a realidade nunca é assim tão fácil, não é mesmo? Não teria graça, se fosse. ;-)

Suponha que nosso chefe peça o seguinte: “descubra os três meios de comunicação mais preferidos, por ordem do mais votado para o menos votado”.

Fácil? Algoritmicamente, talvez:

  1. Conte P2.A, P2.B, P2.c etc.
  2. Crie uma outra tabela, de duas colunas: opção e contagem;
  3. Insira, na primeira linha desta tabela, o rótulo “E-mail” na coluna 1, e sua contagem na coluna 2;
  4. Repita isso para todas as outras opções;
  5. Ordene esse tabela do maior para o menor, usando a coluna 2 e limitando o resultado em 3 linhas.

O resultado seria algo assim:

Meio Contagem
E-mail 10
Cartazes 7
Reuniões 2

“Ah”, pensas tu, “fácil como torcer para o Grêmio, guri!”


Estou em um treinamento de Lean Business Analysis pelo Luiz Parzianello, um porto-alegrense bah, tchê! Daí eu acabei pegando o sotaque, índio velho!


Então você pensa que é fácil?

Hahahahahaha…

Permita-me frisar:


HahahAHhAHHHaHAhAhAHAHHHahahaHAhahaha!!!….


É qualquer coisa, menos fácil. Por favor, tente essas análises:

  1. Qual é a porcentagem de empregados que conhece a estratégia e prefere e-mail?
  2. Qual é a porcentagem de cada opção, em cima do total de empregados que responderam essa pergunta?

A primeira análise é similar à inicial, mas com um filtro aplicado (conhece a estratégia = sim) antes de calcular a razão entre todos que responderam SIM para opção de e-mail pela quantidade de SIMs totais.

E a segunda? Simples:

  1. Calcular a razão entre a quantidade que respondeu “prefiro e-mail”, pela quantidade de participantes que tem pelo menos uma resposta;
  2. Calcular a razão entre a quantidade que respondeu “prefiro cartaz”, pela quantidade de participantes que tem pelo menos uma resposta;
  3. Etc.

E é claro que fica cada vez mais complicado: depois de dois dias trabalhando com Excel sem parar, o chefe olha seu relatório e diz: “excelente! agora quebra por setor!”

Vamos é querer quebrar a cabeça do pobre desafortunado que decidiu te ter na equipe, não é?


Vou tentar colocar de outra maneira: contagens simples são, como o nome implica, ações triviais. Só que, em geral, o maior valor de negócio está nas análises mais complexas, mais sofisticadas. Coisas que nem sempre podem ser respondidas com filtros e contagens.

Se meu exemplo não passou esse cenário, perdão. Esse é o cerne do problema: análises “complexas”


Trabalho de Ser Vivo de Crânio Ornado com Projeções Ósseas

Pode não ser um trampo excessivo quando temos uma pesquisa só, que por sua vez contém apenas uma pergunta deste tipo, que não tem mais que meia-dúzia de opções.

Mas, adivinha: meu colega vai fazer uma pesquisa assim uma vez a cada pelo menos dois meses! E cada uma das pesquisas do baita tem, por alto, uma meia-dúzia dessas perguntas, cada uma com quase dez opções, se não mais. E cada pesquisa atinge 10.000 empregados, com uma taxa de quantidade de respostas média em torno de 3.000. Ou seja, dos 10.000 pesquisados, em média, 3.000 respondem.

E conforme o número de variáveis sobe (gênero, setor, cidade, faixa etária, conhecimento etc. etc. etc.) sobe exponencialmente o trabalho para correlacionar uma coisa com outra.

Mas fica pior.

Uma Pergunta Múltipla Incomoda Muita Gente…

.. duas incomodam, icomodam muito maais.

Uma técnica prática para simplificar o trabalho de corno que é tabular esse tipo de dado é transpor parte da pergunta, ou desnormalizá-la. Por exemplo, a tabela do início vai de:

ID P1 P2.A P2.B P2.C
1 Sim E-mail
2 Não Cartaz Reunião
3 Sim

para:

ID P1 P2
1 Sim E-mail
2 Não Cartaz
2 Não Reunião
3 Sim

Notou o que eu fiz? Eu repliquei cada linha que tinha mais de uma resposta, e coloquei todo mundo lá.

Agora ficou mais fácil fazer uma contatem simples. Mas o que aconteceu se eu tiver DUAS perguntas de múltiplas escolhas?

ID P1 P2 P3
1 Sim E-mail Escolha X
1 Sim E-mail Escolha Y
2 Não Cartaz Escolha Y
2 Não Cartaz Escolha K
2 Não Cartaz Escolha Z
2 Não Reunião
3 Sim Escolha Y

Agora não basta mais contar cada coluna: é preciso deduplicá-las antes, e fazer as contas depois.

Uma vez a cada dois meses.

Em datasets pequenos, de coisa de 3.000 linhas… E algumas dezenas de colunas. Duas perguntas de cinco escolhas cada, as 3.000 linhas iniciais pulam para pelo menos cerca 6.000, podendo chegar – em casos extremos – a centenas de milhares de linhas… PARA SEREM TRATADAS NO EXCEL.

Não vira, né? ;-)

Operações de Conjuntos

Foi tentando resolver esse problema que a minha ficha caiu: eu vou precisar de um ETL específico para cada pergunta de resposta múltipla para colocar tudo como colunas simples, para permitir contagens simples, mas cada contagem vai ficar mais complicada ainda! É um círculo vicioso! A solução que achamos foi aplicar essa transposição coluna a coluna, uma de cada vez, e fazer análises estanques. Só depois, então, as análises de cada coluna são feitas.

MDX To The Rescue

Bom, MDX é difícil, na prática, mas na teoria, no conceito, é simples: uma expressão literal que manuseia conjuntos multidimensionais.

Falando de outra maneira, é uma linguagem que trata um problema complexo como o que eu expliquei aqui, com muito menos trabalho que toda operação manual.

Por exemplo, o caso inicial – top 3 canais – pode ser descrito como um conjunto formado pela união de três subconjuntos, que por sua vez recebeu uma ordenação com limite.


Eu voltarei ao assunto com um exemplo concreto. Por ora, por favor, tentem visualizar o que estou descrevendo.


Mas e se tivermos, por exemplo, várias perguntas de múltiplas respostas? Não tem importância: comandos MDX, que podem ficar verdadeiramente cabeludos, lidam com conjuntos de membros de uma dimensão (as opções de cada pergunta) e calculam as métricas para aqueles cruzamentos. Comandos que constroem sub-conjuntos podem ser aninhados para montar dois, três, n conjuntos e, em seguida, totalizá-los o apresentá-los como uma matriz – uma planilha.

Complexo? Sim. Pouco intuitivo? É, um pouco. Torna tudo viável? Sim!

Conclusão

Muito de análise multidimensional pode ser feito com um conjunto de dados simples e uma boa ferramenta OLAP. Porém, certos conjuntos de dados representam um desafio muito maior – que nem mesmo um bom trabalho de ETL pode simplificar. Podemos acabar mudando um problema complexo em outro, tão complexo quanto ou mais!

A linguagem MDX, e as tecnologias OLAP associado por trás, como servidor de dados multidimensional, pré-agregadores etc., são uma opção poderosa, geralmente certeira e muito pouco conhecida!

É esse cenário que eu pretendo mudar, daqui para o final do ano.

Até lá, guarde em mente que um analista de dados deve aprender MDX por dois motivos simples:

  • Permite analisar mais dados, mais rapidamente;
  • Simplifica o trabalho de responder uma pergunta a partir dos dados, tornando algo complexo em simples, e tornando em possível o im possível.

Até a próxima! ;-)

 

A Nuvem Negra

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

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

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

Boa Ciência

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

Russo rosna...
Russo rosna…

Tradução “limpa”:

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

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

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

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

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

Inteligência de Negócios

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


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


Revendo, acho dá para simplificar:


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


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


(…) E se você pudesse voltar um ano? O que faria? Mandaria alguém embora? Cancelaria uma venda ou faria mais pedidos de matéria-prima? Ou faria tudo igual, de novo?

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

(…) Se pudesse voltar um ano, saberia quando comprar e vender moeda estrangeira e faria uma grana fácil!

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

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

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


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

BI & Ciência

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

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


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


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

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

Uma Nuvem Negra

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

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

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

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

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

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

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

Bloody Conclusion

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

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

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

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

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

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

Vaga Pentaho Jan/2017

Isso é que é começar bem o ano!

  • Consultor Pentaho Experiência em conceitos de BI e modelagem dimensional para Data Warehouse;
  • Conhecimento avançado na linguagem SQL com foco em MySQL (versão 5.6 ou superior);
  • Experiência com a suíte completa do Pentaho sendo elas: Pentaho BA Server (versão 5 ou superior);
  • Pentaho Data Integration (versão 4 ou superior);
  • Pentaho Report Designer (versão 5 ou superior);
  • Modelagem de cubos no Mondrian (versão 3 ou superior);
  • Inglês avançado (Leitura e Escrita)

Intessados podem entrar em contato com Letícia Coelho em leticia ponto coelho arroba deal ponto com ponto br.