Accueil > Big Data, Divers > Big Data : spécificités des traitements en « temps réel »

Big Data : spécificités des traitements en « temps réel »

écrit par René Lefebure

28 mai

(Inspiré d’un article de Mike Barlow sur l’émergence des architectures Big Data)

Un des 3 V du BIG DATA

Si on considère les 3 V du Big Data, on constate qu’il est assez simple de comprendre les impacts sur le Volume et la Variété des données, mais que le concept de Vélocité est souvent moins explicité, voire couvre des aspects assez différents selon les conférenciers.

En fait, on comprend qu’il est de plus en plus important d’aller vite, mais que derrière la Vélocité on retrouve des éléments différents :

–         Time is Money …. le fait de pouvoir être plus rapide et plus agile donne un avantage,

–         Real Time … le fait de pouvoir réagir en fonction du contexte créé la pertinence de la communication.

Le temps c’est de l’argent

Ces deux notions correspondent à des concepts différents :

–         dans le premier cas il s’agit d’agilité pour capter avant les autres des signaux faibles, et pouvoir « prendre de l’avance »,

–         dans le second cas, on peut dire « Après l’heure, ce n’est plus l’heure » et qu’il s’agit de ne pas manquer le moment.

Cet article se propose de définir un peu plus cette notion de temps réel (ou semi-temps réel), de préciser les contraintes d’architecture qui permettent de traiter des données « à la volée », et enfin d’introduire deux composants qui visent à développer cette capacité du temps réel dans les projets Big Data.

 Qu’est-ce que le temps réel ?

Cette promesse de la vitesse est un élément « marketing » qui se révèle être dans de nombreux cas un abus de langage. A l’identique de la promesse de pouvoir traiter des « données non structurées » (car en fait le Big Data passe son temps à transformer une partie des données non structurées dans des formes structurées pouvant être analysées et utilisées), il n’existe pas de vrai « temps réel ».

Le « temps réel » dénote la capacité de traiter les données « à la volée », plutôt que de stocker les données et de les retrouver ensuite. Il s’agit du premier facteur de distinction de la notion de temps réel : on traite les données au Présent et pas dans un Futur. Si je fais appel à une notion de « mémoire » de la donnée, je ne suis pas vraiment en train de faire du temps réel.

 Temps réel = agir au Présent

Il est important dans ce contexte de distinguer :

–         la donnée qui arrive,

–         le modèle de connaissance qui me permet de traiter cette donnée.

La rencontre des 2 éléments peut nécessiter un traitement en temps réel (mais ce type d’approche n’est pas spécifique au Big Data) sauf

–         si le flux de données est très volumineux,

–         si le modèle de connaissance est reconstruit au fur et à mesure du flux de données.

Dans la majeure partie des traitements, le modèle de connaissance est construit sur de Passé … et s’applique sur des données au Présent.

Seule la simultanéité des données et de la connaissance sur le Temps Présent relève du « Temps Réel ».

 La relativité du temps réel

En effet, la notion de PRÉSENT recouvre différents contextes en fonction des utilisateurs.

Selon un site e-commerce, le présent correspond à la durée qui peut se traduire par l’abandon du visiteur. On peut situer ce temps à 0,1 seconde. Si le temps de traitement entre la donnée de navigation et le modèle de connaissance est supérieur à ce dixième de seconde on sort du « temps réel ».

Dans une salle de marché, alimentée par des flux continus de cotation, le temps « réel » se rapproche davantage de la notion de « milli seconde » qui peut lui faire manquer une opportunité.

Selon un militaire qui lance un missile, le temps réel est une micro seconde qui peut lui faire louper la cible.

On constate donc des différences de « timing ».

 Comment se construit le temps réel

Le temps réel pour être effectif doit s’appliquer sur 2 niveaux :

–         Vitesse au niveau de la couche des données,

–         Vitesse au niveau de la couche décisionnelle.

Selon Joe Hellerstein de l’Université de Berkeley, le vrai temps réel ne concerne que les robots. En effet, dès que les humains interviennent dans cette « boucle », il est impropre de parler de temps réel. En effet, une personne prend entre une ou deux secondes pour réagir, ce qui est un espace de temps important qui est géré par les systèmes transactionnels traditionnels (comme dans les Call Center par exemple).

Les systèmes actuels de recommandation utilisés dans les Centres d’Appels ne relèvent pas vraiment de la problématique « Temps réel » (ce qui ne veut pas dire qu’ils ne doivent pas être performants) car on se situe dans le timing de la seconde.

On comprend que la Google Car nécessite de réagir en « temps réel » ce qui implique donc d’accéder très rapidement à son « univers de données », et d’utiliser une couche décisionnelle de manière très rapide pour éviter de renverser un piéton inattentif.

 Les solutions qui permettent du Temps réel

Tous les conférenciers soulignent l’incapacité d’Hadoop de faire du temps réel. A l’image de son logo, Hadoop est plutôt lent et se complait dans le mode « batch ». Il faut compléter Hadoop avec des solutions pour transformer l’éléphant en guépard.

La littérature m’a permis d’identifier deux solutions (liste à mon avis non limitative) : Spark et Storm

–         Spark est un programme Open Source, supporté par Google qui permet de traiter des volumes de données de 1 à 2 Téra en moins d’une seconde. Dans des scénarios utilisant des algorithmes d’apprentissage de type « Machine Learning » Spark peut traiter avec des facteurs d’amélioration compris entre 10 et 100 fois plus vite que Hadoop MapReduce.

–         Storm est un programme Open Source utilisé par des entreprises comme Twitter ou Groupon qui tire profit des options de parallélisme pour s’approcher du temps réel.

Dans le cas de Twitter on peut distinguer les 2 phases dans le traitement de la donnée :

–         Le traitement « Batch » qui présente un temps de latence important. Si on souhaite faire des traitements d’un TeraByte de données, il n’est pas possible de le faire en moins de 1 seconde.

–         Le traitement « Stream » analyse les données au fur et à mesure où les données arrivent (par petit paquet). Il est possible de faire des traitements intensifs telles que des recherches en parallèle, des fusions et rapprochement de données.

En principe lorsque l’on souhaite faire une requête de recherche, il est nécessaire de créer des tables d’index, ce qui est un processus qui nécessite un temps en dehors de la plage « temps réel ». Avec Storm, on peut traiter le flux sur plusieurs machines et obtenir des réponses de manière plus rapide.

Twitter utile Storm pour identifier des tendances dans une logique proche du temps réel. Par exemple si une personne est en train de partager son expérience sur une piste de ski, Storm aidera Twitter pour afficher la publicité la plus adaptée en fonction du contexte de la personne.

En conclusion

Si vous voulez commencer un projet Big Data :

–         Définissez votre attente en termes de Temps de Réponse (êtes-vous vraiment en temps réel avec les 2 Présents),

–         Établissez une distinction nette entre les fonctions relatives à la lecture des données et les parties analytiques pour décider sur les données (quelle fraîcheur attendez-vous de vos modèles),

–         Prévoyez un compagnon pour faire pédaler plus vite Hadoop.

Pour en savoir plus : Amazon

Pas encore de commentaire

Faire un commentaire