Quando particionar tabelas no Azure Databricks

A maioria das tabelas em Azure Databricks com menos de 100 TB de dados não precisa de particionamento. Azure Databricks usa o Delta Lake para todas as tabelas por padrão e clusteriza automaticamente os dados em tabelas não particionadas por tempo de ingestão, para que você obtenha um desempenho semelhante a particionamento sem ajuste manual. Considere uma estratégia de particionamento personalizada somente quando ela tiver desempenho superior ao dessas configurações padrão. Consulte Usar clustering 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 agrupamento por tempo de ingestão padrão.

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

Para converter uma tabela particionada existente do Delta Lake em clustering líquido, use ALTER TABLE ... REPLACE PARTITIONED BY WITH CLUSTER BY. A clusterização líquida funciona tanto para colunas de baixa quanto de alta cardinalidade e evita os limites fixos de partição e os problemas de arquivos pequenos comuns no particionamento estático. Consulte Converter uma tabela particionada para clusterização líquida.

Tipos de dados com suporte para colunas de partição

O particionamento dá suporte a esses tipos de dados para colunas de partição:

• Date
• Timestamp
• TimestampNTZ
• Intervalo
• String
• Binário
• booleano
• Inteiro, Longo, Curto, Byte
• Float, Duplo, Decimal

As colunas de partição devem ser colunas de nível superior. Você não pode particionar por nenhuma das seguintes opções:

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

Para organizar uma tabela por um campo de estrutura, use o clustering líquido, que reconhece um campo de estrutura como uma chave de clustering. O clustering líquido é a única forma de fazer data skipping 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

Particionamento abaixo desses tamanhos mínimos provavelmente afetará negativamente o desempenho da consulta em vez de melhorá-la. Considere o seguinte quando você decidir se deseja 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 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 melhor que o de tabelas com muitas partições menores.

Utilize clusterização no tempo de ingestão

Ao usar o Delta Lake, as tabelas não particionadas usam automaticamente o agrupamento em tempo de ingestão. O agrupamento em tempo de ingestão oferece melhorias de desempenho de consulta semelhantes às estratégias de particionamento com campos datetime, sem a necessidade de otimizar ou ajustar seus dados manualmente.

Compatibilidade entre o particionamento do Delta Lake e do Parquet

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

O Databricks recomenda que você interaja com os dados armazenados no Delta Lake usando apIs e clientes com suporte oficial. Muitos recursos do Delta Lake quebram suposições sobre o layout de dados que podem ter sido usados com o Parquet, Hive ou até mesmo versões anteriores do protocolo Delta Lake.

Particionamento do Delta Lake em comparação com outros data lakes

Técnicas de particionamento úteis em outras tecnologias de código aberto (como Apache Spark, Parquet, Hive e Hadoop) nem sempre são verdadeiras para Azure 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 por meio de logs de transações, você não precisa separar um lote de dados por uma partição para garantir a atomicidade.
• Os clusters de computação do Azure Databricks não têm localidade de dados vinculada à mídia física. Os dados ingeridos no lakehouse são armazenados no armazenamento de objetos de nuvem. Embora os dados sejam armazenados em cache no armazenamento em disco local durante o processamento de dados, o Azure Databricks usa estatísticas baseadas em arquivo para identificar a quantidade mínima de dados para carregamento paralelo.

Ordem Z e partições

Você pode usar índices de ordem Z com partições para acelerar consultas em grandes conjuntos de dados. A maioria das tabelas usa clusterização por tempo de ingestão para evitar a necessidade de ajustar o Z-order e as partições.

Lembre-se das seguintes regras ao planejar uma estratégia de otimização de consulta com base nos limites de partição e na ordem Z:

• A ordem Z requer o OPTIMIZE comando. Você não pode combinar arquivos entre limites de partição e, portanto, o clustering de ordem Z 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 locais físicos), mas não para campos com alta cardinalidade, como carimbos de data/hora. A ordem Z funciona para todos os campos, incluindo campos de cardinalidade alta e campos que podem crescer infinitamente (por exemplo, carimbos de data/hora ou a ID do cliente em uma tabela de transações ou pedidos).
• Não é possível ordenar por Z em campos usados para particionamento.

Como Azure Databricks otimiza em torno de partições existentes

Muitos clientes migram para o Delta Lake a partir de data lakes baseados em Parquet, como por exemplo, usando a CONVERT TO DELTA instrução 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 dados existentes, tabelas grandes podem herdar estratégias de particionamento anteriores.

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

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