HyperLogLog em produção: quando aceitar uma estimativa

Uma base moderada de usuários pode produzir centenas de milhões de eventos. HyperLogLog em produção entra justamente quando contar os identificadores distintos desse rastro exige um estado caro de manter, mover ou recomputar, e a decisão aceita uma estimativa com erro conhecido.

Por que COUNT DISTINCT fica caro em sistemas distribuídos?

O custo não depende apenas da quantidade de entidades cadastradas. Uma tabela com cinquenta mil usuários pode gerar uma tabela de eventos muitas vezes maior, com o mesmo identificador repetido milhares de vezes. Para responder quantos IDs únicos apareceram numa janela, a engine precisa representar estado suficiente para separar valores novos de repetidos.

Uma implementação direta usa um conjunto que cresce com a cardinalidade. Engines reais também podem ordenar, particionar ou derramar dados para disco. Quando a consulta roda em vários nós, a deduplicação global ainda pode exigir shuffle de identificadores ou estados intermediários.

Isso não torna toda consulta COUNT(DISTINCT) problemática. Baixa cardinalidade, índices favoráveis ou execução local podem manter a solução exata simples. O custo aparece quando o estado intermediário cresce, a consulta se repete ou a arquitetura precisa combinar resultados de muitas partições.

Como HyperLogLog em produção reduz o estado?

HyperLogLog aplica hash aos identificadores e usa padrões raros nos bits para estimar quantos valores distintos passaram. Em vez de guardar os elementos, mantém máximos distribuídos entre registradores. A quantidade de registradores define a memória e controla o erro esperado.

Essa troca tem uma consequência arquitetural importante: sketches compatíveis podem ser persistidos e combinados. Um sistema pode materializar um sketch por dia e depois uni-los para estimar a cardinalidade semanal ou mensal sem reler todos os eventos. Somar contagens diárias não funciona porque o mesmo usuário pode aparecer em vários dias. O merge preserva uma estimativa da união.

Os números dependem da implementação. O paper original descreve um arranjo de cerca de 1,5 KB com erro típico próximo de 2% para cardinalidades acima de um bilhão. O Redis documenta até 12 KB e erro padrão de 0,81%. Nenhum desses valores é propriedade universal do algoritmo.

Quando o erro do HyperLogLog compensa?

A aproximação é candidata quando a saída alimenta uma métrica agregada, tendência, painel ou cálculo de alcance, e uma pequena diferença não muda a decisão. Ela fica mais interessante quando sketches pré-agregados evitam recomputar grandes janelas ou transportar estados exatos entre nós.

O sketch deixa de servir quando o sistema precisa explicar quais elementos formam o total. Ele responde quantos, mas não quais. Também não recupera sensores ausentes, não calcula interseção exata e não permite reconciliação entidade por entidade.

Há ainda um contrato operacional. Hash, semente, precisão, versão e serialização precisam ser compatíveis para o merge. Estruturas do Redis, Trino, Snowflake ou outra engine não se tornam intercambiáveis apenas porque usam o nome HyperLogLog.

HyperLogLog ou contagem exata: qual escolher?

A pergunta prática é se o erro pode mudar a decisão ou impedir uma reconciliação posterior. Cobrança, quota rígida, auditoria e obrigações contratuais costumam exigir um total exato e explicável. Métricas operacionais podem aceitar aproximação, desde que o erro esteja documentado e medido.

Se a cardinalidade é moderada e a consulta exata já atende custo e latência, mantenha a solução simples. HyperLogLog resolve um custo observado. Sem esse custo, ele só adiciona contrato, erro estatístico e mais uma estrutura para o time operar.

Referências

Assista ao vídeo completo no YouTube →

Leia também