Skip to content

~/bda/m01 $ cat 02-operaciones-administracion-hdfs.md

  • Big Data Aplicado
  • M01
  • lección 02/09

Operaciones y administración de HDFS

hdfs es el comando de entrada de Hadoop para trabajar con HDFS. La palabra siguiente selecciona la herramienta. DFS viene de Distributed File System (sistema de archivos distribuido). El subcomando dfs abre la interfaz de archivos que usaremos para listar, leer o copiar datos.

Orden Qué hace
hdfs dfs -ls /datos Selecciona la interfaz de archivos con dfs y le pide listar /datos. El cliente usa el destino HDFS que configuramos con fs.defaultFS.
hdfs dfsadmin -report Selecciona la herramienta de administración dfsadmin y consulta el estado y la capacidad del clúster.
hdfs fsck /datos Selecciona la herramienta de diagnóstico fsck y comprueba el estado de los archivos y bloques bajo esa ruta.
hdfs namenode -format Selecciona la herramienta namenode y le pide inicializar los metadatos de una instalación nueva y vacía. Fue el paso de inicialización del bloque 01.

En hdfs namenode -format, la palabra namenode ya selecciona la herramienta que interpreta -format. Insertar dfs cambiaría a la interfaz de archivos, cuyas órdenes son otras. Si recuperas un HDFS ya inicializado, vuelve a arrancar sus procesos con los metadatos existentes. Consulta la guía de comandos de Hadoop 3.4.1.

En este bloque seguiremos trabajando en el mismo HDFS pseudodistribuido del bloque 01. NameNode, DataNode y Secondary NameNode se ejecutan como procesos separados en un único contenedor. Usaremos ese entorno para operar con archivos, comprobar su integridad y recuperar borrados. Con un solo DataNode y réplica 1, cada bloque tiene una única copia.

Si el contenedor está detenido, vuelve a entrar desde el anfitrión:

Terminal window
docker start -ai hadoop-manual

Si en el bloque 01 recuperaste la instalación como hadoop-manual-web, utiliza ese nombre. Dentro del contenedor, sigue el paso «Parar, recuperar la sesión y verificar persistencia» del bloque 01 para arrancar SSH, cambiar a hadoop y ejecutar start-dfs.sh. Si ya tienes HDFS en marcha, continúa en tu sesión de hadoop.

Comprueba dentro del contenedor, como hadoop:

Terminal window
whoami
hdfs dfsadmin -report
hdfs dfsadmin -safemode get
hdfs dfs -cat /datos/prueba/entrada.txt
command -v cmp

Espera a que aparezca un DataNode vivo y el modo seguro esté desactivado. La lectura del archivo confirma que hemos recuperado el mismo HDFS. Si falta cmp en una instalación anterior, abre otra terminal del anfitrión y ejecuta docker exec -it -u root hadoop-manual bash con el nombre de tu contenedor. En esa shell instala el paquete con apt-get update y apt-get install -y diffutils, y vuelve a la sesión de hadoop. Para añadir vim a una instalación anterior, incluye también ese paquete en la orden de instalación.

Los metadatos y los bloques se conservan en la capa de escritura del contenedor entre sesiones. Mantén el contenedor original: si lo eliminas, perderás su instalación y los datos HDFS. Ya se formateó en el bloque 01 y ahora reutilizaremos sus metadatos.

Los comandos de las prácticas se ejecutan dentro del contenedor como hadoop, salvo los pasos que indiquen expresamente volver al anfitrión. La web del NameNode se abre desde el anfitrión en http://localhost:9870.

Crearemos una muestra de ventas, un registro de acceso y un árbol de práctica bajo /datos/m01-02 en HDFS. Así conservamos separado el archivo /datos/prueba/entrada.txt del bloque 01.

Terminal window
mkdir -p /home/hadoop/practicas-hdfs
cd /home/hadoop/practicas-hdfs
printf 'producto,categoria,unidades,precio\nauriculares,audio,2,59.90\naltavoz,audio,1,45.00\nteclado,perifericos,1,75.00\n' > ventas.csv
printf '2026-10-22 GET /catalogo 200\n' > access_log.txt
cp ventas.csv /tmp/ventas.csv
hdfs dfs -mkdir -p /datos/m01-02/practica /datos/m01-02/logs/2026/abril
hdfs dfs -mkdir -p /datos/m01-02/temporal
  • hdfs dfs -mkdir crea directorios en HDFS; -p permite construir varios niveles y no falla si ya existen.

Los archivos de /home/hadoop/practicas-hdfs son locales al contenedor. Las rutas bajo /datos/m01-02 pertenecen a HDFS. Las secuencias muestran una primera ejecución. Si las repites, comprueba los nombres de origen y destino y elige nombres libres antes de volver a copiar, descargar o recuperar.

Empieza por reconocer el árbol, consultar capacidad y transferir los archivos de muestra:

Terminal window
# Navegación y capacidad.
hdfs dfs -ls /
hdfs dfs -ls -R /datos/m01-02
hdfs dfs -du -h /datos/m01-02
hdfs dfs -df -h
# Eliminar un directorio vacío que acabamos de preparar.
hdfs dfs -rmdir /datos/m01-02/temporal
# Transferencia local ↔ HDFS.
hdfs dfs -put access_log.txt /datos/m01-02/logs/
hdfs dfs -copyFromLocal ventas.csv /datos/m01-02/
hdfs dfs -get /datos/m01-02/ventas.csv ./ventas-local.csv
hdfs dfs -copyToLocal /datos/m01-02/logs ./logs-local
  • -ls lista una ruta HDFS; -R recorre también sus subdirectorios.
  • -du -h muestra tamaño lógico y espacio consumido por las réplicas; -df -h informa de capacidad del sistema. -h presenta tamaños legibles.
  • -rmdir elimina el directorio vacío /datos/m01-02/temporal; no sirve para borrar un árbol con archivos.
  • -put y -copyFromLocal copian desde el sistema local a HDFS. Los orígenes relativos se resuelven desde /home/hadoop/practicas-hdfs.
  • -get y -copyToLocal copian desde HDFS al sistema local; ./ señala el directorio local actual. Ninguna de estas transferencias elimina el origen.

Comprueba ambos sistemas antes de continuar:

Terminal window
ls
hdfs dfs -ls /datos/m01-02
hdfs dfs -ls /datos/m01-02/logs
  • ls debe mostrar las muestras originales y las copias descargadas en tu directorio local.
  • Los dos hdfs dfs -ls comprueban los destinos HDFS. Una copia local y otra HDFS pueden tener el mismo nombre sin ser el mismo archivo.

Ahora trabajaremos con los archivos que ya están en HDFS:

Terminal window
# Lectura y gestión.
hdfs dfs -head /datos/m01-02/ventas.csv
hdfs dfs -tail /datos/m01-02/ventas.csv
hdfs dfs -cp /datos/m01-02/ventas.csv /datos/m01-02/ventas-copia.csv
hdfs dfs -mv /datos/m01-02/ventas-copia.csv /datos/m01-02/archivo-archivado.csv
hdfs dfs -ls /datos/m01-02
  • -head muestra el comienzo y -tail, el final del archivo. Esta muestra es tan pequeña que ambas salidas pueden incluir el archivo completo.
  • -cp crea una copia dentro de HDFS; no descarga nada al disco local.
  • -mv cambia la ruta de esa copia dentro de HDFS. Tras la orden, debe aparecer archivo-archivado.csv en lugar de ventas-copia.csv.
  • -ls comprueba el resultado del cambio de nombre.

Local y HDFS son dos sistemas de ficheros distintos

Section titled “Local y HDFS son dos sistemas de ficheros distintos”

En una terminal conviven la ruta local —por ejemplo, /tmp/ventas.csv— y una ruta HDFS —por ejemplo, /datos/m01-02/practica/ventas.csv. Que ambas terminen en ventas.csv no significa que sean el mismo archivo. La dirección de una operación importa:

Operación Origen Destino Efecto que comprobar
-put / -copyFromLocal Sistema local HDFS El original local se conserva; aparece una copia en HDFS.
-get / -copyToLocal HDFS Sistema local El original de HDFS se conserva; aparece una copia local.
-cp HDFS HDFS Se duplica un archivo dentro de HDFS.
-mv HDFS HDFS Cambia la ruta dentro de HDFS.

Antes de aplicar un borrado, un movimiento o una copia, ejecuta hdfs dfs -ls sobre la ruta de origen y sobre la ruta de destino. Esta comprobación sencilla evita confundir una ruta local con una remota.

La siguiente secuencia reutiliza /tmp/ventas.csv, creado al principio, y muestra un ciclo completo sobre /datos/m01-02/practica. Cada grupo de órdenes introduce una comprobación que debe observarse antes de continuar:

Terminal window
# 1. Confirmar el fichero local y subirlo.
ls -lh /tmp/ventas.csv
hdfs dfs -put /tmp/ventas.csv /datos/m01-02/practica/ventas.csv
# 2. Verificar nombre, tamaño y contenido en HDFS.
hdfs dfs -ls -h /datos/m01-02/practica
hdfs dfs -head /datos/m01-02/practica/ventas.csv
# 3. Obtener una copia local con otro nombre y revisar ambas copias.
hdfs dfs -get /datos/m01-02/practica/ventas.csv /tmp/ventas-descargadas.csv
cat /tmp/ventas.csv
cat /tmp/ventas-descargadas.csv
cmp /tmp/ventas.csv /tmp/ventas-descargadas.csv
  • ls -lh confirma existencia y tamaño del origen local.
  • -put copia el CSV a la ruta HDFS indicada. Si esa ruta ya existe, comprueba el contenido antes de elegir un destino nuevo.
  • -ls -h y -head comprueban nombre, tamaño y comienzo de la copia HDFS.
  • -get descarga a un nombre local distinto. Si ese destino ya existe, compruébalo y elige otro nombre antes de repetir; aquí no se solicita sobrescribirlo.
  • Los dos cat permiten revisar visualmente esta muestra pequeña.
  • cmp compara ambos archivos locales byte a byte. Si son iguales no imprime diferencias y termina con estado 0; si difieren devuelve 1 y muestra la primera diferencia. Un problema de acceso produce otro estado y debe diagnosticarse.

Las lecturas y la comparación deben corresponder al mismo contenido. Si no coinciden, detén la práctica y revisa las rutas antes de continuar.

HDFS dispone de permisos inspirados en Unix. Los permisos controlan quién puede leer, escribir o atravesar un directorio.

Terminal window
hdfs dfs -chmod 750 /datos/m01-02/logs
hdfs dfs -chown hadoop:hadoop /datos/m01-02/ventas.csv
hdfs dfs -rm /datos/m01-02/archivo-archivado.csv
  • -chmod 750 permite leer, escribir y atravesar el directorio al propietario, leer y atravesar al grupo, y ningún acceso a otros usuarios.
  • -chown hadoop:hadoop fija tanto el propietario como el grupo en hadoop. Usa hdfs dfs -ls para observar el cambio de grupo si el archivo heredó otro del directorio padre, como supergroup.
  • -rm elimina la ruta de la copia que acabas de renombrar. Si todavía no has habilitado la papelera, el borrado es directo. Más adelante practicaremos la recuperación con otra copia de prueba.

No confundas la propiedad registrada en HDFS con los permisos del archivo local del DataNode. Este laboratorio usa autenticación simple: comprender permisos HDFS no equivale a haber desplegado autenticación fuerte para producción.

hdfs fsck permite inspeccionar el estado de archivos y directorios. No es un botón mágico de reparación: informa de bloques, réplicas y problemas detectados.

Terminal window
hdfs fsck /datos/m01-02/ventas.csv -files -blocks -locations
hdfs fsck /datos/m01-02
  • La primera orden detalla el archivo, sus bloques y las ubicaciones de las réplicas.
  • La segunda analiza los archivos bajo /datos/m01-02 y resume su estado. Consultar el inventario de bloques no equivale a leer todos sus bytes.
Resultado Interpretación
Fichero sano y réplicas esperadas HDFS localiza bloques válidos.
Bloque subreplicado Faltan copias respecto al factor configurado.
Bloque perdido No hay una réplica válida conocida.
Fichero vacío No habrá bloques de datos que localizar.

La ubicación física de bloques puede observarse en los directorios de datos del DataNode, pero no se deben modificar esos ficheros manualmente: HDFS gestiona su estructura interna.

Una salida simplificada puede indicar el tamaño lógico, el número de bloques y la réplica viva:

/datos/m01-02/ventas.csv 111 bytes, replicated: replication=1, 1 block(s): OK
0. BP-...:blk_... len=111 Live_repl=1

La muestra exacta creada con printf tiene 111 bytes, incluida la cabecera y los saltos de línea. Si cambias el contenido o los finales de línea, registra el tamaño real; no debes forzar que coincida con este ejemplo. Los identificadores BP-… y blk_… también varían.

replication expresa el objetivo configurado; Live_repl indica cuántas réplicas vivas se han localizado. En un laboratorio de un solo nodo ambos valores suelen ser uno. En un clúster multínodo una diferencia entre ambos revela subreplicación.

La papelera permite recuperar durante un tiempo los archivos borrados. El cliente mueve el fichero a la papelera del usuario. Para habilitarla, abre /opt/hadoop/etc/hadoop/core-site.xml con nano como hadoop y añade esta propiedad dentro de <configuration>, junto a fs.defaultFS. Si ya existe, comprueba que su valor sea 60. El fragmento muestra solo esa propiedad.

core-site.xml
<property>
<name>fs.trash.interval</name>
<value>60</value>
</property>

Aplica la retención de 60 minutos con un reinicio de HDFS dentro del contenedor. Usa los scripts del bloque 01 con SSH ya en marcha y conserva los metadatos existentes.

Terminal window
stop-dfs.sh
start-dfs.sh
hdfs dfsadmin -report
hdfs dfsadmin -safemode get

Cuando HDFS tenga un DataNode vivo y salga del modo seguro, comprueba el valor y ensaya la recuperación con una copia de prueba. Continúa con el borrado solo si la primera orden devuelve 60.

Terminal window
hdfs getconf -confKey fs.trash.interval
hdfs dfs -mkdir -p /user/hadoop
hdfs dfs -cp /datos/m01-02/practica/ventas.csv /datos/m01-02/practica/archivo.tmp
hdfs dfs -rm /datos/m01-02/practica/archivo.tmp
hdfs dfs -ls /user/hadoop/.Trash/Current/datos/m01-02/practica
hdfs dfs -mv /user/hadoop/.Trash/Current/datos/m01-02/practica/archivo.tmp /datos/m01-02/practica/archivo-restaurado.csv
hdfs dfs -cat /datos/m01-02/practica/archivo-restaurado.csv
  • getconf -confKey consulta la propiedad cargada por el cliente; esperamos 60.
  • -mkdir -p /user/hadoop prepara el directorio personal HDFS de esta cuenta.
  • -cp crea una copia desechable para ensayar el borrado.
  • -rm retira su ruta activa y comunica dónde la ha trasladado la papelera.
  • -ls localiza el archivo dentro de la papelera; comprueba su nombre real antes de recuperarlo.
  • -mv devuelve esa copia al directorio activo con otro nombre y -cat comprueba el texto.

La ruta dentro de .Trash/Current conserva el recorrido de origen. Si no encuentras el fichero, revisa el mensaje de -rm, el usuario efectivo y el valor de fs.trash.interval: con retención 0 la papelera está desactivada. No vuelvas a borrar un fichero importante para comprobarlo.

hdfs dfs -expunge gestiona los checkpoints de papelera y elimina los que han superado la retención; no debe interpretarse como una orden necesaria después de cada borrado. La opción -skipTrash de -rm evita esta protección. Ninguna de las dos es necesaria para completar la recuperación anterior.

Terminal window
# Resumen de nodos, bloques y capacidad.
hdfs dfsadmin -report
# Topología conocida por HDFS.
hdfs dfsadmin -printTopology
# Archivos abiertos.
hdfs dfsadmin -listOpenFiles
# Consultar modo seguro.
hdfs dfsadmin -safemode get
  • -report resume nodos, bloques y capacidad.
  • -printTopology muestra los nodos y su organización lógica conocida, no una comprobación de la infraestructura física real.
  • -listOpenFiles consulta archivos abiertos para escritura; puede no mostrar ninguno si todas las cargas terminaron.
  • -safemode get consulta el modo seguro sin cambiarlo.

El modo seguro impide escrituras durante determinadas comprobaciones. No se trata de un error por sí mismo: hay que interpretar por qué está activo antes de forzar cambios. Es normal observarlo durante el arranque: el NameNode espera los heartbeats y los informes de bloques de los DataNodes para comprobar que se alcanza el nivel de seguridad configurado. Cuando los recibe, abandona el modo seguro automáticamente y permite escrituras. Si permanece activo, revisa primero el informe de nodos y bloques; no lo fuerces a salir como primer diagnóstico.

dfsadmin -report permite relacionar capacidad total, espacio usado y espacio restante. Al interpretar el resultado, diferencia:

  • tamaño lógico de los archivos;
  • espacio físico consumido por sus réplicas;
  • capacidad disponible en cada DataNode;
  • bloques subreplicados o faltantes.

El factor de replicación es un objetivo por fichero, no el número de nodos del clúster. En esta fase solo existe un DataNode, de modo que usamos un objetivo compatible:

Terminal window
hdfs dfs -setrep -w 1 /datos/m01-02/practica/ventas.csv
hdfs fsck /datos/m01-02/practica/ventas.csv -files -blocks -locations
  • -setrep establece el objetivo de réplicas del archivo; -w espera hasta que se alcance. Con valor 1 mantenemos el objetivo compatible con este entorno.
  • fsck permite contrastar después el objetivo con las réplicas vivas.

No ejecutes aquí -setrep -w 2: un DataNode no puede alojar dos réplicas independientes del mismo bloque y la orden quedaría esperando un objetivo imposible de cumplir con este entorno. En el bloque 03 construiremos los tres nodos necesarios para observar cambios de réplica y caída de un servicio. La modificación no cambia por sí sola el contenido lógico del fichero.

Los checksums verifican que los bytes leídos de un bloque coinciden con los almacenados. Durante una lectura, el cliente compara los datos recibidos con su suma de verificación; ante una discrepancia puede informar del bloque defectuoso y solicitar otra réplica. El NameNode coordina después la recuperación que corresponda.

La protección empieza durante la escritura: el cliente divide el flujo en fragmentos y calcula sumas que acompañan a los datos; los DataNodes comprueban lo recibido y conservan información de verificación junto a sus bloques. Durante la lectura, un DataNode devuelve datos y sumas, y el cliente puede reconocer una discrepancia. El NameNode conoce qué DataNodes tienen réplicas y puede coordinar la reparación, pero no recibe todos los bytes de usuario para verificarlos como si fuera un paso obligatorio de la transferencia.

Cliente lee un bloque
│
▼
DataNode entrega datos y sumas de verificación
├── coincide → lectura correcta
└── no coincide en el cliente → aviso y búsqueda de réplica válida

Un checksum no comprueba que un dato tenga sentido de negocio. Un importe negativo permitido por un CSV o una fecha imposible requieren reglas de calidad diferentes, que se estudiarán en M04. Por ejemplo, HDFS puede guardar, replicar y leer perfectamente una fila con edad=-150: sus bytes son íntegros, pero el valor no es válido para el dominio que representa. La integridad técnica y la calidad semántica son evidencias distintas.

El cliente permite obtener una suma de fichero y combinar esa observación con su lectura:

Terminal window
hdfs dfs -checksum /datos/m01-02/practica/ventas.csv
hdfs dfs -cat /datos/m01-02/practica/ventas.csv
hdfs fsck /datos/m01-02/practica/ventas.csv -files -blocks -locations
  • -checksum muestra el algoritmo y la suma del archivo según HDFS.
  • -cat obliga al cliente a leer sus datos y permite observar el contenido.
  • fsck informa de bloques, ubicaciones y réplicas conocidas.

Estas órdenes responden a preguntas diferentes. Una salida HEALTHY de fsck no equivale por sí sola a haber leído y verificado semánticamente todas las filas. Tampoco se debe comparar sin más la suma HDFS con un sha256sum local: pueden representar algoritmos y estructuras diferentes.

Conservar sumas, réplicas y checkpoints tiene una sobrecarga: metadatos adicionales, CPU para calcular/verificar y transferencias para mantener o reparar copias. Al crecer el volumen aumenta el número de bloques y de operaciones que se deben proteger; no desaparece el coste por automatizarlo. La decisión busca que ese coste sea aceptable frente al riesgo de lecturas corruptas o pérdida de disponibilidad.

Un snapshot conserva el estado lógico de un directorio en un momento dado. Sirve para recuperar borrados accidentales o revisar una versión anterior.

Terminal window
hdfs dfsadmin -allowSnapshot /datos/m01-02
hdfs dfs -createSnapshot /datos/m01-02 antes-de-practica
hdfs dfs -ls /datos/m01-02/.snapshot/antes-de-practica
hdfs dfs -rm /datos/m01-02/practica/ventas.csv
hdfs dfs -cp \
/datos/m01-02/.snapshot/antes-de-practica/practica/ventas.csv \
/datos/m01-02/practica/ventas-recuperadas.csv
hdfs dfs -cat /datos/m01-02/practica/ventas-recuperadas.csv
  • -allowSnapshot habilita snapshots en el directorio elegido; requiere privilegios de administración HDFS. Aquí hadoop es la cuenta que arrancó el NameNode y administra este laboratorio.
  • -createSnapshot crea una vista identificada por antes-de-practica.
  • -ls permite consultar esa vista por la ruta especial .snapshot.
  • -rm retira la ruta activa del archivo. Como también está habilitada la papelera, este borrado puede quedar protegido por ambos mecanismos.
  • -cp recupera el contenido desde la ruta del snapshot, con un nombre nuevo. Las barras finales de las líneas continúan una misma orden dentro de Bash.
  • -cat comprueba el contenido recuperado. No es necesario vaciar la papelera para demostrar que se ha usado el snapshot: lo identifica la ruta de origen de la copia.

Replicación, checksum y snapshot son complementarios: el primero mantiene copias, el segundo detecta corrupción y el tercero permite volver a un estado anterior.

El recorrido del ejemplo es concreto: el snapshot registra que ventas.csv formaba parte de /datos/m01-02/practica antes del borrado. La ruta activa desaparece, pero la vista bajo .snapshot sigue permitiendo acceder a sus bloques. La copia final crea un fichero activo llamado ventas-recuperadas.csv; comprueba su contenido contra /tmp/ventas.csv. Para continuar los ejemplos con el nombre inicial, recupera también esa ruta:

Terminal window
hdfs dfs -cp /datos/m01-02/practica/ventas-recuperadas.csv /datos/m01-02/practica/ventas.csv
  • Esta copia conserva ventas-recuperadas.csv y vuelve a crear ventas.csv como archivo activo para los apartados siguientes.

Un snapshot no es una copia independiente en otro centro de datos ni una protección frente a todos los errores administrativos. Conserva una vista lógica dentro del mismo sistema HDFS y consume recursos al retener bloques que de otro modo podrían eliminarse. Define para cada snapshot un propósito, propietario y fecha de eliminación.

Terminal window
hdfs dfs -deleteSnapshot /datos/m01-02 antes-de-practica
hdfs dfsadmin -disallowSnapshot /datos/m01-02
  • -deleteSnapshot elimina la vista con ese nombre, no los archivos activos del directorio.
  • -disallowSnapshot deshabilita nuevos snapshots en el directorio; exige que ya no queden snapshots en él. Borrar una vista puede liberar bloques que solo retenía esa vista, pero no garantiza liberar un tamaño fijo.

Ejemplo conceptual para el contenedor del bloque 01. Para ejecutarlo, prepara antes un entorno virtual Python con la biblioteca hdfs.

Como ampliación de lectura arquitectónica, una aplicación Python puede operar sobre WebHDFS mediante un cliente compatible. El fragmento siguiente permite reconocer las mismas operaciones —listar y leer— desde una API. No forma parte de la secuencia ejecutable de este laboratorio ni se exige instalar dependencias para resolver las actividades de la página.

Dentro del contenedor, http://hadoop:9870 identifica el NameNode. WebHDFS puede redirigir la lectura al DataNode. Un cliente situado en el anfitrión necesitaría además resolver y alcanzar la dirección anunciada por ese nodo. La preparación y el ensayo se reservan para una práctica específica de integración.

from hdfs import InsecureClient
client = InsecureClient('http://hadoop:9870', user='hadoop')
print(client.list('/datos/m01-02'))
with client.read('/datos/m01-02/practica/ventas.csv', encoding='utf-8') as lector:
print(lector.readline())

Trabaja en el contenedor hadoop-manual, como hadoop, con /tmp/ventas.csv preparado al principio. Utiliza /datos/m01-02/actividad03 como directorio HDFS propio para conservar las evidencias del ejemplo resuelto. Esta actividad se centra en comprobar qué se ha almacenado y qué evidencia aporta cada herramienta, sin provocar borrados ni recuperar versiones.

  1. Crea el directorio, sube el CSV con el nombre ventas.csv y comprueba ruta, contenido y tamaño. Anota qué comandos actúan en el sistema local y cuáles en HDFS.
  2. Obtén la suma HDFS y el informe fsck con bloques y ubicaciones. Registra el algoritmo y suma observados, número de bloques, objetivo de replicación y réplicas vivas; explica qué pregunta responde cada comprobación.
  3. Descarga la copia HDFS a un nombre local nuevo y compárala byte a byte con /tmp/ventas.csv mediante cmp. Registra el resultado sin confundirlo con la suma de HDFS.
  4. Un compañero afirma: «fsck indica HEALTHY, así que todos los precios del CSV son correctos». Explica qué permite afirmar esa salida, qué aporta además la lectura y qué validación de negocio seguiría faltando. Identifica el papel del NameNode, DataNode y cliente.

Entrega un registro breve con esta tabla y las salidas relevantes:

Comprobación Orden y resultado propio Qué demuestra Qué no demuestra
Listado y tamaño
Lectura HDFS
Checksum HDFS
Bloques y réplicas con fsck
Comparación local con cmp

La comprobación es satisfactoria si las copias coinciden byte a byte, se identifica una réplica viva y se distinguen integridad técnica, disponibilidad y calidad semántica. No se requiere el mismo identificador de bloque ni la misma suma que otra instalación.

M01-HDFS-04 — Recuperación y administración

Section titled “M01-HDFS-04 — Recuperación y administración”

Ahora debes elegir y justificar una recuperación. Prepara dos versiones locales del CSV: conserva el original con cp y genera otra con el precio del teclado cambiado de 75.00 a 80.00 mediante sed, trabajado en M00. No sobrescribas /tmp/ventas.csv. Usa /datos/m01-02/actividad04 como directorio HDFS y nombres distintos para las dos versiones. Los cambios deben quedar documentados.

  1. Sube ambas versiones y registra contenido, propietario, permisos, capacidad y bloques. Asigna al directorio permisos que permitan trabajar a su propietario sin abrirlo a todos los usuarios.
  2. Incidente A: recuperar un estado documentado. Habilita y crea un snapshot antes de borrar la ruta activa del original. Comprueba el borrado y recupera ese contenido desde el snapshot con un nombre nuevo. Justifica por qué esa vista corresponde al estado que necesitas. Aunque el borrado también pase por la papelera, la evidencia de esta recuperación debe mostrar la ruta .snapshot utilizada.
  3. Incidente B: deshacer un borrado reciente. Borra la ruta activa de la versión modificada y recupérala desde la papelera, sin utilizar el snapshot. Verifica primero la retención y localiza la ruta real indicada por el borrado; no presupongas que siempre coincide si has repetido el ejercicio.
  4. Descarga los dos archivos recuperados a nombres locales nuevos. Usa cmp para compararlos con sus respectivas versiones locales, de modo que la recuperación no confunda el precio 75.00 con 80.00.
  5. Para cada incidente, explica qué mecanismo has utilizado, qué estado permite recuperar y de qué depende su conservación. Indica por qué no demuestra tolerancia a la caída de un DataNode ni protección frente a la pérdida del equipo. Explica también por qué recuperar exactamente el precio 80.00 no demuestra que sea un precio de negocio correcto.

Entrega las órdenes, resultados relevantes y una tabla con estas cinco filas. No se trata de enumerar comandos: cada decisión debe remitir a una evidencia propia.

Actuación Ruta local/HDFS afectada Resultado observado Mecanismo y justificación Límite
Preparación y permisos
Recuperación desde snapshot
Recuperación desde papelera
Comparación de las dos versiones
Conclusión de protección y calidad

Se admiten nombres equivalentes dentro del directorio de la actividad. La comprobación exige recuperar ambas versiones sin confundirlas, justificar la elección de mecanismo y declarar sus límites. Las actividades 03 y 04 son formativas salvo anuncio docente expreso de otro uso.

M01-HDFS-05 — Interpretar bloques y capacidad

Section titled “M01-HDFS-05 — Interpretar bloques y capacidad”

Un archivo de 500 MiB se carga en un clúster HDFS con un tamaño de bloque de 128 MiB y un factor de replicación de 3. Supón que se han creado las tres copias de cada bloque.

  1. Calcula cuántos bloques tendrá el fichero.
  2. Estima el espacio total que ocuparán los datos de las tres copias de cada bloque, excluyendo metadatos y otras sobrecargas.
  3. Indica qué comando utilizarías para comprobar las ubicaciones reales de los bloques.
  4. Explica por qué esa comprobación no sustituye una regla que valide si las columnas del CSV contienen datos coherentes.

Presenta el cálculo con unidades, distingue tamaño lógico de datos replicados y declara que se excluyen metadatos. No redondees cada bloque al tamaño máximo para calcular el almacenamiento: el último conserva solo los bytes restantes.

Comprueba como hadoop que puedes leer el archivo original del bloque 01 y el CSV restaurado de este bloque:

Terminal window
hdfs dfs -cat /datos/prueba/entrada.txt
hdfs dfs -cat /datos/m01-02/practica/ventas.csv

Para terminar, sigue la parada del bloque 01. Ejecuta stop-dfs.sh y exit como hadoop. Después ejecuta exit en la shell de root para detener el contenedor y volver al anfitrión. Así conservas el laboratorio de ambos bloques y liberas sus puertos. En otra sesión puedes recuperar el mismo contenedor y comprobar de nuevo los archivos siguiendo el arranque del bloque 01.