Ignoração de dados para Delta Lake

As informações de salto de dados são coletadas automaticamente quando você grava dados em uma tabela Delta. Delta Lake no Databricks aproveita essas informações (valores mínimos e máximos, contagens nulas e total de registros por arquivo) no momento da consulta para fornecer consultas mais rápidas.

Observação

No Databricks Runtime 13.3 e acima, o Databricks recomenda o uso clusters para disposição da tabela Delta. clusters não é compatível com Z-ordering. Consulte Usar clusters líquidos para tabelas Delta.

Você deve ter estatísticas coletadas para colunas usadas em instruções ZORDER . Consulte O que é Z-ordering?.

Especifique colunas de estatísticas Delta

Por default, o Delta Lake coleta estatísticas nas primeiras 32 colunas definidas no esquema da tabela. Para esta coleção, cada campo em uma coluna aninhada é considerado uma coluna individual. Você pode modificar esse comportamento definindo uma das seguintes propriedades da tabela:

Propriedade da tabela

Databricks Runtime com suporte

Descrição

delta.dataSkippingNumIndexedCols

Todas as versões suportadas do Databricks Runtime

Aumente ou diminua o número de colunas nas quais a Delta coleta estatísticas. Depende da ordem das colunas.

delta.dataSkippingStatsColumns

Databricks Runtime 13.3 LTS e acima

Especifique uma lista de nomes de colunas para as quais o Delta Lake coleta estatísticas. Substitui dataSkippingNumIndexedCols.

As propriedades da tabela podem ser definidas na criação da tabela ou com instruções ALTER TABLE . Consulte Referência de propriedades da tabela Delta.

A atualização desta propriedade não recalcula automaticamente as estatísticas dos dados existentes. Em vez disso, impacta o comportamento da coleta futura de estatísticas ao adicionar ou atualizar dados na tabela. Delta Lake não aproveita estatísticas para colunas não incluídas na lista atual de colunas estatísticas.

No Databricks Runtime 14.3 LTS e acima, você pode acionar manualmente o recálculo de estatísticas para uma tabela Delta usando o seguinte comando:

ANALYZE TABLE table_name COMPUTE DELTA STATISTICS

Observação

strings longas são truncadas durante a coleta de estatísticas. Você pode optar por excluir colunas de strings longas da coleta de estatísticas, especialmente se as colunas não forem usadas com frequência para filtrar consultas.

O que é Z-ordering?

Z-ordering é uma técnica para colocalizar informações relacionadas no mesmo conjunto de arquivos. Essa colocalidade é usada automaticamente pelo Delta Lake em algoritmos de salto de dados do Databricks. Esse comportamento reduz drasticamente a quantidade de dados que o Delta Lake on Databricks precisa ler. Para dados de Z-order, especifique as colunas a serem ordenadas na cláusula ZORDER BY :

OPTIMIZE events
WHERE date >= current_timestamp() - INTERVAL 1 day
ZORDER BY (eventType)

Se você espera que uma coluna seja comumente usada em predicados de consulta e se essa coluna tiver alta cardinalidade (ou seja, um grande número de valores distintos), use ZORDER BY.

Você pode especificar várias colunas para ZORDER BY como uma lista separada por vírgulas. No entanto, a eficácia da localidade diminui a cada coluna extra. O Z-ordering em colunas que não têm estatísticas coletadas seria ineficaz e um desperdício de recursos. Isso ocorre porque a omissão de dados exige estatísticas locais da coluna, como mínimo, máximo e contagem. Você pode configurar a coleta de estatísticas em determinadas colunas reordenando as colunas no esquema ou pode aumentar o número de colunas nas quais coletar estatísticas.

Observação

  • O Z-ordering não é idempotente, mas pretende ser uma operação incremental. Não é garantido que o tempo necessário para o Z-ordering seja reduzido em várias execuções. No entanto, se nenhum novo dado foi adicionado a uma partição que foi apenas Z-ordered, outro Z-ordering dessa partição não terá nenhum efeito.

  • O Z-Ordering visa produzir arquivos de dados equilibrados em relação ao número de tuplas, mas não necessariamente ao tamanho dos dados no disco.Na maioria das vezes, as duas medidas estão correlacionadas, mas pode haver situações em que isso não acontece, o que leva a uma distorção na otimização dos tempos das tarefas.

    Por exemplo, se você ZORDER BY data e seus registros mais recentes forem todos muito mais amplos (por exemplo, matrizes ou valores de strings mais longas) do que os anteriores, espera-se que as durações de tarefa do job OPTIMIZE sejam distorcidas, bem como os tamanhos dos arquivos resultantes. Este é, no entanto, apenas um problema para o próprio comando OPTIMIZE; ele não deve ter qualquer impacto negativo nas consultas subsequentes.