La réplication (couverte dans cet article de blog précédent) est sortie depuis un certain temps et fait partie des fonctionnalités les plus utilisées d'Apache HBase. Avoir des clusters répliquant des données avec différents homologues est un déploiement très courant, que ce soit en tant que stratégie DR ou simplement comme un moyen transparent de répliquer des données entre des environnements de production/mise en scène/développement. Bien qu'il s'agisse d'un moyen efficace de synchroniser différentes bases de données HBase avec une latence inférieure à une seconde, la réplication ne fonctionne que sur les données ingérées après l'activation de la fonctionnalité. Cela signifie que toutes les données préexistantes sur tous les clusters impliqués dans le déploiement de la réplication devront toujours être copiées entre les pairs d'une autre manière. De nombreux outils peuvent être utilisés pour synchroniser des données préexistantes sur différents clusters de pairs. Snapshots, BulkLoad, CopyTable sont des exemples bien connus de ces outils couverts dans les précédents articles du blog Cloudera. Dans cet article, nous allons couvrir HashTable/SyncTable, détaillant une partie de sa logique de mise en œuvre interne, les avantages et les inconvénients de son utilisation, et comment elle se compare à certaines des autres techniques de copie de données mentionnées ci-dessus.
HashTable/SyncTable en bref
HashTable/SyncTable est un outil implémenté sous la forme de deux travaux de réduction de carte exécutés en étapes individuelles. Il ressemble au CopyTable outil, qui peut effectuer des copies de données de table partielles ou entières. Contrairement à CopyTable il copie uniquement les données divergentes entre les clusters cibles, économisant à la fois les ressources réseau et informatiques pendant la procédure de copie.
La première étape à exécuter dans le processus est la HashTable tâche de réduction de carte. Cela doit être exécuté sur le cluster dont les données doivent être copiées sur le pair distant, normalement le cluster source. Un exemple rapide de la façon de l'exécuter est illustré ci-dessous, une explication détaillée de chacun des paramètres requis est donnée plus loin dans cet article :
hbase org.apache.hadoop.hbase.mapreduce.HashTable --families=cf my-table /hashes/test-tbl…20/04/28 05:05:48 INFO mapreduce.Job : mapper 100 % réduire 100 %20/04/28 05:05:49 INFO mapreduce.Job :Job job_1587986840019_0001 terminé avec succès20/04/28 05:05:49 INFO mapreduce.Job :Compteurs :68…Compteurs de format d'entrée de fichier Octets Lecture=0Compteurs de format de sortie de fichier Octets Ecrit=6811788
Une fois le HashTable l'exécution du travail avec la commande ci-dessus est terminée, certains fichiers de sortie ont été générés dans le hdfs source /hashes/my-table répertoire :
hdfs dfs -ls -R /hashes/test-tbldrwxr-xr-x - supergroupe racine 0 2020-04-28 05:05 /hashes/test-tbl/hashes-rw-r--r-- 2 racine supergroupe 0 2020-04-28 05:05 /hashes/test-tbl/hashes/_SUCCESSdrwxr-xr-x - supergroupe racine 0 2020-04-28 05:05 /hashes/test-tbl/hashes/part-r-00000 -rw-r--r-- 2 supergroupe racine 6790909 2020-04-28 05:05 /hashes/test-tbl/hashes/part-r-00000/data-rw-r--r-- 2 supergroupe racine 20879 2020-04-28 05:05 /hashes/test-tbl/hashes/part-r-00000/index-rw-r--r-- 2 supergroupe racine 99 2020-04-28 05:04 /hashes/test- tbl/manifest-rw-r--r-- 2 supergroupe racine 153 2020-04-28 05:04 /hashes/test-tbl/partitions
Ceux-ci sont nécessaires comme entrée pour le SyncTable Cours. SyncTable doit être lancé sur le pair cible. La commande ci-dessous exécute SyncTable pour la sortie de HashTable de l'exemple précédent. Il utilise le dryrun option expliquée plus loin dans cet article :
hbase org.apache.hadoop.hbase.mapreduce.SyncTable --dryrun --sourcezkcluster=zk1.example.com,zk2.example.com,zk3.example.com:2181:/hbase hdfs://source- cluster-active-nn/hashes/test-tbl test-tbl test-tbl…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_MATCHED=97146HASHES_NOT_MATCHED=2MATCHINGCELLS=17MATCHINGROWS=2RANGESNOTMATCHED=2ROWSWITHDIFFS=2SOURCEMISSINGCELLS=1STAR 1
Comme référence rapide, vous pouvez simplement remplacer les paramètres donnés sur les deux exemples par vos valeurs d'environnement réelles. Le reste de cet article couvrira les détails de mise en œuvre plus en profondeur.
Pourquoi deux étapes différentes ?
L'objectif principal de cet outil est d'identifier et de copier uniquement les données manquantes entre les deux clusters. Table de hachage fonctionne comme une tâche de partitionnement/indexation, analysant des lots de données de table et générant des index de hachage pour chacun de ces lots. Ce sont les sorties écrites dans les fichiers sous /hashes/my-table répertoire hdfs transmis comme l'un des paramètres de la tâche. Comme mentionné précédemment, cette sortie est requise par le SyncTable travail. SyncTable scanne la table cible localement dans les mêmes tailles de lot que celles utilisées par HashTable, et calcule également les valeurs de hachage pour ces lots en utilisant la même fonction utilisée par HashTable. Il compare ensuite le hachage de lot local valeur avec celle de la HashTable production. Si les valeurs de hachage sont égales, cela signifie que l'ensemble du lot est identique dans les deux clusters et que rien ne doit être copié sur ce segment. Sinon, il ouvre une analyse du lot dans le cluster source, vérifiant si chacune des cellules existe déjà dans le cluster cible, copiant uniquement celles qui divergent. Sur des ensembles de données clairsemés et légèrement différents, cela se traduirait par beaucoup moins de données copiées entre les deux clusters. Cela ne nécessiterait également qu'un petit nombre de cellules à analyser dans la source pour vérifier les incohérences.
Paramètres requis
Table de hachage ne nécessite que deux paramètres :le nom de la table et le chemin de sortie où les hachages associés et les autres fichiers de métadonnées seront écrits. SyncTable utilise HashTable output dir comme entrée, avec les noms de table dans la source et dans le cluster cible, respectivement. Puisque nous utilisons HashTable /SyncTable pour déplacer des données entre des clusters distants, sourcezkcluster l'option doit être définie pour SyncTable . Il doit s'agir de l'adresse de quorum zookeeper du cluster source. Dans cet exemple d'article, nous avions également référencé directement l'adresse du nœud de nom actif du cluster source, de sorte que SyncTable lira le fichier de sortie de hachage directement à partir du cluster source. Sinon, HashTable la sortie peut être copiée manuellement du cluster source vers le cluster distant (avec distcp, par exemple).
| REMARQUE :L'utilisation de clusters distants sous différents domaines Kerberos n'est prise en charge qu'à partir de CDH 6.2.1. |
Options avancées
Les deux HashTable et SyncTable offrent des options optionnelles supplémentaires qui peuvent être réglées pour des résultats optimaux.
Table de hachage permet de filtrer les données à la fois par clé de ligne et heure de modification, avec startrow/starttime, stoprow/stoptime propriétés, respectivement. La portée du jeu de données peut également être limitée par les versions et familles Propriétés. La taille de lot La propriété définit la taille de chaque partie qui sera hachée. Cela a un impact direct sur les performances de synchronisation. Dans les cas de très peu d'incohérences, la définition de valeurs de taille de lot plus importantes peut entraîner de meilleures performances car de plus grandes parties de l'ensemble de données seraient ignorées sans avoir besoin d'être analysées par SyncTable.
SyncTable fournit un dryrun option qui permet d'avoir un aperçu des changements à appliquer dans la cible.
SyncTable le comportement par défaut consiste à refléter les données source du côté cible, de sorte que toute cellule supplémentaire présente dans la cible mais absente dans la source finit par être supprimée du côté cible. Cela peut être indésirable lors de la synchronisation des clusters sous une configuration de réplication active-active et dans de tels cas, doDeletes les options peuvent être définies sur false, en sautant la réplication des suppressions sur la cible. Il existe également un doPuts similaire indicateur pour les cas où des cellules supplémentaires ne doivent pas être insérées dans le cluster cible.
Analyser les sorties
Table de hachage génère quelques fichiers avec des méta-informations pour SyncTable, ceux-ci, cependant, ne sont pas lisibles par l'homme. Il n'effectue aucune modification sur les données existantes, de sorte que les informations associées n'ont que peu d'intérêt pour un contexte utilisateur.
SyncTable est l'étape qui applique réellement les modifications sur la cible et il peut être important de revoir son résumé avant de modifier réellement les données du cluster cible (voir dryrun possibilité mentionnée ci-dessus). Il publie quelques compteurs pertinents à la fin de la carte pour réduire l'exécution. En regardant les valeurs de l'exemple ci-dessus, nous pouvons voir qu'il y avait 97148 partitions hachées (rapporté par BATCHES compteur), qui SyncTable détecté des divergences dans seulement deux d'entre eux (selon le HASHES_MATCHED et HASHES_NOT_MACTHED compteurs). De plus, dans les deux partitions ayant des hachages différents, 17 cellules sur 2 lignes correspondaient (tel que rapporté par MATCHING_CELLS et MATCHING_ROWS, respectivement), mais il y avait aussi 2 lignes divergentes, sur ces deux partitions (selon RANGESNOTMATCHED et ROWSWITHDIFFS ). Enfin, SOURCEMISSINGCELLS et TARGETMISSINGCELLS dites-nous en détail si les cellules étaient présentes uniquement sur le cluster source ou cible. Dans cet exemple, le cluster source avait une cellule qui n'était pas sur la cible, mais la cible avait également une cellule qui n'était pas sur la source. Depuis SyncTable a été exécuté sans spécifier dryrun option et paramètre doDeletes option sur faux , le travail a supprimé la cellule supplémentaire dans le cluster cible et a ajouté la cellule supplémentaire trouvée dans la source au cluster cible. En supposant aucune écriture se produire sur l'un ou l'autre des clusters, une exécution ultérieure de la même SyncTable commande dans le cluster cible ne montrerait aucune différence :
hbase org.apache.hadoop.hbase.mapreduce.SyncTable --sourcezkcluster=zk1.example.com,zk2.example.com,zk3.example.com:2181:/hbase hdfs://nn:9000/hashes /test-tbl test-tbl test-tbl…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_MATCHED=97148…
Scénarios applicables
Synchronisation des données
À première vue, HashTable/SyncTable peut sembler chevaucher le CopyTable outil, mais il existe encore des scénarios spécifiques où l'un ou l'autre des outils serait plus approprié. Comme premier exemple de comparaison, en utilisant HashTable/SyncTable pour un chargement initial d'une table contenant 100 004 lignes et une taille totale de données de 5,17 Go, il a fallu quelques minutes uniquement pour SyncTable à compléter :
...20/04/29 03:48:00 INFO mapreduce.Job :Tâche en cours d'exécution :job_1587985272792_001120/04/29 03:48:09 INFO mapreduce.Job :tâche job_1587985272792_0011 en cours d'exécution en mode uber :false20/04/ 29 03:48:09 INFO mapreduce.Job : mapper 0 % réduire 0 %20/04/29 03:54:08 INFO mapreduce.Job : mapper 100 % réduire 0 %20/04/29 03:54:09 INFO mapreduce .Tâche :la tâche job_1587985272792_0011 s'est terminée avec succès…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148EMPTY_BATCHES=97148HASHES_NOT_MATCHED=97148RANGESNOTMATCHED=97148ROWSWITHDIFFS=100004TARGETMISSINGCELLS=100004TARGETMISSINGCELLS=74MPReSWITHDIFFS=100004TARGETMISSINGCELLS=74MMême sur un si petit ensemble de données, CopyTable exécuté plus rapidement (environ 3 minutes, tandis que SyncTable a pris 6 minutes pour copier l'ensemble des données):
...20/04/29 05:12:07 INFO mapreduce.Job :Tâche en cours :job_1587986840019_000520/04/29 05:12:24 INFO mapreduce.Job :tâche job_1587986840019_0005 en cours d'exécution en mode uber :false20/04/ 29 05:12:24 INFO mapreduce.Job : mapper 0 % réduire 0 %20/04/29 05:13:16 INFO mapreduce.Job : mapper 25 % réduire 0 %20/04/29 05:13:49 INFO mapreduce .Job : mapper 50 % réduire 0 %20/04/29 05:14:37 INFO mapreduce.Job : mapper 75 % réduire 0 %20/04/29 05:15:14 INFO mapreduce.Job : mapper 100 % réduire 0 %20/04/29 05:15:14 INFO mapreduce.Job:Job job_1587986840019_0005 completed successfully…HBase CountersBYTES_IN_REMOTE_RESULTS=2787236791BYTES_IN_RESULTS=5549784428MILLIS_BETWEEN_NEXTS=130808NOT_SERVING_REGION_EXCEPTION=0NUM_SCANNER_RESTARTS=0NUM_SCAN_RESULTS_STALE=0REGIONS_SCANNED=4REMOTE_RPC_CALLS=1334REMOTE_RPC_RETRIES=0ROWS_FILTERED=0ROWS_SCANNED=100004RPC_CALLS=2657RPC_RETRIES=0Utilisons maintenant à nouveau les deux outils pour traiter les différences clairsemées sur l'ensemble de données. Le test-tbl La table utilisée dans tous ces exemples comporte quatre régions dans le cluster source. Une fois que tous les ensembles de données d'origine ont été copiés dans le cluster cible dans l'exemple précédent, nous avons ajouté quatre lignes supplémentaires du côté source uniquement, une pour chacune des régions existantes, puis avons exécuté HashTable/SyncTable à nouveau pour synchroniser les deux clusters :
20/04/29 05:29:23 INFO mapreduce.Job :Tâche en cours :job_1587985272792_001320/04/29 05:29:39 INFO mapreduce.Job :tâche job_1587985272792_0013 en cours d'exécution en mode uber :false20/04/29 05 : carte 100% réduire 0%20/04/29 05:30:42 INFO mapreduce.Job :travail job_1587985272792_0013 terminé avec succès…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_MATCHED=97144HASHES_NOT_MATCHED=42MATCHINGCELLS=42MATCHINGCELLS=42MATCHINGCELLS=42MATCHINGCELLS=42MATCHINGCELLS=5RANGESNOTMATCHED=4ROWSWITHDIFFS=4TARGETMISSINGCELLS=4TARGETMISSINGROWS=4Nous pouvons le voir avec seulement quatre partitions incompatibles, SyncTable était considérablement plus rapide (environ une minute pour terminer). Utilisation de CopyTable pour effectuer cette même synchronisation a montré les résultats suivants :
20/04/29 08:32:38 INFO mapreduce.Job :Tâche en cours :job_1587986840019_000820/04/29 08:32:52 INFO mapreduce.Job :tâche job_1587986840019_0008 en cours d'exécution en mode uber :false20/04/29 08 :32:52 INFO mapreduce.Job : mapper 0 % réduire 0 %20/04/29 08:33:38 INFO mapreduce.Job : mapper 25 % réduire 0 %20/04/29 08:34:15 INFO mapreduce.Job :carte 50 % réduire 0 %20/04/29 08:34:48 INFO mapreduce.Job : carte 75 % réduire 0 %20/04/29 08:35:31 INFO mapreduce.Job : carte 100 % réduire 0 %20/ 04/29 08:35:32 INFO mapreduce.Job:Job job_1587986840019_0008 completed successfully…HBase CountersBYTES_IN_REMOTE_RESULTS=2762547723BYTES_IN_RESULTS=5549784600MILLIS_BETWEEN_NEXTS=340672NOT_SERVING_REGION_EXCEPTION=0NUM_SCANNER_RESTARTS=0NUM_SCAN_RESULTS_STALE=0REGIONS_SCANNED=4REMOTE_RPC_CALLS=1323REMOTE_RPC_RETRIES=0ROWS_FILTERED=0ROWS_SCANNED=100008RPC_CALLS=2657RPC_RETRIES=0CopierTable a pris le même temps pour synchroniser les tables que lors de la copie de l'ensemble de données, même s'il n'y en avait que quatre cellules à copier. C'était toujours correct pour ce très petit ensemble de données et avec un cluster inactif, mais dans des cas d'utilisation en production avec des ensembles de données plus volumineux et où le cluster cible peut également être utilisé par de nombreuses applications clientes qui y écrivent des données, CopyTable dégradation des performances par rapport à SyncTable serait encore plus élevé.
Il convient de mentionner qu'il existe également des outils/fonctionnalités supplémentaires qui pourraient être utilisés en combinaison pour un chargement initial d'un cluster cible (la cible n'a aucune donnée), tels que l'exportation d'instantanés, le chargement en bloc ou même une copie directe de l'original. répertoires de table du cluster source. Pour les chargements initiaux avec de grandes quantités de données à copier, prendre un instantané de table, puis utiliser ExportSnapshot l'outil surpassera les outils de copie en ligne tels que SyncTable ou CopierTable.
Vérification de l'intégrité de la réplication
Une autre utilisation courante de HashTable/SyncTable consiste à surveiller l'état de la réplication entre les clusters, lors du dépannage d'éventuels problèmes de réplication. Dans ce scénario, il fonctionne comme une alternative à l'outil VerifyReplication. En règle générale, lors de la vérification de l'état entre deux clusters, il n'y a aucune incompatibilité ou un problème temporaire temporaire a entraîné la désynchronisation d'une petite partie de l'ensemble de données plus volumineux. Dans l'environnement de test que nous avons utilisé pour notre exemple précédent, il devrait y avoir 100 008 lignes avec des valeurs correspondantes sur les deux clusters. L'exécution de SyncTable sur le cluster de destination avec l'option dryrun nous permettra d'identifier les différences :
20/05/04 10:47:25 INFO mapreduce.Job :Tâche en cours d'exécution :job_1588611199158_0004…20/05/04 10:48:48 INFO mapreduce.Job : map 100 % reduce 0%20/05/04 10 :48:48 INFO mapreduce.Job:Job job_1588611199158_0004 completed successfully…HBase CountersBYTES_IN_REMOTE_RESULTS=3753476784BYTES_IN_RESULTS=5549784600ROWS_SCANNED=100008…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_MATCHED=97148...Unlike SyncTable we must run l'outil VerifyReplication sur le cluster source. Nous transmettons l'identifiant du pair comme l'un de ses paramètres afin qu'il puisse trouver le cluster distant à analyser pour comparaison :04:39 INFO mapreduce.Job : carte 100 % réduire 0 %20/05/04 11:04:39 INFO mapreduce.Job :tâche job_1588611196128_0001 terminée avec succès… HBase CountersBYTES_IN_REMOTE_RESULTS=2761955495BYTES_IN_RESULTS=5549784600…org. .replication.VerifyReplication$Verifier$CountersGOODROWS=100008...Sans aucune différence, SyncTable trouve tous les hachages correspondant entre les partitions source et cible et évite ainsi d'avoir à analyser à nouveau le cluster source distant. VerifyReplication effectue une comparaison une par une pour chaque cellule dans les deux clusters, ce qui peut déjà entraîner un coût de réseau élevé même lorsqu'il s'agit de si petits ensembles de données.
Ajouter une ligne supplémentaire dans le cluster source et effectuer à nouveau les vérifications. Avec VerifyReplication :
20/05/05 11:14:05 INFO mapreduce.Job :Tâche en cours d'exécution :job_1588611196128_0004…20/05/05 11:16:32 INFO mapreduce.Job : map 100% reduce 0%20/05/05 11 :16:32 INFO mapreduce.Job :tâche job_1588611196128_0004 terminée avec succès…org.apache.hadoop.hbase.mapreduce.replication.VerifyReplication$Verifier$CountersBADROWS=1GOODROWS=100008ONLY_IN_SOURCE_TABLE_ROWS=1…Avant de pouvoir utiliser SyncTable, nous devons à nouveau régénérer les hachages sur la source avec HashTable, car il y a maintenant une nouvelle cellule :
20/05/04 11:31:48 INFO mapreduce.Job :Tâche en cours :job_1588611196128_0003…20/05/04 11:33:15 INFO mapreduce.Job :tâche job_1588611196128_0003 terminée avec succès...Maintenant, SyncTable :
20/05/07 05:47:51 INFO mapreduce.Job :Tâche en cours :job_1588611199158_0014… 20/05/07 05:49:20 INFO mapreduce.Job :tâche job_1588611199158_0014 terminée avec succès… org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_NOT_MATCHED=97148MATCHINGCELLS=749593MATCHINGROWS=100008RANGESMATCHED=97147RANGESNOTMATCHED=1ROWSWITHDIFFS=1TARGETMISSINGCELLS=1TARGETMISSINGROWS=1Nous pouvons voir l'augmentation du temps d'exécution en raison de l'analyse supplémentaire et de la comparaison des cellules entre les deux clusters distants. Pendant ce temps, le temps d'exécution de VerifyReplication a montré peu de variation.
Conclusion
HashTable/SyncTable est un outil précieux pour déplacer les données, lorsqu'il s'agit de rares incohérences entre les ensembles de données de deux clusters. Il utilise le partitionnement et le hachage des données pour détecter efficacement les différences sur les plages des deux ensembles de données, réduisant ainsi le nombre de cellules à analyser tout en comparant les données des deux clusters, tout en évitant également les mises inutiles de valeurs déjà existantes dans le cluster cible. Ce n'est pas une solution miracle, cependant, comme le démontrent certains des exemples ci-dessus, bien qu'il puisse sembler se chevaucher en fonction avec le CopyTable outil, ce dernier peut offrir de meilleures performances lors de la gestion d'une gamme séquentielle plus large de cellules incompatibles. En ce sens, HashTable/SyncTable serait plus applicable dans les cas où les deux clusters contiennent déjà des données, ou dans les cas où une configuration de réplication existante a été interrompue par l'indisponibilité temporaire de l'un des pairs.
Articles associés :
https://blog.cloudera.com/apache-hbase-replication-overview/
https://blog.cloudera.com/approaches-to-backup-and-disaster-recovery-in-hbase/
https://blog.cloudera.com/online-apache-hbase-backups-with-copytable/
https://blog.cloudera.com/introduction-to-apache-hbase-snapshots/
