Smart, Fast… le Big Data dans tous ses états !
SUIVANT LES BESOINS, LE BIG DATA REVÊT DIFFÉRENTES FORMES ET TECHNOLOGIES SOUS- JACENTES. IL Y A QUELQUES MOIS, L’ÉCOSYSTÈME HADOOP AVAIT LES FAVEURS DES ENTREPRISES. DEPUIS, LE HTAP ET LE MASSIVEMENT PARALLÈLE SONT ENTRÉS DANS LA DANSE POUR CONCURRENCER
Hadoop, il y a encore trois ans, était omniprésent. La technologie devait révolutionner les possibilités qu’avaient les entreprises d’analyser leurs données. Et créer le contexte propice au développement de nouveaux services, ou trouver les pépites dans les données qui permettraient 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 entreprises : comme infrastructure sous- jacente pour construire un référentiel de données complémentaire du Datawarehouse de l’entreprise et apporter la possibilité d’ajouter dans l’analyse les données plus ou moins structurées.
L’écosystème Hadoop
Pour mémoire, Hadoop est un framework open source écrit en Java permettant la création d’applications distribuées 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’administration, l’arborescence du système de fichiers, la localisation 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 architecture 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èques 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 interactivité 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’environnement Hadoop simplifiant ainsi l’accès à la plate- forme par la réutilisation des compétences présentes dans les entreprises. Kudu est une autre variante là encore développé par Cloudera avec un stockage en colonne des données. Kudu vient compléter les fonctionnalités de HDFS et HBase, en fournissant des fonctions d’insertion et d’actualisation 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 technologies Flash et RAM. Spark est la nouvelle star de cet écosystème Hadoop. C’est un moteur de calcul qui effectue des traitements distribués en mémoire sur un cluster. Autrement dit, c’est un moteur de calcul in- memory distribué. Comparativement 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 traitements 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’informations que les entreprises souhaitent traiter à la volée et en temps réel. En dehors des objets connectés, les problématiques métier, comme la lutte contre la fraude, l’analyse des données de réseaux sociaux, la géolocalisation, exigent des temps de réponse très faibles, quasiment de l’ordre de moins d’une seconde. Pour résoudre cette problématique dans un contexte Big Data, des architectures dites λ ont été mises sur pieds. Ces architectures ajoutent au MapReduce deux couches de traitements supplémentaires pour la réduction des temps de latence. Storm est une implémentation logicielle de l’architecture λ. Il permet de développer sous Hadoop des applications qui traitent les données en temps réel – ou presque. HortonWorks, un distributeur 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 convergente de traitement des données issues des deux environnements. On pourrait continuer ainsi longtemps vu la taille de l’écosystème Hadoop. Dix- huit projets gravitent autour de cette infrastructure de base sur des sujets comme son administration, sa sécurité et de nouveaux outils de requêtages ou de stockage des données pour améliorer l’utilisation de l’écosystème.
Le translytique ou HTAP
Depuis la création du terme par le Gartner en 2014, le HTAP ( Hybrid Transaction / Analytical Processing) ne cesse de se développer et propose de nouvelles architectures pour répondre aux limitations des architectures plus classiques impliquant des réplications de données avant leur traitement analytique. Les bases de données HTAP évitent cette migration en rendant les données disponibles pour l’analyse dès leur entrée dans la base. Ces analyses pointent directement sur les données les plus fraîches présentes dans l’application HTAP. Cela induit des économies importantes. Plus besoin d’avoir des datawarehouses ou datamarts pour réaliser l’analyse. Les solutions HTAP évitent aussi la gestion de multiples copies de la donnée. De plus, comparativement aux environnements classiques des bases de données transactionnelles, les solutions sont plus simples à faire évoluer ou à mettre à l’échelle voulue pour les traitements. Ces solutions font généralement appel à des traitements en mémoire. Selon le Gartner, l’utilisation de l’IMC ( In- Memory Computing) va connaître un fort développement et représenter un marché de près de 11 milliards de dollars à la fin de 2019. Selon l’institut, 75 % des applications nativement développées pour le Cloud utiliseront cette technologie à la même date.
Plus de 25 % des entreprises globales dans le monde utiliseront des platesformes en 2021 combinant différentes technologies en mémoire. L’année suivante 40 % des entreprises globales s’appuieront sur cette technologie pour éviter la prolifération des référentiels physiques pour la publication de données. SAP HANA est un représentant de cette famille. Plusieurs autres acteurs investissent maintenant ce secteur avec succès Pour caractériser cette architecture, 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’enrichissement par des flux extérieurs n’est pas le but premier de ces environnements.
Le massivement 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 processeurs ou des ordinateurs pour traiter en parallèle les données. Les traitements se font simultanément mais requièrent une écriture spécifique du code de l’application pour qu’elle soit capable de fonctionner sur de nombreux processeurs ou coeurs à la fois. L’idée fondamentale est de traiter une tâche en prenant le moins de temps possible, ou de traiter différentes tâches dans le même laps de temps. Que ce soit dans un cluster ou dans une machine, l’interconnexion entre les différents éléments de traitement est un aspect critique de ces solutions. Si généralement les traitements 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 coprocesseur et peut rendre les applications plus rapides grâce à sa puissance de traitement massivement parallèle, comparé à la conception multicoeur des CPU.
Un élément nouveau, le Cloud
Certains vont objecter que Hadoop est aussi massivement 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 distribuant la charge de traitement parallèle sur différentes machines. Comparativement à 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 infrastructures dans le Cloud, il est possible de trouver des ressources quasiment illimitées pour réaliser les traitements nécessaires. Si le raisonnement 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 logicielles sont là pour fournir les backends nécessaires aux opérations de calcul les plus volumineuses. On voit d’ores et déjà apparaître des solutions qui s’appuient totalement sur ces backends dans le Cloud pour fonctionner. Snowflake, et sa solution de Datawarehouse as a Service en est un cas parmi d’autres. Qubole propose une plate- forme Hadoop dans cet environnement. Les entreprises utilisent de cette manière les fonctionnalités de plates- formes de Big Data mais n’ont plus à la gérer et à s’occuper de son fonctionnement. La généralisation de l’utilisation des outils analytiques dans les entreprises corrélatives à la montée des volumes de données à traiter laisse de grands espoirs à ce type de solutions dans le Cloud. ❍