Ignorar dados

nota

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

As estatísticas de salto de dados são coletadas automaticamente ao gravar dados em uma tabela Delta Lake ou Apache Iceberg gerenciada. O Databricks usa estatísticas por arquivo (valores mínimos e máximos, contagens de nulos e registros totais) no momento da consulta para ignorar arquivos irrelevantes e acelerar as consultas.

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

Especificar colunas de estatísticas

Para o Unity Catalog tabelas externas, as estatísticas são coletadas nas primeiras 32 colunas definidas em seu esquema de tabela por padrão. Para as tabelas gerenciadas do Unity Catalog, as estatísticas de salto de arquivo são escolhidas de forma inteligente usando a otimização preditiva e não têm um limite de 32 colunas. Otimização preditiva executa automaticamente ANALYZE, um comando para coletar estatísticas. A Databricks recomenda ativar a otimização preditiva para todas as tabelas gerenciadas pelo Unity Catalog para simplificar a manutenção de dados e reduzir os custos de armazenamento. Consulte Otimização preditiva para tabelas gerenciadas do Unity Catalog.

Se não estiver usando a otimização preditiva, é possível modificar o comportamento que limita as coletas de estatísticas a 32 colunas ao definir uma das seguintes propriedades de tabela:

Propriedade da tabela	Databricks Runtime tem suporte	Descrição
dataSkippingNumIndexedCols	Todas as versões do Databricks Runtime compatíveis	Aumentar ou diminuir o número de colunas nas quais as estatísticas são coletadas. Depende da ordem das colunas.
dataSkippingStatsColumns	Databricks Runtime 13.3 LTS e acima	Especificar uma lista de nomes de coluna para os quais as estatísticas são coletadas. Substitui dataSkippingNumIndexedCols.

As propriedades da tabela podem ser definidas durante a criação da tabela ou com instruções ALTER TABLE. Consulte a referência de propriedades da tabela. O exemplo a seguir substitui o comportamento padrão da coleta de estatísticas para configurar a coleta de estatísticas em colunas nomeadas.

Delta Lake table

SQL

ALTER TABLE table_name SET TBLPROPERTIES('delta.dataSkippingStatsColumns' = 'col1, col2, col3')

Iceberg table

SQL

ALTER TABLE table_name SET TBLPROPERTIES('iceberg.dataSkippingStatsColumns' = 'col1, col2, col3')

A atualização dessas propriedades não recalcula automaticamente as estatísticas para os dados existentes. Em vez disso, isso impacta o comportamento da futura coleta de estatísticas ao adicionar ou atualizar dados na tabela. Estatísticas não são usadas para colunas não incluídas na lista atual de colunas de estatísticas.

No Databricks Runtime 14.3 LTS e acima, se você alterou as propriedades da tabela ou alterou as colunas especificadas para estatísticas, você pode acionar manualmente o recálculo das estatísticas para uma tabela usando o seguinte comando:

SQL

ANALYZE TABLE table_name COMPUTE DELTA STATISTICS

nota

Strings longas são truncados durante a coleta de estatísticas. Pode-se optar por excluir colunas de strings longas da coleta de estatísticas, especialmente se as colunas não forem usadas frequentemente para consultas de filtragem.

O que é Z-ordering?

nota

O Databricks recomenda os clusters líquidos para todas as novas tabelas. Não é possível usar ZORDER em combinação com clusters líquidos. Consulte Usar clusters líquidos para tabelas.

Z-ordering é uma técnica para colocalizar informações relacionadas no mesmo conjunto de arquivos. Os algoritmos de salto de dados do Databricks usam automaticamente esta colocalidade. Esse comportamento reduz a quantidade de dados que precisam ser lidos. Para dados de Z-order, especifique as colunas a serem ordenadas na cláusula ZORDER BY :

SQL

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 diminui a cada coluna extra.

O Databricks recomenda que você não use ZORDER BY em colunas que não têm estatísticas coletadas porque é ineficaz e usa recursos de compute desnecessários. 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 certas colunas reordenando as colunas no esquema, ou você pode aumentar o número de colunas nas quais coletar estatísticas.

nota

• 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 acabou de ser Z-ordered, outra Z-ordering dessa partição não tem nenhum efeito.

• O Z-ordering visa produzir arquivos de dados igualmente balanceados em relação ao número de tuplas, mas não necessariamente ao tamanho dos dados no armazenamento. Embora os tamanhos de arquivos e o número de tuplas estejam correlacionados, pode haver situações em que não estejam, o que distorce os tempos das tarefas de otimização.

  Por exemplo, se você ZORDER BY data e seus registros mais recentes forem todos muito mais amplos (como arrays mais longos ou valores de strings) do que os do passado, as durações das tarefas do Job OPTIMIZE e os tamanhos dos arquivos resultantes podem ser distorcidos. Isso é, no entanto, apenas um problema para o próprio comando OPTIMIZE; provavelmente não tem efeitos negativos em consultas subsequentes.