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.

Essa técnica foi inventada e desenvolvida por Daniel Linstedt para um projeto na mítica Lockheed Martin, que faz (fazia?) o mítico Blackbird SR-71, o avião dos X-Men. Baixe a amostra do Building a Scalable Data Warehouse with Data Vault 2.0 e leia o prefácio (do mítico Bill Inmon – isso aqui tá um templo grego de tanto mito!!) para ver essa história.

Perdão, mas eu precisava colocar isso aqui.
Perdão, mas eu precisava colocar isso aqui.

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.


Leia meu post Um Ponto Fita o Mundo para ver o argumento inteiro.

Vamos continuar?

Por Quê Adotar DV?

Todo EDW cumpre duas funções básicas:

  • 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 na arquitetura tradicional.
Os impactos das mudanças, agora no arquitetura com DV.
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 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.
Arquitetura Data Vault.

Ou seja:

  1. Um ETL (gerado automaticamente) traz os dados de cada origem;
  2. 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”;
  3. A partir deste banco um segundo processo de ETL popula as soluções;
  4. 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.
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 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.
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.
Uma tabela satélite.

Modelo Completo

A coleção dessas tabelas e seus relacionamentos dão o modelo completo:

As tabelas combinadas no modelo.
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. ;-)

4 comentários sobre “Data Vault – Como Usar

  1. Olá Fábio, tudo certo?
    Eu sempre leio e releio seus posts. E às vezes aparece algo que a gente não leu direito nas primeiras vezes. Foi o caso neste post, sobre automatização dos ETL’s. Só agora notei esse ponto… Eu já achava o máximo criar manualmente os ETL’s para um modelo DV, por causa de todos benefícios de um DV. Mas só agora notei essa parte de automatizar a geração de código neste ponto…

    Mas no artigo tive umas dúvidas:
    1) Nos satélites, você cita um campo “Load End Date/Timestamp: data e hora do fim da validade daquele registro (default é NULO);”. Neste ponto eu fiquei em dúvida. O ETL para estes satélites poderão realizar operação de update ou não? Ou este campo seria apenas para os casos de atributos que já tiveram uma “vigência fechada” nos OLTP (estou fazendo analogia ao SCD tipo II)?

    2) Eu e um colega discutimos se o DV seriam bancos de dados para cada sistema transacional ou todo o DV corporativo estaria em um único banco de dados. Você sugere o DV deveria estar em bancos diferentes? Ou tudo junto? No meu caso, estou falando de SAS e, consequentemente, datasets são tabelas e diretórios são bancos de dados. Então, na falta de um banco relacional como DV, eu inicialmente colocaria todo o DV num “diretório dvault”.

    3) Um BD relacional daria conta de manter um satélite gigantesco (algo como muitos atributos/colunas muitas transações/registros por dia)?

    Por hoje é só (hahaha). Vou continuar a ler e esmiuçar mais para ter mais dúvidas, hehe :P

    Grande abraço,
    Eduardo

  2. Graaaaande Eduardo! Tudo, obrigado! E por aí? Excelentes questões, obrigado! Na verdade, são tão boas que estou escrevendo a resposta em um post dedicado, pois neste espaço de comentários ficaria muito ruim. Estará no ar em alguns minutos, aguarde!

    1. Oi, Felipe, obrigado pela visita.

      A metodologia diz respeito muito mais à modelagem, gestão e ETL que arquitetura propriamente dita. Então a resposta é “não necessariamente, mas se você precisar, sim”. ;-)

      Pense no palco (“stage”) como um recurso que você pode adotar se for necessário, não como uma coisa obrigatória. É muito frequente o uso de um stage para tratamento de arquivos e rápido deslocamento de dados, para janelas de ETL bem pequenas.

      Logo, se o seu ETL não der conta de todas as origens dentro da janela temporal, ou se você precisa processar muitos e muitos arquivos, um palco é uma boa opção e o DV suporta-lo-á. ;-)

Deixe uma resposta

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

Logotipo do WordPress.com

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

Imagem do Twitter

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

Foto do Facebook

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

Foto do Google+

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

Conectando a %s