Qu'est-ce que Hadoop, et comment SQL s'intègre-t-il à cette solution ?

Hadoop est une structure open source, lancée au début des années 2000, pour le stockage et le traitement des données vraiment massives. La solution utilise un système de traitement parallèle avec du matériel basique pour distribuer des calculs sur de larges clusters de machines.

Les tâches Hadoop sont généralement codées en Java, mais comme ce processus peut être compliqué et que la plupart des analystes préfèrent SQL, plusieurs moteurs de calcul ont été développés afin de vous permettre d'utiliser SQL et d'exécuter dans un cluster Hadoop.

Le point fort de Hadoop ? Sa modularité. Les systèmes de gestion de base de données relationnelles traditionnels (SGBDR) et les entrepôts de données MPP regroupent leur système de stockage de dossiers, moteurs de calcul et systèmes de gestion des données sur une seule plateforme. Avec Hadoop, tous ces composants opèrent séparément et indépendamment les uns des autres. Hadoop est un logiciel massif, et la totalité de l'écosystème consiste en des douzaines de vendeurs logiciels, prestataires de services/support, et applications.

Contrairement à de nombreuses solutions d'entrepôts de données analytiques, le logiciel de Hadoop est conçu pour être exécuté avec un matériel basique, ce qui signifie que la totalité de l'architecture logicielle opère également séparément et indépendamment du matériel.

Ensemble, ces deux fonctions signifient qu'une équipe ABD ou DevOps qualifiée peut prendre les mesures nécessaires pour personnaliser tous les aspects de leur stack de données avec Hadoop. Cela signifie que si vous possédez un cluster Hadoop, il est important de connaître les différents avantages et inconvénients de vendeurs.

Quels sont les avantages  lorsque vous utilisez SQL dans Hadoop ?

Rentabilité et efficacité

L'un des avantages principaux de Hadoop est le fait que le logiciel est open source, et conçu pour être exécuté avec du matériel basique, ou du matériel non propriétaire qui n'est lié à aucun prestataire de logiciels.

Ce fait est important car il permet aux organisations d'ajouter plus de machines à leur cluster Hadoop, à des coûts moindres. Les organisations peuvent également échanger différentes technologies Hadoop pour optimiser leurs processus à tout moment sans avoir besoin de remplacer la totalité de leur matériel.

Par exemple, les organisations souhaitant proposer leurs clusters Hadoop en tant qu'entrepôt de données peuvent ajouter un moteur SQL comme Hive pour envoyer une requête de données via SQL. Elles peuvent ensuite échanger Hive avec un autre moteur SQL comme Presto ou Spark, sans avoir besoin de changer leur matériel. La flexibilité est plus grande par rapport à d'autres vendeurs d'entrepôts de données en local, du fait de l'interopérabilité des systèmes basés dans Hadoop.

Agilité

Les utilisateurs Hadoop n'ont pas besoin de déclarer un schéma lorsqu'ils stockent leurs données. De ce fait, le système de fichier distribué Hadoop (HDFS) est un outil rentable pour les organisations souhaitant stocker une quantité massive de données non structurées, et uniquement déclarer un schéma lorsqu'elles souhaitent analyser les données. Cela élimine le besoin de déclarer un schéma potentiellement réducteur lors de l'écriture des données dans le cluster.

L'infrastructure Hadoop s'étend au-delà de SQL et est compatible avec de nombreux langages de programmation différents. C'est l'outil de préférence pour de nombreux développeurs qui souhaitent effectuer une analyse d'apprentissage machine et utiliser de multiples langages de programmation en parallèle sur le même cluster.

Avant le développement des moteurs SQL, l'écriture de code à exécuter dans Hadoop nécessitait des connaissances spécialisées. Cependant, l'arrivée des moteurs SQL dans Hadoop permet aujourd'hui aux organisations d'utiliser un SQL aux normes ANSI dans leurs clusters Hadoop. L'introduction de ces technologies permet aux utilisateurs métiers de connecter tout outil de rapport basé dans SQL à leur cluster Hadoop.

Fiabilité et performance

Hadoop, et spécifiquement le système de fichier distribué Hadoop (HDFS), est généralement mis en œuvre dans les stack de données d'entreprise pour deux raisons : le HDFS est conçu pour être remarquablement insensible aux défaillances (les données au sein du cluster resteront accessibles, même en cas de défaillance des machines dans le cluster) et la structure MapReduce de Hadoop permet aux développeurs de traiter des quantités extrêmement importantes de données.

SQL populaires sur les moteurs Hadoop

Architecture Hadoop

« Lorsqu'on utilisait des bœufs pour tirer des charrues, si un bœuf ne pouvait pas faire bouger un poids, on n'essayait pas d'obtenir un bœuf plus gros. On ne devrait pas essayer d'obtenir des ordinateurs plus gros, mais plutôt des systèmes d'ordinateurs plus imposants. » – Grace Hopper

Les créateurs Hadoop sont des pionniers pour plusieurs concepts qui sont devenus des sources d'innovation dans le domaine des données massives.

Échelle horizontale

Hadoop est conçu pour utiliser une échelle horizontale linéaire, ce qui signifie l'ajout de plusieurs machines de la même taille que votre système de base de données au lieu d'augmenter chaque nœud individuel.

Ce principe garantit non seulement que les utilisateurs Hadoop peuvent facilement et efficacement adapter leur cluster Hadoop, mais aussi que le cluster Hadoop restera performant même si (et surtout si) sa taille évolue.

Pas de mouvements de données

Hadoop a été initialement créé comme un lac de données non structurées pour les données brutes avant que celles-ci ne soient intégrées à une SGBDR. Ce fut une aubaine pour les développeurs qui pouvaient utiliser Java, car ils pouvaient accéder aux données non structurées, et effectuer directement des analyses sur ces données sans avoir à intégrer les données dans une base de données relationnelle. Les utilisateurs métiers, quant à eux, devaient attendre que les données soient nettoyées et placées dans une base de données relationnelle pour pouvoir y accéder avec SQL avant de les utiliser.

Avec l'arrivée de moteurs SQL puissants pour Hadoop, les analystes et utilisateurs métiers peuvent directement accéder aux données du cluster sans avoir à attendre que les données soient déplacées. Les analyses peuvent être effectuées dans un délai plus proche du temps réel, et cela limite le besoin en entrepôt de données consacré aux analystes, ce qui peut simplifier l'architecture de données d'une entreprise.

Schema-on-read

Dans les systèmes plus âgés, avant que les données puissent être écrites dans la base de données, on devait déclarer un schéma qui spécifiait comment les données de la base de données seraient structurées. La création du schéma était un élément crucial des processus ETL (Extract, Transform, Load) nécessaires pour inscrire correctement une donnée dans une base de données.

Ce processus portait le nom de schema-on-write, et c'était l'unique méthode pour inscrire des données dans une base de données. L'infrastructure schema-on-write offrait certains avantages : les données de la base de données étaient robustes (tout ce qui était écrit était considéré comme utilisable par les analystes), cohérentes (toutes les données possédaient la même structure) et propres (accessibles aux utilisateurs finaux).

Cependant, le processus schema-on-write comporte plusieurs inconvénients non négligeables. La personne responsable de l'ETL doit savoir comment les données seront utilisées et analysées avant qu'elles soient écrites, ce qui a généralement pour résultat une disponibilité d'ensemble de données plus limitée. Certaines données peuvent être éliminées ou non collectées parce qu'on ne peut pas déterminer un cas d'utilisation claire pour ces données, ce qui empêche l'analyse historique.

Hadoop et d'autres lacs de données modernes retournent cette idée. Au lieu de déclarer comment les données devraient apparaître exactement dans la base de données, les données provenant de sources externes sont écrites dans un lac de données et transformées uniquement lorsqu'elles sont prêtes à être lues. Cette nouvelle structure est intitulée schema-on-read, parce que le schéma est défini par les analystes lorsque la donnée est lue à la sortie de la base de données pour être analysée.

Si le processus schema-on-read nécessite plus de travail en amont par les analystes afin de comprendre les données avant de déclarer un schéma d'analyse, il offre une plus grande polyvalence et meilleure flexibilité d'analyse, et garantit qu'aucune donnée n'est éliminée si elle ne peut pas être immédiatement schématisée. Schema-on-read offre également aux analystes la liberté d'imposer le schéma le plus logique pour le type d'analyse qu'ils effectuent. Ils n'ont pas besoin d'adapter l'analyse au schéma, ils peuvent à la place adapter le schéma à l'analyse.

Trois composants principaux de l'architecture Hadoop

L'architecture Hadoop peut devenir extrêmement complexe très rapidement, mais on retrouve trois composants essentiels dans tout déploiement moderne Hadoop :

  • Système de fichier distribué Hadoop (HDFS) (stockage)
  • MapReduce (traitement)
  • Apache Hadoop YARN (allocation de ressources)

Système de fichier distribué Hadoop (HDFS)

L'un des plus gros défis ayant mené à l'introduction de HDFS était le besoin de stocker de larges quantités de données sans pour autant dégrader la performance avec l'évolution du stockage.

Chargement des données dans HDFS

HDFS a été créé afin de distribuer les données individuelles à plusieurs machines individuelles et pour les indexer afin qu'elles puissent être récupérées et traitées rapidement.

Les données brutes comprenant divers formats de données sont chargées dans HDFS et partitionnées en petits fichiers nommés blocs. Ces blocs sont ensuite uniformément distribués dans le cluster dans des machines de stockage individuelles appelées nœuds de données. L'emplacement de chaque bloc individuel est ensuite assigné à un nœud spécialisé appelé NameNode. Le NameNode indexe l'emplacement des blocs dans le cluster et gère l'accès à ces nœuds de données.

Réplication par facteur de trois

HDFS réplique chaque bloc trois fois et stocke les copies de chaque bloc sur des nœuds de données séparés. Du fait de ce motif de réplication, le HDFS est incroyablement insensible aux défaillances, parce qu'en cas d'erreur de machine (un événement pratiquement garanti à l'échelle), les données dans le cluster resteront disponibles. Ce motif de réplication garantit que lorsqu'une copie est perdue, HDFS réplique automatiquement cette copie ailleurs dans le cluster, garantissant ainsi systématiquement une grande disponibilité des données.

MapReduce

MapReduce est l'infrastructure qui traite les données distribuées dans plusieurs nœuds différents au sein de HDFS. MapReduce, comme son nom l'indique, allie deux phases :

  • la phase Map, qui effectue l'opération sur les dossiers de blocs individuels stockés dans HDFS
  • la phase Reduce, qui associe les résultats

Préparation des données pour MapReduce

Avant d'utiliser MapReduce, les données nécessaires pour les phases MapReduce doivent être localisées et préparées pour le traitement. Lorsqu'une tâche MapReduce est exécutée, les données stockées dans les blocs de HDFS sont localisées et le format est déterminé. Cela permet à MapReduce de traiter une grande variété de formats de fichiers stockés dans HDFS.

Comme les données d'un seul fichier sont séparées dans plusieurs blocs, une autre fonction intitulée InputSplit est nécessaire, qui divise les données en éléments plus petits et définis pouvant être traités. Les éléments divisés ne contiennent pas de données, ils utilisent ce que l'on appelle un byte offset, qui permet à MapReduce de déterminer un motif logique pour la division des fichiers.

Phase Map

Une fois les entrées localisées et préparées, les données sont prêtes pour la phase Map. Durant la phase Map, les entrées sont traitées sur des nœuds individuels dans le cluster Hadoop au même moment ; on obtient ce que l'on appelle une carte . Toutes ces cartes sont ensuite mélangées, un processus qui consiste à organiser et placer ces cartes dans les nœuds appropriés pour la phase Reduce.

Phase Reduce

Une fois les données correctement partitionnées sur les nœuds appropriés, la phase Reduce rassemble tous les résultats individuels d'une phase Map pour créer un seul résultat. C'est essentiellement une opération sommaire qui marie tous les résultats de ces données en une seule réponse.

Exemple d'une opération MapReduce

Prenons par exemple cet article sur Hadoop, en imaginant qu'il est lu dans HDFS en tant que fichier. On veut effectuer la tâche MapReduce pour déterminer combien de fois le mot Hadoop y est mentionné. Tout d'abord, le fichier doit être lu dans HDFS et divisé en blocs individuels. Ces blocs sont ensuite partitionnés en éléments d'entrée individuels, ce qui garantit que les mots de cet article ne sont pas découpés (si une itération du mot Hadoop est divisée entre deux blocs comme par exemple « Ha » et « doop », cette itération ne sera pas calculée).

Une fois les éléments d'entrée fractionnés calculés, chaque nœud du cluster reçoit un élément fractionné et compte individuellement les itérations du mot « Hadoop » dans l'élément fractionné qu'il a reçu. Les résultats de ces phases de caractérisation individuelles, représentés sous forme de comptes, sont ensuite mélangés, puis regroupés durant la phase de réduction de l'opération pour fournir un décompte complet des itérations de Hadoop dans cet article.

IBM utilise l'excellent exemple du recensement de Rome : les agents de recensement voyageaient dans chaque ville à Rome, comptaient les individus situés dans cette ville, et retournaient dans la capitale où les résultats étaient ensuite regroupés pour former un décompte total de la population de Rome.

Apache Hadoop YARN – un autre négociateur de ressources

Avant le lancement Hadoop 2.0 et l'introduction de YARN, MapReduce gérait également les tâches extrêmement basiques de gestion de charges et de planification des tâches, ce qui rendait la mise en œuvre des applications d'analyse autre que MapReduce sur les mêmes nœuds extrêmement difficile. De plus, les architectures qui contenaient également des applications d'analyse devaient être effectuées en dehors de Hadoop, nécessitant le déplacement de données de Hadoop vers des nœuds externes en dehors de l'infrastructure Hadoop.

L'introduction de YARN fut un événement important, car cela permit enfin aux applications d'analyse non-MapReduce de fonctionner dans le cluster Hadoop. YARN rend cela possible en équilibrant intelligemment les ressources sur les nœuds individuels entre les tâches MapReduce et les applications d'analyse.

Contraintes Hadoop

De nombreux fichiers de petite taille

Hadoop présente une contrainte reconnue par tous : le problème au niveau du stockage et du traitement des tout petits fichiers, c'est-à-dire des fichiers qui sont plus petits qu'un bloc HDFS (environ 64 MB). Hadoop est optimisé pour pouvoir traiter extrêmement efficacement plusieurs fichiers massifs, mais a des problèmes avec les fichiers plus petits, au niveau du stockage et du traitement.

Vous trouverez dans le blog de Cloudera un excellent exemple qui compare un fichier unique de 1 GB divisé en 16 blocs de 64 MB à 10 000 fichiers de 100 KB chacun. Dans le premier cas, 16 tâches de caractérisation individuelles sont créées, et dans le second cas, 10 000 tâches de caractérisation sont créées, ce qui ralentit de façon importante la performance, même si le stockage physique occupé par ces fichiers est le même.

Cloudera propose ensuite deux solutions au problème des petits fichiers dans Hadoop : l'une implique la création d'un fichier HAR, et l'autre implique la création d'un fichier Sequence.

Optimisation Hadoop

Hadoop peut soit être déployé en tant que lac de données non structurées et raffinerie pour les données qui seront déplacées dans un entrepôt de données dédié, soit en tant qu'entrepôt de données dédié utilisant des analyses dans le cluster.

Hadoop avec un entrepôt de données

De nombreuses organisations décident de mettre en œuvre Hadoop en tant que lac de données non structurées pour les développeurs, et utilisent l'infrastructure de traitement de Hadoop comme mécanisme ETL low-cost permettant d'intégrer les données dans un entrepôt de données dédié pour les analystes, les utilisateurs métiers et les applications d'analyse.

Hadoop en tant qu'entrepôt de données

Hadoop 2.0 et YARN, ainsi que le nombre grandissant de SQL aux normes ANSI  pour les moteurs Hadoop, permettent aux analyses dans le cluster d'être effectuées dans Hadoop. Avec ce système, les organisations n'ont pas besoin  de déplacer les données. Au lieu de cela, les calculs et les analyses sont effectués avec Hadoop.

Le principal avantage de SQL pour les moteurs Hadoop est que cela permet aux utilisateurs métiers et aux analystes d'exécuter SQL avec les données stockées dans Hadoop, éliminant ainsi complètement le besoin de déplacer de grandes quantités de données.

Prenez goût à l'analytique

Business intelligence, analyse de big data ou vue client à 360° :
quels que soient vos besoins, Looker peut vous aider. Parlez à nos experts en données.

Demander une démo