Les tables gérées sont des tables appartenant à Hive où l’ensemble du cycle de vie des données des tables est géré et contrôlé par Hive. Les tables externes sont des tables où Hive a un couplage lâche avec les données. Le gestionnaire de réplication réplique les tables externes avec succès vers un cluster cible. Les tables gérées sont converties en tables externes après la réplication.
Hive prend en charge la réplication des tables externes avec les données vers le cluster cible et il conserve toutes les propriétés des tables externes. La permission et la propriété des fichiers de données sont préservées afin que les processus externes concernés puissent continuer à y écrire même après le basculement.
Les écritures sur les tables externes sont effectuées à l’aide des commandes SQL de Hive et les fichiers de données peuvent également être accédés et gérés par des processus extérieurs à Hive. Si une table ou une partition externe est abandonnée, seules les métadonnées associées à la table ou à la partition sont supprimées, mais les fichiers de données sous-jacents restent intacts. Un exemple typique pour une table externe est d’exécuter des requêtes analytiques sur des données appartenant à HBase ou Druid en utilisant Hive, où les fichiers de données sont écrits par HBase ou Druid et Hive les lit pour l’analyse.
Lorsque vous créez une planification pour une politique de réplication Hive, définissez la fréquence de sorte que les changements soient répliqués assez souvent pour éviter des copies trop volumineuses.
Vous pouvez rencontrer les cas d’utilisation suivants pendant la réplication Hive :
Cas d’utilisation de mise à niveau du gestionnaire de réplication Dans un scénario normal, si vous aviez des tables externes qui étaient répliquées en tant que tables gérées, après le processus de mise à niveau, vous devez supprimer ces tables de la cible et définir le répertoire de base. Dans l’instance suivante, elles seront répliquées en tant que tables externes. Conflits dans l’emplacement des données des tables externes pour la réplication de plusieurs clusters source vers le même cluster cible Pour gérer les conflits dans l’emplacement des données des tables externes pour la réplication de plusieurs clusters source vers le même cluster cible, le gestionnaire de réplication affecte un répertoire de base unique pour chaque cluster source sous lequel les données des tables externes du cluster source correspondant sont copiées. Par exemple, si l’emplacement de la table externe dans un cluster source est /ext/hbase_data, l’emplacement dans le cluster cible après la réplication est <base_dir>/ext/hbase_data. Vous pouvez utiliser la commande DESCRIBE TABLE pour suivre le nouvel emplacement des tables externes. Conflits de réplication entre l’emplacement des tables externes HDFS et Hive Lorsque vous exécutez la politique de réplication Hive sur une table externe, les données sont stockées sur le répertoire cible à un emplacement spécifique. Ensuite, lorsque vous exécutez la politique de réplication HDFS qui tente de copier les données au même emplacement de table externe, Replication Manager s’assure que les données Hive ne sont pas remplacées par HDFS. Par exemple, lorsque vous exécutez une politique de réplication Hive sur une table externe, la politique crée un répertoire cible /tmp/db1/ext1. Lorsque vous exécutez une politique de réplication HDFS, la politique ne doit pas remplacer les données en répliquant sur le répertoire /tmp/db1/ext1. Conflits pendant le processus de réplication des tables externes Des conflits apparaissent lorsque deux politiques de réplication Hive sur DB1 et DB2 (provenant du même cluster source ou de clusters sources différents) ont des tables externes qui pointent vers le même emplacement de données (par exemple, /abc) et sont répliquées vers le même cluster cible. Pour éviter de tels conflits, vous devez définir des chemins différents pour la configuration du répertoire de base de la table externe pour les deux stratégies. Par exemple, définissez /db1 pour DB1 et /db2 pour DB2. Cela garantit que l’emplacement des données de la table externe cible est différent pour les deux bases de données. Par exemple, /db1/abcd et /db2/abcd.