Modelagem Data Vault para data warehouses escaláveis e auditáveis

Posicionamento

Data Vault é um método de modelagem para data warehouses que revela todo o seu potencial quando muitos sistemas de origem precisam ser integrados, os requisitos mudam com frequência e a rastreabilidade completa é obrigatória. Utilizo Data Vault há muitos anos em grandes projetos de data warehouse – no setor público, no setor de seguros e no varejo – e combino o método de forma direcionada com modelos dimensionais clássicos para a camada analítica.

Minha abordagem é pragmática. Data Vault não é um fim em si mesmo e não é a escolha certa para todo projeto. Onde o método se encaixa, porém, ele gera um impacto enorme: torna um data warehouse extensível sem romper estruturas existentes, permite uma carga altamente paralela e registra a origem de cada registro e o momento em que foi carregado. Exatamente essas propriedades são frequentemente decisivas em ambientes regulados.

Ao longo dos anos, conheci o Data Vault em configurações muito diferentes – desde data warehouses clássicos on-premises no SQL Server até plataformas baseadas em nuvem com Delta Lake. Essa amplitude me mostrou que o método não está atrelado a uma tecnologia específica, mas representa um padrão de pensamento: separe chaves, relacionamentos e descrições; registre cada entrega de forma auditável; e derive a análise a partir daí. Esse padrão permanece estável enquanto as ferramentas subjacentes evoluem – uma razão fundamental para a longevidade de soluções Data Vault bem construídas.

O método remonta a Dan Linstedt e se consolidou como um padrão estabelecido para data warehouses corporativos nas últimas duas décadas. Com o Data Vault 2.0 vieram as chaves hash, convenções claras de carga e uma ponte para abordagens ágeis. É exatamente essa versão moderna que aplico: chaves hash para carga paralela, separação rigorosa entre Raw Vault e Business Vault, e geração orientada por metadados das estruturas e processos de carga. Assim, o data warehouse permanece gerenciável mesmo quando o número de fontes e tabelas cresce significativamente ao longo dos anos.

Na minha consultoria, valorizo apresentar o Data Vault não como ideologia, mas como uma ferramenta com pontos fortes e limitações claros. Explico quais problemas o método resolve, qual é o custo associado e onde estão seus limites. Essa honestidade é importante para mim, porque um Data Vault aplicado de forma inadequada pode prejudicar um projeto tanto quanto um esquema estrela sobrecarregado. A arte está em utilizar o método onde ele realmente demonstra seus pontos fortes.

Por que Data Vault?

Modelos dimensionais clássicos segundo Kimball ou modelos normalizados segundo Inmon são consagrados, mas encontram seus limites quando um data warehouse cresce por anos, incorpora continuamente novas fontes e ao mesmo tempo precisa manter rastreabilidade completa. Cada nova fonte, cada novo relacionamento e cada novo atributo em um esquema estrela puro geralmente requer adaptações extensas nas tabelas existentes – com o correspondente esforço de testes e verificação de regressão.

O Data Vault enfrenta esse problema com uma separação estrita entre estrutura e conteúdo. Novas fontes são integradas por meio de satélites adicionais, novos relacionamentos por meio de links adicionais – sem que as estruturas existentes precisem ser alteradas. O modelo cresce de forma aditiva. Essa propriedade, conhecida no mundo Data Vault como "Auditability and Adaptability", é a principal razão pela qual utilizo o método em data warehouses corporativos de longa duração.

• Extensibilidade: conectar novas fontes e atributos de forma aditiva, sem quebrar o existente
• Auditabilidade: cada registro carrega origem (Record Source) e carimbo de data/hora de carga
• Paralelismo: hubs, links e satélites podem ser carregados de forma independente e simultânea
• Historização: alterações são registradas de forma completa e auditável
• Separação de responsabilidades: dados brutos no Raw Vault, lógica de negócio no Business Vault

É importante para mim a avaliação honesta: o Data Vault gera mais tabelas e mais joins do que um esquema estrela enxuto. Para um relatório pequeno e estável com poucas fontes, seria um exagero. O método demonstra sua força diante de complexidade, mudanças e requisitos de conformidade – e é exatamente nesses cenários que eu o recomendo e implemento.

Outra vantagem frequentemente decisiva é a capacidade de representar entregas incorretas ou atrasadas de forma limpa. Como o Raw Vault registra cada entrega com carimbo de carga e origem, é possível rastrear retrospectivamente quais dados estavam disponíveis em cada momento. Correções provenientes das fontes são acrescentadas como novas versões, não como sobrescritas – a entrega original permanece visível. Em auditorias e em obrigações de comprovação regulatória, exatamente essa completude é valiosa, pois cada número pode ser rastreado até a entrega original.

A aparente contradição entre Inmon e Kimball se resolve de forma elegante com o Data Vault. Ele não é nem um nem outro, mas sim uma camada de integração própria capaz de servir a ambos os mundos: integra e historiza como um core Inmon e fornece a base para qualquer número de marts Kimball. Esse papel como camada de integração neutra e duradoura é o verdadeiro lugar do Data Vault em uma arquitetura de dados moderna.

Os blocos de construção: hub, link, satélite

O Data Vault trabalha com três blocos de construção centrais. Sua clareza é o verdadeiro ponto forte do método: cada tipo de tabela tem exatamente uma função, e da combinação desses três tipos qualquer modelo, por mais complexo que seja, pode ser construído.

O modelo central do Data Vault: hubs armazenam chaves de negócio, links conectam hubs em relacionamentos, satélites carregam os atributos descritivos e historicizados.

Essa distribuição estrita de papéis é o verdadeiro truque do método. Em modelos clássicos, as tabelas frequentemente mesclam chaves, relacionamentos e atributos – o que as torna difíceis de modificar. O Data Vault decompõe esses três aspectos sistematicamente em tipos de tabelas próprios. Com isso, uma alteração nos atributos de uma fonte afeta apenas seu satélite, um novo relacionamento afeta apenas um novo link, e um novo objeto de negócio afeta apenas um novo hub. As estruturas existentes permanecem intactas. Exatamente essa localidade das alterações torna o modelo tão robusto diante da inevitável mudança dos sistemas de origem.

Hub – a chave de negócio

Um hub representa um objeto de negócio central – como cliente, produto, contrato ou conta. Ele contém exclusivamente a chave de negócio funcional (Business Key), uma chave hash derivada dela como substituta, o carimbo de data/hora de carga e a fonte de dados. Deliberadamente, um hub não contém atributos descritivos: ele é a lista estável e permanente de todas as chaves de negócio de um tipo de objeto já observadas.

Link – o relacionamento

Um link modela um relacionamento entre dois ou mais hubs – como 'cliente tem contrato' ou 'pedido contém produto'. O link também não contém atributos descritivos, apenas as chaves hash dos hubs envolvidos, uma chave hash própria do link, carimbo de carga e origem. Relacionamentos no Data Vault são sempre modelados como muitos-para-muitos – o que torna o modelo robusto diante de alterações futuras de cardinalidade.

Satélite – os atributos descritivos

O satélite carrega os atributos descritivos e variáveis de um hub ou link – como nome, endereço, status ou valor. É o local da historização: quando um atributo muda, um novo registro com novo carimbo de carga é acrescentado; o antigo é preservado. Um hash diff permite identificar eficientemente se algo realmente mudou. Um hub pode ter múltiplos satélites – por exemplo, separados por sistema de origem ou por frequência de atualização.

A distribuição dos atributos em múltiplos satélites é uma decisão de projeto consciente. Com frequência, separo por sistema de origem, para que cada fonte receba seu próprio satélite carregável de forma independente e as mudanças de uma fonte não afetem as demais. Outra separação útil segue a frequência de atualização: dados cadastrais raramente alterados pertencem a um satélite diferente das informações de status que mudam com frequência. Assim, o histórico permanece enxuto, pois não há duplicação de todo o conjunto de atributos a cada pequena alteração.

Além desses três blocos centrais, o Data Vault conhece algumas formas especiais úteis. Satélites de efetividade (Effectivity Satellites) registram em qual período um relacionamento era válido – por exemplo, quando um cliente estava associado a qual contrato. Multi-Active Satellites representam atributos multivalorados, como vários números de telefone de um cliente. E tabelas de referência armazenam listas de códigos e dados cadastrais que não precisam ser historicizados. Utilizo essas extensões de forma direcionada, sem sobrecarregar o modelo desnecessariamente.

Chaves hash e suas vantagens

Um conceito central dos Data Vaults modernos são as chaves hash. Em vez de chaves substitutas sequenciais que precisam ser atribuídas centralmente, um valor hash determinístico é calculado a partir da chave de negócio – por exemplo, com SHA-256 via HASHBYTES no SQL Server. Essa abordagem oferece diversas vantagens decisivas para a carga.

• Chaves hash podem ser calculadas sem consultar previamente uma tabela de lookup
• Hubs, links e satélites podem, portanto, ser carregados de forma totalmente paralela e independente
• A mesma chave de negócio produz sempre a mesma chave hash em todos os sistemas
• Hash diffs sobre atributos descritivos detectam alterações de forma eficiente

O custo disso é um maior consumo de armazenamento e um esforço computacional adicional no processo de hashing. Na prática, porém, as vantagens no processo de carga superam amplamente esses custos, especialmente ao processar grandes volumes de dados em paralelo. É fundamental uma normalização cuidadosa das chaves antes do hashing – ou seja, padronização de maiúsculas/minúsculas, remoção de espaços e um separador definido entre chaves compostas – para que a mesma chave de negócio produza de forma confiável o mesmo hash.

Na escolha do algoritmo de hash, pondero entre segurança contra colisões e consumo de armazenamento. SHA2_256 fornece uma representação de 32 bytes praticamente livre de colisões e é meu padrão para ambientes com requisitos de segurança. Onde o armazenamento e a performance são especialmente críticos e o risco de colisão é aceitável do ponto de vista de negócio, um algoritmo mais curto pode ser considerado ocasionalmente. Essa decisão não é tomada de forma genérica, mas depende do volume de dados, dos requisitos de conformidade e da vida útil esperada do data warehouse.

Modelo de dados e DDL

Como é um modelo Data Vault na prática? O exemplo a seguir mostra a DDL para um hub, um satélite e um link usando cliente, contrato e o relacionamento entre eles. A estrutura é mantida uniformemente simples – essa uniformidade é a base para geração e automação posteriores.

Destaque para as colunas de metadados recorrentes. Cada tabela registra carimbo de carga e Record Source; cada satélite adiciona hash diff e um LoadEndDate opcional. Essas colunas não são acessórias, mas sim a espinha dorsal da auditabilidade: respondem para cada registro as perguntas sobre de onde ele veio, quando foi carregado e se é o estado atual. Como essas colunas têm o mesmo nome e o mesmo comportamento em todas as tabelas, é possível escrever procedimentos de carga genéricos que processam cada hub, cada link e cada satélite seguindo o mesmo esquema.

-- HUB: mantém exclusivamente a chave de negócio + metadados
CREATE TABLE rv.Hub_Customer (
    Customer_HK     binary(32)    NOT NULL,   -- chave hash (SHA2_256)
    Customer_BK     varchar(50)   NOT NULL,   -- chave de negócio
    LoadDate        datetime2(3)  NOT NULL,   -- momento da carga
    RecordSource    varchar(100)  NOT NULL,   -- origem (auditoria)
    CONSTRAINT PK_Hub_Customer PRIMARY KEY (Customer_HK)
);

-- SATELLITE: atributos descritivos e historizados do hub
CREATE TABLE rv.Sat_Customer (
    Customer_HK     binary(32)    NOT NULL,
    LoadDate        datetime2(3)  NOT NULL,
    LoadEndDate     datetime2(3)  NULL,       -- aberto = versão atual
    HashDiff        binary(32)    NOT NULL,   -- detecção de alteração
    RecordSource    varchar(100)  NOT NULL,
    CustomerName    varchar(200)  NULL,
    City            varchar(100)  NULL,
    Segment         varchar(50)   NULL,
    CONSTRAINT PK_Sat_Customer PRIMARY KEY (Customer_HK, LoadDate)
);

-- LINK: relacionamento entre dois hubs (cliente <-> contrato)
CREATE TABLE rv.Lnk_Customer_Contract (
    Cust_Contract_HK binary(32)   NOT NULL,   -- hash sobre ambas as BKs
    Customer_HK      binary(32)   NOT NULL,
    Contract_HK      binary(32)   NOT NULL,
    LoadDate         datetime2(3) NOT NULL,
    RecordSource     varchar(100) NOT NULL,
    CONSTRAINT PK_Lnk_Customer_Contract PRIMARY KEY (Cust_Contract_HK)
);

Note a uniformidade estrita: cada hub, satélite e link segue o mesmo plano estrutural. Exatamente essa uniformidade permite gerar o modelo e os procedimentos de carga a partir de metadados.

O cálculo das chaves hash e do hash diff ocorre no momento da carga. O exemplo a seguir mostra como os valores hash são formados a partir da chave de negócio normalizada e dos atributos descritivos.

-- Chave hash a partir da chave de negócio normalizada; hash diff dos atributos.
-- UPPER + TRIM garantem uma representação canônica e estável.

SELECT
    HASHBYTES('SHA2_256',
              UPPER(LTRIM(RTRIM(s.CustomerId)))                  ) AS Customer_HK,
    HASHBYTES('SHA2_256',
              CONCAT_WS('|',
                        UPPER(LTRIM(RTRIM(ISNULL(s.CustomerName,'')))),
                        UPPER(LTRIM(RTRIM(ISNULL(s.City,'')))),
                        UPPER(LTRIM(RTRIM(ISNULL(s.Segment,'')))) )) AS HashDiff,
    s.CustomerId  AS Customer_BK,
    s.CustomerName, s.City, s.Segment,
    SYSUTCDATETIME() AS LoadDate,
    'CRM'            AS RecordSource
FROM stg.Customer AS s;

CONCAT_WS com um separador definido impede o deslocamento de limites entre atributos. ISNULL garante que valores NULL não alterem o hash de forma incontrolada.

Carga paralela do Raw Vault

A real vantagem do Data Vault se revela na carga. Como as chaves hash são calculadas sem lookups, hubs, links e satélites não dependem uns dos outros durante o carregamento. Eles podem ser carregados de forma totalmente paralela – uma enorme vantagem com grandes volumes de dados e janelas de carga restritas.

Carga paralela: hubs, links e satélites são carregados de forma independente. Cada etapa de carga é idempotente e grava apenas registros novos ou alterados.

A lógica de carga por bloco de construção é simples e sempre a mesma. Um hub recebe apenas chaves que ainda não conhece. Um link recebe apenas relacionamentos que ainda não conhece. Um satélite recebe um novo registro somente quando o hash diff mudou em relação ao último estado conhecido. Todos os três passos são idempotentes: uma nova execução com os mesmos dados não altera nada.

Essa simplicidade tem uma razão mais profunda. Como nenhuma ordem precisa ser respeitada entre os blocos de construção, a complicada gestão de dependências que torna os processos de carga clássicos tão propensos a erros é eliminada. Em um esquema estrela, uma dimensão precisa estar carregada antes que a tabela de fatos associada possa consultar suas chaves substitutas. No Data Vault não existe essa dependência de lookup: cada bloco de construção calcula suas próprias chaves hash. Isso simplifica enormemente a orquestração e permite distribuir a carga em muitos fluxos paralelos sem entrar em conflitos de sequência.

-- Carga do HUB: inserir apenas novas chaves de negócio.
INSERT INTO rv.Hub_Customer (Customer_HK, Customer_BK, LoadDate, RecordSource)
SELECT DISTINCT s.Customer_HK, s.Customer_BK, s.LoadDate, s.RecordSource
FROM   stg.Customer_Hashed AS s
WHERE  NOT EXISTS (SELECT 1 FROM rv.Hub_Customer AS h
                   WHERE h.Customer_HK = s.Customer_HK);

-- Carga do SATELLITE: inserir novo registro apenas se o hash diff mudou.
INSERT INTO rv.Sat_Customer
       (Customer_HK, LoadDate, HashDiff, RecordSource, CustomerName, City, Segment)
SELECT s.Customer_HK, s.LoadDate, s.HashDiff, s.RecordSource,
       s.CustomerName, s.City, s.Segment
FROM   stg.Customer_Hashed AS s
WHERE  NOT EXISTS (
         SELECT 1
         FROM   rv.Sat_Customer AS sat
         WHERE  sat.Customer_HK = s.Customer_HK
           AND  sat.LoadEndDate IS NULL          -- versão atual
           AND  sat.HashDiff    = s.HashDiff );  -- inalterado -> não fazer nada

O padrão é praticamente idêntico para hub, link e satélite. Essa repetibilidade é a razão pela qual os processos de carga do Data Vault se prestam especialmente bem à geração e automação.

A carga do link segue o mesmo princípio. Um link também recebe apenas relacionamentos que ainda não conhece; sua chave hash é calculada a partir das chaves de negócio envolvidas. Como os relacionamentos no Data Vault são sempre modelados como muitos-para-muitos, não há atualização nem exclusão no link – apenas inserção aditiva de novos relacionamentos. Quando for necessário representar a validade temporal de um relacionamento, isso é feito por meio de um Effectivity Satellite associado.

-- Carga do LINK: inserir apenas novos relacionamentos entre cliente e contrato.
INSERT INTO rv.Lnk_Customer_Contract
       (Cust_Contract_HK, Customer_HK, Contract_HK, LoadDate, RecordSource)
SELECT DISTINCT
       s.Cust_Contract_HK, s.Customer_HK, s.Contract_HK, s.LoadDate, s.RecordSource
FROM   stg.Contract_Hashed AS s
WHERE  NOT EXISTS (SELECT 1 FROM rv.Lnk_Customer_Contract AS l
                   WHERE l.Cust_Contract_HK = s.Cust_Contract_HK);

A chave hash do link é formada durante o hashing dos dados de staging a partir das chaves de negócio normalizadas de cliente e contrato. Assim, cada combinação gera exatamente uma chave estável e calculável em paralelo.

Uma vantagem frequentemente subestimada dessa idempotência é a robustez em caso de falha. Se uma execução de carga for interrompida no meio do processamento, ela pode ser simplesmente reiniciada – os registros já carregados não são duplicados, os ausentes são complementados. Não existe estado carregado pela metade e inconsistente que precisaria ser laboriosamente corrigido. Especialmente em ambientes com janelas de carga restritas e alto volume de dados, essa propriedade é extremamente valiosa, pois torna trivial a retomada e elimina intervenções noturnas.

Raw Vault, Business Vault e tabelas PIT

Na prática, divido o vault em duas áreas. O Raw Vault absorve os dados brutos exatamente como chegam das fontes – sem interpretação de negócio, mas com auditabilidade completa. O Business Vault contém estruturas derivadas nas quais a lógica de negócio é implementada: satélites calculados, relacionamentos ponderados ou chaves unificadas entre múltiplas fontes.

Um exemplo típico de lógica de Business Vault é a unificação de objetos de negócio que são geridos de forma diferente em múltiplos sistemas de origem. O mesmo cliente pode ter um identificador diferente no CRM e no sistema de faturamento. No Raw Vault, ambos os identificadores são preservados sem alteração; no Business Vault, uma lógica Same-As-Link ou de mapeamento os reúne em uma visão unificada. Se a regra de unificação precisar ser alterada posteriormente, ela pode ser recalculada a partir do Raw Vault intocado – uma rede de segurança que simplesmente não existe em arquiteturas mais simples.

Essa separação é importante porque mantém os dados brutos e sua interpretação distintos. Se uma regra de negócio mudar, isso afeta apenas o Business Vault – o Raw Vault como verdade auditável permanece intocado. Se posteriormente se constatar que uma regra deveria ter sido diferente, ela pode ser recalculada a partir do Raw Vault sem perda de informação.

Tabelas PIT e Bridge

Como um hub pode ter múltiplos satélites e os satélites são atualizados com frequências diferentes, consultar um estado consistente em um determinado ponto no tempo é trabalhoso. Aqui, as tabelas Point-in-Time (PIT) e as tabelas Bridge são úteis. Uma tabela PIT armazena para cada chave de negócio e data de referência os carimbos de carga dos satélites correspondentes, reduzindo drasticamente o número de joins. As tabelas Bridge agrupam caminhos de link frequentemente utilizados. Ambas são estruturas auxiliares de performance e podem ser reconstruídas a qualquer momento a partir do vault.

A separação entre Raw Vault e Business Vault também oferece vantagens organizacionais. Permite dividir claramente as responsabilidades: uma equipe pode cuidar da carga confiável e próxima à fonte do Raw Vault, enquanto as áreas de negócio, em conjunto com os desenvolvedores, moldam a lógica de negócio no Business Vault. Como o Raw Vault mantém imutavelmente a verdade das fontes, as regras de negócio podem ser testadas experimentalmente, descartadas e recalculadas sem que qualquer informação seja perdida. Esse desacoplamento de dados brutos e interpretação reduz significativamente o risco de erros de consequências graves.

-- Uma tabela PIT mantém, por chave de negócio e data de referência, o
-- momento de carga do satélite correspondente, reduzindo o número de joins.

INSERT INTO bv.Pit_Customer (Customer_HK, SnapshotDate, Sat_Customer_LoadDate)
SELECT  h.Customer_HK,
        cal.SnapshotDate,
        (SELECT MAX(s.LoadDate)
         FROM   rv.Sat_Customer AS s
         WHERE  s.Customer_HK = h.Customer_HK
           AND  s.LoadDate   <= cal.SnapshotDate)  AS Sat_Customer_LoadDate
FROM    rv.Hub_Customer AS h
CROSS JOIN ref.SnapshotCalendar AS cal
WHERE   cal.SnapshotDate >= '2020-01-01';

Uma consulta não precisa mais percorrer todas as versões do satélite, mas faz join diretamente pelos carimbos de carga armazenados na tabela PIT – isso acelera significativamente as análises pontuais no tempo.

O esforço adicional com tabelas PIT e Bridge é bem investido. Sem elas, as análises precisariam determinar dinamicamente a janela correta do satélite para cada data de referência, o que se torna custoso com muitos satélites e grandes históricos. Como essas estruturas auxiliares podem ser derivadas completamente do vault, elas podem ser reconstruídas a qualquer momento conforme necessário – por exemplo, após uma extensão estrutural ou uma correção no Business Vault. São aceleradores puros e não carregam uma verdade própria.

Do vault ao esquema estrela

Um Data Vault é excelente para integração e historização de dados – mas não é o modelo com o qual usuários de negócio ou ferramentas de BI preferem trabalhar. Para a análise, derivo do vault modelos dimensionais segundo Kimball: esquemas estrela com tabelas de fatos e dimensões, intuitivamente compreensíveis e otimizados para ferramentas como Power BI.

As camadas em visão geral: fontes, staging, Raw Vault, Business Vault e a camada Information Mart com esquemas estrela para análise.

Essa abordagem combina o melhor dos dois mundos. O vault garante integração, historização e auditabilidade; o esquema estrela garante compreensibilidade e performance na análise. De um hub com seus satélites emerge uma dimensão – frequentemente como uma Slowly Changing Dimension Tipo 2, para tornar visível o histórico armazenado no vault. De links e seus satélites emergem tabelas de fatos.

-- Hub + satélite tornam-se uma visão dimensional com período de validade.
-- O histórico armazenado no vault vira versões SCD2 no esquema estrela.

CREATE OR ALTER VIEW im.DimCustomer AS
SELECT
    h.Customer_HK                              AS CustomerKey,
    h.Customer_BK                              AS CustomerBk,
    s.CustomerName, s.City, s.Segment,
    s.LoadDate                                 AS ValidFrom,
    LEAD(s.LoadDate) OVER (PARTITION BY h.Customer_HK
                           ORDER BY s.LoadDate) AS ValidTo,
    CASE WHEN s.LoadEndDate IS NULL THEN 1 ELSE 0 END AS IsCurrent
FROM rv.Hub_Customer  AS h
JOIN rv.Sat_Customer  AS s ON s.Customer_HK = h.Customer_HK;

Pela função de janela LEAD, um intervalo válido-de/válido-até é formado elegantemente a partir dos estados de carga sucessivos – sem que o histórico no vault precise ser duplicado.

A grande atratividade dessa separação está na flexibilidade no lado analítico. Do mesmo vault podem ser derivados quantos marts funcionalmente distintos forem necessários – um mart para o controle, um para vendas, um para um relatório regulatório. Cada mart vê exatamente a visão de que precisa e pode ser desenvolvido independentemente dos demais. Se se constatar que um mart precisa de um corte diferente, ele é derivado novamente do vault sem que os dados brutos subjacentes sejam tocados. Esse desacoplamento de integração e análise é um dos maiores ganhos práticos do método.

Modelo em camadas da arquitetura geral

No cenário geral, o Data Vault se encaixa em uma arquitetura claramente estruturada em camadas. As fontes são carregadas em uma camada de staging; lá as chaves hash são calculadas; em seguida o Raw Vault é preenchido. O Business Vault implementa a lógica de negócio, e de ambos emerge a camada Information Mart com os esquemas estrela prontos para análise.

• Staging: dados brutos das fontes, cálculo de chaves hash e hash diffs
• Raw Vault: integração auditável em hubs, links e satélites
• Business Vault: estruturas derivadas, lógica de negócio, chaves unificadas
• Information Marts: esquemas estrela e visões para ferramentas de BI
• Transversal: metadados, orquestração, logging e testes em todas as camadas

Essa estrutura em camadas não é rígida, mas serve como guia. Dependendo do projeto, o Business Vault pode ser mais extenso ou mais enxuto; alguns marts são materializados, outros permanecem como visões. O que é decisivo é que cada camada tenha uma função clara e que a verdade auditável no Raw Vault permaneça intocada.

Temas transversais permeiam todas as camadas. Uma orquestração central controla a ordem e o nível de paralelismo com que as camadas são carregadas. Um logging completo com IDs de lote torna cada execução rastreável. E testes automatizados garantem tanto a carga do vault quanto a derivação dos marts. Essas funções transversais não são acessórias – elas determinam a operabilidade de todo o data warehouse. Por isso, as planifico desde o início, não apenas quando os primeiros problemas operacionais surgem.

Na nuvem, esse modelo em camadas pode ser transferido diretamente para plataformas modernas. A camada de staging corresponde frequentemente a um nível Bronze no data lake; Raw Vault e Business Vault residem como estruturas Delta ou Parquet; e os Information Marts são disponibilizados em um armazenamento analítico de alta performance. O método permanece o mesmo; apenas a tecnologia subjacente muda. Essa independência da plataforma concreta é mais uma razão pela qual o Data Vault se prova em data warehouses pensados para o longo prazo: o modelo sobrevive também a uma mudança tecnológica.

Automação e metadados

O maior ponto forte do Data Vault em operação é sua uniformidade. Como cada hub, link e satélite segue o mesmo plano estrutural, tanto as estruturas de tabelas quanto os procedimentos de carga podem ser gerados a partir de metadados. Em vez de escrever centenas de procedimentos manualmente, mantenho uma descrição em metadados das fontes, chaves e atributos – e gero a partir daí DDL e lógica de carga.

Essa abordagem orientada por metadados traz diversas vantagens. Reduz drasticamente o esforço de implementação, impõe consistência em todos os blocos de construção e transforma a integração de novas fontes em uma tarefa de configuração em vez de um projeto de programação. Ferramentas de modelagem de dados – como PowerDesigner, com o qual trabalhei em vários projetos de DWH – apoiam essa abordagem, assim como geradores desenvolvidos internamente com base nas tabelas de metadados.

A geração abrange não apenas as tabelas, mas todo o stack de carga: a DDL para hubs, links e satélites, o cálculo das chaves hash, os procedimentos de carga idempotentes e as entradas nas tabelas de controle que orquestram a execução paralela. No caso ideal, basta descrever uma nova fonte nos metadados e executar o gerador para obter uma integração totalmente testada e funcional. Essa alavancagem transforma tarefas que normalmente levariam dias em uma questão de horas.

Uma arquitetura orientada por metadados também muda a forma como uma equipe trabalha. A integração de uma nova fonte torna-se uma tarefa bem definida: descrever a fonte, mapear chaves de negócio e atributos, gerar, testar. Em vez de cada desenvolvedor contribuir com seu próprio estilo, o gerador impõe uma implementação uniforme e verificada. Isso reduz o tempo de integração de novos membros da equipe e torna o data warehouse menos dependente de pessoas específicas – um aspecto importante para a operabilidade de longo prazo.

Os próprios metadados tornam-se um ativo valioso. Eles documentam quais fontes estão integradas, quais chaves de negócio são usadas e como os atributos são distribuídos nos satélites. Essa descrição é ao mesmo tempo documentação técnica e plano de construção. Quando uma fonte muda, a descrição nos metadados é atualizada e a parte afetada é regenerada – modelo, lógica de carga e documentação permanecem automaticamente consistentes. Manter essa consistência manualmente em grandes data warehouses é praticamente impossível.

Metodologia de trabalho

Um projeto Data Vault começa com a modelagem de negócio: quais objetos de negócio existem, quais chaves de negócio os identificam, quais relacionamentos existem? Essas questões são esclarecidas em conjunto com as áreas de negócio, pois as chaves de negócio são o fundamento de todo o modelo. Somente depois vêm a implementação técnica e a automação.

• Análise: esclarecer objetos de negócio, chaves e relacionamentos com as áreas de negócio
• Modelagem: projetar hubs, links e satélites; delimitar Raw Vault e Business Vault
• Implementação: gerar e testar DDL e lógica de carga orientadas por metadados
• Marts: derivar esquemas estrela prontos para análise para as ferramentas de BI
• Operação: carga paralela, monitoramento, testes e documentação

É importante para mim utilizar o Data Vault de forma pragmática, não dogmática. Nem toda tabela precisa passar pelo vault completo; alguns dados de referência podem ser geridos de forma mais simples diretamente. Essa ponderação pragmática – onde o vault vale a pena e onde não – faz parte da minha consultoria e poupa ao cliente esforços desnecessários.

Na prática, gosto de trabalhar de forma iterativa. Em vez de projetar todo o modelo antecipadamente até o último detalhe, começo com os objetos de negócio centrais e seus relacionamentos mais importantes e expando o modelo gradualmente. Como o Data Vault cresce de forma aditiva, essa abordagem é de baixo risco: cada extensão é acrescentada sem colocar em risco o existente. Assim, emerge cedo um data warehouse funcional que ganha mais fontes e maior profundidade funcional a cada sprint – e as áreas de negócio já veem os primeiros resultados durante o desenvolvimento.

Serviços típicos em projetos Data Vault

Em torno da modelagem Data Vault, assumo diferentes responsabilidades dependendo da fase do projeto – desde a modelagem de negócio até a implementação e a operação. Integro-me em equipes e paisagens de ferramentas existentes e trabalho em estreita colaboração com arquitetos, desenvolvedores e áreas de negócio, para que o resultado não seja apenas tecnicamente sólido, mas também funcionalmente sustentável e operável a longo prazo.

• Modelagem de negócio de hubs, links e satélites
• Delimitação de Raw Vault e Business Vault
• Estratégia de chave hash com HASHBYTES e normalização canônica de chaves
• Geração orientada por metadados de DDL e procedimentos de carga
• Carga paralela e idempotente do vault
• Tabelas PIT e Bridge para análises de alta performance
• Derivação de modelos dimensionais (esquema estrela, SCD2) para a camada de BI
• Migração de estruturas DWH existentes para um modelo Data Vault
• Testes, logging, monitoramento e documentação do vault

Projetos de referência selecionados e anonimizados

Perguntas frequentes sobre modelagem Data Vault