Quando particionar tabelas no Databricks

Observação

A Databricks recomenda o uso de clustering líquido para todas as novas tabelas Delta. Consulte Usar clustering líquido para tabelas Delta.

Às vezes, os clusters líquidos também são chamados de "partições líquidas". Este artigo se refere apenas ao particionamento legado Delta e não ao líquido clustering.

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

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

Em Databricks Runtime 11.3 LTS e acima, Databricks automaticamente clusters dados em tabelas não particionadas por tempo de ingestão. Consulte Usar clustering de tempo de ingestão.

Tabelas pequenas precisam ser particionadas?

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?

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

Usar clustersde tempo de ingestão

Ao usar Delta Lake e Databricks Runtime 11.3 LTS ou acima, as tabelas não particionadas que o senhor cria se beneficiam automaticamente do tempo de ingestão clustering. O tempo de ingestão oferece benefícios de consulta semelhantes às estratégias de particionamento baseadas em campos de data e hora, sem a necessidade de otimizar ou ajustar os dados.

Observação

Para manter clusters de tempo de ingestão quando você executa um grande número de modificações usando instruções UPDATE ou MERGE em uma tabela, Databricks recomenda executar OPTIMIZE com ZORDER BY usando 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.

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 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 as tabelas Delta.

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

Como as partições do Delta Lake são diferentes das partições em outros data lakes?

Enquanto Databricks e Delta Lake se baseiam em tecnologias de código aberto como Apache Spark, Parquet, Hive e Hadoop, motivações e estratégias de particionamento úteis nessas tecnologias geralmente não são verdadeiras para 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ção, portanto, você não precisa separar lotes de dados por uma partição para garantir a descoberta atômica.

• Os clusters compute 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 cloud . Enquanto os dados são armazenados em cache no armazenamento em disco local durante o processamento de dados, o Databricks usa estatísticas baseadas em arquivo para identificar a quantidade mínima de dados para carregamento paralelo.

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

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

Observação

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

É importante ter em mente as regras a seguir ao planejar uma estratégia de otimização query com base nos limites da partição e na ordem Z:

• A Z-order funciona em conjunto com o comando OPTIMIZE . Você não pode combinar arquivos entre os limites da partição e, portanto, clusters de Z-order só podem 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 localizações físicas), mas não para campos com cardinalidade alta, como registros de data e hora. A Z-order funciona para todos os campos, incluindo campos de alta cardinalidade e campos que podem crescer infinitamente (por exemplo, timestamps ou o ID do cliente em uma tabela de transações ou pedidos).

• Você não pode Z-order em campos usados para particionamento.

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

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

Muitos clientes migram para 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 reescrever os dados existentes. Como tal, muitos clientes têm tabelas grandes que herdam estratégias de particionamento anteriores. Algumas otimizações desenvolvidas pela Databricks buscam aproveitar essas partições quando possível, mitigando algumas possíveis desvantagens 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 de particionamento, a comunidade código aberto pode continuar a criar novos recursos que adicionam complexidade.

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

Alguns usuários experientes do Apache Spark e Delta Lake podem projetar e implementar um padrão que forneça melhor desempenho do que clustersde tempo de ingestão. A implementação de uma estratégia de particionamento incorreta pode ter repercussões muito negativas no desempenho downstream e pode exigir uma reescrita completa dos dados para correção. Databricks recomenda que a maioria dos usuários use configurações default para evitar a introdução de ineficiências caras.