Compartir a través de

Migración de cargas de trabajo de Hive de Azure HDInsight 3.6 a HDInsight 4.0

  • Artículo

HDInsight 4.0 tiene varias ventajas con respecto a HDInsight 3.6. Aquí se ofrece información general sobre las novedades de HDInsight 4.0.

En este artículo se describen los pasos para migrar cargas de trabajo de Hive de HDInsight 3.6 a la versión 4.0, lo cual incluye:

  • La copia del metastore de Hive y la actualización del esquema.
  • La migración segura para la compatibilidad con ACID.
  • La preservación de las directivas de seguridad de Hive.

Los clústeres de HDInsight nuevos y antiguos deben tener acceso a las mismas cuentas de almacenamiento.

La migración de tablas de Hive a una nueva cuenta de almacenamiento debe realizarse como paso independiente. Consulte Migración de Hive entre cuentas de almacenamiento.

Cambios en Hive 3 y novedades:

Cambios en el cliente de Hive

Hive 3 solo admite el cliente ligero, Beeline para ejecutar consultas y comandos administrativos de Hive desde la línea de comandos. Beeline usa una conexión JDBC a HiveServer para ejecutar todos los comandos. Las operaciones de análisis, compilación y ejecución se producen en HiveServer.

Para escribir comandos compatibles de la CLI de Hive, invoque Beeline mediante la palabra clave de Hive como usuario de Hive o invoque una beeline mediante beeline -u <JDBC URL>. Puede obtener la dirección URL de JDBC desde la página de Hive de Ambari.

Screenshot showing JDBC URL output.

El uso de Beeline (en lugar del cliente pesado de la CLI de Hive, que ya no es compatible) tiene varias ventajas, entre las que se incluyen:

  • En lugar de mantener toda la base de código de Hive, puede mantener solo el cliente JDBC.
  • La sobrecarga de inicio es menor mediante Beeline porque no está implicada toda la base de código de Hive.

También puede ejecutar el script de Hive, que se encuentra en el directorio "/usr/bin", que invoca una conexión de beeline mediante la dirección URL de JDBC.

Screenshot showing beeline connection output.

Una arquitectura de cliente ligero facilita la seguridad de los datos en

  • El estado de sesión, las estructuras de datos internas, las contraseñas, etc., residen en el cliente en lugar del servidor.
  • El pequeño número de demonios necesarios para ejecutar consultas simplifica la supervisión y la depuración.

HiveServer aplica la configuración de lista de permitidos y lista de bloqueados que puede cambiar mediante comandos SET. Con las listas de bloqueados, puede restringir la configuración de memoria para evitar la inestabilidad del servidor de Hive. Puede configurar varias instancias de HiveServer con diferentes listas de permitidos y listas de bloqueados para establecer distintos niveles de estabilidad.

Cambios en metastore de Hive

Hive ahora solo admite un metastore remoto en lugar de un metastore insertado (dentro de HS2 JVM). El metastore de Hive reside en un nodo de un clúster administrado por Ambari como parte de la pila de HDInsight. No se admite un servidor independiente fuera del clúster. Ya no se establecen comandos clave=valor en la línea de comandos para configurar el metastore de Hive. Basado en el valor configurado en el servicio HMS "hive.metastore.uris=' " " usado y conexión establecida.

Cambio del motor de ejecución

Apache Tez reemplaza a MapReduce como motor de ejecución de Hive predeterminado. MapReduce está en desuso a partir de Hive 2.0 Consulte HIVE-12300. Con expresiones de grafos acíclicos dirigidos (DAG) y primitivos de transferencia de datos, la ejecución de consultas de Hive en Tez mejora el rendimiento. Las consultas SQL que envía a Hive se ejecutan de la siguiente manera

  1. Hive compila la consulta.
  2. Tez ejecuta la consulta.
  3. YARN asigna recursos para las aplicaciones en el clúster y habilita la autorización para trabajos de Hive en colas de YARN.
  4. Hive actualiza los datos en ABFS o WASB.
  5. Hive devuelve los resultados de la consulta a través de una conexión JDBC.

Si un script o aplicación heredado especifica MapReduce para su ejecución, se produce una excepción como se indica a continuación

Screenshot showing map reducer exception output.

Nota:

La mayoría de las funciones definidas por el usuario (UDF) no requieren ningún cambio para ejecutarse en Tez en lugar de MapReduce.

Cambios con respecto a la transacción ACID y CBO:

  • Las tablas ACID son el tipo de tabla predeterminado en HDInsight 4.x sin sobrecarga operativa o de rendimiento.

  • Desarrollo simplificado de aplicaciones, operaciones con garantías transaccionales más sólidas y semántica más sencilla para comandos SQL

  • El sistema interno de Hive se encarga de la creación de cubos para las tablas ACID en HDInsight 4.1, eliminando así la sobrecarga de mantenimiento.

  • Optimizaciones avanzadas: actualización en CBO

  • Caché automática de consultas. La propiedad usada para habilitar el almacenamiento en caché de consultas es hive.query.results.cache.enabled. Debe establecer esta propiedad en true. Hive almacena la caché de resultados de la consulta en /tmp/hive/__resultcache__/. De manera predeterminada, Hive asigna 2 GB para la caché de resultados de la consulta. Puede cambiar esta configuración estableciendo el siguiente parámetro en hive.query.results.cache.max.size.

    Para más información, consulte Ventajas de migrar a Azure HDInsight 4.0.

Reescrituras de vistas materializadas

Para más información, en Hive: Vistas materializadas

Cambios después de actualizar a Apache Hive 3

Para buscar y usar las tablas de Apache Hive 3 después de una actualización, debe comprender los cambios que se producen durante el proceso de actualización. Cambios en la administración y ubicación de las tablas, los permisos para los directorios de tabla, los tipos de tabla y los problemas de cumplimiento de ACID.

Administración de Hive de tablas

Hive 3 toma más control de las tablas que Hive 2 y requiere que las tablas administradas cumplan una definición estricta. El nivel de control que Hive toma sobre tablas es homogéneo para las bases de datos tradicionales. Hive es consciente de los cambios delta de los datos; este marco de control mejora el rendimiento.

Por ejemplo, si Hive sabe que la resolución de una consulta no requiere el examen de tablas para nuevos datos, Hive devuelve los resultados de la caché de resultados de la consulta de Hive. Cuando cambian los datos subyacentes de una vista materializada, Hive debe recompilar la vista materializada. Las propiedades ACID revelan exactamente qué filas han cambiado y deben procesarse y agregarse a la vista materializada.

Cambios de Hive en las propiedades ACID

Hive 2.x y 3.x tienen tablas transaccionales (administradas) y no transaccionales (externas). Las tablas transaccionales tienen propiedades atómicas, coherentes, de aislamiento y duraderas (ACID). En Hive 2.x, la versión inicial del procesamiento de transacciones ACID es ACID v1. En Hive 3.x, las tablas predeterminadas serían con ACID v2.

Formatos de almacenamiento nativos y no nativos

Los formatos de almacenamiento son un factor en la actualización de los cambios en los tipos de tabla. Hive 2.x y 3.x admite los siguientes formatos de almacenamiento nativos y no nativos de Hadoop

Nativo: Tablas con compatibilidad integrada en Hive, en los siguientes formatos de archivo

  • Texto
  • Archivo de secuencia
  • Archivo RC
  • Archivo AVRO
  • Archivo ORC
  • Archivo Parquet

No nativo: Tablas que usan un controlador de almacenamiento, como DruidStorageHandler o HBaseStorageHandler

Cambios de actualización de HDInsight 4.x a los tipos de tabla

En la tabla siguiente se comparan los tipos de tabla de Hive y las operaciones ACID antes de una actualización de HDInsight 3.x y después de una actualización a HDInsight 4.x. La propiedad del archivo de tabla de Hive es un factor para determinar los tipos de tabla y las operaciones ACID después de la actualización

Comparación de tipos de tabla de HDInsight 3.x y HDInsight 4.x

HDInsight 3.x - - - HDInsight 4.x -
Tipo de tabla ACID v1 Formato Propietario (usuario) del archivo de tabla de Hive Tipo de tabla ACID v2
Externo No Nativo o no nativo Hive o no Hive Externo No
Administrado Sí ORC Hive o no Hive Administrado, actualizable Sí
Administrado No ORC Hive Administrado, actualizable Sí
Administrado No ORC no Hive Externo, con eliminación de datos No
Administrado No Nativo (pero no ORC) Hive Administrado, insertar solo Sí
Administrado No Nativo (pero no ORC) no Hive Externo, con eliminación de datos No
Administrado No No nativo Hive o no Hive Externo, con eliminación de datos No

Suplantación de Hive

La suplantación de colmena estaba habilitada de manera predeterminada en Hive 2 (doAs=true), y deshabilitada de manera predeterminada en Hive 3. La suplantación de Hive ejecuta Hive como usuario final o no.

Otros cambios de actualización de HDInsight 4.x

  1. Las tablas ACID administradas que no pertenecen al usuario de Hive permanecen administradas después de la actualización, pero Hive se convierte en el propietario.
  2. Después de la actualización, el formato de una tabla de Hive es el mismo que antes de la actualización. Por ejemplo, las tablas nativas o no nativas permanecen nativas o no nativas, respectivamente.

Cambios de ubicación

Después de la actualización, la ubicación de las tablas o particiones administradas no cambia en ninguna de las condiciones siguientes:

  • El directorio de tabla o partición anterior no estaba en su ubicación predeterminada /apps/hive/warehouse antes de la actualización.
  • La tabla o partición antigua se encuentra en un sistema de archivos diferente al del nuevo directorio de almacenamiento.
  • El directorio de partición o tabla anterior está en una zona de cifrado diferente a la del nuevo directorio de almacenamiento.

De lo contrario, cambia la ubicación de las tablas o particiones administradas. El proceso de actualización mueve los archivos administrados a /hive/warehouse/managed. De forma predeterminada, Hive coloca las tablas externas nuevas que cree en HDInsight 4.x en /hive/warehouse/external

El /apps/hive directory, que es la ubicación anterior del almacenamiento de Hive 2.x, podría existir o no en HDInsight 4.x

Los siguientes escenarios están presentes para los cambios de ubicación

Escenario 1

Si la tabla es una tabla administrada en HDInsight-3.x y si está presente en la ubicación /apps/hive/warehouse y se convierte como tabla externa en HDInsight-4.x, la ubicación también es la misma /apps/hive/warehouse en HDInsight 4.x. No cambia ninguna ubicación. Después de este paso, si va a realizar el comando alter table para convertirlo como tabla administrada (acid) en ese momento presente en la misma ubicación /apps/hive/warehouse.

Escenario 2

Si la tabla es una tabla administrada en HDInsight-3.x y si está presente en la ubicación /apps/hive/warehouse y se convierte en una tabla administrada (ACID) en HDInsight 4.x, la ubicación es /hive/warehouse/managed.

Escenario 3 Si va a crear una tabla externa, en HDInsight-4.x sin especificar ninguna ubicación, se presenta en la ubicación /hive/warehouse/external.

Conversión de tablas

Después de actualizar, para convertir una tabla no transaccional en una tabla transaccional ACID v2, use el comando ALTER TABLE y establezca las propiedades de tabla en

transaction'='true' and 'EXTERNAL'='false
  • La tabla administrada, el formato ORC distinto de ACID y propiedad del usuario que no es de Hive en HDInsight-3.x se convertirá en una tabla externa que no sea ACID en HDInsight-4.x.
  • Si el usuario desea cambiar la tabla externa (no ACID) a ACID, también debe cambiar la tabla externa a administrada y ACID. Dado que en HDInsight-4.x todas las tablas administradas son estrictamente ACID de forma predeterminada. No se pueden convertir las tablas externas (no ACID) en tabla ACID.

Nota

La tabla debe ser una tabla ORC.

Para convertir la tabla externa (no ACID) en una tabla administrada (ACID),

  1. Convierta la tabla externa en administrada y acid es igual a true mediante el siguiente comando: 
    alter table <table name> set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');
  2. Si intenta ejecutar el siguiente comando para la tabla externa, obtendrá el siguiente error.

Escenario 1

Considere la posibilidad de que la tabla rt sea externa (no ACID). Si la tabla no es ORC,

alter table rt set TBLPROPERTIES ('transactional'='true');
ERROR : FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. Unable to alter table. The table must be stored using an ACID compliant format (such as ORC): work.rt
The table must be ORC format

Escenario 2

>>>> alter table rt set TBLPROPERTIES ('transactional'='true'); If the table is ORC table.
ERROR:
Error: Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. Unable to alter table. work.rt can't be declared transactional because it's an external table (state=08S01,code=1)

Este error se produce porque la tabla rt es externa y no se puede convertir la tabla externa en ACID.

Escenario 3

>>>> alter table rt set TBLPROPERTIES ('EXTERNAL'='false');
ERROR:
Error: Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. Unable to alter table. Table work.rt failed strict managed table checks due to the following reason: Table is marked as a managed table but isn't transactional. (state=08S01,code=1)

Aquí estamos intentando cambiar primero la tabla externa a tabla administrada. En HDInsight 4.x, debe ser una tabla estrictamente administrada (lo que significa que debe ser ACID). Así que aquí tiene un interbloqueo. La única manera de convertir la tabla externa (NON_ACID) en administrada (ACID) es seguir el comando:

alter table rt set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');

Sintaxis y semántica

  • Creación de una tabla Para mejorar la capacidad de uso y la funcionalidad, Hive 3 cambió la creación de tablas. Hive ha cambiado la creación de tablas de las siguientes maneras

    • Crea una tabla compatible con ACID, que es el valor predeterminado en HDP
    • Admite escrituras e inserciones simples
    • Escrituras en varias particiones
    • Inserta varias actualizaciones de datos en una sola instrucción SELECT
    • Elimina la necesidad de crear cubos.

    Si tiene una canalización ETL que crea tablas en Hive, las tablas se crean como ACID. Hive ahora controla estrechamente el acceso y realiza la compactación periódicamente en las tablas

    Antes de la actualización En HDInsight 3.x, CREATE TABLE creaba de manera predeterminada una tabla no ACID.

    Después de la actualización De manera predeterminada, CREATE TABLE crea una tabla transaccional ACID completa en formato ORC.

    Acción requerida Para acceder a las tablas ACID de Hive desde Spark, debe conectarse a Hive usando el Conector de almacén de Hive (HWC). Para escribir tablas ACID en Hive desde Spark, use la API de HWC y HWC

  • Escape de referencias db.table

    Debe cambiar las consultas que usan referencias db.table para evitar que Hive interprete toda la cadena db.table como nombre de tabla. Hive 3.x rechaza db.table en consultas SQL. No se permite un punto (.) en los nombres de tabla. Debe incluir el nombre de la base de datos y el nombre de la tabla entre acentos graves. Busque una tabla que tenga la referencia de tabla problemática. math.students que aparece en una instrucción CREATE TABLE. Incluya el nombre de la base de datos y el nombre de la tabla entre acentos graves.

    TABLE `math`.`students` (name VARCHAR(64), age INT, gpa DECIMAL(3,2));

  • CONVERSIÓN DE MARCAS DE TIEMPO Los resultados de las aplicaciones que convierten valores numéricos en marcas de tiempo difieren de Hive 2 a Hive 3. Apache Hive cambió el comportamiento de CAST para cumplir con el estándar SQL, que no asocia una zona horaria con el tipo TIMESTAMP.

    Antes de la actualización Se podía usar la conversión de un valor de tipo numérico en una marca de tiempo para obtener un resultado que reflejara la zona horaria del clúster. Por ejemplo, 1597217764557 es 2020-08-12 00:36:04 PDT. Al ejecutar la consulta siguiente, se convierte el valor numérico en una marca de tiempo en PDT: SELECT CAST(1597217764557 AS TIMESTAMP); | 2020-08-12 00:36:04 |

    Después de la actualización La conversión de un valor de tipo numérico en una marca de tiempo genera un resultado que refleja la hora UTC en lugar de la zona horaria del clúster. La ejecución de la consulta convierte el valor numérico en una marca de tiempo en UTC. SELECT CAST(1597217764557 AS TIMESTAMP); | 2020-08-12 07:36:04.557 |

    Acción requerida Cambie las aplicaciones. No convierta desde un número para obtener una zona horaria local. Las funciones integradas from_utc_timestamp y to_utc_timestamp se pueden usar 1para imitar el comportamiento antes de la actualización.

  • COMPROBACIÓN DE LA COMPATIBILIDAD DE LOS CAMBIOS DE COLUMNA Un cambio de configuración predeterminado puede hacer que fallen las aplicaciones que cambien los tipos de columna.

    Antes de la actualización En HDInsight 3.x Hive.metastore.disallow.incompatible.col.type.changes es false de manera predeterminada para permitir cambios en tipos de columnas incompatibles. Por ejemplo, puede cambiar una columna STRING a una columna de un tipo incompatible, como MAP<STRING, STRING>. No se produce ningún error.

    Después de la actualización Hive.metastore.disallow.incompatible.col.type.changes es true de manera predeterminada. Hive evita cambios en tipos de columna incompatibles. No se bloquean los cambios de tipo de columna compatibles, como INT, STRING, BIGINT.

    Acción requerida Cambie las aplicaciones para que no permitan cambios incompatibles de tipo de columna para evitar posibles daños en los datos.

  • ANULACIÓN DE PARTICIONES

    Las palabras clave OFFLINE y NO_DROP de la cláusula CASCADE para anular particiones provocan problemas de rendimiento y ya no se admiten.

    Antes de la actualización Podía usar las palabras clave OFFLINE y NO_DROP en la cláusula CASCADE para evitar que las particiones se leyeran o se anularan.

    Después de la actualización OFFLINE y NO_DROP no se admiten en la cláusula CASCADE.

    Acción requerida Cambie las aplicaciones para quitar OFFLINE y NO_DROP de la cláusula CASCADE. Use un esquema de autorización, como Ranger, para evitar que las particiones se anulen o lean.

  • CAMBIO DEL NOMBRE DE UNA TABLA Tras la actualización Cambio del nombre de una tabla administrada traslada su ubicación solo si la tabla se crea sin una cláusula LOCATION y se encuentra bajo su directorio de base de datos.

Limitaciones con respecto a CBO

  • Vemos que la salida select da ceros al final en algunas columnas. Por ejemplo, si tenemos una columna de tabla con tipo de datos como decimal(38,4) y si insertamos datos como 38 agrega los ceros finales y proporciona el resultado como 38.0000 Según https://issues.apache.org/jira/browse/HIVE-12063 y https://issues.apache.org/jira/browse/HIVE-24389, la idea es conservar la escala y la precisión en lugar de ejecutar un contenedor en las columnas decimales. Este es el comportamiento predeterminado desde Hive 2. Para corregir este problema, puede usar la opción siguiente.

    1. Modifique el tipo de datos en el nivel de origen para ajustar la precisión como col1(decimal(38,0)). Este valor proporciona el resultado como 38 sin cero final. Pero si inserta los datos como 35.0005, es .0005 y solo proporciona el valor como 38 1.Quite los ceros finales de las columnas con problemas y, a continuación, convierta en cadena,
      1. Use select TRIM(cast(<column_name> AS STRING)+0 FROM <table_name>;
      2. Use regex.

  1. Se produce un error en la consulta de Hive con "Expresión de subconsulta no admitida" cuando se usa UNIX_TIMESTAMP en la consulta. Por ejemplo, si ejecutamos una consulta, se produce un error "Expresión de subconsulta no admitida"

    select * from
(SELECT col_1 from table1 where col_2 >= unix_timestamp('2020-03-07','yyyy-MM-dd'));

    El caso raíz de este problema es que el código base de Hive actual está iniciando una excepción que analiza el UNIX_TIMESTAMP porque no hay ninguna asignación de precisión en HiveTypeSystemImpl.java code para la precisión de UNIX_TIMESTAMP que Calcite reconoce como BIGINT. Pero la consulta siguiente funciona bien select * from (SELECT col_1 from table1 where col_2 >= 1);

    Este comando se ejecuta correctamente, ya que col_2 es un entero. El problema anterior se solucionó en hdi-3.1.2-4.1.12(pila 4.1) y hdi-3.1.2-5.0.8(pila 5.0)

Pasos para actualizar

1. Preparación de los datos

  • La versión 3.6 de HDInsight de manera predeterminada no es compatible con las tablas ACID. Sin embargo, si hay tablas ACID, ejecute la compactación "MAYOR" en ellas. Para más información sobre la compactación, consulte el manual del lenguaje Hive.

  • Si usa Azure Data Lake Storage Gen1, es probable que las ubicaciones de las tablas de Hive dependan de las configuraciones de HDFS del clúster. Ejecute la siguiente acción de script para que estas ubicaciones se puedan llevar a otros clústeres. Consulte Acción de script a un clúster en ejecución.

    Propiedad Value
    URI de script de Bash https://hdiconfigactions.blob.core.windows.net/linuxhivemigrationv01/hive-adl-expand-location-v01.sh
    Tipos de nodo Head
    Parámetros

2. Copia de la base de datos SQL

  • Si el clúster usa un metastore de Hive predeterminado, siga esta guía para exportar los metadatos en un metastore externo. A continuación, cree una copia del metastore externo para la actualización.

  • Si el clúster usa un metastore de Hive externo, cree una copia de este. Entre las opciones se incluyen exportación/importación y restauración a un momento dado.

3. Actualización del esquema del metastore

En este paso se usa Hive Schema Tool desde HDInsight 4.0 para actualizar el esquema de del metastore.

Advertencia

Este paso no es reversible. Ejecútelo solo en una copia del metastore.

  1. Cree un clúster de HDInsight 4.0 temporal para acceder a schematool de Hive 4.0. Puede usar el metastore de Hive predeterminado para este paso.

  2. Desde el clúster de HDInsight 4.0, ejecute schematool para actualizar el metastore de HDInsight 3.6 de destino. Edite el siguiente script de shell para agregar el nombre del servidor SQL, el nombre de la base de datos, el nombre de usuario y la contraseña. Abra una sesión SSH en el nodo principal y ejecútelo.

    SERVER='servername.database.windows.net'  # replace with your SQL Server
DATABASE='database'  # replace with your 3.6 metastore SQL Database
USERNAME='username'  # replace with your 3.6 metastore username
PASSWORD='password'  # replace with your 3.6 metastore password
STACK_VERSION=$(hdp-select status hive-server2 | awk '{ print $3; }')
/usr/hdp/$STACK_VERSION/hive/bin/schematool -upgradeSchema -url "jdbc:sqlserver://$SERVER;databaseName=$DATABASE;trustServerCertificate=false;encrypt=true;hostNameInCertificate=*.database.windows.net;" -userName "$USERNAME" -passWord "$PASSWORD" -dbType "mssql" --verbose

    Nota

    Esta utilidad usa beeline del cliente para ejecutar scripts de SQL en /usr/hdp/$STACK_VERSION/hive/scripts/metastore/upgrade/mssql/upgrade-*.mssql.sql.

    La sintaxis de SQL de estos scripts no es necesariamente compatible con otras herramientas de cliente. Por ejemplo, SSMS y el editor de consultas de Azure Portal requieren la palabra clave GO después de cada comando.

    Si se produce un error en algún script debido a la capacidad de los recursos o a los tiempos de espera de las transacciones, escale verticalmente SQL Database.

  3. Compruebe la versión final con la consulta select schema_version from dbo.version.

    La salida debe coincidir con la del siguiente comando de Bash desde el clúster de HDInsight 4.0.

    grep . /usr/hdp/$(hdp-select --version)/hive/scripts/metastore/upgrade/mssql/upgrade.order.mssql | tail -n1 | rev | cut -d'-' -f1 | rev

  4. Elimine el clúster de HDInsight 4.0 temporal.

4. Implementar un nuevo clúster de HDInsight 4.0

Cree un nuevo clúster de HDInsight 4.0; para ello, seleccione el metastore de Hive actualizado y las mismas cuentas de almacenamiento.

  • El nuevo clúster no requiere el mismo sistema de archivos predeterminado.

  • Si el metastore contiene tablas que residen en varias cuentas de almacenamiento, debe agregar esas cuentas de almacenamiento al nuevo clúster para acceder a estas tablas. Consulte Adición de más cuentas de almacenamiento a HDInsight.

  • Si se produce un error en los trabajos de Hive debido a la inaccesibilidad del almacenamiento, compruebe que la tabla se encuentra en una cuenta de almacenamiento agregada al clúster.

    Use el siguiente comando de Hive para identificar la ubicación de la tabla:

    SHOW CREATE TABLE ([db_name.]table_name|view_name);

5. Conversión de tablas para la compatibilidad con ACID

Las tablas administradas deben ser compatibles con ACID en HDInsight 4.0. Ejecute strictmanagedmigration en HDInsight 4.0 para convertir todas las tablas administradas distintas de ACID en tablas externas con la propiedad 'external.table.purge'='true'. Ejecute desde el nodo principal:

sudo su - hive
STACK_VERSION=$(hdp-select status hive-server2 | awk '{ print $3; }')
/usr/hdp/$STACK_VERSION/hive/bin/hive --config /etc/hive/conf --service strictmanagedmigration --hiveconf hive.strict.managed.tables=true -m automatic --modifyManagedTables

6. Error de clase no encontrada con MultiDelimitSerDe

Problema

En determinadas situaciones, cuando se ejecuta una consulta de Hive, es posible que reciba java.lang.ClassNotFoundException, lo que indica que la clase org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe no se encuentra la clase. Este error se produce cuando el cliente migra de HDInsight 3.6 a HDInsight 4.0. La clase SerDe org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe, que forma parte de hive-contrib-1.2.1000.2.6.5.3033-1.jar en HDInsight 3.6 y se usa la clase org.apache.hadoop.hive.serde2.MultiDelimitSerDe, que forma parte de hive-exec jar en HDI-4.0. hive-exec jar se cargará en HS2 de forma predeterminada cuando se inicie el servicio.

PASOS PARA SOLUCIONAR PROBLEMAS

  1. Compruebe si algún archivo JAR de una carpeta (es probable que esté en la carpeta de bibliotecas de Hive, que es /usr/hdp/current/hive/lib en HDInsight) contenga esta clase o no.
  2. Compruebe las clases org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe y org.apache.hadoop.hive.serde2.MultiDelimitSerDe como se mencionó en la solución.

Solución

  1. Aunque un archivo JAR es un archivo binario, puede usar el comando grep con los modificadores -Hrni como se indica a continuación para buscar un nombre de clase determinado.

    grep -Hrni "org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe" /usr/hdp/current/hive/lib

  2. Si no encontró la clase, no devolverá ninguna salida. Si encuentra la clase en un archivo JAR, devolverá la salida.

  3. A continuación se muestra el ejemplo tomado de un clúster de HDInsight 4.x.

    sshuser@hn0-alters:~$ grep -Hrni "org.apache.hadoop.hive.serde2.MultiDelimitSerDe" /usr/hdp/4.1.9.7/hive/lib/
Binary file /usr/hdp/4.1.9.7/hive/lib/hive-exec-3.1.0.4.1-SNAPSHOT.jar matches

  4. En la salida anterior, podemos confirmar que ningún archivo jar contiene la clase org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe y que hive-exec jar contiene org.apache.hadoop.hive.serde2.MultiDelimitSerDe.

  5. Pruebe a crear la tabla con el formato de fila DerDe como ROW FORMAT SERDE org.apache.hadoop.hive.serde2.MultiDelimitSerDe

  6. Este comando corregirá el problema. Si ya ha creado la tabla, puede usar los siguientes comandos para cambiar el nombre.

    Hive => ALTER TABLE TABLE_NAME SET SERDE 'org.apache.hadoop.hive.serde2.MultiDelimitSerDe'
Backend DB => UPDATE SERDES SET SLIB='org.apache.hadoop.hive.serde2.MultiDelimitSerDe' where SLIB='org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe';

El comando update se usa para actualizar los detalles manualmente en la base de datos de back-end, mientras que el comando alter se usa para modificar la tabla con la nueva clase SerDe desde beeline o Hive.

Script de comparación de esquemas de base de datos de back-end de Hive

Puede ejecutar el siguiente script después de completar la migración.

Existe la posibilidad de que falten algunas columnas en la base de datos del back-end, lo que provoca fallos en la consulta. Si la actualización del esquema no se ha realizado correctamente, existe la posibilidad de que nos encontremos con el problema del nombre de columna no válido. El siguiente script captura el nombre de columna y el tipo de datos de la base de datos de back-end del cliente y proporciona la salida si falta alguna columna o tipo de datos incorrecto.

La siguiente ruta de acceso contiene el archivo schemacompare_final.py y test.csv. El script está presente en el archivo "schemacompare_final.py" y el archivo "test.csv" contiene todo el nombre de columna y el tipo de datos de todas las tablas, que deben estar presentes en la base de datos de back-end de Hive.

https://hdiconfigactions2.blob.core.windows.net/hiveschemacompare/schemacompare_final.py

https://hdiconfigactions2.blob.core.windows.net/hiveschemacompare/test.csv

Descargue estos dos archivos desde el vínculo. Y copie estos archivos en uno de los nodos principales donde se esté ejecutando el servicio Hive.

Pasos para ejecutar el script:

Cree un directorio denominado "schemacompare" en el directorio "/tmp".

Coloque "schemacompare_final.py" y "test.csv" en la carpeta "/tmp/schemacompare". Realice "ls -ltrh /tmp/schemacompare/" y compruebe si los archivos están presentes.

Para ejecutar el script de Python, use el comando "python schemacompare_final.py". Este script comienza a ejecutar el script y tarda menos de cinco minutos en completarse. El script anterior se conecta automáticamente a la base de datos de back-end y captura los detalles de cada tabla, que Hive usa y actualiza los detalles en el nuevo archivo csv denominado "return.csv". Después de crear el archivo return.csv, compara los datos con el archivo "test.csv" e imprime el nombre de columna o el tipo de datos si falta algo en el nombre de tabla.

Una vez que haya ejecutado el script, puede ver las siguientes líneas, que indican que los detalles se capturan para las tablas y el script está en curso

KEY_CONSTRAINTS
Details Fetched
DELEGATION_TOKENS
Details Fetched
WRITE_SET
Details Fetched
SERDES
Details Fetched

Y puede ver los detalles de la diferencia en la línea "DETALLES DE LA DIFERENCIA:". Si hay alguna diferencia, imprime

PART_COL_STATS;
('difference', ['BIT_VECTOR', 'varbinary'])
The line with semicolon PART_COL_STATS; is the table name. And under the table name you can find the differences as ('difference', ['BIT_VECTOR', 'varbinary']) if there are any difference in column or datatype.

Si no hay diferencias en la tabla, la salida es

BUCKETING_COLS;
('difference', [])
PARTITIONS;
('difference', [])

A partir de esta salida, puede encontrar los nombres de columna que faltan o son incorrectos. Puede ejecutar la consulta siguiente en la base de datos de back-end para comprobar una vez si falta o no la columna.

SELECT * FROM INFORMATION_SCHEMA.columns WHERE TABLE_NAME = 'PART_COL_STATS';

En caso de que alguna de las columnas falte en la tabla, por ejemplo, si ejecutamos las consultas como insert o insert overwrite entonces las estadísticas se calcularán automáticamente e intentará actualizar la tabla de estadísticas como PART_COL_STATS y TAB_COL_STATS. Y si falta la columna como "BIT_VECTOR" en las tablas, se producirá un error "Nombre de columna no válido". Puede agregar la columna como se mencionó en los siguientes comandos. Como solución alternativa, puede deshabilitar las estadísticas estableciendo las siguientes propiedades, que no pueden actualizar las estadísticas en la base de datos de back-end.

hive.stats.autogather=false;
hive.stats.column.autogather=false;
To Fix this issue, run the following two queries on backend SQL server (Hive metastore DB):

ALTER TABLE PART_COL_STATS ADD BIT_VECTOR VARBINARY(MAX);
ALTER TABLE TAB_COL_STATS ADD BIT_VECTOR VARBINARY(MAX);

Este paso evita los errores de consulta, que producen un error con "Nombre de columna no válido" una vez después de la migración.

Protección de Hive en diferentes versiones de HDInsight

Opcionalmente, HDInsight se integra con Microsoft Entra ID mediante Enterprise Security Package (ESP) de HDInsight. ESP utiliza Kerberos y Apache Ranger para administrar los permisos de recursos específicos dentro del clúster. Las directivas de Ranger implementadas con Hive en HDInsight 3.6 se pueden migrar a HDInsight 4.0 con los pasos siguientes:

  1. Vaya al panel de Ranger Service Manager en el clúster de HDInsight 3.6.
  2. Vaya a la directiva denominada HIVE y expórtela a un archivo json.
  3. Asegúrese de que todos los usuarios a los que se hace referencia en el archivo json de directiva exportada existen en el nuevo clúster. Si en el json de directiva aparece una referencia a un usuario que no existe en el nuevo clúster, tendrá que agregar el usuario al nuevo clúster o quitar la referencia de la directiva.
  4. Vaya al panel de Ranger Service Manager en el clúster de HDInsight 4.0.
  5. Vaya a la directiva denominada HIVE e importe el archivo json de directiva de ranger del paso 2.

Cambios de Hive en HDInsight 4.0 que pueden requerir cambios en la aplicación

Consulte el anuncio de HDInsight 4.0 para otros cambios.

Después de la migración

Asegúrese de seguir estos pasos después de completar la migración.

Integridad de la tabla

  1. Vuelva a crear tablas en Hive 3.1 mediante CTAS o IOW para cambiar el tipo de tabla en lugar de cambiar las propiedades de la tabla.
  2. Mantenga doAs como false.
  3. Asegúrese de que la propiedad de las tablas/datos administrados corresponde al usuario "hive".
  4. Use tablas ACID administradas si el formato de tabla es ORC y no ACID administrado para tipos que no son ORC.
  5. Vuelva a generar estadísticas en tablas recreadas, ya que la migración habría provocado estadísticas incorrectas.

Estado del clúster

Si varios clústeres comparten el mismo almacenamiento y la misma base de datos de HMS, deberíamos habilitar los subprocesos de autocompactación/compactación solo en un clúster y deshabilitarlos en todos los demás.

Ajuste el metastore para reducir su uso de la CPU.

  1. Deshabilite los agentes de escucha de eventos transaccionales.

    Nota

    Realice los pasos siguientes, solo si no se usa la característica de replicación de Hive.

    1. En la interfaz de usuario de Ambari, quite el valor de hive.metastore.transactional.event.listeners.
    2. Valor predeterminado: org.apache.hive.hcatalog.listener.DbNotificationListener
    3. Valor nuevo: <Empty>

  2. Deshabilite PrivilegeSynchronizer de Hive

    1. En la interfaz de usuario de Ambari, establezca hive.privilege.synchronizer = false.
    2. Valor predeterminado: true
    3. Valor nuevo: false

  3. Optimización de la característica de reparación de particiones

  4. Deshabilitar la reparación de particiones: esta característica se usa para sincronizar las particiones de las tablas de Hive en la ubicación de almacenamiento con el metastore de Hive. Puede deshabilitar esta característica si se usa "msck repair" después de la ingesta de datos.

  5. Para deshabilitar la característica , agregue "discover.partitions=false" en las propiedades de la tabla mediante ALTER TABLE. O (si la característica no se puede deshabilitar)

  6. Aumente la frecuencia de reparación de la partición.

  7. Desde la interfaz de usuario de Ambari, aumente el valor de "metastore.partition.management.task.frequency" (en segundos).

    Nota

    Este cambio puede retrasar la visibilidad de algunas de las particiones ingeridas en el almacenamiento.

    1. Valor predeterminado: 60
    2. Valor propuesto: 3600

  8. Optimizaciones avanzadas Las siguientes opciones deben probarse en un entorno inferior (no de producción) antes de aplicarlas en producción.

    1. Quite el agente de escucha relacionado con la vista materializada si no se usa la vista materializada.
    2. En la interfaz de usuario de Ambari, agregue una propiedad personalizada (en hive-site.xml personalizado) y quite los subprocesos de metastore en segundo plano no deseados.
    3. Nombre de propiedad: metastore.task.threads.remote
    4. Valor predeterminado: N/A (it uses few class names internally)
    5. Valor nuevo: org.apache.hadoop.hive.metastore.txn.AcidHouseKeeperService,org.apache.hadoop.hive.metastore.txn.AcidOpenTxnsCounterService,org.apache.hadoop.hive.metastore.txn.AcidCompactionHistoryService,org.apache.hadoop.hive.metastore.txn.AcidWriteSetService,org.apache.hadoop.hive.metastore.PartitionManagementTask

  9. Deshabilite los subprocesos en segundo plano si la replicación está deshabilitada.

    1. En la interfaz de usuario de Ambari, agregue una propiedad personalizada (en hive-site.xml personalizado) y quite los subprocesos no deseados.
    2. Nombre de propiedad: metastore.task.threads.always
    3. Valor predeterminado: N/A (it uses few class names internally)
    4. Valor nuevo: org.apache.hadoop.hive.metastore.RuntimeStatsCleanerTask

optimización de consultas

  1. Mantenga las configuraciones predeterminadas de Hive para ejecutar las consultas a medida que estén optimizadas para las cargas de trabajo de TPC-DS. Solo necesita el ajuste de nivel de consulta si se produce un error o se ejecuta lentamente.
  2. Asegúrese de que las estadísticas están actualizadas para evitar un plan incorrecto o resultados incorrectos.
  3. Evite mezclar tablas ACID externas y administradas en el tipo de combinación de consultas. En tal caso, intente convertir una tabla externa a una tabla no ACID administrada a través de la recreación.
  4. En Hive-3, se trabajó mucho en la vectorización, la CBO, la marca de tiempo con zona, etc., lo que puede tener errores de producto. Por lo tanto, si alguna consulta proporciona resultados incorrectos, intente deshabilitar la vectorización, CBO, la combinación de asignación, etc., para ver si eso ayuda.

Otros pasos que se deben seguir para corregir los resultados incorrectos y un rendimiento deficiente después de la migración

  1. Problema La consulta de Hive proporciona el resultado incorrecto. Incluso la consulta select count(*) proporciona el resultado incorrecto.

    Causa La propiedad "hive.compute.query.using.stats" está establecida en true, de manera predeterminada. Si se establece en true, se usan las estadísticas, que se almacenan en el metastore para ejecutar la consulta. Si las estadísticas no están actualizadas, se producirán resultados incorrectos.

    Resolución recopile las estadísticas de las tablas administradas usando el comando alter table <table_name> compute statics; a nivel de tabla y a nivel de columna. Vínculo de referencia: https://cwiki.apache.org/confluence/display/hive/statsdev#StatsDev-TableandPartitionStatistics

  2. Problema Las consultas de Hive tardan mucho tiempo en ejecutarse.

    Causa Si la consulta tiene una condición de combinación, Hive crea un plan de si se debe usar combinación de asignación o de fusión en función del tamaño de tabla y la condición de combinación. Si una de las tablas contiene un tamaño pequeño, carga esa tabla en la memoria y realiza la operación de combinación. De este modo, la ejecución de la consulta es más rápida en comparación con la combinación de fusión.

    Resolución Asegúrese de establecer la propiedad "hive.auto.convert.join=true", que es el valor predeterminado. Si se establece en false, se usa la combinación de fusión y se puede producir un rendimiento deficiente. Hive decide si usar la combinación de asignación o no en función de las siguientes propiedades, que se establecen en el clúster

    set hive.auto.convert.join=true;
set hive.auto.convert.join.noconditionaltask=true;
set hive.auto.convert.join.noconditionaltask.size=<value>;
set hive.mapjoin.smalltable.filesize = <value>;

    La combinación común se puede convertir a la combinación de asignación automáticamente, cuando hive.auto.convert.join.noconditionaltask=true, si el tamaño estimado de las tablas pequeñas es menor que el subárbol.auto.convert.join.noconditionaltask.size (el valor predeterminado es 10 000 000 MB).

    Si tiene algún problema relacionado con OOM estableciendo la propiedad hive.auto.convert.join en true, es aconsejable establecerla en false solo para esa consulta concreta en el nivel de sesión y no en el nivel de clúster. Este problema puede producirse si las estadísticas son incorrectas y Hive decide usar la combinación de asignación en función de las estadísticas.

  • Problema La consulta de Hive proporciona el resultado incorrecto si la consulta tiene una condición de combinación y las tablas implicadas tienen valores NULL o vacíos.

    Causa A veces, podemos obtener un problema relacionado con valores NULL si las tablas implicadas en la consulta tienen muchos valores NULL. Hive realiza la optimización de consultas de forma incorrecta con los valores NULL implicados, lo que da como resultado resultados incorrectos.

    Resolución Se recomienda intentar establecer la propiedad set hive.cbo.returnpath.hiveop=true en el nivel de sesión si obtiene resultados incorrectos. Esta configuración presenta el filtrado no nulo en las claves de combinación. Si las tablas tenían muchos valores NULL, para optimizar la operación de combinación entre varias tablas, podemos habilitar esta configuración para que tenga en cuenta solo los valores no NULL.

  • Problema La consulta de Hive proporciona el resultado incorrecto si la consulta tiene varias condiciones de combinación.

    Causa A veces Tez produce planes en tiempo de ejecución erróneos cuando hay combinaciones iguales varias veces con map-joins.

    Resolución Existe la posibilidad de obtener resultados incorrectos cuando se establece hive.merge.nway.joins en false. Intente establecerlo en true solo para la consulta que se ha visto afectada. Esto ayuda a consultar con varias combinaciones en la misma condición, combinar combinaciones en un único operador de combinación. Este método es útil si hay combinaciones aleatorias grandes para evitar una fase de reorganización.

  • Problema: hay un aumento en el tiempo de ejecución de la consulta día a día en comparación con las ejecuciones anteriores.

    Causa Este problema puede producirse si hay un aumento en más números de archivos pequeños. Por lo tanto, Hive tarda tiempo en leer todos los archivos para procesar los datos, lo que da lugar a un aumento del tiempo de ejecución.

    Resolución Asegúrese de ejecutar la compactación con frecuencia para las tablas, que son administradas. Este paso evita los archivos pequeños y mejora el rendimiento.

    Vínculo de referencia: Transacciones de Hive: Apache Hive: Apache Software Foundation.

  • Problema La consulta de Hive proporciona un resultado incorrecto cuando el cliente usa una condición de combinación en una tabla orc ACID administrada y una tabla orc no ACID administrada.

    Causa Desde HIVE 3 en adelante, se solicita estrictamente mantener todas las tablas administradas como una tabla acid. Y si queremos mantenerla como una tabla acid, el formato de tabla debe ser orc y este es el criterio principal. Pero si deshabilitamos la propiedad de tabla administrada estricta "hive.strict.managed.tables" en false, podemos crear una tabla no ACID administrada. En algunos casos el cliente crea una tabla ORC externa o después de la migración la tabla se convierte en una tabla externa y desactivan la propiedad de tabla administrada estricta y la convierten en tabla administrada. En este punto, la tabla se convierte al formato orc no ACID administrada.

    Resolución La optimización de Hive falla si se une una tabla ORC no ACID administrada con una tabla con ORC ACID administrada.

    Si va a convertir una tabla externa en una tabla administrada,

    1. No establezca la propiedad "hive.strict.managed.tables" en false. Si la establece, puede crear una tabla no ACID administrada, pero no se solicita en HIVE-3
    2. Convierta la tabla externa en tabla administrada usando el siguiente comando alter en lugar de alter table <table_name> set TBLPROPERTIES ('EXTERNAL'='false');
    alter table rt set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');

Guía de solución de problemas

La guía de solución de problemas de HDInsight 3.6 a 4.0 para cargas de trabajo de Hive proporciona respuestas a problemas comunes que surgen al migrar cargas de trabajo de Hive de HDInsight 3.6 a HDInsight 4.0.

Lecturas adicionales