Quando particionar tabelas no Azure Databricks

Nota

O Databricks recomenda o uso de clustering líquido para todas as novas tabelas Delta. Veja Utilizar clustering líquido para tabelas Delta.

Os aglomerados líquidos são por vezes também referidos como "partições líquidas". Este artigo refere-se apenas ao particionamento Delta herdado e não ao agrupamento líquido.

Este artigo fornece uma visão geral de como você pode particionar tabelas no Azure Databricks e recomendações específicas sobre quando você deve usar o particionamento para tabelas apoiadas pelo Delta Lake. Devido aos recursos e otimizações internos, a maioria das tabelas com menos de 1 TB de dados não requer partições.

O Azure Databricks usa o Delta Lake para todas as tabelas por padrão. As recomendações a seguir pressupõem que você esteja trabalhando com o Delta Lake para todas as tabelas.

No Databricks Runtime 11.3 LTS e superior, o Azure Databricks agrupa automaticamente os dados em tabelas não particionadas por tempo de ingestão. Consulte Usar agrupamento de tempo de ingestão.

As mesas pequenas precisam ser particionadas?

O Databricks recomenda que você não particione tabelas que contenham menos de um terabyte de dados.

Qual é o tamanho mínimo para cada partição em uma tabela?

O Databricks recomenda que todas as partições contenham pelo menos um gigabyte de dados. Tabelas com menos partições maiores tendem a superar tabelas com muitas partições menores.

Usar agrupamento de tempo de ingestão

Usando Delta Lake e Databricks Runtime 11.3 LTS ou superior, tabelas não particionadas que você cria se beneficiam automaticamente do cluster de tempo de ingestão. O tempo de ingestão fornece benefícios de consulta semelhantes às estratégias de particionamento baseadas em campos datetime sem qualquer necessidade de otimizar ou ajustar seus dados.

Nota

Para manter o agrupamento de tempo de ingestão quando você executa um grande número de modificações usando UPDATE instruções ou MERGE em uma tabela, o Databricks recomenda executar OPTIMIZE com ZORDER BY o uso de uma coluna que corresponda à ordem de ingestão. Por exemplo, pode ser uma coluna contendo um carimbo de data/hora de evento ou uma data de criação.

O Delta Lake e o Parquet partilham estratégias de particionamento?

O Delta Lake usa o Parquet como o formato principal para armazenar dados, e algumas tabelas Delta com partições especificadas demonstram uma organização semelhante às tabelas do 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 as cargas de trabalho não devem depender dessa estratégia de particionamento para interagir com tabelas Delta.

Muitos recursos do Delta Lake quebram suposições sobre o layout de dados que podem ter sido transferidos de Parquet, Hive ou até mesmo versões anteriores do protocolo Delta Lake. Você deve sempre interagir com os dados armazenados no Delta Lake usando clientes e APIs oficialmente suportados.

Qual é a diferença entre as partições Delta Lake e as partições em outros data lakes?

Embora o Azure Databricks e o Delta Lake se baseiem em tecnologias de código aberto como Apache Spark, Parquet, Hive e Hadoop, as motivações e estratégias de particionamento úteis nessas tecnologias geralmente não são válidas para o Azure Databricks. Se você optar por particionar sua tabela, considere os seguintes fatos antes de escolher uma estratégia:

• As transações não são definidas por limites de partição. O Delta Lake garante o ACID por meio de logs de transações, portanto, você não precisa separar um lote de dados por uma partição para garantir a descoberta atômica.
• Os clusters de computação do Azure Databricks não têm localidade de dados vinculada à mídia física. Os dados ingeridos na casa do lago são armazenados no armazenamento de objetos na 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.

Como a ordem Z e as partições funcionam juntas?

Você pode usar índices de ordem Z ao lado de partições para acelerar consultas em grandes conjuntos de dados.

Nota

A maioria das tabelas pode aproveitar o agrupamento de tempo de ingestão para evitar a necessidade de se preocupar com a ordem Z e o ajuste de partição.

As regras a seguir são importantes para ter em mente ao planejar uma estratégia de otimização de consulta com base nos limites de partição e na ordem Z:

• A ordem Z funciona em conjunto com 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 de data ou locais físicos), mas não para campos com cardinalidade alta, como carimbos de data/hora. 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 ordenar Z em campos usados para particionamento.

Se as partições são tão ruins, por que alguns recursos do Azure Databricks as usam?

As partições podem ser benéficas, especialmente para mesas muito grandes. Muitos aprimoramentos de desempenho em torno do particionamento se concentram em tabelas muito grandes (centenas de terabytes ou mais).

Muitos clientes migram para o Delta Lake a partir de data lakes baseados em Parquet. A CONVERT TO DELTA instrução permite converter uma tabela existente baseada em Parquet em uma tabela Delta sem reescrever dados existentes. Como tal, muitos clientes têm tabelas grandes que herdam estratégias de particionamento anteriores. Algumas otimizações desenvolvidas pela Databricks procuram aproveitar essas partições quando possível, mitigando algumas desvantagens potenciais para estratégias de particionamento não otimizadas para Delta Lake.

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

É possível superar as otimizações internas do Azure Databricks com particionamento personalizado?

Alguns usuários experientes do Apache Spark e Delta Lake podem ser capazes de projetar e implementar um padrão que fornece melhor desempenho do que o clustering de tempo de ingestão. A implementação de um stategy de particionamento incorreto pode ter repercussões muito negativas no desempenho downstream e pode exigir uma regravação completa dos dados para corrigir. O Databricks recomenda que a maioria dos usuários use as configurações padrão para evitar a introdução de ineficiências dispendiosas.