Aller au contenu principal
Version: 1.3.1.0

Présentation d'Apache Kafka

Apache Kafka est une plateforme de streaming d'événements distribuée, conçue pour des pipelines de données en temps réel à haut débit et tolérants aux pannes. ODP 1.3.1.0 intègre Kafka 3.8.1, qui repose sur une architecture entièrement basée sur KRaft, éliminant ainsi la dépendance à ZooKeeper pour la gestion des métadonnées de Kafka.

Qu'est-ce que Kafka ?​

Kafka modélise les données comme un flux continu, ordonné et durable d'événements (également appelés enregistrements ou messages). Contrairement aux files de messages traditionnelles où les messages sont consommés puis supprimés, Kafka conserve les événements pendant une période configurable (7 jours par défaut), permettant à plusieurs consommateurs indépendants de lire le même flux à des positions et à des moments différents.

Kafka joue le rôle de système nerveux central pour les architectures de données en temps réel : les producteurs écrivent des événements au fil de leur occurrence, et n'importe quel nombre de consommateurs peut les traiter — en temps réel ou en rejouant l'historique.

Concepts fondamentaux​

Topics et partitions​

Les données dans Kafka sont organisées en topics — des journaux nommés en ajout uniquement. Chaque topic est divisé en partitions distribuées sur l'ensemble du cluster de brokers. Le partitionnement offre :

  • Parallélisme : plusieurs consommateurs peuvent lire simultanément des partitions différentes d'un même topic.
  • Ordonnancement : les événements au sein d'une même partition sont strictement ordonnés ; ce n'est pas le cas entre partitions différentes.
  • Scalabilité : les topics peuvent comporter des centaines de partitions réparties sur de nombreux brokers, permettant une mise à l'échelle horizontale du débit.

Chaque partition est répliquée sur plusieurs brokers pour assurer la tolérance aux pannes. Un leader désigné gère toutes les lectures et écritures d'une partition ; les followers répliquent les données et prennent le relais en cas de défaillance du leader.

Groupes de consommateurs​

Un groupe de consommateurs est un ensemble de consommateurs qui traitent coopérativement un topic. Chaque partition est assignée à un seul consommateur au sein du groupe, permettant un traitement parallèle tout en garantissant que chaque événement est traité par exactement un consommateur du groupe. Les différents groupes de consommateurs suivent indépendamment leur propre position de lecture (offset) dans chaque partition, de sorte qu'un même topic peut alimenter plusieurs systèmes en aval sans interférence.

Kafka 3.8.1 dans ODP​

ODP intègre Kafka 3.8.1, déployé et géré par Ambari. Points clés :

  • Mode KRaft : Kafka 3.8.1 fonctionne en mode KRaft, utilisant un contrôleur de quorum interne basé sur Raft pour la gestion des métadonnées. Cela simplifie les opérations en supprimant la dépendance à ZooKeeper du plan de contrôle Kafka (ZooKeeper reste utilisé par d'autres services ODP).
  • Intégration Ambari : la configuration des brokers, la gestion des topics et les métriques au niveau des brokers sont accessibles depuis l'interface Ambari. Ambari gère les redémarrages progressifs et les modifications de configuration.
  • Déploiement multi-brokers : les architectures de référence ODP déploient les brokers Kafka sur des nœuds worker dédiés pour les isoler des I/O des DataNodes HDFS.

Cas d'usage​

Pipelines de données en temps réel​

Kafka découple les producteurs de données des consommateurs, permettant des architectures orientées événements où les systèmes en amont (bases de données, applications, appareils IoT, APIs) publient des événements sans avoir à connaître les systèmes en aval qui les consommeront. NiFi dans ODP peut ingérer des données depuis des sources externes et les publier dans des topics Kafka ; Spark Streaming et Flink consomment ensuite ces topics pour le traitement.

Sourcing d'événements​

Parce que Kafka conserve l'historique complet des événements, il s'adapte naturellement aux patterns d'event sourcing, où l'état actuel d'un système est dérivé en rejouant les événements passés. Cela permet des pistes d'audit, des requêtes temporelles et la récupération après des erreurs de traitement en aval en rejouant depuis un offset connu.

Change Data Capture (CDC)​

Kafka Connect (inclus avec Kafka) prend en charge des connecteurs CDC qui capturent les modifications au niveau des lignes dans des bases de données relationnelles et les publient en tant qu'événements Kafka. Ces événements peuvent être consommés par Spark ou Flink pour maintenir des réplicas quasi-temps réel dans HDFS ou dans des tables Iceberg.

Spark Structured Streaming​

Spark traite un topic Kafka comme une table source non bornée. Un DataFrame en streaming lit les événements en continu :

df = (spark.readStream
    .format("kafka")
    .option("kafka.bootstrap.servers", "broker01:9092,broker02:9092")
    .option("subscribe", "events")
    .load())

Spark gère automatiquement la gestion des offsets, la livraison en exactement-once (avec des sinks Iceberg ou HDFS), et le watermarking pour les données tardives.

Le connecteur Kafka natif de Flink prend en charge les rôles de source et de sink avec une sémantique exactement-once via les transactions Kafka. Le modèle de traitement basé sur le temps événementiel de Flink, combiné au suivi des offsets de Kafka, permet un traitement de flux avec état à latence milliseconde — adapté au traitement d'événements complexes, à la détection de fraude et aux agrégations en temps réel.

Plugin Ranger pour l'autorisation Kafka​

Dans ODP, le plugin Apache Ranger pour Kafka applique le contrôle d'accès sur les ressources Kafka. Les politiques Ranger peuvent :

  • Accorder ou refuser les permissions Publish (produire) et Consume par topic, par utilisateur ou groupe
  • Restreindre les opérations de création et de suppression de topic
  • Journaliser toutes les tentatives d'accès dans la piste d'audit Ranger à des fins de conformité

Le plugin Ranger pour Kafka s'intègre à l'interface Authorizer intégrée de Kafka et est configuré automatiquement par Ambari lorsque Ranger est activé sur le cluster.

Métriques Kafka dans Ambari​

Ambari collecte et affiche les métriques Kafka essentielles nativement :

  • Métriques des brokers : octets entrants/sortants par seconde, messages entrants par seconde, partitions sous-répliquées
  • Lag du consommateur : la différence entre le dernier offset et l'offset actuel du groupe de consommateurs — indicateur de santé critique pour les pipelines de streaming
  • Métriques par topic : débit par topic et distribution des leaders de partitions

Ces métriques alimentent le système d'alertes d'Ambari, permettant aux opérateurs de configurer des alertes pour les seuils de lag des consommateurs, l'indisponibilité d'un broker ou les événements de sous-réplication.