O Automatizado, Nenhum código Pilha de dados
Saiba como Astera O Data Stack pode simplificar e agilizar o gerenciamento de dados da sua empresa.
Carregando Dados em Fatos e Dimensões — Um Pedaço de Bolo?
KimballA modelagem dimensional de estilo tem sido a arquitetura preferida da maioria dos desenvolvedores de data warehouse nas últimas duas décadas. A natureza desnormalizada desses esquemas, juntamente com a otimização para manutenção do histórico, torna o modelo dimensional uma ferramenta ideal para o arsenal de armazenamento de dados, especialmente para geração de relatórios por meio de inteligência de negócios (BI).
À primeira vista, a ideia é simples: as tabelas de fatos contêm informações transacionais e as dimensões fornecem contexto a esses fatos por meio de relacionamentos de chave estrangeira. As questões que surgem, entretanto, são as seguintes: Quão fácil é carregar e manter dados em tabelas de fato e dimensão? E vale a pena o esforço?
Vamos pegar um cenário onde você configurou uma arquitetura para seu data warehouse — um esquema em estrela simples que consiste em informações de vendas na tabela de fatos, cercado por algumas dimensões, como clientes, fornecedores, etc. Os dados de origem inicialmente provenientes de sistemas distintos foram carregados em uma camada de preparação unificada.
O objetivo é configurar um processo de carregamento e manutenção para suas tabelas de dimensões e fatos. Carregar dados em tabelas de dimensão pode ser simples, já que você não está procurando manter o histórico. Nesse caso, você deseja apenas atualizar os registros de destino, o que pode ser feito por meio de Alterar lentamente as dimensões Tipo 1 (SCD1). Aqui está um trecho de como seria essa consulta:
No entanto, é improvável que isso seja suficiente em um cenário de negócios prático. É importante manter pelo menos algum histórico em um data warehouse para identificar tendências e padrões. É aí que outros tipos de SCD mais complicados entram em ação, como SCD 2, 3 e 6.
Se você pretende usar SCD 2 ou 6 em determinados campos, a tabela também precisa conter identificadores de registro para reconhecer a linha ativa para cada registro. Isso pode ser um sinalizador verdadeiro/falso, um intervalo de data de expiração efetivo ou apenas um número de versão para cada registro, para citar alguns exemplos.
Caso pretenda usar o SCD 3 ou 6, seria necessário um campo adicional para armazenar o valor anterior do campo em questão.
Veja como seria uma parte da consulta se você usasse o SCD 2 ou 6 para manter o histórico:
Está começando a parecer um pouco complicado? Nós apenas tocamos a ponta do iceberg.
Você provavelmente precisaria de diferentes níveis de histórico para diferentes campos. Digamos, por exemplo, que você tenha uma dimensão de funcionário que contenha informações de salário e número de telefone dos funcionários. Aqui, você pode acompanhar como o salário de um funcionário está mudando, mas apenas atualizar o número de telefone.
Para casos como este, você usaria vários tipos de SCD; SCD 1 para os campos que exigem apenas atualizações e SCD 2, 3 ou 6 para os campos que exigem a manutenção de um determinado nível de histórico. Com tantas coisas para levar em conta, você pode imaginar como a consulta ficaria complexa!
Até agora, nos concentramos no preenchimento e manutenção de tabelas de dimensão. Essas dimensões fornecem contexto para as informações armazenadas nas tabelas de fatos. Portanto, toda alteração em uma tabela de dimensão também é propagada para a tabela de fatos; garantir que essa propagação seja feita com precisão pode ser um desafio.
Algumas das informações que você precisa carregar na tabela de fatos não estão disponíveis na fonte. As chaves substitutas usadas para estabelecer relacionamentos entre dimensões e tabelas de fatos não existem na camada de preparação — elas foram criadas como chaves geradas pelo sistema em cada dimensão.
Portanto, você precisaria criar um mecanismo que usa pesquisas de dimensão para levar cada chave comercial (natural) de entrada da camada de preparação para a dimensão relevante e buscar a chave substituta ativa para esse registro. Além disso, as complexidades de buscar essas chaves substitutas variam de acordo com o tipo de SCD usado para cada campo e o identificador de linha presente na tabela de dimensões.
Como se esse processo não fosse complexo o suficiente, aqui está outra bola curva para você: e se você tiver algumas entradas ausentes na tabela de fatos que não requerem a chave substituta mais atualizada? Você pode usar uma chave de data de transação para determinar a chave substituta ativa, desde que tenha usado um identificador de linha ativa específico de registro de data e hora, como o intervalo de datas de expiração efetiva.
A situação também pode ser inversa: você pode ter algumas entradas na tabela de fatos que se referem a um registro de dimensão que ainda não foi adicionado à tabela de dimensões. Este é um enigma comum de armazenamento de dados - dimensões que chegam tarde e fatos que chegam cedo. Para atender a esse problema, você pode criar um registro fictício na tabela de dimensões em tempo de execução.
Esse registro acabaria sendo substituído pelo registro de dimensão apropriado (atrasado) vindo da origem. Mas pelo menos permitiria que a pesquisa de dimensão ocorresse no momento certo, sem soluços desnecessários.
Em suma, carregar dados na tabela de fatos pode ser um processo tedioso e sujeito a erros. Se os problemas destacados acima não forem resolvidos. Por exemplo, seus pipelines podem travar ou seu warehouse pode acabar contendo dados imprecisos.
Aqui está um exemplo de consulta que pode carregar dados em uma tabela de fatos:
Digamos que você faça tudo. Você digitou com sucesso todas as consultas necessárias e elas estão perfeitas. Seu trabalho ainda não está completo. Um processo de armazenamento de dados nunca está completamente concluído porque a manutenção do ecossistema é tão importante quanto projetá-lo em primeiro lugar. Para maximizar o desempenho, você precisa garantir que os dados sejam carregados de forma incremental, exigindo que o mecanismo Change Data Capture (CDC) seja implementado.
Além disso, essas consultas complexas precisariam de atualizações frequentes, dependendo das necessidades do negócio. Você pode ter que adicionar ou remover campos, alterar certos tipos de dados, alterar o tipo de SCD aplicado a um campo, etc. Fazer essas alterações nas consultas não é apenas demorado, mas também extremamente propenso a erros. Antes que você perceba, você pode ter bagunçado um pipeline existente ao implementar uma pequena alteração no mecanismo de carregamento.
Apesar desses possíveis problemas de manutenção, você ainda sentiria que a maior parte do trabalho duro está concluída. No entanto, as empresas estão constantemente procurando modernizar e melhorar seus processos de dados. Pode chegar o dia em que sua empresa decidir mudar de plataforma de data warehouse. Digamos que eles decidiram migrar do SQL Server local para uma plataforma de nuvem como Floco de neve or Amazon RedShift.
Você percebe o que isso exigiria? Primeiro, você deve criar uma nova arquitetura na nova plataforma. Em seguida, reescreva todas as consultas para configurar pipelines nativos para as novas tabelas de destino. Você basicamente teria que executar todo o processo novamente - do zero! Portanto, com base em tudo o que revelamos, é seguro concluir que carregar dados em tabelas de fatos e dimensões é NÃO muito fácil. O nível de complexidade envolvido pode se tornar muito alto, mesmo para usuários técnicos.
Mas e se eu te disser que existe uma forma muito mais fácil de atingir o mesmo resultado?
Com o Astera Construtor de Data Warehouse, você pode construir uma arquitetura para o seu modelo dimensional usando o designer de modelo de dados intuitivo. Além disso, a interface clicar e apontar permite atribuir funções, como tipos de SCD, identificadores de linha ativos, chaves de data de transação, etc., aos campos de fato e tabelas de dimensão.
Mais importante ainda, você pode aproveitar as informações em seus modelos no componente ETL/ELT baseado em arrastar e soltar da ferramenta para automatizar as tarefas tediosas e demoradas envolvidas no carregamento de tabelas de fatos e dimensões - desde a manutenção de SCDs em dimensões até a execução pesquisas de dimensão em tabelas de fatos. O código complicado que vimos anteriormente é gerado automaticamente pela ferramenta.
Por que perder tanto tempo e esforço escrevendo consultas enormes quando você pode obter o mesmo resultado usando uma interface visual simples? Embora o carregamento de dados em fatos e dimensões normalmente não seja fácil, com Astera Construtor de Data Warehouse, pode ser!
Se você quiser explorar a maneira ágil de construir seu data warehouse, entre em contato conosco em [email protegido] hoje ou baixe um 14-day free trial.
