Re-Estimando Projetos de ETL

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

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

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

Introdução

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

Coletando os Parâmetros

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

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

Descrevendo a necessidade do cliente.

Descrevendo a necessidade do cliente.

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

Daí eu procuro descobrir o seguintes:

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

Completando o Cenário

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

150325_ReEstimandoProjetosDeETL_02

Provável Data Vault para a necessidade anterior.

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

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

150325_ReEstimandoProjetosDeETL_03

Provável estrela deste caso.

O Processo de Estimativa

Pelo que eu tenho visto, em média:

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

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

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

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

Alguns modificadores:

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

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

Estimando…

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

  • 1 semana para iniciação do projeto;
  • 1 semana para estabelecimento da linha de produção do Data Vault;
  • ETL do Data Vaul: ( 1 hub + 1 satélite ) * 1 hora = 2 horas -> arredondando, 1 dia;
  • ETL do Data Mart (trunca e recarrega): (1 dimensão + 1 fato) * 1 semana = 2 semanas.

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

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

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

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

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

Estimando Mais Adiante

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

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

150325_ReEstimandoProjetosDeETL_04

Diagrama DV para nova necessidade.

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

Exemplos:

H1 – H2 = Link 1-2

H2 – H3 = Link 2-3

etc.

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

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

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

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

Estimando:

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

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

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

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

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

Conclusão

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

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

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


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

CategoriasUncategorized

Cruel Sucesso

Vou contar uma história usando Scrum, para simplificar. Mas se você conseguir imaginar um projeto Waterfall que dê certo, pode aplicar a mesma história, pois o resultado seria o mesmo.

No começo tudo são flores: o cliente e a equipe constroem o backlog do produto. Neste caso, uma prosaica solução de análise multidimensional, OLAP.

A equipe trabalha duro, sempre em contato com o cliente, e no final da primeira sprint conseguem demonstrar a ferramenta, instalada e funcionando, e uma estrela simples: uma fato com uma métrica de quantidade, e a dimensão Cliente. O usuário consegue, por exemplo, contar a quantidade de clientes por cidade ou estado. “Beleza, mas você vai me dar mais coisas, né?” pergunta o ansioso usuário final. Claro, reassegura-mo-lo, vai ter a sua estrela completa no final da próxima iteração.

Ao final dessa primeira demonstração o PO (Product Owner) e a equipe se reúnem para planejar a segunda sprint. O planejamento praticamente endossa o backlog anterior, com pequenas mudanças pontuais e inconsequentes. A segunda sprint começa, evolui bem e termina em ordem. Nova apresentação é feita para o cliente, agora com a primeira estrela completa. O cliente decide colocar o sistema em produção, mesmo faltando mais duas estrelas, previstas para a próxima iteração.

A apresentação ocorreu de manhã, e a retrospectiva à tarde. No dia seguinte o PO vem para o planejamento da próxima sprint.

É quando a porca torce o rabo.

Pensando Bem…

“… e este”, conclui o Scrum Master, “é o backlog atual.Acredito que vamos manter as mesmas demandas, não? Com isso nós vamos completar a primeira release do OLAP no final deste mês, daqui a duas sprints.”

O cliente olha no fundo dos olhos do SM e diz “Sabe, depois da apresentação ontem, eu voltei e pedi ao Sr. BI que me deixasse testar um pouco mais o sistema.” O Scrum Master olha para o Sr. BI, que olha de volta, inocentemente. “Ele deixou?”, pergunta o SM. Sim, ele havia deixado, e até respondeu algumas perguntas, tanto que ele se atrasou para o começo da retrospectiva. “E você achou algum problema? Quer cancelar a entrada em produção desta estrela?”

- “Não, claro que não. É que, pensando bem… Acho que as próximas estrelas não são bem o que eu preciso.”

Paciente e diligentemente, o Scrum Master e a equipe escutam as novidades, debatem para entender e ajustam o backlog.

Veja: estamos começando a terceira sprint. Da primeira para segunda, tudo certo. No final da segunda o usuário conseguiu usar o produto por umas poucas horas e, antes de começar a terceira ele pediu uma mudança. Tudo dentro do bem-comportado processo do Scrum e, até aí, nada demais.

Sprint 3

E assim a Sprint 3 começou. Como das outras vezes, a equipe buscava o PO para tirar dúvidas e manter o trabalho alinhado com o backlog, mas parece que os selvagens tempos das Cascatas insinuavam-se pelas frestas: o cliente tentou mudar o backlog quase todas as vezes!!

Não era intencional, claro, afinal o cliente sabe que sabotar a equipe de desenvolvimento causa só uma vítima – ele mesmo. Não, muito ao contrário. Ele queria evitar que a equipe entregasse algo pouco valioso. Por isso o cliente sempre estava preocupado em mostrar como, a partir da Estrela 1, que ele estava usando desde sua entrega no final da Sprint 2, ele havia descoberto que a Estrela 2 (e a 3 também) trariam uma dimensão incorreta. O grão dessas duas novas estrelas servia, para a análise que ele achava que precisava fazer, mas não serviriam para a análise que ele descobriu que precisa fazer.

Esse é um problema grave: havia um desalinhamento fundamental entre o backlog prometido no início da Sprint 3 e a realidade do cliente. Quando o cliente começou a usar a Estrela 1, ele começou a “entender” os dados, o negócio e percebeu que havia feito pressuposições, e que essas agora mostravam-se incorretas.

Cuidado Com o Que Deseja…

… por que você pode conseguir.

A maior marca de um projeto de BI de sucesso é o seu aparente fracasso.

Por quê? Porque um projeto de sucesso gera novas perguntas, que geram novas demandas de dados, que faz parecer que o projeto está sempre no início! Mas não! Ele deu tão certo que o cliente avançou e aprendeu – gerou Inteligência do Negócio a partir dos dados.

É nesse caminho que ia nossa história: assim que o cliente começou a usar os dados de uma entrega de sucesso, a compreensão do problema mudou. É uma consequência natural de se aprender mais: novos conhecimentos desafiam nossas antigas visões e percepções. Ainda que isso aconteça em projetos de outros tipos de sistemas, em soluções de Inteligência de Negócios essa dinâmica gera consequências complicadas.

Por exemplo, aonde vai nossa história? Como ela termina? Assim.

O Scrum Master sacou o problema e decidiu convocar um fim abrupto para a Sprint 3. O cliente sentou novamente com a equipe e refizeram o backlog. A Sprint 4 começou e seguiu sem problemas. A demonstração ao final conseguiu recuperar o moral da equipe – estavam de novo na crista da onda, entregando valor para o cliente! Yeah! Touchdown!

Começaram a Sprint 4, que agora ia incluir novas dimensões e estrelas para aumentar a comunidade de usuários. O PO agora eram duas pessoas: o primeiro cliente e um novo usuário do outro departamento. Montaram um backlog para as próximas três sprints e planejaram a Sprint 5. Enquanto isso o novo cliente passou a usar as estrelas que já haviam sido entregues.

E adivinhe o que aconteceu? Isso mesmo: ele percebeu que havia entendido algumas coisas incorretamente. De novo a equipe não conseguia andar na sprint porque o novo cliente não colaborava. Mas desta vez a recusa era hostil!

“Vocês atenderam o outro direitinho! Porque não querem fazer o que eu preciso? Isso que nós combinamos não estava certo! Agora eu percebo isso, e não adianta continuar, eu não vou usar o que vocês estão fazendo!”

Conclusão

Preciso continuar a história? A Sprint 5 foi abortada – de novo – e a sprint 6 e 7 replanejadas. A Sprint 6 saiu redondinha, mas o sucesso deixou uma sensação de desconforto ao invés de alívio. A Sprint 7 foi abortada, virou 8, que deu certo etc. etc. etc.

Estou montando esse cenário na melhor das situações, com equipe funcional e capaz, Scrum Master habilidoso, clientes inteligentes etc. Imagine uma empresa que desenvolva em Waterfall, com feudos departamentais disputando acesso e posse dos dados, usuários mal-preparados ou obtusos…

E esse é um problema ainda mais insidioso porque eu nunca vi ninguém percebê-lo. Por um tempo achei que eu estava viajando! A história acima tem um ritmo acelerado, e talvez a velocidade normal de um projeto seja um impecilho para identificar essa situação. Projetos de BI têm a bagunça da redefinição de requisitos como normal, como consequência da indecisão do cliente. Ainda que haja um nível de indecisão, não acredito que seja esse o responsável por fazer o projeto parecer retroceder periodicamente.

Se você não se identificou com a história, pense um pouco e tente se lembrar: algum de seus clientes parece estar sempre aguardando a próxima versão? Tem algum cliente que sempre volta pedindo alguma mudança? Um novo relatório, uma mudança na dimensão, outra agregação para a mesma métrica? Será que ele não está mudando os requisitos por que está aprendendo?

Da próxima vez que alguém reclamar que o projeto de BI está patinando, erga as orelhas: o projeto pode estar sendo vítima do próprio sucesso!

Até a próxima!


P.S.: eu não sei como lidar com isso. Eu ainda não consegui pegar um caso destes acontecendo claramente, e mesmo que tivesse pego, não sei se saberia o que fazer. Intuitivamente eu diria que precisamos deixar o cliente com o sistema a sós por algum tempo – uma semana? um mês? – antes de planeja a próxima etapa de desenvolvimento, mas duvido que algum cliente toparia isso…

Pentaho Day 2015: Eu Vou!

LogoPentahoDay2015

Semana passada eu tive a honra de ser convidado pela organização do Pentaho Day 2015 para apresentar uma palestra no evento. Este ano a coordenação está sob liderança de Márcio Vieira, da Ambiente Livre, e o evento será em Curitiba, dias 15 e 16 de maio.

Ontem eu recebi a confirmação que minha proposta foi aceita:

http://www.pentahobrasil.com.br/eventos/pentahoday2015/blog/fabio-de-salles-pentaho-day/

O tema é Introdução à Inteligência de Negócios – Nadando na Sopa de Letrinhas de BI.

Você pode se inscrever através do Eventbrite – basta clicar aqui.

Nos vemos lá! :-)

Todos os Caminhos Levam a um DW

No final de 2014 o artigo Monetizing Big Data: A Q&A with Wells Fargo’s Data Chief expunha a opinião de que DWs não são uma condição necessária para projetos de BI de sucesso. Concordo com ele em certos pontos, mas não de maneira geral. Eu não cheguei realmente a detectar uma tendência que defenda isso, mas vejo essa mesma opinião em fóruns e na propaganda de algumas ferramentas de visualização de dados.

O Prof. Goodnight, CEO do SAS, tem um excelente artigo no qual ele retruca a declaração acima. Leia ambos, são muito bons.

Assim como o Prof. Goodnight, eu também não acredito que DWs tenham chegado ao fim do seu ciclo de vida. Vou contar uma história, e no final eu volto para amarrar as pontas. Divirtam-se!

No Início Era o Excel

Para escrever meu livro Pentaho na Prática eu criei uma base de dados de treinamento chamada Beltrano S/A. Essa base reflete o sistema transacional da empresa fictícia chamada (adivinhe!!) Beltrano S/A, que é uma empresa de treinamentos.

Agora imagine que o Sr. Beltrano da Silva decidiu investir no crescimento da empresa, e se prepara para abrir filiais. Ele usa alguns sistemas transacionais para cuidar dos negócio da empresa, e começa a fazer perguntas. Cada pergunta que ele faz percorre um caminho dentro da empresa – ora pelo Financeiro, ora por Vendas, ora por Operações – mas sempre acaba caindo no mesmo lugar: a Informática, que é a responsável por manter os sistemas funcionando.

Porque lá, se eles não têm nada a ver com o negócio em si, mas apenas com as bases e os dados? É porque os “outros” empregados da Beltrano não sabem mexer nessas bases, ou simplesmente nem sabem que elas existem.

O Sr. Gerente da Informática recebe cada um desses pedidos e devolve arquivos com linhas e linhas de dados. Por exemplo, o Sr. Beltrano pediu ao Sr. Gerente de Vendas a lista dos 10 cursos mais rentáveis por região de São Paulo, e por Bairro. O Sr. de Vendas pediu ajuda ao Sr. da Informática, que fez uma consulta na base e trouxe a resposta para o ano passado, mês a mês, em um arquivo CSV. O Sr. de Vendas montou “um Excel” com esses dados, imprimiu e entregou na mão do Sr. Beltrano.

Invariavelmente e, para supremo desgosto do Sr. de Vendas, imediatamente, o Sr. Beltrano olha os papéis na mão do subordinado de relance e responde: “Jóia, e quebrando por X?” X pode ser qualquer coisa – cidade, bairro, curso, instrutor, estado etc. etc. etc.

Água Mole em Pedra Dura

Você conhece o final dessa história: de tanto vai e volta alguém decide que precisam achar uma forma melhor de fazer isso. Descobrem que o assunto responde pelo nome de “BI” e vão ao mercado buscar o que precisam.

Vem uma consultoria e diz que precisam de um projeto super-duper de DW. Caro demais.

Vem outra e diz que precisam de Data Mining, que depende de construir um DW antes. Caro demais ao quadrado!!

Outra empresa oferece as ferramentas de BI, poderosas, complexas e caras, mas nada de serviço. Caro demais e trabalhoso demais.

Finalmente uma das empresas mostra um produto interessante: caro, mas acessível, permite manusear facilmente os dados de qualquer base. “Precisa de DW, como o projeto de Data Mining?” Nããão, diz o fornecedor, é self-service (!), basta conectá-lo à base de dados e mandar ver! É fácil e simples!

Fechado! Na semana seguinte vem o CD. O Sr. da Informática instala a cópia no computador do Sr. Beltrano e configura para ler as bases.

O Paraíso na Terra…

Nos primeiros dias o Sr. Beltrano até se diverte, mas ele tem mais o que fazer e repassa o serviço para um dos membros da TI, o Sr. Analista. Esse novo usuário conhece as bases e sabe como extrair o que o dono precisa.

Funcionou! Um relatório, um gráfico, um painel, outro gráfico… Ficando mais complicado… Pegando mais dados…

Pá! O pessoal de vendas começa a reclamar que o sistema está lento. O pessoal do Financeiro começa a reclamar que o sistema está lento. A menina da portaria reclama que o sistema está lento! Sem dinheiro para mais computadores, o Sr. da Informática tem a idéia salvadora: gravar uma cópia dos bancos na máquina do Sr. Analista.

… Não Existe

De novo, funcionou no começo. O problema passou a ser outro: os dados ficavam defasados, porque a base inteira era muito grande para copiar, e não dava para sincronizar minuto a minuto.

Tudo bem, disse o Sr. Beltrano, não precisa minuto a minuto. Uma vez por dia basta.

Beleza: durante a noite, um processo automático copiava a base, que estava sem atividade àquela hora, do servidor para o computador do Sr. Analista.

Funcionou? Sim, claro.

O Que Foi Agora?!

O Sr. Beltrano não deixava o Sr. Analista em paz, e chegou o dia em que pediu um relatório comparando aqueles números com os do mês passado.

Fácil! A base da Beltrano já tem histórico: ela guarda todos os dados e pedidos e coisas que aconteceram na vida da Beltrano. Claro que, no começo, a base era diferente e por isso os dados de um ano atrás estavam em tabelas antigas, que não era mais atualizadas. Tudo: o pedido era só para um mês.

Funcionou, no começo.

A base guardava tudo que ela processava, mas a complexidade do modelo de dados, aliado à complexidade das perguntas de negócio fazia com que os cruzamentos – as consultas SQL escritas pelo Sr. Analista – crescessem em complexidade. A certa altura o Sr. Analista levava até dois dias escrevendo e testando e debugando as consultas.

O Sr. Beltrano disse ao Sr. Analista, suavemente, que precisa de um serviço mais rápido De qualquer *%$%@!$ de jeito!

Você Está de Brincadeira!

A idéia salvadora veio de Vendas: e se o Sr. Analista deixasse os dados pré-arranjados? Ele tem poder total sobre a cópia do banco dele, mesmo.

Boa idéia, pensou o Sr. Analista, e montou consultas que pré-combinavam os dados em novas tabelas, mais simples, sem relacionamentos com nenhuma outra e fáceis de se consultar.

Funcionou? Sim, claro, no começo… KKKKK

O sistema antigo estava chegando a seu limite e por isso o Sr. Beltrano comprou um ERP. Resultado? Ele ficou sem relatórios do novo sistema por quase um mês, até o Sr. Analista aprender o suficiente para repetir as mesmas consultas no novo sistema, mas ainda assim não era a mesma coisa. As tabelas eram diferentes, os dados guardados eram diferentes, organizados de maneira diferente.

O fato é que todo o trabalho do Sr. Analista foi congelado. O Sr. Analista voltou para a TI e contrataram um novo profissional, de BI, para ajudar o Sr. Beltrano. Mais um ou dois meses, e o Sr. Beltrano, agora com uma nova versão daquela ferramenta – lembram-se? – estava de volta ao jogo.

QUEREM ME ENLOUQUECER?!!

(Risos)

Bom, lembram do Sr. Analista? Que voltou para TI? Então, souberam disso. Fora da asa do Sr. Beltrano, o Sr. Analista virou presa fácil da empresa inteira: pediam relatórios para ele o tempo todo! Financeiro, Vendas, Operações, a moça da recepção, todo mundo conseguia pedir alguma coisa para ele, e o Sr. da Informática deixava.

E isso funcionava? Não, é óbvio!!! (kkkk)

O backlog do Sr. Analista crescia, as reclamações sobre o Sr. da Informática cresciam (ele era acusado de não deixar o Sr. Analista atender quem precisava de ajuda) e as reuniões de diretoria estavam virando um pesadelo de conciliação!

Vejam, o Sr. BI, auxiliar direto do Sr. Beltrano, montava gráficos e relatórios e tudo mais – e o Sr. Analista fazia exatamente a mesma coisa, mas para o restante da empresa inteira. Cada qual em cima de suas bases, com seus próprios critérios, a seu tempo.

Os números viviam a se explicar. Era quase um Inquérito Policial-Matemático.

Highlander na Parada

Os cérebros da empresa concluíram que a raiz do problema era o fato de cada um usar uma base diferente e critérios diferentes.

Reorganizaram a empresa: montaram o setor de BI, que cuidaria de uma base de dados única. O Sr. BI cuidaria dos relatórios e análises, e o Sr. Analista manteria e extenderia a base.

Ah, é! A esta altura, a base de dados corporativa era uma mixórdia de tabelas, scripts, comandos SQL, componentes de replicação blá blá blá. Os tempos de consulta estavam ficando maiores, e tabelas de apoio eram criadas quando necessário.

Os Portões do Inferno se Abrem

Enquanto na teoria o Departamento de TI rumava para o manso recanto da base corporativa e dos empregados dedicados, felizes e satisfeitos, na prática a tensão crescia: o backlog de demandas do Sr. BI (que agora acumulava o do Sr. Beltrano e o do restante da empresa) transbordava. As reclamações de prevaricação, justas e nem tão justas, abundavam. Volta e meia voava um dedo na cara de alguém. Horas extras foram jogadas na equação, mas resolveu pouco, porque o time de BI estava no limite da exaustão.

A solução é óbvia! Contrataram um ajudante para cada um, descartaram o antigo software do Sr. Beltrano, compraram um novo, com portal web e recursos de Business Analytics Self-Service Turbo Pro 2.0 etc. blá blá blá

Aqueles Que Desconhecem a História…

No final, o cenário na Beltrano era apocalíptico:

  • O ritmo de produção de análises e relatórios era lento…
  • … por que todas as demandas da empresa passavam por dois empregados;
  • Na tentativa de aliviar esse gargalo, dando autonomia aos usuários, mais software foi comprado…
  • … e a demanda em cima do departamento de BI aumentou: além de atender os usuários do backlog, tinham novos produtos para cuidar.
  • O processo de ingestão de dados na base corporativa não era automatizado…
  • … o que ajudava a aumentar a carga em cima do departamento de BI.
  • Os usuários continuavam tão insatisfeitos quanto antes…
  • … e a sensação era de que “o BI” só atrapalhava.

… Estão Condenados a Repeti-la

Aos poucos alguns usuários mais espertos começaram a descobrir como acessar os dados da empresa, e conseguiam exportá-los para um Excel. Ali eles podiam trabalhar em paz, longe da zoeira que era “o BI”, e resolver suas necessidades.

Estava tudo indo bem, mas aos poucos o trabalho para manter aquelas poucas planilhas foi aumentando, as poucas planilhas viraram muitas planilhas, foram ficando mais complexas… O diretor de Vendas, que era mais desesperado, usou a verba do departamento para comprar um daqueles produtos self-service, se ligando direto nos dados.

E a roda seguia girando…

Data Warehouse São Obsoletos?

É claro que essa história é só uma invenção da minha cabeça. Mas, guardadas as devidas proporções, eu vi isso acontecer na empresa em que trabalho, e em outras empresas, através de relatos de amigos e conhecidos. Gente se queimando com chefe, chefe se queimando com diretor, e assim sucessivamente, no meio de uma bagunça de ferramentas e conceitos, com cada solução criando novos problemas mas nem sempre resolvendo os antigos.

Olhando só o que aconteceu com os dados da Beltrano S/A, o que vemos na história?

  1. No começo é consulta direta (e usa-se Excel para análise dos dados);
  2. Os dados passam a ser replicados integralmente (explorados com uma ferramenta mais adequada;)
  3. A cópia em tempo real é pesada demais e um compromisso é atingido: a replicação passa a ser diária;
  4. A cópia não basta: a complexidade dos dados força à sua recombinação a priori, antes da exploração – os dados começam a ser transformados durante a carga;
  5. A demanda sobe, e o peso dos dados é aliviado com estruturas de apoio, como tabelas pré-agregadas e/ou normalizadas.

Neste ponto a ferramenta de consulta precisa estar à disposição da comunidade de não-técnicos que consomem aqueles dados. Isso causa um efeito em cascata de demanda, sofisticação crescente, dados de outras fontes começam a ser requeridos e por aí vamos.

Conclusão

Quem é do ramo sabe o que aconteceu nessa historinha: a Beltrano re-inventou a roda da bicicleta, um raio de cada vez. Eles partiram da idéia simplória de que os dados podem ser consumidos em seu estado bruto, para chegar na necessidade de centralização e organização dos dados. Caso contrário as contradições e falhas dos dados vão aparecer nos números construídos por cada usuário. No limite não haverão dois totais de venda do mês iguais na empresa inteira.

Um Armazém de Dados não é um projeto estéril, um capricho do povo de TI. É um “ser” que reflete a empresa e seu conhecimento, que muda e cresce continuamente. Um DW constrói e guarda a memória que a empresa, na figura de seus empregados, consulta para estabelecer relações, para responder perguntas, para tirar as dúvidas no momento de escolher a direção do próximo passo.

Por isso eu não acredito que DWs sejam obsoletos. Cada nova moda tecnológica traz promessas valiosas, mas somos nós, seres humanos, que realizamos essas promessas usando essas tecnologias. Por si só, elas são estéreis. Não existe mágica, só trabalho duro e recompensas ao final do dia.

A Opinião dos Fornecedores

Alguns fornecedores perceberam a armadilha em que se colocariam se defendessem a não-adoção de DWs. Por exemplo, este post do Tibco Spotfire de 2011 explica que, apesar de custar dinheiro, muito dinheiro, um DW é importante e dá boas explicações do porquê. Já este outro artigo, de uma empresa alemã de consultoria, oferece alguns comentários interessantes sobre DW, sua importância e a realidade típica de projetos de DW. Leia ambos, valem a pena.

Até a próxima!

Quando Nuton Gritou Eureqa

Eu tento fazer com que todo texto seja fleugmático: interessante, mas controlado, sem deixar a empolgação subir à cabeça. Mas esse aqui vai ser difícil. Quando eu assisti o vídeo eu só conseguia pensar OMGWTFOMGWTF…

Funciona assim.

Data Mining é uma coisa manual. Não é possível fazer uma garimpagem de dados automática, por poucas e boas razões:

  1. Um modelo que represente um negócio (sazonalidade de vendas, por exemplo) é necessariamente muito complexo, e possui, necessariamente, muitas variáveis;
  2. A busca da equação mais adequada é um problema de combinatória: combinar N famílias de equações, parametrizadas por M variáveis;
  3. Dado o número de variáveis e as famílias de equações que podem servir como modelo, o número de combinações explode e a busca, mesmo com supercomputadores (que não estão disponíveis para qualquer um, diga-se de passagem), seria demorada demais para ser útil.

Tradicionalmente o analista de Data Mining faz uma avaliação dos dados, seleciona uma amostra e vira-a de tudo quanto é lado, tentando enxergar alguma possível relação entre as variáveis. A partir daí ele propõe alguns modelos e, paulitanemente, vai limando os menos adequados e melhorando as propostas iniciais. Isso repete-se até que o erro diminua para um patamar definido pelo negócio, e então testa-se o modelo contra o restante dos dados. Se passar, vai para produção, onde ele identificará possíveis clientes, prováveis fraudadores, relacionamentos em atrito etc. etc. etc.

Não dá para automatizar isso e obter um resultado dentro dos próximos milhões de anos, mesmo para pequenos conjuntos de dados, mesmo com problemas simples. Não dá, é uma impossibilidade combinatória. Sempre será necessário algum tipo de guia humano para ajudar a máquina a sair do outro lado.

Um bom programador pode olhar para isso e retrucar que “dá para fazer um programa pré-carregado com os modelos mais comuns e conhecidos”. Isso reduziria a busca no espaço de soluções a um volume muito menor que o espaço inteiro (que pode muito bem ser infinito) e assim semi-automatizar Data Mining. Ok, mas pouco prático, já que cada caso é um caso, e isso reflete-se em cada modelo é um modelo.

Qualquer um que estudou Computação Natural pode olhar para essa situação e intuir a existência de uma solução com Algoritmos Genéticos ou Computação Evolutiva. Eu mesmo, que fui aluno de algumas dessas matérias, cheguei a pensar se não seria possível um motor de Data Mining automático. Nunca levei a idéia a sério, até porque eu sou fraquinho com Matemática.

Mas não é que algém levou? E é isso que o Eureqa, da empresa Nutonian, faz: ele gera uma série de possíveis modelos, aleatoriamente, e evolue-os até um certo erro pré-definido. Nada mais óbvio, nada mais simples. Mas eles fizeram!!!!

Assistam os vídeos deste link para ter uma idéia de como funciona. O exemplo dado no primeiro vídeo (Through the Wormhole with Morgan Freeman) é o mais claro. Eu ainda acho que ele usou um caso muito simples, muito banal (um pêndulo duplo), mas mesmo assim é impressionante!

Pode parecer pouca coisa, ou besteirol científico, mas o simples fato de já existir um produto que faz isso torna a possibilidade de Data Mining automático muito mais próxima da realidade!

Uau!

Leia mais…

Um Ponto Fita o Mundo

Sua empresa precisa de um Armazém de Dados? Vocês decidiram adotar Data Discovery, então seu primeiro impulso é esnobar respondendo “não, porque a ferramenta não precisa disso”. (Estou sendo sarcástico. ;-) )

Já faz algum tempo que eu publiquei um post sobre o assunto, no qual eu apresentava um argumento definitivo (na minha opinião) a favor da adoção de Armazém de Dados por qualquer empresa que deseje investir em BI. Não tenho nada acrescentar àquele argumento, mas recentemente cheguei a uma outra interpretação e pensei se não seria bacana dividi-la com vocês.

Eu sou formado em Física. Um dos jargões que aprendemos na faculdade é o verbo “fitar”, um estrangeirismo a partir do verbo inglês to fit. Em português podemos usar ajustar ou encaixar mas, como bons brasileiros, falamos fitar e boas.

Em Física queremos explicar a Naturza e por isso boa parte do nosso trabalho é, a partir da observação de um fenômemo, escolher uma função matemática para descrever esse fenômemo – esculpir um modelo matemático da realidade – e tentar encaixar a função nos dados experimentais. Quando nossa função – nosso modelo – encaixa-se sobre os dados, sabemos que ela serve para explicar a realidade, até onde nossos dados experimentais chegam. Todas as fórmulas da Física que você aprendeu na escola são resultado desse trabalho. Seja a Lei da Gravitação Universal, seja o Princípio da Conservação da Energia ou as Leis de Maxwell, tudo, tudo decorrente do teste de modelos matemáticos contra a realidade.

Tentar encaixar a função nos dados experimentais é, você adivinhou, fitar uma curva. A figura abaixo é um exemplo clássico: uma reta fitando os pontos.

Exemplo de uma reta "fitando" os pontos. Será que não existe nada melhor?

Exemplo de uma reta “fitando” os pontos. Será que não existe nada melhor?

E cá entre nós, ô fitizinho ruim! Me parece que uma Gausiana e uma reta modulando uma quádrica dá mais certo… Não acham? ;-)

BI vs. To Fit

Bom, na minha opinião (sempre!), Inteligência de Negócios é a administração científica de uma empresa, é o processo de levantar hipóteses e testá-las, e usar o resultado para decidir entre uma ação ou outra.

Uma forma diversa de falar “testar hipóteses” é “encaixar uma fórmula a um conjunto de pontos”. Em bom fisiquês, é fitar uma função num experimento. Se você quiser ir mais longe ainda, é a criação de um modelo matemático para explicar a realidade. Mas aí também é pedir demais da TI…

Voltando, pergunta retórica: que função você pode fitar em um experimento que coletou a medida de apenas um ponto?

Um ponto não fita nada. Ou melhor: fita tudo!

Um ponto não fita nada. Ou melhor: fita tudo!

Esse ponto pode ser qualquer coisa, medida instantâneamente. Ou seja, uma medida no momento e mais nada. Como as vendas de hoje, ou o total de pedidos de suporte, o quantos chamados um empregado abriu… Qualquer grão, mas em um único momento no tempo.

Oras, se você mediu seu experimento apenas uma vez – uma única vez – então você tem apenas UM ponto. Quem lembra das aulas de geometria deve se lembrar do lema “uma reta é determinada por dois pontos”. Com um só ponto você não define nada, absolutamente e rigorosamente NADA. Qualquer uma das funções ilustradas pelas linhas coloridas no gráfico acima pode ser ajustadas para passar sobre o ponto medido. Não podemos afirmar nada sobre aquele pontinho.

E este é precisamente o fulcro: como é que vamos testar uma hipótese contra um conjunto de dados que possui uma só medida? Não vamos! Não é possível fitar nada a um conjunto que tenha só um ponto!

Colocada de outra forma, pode-se dizer que é possível fitar um mundo de teorias e hipóteses em um ponto! Não dá para negar nenhuma delas em favor de outra! Qualquer modelo pode explicar aquele ponto!

Agora, se formos adiante e, de tempos em tempos, repetirmos o experimento e coletarmos um novo ponto, teremos uma evolução daquela variável (ou conjunto de) ao longo do tempo. Podemos ver o que aconteceu até agora e tentar enter como aconteceu dessa forma, e talvez o que vai acontecer a seguir.

Agora sim: com mais pontos podemos ver como o sistema se comporta.

Agora sim: com mais pontos podemos ver como o sistema se comporta.

O gráfico acima conta o final da história: para entender o que está acontecendo no meu sistema eu preciso de mais pontos. Só acumulando medidas do sistema ao longo do tempo é que podemos testar e descartar ou confirmar hipóteses.

E um Armazém de Dados é o sub-sistema da disciplina BI que resolve essa demanda por informação temporal. DW é mais que um banco de dados ou um cluster Hadoop: é uma técnica de coleta organização de dados com vistas a análises futuras. Por isso usamos um DW para soluções de BI: para não ter que reinventar a roda e cometer todos os erros de novo, só para sair com um conjunto temporal de dados do outro lado.

Tempo Não É Tudo

Alguém menos informado pode sentir-se tentado a argumentar que não é preciso coletar dados ao longo do tempo se as variáveis de interesse não incluem o tempo. Por exemplo, “que perfil de mutuário tem mais chance de não pagar o empréstimo?” Basta eu montar o perfil dos Mutuários em atraso hoje para descobrir isso.

Bom, esse argumento tem dois grandes furos:

  1. Sem uma análise da relação ao longo do tempo você não pode dizer que variável causou que consequência. Em termos técnicos, a ausência do tempo proíbe quase sempre a determinação do nexo causal;
  2. Sem uma análise ao longo do tempo você não tem como dizer se o valor medido é um outlier ou é o valor normalmente encontrado para aquela variável.

Imagine a consequência de conceder mais empréstimos justamente para o maior caloteiro, só por que, por acaso, conseguiu pagar a dívida em dia no mês passado, enquanto que o melhor pagador se atrasou para chegar ao banco!

Não há escapatória: até mesmo para saber que uma relação é constante no tempo é preciso analisá-la ao longo do tempo.

Conclusão

Resumindo, você precisa armazenar histórico dos dados da sua empresa porque “um ponto não fita nada!”

Explicar para alguém porque um DW é necessário em projetos de BI, usando só uma frase, é uma coisa bem difícil. Primeiro precisamos entender que BI é, resumidamente, a tomada de decisão a partir do teste de hipóteses. Se aceitarmos esse fato (nem todos aceitam), ainda temos que entender que o teste de hipóteses é, na verdade, um trabalho de encaixar uma explicação matemática a uma realidade mensurada.

No fundo, não “precisamos” de DW. Precisamos é armazenar a evolução dos parâmetros da empresa ao longo do tempo. Podemos fazer isso de várias formas: um estagiário anotando valores em um papel de pão, ou uma planilha Excel, ou dumps de bases em um cluster Hadoop. Ocorre que, por acaso, DW é a tecnologia adequada para isso.

Se alguém te disser que você não precisa de DW para “fazer” BI, você vai acreditar?


Ah, em português fitar significa olhar fixamente.

Testando o Vertica

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

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

O Experimento

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

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

Tempo total para fazer a mesma coisa.

Tempo total para fazer a mesma coisa.

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

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

Tempo por operação nas duas tecnologias.

Tempo por operação nas duas tecnologias.

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

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

Legal.

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

A Conclusão…

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

E eu aposto que é.

Feliz Ano Novo!!

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 108 outros seguidores