No artigo anterior, falei sobre os fundamentos do DATA VAULT, descrevi os principais elementos do DATA VAULT e sua finalidade. Este não pode ser considerado o tema DATA VAULT esgotado, é necessário falar sobre os próximos passos na evolução do DATA VAULT.
E neste artigo vou focar no desenvolvimento do DATA VAULT e na transição para BUSINESS DATA VAULT ou simplesmente BUSINESS VAULT.
Razões para o aparecimento do BUSINESS DATA VAULT
Deve-se notar que o DATA VAULT, embora tenha certos pontos fortes, tem suas desvantagens. Uma dessas desvantagens é a dificuldade em escrever consultas analíticas. As consultas possuem um número significativo de JOINs, o código é longo e complicado. Além disso, os dados que entram no DATA VAULT não sofrem nenhuma transformação, portanto, do ponto de vista empresarial, o DATA VAULT em sua forma pura não tem valor absoluto.
Foi para eliminar estas deficiências que a metodologia DATA VAULT foi ampliada com elementos como:
- Tabelas PIT (ponto no tempo);
- Mesas BRIDGE;
- DERIVAÇÕES PREDEFINIDAS.
Vamos dar uma olhada mais de perto no propósito desses elementos.
Tabelas de IRPF
Normalmente, uma entidade empresarial (HUB) pode conter dados com diferentes taxas de atualização, por exemplo, se estamos falando de dados que caracterizam uma pessoa, podemos dizer que informações sobre um número de telefone, endereço ou e-mail têm uma taxa de atualização maior do que, digamos, nome completo, dados do passaporte, estado civil ou sexo.
Portanto, ao determinar os satélites, você deve ter em mente a frequência de atualização deles. Por que isso é importante?
Se você armazenar atributos com taxas de atualização diferentes na mesma tabela, terá que adicionar uma linha à tabela sempre que o atributo alterado com mais frequência for atualizado. O resultado é um aumento no espaço em disco e no tempo de execução da consulta.
Agora que dividimos os satélites por frequência de atualização e podemos carregar dados neles de forma independente, devemos garantir que podemos receber dados atualizados. Melhor, sem usar JOINs desnecessários.
Deixe-me explicar, por exemplo, você precisa obter informações atuais (de acordo com a data da última atualização) de satélites que possuem taxas de atualização diferentes. Para fazer isso, você precisará não apenas fazer um JOIN, mas também criar várias consultas aninhadas (para cada satélite contendo informações) com a seleção da data máxima de atualização MAX (Update Date). A cada novo JOIN, esse código cresce e rapidamente se torna difícil de entender.
A tabela PIT foi projetada para simplificar essas consultas; as tabelas PIT são preenchidas simultaneamente com a gravação de novos dados no DATA VAULT. Tabela PIT:
Assim, temos informações sobre a relevância dos dados para todos os satélites em cada momento. Utilizando JOINs para a tabela PIT, podemos eliminar completamente as consultas aninhadas, naturalmente com a condição de que o PIT seja preenchido todos os dias e sem lacunas. Mesmo que haja lacunas no PIT, você poderá obter os dados mais recentes usando apenas uma consulta aninhada no próprio PIT. Uma consulta aninhada será processada mais rapidamente do que consultas aninhadas para cada satélite.
PONTE
As tabelas BRIDGE também são usadas para simplificar consultas analíticas. Porém, o que difere do PIT é uma forma de simplificar e agilizar as solicitações entre diversos hubs, links e seus satélites.
A tabela contém todas as chaves necessárias para todos os satélites, que são frequentemente utilizadas em consultas. Além disso, se necessário, as chaves comerciais com hash podem ser complementadas com chaves em formato de texto se os nomes das chaves forem necessários para análise.
O fato é que sem utilizar o BRIDGE, no processo de recepção de dados localizados em satélites pertencentes a diferentes hubs, será necessário fazer um JOIN não só dos próprios satélites, mas também dos links que conectam os hubs.
A presença ou ausência do BRIDGE é determinada pela configuração de armazenamento e pela necessidade de otimizar a velocidade de execução da consulta. É difícil encontrar um exemplo universal de BRIGE.
DERIVAÇÕES PREDEFINIDAS
Outro tipo de objeto que nos aproxima do BUSINESS DATA VAULT são as tabelas contendo indicadores pré-calculados. Essas tabelas são muito importantes para os negócios, pois contêm informações agregadas de acordo com determinadas regras e tornam seu acesso relativamente fácil.
Arquitetonicamente, DERIVAÇÕES PREDEFINIDAS nada mais são do que mais um satélite de um determinado hub. Ele, como um satélite normal, contém uma chave comercial e a data de criação do registro no satélite. É aqui que as semelhanças terminam, no entanto. A composição adicional dos atributos de tal satélite “especializado” é determinada pelos usuários empresariais com base nos indicadores pré-calculados mais populares.
Por exemplo, um hub contendo informações sobre um funcionário pode incluir um satélite com indicadores como:
- Salário mínimo;
- Salário máximo;
- Salário médio;
- Total acumulado de salários acumulados, etc.
É lógico incluir DERIVAÇÕES PREDEFINIDAS na tabela PIT do mesmo hub, então você pode obter facilmente fatias de dados para um funcionário em uma data especificamente selecionada.
CONCLUSÕES
Como mostra a prática, o uso do DATA VAULT por usuários empresariais é um tanto difícil por vários motivos:
- O código de consulta é complexo e complicado;
- A abundância de JOINs afeta o desempenho das consultas;
- Escrever consultas analíticas requer excelente conhecimento de design de armazenamento.
Para simplificar o acesso aos dados, o DATA VAULT é estendido com objetos adicionais:
- Tabelas PIT (ponto no tempo);
- Mesas BRIDGE;
- DERIVAÇÕES PREDEFINIDAS.
Próximo Pretendo contar, na minha opinião, o que há de mais interessante para quem trabalha com BI. Apresentarei maneiras de criar tabelas de fatos e tabelas de dimensões baseadas em DATA VAULT.
Os materiais do artigo são baseados em:
- На Kenta Graziano, que, além de uma descrição detalhada, contém diagramas modelo;
- Livro: “Construindo um Data Warehouse Escalável com DATA VAULT 2.0”;
- Artigo .
Fonte: habr.com