Em TI vivemos imersos em estrangeirismos, que é como se chama o uso de uma palavra de outra língua no nosso idioma natal.
Em si, isso não é ruim. Por exemplo, quando a palavra nativa é desajeitada ou esquisita, um termo de outra língua ajuda bastante: quebra-luz ou sustentador, as palavras em português para abajur (abat-jour) e sutiã (soutièn).
Mas em outras ocasiões isso é um problema sério. Meu exemplo favorito é leader. Traduzido como líder, a palavra não evoca nada. Ou melhor, evoca aquela pessoa destemida, à beira de um promontório, com o peito aberto para o espaço e um olhar confiante e distante.
Só que essa imagem que a palavra cria na sua cabeça está errada. Quer ver? O que é um guia?
Você deve ter pensado “é o cara que conhece o caminho, os desvios, atalhos, riscos e armadilhas”. Correto. É a pessoa que já passou por ali e vai te ajudar na travessia. É um profissional que vai tomar as decisões e vai se responsabilizar por elas, que vai delegar e cobrar o resultado, que amalgar várias pessoas, todas únicas e diferentes entre si, em uma coisa coesa, com direção firme.
E adivinhe? Leader, traduzido, significa guia.
Entendeu? Só de mudar a palavra estrangeira para seu equivalente nativo você já ganhou uma idéia melhor do que significa ser um líder. Agora você pode até avaliar se é uma pessoa para essa posição ou não, pode avaliar quem te lidera, pode escolher quem vai querer para ser seu guia. E em várias dimensões: profissional, pessoal, social…
Hub, Link and Satellite
Um Data Vault é um repositório de dados usado para construção de Data Warehouses.
Vamos mudar a frase anterior: “um cofre de dados é um repositório de dados usado para construir armazéns de dados”. Notou? Só de trocar Data Vault por cofre de dados e Data Warehouse para armazém de dados as imagens na sua cabeça estão diferentes.
Traduzir Data Vault por cofre de dados não é uma boa idéia, porque um Data Vault não tem nada a ver com segurança ou inviolabilidade. Mudar DW para Armazém de Dados, porém, já ajuda.
O mesmo ocorre com as estruturas básicas de um Data Vault: hub, link e satellite. Desta forma, em inglês, elas não dizem muito. Quando estudamos cada uma dessas estruturas aprendemos que se referem a layout de tabela muito específico.
Agora, veja como a coisa muda se traduzirmos:
Hub: Pivô;
Link: Elo;
Satellite: Satélite.
Pivô
Pivô, do francês pivot, é aquele elemento sobre o qual se faz uma rotação (pivotear) ou aquilo que fica no centro, no eixo, no qual se ligam outras partes.
A função de um hub é justamente essa: estar no centro do armazém de dados, como um conceito de negócio, no qual outras estruturas (links e satellites) vão se ligar.
Cubo, caixa, eixo, âncora – muitas outras traduções existem para hub, mas eu gostei mais de pivô. Cubo já existe em BI, eixo é esquisito. Caixa e âncora não têm significado claro neste contexto.
Elo
Em um Data Vault, link é uma tabela que liga dois ou mais pivôs (hubs). Essa é uma palavra muito usada, comum até fora da Informática: todo mundo compartilha links para todo tipo de coisa – páginas web, perfis em redes sociais, arquivos e formulários etc. etc. etc.
Não seria um problema deixar link como link (como hub também não era). Mas…
Mas existe uma palavra em português que serve muito bem para essa função e transmite a imagem mais adequada: elo. Ao invés de um caminho para alguma coisa, como nos habituamos a pensar para link web (que no mais das vezes é uma URL e não um link), a palavra elo transmite a idéia de coisas ligando-se entre si e formando algo maior. E essa é exatamente a função de um tabela elo (link): conectar, ligar dois ou mais pivôs e assim conectar todos os conceitos de negócios entre si.
Link poderia ser traduzido, também, por conexão, ligação, contato, junção, ligadura, ligamento etc. Nenhuma dessas palavras, porém, cria uma imagem tão ilustrativa do conceito de link como elo.
Satélite
Um satellite em Data Vault é a tabela que guarda contexto. É lá que ficam os atributos que podem ser atualizados e descrevem os conceitos de negócio (pivôs) e contextualiza as relações entre esses conceitos (elos).
A palavra é tão próxima do português satélite que quem usa Data Vault sempre fala “hubs, link e satélite”, misturando português e inglês como se fosse uma feijoada de frango.
E é uma palavra muito apta à sua função: ela se liga aos outros elementos e sempre apenas a um, como um corpo preso por atração gravitacional a um outro corpo (eu sou físico e satélite para mim tem uma imagem muito clara). Se eu tivesse criado o conceito de Data Vault, talvez chamasse de “context” ou “attributes” ou qualquer coisa mais óbvia (não sou um cara criativo, mind you), mas Daniel Linstedt escolheu satellite e caiu muito bem.
Assim, completando a tradução dos conceitos de Data Vault, eu vou continuar com satélite, como todo mundo.
Pivô, elo e satélite
Meio como Doc Brown, de “De Volta para o Futuro”, um dia eu tive uma epifania sobre como a língua interfere na interpretação do texto. Tudo começou com Data Mining, que depois de dez anos traduzindo como mineração de dados eu mudei para Garimpagem de Dados (e hoje eu diria Garimpagem em Dados).
Desde então eu venho testando traduzir alguns termos para verificar se em português eles mais ajudam ou mais atrapalham. E hoje eu decidi acabar de vez com hub, link e satélite. Não apenas por causa da feijoada de frango que é misturar português e inglês tão intimamente, mas porque eu quero poder ampliar a audiência do Data Vault, agora que (FINALMENTE!!!) o mundo (e o Brasil junto) o descobriu.
Então, a partir de hoje eu vou falar “pivô, elo e satélite” ao invés de “feijão, paio e frango”, digo, “hub, link e satéite”.
Em agosto de 2005 eu lancei um mini-curso sobre como fazer levantamento de requisitos para projetos de Business Intelligence. O que diferenciava aquele curso da prática tradicional era ser voltado para projetos ágeis. Você pode ver aquele post clicando aqui, conhecer o curso aqui e assistir ao vídeo promocional seguindo este link.
O assunto é interessante por demais da conta. Nestes dois últimos anos eu tenho me dedicado a estudar como melhorar a implementação de projetos de BI e DW usando técnicas ágeis. Tenho visitado palestras, lido artigos pela web, conversado com inúmeros profissionais. O resultado desse envolvimento todo apareceu na minha palestra do Pentaho Day 2017, BI E.V.A., que teve uma boa recepção junto à comunidade Pentaho.
Hoje eu recebi um e-mail da TDWI, um respeitado instituto de Data Warehousing. O assunto? É óbvio, né?
Agile BI.
E-mail do TDWI convidando para um curso de Agile BI.
Techniques for determining the right level of up-front design
How to avoid overbuilding solutions by designing for what is needed
Domain modeling
Data model patterns
Data smells and the impact of technical debt
Continuous integration
Safe refactoring techniques for making incremental design changes
How to determine the right level of design documentation that is needed
Effective collaborative modeling practices for cross-functional teams
How to minimize the amount of unnecessary rework through reference and conceptual designs
How to establish iteration zero as an agile practice that gives teams the runway to start delivering
Hmm… Interessante. Uma das coisas que eu comento no BI E.V.A. é que há muito sendo discutido sobre como se transformar o processo de modelagem de dados, em especial Modelagem Dimensional, em um processo “ágil”. No fundo, o que muito da literatura tem pregado é como incorporar Scrum ao processo tradicional.
Eu já fiz isso, e não adianta.
Pense um pouco: o cerne de ser ágil é prover melhoria contínua. Mas o cerne de um processo de modelagem dimensional é entender a necessidade do cliente. Não é muito evidente, mas o fato é que essas motivações são incompatíveis. Ainda não tenho um argumento finalizado e por enquanto eu recomendo a leitura das notas da apresentação BI E.V.A. – é o melhor que eu consigo no estágio atual.
Ainda não é uma Conclusão
Voltando ao curso do TDWI, o que é que eles oferecem? Uma outra abordagem ao processo de modelagem de dados? Não.
Um outro modelo de dados? Não.
Uma outra forma de tratar os levantamentos de requisito? Não. (Meu curso faz isso.)
Eles propõe “modelar apenas o suficiente para galvanizar o cliente e desenvolvedores ao redor de uma compreensão compartilhada do domínio do problema, arquitetura e modelo de dados”.
Ou seja: adotemos ágil e, na hora de construir o modelo de dados, vamos fazer apenas o mínimo para começar. Do que se depreende que desenvolvimento incremental, aqui, deve ser “uma dimensão por história”, “uma estrela por épico” ou coisa do tipo!
Foi exatamente o que eu tentei. Deu resultado, mas ainda não me permitiu os fantásticos ganhos de produtividade que Scrum normalmente proporciona. Leia “Scrum: a arte de fazer o dobro do trabalho na metade do tempo” para saber do que é que eu estou falando. ;-)
Ganhos fantásticos!
O que eu acabei descobrindo é que o que atrapalha o desenvolvimento ágil – incremental – é a dificuldade de expressar a necessidade do cliente de modo que permita correções e ajustes, o que acabou me levando a rever o problema por outro ângulo.
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!
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?
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
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?!…
(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! ;-)
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. ↩
Na parte do Modelo Completo, onde tem o desenho, a tabela s_l_empregados_pedidos não deveria estar linkada à tabela h_pedidos? Ou se não for na h_pedidos, não deveria existir uma tabela hub entre ela e a l_empregados_pedidos?
Fiquei meio perdido ali. Você tem algum exemplo com dados?
E uma outra pergunta. O que vai exatamente no campo Record Source? O nome da tabela de origem?
Fui ver, e ele tem razão. Naquele post, a função da tabela s_l_empregados_pedidos não está clara, até porque existe um erro também. Neste post completo a explicação, explicitando o que eu queria fazer e mostro uma correção possível.
O Problema
A metodologia de modelagem de dados para Data Vault define três tipos principais de tabelas: hub, links e satélites. Hubs registram conceitos de negócio, como vendedor, cliente e produto. Links registram relacionamentos entre conceitos de negócios, ou seja, entre hubs. Por exemplo, se um vendedor cuida de um certo cliente, então podemos definir um link entre os hubs de vendedor e cliente.
Satélites guardam os atributos de hubs e links. Se o cliente é um hub, um satélite de cliente contém, por exemplo, seu endereço, sua data de nascimento, sua ocupação e outros dados.
A figura da qual o Cesar falou mostrava dois hubs, empregados e pedidos, e um link entre os dois:
As tabelas combinadas no modelo.
Além disso, ela também mostra um satélite para hub empregados, e um para o link empregado-pedido. E isso está errado!
Sim, veja: satélites contêm atributos de um hub ou de um link. A tabela s_l_empregados_pedidos é um (s_)atélite pertencente ao (l_)ink empregados_pedidos. Mas olhe que atributos esse satélite tem:
data_pedido
pagamento_tipo
De quem são esses atributos? Data do pedido é um atributo do… pedido. E tipo de pagamento? Também! Ora, se são atributos do pedido – e não da relação entre pedido e vendedor – então esse satélite é do hub pedido, e não do link empregado-pedido! Por isso esse satélite está errado.
Para estar correto ele precisaria conter algum atributo da relação, do link. Esse modelo não é um bom caso para um exemplo de satélite de link, que era a minha intenção original.
A Solução
A mensagem que eu queria passar precisa de um modelo ligeiramente diferente:
O modelo corrigido.
Agora temos um novo hub, cliente. Poderíamos ter seu respectivo satélite, mas seria redundante, pois já temos um exemplo de satélite de hub.
Nesta empresa, cada cliente é atendido por um único vendedor ou gerente, que é o dono da conta, como acontece em um banco, por exemplo. Em um banco, todo cliente possui um gerente. Esse relacionamento aparece como um novo link, entre clientes e empregados.
Como dizia uma propaganda de banco, o tempo passa, o tempo voa. Um gerente muda de agência, outro muda de emprego, entram novos gerentes, chegam clientes de outras agências, clientes vão embora… Conforme o tempo passa, a relação cliente-gerente muda. Pior ainda: pode ir e voltar, ou seja, um cliente pode estar com um gerente hoje, outro daqui um mês e daí no ano seguinte volta a estar sob seu primeiro gerente.
O link não possui data de validade. Ele não possui nada além de data de criação e sistema de origem, aliás. Como, então, saber qual é o gerente atual de cada cliente? Ou que gerente teve que clientes durante um certo período?
Um satélite de link, justamente como mostrado na figura anterior, resolve essa situação: cada vez que o link sofre uma atualização, o satélite versiona sua data de validade. Resumindo:
Porque um link pode ter um satélite? Por que a relação entre dois hubs pode mudar ao longo do tempo, e a única forma de saber quais estão ativas, hoje, no sistema de origem é usando um satélite.
Evidentemente, um link pode ter outros atributos além de período de validade. Exemplo? Pense nos itens de um pedido, ou seja, os produtos que o cliente comprou naquele pedido. Esses itens são registrados no DV como um link entre o hub pedido e o hub produto. Agora, os detalhes de cada item, ou seja, a quantidade, o valor pago etc. são registrados como satélites desse link.
Record Source??
Quanto à segunda pergunta, o que vai no campo Record Source? Bom, o campo RSRC recebe o nome do sistema de origem, não da tabela. Como as tabelas, em princípio, fazem a integração dos dados, o campo indica em que sistema foi identificado aquele elemento – hub, link ou satélite – pela primeira vez. Como as tabelas hub e link são carregadas um sistema de cada vez, o campo RSRC indica, no fundo, que sistema foi carregado primeiro, já que ele não é atualizado mesmo que o campo seja encontrado em outro sistema, com o valor idêntico.
Esse campo tem um pouco mais de utilidade para satélites.
Já passei por situações em que era fundamental separar os dados dentro do satélite por sistema de origem. Foi com o Zabbix: um DV foi construído para integrar 11 Zabbixes. Como era tudo igual, tínhamos apenas uma tabela de satélite para cada item. Como o mesmo item podia aparecer em dois ou mais Zabbixes diferentes, o satélite do Zabbix 1 podia ser encerrado se o mesmo item existisse em qualquer outro Zabbix. O mesmo aconteceria com o segundo Zabbix a ser carregado e assim por diante e depois se repetindo desde o início. A única forma de resolver foi filtrando o satélite pelo RSRC, um para cada Zabbix. ;-)
Para escrever meu primeiro post sobre Data Lake eu pesquisei sobre o assunto. Abri o Firefox e saí fuçando o mundo com o Google. Achei alguns artigos interessantes, até que um deles matou o assunto e fiz o post. Eu peguei o restante das pesquisas, dei uma passada d’olhos e, como não achasse nada muito divergente daquilo, descartei.
Limpando meus papéis eu achei um dos artigo que eu separara para ler com mais calma, chamado – que criativo! – DataLake, publicado pelo Martin Fowler em pessoa, em fevereiro de 2015.
Ele se autodefine como “author, speaker, and loud-mouth on the design of enterprise software”, ou em bom português, “autor, palestrante e tagarela sobre o design de software corporativo”.
Eu sou um fã de seu trabalho e já li muitos livros dele e da série Signature, a maioria através Addison-Wesley. Ele é muito bom, e é preciso que se destaque isso: em desenvolvimento de software. Ele nunca publicou ou palestrou sobre BI. O mais perto que ele chegou foi um livro sobre NoSQL escrito em parceria e, pelo visto, este artigo. Por mais que eu o respeite em seu campo, não posso ter o mesmo sentimento quando ele atua fora de sua área. Neste caso o que ele escreve está mais para uma visão multidisciplinar e informada que um comentário de especialista no assunto.
E não é que tem ali uma coisa que eu não tinha notado? Algo que parcialmente redime o conceito de Data Lake e confirma a importância de Data Vault. Vou pegar o assunto do começo, desenvolver o tema e, na conclusão, mostro o que me escapou antes. Acredito que isso vai ajudar a entender melhor tanto o conceito e a utilidade de um Data Lake, quanto a verdadeira natureza de ambos – Data Lake e Data Vault.
Despensa, Cozinha e Salão
Não deixe de ler o artigo, que é muito bem escrito e é do próprio Martin Fowler. Ele começa:
Data Lake é um termo que apareceu nesta década para descrever um importante componente do encanamento analítico no mundo do Big Data. A idéia é ter um único depósito para todos os dados crus que qualquer um na organização possa precisar para análise. Normalmente o povo usa Hadoop para trabalhar os dados no lago, mas o conceito é mais amplo que meramente Hadoop.
Eu saí pulando pelo artigo, da primeira vez, e do meio dele achei o que eu queria ouvir (ler!):
O Data Lake não deve ser acessado diretamente com frequência. Pelo fato de os dados serem crús, você precisa de um bocado de habilidade para tirar qualquer sentido deles. Você tem relativamente pouca gente que trabalha no Data Lake, e conforme eles descobrem visões úteis genericamente, eles podem criar Data Marts cada um do qual com um modelo específico para um único bounded context. Daí, um número grande de usuários podem tratar esta “loja a beira-rio” como uma fonte de dados fidedigna para aquele contexto.
No original: The data lake shouldn’t be accessed directly very much. Because the data is raw, you need a lot of skill to make any sense of it. You have relatively few people who work in the data lake, as they uncover generally useful views of data in the lake, they can create a number of data marts each of which has a specific model for a single bounded context. A larger number of downstream users can then treat these lakeshore marts as an authoritative source for that context.
Neste ponto eu parei de ler e fui escrever aquele post. Quando eu retornei e reli este artigo inteiro, eu notei a primeira relação desta visão de Data Lake com um Data Vault: assim como o proposto aqui por Fowler, um Data Vault não é uma estrutura para acesso direto. Os dados de um DV precisam ser refinados para uma área de apresentação, para aí então serem consumidos. Usando a metáfora de restaurante do Kimball, um Data Vault é a despensa, e tanto o DV quanto o Data Lake precisam passar por uma cozinha que deve preparar os dados para consumo pela clientela.
Aff… Medo de perder o contato com a realidade com tantas metáforas… Enfim, em frente.
Uma Rosa por Qualquer Outro Nome
Não bastasse essa semelhança, existe um outro conceito amarrado ao Data Vault que aparece no post do Fowler: o bounded context, que corresponderia a um conceito meio obscuro em DV, o Unit of Work.
Primeiro, o que é bounded context? A imagem abaixo dá um exemplo:
Ilustração do conceito de contexto limitado – bounded context.
Agora a definição de bounded context:
Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD‘s strategic design section which is all about dealing with large models and teams. DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.
Ou, em tradução livre, “contexto limitado é um padrão central em Domain-Driven Design. É o foco da estratégia de design, que mostra como lidar com grandes modelos e equipes. DDD lida com modelos grandes dividindo-os em diferentes contextos limitados, sendo explícito em seus inter-relacionamentos”.
Em outras palavras, o tal do “contexto limitado” que o Fowler usa para dar sentido aos dados consumidos do Data Lake é similar ao conceito de orientação a assunto, subject oriented, do Inmon e [Kimball][dmmanifesto_bitly]:
“(…)what a data warehouse is – a subject oriented, nonvolatile, integrated, time variant collection of data in support of management’s decisions(…)”
Como o próprio Linstedt (o criador do Data Vault) insiste na necessidade de um área de apresentação de dados, tanto o conceito de “orientação por assunto” ou “limitação de contexto” se aplicam ao Data Vault! Mas há algo mais: existe um conceito pouco mencionado chamado Unit of Work (UoW), ou “Unidade de Trabalho”.
Conceito de UoW ilustrado: cada circunferência representa uma “unidade”, que se integra a conceitos vizinhos.
Eu revi os livros e fiz uma busca pela Internet, mas não achei nada definitivo sobre o assunto. Este post foi feito por um dos alunos do Hans Hultgren, que parece ter sido o único a avaliar o conceito do ponto de vista de modelagem. Isso seria a definição de UoW:
A Unit of Work defines a correlated set of data;
A Unit of Work keep things together;
A Unit of Work establishes consistency between arriving data and data stored in the Datavault links;
UOW should be consistent with the (Enterprise wide) business keys.
Resumindo e traduzindo, traduzindo e resumindo, uma Unidade de Trabalho segundo Hans Hultgren é:
Um conjunto de dados correlacionados entre si, que faz sentido apenas quando estão juntos e representam aspectos do negócio.
Nest link e neste outro link esse conceito aparece de novo, mas sempre jogados, sem aprofundamento.
Então temos três conceitos:
O clássico subject oriented, da área de DW;
O bounded context herdado da área de desenvolvimento de sistemas;
O misterioso Unit of Work, visto em textos de Data Vault.
E todos eles querem dizer praticamente a mesma coisa: um conjunto de dados relacionados entre si, que representam a realidade da organização tal como foi capturada pelos sistemas informatizados.
‘Tis but thy name that is my enemy;
Thou art thyself, though not a Montague.
What’s Montague? It is nor hand, nor foot,
Nor arm, nor face, nor any other part
Belonging to a man. O, be some other name!
What’s in a name? that which we call a rose
By any other name would smell as sweet;
So Romeo would, were he not Romeo call’d,
Retain that dear perfection which he owes
Without that title. Romeo, doff thy name,
And for that name which is no part of thee
Take all myself.
W. Shakespeare, Romeu and Juliet
Portanto temos mais um tema em comum entre a visão de Data Lake de Martin Fowler e os conceitos de um Data Warehouse: o conjunto de dados correlacionados entre si.
Mesmo Assim…
… Fowler comete alguns equívocos:
Ele afirma que modelar o dado na entrada é um beco sem saída. De fato, usando modelo dimensional ou a terceira forma normal, não há solução possível. Cedo ou tarde esses modelos abrem o bico e quebram. Eu já discuti isso aqui e a conclusão foi justamente que um Data Vault supera essa limitação;
Ele diz que qualidade de dados é um problema, primeiro porque pode ser difícil equalizar a qualidade entre fontes diversas, e depois porque Data Mining (ele não usa esse termo, mas é disso que ele fala) precisa dos dados sujos. Ele tem razão e está errado nos dois casos, pois um modelo dimensional, que é feito para apresentação, guarda dados limpinhos e cheirosos, mas não um Data Vault. Um DV guarda 100% dos dados tal como vêm dos sistemas de origem, tanto que uma das premissas é que possamos reconstruir o estado do sistema de origem usando o DV e ter 100% de auditabilidade;
Aceita que o sistema de origem pode e deve mudar, afirma que o Data Lake deve guardar tudo e nunca apagar nada, mas deixa em aberto como gerenciar a associação entre as diversas capturas ao longo do tempo e a variação de esquema no sistema de origem. Quer dizer, até entende essa necessidade – uma coisa básica em todo DW – mas não tem idéia de como deve ser feito. Apesar de um modelo dimensional e um na 3NF poderem assimilar essas mudanças, um Data Vault é a única modelagem que aguenta.
E, vamos reconhecer, ele diz uma coisa muito muito bacana: You should use a data lake for analytic purposes, not for collaboration between operational systems. Ele afirma que trocas de dados transacionais entre sistemas devem ser feitas usando tecnologias como chamadas HTTP RESTFul e não via DW/DL/WH(atever). Finalmente! Acredite se quiser, tem gente que vê essas tecnologias de BI/DW como respostas para toda e qualquer necessidade. Absurdo! Mais um ponto para o Sr. Fowler.
Conclusão
É isso que conseguimos quando pegamos profissionais inteligentes, altamente gabaritados e humildes1 como Martin Fowler. Ele conseguiu enxergar na definição do James Dixon, da Pentaho, um componente do cenário de análises de dados de uma organização. Até então, eu via no conceito Data Lake apenas um departamento de marketing forçando a barra para vender software.
Mas o resultado final do post do Fowler é muito maior que seu conteúdo:
Data Lake
Data Vault
Dados crús
Dados crús
Precisa destilar para consumir
Precisa destilar para consumir
Context bounded
Subject oriented
PQP DE RODINHA!!!
O que o artigo dele coloca é de uma obviedade cristalina, e por isso mesmo nós, gente comum, deixamos passar:
DATA LAKE = DATA VAULT
Só o gênio dele para trazer essa relação à tona.
Então, da próxima vez que aventarem um Data Lake do seu lado, responda: “show! me dê o curso do Linstedt, o Wherescape e vamos começar!”
;-)
Para mim é inconcebível um cara da área dele falar sobre outro assunto com tanta propriedade sem ter estudado e se consultado com um monte de livros e pessoas e ter ouvido essas pessoas. A lista de agradecimentos dele, ao final de seu artigo, reforça minha certeza. ↩
Faz uns dois anos, e começou assim: minha mão estava coçando para testar Data Vault. Eu tinha feito alguns experimentos, tinha implementado um caso pequeno, mas ainda queria explorar mais. Queria um volume maior, mais complexidade, algo mais difícil.
Cuidado com o que você deseja, porque pode conseguir.
E eu consegui. Quem mandou desejar? Um dos softwares que o SERPRO usa é o Zabbix. Resumidamente, ele server para monitorar ativos, como roteadores, servidores e hubs, coletar métricas do parque informatizado e assim por diante. Consulte a página do projeto Zabbix para saber mais.
Como o SERPRO é uma coisa imensa, tudo está sempre no limite, no máximo, no maior volume, no mais complicado. São milhares de máquinas, dezenas, se não centenas de redes e sub-redes, kilômetros de cabos e tudo mais. Não vou entrar em detalhes técnicos para não correr o risco de falar besteira mas, resumidamente, o povo super-criativo conseguiu botar o esquema todo para a funcionar dentro do que era possível e desejável. Há um vídeo com uma apresentação sobre esse assunto neste link, feita por um dos empregados do SERPRO.
Uma das soluções adotadas passava por uma concentração de dados, que era atualizada periodicamente e servia para apresentar certos dados coletados pelo Zabbix.
Enter Linstedtman!
A pessoa responsável por essa necessidade foi aluna em um dos meus treinamentos de Pentaho, e veio me procurar imaginando se o PDI não poderia ajudar nesse caso. Afinal, consolidar dados é justamente a função dele.
As atualizações precisavam ocorrer a cada 30 minutos, no máximo, ou idealmente a cada 5 minutos ou menos. Apesar do grande espalhamento do sistema, como o volume dos dados capturados era, em si, até modesto, a baixa latência do refresh não era um problema.
O que realmente dava trabalho era a integração dos dados. Poderíamos, por exemplo, modelar os dados em uma estrela dimensional, definindo os atributos de interesse como dimensões e adotar uma fato artificial para correlacionar os dados entre si. Daria certo mas, depois de algumas mudanças nas fontes dos dados, as tabelas dimensionais acabariam ficando complicadas demais. Ou seja, logo no início do projeto daríamos de cara justamente com o ponto fraco da metodologia – a dificuldade de manutenção. Não era uma opção.
Poderíamos simplesmente replicar o layout de origem, mas isso implicaria em capturar os dados em uma granularidade confusa e, de novo, na primeira alteração na origem, quebraria todo histórico.
Não havia alternativa. Eu não queria admitir que estava usando os problemas como justificativa, mas no final, os problemas justificaram mesmo a escolha óbvia.
Usar um Data Vault. :-)
The Curse
Como havia uma certa urgência, trabalhamos em equipe: eu analisava os sistemas de origem para desenhar o Data Vault, e ia tirando dúvidas sobre os conceitos de negócio com os especialistas. Em pouco tempo (duas semanas, se não me falha a memória), foi montado o diagrama de tabelas, os modelos de transformação PDI e, com isso, um processo de ETL completo, de cabo a rabo, saiu do nada.
Como não era um grande volume de dados, a primeira carga levou coisa de uns trinta minutos, um pouco menos que isso. A partir da segunda carga, o processo de ETL terminava em menos de um minuto, graças ao fato de o DV usar CDC para tudo. Quando a rede está muito lenta, leva quase três minutos. Finalmente, por garantia, decidiu-se manter uma latência de 30 minutos (i.e. meia-hora), que dá uma boa margem para falha e recuperação, e ainda atende a necessidade.
E isso tem funcionado nesses últimos dois anos, sem parar, sem falhas, sem soluços, liso como gelo. De vez em quando aparece uma situação nova, e toca lá eu ir atrás de entender como usar Data Vault para resolver.
Um dia destes, batendo-papo e conversando sobre o projeto, a minha ficha caiu.
Sabe, eu não implementei esse lance – eu apenas desenhei um template, um gabarito de transformações para hubs, links, satélites e satélites de links. Nem tampouco desenhei o diagrama de dados: passei as regras de modelagem para a pessoa e deixei-a desenhar sozinha. Eu revisava tudo e corrigia os erros cometidos, mas eu mesmo não pus um dedo no processo de ETL!
É verdade que eu montei a configuração do PDI, configurei a captura de logs de cada transformação, e ainda montei um job que chama tudo. Mas de novo: montei na minha máquina, mandei para o projeto, expliquei como instalar no servidor e não fiz mais nada.
E tudo ia crescendo, ganhando tabelas, coletando dados… E a coisa rodando, e o monstro ficando maior, e maior e novos problemas aparecendo e eu só dizendo o que fazer. No máximo eu examinava os dados remotamente, para descobrir porque isso ou aquilo não estava dando certo, diagnosticava e, quando muito, corrigia os templates. A pessoa do projeto regerava as transformações problemáticas e tudo ia em frente.
Vocês não perceberam ainda né? Eu também demorei:
O projeto foi completamente, totalmente, 100%-mente construído, implementado e está sendo gerenciado por um profissional que não criou nada daquilo.
O projeto foi completamente, totalmente, 100%-mente construído, desenhado e planejado por um profissional que não implementou uma única transformação!
Sacaram? Eu não repeti a mesma frase duas vezes, leiam de novo.
Vou escrever ao contrário e vamos ver se fica mais claro:
O grau de automação do desenvolvimento foi tão grande, e em nível tão detalhado e profundo que a construção do modelo de dados e processo de ETL foi feito por um profissional que ignorava quase que completamente a técnica (DV) por trás.
E mais: a flexibilidade e resiliência da Metodologia de Data Vault é tão grande que foi possível desenvolver tudo – modelo e ETL – entendendo quase nada do negócio!
Nossa ignorância mútua dos problemas um do outro só não era total porque aos poucos fomos pegando partes da coisa – eu entendendo um pouco de Zabbix e o outro lado um pouco de DV e PDI. Mas nunca precisamos explicar nada sobre os detalhes de nada um ao outro!!!!!!!
:-O
Conclusão
Na esbórnia cultural que foi a década de 80, um dos filmes mais aclamados foi Ladyhawk, que contava a história de um casal amaldiçoado por um sacerdote malévolo. A maldição jogada nos dois fazia com que nunca se vissem, a não ser por uns breves segundos ao anoitecer e ao raiar do dia. Esse era o tal “Feitiço de Áquila”, que o nome do lugar: durante o dia a mulher era um gavião, e durante a noite, quando ela voltava à forma humana, o cara virava um lobo.
Preciso pedir perdão a vocẽs, porque foi mais forte que eu. Não deu para resistir.
Eu tive que brincar com isso.
A narrativa épica de um projeto de sucesso na era ágil! Quem projetou o ETL não implementou, e não sabia nada do negócio, enquanto que quem entendia tudo do negócio não sabia nada nem do modelo de dados, nem do ETL que estava implementando com as próprias mãos (e um monte de processos automatizados!)
Uma equipe que nunca se vê, um projeto conhecido metade por cada um, que ninguém sabe por inteiro! Essa é a história de…
… Ladyvaulk – O Feitiço de Dataváulquila!!!
Preciso concluir?? Não é à toa que existem, hoje, ferramentas como Wherescape e Attunity! Data Vault é uma coisa tão bombástica que um só “arquiteto”, como eu, pode cuidar de muitos projetos ao mesmo tempo, cada qual com UM – permita-me frisar: UM! – profissional de dados do outro lado.
AI MEUS SAIS!
Traduzindo: uma equipe de arquiteto mais alguns implementadores pode cuidar de muitos Data Vaults. É uma eficiência simplesmente impensável em qualquer outra metodologia!!
Claro que a realidade não é tão rósea. Para começo de conversa, os dados precisam ser extraídos do Data Vault, preparados e só então consumidos. Isso dá trabalho, mas mesmo assim nem de longe é o mesmo trabalho que dá construir um ETL para um modelo dimensional carregado diretamente a partir da fonte.
É isso. Até a próxima! :-)
Eu rio toda vez que falo Dataváulquila em voz alta. Vamos, tentem! Não me deixem pagando este mico sozinho!… :-D
Eu já escrevi um pouco sobre como projetos de BI “acontecem”. Em Cruel Sucesso eu divaguei sobre a eterna sensação de fracasso que algubs projetos de BI experimentam, mesmo que ele esteja indo de vento em popa. No Todos os Caminhos Levam a um DW eu me diverti escrevendo uma história maluca sobre um projeto de BI fictício, que nasce como uma planilha Excel e cresce como mandiopã, até explodir e voltar ao começo. Mudando o foco para requisitos, eu discorri sobre Ágil e BI (De Agilidade e BI), para descaradamente anunciar meu curso de requisitos de BI para gestão ágil.
Quase sempre esses posts vem do nada, motivados por alguma situação pela qual passei. Eu estava com o novo fascículo da série Soluções Clássica quase pronto (Credit Scoring), mas aconteceu de novo: me meti num debate sobre o que era um “bom” projeto de BI.
Bom, eu tenho uma idéia do que deve ser um. Vou dividir com vocês a opinião que eu coloquei no debate, mas já sabem, né?
Disclaimer: o que você vai ler é a minha opinião, logo você não é obrigado a gostar dela ou concordar. Terei prazer em ouvir críticas ou outras opiniões, mas no final – como diz o Homer Simpson – a opinião é minha e faço com ela o que quiser, certo?
Sucesso Não Existe
Primeiro, não existe mundo perfeito. Não adianta sonharmos com a próxima grande ferramenta para resolver nossos problemas, porque o melhor que pode acontecer é resolvermos os problemas atuais e caírmos em novos. O que faz a diferença, na minha humilde opinião, é evitarmos empacar. Se empacamos, o projeto começa a fazer água, e quanto mais tempo demoramos para resolver o problema da vez, menos relevante o projeto de BI se torna, até que um dia todo mundo está se virando sozinho e o projeto é mantido vivo apenas com auxílio de aparelhos.
O que torna um projeto bom, de sucesso, então, é o fato de ele estar sempre em movimento, resolvendo cada problema como um corredor salta obstáculos: pula, corre, pula, corre, pula, corre… Eventualmente, um dia a coisa toda entra em velocidade de cruzeiro, a quantidade de erros cai substancialmente e a empresa desenvolve uma cultura de BI. Esse é o projeto de sucesso: falível, sempre precisando de alguma melhoria, mas que entrega resultados e é acreditado pela organização, sustentado pela cultura de conhecimento da empresa.
Um projeto de BI de sucesso, IMHO, é aquele que resolve um problema atrás do outro, sempre entregando um pouco mais de resultados a cada etapa, capaz de suplanta as próprias limitações e ir ao encontro das expectativas do cliente.
O Caminho para o Sucesso
Ora, dirão vocês, bolas. A definição acima é uma rematada platitude: não diz nada de realmente útil ou prático. Concordo. Vamos escrevê-la ao contrário para ver se fica mais claro:
Fracassa o projeto de BI que persistir em trilhar caminhos sem saída.
Consegui me fazer entender? Quando optamos por este ou aquele caminho, corremos o risco de enveredar por uma rua sem saída. Projetos – de qualquer tipo – que reiteradamente optam por entrar em becos sem saída acabam morrendo porque, cedo ou tarde, a organização se cansa de tanto vai-e-vem! Quer seguir no caminho para o sucesso? Esforce-se por evitar decisões ruins!
Decisões, Decisões, Decisões
Devo ter engolido o grilo falante quando era criança, pois eu sempre escuto uma voz fininha, tirando onda com a minha cara. Desta vez ela disse “Intelijumento! Se soubéssemos que decisão vai dar errado, não a tomaríamos! Dã!”
Óbvio, claro, não se questiona isso. É a própria essência do processo decisório, é a meta personificada de se fazer uma escolha: fazer a escolha certa!
Como saber se uma opção, e não a outra, é a correta? Ah, de muitas formas. Em alguns casos estamos passando pelo mesmo problema uma segunda vez. Se da primeira fizemos a escolha certa, tendemos a repeti-la, e vice-versa: deu errado antes? Vamos tentar outra coisa. Em outros casos não conhecemos, ainda, as consequências de cada caminho, mas podemos avaliá-las com o que estivar à mão – opiniões, análises estatísticas, jogar cara-ou-coroa – e escolher a que parece melhor.
Em último caso, recorra a um taxista: eles sempre sabem o que os outros deviam fazer. ;-)
O Que Funciona?
E aqui chegamos no ponto em que eu queria: o que funciona em um projeto de BI? Como montar um projeto que vai empacar menos?
Armazéns de Dados
Um bom DW é fundamental para qualquer projeto de BI de sucesso. Você pode se virar com dumps, ODFs, Data Lakes, mas esses caminhos são becos sem saída: cedo ou tarde o peso da falta de integração dos dados (dumps e Data Lakes) e das manutenções de modelo e ETL (ODFs e EDW Dimensional) vão afundar seu projeto – mesmo que todo o restante funcione.
Logo, lição número um: monte um bom projeto de DW, capaz de incorporar novas fontes num estalar de dedos e de produzir novas apresentações de dados em dois palitos. Quem acompanha meu blog já sabe o que isso significa: Data Vault.
Equipes
Ferramentas são importantes, mas não são nem metade da solução. Problemas são resolvidos por pessoas com conhecimento e competência para aplicar ferramentas, não pelas ferramentas. E outra: muito ajuda quem pouco atrapalha – gerente bom é gerente quietinho, que serve a equipe, ajudando a remover obstáculos.
Processos
Há dois grupos de processos dentro de um projeto de BI, especificamente:
Processos de Desenvolvimento;
Processos de Atendimento.
O primeiro é batata: é o processo pelo qual a equipe (parte dela, na verdade) mencionada acima produz os resultados requisitados pelo cliente.
O segundo processo é virtualmente ignorado pela comunidade de praticantes de BI: é o processo pelo qual a outra parte da equipe apóia o cliente. Sim! É o time de “vendedores”, instrutores e tutores, que trabalham com o cliente para entender o que ele precisa e transformar isso em requisitos, que serão tratados pelos desenvolvedores; que ajudam cada novo usuário a aprender a usar as ferramentas e os dados do projeto. O tutor é uma figura inexistente na literatura, mas pode ser visto como um instrutor particular, que vai resolver o problema do usuário uma primeira vez, e ajudar o usuário a repetir esses passos. Ele é diferente do instrutor, que ensina a usar o que está pronto. O tutor cria coisas novas – novas práticas, novos usos dos dados, novos requisitos.
Processo de Desenvolvimento
Não tem segredo: waterfall [bigbang][bigbang_bitly] não funciona, ponto final. A única forma de gestão de projetos que dá certo é Ágil, e neste ponto Scrum é o meu preferido.
Processo de Atendimento
De novo, não tem segredo: um grupo de vendedores (ou evangelistas/analistas de requisitos) e apoiadores (instrutores e tutores) expostos exaustivamente, com uma mensagem clara: Precisa de dados? Me ligue!. Eles interagem com o processo de desenvolvimento alimentando novas histórias no backlog (para os vendedores), com o cliente por meio de chamadas de suporte (tutores/suporte técnico) e com a empresa por meio da capacitação corporativa.
Soluções
Todo projeto de BI usa quatro tipos de soluções:
Apresentações;
Relatórios;
OLAP;
Data Mining.
As três primeiras são baseadas em ferramentas, e portanto são resolvidas pela incorporação de profissionais das respectivas ferramentas ao time. Já a última é tratada como uma conjunto de projetos-filhos e raramente é tratada in house. O normal, para soluções que envolvem Data Mining, é contratar uma empresa especializada no assunto desejado.
E os painéis? Painel não é solução de BI, é ferramenta de (tcham-tcham-tcham-tcham-tcham!) apresentação de dados (e não, não é ferramenta de análise! Quem analisa é OLAP e Data Mining.) Logo, você pode ler o primeiro item da lista acima como “dashboards“. Porém, há muitas formas de se apresentar dados e eu evitaria fechar esse escopo prematuramente, jogando tudo na vala comum “painel”.
Um bom projeto de BI precisa incorporar essas categorias, sem exceções. Não precisa oferecer tudo ao mesmo tempo, desde o dia 1, mas deve garantir que o roadmap vai contemplá-las ao longo do caminho. Como conseguir isso? Tente incluir no seu time um generalista de BI, aquele cara que entende um pouco de tudo, e sabe como os assuntos se interconectam, como amadurecem ao longo do ciclo de vida do projeto.
Se você não puder contar com um membro permanente, aceite um membro flutuante, como um coacher, por exemplo. Se não existir na empresa, procure um consultor externo. Raramente um profissional desse cresce durante um projeto de BI, e você só vai achar um na sua empresa, à sua disposição, por pura sorte.
Conclusão
Então vamos lá: um bom projeto de BI é composto por um time multi-disciplinar (especialistas em ferramentas de ETL, apresentação e exploração de dados), com uma equipe voltada para o atendimento do cliente (esqueça a idéia de ter “self-service 100%”) e outra voltada para uma linha de produção de soluções. Na entrada dessa linha está um DW baseado em Data Vault, no meio as áreas de dados para consumo e na ponta as ferramentas de uso dos dados (apresentação, relatórios e OLAP.) Pipocando aqui e ali aparecem os sub-projetos de Data Mining, tocados normalmente por consultorias externas e nascendo de necessidades pontuais. Essa visão geral pode ser melhor organizada por um generalista.
Nenhuma destas idéias é minha, e isso em parte me dá confiança nelas: Bill Inmon chama esse modelo de CIF, o inglês para Fábrica de Informações Corporativas.
Diagrama da Fábrica Corporativa de Informações.
Outro nome para essa abordagem é BICC – Business Intelligence Competence Center. Veja este artigo para uma discussão mais detalhada do conceito.
Não é um BICC, mas dá uma idéia de como funciona a tal “linha de produção”.
O restante da minha confiança nesse modelo nasce de eu ter experimentado tudo isso: Data Vault, Scrum, Data Mining, OLAP, Relatórios, equipes proficientes etc. etc. etc. Eu vi projetos de BI fracassarem ao descuidar desses fundamentos, como também vi projetos de BI que estão vivos até hoje, alguns zumbis, outros mancando, mas em operação. Se os que dão certo trazem pistas do que pode ser o mais importante, ou o que dá resultados, os que se arrastam, semi-mortos, são os mais valiosos para entender como e porque as coisas dão errado.
Um dos leitores do blog deixou este comentário em 18/5/16:
Fábio, gostaria de mais instruções sobre o data vault, como aplicar, onde aplicar e como é sua modelagem e arquitetura.
Prometi a ele que o próximo post responderia essa questão. Então aqui está: Data Vault, uma visão geral sobre onde aplicar, como modelar e em que arquitetura colocá-lo.
Do Começo, Por Favor
Data Vault é uma metodologia de desenvolvimento de Armazém de Dados Corporativo (do Inglês EDW), que inclui modelagem e processo de ETL. A versão 1.0 parava aí, já a 2.0 vai adiante, até a camada de apresentação dos dados.
Aplicando Data Vault podemos desenvolver um Armazém de Dados com baixo custo, alta produtividade, baixo retrabalho, com processo de ETL de alta performance e altíssimo MTBF.
Volte Mais!
E porque precisamos de um Armazém de Dados mesmo? Bom, não é o assunto deste post, mas aqui vai, resumidamente:
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.
Puxa dados dos vários sistemas da empresa para um repositório central;
Integra os dados dos diversos sistemas em uma visão abrangente.
Um EDW precisa puxar os dados de todos os sistemas porque qualquer se não olharmos em todos os dados da empresa nunca teremos a certeza de termos investigado tudo que há para ser examinado. É como perguntar que livro sumiu da biblioteca: só olhando todos vamos saber qual não está lá. Se o gerente financeiro pergunta “quais são todos os gastos da empresa”, precisamos olhar tudo!
Pense: se sua empresa tiver dois sistemas em MySQL, um em SQL Server, um em Postgres e outro em Oracle, como escrever um SQL que percorra todas essas bases? Não dá, não é? Os dados precisam estar em um repositório centralizado por simples limitação das atuais tecnologias de banco de dados: como em geral usamos SQL para fazer essas pesquisas, e um SELECT não consegue consultar – ao menos não de maneira fácil – dois ou três ou mais bancos de tecnologias diferentes ao mesmo tempo.
Os dados precisam estar integrados, o que significa bater os CPFs 012345678-00 com 1234567800. Quando puxamos um relatório do cliente 012.345.678-00 precisamos que ele seja identificado em todos os sistemas, não importando se na origem ele aparece como 1234567800, 012345678-00, 012.345.678-00 ou de qualquer outra forma. Dados não-integrados fornecem respostas erradas. Sem integrar os dados, seu DW não vale o HD no qual está gravado.
Há várias técnicas para construir um DW atendendo essas duas obrigações:
Copiar tudo da origem, mantendo os mesmos modelos, e integrar na hora de fazer a consulta. Frágil, trabalhoso e pesado (consome muita máquina;)
Copiar tudo da origem, gravando em um novo modelo na Terceira Forma Normal. Mais robusto e de melhor performance que o anterior, mas de evolução e manutenção tão difícil que beira o insano;
Copiar a origem em um novo modelo, como no item anterior, mas em um Modelo Dimensional. Não tão robusto, mas de boa performance, com evolução e manutenção práticas e simples no começo, mas tendendo à impossibilidade de manutenção e evolução com o tempo.
E finalmente, o Data Vault, que não sofre de nenhum destes problemas e tem todas as vantagens. Resumindo em figuras:
Os impactos das mudanças na arquitetura tradicional.
Os impactos das mudanças, agora no arquitetura com DV.
Só para ficar claro: por “nenhum impacto aqui”, no último quadro da figura acima, eu quero dizer “nenhum impacto de manutenção”, já que, obviamente, pode ser preciso criar algo novo. Não haverá impacto no que já existe, não será necessário mudar nada.
Adotar Data Vault como metodologia para desenvolvimento de um DW vai evitar os problemas que costuma comprometer os DWs da 3FN e Dimensionais.
Hoje vamos deixar só com essa afirmação, porque este é um post de visão geral, mas você pode seguir os links apresentados até agora para ler o (extenso) argumento explicando porque é assim.
Como Aplicar?
De fato, não há segredo na aplicação de Data Vault. A técnica meio que se resume em:
Quebrar o trabalho em “histórias”: quero medir isso, quero analisar aquilo;
Daí, para cada uma:
Identificar as tabelas na origem que respondem essas perguntas
Expandir o modelo de dados do DV com hubs, links e satélites;
Gerar automaticamente ETL de carga do DV;
Desenhar o ETL para a área de apresentação.
Existem padrões e técnicas para cada atividade, e a metodologia casa-se como uma luva à gestão ágil. Meu método preferido é o Scrum, e chega a ser surpreendente ver como DV adequa-se tão perfeitamente ao Scrum.
Veja meu post De Agilidade e BI para alguns comentários sobre o levantamento de requisitos para projetos ágeis.
Como É a Arquitetura?
Você já deve ter intuido a forma geral da arquitetura em uma das figuras anteriores. Reorganizando e renomeando as partes daquela figura temos uma visão mais clara:
Arquitetura Data Vault.
Ou seja:
Um ETL (gerado automaticamente) traz os dados de cada origem;
Um banco de dados (preferencialmente relacional, mas um Hadoop does too) recebe e, graças ao modelo de dados do DV, integra tudo “na entrada”;
A partir deste banco um segundo processo de ETL popula as soluções;
Essas soluções podem ser de todo tipo: análises multidimensionais (OLAP), Data Mining (CRM etc.), painéis, relatórios etc. etc. etc.
Cada uma destas soluções após o segundo ETL têm suas arquiteturas particulares. No fundo a arquitetura de um DV são dois ETLs com um banco com modelo de dados DV no meio, mais nada. A partir daí, tudo fica igual à qualquer outro projeto de BI.
Modelagem
A modelagem de um Data Vault é relativamente simples, e você pode ler um pouco mais sobre ela neste post. Grosso modo, porém, resume-se ao seguinte:
Identificar chaves de negócio e criar hubs;
Encontrar relacionamentos entre chaves de negócio e criar links;
Escolher os atributos de hubs e links e criar os satélites.
Hubs
Hubs são tabelas que guardam conceitos, ou chaves, de negócios. Uma chave de negócio é um conceito importante para a empresa: cliente, produto, pedido, posição no call center, empregado, etc.
Tabelas hub possuem as seguintes colunas, nem uma a mais nem a menos:
Business Key: chave primária, um inteiro sequencial;
Load Date/Timestamp: data e hora da inserção do registro;
Record Source: fonte da chave de negócios;
Source business key: chave de negócio no sistema de origem.
Uma tabela hub.
Não há grandes segredos aqui: tabelas hubs acumulam as chaves de negócio, que são a espinha dorsal do modelo. A chave primária é a BK. A cada carga insere-se apenas as novas chaves de negócio dos sistemas de origem. Se a chave já existe, nada é feito. Se a mesma chave existe em vários sistemas, apenas a primeira que chegar é inserida.
Links
Links tão tabelas que guardam o relacionamento entre dois hubs. Uma tabela link que relaciona os hubs 1, 2, … , n possuem as seguintes colunas, nem mais, nem menos:
Link Key: chave primária, um inteiro sequencial;
Load Date/Timestamp: data e hora da inserção do registro;
Record Source: fonte do relacionamento;
BK1: business key do hub 1;
BK2: business key do hub 2;
…
BKn: business key do hub n.
Uma tabela link.
Ela também não sofrem atualização: novos relacionamentos são inseridos, antigos são ignorados. Se um relacionamento já registrado não é mais detectado, ele não é apagado.
Satélites
Satélites são como tabelas de dimensão: guardam os contextos de hubs e links. Uma tabelas satélite de um hub/link que guarda os atributos A1, A2, … , An de um hub/link X possui as seguintes colunas, nem mais, nem menos:
Business Key/Link key: chave primária do hub/link
Load Date/Timestamp: data e hora da inserção do registro;
Load End Date/Timestamp: data e hora do fim da validade daquele registro (default é NULO);
Record Source: fonte dos atributos;
A1: atributo 1;
A2: atributo 2;
…
An: atributo n.
Uma tabela satélite.
Modelo Completo
A coleção dessas tabelas e seus relacionamentos dão o modelo completo:
As tabelas combinadas no modelo.
A etapa seguinte é construir o ETL para dentro do DV, e depois do DV para a camada de apresentação/consumo de dados.
ETL
Um DV possui duas vantagens “matadoras”: integração dos dados no modelo, ao invés de no ETL como é o mais comum, e um ETL padronizado. Graças à essa padronização o ETL de um DV inteiro pode ser gerado automaticamente: a partir de alguns gabaritos de SQL podemos construir o processo que lê e grava todos os hubs, links e satélites.
Eu sempre uso o Pentaho Data Integration (PDI) para processos de ETL, e meu curso de DV entrega ao aluno um gabarito de projeto completo – é só tirar da caixa e usar. A última versão dele traz até os SQLs para criar as tabelas no Data Vault.
Isso para o primeiro ETL, para dentro do DV. O segundo ETL, saindo do DV para a camada de apresentação, é mais particular, e não há como automatizar sua geração. Por outro lado, como todos os pontos de partida não são mais os sistemas de origem mas sim o DV, a “forma” geral desse segundo processo é mais uniforme, e alguns padrões acabam por facilitar seu desenvolvimento.
Por exemplo, dimensões são quase sempre construídas a partir de um hub e seus satélites, e tabelas fatos originam-se de links. Construídos os SQLs que lêem isso no DV (e nisso eles seguem um padrão de JOINs bem cadenciado), o passo seguinte é fazer trocas de chaves naturais por delegadas e, em caso de necessidade, limpar os dados.
Conclusão
Adoro quando um leitor pede algo, pois escolher o tema do próximo post, para mim, é como escolher roupa para sair: muito, muito difícil – e se não gostarem? e se ficar ruim? e se eu falar besteira por saber pouco? E se?…
Vimos que um Data Vault é uma metodologia que habilita a realização da visão de Bill Inmon, a Corporate Information Factory. A [CIF][cif_bitly] (até o advento do DV, outro mito) é como uma linha de produção, que ingere todos os dados da empresa e “fabrica” produtos de dados conforme as necessidades vão surgindo.
Data Vault é uma metodologia composta por uma modelagem, um processo de geração automática de ETL e outros elementos (como padrões e nomenclaturas.) O EDW se completa com um segundo processo de extração, que leva os dados para as áreas de apresentação, em formato dimensional ou não. Tudo em um processo de desenvolvimento que nasceu para ser tocado com gestão ágil (Scrum, na minha preferência), boa parte automatizada e com baixo ou nenhum retrabalho.
Não deixe de ver o post As Vantagens do Data Vault para mais sobre como um DV pode ajudar seu projeto de EDW.
É claro que nada é 100% a prova de falhas, defeitos ou problemas e eu mesmo já enfrentei minha cota de surpresas, dificuldades e maluquices nesse caminho que venho trilhando há alguns anos. Mesmo assim, hoje em dia, um Data Vault é a coisa que mais se aproxima de um método perfeito.
Fora essa babação no final, acredito que era isso. ;-)
Semana passada, 6/5/16, eu assisti uma palestra sobre uma empresa chamada Attunity, e suas ferramentas para Business Intelligence. Vendo as promessas do representante brasileiro eu me dei conta de que já escrevi bastante sobre DV, mas nunca escrevi especificamente sobre as vantagens trazidas pela adotação de Data Vault. Vamos corrigir isso hoje, partindo desta apresentação.
Você pode pular direto para a lista de vantagens clicando aqui.
Uma Nova Categoria
Estamos em 2016 e já lá se vão cerca de 40-50 anos desde que Bill Inmon começou o debate sobre Armazéns de Dados, e 24 anos desde seu livro Building the Data Warehouse. Muita água passou embaixo da ponte e todas suas idéias estão sedimentadas, firmes, sobre as quais se assenta a moderna indústria de DW. Um destes conceitos é a Corporate Information Factory, que agrupa as fontes de dados e seus consumidores como uma linha de produção.
Diagrama da Fábrica Corporativa de Informações.
Tal qual a revolução industrial fez com a manufatura, graus de automação sucessivamente maiores estão acelerando e simplificando o desenvolvimento, manutenção e gerenciamento de Data Warehouses. Instrumental para essa revolução foram tecnologias aparentemente irrelevantes, como modelos de dados e metodologias de desenvolvimento.
Metodologias como Scrum, Continuous Integrations e DevOps agem para diminuir a intervenção e variabilidade da ação humana, enquanto que outras, como Modelagem Dimensional e Data Vault, domam a confusão dos sistemas OLTP e permitem a criação de algoritmos. E é justamente essa criação de algoritmos que permite automatizar o processo de desenho, desenvolvimento e manutenção de DWs.
Uma nova categoria de ferramentas brotou desse fértil ambiente: ferramentas de automação de gestão de DW. Ainda não vi esse ramo ser tratado por um acrônimo, nem mesmo ter um nome mais comum, mas acho que, em Inglês, seria algo Data Warehouse Management Solutions, ou DWMS. Já sabem: se virem por aí, apareceu no GeekBI primeiro. ;-)
Continuando, essa categoria já tem alguns nomes internacionais:
Fazia tempo que eu não visitava o BI Ready, empresa de Ian Nicholson com quem já troquei umas idéias no LinkedIn. Surpresa! Ela foi adquirida pela Attunity e agora são um nome só. Não é à toa que, na apresentação, a Attunity declarou pertencer a essa turma – ela comprou “metade” das empresas dessa área!
Esse é o Ian Nicholson, fundador da BI Ready, fazendo a mesma cara que eu faria se tirasse essa foto.
Processos e Problemas
Um projeto de DW que hoje é chamado de “tradicional” (i.e., feito com metodologias de mais de 15 anos atrás) envolvia as seguintes etapas:
Levantar os requisitos;
Estudar os dados de origem;
Desenhar o modelo dimensional;
Desenhar o processo de ETL;
Colocar em produção;
Dar manutenção: propagar as mudanças dos sistemas de origem e adequar às novas necessidades do cliente.
Esse projeto em geral era tocado dentro de uma moldura PMI (a.k.a. Waterfall). Era um método tão certeiro e determinístico que até hoje todo mundo sabe que, feito assim, sempre falha.
Os problemas de um DW ‘clássico’.
DW feito por cópia dos bancos de origem é a pior escolha possível, a menos que seja para uma padaria, uma farmácia, uma banca de jornais etc. ;-) Veja que não estou falando de palco (stage), mas de montar o DW como uma coleção de réplicas. Um modelo dimensional é o mínimo necessário para sobreviver aos problemas que serão apresentados ao final desta seção.
Levantar os requisitos da próxima entrega (30 dias;)
Estudar os dados de origem até encontrar o estritamente necessário para próxima entrega;
Desenhar o DV;
Gerar automaticamente o processo de ETL;
Derivar dados para apresentação;
Colocar em produção e reiniciar o ciclo.
A manutenção é incorporada nas sprints.
Veja que, grosso modo, o processo em si não mudou muito: de projeto waterfall passamos para Scrum, de modelo Dimensional no miolo do DW passamos para um Data Vault e o ETL principal é gerado automaticamente.
Os problemas que existem (existiam e vão continuar existindo) são:
Integração: sem integrar e limpar 100% dos dados, todas as respostas são suspeitas. Ou você confiaria nos números sabendo que algo pode ter ficado de fora?
Historiamento: não adianta montar um armazém que não guarda histórico. Fazer isso é cuidar de dados operacionais e jogar a água fora com o bebê – o maior valor dos dados está no histórico;
Mudanças na origem: sistemas transacionais representam os processos que a empresa executa. Se a empresa muda, forçosamente os OLTPs precisam mudar, e o DW vai ter que ser adequado, sempre;
Performance de ETL: a menos que a empresa esteja definhando, ela sempre vai crescer, sempre vai querer mais dados. O hardware para ETL sempre acaba ficando obsoleto, por um motivo ou outro, cedo ou tarde. O truque é extrair tudo que ele pode dar, e não desperdiçar nada;
Velocidade de mudança: por fim, em cima de todos os problemas apresentados, temos o fato de que as coisas não estão ficando mais calmas, mais lentas, e sim mais rápidas, com mais demandas e mais complexidade.
Ferramentas…
As novas ferramentas de automação de DW se propõem a resolver esses problemas.
O Attunity propõe resolver um DW em dois passos:
Usando o Attunity Replicate os dados são trazidos de diversas fontes de dados para um repositório centralizado;
Daí, com o Attunity Compose, um DW é desenhado e carregado automaticamente.
Há um bom grau de magia negra envolvida (=coisas que acontecem sem entendermos claramente como), mas tudo faz um bom sentido. O Replicate se conecta aos bancos de dados de origem e fazem uma engenharia reversa total. Com essas informações ele vai ao banco de destino e recria o banco de origem, respeitando as diferenças de tecnologias. Por exemplo, ele pode replicar bancos MS SQL Server e Oracle para dentro de um único Postgres. Depois ele faz uma transferência inicial, em que replica as origem(ns) inteira(s) no(s) destino(s). A partir do final desta carga, o Attunity Replicate passa a ler o log de commits dos bancos de origem e replicar no destino, em tempo real.
Quem leu meu post Analítico ou Operacional? sabe que essa replicação não é um DW, e que fazer isso “não é BI”.
A Attunity também sabe, e dá o passo final em direção ao DW através do Compose. O que essa ferramenta faz é mais magia negra que a outra:
Através de engenharia reversa e algoritmos especiais, o Compose “descobre” os relacionamentos entre as várias colunas de todas as tabelas das origens;
Usando esse conhecimento, a ferramenta monta um DW – desenha um modelo de dados – automaticamente;
Em seguida constrói (sempre automaticamente) o ETL para esse DW;
Na última etapa ele monta uma área de apresentação de dados, seguindo indicações de que dados o cliente quer explorar.
A ferramenta ainda permite customizações e correções feitas pelo time de DW, de modo que qualquer interpretação incorreta pode ser ajustada.
Ou seja, ele automatizou 100% do processo moderno de desenvolvimento de DWs!!!! E digo mais: !!!!. Mas não pára por aí:
Esse DW guarda histórico;
A área de apresentação pode expor estrelas multidimensionais, com até mesmo SCDs tipo 2;
Ele detecta mudanças nas origens e ajusta o DW e o ETL;
Todas essas ferramentas são clusterizáveis, ou seja, podem ser escalonadas horizontalmente.
Isso são coisas que ouvi ou que perguntei durante a apresentação. Há coisas que eu não perguntei, mas presumo que também estejam no pacote, como tratamento de erros de ETL e monitoramentos diversos. Aliás, a parte de monitoramento é muito bacana, também – aprendi um negócio chamado “hot data, cold data”, sobre o qual vou fazer uns experimentos e, eventualmente, vou postar sobre.
… e Soluções
E como o Data Vault se encaixa nesse cenário? Simples: ele oferece tudo que as ferramentas oferecem, sem o custo monetário. Digo monetário explicitamente porque não existe almoço grátis, sempre precisamos pagar por algo. Se não é em dinheiro, vai ser em treinamento e capacitação, por exemplo, ou simplesmente mais trabalho.
DW ‘moderno’, re-organizado segundo DV.
Eis a lista de vantagens (ou problemas resolvidos) trazidos pela adoção de Data Vault no miolo do EDW:
Velocidade de desenvolvimento: usar DV corta o tempo necessário para desenvolver e entregar em algumas ordens de grandeza. Por exemplo, coisas que levariam meses saem em dias;
Modelo de dados: o diagrama de dados do Data Vault é construído através de regras simples, que capturam o negócio no modelo. Assim, uma vez que tenhamos a lista de esquemas, tabelas e colunas do sistema de origem, o ato de desenhar um DV é trivial e leva algumas horas, contra algumas semanas de outros formatos;
Processo de ETL: usando o Pentaho Data Integration, o processo de ETL é gerado automaticamente, a partir do modelo elaborado anteriormente. Ainda é preciso juntar as partes (as diversas transformações) dentro de um job (pré-fabricado), mas isso é uma tarefa de minutos. O ETL inteiro sai em menos de um dia;
Integração: o modelo de dados do Data Vault já arquiva os dados de maneira integrada. Ou seja, a integração ocorre via modelo, no momento em que os dados aterrisam no DV;
Historiamento: 100% dos dados de um DV são historiados, automaticamente e por definição;
Mudanças na origem: evidentemente não são tratadas automaticamente – um software pode fazer isso, não uma metodologia. Entretanto, esse impacto é mínimo:
Qualquer mudança na origem não quebra o processo de ETL, ao contrário de DWs baseados em outros modelos;
Mudanças na origem são resolvidas por um algoritmo simples, e qualquer manutenção leva praticamente o mesmo tempo de repetir o desenvolvimento (horas ao invés de semanas, portanto;)
Nenhuma mudança na origem quebra a área de apresentação. A área de apresentação é reformada apenas em casos que afetem-na. Graças a esse fato, o impacto sobre a área de apresentação causada por mudanças nas origens é de mínimo a inexistente;
Performance de ETL: várias vantagens ao usar um DV;
Alta velocidade: por tratar apenas deltas (i.e., as diferenças) por meio de comparações simples, o processo é muito rápido;
Paralelização: graças ao formato do ETL, todas as operações podem ser maciçamente paralelizadas, possibilitanto uso de hardware barato (COTS;)
Resistente a erros: o ETL de um DV é auto-reinicializável por definição, e só é interrompido por falhas graves (hardware ou dados muito corrompidos;)
Velocidade de mudança: é a mesma da velocidade de desenvolvimento – muito rápida.
Como vantagem extra, pelo fato de DV permitir atacar o problema por pedaços, ele se presta à:
Modularização em sprints;
Paralelização do desenvolvimento.
Por ser baseado em processos automatizados e algoritmos, a quantidade de erros é substancialmente menor, gerando projetos de qualidade maior, e mais padronizado.
Conclusão
Já há alguns anos a indústria de BI vem incorporando tecnologias que habilitam novas soluções de problemas complexos, como a construção, gerenciamento e manutenção de Armazéns de Dados. Essas tecnologias surgem como técnicas/metodologias e softwares.
Um software representante desta nova categoria é o Attunity, especificamente os módulos Replicate e Compose. O primeiro copia dados de diversas origens para um mesmo (ou vários) destino(s). O segundo modela um DW e cria o processo de ETL automaticamente a partir da réplica. Não sei com que qualidade, precisão e velovidade o Attunity entrega os resultados, mas a promessa é fantástica, para dizer o mínimo.
Esse produto é resultado de evoluções anteriores. Uma destas é a metodologia Data Vault, que oferece essa lista de vantagens:
Alta velocidade de desenvolvimento: entrega em dia o que levava meses;
Processo de ETL gerado automaticamente – maior velocidade, qualidade e padronização, com menos erros;
Integração: dados são integrados na entrada;
Historiamento: 100% dos dados de um DV são historiados;
Mudanças: resiliente a mudanças na origem, processo de ETL não pára e impacto global (tanto ETL quanto usuários) é de mínimo a irrisório;
ETL de alta performance, imune à erros, restartável e 100% paralelizável (é possível executar simultaneamente todas as etapas da carga do DV;)
Adequado à processos de desenvolvimento ágil;
Desenvolvimento do modelo (dada ferramenta adequada) e do ETL paralelizável.
Com um Data Vault podemos obter os mesmos resultados prometidos pelo Attunity, com menos automação, e com um custo diferente (menor?)
Clicando aqui você vê a lista dos meus posts marcados com Data Vault. Eis links para alguns do meus posts sobre o assunto:
Só para não deixar vocês pendurados: eu ofereço os dois cursos, Requisitos Ágeis e Data Vault. Fazer essa propaganda dá impressão que eu montei um post para me auto-promover, mas juro que não é o caso deste aqui. Acredito no valor que esses cursos agregam e sentiria que estaria prejudicando você, meu leitor, ao evitar contar que eles existem. Quem me acompanha sabe que quando eu vou vender algo aqui, eu aviso no começo. ;-)
No primeiro post da série eu apresentei uma analogia direta entre Mineração real e Mineração de Dados. Minha esperança era ter encontrado uma forma simples de responder a pergunta “O que é o produto?”.
No post de hoje eu vou explorar essa analogia e apontar algumas das etapas em um projeto de mineração tradicional e construir uma explicação simples de como projetar e conduzir projetos de Data Mining.
Ilusões Esmeraldas
Você se lembra de expedições chamadas bandeiras, sobre as quais aprendemos na escola? Bandeiras desbravavam nossos sertões e cumpriam várias funções: conseguir mão-de-obra (escravos), expandir recursos (criar plantações e vilarejos), conhecer o território e buscar minérios e pedras preciosas. Uma das mais famosas foi a Bandeira de 1674, que tinha como uma das metas encontrar certa lendária montanha, cheia de prata e esmeraldas. Do verbete da Wikipedia:
A 8 de agosto de 1672, Fernão Dias Pais Leme se apresentou à câmara de São Paulo a chamado de seus oficiais e declarou que, em cumprimento da carta régia, partiria em março seguinte para o sertão de Sabaraboçu a fim de descobrir prata e esmeraldas. Itaverava-uçu ou Sabarabuçu era a “serra que resplandece”, inventada por Filipe Guilhem: sertanista castelhano, a procurar nas “gerais” sem tamanho a misteriosa montanha de prata ou esmeralda, visão do paraíso…
O destaque é meu. Quer dizer, ninguém tinha a menor idéia se existia ou não um veio explorável de qualquer coisa, em algum lugar! Fernão Dias aventurar-se-ia pela mata selvagem em busca de um “visão do paraíso” descrita por outro explorador, sem a mais remota comprovação!
Hoje em Dia…
… mineração é uma ciência elaborada e muito sofisticada. Envolve desde análise de imagens de satélites, amostras de solo, Geologia e Sismologia, Física, Química e até Biologia, em busca de certeza da existência de depósitos, e depois, para o projeto, Engenharia Mecânica e Elétrica de alto gabarito, sem falar em todas as habilidades de gestão, planejamento, finanças etc. etc. etc. Abrir uma mina, hoje em dia, é um brincadeira de menino grande, com várias etapas:
Etapas de um projeto de mineração.
Note que existem três etapas só de pesquisa, para apenas na quarta etapa desenvolver a mina e só então começar a produzir! Muito antes de o minério começar a sair da mina, todas as justificativas financeiras, riscos e promessas estão muito claras. O que não é tão exótico assim: para que gastar dinheiro “estragando” uma paisagem se não for valer à pena?
Projetos de Data Mining precisam ser guiados por esse mesmo raciocínio por um único motivo: é um projeto tão complexo que se não houver um objetivo bem claro, ele vai dar em nada com certeza. Data Mining não é uma ferramenta, que acaba sendo aproveitada em usos paralelos se o uso principal falhar. Nem tão pouco é uma produto essencial, como um ERP ou BPMS, que toda empresa deve ter e por isso é melhor instalar e começar a usar o quanto antes, mesmo sem ter muito claros os detalhes. Toda essa zoeira em torno de BigData e Data Science ajuda a piorar o cenário, pois acabam funcionando como uma cortina de fumaça em volta do assunto.
Data Mining é difícil, é a coisa mais difícil de BI, que é uma disciplina difícil por natureza. Sem um plano bem claro e justificado, Data Mining dá em nada. Pior: dá em desperdício de tempo e dinheiro.
Projeto de Data Mining
Vamos olhar as etapas da figura anterior e compará-las a uma iniciativa de Data Mining numa empresa. Antes de começar, vamos reforçar o que aprendemos no post anterior:
O produto de Data Mining é um Modelo Matemático, da mesma forma que o produto de Mineração é o minério: ambos servem de insumo para produção de algo. Minérios são refinados em produtos, e Modelos Matemáticos são refinados em decisões automáticas.Nosso projeto de Data Mining quer desencavar um modelo. Em que dados? De que maneira? Que valor?
Vamos adiante com a analogia.
Geociência
A primeira etapa de um projeto de mineração fornece dados que encoragem a exploração, que sugiram que ali pode haver uma boa oportunidade. É a etapa que responde a perguntas “o quê estamos procurando?” e “porque aqui e não ali?” Em nossa analogia, Geociências é transformada em Conhecimento de Negócio, puro e simples. É o conhecimento de negócio e da operação da organização que diz onde pode haver uma oportunidade de ganhos.
Quem “faz” Geociência é um profissional especializado, experiente, que já fez isso outras vezes. É um cara tão importante que aparece em relatórios oficiais de minerações. Para o caso do Data Mining estamos falando de uma pessoa com habilidades de Matemática e Estatística de nível de Ensino Superior, com visão estratégica e conhecimento de negócio. Não bastasse isso, é alguém que precisa ter alguma experiência na atividade de avaliar organizações, seus processos de negócio, seus dados e vislumbrar oportunidades de negócio nos dados.
Cientistas de Dados, que é o título de Analistas de Data Mining por esses dias, não se qualificam. Podem ser uma alternativa, na falta do referido profissional, mas não é o ideal porque, em geral, está muito focado nas técnicas e ferramentas, e menos na visão de negócio.
Exploração & Descoberta
A exploração é levada adiante por mineiros e prospectos técnicos, e tem a função de encontrar o depósito mineral propriedamente dito. Depois de o geocientista levantar a forte suspeita da existência de um aluvião qualquer, é essa etapa que vai tirar a prova dos nove e dizer que ali tem mesmo alguma coisa.
Em Data Mining é a tal da Prova de Conceito, ou PoC. Conduzidos pelo “Geocientista Empresarial” (Cientista de Negócios??? Aff…), um time com um Analista de Data Mining e outros SMEs (Subject Matter Experts, tais como DBAs, Financistas, Marketeiros etc.) faz a primeira avaliação da oportunidade levantada. Dá para fazer? Existem dados suficientes? Vai chegar a um resultado ou calcular por anos a fio? E que resultado vai trazer? Qual serã seu ROI?
Eu não gosto do termo, mas entendo que esta etapa pode ser caracterizada por uma buzzword que não colou: Business Discovery. A expressão, agora dentro do conceito de mineração, traz um significado claro: é o resultado da exploração dos dados crús da empresa e aponta para um “veio virtual de dados valiosos”. Eu suspeito que esse era o conceito imaginado por empresas que vivem da buzzword Data Discovery – tanto que BD foi tentado antes, não colou e “morfou” em Data Discovery.
Agora, uma vez que a oportunidade de negócio identificada na primeira etapa, Geociência, foi avalizado por esta etapa anterior, Descoberta, nos resta decidir se vamos adiante, construir o modelo.
Desenvolvimento
É neste ponto que a mina ganha corpo, que figurativamente sai do subterrâneo. É o momento de comprar equipamentos, contratar pessoas e treinar mineiros e, enquanto isso acontece, licenças de operação foram (ou estão sendo) negociadas e adquiridas, uma rede de logística é desenhada, e assim por diante, com muitas coisas acontecendo interdependentemente.
Em Data Mining, nesta etapa, a equipe provisória é formalizada, com os eventuais ajustes, os ambientes e recursos são amealhados, e o projeto de Data Mining ocorre.
Note que em Data Mining estamos uma fase adiantados em relação ao projeto de uma mineração real: o produto da mina – o minério – só vai começar a sair na próxima etapa, mas o produto do projeto de Data Mining – O Modelo – ficará pronto na etapa atual. Até entendo que podemos discutir isso, e eventualmente jogar a produção do modelo para etapa seguinte e declarar esta aqui como uma etapa de planejamento, de venda interna etc. Mas, IHMO, a venda precisa ter sido feita lá atrás, antes da PoC. E depois, montar um projeto de DM é incomparavelmente mais simples e rápido que montar um projeto de uma mina.
Esta etapa possui subdivisões próprias, tal como um projeto de mineração. O Analista de Data Mining constrói, testa e valida o modelo. Esse analista precisa ter uma formação operacional sólida, tem que dominar suas ferramentas e ser do ramo. Não dá para aprender a construir modelos por tentativa e erro, experimentando ora isso, ora aquilo. É preciso saber o que se está fazendo, sob o risco de encontrar um modelo errado.
Ao final desta etapa teremos o Modelo, que é equivalente ao minério extraído pela mina.
Produção
Para a mineração, é aqui que o produto aparece. Ele vem na forma de lingotes, pelotas, fios ou barras, puros ou combinados em ligas, e caem no mercado para venda. Graças à peculiariedades das cadeias de suprimento de nosso mundo moderno, essa produção sempre tem um destino praticamente certo, quando não pago em adiantado.
No projeto de Data Mining, por outro lado, é quando o modelo é posto para trabalhar e gera decisões automáticas. O que acontece nesta etapa depende de como a etapa anterior, modelagem, foi tratada.
Se o Desenvolvimento restringiu-se à criação do modelo, então esta etapa implica em um novo projeto, ou um sub-projeto independente, que é a integração do modelo aos sistemas da empresa. Por exemplo, se o modelo faz a seleção de produtos em uma mala-direta, então ele precisa ser integrado ao gerenciador de campanha e isso requer, via de regra, um mini-projeto. A equipe conta com o Analista de Data Mining, mas fora isso quase sempre é diferente da anterior. Os ambientes são outros e a infra-estrutura envolvida agora é a operacional. Findado esse mini-projeto de integração, o projeto de Data Mining entre em modo de monitoramento, avaliação e ajuste do modelo – operação contínua.
O contra-exemplo é um modelo de pontuação de crédito (Credit Scoring), no qual vários parâmetros são passados e uma pontuação é retornada. Esse tipo de integração pode ser feito por meio de um webservice, um webservice que pode ser construído na etapa anterior, ao longo de um projeto paralelo para integrar o novo método de scoring ao sistema transacional. Neste caso, a presente etapa assume apenas o modo de operação contínua.
Conclusão
Do post anterior tiramos o conceito de produto em um projeto de Data Mining: um modelo matemático, que pode ser usado para gerar decisões automáticas no sistema transacional.
Hoje chegamos a uma nova analogia: as etapas de um projeto de Data Mining:
Geociência: usar o conhecimento de um especialista em Data Mining e negócios para identificar oportunidades nos dados;
Exploração & Descoberta: Prova de Conceito liderada por um Analista de Negócio em conjunto com um Analista de Data Mining para determinar a viabilidade e o ROI da oportunidade;s
Desenvolvimento: desenvolvimento do modelo, usando o método SEMMA por exemplo;
Produção: integração do modelo nos sistemas da organização.
Alguém pode argumentar que essas quatro etapas já existem dentro do CRISP-DM e que estou apenas explicando-o com minhas próprias palavras. Concordo. Minha intenção não é inventar um método, mas ajudar o não-Data Miner a entender o assunto. Nesse sentido, sim, é uma repetição do CRISP-DM. Só que as três primeiras fases do CRISP-DM, tal como estão colocadas, me dão a sensação de que primeiro decidimos por um projeto de Data Mining e só depois envolvemos o negócio, quando na realidade isso não funciona – acredite-me, já vi mais que minha cota disto nestes últimos 15 anos.
Para obter sucesso é o Negócio que deve impulsionar o projeto de Data Mining, não o contrário. Justamente para ajudar o executivo que precisa tomar pé no assunto eu reescreveria o CRISP-DM com outros termos, como por exemplo:
Etapas de um projeto de Data Mining.
Eu ainda não senti aquela epifania que me acomete quando eu tenho certeza que bati em cima. Sinto que está faltando alguma coisa, que dá para melhorar. E até que eu consiga uma abordagem melhor, o que você achou desta? Ajudou? ;-)
Geek BI 