Quando particionar tabelas no Azure Databricks

Observação

O Databricks recomenda a utilização de clustering líquido para todas as novas tabelas Delta. Confira Usar clustering líquido para tabelas Delta.

Clusters líquidos às vezes também são conhecidos como “partições líquidas”. Este artigo refere-se apenas ao particionamento Delta herdado e não ao clustering líquido.

Este artigo fornece uma visão geral de como você pode particionar tabelas no Azure Databricks, bem como recomendações específicas sobre quando usar o particionamento para tabelas com suporte do Delta Lake. Devido a recursos internos e otimizações, a maioria das tabelas com menos de 1 TB de dados não exige 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 clustering de tempo de ingestão.

Tabelas pequenas precisam ser particionadas?

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

Qual é o tamanho mínimo de 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 ter um desempenho melhor que o de tabelas com muitas partições menores.

Usar clustering de tempo de ingestão

Usando o Delta Lake e o Databricks Runtime 11.3 LTS ou superior, as tabelas não particionadas que você cria se beneficiam automaticamente do agrupamento do 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 a necessidade de otimizar ou ajustar seus dados.

Observação

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

O Delta Lake e Parquet compartilham estratégias de particionamento?

O Delta Lake usa Parquet como o formato principal para armazenar dados e algumas tabelas Delta com partições especificadas demonstram uma organização semelhante à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.

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ê sempre deve interagir com os dados armazenados no Delta Lake usando APIs e clientes com suporte oficial.

Como as partições do Delta Lake são diferentes das 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 verdadeiras 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 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.

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

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

Observação

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

É importante ter as seguintes regras em mente ao planejar uma estratégia de otimização de consulta baseada nos limites de partição e na ordem Z:

• A ordem Z funciona em conjunto com o comando OPTIMIZE. 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 executar a ordem 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 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 de data lakes baseados em Parquet. A instrução CONVERT TO DELTA permite converter uma tabela baseada em Parquet existente em uma tabela Delta sem re-escrever dados existentes. Assim, muitos clientes têm tabelas grandes que herdam estratégias de particionamento anteriores. Algumas otimizações desenvolvidas pelo Databricks buscam aproveitar essas partições quando possível, mitigando algumas possíveis desvantagens das estratégias de particionamento não otimizadas para o Delta Lake.

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

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

Alguns usuários experientes do Apache Spark e do Delta Lake podem conseguir criar e implementar um padrão que fornece melhor desempenho do que o do clustering de tempo de ingestão. A implementação de uma estratégia de particionamento ruim pode ter repercussões muito negativas sobre o desempenho downstream e pode exigir uma re-escrita completa dos dados. O Databricks recomenda que a maioria dos usuários use as configurações padrão para evitar a introdução de ineficiências caras.