Questions d'entretien Apache Kafka
1. Qu'est-ce qu'Apache Kafka et quels problèmes resout-il ?
Apache Kafka est une plateforme de streaming d'événements distribue conçue pour le traitement de données en temps réel a grande échelle. Il résout les problèmes de : communication asynchrone entre services (messaging), ingestion de données à haut debit, traitement de flux temps réel, intégration de données (connecter des systèmes heterogenes), et journalisation d'événements. Kafka est utilisé par LinkedIn, Netflix, Uber et des milliers d'entreprises pour gérer des millions d'événements par seconde.
2. Expliquez les concepts de topic, partition et offset.
Un topic est une catégorie 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 parallélisme maximal de consommation.
3. Comment fonctionne la production de messages dans Kafka ?
Le producer envoie des messages à un topic. Chaque message à une cle (optionnelle) et une valeur. Si une cle est fournie, Kafka utilise un hash de la cle pour déterminer la partition (mêmes clés = même partition = ordre garanti). Sans cle, les messages sont distribues en round-robin. Le producer peut choisir le niveau de fiabilité : acks=0 (pas d'attente), acks=1 (attente du leader), acks=all (attente de tous les réplicas en ISR). acks=all avec min.insync.réplicas=2 est recommandé 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 assignée à 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 données, utilisez un consumer group dédié par application. Plusieurs groupes peuvent lire le même topic indépendamment.
5. Comment Kafka garantit-il la durabilité des messages ?
Kafka replique chaque partition sur plusieurs brokers. Le leader gere les lectures et écritures, les followers repliquent. L'ensemble des réplicas à jour forme l'ISR (In-Sync Réplicas). Un message est considere "committed" quand tous les ISR l'ont ecrit. Avec acks=all et min.insync.réplicas=2, un message survit à la perte d'un broker. Les messages sont stockes sur disque avec un log compacte ou une retention temporelle (7 jours par défaut).
6. Qu'est-ce que Kafka Connect et quand l'utiliser ?
Kafka Connect est un framework pour connecter Kafka à des systèmes externes sans coder. Les source connectors importent des données dans Kafka (bases de données avec CDC via Debezium, fichiers, APIs). Les sink connectors exportent des données de Kafka vers des destinations (Elasticsearch, S3, HDFS, bases de données). Avantages : pas de code à maintenir, scalabilité, gestion des erreurs et des offsets integree. Confluent Hub propose des centaines de connecteurs preconstruits.
7. Expliquez Kafka Streams et sa différence avec les consumers classiques.
Kafka Streams est une bibliothèque Java/Scala pour le traitement de flux en temps réel. Contrairement à un consumer qui lit et traite message par message, Kafka Streams offre des opérations de haut niveau : filter, map, groupBy, aggregate, join (entre streams ou avec des tables), et les fenêtrès temporelles (tumbling, hopping, session). Il maintient un état local (RocksDB) pour les agrégations. C'est une alternative légère à Apache Flink ou Spark Streaming, déployable comme une simple application Java.
8. Comment gérer les schémas des messages avec Kafka ?
Utilisez un Schéma Registry (Confluent ou Apicurio) pour versionner les schémas des messages (Avro, Protobuf, JSON Schéma). Le producer enregistre le schéma et envoie l'ID du schéma avec le message. Le consumer récupère le schéma pour deserialiser. Le Schéma Registry applique des règles de compatibilité (backward, forward, full) pour éviter les breaking changes. Avro est le format le plus utilise avec Kafka pour sa compacite et son support natif de l'évolution de schéma.
9. Comment surveiller un cluster Kafka ?
Métriques essentielles : Under-replicated partitions (partitions dont les réplicas ne sont pas à jour — indicateur de problème), ISR shrink/expand (brokers qui quittent/rejoignent les ISR), consumer lag (retard entre la production et la consommation — critique), request latency (temps de réponse 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 réplication 3 pour les topics critiques, min.insync.réplicas=2. Partitions : ajustez le nombre selon le debit souhaite (chaque partition peut gérer ~10 Mo/s en écriture). Configuration : acks=all pour la fiabilité, compression (lz4 ou zstd), retention adaptée au cas d'usage. Opérations : monitoring du consumer lag, alertes sur les partitions sous-repliquees, mises à jour progressives (rolling restart). Sécurité : TLS entre brokers et clients, SASL pour l'authentification, ACLs pour l'autorisation.