UNIVERSIDAD NACIONAL DE INGENIERIA

FACULTAD DE INGENIERIA INDUSTRIAL Y SISTEMAS

SECCION DE POSTGRADO

DOCTORADO EN INGENIERIA DE SISTEMAS

ANLISIS E INTERPRETACIN DEL PAPER

The Hadoop Distributed File System
CURSO: SISTEMAS COOPERATIVOS DISTRIBUIDOS
PROFESOR: DR. GLEN RODRIGUEZ
AUTOR
PAUL MILLER TOCTO INGA

2014

ndice
1.
2.
3.
4.
5.
6.
7.

PROBLEMA
TRABAJOS ANTERIORES
REVISION DE LITERATURA
SOLUCIN
RESULTADOS
CONCLUSIONES
BIBLIOGRAFA

1. PROBLEMA
Debido al desarrollo exponencial de usuarios del internet 2 billones de usuarios
con tendencia a un crecimiento, as como los celulares activos en una cantidad
cercano a los 7.3 billones y los datos procesados diariamente en Twitter
cercano a 7 TB, como en Facebook los datos procesados diariamente cercano
a 500 TB; se tiene que los datos procesados son no estructurados en
aproximadamente 80 %, esta informacin se necesita procesar para obtener
informacin que permita la toma de decisiones.
2. TRABAJOS ANTERIORES
Al igual que HDFS, existen sistemas de archivos distribuidos, que almacenan
los archivos de metadata del sistema y los datos de aplicacin separadamente:
PVFS: Un sistema de archivos paralelo para clsteres en Linux
Sistema de archivo Lustre
GFS: Evolucin en avance rpido
Pero HDFS no utiliza mecanismo de proteccin de datos como Lustre y PVFS,
como tambin si utiliza replicacin de datos como GFS.
3. REVISION DE LITERATURA
La implementacin distribuida del namespace tiene o estn intentando en los
siguientes sistemas:

Ceph: A Scalable High-Performance Distributed File System

GFS est evolucionando a un Sistema de namespace distribuido
Lustre tiene una implementacin de namespace con clsteres.

4. SOLUCIN
Hadoop tiene como sistema de archivos distribuidos al Hadoop Distributed
Filesystem (HDFS).
4.1 Diseo de HDFS.- Tiene las siguientes caractersticas:
Soporta Archivos muy grandes.- Donde archivos muy grandes son
cientos de megabytes, gigabytes, terabytes de tamao. Actualmente
tenemos clsteres de Hadoop ejecutando que almacenan peta bytes.
Acceso de datos inmediatamente.- Cumple con la idea que el patrn de
procesamiento de datos ms eficiente es grabar una vez y leer muchas
veces. Lo que importa es la lectura de todos los datos.
Hardware estndares.- Su diseo contempla la ejecucin en hardware
disponible comnmente por muchos distribuidores, y en el caso de fallas
continuar funcionando sin interrupcin.
4.2 Arquitectura HDFS.- Tiene los siguientes componentes:

NameNode.- Est formado por inodes, mantiene el rbol de namespace

y la relacin de los blocks de archivos con los DataNodes.
o Inodes.- Representa archivos y directorios, tiene la siguiente
informacin: permisos, modificacin, tiempo de accesos,
namespace y tamao del espacio en disco
o Cuando un cliente HDFS desea leer un archivo primero trabaja
con el NameNode para conocer la ubicacin de los bloques de
datos que forman parte del archivo, luego de lo cual lee los
contenidos de los bloques de datos cercanos al cliente, ver figura
1.

Figura 1

Cuando un cliente HDFS desea escribir los datos,

solicita al NameNode, tres DataNodes donde
replicar los datos, entonces el cliente graba los
datos en el DataNode en forma secuencial, ver
figura 2

Figura 2
o El diseo actual considera un NameNode por cada clster. El
clster puede tener cientos de DataNodes y cientos de HDFS
clientes por clster, porque cada DataNode puede ejecutar
mltiples aplicaciones concurrentemente. Ver figura 3

Figura 3
o HDFS mantiene todo el namespace en RAM
o Los datos inodo y la lista de bloques que pertenecen a cada
archivo comprenden los metadatos del sistema de nombres
llamado la imagen.
o En el sistema de archivos nativo del host local se almacenan:
Los registros permanentes de la imagen se llaman
checkpoint.

 El log de las modificaciones llamado Journal

o Para mejorar la duracin, se pueden almacenar copias del
checkpoint y del Journal en otros servidores.
o Durante el reinicio del NameNode se restablece el namespace
mediante la lectura del namespace y el journal.
o Las ubicaciones de las rplicas de los bloques pueden cambiar
en el tiempo y no forman parte del checkpoint persistente.

DataNode.- Tiene las siguientes caractersticas:

o Cada block replicado en un DataNode est representado por dos
archivos en el sistema de archivos nativo del local host.
o El primer archivo contiene los datos mismos y el segundo archivo
es metadata de bloques que incluyen sumas de verificacin para
el bloque de datos y la generacin de huella del bloque.
o El tamao del archivo de data es igual a la longitud del bloque y
no requiere espacio extra como los tradicionales archivos de
sistema, donde se tiene el concepto de tamao de bloque
nominal.
o Se realiza un proceso llamado handshake, realizado al inicializar
el DataNode, que consiste en verificar en el NameNode el
identificador del namespace y la versin del software del
DataNode, en el caso no coincida cualquiera de ellos,
automticamente se apaga el DataNode.
o El identificador el namespace es asignado a la instancia del
sistema de archivos cuando es formateado, este identificador se
almacena permanentemente en todos los nodos del clster. Los
nodos con diferentes identificadores no pueden integrarse al
clster, con lo cual se asegura la integridad del sistema.
o La consistencia de las versiones permite evitar la corrupcin de
los datos o sus prdidas, debido a la existencia de grandes
clsteres de cientos de mquinas, fcilmente se tienen nodos que
no se han apagado apropiadamente previo a la actualizacin del
software o no estaban disponibles durante la actualizacin.
o Un DataNode que es inicializada nueva y sin un identificador de
namespace, se le permite unirse al clster y se le asigna el
identificador del namespace del clster.
o Un DataNode almacena permanentemente un identificador nico
de almacenamiento, este es un identificador interno, que se
mantiene an si se reinicia el DataNode con un IP o un puerto
diferente, se asigna cuando el DataNode se registra con el
NameNode la primera vez y nunca cambia.
o Un reporte de bloques de datos, es la informacin que enva un
DataNode a un NameNode, consistente en: el identificador del
bloque de datos, la fecha de la generacin y la longitud por cada

bloque replicado en el servidor, este reporte se enva la primera

vez, cuando se registra el DataNode, posteriormente se enva un
reporte de bloque datos cada hora, asegurando la informacin
para que el NameNode tenga actualizado donde estn
localizados las rplicas en el clster.
o Los heartbeats es la comunicacin que enva los DataNodes al
NameNode, para indicar que aun est operando y las rplicas de
bloques de datos disponibles, las comunicaciones son en
intervalos de tres segundos, Si el NameNode no recibe un
heartbeat de un DataNode en 10 minutos, este considera que el
Data Node est fuera de servicio y los bloques de datos ubicados
en el NameNode no estn disponibles, en ese instante el
NameNode planifica la rplica de los bloques de datos no
disponibles en otros DataNodes. Tambin los heartbeats llevan
informacin acerca del total de la capacidad de almacenamiento,
la fraccin de almacenamiento usado y el nmero de datos
transferidos. Esta informacin estadstica son usados para la
asignacin de espacio y las decisiones de balanceo de carga.
Tambin los NameNode responde a los heartbeats, enviando
instrucciones a los DataNodes, estos pueden ser comandos tales
como:
Replicar bloques de datos a otros nodos
Quitar rplicas de bloques de datos locales
Volver a registrar o apagar un nodo.
Enviar inmediatamente un reporte de bloque de datos.
Estos comandos son importantes para el mantenimiento de la
integridad de todo el sistema y pueden ser procesados sin
afectar el funcionamiento de los NameNodes.
Cliente HDFS.- Es el medio de acceso de los usuarios de aplicaciones,
de forma similar a los sistemas de archivos convencionales, soporta
operaciones de lectura, escritura y eliminacin de archivos; adems de
operaciones para crear y eliminar directorios. Los usuarios referencias
archivos y directorios mediante caminos en el namespace.
La aplicacin del usuario no necesita conocer que el almacenamiento y
la meta data del sistema de archivos estn en diferentes servidores o
que los bloques de datos tienen mltiples rplicas.
La lectura de un archivo es mediante el cliente HDFS, quin consulta al
NameNode por la lista de DataNodes que el host replica de los archivos
de bloques de datos, luego se dirige directamente al DataNode y solicita
la transferencia del bloque deseado.
Cuando un cliente graba, primero pregunta al NameNode para escoger
los DataNode, donde almacenar el primer bloque de datos del archivo y
realiza un proceso secuencial de envo de los datos de nodo a nodo,
cuando el primer bloque de datos se llen, el cliente solicita uno nuevo
al DataNode y as sucesivamente ver figura 4.

Figura 4
A diferencia de los sistemas convencionales, en HDFS se tiene un API, que
permite la ubicacin de los bloques de datos, mediante esquemas como el
MapReduce que planifica la tarea de ubicacin de los datos, lo cual mejora
el rendimiento.
Tambin se puede configurar el factor de replicacin, que por defecto es
tres, donde para archivos crticos archivos que son ledos
frecuentemente, si tienen un factor de replicacin mayor mejorara la
tolerancia a fallas e incrementara su lectura.
Imagen y Journal.o Imagen es el namespace de la metadata del sistema de archivos,
que describe la organizacin de los datos como directorios y
archivos
Checkpoint es una Imagen grabado en el disco de forma
permanente, nunca es cambiado por el NameNode, se
remplaza enteramente cuando
se crea un nuevo
Checkpoint durante el reinicio, a solicitud del
administrador o por CheckpointNode.
o El Journal es una grabacin del log de los cambios al sistema de
archivos que no se modificaran.
Por cada transaccin realizada por un cliente, los cambios
son grabados en Journal y el archivo Journal
es
sincronizado antes que el cambio sea efectivo en el
cliente HDFS.
o Durante el
reinicio el NameNode inicializa la imagen del
namespace desde el Checkpoint y repone los cambios desde el

Journal hasta que la imagen est actualizada con el ltimo estado

del sistema
o Un nuevo checkpoint y un Journal vaco se graba en el directorio
de almacenamiento antes que el NameNode empiece a atender a
los clientes.
o Si cualquiera de los dos(checkpoint o Journal) no existen o se
corrompen, la informacin del namespace se perder
parcialmente o enteramente, para preservar la informacin crtica
se puede configurar, para almacenar el checkpoint y el journal en
multiples directorios de almacenamiento, lo recomendable es
ubicarlos en diferentes volmenes y en directorios de
almacenamiento remotos. Lo cual previene de las fallas de un
volumen y el segundo de las fallas del nodo entero.
o Si el NameNode detecta un error al grabar el Journal a uno de los
directorios de almacenamiento, automticamente se excluye
dicho directorio de la lista de directorios.
o El NameNode
automticamente se apaga si
ningn
almacenamiento est disponible.
o El NameNode es un sistema multitarea y procesa solicitudes
simultneamente de muchos clientes.
o La grabacin de una transaccin al disco llega a ser un cuello de
botella, porque todas las otras transacciones tienen que esperar,
hasta que el procedimiento iniciado por uno de ellos est
completo, para optimizar este proceso se realiza un proceso en
batch,
de mltiples transacciones iniciadas por diferentes
clientes, consistente en realizar el commit de un conjunto de
transacciones que han iniciado el proceso en batch, las
restantes transacciones solo se verifican que sus transacciones
ya fueron grabadas o no.
El CheckpointNode.- El NameNode puede ejecutar los siguientes roles:
CheckpointNode o BackupNode, el rol se especifica al iniciar el nodo.
El CheckpointNode peridicamente combina el checkpoint existente y el
Journal para crear un nuevo checkpoint y un Journal vaco.
El CheckpointNode usualmente se ejecuta en un diferentes host del
NameNode porque tiene el mismo requerimiento del NameNode.
El CheckpointNode descarga el actual checkpoint y Journal del
NameNode, los unifica y luego enva el nuevo checkpoint al NameNode.
El sistema puede inicializar desde el ms reciente checkpoint si todas
las copias persistentes de la imagen del namespace o journal estn
disponibles.
El journal crece cuando el cluster del HDFS se ejecuta por largo periodo,
cuando ms grande crece el journal, la probabilidad de prdida o

corrupcin es alta, tambin a mayor tamao del journal el tiempo

requerido es mayor para reiniciar el NameNode.

El BackupNode.- Es una caracterstica recientemente introducida, que

es similar al CheckpointNode.
Es capaz de crear checkpoints peridicos, adicionalmente mantiene
actualizada la imagen del archivo del sistema namespace, que est
sincronizada con el NameNode.
Acepta los datos continuos del journal de las transacciones del
namespace del NameNode activo, grabando los datos en su propio
directorio de almacenamiento, y aplica estas transacciones a su propia
imagen namespace en memoria.
Tambin el BackupNode se considera como un journal de
almacenamiento por el NameNode.
El BackupNode en memoria y el checkpoint en el disco es un registro
del ltimo estado del namespace.
Tambin el BackupNode puede crear un checkpoint sin descargar un
checkpoint y un archivo journal del activo NameNode, generando un
proceso checkpoint en el BackupNode mas eficiente.
El BackupNode se puede considerar un NameNode de solo lectura
porque contiene toda la informacin, excepto las ubicaciones de los
bloques de datos.
Tambin el uso de BackupNode nos da la opcin de correr el
NameNode sin almacenamiento persistente, con la asignacin de dicha
responsabilidad al BackupNode.

Actualizacin, Instantneas del sistema de archivos.En el proceso de actualizacin existe un incremento de la probabilidad
de corrupcin del sistema por los errores del software o los errores
humanos, mediante las instantneas es posible realizar una cancelacin
de la actualizacin y regresar al estado en el cual se tom las
instantneas.
Cuando se requiere una instantnea, el NameNode primero lee el
checkpoint y el archivo journal, ambos son fusionados en memoria,
entonces se graba un nuevo checkpoint y el journal vaco a una nueva
ubicacin, de tal forma que el antiguo checkpoint y el journal
permanecen sin cambiar.
Las instantneas locales en el DataNode no se pueden crear replicando
los directorios de archivos de datos, porque sera necesario duplicar la
capacidad de almacenamiento de cada DataNode en el cluster, para lo
cual cada DataNode crea una copia del almacenamiento del directorio y
los vnculos existentes en el bloque de archivos.

Cuando un DataNode elimina un bloque de datos, solo elimina los

vnculos, as la rplica de los bloques permanecen sin tocar en sus
directorios antiguos.
El administrador del cluster puede elegir regresar el HDFS al estado de
la instantnea cuando reinicia el sistema, el NameNode recupera el
checkpoint grabado cuando la instantnea fue creada, los DataNodes
restauran el anterior directorio renombrado e inicia un proceso para
borrar las rplicas creadas despus de tomar la instantnea, no existe
la posibilidad de anular el roll back.
El administrador del cluster puede recuperar el almacenamiento
ocupado por la instantnea, indicando al sistema que abandone la
instantnea, finalizando el upgrade del software.
Las instantneas tambin se utilizan para almacenar la nueva versin de
la evolucin del software en un cambio de formato del checkpoint del
NameNode y de los archivos de Journal, o en la representacin de los
bloques de archivo rplica en los DataNodes.
La creacin de un snapshot es necesario sobre todo el cluster, ms que
sobre una de sus partes, para poder mantener la integridad del sistema.
Una instantnea permite evitar la destruccin del HDFS, cuando existe
un problema
4.3 Operaciones de Entrada/Salida y Gestin de rplicas
Arquitectura HDFS.- Tiene los siguientes componentes:
Leer y Grabar un archivo.- El modelo usado es una grabacin y
mltiples lecturas, lo cual significa que un aplicativo adiciona datos al
HDFS, creando un nuevo archivo y grabando datos en este archivo,
despus que el archivo es cerrado, los bytes grabados no pueden ser
alterados o eliminados, excepto que se puede adicionar nuevos datos al
archivo, cuando se reabra el archivo para adicionar.
El cliente HDFS que abre un archivo tiene permiso para grabar, de tal
forma que ningn otro cliente pueda grabar en dicho archivo, y este
cliente tiene que enviar peridicamente un heartbeat al NameNode, para
renovar el permiso, y el permiso se pierde cuando se cierra el archivo,
adems que tiene un rango de tiempo de uso entre un lmite suave y un
lmite duro. Si se supera el lmite duro el archivo es cerrado y se pone a
disponibilidad de otro cliente. Existe concurrencia en la lectura en todo
instante.
Los bytes previamente se completan hasta completa un tamao(64KB),
luego de lo cual la data es colocado en la cola, despus que los datos
son grabados en el HDFS, para que esta data sea visible se debe de
realizar una operacin hflush, lo cual asegura que todos los datos
previamente grabados sern visibles.

En la siguiente figura se tiene el encolamiento figura 5.

Figura 5
Existe un verificador numrico de que los datos estn correctos, este
verificador lo crea el cliente HDFS, est en funcin de los datos que
enva al DataNode, este lo graba en un archivo separado de los datos.
Cuando un HDFS lee un archivo, tiene los datos y el verificador
numrico, en caso que el verificador no corresponda, el cliente notifica al
DataNode, quin enva una rplica de los datos de otra DataNode, la
ubicacin de las rplicas est en funcin de la distancia del lector y en
caso falle la lectura, el cliente intenta la prxima rplica
secuencialmente.
Al momento de leer se considera la longitud de la ltima longitud del dato
a leer antes de empezar el proceso.
Este diseo est optimizado para un procesamiento en lotes, que
realiza el MapReduce, como tambin la mejora del tiempo de la
lectura/grabacin, para soportar aplicaciones como Scribe, que provee

una data continua en tiempo real, HBase que es el acceso a grandes

tablas de forma aleatorio en tiempo real.
Ubicacin de los bloques.Se tiene una arquitectura ejemplo de la ubicacin de los bloques.

.
La distancia de un nodo a su padre se asume como uno, la distancia entre
nodos es la suma de las distancias a su ancestro comn.
El administrador puede obtener la identificacin del rack de un nodo, dado
la direccin de un nodo, el NameNode permite ubicar la ubicacin de un
rack de cada DataNode, porque al registrarse un DataNode el NameNode
indica a que rack pertenece.
La ubicacin mediante una buena poltica de las rplicas permite mejorar la
disponibilidad, confiabilidad y la utilizacin del ancho de banda de la red.
HDFS provee una poltica de ubicacin configurable, para que los usuarios
e investigadores puedan experimentar y testear.
Existe una poltica por defecto de la ubicacin de los bloques del HDFS,
que considera lo siguiente:
o La primera rplica se ubica en el nodo donde el que graba est
ubicado.
o La segunda y tercera en nodos diferentes en un diferente rack, y
el resto de forma aleatoria con la restriccin de que no ms de
una rplica es ubicado en un nodo y no ms de dos rplicas en

el mismo rack cuando el nmero de rplicas es menor que dos

veces el nmero de racks.
o El orden de procesamiento es secuencial y se considera la
proximidad a la primera rplica, en el caso de la lectura por el
DataNose se considera la cercana de los bloques de datos.

Balanceador.- Es una herramienta que balancea el espacio del disco en

un HDFS clster. Toma un valor umbral como parmetro de entrada, que
es una fraccin en el rango entre 0 y 1. Un clster es balanceado si
para cada DataNode, la utilizacin del nodo (radio del uso del espacio
en el nodo entre la capacidad total del nodo) difiera de la utilizacin del
total del clster (radio del espacio en el clster entre la capacidad total
del clster) en no ms del valor del umbral.
Es una herramienta que puede ser ejecutado por el administrador,
permitir el movimiento iterativamente desde los DataNodes con una
alta utilizacin a los nodos con baja utilizacin, considerando que no se
disminuya el nmero de rplicas o el nmero de racks, tambin
minimizando la copia de los datos entre racks.
Una configuracin tambin considera un parmetro de consumo de
ancho de banda para rebalanceo de las operaciones.

Escner del Block.- Verificar que el checksum almacenado coincida con

el bloque de datos. Los DataNodes ejecutan peridicamente, el Escner
del Block ajusta la lectura del ancho de banda para completar la
verificacin en un periodo configurable.
Si la verificacin es ok, se guarda la informacin en un log, siempre se
almacena dos versiones del log el actual y el anterior.
Cuando una lectura de un cliente o el block scanner detecta un bloque
corrupto se comunica al NameNode, este marca a la rplica como
corrupta, e inmediatamente planifica una copia correcta, cuando esta se
concluya satisfactoriamente, la copia corrupta se planifica para
eliminacin. An cuando todos los bloques estn corruptas, la poltica
permite que el usuario recupere la data de la copia corrupta.
Decomisionamiento.- Es cuando un miembro de un clster es excluido,
luego de lo cual no puede ser seleccionado como destino de la
ubicacin de una rplica, pero puede seguir sirviendo a las solicitudes
de pedidos de lectura, hasta que todos los bloques de este nodo sean
replicados, una vez finalizado este proceso de replicacin el DataNode
entra en un estado de decomisionamiento, para poder ser eliminado.
Copia de datos entre clsteres.- Es una herramienta llamada DistCp,
sirve para realizar en paralelo copia de grandes volmenes de datos
entre clsteres. Es un trabajo de MapReduce, que automticamente
planifica tareas en paralelo, deteccin de errores y recuperacin.
Aplicacin en Yahoo
25000 Nodos en total
o 25 PB de almacenamiento de datos en lnea

3500 Nodos por clsteres:

o 9.8 PB de espacio total
o 3.3 PB para las aplicaciones de los usuarios
o Mil nodos aproximadamente igual a 1 PB de almacenamiento
de aplicaciones.
60 millones de archivos
63 millones de bloques de datos
o Un bloque de datos tiene 54000 rplicas de datos
Cada da las aplicaciones pueden crear 2 millones de nuevos
archivos
Un cluster tiene:

o 2 quad core Xeon processors @ 2.5ghz

o Red Hat Enterprise Linux Server Release 5.1
o Sun Java JDK 1.6.0_13-b03
o 4 directly attached SATA drives (one terabyte each)
o 16G RAM
o 1-gigabit Ethernet
70% del espacio de disco ocupa el HDFS, el resto es reservado al
sistema operativo(Red Hat Linux), logs y espacio para las tareas
correspondientes a las salidas.
40 nodos en un rack comparten un switch IP
8 switches se conectan entre s, mediante un core switch, estos
brindan la conectividad entre racks y brindan la salida de los
recursos.
Cada clster tiene un NameNode y un BackupNode con 64 GB RAM,
solo para gestin del sistema.
Los bloques de datos son replicados tres veces.
Se tiene una actualizacin tecnolgica permanente, contemplando la
economa y el almacenamiento.
El proyecto Hadoop fue fundado en 2006 y Yahoo! adopt Hadoop
para su uso interno.
El producto estrella es la produccin del Mapa Web y el ndice del
WWW, por ser un componente crtico (75 horas de tiempo
transcurrido, 500 terabytes de datos intermedios de MapReduce, 300
terabytes de salida total).
La robustez y durabilidad de la data es lo ms importante, como
tambin el rendimiento econmico.
A. Duracin de los datos
a. La replicacin de tres veces asegura los datos.
b. La probabilidad de perder un bloque durante un ao es menos de
0.005
c. 0.8 % de nodos fallan cada mes, pero no afectan porque se tiene
la replicacin.

d. HDFS tambin puede soportar la prdida de un rack( cada bloque

tiene una rplica en otro rack)
e. Si falla un core switch, es probable que algunos bloques puedan
no estar disponibles, lo que se soluciona reparando el core swith
f. La falta de electricidad puede ocasionar la prdida de datos,
dependiendo de la magnitud(No se ha usado la estrategia de
reiniciar un nodo para verificar si puede sobrevivir al reinicio)
g. El block scanner puede detectar en un clster grande 20 rplicas
malas en el proceso.
B. Cuidado de lo comn. Se tienen caractersticas que se han compartido,
en una comunidad de usuarios grande y diverso.
a. Los permisos en HDFS se han considerado teniendo presente el
modelo de seguridad en UNIX, para directorios y archivos,
considerando los accesos separados para el propietario, para los
otros miembros de los grupos de usuarios asociados con el
archivo o el directorio y para todos los usuarios.
La principal diferencia entre UNIX (POSIX) y HDFS son los
archivos ordinarios que en el HDFS no tienen permiso de
ejecucin. En el actual esquema de permiso, la identidad del
usuario es dbil: t eres quien tu host dice que eres. Actualmente
est en proceso un modelo de identidad ms fuerte, inicialmente
se usar Kerberos.
Es necesario reforzar la poltica de asignacin de recursos entre
los usuarios de la comunidad, como protegerse de las
aplicaciones que agotan los recursos. Para gestionar el
almacenamiento de los recursos de namespace, se tiene que
asignar cuotas por el espacio total que ocupan los archivos en el
directorio, lo mismo se debe realizar con los subdirectorios.
Se debe de considerar un directorio para todas las salidas del
trabajo Map Reduce.
Utilizar los archivos de tipo HAR, similares a archivos tar, JAR
o Zip, que comprimen a informacin de entrada y son usadas
transparentemente como entrada al trabajo MapReduce.
C. Trabajos Futuros
a. Construir una solucin automatizada de un problema, usando
Zookeeper
b. Que el NameNode soporte escalabilidad
c. Que mltiples namespaces (y NameNodes) que compartan el
almacenamiento fsico en un clster.
d. Que se pueda usar namespaces cntricos de aplicaciones o
trabajos.

e. Mejorar la cooperacin entre clsteres que permita escalar a

clsteres mucho ms grandes.
5. RESULTADOS
Hadoop, por consiguiente HDFS actualmente es usado por la mayora de
compaas que realizan el procesamiento de grandes volmenes de
informacin.
Beanchmarks
Se presentan resultados de clsteres de al menos 3500 nodos.
DFSIO (Distributed File Input Output).- mide el promedio de
escritura, lectura y adicin de datos.
o DFSIO Read: 66 MB /s per node
o DFSIO Write: 40 MB /s per node
Para un clster en produccin:
o Busy Cluster Read: 1.02 MB/s per node
o Busy Cluster Write: 1.09 MB/s per node

Beanchmark de la medicin de un NameNode.-

6. CONCLUSIONES
El HDFS soluciona en parte las necesidades actuales de procesamiento de
grandes volmenes de informacin que cumple las siguientes
caractersticas:
o Soporta Archivos muy grandes.

o Acceso de datos inmediatamente

o Hardware estndares.
7. BIBLIOGRAFA
Konstantin Shvachko, Hairong Kuang, Sanjay Radia, Robert Chansler; The
Hadoop Distributed File System, Mass Storage Systems and Technologies
(MSST), 2010 IEEE 26th Symposium on, Incline Village, NV, May 2010
Apache Hadoop. http://hadoop.apache.org/
Sameer Wadkar, Madhu Siddalingaiah, Jason Venner, Pro Apache Hadoop,
2nd Edition, Apress, 2014