Hadoop / Big Data Benjamin Renaut <renaut.benjamin@tokidev.fr> MBDS 2014-2015
6 map/reduce et Hadoop: exemples plus avancés
Exemple: parcours de graphe 6-1 On cherche à déterminer la profondeur maximale de tous les nœuds d'un graphe à partir d'un nœud de départ (via breadth-first search, parcours en largeur). Le graphe:
Exemple: parcours de graphe 6-2 Données d'entrée: (1;"2,5 GRIS 0") (2;"3,4 BLANC -1") (3;"6 BLANC -1") (4;" BLANC -1") (5;"6 BLANC -1") (6;" BLANC -1") avec valeur sur le modèle «NOEUDS_FILS COULEUR PROFONDEUR». Et couleur ayant pour valeur «BLANC» pour un nœud non parcouru, «GRIS» pour un nœud en cours de parcours, et «NOIR» pour un nœud déjà parcouru. Dans nos données d'entrée, l'unique nœud GRIS indique le nœud de départ.
Exemple: parcours de graphe 6-3 map: si le nœud du couple (clef;valeur) d'entrée est GRIS, alors: Pour chacun de ses fils, retourner (ID_FILS;" GRIS PROFONDEUR+1), où PROFONDEUR est la profondeur du nœud courant. Retourner également le couple (clef;valeur) courant, avec couleur=noir. Sinon: retourner le couple (clef;valeur) d'entrée. Pseudo code: SI NODE.COULEUR=="GRIS": POUR CHAQUE FILS DANS NODE.CHILDREN: FILS.COULEUR="GRIS" FILS.PROFONDEUR=NODE.PROFONDEUR+1 RENVOYER (FILS.ID;FILS) NODE.COULEUR="NOIR" RENVOYER (NODE.ID;NODE)
Exemple: parcours de graphe 6-4 reduce: parcourir chacune des valeurs associées à la clef unique (après shuffle). Renvoyer un couple (clef;noeud) avec un nœud dont: La profondeur est la plus haute rencontrée parmi les valeurs associées à cette clef unique (l'identifiant du nœud). La couleur est la plus «forte» parmi ces mêmes valeurs. La liste des nœuds enfants est la plus longue parmi ces valeurs. et pour clef la clef unique en question.
Exemple: parcours de graphe 6-5 Pseudo code: H_CHILDREN=""; H_PROF=-1; H_COULEUR="BLANC"; POUR CHAQUE VALEUR: SI VALEUR.CHILDREN.LENGTH()>H_CHILDREN.LENGTH(): H_CHILDREN=VALEUR.CHILDREN SI VALEUR.PROFONDEUR>H_PROF: H_PROF=VALEUR.PROFONDEUR SI VALEUR.COULEUR>H_COULEUR: H_COULEUR=VALEUR.COULEUR NODE=NOUVEAU NOEUD NODE.COULEUR=H_COULEUR NODE.CHILDREN=H_CHILDREN NODE.PROFONDEUR=H_PROF RENVOYER(CLEF;NODE)
Exemple: parcours de graphe 6-6 On exécute le programme map/reduce plusieurs fois, jusqu'à ce que tous les nœuds de la liste aient pour couleur la valeur «NOIR» <=> jusqu'à ce que tous les nœuds aient été parcourus. Ce type de logique s'implémente très facilement au sein d'un framework map/reduce (Hadoop).
Exemple: parcours de graphe 6-7 Premier lancement: Données d'entrée: (1;"2,5 GRIS 0") (2;"3,4 BLANC -1") (3;"6 BLANC -1") (4;" BLANC -1") (5;"6 BLANC -1") (6;" BLANC -1") Graphe:
Exemple: parcours de graphe 6-8 Pour ce premier lancement: Sortie de map: (1;"2,5 NOIR 0") (2;" GRIS 1") (5;" GRIS 1") (2;"3,4 BLANC -1") (3;"6 BLANC -1") (4;" BLANC -1") (5;"6 BLANC -1") (6;" BLANC -1") Sortie de reduce: Aprés shuffle: 1: ("2,5 NOIR 0") 2: (" GRIS 1"),("3,4 BLANC -1") 3: ("6 BLANC -1") 4: (" BLANC -1") 5: (" GRIS 1"),("6 BLANC -1") 6: (" BLANC -1") (1;"2,5 NOIR 0") (2;"3,4 GRIS 1") (3;"6 BLANC -1") (4;" BLANC -1") (5;"6 GRIS 1") (6;" BLANC -1")
Exemple: parcours de graphe 6-9 Lancement 2: Données: Graphe: (1;"2,5 NOIR 0") (2;"3,4 GRIS 1") (3;"6 BLANC -1") (4;" BLANC -1") (5;"6 GRIS 1") (6;" BLANC -1")
Exemple: parcours de graphe 6-10 Lancement 3: Données: Graphe: (1;"2,5 NOIR 0") (2;"3,4 NOIR 1") (3;"6 GRIS 2") (4;" GRIS 2") (5;"6 NOIR 1") (6;" GRIS 2")
Exemple: parcours de graphe 6-11 Après le lancement 3: Données de sortie: (1;"2,5 NOIR 0") (2;"3,4 NOIR 1") (3;"6 NOIR 2") (4;" NOIR 2") (5;"6 NOIR 1") (6;" NOIR 3") Graphe:
Exemple: parcours de graphe 6-12 Tous les nœuds ont tous désormais pour couleur la valeur «NOIR» ; le programme en charge de lancer la tâche map/reduce à répétition sur les données s arrête. On a ainsi effectué un parcours en largeur sur le graphe, parallélisable (parallel breadth-first search). A chaque étape de profondeur dans le parcours correspond l'exécution d'une tâche map/reduce avec une fonction map executée pour chaque nœud à chaque étape.
Conclusion 6-13 Applications courantes de map/reduce et Hadoop: Analyse de logs et données en général, validation de données, recoupements, filtrage, etc. => traitements sur des volumes de données massifs. Exécution de tâches intensives en CPU de manière distribuée (simulations scientifiques, encodage vidéo, etc.). et bien souvent les deux: tâches intensives en CPU sur des volumes de données massifs (entraînement de modèles en machine learning, etc.) Plus complexe, voire contre-productif à appliquer sur tout problème où la fragmentation des données d'entrée pose problème (en fait sur tout problème où la stratégie du diviser pour régner n'est pas viable).
7 Sqoop
Présentation 7-1 Comme on l'a vu, Hadoop accède aux données qu'il va traiter par le biais de HDFS, et stocke ses résultats au même endroit. Bien souvent, cependant, on va vouloir faire travailler Hadoop sur des données provenant d'une base de données traditionnelle (statistiques web, données provenant du backend d'une solution logicielle, etc.). Sqoop est un outil permettant de répondre à ce problème. Il vise à permettre de facilement transférer des données depuis des bases de données structurées (MySQL, PostgreSQL, Oracle, etc.) vers HDFS, et vice-versa. Projet Open Source de la fondation Apache, développé par des bénévoles depuis 2009. Son utilisation n'a cessé d'augmenter depuis et il est devenu un des projets phares de la fondation Apache en 2012.
Remarque 7-2 On parle ici de base de données structurée pour désigner les bases de données «classiques», avec des tables, des indexs, etc... Par opposition, HDFS fonctionne à partir de simples fichiers texte, sans aucun index. C'est une méthode sensiblement moins performante de stocker des données mais contrairement aux bases de données structurées, elle permet de stocker des quantités véritablement massives de données (plusieurs centaines de petaoctets si nécessaire). Il existe également des modèles hybrides de ces deux approches: des bases de données qui abandonnent l'idée de contraintes rigides telles que les tables, les relations, etc... mais proposent des fonctionnalités commes les indexs et stockent les données autour du concept de document, des blocs de données au format JSON, XML ou encore YAML et qui n'ont pas la contrainte de devoir tous respecter le même format et d'avoir tous les mêmes champs. Un exemple de ce type de base est MongoDB, un autre exemple est le projet Apache Cassandra.
Principe de fonctionnement 7-3 Sqoop est un outil en ligne de commande, au même titre que le client hadoop. Il est ainsi utilisable facilement au sein de scripts automatisés. Il peut non seulement importer le contenu d'une table située dans une base de données au sein de HDFS, mais également générer une classe Java toute prête, utilisable au sein d'un programme Hadoop, qui permet facilement d'accéder aux données qu'il a généré. Ainsi, si on souhaite par exemple manipuler les données provenant d'une table MySQL, on va demander à Sqoop de générer un fichier java permettant l'accés aux données qu'il exportera, et on utilisera ce fichier java au sein de notre programme Hadoop le.jar qu'on exécutera. Ensuite, il suffira à tout moment d'exécuter Sqoop pour importer la dernière version de nos données depuis la base, et de lancer notre programme Hadoop pour facilement manipuler ces données.
Principe de fonctionnement 7-4 Enfin, Sqoop est également capable d'importer des données depuis HDFS au sein d'une base de données. Cette fonctionnalité sera utilisée pour importer nos résultats au sein d'une table, et pouvoir ensuite par exemple les afficher depuis un backend. Par ailleurs, on peut également utiliser Sqoop pour procéder à de l'archivage de données. Si par exemple on a une table MySQL contenant un grand nombre de statistiques webs, on pourra par le biais d'une seule commande sauvegarder toutes les anciennes statistiques dans HDFS en profitant ainsi de sa capacité à conserver une très grande quantité de données, et de ses capacités de réplication. Ainsi, notre table MySQL restera lègere et les requêtes s'exécuteront rapidement, mais on gardera tout de même une trace de toutes les données passées.
Principe de fonctionnement 7-5 Sqoop utilise les connecteurs JDBC Java il gère donc un très grand nombre de SGBD différents (MySQL, Oracle, PostgreSQL, etc.). Il peut importer une table entière, ou encore le résultat d'une requête SQL (pour sélectionner seulement certains enregistrements). Il est extrêmement configurable: les champs à inclure dans l'importation, leur ordre, l'endroit où stocker les données, leur format, etc... sont des options configurables. Pour l'exécution d'un import ou d'un export de données, il créé une tâche map qu'il exécute via le cluster Hadoop local. Ainsi, la tâche d'importation ou d'exportation est exécutée en parallèle, en tirant partie de toute la puissance du cluster.
Formats de données 7-6 Sqoop gère trois formats distincts pour stocker les données sur HDFS: Sous forme de delimited text files: des fichiers texte humainement lisibles qui listent les champs de la base, séparés par des virgules (configurable). C'est l'option qu'on utilisera lorsque l'on souhaite garder un accès facile (humainement parlant) aux données qu'on exporte, et que les données situées en base ne sont pas binaires. Sous forme de sequence files: des fichiers binaires propres à Sqoop. C'est l'option qu'on utilisera si on souhaite manipuler les données depuis un programme Map/Reduce dans Hadoop, car les performances sont nettement supérieures aux fichiers textes. On se servira également de ce format pour les tables contenant des données binaires. Ce format ne sera cependant facilement lisible qu'avec la classe dédiée Java créée par Sqoop le lire depuis d'autres langages de programmation est complexe (format non trivial).
Formats de données 7-7 Sous forme de Avro data files: un autre format binaires, décrivant des données sérialisées. Contrairement aux sequence files, le format Avro est facilement lisible par le biais de librairies disponibles dans de nombreux autres langages de programmation (par le biais des librairies du projet Apache Avro). Ses performances sont légèrement inférieures aux sequence files, mais toujours largement supérieures au format texte. Dans les trois cas, la compression est supportée, avec plusieurs algorithmes possibles cette option diminuera sensiblement les performances de lecture mais permettra d'économiser l'espace occupé par les données sur HDFS. D'une manière générale, on retient qu'on utilisera le format texte pour garder les données sous un format facilement lisible (ou pour du debug), le format sequence files si on compte exploiter les données depuis un programme Hadoop «natif» (Java), et le format Avro si on compte les exploiter depuis un programme Hadoop rédigé dans un autre langage.
Exemple Format texte 7-8 Table en base de données contenant des élèves du MBDS (trois colonnes: id, nom et prénom). Aprés export Sqoop au format texte, un fichier sera créé sur HDFS contenant: 1,ARNAUD,Clément 2,BANGOURA,Mohamed Amy 3,BEATINI,Nathalie 4,BIGA,Anthony 5,CHAABANE,Mohamed 6,CHATTON,Jérémy 7,DA SILVA,David 8,DEMEURE,Guillaume [ ]
Fichier de sortie 7-9 Puisqu'un export Sqoop est une tâche Hadoop MAP, le résultat de l'export sera stocké dans une série de fichiers sous la forme: part-m-00000 part-m-00001 part-m-00002...etc... Par ailleurs, un fichier _SUCCESS est également créé pour confirmer que l'export a été réalisé correctement. Dans le cas où on choisit le format Avro, alors les noms de fichier seront identique mais porteront l'extension «.avro» (part-m-00000.avro, etc.). On peut préciser la taille limite, en octets, de chacun des fichiers fragments qui résultent de l'import.
Import 7-10 Pour importer des données depuis une base de données, la commande la plus basique est la suivante: sqoop import -connect [JDBC STRING] -username [USER] \ --password [PASSWORD] -table [TABLE] qui importera le contenu de la table [TABLE] depuis la base de données spécifiée dans un répertoire portant le nom de la table dans HDFS. Par exemple: sqoop import -connect jdbc:mysql://localhost/poemes \ -username hadoop -password h4d00p \ -table rose_reseda
Import - contraintes 7-11 On peut également importer des données selon une contrainte SQL WHERE: sqoop import -connect [JDBC STRING] -username [USER] \ --password [PASSWORD] -table [TABLE] \ --where [CONTRAINTE] par exemple avec "id>50" comme valeur de [CONTRAINTE]. On peut également choisir les champs à importer, avec l'option columns: sqoop import -connect [JDBC STRING] -username [USER] \ --password [PASSWORD] -table [TABLE] \ -columns COL1,COL2,COL3 ce qui permet également de définir l'ordre dans lequel les champs apparaitront dans les fichiers au format texte.
Import requêtes SQL 7-12 On peut également utiliser une requête SQL directement. Ce cas supporte notamment les jointures. On utilise pour ce faire l'option -query. En revanche, comme Sqoop va effectuer le traitement de manière parallèle, il faut lui laisser un espace au sein de la requête dans lequel il pourra ajouter une clause différenciante selon les nodes qui effectueront chacun un morceau de la requête «globale». On utilise pour ce faire le marqueur $CONDITIONS. Il est également nécessaire de lui indiquer quel champ résultant de la requête il peut utiliser pour distribuer le travail aux différents nœuds. Ce champs doit être tel qu'il permette à Sqoop de distribuer correctement le travail aux différents nœuds du cluster. Ce champ indiqué par l'option -split-by est souvent la clef primaire de la table/une des clefs primaires du set de résultat concerné.
Import requêtes SQL 7-13 La syntaxe: sqoop import -connect [JDBC STRING] -username [USER] \ --password [PASSWORD] -table [TABLE] \ -query [REQUETE INCLUANT $CONDITIONS] \ --split-by [COLONNE] Par exemple: sqoop import -connect jdbc: [ ] \ -query "SELECT a.id,a.nom FROM users a, wallet_content b \ where a.id==b.owner_id AND b.type==2 AND \$CONDITIONS" \ -split-by a.id...pour récupérer les infos des utilisateurs dont le wallet contient au moins un item de type «2».
Import incrémentaux 7-14 On peut également demander à Sqoop d'importer depuis une table uniquement les données qui ont été modifiées depuis le dernier import. Pour ce faire, on utilise les trois options suivantes: --incremental: indique le mode de vérification, qui peut avoir une des deux valeurs suivantes: append: Sqoop importera uniquement les nouveaux enregistrements dans la table, et seulement ceux pour lesquels le champs spécifié a au moins la valeur minimale spécifiée. Typiquement utilisée avec une clef primaire AUTO_INCREMENT (un id). lastmodified: Scoop importera tous les enregistrements dont le champs spécifié a eu une valeur mise à jour depuis le dernier import, supérieure à la précédente. Doit être utilisé avec un champs TIMESTAMP.
Import incrémentaux 7-15 --check-column: indique quel est le champ à vérifier lors de l'import incrémental. Dans le cas de append, il s'agit du champ numérique à contrôler. Dans le cas de lastmodified, il s'agit du champ TIMESTAMP à contrôler. --last-value: la dernière valeur à considérer pour le champs numérique (append) ou pour le timestamp (lastmodified). A la fin de l'exécution d'une tâche append, Sqoop affichera la prochaine valeur à utiliser pour le paramètre -last-value sur la sortie standard. On remarque que pour un import incrémental, on doit nécessairement utiliser un champ numérique ou un champ traduisant une date (TIMESTAMP, DATE, etc.). Remarque: la syntaxe des imports incrémentaux peut être couplée à des tâches sauvegardées Sqoop, qu'on peut rappeler à tout moment, pour simplifier grandement la vie de l'utilisateur. Elles seront abordées un peu plus loin dans le cours.
Import incrémentaux exemples 7-16 Exemple: sqoop import -connect jdbc: [ ] \ --table statistiques -incremental append \ -check-column id -last-value 353...pour importer les statistiques qui ont un id supérieur ou égal à 353. On remarque qu'on aurait également pu utiliser -where "id>=353". Un second exemple: sqoop import -connect jdbc: [ ] \ --table users -incremental lastmodified \ -check-column last_login -last-value 1223523134...pour importer les utilisateurs qui se sont identifiés sur le backend récemment (>= au timestamp 1223523134), en mettant à jour ceux qu'on avait déjà importé.
Autres options utiles 7-17 Quelques autres options utiles de Sqoop: --outdir [DIR] : normalement, Sqoop génère le fichier Java qui permet d'accéder aux données facilement depuis un programme hadoop directement dans le répertoire courant. Cette option permet de lui indiquer un autre répertoire où il doit le sauvegarder. Dans tous les cas, le nom de fichier correspond au nom de la table (par exemple members.java pour une table members, etc.). --package-name [PKG] : permet de définir un package Java pour le code autogénéré par Sqoop. En temps normal, Sqoop génère simplement une classe portant le nom de la table (IE, classe members dans members.java). Cette option permet de spécifier un nom de package complet (par exemple, org.mbds.hadoop.members).
Autres options utiles 7-18 --target-dir [DIR] : indique à Sqoop l'emplacement où stocker les données importées dans HDFS (par exemple, /data). --warehouse-dir [DIR] : alternative à -target-dir; indique à Sqoop un répertoire global où il créera un répertoire par table importée, en stockant les fichiers d'importation de chaque table dans le répertoire qui lui correspond. Cette option est notamment utile lorsque l'on souhaite importer plusieurs tables à la fois. Remarque: on ne peut pas utiliser -target-dir et - warehouse-dir en même temps. --fields-terminated-by [DELIM] : permet d'indiquer une alternative au caractère de délimitation des champs par défaut (virgule ','). --lines-terminated-by [DELIM] : même chose pour les lignes/records (au lieu d'un retour à la ligne).
Autres options utiles 7-19 --as-avrodatafile : indique à Sqoop qu'on souhaite stocker les résultats au format Avro. --as-sequencefile : indique à Scoop qu'on souhaite stocker les résultats au format sequence file. --as-textfile : indique à Scoop qu'on souhaite stocker les résultats au format texte (utilisé par défaut). --direct : utilise le mode d'importation direct une version plus rapide de l'import pour certains SGBD (par exemple, pour MySQL, utilise l'outil interne mysqldump au lieu de contacter la base «manuellement»). --compress : active la compression de fichiers (par défaut en gzip).
Autres options utiles 7-20 --compression-codec [CODEC] : spécifie l'algorithme de compression à utiliser. Valeurs possibles: gzip, bzip2. Par défaut, gzip. -m [MAPPERS] : indique le nombre d'opérations Map lancées en parallèle pour un import/un export. Permet d'ajuster le parallélisme de l'opération. Remarque: il existe de nombreuses autres options disponibles pour Sqoop certaines plus utiles que d'autres. Pour plus d'informations, se référer à la documentation officielle de Sqoop: http://sqoop.apache.org/
Importer plusieurs tables 7-21 Pour importer toutes les tables (ou plusieurs tables à la fois) grâce à Sqoop, on utilise la commande import-all-tables. Syntaxe: sqoop import-all-tables -connect jdbc: [ ] \ --exclude-tables TABLE1,TABLE2 L'option -exclude-tables permet d'exclure certaines tables de la base de données. C'est typiquement avec cette commande qu'on utilisera l'option -warehousedir vue précédemment elle permettra à Sqoop de créer un répertoire par table importée, en stockant les fichiers de données à l'intérieur de chacun des répertoires concernés.
Export 7-22 Afin d'effectuer l'opération inverse, c'est à dire exporter des données depuis HDFS vers la table d'une base de données, on va utiliser la commande Sqoop export. Le format des données doit impérativement être un format supporté par Sqoop (et on doit lui indiquer lequel avec les options vues précédemment). La plupart des options de import sont également disponibles pour la commande export: --connect, --username, --password, etc... L'option -table est elle aussi disponible, mais elle indique cette fois la table dans laquelle on souhaite exporter les données. Enfin, on précise le répertoire contenant les fichiers à exporter (des fichiers part-r-00000, part-r-00001, etc.) avec l'option -export-dir.
Export 7-23 Par ailleurs, on dispose de deux modes possibles pour l'exportation, à préciser à l'aide de l'option - update-mode: updateonly : avec cette valeur, Sqoop n'exportera pas les enregistrements pour lesquels un enregistrement n'existe pas déjà avec la même clef primaire/les mêmes champs clef (paramétrables). C'est l'option par défaut. allowinsert : avec cette valeur, Sqoop aura le même comportement mais si un enregistrement n'existe pas déjà dans la table, il en insérera un nouveau. C'est avec l'option -update-key qu'on va pouvoir préciser le champ que Sqoop doit regarder pour déterminer si oui ou non un enregistrement existe déjà. On peut par ailleurs spécifier plusieurs champs «clef» à vérifier, séparés par des virgules.
...chargera les résultats situé dans /members sur HDFS dans la table members. Si un enregistrement n'est pas trouvé pour le couple de champs nom/prenom, Sqoop insérera de nouveaux enregistrements dans la table. Exemples 7-24 Deux exemples: sqoop export -connect jdbc: [ ] \ --export-dir /results -table results \ -update-mode updateonly -update-key id chargera les fichiers résultats situés dans le répertoire HDFS /results dans la table results de la base de données. Si un enregistrement existant n'est pas trouvé pour le champ id, alors l'enregistrement à exporter ne sera pas inséré. sqoop export -connect jdbc: [ ] \ --export-dir /members -table members \ -update-mode insert -update-key nom,prenom
Code auto-généré 7-25 Comme on l'a indiqué précédemment, Sqoop génère un code à partir des enregistrements qu'il importe depuis la base de données dans HDFS. Il s'agit d'une classe unique, par table, qui désigne un enregistrement de la table. En réalité, cette classe implémente l'interface Hadoop Writable, exactement comme tous les types Hadoop vus précédemment: IntWritable, Text, etc... Autrement dit, simplement en important cette classe auto-générée dans son code, on peut directement se servir des données reçues en entrée (et qui sont présentes sur HDFS et proviennent de HDFS) comme d'une clef ou d'une valeur dans nos opération Map ou Reduce. Exemple de définition de classe auto-générée: public class members extends SqoopRecord implements DBWritable, Writable {
8 Connecteurs HDFS en temps réel
Présentation 8-1 On a présenté Sqoop, un outil polyvalent qui permet d'importer ou d'exporter des données entre HDFS et les bases de données «classiques» (Oracle, MySQL, PostgreSQL, etc...). Sqoop est extrêmement utile pour faire des échanges entre les bases de données et HDFS. Il s'agit cependant d'un outil utilisé pour des échanges de données ponctuels: on s'en servira par exemple pour effectuer des traitements Hadoop sur les données de la base toutes les nuits, ou encore toutes les N minutes, etc... en ré-important éventuellement les données dans la base après traitement. Il y a cependant des cas d'utilisation où on souhaite pouvoir échanger des données entre une base de données et la couche HDFS en temps réel. Par exemple, on pourrait avoir des retours statistiques sur un large réseau social depuis un backend centralisé, dont les données nécessitent des traitements massifs par le biais de Hadoop.
Les connecteurs 8-2 On pourrait imaginer utiliser un outil comme Sqoop de manière continue, en lançant en permanence la même tâche Sqoop. Cependant, pendant que la tâche s'exécute, de nouvelles données peuvent apparaître; par ailleurs, la charge appliquée au SGBD serait conséquente et provoquerait de potentiels problèmes d accès aux bases (LOCK des tables). Pour répondre à ce problème, la plupart des bases de données largement utilisées ont développé des points d'intégration entre les SDBG et HDFS. On désigne souvent ces points d'intégration en parlant de connecteurs Hadoop. On voit également les termes applier ou encore bridges. Ces connecteurs ont tous en commun la capacité d'écrire sur HDFS les données de la base en permanence, au fur et à mesure. Parfois, ils sont aussi capables de répliquer des modifications faites sur HDFS dans la base de données.
MySQL applier for Hadoop 8-3 Dans le cas de MySQL, le connecteur est le MySQL applier for Hadoop d'oracle. Il fonctionne en tirant partie des binary logs de MySQL les logs binaires que MySQL peut générer (si activé) en permanence et qui indiquent toutes les modifications faites sur la base de données. Ce sont ces mêmes binary logs qui sont utilisés pour les mécanismes de réplication MySQL classiques (entre nœuds MySQL). Le connecteur génère un répertoire par base de données sur HDFS. A l'intérieur de ce répertoire, il créé un répertoire différent par table présente dans la base de données. Enfin, à l'intérieur de ces répertoires, il génère des séries de fichiers contenant les données de la table concernée. Le format des fichiers est configurable: format texte ou format binaire sequence files (les mêmes que ceux vus avec Sqoop).
MySQL applier for Hadoop 8-4 (source: documentation MySQL)
(source: documentation MySQL) MySQL applier for Hadoop 8-5
Oracle SQL connector for HDFS 8-6 Dans le cas de Oracle, le connecteur est le Oracle SQL connector for HDFS. Il est sensiblement plus puissant que le connecteur de MySQL; notamment, il est capable de lire des données depuis HDFS qui ont été générées par des programmes Hadoop. Il fonctionne en utilisant le mécanisme des tables externes Oracle: des «tables» virtuelles Oracles qui désignent en réalité des données situées en dehors du SGBD. Pour connecter des dossiers ou fichiers HDFS à Oracle, il suffit de créer ces tables externes en définissant un schéma de données bien précis (comme pour une table classique). Ce schéma correspond à un format de données situé sur HDFS. Il est même possible d'effectuer des jointures entre des tables Oracle «classiques» et des tables virtuelles qui correspondent à des données sur HDFS.
Oracle SQL connector for HDFS 8-7 Le connecteur Oracle est capable de stocker les données sous HDFS dans deux formats principaux: un format texte, similaire au format texte utilisé dans Sqoop et le connecteur MySQL et humainement lisible, ou un format binaire. Le format binaire en question n'est pas celui des sequences files vu précédemment, mais un format propre à Oracle et désigné sous le terme de data dumps. Oracle fourni par ailleurs des APIs Java nécessaires pour accéder simplement et rapidement aux données stockées dans ce format de la même manière que pour des Sequence Files. Ces APIs définissent notamment des classes Input/OutputFormat Hadoop, de la même manière que par exemple la classe Hadoop SequenceFileInputFormat vue en TP. On peut donc se servir de ces classes comme d'un format d'entrée pour une tâche Hadoop, ou d'un format de sortie, toujours sur HDFS.
Autres connecteurs et modèles 8-8 Il existe de nombreux autres connecteurs permettant l'accés à des données situées dans une base de données depuis Hadoop certains propriétaires et commerciaux, d'autres Open Source et librement disponibles. D'autres connecteurs évitent complètement HDFS Hadoop va alors récupérer ses données dans le SGBD directement lors de l'exécution d'une tâche. Il suffit au programmeur d'utiliser une autre API pour préciser à Hadoop la source de ses données. Exemple: VoltDB. Il s'agit d'un SGBD Open Source innovant qui utilise un stocke ses données en mémoire vive (un peu comme le moteur MEMORY de MySQL), de manière distribuée et répliquée, et constitue ainsi une alternative à HDFS. Il propose des APIs Java pour l'accés aux données depuis Hadoop, et offre ainsi l'avantage de pouvoir directement s'intégrer à Hadoop et venir «remplacer» HDFS.