Quem me acompanha aqui no GeekBI viu meus posts sobre DV e sabe que eu sofro de uma grave insegurança acerca da hamletiana questão DV or Not DV. Bom, eu sofria.

Todo DW Deve Usar DV

Mas todo mesmo??? Não, nem todos. Ele não é necessário se seu DW é de testes, sua empresa é muito pequena (só tem dois departamentos e faz controle de pedidos em Excel) etc. Caso contrário, sim, todo DW deve usar DV, e meu objetivo hoje é tentar explicar porquê.

(In)Definição funcional de DW

Ok, de novo: o que é um DW? A definição clássica do Bill Inmon é:

Um armazém de dados é uma coleção de dados não-voláteis, historiados, integrados e orientados por assunto para suporte do processo decisório dos gestores.
A warehouse is a subject-oriented, integrated, time-variant and non-volatile collection of data in support of management’s decision making process.

Bill Inmon

Existe uma outra, mas ela não é declarada explicitamente. Ela é advogada por Ralph Kimball e pode ser escrita mais ou menos assim:

O Data Warehouse Corporativo é a coleção de Data Marts integrados através do barramento corporativo de dados.

Ralph Kimball

Uma coisa interessante sobre a definição do Kimball é que ele estressa o fato de que o DW é uma ferramenta de análise de dados. Seu modelo dimensional é tão adequado a isso que o próprio Bill Inmon escreveu, em 2000, que se ele precisasse desenhar um Data Mart, ele não consideraria usar outra coisa que não um Modelo Dimensional (Star Schema – The Complete Reference, Christopher AdamsonInmon’s Corporate Information Factory, p. 18.)

Já a definição do Inmon vai no sentido oposto: o DW acumula os dados, mas não deve ser consultado pelo cliente. Para consultas, Data Marts devem ser populados a partir do DW.

Necessidade de Dados para BI

Existem duas necessidades de dados para Inteligência de Negócios que são atendidas por DWs.

Armazenamento

Se uma empresa decide armazenar dados sobre seus processos e operações, ela deveria armazenar a maior quantidade possível, com o maior detalhamento possível. Afinal, o que hoje não é importante pode sê-lo amanhã. Se a empresa armazena apenas o que entende importante hoje, ela pode sentir falta de algo no futuro. Claro, essa lacuna sempre pode ser preenchida daquele momento em diante, mas o passado – com todo seu valor – terá sido perdido.

  • Do tamanho da empresa;
  • Tudo que já existiu;
  • Sempre aumenta.
Foto de um moderno armazém típico. Consegue se imaginar comprando num lugar destes? So se for via web!
Foto de um moderno armazém típico. Consegue se imaginar comprando num lugar destes? So se for via web!

Análise

Uma vez que o dado foi resgatado das entranhas dos sistemas transacionais e separados, podemos analisá-los – responder perguntas de negócio, estimar, prever e extrapolar tendências. Dados brutos raramente entregam algum conhecimento, e por isso é necessário “massagear” os dados até que eles ofereçam alguma interpretação possível. Isso é tão importante que, depois de décadas ocultos em projetos de Data Mining, estatísticos, matemáticos e físicos estão ganhando notoriedade com a invenção da buzz word Data Scientist (Cientista de Dados – como se algum cientista não lidasse com dados, hehe.)

  • Do tamanho de pessoas;
  • Só o relevante;
  • Renova-se.
Um supermercado facilita o acesso à mercadoria que o cliente procura. O estoque está escondido, no armazém.
Um supermercado facilita o acesso à mercadoria que o cliente procura. O estoque está escondido, no armazém.

Armazéns de dados usados para análise

Pausa para epifania:

O que acontece se você tenta criar um Data Warehouse Corporativo (EDW) para análise?

Se você tentar forçar todos os dados da empresa em um formato adequado ao “consumo” por analistas terá um DW que:

  • É do tamanho da empresa;
  • É usado por pessoas;
  • Acumula tudo;
  • Expõe tudo;
  • É consumido em partes.

Resposta: ele não seria nem uma coisa, nem outra.

Armazém + Supermercado = WTF???
Armazém + Supermercado = WTF???

Olhem as figuras: elas mostram como é um armazém puro, como é um supermercado, e como fica um armazém quando você dá para o cliente um carrinho de compras e diz “se vira aí.” Podemos descrever essa situação como “atacado no varejo” – uma antítese, uma definição contraditória.

Model Wars

E é por isso que você precisa de um Data Vault: para armazenar seus dados corporativos crús, de maneira integrada e acumulativa, sem compromissos quanto ao volume, à taxa de armazenagem ou ao conteúdo. Caso contrário, se você arquivar seus dados em outro modelo, você vai acabar em um beco sem saída.

O DW foi “inventado” (descrito formalmente pela primeira vez acho que é mais o termo) por Bill Inmon, que propôs um modelo de dados para montar um DW.

Corporate Information Factory

Visão da arquitetura típica de um CIF.
Visão da arquitetura típica de um CIF.

Uma CIF, ou Fábrica Corporativa de Informações, é um banco dados e processos de ETL associados com algumas características particulares:

  • O modelo de dados é na 3NF (3a Forma Normal);
  • O dado é armazenado integrado e limpo;
  • Sem acesso direto do cliente ao dados do DW;
  • O consumo de dados pelo cliente é feito por Data Marts Dimensionais, derivados da CIF.

Era uma idéia natural, dado que a 3NF é uma maneira eficiente de se guardar dados relacionados entre si. Só que ele tem alguns problemas:

  • O dado gravado no DW não é o mesmo que existe no sistema de origem;
  • A 3NF é um modelo de dados muito bom para aplicações transacionais, mas muito ruim para DW por que é um método complexo e difícil, especialmente se precisar ser extendido;
  • Apesar de Inmon afirmar o contrário, CIFs tem grande custo/demora inicial, manutenção complexa
  • Para esses dias de Scrum, CIFs não são uma arquitetura apta a ser “agilizada”.

Dimensional Enterprise Data Warehouse

Como dito no começo deste post, Ralph Kimball advoga algo que agora podemos chamar de “atacado no varejo”:

  • O EDW é uma coleção de Data Marts (assuntos), que são “estrelas” Fato-Dimensão;
  • A integração dos dados é feito via barramento de dimensões;
  • O dado é armazenado integrado e limpo;
  • O cliente final tem acesso direto ao EDW, normalmente por alguma ferramenta gráfica, como Microstrategy ou PIR/Analyzer.
O Barramento Dimensional Corporativo (interpretação artística acima e exemplo de documentação abaixo.)
O Barramento Dimensional Corporativo (interpretação artística acima e exemplo de documentação abaixo.)

Ele resolveu muitas dificuldades da CIF:

  • Modelo dimensional é resiliente e flexível:
    • Acomoda mudanças de negócio;
    • Bom para análise por pessoas;
    • Bom para armazenamento por bancos;
  • Projeto modular, bottom-up
    • Começa pequeno e cresce organicamente;
    • Manutenção simples;
    • Apto a ser “agilizado”.

Mas mesmo assim ainda tem suas fraquezas:

  • Assim como na CIF, o dado gravado não é o mesmo que existe no sistema de origem;
  • O modelo de dados depende do processo de negócio e do entendimento deste processo (pelo cliente ou pelo desenvolvedor). Se o negócio ou seu entendimento muda, o modelo precisa mudar junto;
  • Mesmo sendo resiliente, essa resiliência tem limite;
  • Mesmo sendo bom para integrar dados, a integração depende de dimensões comuns que nem sempre existem, o que causa aumento de dimensões “iguais mas diferentes”.

CIF x EDW-D

Além de suas limitações particulares, ambos tem algumas fraquezas intrínsecas:

  • Dado é mascarado: ele é alterado e depois carregado;
  • ETL frágil: pode parar por “dado ruim” e re-início é complexo;
  • ETL pode ficar pesado e afetar janela de tempo.

Truco!

E agora? A proposta de Inmon é complexa e tende a matar o EDW sob seu próprio peso. A do Kimball espana em projetos grandes demais – e nos dias de hoje, grande demais é o novo médio. Não que eles sejam totalmente inadequados. As abordagens CIF e EDW-D respondem muito bem, até, para uma boa gama de problemas e necessidades. Elas apenas têm limitações que tornam tudo mais difícil (mas apenas em poucos casos impossíveis.)

Apresentando Daniel Linstedt & Seu Maravilhoso Data Vault

O cara é uma figura. Assista o vídeo dele aqui. Eu tomei contato com suas idéias através do Kettle Solutions, mas se eu tivesse assistido o vídeo antes, eu nem teria lido o material – sério. Tudo que ele faz – palestra, vídeo, aula etc. – parece coisa de Shop Time!!! Mas não compre ainda! Se você adotar Data Vault e adquirir o divertidíssimo curso on-line Mega-Promo, você ainda ganha uma fantástica empresa altamente produtiva!!

O fato é que a metodologia/técnica/teoria/coisa que ele inventou resolve todos esses problemas, muito bem. Claro que ela também tem suas limitações, mas até as limitações são coisas complicadas de se entender, de tão eficiente que DV é.

Eu sabia disso – eu consegui entender que DV é o modelo de dados ideal para uma CIF, que depois popula Data Marts dimensionais usados pelos clientes. Essa não era a minha dúvida. O problema era outro.

Como é que mais Trabalho…

Quando implementamos um DV, dobramos o tamanho do EDW.

Arquitetura do EDW Dimensional típico.
Arquitetura do EDW Dimensional típico.

Em um Data Warehouse Corporativo Dimensional temos um processo de ETL que lê das origens e grava em um modelo de dados dimensional, a partir do qual a bancada de exploração é montada. Quando incluímos um Data Vault na jogada, não nos livramos do ETL dimensional, mas tão somente o alteramos:

Arquitetura de um EDW extendida com um Data Vault entre as fontes e os Data Marts.
Arquitetura de um EDW extendida com um Data Vault entre as fontes e os Data Marts.

Louco, voces estão pensando, mas vocês já sabiam disso, não é?

…dá menos Trabalho?

Simples: tornando viável o impossível, e o difícil, fácil.

Quais são os maiores problemas de uma CIF? Modelo de dados e evolução complexas. Se você optou pela CIF no seu EDW, um DV te dá um modelo de dados simples, de evolução muito fácil.

Quais são os maiores problemas de um EDW Dimensional? As mudanças: sempre que o cliente pede algo novo, como incluir uma nova fonte de dados, não apenas o modelo de dados precisa passar por uma revisão e eventual ajuste, mas o processo de ETL também precisa ser revisto.

A Minha Experiência

Atualmente estou envolvido em um projeto de DW relativamente simples: municiar o cliente com cubos OLAP para que ele possa monitorar o desempenho da área em suas atividades. Temos só duas fontes de dados, mas em breve uma delas será desativada e tudo ficará na outra. Logo, nada muito complexo.

Adotamos uma gestão de projetos Scrum, que se baseia em iterações curtas (algumas semanas) para entrega de uma lista de objetivos reduzidos, previamente combinados com o usuário.

Não tenho nenhum problema em nenhum aspecto do projeto: ambientes ok, ferramentas ok, equipe nota 10, cliente fantástico. É o projeto dos sonhos de qualquer um – meu, inclusive.

Só tenho uma dificuldade: o modelo de dados. De tanto eu pestear meus chefes na empresa em que trabalho, eles me deixaram modelar o DW (ou Data Mart, melhor dizendo, já que há muita coisa da empresa que não entra nesse banco) e desenvolver o ETL, que eu comecei a fazer da forma que eu sempre disse que deveria ser feita.

Provei do meu próprio remédio – ele é muito bom, mas tem efeitos colaterais perigosos.

Métricas Misturadas

Espanei logo na primeira estrela.

Fiz tudo de acordo com o figurino: eu escolhi o processo de negócio e o grão, as métricas e as dimensões. Mas eu não fiquei satisfeito e refiz. Ficou ruim e refiz de novo. Voltei ao primeiro arranjo, mudei de novo, tentei outra coisa… Não conseguia chegar a um acordo sobre as métricas. Elas ficavam… estranhas, acho.

No dia seguinte, descansado, eu me toquei do que acontecera. A métrica que o processo de negócio comportava não era a métrica que o cliente queria explorar. Ora, que tolinho, dei mancada de amador, pensei eu.

Há!

Grão Grilado

Voltei ao início e ajustei a definição do processo de negócio para incluir mais coisas, e daí o grão, as métricas e as dimensões. Ficou melhor, mas ainda não resolveu. O novo entendimento sobre o processo de negócio que meu cliente queria analisar ainda não era suficiente. Pensando sobre o caso eu vi que, se ampliasse e ampliasse, até encampar tudo, o modelo ficaria estropiado.

Eu já estava há quase uma semana desenhando e redesenhando o modelo, testando alguns protótipos. Minha expectativa era fazer um ou dois protótipos, refinar meu entendimento do problema, do sistema de origem e da necessidade do cliente, e então jogá-los fora e redesenhar certo.

Aconteceu isso, mas não como eu esperava. Eu não convergia, não conseguia achar o “corte” do negócio que desse o que o cliente pedia.

Supernova

Sabem quando acende aquela lâmpada na cabeça do Patolino? Bom, sobre a minha cabeça acendeu uma supernova – foi o tal momento da epifania que eu descrevi acima. De repente ficou claro que eu não conseguia achar o corte certo porque simplesmente não existia corte certo. Era como se eu estivesse tentando temperar e fritar filé mignon para conseguir hambúrguer com fritas (com pão, queijo, tomate e maionese, tudo.) O cliente precisava de uma “visão” dos dados que não era disponível em um só processo de negócio. Eu ainda não tenho certeza se entendi bem o porque disso – se é um grande processo com várias etapas, ou se a análise do cliente é muito alto nível – mas o fato é que eu consegui andar quando eu quebrei os dados nos vários processos de negócio. Cada um passou a trazer um pouco do que o cliente queria, como uma fato atômica (sem divisão, mínima ou essencial.) Daí eu pude determinar os grãos, dimensões e métricas das várias estrelas necessárias. No final, eu desenhei uma estrela “Análise” que reunia as métricas contra as dimensões pedidas pelo cliente.

Hoje, meu processo de ETL tem três etapas:

  • Atualização das dimensões;
  • Carga dos novos fatos “atômicos”;
  • Carga da estrela Análise a partir das estrelas atômicas.

Ou seja, de uma forma ou de outra, eu acabei estabelecendo um Data Warehouse que acumula os dados, e uma estrela para análise, como um Data Mart.

Lixo, Lixo, Lixo

Esse projeto lidava com um tipo de sistema de origem que eu nunca havia trabalhado. Eu brinquei um tempo com vendas (usando a base de dados que evoluiria para a Beltrano S/A), algumas coisas com finanças e um projeto para uma empresa de telefonia, além de todos os outros que eu conheci, que envolviam banco, marketing, televisão etc. O sistema de origem desse projeto é um software de gestão de projeto, completo, com tudo, inclusive a pia da cozinha.

Eu não conhecia os tipos de fato necessário, e tinha só uma idéia do que seriam as dimensões. Por isso eu liguei para um grande amigo, dono de uma empresa de consultoria e treinametno em DW (ele cursou os treinamento do Kimball Group com o Kimball em pessoa) e discuti algumas idéias com ele. Melhor dizendo: admiti que estava perdido e não sabia por onde começar e ele me deu um caminho, que funcinou perfeitamente.

Mas houve uma consequência engraçada: uma das fatos era do tipo snapshot (foto), e acumula dados sobre projetos – coisas como data, cliente, líder, departamento etc. Um dos atributos dessa fato era o ID do projeto, que tipicamente vira uma dimensão degenerada. Outros dois eram o título do projeto e a descrição. Claro que daria para fazer uma dimensão Projeto para guardar esse campos, mas haviam vários outros atributos textuais que se ligavam aos dados de projeto, como estado, tipo de projeto, tipo de processo etc. Como essas coisas evoluem ao longo do tempo – não, pior: vão e vem, avançam de estado e retrocedem para depois avançar de novo, sem padrão – montar uma dimensão seria uma péssima idéia, porque ela cresceria com a fato.

Eu poderia adicionar os atributos diretamente na fato, degenerando tudo e mantendo coisas como empregados, departamentos e datas em dimensões regulares. Só que adicionar campos de texto à fato é garantia de destruir a performance. A tabela em questão é pequena, e cresce à taxa de milhares de linhas por dia, ou seja, quase nada. Mas há outras fatos do mesmo tipo (cheia de atributos textuais), uma das quais crescendo à (por enquanto) +30.000 linhas/dia.

A solução recomendanda por meu amigo, e que eu acatei, foi levar esses atributos para uma dimensão Junk (“lixo”), que eu acabei por fazer uma para cada atributo ou no máximo par de atributos (como título e descrição.) No final eu acabei com uma Junk Dimension Título, uma Junk Dimension Tipo, uma Junk Dimension Estado e assim por diante.

A minha estrela de acumulação estava ficando cheia de atributos descritivos que nunca entrariam em um barramento dimensional corporativo, que lembrava cada vez mais um arranjo hub-link-satellite (os elementos de um DV.)

Re-Retrabalho

Depois dos percalços iniciais eu consegui divisar um padrão no modelo dimensional e dividir com a equipe, para que mais gente pudesse entrar no projeto que até então estava inteiramente comigo.

Conforme o modelo foi ganhando forma, as extrações sendo desenhadas e o resultado apresentado ao cliente (Scrum, lembre-se), o cliente foi entendendo melhor sua necessidade e pedindo mudanças, sempre dentro das restrições impostas pelo Scrum. Mesmo assim, o modelo precisou ganhar uma fato que inicialmente não se acreditava necessário, redesenhar a dimensão Empregado pelo menos uma vez, sem contar os ajustes (além de mais duas mudanças programadas para breve), alterar algumas regras e adicionar vários filtros e correções para dados mal-comportados.

Bom, o suco da história é que o modelo ainda está crescendo (normal), mas também mudando o que já foi feito (anormal). Quero dizer, não é anormal mudar, mas não deveria ser comum precisar rever coisas demais. O ritmo de mudanças em coisas estabelecidas está caindo e deve tender a zero…

… mas e se não? E todas as vezes que precisamos truncar o histórico já acumulado para poder implementar um conceito refinado, uma regra revista? E quantas vezes mais isso vai acontecer?

DV To The Rescue!

Falo baseado em minha intuição, claro, mas estou certo que teria tido menos dificuldades iniciais e o impacto do retrabalho teria sido menor se eu tivesse adotado um DV desde o início. Coisas que teriam sido melhor incluem:

  • Início rápido: como os elementos do DV têm regras claras, nas duas primeiras semanas eu já teria colocado no ar no mínimo os cubos (minha tradução para hubs, como cubos de roda), elos (links) e satélites necessários para a primeira visão do cliente;
  • Histórico mais cedo: nas duas semanas seguintes, enquanto a carga do DV seguisse acumulando dados em produção, acredito que teria conseguido um modelo dimensional e uma extração para levar os poucos dados já no DV para uma estrela de análise, útil ao meu cliente;
  • Menos retrabalho: se eu notasse falta de algo no DV, em menos de uma hora eu conseguiria adicionar esse pedaço em produção, para seguir desenhando o Dimensional;
  • ETL simplificado para o DV: como eu uso o PDI, meu trabalho é medido com a dificuldade de construir uma transformação para fazer algo. O DV usa transformações-padrão para cubos (são sempre as mesmas, basta mudar os nomes da tabela e da chave), um gabarito (template) para elos e outro para os satélites (não há padrão xerocável, mas há um padrão de processo de desenvolvimento). Essas transformações são muito mais simples que as necessárias para carregar uma dimensão e mais simples ainda que uma que carrega fatos;
  • ETL simplificado para os Data Marts Dimensionais: ao contrário da situação em que o EDW Dimensional é carregado a partir do sistema de origem, agora ele seria carregado a partir do DV. As transformações que geram dimensões a partir do DV são praticamente padronizadas. É só copiar, colar e alterar o que for preciso – o processo muda pouco. A transformação para fato ainda serão mais complexas que para as dimensões, mas, de novo, por contar com uma fonte padronizada (o DV), ficariam mais simples e mais padronizadas;
  • Preservação do histórico: se for preciso refazer algo do dimensional, eu poderia jogar fora o modelo dimensional inteiro se fosse preciso, sem me preocupar em perder nenhum dos dados acumulados até então. Seria possível incluir no DV até mesmo coisas ainda não necessárias, e no futuro dispor imediatamente do histórico inteiro em novos Data Marts.

Conclusão

Como Bill Inmon propôs, ao definir um DW, um Data Warehouse é um depósito de dados corporativos, que acumula tudo que possa ser importante para a empresa, e os clientes da corporação que precisarem analisar esses dados devem fazê-los a partir de data marts preparados para tal. Ralph Kimball patronizou a popularização do BI através do desenvolvimento da Modelagem Dimensional.
Finalmente, Daniel Linstedt completou a visão de Bill Inmon com a criação da metodologia Data Vault.

Pelas implicações práticas e lógicas, e a partir da experiência que estou passando, afirmo que um Data Vault é uma necessidade de todo EDW porque torna possível o crescimento suave, progressivo do DW, simplificando o desenvolvimento dos processos e sua gestão.

Espero ter trazido alguma novidade ao compartilhar aqui minha experiência e minha percepção do problema de criar e evoluir um DW em uma empresa. Apreciaria muito ouvir/ler críticas, dúvidas e sugestões.

9 comentários sobre “Data Vault Para Quê?

  1. Muito boa sua abordagem. Existe um grande mito sobre a adoção ou não de um EDW, mas posso dizer que os grandes clientes entendessem a sua comparação entre o Armazém e o Supermercado metade dos nossos problemas de implementação estariam resolvidos. Parabéns excelente post.

    1. Muito obrigado, Washington. Como eu disse, foi uma epifania. Mexo com isso há mais de 10 anos, mas nunca tinha ficado tão claro quanto agora. Imagino que nem todas as pessoas percebam essa separação porque a maioria aprende sobre BI com fornecedores de ferramentas…

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s