Comprender el mecanismo de bloqueo de la colmena a partir de un problema de tabla de bloqueo
En vista de comentarios similares anteriores, al verificar los bloqueos de las tablas involucradas en el SQL,
encontramos varios bloqueos compartidos para desbloquear la tabla.
Sin embargo, cuando se vuelve a ejecutar SQL, todavía hay un bloqueo. La columna vertebral de SQL es la siguiente (busque el usuario de un día determinado en la tabla de particiones B, que no existe en la tabla de historial A, y agregue la partición antes de la ejecución).
Se descubrió que no solo no se podía insertar, sino que tampoco se podía ejecutar el select user_id de la declaración. Debido a que es una tabla de prueba, se reconstruye (más tarde se estima que hay varias particiones bloqueadas y hay bloqueos X. Solo desbloquear la tabla no puede desbloquear cada partición de forma recursiva). Después de reconstruir, seleccione distinguir... La memoria del GC excederá toda esta declaración y se reescribirá en el siguiente cuadro (la función de ventana reemplaza distinta, la conexión externa reemplaza en):
Entonces, la declaración de selección se puede ejecutar, pero todo el SQL aún bloquea la tabla.
Mira la información.
Bloqueo de colmena, esas cosas
Documentos oficiales
blogs.com/barneywill/p/10185577.html
Se encontró una declaración seleccionada. La partición t1 p1 requiere bloqueos S en t1 y t 1, por lo que seleccionar toda la tabla de particiones requiere bloqueos S en todas las particiones.
Volviendo a la declaración, la operación de unión se basa en el bloqueo S de la tabla A, pero eventualmente se escribirá en una nueva partición de la tabla A y agregará un bloqueo X, lo que provocará un punto muerto. Por lo tanto, es necesario hacer que la partición se escriba en la tabla A sin bloqueo S:
Ejecutar con éxito.
Además, configure el parámetro hive set hive. Support.concurrency = false antes de la ejecución de SQL puede forzar que se ignore el bloqueo, pero por el bien de la integridad de los datos, no se recomienda esta operación.