Las tablas gestionadas son tablas propiedad de Hive en las que todo el ciclo de vida de los datos de las tablas es gestionado y controlado por Hive. Las tablas externas son tablas en las que Hive tiene un acoplamiento suelto con los datos. El Gestor de Replicación replica las tablas externas con éxito en un cluster de destino. Las tablas gestionadas se convierten en tablas externas después de la replicación.
Hive admite la replicación de tablas externas con datos al clúster de destino y conserva todas las propiedades de las tablas externas. El permiso y la propiedad de los archivos de datos se conservan para que los procesos externos pertinentes puedan seguir escribiendo en ellos incluso después de la conmutación por error.
Las escrituras en las tablas externas se realizan mediante los comandos SQL de Hive y los archivos de datos también pueden ser accedidos y gestionados por procesos externos a Hive. Si se elimina una tabla o partición externa, sólo se eliminan los metadatos asociados a la tabla o partición, pero los archivos de datos subyacentes permanecen intactos. Un ejemplo típico para una tabla externa es ejecutar consultas analíticas sobre datos propiedad de HBase o Druid utilizando Hive, donde los archivos de datos son escritos por HBase o Druid y Hive los lee para el análisis.
Cuando cree una programación para una política de replicación de Hive, establezca la frecuencia para que los cambios se repliquen con la suficiente frecuencia como para evitar copias demasiado grandes.
Es posible que se encuentre con los siguientes casos de uso durante la replicación de Hive:
Caso de uso de la actualización de Replication Manager En un escenario normal, si tenía tablas externas que se replicaban como tablas gestionadas, después del proceso de actualización, debe eliminar esas tablas del destino y establecer el directorio base. En la siguiente instancia se replican como tablas externas. Conflictos en la ubicación de los datos de las tablas externas para la replicación de varios clústeres de origen en el mismo clúster de destino Para gestionar los conflictos en la ubicación de los datos de las tablas externas para la replicación de varios clústeres de origen en el mismo clúster de destino, el Administrador de replicación asigna un único directorio base para cada clúster de origen en el que se copian los datos de las tablas externas del clúster de origen correspondiente. Por ejemplo, si la ubicación de la tabla externa en un clúster de origen es /ext/hbase_data, la ubicación en el clúster de destino después de la replicación es <base_dir>/ext/hbase_data. Puede utilizar el comando DESCRIBE TABLE para rastrear la nueva ubicación de las tablas externas. Conflictos de replicación entre HDFS y la ubicación de la tabla externa de Hive Cuando se ejecuta la política de replicación de Hive en una tabla externa, los datos se almacenan en el directorio de destino en una ubicación específica. A continuación, cuando se ejecuta la política de replicación de HDFS que intenta copiar los datos en la misma ubicación de la tabla externa, Replication Manager se asegura de que los datos de Hive no sean anulados por HDFS. Por ejemplo, cuando se ejecuta una política de replicación Hive en una tabla externa, la política crea un directorio de destino /tmp/db1/ext1. Cuando se ejecuta una política de replicación de HDFS, la política no debe anular los datos replicando en el directorio /tmp/db1/ext1. Conflictos durante el proceso de replicación de tablas externas Los conflictos aparecen cuando dos políticas de replicación de Hive en DB1 y DB2 (ya sea del mismo clúster de origen o de diferentes clústeres de origen) tienen tablas externas que apuntan a la misma ubicación de datos (por ejemplo, /abc) y se replican al mismo clúster de destino. Para evitar estos conflictos, debe establecer diferentes rutas para la configuración del directorio base de la tabla externa para ambas políticas. Por ejemplo, establezca /db1 para DB1 y /db2 para DB2. Esto garantiza que la ubicación de los datos de la tabla externa de destino sea diferente para ambas bases de datos. Por ejemplo, /db1/abcd y /db2/abcd.