Manipulando Slowly Changing Dimensions (SCD) usando Delta Tables
Lidando com o desafio de Slowly Changing Dimensions (SCD) usando o Delta Framework
Já a algum tempo venho pensando em comentar sobre o assunto aqui no blog, e a poucos dias atrás encontrei um post aqui no Medium e resolvi apenas “traduzi-lo” e adicionar alguma coisa, mas deixando bem claro que todos os direitos são reservados ao autor principal, segue abaixo link do post original.
Por muito tempo, o método Kimball foi um padrão para técnicas de modelagem de dados dimensionais. De acordo com Kimball “ A noção de tempo permeia todos os cantos do data warehouse ”. O que isso significa no contexto da análise de dados? Em um alto nível, a análise moderna pode ser vista como a agregação de dados que mudam constantemente com o passar do tempo. O problema é que os dados em constante mudança não incluem apenas novas adições, mas também alterações em conjuntos de dados anteriores.
A modelagem de dados dimensionais gerais agrupa os dados em duas categorias principais:
Fatos — Esses dados representam conjuntos de dados ilimitados que armazenam medições de entidades. Ele contém dados essenciais para análises quantitativas e tomadas de decisão. As tabelas de fatos frequentemente têm colunas que se juntam a outras tabelas (dimensões) para referência.
Dimensões — Esses dados representam conjuntos de dados relativamente limitados que fornecem informações descritivas sobre as medições realizadas nas tabelas de fatos. Em comparação com as tabelas de fatos, as dimensões evoluem em um ritmo muito mais lento. Esta é a razão pela qual eles são comumente referidos como “ dimensões que mudam lentamente ”.
A abordagem de Kimball envolve a criação de um esquema em estrela com base em fatos e dimensões. Devido à estrutura desnormalizada, o esquema em estrela é adequado para casos de uso analítico… sem necessidade de condições complexas de junção. Por esse motivo, por vários anos, o esquema em estrela tem sido um padrão de fato para modelagem em data warehouses tradicionais.
Quer saber mais sobre Modelagem Dimensional, consulte o post abaixo:
Slowly Changing Dimensions (SCD), ou Dimensões que Mudam Lentamente em português, é um conceito utilizado em Business Intelligence (BI) para gerenciar mudanças em dados de dimensões ao longo do tempo.
As dimensões representam aspectos de negócios que são importantes para a análise, como clientes, produtos, localizações e tempo. À medida que os dados de dimensão mudam ao longo do tempo, é necessário gerenciar essas mudanças para manter a integridade dos dados históricos e permitir análises precisas.
Por muitos anos, os manipuladores de dados enfrentaram o desafio de lidar com slowly changing dimensions sem perder seu histórico anterior, bem como preservar a referência relacional às tabelas de fatos. O método Kimball propõe vários métodos para lidar efetivamente com slowly changing dimensions ou SCD em resumo. A realidade é que, uma vez que um determinado método SCD é escolhido, é relativamente fácil implementá-lo em um data warehouse. O suporte para transações SQL e ACID facilita o manuseio.
Infelizmente, implementar o mesmo no data lake é uma história diferente. Existem algumas razões para isso:
- O primeiro problema é a imutabilidade . De acordo com as práticas recomendadas, os dados em um data lake não devem ser alterados.
- Em segundo lugar, por vários anos não foi possível realizar gravações atômicas em um data lake. Isso significa que você precisa reescrever a tabela inteira, mesmo se tiver uma pequena edição.
A estrutura do Delta Lake aborda os problemas acima. O suporte para transações ACID (atomicidade, consistência, isolamento e durabilidade) agora torna possível implementar o SCD com a mesma facilidade de um data warehouse. Neste post traduzido do original, aprenderemos como implementar os métodos mais comuns para lidar com dimensões que mudam lentamente usando a estrutura Delta Lake.
Considere um exemplo de cenário de caso abaixo:
“Uma empresa deseja acompanhar a dimensão do cliente para as mudanças que ocorrem ao longo do tempo. Eles solicitaram que seu grupo de engenharia de dados sugerisse algumas alternativas. Após uma consideração cuidadosa, a engenharia de dados apresentou três opções para gerenciar as slowly changing dimensions SCD Tipo 1, SCD Tipo 2 e SCD Tipo 3”
Antes de passarmos para cada opção, vamos tentar entender a estrutura de dados da dimensão do cliente. Ao longo deste post, usaremos os conjuntos de dados de amostra abaixo. O conjunto de dados abaixo mostra alguns exemplos de registros de clientes. Para explicar as diferentes opções para lidar com dimensões que mudam lentamente, nosso foco permanecerá no registro do cliente destacado usando uma caixa vermelha (cliente com nome = Magee Cash ).
Magee Cash mudou recentemente de endereço. Os registros de alteração são entregues como registros CDC ao sistema OLAP . No contexto da engenharia de dados, o processo CDC visa capturar conjuntos de dados incrementais de fontes e mesclá-los em data lakes corporativos. A seguir está o registro de alteração para Magee Cash , observe que o endereço é diferente do registro original acima.
Quer saber mais sobre CDC usando AWS DMS— Change Data Capture, consulte o post abaixo:
Os principais recursos do Delta Lake o tornam uma plataforma extremamente adequada para a construção de uma arquitetura moderna de data lakehouse . Na arquitetura Lakehouse, o Delta Lake pode ser usado para mesclar registros de alterações em uma camada de dados comum (prata — silver). Depois de criada, a camada de prata atua como a camada de dados fundamental para suas cargas de trabalho analíticas, incluindo BI, ciência de dados, aprendizado de máquina e inteligência artificial. Por esta razão, a camada de prata é muitas vezes referida como a “ única fonte da verdade ” em inglês: “single source of truth”).
Vamos voltar ao objetivo principal deste artigo. Agora que temos uma compreensão clara dos conjuntos de dados, estamos prontos para explorar o primeiro método SCD.
SCD tipo 1
Esse tipo geralmente é chamado de método “ Sobrescrever ”. Nesse método, quaisquer alterações nos dados de dimensão simplesmente substituem o estado anterior dos dados com a mesma chave. Embora muito simples de implementar, este método sofre de uma grande desvantagem. Devido ao mecanismo de substituição, você não apenas perde o histórico anterior da dimensão, mas também o estado da tabela de fatos à qual ela é anexada. A imagem antes e depois da dimensão do cliente usando o método SCD tipo 1 é mostrada abaixo.
Observe como o antigo endereço residencial é simplesmente substituído pelo endereço novo, o histórico do endereço anterior é perdido. As repercussões da perda do histórico podem ser graves nos casos em que uma agregação da tabela de fatos é afetada pela alteração na dimensão. Nesse caso, sem o histórico, torna-se extremamente difícil rastrear o motivo pelo qual o valor de agregação foi afetado.
Agora aprenderemos como o SCD Tipo 1 pode ser implementado usando a estrutura Delta. Comece criando a tabela de dimensões do cliente da camada prata ( customer_silver_scd1 ) usando os dados brutos do cliente definidos na camada bronze do Lakehouse.
Crie um novo dataframe usando o registro de alteração para Magee Cash .
Por fim, mescle o registro de mudança de endereço na tabela de dimensões da camada de prata customer_silver_scd1 .
Depois de realizar uma consulta na tabela de dimensões da camada de prata, você notará que a mudança de endereço substituiu seu estado anterior. O problema é que o estado anterior deste registro não é visto em lugar nenhum.
Considere um cenário em que a Magee Cash pode ter feito um pedido de comércio eletrônico usando a versão anterior do endereço. O produto ainda não foi enviado, mas o endereço mudou entretanto. Para onde o produto deve ser enviado? O endereço antigo ou o novo.
Deixe-me apresentar a você um recurso muito útil na estrutura do Delta Lake. Delta Lake mantém um histórico cronológico de alterações, incluindo inserções, atualizações e exclusões. No exemplo acima, a versão 0 da tabela foi gerada quando a tabela de camada de prata customer_silver_scd1 foi criada. Da mesma forma, a versão 1 da tabela foi criada quando realizamos a mesclagem de dados para a alteração do registro de endereço. Além disso, as tabelas do Delta Lake podem ser facilmente restauradas para qualquer versão anterior, conforme desejado.
Devido às deficiências citadas acima, o SCD Tipo 1 raramente é usado em plataformas de dados modernas. Portanto, precisamos de métodos melhores, que nos permitam realizar alterações nas dimensões, preservando as referências anteriores para usos ativos. No geral, basta usar o SCD Tipo 1 se seus cálculos não se importarem com o estado anterior dos dados ou com as repercussões que isso causa no futuro.
SCD Tipo 2
Também conhecido como método “ Adicionar um novo registro ”. Nesse método, o registro de alteração é adicionado como um novo registro à tabela de dimensões e marcado como “ Atual ” ou “ Ativo ”. Além disso, a versão anterior do registro é marcada como “ Expired ” ou “ Inactive ”. As várias versões (atual e histórica) de um registro são ligadas usando uma chave substituta . No nível da tabela, o SCD Tipo 2 é implementado adicionando colunas de carimbo de data/hora StartDate e EndDate para cada linha na tabela de dimensões. Além disso, uma coluna de status é adicionada para marcar se o registro é atual ou expirado status. A imagem antes e depois da dimensão do cliente usando o método SCD Tipo 2 é mostrada abaixo.
Agora aprenderemos como o SCD Tipo 2 pode ser implementado usando a estrutura delta. Comece criando a tabela de dimensões do cliente da camada prata ( customer_silver_scd2 ) usando o conjunto de dados brutos do cliente na camada bronze do Lakehouse.
Agora, mescle o registro de mudança de endereço na tabela de dimensões da camada de prata customer_silver_scd2 .
Observe que o registro anterior foi marcado como Expirado e uma data final é atualizada. Além disso, um novo registro com o endereço mais recente foi inserido com a data de início igual à data de término do registro anterior. Usando essa abordagem, Magee Cash certamente receberá seu pedido de comércio eletrônico enviado para o endereço correto.
Usando a abordagem SCD Tipo 2, você pode rastrear cronologicamente o histórico de alterações ao longo do tempo e manter as referências a tabelas de fatos de maneira cronológica. Devo admitir que a implementação é um pouco complicada em comparação com o SCD Tipo 1.
Como alerta, o aplicativo que mantém a tabela de dimensões precisa ser codificado de forma que a adição do novo registro com a versão atual e a expiração da versão anterior sejam realizadas em uma única transação. Além disso, toda consulta que vai contra a tabela de dimensão precisa filtrar status= Current .
Existe uma alternativa mais simples, ainda exploramos outro método que, de certa forma, é simplesmente uma extensão do método SCD Tipo 1.
SCD Tipo 3
Também conhecido como método “ Adicionar um novo campo ”. Para cada alteração, a versão anterior e a versão atual são armazenadas como duas colunas distintas na mesma linha da tabela de dimensões. O SCD Tipo 3 é relativamente mais fácil de implementar em comparação com o SCD Tipo 2, o histórico inclui apenas as versões atual e anterior.
Agora aprenderemos como o SCD Tipo 3 pode ser implementado usando a estrutura delta. Comece criando a tabela de dimensões do cliente da camada prata ( customer_silver_scd3 ) usando o conjunto de dados brutos do cliente na camada bronze.
Observe que cada coluna na tabela de dimensão mantém um estado atual e anterior . No momento da criação da tabela de dimensões, o estado atual da coluna é preenchido com os dados mais recentes, mas o estado anterior da coluna é deixado em branco.
Agora, mescle o registro de mudança de endereço na tabela de dimensões da camada de prata customer_silver_scd3 .
Seguindo em frente para verificar o estado do registro após a fusão do lago delta.
Observe que o campo de address agora está preenchido com o registro alterado e a versão anterior do endereço foi movida para o campo Previous_address . Da mesma forma, o campo de data modificada foi atualizado para manter uma cronologia de alteração.
O fato de que apenas uma quantidade limitada de histórico está disponível torna o caso de uso do SCD Tipo 3 um pouco limitado. Mas a facilidade de implementação o torna um tanto desejável. É uma boa compensação se você odeia as limitações do SCD Tipo 1 e acha o SCD Tipo 2 difícil de implementar e gerenciar.
Todo o código usado neste post pode ser encontrado no link abaixo:
Em muitos aspectos, o SCD tipo 2 é frequentemente considerado a técnica principal para implementar slowly changing dimensions. Deve ficar claro que o objetivo principal do SCD não é armazenar o histórico de registros ao longo do tempo, mas sim manter uma associação precisa com as tabelas de fatos. Além disso, em muitos aspectos, as slowly changing dimensions exigem que você atualize os registros, o que, em termos gerais, vai contra os princípios da natureza imutável do data lake/warehouse. No entanto, novos avanços feitos por frameworks como o Delta Lake tornaram possível a implementação de cenários SCD com facilidade e simplicidade .
Existem mais 2 tipos, mas estes só explicaremos bem por cima, só realmente para conhecimento, vamos lá…
SCD Tipo 4
Além dos 3 tipos informados acima, temos mais alguns, como por exemplo o SCD do tipo 4, veja um exemplo:
- É uma mistura de SCD Tipo 1 e 2
- Instantâneos históricos são mantidos em uma tabela de histórico separada
Exemplo: Na ilustração acima, o sistema OLAP foi projetado para ter duas tabelas de data warehouse. Uma tabela replica o sistema OLTP, enquanto a outra tabela mantém o instantâneo histórico.
- Essa técnica funciona, como um encanto, quando os valores da dimensão mudam com frequência e a maioria das análises deve ser feita em um instantâneo atual dos dados. Vale a pena armazenar dados históricos, mas raramente os extraímos.
SCD Tipo 6
O SCD Híbrido (conhecido também como SCD Tipo 6), combina todas os SCD anteriores. Isso o torna bastante flexível para as atualizações das dimensões, porém com um grande custo de complexidade.
Outros tipos de tabelas dimensão
Além das SLOWLY CHANGING DIMENSIONS, também temos:
DEGENERATE DIMENSION — Dimensão degenerada é uma chave de dimensão na tabela fato que não possui sua própria tabela de dimensão, ou seja, é a dimensão que não mereceu ser uma dimensão e foi inserida como coluna na tabela fato pois todos os atributos interessantes foram colocados em dimensões analíticas. O termo “dimensão degenerada” foi originado por Ralph Kimball.
ROLE-PLAYING DIMENSION — Uma única dimensão pode ser referenciada várias vezes em uma tabela fato, com cada referência vinculada a uma função logicamente distinta para a dimensão. Por exemplo, uma tabela fato pode ter várias datas, cada uma delas representada por uma chave estrangeira para a dimensão da data. É essencial que cada chave estrangeira se refira a uma visão separada da dimensão da data, para que as referências sejam independentes.
CONFORMED DIMENSION — As tabelas de dimensões estão em conformidade quando os atributos em tabelas de dimensões separadas têm os mesmos nomes de coluna. As informações de tabelas fato separadas podem ser combinadas em um único relatório usando atributos de dimensão conformes que estão associados a cada tabela de fato. As dimensões conformes definidas uma vez em colaboração com os representantes de governança de dados da empresa são reutilizadas em tabelas fato fornecendo eles fornecem consistência analítica e custos futuros reduzidos.
JUNK DIMENSION — A dimensão lixo é simplesmente uma estrutura que fornece um local para armazenar os atributos ou uma coleção de códigos transacionais aleatórios que não estão relacionados a nenhuma dimensão específica. Esses tipos de atributos não se integram facilmente às dimensões convencionais, como Cliente, Fornecedor e Produto, no entanto, alguns dos atributos diversos contém dados que têm um valor comercial significativo, dessa forma são armazenados em uma dimensão lixo. fonte.
Alguns tipos de Tabelas Fato
Transactional — Uma tabela fato transacional é a mais comum em tabelas fato, a granularidade associada a uma tabela de fato transacional é geralmente especificada como uma linha por linha em uma transação. Normalmente, uma tabela fato transacional contém dados do nível mais detalhado de negócio, fazendo com que tenha um grande número de dimensões associadas.
Aggregate — Tabelas fato agregadas são usadas em modelos dimensionais do data warehouse para produzir um resumo de informações pré-calculadas, as agregações geralmente são pré-computadas podendo ser carregada diretamente da fonte de dados ou da tabela fato transacional alterando a granularidade para um nível mais alto. Com os dados resumidos carregados na tabela agregada o volume de dados é menor obtendo-se um ganho de performance considerável nas consultas comparado com um fato transacional.
Periodic snapshots — As tabelas snapshots periódico registram dados que é instantâneo em um período de tempo predefinido, podendo ser diariamente, semanalmente ou mensalmente. Como o nome indica tira-se uma “imagem do momento” em que o fato ocorreu, os dados de origem da tabela snapshot periódico são dados de uma tabela de fato transacional em que se escolhe um período a ser capturado.
Accumulating snapshots — As tabelas de snapshots acumulado descreve a atividade de um processo de negócios que possui início e fim. Esse tipo de tabela de fato possui várias colunas de data para representar marcos no processo. A medida em que as etapas do processo forem sendo concluídas o registro correspondente na tabela de fato é atualizado.
Factless Fact Tables — As tabelas de fato sem fato são encontradas na modelagem de data warehouse esta tabela não possui nenhuma medida ela contém apenas chaves estrangeiras para tabelas dimensionais, sendo suficiente para responder a questões relevantes. As tabelas de fatos sem fatos também podem ser usadas para analisar o que não aconteceu, essas consultas sempre têm duas partes: uma tabela de cobertura sem fatos que contém todas as possibilidades de eventos que podem acontecer e uma tabela de atividades que contém os eventos que ocorreram. Quando a atividade é subtraída da cobertura, o resultado é o conjunto de eventos que não ocorreram. fonte.
Vejam também
Espero que tenham gostado! Caso tenham dicas de materiais neste sentido, podem deixar nos comentários… Gratidão!
