No artigo anterior, falei sobre os fundamentos do DATA VAULT, descrevi os principais elementos do DATA VAULT e suas funções. No entanto, isso não exaure o tema DATA VAULT; é necessário discutir as próximas etapas da evolução do DATA VAULT.
Neste artigo, concentrarei-me no desenvolvimento do DATA VAULT e na transição para o BUSINESS DATA VAULT ou simplesmente BUSINESS VAULT.
Razões para o surgimento do BUSINESS DATA VAULT
É importante notar que, embora o DATA VAULT tenha certas vantagens, também apresenta desvantagens. Uma dessas desvantagens é a complexidade na escrita de consultas analíticas. As consultas têm uma quantidade significativa de JOINs, resultando em código longo e complicado. Além disso, os dados que entram no DATA VAULT não são submetidos a nenhuma transformação, portanto, do ponto de vista do negócio, o DATA VAULT em sua forma pura não possui valor absoluto.
Foi precisamente para eliminar essas desvantagens que a metodologia DATA VAULT foi expandida com elementos como:
- tabelas PIT (point in time);
- tabelas BRIDGE;
- DERIVAÇÕES PREDEFINIDAS.
Vamos examinar mais detalhadamente a função desses elementos.
Tabelas PIT
Normalmente, um objeto de negócio (HUB) pode conter dados com diferentes frequências de atualização. Por exemplo, se falarmos sobre dados que caracterizam uma pessoa, podemos afirmar que informações sobre número de telefone, endereço ou e-mail têm uma frequência de atualização mais alta do que, digamos, nome completo, dados do passaporte, estado civil ou sexo.
Portanto, ao determinar os satélites, deve-se considerar a frequência de suas atualizações. Por que isso é importante?
Se armazenarmos atributos com diferentes frequências de atualização em uma única tabela, será necessário adicionar uma linha na tabela a cada atualização do atributo que muda mais com frequência. Como consequência, teremos um aumento no volume de espaço em disco e um aumento no tempo de execução das consultas.
Agora que dividimos os satélites de acordo com a frequência de atualização, e podemos carregar dados neles independentemente, é necessário garantir a possibilidade de obter dados atualizados. É melhor, sem o uso excessivo de JOINs.
Por exemplo, é necessário obter informações atualizadas (com base na data da última atualização) de satélites que têm diferentes frequências de atualização. Para isso, não basta fazer um JOIN, mas também criar várias subconsultas (para cada satélite contendo informações) escolhendo a data máxima de atualização MAX(Data de Atualização). Com cada novo JOIN, esse código cresce rapidamente e se torna difícil de entender.
A tabela PIT foi criada para simplificar tais consultas; as tabelas PIT são preenchidas simultaneamente com a inserção de novos dados no DATA VAULT. Tabela PIT:
Assim, temos informações sobre a relevância dos dados de todos os satélites em cada momento no tempo. Usando JOINs com a tabela PIT, podemos eliminar completamente as subconsultas, desde que a PIT seja preenchida diariamente e sem lacunas. Mesmo se houver lacunas na PIT, é possível obter dados relevantes utilizando apenas uma subconsulta para a própria PIT. Uma subconsulta funcionará mais rapidamente do que subconsultas para cada satélite.
BRIDGE
As tabelas do tipo BRIDGE também são utilizadas para simplificar consultas analíticas. No entanto, diferentemente da PIT, elas servem para agilizar as consultas entre diferentes hubs, links e seus satélites.
A tabela contém todas as chaves necessárias para todos os satélites, que são frequentemente usadas nas consultas. Além disso, se necessário, as chaves de negócios hash podem ser complementadas por chaves em formato textual, se os nomes das chaves forem necessários para análise.
O fato é que, sem o uso de BRIDGE, ao obter dados de satélites pertencentes a diferentes hubs, será necessário realizar JOIN não apenas entre os satélites, mas também entre os links que conectam os hubs.
A presença ou ausência de BRIDGE é determinada pela configuração do repositório e pela necessidade de otimizar a velocidade de execução das consultas. É difícil inventar um exemplo universal para BRIDGE.
DERIVAÇÕES PREDEFINIDAS
Outro tipo de objeto que nos aproxima do BUSINESS DATA VAULT são as tabelas que contêm métricas pré-calculadas. Essas tabelas são realmente importantes para os negócios, pois contêm informações agregadas de acordo com regras estabelecidas e permitem o acesso a elas de forma relativamente simples.
As Derivações PREDEFINIDAS arquiteturalmente representam, nada mais, do que mais um satélite de um determinado hub. Ele, assim como o satélite comum, contém a chave do negócio e a data de criação do registro no satélite. No entanto, aqui as semelhanças terminam. A composição adicional dos atributos desse "satélite especializado" é determinada pelos usuários de negócios com base nos indicadores mais requisitados e previamente calculados.
Por exemplo, um hub contendo informações sobre um funcionário pode incluir um satélite com os seguintes indicadores:
- Salário mínimo;
- Salário máximo;
- Salário médio;
- Total acumulado de salários e assim por diante.
É lógico incluir as DERIVAÇÕES PREDEFINIDAS na tabela PIT desse mesmo hub, assim é possível obter sem esforço cortes de dados sobre o funcionário em uma data específica.
CONCLUSÕES
Como mostra a prática, o uso do DATA VAULT pelos usuários de negócios é um tanto complicado por várias razões:
- O código das consultas é complexo e volumoso;
- A abundância de JOINs afeta a performance das consultas;
- Para escrever consultas analíticas é necessário um conhecimento excepcional da estrutura do repositório.
Para simplificar o acesso aos dados, o DATA VAULT é ampliado com objetos adicionais:
- tabelas PIT (point in time);
- tabelas BRIDGE;
- DERIVAÇÕES PREDEFINIDAS.
Na próxima Eu planejo compartilhar, 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 com base no DATA VAULT.
Os materiais do artigo são baseados em:
- Sobre Kenta Graziano, que, além de uma descrição detalhada, contém esquemas do modelo;
- No livro: "Construindo um Armazém de Dados Escalável com DATA VAULT 2.0";
- Artigo .
Fonte: habr.com
