Questions d'entretien Apache Kafka
1. Qu'est-ce qu'Apache Kafka et quels problemes resout-il ?
Apache Kafka est une plateforme de streaming d'evenements distribue concue pour le traitement de donnees en temps reel a grande echelle. Il resout les problemes de : communication asynchrone entre services (messaging), ingestion de donnees a haut debit, traitement de flux temps reel, integration de donnees (connecter des systemes heterogenes), et journalisation d'evenements. Kafka est utilise par LinkedIn, Netflix, Uber et des milliers d'entreprises pour gerer des millions d'evenements par seconde.
2. Expliquez les concepts de topic, partition et offset.
Un topic est une categorie de messages (equivalent d'une table). Un topic est divise en partitions numerotees, distribuees sur les brokers du cluster. Chaque partition est un log ordonne et immutable. Les messages dans une partition ont un offset sequentiel unique (0, 1, 2, ...) qui sert d'identifiant. L'ordre des messages est garanti uniquement au sein d'une partition, pas entre partitions. Le nombre de partitions determine le parallelisme maximal de consommation.
3. Comment fonctionne la production de messages dans Kafka ?
Le producer envoie des messages a un topic. Chaque message a une cle (optionnelle) et une valeur. Si une cle est fournie, Kafka utilise un hash de la cle pour determiner la partition (memes cles = meme partition = ordre garanti). Sans cle, les messages sont distribues en round-robin. Le producer peut choisir le niveau de fiabilite : acks=0 (pas d'attente), acks=1 (attente du leader), acks=all (attente de tous les replicas en ISR). acks=all avec min.insync.replicas=2 est recommande pour la production.
4. Expliquez les consumer groups et le rebalancing.
Un consumer group est un ensemble de consumers qui se partagent la lecture d'un topic. Chaque partition est assignee a un seul consumer du groupe (pas de double lecture). Si un consumer tombe, ses partitions sont rebalancees vers les consumers restants. Le nombre maximum de consumers actifs dans un groupe est egal au nombre de partitions. Pour lire toutes les donnees, utilisez un consumer group dedie par application. Plusieurs groupes peuvent lire le meme topic independamment.
5. Comment Kafka garantit-il la durabilite des messages ?
Kafka replique chaque partition sur plusieurs brokers. Le leader gere les lectures et ecritures, les followers repliquent. L'ensemble des replicas a jour forme l'ISR (In-Sync Replicas). Un message est considere "committed" quand tous les ISR l'ont ecrit. Avec acks=all et min.insync.replicas=2, un message survit a la perte d'un broker. Les messages sont stockes sur disque avec un log compacte ou une retention temporelle (7 jours par defaut).
6. Qu'est-ce que Kafka Connect et quand l'utiliser ?
Kafka Connect est un framework pour connecter Kafka a des systemes externes sans coder. Les source connectors importent des donnees dans Kafka (bases de donnees avec CDC via Debezium, fichiers, APIs). Les sink connectors exportent des donnees de Kafka vers des destinations (Elasticsearch, S3, HDFS, bases de donnees). Avantages : pas de code a maintenir, scalabilite, gestion des erreurs et des offsets integree. Confluent Hub propose des centaines de connecteurs preconstruits.
7. Expliquez Kafka Streams et sa difference avec les consumers classiques.
Kafka Streams est une bibliotheque Java/Scala pour le traitement de flux en temps reel. Contrairement a un consumer qui lit et traite message par message, Kafka Streams offre des operations de haut niveau : filter, map, groupBy, aggregate, join (entre streams ou avec des tables), et les fenêtres temporelles (tumbling, hopping, session). Il maintient un etat local (RocksDB) pour les agregations. C'est une alternative legere a Apache Flink ou Spark Streaming, deployable comme une simple application Java.
8. Comment gerer les schemas des messages avec Kafka ?
Utilisez un Schema Registry (Confluent ou Apicurio) pour versionner les schemas des messages (Avro, Protobuf, JSON Schema). Le producer enregistre le schema et envoie l'ID du schema avec le message. Le consumer recupere le schema pour deserialiser. Le Schema Registry applique des regles de compatibilite (backward, forward, full) pour eviter les breaking changes. Avro est le format le plus utilise avec Kafka pour sa compacite et son support natif de l'evolution de schema.
9. Comment surveiller un cluster Kafka ?
Metriques essentielles : Under-replicated partitions (partitions dont les replicas ne sont pas a jour — indicateur de probleme), ISR shrink/expand (brokers qui quittent/rejoignent les ISR), consumer lag (retard entre la production et la consommation — critique), request latency (temps de reponse du broker), log size (espace disque). Outils : Kafka Manager / CMAK, Confluent Control Center, Prometheus + Grafana avec le JMX exporter, Burrow (monitoring du lag).
10. Quelles sont les bonnes pratiques pour Kafka en production ?
Dimensionnement : 3+ brokers minimum, facteur de replication 3 pour les topics critiques, min.insync.replicas=2. Partitions : ajustez le nombre selon le debit souhaite (chaque partition peut gerer ~10 Mo/s en ecriture). Configuration : acks=all pour la fiabilite, compression (lz4 ou zstd), retention adaptee au cas d'usage. Operations : monitoring du consumer lag, alertes sur les partitions sous-repliquees, mises a jour progressives (rolling restart). Securite : TLS entre brokers et clients, SASL pour l'authentification, ACLs pour l'autorisation.