Un intergiciel post-Hadoop pour gérer les flux de données

Il fut un temps où les architectures de supercalcul se composaient de deux parties. Des machines pour le stockage de données. D'autres pour leur traitement. Pour travailler, on faisait donc passer les données d'une machine à l'autre. Ce qui prenait du temps.

Tout cela a changé avec deux articles phares publiés en 2003 et 2004 par Google. « Le premier a introduit GFS, le système de fichiers de Google, raconte Shadi Ibrahim, membre de l'équipe Stack au centre Inria Rennes – Bretagne Atlantique. Désormais, les grands fichiers seraient divisés en petits morceaux distribués sur de multiples serveurs, chaque morceau se situant sur un serveur et étant dupliqué environ trois fois. En cas de crash, la donnée resterait donc disponible sur un autre serveur. » Double avantage : « vous pouvez lire le fichier plus vite car vous accédez à la donnée en parallèle. Par ailleurs, le traitement est aussi plus rapide. »

Le traitement, il en est justement question dans le deuxième article consacré, lui, à Map Reduce : une méthode novatrice pour la gestion du big data . « Google avait toutes ces machines où s'entreposaient des données désormais très disponibles grâce à de multiples serveurs. Alors, ils se sont dit qu'ils allaient utiliser ces machines non plus seulement pour le stockage, mais aussi pour le calcul. Du coup, plus besoin de transférer via le réseau. »

Le moteur qui fait fonctionner le cloud

Peu après, Doug Cutting, un programmeur inspiré par ces deux publications, développait un intergiciel open source pour implémenter Map Reduce et faciliter la création d'applications utilisant ce paradigme. Son nom : Hadoop. Massivement adopté par l'industrie, il devient vite “le moteur qui fait fonctionner le cloud.”

Mais avec une limite : « il ne peut pas gérer les applications traitant des flux de données. Il peut uniquement traiter des données de taille fixe déjà stockées dans le système de fichier. Aujourd'hui, pourtant, beaucoup d'applications génèrent massivement des flux de données qu'il faut traiter aussitôt qu'elles arrivent. La voiture autonome par exemple. Ses capteurs collectent des informations et les décisions doivent être très rapides. Pas le temps de stocker les données. Il faut les traiter immédiatement. »

Spark, Storm et Flink

Plusieurs solutions alternatives capables de prendre en compte ces flux de données ont vu le jour. “Les plus utilisées sont :  Spark, Storm et  Flink. Les deux premiers viennent des États-Unis. Le dernier a été conçu par TU Berlin. Mais eux aussi rencontrent tous des problèmes. ”

Le projet KerStream s'intéresse à trois d'entre eux. Pour commencer, il se penche sur la façon dont ces modèles considèrent les ressources et les tâches. « Ils partent du présupposé que les machines sont uniformes et que les tâches ont toutes le même coût. Or, en réalité, ni les unes ni les autres ne sont homogènes. Sur votre grappe, vous pouvez avoir des machines différentes, ou des performances différentes selon les machines si, par exemple, d'autres applications partagent la ressource. De plus, des tâches différentes vont avoir des complexités différentes. Et la charge varie dans le temps. Il faut donc prendre en compte cette dynamicité de la charge. Ce que les modèles actuels ne font pas. »

Détecter les retardataires

Le deuxième axe de recherche vise à gérer le problème des retardataires. C'est-à-dire les tâches qui s'exécutent plus lentement que les autres. « Pour les détecter, Hadoop regarde le taux de progression des différentes tâches pendant l'exécution et repère, par exemple, celles qui sont 20% moins rapides que la moyenne. Ces tâches sont alors estampillées comme retardataires. Mais cette technique marche mal. » Pourquoi ? « Parce que, par définition, certaines tâches prennent plus de temps que d'autres. Résultat : vous avez de fausses détections. Au début, ce n'était pas trop gênant car Hadoop et Map Reduce servaient pour des données par lots qui s'exécutent plutôt sur une longue période. Parfois des milliers de secondes pour une tâche et des jours entiers pour un traitement. Mais avec les flux de données, on bascule dans une autre échelle de temps : millisecondes, voire microsecondes. Le problème hérité de Hadoop est amplifié par le fait qu'il s'agit maintenant de faire tourner des applications critiques sensibles au facteur temps. En étudiant les méthodes de détection actuelles, nous avons découvert qu'elles ne sont pas très bonnes. »

Ce constat a amené à l'introduction d'un ensemble de métriques qui vont aider les chercheurs à caractériser les retardataires et à construire de nouveaux mécanismes de détection. Ces métriques sont : la précision, le rappel, la latence de détection, le temps avant l'exécution des retardataires non détectés et les faux positifs. « La première concerne donc la précision : combien de tâches classées comme en retard le sont vraiment ? Vous voulez un taux de 100%. La seconde porte sur les rappels : combien de retardataires n'ont pas été détectés ? En utilisant ces nouvelles métriques, nous avons introduit un nouveau mécanisme de détection. Il améliore la précision, mais nous sommes passés à côté de beaucoup de retardataires. Nous continuons à travailler sur ce sujet. »

Par la même occasion, il est apparu que « quand Hadoop trouve des retardataires, il attend que de la ressource redevienne disponible pour lancer l'exécution d'une copie. Il ne cherche pas à effectuer la meilleure allocation pour cette tâche pourtant si critique. Il arrive donc que la copie soit exécutée sur un serveur lent, générant ainsi peut-être même un autre retardataire. »

Relancer les tâches en échec

Avec la nouvelle méthode, « au lieu d'attendre, une fois que nous avons détecté le retardataire et vérifié que c'en était bien un, nous cherchons de la ressource sur laquelle nous pourrions exécuter la tâche tout de suite et plus rapidement. Nous posons deux questions pour l'ordonnancement : où et quand exécuter cette tâche spéculative ? » Pour l'instant, cette recherche porte sur Hadoop , mais avec l'intention d'aller ensuite sur Spark . « Dans Spark, il y a beaucoup de facteurs influant sur le temps d'exécution. Travailler d'abord sur Hadoop nous a permis de mettre ces facteurs de côté pour nous concentrer sur le problème qui nous intéresse. Maintenant, nous allons pouvoir transposer les résultats vers les applications traitant des flux de données. »

Le troisième et dernier sujet concerne aussi les échecs. « Avec des flux de données, il faut très vite repérer et réparer les tâches en échec. On a quelques microsecondes. Dans Spark, ils réutilisent le système de recalcul hérité de Hadoop. Mais cela prend encore du temps. Dans Flink, ils utilisent des points de contrôle synchrones. Ce qui rajoute de la gestion car il faut arrêter l'exécution de l'application en cours en attendant la mise en cohérence des snapshots distribués. Nous essayons donc quelque chose qui serait hybride. Quelque chose avec de la réexécution asynchrone et des points de contrôle synchrones en fonction des besoins de l'application. Ce serait une solution adaptative complètement automatisée qui choisirait la meilleure technique pour gérer les échecs en fonction des caractéristiques de l'application et de la configuration du système. »

Débuté en 2017, le projet KerStream rencontre un certain succès. « De plus en plus de gens y collaborent, y compris en Chine, à Singapour et aux Etats-Unis. Récemment, Inria et le Lawrence Berkeley National Laboratory ont aussi créé une équipe commune pour travailler, entre autres, dans ce domaine. » Les méthodes développées étant génériques, elles pourraient s'appliquer aux différents intergiciels pour flux de données déjà existants.