Modelação de dados

Este artigo apresenta considerações, advertências 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 de 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 de banco de dados com o Azure Databricks.

Importante

Este artigo se aplica exclusivamente a tabelas apoiadas pelo Delta Lake, que inclui todas as tabelas gerenciadas pelo Unity Catalog.

Você pode usar o Azure Databricks para consultar outras fontes de dados externas, incluindo tabelas registradas na Lakehouse Federation. Cada fonte de dados externa tem diferentes limitações, semânticas e garantias transacionais. Consulte Dados de consulta.

Conceitos de gerenciamento de banco de dados

Uma lakehouse construída com o Azure Databricks partilha muitos componentes e conceitos com outros sistemas de armazenamento de dados empresariais. Considere os seguintes conceitos e recursos ao projetar seu modelo de dados.

Transações no Azure Databricks

O Azure Databricks delimita as transações a tabelas individuais. Isso significa que o Azure Databricks não oferece suporte a instruções de múltiplas tabelas (também chamadas de transações de múltiplas instruções).

Para cargas de trabalho de modelagem de dados, isso se traduz em ter que executar várias transações independentes quando a ingestão de um registro de origem requer a inserção ou atualização de linhas em duas ou mais tabelas. Cada uma dessas transações pode ser bem-sucedida ou falhar independentemente de outras transações, e as consultas downstream precisam ser tolerantes à incompatibilidade de estado devido a transações com falha ou atraso.

Chaves primárias e estrangeiras no Azure Databricks

As 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. Consulte Restrições no Azure Databricks.

Junta-se ao Azure Databricks

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

Consulte Trabalhar com associações no Azure Databricks.

Nota

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. Ver Vistas materializadas.

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, e ao armazenamento de dados complexos como structs, cadeias de caracteres JSON e mapas e matrizes. Consulte Modelo de dados semiestruturados.

Modelos de dados normalizados

O Azure Databricks pode funcionar bem com qualquer modelo de dados. Se você tiver um modelo de dados existente que precise consultar ou migrar para o Azure Databricks, avalie o desempenho antes de rearquitetar 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 altamente normalizado, como o terceiro formulário normal (3NF).

Modelos como o esquema em estrela ou o esquema de 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 sincronizadas. 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 no nível de arquivo. Para obter mais informações sobre a omissão de dados, consulte Omissão de dados para Delta Lake.