Liquid Clustering ou ZOrder: o layout deve seguir a consulta que importa

Kushal Kumar Vishwakarma comparou particionamento por data, ZOrdering e Liquid Clustering em Delta Lake usando 50 milhões de transações sintéticas e perfis de consultas do Databricks.[10] O resultado varia por padrão de acesso: Liquid Clustering vence algumas consultas, enquanto ZOrder é mais rápido no filtro seletivo por múltiplas colunas.[10]

A leitura de engenharia é que um layout não deveria ser escolhido pelo nome mais novo. Ele precisa servir às consultas importantes e ao custo de manter os dados ao longo do tempo.

O que muda para quem desenvolve

Na consulta pontual, Liquid Clustering termina em 1,003 segundo lendo 784,86 MB, enquanto ZOrder leva 1,437 segundo e lê 369,09 MB.[10] Menos dados lidos não correspondeu a menor latência nesse caso.[10] O autor atribui a vantagem de Liquid Clustering à localidade dentro dos arquivos e à organização por curva de Hilbert.[10]

No filtro multicoluna, a posição se inverte: ZOrder registra 0,615 segundo e 59,03 MB, contra 2,967 segundos e 639,95 MB de Liquid Clustering.[10] A explicação proposta é que predicados seletivos alinhados a um conjunto estável de colunas favorecem a eliminação precisa de arquivos.[10]

Minha recomendação é avaliar mais de uma dimensão. Bytes escaneados ajudam a explicar uma consulta, mas não substituem tempo de resposta, variabilidade, uso de computação e impacto das atualizações. Uma otimização que favorece uma carga também pode prejudicar outra que importa mais ao produto.

Como aplicar

Selecione as consultas que representam o serviço real: acesso pontual, intervalo temporal e filtro combinado, por exemplo. Preserve seletividade, distribuição e volume compatíveis com o uso esperado. Não transforme um caso raro no único critério de decisão.

Compare layouts em cópias isoladas dos mesmos dados, usando recursos equivalentes. Registre configuração, plano, arquivos e bytes lidos, latência e consumo. Repita a medição, diferencie cache frio e aquecido e conserve os resultados que contrariem a hipótese inicial.

Inclua a escrita no experimento. Meça ingestão, alterações, reorganização e esforço de agendar manutenção. Depois, pondere os resultados pela frequência e pela exigência de cada consulta. Um relatório financeiro recorrente e uma busca interativa podem ter tolerâncias diferentes.

O aceite deveria responder qual layout atende ao objetivo operacional com custo sustentável. Não basta produzir uma tabela com uma célula em negrito. Se os padrões de acesso mudam, defina também quando a decisão será reavaliada.

Cuidados e limites

O artigo não mede custo de escrita, amplificação de I/O ou computação de manutenção.[10] Portanto, a vantagem de leitura não comprova economia total de operação.

Os resultados da agregação ampla repetem os valores publicados para a agregação temporal.[10] Preserve essa particularidade em vez de apresentar as linhas como duas demonstrações independentes de superioridade.

Os dados são sintéticos, e o autor ressalva diferenças de distribuição, sazonalidade, evolução de esquema e padrões de produção.[10] Use o teste como roteiro para medir sua carga. Não como justificativa para migrar todas as tabelas, nem para aplicar mecanismos de Delta Lake diretamente a um banco relacional.

Fonte

[10] Fonte: InfoQ, artigo de Kushal Kumar Vishwakarma