Quando particionar tabelas em Databricks

nota

O Databricks recomenda o clustering líquido para todas as tabelas gerenciadas. Para tabelas gerenciadas usando Apache Iceberg, o Unity Catalog oferece suporte apenas ao clustering líquido e interpreta colunas PARTITION BY como chaves de clustering. Consulte Converter uma tabela particionada para liquid clustering.

A maioria das tabelas no Databricks com menos de 100 TB de dados não precisa de particionamento. O Databricks usa o Delta Lake para todas as tabelas por default e agrupa automaticamente os dados em tabelas não particionadas pelo tempo de ingestão, de modo que você obtém desempenho semelhante ao particionamento sem ajuste manual. Considere uma estratégia de particionamento personalizada somente quando ela superar esses defaults. Consulte Usar clusters de tempo de ingestão.

Estratégias de particionamento personalizadas

Usuários avançados do Apache Spark e do Delta Lake podem identificar uma estratégia de particionamento que supera o clustering no momento da ingestão padrão.

atenção

Uma estratégia de particionamento ineficaz pode afetar negativamente o desempenho da query e exigir uma reescrita completa dos dados para correção. Uma reescrita completa pode ser muito cara e lenta para tabelas grandes.

Antes de usar estratégias de particionamento personalizadas, o Databricks recomenda clusters líquidos para todas as tabelas e otimização preditiva para tabelas gerenciadas do Unity Catalog. Consulte Usar clusters líquidos para tabelas e Otimização preditiva para tabelas gerenciadas do Unity Catalog.

Para converter uma tabela Delta Lake particionada existente para liquid clustering, use ALTER TABLE ... REPLACE PARTITIONED BY WITH CLUSTER BY. O liquid clustering funciona para colunas de baixa e alta cardinalidade e evita os limites de partição fixos e problemas de arquivos pequenos comuns com o particionamento estático. Consulte Converter uma tabela particionada para liquid clustering.

Tipos de dados suportados para colunas de partição

O particionamento oferece suporte a estes tipos de dados para colunas de partição.

• Data
• Carimbo de data/hora
• TimestampNTZ
• Intervalo
• String
• binário
• Booleana
• inteiro, longo, curto, byte
• Ponto flutuante, Duplo, Decimal

Colunas de partição devem ser colunas de nível superior. Não é possível particionar por nenhum dos seguintes:

• Tipos complexos, como StructType, MapType ou ArrayType VariantType
• Campos struct, como struct_col.field. O Delta Lake trata um campo struct em PARTITIONED BY como uma expressão, em vez de uma referência de coluna.

Para organizar uma tabela por um campo estruturado, utilize o liquid clustering, que reconhece um campo estruturado como uma chave de clusters. Os clusters líquidos são a única maneira de ignorar dados em um campo de estrutura sem antes extraí-lo para uma coluna de nível superior. Consulte Usar clustering líquido para tabelas.

Recomendações de tamanho mínimo

O particionamento abaixo desses tamanhos mínimos provavelmente afetará negativamente o desempenho da query em vez de melhorá-lo. Considere o seguinte ao decidir se deve particionar uma tabela:

• Para tabelas:

  • Com menos de 1 TB de dados, não particione.
  • Com mais de 1 TB a 100 TB de dados, use o agrupamento líquido em vez do particionamento. O particionamento provavelmente afeta negativamente o desempenho com mais frequência do que ajuda.
  • Com 100 TB ou mais de dados, o particionamento pode melhorar o desempenho, mas o Databricks recomenda usar o clustering líquido primeiro e verificar as melhorias de desempenho.

• Para partições, verifique se cada partição contém pelo menos 1 GB de dados. Tabelas com menos partições maiores tendem a ter um desempenho superior a tabelas com muitas partições menores.

Usar clustering de tempo de ingestão

Ao usar o Delta Lake, as tabelas não particionadas utilizam automaticamente a clusterização por tempo de ingestão. O tempo de ingestão apresenta melhorias de desempenho de consulta semelhantes a estratégias de particionamento com campos de data e hora, sem a necessidade de otimizar ou ajustar manualmente seus dados.

nota

Para manter clustering por tempo de ingestão ao realizar um grande número de modificações usando instruções UPDATE ou MERGE em uma tabela, Databricks recomenda o uso clustering líquido em uma coluna que corresponda à ordem de ingestão, como um carimbo de data/hora do evento ou uma data de criação. Consulte Usar clustering líquido para tabelas.

Compatibilidade de particionamento do Delta Lake e Parquet

O Delta Lake usa Parquet para armazenar dados, e algumas tabelas particionadas do Delta Lake têm disposições de dados semelhantes às tabelas Parquet armazenadas com o Apache Spark. O Apache Spark usa particionamento no estilo Hive ao salvar dados no formato Parquet. O particionamento no estilo Hive **não** faz parte do protocolo do Delta Lake, e as cargas de trabalho não devem depender dessa estratégia de particionamento para interagir com as tabelas Delta Lake.

O Databricks recomenda que você interaja com os dados armazenados no Delta Lake usando clientes e APIs oficialmente compatíveis. Muitos recursos do Delta Lake quebram as suposições sobre a disposição dos dados que poderiam ter sido usadas com Parquet, Hive ou até mesmo versões anteriores do protocolo Delta Lake.

nota

Ao habilitar o mapeamento de colunas para uma tabela Delta Lake, prefixos aleatórios substituem nomes de colunas em diretórios de partição para particionamento no estilo Hive. Consulte Renomear e eliminar colunas com o mapeamento de colunas do Delta Lake.

Particionamento do Delta Lake comparado a outros data lakes

As técnicas de particionamento úteis em outras tecnologias de código aberto (como Apache Spark, Parquet, Hive e Hadoop) nem sempre são válidas para o Databricks. Se você optar por particionar sua tabela, considere o seguinte:

• As transações não são definidas por limites de partição. Como o Delta Lake garante ACID através de logs de transação, não é necessário separar um lote de dados por uma partição para garantir a atomicidade.
• Databricks compute não têm localidade de dados vinculada à mídia física. Os dados ingeridos no lakehouse são armazenados no armazenamento de objetos na nuvem. Enquanto os dados são armazenados em cache no disco local durante o processamento de dados, a Databricks usa estatísticas baseadas em arquivos para identificar a quantidade mínima de dados para carregamento paralelo.

Z-order e partições

nota

Databricks recomenda o uso clustering líquido em vez Z-ordering para todas as novas tabelas. Consulte Usar clustering líquido para tabelas.

Pode-se usar índices Z-order junto com partições para acelerar consultas em grandes datasets. A maioria das tabelas usa clustering por tempo de ingestão para evitar a necessidade de ajustar Z-order e partições.

Tenha em mente as seguintes regras ao planejar uma estratégia de otimização de consulta baseada em limites de partição e Z-order:

• A Z-order exige o comando OPTIMIZE. Você não pode combinar arquivos entre os limites da partição e, portanto, o clustering de Z-order só pode ocorrer dentro de uma partição. Para tabelas não particionadas, os arquivos podem ser combinados em toda a tabela.
• O particionamento funciona bem apenas para campos de cardinalidade baixa ou conhecida (por exemplo, campos de data ou localizações físicas), mas não para campos com cardinalidade alta, como registros de data e hora. A Z-order funciona para todos os campos, incluindo campos de alta cardinalidade e campos que podem crescer infinitamente (por exemplo, timestamps ou o ID do cliente em uma tabela de transações ou pedidos).
• Você não pode Z-order em campos usados para particionamento.

Como o Databricks otimiza partições existentes

Muitos clientes migram para o Delta Lake de data lakes baseados em Parquet, como ao usar a instrução CONVERT TO DELTA para converter uma tabela existente baseada em Parquet em uma tabela Delta Lake sem reescrever os dados existentes. Como a conversão não reescreve os dados existentes, tabelas grandes podem herdar estratégias de particionamento anteriores.

Algumas otimizações do Databricks usam essas partições quando possível, mitigando os efeitos negativos no desempenho para estratégias de particionamento que não são otimizadas para o Delta Lake.

Delta Lake e Apache Spark são tecnologias de código aberto. Embora o Databricks tenha recursos que reduzem a dependência do particionamento, a comunidade de código aberto pode criar novos recursos que adicionam complexidade.