Data Vault: Como Usar – Errata

Meu grande amigo e co-autor do PnP, Cesar Domingos, me mandou um e-mail com duas dúvidas:

Fala Fábio,

Tudo bem?

Tô vendo uns posts seus sobre Data Vault e fiquei com dúvida em um.

https://geekbi.wordpress.com/2016/05/25/data-vault-como-usar/

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?

Abraços,

Cesar Domingos
Vida corrida de Cesar Domingos
Consultor Linux e BI
LPIC-3 e RHCE

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.
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.
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. ;-)

Anúncios

O Que É Data Discovery – Interregno

Esta não é a parte dois da série, mas apenas um comentário no meio.

Recentemente foi lançado um livro sobre QlikView. Excelente notícia, já que conhecimento destilado é o combustível do sucesso. Sendo um autor, eu valorizo ainda mais pois sei do trabalho inclemente e ingrato que é escrever um livro. Parabéns ao autor!

O que eu achei interessante, e muito pertinente na discussão em busca da resposta à pergunta “o que é DD?”, é que o site destaca um capítulo como mais importante. Veja na figura:

Conteúdo do livro sobre QlikView.
Conteúdo do livro sobre QlikView.

Viram lá, no capítulo 3? “O segredo” de um app Qlik Sense é (rufem os tambores) a carga dos dados, transformações e modelos.

Hmm… Como é? Li corretamente? O segredo está na preparação dos dados?

Estou sendo chato, eu já sabia disso. Na verdade, esse detalhe sempre foi bem propagandeado: ele usa uma ferramenta interna, tipo linguagem script, para extrair, transformar e carregar em memória os dados. O que a propaganda não reforça é a importância que isso tem: o livro Qlik for Developers explica que quanto mais arrumados os dados estiverem, melhor e mais fáceis serão os resultados.

O presente lançamento reforça isso.

Que conclusão tiramos? Ora, que se você quer explorar seus dados, faça um favor a você mesmo: invista em um DW.

“Ah, mas DW são velharias, é um conceito fracassado, dá muito trabalho e nenhum resultado etc. etc. etc.”

É mesmo? Permita-me e re-frasear: se você não tem um bom modelo de dados, cedo ou tarde vai ter que construir um – seja com uma ferramenta especialista, como ODI ou PDI, seja com uma linguagem script (ai, ai…) Não importa como: no final, são os dados que importam e são eles que terão que ser tratados. Não é a ferramenta, são os dados.

Os dados.

É isso. ;-)

Introdução à Data Vault

Toda empresa que deseja usufruir das vantagens que projetos de Inteligência de Negócios trazem (como incremento de lucros), precisa investir concomitantemente em Armazéns de Dados.

O primeiro passo é decidir o que se deseja: oferecer relatórios, análises, uma solução do tipo CRM ou Churn etc. Essa escolha vai determinar quais dados são necessários. Esses dados devem ser levados para um Armazéns de Dados (ou DW, do inglês Data Warehouse)  antes de ser consumidos pelo projeto de BI.

Armazéns de Dados são bancos de dados, em qualquer tecnologia, que acumulam os dados da empresa. Um DW, em princípio, acumula todos os dados que a empresa julgar importantes hoje, como aqueles necessários para o projeto de BI, ou acreditar que possam vir a ser importantes no futuro. Os dados são armazenados no DW em sua menor granularidade, para que qualquer pergunta possa ser respondida.

Cada solução de BI implantada na empresa consome dados em formatos específicos. Por exemplo, relatórios e análises OLAP funcionam melhor se os dados estiverem organizados em um Modelo Dimensional. Já uma solução de CRM consome dados em formato “tabelão”, que são adequados a Data Mining. Painéis podem usar os dados de uma estrela dimensional, mas eventualmente pode ser mais producente usar tabelas especiais – simplificam a lógica nos painéis e tendem a reduzir o consumo de hardware. E assim por diante.

Observe sua vida: você usa uma só máquina para tudo? O seu carro passa fax? O seu fax corta grama? O seu barbeador bate bolo? Não, claro. (Caso sua resposta para uma destas perguntas seja sim, entre em contato comigo – vamos ficar ricos!!)

Da mesma forma que no mundo real, o mundo informatizado também usa programas e tecnologias específicas: banco de dados não serve HTTP, Java armazena dados, PHP não oferece cubos OLAP.

Armazéns de Dados não servem para consultas – servem para armazenar dados. Logo, o primeiro erro que precisamos evitar é “one size fits all”: uma tecnologia desenvolvida para resolver um problema não serve para resolver qualquer problema, muito menos todos.

Data Vault

Uma tradução livre do termo é Cofre de Dados: uma tecnologia adequada a acumular dados ao longo do tempo. A partir deste repositório de dados, outros projetos podem se servir do que precisar.

A idéia central de se ter um Data Vault é dispor de um repositório que receba e organize os dados de múltiplas fontes, de tal forma que seja muito fácil incluir ou remover fontes, sem quebrar o repositório e sem virar um pesadelo de manutenção. A partir daí, cada projeto de BI busca do DV os dados que precisa e grava-os em outros repositórios de dados, no formato que precisar.

Apesar de soar como uma camada desnecessária, aparentemente dobrando o esforço (com DV precisamos de dois ETLs no mínimo – um para dentro e outro para fora do DV), adotar um Data Vault reduz o trabalho porque torna o crescimento do DV algo semi-automático, e a criação de fontes secundárias algo padronizado.

Veremos a seguir um DV: seus componentes e como um é modelado. Tudo que será visto pode ser encontrado nos livros abaixo:

Beltrano S/A

Para os exemplos vamos usar o diagrama de dados do banco transacional da Beltrano S/A:

Modelo E-R da aplicação transacional.
Modelo E-R da aplicação transacional.

Leia este link para todos os detalhes sobre a base.

O Modelo de Dados

Um DV tem três componentes básicos:

  1. Hub
  2. Link
  3. Satélite

E mais algumas tabelas acessórias:

  1. Point-In-Time (PIT)
  2. Same-As
  3. Tabelas “dicionário”

Não vou entrar no detalhe das tabelas acessórias, pois elas resolvem problemas específicos que não são necessários para entender o mecanismo geral.

Hub

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:

  1. Business Key: chave primária, um inteiro sequencial;
  2. Load Date/Timestamp: data e hora da inserção do registro;
  3. Record Source: fonte da chave de negócios;
  4. Source business key: chave de negócio no sistema de origem.
DV Beltrano S/A: hub Empregados.
DV Beltrano S/A: hub Empregados.

Não há grandes segredos aqui: tabelas hubs acumulam as chaves de negócio, que são a espinha dorsal dos dados. 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.

Se a mesma chave existe em vários sistemas, com os mesmos valores, essa tabela automaticamente integra esses sistemas. Por outro lado, se a mesma chave existe em sistemas diferentes, mas com valores diferentes diferentes, então elas devem ser carregadas em hubs separados por sistema. A integração é feita por uma tabela do tipo Same-As entre cada hub.

Eventualmente a chave de negócio no sistema de origem podem ser uma chave composta (ter mais de uma coluna), mas nunca podemos montar como chave de negócio as colunas 3 e 4.

Link

Links tão tabelas que guardam o relacionamento entre dois hubs.

Uma tabelas link que relaciona os hubs 1, 2, … , n possuem as seguintes colunas, nem mais, nem menos:

  1. Link Key: chave primária, um inteiro sequencial;
  2. Load Date/Timestamp: data e hora da inserção do registro;
  3. Record Source: fonte do relacionamento;
  4. BK1: business key do hub 1;
  5. BK2: business key do hub 2;
  6. BKn: business key do hub n.
DV Beltrano S/A: link Empregados-Pedidos.
DV Beltrano S/A: link Empregados-Pedidos.

Uma tabela link mantém relacionamentos M para M entre os hubs. Elas não dizem nada sobre a validade desse relacionamento, mas apenas que ele foi detectado no sistema de origem. Uma tabela link pode manter auto-relacionamentos também: um hub empregado, quando um empregado é chefe do outro, usa uma tabela link para registrar o relacionamento pai-filho entre os empregados.

Ela também não sofre atualização: novos relacionamentos são inseridos, antigos são descartados. Se um relacionamento já registrado não é mais detectado, ele não é apagado.

Satélite

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:

  1. Business Key/Link key: chave primária do hub/link
  2. Load Date/Timestamp: data e hora da inserção do registro;
  3. Load End Date/Timestamp: data e hora do fim da validade daquele registro (default é NULO);
  4. Record Source: fonte dos atributos;
  5. A1: atributo 1;
  6. A2: atributo 2;
  7. An: atributo n.
DV Beltrano S/A: satélite Empregados.
DV Beltrano S/A: satélite Empregados.

Ao contrário do hub e link, o satélite não tem uma chave primária própria. Ao invés disso a chave primária é composta pelas colunas 1 e 2 (BK/LK + LDTS.)

De novo ao contrário dos hubs/links, os registros de um satélite possuem validade: a cada carga o processo verifica se os registros do satélite ainda existem na origem. Se não existirem mais, eles recebem um date/timestamp atual na coluna 3 (LEDTS.) A cada carga os satélites mudam e desta forma acumulam histórico do sistema.

DV Beltrano S/A: satélite do link Empregados-Pedidos, que guarda a validade do link.
DV Beltrano S/A: satélite do link Empregados-Pedidos, que guarda a validade do link.

Os atributos de uma chave de negócio ou relacionamento não precisam estar totalmente contidos em uma única tabela: se os atributos variam em taxas diferentes (como quando alguns mudam todos os dias, enquanto outros apenas de vez em quando), eles podem ser gravados em tabelas diferentes.

Quando um mesmo conceito de negócio existe em dois sistemas, criamos um satélite para cada sistema, com cargas independentes.

Corpo

Hubs são conceitos de negócios, links relacionam estes conceitos entre si e os satélites dão o contexto dessas chaves e relacionamentos.

DV Beltrano S/A: modelo captura que empregado fez que pedido.
DV Beltrano S/A: modelo captura que empregado fez que pedido.

Se compararmos um DV a um corpo humano, os hubs são como ossos, formando um esqueleto, links são ligamentos que unem os ossos e satélites são todos os músculos, orgãos e pele que recobre o esqueleto, dando-lhe forma.

Ah! Existe um código de cores: hubs são azuis, links vermelhos e satélites são amarelos.

As Vantagens de um Data Vault

Um DV oferece três vantagens:

  1. Estabilidade e Isolação
  2. Repetibilidade
  3. Performance

Estabilidade

Basta deter-se um pouco sobre essas explicações e perceber que, se a empresa não muda constantemente de ramo, seus conceitos de negócios são relativamente estáveis. Ou seja, mesmo que a empresa mude a forma como ela processa sua vida diária, poucos conceitos de negócio vão nascer ou sumir ao longo do tempo. Mesmo assim, um novo conceito de negócio é imediatamente associado a um novo hub. A implementação desse novo hub não afeta os que já existem – o impacto por uma novidade em termos de conceito de negócio é zero.

Os relaciomentos entre dois conceitos também são, via de regra, estáveis. Pense em produto e fornecedor: podem surgir novos fornecedores (inseridos num hub “fornecedor”), com novos produtos (inseridos num hub “produto”), ou mesmo novos produtos de um fornecedor já existente. Quando isso acontece, o próprio processo de carga se encarrega de anotar esse relaciomento, automaticamente. Se um novo relacionamento é descoberto, porém, o impacto no DV é zero: basta criar a nova tabela link e produzir o código de carga dela. Nenhuma outra tabela do DV é afetada. Ah, e se um relacionamento “morrer”, basta desativar a carga para ele, e para seus satélites – sem NENHUM impacto no restante do Cofre de Dados.

Já os satélites, que são naturalmente mais voláteis, podem mudar de forma com certa frequência. Digamos que, hoje, o DV coleta todos os hipotéticos atributos do cliente. Algo acontece – inventam um novo tipo de e-mail – e passamos a registrar, no sistema de origem, mais esse atributo. Qual é o impacto disso no DV? A resposta é “depende”:

  1. O caminho mais fácil é simplesmente criar um novo satélite com apenas esse atributo e instalar o novo processo de carga para ele. Impacto zero, mas o custo de recuperar essa informação depois pode ficar muito alto, especialmente se formos preguiçosos o tempo todo. A título de curiosidade, essa abordagem leva a uma coisa chamada Anchor Modeling;
  2. O segundo caminho mais fácil é estancar o satélite atual, mudando seu nome para alguma coisa _ate_data-X,  e criar um novo satélite com o novo atributo, e passar a carregá-lo daí em diante. É uma técnica mais interessante em situações que mais do que um par e tal de novis atributos precisam ser capturados. A derivação dos dados para as fontes secundárias precisa levar em conta as diversas versões da tabela, mas o impacto no DV é próximo a zero;
  3. Finalmente podemos simplesmente aumentar o satélite atual em uma coluna e atualizar a carga dele para levar esse novo atributo. A vantagem é que você mantém o mesmo número de tabelas que existia antes, mas agora seu processo de extração pós-DV precisa saber que esse atributo não vão existir em todas as versões de cada registro do satélite. Impacto para o DV: próximo a zero também.

Repare que o DV tem um impacto na sua atualização, mas esse impacto não se propaga para fora dele: em qualquer um dos casos listados acima, a extração de dados do DV para fontes de dados secundárias não sofre NENHUMA alteração. Mesmo nas opções que mudam as tabelas dos satélites (é indiferente o que acontece aos hubs e links), as alterações vão de nada (ignorar a nova tabela/coluna) a pouca (mudar o nome de uma tabela.)

Veja que se queremos que o novo atributo “saia” para as fontes secundárias, então o impacto vai ser maior.

Lido ao contrário fica:

A incorporação de novas fontes de dados ao Data Vault não perturba os processos de carga das fontes de dados derivadas: o DV pode ser evoluído com um impacto próximo ao desprezível para a carga dos data marts dimensionais, tabelas de painéis etc.

Isolação

Isso é perfeito para DWs que servem mais de um departamento (praticamente todos): mudanças requeridas por um departamento tem impacto desprezível a nulo nos produtos de BI de outros departamentos.

Repetibilidade

Um Cofre de Dados é montado com “pedaços” (tabelas) padronizados. Cada tipo de pedaço – hub, link ou satélite – segue um modelo (um template ou gabarito) e tem um processo de carga idêntico. Para cada nova tabela mudam-se coisas como chaves de negócio ou atributos, mas o processo em si, de desenhar o DV e seu ETL, é 100% repetitivo. Isso significa que criar um novo hub/link/satélite e seu processo de carga é o mesmo que copiar um outro elemento do mesmo tipo já pronto, e mudar os nomes das colunas e tabelas.

Em outras palavras:

O layout das tabelas e o processo de ETL para um Data Vault é 100% baseado em templates. A geração do processo de ETL pode ser automatizada ao ponto de um novo hub/link/satélite poder ser incluído no modelo e colocado em produção em menos de uma hora.

O tempo acima não é um chute: eu brinquei com um sistema real e descobri que consigo criar um hub em menos de 15 minutos, um link em menos de 20 e um satélite em menos de uma hora. O satélite leva muito mais tempo porque tem um número variável de colunas, e isso dá um trabalho extra para testar (a criação mesmo, de todos, é de cinco minutos – o resto é tempo desenho para saber que colunas usar e testar o resultado.)

Performance

O conceito de Data Vault foi feito tendo em mente a idéia de se aproveitar de capacidades de processamento paralelo massivo – MPP. Graças à sua arquiteturua, cada tipo de elemento de um DV podem ser carregados 100% em paralelo: podemos carregar todos os hubs ao mesmo tempo, todos os links ao mesmo tempo e todos os satélites ao mesmo tempo.

Graças a bancos de dados capazes de se espalhar em diversos servidores, e programas de ETL como o Pentaho Data Integration que pode escalonar elasticamente por inúmeras máquinas, o gargalo de carga de um Data Vault passa a ser a própria velocidade de rede e computadores – melhorando esses, reduzimos o tempo de carga

Data Vault 2.0 & BigData

Tudo que este post aborda vem da especificação 1.0 do Data Vault. A especificação do DV 2.0 troca as chaves sequenciais por hashes, o que permite carregar 100% dos elementos em paralelo. Graças à eliminação da dependência de um campo sequencial, um DV 2.0 é adequado para criar DWs diretamente em clusters Hadoop.

A Regra de Ouro do Data Vault

Daniel Linstedt define como a regra de ouro do DV

Carregar 100% dos dados, 100% das vezes

Ele diz, nas apresentações, que chega de chamadas do Centro de Dados de madrugada, avisando que a carga do DW parou. Chega de perder o sono por falhas causadas por dados mal-formatados. Um DV carrega tudo, da forma que vier. Como diz o cowboy, “eu carrego antes e limpo depois”. Bam! Bam! :-)

Conclusão

Sólidos projetos de BI de qualidade constroem-se sobre Armazém de Dados. A melhor tecnologia para construção de um DW é aquela que reduz seu custo e tempo de desenvolvimento, reduz retrabalho e aumenta sua performance.

Data Vault é um modelo de dados criado por Daniel Linstedt em 2000 que atende a todas essas necessidades. A versão 2.0 da especificação traz melhorias que permitem construir um DW diretamente em um cluster Hadoop e com isso baratear ainda mais o processo e a infraestrutura, enquanto aumenta sua performance.

Um Data Vault é o ponto final de um DW, mas um DW é só o ponto de partida para projetos de BI, que devem extrair seus dados do DW, no formato que desejarem, como bem entenderem.

É isso.