Introdução à Data Vault

Antes de iniciar o post, gostaria de agradecer ao meu amigo Fábio de Salles por ter fornecido as imagens dos modelo de dados retiradas diretamente do seu blog, Geek BI.

Bora lá!

Em meu post anterior (As Etapas do BI — Data Warehouse? ETL/EL-T? What?) comentei brevemente sobre Data Vault e prometi realizar um post sobre. Aqui está!

Data Vault, é uma técnica de modelagem de dados para o desenvolvimento de Enterprise Data Warehouses (EDW), criado por Daniel Linstedt.

Um Data Vault, inclui modelos de dados simples e processos de ETL, cujo seu objetivo é armazenar dados ao longo do tempo e dispor um repositório central que receba e organize os dados de diversas fontes, é a partir deste repositório que outros projetos vão consumir os dados. Como a imagem abaixo.

Arquitetura com Data Vault

Revendo a imagem, podemos ver que existe uma camada de Data Vault, que aparenta ter o dobro de trabalho, pois afinal, precisamos modelar um DV e ainda criar ao mínimo dois ETLs, um que realize o processo para dentro do DV e outro processo para fora na a criação de Data Marts, WS etc.

Parece desvantajoso, mas…

Desenvolver um Data Vault trás inúmeros benefícios, como:

• Desenvolvimento de Data Warehouses totalmente eficientes;
• Alta produtividade;
• Retrabalho reduzido;
• Processos de ETL totalmente performático e paralelizável;
• Velocidade de desenvolvimento;
• Armazenamento de histórico automaticamente;
• Desenvolvimento escalável (meu preferido);
• Adequação aos processos de desenvolvimento ágil.

Apenas uma observação que talvez não ficou claro, o Data Vault não foi feito para realizar análises, mas sim para armazenar histórico, ou seja, se for realizar análises em um DV, não terá uma performance digna de uma análise eficiente.

A Modelagem do DV

A primeira vista, um modelo de DV parece um bicho de 7 cabeças e nos perguntamos o motivo de adota-lo, acredite eu mesmo me perguntava, pra que tudo isso? Porém, quando coloquei na prática, vi que era fácil, intuitivo e além de tudo, trás uma enorme escalabilidade e flexibilidade para manutenções e trabalhos futuros.

A modelagem é simples e possui três componentes fundamentais e essenciais para a construção do DV, são eles:

Hub

Seu objetivo é armazenar as chaves de negócios identificadas. Um exemplo, é a chave primária (PK, do inglês Primary Key) de uma tabela de um banco de dados relacional.

Tabela de Hub

A tabela de hub é composta por 4 atributos, são eles:

• BK (Business Key): É a chave primária da tabela;
• LDTS (Load Date Time Stamp): Armazena a data e hora em que o registro foi inserido;
• RSRC (Record Source): Descrição da fonte da chave de origem;
• SBK (Source Business Key): É a chave de negócio da fonte de origem, como citado no exemplo anteriormente.

A tabela de Hub é feita incrementalmente, ou seja, só insere novas chaves a cada carga. Caso a chave de origem já exista no hub, ela será ignorada.

Link

O objetivo deste tipo de tabela, é relacionar um hub ao outro, ou seja, se levarmos ao pé da letra, o link relacionada o negócio propriamente dito, com isso, esse tipo de tabela pode relacionar mais de um negócio, conectando diversos hubs em um único link.

Tabela de Link

• Link Key (Chave do Link): É a chave primária da tabela;
• LDTS (Load Date Time Stamp): Armazena a data e hora em que o registro foi inserido;
• RSRC (Record Source): Descrição da fonte do relacionamento;
• BK (Business Key): É a chave de negócio do Hub, ou seja, esse campo é uma chave estrangeira (FK, do inglês Foreign Key) que é relacionada diretamente com a chave primária do Hub (Business Key). Como mostra os campos selecionados em laranja, pedido_bk e empregado_bk, isso demonstra um relacionamento entre ambos hubs, logo, entre o negócio.

O link ele demonstra o relacionamento entre as chaves de origem, ou seja, se no sistema de origem existe um relacionamento entre tabelas, isso terá que ser refletido no link. Assim como o hub, é a carga incremental, são inseridos apenas novos relacionamentos, quem já existe são descartados.

Satélite

Os satélites são as tabelas que armazenam as descrições, ou seja, guardam os atributos que dão o contexto do negócio para as chaves armazenadas nas tabelas de hubs e links. Podemos pensar que o satélite é uma tabela de dimensão.

Tabela de Satélite

• BK (Business Key) / Link Key: É a chave primária da tabela de Hub ou Link;
• LDTS (Load Date Time Stamp): Armazena a data e hora em que o registro foi inserido;
• RSRC (Record Source): Descrição da fonte dos atributos;
• LEDTS (Load End Date Time Stamp): Armazena a data e hora em que o registro deixou de ser valido;
• Atributos: Armazena os campos que vão compor o contexto dos hubs ou links.

No satélite, podemos observar que ele é sua chave primária é composta, com a chave de negócio do hub e o LDTS, e o interessante é vermos também que no satélite possuímos o campo de LEDTS que é diferente das outras tabelas. O LEDTS por padrão é Nulo, ele quem mantém o controle da minha versão de registro para manter sempre meus dados atualizados, e mantendo assim o histórico do registro no satélite.

Já na questão de carga, os satélites são inseridos novos, e os que sofrem algum tipo de atualização no sistema de origem, é atualizado no DV. Ou seja, quando o registro é atualizado, o satélite preenche o LEDTS que era nulo (significando a versão mais atual) e inserindo um novo registro.

Um ponto bem curioso

Cada tabela do Data Vault é composto por uma cor:

• Hub: Azul
• Link: Vermelho
• Satélites Amarelo

Outras tabelas

No Data Vault, ainda possuem outras tabelas, que são:

• Point-in-Point (PIT): Combinação de dados em momentos diferentes no tempo e a redução de complexidade em junção de relacionamento com o objetivo de melhorar o desempenho.
• Same-As: Utilizada para integrar dois Hubs, quando existem a mesma chave com valores diferentes em sistemas distintos.

Essas tabelas são somente utilizadas em casos específicos, porém todo o mecanismo de funcionamento do Data Vault, se dão pelo Hub, Link e Satélite.

E a aplicação, como fica?

Agora que sabemos o básico, já entendemos o que cada tabela faz e qual seu objetivo, vamos para um exemplo prático.

Veja o seguinte modelo, que compõem um sistema transacional — OLTP.

Se fossemos converter parte deste modelo para um Data Vault, a modelagem ficaria coerente e condizente, pois iríamos atender todas as especificações do DV, isolando os negócios, descrições e relacionamento de negócio.

Em um DV, ficaria assim.

Vemos que isolamos as chaves de origem do negócio em dois hubs distintos:

• h_pedidos;
• h_empregados.

Com isso, criamos um link que representa a ligação entre ambos hubs, demostrando assim, um relacionamento do negócio no sistema de origem.

• l_empregados_pedidos.

E por fim, vemos que criamos dois satélites, que dão contextos através dos atributos para os hubs e links:

• s_empregados;
• s_l_empregados_pedidos.

E em questão do ETL?

Bom o ETL é bem simples e performático, eu desenvolvi alguns fluxos utilizando Pentaho Data Integration (que ajuda e muito) para demonstrar aqui no blog, como funciona o processo um para cada tipo de tabela.

Tabela Hub:

Fluxo de ETL para Hubs

A tabela de hub é o fluxo mais simples que tem, já que não tem necessidade de realizar lookups.

Basicamente, o fluxo está conectado em duas fontes de dados distintas, uma na minha origem e outra em meu DV. Com isso, é realizado uma junção de ambos, e verificado somente onde o DV possui a chave nula, exatamente no step de Filter rows, ou seja, só passa para as etapas seguintes, se o DV não possuir a chave de origem. E ao fim, seta as variáveis de LDTS e RSRC, para assim armazenar o hub.

O interessante que, para qualquer hub que irá compor o DV, o fluxo é o mesmo e nunca muda, basta alterar os steps (quadradinhos) para cada necessidade.

Tabela de Link:

Fluxo de ETL para Links

A ideia para o fluxo de Link é a mesma de Hub, porém, ao invés de verificar se as chaves são existentes, verificamos se o relacionamento já existe no Link. Caso o devido relacionamento exista ele não irá prosseguir, porém, se ele não existir, seguirá o fluxo normalmente com um acréscimo. Os processos de ETL para os Links possuem Lookups, que são valores de retorno para preencher a tabela. No caso destes steps de Lookups, vemos que está fazendo uma verificação para o retorno da chave dos Hubs de Pedido de Empregado, que retornaram suas Business Key, e armazenaram ao final, realizando assim, o devido relacionamento de negócio.

Assim como no hub, o fluxo nunca muda, a não ser o fato de que possa ter mais de duas ligações entre hubs, necessitando assim adicionar mais steps de Lookups no fluxo, e claro, realizando as devidas configurações para cada step.

Tabela de Satélite:

Fluxo de ETL para Satélites

Com a mesma ideia dos fluxos anteriores, devemos conectar a nossa origem e nosso DV, porém podemos perceber que existe um passo antes da ordenação. Esse step em especial, cria um variável para identificar se ocorreu alguma mudança ou não na linha do registro, pois essas variáveis criadas, serão utilizadas para verificarmos se ocorreu atualização ou não. Quando realizada a junção, as variáveis padrões para o DV já são integradas e a primeira verificação já ocorre. O step de Filter Rows denominado Novo ou Antigo? possui o papel de identificar se o registro já está ou não no satélite. Caso esse registro não exista, ele recuperará a Business Key do Hub e armazenará um novo registro, caso contrário, ele verifica se possui atualização para o determinado registro, se a atualização der positivo, então ele atualizará a versão anterior do satélite e incluirá a nova.

Por fim…

Podemos automatizar essas rotinas, incluindo elas em um Job do Pentaho, e agendarmos sua periodicidade.

Job de Hubs

Claro que na imagem faltaria os links e satélites para serem adicionados, porém, a ideia é termos um Job para cada tipo de tabela do DV, e um job centralizador para realizar a chamada destes outros jobs.