Modelagem de dados

Este artigo apresenta considerações, advertências e recomendações para a modelagem de dados em Databricks. Ele é voltado para usuários que estão configurando novas tabelas ou criando cargas de trabalho de ETL, com ênfase na compreensão dos comportamentos do 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 as cargas de trabalho usam as tabelas. O modelo de dados escolhido pelo senhor afeta o desempenho da consulta, os custos do compute e os custos de armazenamento. Isso inclui uma introdução aos conceitos básicos de design de banco de dados com o Databricks.

Importante

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 Federação lakehouse. Cada fonte de dados externa tem limitações, semânticas e garantias transacionais diferentes. Consulte Dados de consulta.

Conceitos de gerenciamento de banco de dados

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

O Databricks limita as transações a tabelas individuais. Isso significa que o Databricks não oferece 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 na necessidade de realizar várias transações independentes quando a ingestão de um registro de origem exige 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 com a incompatibilidade de estado devido a transações falhadas ou atrasadas.

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 empresariais baseados em cloud, mas é diferente 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 falhar ao ignorar 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 uniões no Databricks.

Trabalhar com tipos de dados aninhados e complexos

Databricks suporta o trabalho com fontes de dados semiestruturadas, incluindo JSON, Avro e ProtoBuff, e o armazenamento de dados complexos como structs, JSON strings, mapas e matrizes. Consulte Modelo 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 bom desempenho em Databricks, pois há menos junções presentes em consultas padrão e menos chaves para manter a sincronia. 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 obter mais informações sobre a omissão de dados, consulte Omissão de dados para o Delta Lake.