Le stream processing, quesako ?

Publié par Damien Fleuret le

Temps de lecture : 3 minutes

Asynchrone, flux, stream, stream de données, stream processing…
Vous avez sûrement déjà entendu au moins une fois ces mots là. Savez-vous ce qu’il se cache derrière ce jargon infernal ? Ou bien avez-vous peur de vous perdre dans les méandres de la technique en essayant de comprendre ce que cela peut bien vouloir dire ? 

En moins de 5 min, nous allons essayer de démystifier ces termes barbares, qui ont tous pour même thème, le stream processing.

Quelques mots-clés

Avant d’entrer dans le vif du sujet, quelques définitions importantes.
Stream : mot anglais, flux continu de données, potentiellement sans fin (pour nos amis anglophones, endless data).
Stream processing : mot anglais, paradigme de programmation décrivant le traitement d’un stream.
Batch processing : mot anglais, traitement par morceaux de données ou traitement des données toutes les X secondes.
Producteur (producer) : application qui génère le stream.
Consommateur (consumer) : application qui attend et qui traite les données du flux.

Quesako ?

Actuellement, le mécanisme de traitement des données le plus répandu est le batch processing.

Ce mécanisme a cependant quelques limites :

  • Temps de traitement long
  • Aucune réactivité (batchs souvent lancés la nuit)

Durant les années 80, un nouvelle pensée émerge pour pallier ces problèmes, le stream processing. Il s’agit plus exactement d’un paradigme de programmation, une manière de construire son logiciel.

Contrairement aux batchs, il permet de produire/traiter/transmettre des données et/ou d’effectuer des calculs au fil de l’eau, de façon « quasi-instantanée« .
Les utilisateurs / applications reçoivent donc les données de manière continue et n’ont plus à attendre que les données soient traitées dans leur intégralité.

A quelle sauce ?

Le stream processing est spécialement efficace pour des applications :

  • Gourmande en calculs
  • Asynchrones, c’est à dire qui n’ont pas besoin d’attendre le résultat d’une opération
  • Générant beaucoup de données temporaires

On peut citer par exemple :

  • Le traitement graphique (calcul sur des vertex pour les jeux vidéos),
  • Le traitement d’images/vidéos : stream de vidéos (Youtube, Netflix ,…)
  • L’IoT Internet Of Things, ou L’Internet des objets IdO en français : station météo (Température, pression, hydrométrie, …)
  • Le monitoring : les logs, trace applicative, métriques machine, …
  • La Finance : les transactions, les prix, …
  • Les applications en ligne : drive google par ex.

Quels outils derrière ça ?

Il existe aujourd’hui plusieurs outils répondant aux besoins principaux des développeurs.

On peut citer les files JMS (natif java 6), ActiveMQ (Apache), RabbitMQ (Pivotal), Apache Kafka (Apache Sofware Fundation, solution Kafka by Confluent), Pulsar (Apache / by Yahoo).

Nous ne détaillerons pas la mise en place de tels outils ici, cela sera traité dans de futurs articles. En attendant, vous pouvez commencer à jouer avec ces outils ici, ou ici, ou encore là.

Un paradigme parfait ? :thinking:

Nous avons déjà cité ses avantages par rapport au batch processing, mais il en a encore sous le capot.
Cependant, comme tout le monde, il a aussi son côté sombre…

Autres avantages

  • Permet de réduire l’adhérence entre les applications. En effet, l’utilisation d’un acteur tiers pour le stream permet d’isoler plus fortement les applications. Cela facilite la mise à jour du SI.
  • Les solutions de stream processing sont souvent distribuées : il est possible d’avoir plusieurs producteurs/consommateurs sur un même flux. Cela peut accélérer le traitement ou permettre de faire des traitements de nature différente en parallèle.

Inconvénients

  •  Il s’agit d’un autre mode de pensée, cela nécessite donc une « remise en question » des développeurs accompagnée d’un temps d’adaptation.
  • Le débogage est plus difficile : la façon dont est liée les applications est indirecte, localiser le traitement qui perturbe le système est complexe.
  • La mise en place est difficile dans des SI applicatifs, qui ne sont pas souvent adaptés.
  • Le  Théorème de Brewer (Event Consistency) empêche un système distribué de garantir en même temps la cohérence, la disponibilité et la tolérance aux partitions des données.
    Un effort supplémentaire sera requis afin de paramétrer au mieux les flux pour répondre au besoin.

    • Disponibilité et cohérence –> Gestion du fenêtrage de données (Time trigger, count trigger, Sliding Window, Session window etc.)
    • Cohérence –> Problèmes temps event vs temps processing
    • Cohérence –> Gestion de l’ordre de traitement (FIFO, First In First Out). L’ordonnancement des évènements n’est jamais garanti.
    • Tolérance aux partitions –> Configuration avancée de l’outil utilisé. (Sauvegarde, réplication etc.)

Mission accomplie ?

Nous avons vu ensemble les principes de base de ce paradigme et ses cas d’utilisation dans un système d’information.
Le Stream Processing n’est maintenant plus un « secret » pour vous. Si vous avez besoin d’informations supplémentaires, voici quelques sources très intéressantes :

Catégories : Développement

Damien Fleuret

Développeur Back