Par Bertrand Ounanian, Senior Sales Engineer SEUR de Vast Data
L’analyse de données et les systèmes de stockage ont beaucoup évolué au cours de ces dix dernières années. La côte de popularité des frameworks Big Data tels que Hadoop s’est accélérée au début des années 2010. Ils sont devenus populaires alors que les volumes de données étaient en pleine croissance. Les utilisateurs se sont d’abord concentrés sur les traitements batch mais cette approche était consommatrice de temps, se comptant en heures ou en jours. Aujourd’hui la situation a changé. Les charges de travail sont devenues plus exigeantes en termes d’agilité et de performance. Les systèmes précédents n’ont pas été conçus pour supporter l’augmentation exponentielle du nombre de jobs et les plateformes actuelles ne peuvent plus se contenter de gérer des traitements batch. Elles doivent aussi prendre en charge les requêtes ad hoc/interactives et les traitements temps réel.
L’héritage d’Hadoop
Au fil du temps, le framework Big Data Hadoop s’est essouflé, mais les concepts sous-jacents qu’il a introduits (avec MapReduce comme principe de traitement, le rapprochement de la donnée au plus proche des CPUs, l’utilisation de matériel banalisé pour bâtir des clusters d’analyse de données semi-structurées), sont devenus le cœur des systèmes modernes d’analyse de données. Hadoop a aussi donné naissance à un riche écosystème de projets, comme Hive, Kafka ou encore Impala. Pour l’histoire, Hadoop a été développé chez Yahoo au début des années 2000. L’idée initiale est venue de deux articles de Google (“The Google File System” et “MapReduce : Simplified Data Processing on Large Clusters”), et a permis à Yahoo d’augmenter la puissance de traitement tout en utilisant du matériel banalisé à faible coût.
Hadoop promettait de perturber le marché du data warehouse et de l’analyse qui avait longtemps été un bastion pour des entreprises telles que Oracle, Teradata et IBM. Alors que l’utilisation de MapReduce a lentement décru, Hadoop Distributed File System (HDFS) reste prépondérant en tant que système de fichiers supportant les applications Big Data comme Spark et Kafka. Lorsque Hadoop Distributed File System a vu le jour, les disques étaient plus rapides que les adaptateurs réseau. Il a donc été créé sous la forme d’un cluster de serveurs embarquant des disques internes, permettant de rapprocher la donnée du compute. À l’époque, les disques SSD étaient coûteux et leur capacité était limitée. On utilisait des disques mécaniques et la plupart des réseaux étaient encore très largement basés sur du Gigabit ethernet . La seule façon d’éviter les goulots d’étranglement du réseau était de maintenir un couplage fort entre le stockage et le calcul.
À mesure que les systèmes de Big Data évoluaient vers des solutions en temps réel telles que Spark et Kafka, le stockage se devait de devenir plus rapide et prendre en charge les techniques d’analyse des données. Il devait également évoluer vers des centaines ou milliers de nœuds, offrant une capacité beaucoup plus importante.
L’évolution du traitement des données volumineuses
Le cœur de la plupart des traitements Big Data modernes réside dans un modèle d’architecture appelé Lambda. Ce type de traitement adresse des événements qui arrivent à grande échelle. En général, ces données proviennent de sources telles que des fichiers de logs ou des capteurs IoT, puis sont transmises à une plateforme de streaming comme Kafka. Kafka est une plateforme open source de streaming d’événements distribuée qui peut traiter ces données à la volée.
On peut considérer une plateforme de streaming comme une requête unique qui s’exécute sur toutes les valeurs qui transitent. Cette requête agit comme une action conditionnelle – par exemple, si vous traitez des données de capteurs, vous pourriez vouloir capturer ces valeurs afin de pouvoir prendre des actions. Cela pourrait prendre la forme de l’exécution d’une fonction dans le cas d’un système IT, ou d’un opérateur examinant physiquement un dispositif. Le reste des valeurs sera poussé dans un stockage “froid”, permettant une analyse à plus grande échelle avec l’historique des valeurs (tendances, apprentissage automatique, etc..). Cette couche froide est généralement un data warehouse, ou une combinaison de HDFS et de Spark.
L’une des difficultés rencontrées par Hadoop dans une infrastructure physique avec stockage local est que pour ajouter de la capacité de stockage, il fallait également ajouter de la capacité de calcul (toujours en raison du couplage étroit entre CPU + capacité dans les architectures de type “shared nothing”), ce qui était coûteux en termes de coûts d’acquisition et de gestion.
De ce fait, les défis posés par Hadoop ont donné lieu à deux conséquences majeures. Premièrement, les entreprises se sont tournées vers le stockage objet pour rendre le stockage Big Data plus abordable. L’API S3, l’interface d’object storage la plus répandue, est devenue une norme industrielle, permettant aux entreprises de stocker, d’extraire, de lister, de supprimer et de déplacer des données dans presque tous les stockages objets. Enfin, plus récemment, l’autre percée technologique est apparue sous la forme de l’architecture DASE (disaggregated shared everything), qui permet de faire évoluer le stockage clusterisé indépendamment des CPU afin de mieux répondre aux besoins des applications en termes de capacité et de performance.
L’essor du Datalake
Le concept de datalake dans lequel les données en attente d’analyse sont stockées dans leur format natif a contribué à l’essor du stockage moderne. La partie la plus difficile de tout système de business intelligence ou d’analyse de données est de faire passer les données de leur format brut à un format dans lequel elles peuvent être facilement interrogées. Traditionnellement un ETL (Extract, Transform, Load) était utilisé pour cela. Hadoop a permis de remplacer cette approche par le fait de transformer la donnée au moment de la requête. (Extract, Load, Transform). Cela permet à différentes applications d’utiliser la même donnée brute.
Les solutions conçues pour fonctionner avec des datalakes sont rapides, flexibles et prennent en charge une grande variété de langages. Le meilleur exemple est probablement Spark, qui peut agir comme un datawarehouse distribué, avec des coûts beaucoup plus faibles. Cependant, au-delà des frameworks d’analyse de données, le stockage sous-jacent a connu des changements substantiels qui permettent l’évolutivité, la vitesse et la capacité nécessaires pour l’analyse de données.
Lors de sa création, Hadoop était conçu pour fonctionner avec des disques durs mécaniques très denses et bon marché. Cependant le stockage Flash a évolué, devenant moins coûteux, plus dense et plus rapide grâce à des protocoles tels que NVMe (Non-Volatile Memory express), qui offre des niveaux de latence extrêmement bas, et des disques SSD très denses. Cette vitesse, associée à la réduction des coûts des SSD, représente le stockage full-flash évolutif et abordable pour prendre en charge les datalakes.
En clair, le stockage a beaucoup évolué au fil des ans. Il est devenu plus rapide et a une capacité bien meilleure évolutivité. Le prochain grand défi est de savoir comment stocker, protéger, gérer et extraire des informations pertinentes des données résidant dans ce stockage. Pour cela, une architecture DASE (disaggregated shared everything) permet aux entreprises de bénéficier de performances de stockage temps réel, en se basant sur des protocoles standards comme S3, pour tous les contextes d’analyse des données, du datawarehouse et des requêtes ad hoc aux travaux plus complexes de data science.
