(1 votes, moyenne: 4,00 sur 5)
Loading...Dans n’importe quel article ou blog post, il n’est généralement pas rare d’avoir au moins une allusion à Hadoop. Dans le monde du Big Data, Hadoop a été la référence surtout avec l’arrivée de Hadoop 2.0 en 2013 qui a rendu l’environnement plus facile et plus stable. En revanche, malgré l’inclusion d’Impala qui permet d’interroger les informations stockées en temps réel, Hadoop reste malgré tout un système basé sur le traitement par lots (batch processing).
Le traitement des big data est connu pour ses trois caractéristiques principales, les 3VS à savoir, Volume, Vitesse et Variété. Beaucoup de data scientist et ingénieurs Big Data s’entendent sur le fait qu’Hadoop traite les données suffisament rapidement pour répondre aux critères de vitesse. En fait, comme j’ai un background de calcul en temps réel et précision des largeurs de données (fixed point, floatting point), cet argument me fait penser aux ingénieurs et aux informaticiens des années 90 qui se demandaient : « Pourquoi avez-vous besoin de 64 bits alors que 32 bits fonctionnent parfaitement bien ? » Et je me demande « Pourquoi avez-vous besoin de Spark alors qu’Hadoop fonctionne très bien ? ».
Hadoop où la volonté d’aller plus loin
Cette volonté de traiter les big data plus rapidement, en particulier plus rapidement qu’avec Hadoop, a laissé la porte ouverte à une myriade de solutions propriétaires et open source. Cela a également conduit la Fondation Apache – « The grey beards » à sponsoriser Hadoop et d’autres plateformes pour accélérer le passage de certains projets d’un statut d’incubateur à des projets de haut niveau. Avec ce coup d’accélérateur, ces projets sont aujourd’hui adoptés dans l’industrie. Parmi ces projets, il convient de citer Apache Spark, une solution découverte par « lightning-fast cluster computing » pour le traitement des big data.
Pour ceux d’entre vous qui utilisent Hadoop 2.0, je vous invite à réflechir aux questions suivantes :
- Comment exécuter des programmes 100 fois plus rapidement qu’avec Hadoop MapReduce en mémoire ou 10 fois plus rapidement sur le disque?
- Comment écrire des applications très rapidement en Java, Python ou Scala, de manière à pouvoir construire des applications parallèles qui tirent parti de votre environnement distribué ?
- Comment combiner du SQL, des analyses en streaming et des analyses complexes dans la même application ?
- Et enfin, comment accéder à toutes vos données et les traiter à partir de votre environnement actuel Hadoop ?
Si vous n’avez pas trouvé la réponse, je vais vous la donner : Spark !
Qu’est ce que Apache Spark ?
Développé en Scala, Spark est un framework open source de calcul distribué pour des analyses avancées qui peuvent tirer parti de l’environnement de stockage Hadoop (comme HDFS). Il a été initialement développé comme un projet de recherche à UC Berkeley’s AMPLab. En Juin 2013, Spark a obtenu le statut de projet d’incubateur à la Fondation Apache. En Février 2014, il a même été requalifié en projet de haut niveau. Spark 1.5.1 est disponible en open source.
Pourquoi Spark à la place d’Hadoop ?
Dès le début, Spark a été conçu pour soutenir le traitement en mémoire. Ansi, les programmes algorithmiques itératifs peuvent être développés sans avoir besoin d’écrire un jeu de résultats après chaque passage au sein des données. Le résultat du traitement n’est pas écrit sur le disque mais gardé en mémoire. Cette capacité à tout garder en mémoire est une technique de calcul de haute performance destinée aux analyses avancées. Ceci permet à Spark d’être ultra-rapide avec des vitesses de traitement qui sont 100 fois supérieures par rapport aux algorithmes comparables utilisant MapReduce.
Spark dispose d’un cadre intégré pour effectuer des analyses avancées comme la bibliothèque du machine learning MLlib, le moteur graphique GraphX, le moteur d’analyse en streaming Spark Streaming ou l’outil interactif de requêtes en temps réel Shark. Cette plate-forme unique assure aux utilisateurs une cohérence dans les résultats produits à travers différents types d’analyse.
Spark possède également une couche d’abstraction appelée jeux de données élastiques répartis ou RDD (Resilient Distributed datasets) qui sont des collections partitionnées en lecture seule de documents (dossiers) créés à travers « des opérations déterministes sur des données stables. » Les RDDs comprennent « des informations sur la traçabilité des données avec des instructions pour la transformation des données et pour leur persistance. » Ils constituent une collection d’objets distribués qui peuvent être mis en mémoire cache sur plusieurs nœuds de cluster. Les RDDs sont conçus l’ambition de prévenir la détérioration des opérations : si une opération échoue, elle est automatiquement reconstruite. Sur ce sujet, je vous invite à lire mon prochain livre blanc publié prochainement. Pour plus d’informations sur les RDDs vous pouvez consultez le papier publié par UC Berkeley’s AMPLab.
Spark fonctionne avec n’importe quel fichier stocké dans HDFS ou n’importe quel autre système de stockage supporté par Hadoop. Il supporte les fichiers textes, SequenceFiles et tout autre fichier Hadoop inputFormat.
Spark streaming fournit une abstraction appelée «discretized streams » ou DStreams. Les DStreams sont une séquence continue de RDDS représentant un flux de données qui est créé à partir de données en direct ingérées ou générées en transformant d’autres DStreams. Spark reçoit ces données, les divise en lots (batches) puis réplique les lots pour la tolérance aux pannes et les garde en mémoire pendant une période de temps, où ils sont disponibles pour des opérations mathématiques. Ils sont ensuite traités à intervalles de courte durée. Les données recueillies deviennent leur propre RDD qui est ensuite traité en utilisant le jeu habituel des applications Spark.
Retour d’expérience
Spark supporte les interfaces de programmation Scala, Java, Python et maintenant R. J’ai eu l’occasion d’utiliser Spark lors de ma formation pour des applications réelles (analyse de sentiments, etc.) depuis Mai 2014. Je trouve qu’il faudrait améliorer d’avantage GraphX pour réduire les bugs. J’ai également utilisé Python et R pour développer des applications sur Spark et j’ai pu constater qu’il est incroyablement rapide. Il était sur un cluster de calcul haute performance de six nœuds avec beaucoup, beaucoup de mémoire et une infrastructure existante Hadoop, tout ceci dans le cloud (Microsoft Azure).
Est-ce que je recommanderais Spark ?
Oui, Spark corrige de nombreux « oversignts » que je vois dans Hadoop. De plus, il travaille rapidement.
Devrais-je me débarrasser des environnements Hadoop et/ou Storm ?
Non pas encore. Spark est très nouveau et ce n’est que récemment que des entreprises ont commencé à l’adopter et le soutenir. Si cette tendance continue, Spark pourrait être le prochain changement évolutif dans les environnements de traitement Big Data.
