Cómo depurar Hive

Este artículo resume el método DEBUG que uso cuando uso HQL para realizar operaciones de consulta. Tiene principalmente los siguientes ejes:

Abrir registro de DEBUG de Hive

Explicación

Ver. plan.xml

Uso de IDE para depuración remota

La siguiente es una breve descripción del método. Cuando ocurra un problema, ábralo primero, puede haber información útil. Además, también podemos generar algunos registros DEBUG desde nuestra propia UDF o SerDe para facilitar la localización del problema:

hive -hiveconf hive.root.logger=DEBUG,console

explica

p>

Es decir, agregue EXPLAIN delante de HQL, por ejemplo:

EXPLAIN SELECT * FROM...

Pero esto no es muy útil cuando comprobamos errores. Tampoco lo usamos para localizar ningún error, pero puede ser útil al verificar algunos problemas de rendimiento o observar la ejecución de tareas de MR por parte de Hive.

Ver plan.xml

Primero, Necesito hablar sobre la ejecución de Hive. El proceso específico es el siguiente:

El cliente Hive (generalmente Hive cli, clase de entrada CliDriver) convierte HQL en un plan de ejecución MR (árbol de operadores) y lo serializa en plan.xml

Cargue plan.xml a hdfs

El cliente Honeycomb inicia un nuevo proceso y envía el programa MapReduce con la clase de entrada ExecDriver. El asignador de ExecDriver leerá plan.xml durante la fase de configuración y lo revertirá a un. Estructura de árbol del operador y luego ejecutarla.

Por lo tanto, plan.xml describe con precisión el proceso de ejecución específico del programa MR, y el archivo xml tiene una jerarquía clara, información más rica que el resultado de la explicación y es muy fácil de leer. Los planes de ejecución de MR rara vez tienen problemas, pero podemos usar plan.xml para eliminar algunos problemas sospechosos, como confirmar si hay un problema en la fase de traducción o en la fase de ejecución de MR. Hay un parámetro que resulta confuso:

SET hive.exec.mode.local.auto=false;

Esto en realidad es una optimización de Hive. Cuando Hive lo considera apropiado, lo hace. habilitará automáticamente el modo local para cálculos más rápidos (útil para tamaños de datos más pequeños). Por lo tanto, configurar este parámetro no necesariamente da como resultado la ejecución en modo local.

Agregar parámetros de depuración remota en la JVM

Estos parámetros son relativamente simples y se presentan en muchos artículos (pero creo que este artículo de IBM es el mejor):

-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address= 8765

suspend=y es para darnos la oportunidad de adjuntar el IDE al proceso que se está depurando, de lo contrario esto Es otro trabajo que corre contra el tiempo.

El problema es que desde el inicio de Hive hasta la ejecución del programa MR, hay dos JVM (o solo una, más detalles más adelante) que deben iniciarse:

hive cli requiere una clase de entrada como JVM de CliDriver

El programa MR requiere una JVM con la clase de entrada ExecDriver

Esperamos realizar una depuración general en el proceso de depuración.

Generalmente, queremos depurar el código durante la fase MR, por lo que debemos asegurarnos de no escuchar el puerto de depuración al iniciar la primera JVM y solo agregar los parámetros anteriores en la segunda. JVM. O al menos use puertos diferentes en ambas etapas; de lo contrario, la segunda JVM no se iniciará si hay un conflicto de puertos.

hive inicia CliDriver y ExecDriver a través de "hadoop jar". Por lo tanto, se pueden agregar parámetros JVM a través de la variable de entorno HADOOP_CLIENT_OPTS. Sin embargo, es imposible exportar HADOOP_CLIENT_OPTS directamente porque Hive primero debe llamar a la versión de hadoop para determinar la versión antes de llamar a HADOOP_CLIENT_OPTS para determinar la versión de hadoop y HADOOP_CLIENT_OPTS para determinar. la versión para la versión de hadoop Para determinar la versión, HADOOP_CLIENT_OPTS a la versión de hadoop para determinar la versión. OPTS también funciona para las versiones de hadoop, por lo que solo puede cambiar el script de inicio de hadoop, generalmente /usr/lib/hadoop/bin/hadoop, que debe configurar en este código adjunto:

...

elif [ "$COMMAND" = "jar" ] ; entonces

# Agregue HADOOP_CLIENT_OPTS aquí

HADOOP_CLIENT_OPTS="$HADOOP_CLIENT_OPTS -Xdebug -Xrunjdwp.transport =dt_socket ,servidor=y,suspend=y,dirección=8765"

CLASS=org.apache.hadoop.util.RunJar

elif [ "$COMMAND" = "checknative" ]; entonces

...

Simplemente distinguir los parámetros JVM1 y JVM2 no es suficiente. hive proporciona tres configuraciones de variables (se pueden corregir viendo el código, que aún no se describe en la documentación oficial):

HIVE_DEBUG_RECURSIVE: le dice a hive que pase la variable HADOOP_CLIENT_OPTS a la JVM secundaria

HIVE_MAIN_CARDS: le dice a Hive que pase HADOOP_CLIENT_OPTS a la JVM secundaria. HIVE_MAIN_CLIENT_DEBUG_OPTS y HIVE_CHILD_CLIENT_DEBUG_OPTS: indique a Hive que pase la variable HADOOP_CLIENT_OPTS a la JVM secundaria al pasar la variable HADOOP_CLIENT_OPTS a la JVM secundaria.

Por lo tanto, el código final debería ser:

...

elif [ "$COMMAND" = "jar" ] then

<; p > si! echo "$HADOOP_CLIENT_OPTS"|fgrep 'dt_socket' ; entonces

HADOOP_CLIENT_OPTS="$HADOOP_CLIENT_OPTS -Xdebug -Xrunjdwp:transport=dt_socket, server=y,suspend=n,server=n,jdwp:transport=dt_socket ," ; entonces

si! servidor=y,suspend=n,dirección=8765"

fi

HIVE_DEBUG_RECURSIVE=y

HIVE_MAIN_CLIENT_DEBUG_OPTS="suspend=n,dirección=8765"< / p>

HIVE_CHILD_CLIENT_DEBUG_OPTS="suspend=y,address=8766"/>

exportar HADOOP_CLIENT_OPTS HIVE_CHILD_CLIENT_DEBUG_OPTS HIVE_DEBUG_ RECURSIVE HIVE_MAIN_CLIENT_DEBUG_OPTS

CLASS=org.apache.hadoop. util.RunJar

elif [ "$COMMAND" = "checknative" ] ; entonces

...

Otra situación es que la colmena está optimizada como No. envíe la tarea MR, eliminando la necesidad de iniciar una segunda JVM:

SELECT * FROM...

Agregue al puerto 8765 e ignore HIVE_CHILD_CLIENT_DEBUG_OPTS