Tutoriel pour apprendre à travailler avec HBase

Avant de donner la définition d'HBase, commençons par dire ce qu'il n'est pas : HBase n'est pas un SGBD au sens strict du terme. Il n'implémente pas un schéma de base de données modélisée à l'aide d'un MCD, et ne fournit pas les fonctionnalités de gestion de ce schéma telles que le typage des données, les mécanismes de clés primaires, les clés étrangères, d'index, le langage d'interrogation de données, ou encore la gestion des transactions. À la place de "système de gestion de base de données", HBase est plus ce que l'on pourrait qualifier d'"entrepôt de stockage de données". Là où les SGBD assurent à la fois le stockage et le traitement des données, HBase lui, est plus spécialisé sur le stockage de celles-ci. Il utilise des modèles de calcul externe pour leur requêtage. HBase est un SGBD distribué, orienté colonne qui fournit l'accès en temps réel, aussi bien en lecture qu'en écriture, aux données stockées sur le HDFS. Là où le HDFS fournit un accès séquentiel aux données en batch, non approprié pour des problématiques d'accès rapide à la donnée comme le Streaming, HBase couvre ces lacunes et offre un accès rapide aux données stockées sur le HDFS. Il faut comprendre par là que HBase est perçu par le HDFS comme un client à qui il fournit les données. HBase a été conçu pour :

• ne fonctionner que sur un cluster Hadoop ;
• être linéairement scalable, c'est-à-dire que supporte l'ajout de nœuds au cluster ;
• stocker de très grosses volumétries de données épaves, c'est-à-dire des données à structure irrégulière, avec plein de valeurs nulles comme les matrices creuses en algèbre. Nous y reviendrons plus bas ;
• fournir un accès en temps réel à cette grosse volumétrie de données aussi bien pour les opérations de lecture que d'écriture sur le HDFS ;
• s'appuyer sur des modèles de calculs distribués tels que le MapReduce (et donc tous ses langages d'abstraction tels que Hive, Pig, Cascading…) pour l'exploitation de ses données.

En réalité, HBase est l'implémentation Hadoop du projet Google Big Table. Big Table est le premier SGBD distribué développé par Google qui s'appuie sur le GFS (Google File System) dont le HDFS est l'implémentation.

La particularité de HBase est qu'il n'implémente pas de concept de « base de données ». Par conséquent la manière dont on concevait les bases de données dans les approches traditionnelles ne peut pas être utilisée avec les approches NoSQL en général et avec HBase en particulier. Nous insistons là-dessus parce que dans notre travail professionnel quotidien, nous avons vu beaucoup d'entreprises commencer leur projet de migration vers HBase avec la conception d'un MCD. Ceci vient sûrement du fait que dans le passé, et jusqu'à présent, lorsqu'on veut concevoir une base de données, on commence par concevoir un MCD, qui sera par la suite transformé en un modèle relationnel (MRD) et finalement en script SQL, qui sera exécuté par le moteur du SGBDR. Si vous exercez le métier de consultant, d'ingénieur, d'analyseur de base de données ou tout autre profession relative à la construction des bases de données, ou si vous êtes étudiants, alors il y a de fortes chances que vous ayez été formés à débuter la création d'une base de données par un MCD. Cette façon de faire est devenu normale, voire même de l'ordre du réflexe. Mais avec le NoSQL en général et HBase en particulier, tout change : premièrement le concept de base de données n'est pas le même que dans les SGBDR, en plus il varie selon les catégories de SGBD NoSQL, et deuxièmement vous ne commencez pas la conception de votre « base de données » par un MCD. Nous allons voir plus bas comment modéliser une base de données en HBase. Pour l'heure, vous devez garder à l'esprit que dans le NoSQL, le schéma de « base de données » que vous allez concevoir a pour but d'assurer la distribution du stockage et faciliter l'accès des données dans un cluster pour les traitements parallèles. Gardez bien cela à l'esprit !

Le concept de base de données en HBase est la table HBase. En d'autres termes, développer et modéliser une base de données en HBase revient à implémenter une ou plusieurs tables HBase. Une table HBase est un tableau multidimensionnel de données distribué et persisté sur le HDFS sous forme de fichiers spécifiques appelés HFiles. Voici les dimensions qui forment ce tableau multidimensionnel :

• la première dimension c'est la "row key" (clé de ligne). Chaque ligne du tableau HBase est identifiée de façon unique par une clé "row key". Attention, bien que similaire à une clé primaire dans une table relationnelle, la différence ici est que la row key n'est pas nécessairement une colonne parmi l'ensemble des colonnes désignées comme telles par le développeur, c'est une colonne interne à la structure de la table HBase, similaire à la colonne de numéros qui identifient chaque ligne d'une feuille de calcul Excel. Par contre, vous avez la responsabilité de définir, non pas la colonne qui va servir de row key, mais la structure des données qui vont y être générées. Nous allons vous montrer comment faire plus bas ;
• la deuxième dimension est la famille de colonne (column family), d'où HBase tire son nom de SGBD orienté colonne. Les familles de colonnes représentent les valeurs d'un ensemble de colonnes physiquement colocataires, c'est-à-dire physiquement sérialisées (stockées) dans le même ficher. Chaque famille de colonnes est persistée dans un HFile séparé, et chaque HFile possède son propre jeu de paramètres de configuration. Cette dimension est très importante, car elle définit la façon dont les données sont persistées et accédées. À cet effet, lors de la modélisation de la table HBase, vous veillerez particulièrement à placer les colonnes les plus utilisées dans la même famille de colonnes. Petite remarque, les colonnes qui constituent une famille de colonnes n'entretiennent pas de lien particulier, elles sont indépendantes et c'est vous qui décidez des critères sur lesquels vous allez les regrouper. De plus, il n'y a théoriquement pas de limites au nombre de familles de colonnes qui peuvent être créées et au nombre de colonnes dans chaque famille. Une fois encore, tout dépend des besoins du client, de vous le créateur de la table HBase et de la capacité du cluster ;

• la troisième dimension est la colonne (column qualifier). Une colonne c'est l'adresse d'une série de données dans une famille de colonnes. Vous pouvez voir les colonnes HBase comme les colonnes d'un tableau ou comme celles d'une feuille de calcul Excel. Ils désignent simplement les données des lignes de la même adresse dans une famille de colonnes. Cette adresse porte un label et c'est ce label que l'on qualifie de colonne ou de qualificateur de colonne. Les colonnes sont dynamiques et peuvent être différentes d'une ligne à une autre, en d'autres termes, des valeurs peuvent être manquantes pour la ligne d'une colonne (NULL dans les bases de données traditionnelles), auquel cas la colonne n'est pas créée pour la ligne en question. C'est cette propriété (le dynamisme des colonnes) qui lui permette de stocker des données éparses :

  À la différence des colonnes, les familles de colonnes elles, sont statiques, c'est-à-dire définies à la création de la table et fixes tout au long de leur vie, là où les colonnes elles sont dynamiques, c'est-à-dire ne sont pas définies lors de la création de la table, mais sont dynamiquement créées lors des opérations d'écriture/mise à jour de la donnée dans la colonne de la ligne. Ainsi, HBase traite les colonnes comme une table dynamique de paires de clé/valeur. Comme résultat, chaque ligne/famille de colonnes peut contenir des jeux arbitraires de colonnes. La figure ci-après illustre la propriété dynamique des colonnes.

  Figure 1 : cette figure illustre le dynamisme des colonnes dans HBase. Les colonnes sont créées à l'ajout de données dans la table. Attention, notez que l'absence d'une valeur dans une colonne ne signifie pas qu'elle est nulle. Cela signifie qu'elle n'existe pas pour ce TimeStamp. C'est cette caractéristique qui permet à HBase de gérer les données épaves.

• la quatrième dimension c'est la cellule (cell) ou valeur (pour faire référence au contenu de la cellule). Une cellule HBase est l'intersection entre une row key, une famille de colonnes et une colonne. Les données sont stockées dans les cellules. Attention ! À la différence des cellules dans le sens Excel du terme, les cellules HBase ne stockent pas uniquement les données textuelles ou des nombres. Vous pouvez stocker dans chaque cellule, un PDF, une vidéo, une image, un texte, bref n'importe quel type de données numériques. Elles y sont stockées sous forme de type générique Byte[](1), ainsi, vous n'avez pas à typer les colonnes en HBase. Dans la figure 33 ci-dessus, vous pouvez voir chaque cellule Hbase ;

• la dernière dimension est le TimeStamp. Il faut savoir qu'HBase ne fait pas de différence entre les ajouts de lignes dans la table (opération d'écriture) et leur mise à jour (opération de modification d'une ligne). Tout comme dans le HDFS et dans un Data Warehouse, chaque opération de mise à jour est un ajout d'une nouvelle version de la même ligne de données. La distinction de versions d'une même ligne se fait à l'aide d'une valeur horodatée appelée TimeStamp. Ce TimeStamp c'est la date et l'heure, à la milliseconde près, auquelles la mise à jour a été effectuée. Pour les habitués de la modélisation des Data Warehouse, le TimeStamp correspond à une dimension SCD (Slowly Changing Dimension). Par défaut, HBase stocke les trois dernières versions d'une valeur de colonne (tout en supprimant automatiquement les anciennes versions). La profondeur(2) du "Versioning" peut être contrôlée lors de la création de la table.

La figure suivante illustre le tableau multidimensionnel qui forme la structure logique d'une table HBase.

La représentation hiérarchique de la structure de la table HBase suivante va vous permettre de garder à l'esprit les liens qui existent entre ces différentes dimensions :

Soit la table HBase suivante :

Dans cette table, la Row Key est une colonne triée qui identifie de façon unique chaque « ligne ». La colonne TimeStamp contient des valeurs horodatées qui indiquent les dates auxquelles chaque cellule a été créée. Personnel et Contact sont les familles de colonnes et possèdent respectivement les colonnes Prénom et Âge pour Personnel, et téléphone et ville pour Contact. Ces deux familles de colonnes signifient simplement que les colonnes de données Prénom et Âge seront sérialisées et persistées sur le même fichier HFile et les colonnes sur le HDFS, téléphone et ville seront sérialisées et persistées sur le même fichier HFile également. Les cellules sont les intersections entre « row key, TimeStamp,  famille de colonnes et colonne ». Par exemple, la cellule à l'intersection « 00003, 10/09/2011 13:10:05:09, Infos_Contact, ville » contient la valeur « Marseille ». Remarquez que l'horodatage permet d'enregistrer plusieurs versions de la même cellule. Remarquez aussi que les trois lignes à l'intérieur de la Row Key 00001 sont des versions de la même ligne ; en effet ces trois lignes représentent le changement d'âge et de ville du contact « Juvenal ». Au lieu de mettre à jour la ligne de row key 00001, et perdre l'historique des états du contact, comme cela aurait été le cas dans un SGBDR de type Oracle ou MySQL, HBase permet de conserver l'historique du contact à l'aide du TimeStamp. À défaut de la représentation précédente, la représentation plate suivante, plus simple est souvent adoptée pour les tables HBase :

En dehors de la représentation tabulaire, la table HBase peut se représenter sous forme de schéma multidimensionnel. Celui-ci est la représentation favorite des développeurs, nous allons expliquer plus bas pourquoi. La représentation d'une table HBase sous un schéma multidimensionnel suit la spécification JSON suivante :

{
"Row Key 1":
{
    "column family 1":
        {
            "Column 1":
                {
                    "TimeStamp 1": "Cell value",
                        ..................
                    "TimeStamp N": "Cell value",
                }        
            ..............
            "Column N":
                {
                    "TimeStamp 1": "Cell value",
                        ..................
                    "TimeStamp N": "Cell value",
                }                                    
            }
    ....................
    "column family N":
        {
            "Column 1":
                {
                    "TimeStamp 1": "Cell value",
                        ..................
                    "TimeStamp N": "Cell value",
                }
            ..............
            "Column N":
                {
                    "TimeStamp 1": "Cell value",
                        ..................
                    "TimeStamp N": "Cell value",
                }                                    
            }
    }
    ...............................
"Row Key N":
    {
         "Column family 1":
           {
            "Column 1":
                {
                    "TimeStamp 1": "Cell value",
                        ..................
                    "TimeStamp N": "Cell value",
                }            
                ..............
            "Column N":
                {
                    "TimeStamp 1": "Cell value",
                        ..................
                    "TimeStamp N": "Cell value",
                }                                    
           }
        ....................
        "Column family N":
             {
              "Column 1":
                {
                    "TimeStamp 1": "Cell value",
                        ..................
                    "TimeStamp N": "Cell value",
                }    
                ..............
              "Column N":
                {
                    "TimeStamp 1": "Cell value",
                        ..................
                    "TimeStamp N": "Cell value",
                }                            
             }        
     }
}

La représentation sous forme de schéma multidimensionnel de la table HBase de notre exemple, donne ceci :

{
"00001":
{
    "Personnel":
        {
            "Prénom":
                {
                    "10/09/2011 13:05:17:09": "Juvénal"
                }        
        
               "Âge":
                {
                    "10/09/2011 13:05:17:09": "22",
                    "20/09/2013 15:00:05:09": "25"
                }                                    
         }
    
      "Contact":
        {
             "Téléphone":
                {
"10/09/2011 13:05:17:09": "06 90 98 76 52"
                }

            "ville d'habitation":
                {
                    "10/09/2011 13:05:17:09": "Douala",
                    "20/09/2013 15:00:05:09": "Lille",
                    "30/10/2016 16:18:50:10": "Paris"
                }                                    
            }
"00002":
{
    "Personnel":
        {
            "Prénom":
                {
                    "10/09/2011 13:10:05:09": "Paul"
                }        
        
               "Âge":
                {
                    "10/09/2011 13:10:05:09": "30"
                }                                    
         }
    
      "Contact":
        {
             "Téléphone":
                {
"10/09/2011 13:10:05:09": "07 90 94 86 52"
                }

              "ville d'habitation":
                {
                    "10/09/2011 13:10:05:09": "Nancy",
                }                                    
        }
  }

"00003":
{
    "Personnel":
        {
            "Prénom":
                {
                    "12/09/2011 11:30:20:09": "Jean"
                }        
        
               "Âge":
                {
                    "12/09/2011 11:30:20:09": "34"
                }                                    
         }
    
      "Contact":
        {
             "Téléphone":
                {
"12/09/2011 11:30:20:09": "06 74 98 76 25"
                }

              "ville d'habitation":
                {
                    "12/09/2011 11:30:20:09": "Marseille",
                }                                    
        }
  }
}

La représentation sous forme multidimensionnelle permet aux développeurs en fonction de leur langage de programmation, de manipuler la table HBase comme une table de hachage (Ruby), un tableau associatif (PHP), un dictionnaire (Python) ou un objet (Java) qui expose des méthodes via une API. En dehors de la représentation multidimensionnelle, une table HBase peut aussi se représenter sous forme de paires de clés/valeurs. Pour représenter la table sous forme de clé/valeur, vous pouvez utiliser la syntaxe suivante :

{
    "Row Key 1" -> 
         {"column family 1": {"Column 1": {"TimeStamp 1": "Cell value", "TimeStamp N": "Cell value"}},
                           {"Column N": {"TimeStamp 1": "Cell value", "TimeStamp N": "Cell value"}},
        "Column family N": {"Column 1": {"TimeStamp 1": "Cell value", "TimeStamp N": "Cell value"}},                          {"Column N": {"TimeStamp 1": "Cell value", "TimeStamp N": "Cell value"}      }, 

    "Row Key N" -> 
         {"column family 1": {"Column 1": {"TimeStamp 1": "Cell value", "TimeStamp N": "Cell value"}},
                           {"Column N": {"TimeStamp 1": "Cell value", "TimeStamp N": "Cell value"}},
        "Column family N": {"Column 1": {"TimeStamp 1": "Cell value", "TimeStamp N": "Cell value"}},                          {"Column N": {"TimeStamp 1": "Cell value", "TimeStamp N": "Cell value"}      }
}

La représentation de la table HBase de notre exemple en paires de clés/valeurs donne ceci :

{
    "00001" -> 
         {"Personnel": {"Prénom": {"10/09/2011 13:05:17:09": "Juvénal"}},
                      {"Âge": {"10/09/2011 13:05:17:09": "22", "20/09/2013 15:00:05:09": "25"}},
           "Contact": {"Téléphone": {"10/09/2011 13:05:17:09": "06 90 98 76 52"}}, 
                    {"ville d'habitation": {"10/09/2011 13:05:17:09": "Douala", "20/09/2013     15:00:05:09": "Lille", "30/10/2016 16:18:50:10": "Paris"}}

      }, 

    "00002" -> 
         {"Personnel": {"Prénom": {"10/09/2011 13:10:05:09": "Paul"}},
                      {"Âge": {"10/09/2011 13:10:05:09": "30"}},
           "Contact": {"Téléphone": {"10/09/2011 13:10:05:09": "07 90 94 86 52"}}, 
                    {"ville d'habitation": {"10/09/2011 13:10:05:09": "Nancy" }}
      }, 
        
"00003" -> 
         {"Personnel": {"Prénom": {"12/09/2011 11:30:20:09": "Jean"}},
                      {"Âge": {"12/09/2011 11:30:20:09": "34"}},
       "Contact": {"Téléphone": {"12/09/2011 11:30:20:09": "06 74 98 76 25"}}, 
                    {"ville d'habitation": {"12/09/2011 11:30:20:09": "Marseille"}}
      }
}

La connaissance de ces différentes représentations est très importante dans la modélisation de la table HBase. Au même titre que le MCD (Modèle Conceptuel de Données), elles servent d'outil de communication entre les utilisateurs métiers et les développeurs. Généralement la forme tabulaire est très expressive pour les utilisateurs métiers, tandis que les deux autres sont très adaptées pour communiquer avec les développeurs. En fait, la forme de représentation est le premier choix que vous devez faire en matière de modélisation HBase. Attention tout de même à ne pas confondre la représentation de la table HBase avec sa structure interne. Par exemple, le fait de représenter une table HBase sous forme de clés/valeurs ne signifie pas qu'HBase fonctionne comme un SGBD clés/valeurs. C'est juste une représentation. Maintenant que vous avez compris les concepts de base de HBase, nous allons vous emmener dans son architecture et son fonctionnement interne.

Tout comme dans l'approche relationnelle, la première étape consiste à modéliser la base de données à travers un MCD, la première étape dans tout projet HBase est la modélisation de la table HBase. Nous allons vous fournir ici les règles de bonnes conception et modélisation d'une table HBase. Comme nous l'avons dit plus haut, la modélisation en HBase consiste à concevoir et implémenter des tables Hbase, dans le but d'y exécuter des requêtes distribuées. La modélisation des bases de données relationnelles se fait à l'aide d'un MCD qui sera transformé en schéma relationnel à l'aide d'un ensemble de règles standardisées appelées Formes Normales (les 12 Formes Normales). Lorsqu'on modélise une base de données relationnelles, le but est de réduire la redondance et d'assurer la cohérence des données. Les Formes Normales assurent que les schémas de base de données qui seront modélisés minimiseront les redondances et maximiseront la cohérence de la base. Dans un environnement distribué, on ne peut pas se permettre de minimiser la redondance des données, puisque c'est la redondance qui est la clé de la haute disponibilité et de la tolérance aux pannes du cluster ; au contraire il faut la maximiser pour assurer une répartition équilibrée des données dans le cluster. Dans un SGBD distribué en général et dans HBase en particulier, le but de la modélisation est d'assurer le partitionnement des données en blocs qui vont être distribués dans le cluster de façon indépendante de manière à garantir l'accès rapide à ces blocs par les requêtes. À la différence des règles de modélisation des Bases de Données Relationnelles qui font l'objet de standards approuvés et validés par des organismes comme l'OMG (Object Management Group)(3), ou l'ISO, les règles de modélisation en environnement distribué, précisément en Hbase, proviennent plus des "Best practices", c'est-à-dire des pratiques éprouvées sur le terrain que de standards. Ces "Best Practices" ne s'appuient pas sur des expérimentations, mais sur les principes du stockage et du traitement de données en environnement distribué.

Préalablement à l'application des règles de modélisation comme les formes normales, le concepteur utilise un ensemble de questions pour le guider dans la conception de sa base de données. Dans le cas d'une base de données relationnelle, ces questions sont les suivantes : quelles sont les tables de notre base de données ? Quelles sont les clés primaires ? Quelles sont les associations qui existent entre les tables ? Ainsi de suite. Idem, préalablement à l'application des "Best practices", vous devez répondre aux questions suivantes pour modéliser une table HBase :

• quelle est la structure des valeurs de la row key ?
• combien de familles de colonnes la table doit-elle avoir ?
• quelles données vont dans quelle famille de colonnes ?
• combien de colonnes y'a t-il dans chaque famille ?
• quel est le label ou titre de chaque colonne ?
• quelles données seront stockées dans les cellules ?
• combien de versions de chaque cellule HBase devra t'il historiser ?

Une fois que vous avez répondu à ces questions, vous pouvez utiliser ce guide de "best practices" pour assurer la modélisation optimale de la ou des tables. Il y en cinq principales.

• Regroupez les colonnes utilisées selon le même schéma dans la même famille de colonnes

Les colonnes appartenant à la même famille de colonnes sont persistées sur le même fichier HFile dans le HDFS. Par conséquent, les colonnes qui sont utilisées suivant un même schéma doivent être regroupées dans la même famille de colonnes. Lorsque nous parlons de colonnes utilisées selon le même schéma, nous faisons référence aux colonnes qui sont utilisées au même moment, ou dont la modification de l'une entraîne la modification de l'autre. Par exemple, supposons que nous avons les colonnes prix total, prix unitaire, quantité, une modification de la colonne prix total passe toujours par une modification de la colonne prix unitaire et quantité. Par conséquent, il serait optimal de regrouper ces trois colonnes dans la même famille de colonnes.

• Essayez autant que faire se peut de limiter à 10 ou 15 le nombre de familles de colonnes par table

À cause du fait que chaque famille de colonne = un fichier HFile différent, lorsque HBase veut lire une ligne de données particulière, il effectue une jointure de tous les HFiles des familles de colonnes avant d'identifier la ligne dans chaque fichier à l'aide de sa row key. Donc plus, il y a de HFiles, plus il faut de temps pour les fusionner afin de lire les données.

• Donnez le nom de toutes les colonnes à la création de la table même si les colonnes elles-mêmes n'existent pas encore

Ces noms seront enregistrés par HBase sous forme de métadonnées. Lorsque les colonnes seront effectivement créées par le développeur, il s'appuiera sur ces métadonnées pour les nommer. De plus, étant donné que ces métadonnées sont stockées dans la table, elles occupent de l'espace disque, par conséquent vous devriez limiter la longueur du nom des colonnes pour gagner en espace disque.

• Privilégiez une structure composite pour les valeurs de la row key

En effet, l'accès aux données de la table HBase se fait par des opérations de lecture/écriture à partir de la row key. Par conséquent, la structure des valeurs de la row key doit s'accommoder à tous les scénarios d'accès à la table envisageables. Une structure composée de plusieurs types de valeurs concaténées est donc la plus appropriée pour couvrir la majorité des cas. Dans tous les cas, évitez le schéma de la clé à valeur auto-incrémentée, type 1, 2, 3… comme c'est souvent le cas dans la modélisation de la clé primaire en base de données relationnelle. Voici trois modèles de clé composite pour la row key : "valeur aléatoire" + valeur auto-incrémentée, utilisation des valeurs d'une colonne particulière comme valeurs de la row key, ou simplement valeurs aléatoires comme valeurs de la row key. Par exemple : foo0001, a-foo1, xhek23eh.

• Dénormalisez au maximum les tables que vous modélisez

En effet, la priorité de Hbase, c'est de distribuer le stockage des données sur les nœuds d'un cluster et d'en faciliter l'accès. Pour une distribution efficace, il faut que les partitions entretiennent le moins de liens possibles. Adoptez donc un esprit de modélisation qui favorise le moins de normalisation possible, c'est-à-dire exactement l'inverse de ce qui se fait en modélisation relationnelle. De plus, la dénormalisation dans un contexte distribué favorise une performance élevée des requêtes.

En utilisant ce guide de questions et de règles, vous développerez des tables qui seront efficacement partitionnées, distribuées dans le cluster et rapide à accéder. Nous allons maintenant passer à la deuxième étape, l'exploitation de la table.

Une fois que la table a été modélisée et implémentée, vous pouvez l'utiliser. Pour interagir avec HBase et effectuer des opérations comme la création de table, la lecture ou l'écriture de données, vous passez par un client HBase. Tout comme Hadoop, HBase a été développé en Java. Il fournit des interfaces de programmation d'application (API) natives Java, pour la programmation des tâches de création et de manipulation des tables. Ces API se sont les classes JAVA HTableInterface ou HTable. Elles fournissent les méthodes nécessaires à la manipulation, la configuration d'HBase et l'exploitation des tables qui y sont implémentées.

Dans les SGBDR, pour interagir avec la Base de données, le SGBDR utilise le SQL et celui-ci sert à la fois de langage de définition de la structure et d'exploitation de la base de données. Le SQL fournit un ensemble d'opérations et ce sont ces opérations que l'analyste utilise pour manipuler sa base de données. Deux catégories d'opérations y sont fournies : les opérations de définition de la base de données (le CRUD - CREATE, INSERT, UPDATE, DELETE) et les opérations d'interrogation de la base de données (SELECT). L'utilisateur définit une requête à l'aide d'une ou des deux catégories de ces opérations et elle est soumise au SGBDR pour traitement. Il en est de même avec HBase. HBase fournit une série d'opérations pour interagir avec les tables HBase. Ces opérations peuvent être exploitées en masse par le MapReduce et elles sont au nombre de quatre :

• Get : équivalent à l'opération SQL SELECT, cette opération permet de renvoyer les valeurs soit d'une colonne soit d'une famille de colonnes, soit alors des versions des valeurs de cellule pour une ligne spécifiée. Si le Get est utilisé pour lire les valeurs d'une famille de colonne, donc des données du même HFile, alors HBase n'effectuera pas de jointure de HFiles. La syntaxe de cette commande est la suivante :

get 'table name', 'rowkey_value', {COLUMN => ['column_family:column_name', ……, 'column_family:column_name'], VERSIONS => <Nombre de versions retournées>...}

Exemple :

get 'Customers', 'CC09877', {COLUMN => ['personal:customer_name', 'public: enterprise'], VERSIONS => 10}

Cette requête porte sur la table Customers et extrait les valeurs des colonnes customer_name et enterprise pour la Row Key  de valeur CC09877, elle y extrait les 10 premières versions de la row_key :

• Put : équivalent à un INSERT en SQL, cette opération ajoute une nouvelle ligne dans la table si cette ligne n'existe pas (c'est-à-dire que la valeur de clé n'existe pas dans la table) ou ajoute une nouvelle version de la même ligne si elle existe déjà dans la table. Comme avec le GET, le PUT peut se limiter à ajouter une ligne dans une colonne ou une famille de colonnes spécifiques. La syntaxe de cette commande est la suivante :

Put 'table_name', 'rowKey_value', 'colum_family:column_name', 'value',… 'colum_family:column_name', 'value'

Exemple : ajouter à la table Customers une nouvelle version de la rowkey 'CC09877', les valeurs respectives 'juvénal' et 'CAPGEMINI' aux colonnes 'personal:customer_name', 'public: 'enterprise'. Cela donne la requête suivante :

Put 'customers', 'CC09877', 'personal:customer_name', 'juvénal', 'public: 'enterprise', 'CAPGEMINI' ;

• Scan : cette opération permet d'itérer sur plusieurs lignes pour récupérer les lignes de familles de colonnes, colonnes ou cellules pour des clés spécifiques. La syntaxe de cette commande est la suivante :

scan '< TABLE>', {COLUMNS => ['<Colonne1>',…,'<ColonneN>'], VERSIONS => <nombre de versions retournées>, FILTER => <critère filtre>, LIMIT = <nbre_de_valeurs_renvoyées> ...}

Exemple :

scan 'customers, {COLUMNS => ['personal:customer_name', 'public: enterprise'], VERSIONS => 10, FILTER => "PrefixFilter('CC09877')" }.

Cette requête renvoie les données dont les rowKeys sont  préfixées « CC ». Vous pouvez transférer les résultats renvoyés par la requête en utilisant la commande shell suivante :

echo "commande hbase shell" | hbase shell > fichier.txt
par exemple, on peut transférer les résultats de notre requête en la re-écrivant de la façon suivante :

echo " scan 'customers, {COLUMNS => ['personal:customer_name', 'public: enterprise'], VERSIONS => 10, FILTER => \"PrefixFilter('CC09877')\" } => results.txt ;

• Delete : a l'instar du DELETE en SQL, cette opération supprime une ou plusieurs lignes spécifiques, colonnes, familles de colonnes ou cellules. En réalité, la suppression ne se fait pas au moment où la requête est envoyée, au contraire, HBase crée des marqueurs sur chaque valeur à supprimer et celles ci sont supprimées massivement lorsqu'HBase effectue un compactage de la table. La syntaxe pour cette commande est la suivante :

DELETE 'table_name>', 'rowKey_value>', 'column_name >', 'time_stamp>'

Exemple : DELETE customers 'CC09877', 'personal: customer_name', 1209201600002345

Cette commande supprime la version 1209201600002345 de la row key CC09877 pour la colonnecustomer_name ;

Toutes ces opérations peuvent se programmer de façon massivement parallèle à l'aide du MapReduce, et donc par ricochet l'utilisateur non technique peut utiliser un langage d'abstraction comme le HiveQL ou le Pig Latin, pour créer et manipuler les tables HBase. Apache a récemment intégré dans Hive une classe HBaseStorageHandler qui permet de mapper les tables HBase à Hive.  Vous pouvez ainsi utiliser une opération CREATE TABLE dans HiveQL pour créer une table dans HBase, SELECT pour renvoyer les valeurs, INSERT pour insérer les valeurs dans la table HBase et ainsi de suite. supposons que nous voulons créer une table HBase à partir d'un script HiveQL, la requête serait la suivante :

CREATE TABLE IF NOT EXISTS Clients(
   id_client   STRING,
   concat(Nom_client,' ', prenom_client) Noms_client
   datediff(date_naissance, CURRENT_DATE()) Age_client,
   Substr(genre, 1, 1)   genre,
   Qantité * Prix_unitaire  Vente)  
STORED BY 'org.apache.hadoop.hive.HBaseStorageHandler'
WITH SERDEPROPERTIES ("hbase.columns.mapping" = "id_client:key, personal:customer_name, personal:customer_age, personal:customer_gender, product:sales") 
TBLPROPERTIES ("hbase.table.name" = "Customers");

Dans la requête, nous créons dans HBase, une table appelée 'customers', possédant deux familles de colonnes : 'personnal' et 'product'. Les valeurs de la row key de la table sont les valeurs de la colonne id_client, et la famille 'personnal' contient les colonnes Noms_client (avec pour label customer_name), Age_client (avec pour label 'customer_age'), genre (avec pour label 'customer_age'). Après avoir créé et référencé la table HBase avec l'instruction CREATE TABLE, vous pouvez l'utiliser normalement comme si vous étiez en train de faire du HiveQL classique, à la seule différence que chaque instruction est retranscrite en son équivalent GET, PUT, SCAN ou DELETE en HBase. Par exemple, vous pouvez utiliser une instruction INSERT pour charger dans votre table HBase des données d'entrée stockées dans le HDFS.

FROM Clients INSERT INTO TABLE Customers
	SELECT Clients.* ;

Vous pouvez également utiliser le SELECT pour envoyer des requêtes de lecture spécifiques à HBase.

SELECT SUM(vente) FROM Clients
	 WHERE age_client BETWEEN 25 AND 30 GROUP BY genre;

Voilà, maintenant vous savez comment utiliser HBase. Vous pouvez vous inspirer des modèles de scripts et des exemples que nous avons fournis ici pour commencer à écrire vos propres programmes HBase.

Nous savons qu'en tant que professionnel ou étudiant, vous avez l'habitude de travailler avec les Bases de Données relationnelles. Pratiquement toutes les entreprises utilisent encore les bases relationnelles. Avec la transition Numérique en cours, elles seront forcées de migrer certaines de leurs bases de données relationnelles vers des SGBD NoSQL. Vous serez donc sûrement emmenés à travailler sur des projets de migration de données, des bases relationnelles vers les bases NoSQL en général, et vers les tables HBase en particulier. D'après notre expérience personnelle, les projets de migration des bases de données relationnelles vers HBase sont de plus en plus courants. Dans ce point, notre objectif est de vous donner les clés pour migrer efficacement une base de données relationnelle vers une table HBase. Nous avons identifié trois clés dont l'application garantit la migration réussie du relationnel vers HBase :

• gardez déjà à l'esprit que le monde du NoSQL représente tout d'abord un changement de paradigme, c'est comme si vous cessez de vivre dans une démocratie et subitement intégrez une monarchie. Ce n'est pas tant les principes ou les concepts qui diffèrent du SQL au NoSQL, mais c'est la façon de penser. Ainsi, migrer une base relationnelle vers une base non relationnelle va vous demander de penser différemment que ce que vous avez toujours eu l'habitude de penser ;
• la priorité d'une base de données relationnelle, c'est la cohérence de la base de données et l'intégrité des transactions qui y sont effectuées. La priorité d'une table Hbase, c'est la distribution du stockage et l'accès rapide aux partitions distribuées. Ainsi, à cause de ces priorités divergentes, si vous devez migrer une base de données relationnelle vers une table NoSQL, de prime abord, ne le faites pas !  Mais si vraiment vous êtes dans l'obligation de le faire, alors reconstruisez votre base en tenant compte des priorités d'HBase, c'est-à-dire la facilité de distribution et la rapidité d'accès ;
• si vous devez absolument migrer votre base, alors évaluez les inconvénients associés à la dénormalisation de votre base de données ; si ceux-ci sont acceptables, du moins dans le moyen terme, alors essayer d'obtenir des tables HBase qui respectent les règles de modélisation que nous avons énoncées plus haut.

Voilà, en tenant compte des conseils de ce petit guide, vous pourrez prendre des décisions adéquates quant à une éventuelle migration de base relationnelle vers une ou plusieurs tables HBase. Nous allons également aborder la migration de Phoenix à HBase.

Phoenix est une couche SQL installée au-dessus de HBase pour l'exécution des requêtes SQL sur les données stockées dans des tables HBase. Phoenix est un autre moyen pour exploiter HBase. Nous dirions même qu'il est le plus simple et le plus performant, car il s'appuie sur le SQL, que vous connaissez déjà. Si nous revenons sur l'étude de Phoenix, c'est à cause de sa progression dans le marché, il est de plus en plus adopté comme interface d'utilisation d'HBase à cause de la transparence qu'il offre aux utilisateurs métiers et l'utilisation du SQL. La figure ci-après illustre l'architecture simplifiée de HBase et le positionnement de Phoenix dans l'architecture de HBase.

Comme la figure le montre, Phoenix est installé au niveau du client HBase d'une part, c'est-à-dire au niveau de l'interface HtableInterface Et d'autre part, au niveau des RegionsServers.  Ainsi, Phoenix ne distribue pas lui-même les données, il n'exécute pas non plus les requêtes, il permet aux utilisateurs d'écrire des requêtes SQL à la place des commandes GET, PUT, SCAN, DELETE (au niveau du client), les compilent et les exécutent directement au niveau des RegionsServers. La différence par rapports aux commandes classiques est qu'une fois compilées, ces requêtes sont exécutées sur les régions de la table HBase sans être transformées en fonctions MapReduce. Par contre, c'est HBase qui s'occupe des aspects distribués du traitement. C'est pour cette raison que dans la communauté open source, on dit de Phoenix qu'il est le "SQL Skin for HBase" (la peau SQL de HBase). La compilation effectuée par Phoenix aboutit à des performances de l'ordre de la milliseconde en fonction du volume de données traité. En filigrane, on pourrait dire que Phoenix essaye de fonctionner comme un moteur SQL MPP. Phoenix supporte aussi bien la création de table HBase que le mapping d'une table HBase existante. La spécification SQL de Phoenix est conforme aux différentes normes SQL. Rendez-vous sur le site officiel d'Apache Phoenix pour plus de détail.