Modelagem de dados

Este artigo apresenta considerações, ressalvas e recomendações para modelagem de dados no Azure Databricks. Ele é direcionado para usuários que estão configurando novas tabelas ou criando cargas de trabalho ETL, com ênfase na compreensão dos comportamentos do Azure Databricks que influenciam a transformação de dados brutos em um novo modelo de dados. As decisões de modelagem de dados dependem de como sua organização e cargas de trabalho usam tabelas. O modelo de dados escolhido afeta o desempenho da consulta, os custos de computação e os custos de armazenamento. Isso inclui uma introdução aos conceitos fundamentais no design do banco de dados com o Azure Databricks.

Conceitos de gerenciamento de banco de dados

Uma lakehouse construída com o Azure Databricks compartilha muitos componentes e conceitos com outros sistemas de data warehouse corporativos. Considere os seguintes conceitos e recursos ao projetar seu modelo de dados.

Transações no Azure Databricks

O Azure Databricks define os escopos das transações para tabelas individuais. Isso significa que o Azure Databricks não dá suporte a instruções de várias tabelas (também chamadas de transações de várias instruções).

Para cargas de trabalho de modelagem de dados, isso se traduz em ter que executar várias transações independentes ao ingerir um registro de origem requer inserir ou atualizar linhas em duas ou mais tabelas. Cada uma dessas transações pode ter êxito ou falhar independentemente de outras transações, e as consultas downstream precisam ser tolerantes à incompatibilidade de estado devido a transações com falha ou atrasadas.

Chaves primárias e estrangeiras no Azure Databricks

Chaves primárias e estrangeiras são informativas e não impostas. Esse modelo é comum em muitos sistemas de banco de dados corporativos baseados em nuvem, mas difere de muitos sistemas de banco de dados relacionais tradicionais. Confira Restrições no Azure Databricks.

Junções no Azure Databricks

As junções podem introduzir gargalos de processamento em qualquer design de banco de dados. Ao processar dados no Azure Databricks, o otimizador de consulta busca otimizar o plano de junções, mas pode ter dificuldades quando uma consulta individual deve unir resultados de muitas tabelas. O otimizador também pode falhar ao ignorar registros em uma tabela quando os parâmetros de filtro estiverem em um campo em outra tabela, o que pode resultar em uma verificação completa da tabela.

Consulte Trabalhar com junções no Azure Databricks.

Trabalhando com tipos de dados aninhados e complexos

O Azure Databricks dá suporte ao trabalho com fontes de dados semiestruturadas, incluindo JSON, Avro e ProtoBuff, além de armazenar dados complexos como structs, cadeias de caracteres JSON e mapas e matrizes. Consulte dados semiestruturados do Modelo.

Modelos de dados normalizados

O Azure Databricks pode funcionar bem com qualquer modelo de dados. Se você tiver um modelo de dados existente que precisa consultar ou migrar para o Azure Databricks, deverá avaliar o desempenho antes de recriar a arquitetura dos seus dados.

Se você estiver arquitetando um novo lakehouse ou adicionando conjuntos de dados a um ambiente existente, o Azure Databricks recomenda não usar um modelo fortemente normalizado, como o terceiro formulário normal (3NF).

Modelos como o esquema estrela ou o esquema floco de neve têm um bom desempenho no Azure Databricks, pois há menos junções presentes em consultas padrão e menos chaves para manter a sincronização. Além disso, ter mais campos de dados em uma única tabela permite que o otimizador de consulta ignore grandes quantidades de dados usando estatísticas de nível de arquivo. Para obter mais informações sobre como ignorar dados, consulte Ignorar dados no Delta Lake.