Quando particionar tabelas no Azure Databricks

A maioria das tabelas no Azure Databricks com menos de 100 TB de dados não precisa de particionamento. O Azure Databricks usa o Delta Lake para todas as tabelas por defeito e agrupa automaticamente os dados em tabelas não particionadas por tempo de ingestão, por isso tens um desempenho semelhante ao de particionamento sem ajustes manuais. Considere uma estratégia de particionamento personalizada apenas quando tiver um desempenho superior ao destas opções predefinidas. Consulte Usar agrupamento por tempo de ingestão.

Estratégias de particionamento personalizadas

Utilizadores avançados do Apache Spark e do Delta Lake podem identificar uma estratégia de particionamento que supera o agrupamento padrão do tempo de ingestão.

Antes de utilizar estratégias de particionamento personalizadas, a Databricks recomenda clustering líquido para todas as tabelas e otimização preditiva para tabelas geridas pelo Unity Catalog. Veja Utilizar o agrupamento líquido para tabelas e Otimização preditiva para tabelas geridas do Unity Catalog.

Para converter uma tabela Delta Lake já particionada em liquid clustering, utilize ALTER TABLE ... REPLACE PARTITIONED BY WITH CLUSTER BY. O agrupamento líquido funciona tanto para colunas de baixa como de alta cardinalidade e evita os limites fixos das partições e problemas de ficheiros pequenos comuns na partição estática. Veja Converter uma tabela particionada para agrupamento líquido.

Tipos de dados suportados para colunas de partição

A partição suporta estes tipos de dados para colunas de partição:

• Date
• Data e Hora
• TimestampNTZ
• Intervalo
• String
• Binary
• booleano
• Inteiro, Longo, Curto, Byte
• Flutuador, Duplo, Decimal

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

• Tipos complexos, como StructType, MapType, ArrayType, ou VariantType
• Campos de estruturas, como struct_col.field. 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 struct, use em vez disso o cluster líquido, que reconhece um campo struct como chave de clustering. O agrupamento de líquidos é a única forma de saltar dados num campo de struct sem primeiro extraí-lo para uma coluna de topo. Veja Utilizar clustering líquido para tabelas.

Recomendações de tamanho mínimo

Particionar abaixo destes tamanhos mínimos tende a afetar negativamente o desempenho das consultas em vez de o melhorar. Considere o seguinte ao decidir se deve particionar uma tabela:

• Para tabelas:
  • Com menos de 1 TB de dados, não particiones.
  • Com entre 1 TB e 100 TB de dados, utilize liquid clustering em vez de particionamento. A partição provavelmente afeta negativamente o desempenho mais vezes do que ajuda.
  • Com 100 TB ou mais de dados, a partição pode melhorar o desempenho, mas a Databricks recomenda primeiro usar clustering líquido 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 superar tabelas com muitas partições menores.

Usar agrupamento de tempo de ingestão

Ao usar o Delta Lake, as tabelas não particionadas usam automaticamente agrupamento por tempo de ingestão. O tempo de ingestão apresenta melhorias no desempenho das consultas semelhantes às estratégias de partição com campos data-hora, sem necessidade de otimizar ou ajustar manualmente os dados.

Compatibilidade de particionamento entre Delta Lake e Parquet

A Delta Lake utiliza o Parquet para armazenar dados, e algumas tabelas Delta Lake particionadas têm layouts 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 Delta Lake, e os processos não se devem basear nesta estratégia de particionamento para interagir com as tabelas do Delta Lake.

O Databricks recomenda que interaja com os dados armazenados no Delta Lake usando clientes e APIs oficialmente suportados. Muitas funcionalidades do Delta Lake quebram pressupostos sobre o layout dos dados que poderiam ter sido usados com o Parquet, Hive ou até versões anteriores do protocolo Delta Lake.

Partição do Delta Lake comparada com outros lagos de dados

Técnicas de particionamento úteis noutras tecnologias open source (como Apache Spark, Parquet, Hive e Hadoop) nem sempre se aplicam ao Azure Databricks. Se optar por particionar a sua tabela, considere o seguinte:

• As transações não são definidas por limites de partição. Como o Delta Lake assegura ACID através dos registos de transações, não é necessário separar um lote de dados por uma partição para garantir 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 em armazenamento em nuvem. Enquanto os dados são 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 ao lado de partições para acelerar consultas em grandes conjuntos de dados. A maioria das tabelas utiliza agrupamento por tempo de ingestão para evitar a necessidade de ajustar a ordem Z e as partições.

Tenha em mente as seguintes regras ao planear uma estratégia de otimização de consultas baseada nos limites das partições e na ordem Z:

• A ordem Z requer o OPTIMIZE comando. Não é possível 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 temporais ou locais físicos), mas não para campos com cardinalidade alta, como marcadores de tempo. A ordem Z funciona para todos os campos, incluindo campos de alta cardinalidade e campos que podem crescer infinitamente (por exemplo, carimbos de data/hora ou o ID do cliente em uma tabela de transações ou pedidos).
• Não é possível aplicar Z-order em campos usados para particionamento.

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

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

Algumas otimizações da Databricks utilizam estas partições sempre que possível, atenuando os efeitos negativos no desempenho das estratégias de particionamento que não estão otimizadas para o Delta Lake.

Delta Lake e Apache Spark são tecnologias de código aberto. Embora o Databricks tenha funcionalidades que reduzem a dependência da partição, a comunidade open source pode criar novas funcionalidades que aumentem a complexidade.