L'évolution du pipeline de données

Version imprimable, PDF et e-mail

Le pipeline de données est le pilier central des applications consommant un volume élevé de données. Dans le premier article de cette série, nous nous pencherons sur l'histoire de ce pipeline de données ainsi que l'évolution de ces technologies à travers le temps. Nous examinerons ensuite la manière dont Barracuda exploite certains de ces systèmes, les éléments à prendre en compte lors de l'évaluation des composants du pipeline de données ainsi que des exemples d'applications pour vous aider à développer et déployer ces technologies.

 

MapReduce

En 2004, Jeff Dean et Sanjay Ghemawat de Google publient MapReduce: Simplified Data Processing on Large Clusters. Dans cette étude, ils donnent la définition suivante de MapReduce :

« […] un modèle de programmation et une implémentation associée permettant de traiter et générer des ensembles volumineux de données. Les utilisateurs définissent une fonction Map, qui traite une paire clé/valeur afin de générer un ensemble de paires clé/valeur intermédiaires, ainsi qu'une fonction Reduce qui se charge de fusionner toutes les valeurs intermédiaires associées à une même clé intermédiaire. »

En s'appuyant sur le modèle MapReduce, les deux informaticiens parviennent à simplifier la charge de travail parallèle sur laquelle reposaient les index Web de Google. Cette charge de travail est programmée sur un cluster de nœuds et capable d'évoluer au rythme du Web.

Lorsque l'on s'intéresse au modèle MapReduce, il est notamment important d'examiner où et comment sont stockées les données dans le cluster, un système auquel Google a donné le nom de Google File System (GFS). Le projet Apache Nutch permettra de donner vie à une alternative open source de MapReduce appelée Hadoop et développée à partir d'une implémentation open source de GFS. Hadoop est pour la première fois proposé par Yahoo! en 2006. (Hadoop est ainsi nommé en hommage au doudou du fils de Doug Cutting, un éléphant en peluche.)

Apache Hadoop : une implémentation open-source de MapReduce

Hadoop remporte un franc succès et les développeurs introduisent bientôt des abstractions permettant de définir des tâches à un plus haut niveau. Là où, par le passé, les fonctions Input, Map, Combine et Reduce étaient définies de manière très conventionnée (généralement en langage Java simple), les utilisateurs ont désormais la possibilité de concevoir des pipelines de données à partir de sources, récepteurs et opérateurs communs avec Cascading. À l'aide de la plateforme Pig, les développeurs peuvent également définir des tâches à un niveau encore plus élevé en utilisant un tout nouveau langage appelé le Pig Latin. Calculez et comparez ainsi le nombre de mots dans Hadoop, Cascading (2007) et Pig (2008).

Apache Spark : un moteur d'analyse unifié pour un traitement des données à grande échelle

C'est en 2009 que Matei Zaharia, alors étudiant à l'université de Berkeley, commence à développer Spark. En 2010, son équipe publie Spark: Cluster Computing with Working Sets, où elle détaille une méthode permettant de réutiliser un ensemble de données pour différentes opérations parallèles, et dévoile la première version publique de Spark en mars cette même année. En 2012, l'article Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing fait suite à cette première publication et remporte le prix de la meilleure publication lors du sommet USENIX Symposium on Networked Systems Design and Implementation. Dans cette publication, on découvre une nouvelle approche, nommée « Resilient Distributed Datasets » (RDD). Celle-ci permet aux programmeurs d'effectuer des calculs en mémoire pour appliquer des ordres de grandeur à des algorithmes itératifs comme PageRank afin d'accroître leurs performances ou d'exploiter le machine learning pour le même type de tâches conçues sur Hadoop.

Outre les gains de performance pour les algorithmes itératifs, Spark permet également pour la première fois d'exécuter des requêtes interactives, une innovation majeure. Spark exploite ainsi un interpréteur Scala interactif pour permettre aux data scientists d'interagir avec le cluster et d'exploiter de grands ensembles de données bien plus rapidement qu'en utilisant l'approche traditionnelle consistant à compiler et soumettre une tâche Hadoop, puis à attendre les résultats.

Un problème demeure toutefois : seules les données d'une source liée sont prises en compte dans le cadre des tâches Hadoop ou Spark (et non les nouvelles données entrantes au moment de l'exécution). La tâche est associée à une source d'entrée, qui détermine la façon dont celle-ci sera décomposée en segments ou tâches parallèles, exécute simultanément les tâches sur le cluster, puis combine les résultats et les enregistre quelque part. Cette approche fonctionne à merveille pour des tâches telles que la création d'index PageRank ou la régression logistique, mais s'avère inadaptée pour de nombreuses autres tâches s'exécutant sur une source non liée ou en continu, comme l'analyse du flux de clics (ou « click-stream ») et la prévention des fraudes.

Apache Kafka : une plateforme de streaming distribuée

En 2010, l'équipe d'ingénieurs de LinkedIn entreprend de réorganiser la technologie sous-jacente du réseau social professionnel [A Brief History of Kafka, LinkedIn’s Messaging Platform]. Comme bon nombre de sites Web, LinkedIn est passé d'une architecture monolithique à une architecture microservices interconnectée, mais c'est l'adoption d'une nouvelle architecture basée sur un pipeline universel lui-même conçu sur un journal de validation distribué appelé Kafka qui permet à LinkedIn de traiter ses flux d'événements en temps quasi réel et à une échelle considérable. Kafka est ainsi nommé par Jay Kreps, ingénieur principal de LinkedIn, car il s'agit d'un « système optimisé pour l'écriture » et Jay apprécie tout particulièrement les œuvres de Franz Kafka.

LinkedIn crée, en premier lieu, Kafka avec l'objectif de découpler ses microservices existants et ainsi leur permettre d'évoluer plus librement et indépendamment. Avant l'arrivée de sa plateforme de streaming distribuée, le schéma ou protocole utilisé pour permettre aux services de communiquer entre eux avait en effet condamné ces services à une évolution parallèle. L'équipe en charge de l'infrastructure de LinkedIn avait donc compris qu'il leur fallait disposer d'une grande flexibilité pour faire évoluer ses services de manière indépendante. Ils conçoivent ainsi Kafka afin de permettre à leurs services de communiquer de manière asynchrone et basée sur les messages. Cette plateforme doit être à la fois durable (persistance des messages sur disque) et tolérante aux défaillances de nœuds et réseau tout en offrant des caractéristiques en temps quasi réel et une évolutivité horizontale pour s'adapter à la croissance. Kafka répond à ces besoins en fournissant un journal distribué (voir The Log: What every software engineer should know about real-time data's unifying abstraction).

En 2011, Kafka est proposé en open source et adopté par de très nombreuses entreprises. Kafka offre plusieurs innovations par rapport aux précédentes abstractions de file d'attente de messages ou pub-sub :

  • Les topics (files d'attente) Kafka sont partitionnés et répliqués sur un cluster de nœuds Kafka (appelés brokers).
  • Kafka utilise ZooKeeper pour garantir la coordination, la haute disponibilité et le failover des clusters.
  • Les messages persistent sur disque pendant de très longues périodes.
  • Les messages sont consommés dans l'ordre.
  • Les consommateurs sont chargés du maintien de leur état de consommation (offset du dernier message consommé).

Les systèmes producteurs n'ont ainsi pas à maintenir l'état de consommation de chaque message et peuvent désormais être transmis au système de fichiers à un rythme élevé. Les consommateurs étant chargés du maintien de leur propre offset au sein du topic, ils peuvent ainsi prendre en charge les mises à jour et défaillances de manière optimale.

Apache Storm : système de calcul en temps réel distribué

Parallèlement, en mai 2011, Nathan Marz finalise l'acquisition de sa société BackType par Twitter. BackType « concevait des produits d'analyse pensés pour aider les entreprises à comprendre leur impact historique et en temps réel sur les médias sociaux » [History of Apache Storm and Lessons Learned]. L'un des joyaux de BackType était un système de traitement en temps réel nommé « Storm ». Storm fournit une abstraction, appelée « topologie », qui simplifie les opérations sur les flux de la même façon que MapReduce facilite le traitement par lot. Storm est ainsi présenté comme un « Hadoop en temps réel » et se retrouve rapidement au cœur de toutes les conversations sur GitHub et Hacker News.

Apache Flink : calculs avec état sur les flux de données

Flink est également dévoilé au public en mai 2011. Ce framework est issu du projet de recherche académique « Stratosphere » [http://stratosphere.eu/], collaboration entre une poignée d'universités allemandes. Stratosphere doit permettre « d'optimiser le traitement parallèle de volumes de données élevés sur des plateformes IaaS (Infrastructure as a Service) » [http://www.hpcc.unical.it/hpc2012/pdfs/kao.pdf].

À l'instar de Storm, Flink offre un modèle de programmation permettant de traiter des « jobs » (flux de données) incluant un ensemble de flux et de transformations. Flink fournit également un moteur d'exécution capable de traiter efficacement le job de manière parallèle et de le programmer sur un cluster géré. Le modèle de programmation de Flink présente la spécificité d'admettre à la fois les sources de données liées et non liées. La syntaxe d'un job à exécuter une fois traitant des données depuis une base SQL (traditionnellement associé à un traitement par lot) et celle d'un job à exécuter en continu sur des données en flux issues d'un topic Kafka sont donc proches. Flink intègre le projet d'incubation Apache en mars 2014 et est accepté en tant que Top-Level Project (projet de premier plan) Apache en décembre 2014.

En février 2013, la version alpha de Spark Streaming est introduite avec Spark 0.7.0. En septembre 2013, LinkedIn rend disponible en open source son framework de traitement de flux, nommé Samza, avec cette publication.

En mai 2014, Spark 1.0.0 est publié et introduit Spark SQL. Si cette version offre des capacités de diffusion limitée (la source de données doit être divisée en « micro-lots »), les bases d'une exécution en flux des requêtes SQL sont bien présentes.

Apache Beam : un modèle de programmation unifié pour le traitement par flux ou par lots

En 2015, un collectif d'ingénieurs Google publie un article intitulé The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing. Un an plus tôt, en 2014, une implémentation du modèle Dataflow était dévoilée sur Google Cloud Platform. En 2016, Google fait don à Apache du SDK de base de ce projet ainsi que de plusieurs connecteurs E/S et d'un exécuteur local. La première version d'Apache Beam est publiée en juin, la même année.

L'un des principaux avantages du modèle Dataflow (et Apache Beam) est qu'il permet de créer des pipelines sans se soucier du moteur d'exécution. Lors de l'écriture, Beam peut ainsi compiler le même code, qu'il cible Flink, Spark, Samza, GearPump, Google Cloud Dataflow ou Apex. Par conséquent, l'utilisateur est libre de changer de moteur d'exécution sans avoir à prévoir de ré-implémentation. Un moteur d'exécution « Direct Runner » est également disponible pour les tests et développements dans l'environnement local.

En 2016, l'équipe de développement de Flink présente Flink SQL. Kafka SQL est annoncé en août l'année suivante et, en mai 2019, un groupe d'ingénieurs Apache Beam, Apache Calcite et Apache Flink publie « One SQL to Rule Them All: An Efficient and Syntactically Idiomatic Approach to Management of Streams and Tables », un article en faveur d'un SQL unifié.

Où en sommes-nous aujourd'hui ?

Les outils mis à la disposition des architectes logiciel en charge du pipeline de données continuent d'évoluer à un rythme impressionnant. De nouveaux moteurs de flux de travail, tels qu'Airflow et Prefect, et systèmes d'intégration comme Dask permettent aujourd'hui aux utilisateurs de paralléliser et programmer de grands volumes de charges de travail de machine learning sur le cluster. De nouveaux concurrents comme Apache Pulsar et Pravega s'opposent à Kafka sur le terrain de l'abstraction du stockage du flux. Des projets comme Dagster, Kafka Connect et Siddhi intègrent des composants existants tout en proposant des approches inédites en matière de visualisation et conception du pipeline de données. Avec ces avancées rapides, la conception d'applications consommant des volumes considérables de données nous réserve encore bien des surprises.

Envie de travailler avec ce type de technologie ? Contactez-nous ! Nous avons de multiples postes d'ingénieurs à pourvoir dans plusieurs régions du monde.

Remonter en haut de page
Tweeter
Partager
Partager