Chapitre III - NoSQL et Hadoop - Cours PDF

20/12/2024 Chapitre III 2 Limitations de Hadoop 3...

20/12/2024 Chapitre III 2 Limitations de Hadoop 3  Hadoop utilise HDFS pour le stockage de données volumineuses et MapReduce pour les Plan traiter.  HDFS n’est pas idéal pour des applications nécessitant un accès en temps réel aux données. Les opérations d’écriture et de lecture dans HDFS sont conçues pour des I. Introduction (limites de hdfs, BD NoSQL traitements batch, ce qui peut entraîner des délais non négligeables pour des données II. Hbase (Présentation, historique) requérant une faible latence.  Hadoop est conçu pour effectuer un traitement par lots (non interactif) et les données ne III. Architecture global de HBase seront accessibles que de manière séquentielle.  Dans plusieurs scénarios, le traitement séquentiel de fichiers volumineux génère d'autres IV. Commandes Shell HBase fichiers également volumineux qui devraient également être traités de manière séquentielle.  Une nouvelle solution est nécessaire pour pouvoir traiter de données volumineuses de façon assurer un accès aléatoire aux données.  Plusieurs outils comme HBase, Cassandra, couchDB, Dynamo et MongoDB permettent de stocker une très grande quantité de données et d'y accéder de façon aléatoire.  Ces outils utilisent des modèles de données différents et font partie des technologies de BD NoSQL NoSQL 4 NoSQL : Pourquoi utiliser le NoSQL? 5  NoSQL, alias "Not Only SQL", est un ensemble de technologies de BD  Conçues pour gérer des volumes massifs de données non introduites spécifiquement pour gérer des types et structures de BD très structurées ou semi-structurées. variés en Big Data où les données sont distribuées et disparates  No  Adaptées pour des cas nécessitant une évolutivité Relational horizontale (distribution sur plusieurs serveurs).  Il existe quatre types de BD (entrepôts, datastores) NoSQL qui peuvent  Idéales pour des données très dynamiques (réseaux être orientées: sociaux, IoT, systèmes en temps réel).  Clé-valeur: MemcacheD, REDIS, Riak  Moins strictes sur les relations entre données, mais très  Graphe: Neo4j et Sesame rapides pour des lectures/écritures massives.  Colonnes: Hbase, Cassandra et SimpleDB  Documents: MongoDB et CouchDB  Les technologies NoSQL ne remplaceront pas les RDBMS ou les DW. 1  20/12/2024 NoSQL : À quoi ressemble une BD NoSQL? BD orientée Clé/Valeur 6 7  Principes:  Un SGBD qui n'est pas structuré et dont l'élément de base n'est pas un tuple mais dépend du type de BD NoSQL;  Représentation des données sous forme de clé/valeur.  Un langage de requête non uniformisé, propre à chaque BD. Souvent au format  Les valeurs peuvent être de simple chaines de JSON avec une API REST; caractères ou des objets sérialisés complexes.  Une dénormalisation des données où certains enregistrements sont en partie ou  Utilisation: entièrement dupliqués;  Dépôt de données avec besoins de requêtage simples  Type de base de données NoSQL à choisir en fonction de l'usage souhaité ; (préférences d'utilisateur, données de panier, les logs...)  Types de base de données NoSQL existants: clé-valeur, colonnes, documents,  Implémentations: graphe.  Voldemort  Riak  Redis BD orientée Document 8 BD orientée Graphe 9  Principes:  Principes:  C'est une variante des SGBD clé/valeur, où la valeur est un document de type XML ou  Les données sont représentées sous-forme de graphe: JSON.. Des nœuds pour les entités, des arcs pour les relations entre les entités.  Les documents ont une structure arborescente, ils sont composés de champs  Ce type de SGBD est adapté à la manipulation de et des valeurs associées données fortement connectées.  Ce type de SGBD permet d'effectuer des  Utilisation: requêtes sur le contenu des documents.  Systèmes de recommandations, Réseaux sociaux,  Utilisation: Systèmes de transport...  Enregistrements d'événements, gestion de  Implémentations: contenu...  Neo4J  Implémentations:  AllegroGraph  CouchDB (fondation apache)  …  MangoDB  … 2  20/12/2024 BD orientée colonne 10 Théorème CAP : 11  Principes:  Destiné à évaluer les systèmes de stockage distribués  Proche du relationnel. Mais le stockage des données se fait par colonne et non par ligne  Un système distribué ne peut pas garantir simultanément les trois propriétés. Il doit faire un compromis et se concentrer sur deux propriétés au détriment de la troisième.  Ajout de colonnes facile et dynamique  Propriétés CAP: Consistency, Availability, Partition tolerance  Possibilité de compression des données  Le théorème de CAP (théorème de Brewer) (Brewer, 2000) stipule qu'il est impossible  Utilisation: d'obtenir ces trois propriétés en même temps dans un système distribué et qu'il faut  Optimisation de la recherche, traitement et donc en choisir deux parmi les trois analyse de données structurées  Implémentations:  HBASE (à étudier dans ce cours)  Cassandra Hbase : Présentation 1/2 12 Hbase : Présentation 2/2 13  HBase, considéré comme la BD de Hadoop, a un modèle orienté colonnes  Distribué, privilégie la cohérence et la disponibilité des données sans oublier les similaire au modèle BigTable de Google permettant un accès aléatoire rapide. performances  Très évolutif  S'appuie sur Hadoop (Apache) qui facilite le traitement distribué de larges jeux de données et ses composants  Partitionnement automatique de données sur plusieurs nœuds (sharding)  Hadoop Core =  Evolue linéairement et automatiquement avec l'ajout de nouveaux nœuds  HDFS pour le stockage  Faible latence  MasterServer: Namenode (mode master/slave)  Supporte la lecture/écriture aléatoire  RegionServer: Datanode  Distribuée, Tolérante aux fautes  Zookeeper: infrastructure centralisée et services pour gérer un "cluster" de serveurs: parmi  HBase a des performances exceptionnelles pour des lectures et écritures massives les activités: synchronisation, choix du serveur maitre et vérification de la disponibilité des de données. Elle a été conçue pour stocker de très grandes tables de données. serveurs  Non-relationnelle (NoSQL-Orientée Colonnes)  MapReduce: modèle de programmation distribuée  HBase est utilisé par Facebook pour stocker tous les messages SMS, email et chat (2010). 3  20/12/2024 Hbase : Historique Hbase : Architecture globale 1/7 14 15  2006.11 - Google sort son papier sur BigTable  Une architecture maître esclave:  2007.02 - Version prototype d'HBase/contribution à Hadoop  Noeud maître = Hmaster, Noeud esclave = RegionServer  2007.10 Première version d'HBase -  Correspondance directe avec le cluster HDFS  2010.05 - HBase devient un top-level project à la fondation Apache  2015.02-HBase 2.0.0  2020.11-Hbase 2.3.3  2024.01-Hbase 3.0.0 Hbase : Architecture globale 2/7 16 Hbase : Architecture globale 3/7 17  Pour obtenir une grande efficacité, les données des tables HBase sont séparées en régions:  Une région contient un certain nombre de n-uplets contigus (intervalle de clés successives).  Lorsqu'on crée une table, elle est mise dans une seule région.  Lorsqu'une table dépasse une certaine limite, elle se fait couper en deux régions au milieu de ces clés. Et ainsi de suite si les régions deviennent trop grosses.  Chaque région est gérée par Serveur de Région (Region Server).  Ces serveurs sont distribués sur le cluster, ex: un par machine 4  20/12/2024 Hbase : Zookeeper 18 Hbase : Le Master 19  Zookeeper fournit un service de coordination  Il surveille toutes les instances du serveur de régions dans le cluster  Les méta-données de mapping "Région-Serveur de région" sont gardées dans  Il est responsable des modifications de schéma et d'autres opérations sur les de méta-tables stockées dans Zookeeper. métadonnées telles que la création de tables et de familles de colonnes  Les serveurs de régions envoient des pulsations (heartbeats) à ZK  Il assigne des régions aux serveurs de région et utilise Apache ZooKeeper pour cette tâche.  Le client trouve le serveur de région via ZK  Il équilibre la charge des régions sur les serveurs de régions. Il décharge les  Le client écrit / lit directement depuis et vers les serveurs de régions serveurs occupés et déplace les régions vers des serveurs moins occupés.  Zookeeper s'assure qu'il ait un seul maitre en exécution.  A leur démarrage, les maîtres s'adressent à ZooKeeper. Le premier à y accéder  Le Maître consulte ZK pour connaître les serveurs de régions défaillants devient actif (principal) et les autres passifs (backup)  ZK assure la tolérance aux pannes dans l’architecture de Hbase Hbase : Serveur de région 20 Hbase : Région 21  Le serveur de région met un ensemble de régions à la disposition des clients.  Une région est une partition logique horizontale d'une table avec une ligne de début et une ligne de fin. (taille par défaut: 256M)  Une région stocke les données d'une partie d'une table.  Les régions sont l'élément de base de la disponibilité et de la distribution des  Il y a plusieurs magasins (Store) dans une région tables.  Un magasin contient une famille de colonnes dans une région.  Une région est automatiquement divisée par le serveur de la région lorsqu'elle  Un magasin a un Memstore et un ensemble de Hfile dépasse une taille spécifiée.  Le MemStore est un tampon d'écriture en mémoire dans lequel Hbase accumule  Périodiquement, un équilibreur de charge déplace les régions dans le cluster des données avant une écriture permanente dans les Hfiles pour équilibrer la charge.  WAL (Write-Ahead-Log) stocke toutes les modifications des données. Il y a un  Lorsqu'un serveur de région est défaillant, ses régions seront réaffectées à WAL par serveur de région. Toutes les modifications des régions d'un serveur d'autres serveurs de régions. de région sont d'abord enregistrées dans le WAL 5  20/12/2024 Hbase : Organisation logique des données Hbase : Organisation logique des données Namespace 22 Table 23  Principes: Un groupement logique de table  Principes: Un groupement logique de table  Caractéristiques :  Caractéristiques :  Permet d'isoler des tables pour des raisons de quotas, de  Élément servant à organiser les données dans Hbase restrictions géographiques, de sécurité  Le nom d'une table est une chaîne de caractère, désignée de  Deux namespace existent déjà par défaut manière non ambiguë en préfixant son nom par le nom de son  hbase: Contient toutes les tables des méta-données de namespace séparé par ' :' Hbase.  default: namespace par défaut lorsque aucun namespace n'est spécifié à la création d'une table. Nom_namespace : nom_table Hbase : Organisation logique des données Hbase : Organisation logique des données Row 24 ColumnFamily 25  Principes :  Principes:  Permet d'organiser les données dans une table  Regroupe les données au sein d'une ligne  Une ligne est identifiée par une clé unique: Rowkey  Toutes les lignes de la table ont les mêmes ColumnFamily,  La Rowkeys n'a pas de type. pouvant être peuplée ou pas  Au moins une à la création de la table dans HBase 6  20/12/2024 Hbase : Organisation logique des données Hbase : Organisation logique des données Column (column qualifier) 26 Cell 27  Principes:  Principes:  Permet de subdiviser les columnfamily  Identifiée par la combinaison d'un RowKey, de la  Désignée par une chaîne de caractères appelée column qualifier ColumnFamily et de la Column  Non typée.  Les données stockées dans une cellule sont les valeurs de la  Le columnqualifier permet l'accès aux données. Ce dernier n'est cellule pas spécifié à la création de la table mais plus tôt à l'insertion  On peut stocker différente version de la cellule (ou timestamp) de la donnée. Hbase : Organisation logique des données Hbase : Organisation logique des données Version 28 Valeur 29  Principes :  Principes:  Les valeurs au sein d'une cellule sont versionnées  Une valeur est une donnée atomique de la base  Les versions sont identifiées par défaut par un timestamp (de type long)  Non typée  Une fois la valeur est écrite dans HBase, Elle ne peut pas être modifiée. Au lieu  Les valeurs nulles ne sont pas matérialisées (aucun stockage nécessaire)  Désignée par une clé multi-dimensionnelle: (rowkey, column family, column, version) de cela une autre version avec un Timestamp plus récent peut être ajoutée.  Désignation complète d'une valeur dans HBase  Le nombre de version que l'on peut stocker par cellule est paramétrable  namespace:table(rowkey, column family, column, version) > val 7  20/12/2024 Hbase : Organisation logique des données Hbase : Commandes Shell 1/7 Valeur 30 31  Pour manipuler les données, Hbase propose plusieurs méthodes:  Valeur NULL  Hbase Shell  API Java  Web-services REST ful (Ruby, Php, Python, Perl, C++,..)  Exemple de commandes Hbase Shell  Lancer le shell de HBase: …] $ hbase shell  Pour supprimer un namespace: drop_namespace 'nom_namespace' Base de données ralationnel BD orienté colonne  Créer une table dans un namespace create 'nom_namespace:nom_table', 'cf1', 'cf2', … ID Prénom Opérate Localite  Lister les tables d’un namespace: list_namespace_tables 'nom_namespace ur  Création de la table Message ayant deux familles de colonnes: auteur et contenu  > create 'Message' , 'auteur' , 'contenu‘ 1 Mohame Bizerte  Vérifier la création de la table en listant les noms de tables existantes: d  > list  > list 'Message' 2 Ali Telecom  Description de la table Message: > describe 'Message' On aura les propriétés de chaque 3 Olfa famille de colonnes (VERSIONS, COMPRESSION, …)  01/04/2024 4 Tunis  10 5 Ariana  HBase : Atelier 1 (2/8)  7. Ajouter une famille de colonnes destination:  > alter 'Message' , {NAME => 'destination'}  > describe 'Message' Hbase : Commandes Shell 2/7 Hbase : Commandes Shell 3/7 32 33  Insérer des données avec la commande put:  Supprimer des lignes ou des cellules:  syntaxe: put 'HBase_table_name' , 'row_key' , 'colfamily:colname' , 'value'  Syntaxe: deleteall 'table_name', 'row_key'  > put 'Message', '1', 'auteur:name', 'Said'  delete 'table_name', 'row_key', 'column_name', time_stamp_value  > put 'Message', '1', 'auteur:role', 'admin'  > delete 'Message' , '2' , 'contenu:msg' , 150528649549  > put 'Message', '1', 'contenu:msg', 'le patch hbase 2.0 est prêt'  > deleteall 'Message' , '1'  > put 'Message', '1', 'destination:name', 'Farid'  Supprimer des familles de colonnes:  > put 'Message', '2', 'auteur:name', 'Farid'  Syntaxe: alter 'table_name', {NAME => ' 'column_familly', METHOD =>  > put 'Message', '2', 'contenu:msg', 'le patch reçu ne fonctionne pas' 'delete'}  Lire les données de la table Message avec la commande get:  OU  syntaxe: get 'HBase_table_name','row_key'  alter 'table_name', 'delete'=> 'column_familly'  > get 'Message' , '1‘  pour avoir toutes les colonnes de toutes les familles de  > alter 'Message' , 'delete'=> 'destination' colonnes de la ligne '1  > decribe 'Message‘  > get 'Message', '1', {COLUMN => 'auteur:name'} Pour avoir une seule  Vider la table Message avec la commande: truncate 'Message‘ colonne 'auteur:name'  Supprimer la table Message avec la commande: drop 'Message‘  > get 'Message', '1', {COLUMN => ['auteur:name', 'contenu:msg']}  Pour  La commande ImportTsv permet de charger un fichier csv dans une table Hbase avoir deux colonnes 'auteur:name' et 'contenu:msg‘  La commande scan pour avoir son contenu  Lire les données avec la commande scan: scan 'table_name', {attribute => 'value' , … }  > scan 'Message'  > scan 'Message' , {COLUMNS => ['auteur:name', 'contenu:msg']} 8  20/12/2024 Hbase : Commandes Shell 4/7 Hbase : Commandes Shell 5/7 34 35 Hbase : Commandes Shell 6/7 Hbase : Commandes Shell 7/7 36 37 9