Traitement de données en streaming : architecture sur Kafka et Flink

# Traitement de flux : Une architecture comme des briques LEGO

Les systèmes modernes de traitement de données exigent flexibilité et évolutivité. Dans cet article, nous décomposons la manière de combiner Kafka, Flink, S3 et d'autres composants en une plateforme de streaming unifiée en utilisant des principes d'architecture modulaire. Nous plongerons en détail dans les étapes d'intégration, de la génération de données à l'analyse en temps réel.

Fondations du système : Plateforme de streaming

Pour construire un traitement de flux, nous utilisons une pile de technologies éprouvées. Le composant central est Apache Kafka — une plateforme de streaming distribuée qui garantit une livraison fiable des messages. À ses côtés, nous utilisons :

• Kafka Connect pour l'intégration avec des systèmes externes
• Schema Registry pour la gestion des schémas de données
• Kafka UI comme interface de gestion visuelle

L'idée clé est de traiter les composants comme des briques LEGO. Chacun gère une fonction spécifique et se connecte aux autres via des interfaces bien définies. Pour lancer une configuration minimale, Docker Compose et Git LFS suffisent. Le système est assemblé via des builds multi-étapes, garantissant des environnements reproductibles.

Exemple de configuration de base dans docker-compose.yml :

services:
  kafka:
    image: confluentinc/cp-kafka:8.1.0
    environment:
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092

  schema-registry:
    image: confluentinc/cp-schema-registry:8.1.0
    environment:
      SCHEMA_REGISTRY_KAFKASTORE_BOOTSTRAP_SERVERS: kafka:9092

Il est important de comprendre la différence entre les bases de données traditionnelles et les systèmes de streaming. Dans les SGBD relationnels, l'accent est mis sur l'état (tableaux, enregistrements), tandis que dans le traitement de flux, il porte sur les événements. Chaque message dans Kafka représente un événement immuable ajouté à la fin du journal. Cette approche permet des systèmes avec livraison garantie et récupération d'état.

Étapes d'intégration des données

Nous diviserons le processus de construction du système en quatre étapes logiques :

• Ingest — réception des données provenant de sources externes
• Storage — stockage persistant
• Transform — transformation et enrichissement
• Serve — livraison des résultats

Ingest : Génération et ingestion des données

Dans l'étape Ingest, nous configurons la source de données via Kafka Connect. Pour la démonstration, nous implémentons un générateur de relevés de capteurs de température. Le connecteur Java génère des données synthétiques avec des coordonnées géographiques et une température, en tenant compte de l'heure de la journée et de la position par rapport à l'équateur.

Configuration du connecteur :

{
  "connector.class": "dev.miron.connect.temp.TempSourceConnector",
  "tasks.max": "1",
  "topic": "earth-temp",
  "sensors": "5",
  "messages.per.sensor.per.second": "1"
}

Notez l'utilisation d'Avro pour la sérialisation. Les messages sont stockés au format binaire, réduisant le volume de trafic et accélérant le traitement. Schema Registry gère le versionnage des schémas et les contrôles de compatibilité (mode BACKWARD). Lorsque la structure des données change, le système rejette automatiquement les mises à jour invalides.

Storage : Stockage à long terme

Pour le stockage persistant, nous utilisons une combinaison de S3 et Apache Iceberg. S3 sert de stockage d'objets, tandis qu'Iceberg ajoute une couche de métadonnées permettant des transactions ACID et le voyage dans le temps. Cette approche gère efficacement les grands ensembles de données, en évitant les problèmes des systèmes de fichiers traditionnels.

Configuration du connecteur sink :

{
  "connector.class": "io.confluent.connect.s3.S3SinkConnector",
  "topics": "earth-temp",
  "s3.bucket.name": "data-lake",
  "storage.class": "io.confluent.connect.s3.storage.S3Storage",
  "format.class": "io.confluent.connect.s3.format.avro.AvroFormat"
}

Pour les requêtes de données, nous utilisons Trino — un moteur SQL distribué capable de fédérer des données provenant de multiples sources. Cela permet des requêtes analytiques complexes sans déplacer les données.

Transformation des données

Nous implémentons l'étape Transform avec Apache Flink — un moteur de traitement de flux supportant les fenêtres et les opérations avec état. Exemple de tâche : conversion de la température de Fahrenheit en Celsius et filtrage des valeurs anomalaires.

DataStream<TempEvent> processed = source
  .map(event -> {
    event.setCelsius((event.getFahrenheit() - 32) * 5/9);
    return event;
  })
  .filter(event -> event.getCelsius() > -50 && event.getCelsius() < 60);

Flink s'intègre avec Kafka via des connecteurs natifs. Il est crucial de configurer correctement le checkpointing pour des garanties de traitement exactly-once. Paramètres clés :

• execution.checkpointing.interval: 60000
• state.backend: rocksdb
• state.checkpoints.dir: file:///checkpoints

Pour la surveillance, nous utilisons l'interface web intégrée de Flink pour suivre les retards de traitement (lag) et les états des opérateurs.

Couche de service

Dans l'étape finale, les données deviennent disponibles pour les consommateurs. Nous implémentons deux options :

• PostgreSQL via un connecteur JDBC pour les requêtes opérationnelles
• Redis pour la mise en cache des données chaudes

Configuration du sink PostgreSQL :

{
  "connector.class": "io.confluent.connect.jdbc.JdbcSinkConnector",
  "connection.url": "jdbc:postgresql://postgres:5432/analytics",
  "topics": "processed-temp",
  "auto.create": "true",
  "insert.mode": "upsert",
  "pk.fields": "sensorId,timestamp"
}

Pour Redis, nous utilisons un connecteur personnalisé qui stocke les derniers relevés pour chaque capteur dans des tables de hachage. Cela offre une latence en millisecondes pour les requêtes sur les données actuelles.

Points clés

• Les schémas de données doivent être gérés via Schema Registry avec compatibilité BACKWARD
• Le traitement avec état dans Flink nécessite une configuration du checkpointing et une sélection du backend d'état
• La décomposition du système en étapes Ingest/Storage/Transform/Serve simplifie le débogage
• La sérialisation binaire (Avro/Protobuf) est critique pour les performances des systèmes de streaming
• Le test des configurations via Docker Compose permet des itérations rapides

— Editorial Team