Um Cofre de Dados Brutos foi criado para armazenar dados brutos. Além de capturar e integrar os dados, alguns exemplos de regras de negócios flexíveis dentro do Business Vault foram aplicados. Este artigo se concentra em usar os dados do modelo combinado do Data Vault (ou seja, o Raw Data Vault e o Business Vault) e transformá-los em informações valiosas para fornecer aos usuários corporativos.
Entrega de informações
O Raw Data Vault e o Business Vault capturam os dados brutos dos sistemas de origem e os resultados da lógica de negócios exigida pelos usuários de negócios. Pode-se argumentar que o trabalho está feito até lá.
Mas, na realidade, os usuários finais normalmente não querem trabalhar com as entidades Raw Data Vault ou Business Vault. As razões válidas para isso geralmente incluem falta de conhecimento na modelagem do Data Vault e, portanto, falta de clareza sobre como consultar uma implementação do Data Vault. Além disso, a maioria dos usuários finais já está familiarizada com diferentes métodos de consumo de dados. Isso normalmente inclui modelos dimensionais, como esquema em estrela ou esquema de floco de neve, ou tabelas planas e largas totalmente desnormalizadas. Neste artigo, discutimos entidades de fato e dimensões de mudança lenta (SCD) 1 e 2.
Além disso, a maioria das ferramentas para fornecer informações, como ferramentas de painel como Microsoft PowerBI ou SQL Server Analysis Services para produzir cubos OLAP, são fáceis de usar com esses modelos.
Como fornecer informações com o Data Vault 2.0
Independentemente do formato de entrega de informações desejado, ele pode ser consultado diretamente de entidades do Raw Data Vault. O modelo do Data Vault segue um design otimizado de esquema na leitura, em que os dados brutos são armazenados no estado em que se encontram e as transformações, como lógica de negócios e alterações estruturais, são aplicadas durante o tempo de consulta. Isso é verdade, exceto que os dados de origem de entrada são divididos nos componentes fundamentais: chaves de negócios, relacionamentos e dados descritivos. Esta é a otimização do armazenamento e facilita muito a aplicação de regras de negócios e também a transformação em qualquer esquema de informações de destino desejado.
As entidades do Business Vault são usadas durante a entrega de informações para aplicar regras de negócios. Na maioria dos casos, os dados brutos são insuficientes para relatórios: eles contêm dados incorretos e alguns dados estão ausentes ou precisam ser convertidos de uma moeda para outra. No entanto, alguns dos dados brutos são bons o suficiente para relatórios. Portanto, em muitos casos, os modelos de informações, como um modelo dimensional, seriam derivados do Raw Data Vault e do Business Vault unindo as entidades necessárias.
Os requisitos de entrega de informações geralmente incluem um requisito de historização. Uma dimensão de mudança lenta (SCD) Tipo 1 incluiria apenas o estado atual dos atributos descritivos. No entanto, o SCD Tipo 2 consistiria no histórico completo de atributos descritivos. O Data Vault segue uma abordagem multitemporal e aproveita vários cronogramas para implementar essas soluções:
- O carimbo de data/hora da data de carregamento é a linha do tempo técnica que indica quando os dados chegaram à plataforma de dados. A linha do tempo deve ser definida (e controlada) pela equipe da plataforma de dados.
- O carimbo de data/hora do instantâneo indica quando as informações devem ser entregues ao usuário final. Essa linha do tempo é regular (por exemplo, todas as manhãs às 8h) e definida pelo usuário corporativo.
- Os cronogramas de negócios estão dentro dos dados de origem e indicam quando algo aconteceu. Os exemplos incluem datas de nascimento, datas válidas de e até datas de alteração e datas de exclusão.
Separar essas linhas do tempo e criar soluções multitemporais, em que alguns dados são retroativos ou pós-datados, torna-se muito mais simples. No entanto, isso está além do escopo deste artigo.
Passo a passo da implementação
Para atender aos requisitos de negócios, vamos começar da forma mais simples possível. Por vários motivos, é altamente recomendável que os information marts sejam implementados usando exibições SQL inicialmente e usem tabelas físicas apenas se o desempenho ou os tempos/custos de processamento exigirem. Outras opções, como PIT e tabelas de bridge, normalmente fornecem uma solução suficiente (virtualizada).
Seguimos essa recomendação neste artigo e começamos com uma visão de dimensão e uma visão de fato.
Dimensão da loja
Muitas entidades de dimensões são derivadas de um hub e seu satélite. Se nenhuma regra de negócios for implementada, a Dimensão poderá acessar diretamente das entidades do Raw Data Vault. Por exemplo, a instrução CREATE VIEW a seguir implementa uma dimensão de armazenamento SCD Tipo 1:
Essa consulta simples acessa o store_hub e o une ao satélite store_address. Ele seleciona a chave de negócios do hub porque os usuários corporativos típicos desejam incluí-la na dimensão. Além disso, ele renomeia todos os atributos descritivos do satélite para torná-los mais legíveis. A chave de hash é adicionada para junções eficientes de entidades Fact. No final, uma cláusula WHERE aproveita o sinalizador is_current no satélite para incluir apenas os dados descritivos mais recentes. Este sinalizador é calculado em uma exibição no topo da tabela de satélite real. Assim, a exibição é unida, não a tabela. Somente essa cláusula WHERE específica torna essa dimensão do SCD tipo 1. Deixá-lo de fora levaria automaticamente a um SCD tipo 2! No entanto, nesse caso, faria sentido incluir adicionalmente o load_date e o load_end_date da visualização de satélite.
Fato da transação
A instrução CREATE VIEW a seguir implementa uma entidade de fato. Neste exemplo simples, nenhuma agregação é definida. A granularidade da entidade de fato derivada corresponde aos dados subjacentes do link não historizado. Portanto, a visão de fato pode ser derivada diretamente do link não historizado sem a necessidade de um deslocamento de grão, por exemplo, uma cláusula GROUP BY:
Essa consulta é selecionada no link não historizado e une os dois hubs por meio das hashkeys. A partir desses hubs, as chaves de hash são atribuídas. No link não histórico, os detalhes relevantes da transação são escolhidos. Um filtro para historização não é necessário porque hubs e links não historiados capturam apenas dados inalterados. Capturar fatos em mudança, que em teoria nunca deveriam acontecer, mas podem acontecer na realidade, também é possível usando links não históricos, mas além do escopo deste artigo.
Agregações pré-calculadas
Na maioria dos ambientes de negócios, os desenvolvedores de BI agora conectariam sua ferramenta de relatório preferida ao nosso modelo dimensional fornecido para criar relatórios personalizados. É comum agregar dados para calcular somas, contagens, médias ou outros valores agregados, especialmente para dados de fatos. Dependendo do volume de dados, da ferramenta de relatório e da complexidade da agregação, isso pode ser um desafio para os usuários corporativos.
Para simplificar o uso e otimizar o desempenho da consulta em alguns casos, uma pré-agregação na camada dimensional pode ser a melhor opção. Por exemplo, a instrução CREATE VIEW implementa outra exibição de fatos da transação de armazenamento que já inclui as agregações solicitadas. Como as agregações são sempre baseadas em uma cláusula GROUP BY, as exibições a seguir implementam os dois deslocamentos de granularidade para calcular o número e a quantidade de transações nas diferentes dimensões de loja e cliente:
Em ambas as consultas, apenas um hub é necessário. A chave de hash de cada hub é usada para a cláusula GROUP BY e três agregações básicas são aplicadas para determinar a contagem de transações e calcular a soma e a quantidade média de transações.
Embora isso reduza a carga de trabalho no lado do usuário corporativo, essa implementação ainda pode ser lenta ou produzir altos custos de processamento. Portanto, faria sentido começar a materializar essa entidade de fato agregada ou introduzir uma tabela de ponte.
Uma tabela de bridge é semelhante a uma tabela de fatos pré-agregada em modelos dimensionais. No entanto, é muito mais personalizável, pois implementa apenas a operação de deslocamento de grãos (neste caso, a cláusula GROUP BY), cálculos de medida e cronogramas. Ele também contém as referências de hub, que serão transformadas em referências de dimensão, como visto nos exemplos anteriores.
A definição da tabela de bridge é fornecida na seguinte instrução:
A tabela de ponte também pode conter cálculos comerciais complexos em muitos outros casos. Ainda assim, o foco está na operação de deslocamento de grãos, que leva um tempo razoável em muitos sistemas de banco de dados tradicionais devido ao armazenamento baseado em linhas. No entanto, o Microsoft Fabric usa um formato de armazenamento diferente otimizado para agregações, mas normalmente ao preço das junções.
A tabela de ponte visa melhorar o desempenho da consulta de entidades de fato. Por sua vez, isso significa que não há problema em pré-unir outros dados na tabela de ponte se o desempenho da junção for insuficiente.
Um requisito comum é a adição de uma dimensão de tempo.
Entrega de informações baseada em instantâneo
Até agora, a dimensão de loja apresentada neste artigo era uma dimensão SCD Tipo 1 – uma dimensão sem histórico. No entanto, em muitos casos, as empresas desejam relacionar fatos à versão membro da dimensão da hora em que o fato ocorreu. Por exemplo, um pedido foi emitido antes que o cliente se mudasse para outro estado. Em um cenário Tipo 1, a receita do pedido seria associada ao estado atual do cliente. No entanto, isso pode não estar correto, dependendo dos requisitos de informação. Nesses casos, a receita deve estar associada ao estado do cliente no momento da transação.
Esse requisito de informação exige uma dimensão SCD Tipo 2 com histórico. As tabelas PIT (ponto no tempo) são recomendadas para produzir essas dimensões com eficiência. Esta seção discute as etapas necessárias para criar essa tabela.
Um bom ponto de partida é uma tabela de datas. Essa tabela é uma tabela de referência para datas e pode produzir uma dimensão de data e preencher a tabela PIT. A instrução a seguir cria a tabela e a inicializa com datas entre 1970 e 2099:
A primeira parte é uma instrução DDL simples que cria a tabela de data de referência. Isso é seguido por uma instrução INSERT que aproveita várias CTEs (Common Table Expressions) para simplificar a lógica.
O primeiro CTE date_base simplesmente gera uma lista dos números de 1 a 10, seguido pelo date_basic CTE, que CROSS JOINs o CTE anterior quatro vezes, criando 10 * 10 * 10 * 10 = 10000 linhas. Um ROW_NUMBER() transforma os números em um número crescente que varia de 1 a 10000. O próximo snapshot_base CTE usa esse número crescente para executar uma função DATEADD() sobre uma data de início especificada, ‘2020-01-01 07:00:00’, para gerar uma lista de datas diárias. Isso é feito uma vez no tipo de dados datetime2 e uma vez no tipo de dados date. O último CTE snapshot_extended adiciona metadados como MÊS, ANO, etc. Por fim, colunas booleanas, que marcam o início e o fim de semanas, meses, trimestres e anos., são adicionadas. Tudo é então inserido na tabela de datas de referência.
Essa tabela de data de referência agora pode criar e carregar uma tabela de ponto no tempo (PIT). A tabela PIT pré-calcula para cada SDTS (carimbo de data/hora de data de snapshot), qual entrada de satélite é válida para cada chave de negócios. A granularidade de um PIT é (número de instantâneos) * (número de chaves de negócios) = contagem de linhas no PIT. O código a seguir cria e preenche um exemplo simples de PIT para lojas:
O único pit_entries CTE define todo o conjunto de entradas PIT. O hub de armazenamento é unido à tabela de instantâneo somente quando o hub aparece antes do SDTS para reduzir o número de linhas. Mas como não há uma condição JOIN mais específica, após essa junção, o número de linhas já é um múltiplo do número de linhas no hub.
Em seguida, o único satélite anexado ao hub da loja é ingressado, store_address_crm_lroc_sat. Ele é unido na chave de hash e, além disso, o load_date e o load_end_date são aproveitados para determinar o registro válido para um SDTS específico usando a função BETWEEN.
A lista SELECT desta CTE apresenta um novo conceito, uma chave dimensional, hk_d_store, gerada pelo hash da chave de hash do hub de armazenamento e do SDTS. Isso cria uma nova coluna exclusiva que pode ser usada para a restrição de chave primária e cargas incrementais. Além disso, ambos os componentes dessa chave dimensional, hk_store_hub e snapshot_datetime, são selecionados. A chave de hash e a carga, datetime do satélite, também são escolhidas para identificar exclusivamente uma linha do satélite. Eles são renomeados para incluir o nome do satélite, o que ajuda ao conectar vários satélites em vez de apenas um. Um PIT típico sempre reúne todos os satélites conectados a um hub específico. Portanto, um PIT típico tem várias combinações de chave de hash e colunas load_datetime.
Esse PIT agora pode ser usado como ponto de partida para uma dimensão de armazenamento baseada em instantâneo. Para produzir uma dimensão de armazenamento historizada (SCD Tipo 2), o PIT é unido ao hub e ao satélite:
Com todo o histórico pré-calculado em nosso PIT, a dimensão real pode ser virtual novamente porque a única operação necessária é um INNER-JOIN.
Informações e padrões adicionais sobre tabelas PIT e bridge podem ser encontrados no Blog Scalefree.
Conclusão
O Data Vault foi projetado para integrar dados de várias fontes de dados, destruir criativamente os dados em seus componentes fundamentais e armazená-los e organizá-los para que qualquer estrutura de destino possa ser derivada rapidamente. Este artigo se concentrou na geração de modelos de informação, geralmente modelos dimensionais, usando entidades virtuais. Eles são usados na arquitetura de dados para fornecer informações. Afinal, os modelos dimensionais são mais fáceis de consumir por soluções de painéis, e os usuários corporativos sabem como usar dimensões e fatos para agregar suas medidas. No entanto, as tabelas PIT e bridge geralmente são necessárias para manter o nível de desempenho desejado. Eles também simplificam a implementação de entidades de dimensão e fato e, por esses motivos, são frequentemente encontrados em plataformas de dados baseadas no Data Vault.
Fonte: Blog Microsoft Tech Community.
Transforme seus dados em estratégia com a DataEX
A implementação do Data Vault 2.0 e do Azure Synapse é um passo essencial para garantir uma estrutura de dados robusta e eficiente. No entanto, transformar essas tecnologias em resultados concretos exige experiência e uma abordagem estratégica. A DataEX é especializada em soluções de engenharia de dados e inteligência artificial, ajudando empresas a extrair insights valiosos para otimizar processos e impulsionar a tomada de decisão.
Se você deseja potencializar sua gestão de dados e garantir que sua empresa aproveite ao máximo o poder do Azure Synapse e do Data Vault 2.0, entre em contato com a DataEX. Agende uma reunião com nossos especialistas e descubra como podemos transformar seus desafios de dados em oportunidades estratégicas para o seu negócio.
Preencha o formulário e nosso time entrará em contato.
E nos siga em nossas redes sociais e leia o blog Data Universe diariamente.
