Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
As decisões de modelagem de dados dependem de como sua organização e cargas de trabalho usam tabelas e o modelo escolhido afeta o desempenho da consulta, os custos de computação e os custos de armazenamento. Esta página aborda os comportamentos de Azure Databricks que influenciam a modelagem de dados, para os usuários que configuram novas tabelas ou criarem cargas de trabalho ETL.
Importante
Este artigo aplica-se exclusivamente a tabelas apoiadas pelo Delta Lake, que inclui todas as tabelas gerenciadas do Catálogo do Unity.
Você pode usar o Azure Databricks para consultar outras fontes de dados externas, incluindo tabelas registradas no Lakehouse Federation. Cada fonte de dados externa tem limitações, semântica e garantias transacionais diferentes. Confira Consultar dados.
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 às 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 significa ter que realizar várias transações independentes quando a ingestão de um registro de origem exige inserir ou atualizar linhas em duas ou mais tabelas. Cada uma dessas transações pode ser bem-sucedida ou falhar independentemente das outras transações, e as consultas subsequentes precisam tolerar inconsistências de estado causadas por transações que falharam ou foram atrasadas.
Chaves primárias e estrangeiras no Azure Databricks
Chaves primárias e chaves estrangeiras são apenas informativas e não são aplicadas. 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 deixar de pular registros em uma tabela quando os parâmetros de filtro estão em um campo de outra tabela, o que pode resultar em uma varredura completa da tabela.
Consulte Trabalhar com junções no Azure Databricks.
Observação
Você pode usar exibições materializadas para calcular incrementalmente os resultados de algumas operações de junção, mas outras junções não são compatíveis com exibições materializadas. Confira Exibições materializadas.
Trabalhando com tipos de dados aninhados e complexos
Azure Databricks dá suporte ao trabalho com fontes de dados semiestruturadas, incluindo JSON, Avro e Protobuf, 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.