Em 2000 eu pude participar de uma conferência do SAS – como empregado, nos bastidores – e ver Bill Inmon palestrar. Por essas coisas de eventos e ranks, eu não tive a oportunidade de conhecê-lo e, no fundo, não teria sido nada tão extraordinário para mim. Lembro-me de vê-lo falando e do sentimento de reverência por estar assistindo o pai do assunto, mas nada mais que isso.
Acho que deve ser o que sentimos quando vemos um jornalista da TV na rua: ah, puxa, ele é da TV, e acaba nisso. (Muito diferente, por exemplo, de assistir o show do Robert Plant e Jimmy Page no Hollywood Rock – muuuuito diferente.)
Hoje, praticamente 20 anos depois, o destino me leva para o lado do pai do DW mais uma vez. Mas agora, na mesma página:
Literalmente na mesma página, no WWDVC 2021
He, he. Agora eu me sinto no show do Led Zeppelin. :-D No palco do show, para ser exato.
Então é isso: em 2021 eu vou apresentar uma palestra ao vivo (um case) e outra pré-gravada (Data Culture) no palco do World Wide Data Vault Consortium 2021.
Este ano ele será totalmente virtual – por isso eu consegui me inscrever como palestrante. Mas isso significa que ninguém precisa mais pagar um vôo até Vermont, e hotel, para assistir a conferência!! Interessado? Acesse a página do evento e inscreva-se!
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 é:
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 Adamson, Inmon’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!
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.
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???
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.
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.)
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.
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.
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.
Geek BI 