Retenção de Dados no Kafka: Entendendo e Gerenciando Seus Fluxos de Eventos

A retenção de dados no Kafka responde a uma pergunta prática: por quanto tempo seus fluxos de eventos devem permanecer no disco antes que o Kafka possa excluí-los? Se suas configurações forem muito flexíveis, os corretores podem ficar sem espaço. Se forem muito agressivas, um consumidor lento pode perder a chance de reproduzir dados.

O Kafka armazena registros em logs de partição. Esses logs são divididos em arquivos de segmento, e a limpeza de retenção exclui segmentos fechados antigos. Esse detalhe é importante porque o Kafka geralmente não exclui um registro de cada vez no momento em que ele se torna antigo. Um segmento se torna elegível apenas quando atende às regras de retenção configuradas.

Por que as Configurações de Retenção são Importantes

A retenção é um trade-off entre armazenamento, necessidades de reprodução e risco operacional.

• Custo de armazenamento: Retenção longa em tópicos de alto volume pode consumir muito disco do corretor.
• Recuperação do consumidor: Sua janela de retenção deve ser maior que a maior interrupção realista do consumidor ou janela de reprocessamento.
• Estabilidade: Discos cheios podem impedir que os corretores aceitem gravações e podem desencadear problemas maiores no cluster.
• Conformidade: Alguns dados devem ser mantidos por um período mínimo, enquanto outros devem ser removidos rapidamente.

Um tópico de pagamentos pode precisar de vários dias de histórico de reprodução. Um tópico de log de depuração em um cluster de desenvolvimento pode precisar apenas de algumas horas.

Como o Kafka Exclui Dados Antigos

Os tópicos do Kafka são divididos em partições. Cada partição é um log ordenado somente de acréscimo. O Kafka escreve novos registros no segmento ativo e rola para um novo segmento quando o atual atinge um tamanho ou idade configurados.

A retenção se aplica por partição. Se você definir retention.bytes=1073741824, isso é aproximadamente 1 GiB por partição, não 1 GiB para todo o tópico. Um tópico com 12 partições pode, portanto, manter cerca de 12 GiB antes que as réplicas sejam contadas.

Quando a retenção baseada em tempo e a baseada em tamanho são configuradas, o Kafka pode excluir segmentos antigos elegíveis quando qualquer um dos limites exigir limpeza.

Retenção Baseada em Tempo

A retenção baseada em tempo mantém os registros por um período configurado.

No nível do corretor, log.retention.ms define o padrão para tópicos que não o substituem. No nível do tópico, retention.ms substitui esse padrão para um tópico.

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name orders \
  --alter \
  --add-config retention.ms=259200000

Esse exemplo define orders para três dias. Verifique com:

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name orders \
  --describe

Use retenção de tempo quando seu principal requisito for uma janela de reprodução, como "os consumidores devem ser capazes de se recuperar de uma interrupção de fim de semana".

Retenção Baseada em Tamanho

A retenção baseada em tamanho limita a quantidade de dados de log que cada partição pode manter.

No nível do corretor, log.retention.bytes define o limite padrão por partição. No nível do tópico, retention.bytes o substitui para um tópico. Um valor de -1 significa nenhum limite de tamanho dessa configuração.

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name high-volume-logs \
  --alter \
  --add-config retention.bytes=1073741824

Isso define um limite de 1 GiB por partição. Use retenção de tamanho quando a proteção do disco for mais importante que uma janela de tempo fixa. Tenha cuidado com tópicos de pico, porque um pico de tráfego pode encurtar a janela de reprodução efetiva.

Padrões do Corretor e Substituições de Tópico

Os padrões do corretor residem em server.properties e se aplicam a tópicos que não definem seus próprios valores de retenção.

log.retention.ms=604800000
log.retention.bytes=-1
log.retention.check.interval.ms=300000

Alterar os padrões do corretor geralmente requer uma reinicialização do corretor ou uma alteração dinâmica na configuração do corretor, dependendo da sua versão do Kafka e das ferramentas de implantação. As alterações no nível do tópico por meio de kafka-configs.sh são geralmente mais seguras porque diferentes tópicos raramente precisam da mesma janela de retenção.

Para um novo tópico, defina a retenção ao criá-lo:

kafka-topics.sh --bootstrap-server localhost:9092 \
  --create \
  --topic audit-events \
  --partitions 6 \
  --replication-factor 3 \
  --config retention.ms=604800000 \
  --config retention.bytes=2147483648

Para um tópico existente, altere a configuração do tópico:

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name audit-events \
  --alter \
  --add-config retention.ms=1209600000

Para voltar ao padrão do corretor, exclua a substituição do tópico:

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name audit-events \
  --alter \
  --delete-config retention.ms

Retenção e Compactação de Log

A limpeza do Kafka é controlada por cleanup.policy. Os valores comuns são delete, compact ou ambos como compact,delete.

• delete remove segmentos de log antigos com base no tempo ou tamanho de retenção.
• compact mantém o valor mais recente para cada chave e remove valores mais antigos para essa chave ao longo do tempo.
• compact,delete permite que as regras de compactação e exclusão sejam aplicadas.

A compactação é útil para tópicos do tipo changelog, como atualizações de perfil de cliente identificadas por ID do cliente. Não é uma substituição geral para retenção. Marcadores de exclusão e retenção de exclusão têm seu próprio comportamento de tempo, portanto, teste tópicos compactados antes de confiar neles para limpeza.

Lista de Verificação Prática de Retenção

Comece com a maior interrupção do consumidor que você pode tolerar. Se um grupo de consumidores pode ficar offline por 48 horas, uma janela de retenção de 24 horas é muito curta.

Estime as necessidades de disco antes de alterar tópicos de produção:

taxa de ingestão por segundo x segundos retidos x número de partições x fator de replicação

Isso é apenas uma estimativa porque compactação, tamanho do registro, índices e sobrecarga de segmento afetam o número real. Ainda assim, fornece um ponto de partida útil.

Monitore o uso do disco do corretor, a taxa de crescimento do tópico, as partições sub-replicadas e o atraso do consumidor juntos. A pressão no disco combinada com o aumento do atraso é um aviso de que os consumidores podem ficar fora da janela de retenção.

O padrão mais seguro é simples: use retenção no nível do tópico, documente por que cada tópico de alto volume tem sua configuração e teste a retenção mais curta em staging antes de aplicá-la à produção.