Hadoop Hbase - Introduction

5 502 vues

Publié le

Introduction aux Big Data, à Hadoop et HBase.

Publié dans : Logiciels
1 commentaire
19 j’aime
Statistiques
Remarques
  • Un grand bravo pour cette très bonne présentation, très claire !! Félicitations !
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
Aucun téléchargement
Vues
Nombre de vues
5 502
Sur SlideShare
0
Issues des intégrations
0
Intégrations
10
Actions
Partages
0
Téléchargements
0
Commentaires
1
J’aime
19
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Hadoop Hbase - Introduction

  1. 1. Introduction à HADOOP-HBASE Blandine LARBRET 2015
  2. 2. Blandine LARBRET Ingénieur biologiste reconvertie en informatique, je suis à ce jour étudiante en alternance pour obtenir un Master2 Software Development. Au cours de mes 2 ans d'alternance, j'ai découvert le monde pas si simple de HBase que j'ai voulu partager. Cette présentation est donc juste une introduction aux différentes Big Data et plus précisément à Hadoop et HBase. Les schémas que j'ai réalisé traduisent ma propre compréhension de ce modèle de base de données, acquise à partir de toute la littérature que j'ai pu explorer. En espérant que ça puisse vous éclairer... larbret.blandine@gmail.com
  3. 3. Plan Les différentes Big Data Hadoop HBase
  4. 4. BIG DATA
  5. 5. Historique 1 Go 1 To = 103 Go 1 Po = 106 Go 1 Eo = 109 Go 1 Zo = 1012 Go 1982 1970 BD relationnelle 1997 notion de Big Data 1999 Big Analytics 1996 explosion du web 2010 1 Yo = 1015 Go www.winshuttle.fr/chronologie-big-data/ Besoin croissant en capacité de stockage numérique Futur
  6. 6. Contexte
  7. 7. Contexte Exemples Données mondiales => 1,8 Zo en 2011 Emails => 250 milliards / jour (80% de spams) Vidéos => 72h déposées / min sur Youtube Boeing => 20 To / heure de données www.santepublique-editions.fr/objects/cyres-big-data-pre-769-sentation -tables-rondes-ingensi.pdf
  8. 8. Domaines d’application Entreprises du web Google, Facebook, Twitter, Amazon, Ebay ... Grands groupes Sécurité Sociale, INPI, banques... Analyses de données statistiques pour les entreprises privées, sondages d’opinion, études marketing... Recherche scientifique séquençage du génome humain, astronomie...
  9. 9. Définition des Big Data Une Big Data est une base de données distribuée sur plusieurs machines d'un même réseau. Du fait de sa configuration, les jointures connues sous les SGBDR n'existent plus, rendant le langage SQL sans intérêt. C'est pourquoi les Big Data étaient initialement appelées Bases de Données NoSQL, pour "Not Only SQL", sous-entendues "non relationnelles". Mais le terme de NoSQL sonnant comme un affront aux administrateurs de BD classiques, il a cédé la place à celui de Big Data. La notion de Big Data est apparue en 1997, mais la technologie fut développée à partir de 2003 par Google. http://www.stechfrites.com/content/le-mouvement-nosql
  10. 10. Définition des Big Data Nœud : serveur appartenant au réseau d'une Big Data Cluster : ensemble des serveurs d'un même réseau Big Data Les nœuds peuvent être physiquement hétérogènes (configuration hardware différente). Les systèmes de gestion des Big Data gèrent cette hétérogénéité.
  11. 11. Définition des Big Data base de données relationnelle = stockage modéré base de données distribuée = stockage illimité BIG DATA cluster nœud
  12. 12. Dénormalisation Le stockage illimité sur un réseau distribué permet la réplication des données, ce qui optimise leur lecture et assure leur sauvegarde même en cas de panne matérielle. C'est la dénormalisation. En BD classique, la maintenance d'un tel système est compliquée en cas de modification. Mais les systèmes de gestion des Big Data gèrent totalement les réplications. data http://www.thecodingmachine.com/fr/d%C3%A9normalisation-du-mod%C3%A8le -de-donn%C3%A9es
  13. 13. Les 3 V Volume gros volume de données à stocker > 1 Petaoctet Variété différents type de données => brutes, texte, images... Vélocité rapidité de traitement en écriture et lecture Laney D. - 2001 - "3D Data Management: Controlling Data Volume, Velocity, and Variety" META group Inc.
  14. 14. Propriétés ACID Les BD relationnelles doivent respecter toutes les propriétés ACID : - Atomicité : les requêtes reçues par la base doivent être complètes sous peine d'être non traitées - Cohérence : les requêtes doivent respecter l'état de validité de la base (respect des contraintes, des mises à jour...) - Isolation : les requêtes sont indépendantes les unes des autres lors d'un envoi simultané - Durabilité : les modifications de la base doivent être effectuées en priorité avant toute autre action pour permettre la sauvegarde de ces changements Les Big Data ne répondent pas à ces propriétés. Mais elles respectent le théorème CAP.
  15. 15. Théorème CAP Il est impossible pour tout système de garantir en même temps les trois contraintes suivantes, seules 2 peuvent être respectées simultanément : - Cohérence (= Consistency) : tous les nœuds du système voient exactement les mêmes données au même moment - Disponibilité (= Availability) : garantie que toutes les requêtes reçoivent une réponse - Résistance au morcellement (= Partition Tolerance) : aucune panne moins importante qu'une coupure totale du réseau ne doit empêcher le système de répondre correctement (ou encore : en cas de morcellement en sous-réseaux, chacun doit pouvoir fonctionner de manière autonome). A. Fox, E.A. Brewer - 1999 - "Harvest, Yield and Scalable Tolerant Systems" Proc. 7th Workshop Hot Topics in Operating Systems - p.174-178
  16. 16. Propriétés ACID vs Théorème CAP Availability Partition tolerance Consistency CA AP CP Big Data Atomicité Cohérence Isolation Durabilité BD relationnelle 4 / 4 2 / 3
  17. 17. Les plus connues Availability Partition tolerance Consistency CA AP CP http://nosql-database.org/
  18. 18. Modèle orienté Objet Ce modèle permet de stocker des objets, avec leurs attributs, leurs relations d'héritage et leurs références vers d'autres objets, de manière persistante. Certains systèmes permettent même d'exécuter les méthodes des objets directement dans la base de données. Ce modèle est, en pratique, plutôt proche du modèle relationnel et n'est pas exclusif aux Big Data. D'ailleurs, certaines SGBDR permettent de choisir entre relationnel et orienté objet.
  19. 19. Modèle orienté Objet relationnel orienté Objet
  20. 20. Modèle orienté Clé-Valeur Ce modèle est une simple correspondance entre une clé et une valeur, comme une table de hachage à la différence qu'en Big Data, le stockage se fait sur un réseau distribué. Il est essentiellement utilisé en tant que cache, pour stocker des données semi-persistantes qui ne doivent être conservées qu'un temps donné.
  21. 21. Modèle orienté Colonne Il s'agit d'un modèle structuré où l'équivalent de plusieurs tables d'une base de données relationnelle est réuni dans une seule grande table sous forme de colonnes, éliminant ainsi les jointures. Ce modèle permet d'enregistrer des volumes très importants de données simples, généralement sur des clusters de quelques dizaines à quelques centaines de serveurs, souvent répartis sur plusieurs datacentres. Il est donc destiné pour de très gros stockages comme Google ou Facebook.
  22. 22. Modèle orienté Document Une clé primaire est associée à une structure de plusieurs valeurs de types différents, appelée document. Chaque clé peut être associée à une structure différente. Les données sont alors organisées dans des fichiers au format XML ou JSON. Ce modèle est utile pour le stockage de données hétérogènes. document type A type B type A
  23. 23. Modèle orienté Graphe Ces systèmes sont prévus pour stocker des graphes (au sens de la théorie des graphes), avec des nœuds comportant des attributs et des liens entre les différents nœuds. L'exemple type est le stockage d'un réseau social où il est possible de parcourir les relations entre utilisateurs. A BC D FlockDB
  24. 24. HADOOP
  25. 25. Historique En 2004, Google publie un article de recherche présentant son nouvel algorithme MapReduce, conçu pour réaliser des opérations analytiques à grande échelle sur un grand cluster de serveurs via son système de fichier Google Filesystem (GFS). Doug Cutting, qui travaillait alors sur le développement du moteur de recherche libre Apache Lucene, s’est alors emparé des concepts décrits dans l’article et a décidé de répliquer les outils développés par Google en version open source, ce qui est devenu le projet Hadoop en 2006. Hadoop est le nom de l’éléphant qui servait de doudou à son fils. J. Dean, S. Ghemawat (Google Inc.) - 2004 "MapReduce : Simplified data processing on large clusters" Sixth Symposium on Operating System Design and Implementation - San Francisco, CA
  26. 26. MapReduce Utilisé pour réduire les temps de lecture dans une base de données distribuée, cet algorithme repose sur la parallélisation du travail de recherche à travers plusieurs serveurs via deux fonctions principales : Map et Reduce, qui sont des méthodes bloquantes (bloquent le processus tant que leur exécution n'est pas terminée). La recherche est en fait coupée en morceaux répartis sur plusieurs serveurs qui travaillent en même temps. Le résultat final est donc obtenu plus rapidement ; et plus il y a de serveurs, plus le résultat est rapide. Bien qu'Hadoop soit sa première implémentation, le MapReduce est aujourd'hui utilisé dans de nombreux autres frameworks.
  27. 27. MapReduce Architecture Son organisation s'appuie sur un système de serveurs maître-esclaves. Ainsi, lors d'une requête, le serveur-maître, appelé JobTracker, procède à l'analyse de toutes les données de la base et les scinde en plus petits blocs de données (= splitting) pour les répartir à plusieurs serveurs-esclaves, appelés TaskTrackers. Par défaut, la taille des blocs distribués est de 64 Mo. Un serveur-maître secondaire sert de secours en cas de défaillance du serveur-maître principal. Le JobTracker y réalise alors régulièrement des copies des blocks et de leur attribution aux différents Tasktrackers.
  28. 28. MapReduce Architecture Le temps de réponse des TaskTrackers donne le Ration Performance (RP) collecté par le JobTracker. Ce ratio est important en milieu distribué hétérogène. Il permet au JobTracker d'adapter la quantité de blocs de données fournie à un TaskTracker. Ainsi sur les machines performantes travailleront plus que les machines moins performantes, car dès qu'un bloc a fini d'être analysé, le JobTracker en fournit un nouveau. Le JobTracker réalise en continu une mesure des RP des chaque serveurs-esclaves. Dès que le RP d'un TaskTracker baisse, sa charge de travail est allégée et répartie sur des TaskTrackers plus performants jusqu'à ce que son RP retrouve sa valeur normale. Le JobTracker peut ainsi remplacer un serveur-esclave défaillant par un autre en assignant à ce dernier le bloc de données qui n'a pas retourné de résultat, donc celui du TaskTracker défaillant.
  29. 29. MapReduce Architecture 2 modes de lecture peuvent être utilisés pour lire les données stockées dans la base : - mode direct où les données sont directement lues depuis le disque local, avec transfert depuis la mémoire cache vers la mémoire du lecteur en utilisant l'accès direct à la mémoire ; - mode streaming où le lecteur lit les données depuis un autre processus en cours d'exécution à l'aide de moyen de communication comme TCP/IP ou JDBC. D'après certains tests, la différence de performance entre ces deux modes est faible (10%). http://fr.wikipedia.org/wiki/MapReduce
  30. 30. copie des blocs de données et de leur attribution JobTracker (serveur-maître) TaskTracker (serveur esclave) serveur-maître secondaire parsing (Map) en direct en streaming splitting (Map) 64 Mo RESULTAT DATA MapReduce Architecture
  31. 31. MapReduce Principe La fonction Map commence par un décodage des blocs de données reçus. C'est le parsing, qui peut être alors de deux types : - décodage immuable : n données instancient n objets de programmation (donc 1 objet/donnée). Ces objets sont non modifiables, donc immuables. - décodage mutable : n données instancient 1 seul objet qui est réutilisé pour toutes les instanciations. Il s'agit donc d'un objet mutable. Le décodage immuable est plus lent que le décodage mutable car il produit un grand nombre d'objets immuables durant le processus de décodage. La création de tous ces objets augmentent la charge de travail des processeurs. Jiang D, Ooi BC, Shi L, Wu S - 2010 - "The performance of MapReduce : an in-depth study" Proceedings of the VLDB Endowment 3 (1-2), 472-483
  32. 32. MapReduce Principe Les données décodées sont réorganisées en couples clé-valeur (= shuffle). Ces couples sont ensuite triés selon leur clé (= sort). Le résultat de la fonction Map donne donc un regroupement de plusieurs valeurs pour une même clé. La fonction Reduce compressent ces groupes clé-valeurs de sorte qu'une clé soit de nouveau associée à une seule valeur. Cette compression est alors renvoyée au JobTracker en guise de résultat qui centralise tous les résultats des différents bloc pour constituer la réponse à la requête.
  33. 33. MapReduce Principe Data Splitting Shuffle Sort Reduce Result Map http://blog.inovia-conseil.fr/?p=46
  34. 34. MapReduce Configuration MapReduce est configurable presque à tous les niveaux : - choix du JobTracker, des TaskTrackers et du serveur-maître secondaire - mode de parsing - taille des blocks lors du splitting (64 Mo par défaut) - espace mémoire utilisé pour fonctionner - fonctions map et reduce http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client- core/MapReduceTutorial.html http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client- core/MapredCommands.html
  35. 35. Architecture Hadoop Hadoop est un framework développé en Java. Son HDFS (Hadoop File System) est un système de fichiers en cluster conçu pour stocker de très gros volumes de données sur un grand nombre de machines. On trouve : - un serveur-maître, appelé NameNode, qui enregistre dans un fichier la localisation des données réparties en blocs dans le cluster. Ce fichier de métadonnées a une taille configurée par défaut à 256 Mo. - un serveur-maître secondaire, qui gère l'historique des modifications faites dans le fichier de métadonnées (WAL : Write Ahead Log). Ce NameNode secondaire permet la continuité du fonctionnement du cluster Hadoop en cas de panne du NameNode principal. - des serveurs-esclaves, appelés DataNodes, qui stockent les données scindées en petits blocs de 64 Mo par défaut. Ces blocs sont des fichiers de données stockées en bytes, appelés DataFiles.
  36. 36. Architecture Hadoop L'HDFS est conçu pour assurer la sauvegarde des données en répliquant l’ensemble des données écrites sur le cluster. Par défaut, chaque donnée est écrite sur 3 DataNodes différents. Hadoop peut être lancé selon 3 modes : - mode standalone, pour tourner sur un seul serveur - mode pseudo-distribué où le principe HDFS est contenu sur une seule machine et donne l'illusion d'un mode distribué - mode distribué, où l'HDFS est réparti sur un réel cluster physique.
  37. 37. Architecture Hadoop NameNode (serveur maître) NameNode secondaire Metadonnées 256 Mo max par défaut WAL archivage de l'historique DataFiles 64 Mo max par défaut 3 réplications des données par défaut DataNode (serveur esclave) HDFS Hadoop File System
  38. 38. Configuration Hadoop Hadoop est conçu pour des serveurs Linux. Pour des tests, il est possible d'utiliser Windows avec Cygwin. http://ebiquity.umbc.edu/Tutorials/Hadoop/00%20-%20Intro.html Hadoop est configurable pour : - le choix du NameNode et de son serveur-maître secondaire - la quantité et le choix des DataNodes - la taille des DataFiles - la taille du fichier de métadonnées dans le NameNode - le nombre de réplication par serveur-esclave
  39. 39. Configuration Hadoop configuration du cluster variables d'environnement configuration des fichiers http://hadoop.apache.org/docs/r1.1.2/cluster_setup.html configuration du MapReduce identification des NameNodes identification des DataNodes https://hadoop.apache.org/docs/r2.5.1/hadoop-project-dist/hadoop-hdfs/hdfs-default.xml http://hadoop.apache.org/docs/r1.1.1/mapred-default.html
  40. 40. HBASE
  41. 41. Historique - 2004 - Google publie le MapReduce (algorithme pour les sytèmes distribués) - 2006 - Doug Cutting crée Hadoop (framework de stockage en cluster) - 2006 - Google utilise Hadoop pour créer BigTable (SGBD BigData propriétaire) - 2007 - création de HBase (= BigTable en version open source) par Powerset qui contribue au developpement de Hadoop F. Chang, R.E. Gruber et al. (Google Inc.) - 2006 "Bigtable: A Distributed Storage System for Structured Data" Seventh Symposium on Operating System Design and Implementation - Seattle, WA
  42. 42. Historique - 2008 - Powerset se fait racheter par Microsoft qui abandonne le développement de HBase (car open source) - 2008 - Hadoop devient le projet principal de la fondation Apache - 2010 - HBase devient le projet principal de la fondation Apache L. George - 2011 "HBase the Definitive Guide" - O'Reilly
  43. 43. Architecture HBase est un système de gestion des données pour un environnement distribué qui doit être couplé au gestionnaire de fichiers Hadoop. Hbase gère la partie logique, tandis qu'Hadoop gère la partie physique. C'est un modèle de stockage BigData orienté colonne, basé sur le principe de BigTable de Google.
  44. 44. Architecture Aspect logique Les données sont gérées au sein de grandes tables (appelées HTable) composées de lignes (nommées row) et de familles de colonnes (family). Les familles de colonnes sont sous-divisées en colonnes (qualifier). Les lignes sont des identifiants dont la valeur est unique, soit l'équivalent de la clé primaire dans le mode relationnel. Comparaison avec un SGBDR : HTable => ensemble de toutes les tables de la base family => une table qualifier => un attribut row => clé primaire Du fait que toutes les données sont logiquement placées dans la même table, les jointures sont inutiles. http://hbase.apache.org/book.html#datamodel
  45. 45. Architecture Aspect logique Les données (dites value) sont stockées pour une ligne et une colonne précises. Mais plusieurs écritures peuvent être effectuées pour un même emplacement. On parle alors de version de données à des temps différents (timestamp). Par défaut, le timestamp est configuré à 3 versions. Il peut être modifiable, mais il est déconseillé d'enregistrer au-delà de 100 versions. L'ensemble des informations (ou coordonnées) d'une donnée est appelée keyValue et correspond donc à : KeyValue = row + family + qualifier + timestamp + value Les données sont toujours enregistrées sous la forme de keyValue, donc avec leurs coordonnées complètes.
  46. 46. Architecture Aspect logique
  47. 47. Configuration Peuvent être configurés : - les rôles des serveurs (master, slaves) - le zookeeper (nb d'instances, temps de session) - le memstore - la compression des storefiles ... http://hbase.apache.org/book.html#important_configurations
  48. 48. Architecture Aspect physique HBase est basé sur la même architecture physique qu'Hadoop puisque ce dernier gère le stockage physique. On retrouve donc une configuration distribuée en cluster de plusieurs nœuds qui peuvent être hétérogènes au niveau hardware. Le principe est donc le même que celui d'Hadoop. Seuls les noms diffèrent. Ainsi : Architecture HADOOP HBASE serveur-maître namenode regionserver serveur-esclave datanode region fichier de stockage datafile storefile
  49. 49. Architecture Aspect physique Avant d'être stockées à travers le cluster, les données à stocker transitent par un framework fourni avec HBase : le zookeeper. Il coordonne la destination d'archivage des données dans un système distribué. Ces données sont ensuite réparties sur les différents serveurs (Region) du cluster, où elles sont triées et compactées par le memstore de HBase. Pour une meilleure gestion de l'espace mémoire, les données sont toujours sauvegardées sous forme de bytes. Elles sont stockées dans les regionservers sous forme de blocs de données (les storefiles) d'une taille configurée par défaut de 64 Mo (configuration faite via Hadoop).
  50. 50. Architecture Aspect physique La répartition des données sur les regionserveurs se fait en 2 étapes : - les lignes d'une HTable sont scindées en paquets réguliers par le regionserveur, - chaque paquet est dirigé chacun vers un serveur-esclave où il est de nouveau divisé par le memstore selon les colonnes de la HTable. Les données issues de la même famille de colonne sont alors stockées dans un même storefile (ou datafile pour Hadoop) dans la limite de taille configurée (64 Mo par défaut selon Hadoop). Si la taille d'un paquet produit par le memstore venait à avoir une taille trop importante, le dépassement formerait un nouveau storefile. De même, si un datanode venait à être surchargé, il serait également redivisé à travers d'autres datanodes afin de répartir la charge.
  51. 51. Architecture Aspect physique
  52. 52. Design Eléments critiques Les performances de HBase sont plutôt tournées sur la lecture des données, via le MapReduce et la dénormalisation. D'après la façon de HBase de stocker les données, 2 éléments influent sur la vitesse de lecture : - choix des colonnes : si une requête trouve son résultat dans 2 colonnes issues de 2 familles différentes, la recherche se fera sur 2 storefiles différents, augmentant ainsi le temps de lecture. - choix des lignes : les noms des lignes représentant la clé primaire, leur choix doit être le plus judicieux possible pour un accès rapide aux données selon les requêtes estimées. exemple : temps de lecture différent selon une row structurée nom+date ou date+nom http://hbase.apache.org/book.html#schema
  53. 53. Design Colonnes Les données sont enregistrées par leur keyValue, donc avec toutes leurs coordonnées. De ce fait pour toutes les valeurs d'une même ligne, le nom des families, qui représente le nom du fichier HDFS au format string, et celui des qualifiers, stocké en bytes[ ] dans le fichier, seront systématiquement répétés. Pour optimiser la place mémoire, il est donc recommandé d'employer des noms de familles de colonnes les plus petits possible (donc en un seul caractère) et de rentabiliser ceux des colonnes en les utilisant comme un complément d'information. Exemple : ligne (ou row) = date arrondie à l'heure familles de colonnes = t (température d'un composant), e (état activé ou non du composant) colonne (ou qualifier) = temps en minutes N. Dimiduk, A. Khurana- 2012 "HBase in action" - Manning
  54. 54. Design Colonnes Le nombre de colonnes (qualifiers) peut être considéré comme illimité, bien qu'il soit plus ou moins lié à la taille des fichiers HDFS. Mais il n'est pas conseillé de créer trop de familles de colonnes : HBase a du mal à gérer plus de 3 families pour une même table. http://hbase.apache.org/book/book.html
  55. 55. Design Lignes (= clé primaire) Les enregistrements des lignes dans les fichiers HDFS se font de manière séquentielle. Il faut donc penser à ce qu'ils produisent un stockage ordonné. Par exemple, un tri sur le nom des lignes par ordre alphabétique après stockage n'est pas possible. Il faut aussi tenir compte de la répartition des lignes dans l'HDFS. Hadoop stockant des blocs de lignes sur un même DataNode, il peut être intéressant de regrouper les données selon certaines requêtes et donc choisir des noms de lignes en conséquence. Enfin, comme pour les colonnes, les rows sont répétées dans la keyValue de chaque donnée. Elles doivent donc être utilisées comme un moyen supplémentaire de stocker de l'information.
  56. 56. Communication HBase est écrit en Java. Il y a donc une API Java. Mais d'autres moyens de communication avec cet outil ont été mis en place : - HBase shell - Hive - Pig - API JRuby - API Cascading
  57. 57. Communication Hive Initialement développé par Facebook, Hive est aujourd'hui un projet open source Apache qui offre un langage similaire au SQL, le HiveQL, pour effectuer des requêtes au sein d'un système distribué. Hive emploie un gestionnaire de stockage qui peut donc intervenir sur les données stockées dans le HDFS, mais également dans d'autres sources. De ce fait il est capable d'effectuer des travaux de MapReduce. Ainsi Hive permet aux utilisateurs peu à l'aise avec la manipulation du MapReduce de pouvoir tout de même utiliser ce modèle de recherche au travers de requêtes pseudo-SQL. Depuis la version 0.6.0, Hive est également livré avec un gestionnaire pour HBase. Il est alors possible de définir des HiveTables dans le langage HiveQL qui seront fidèlement converties en HTables.
  58. 58. Communication Pig Développé au départ par Yahoo, Pig est devenu lui aussi un projet Apache. Il est employé pour analyser les données d'une Big Data à travers le langage de requêtes Pig Latin. Comme Hive, il cache l'éventuelle complexité du modèle MapReduce derrière un langage de haut-niveau plus intuitif pour l'utilisateur. Le Pig Latin est en effet un langage de programmation orienté flux de données qui permet de représenter les résultats sous forme de graphes, mettant alors en évidence un certain nombre de propriétés comme le parallélisme disponible ou la localité des données. Ce langage est donc l'un des avantages principal de Pig. Un autre avantage est l'optimisation des tâches que cet outil propose en automatisant leur exécution. Enfin, les utilisateurs peuvent créer leurs propres fonctions pour gérer un traitement de données particulier.
  59. 59. Communication HBase Shell C'est l'interface système (shell) qui permet d'administrer la base. Elle est activée par la commande hbase shell et quittée par la commande exit. Ce shell est basé sur JRuby qui est une implémentation du langage Ruby en Java. Il utilise donc le shell Ruby, IRB (Interactive Ruby Shell), auquel sont ajoutées des commandes spécifiques basées sur l'API Java.
  60. 60. HBase Shell Commandes principales créer une table T avec ses familles de colonnes F1 et F2 create 'T', 'F1', 'F2' déverrouiller une table disable 'T' , déverrouiller toutes les tables  disable_all '*.*' ajouter une famille de colonnes à une table alter 'T', NAME =>'F3' reverrouiller une table  enable 'T' ajouter ou remplacer une valeur à certaines coordonnées  put 'T', 'R1', 'F1:C1', 'V1' savoir si une table existe  exist 'T' compter le nombre de valeurs dans des colonnes  count 'T', {COLUMNS => [F1:C2, F1:C3]}
  61. 61. HBase Shell Commandes principales lister toutes les tables  list décrire une table  describe 'T' lire toutes les lignes d'une table  scan 'T' lire des familles de colonnes  scan 'T', {COLUMNS => ['F1', 'F2']} lire des colonnes  scan 'T', { COLUMNS => [F1:C3', F2:C1']} lire des colonnes au départ d'une ligne précise  scan 'T', { COLUMNS => [F1:C3', F2:C1'], STARTROW => 'R2'} lire des colonnes jusqu'à une ligne précise  scan 'T', { COLUMNS => [F1:C3', F2:C1'], STOPROW => 'R6'}
  62. 62. HBase Shell Commandes principales lire une ligne avec toutes ses valeurs  get 'T', 'R3' lire les valeurs d'une ligne et d'une famille de colonnes  get 'T', 'R2', 'F1' lire les valeurs d'une ligne et d'une colonne  get 'T', 'R1', 'F2:C3' vider une table  truncate 'T' supprimer une table  drop 'T' supprimer une famille de colonnes  alter 'T', delete => 'F1' supprimer une ligne entière  deleteall 'T', 'R1' supprimer une valeur via ses coordonnées  delete 'T', 'R1', 'F1:C2'

×