Quando particionar tabelas no Azure Databricks

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 assumem que estás a trabalhar com 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 por 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

Ao usar Delta Lake e o Databricks Runtime 11.3 LTS ou superior, as tabelas não particionadas criadas beneficiam-se automaticamente da distribuição por tempo de ingestão. O tempo de ingestão de dados fornece benefícios de consulta semelhantes às estratégias de particionamento baseadas em campos de data e hora, sem qualquer necessidade de otimizar ou ajustar os dados.

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. Particionamento no estilo Hive não faz parte do protocolo Delta Lake, e os processamentos não devem depender dessa estratégia de particionamento para trabalhar 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 em relação às partições noutras 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 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.

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.

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 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.

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

As partições podem ser benéficas, especialmente para tabelas 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 utilizadores 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 por tempo de ingestão. A implementação de uma estratégia de particionamento incorreta pode ter repercussões muito negativas no desempenho subsequente 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.