Dans le premier article de cette série, j'ai présenté les arguments en faveur d'une architecture hybride de traitement par lots et en continu pour l'intégration des données et je me suis concentré sur la compréhension du calcul par lots. Dans le présent article, je me concentrerai sur la compréhension du calcul en continu. Dans le dernier article, je passerai en revue les avantages de l'unification du batch et du streaming pour l'intégration des données.
Comprendre le calcul en continu
Les moteurs de traitement des données en continu ont des fonctionnalités et des stratégies de mise en œuvre variées. D'une part, un moteur de traitement en continu peut traiter les données au fur et à mesure qu'elles arrivent, contrairement à un système par lots qui doit d'abord disposer de toutes les données avant de lancer un calcul. L'objectif du calcul en continu peut être de filtrer les données inutiles ou de transformer les données entrantes avant d'envoyer les données résultantes à leur destination finale. Si chaque élément de données en continu peut être traité indépendamment, les besoins en mémoire des nœuds de traitement des flux peuvent être limités tant que le calcul en continu peut suivre le rythme des données entrantes. En outre, il n'est souvent pas nécessaire ou souhaitable de conserver les données de flux entrantes sur le disque.
Un autre aspect, plus sophistiqué, du traitement des flux consiste à effectuer des calculs sur des ensembles de données entrantes, comme l'agrégation pour trouver une somme ou une moyenne. Cette méthode est utile dans de nombreux contextes où vous souhaitez répondre aux données entrantes en temps réel afin d'identifier un comportement ou de détecter des problèmes. Un ensemble de données peut être défini par un nombre fixe d'éléments de données, par exemple tous les 10 messages. Un ensemble de données peut également être défini comme les éléments de données qui arrivent au cours d'une période donnée, par exemple toutes les 30 secondes. Enfin, un ensemble de données en continu peut également être défini par une fenêtre coulissante dans laquelle un calcul en continu est effectué sur les 30 dernières secondes de données toutes les 10 secondes. Cela permet de créer des ensembles de données qui se chevauchent.
Tout comme le traitement des données par lots, le calcul en continu nécessite un moyen de gérer les défaillances au cours de l'exécution. Les moteurs de traitement de flux actuels, tels que Apache Storm, Apache Flink et Spark Streaming, ont tous des approches différentes pour parvenir à la tolérance aux pannes. L'une d'entre elles consiste à enregistrer périodiquement des points de contrôle des nœuds de flux dans un stockage persistant et à restaurer à partir du point de contrôle en cas de défaillance. Apache Flink utilise une forme de point de contrôle pour tolérer les défaillances. Une autre approche consiste à récupérer les défaillances en rejouant le flux de données entrant à partir d'un stockage fiable, tel qu'Apache Kafka. Apache Storm utilise une approche de relecture. Une autre approche adoptée par Spark Streaming consiste à lire les données entrantes dans des micro-lots qui sont répliqués dans la mémoire du cluster de traitement des flux. De cette manière, les données de flux entrantes peuvent être récupérées à partir d'une réplique.
Les différents moteurs de traitement de flux ont également des sémantiques de traitement différentes, qui sont influencées par leurs approches de la tolérance aux pannes. Storm et Flink peuvent traiter les données dès leur arrivée, alors que Spark doit combiner les données entrantes en micro-lots avant de les traiter. Cependant, l'approche par micro-lots peut conduire à un débit global plus élevé au détriment de la latence. Une autre différence sémantique concerne le traitement des messages au moins une fois ou exactement une fois. Spark Streaming et Flink ont une sémantique "exactly once", ce qui est plus facile à raisonner pour un programmeur. Storm prend en charge la sémantique "at least once" par défaut, mais la sémantique "exactly once" peut être obtenue en utilisant la couche API Trident pour Storm.
Bien que les fonctionnalités de ces moteurs de diffusion en continu se chevauchent dans une certaine mesure, certains moteurs conviendront mieux à différents types de problèmes. À l'heure actuelle, il n'existe pas de cadre universel permettant de résoudre tous les problèmes liés à la diffusion en continu. De plus en plus, les tâches d'intégration de données devront être exécutées à la fois dans un contexte de diffusion en continu et dans un contexte de traitement par lots.
Dans le dernier article de cette série, je décrirai les avantages de l'unification du traitement par lots et du traitement en continu pour l'intégration des données d'entreprise.
