Conservazione dei Dati in Kafka: Comprendere e Gestire i Tuoi Flussi di Eventi

La conservazione dei dati in Kafka risponde a una domanda pratica: per quanto tempo i tuoi flussi di eventi dovrebbero rimanere su disco prima che Kafka possa eliminarli? Se le impostazioni sono troppo permissive, i broker possono esaurire lo spazio. Se sono troppo aggressive, un consumatore lento potrebbe perdere la possibilità di riprodurre i dati.

Kafka memorizza i record nei log delle partizioni. Questi log sono suddivisi in file di segmento, e la pulizia della conservazione elimina i vecchi segmenti chiusi. Questo dettaglio è importante perché Kafka di solito non elimina un record alla volta nel momento in cui diventa vecchio. Un segmento diventa idoneo solo quando soddisfa le regole di conservazione configurate.

Perché le Impostazioni di Conservazione Contano

La conservazione è un compromesso tra spazio di archiviazione, esigenze di riproduzione e rischio operativo.

• Costo di archiviazione: Una conservazione lunga su topic ad alto volume può consumare molto disco del broker.
• Ripristino del consumatore: La tua finestra di conservazione deve essere più lunga del più lungo periodo realistico di inattività del consumatore o di rielaborazione.
• Stabilità: Dischi pieni possono impedire ai broker di accettare scritture e possono innescare problemi più ampi nel cluster.
• Conformità: Alcuni dati devono essere conservati per un periodo minimo, mentre altri dovrebbero essere rimossi rapidamente.

Un topic di pagamenti potrebbe aver bisogno di diversi giorni di cronologia di riproduzione. Un topic di log di debug in un cluster di sviluppo potrebbe aver bisogno solo di poche ore.

Come Kafka Elimina i Dati Vecchi

I topic di Kafka sono divisi in partizioni. Ogni partizione è un log ordinato e solo append. Kafka scrive nuovi record nel segmento attivo e passa a un nuovo segmento quando quello corrente raggiunge una dimensione o un'età configurata.

La conservazione si applica per partizione. Se imposti retention.bytes=1073741824, si tratta di circa 1 GiB per partizione, non 1 GiB per l'intero topic. Un topic con 12 partizioni può quindi conservare circa 12 GiB prima che vengano contate le repliche.

Quando sono configurati sia la conservazione basata sul tempo che quella basata sulla dimensione, Kafka può eliminare i vecchi segmenti idonei quando uno dei due limiti richiede la pulizia.

Conservazione Basata sul Tempo

La conservazione basata sul tempo mantiene i record per un periodo configurato.

A livello di broker, log.retention.ms imposta il valore predefinito per i topic che non lo sovrascrivono. A livello di topic, retention.ms sovrascrive quel valore predefinito per un topic.

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

Questo esempio imposta orders a tre giorni. Verificalo con:

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

Usa la conservazione temporale quando il tuo requisito principale è una finestra di riproduzione, come "i consumatori devono essere in grado di riprendersi da un'interruzione del fine settimana".

Conservazione Basata sulla Dimensione

La conservazione basata sulla dimensione limita la quantità di dati di log che ogni partizione può conservare.

A livello di broker, log.retention.bytes imposta il limite predefinito per partizione. A livello di topic, retention.bytes lo sovrascrive per un topic. Un valore di -1 significa nessun limite di dimensione da quella impostazione.

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

Questo imposta un limite di 1 GiB per partizione. Usa la conservazione basata sulla dimensione quando la protezione del disco è più importante di una finestra temporale fissa. Fai attenzione con i topic a burst, perché un picco di traffico può ridurre la finestra di riproduzione effettiva.

Valori Predefiniti del Broker e Override dei Topic

I valori predefiniti del broker si trovano in server.properties e si applicano ai topic che non impostano i propri valori di conservazione.

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

Modificare i valori predefiniti del broker di solito richiede un riavvio del broker o una modifica dinamica della configurazione del broker, a seconda della versione di Kafka e degli strumenti di deployment. Le modifiche a livello di topic tramite kafka-configs.sh sono spesso più sicure perché topic diversi raramente necessitano della stessa finestra di conservazione.

Per un nuovo topic, imposta la conservazione quando lo crei:

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

Per un topic esistente, modifica la configurazione del topic:

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

Per tornare al valore predefinito del broker, elimina l'override del topic:

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

Conservazione e Compattazione dei Log

La pulizia di Kafka è controllata da cleanup.policy. I valori comuni sono delete, compact, o entrambi come compact,delete.

• delete rimuove i vecchi segmenti di log in base al tempo o alla dimensione di conservazione.
• compact mantiene il valore più recente per ogni chiave e rimuove i valori più vecchi per quella chiave nel tempo.
• compact,delete consente l'applicazione sia delle regole di compattazione che di eliminazione.

La compattazione è utile per topic di tipo changelog, come gli aggiornamenti dei profili cliente indicizzati per ID cliente. Non è una sostituzione generale per la conservazione. I tombstone e la conservazione per eliminazione hanno il loro comportamento temporale, quindi testa i topic compattati prima di fare affidamento su di essi per la pulizia.

Checklist Pratica per la Conservazione

Inizia con la più lunga interruzione del consumatore che puoi tollerare. Se un gruppo di consumatori potrebbe essere offline per 48 ore, una finestra di conservazione di 24 ore è troppo breve.

Stima le esigenze del disco prima di modificare i topic di produzione:

tasso di ingest al secondo x secondi conservati x numero di partizioni x fattore di replica

Questa è solo una stima perché compressione, dimensione dei record, indici e overhead dei segmenti influenzano il numero reale. Tuttavia, fornisce un punto di partenza utile.

Monitora insieme l'utilizzo del disco del broker, il tasso di crescita dei topic, le partizioni sotto-replicate e il lag del consumatore. La pressione del disco combinata con un lag crescente è un avviso che i consumatori potrebbero uscire dalla finestra di conservazione.

Il valore predefinito più sicuro è semplice: usa la conservazione a livello di topic, documenta perché ogni topic ad alto volume ha la sua impostazione e testa una conservazione più breve in staging prima di applicarla in produzione.