Retención de Datos en Kafka: Comprendiendo y Gestionando tus Flujos de Eventos

La retención de datos en Kafka responde a una pregunta práctica: ¿cuánto tiempo deben permanecer tus flujos de eventos en el disco antes de que Kafka pueda eliminarlos? Si tu configuración es demasiado permisiva, los brokers pueden quedarse sin espacio. Si es demasiado agresiva, un consumidor lento puede perder la oportunidad de reproducir datos.

Kafka almacena registros en registros de partición. Esos registros se dividen en archivos de segmento, y la limpieza de retención elimina los segmentos cerrados antiguos. Ese detalle importa porque Kafka normalmente no elimina un registro a la vez en el momento en que se vuelve antiguo. Un segmento se vuelve elegible solo cuando cumple con las reglas de retención configuradas.

Por Qué Importa la Configuración de Retención

La retención es un equilibrio entre almacenamiento, necesidades de reproducción y riesgo operativo.

• Costo de almacenamiento: Una retención prolongada en temas de alto volumen puede consumir mucho disco del broker.
• Recuperación del consumidor: Tu ventana de retención debe ser más larga que la interrupción del consumidor o la ventana de reprocesamiento más larga realista.
• Estabilidad: Los discos llenos pueden impedir que los brokers acepten escrituras y pueden desencadenar problemas más amplios en el clúster.
• Cumplimiento normativo: Algunos datos deben conservarse durante un período mínimo, mientras que otros deben eliminarse rápidamente.

Un tema de pagos podría necesitar varios días de historial de reproducción. Un tema de registro de depuración en un clúster de desarrollo podría necesitar solo unas pocas horas.

Cómo Kafka Elimina Datos Antiguos

Los temas de Kafka se dividen en particiones. Cada partición es un registro ordenado de solo anexión. Kafka escribe nuevos registros en el segmento activo y pasa a un nuevo segmento cuando el actual alcanza un tamaño o edad configurados.

La retención se aplica por partición. Si configuras retention.bytes=1073741824, eso es aproximadamente 1 GiB por partición, no 1 GiB para todo el tema. Un tema con 12 particiones puede, por lo tanto, mantener alrededor de 12 GiB antes de contar las réplicas.

Cuando se configuran tanto la retención basada en tiempo como la basada en tamaño, Kafka puede eliminar segmentos antiguos elegibles cuando cualquiera de los límites requiere limpieza.

Retención Basada en Tiempo

La retención basada en tiempo mantiene los registros durante un período configurado.

A nivel de broker, log.retention.ms establece el valor predeterminado para los temas que no lo anulan. A nivel de tema, retention.ms anula ese valor predeterminado para un tema.

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

Ese ejemplo establece orders a tres días. Verifícalo con:

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

Usa retención por tiempo cuando tu requisito principal sea una ventana de reproducción, como "los consumidores deben poder recuperarse de una interrupción de fin de semana".

Retención Basada en Tamaño

La retención basada en tamaño limita la cantidad de datos de registro que cada partición puede mantener.

A nivel de broker, log.retention.bytes establece el límite predeterminado por partición. A nivel de tema, retention.bytes lo anula para un tema. Un valor de -1 significa que no hay límite de tamaño desde esa configuración.

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

Eso establece un límite de 1 GiB por partición. Usa retención por tamaño cuando la protección del disco sea más importante que una ventana de tiempo fija. Ten cuidado con los temas con ráfagas, porque un pico de tráfico puede acortar la ventana de reproducción efectiva.

Valores Predeterminados del Broker y Anulaciones de Temas

Los valores predeterminados del broker residen en server.properties y se aplican a los temas que no establecen sus propios valores de retención.

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

Cambiar los valores predeterminados del broker generalmente requiere un reinicio del broker o un cambio de configuración dinámica del broker, dependiendo de tu versión de Kafka y las herramientas de implementación. Los cambios a nivel de tema a través de kafka-configs.sh suelen ser más seguros porque diferentes temas rara vez necesitan la misma ventana de retención.

Para un tema nuevo, establece la retención cuando lo crees:

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 un tema existente, modifica la configuración del tema:

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

Para volver al valor predeterminado del broker, elimina la anulación del tema:

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

Retención y Compactación de Registros

La limpieza de Kafka se controla mediante cleanup.policy. Los valores comunes son delete, compact, o ambos como compact,delete.

• delete elimina segmentos de registro antiguos según el tiempo o tamaño de retención.
• compact mantiene el valor más reciente para cada clave y elimina los valores más antiguos para esa clave con el tiempo.
• compact,delete permite que se apliquen tanto las reglas de compactación como las de eliminación.

La compactación es útil para temas de tipo registro de cambios, como actualizaciones de perfiles de clientes clave por ID de cliente. No es un reemplazo general para la retención. Las marcas de eliminación y la retención de eliminación tienen su propio comportamiento de temporización, por lo que debes probar los temas compactados antes de confiar en ellos para la limpieza.

Lista de Verificación Práctica de Retención

Comienza con la interrupción del consumidor más larga que puedas tolerar. Si un grupo de consumidores podría estar fuera de línea durante 48 horas, una ventana de retención de 24 horas es demasiado corta.

Estima las necesidades de disco antes de cambiar temas de producción:

tasa de ingesta por segundo x segundos retenidos x número de particiones x factor de replicación

Eso es solo una estimación porque la compresión, el tamaño del registro, los índices y la sobrecarga del segmento afectan el número real. Aún así, te da un punto de partida útil.

Monitorea el uso del disco del broker, la tasa de crecimiento del tema, las particiones sub-replicadas y el retraso del consumidor juntos. La presión del disco junto con un retraso creciente es una advertencia de que los consumidores pueden quedar fuera de la ventana de retención.

El valor predeterminado más seguro es simple: usa retención a nivel de tema, documenta por qué cada tema de alto volumen tiene su configuración y prueba una retención más corta en un entorno de prueba antes de aplicarla a producción.