Quando particionar tabelas em Databricks
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 o senhor pode particionar tabelas em Databricks e recomendações específicas sobre quando deve usar o particionamento para tabelas apoiadas por Delta Lake. Devido ao recurso integrado e às otimizações, a maioria das tabelas com menos de 1 TB de dados não precisa de partições.
Databricks usa Delta Lake para todas as tabelas por default. As recomendações a seguir pressupõem que o senhor esteja trabalhando com o Delta Lake em todas as tabelas.
Em Databricks Runtime 11.3 LTS e acima, Databricks agrupa automaticamente os dados em tabelas não particionadas por tempo de ingestão. Consulte Usar clustering de tempo de ingestão.
Mesas pequenas precisam ser particionadas?
A Databricks recomenda que o senhor não particione tabelas que contenham menos de um terabyte de dados.
Qual é o tamanho mínimo para cada partição em uma tabela?
A 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 clustering de 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 fornece benefícios de consulta semelhantes às estratégias de particionamento com base em campos de data e hora, sem a necessidade de otimizar ou ajustar seus dados.
Para manter o tempo de ingestão clustering quando o senhor realiza um grande número de modificações usando instruções UPDATE ou MERGE em uma tabela, o site 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 e hora do evento ou uma data de criação.
O Delta Lake e o Parquet compartilham estratégias de particionamento?
O Delta Lake usa o Parquet como o formato principal para armazenar dados, e algumas tabelas do Delta com partições especificadas demonstram 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 contar com essa estratégia de particionamento para interagir com as tabelas Delta.
Muitos recursos do Delta Lake quebram as suposições sobre a disposição dos dados que podem ter sido transferidos de Parquet, Hive, ou mesmo de versões anteriores do protocolo Delta Lake. O senhor deve sempre interagir com os dados armazenados no Delta Lake usando clientes e APIs oficialmente compatíveis.
Quando o senhor ativa o mapeamento de coluna para uma tabela Delta, os prefixos aleatórios substituem os nomes de coluna nos diretórios de partição para o particionamento no estilo Hive. Consulte Renomear e soltar colunas com o mapeamento de colunas do Delta Lake.
Qual é a diferença entre as partições do Delta Lake e as partições de outros data lake?
Embora Databricks e 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 se aplicam a 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 pelos limites da partição. Delta Lake garante ACID por meio da transação logs, de modo que o senhor não precisa separar um lote de dados por uma partição para garantir a descoberta atômica.
- Databricks compute não têm localidade de dados vinculada à mídia física. Os dados ingeridos no lakehouse são armazenados no armazenamento de objetos na nuvem. Enquanto os dados são armazenados em cache no disco local durante o processamento de dados, a Databricks usa estatísticas baseadas em arquivos para identificar a quantidade mínima de dados para carregamento paralelo.
Como o site Z-order e as partições funcionam juntos?
O senhor pode usar Z-order juntamente com partições para acelerar as consultas em grandes conjuntos de dados.
A maioria das tabelas pode aproveitar o tempo de ingestão clustering para evitar a necessidade de se preocupar com o ajuste de Z-order e de partição.
É importante ter em mente as seguintes regras ao planejar uma estratégia de otimização de consulta com base em limites de partição e Z-order:
- 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 Databricks recursos as utilizam?
As partições podem ser benéficas, especialmente para mesas 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 a partir do data lake baseado em Parquet. A instrução CONVERT TO DELTA permite que o senhor converta uma tabela existente baseada em Parquet em uma tabela Delta sem reescrever os dados existentes. Dessa forma, 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, atenuando algumas possíveis desvantagens das estratégias de particionamento não otimizadas para o Delta Lake.
Delta Lake e Apache Spark são códigos abertos de tecnologia. Enquanto o site Databricks continua a introduzir recursos que reduzem a dependência do particionamento, a comunidade do código aberto pode continuar a criar novos recursos que aumentam a complexidade.
É possível superar as otimizações da Databricks integrada com particionamento personalizado?
Alguns usuários experientes do Apache Spark e do Delta Lake podem ser capazes de projetar e implementar um padrão que ofereça melhor desempenho do que o clustering de tempo de ingestão. A implementação de uma estratégia de particionamento ruim pode ter repercussões muito negativas no desempenho downstream e pode exigir uma reescrita completa dos dados para ser corrigida. Databricks recomenda que a maioria dos usuários use as configurações do default para evitar a introdução de ineficiências dispendiosas.