CopyTable est un simple utilitaire Apache HBase qui, sans surprise, peut être utilisé pour copier des tables individuelles dans un cluster HBase ou d'un cluster HBase à un autre. Dans cet article de blog, nous parlerons de ce qu'est cet outil, pourquoi vous voudriez l'utiliser, comment l'utiliser et quelques mises en garde de configuration courantes.
Cas d'utilisation :
CopyTable est à la base une tâche Apache Hadoop MapReduce qui utilise l'interface de chemin de lecture HBase Scan standard pour lire les enregistrements d'une table individuelle et les écrit dans une autre table (éventuellement sur un cluster séparé) à l'aide de l'interface de chemin d'écriture HBase Put standard. Il peut être utilisé à plusieurs fins :
- Copie interne d'un tableau (instantané du pauvre)
- Sauvegarde d'instance HBase à distance
- Copies de table HBase incrémentielles
- Copies partielles de la table HBase et modifications du schéma de la table HBase
Hypothèses et limites :
L'outil CopyTable comporte certaines hypothèses et limites de base. Tout d'abord, en cas d'utilisation dans une situation multi-cluster, les deux clusters doivent être en ligne et l'instance cible doit avoir la table cible présente avec les mêmes familles de colonnes définies que la table source.
Étant donné que l'outil utilise des scans et des puts standards, le cluster cible n'a pas besoin d'avoir le même nombre de nœuds ou de régions. En fait, il peut avoir différents nombres de tables, différents nombres de serveurs de région et peut avoir des limites de division de région complètement différentes. Étant donné que nous copions des tables entières, vous pouvez utiliser des paramètres d'optimisation des performances tels que la définition de valeurs de mise en cache du scanner plus élevées pour plus d'efficacité. L'utilisation de l'interface put signifie également que des copies peuvent être faites entre des clusters de différentes versions mineures. (0.90.4 -> 0.90.6, CDH3u3 -> CDH3u4) ou versions compatibles filaire (0.92.1 -> 0.94.0).
Enfin, HBase ne fournit que des garanties ACID au niveau des lignes ; cela signifie que pendant qu'un CopyTable est en cours, des lignes nouvellement insérées ou mises à jour peuvent se produire et ces modifications simultanées seront soit complètement incluses, soit complètement exclues. Bien que les lignes soient cohérentes, il n'y a aucune garantie quant à la cohérence, la causalité ou l'ordre des options de vente sur les autres lignes.
Copie interne d'un tableau (instantané du pauvre)
Les versions de HBase jusqu'aux versions 0.94.x les plus récentes incluses ne prennent pas en charge l'instantané de table. Malgré les limitations ACID de HBase, CopyTable peut être utilisé comme un mécanisme d'instantané naïf qui fait une copie physique d'une table particulière.
Disons que nous avons une table, tableOrig avec les familles de colonnes cf1 et cf2. Nous voulons copier toutes ses données dans tableCopy. Nous devons d'abord créer tableCopy avec les mêmes familles de colonnes :
srcCluster$ echo "create 'tableOrig', 'cf1', 'cf2'" | hbase shell
Nous pouvons alors créer et copier la table avec un nouveau nom sur la même instance HBase :
srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --new.name=tableCopy tableOrig
Cela démarre une tâche MR qui copiera les données.
Sauvegarde d'instance HBase à distance
Disons que nous voulons copier des données vers un autre cluster. Il peut s'agir d'une sauvegarde ponctuelle, d'une tâche périodique ou d'un amorçage pour la réplication entre clusters. Dans cet exemple, nous aurons deux clusters distincts :srcCluster et dstCluster.
Dans ce cas multi-cluster, CopyTable est un processus push - votre source sera l'instance HBase à laquelle votre hbase-site.xml actuel fait référence et les arguments ajoutés pointent vers le cluster et la table de destination. Cela suppose également que tous les MR TaskTrackers peuvent accéder à tous les nœuds HBase et ZK du cluster de destination. Ce mécanisme de configuration signifie également que vous pouvez l'exécuter en tant que tâche sur un cluster distant en remplaçant les configurations hbase/mr pour utiliser les paramètres de n'importe quel cluster distant accessible et spécifier les nœuds ZK dans le cluster de destination. Cela pourrait être utile si vous vouliez copier des données à partir d'un cluster HBase avec des SLA inférieurs et ne vouliez pas exécuter directement des tâches MR dessus.
Vous utiliserez le paramètre –peer.adr pour spécifier l'ensemble ZK du cluster de destination (par exemple, le cluster vers lequel vous copiez). Pour cela, nous avons besoin de l'adresse IP et du port du quorum ZK ainsi que du nœud ZK racine HBase pour notre instance HBase. Supposons que l'une de ces machines est srcClusterZK (répertoriée dans hbase.zookeeper.quorum) et que nous utilisons le port client zk par défaut 2181 (hbase.zookeeper.property.clientPort) et le parent znode ZK par défaut /hbase (zookeeper.znode. parent). (Remarque :si vous aviez deux instances HBase utilisant le même ZK, vous auriez besoin d'un zookeeper.znode.parent différent pour chaque cluster.
# create new tableOrig on destination cluster dstCluster$ echo "create 'tableOrig', 'cf1', 'cf2'" | hbase shell # on source cluster run copy table with destination ZK quorum specified using --peer.adr # WARNING: In older versions, you are not alerted about any typo in these arguments! srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --peer.adr=dstClusterZK:2181:/hbase tableOrig
Notez que vous pouvez utiliser l'argument –new.name avec –peer.adr pour copier vers une table nommée différemment sur le dstCluster.
# create new tableCopy on destination cluster dstCluster$ echo "create 'tableCopy', 'cf1', 'cf2'" | hbase shell # on source cluster run copy table with destination --peer.adr and --new.name arguments. srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --peer.adr=dstClusterZK:2181:/hbase --new.name=tableCopy tableOrig
Cela copiera les données de tableOrig sur le srcCluster vers la table tableCopy du dstCluster.
Copies de table HBase incrémentielles
Une fois que vous avez une copie d'une table sur un cluster de destination, comment copiez-vous les nouvelles données qui sont ensuite écrites sur le cluster source ? Naïvement, vous pouvez réexécuter le travail CopyTable et copier sur toute la table. Cependant, CopyTable fournit un mécanisme de copie incrémentielle plus efficace qui copie simplement les lignes mises à jour du srcCluster vers le dstCluster de sauvegarde spécifié dans une fenêtre de temps. Ainsi, après la copie initiale, vous pourriez alors avoir une tâche cron périodique qui copie les données de l'heure précédente uniquement de srcCluster vers le dstCuster.
Cela se fait en spécifiant les arguments –starttime et –endtime. Les heures sont spécifiées en millisecondes décimales depuis l'heure de l'époque unix.
# WARNING: In older versions, you are not alerted about any typo in these arguments! # copy from beginning of time until timeEnd # NOTE: Must include start time for end time to be respected. start time cannot be 0. srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable ... --starttime=1 --endtime=timeEnd ... # Copy from starting from and including timeStart until the end of time. srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable ... --starttime=timeStart ... # Copy entries rows with start time1 including time1 and ending at timeStart excluding timeEnd. srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable ... --starttime=timestart --endtime=timeEnd
Copies partielles de la table HBase et modifications du schéma de la table HBase
Par défaut, CopyTable copie toutes les familles de colonnes à partir des lignes correspondantes. CopyTable fournit des options pour copier uniquement les données de familles de colonnes spécifiques. Cela peut être utile pour copier les données source d'origine et exclure les familles de colonnes de données dérivées qui sont ajoutées par le traitement de suivi.
En ajoutant ces arguments, nous ne copions que les données des familles de colonnes spécifiées.
- –familles=srcCf1
- –families=srcCf1,srcCf2
À partir de la version 0.92.0, vous pouvez copier tout en modifiant le nom de famille de la colonne :
- –families=srcCf1:dstCf1
- copier de srcCf1 vers dstCf1
- –families=srcCf1:dstCf1,dstCf2,srcCf3:dstCf3
- copier de srcCf1 vers destCf1, copier dstCf2 vers dstCf2 (pas de renommage) et srcCf3 vers dstCf3
Veuillez noter que dstCf* doit être présent dans la table dstCluster !
À partir de la version 0.94.0, de nouvelles options sont proposées pour copier les marqueurs de suppression et pour inclure un nombre limité de versions écrasées. Auparavant, si une ligne était supprimée dans le cluster source, la suppression n'était pas copiée - au lieu de cela, une version obsolète de cette ligne restait dans le cluster de destination. Cela tire parti de certaines des fonctionnalités avancées de la version 0.94.0.
- –versions=vers
- où vers est le nombre de versions de cellule à copier (la valeur par défaut est 1, c'est-à-dire la dernière uniquement)
- –all.cells
- copie également les marqueurs de suppression et les cellules supprimées
Pièges courants
Le client HBase dans les versions 0.90.x, 0.92.x et 0.94.x utilise toujours zoo.cfg s'il se trouve dans le chemin de classe, même si un fichier hbase-site.xml spécifie d'autres paramètres de configuration du quorum ZooKeeper. Cette "fonctionnalité" provoque un problème courant dans CDH3 HBase car ses packages incluent par défaut un répertoire où zoo.cfg réside dans le chemin de classe de HBase. Cela peut et a conduit à la frustration lors de l'utilisation de CopyTable (HBASE-4614). La solution consiste à exclure le fichier zoo.cfg du chemin de classe de votre HBase et à spécifier les propriétés de configuration de ZooKeeper dans votre fichier hbase-site.xml. http://hbase.apache.org/book.html#zookeeper
Conclusion
CopyTable fournit une assurance de reprise après sinistre simple mais efficace pour les déploiements HBase 0.90.x (CDH3). En conjonction avec la fonctionnalité de réplication trouvée et prise en charge dans la base HBase 0.92.x de CDH4, les fonctionnalités incrémentielles de CopyTable deviennent moins utiles, mais sa fonctionnalité de base est importante pour amorcer une table répliquée. Bien que des fonctionnalités plus avancées telles que les instantanés HBase (HBASE-50) puissent faciliter la reprise après sinistre lors de sa mise en œuvre, CopyTable restera un outil utile pour l'administrateur HBase.
