Introducción
Un espacio comunitario guarda sus visitas confirmadas en un histórico de Hive. Una corrección aprobada sustituye el conjunto completo de visitas confirmadas de una fecha. No es un parche que se añade a las filas de ayer. Una fecha aprobada tiene ahora dos visitas confirmadas y otra no tiene ninguna. Las demás fechas, incluida una incorporación posterior, deben conservarse intactas.
Compararás la adición y la sustitución en tablas de práctica desechables y después guardarás y ejecutarás un archivo SQL con un alcance limitado sobre el histórico ORC real. También repetirás ese archivo y volverás a leer el resultado. El entorno ya ejecuta Hive y HDFS y contiene registros originales, correcciones candidatas y un histórico independientes.
Debes conocer las tablas externas de Hive, SELECT con WHERE, las columnas de partición, ORC y las rutas básicas de HDFS. Este laboratorio presenta las particiones de destino estáticas y la sustitución completa de una fecha. Todo el trabajo se realiza en la pestaña Terminal. Los 65 minutos son una estimación del autor que incluye la lectura y los errores habituales.
Compara de forma segura la adición y la sustitución
En este paso leerás un día normal del histórico y compararás tres alcances de escritura en tablas de práctica desechables. Mantén el histórico real sin cambios durante esta comparación.
Abre Terminal. Utiliza el espacio de trabajo preparado durante todo el laboratorio:
cd /home/labex/project
El directorio local venue contiene archivos CSV de referencia y una lista de aprobación. cat muestra un archivo sin editarlo:
cat venue/approved-days.txt
2026-10-02
2026-10-03
Estas son las únicas fechas del histórico real que puedes sustituir. Lee primero un día normal. Beeline envía SQL a HiveServer2. En el siguiente comando, -u indica la dirección de conexión JDBC, -n labex indica el nombre de usuario del cliente y -e proporciona el texto SQL. Las comillas dobles mantienen ese texto como un único argumento del shell; las comillas simples interiores delimitan valores SQL. DATE '...' hace explícito el tipo de fecha.
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SELECT * FROM venue_archive.archive WHERE visit_date=DATE '2026-10-04' ORDER BY visit_id;"
Lee las filas de datos debajo de los avisos de inicio. La fecha contiene v4 / Music / 4 y v5 / LateWalk / 2. La visita posterior v5 es válida y debe permanecer. La imagen puede mostrar avisos de SLF4J sobre varios enlaces de registro; son distintos de los errores SQL. Espera a que el comando devuelva el indicador antes de continuar.
Ahora inspecciona toda la fuente candidata, incluidos los registros cancelados:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SELECT * FROM venue_archive.candidate ORDER BY visit_date,visit_id;"
El 2 de octubre contiene c21 / PrintWorkshop / 5 y c22 / Bookbinding / 2, ambos con estado confirmed. El 3 de octubre tiene una fila cancelled. El histórico solo almacena filas confirmed, por lo que el conjunto de sustitución del 3 de octubre está legítimamente vacío. Que una fecha no aparezca en un resultado filtrado no significa «dejar intacta esa fecha antigua del histórico». La aprobación y el filtro de filas confirmadas responden a preguntas distintas.
Comprueba dónde leen y escriben las tres tablas reales. DESCRIBE FORMATTED añade metadatos de almacenamiento a las definiciones de columnas: busca Table Type, Location e InputFormat en cada resultado. La salida extensa también incluye detalles del motor; céntrate en estos campos antes de escribir.
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "DESCRIBE FORMATTED venue_archive.raw; DESCRIBE FORMATTED venue_archive.candidate; DESCRIBE FORMATTED venue_archive.archive;"
Las tres son objetos EXTERNAL_TABLE. La ubicación original es hdfs://localhost:9000/user/labex/venue-archive/raw; la ubicación candidata termina en /user/labex/venue-archive/candidate. Ambas utilizan entrada de texto. El histórico está en hdfs://localhost:9000/warehouse/external/venue_archive.db/archive y su formato de entrada termina en OrcInputFormat. Los archivos locales venue/*.csv son copias de referencia, no el histórico. Conserva las correspondencias y los archivos de origen suministrados.
Antes de modificar el histórico real, utiliza dos tablas desechables: practice_days tiene particiones por fecha y practice_whole almacena la fecha como una columna normal. Ambas empiezan con las visitas confirmadas originales. Los siguientes comandos muestran deliberadamente resultados incorrectos solo en estas tablas de práctica.
INSERT INTO añade filas. PARTITION(visit_date='2026-10-02') es una partición de destino estática: la fecha literal determina dónde se escriben todas las filas seleccionadas. Por ello, SELECT debe devolver únicamente las tres columnas que no son de partición. Su condición WHERE, independiente, elige las filas de origen. Nombrar el destino no filtra automáticamente la fuente.
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "INSERT INTO TABLE venue_archive.practice_days PARTITION(visit_date='2026-10-02') SELECT visit_id,activity,visitors FROM venue_archive.candidate WHERE visit_date=DATE '2026-10-02' AND record_status='confirmed'; SELECT * FROM venue_archive.practice_days WHERE visit_date=DATE '2026-10-02' ORDER BY visit_id;"
El resultado contiene c21, c22 y el antiguo v2. El SQL ha funcionado, pero el contrato de sustitución no se ha cumplido. Volver a añadir la misma corrección produciría más duplicados.
INSERT OVERWRITE sustituye las filas existentes del destino. En la tabla no particionada practice_whole, el destino es la tabla completa. Observa cómo desaparecen las demás fechas:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "INSERT OVERWRITE TABLE venue_archive.practice_whole SELECT visit_id,activity,visitors,visit_date FROM venue_archive.candidate WHERE visit_date=DATE '2026-10-02' AND record_status='confirmed'; SELECT * FROM venue_archive.practice_whole ORDER BY visit_date,visit_id;"
Solo quedan las dos filas del 2 de octubre. Una escritura correcta sobre toda la tabla puede perder silenciosamente fechas ajenas. Restaura esta tabla desechable desde su fuente original completa:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "INSERT OVERWRITE TABLE venue_archive.practice_whole SELECT visit_id,activity,visitors,visit_date FROM venue_archive.raw WHERE record_status='confirmed'; SELECT * FROM venue_archive.practice_whole ORDER BY visit_date,visit_id;"
Vuelven las cinco filas originales. Por último, combina OVERWRITE con una partición de fecha estática en practice_days:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "INSERT OVERWRITE TABLE venue_archive.practice_days PARTITION(visit_date='2026-10-02') SELECT visit_id,activity,visitors FROM venue_archive.candidate WHERE visit_date=DATE '2026-10-02' AND record_status='confirmed'; SELECT * FROM venue_archive.practice_days ORDER BY visit_date,visit_id;"
Hay seis filas: el 1 de octubre original, las dos filas corregidas del 2 de octubre, el 3 de octubre original y ambas visitas del 4 de octubre. El antiguo v2 ha desaparecido. Este es el alcance de escritura necesario para el histórico real.
Si Beeline indica un nombre de tabla no válido, el SQL no ha encontrado el objeto previsto. Comprueba la ortografía con el siguiente comando de solo lectura que ya conoces y vuelve a ejecutar el comando corregido. Para investigar un error de ruta utiliza pwd y ls venue; vuelve al directorio con el comando cd anterior. No recrees tablas ni vuelvas a ejecutar la preparación del entorno para corregir una errata.
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SHOW TABLES IN venue_archive;"
Antes de comprobar este paso, confirma que la partición de práctica contiene exactamente c21 y c22 el 2 de octubre, que la práctica de tabla completa vuelve a tener sus cinco filas originales y que el histórico real conserva sus datos originales.
Sustituye el día aprobado con registros confirmados
En este paso guardarás y ejecutarás la sustitución real del 2 de octubre. Continúa en Terminal, dentro de /home/labex/project.
La tabla real venue_archive.archive es una tabla ORC externa y no transaccional con particiones visit_date DATE. Sus fuentes original y candidata son tablas externas de texto delimitado por comas e independientes entre sí. Solo puedes sustituir fechas aprobadas del histórico: no edites las fuentes, cambies definiciones o ubicaciones, reasignes particiones, crees fechas adicionales ni reconstruyas todo el histórico. El 1 y el 4 de octubre deben conservar sus datos originales y sus archivos HDFS existentes. Reescribir filas idénticas también queda fuera del alcance aprobado.
Inspecciona la lista real de particiones y la disposición de columnas antes de escribir. SHOW PARTITIONS enumera las particiones de fecha registradas; DESCRIBE muestra las columnas normales seguidas de la información de partición:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SHOW PARTITIONS venue_archive.archive; DESCRIBE venue_archive.archive;"
Las cuatro fechas van del 1 al 4 de octubre. Las columnas normales son visit_id STRING, activity STRING y visitors INT; visit_date DATE es la columna de partición. Mantén intactos esta correspondencia y el formato ORC.
Guarda el SQL en un archivo editable para poder inspeccionar, corregir y repetir la misma operación. nano es un editor de texto dentro de Terminal. El siguiente comando abre replace-approved-days.sql en el espacio de trabajo actual; como es un archivo nuevo, su área de edición está inicialmente vacía:
nano replace-approved-days.sql
Escribe las siguientes cinco líneas SQL en nano, no en el indicador del shell. Las comillas simples delimitan valores SQL y el punto y coma termina la sentencia. Detente después del último punto y coma sin añadir una línea vacía adicional; nano añade el salto de línea final al guardar:
INSERT OVERWRITE TABLE venue_archive.archive
PARTITION(visit_date='2026-10-02')
SELECT visit_id,activity,visitors
FROM venue_archive.candidate
WHERE visit_date=DATE '2026-10-02' AND record_status='confirmed';
Utiliza las flechas para llegar al carácter que necesites corregir; Home y End llevan al principio y al final de la línea actual. Backspace borra el carácter situado a la izquierda del cursor; Delete borra el carácter situado en el cursor. Escribe el texto correcto en su lugar. El pie de nano utiliza ^ para indicar Ctrl. Pulsa Ctrl+O para guardar: en File Name to Write, conserva el nombre mostrado y pulsa Enter. Después pulsa Ctrl+X para salir. Espera a que vuelva el indicador del shell; el SQL se escribe en el editor, mientras que los comandos siguientes se introducen en ese indicador.
Lee lo guardado antes de ejecutarlo:
cat replace-approved-days.sql
Comprueba las dos fechas de la sentencia: tanto el destino estático como el filtro de origen son el 2 de octubre. La corrección representa el conjunto confirmado completo, incluidas las dos filas c21 y c22. No necesitas buscar coincidencias con los identificadores antiguos ni actualizar filas individualmente.
La opción -f de Beeline lee SQL desde un archivo. Ejecuta el archivo guardado:
beeline -u jdbc:hive2://localhost:10000/default -n labex -f replace-approved-days.sql
Después lee las cuatro fechas como lo haría un usuario de los datos:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SELECT visit_date,visit_id,activity,visitors FROM venue_archive.archive ORDER BY visit_date,visit_id;"
Debes obtener seis filas. El 2 de octubre contiene c21 / PrintWorkshop / 5 y c22 / Bookbinding / 2, sin v2. El 3 de octubre conserva por ahora el antiguo v3. Permanecen intactos v1 del 1 de octubre y v4 y v5 del 4 de octubre.
La conexión de Beeline te identifica como labex. HiveServer2 realiza las escrituras de almacenamiento como su usuario de servicio hive, por lo que los nuevos archivos ORC pueden pertenecer a hive:bigdata. No tienes que cambiar sus propietarios ni permisos. El NameNode de HDFS se ejecuta con su propia identidad de servicio hdfs.
Si una sentencia SQL tiene un error de sintaxis, inspecciona el archivo guardado con cat y reábrelo con nano replace-approved-days.sql. Utiliza las flechas para localizar la sentencia indicada por el error de Beeline. Corrige el nombre de tabla, las fechas, las comillas o el punto y coma según corresponda, conservando las demás líneas SQL. Guarda con Ctrl+O, Enter y sal con Ctrl+X. Vuelve a leer el archivo antes de ejecutar de nuevo -f. Si añadiste filas por error a esta fecha aprobada, la misma sobrescritura correcta de la partición elimina las filas obsoletas y duplicadas. Esta recuperación se limita a la fecha aprobada; no autoriza a reconstruir una fecha protegida.
Aplica una sustitución por un conjunto vacío y repite el archivo
En este paso vaciarás la partición aprobada del 3 de octubre, ejecutarás dos veces el archivo de corrección completo y comprobarás que el histórico no acumula filas. Continúa en Terminal, dentro de /home/labex/project.
Una cancelación también es una corrección. La lista de aprobación incluye el 3 de octubre, pero su candidato no tiene visitas confirmadas. Ejecuta primero la selección de origen:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SELECT visit_id,activity,visitors FROM venue_archive.candidate WHERE visit_date=DATE '2026-10-03' AND record_status='confirmed';"
No hay filas de datos. El histórico final correcto tampoco debe tener filas de esa fecha. Omitir la escritura dejaría el antiguo v3.
Reabre el mismo archivo. Conserva la sentencia existente del 2 de octubre; añadirás una sentencia, sin copiar de nuevo la primera:
nano replace-approved-days.sql
Utiliza la flecha hacia abajo para llegar a la línea vacía posterior al punto y coma de la primera sentencia, y End si necesitas llegar al final de esa línea. En esa línea vacía, pulsa Enter una vez para dejar una línea en blanco entre las sentencias. Después escribe únicamente las cinco líneas nuevas siguientes. Detente después de su último punto y coma sin añadir una línea vacía adicional. Si retomas una edición interrumpida, comprueba primero si esta sentencia del 3 de octubre ya está presente; corrígela en vez de añadir un duplicado.
INSERT OVERWRITE TABLE venue_archive.archive
PARTITION(visit_date='2026-10-03')
SELECT visit_id,activity,visitors
FROM venue_archive.candidate
WHERE visit_date=DATE '2026-10-03' AND record_status='confirmed';
Guarda con Ctrl+O, Enter y sal con Ctrl+X. Lee el archivo guardado completo desde el indicador del shell:
cat replace-approved-days.sql
Comprueba que contenga exactamente dos sentencias: la original del 2 de octubre seguida de la nueva del 3 de octubre. En cada una, tanto el destino estático como el filtro de origen deben indicar la fecha aprobada de esa sentencia. Si hay algún error, reabre el mismo archivo en nano, corrige solo las líneas afectadas, guarda e inspecciónalo de nuevo.
Ejecuta por primera vez este archivo completo guardado:
beeline -u jdbc:hive2://localhost:10000/default -n labex -f replace-approved-days.sql
Una sobrescritura estática cuya selección está vacía elimina las filas antiguas de la partición de destino. La fecha sigue registrada. El motor de almacenamiento decide si una partición vacía contiene archivos físicos; no crees por tu cuenta archivos CSV u ORC de relleno.
Lee las fechas registradas y el resultado completo:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SHOW PARTITIONS venue_archive.archive; SELECT visit_date,visit_id,activity,visitors FROM venue_archive.archive ORDER BY visit_date,visit_id; SELECT COUNT(*) FROM venue_archive.archive WHERE visit_date=DATE '2026-10-03';"
Siguen apareciendo las cuatro particiones. El resultado completo tiene cinco filas: v1, c21, c22, v4 y v5. El recuento del 3 de octubre es 0. Una lista con dos fechas aprobadas no implica que ambas particiones deban contener registros.
Ahora ejecuta otra vez el mismo archivo guardado, sin cambiarlo:
beeline -u jdbc:hive2://localhost:10000/default -n labex -f replace-approved-days.sql
Repite la consulta de lectura:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SELECT visit_date,visit_id,activity,visitors FROM venue_archive.archive ORDER BY visit_date,visit_id; SELECT COUNT(*) FROM venue_archive.archive;"
Permanecen las mismas cinco filas y el total es 5. Esta sustitución puede repetirse con las fuentes suministradas: no añade duplicados. La repetición puede recrear los archivos de las particiones aprobadas, pero los archivos originales de las fechas que no son objetivo deben permanecer intactos.
Puedes inspeccionar la fuente original con los comandos HDFS que ya conoces. Aquí, -cat lee el archivo de origen exacto, no el histórico ORC derivado:
hdfs dfs -cat /user/labex/venue-archive/raw/raw.csv
Todavía contiene los originales v2 y v3. Modificar un histórico derivado no reescribe su historia original. El candidato y la lista de aprobación también deben conservarse tal como se suministraron. Mantén el archivo SQL en el espacio de trabajo. Las comprobaciones observan los datos, definiciones, alcance y archivos protegidos actuales de Hive; no ejecutan cualquier SQL guardado. La repetición real y las lecturas del resultado son la autocomprobación de la operación guardada.
Resumen
Has comparado la adición, la sustitución de una tabla completa y la sustitución de una partición estática. Después has sustituido un día aprobado completo, aplicado una sustitución legítima por un conjunto vacío y repetido el mismo SQL guardado sin acumular filas. La historia original independiente y las demás fechas del histórico permanecieron intactas.
