Modelagem de dados
As decisões de modelagem de dados dependem de como sua organização e as cargas de trabalho utilizam as tabelas, e o modelo escolhido afeta o desempenho das consultas, os custos de compute e os custos de armazenamento. Esta página aborda os comportamentos do Databricks que influenciam a modelagem de dados, para usuários que configuram novas tabelas ou criam cargas de trabalho de ETL.
Este artigo se aplica exclusivamente a mesas apoiadas por Delta Lake, o que inclui todas as mesas Unity Catalog gerenciar.
O senhor pode usar o site Databricks para consultar outras fontes de dados externas, inclusive tabelas registradas na Lakehouse Federation. Cada fonte de dados externa tem limitações, semânticas e garantias transacionais diferentes. Consulte Dados da consulta.
Conceitos de gerenciamento de banco de
Uma lakehouse construída com a Databricks compartilha muitos componentes e conceitos com outros sistemas de data warehousing corporativos. Considere os seguintes conceitos e recursos ao projetar seu modelo de dados.
Transações sobre Databricks
Por default, o Databricks define o escopo das transações para tabelas individuais. Para cargas de trabalho de modelagem de dados, isso se traduz na necessidade de realizar múltiplas 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 ter sucesso ou falhar independentemente de outras transações, e as queries downstream precisam ser tolerantes a incompatibilidades de estado devido a transações falhas ou atrasadas.
Tabelas com catalog commits habilitados podem participar de transações que abrangem múltiplas instruções e múltiplas tabelas. Consulte Transações.
Chave primária e estrangeira no Databricks
As chaves primária e estrangeira são 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. Consulte Restrições em Databricks.
participar Databricks
pode introduzir gargalos de processamento em qualquer projeto de banco de dados. Ao processar dados em Databricks, o otimizador de consultas procura otimizar o plano de junção, mas pode ter dificuldades quando uma consulta individual precisa join resultados de muitas tabelas. O otimizador também pode não ignorar registros em uma tabela quando os parâmetros do filtro estão em um campo em outra tabela, o que pode resultar em uma verificação completa da tabela.
Consulte Trabalhar com o join em Databricks.
Trabalhando com tipos de dados aninhados e complexos
A Databricks suporta fontes de dados semiestruturadas, incluindo JSON, Avro e Protobuf, e armazena dados complexos como structs, strings JSON e mapas e arrays. Consulte Modelagem de dados semiestruturados.
Modelos de dados normalizados
O Databricks pode funcionar bem com qualquer modelo de dados. Se o senhor tiver um modelo de dados existente que precise ser consultado ou migrado para o Databricks, deverá avaliar o desempenho antes de rearquitetar seus dados.
Se estiver arquitetando um novo lakehouse ou adicionando um conjunto de dados a um ambiente existente, o Databricks recomenda não usar um modelo altamente normalizado, como a terceira forma normal (3NF).
Modelos como o esquema em estrela ou o esquema em floco de neve têm um bom desempenho no Databricks, pois apresentam menos junções 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 consultas ignore grandes quantidades de estatísticas de uso de dados em nível de arquivo. Para mais informações sobre omitir dados, consulte Omitir dados.