Implementando um armazém de dados dimensional com Databricks SQL: Parte 1

Cada vez mais organizações estão transferindo suas cargas de trabalho de armazenamento de dados para o Databricks.  A natureza elástica da plataforma e as melhorias significativas em seu motor de execução de consultas permitiram que a Databricks estabelecesse recordes mundiais tanto em desempenho de consultas de armazenamento de dados quanto em desempenho de custos, tornando-a uma opção cada vez mais atraente para a consolidação da infraestrutura de análise.

Para apoiar esses esforços, já blogamos anteriormente sobre como a Databricks suporta várias abordagens de design de armazenamento de dados. Nesta série de blogs, queremos dar uma olhada mais de perto em uma das abordagens mais populares para o armazenamento de dados, a modelagem dimensional, um padrão de design caracterizado por estrela- e esquemas de floco de neve, e mergulhar profundamente nos padrões padronizados de extração, transformação e carregamento (ETL) amplamente adotados em suporte a essa abordagem. 

A modelagem dimensional otimiza o armazenamento de dados para um desempenho rápido de consultas. Ao estruturar dados em fatos e dimensões, você pode analisar facilmente os dados de várias perspectivas. Também permite que você explore os dados de vários ângulos simultaneamente (análise multidimensional). 

Para tornar isso amplamente acessível à comunidade de modelagem dimensional, vamos aderir de perto aos padrões clássicos associados a essa abordagem de modelagem. Essas informações serão distribuídas nos seguintes posts do blog:

• Parte 1: Definindo os Objetos de Dados (Dimensionais) (esta postagem)
• Parte 2: Construindo os Fluxos de Trabalho ETL Dimensionais 
• Parte 3: Construindo os Fluxos de Trabalho do Fact ETL (em breve)

Além disso, centraremos nossas discussões de design em torno de um dos esquemas estrela mais comumente usados (Figura 1) no AdventureWorksDW banco de dados, um banco de dados de exemplo criado pela Microsoft e amplamente utilizado para fins de treinamento em data warehouse e Business Intelligence.

O modelo físico

Dentro da Plataforma Databricks, fatos e dimensões são implementados como tabelas físicas. Estes são organizados dentro de catálogos, semelhantes a bancos de dados, mas com maior flexibilidade para a amplitude de ativos de informação que a plataforma suporta. Os catálogos são então subdivididos em esquemas, criando limites lógicos e de segurança em torno de subconjuntos de objetos no catálogo (Figura 2).

Tabela de dimensões

Tabelas de dimensão aderem a um conjunto relativamente rígido de padrões estruturais. Um identificador sequencial, uma chave substituta, é geralmente definida para suportar uma ligação estável e eficiente entre tabelas de fatos e a dimensão. Identificadores únicos de sistemas operacionais (frequentemente referidos como chaves naturais ou chaves de negócios), juntamente com uma coleção desnormalizada de atributos de negócios relacionados, geralmente seguem. Atrás dos identificadores, geralmente há uma série de colunas de metadados destinadas a suportar processos ETL contínuos. Dentro da Plataforma Databricks, podemos implementar uma tabela de dimensão usando a declaração CREATE TABLE, como é mostrado aqui para a dimensão do cliente:  

Colunas de identidade

Neste exemplo, para a coluna de chave substituta, CustomerKey, empregamos uma coluna de identidade que cria automaticamente um valor BIGINT sequencial para o campo à medida que inserimos linhas. Se usamos a opção SEMPRE ou POR PADRÃO com a coluna de identidade depende de queremos proibir ou permitir a inserção de nossos próprios valores para este campo.

Entrada de membro ausente

Um padrão comum implementado com tabelas de dimensão é a criação de uma entrada de membro ausente. Esta entrada é usada em cenários onde registros de fatos chegam com ligação ausente ou desconhecida para uma dimensão e pode ser criada com um valor de chave substituta pré-determinado como o que é mostrado aqui quando a opção POR PADRÃO é empregada:

Campos de identidade

Como uma boa prática, sempre que inserir valores em um campo de identidade, é melhor garantir que os metadados para o campo de identidade sejam atualizados através do uso de um comando ALTER TABLE com a opção SYNC IDENTITY empregada:

Tipo de dados

Para a chave de negócio/natural e outros campos vinculados a dados em sistemas de origem, precisaremos alinhar os tipos de dados do sistema de origem com aqueles tipos de dados suportados pela Plataforma Databricks (Tabela 1). Para campos de metadados onde um valor de bit é empregado, como 0 ou 1, observe que costumamos usar um tipo de dados INT em vez dos tipos de dados BOOLEAN ou TINYINT para facilitar um pouco o manuseio de literais.

Tabela 1. Os tipos de dados suportados pela Plataforma Databricks

Tabelas de fatos

As tabelas de fatos, também, seguem suas convenções estruturais. Compostas principalmente por medidas e referências de chave estrangeira para dimensões relacionadas, as tabelas de fatos também podem incluir identificadores únicos para registros de transações (ou outros atributos descritivos em uma relação quase um para um com os registros de fatos), referidos como dimensões degeneradas. Elas também podem incluir campos de metadados para suportar o carregamento incremental (também conhecido como delta extract) de dados de sistemas de origem. Dentro da Plataforma Databricks, podemos implementar uma tabela de fatos usando a instrução CREATE TABLE semelhante ao que é mostrado aqui para o fato de vendas na Internet:

Referências de chave estrangeira

Como mencionado na seção anterior sobre tabelas de dimensão, os tipos de dados no ambiente Databricks são mapeados de forma flexível para aqueles empregados pelos sistemas de origem. As referências de chave estrangeira entre as tabelas de fatos e dimensões também podem ser feitas explicitamente usando a instrução ALTER TABLE como mostrado aqui:

Nota: Se você preferir definir as restrições de chave estrangeira como parte da instrução CREATE TABLE, você pode simplesmente adicionar uma lista separada por vírgulas de cláusulas FOREIGN KEY (na forma  FOREIGN KEY (foreign_key) REFERENCES table_name (primary_key)  logo após a lista de definição de coluna.

Metadados e outras considerações

O apelo do modelo dimensional é sua relativa acessibilidade para analistas de negócios. Com isso em mente, muitas organizações adotam convenções de nomenclatura para fatos e dimensões, como os prefixos Fato e Dim nos exemplos acima, e incentivam o uso de nomes longos e autoexplicativos para tabelas e campos que muitas vezes desviam significativamente dos nomes empregados em sistemas operacionais de origem.

Com isso em mente, é importante notar as limitações do Databricks na nomeação de objetos. Estes incluem:

• Nomes de objetos não podem exceder 255 caracteres
• Os seguintes caracteres especiais não são permitidos:
  • Ponto (.)
  • Espaço ( )
  • Barra (/)
  • Todos os caracteres de controle ASCII (00-1F hex)
  • O caractere DELETE (7F hex)

Além disso, é importante notar que os nomes dos objetos não são sensíveis a maiúsculas e minúsculas e são, de fato, armazenados no repositório de metadados em letras minúsculas. Se isso pode criar problemas com a legibilidade do objeto, você pode considerar a adoção de um snake case convenção para melhorar a legibilidade de alguns nomes de objetos.

Independentemente de suas convenções de nomenclatura, é uma boa ideia definir comentários descritivos para todos os objetos e campos dentro do data warehouse. Isso é feito através do uso da instrução COMMENT ON para objetos de tabela e a instrução ALTER TABLE para campos individuais, como demonstrado aqui:

Essas e outras metadados (incluindo informações de linhagem) estão acessíveis através da interface do usuário do Databricks Catalog Explorer (Figura 3) e através de objetos no esquema de informações incorporado em cada catálogo.

Por fim, este blog aborda a criação de tabelas de fatos e dimensões puramente sob a perspectiva de aderir aos princípios de design dimensional. Se você quiser explorar algumas opções adicionais para a definição de tabela que consideram otimizações de desempenho e manutenção, confira este blog sobre otimização do desempenho do esquema estrela.

Próximos passos: implementando a ETL da tabela de dimensão

Depois de abordar os conceitos básicos por trás da criação de tabelas de fatos e dimensões, voltaremos nossa atenção no próximo blog para implementar os padrões de ETL que suportam tabelas de dimensões, com ênfase especial nos padrões de dimensão de mudança lenta do Tipo-1 e Tipo-2 usando tanto Python quanto SQL.

Para saber mais sobre o Databricks SQL, visite nosso website ou leia a documentação. Você também pode conferir o tour do produto Databricks SQL. Suponha que você queira migrar seu armazém existente para um armazém de dados sem servidor de alto desempenho, com uma ótima experiência do usuário e um custo total mais baixo. Nesse caso, o Databricks SQL é a solução — experimente gratuitamente.

(This blog post has been translated using AI-powered tools) Original Post