Usos do design de modelagem de cofre de dados
- Claude Paugh
- 2 de mai.
- 9 min de leitura
Atualizado: 26 de jun.
O Data Vault é, na verdade, um paradigma de design, e não uma tecnologia. Pode ser usado em qualquer banco de dados relacional ou datalake. Surgiu do desejo de encontrar uma maneira melhor de armazenar dados e se distanciar dos designs de esquema estrela/cluster/constelação e floco de neve (não da empresa de banco de dados) que são frequentemente usados em data warehouses.
Mas, ao fazê-lo, oferece um padrão diferente que realmente exclui, ou pelo menos limita, os usuários finais da equação. Pode ser difícil consultar usuários finais, e a organização de entidades não é intuitiva. Pode substituir um warehouse ou armazenamento de dados operacionais, se o público-alvo for engenheiros e não usuários finais. Definitivamente, não substitui um Data Mart.
Por que fugir disso? Eles não funcionam? Como muitas coisas no setor de tecnologia, a resposta para "funcionar" ou não depende do caso de uso. Qual é o propósito e a função para os quais você pretende usá-los? Os atores que participam das funções de consumidor e produtor geralmente determinam os parâmetros do caso de uso, ou seja, onde estão o foco e os limites.
No caso das variações dos esquemas em estrela que mencionei acima, o foco do caso de uso são os usuários finais. Eles acessam os dados de forma ad hoc usando ferramentas e consultas interativas ou também consomem os relatórios produzidos. Para dar uma ideia visual do esquema acima, apresento um diagrama em estrela simples abaixo. As três tabelas na parte superior são os dados de origem do esquema em estrela, destacados em verde.
As variações são mostradas no diagrama a seguir, exceto para o floco de neve. O Snowflake basicamente adiciona tabelas de referência adimensionais ao diagrama abaixo, que, na maioria dos casos, estão relacionadas a dimensões. Por exemplo, tabelas de vários tipos para categorizar dados dentro de dimensões. Pense nos tipos de remessa (aérea, terrestre, marítima) e nas características de cada uma.
Estrela: Um fato com muitas dimensões
Aglomerado Estelar - Fatos Múltiplos com Dimensões
Constelação Estelar: Vários Fatos e Dimensões Relacionados
Como você provavelmente pode inferir, todos esses três designs estão focados em criar e fornecer análises aos consumidores, seja uma ferramenta interativa usando consultas ou relatórios.
Nos bastidores, do ponto de vista do usuário final, há uma grande quantidade de depuração e transformação da qualidade dos dados para poder gravar dados nas tabelas de dimensão (Dim). Isso antes de você começar a preencher as análises nas tabelas de fatos (Facts).
Como todas as dimensões e fatos usam chaves "burras" ou substitutas, o que é praticamente padrão no design de mercados e armazéns, existe a possibilidade de criar duplicatas. Isso ocorre porque há casos de uso em que duplicatas são válidas, e esse padrão de design de chave substituta acomoda isso. Isso é particularmente útil quando se utilizam dados de séries temporais, já que os valores de carimbo de data/hora podem ser os mesmos, mas a sequência os diferencia.
Qualidade de dados
Os controles de qualidade dos dados precisam ser precisos, caso contrário, é fácil que "distorções" infestem seus dados. Se você estiver executando modelos de ML a partir de dados distorcidos, eles se desviarão e não fornecerão os resultados esperados. Ocorrências excessivas de desvio geralmente indicam problemas de qualidade dos dados ou sensibilidade do modelo de ML. Este é, pelo menos em parte, um dos benefícios do uso dos padrões de design do Data Vault: eles evitam duplicatas e garantem a exclusividade de certas classificações de dados para ajudar a reduzir o esforço de qualidade dos dados. Em teoria, isso deveria ser uma ajuda adicional para prevenir o problema de desvio.
Seu único aspecto, a exclusividade, não aborda especificamente a validação do conteúdo dos dados. Por exemplo, se uma coluna deve ter apenas valores com 9 caracteres alfanuméricos, você precisa de validação ou se uma coluna está restrita a uma lista de valores, você ainda precisa inspecionar. Os tipos mais comuns de validação de qualidade de dados (IMO) são a inspeção de valores em colunas devido a restrições: comprimento, tipo de dado, número de palavras, etc. Se todas as suas fontes de dados forem um banco de dados relacional com restrições aplicadas às colunas, o trabalho de qualidade de dados será muito mais fácil. Mas isso é muito raro.
Os dados são provenientes de formatos estruturados, semiestruturados e não estruturados. Portanto, pode-se dizer que os utilitários de inspeção têm uma longa vida útil. Usar expressões regulares, ou regex, em diversas formas, de scripts Python a SQL, é bastante comum para quem precisa construir uma solução "caseira". Existem diversas estruturas e utilitários de validação de dados em Python, como Pydantic e Cerberus, para citar alguns. Muitas ferramentas de qualidade de dados existiram ao longo dos anos, mas parecem ter se tornado obsoletas e, como resultado, foram adquiridas por empresas muito maiores e integradas aos seus produtos. Informatica , IBM , SAS e Ab Initio têm sido compradoras de produtos de qualidade de dados e inteligência de negócios nas últimas duas décadas.
As outras verificações de qualidade de dados mais comuns são as contagens de registros, basicamente para verificar se as entradas e saídas correspondem durante o carregamento. É uma das poucas verificações genéricas de qualidade de dados que você pode fazer, pois, ao iniciar transformações nos seus dados, contagens específicas desaparecem. Você precisa de um perfil da relação entrada/saída da transformação para poder calcular qual intervalo de contagens os resultados da transformação podem ter. Como mencionei antes, um fator na criação do Data Vault foi a qualidade dos dados, mas existem vários outros.
Cofre de Dados
É descrito por seu criador, Dan Linstedt , como "um conjunto de tabelas normalizadas, orientadas a detalhes, com rastreamento histórico e vinculadas de forma única, que suportam uma ou mais áreas funcionais. É uma abordagem híbrida que abrange o melhor da terceira forma normal (3NF) e o esquema em estrela". Segundo Dan, foi inspirado por uma visão simplista de neurônios, dendritos e sinapses.
Existem vários benefícios citados ou alegados do Data Vault, incluindo o fato de que todos os relacionamentos são orientados por chaves e o padrão de design pode ser escalonado para bancos de dados de vários petabytes (PB). O Data Vault é um exemplo de modelagem de âncora, que é uma abordagem ágil para modelagem de dados, permitindo capturar alterações sem necessariamente ter um impacto generalizado no modelo existente. Ele também é orientado por processos de negócios, o que, idealmente, um esquema em estrela e suas variações também deveriam ser.
A metodologia de modelagem é semelhante à criação de modelos de dados de entidade-relacionamento: crie um modelo lógico que represente o processo de negócios e os elementos de dados nele envolvidos. O Data Vault é uma abordagem altamente normalizada para a criação de um modelo baseado em entidade, o que proporciona grande parte da sua flexibilidade, já que não há repetição de elementos de dados em todo o esquema.
Outro benefício dessa prática de modelagem é que ela garante total auditabilidade e rastreabilidade. Também está em conformidade com o SEI CMM Nível 5 (arquitetura repetível, consistente e redundante) e fornece modelos em conformidade com Sarbanes-Oxley, HIPPA e BASIL II.
Então, o que é exatamente? O Data Vault é um conjunto de Hubs, Satélites e Links que representam o processo de negócios modelado na fase de modelagem lógica de dados (pré-requisito). Ele deve ser representativo da(s) área(s) em que você está trabalhando; veja o caso de negócios hipotético abaixo. Seus melhores casos de uso são para armazenamentos de dados operacionais ou data warehouses; eles não substituem esquemas em estrela.
Abaixo está um fluxo de dados hipotético de um gestor de ativos que negocia ações, títulos, futuros, opções, etc. Como algumas negociações financeiras agora são 24 horas por dia, 7 dias por semana, e uma parcela significativa é algorítmica, o "negociador" no diagrama é, na verdade, um software nesses casos. Além disso, a Corretora e o Formador de Mercado podem ser uma única parte (uma única empresa), e pode haver vários bancos custodiantes envolvidos em grandes negociações institucionais.
Ocasionalmente, um banco custodiante é uma terceira parte cujo único propósito é repassar fundos entre dois ou mais bancos custodiantes. Isso tende a ser um cenário comum em mercados internacionais. Essas nuances apenas adicionam mais partes à transação, mas não alteram o processo em si.
O exemplo abaixo representa um modelo de dados lógicos atribuídos, baseado no diagrama de fluxo de dados acima. Adicionei atributos comuns que me chamaram a atenção, mas isso normalmente incluiria elementos adicionais que acrescentam complexidade ao modelo, mas podem adicionar ruído a este exemplo. Por isso, os deixei de fora.
A tradução do LDM acima para um formato físico de cofre de dados está abaixo. Normalmente, o LDM é traduzido para o físico com uma conversão entidade -> tabela muito semelhante, exceto nos casos em que relacionamentos lógicos muitos-para-muitos precisam ser implementados fisicamente com uma tabela associativa. Nesse caso, também pode haver uma desnormalização no físico, mas essa fase geralmente é resultado de ciclos de teste que identificam problemas de desempenho. Sem trocadilhos, mas a desnormalização não é uma prática comum – você não começa por aí; é reativa ou segue um padrão estabelecido.
A implementação do data vault de um modelo físico é muito diferente do LDM. Você notará que ele não se parece com um esquema em estrela ou qualquer um de seus derivados.
Existem alguns conceitos básicos que o data vault segue no padrão de design:
Os designs de Data Vault não substituem o OLAP implementado em esquemas estrela e seus derivados, nem são adequados para o OLTP, seu "ponto ideal" como data warehouse ou armazenamento de dados operacionais. É algo híbrido.
Ele é otimizado para armazenamento e não para consultas conduzidas pelo usuário, em parte devido à adesão estrita à terceira forma normal (3NF).
Três tipos de entidades: hub, satélite e links. Você pode ter tabelas de referência que suportem satélites estáticos, por exemplo, tabelas de países ou moedas, códigos postais, pesos e medidas.
Hubs são tabelas com poucas alterações nos dados. Elas devem conter uma chave de negócio. Em alguns aspectos, você pode considerá-las como algo análogo a uma dimensão que muda muito lentamente.
Links são associações entre chaves de negócios, que geralmente são hubs, mas nem sempre. É uma entidade associativa que resolve relacionamentos entre as chaves.
Satélites são para atributos temporais e descritivos, como dados gerados por data/hora, semelhantes ao conteúdo de transações. Satélites podem ter relacionamentos com outros satélites, dados de referência e links para hubs.
Existem links entre hubs, com a tabela de links absorvendo as chaves primárias dos hubs. Os hubs podem ter satélites como filhos.
Os links podem ter satélites como filhos, mas não como pais. A chave primária do link é absorvida pelo satélite.
Cada tabela tem uma data de carregamento e uma fonte de registro para cada linha. Elas devem criar uma chave única quando adicionadas à chave "natural" ou "comercial" em uma tabela. Em tabelas sem uma chave "natural", você pode usar a chave substituta. Use restrições de chave única ou índices de chave única para forçar essa restrição (a última é minha contribuição), supondo que você esteja usando um SGBD relacional.
Se você estiver implementando o modelo em um datalake sem restrições ou índices, poderá usar definições de partição e, obviamente, inserir a lógica no seu código para impor isso. A menos que esteja escrevendo no Apache Iceberg, onde as restrições podem ser implementadas em sua camada de metadados.
Dependendo do banco de dados de documentos que você estiver usando, você também pode usar restrições.
Práticas de carregamento de dados
A sequência de carregamento das tabelas é importante, especialmente se você estiver restringindo o uso de chaves/índices. Os primeiros a serem carregados são os hubs, que podem ser executados em paralelo, criando novas chaves substitutas. O próximo passo seriam os links, carregando quaisquer valores de atributos e criando associações entre os hubs. Por último, vêm os satélites, que estão na extremidade receptora dos links ou hubs, e podem ser carregados em paralelo entre si.
Para garantir a exclusividade dos registros, lembre-se da questão da 3NF: o hash é comumente usado como parte do processamento ETL/ELT para comparar o hash do registro recebido com os hashes dos registros atualmente na tabela. Os registros nunca são excluídos do cofre de dados.
Casos de Uso Os principais casos de uso para projetos de Data Vault foram armazenamentos de dados operacionais (ODS) e data warehouses corporativos (EDW). Ambos os casos se encaixam bem devido a vários fatores:
A adesão estrita à Terceira Forma Normal (3NF) não tem campos desnormalizados ou duplicados em tabelas, o que leva ao uso mais eficiente do armazenamento.
Verificações de exclusividade de dados são incorporadas ao processo de carregamento quando hashes são usados para confirmar se você já armazenou aquele registro específico, evitando duplicação de registros. Isso também reduz o armazenamento.
Pode ser difícil consultar usuários finais. Você precisaria de conhecimentos mais avançados de SQL para consultar as tabelas em um projeto de cofre de dados, em comparação com usuários finais típicos. É mais adequado para engenheiros acessarem os dados, ou seja, não é fácil de usar. Se você quiser expor os dados aos usuários finais, em um RDBMS tradicional, você pode criar visualizações para simplificar o acesso deles.
Menos registros armazenados significam menos dados escaneados por consultas, portanto, o tempo de recuperação da saída com uma consulta eficiente tem menos trabalho a fazer em comparação com uma estrutura desnormalizada.
O design da tabela é mais adequado para engenheiros. Ele tem foco estrito na normalização e em estruturas que refletem o armazenamento eficiente de dados, em vez de um fluxo de processos de negócios.
Acredito que o padrão de design Data Vault definitivamente tem seu lugar, especialmente nos casos em que você deseja literalmente manter o máximo de dados possível. Seja em um datalake ou em um RDBMS. Ele provavelmente é mais eficaz para resolver esse problema do que qualquer esquema em estrela ou derivado de um esquema em estrela. O caso do ODS geralmente envolve dados de uma semana a alguns meses, e também é adequado para isso, porque a normalização ajuda em todos os aspectos. Vale a pena avaliar esses usos especializados.
