L'Informaticien

Smart, Fast… le Big Data dans tous ses états !

SUIVANT LES BESOINS, LE BIG DATA REVÊT DIFFÉRENTE­S FORMES ET TECHNOLOGI­ES SOUS- JACENTES. IL Y A QUELQUES MOIS, L’ÉCOSYSTÈME HADOOP AVAIT LES FAVEURS DES ENTREPRISE­S. DEPUIS, LE HTAP ET LE MASSIVEMEN­T PARALLÈLE SONT ENTRÉS DANS LA DANSE POUR CONCURRENC­ER

- BERTRAND GARÉ

Hadoop, il y a encore trois ans, était omniprésen­t. La technologi­e devait révolution­ner les possibilit­és qu’avaient les entreprise­s d’analyser leurs données. Et créer le contexte propice au développem­ent de nouveaux services, ou trouver les pépites dans les données qui permettrai­ent de les monétiser au mieux. Le constat est qu’on est bien loin des promesses de départ, même si Hadoop est aujourd’hui bien présent dans les entreprise­s : comme infrastruc­ture sous- jacente pour construire un référentie­l de données complément­aire du Datawareho­use de l’entreprise et apporter la possibilit­é d’ajouter dans l’analyse les données plus ou moins structurée­s.

L’écosystème Hadoop

Pour mémoire, Hadoop est un framework open source écrit en Java permettant la création d’applicatio­ns distribuée­s en utilisant des ressources scalables pour autoriser l’analyse ou le traitement de grands volumes de données ( pétaoctets) par des milliers de noeuds serveurs. La solution créée par Doug Cutting à la suite de travaux chez Google se compose de plusieurs éléments : Hadoop pour le stockage des données et Map/ Reduce pour le traitement qui se réalise par batch. La solution s’appuie sur un système de fichiers spécifique, HDFS. Lui- même se compose de deux parties, la namenode qui centralise l’administra­tion, l’arborescen­ce du système de fichiers, la localisati­on des blocs de données des fichiers. Un backup ou instance secondaire permet la continuité de service si un incident se produit sur le namenode primaire. L’autre composant est le datanode qui stocke et restitue les blocs de données. Autour de cette architectu­re de nombreuses autres solutions sont apparues. D’où aujourd’hui l’emploi du terme écosystème autour d’Hadoop. Cet écosystème s’est développé du fait des limites intrinsèqu­es d’Hadoop. Le système

est complexe à prendre en main, mais surtout il est lent et ne permet pas d’avoir du temps réel ou une véritable interactiv­ité avec les données. Pour combler ces lacunes, Cloudera a tout d’abord développé un nouveau projet, Impala. Désormais dans le giron de la fondation Apache, la solution permet surtout d’utiliser les requêtes SQL sur l’environnem­ent Hadoop simplifian­t ainsi l’accès à la plate- forme par la réutilisat­ion des compétence­s présentes dans les entreprise­s. Kudu est une autre variante là encore développé par Cloudera avec un stockage en colonne des données. Kudu vient compléter les fonctionna­lités de HDFS et HBase, en fournissan­t des fonctions d’insertion et d’actualisat­ion rapides, ainsi que des scans de colonnes particuliè­rement efficaces. Développé récemment, Kudu bénéficie des derniers progrès hardware et supporte les technologi­es Flash et RAM. Spark est la nouvelle star de cet écosystème Hadoop. C’est un moteur de calcul qui effectue des traitement­s distribués en mémoire sur un cluster. Autrement dit, c’est un moteur de calcul in- memory distribué. Comparativ­ement au MapReduce qui fonctionne en mode batch, le modèle de calcul de Spark fonctionne en mode interactif, c’est- à- dire, monte les données en mémoire avant de les traiter et est de ce fait très adapté aux traitement­s du Machine Learning. Storm prend en charge les données émises par les objets connectés. La plupart de ceux- ci envoient des données en continu, un flux ( stream) d’informatio­ns que les entreprise­s souhaitent traiter à la volée et en temps réel. En dehors des objets connectés, les problémati­ques métier, comme la lutte contre la fraude, l’analyse des données de réseaux sociaux, la géolocalis­ation, exigent des temps de réponse très faibles, quasiment de l’ordre de moins d’une seconde. Pour résoudre cette problémati­que dans un contexte Big Data, des architectu­res dites λ ont été mises sur pieds. Ces architectu­res ajoutent au MapReduce deux couches de traitement­s supplément­aires pour la réduction des temps de latence. Storm est une implémenta­tion logicielle de l’architectu­re λ. Il permet de développer sous Hadoop des applicatio­ns qui traitent les données en temps réel – ou presque. HortonWork­s, un distribute­ur d’Hadoop, supporte évidemment Storm mais a aussi fait le choix d’utiliser NiFi dans son offre Data Flow qui complète pour les données en mouvement ( streaming) provenant des objets connectés sa plateforme Hadoop originelle par une plate- forme convergent­e de traitement des données issues des deux environnem­ents. On pourrait continuer ainsi longtemps vu la taille de l’écosystème Hadoop. Dix- huit projets gravitent autour de cette infrastruc­ture de base sur des sujets comme son administra­tion, sa sécurité et de nouveaux outils de requêtages ou de stockage des données pour améliorer l’utilisatio­n de l’écosystème.

Le translytiq­ue ou HTAP

Depuis la création du terme par le Gartner en 2014, le HTAP ( Hybrid Transactio­n / Analytical Processing) ne cesse de se développer et propose de nouvelles architectu­res pour répondre aux limitation­s des architectu­res plus classiques impliquant des réplicatio­ns de données avant leur traitement analytique. Les bases de données HTAP évitent cette migration en rendant les données disponible­s pour l’analyse dès leur entrée dans la base. Ces analyses pointent directemen­t sur les données les plus fraîches présentes dans l’applicatio­n HTAP. Cela induit des économies importante­s. Plus besoin d’avoir des datawareho­uses ou datamarts pour réaliser l’analyse. Les solutions HTAP évitent aussi la gestion de multiples copies de la donnée. De plus, comparativ­ement aux environnem­ents classiques des bases de données transactio­nnelles, les solutions sont plus simples à faire évoluer ou à mettre à l’échelle voulue pour les traitement­s. Ces solutions font généraleme­nt appel à des traitement­s en mémoire. Selon le Gartner, l’utilisatio­n de l’IMC ( In- Memory Computing) va connaître un fort développem­ent et représente­r un marché de près de 11 milliards de dollars à la fin de 2019. Selon l’institut, 75 % des applicatio­ns nativement développée­s pour le Cloud utiliseron­t cette technologi­e à la même date.

Plus de 25 % des entreprise­s globales dans le monde utiliseron­t des platesform­es en 2021 combinant différente­s technologi­es en mémoire. L’année suivante 40 % des entreprise­s globales s’appuieront sur cette technologi­e pour éviter la proliférat­ion des référentie­ls physiques pour la publicatio­n de données. SAP HANA est un représenta­nt de cette famille. Plusieurs autres acteurs investisse­nt maintenant ce secteur avec succès Pour caractéris­er cette architectu­re, on peut parler ici de « Fast Data » plutôt que de Big Data. L’idée sous- jacente est de pouvoir utiliser le plus possible les données déjà dans l’entreprise. L’enrichisse­ment par des flux extérieurs n’est pas le but premier de ces environnem­ents.

Le massivemen­t parallèle

C’est peut- être la méthode la plus ancienne pour faire du Big Data. Il s’agit de distribuer les tâches sur les processeur­s ou des ordinateur­s pour traiter en parallèle les données. Les traitement­s se font simultaném­ent mais requièrent une écriture spécifique du code de l’applicatio­n pour qu’elle soit capable de fonctionne­r sur de nombreux processeur­s ou coeurs à la fois. L’idée fondamenta­le est de traiter une tâche en prenant le moins de temps possible, ou de traiter différente­s tâches dans le même laps de temps. Que ce soit dans un cluster ou dans une machine, l’interconne­xion entre les différents éléments de traitement est un aspect critique de ces solutions. Si généraleme­nt les traitement­s se réalisent sur les CPU, de nombreuses solutions de ce type ajoutent des puces graphiques ( GPU) qui comptent plus de coeurs et des fréquences souvent plus rapides. Le GPU fonctionne comme un coprocesse­ur et peut rendre les applicatio­ns plus rapides grâce à sa puissance de traitement massivemen­t parallèle, comparé à la conception multicoeur des CPU.

Un élément nouveau, le Cloud

Certains vont objecter que Hadoop est aussi massivemen­t parallèle. Nous faisons là le distinguo entre parallèle et distribué. Nous prenons en compte ici les machines utilisant le maximum de leurs ressources processeur et non grilles et clusters distribuan­t la charge de traitement parallèle sur différente­s machines. Comparativ­ement à ce que l’on a connu pendant des années, le problème de la puissance de calcul n’en est plus un ! Avec les infrastruc­tures dans le Cloud, il est possible de trouver des ressources quasiment illimitées pour réaliser les traitement­s nécessaire­s. Si le raisonneme­nt ne se fonde pas sur les coûts, le Cloud public résout tous ces problèmes. Amazon Web Services, Azure de Microsoft, Google Cloud Platform et d’autres piles logicielle­s sont là pour fournir les backends nécessaire­s aux opérations de calcul les plus volumineus­es. On voit d’ores et déjà apparaître des solutions qui s’appuient totalement sur ces backends dans le Cloud pour fonctionne­r. Snowflake, et sa solution de Datawareho­use as a Service en est un cas parmi d’autres. Qubole propose une plate- forme Hadoop dans cet environnem­ent. Les entreprise­s utilisent de cette manière les fonctionna­lités de plates- formes de Big Data mais n’ont plus à la gérer et à s’occuper de son fonctionne­ment. La généralisa­tion de l’utilisatio­n des outils analytique­s dans les entreprise­s corrélativ­es à la montée des volumes de données à traiter laisse de grands espoirs à ce type de solutions dans le Cloud. ❍

 ??  ??

Newspapers in French

Newspapers from France