Machine Translated by Google

El sistema de archivos distribuidos Hadoop

Konstantin Shvachko, Hairong Kuang, Sanjay Radia, Robert Chansler

¡Yahoo!

Sunnyvale, California, EE. UU.

{Shv, Hairong, SRadia, Chansler}@Yahoo­[Link]

Resumen: El Sistema de Archivos Distribuidos Hadoop (HDFS) está diseñado para Desarrollado en Facebook. Pig [4], ZooKeeper [6] y Chukwa se originaron y
almacenar grandes conjuntos de datos de forma fiable y transmitirlos con un alto desarrollaron en Yahoo! Avro se originó en Yahoo! y se está desarrollando en conjunto
ancho de banda a las aplicaciones de usuario. En un clúster grande, miles de con Cloudera.
servidores alojan almacenamiento conectado directamente y ejecutan tareas de las
aplicaciones de usuario. Al distribuir el almacenamiento y la computación entre varios HDFS es el componente del sistema de archivos de Hadoop. Si bien la interfaz de
servidores, el recurso puede crecer según la demanda, manteniendo su rentabilidad HDFS sigue el modelo del sistema de archivos UNIX, se sacrificó la fidelidad a los
en cualquier tamaño. Describimos la arquitectura de HDFS e informamos sobre la estándares en favor de un mejor rendimiento de las aplicaciones.
experiencia con el uso de HDFS para gestionar 25 petabytes de datos empresariales
en Yahoo!.
HDFS almacena los metadatos del sistema de archivos y los datos de la aplicación

Palabras clave: Hadoop, HDFS, sistema de archivos distribuido por separado. Al igual que en otros sistemas de archivos distribuidos, como PVFS [2]
[14], Lustre [7] y GFS [5][8], HDFS almacena los metadatos en un servidor dedicado,
llamado NameNode. Los datos de la aplicación se almacenan en otros servidores
I. INTRODUCCIÓN Y TRABAJOS RELACIONADOS
llamados DataNodes. Todos los servidores están completamente conectados y se
Hadoop [1][16][19] proporciona un sistema de archivos distribuido y un marco para comunican entre sí mediante protocolos basados en TCP.
el análisis y la transformación de grandes conjuntos de datos mediante el paradigma
MapReduce [3]. Una característica importante de Hadoop es la partición de datos y la
A diferencia de Lustre y PVFS, los DataNodes en HDFS no utilizan mecanismos
computación en miles de hosts, así como la ejecución de cálculos de aplicaciones en
de protección de datos como RAID para garantizar la durabilidad de los datos. En
paralelo cerca de sus datos. Un clúster de Hadoop escala la capacidad de computación,
cambio, al igual que en GFS, el contenido de los archivos se replica en múltiples
la capacidad de almacenamiento y el ancho de banda de E/S simplemente añadiendo
DataNodes para mayor confiabilidad. Si bien garantiza la durabilidad de los datos, esta
servidores básicos. Los clústeres de Hadoop en Yahoo! abarcan 25 000 servidores y
estrategia tiene la ventaja adicional de que se multiplica el ancho de banda de
almacenan 25 petabytes de datos de aplicaciones; el clúster más grande tiene 3500
transferencia de datos y se ofrecen más oportunidades para ubicar los cálculos cerca
servidores.
de los datos necesarios.

Cien otras organizaciones en todo el mundo informan que utilizan Hadoop. Varios sistemas de archivos distribuidos han implementado o están explorando
implementaciones verdaderamente distribuidas del espacio de nombres. Ceph [17]
cuenta con un clúster de servidores de espacio de nombres (MDS) y utiliza un
algoritmo de partición dinámica de subárboles para asignar el árbol de espacios de
Sistema de archivos distribuido
HDFS nombres a los MDS de forma uniforme. GFS también está evolucionando hacia una
¡Objeto de este artículo!
implementación de espacio de nombres distribuido [8]. El nuevo GFS contará con
Marco de computación distribuida MapReduce cientos de servidores de espacio de nombres (maestros) con 100 millones de archivos por maestro.
Lustre [7] incluye una implementación de espacio de nombres agrupado en su hoja de
HBase Servicio de mesa orientado a columnas
ruta para la versión 2.2 de Lustre. El objetivo es distribuir un directorio en múltiples
servidores de metadatos (MDS), cada uno de los cuales contiene una porción disjunta
Lenguaje de flujo de datos y marco de ejecución paralela
Cerdo del espacio de nombres. Un archivo se asigna a un MDS específico mediante una
función hash en el nombre del archivo.
Colmena Infraestructura de almacenamiento de datos

II. ARQUITECTURA
Servicio de coordinación distribuida ZooKeeper

Chukwa A. Nodo de nombre

Sistema de recopilación de datos de gestión
El espacio de nombres HDFS es una jerarquía de archivos y directorios. Los
Avro Sistema de serialización de datos
archivos y directorios se representan en el NameNode mediante inodos, que registran
atributos como permisos, tiempos de modificación y acceso, espacio de nombres y
Tabla 1. Componentes del proyecto Hadoop cuotas de espacio en disco. El contenido del archivo se divide en grandes bloques
(normalmente de 128 megabytes, pero seleccionables por el usuario archivo por
Hadoop es un proyecto Apache; todos los componentes están disponibles a
archivo) y cada bloque se replica de forma independiente en varios DataNodes
través de la licencia de código abierto de Apache. Yahoo! ha desarrollado y contribuido
(normalmente tres, pero seleccionables por el usuario archivo por archivo). El
al 80% del núcleo de Hadoop (HDFS y MapReduce). HBase se desarrolló originalmente
NameNode mantiene el árbol de espacios de nombres y la asignación de bloques de
en Powerset, ahora un departamento de Microsoft. Hive [15] se originó y desarrolló.
archivos a los DataNodes.

978­1­4244­7153­9/10/$26.00 ©2010 IEEE

Uso autorizado con licencia limitado a: UNIVERSITAT OBERTA DE CATALUNYA. Descargado el 23 de febrero de 2025 a las [Link] UTC desde IEEE Xplore. Se aplican restricciones.
Machine Translated by Google

(la ubicación física de los datos del archivo). Un cliente HDFS que desea leer un DataNode cuando se registra con NameNode por primera vez y nunca cambia
archivo primero contacta al NameNode para obtener la ubicación de los bloques después de eso.
de datos que lo componen y luego lee el contenido del bloque del DataNode más
Un DataNode identifica las réplicas de bloque que posee al NameNode
cercano. Al escribir datos, el cliente solicita al NameNode que designe un conjunto
mediante el envío de un informe de bloque. Este informe contiene el ID del bloque,
de tres DataNodes para alojar las réplicas de los bloques. El cliente escribe los
la marca de generación y la longitud de cada réplica de bloque alojada en el
datos en los DataNodes mediante una canalización. El diseño actual tiene un único
servidor. El primer informe de bloque se envía inmediatamente después del
NameNode para cada clúster. El clúster puede tener miles de DataNodes y
registro del DataNode. Los informes de bloque posteriores se envían cada hora y
decenas de miles de clientes HDFS por clúster, ya que cada DataNode puede
ejecutar múltiples tareas de aplicación simultáneamente. proporcionan al NameNode una vista actualizada de la ubicación de las réplicas
de bloque en el clúster.

Durante el funcionamiento normal, los DataNodes envían latidos al NameNode

para confirmar que este está funcionando y que las réplicas de bloque que aloja
HDFS mantiene todo el espacio de nombres en RAM. Los datos del inodo y la
están disponibles. El intervalo predeterminado entre latidos es de tres segundos.
lista de bloques de cada archivo conforman los metadatos del sistema de
Si el NameNode no recibe un latido de un DataNode en diez minutos, este lo
nombres, denominado imagen. El registro persistente de la imagen, almacenado
considera fuera de servicio y las réplicas de bloque que aloja no están disponibles.
en el sistema de archivos nativo del host local, se denomina punto de control. El
A continuación, programa la creación de nuevas réplicas de esos bloques en otros
NameNode también almacena el registro de modificaciones de la imagen,
DataNodes.
denominado diario, en el sistema de archivos nativo del host local. Para una
mayor durabilidad, se pueden realizar copias redundantes del punto de control y
del diario en otros servidores. Durante los reinicios, el NameNode restaura el
espacio de nombres leyéndolo y reproduciendo el diario. Las ubicaciones de las Los latidos de un DataNode también contienen información sobre la capacidad
réplicas de bloques pueden cambiar con el tiempo y no forman parte del punto de total de almacenamiento, la fracción de almacenamiento en uso y el número de
control persistente. transferencias de datos en curso. Estas estadísticas se utilizan para la asignación
de espacio y el balanceo de carga del NameNode.

B. Nodos de datos
El NameNode no llama directamente a los DataNodes. Utiliza las respuestas
Cada réplica de bloque en un DataNode se representa mediante dos archivos a los latidos para enviar instrucciones a los DataNodes. Las instrucciones incluyen
en el sistema de archivos nativo del host local. El primer archivo contiene los datos comandos para:
y el segundo contiene los metadatos del bloque, incluyendo las sumas de
comprobación de los datos del bloque y su marca de generación. • replicar bloques a otros nodos;
•
El tamaño del archivo de datos equivale a la longitud real del bloque y no requiere eliminar réplicas de bloques locales;
espacio adicional para redondearlo al tamaño nominal del bloque, como en los • volver a registrar o apagar el nodo;
sistemas de archivos tradicionales. Por lo tanto, si un bloque está medio lleno, solo • enviar un informe de bloqueo inmediato.
necesita la mitad del espacio del bloque completo en la unidad local.
Estos comandos son importantes para mantener la integridad general del
sistema y, por lo tanto, es fundamental mantener la frecuencia de los latidos,
Durante el arranque, cada DataNode se conecta al NameNode y realiza un
incluso en clústeres grandes. El NameNode puede procesar miles de latidos por
protocolo de enlace. El propósito del protocolo de enlace es verificar el ID del
segundo sin afectar a otras operaciones del NameNode.
espacio de nombres y la versión de software del DataNode. Si alguno de los dos
no coincide con el del NameNode, el DataNode se apaga automáticamente.

C. Cliente HDFS
El ID del espacio de nombres se asigna a la instancia del sistema de archivos
Las aplicaciones de usuario acceden al sistema de archivos mediante el
al formatearse. Este ID se almacena de forma persistente en todos los nodos del
cliente HDFS, una biblioteca de código que exporta la interfaz del sistema de
clúster. Los nodos con un ID de espacio de nombres diferente no podrán unirse al archivos HDFS.
clúster, lo que preserva la integridad del sistema de archivos.
Al igual que la mayoría de los sistemas de archivos convencionales, HDFS
admite operaciones de lectura, escritura y eliminación de archivos, así como
La consistencia de las versiones de software es importante porque una versión operaciones de creación y eliminación de directorios. El usuario referencia los
incompatible puede causar corrupción o pérdida de datos y en clústeres grandes
archivos y directorios mediante rutas en el espacio de nombres. La aplicación del
de miles de máquinas es fácil pasar por alto nodos que no se apagaron
usuario generalmente no necesita saber que los metadatos y el almacenamiento del
correctamente antes de la actualización del software o que no estaban disponibles
sistema de archivos se encuentran en servidores diferentes, ni que los bloques tienen múltiples réplica
durante la actualización.
Cuando una aplicación lee un archivo, el cliente HDFS solicita al NameNode
A un DataNode recién inicializado y sin ninguna ID de espacio de nombres se
la lista de DataNodes que alojan réplicas de los bloques del archivo. Luego,
le permite unirse al clúster y recibir la ID de espacio de nombres del clúster.
contacta directamente con un DataNode y solicita la transferencia del bloque
deseado. Cuando un cliente escribe, solicita al NameNode que seleccione los
Tras el protocolo de enlace, el DataNode se registra con el NameNode. Los DataNodes que alojarán las réplicas del primer bloque del archivo. El cliente
DataNodes almacenan de forma persistente sus ID de almacenamiento únicos. El organiza una canalización de nodo a nodo y envía los datos. Cuando se completa
el primer bloque, el cliente solicita que se seleccionen nuevos DataNodes para
ID de almacenamiento es un identificador interno del DataNode, lo que lo hace
reconocible incluso si se reinicia con una dirección IP o puerto diferente. El ID de alojar réplicas del siguiente bloque. Se organiza una nueva canalización y el
almacenamiento se asigna al

Uso autorizado con licencia limitado a: UNIVERSITAT OBERTA DE CATALUNYA. Descargado el 23 de febrero de 2025 a las [Link] UTC desde IEEE Xplore. Se aplican restricciones.
Machine Translated by Google

Figura 1. Un cliente HDFS crea un nuevo archivo indicando su ruta al NameNode. Para cada bloque del archivo, el NameNode devuelve una lista de DataNodes que
albergan sus réplicas. El cliente envía los datos a los DataNodes seleccionados, que finalmente confirman la creación de las réplicas de bloque al NameNode.

El cliente envía los bytes restantes del archivo. Cada opción de DataNodes Se debe configurar para almacenar el punto de control y el diario en varios
probablemente sea diferente. Las interacciones entre el cliente, el NameNode y directorios de almacenamiento. Se recomienda colocar los directorios en
los DataNodes se ilustran en la Fig. 1. volúmenes diferentes y que uno de ellos se encuentre en un servidor NFS remoto.
La primera opción evita pérdidas por fallos de un solo volumen, mientras que la
segunda protege contra fallos de todo el nodo. Si el NameNode detecta un error
A diferencia de los sistemas de archivos convencionales, HDFS proporciona al escribir el diario en uno de los directorios de almacenamiento, lo excluye
una API que expone la ubicación de los bloques de archivos. Esto permite que
automáticamente de la lista de directorios de almacenamiento.
aplicaciones como MapReduce programen una tarea donde se encuentran los
datos, mejorando así el rendimiento de lectura. También permite que una
El NameNode se apaga automáticamente si no hay ningún directorio de
aplicación establezca el factor de replicación de un archivo. Por defecto, el factor
almacenamiento disponible.
de replicación de un archivo es tres. Para archivos críticos o a los que se accede
con frecuencia, un factor de replicación más alto mejora su tolerancia a fallos y El NameNode es un sistema multihilo que procesa solicitudes simultáneamente
aumenta su ancho de banda de lectura. de varios clientes. Guardar una transacción en disco se convierte en un cuello de
botella, ya que los demás hilos deben esperar a que finalice el proceso de vaciado
y sincronización síncrono iniciado por uno de ellos. Para optimizar este proceso,
D. Imagen y Diario el NameNode procesa por lotes múltiples transacciones iniciadas por diferentes
clientes. Cuando uno de los hilos del NameNode inicia una operación de vaciado
La imagen del espacio de nombres son los metadatos del sistema de
y sincronización, todas las transacciones procesadas en ese momento se
archivos que describen la organización de los datos de la aplicación como
confirman conjuntamente. Los hilos restantes solo necesitan comprobar que sus
directorios y archivos. Un registro persistente de la imagen escrita en disco se
transacciones se han guardado y no necesitan iniciar una operación de vaciado y
denomina punto de control. El diario es un registro de confirmación de escritura
sincronización.
anticipada para los cambios en el sistema de archivos que deben ser persistentes.
Para cada transacción iniciada por el cliente, el cambio se registra en el diario, y
el archivo del diario se vacía y sincroniza antes de que el cambio se confirme en
el cliente HDFS. El NameNode nunca modifica el archivo del punto de control; se E. Nodo de punto de control
reemplaza por completo cuando se crea un nuevo punto de control durante el El NameNode en HDFS, además de su función principal de atender las
reinicio, a petición del administrador o por el CheckpointNode descrito en la solicitudes de los clientes, puede ejecutar alternativamente dos funciones
siguiente sección. Durante el inicio, el NameNode inicializa la imagen del espacio adicionales: CheckpointNode o BackupNode. La función se especifica al iniciar el
de nombres desde el punto de control y luego reproduce los cambios del diario nodo.
hasta que la imagen se actualiza con el último estado del sistema de archivos. Un
El CheckpointNode combina periódicamente el punto de control y el diario
nuevo punto de control y un diario vacío se reescriben en los directorios de
existentes para crear uno nuevo y un diario vacío. El CheckpointNode suele
almacenamiento antes de que el NameNode comience a atender a los clientes.
ejecutarse en un host diferente al del NameNode, ya que tiene los mismos
requisitos de memoria que este. Descarga los archivos actuales del punto de
control y del diario del NameNode, los fusiona localmente y devuelve el nuevo
Si falta el punto de control o el diario, o se corrompe, la información del punto de control al NameNode.
espacio de nombres se perderá parcial o totalmente.
En su totalidad. Para preservar esta información crítica, HDFS puede

Uso autorizado con licencia limitado a: UNIVERSITAT OBERTA DE CATALUNYA. Descargado el 23 de febrero de 2025 a las [Link] UTC desde IEEE Xplore. Se aplican restricciones.
Machine Translated by Google

La creación de puntos de control periódicos es una forma de proteger los y los archivos de diario, y los fusiona en memoria. Luego, escribe el nuevo punto de
metadatos del sistema de archivos. El sistema puede iniciarse desde el punto de control y el diario vacío en una nueva ubicación, de modo que el punto de control y
control más reciente si las demás copias persistentes de la imagen o el diario del el diario anteriores permanecen sin cambios.
espacio de nombres no están disponibles.
Durante el protocolo de enlace, el NameNode indica a los DataNodes si deben
La creación de un punto de control permite que el NameNode trunque el final crear una instantánea local. Esta instantánea local en el DataNode no puede crearse
del diario cuando se carga el nuevo punto de control. Los clústeres HDFS se replicando los directorios de los archivos de datos, ya que esto requeriría duplicar
ejecutan durante periodos prolongados sin reinicios, durante los cuales el diario la capacidad de almacenamiento de cada DataNode del clúster. En su lugar, cada
crece constantemente. Si el diario crece demasiado, aumenta la probabilidad de DataNode crea una copia del directorio de almacenamiento y crea enlaces físicos a
pérdida o corrupción del archivo. Además, un diario muy grande prolonga el tiempo los archivos de bloque existentes. Cuando el DataNode elimina un bloque, solo
necesario para reiniciar el NameNode. En un clúster grande, procesar un diario de elimina el enlace físico, y las modificaciones de bloque durante las anexiones utilizan
una semana de duración tarda una hora. Se recomienda crear un punto de control la técnica de copia en escritura. Por lo tanto, las réplicas de bloque antiguas
diario. permanecen intactas en sus directorios anteriores.

El administrador del clúster puede revertir HDFS al estado de instantánea al

F. Nodo de respaldo
reiniciar el sistema. NameNode recupera el punto de control guardado al crear la
Una característica recientemente introducida de HDFS es BackupNode. instantánea.
Al igual que un CheckpointNode, el BackupNode es capaz de crear puntos de control Los DataNodes restauran los directorios previamente renombrados e inician un
periódicos, pero además mantiene una imagen en memoria actualizada del espacio proceso en segundo plano para eliminar las réplicas de bloque creadas después de
de nombres del sistema de archivos que siempre está sincronizada con el estado la instantánea. Si se opta por revertir, no es posible avanzar. El administrador del
del NameNode. clúster puede recuperar el almacenamiento ocupado por la instantánea ordenando
al sistema que la abandone, finalizando así la actualización del software.
El BackupNode acepta el flujo de registro de las transacciones del espacio de
nombres del NameNode activo, las guarda en sus propios directorios de
almacenamiento y las aplica a su propia imagen del espacio de nombres en memoria.
El NameNode trata al BackupNode como un almacén de registro, al igual que trata La evolución del sistema puede provocar cambios en el formato de los archivos
los archivos de registro en sus directorios de almacenamiento. Si el NameNode falla, de punto de control y diario del NameNode, o en la representación de datos de los
su imagen en memoria y el punto de control en disco constituyen un registro del archivos de réplica de bloques en los DataNodes. La versión del diseño identifica
estado más reciente del espacio de nombres. los formatos de representación de datos y se almacena permanentemente en los
directorios de almacenamiento del NameNode y de los DataNodes. Durante el inicio,
cada nodo compara la versión del diseño del software actual con la versión
El BackupNode puede crear un punto de control sin descargar los archivos de
almacenada en sus directorios de almacenamiento y convierte automáticamente
punto de control y diario del NameNode activo, ya que cuenta con una imagen de
los datos de los formatos antiguos a los nuevos. La conversión requiere la creación
espacio de nombres actualizada en su memoria. Esto hace que el proceso de
obligatoria de una instantánea cuando el sistema se reinicia con la nueva versión
creación de puntos de control en el BackupNode sea más eficiente, ya que solo
del diseño del software.
necesita guardar el espacio de nombres en sus directorios de almacenamiento local.

HDFS no separa las versiones de diseño para NameNode y DataNodes, ya que

El BackupNode se puede ver como un NameNode de solo lectura.
la creación de instantáneas debe ser una iniciativa de todo el clúster y no un evento
Contiene toda la información de metadatos del sistema de archivos, excepto las
selectivo de nodos. Si un NameNode actualizado, debido a un error de software,
ubicaciones de los bloques. Puede realizar todas las operaciones del NameNode
purga su imagen, realizar una copia de seguridad únicamente del estado del
normal que no impliquen la modificación del espacio de nombres.
espacio de nombres implica la pérdida total de datos, ya que el NameNode no
o conocimiento de la ubicación de los bloques. El uso de un BackupNode permite
reconocerá los bloques reportados por los DataNodes y ordenará su eliminación. En
ejecutar el NameNode sin almacenamiento persistente, delegando la responsabilidad
este caso, la reversión recuperará los metadatos, pero se perderán los datos. Se
del estado del espacio de nombres persistente al BackupNode.
requiere una instantánea coordinada para evitar una destrucción catastrófica.

G. Actualizaciones, instantáneas del sistema de archivos

Durante las actualizaciones de software, aumenta la posibilidad de dañar el III. OPERACIONES DE ENTRADA /SALIDA DE ARCHIVOS Y GESTIÓN DE RÉPLICAS
sistema debido a errores de software o errores humanos. El objetivo de crear
instantáneas en HDFS es minimizar los posibles daños a los datos almacenados en A. Lectura y escritura de archivos
el sistema durante las actualizaciones.
Una aplicación añade datos a HDFS creando un nuevo archivo y escribiendo
El mecanismo de instantánea permite a los administradores guardar de forma los datos en él. Una vez cerrado el archivo, los bytes escritos no se pueden
persistente el estado actual del sistema de archivos, de modo que si la actualización modificar ni eliminar, excepto que se pueden añadir nuevos datos al abrirlo de nuevo
genera pérdida o corrupción de datos, es posible revertir la actualización y devolver para añadirlos. HDFS implementa un modelo de un solo escritor y múltiples lectores.
HDFS al espacio de nombres y al estado de almacenamiento como estaban en el
momento de la instantánea.
Al cliente HDFS que abre un archivo para escritura se le otorga una concesión
La instantánea (solo puede existir una) se crea a discreción del administrador para el archivo; ningún otro cliente puede escribir en él. El cliente que escribe
del clúster cada vez que se inicia el sistema. Si se solicita una instantánea, el renueva periódicamente la concesión enviando un latido al NameNode. Al cerrar el
NameNode primero lee el punto de control. archivo, se revoca la concesión.

Uso autorizado con licencia limitado a: UNIVERSITAT OBERTA DE CATALUNYA. Descargado el 23 de febrero de 2025 a las [Link] UTC desde IEEE Xplore. Se aplican restricciones.
Machine Translated by Google

La duración del arrendamiento está sujeta a un límite flexible y un límite estricto. Las líneas gruesas representan los paquetes de datos, las líneas discontinuas los
Hasta que expire el límite flexible, el autor tiene acceso exclusivo al archivo. Si el mensajes de confirmación y las líneas finas los mensajes de control para configurar
límite flexible expira y el cliente no cierra el archivo ni renueva la concesión, otro y cerrar la canalización. Las líneas verticales representan la actividad en el cliente
cliente puede anularla. Si, una vez expirado el límite máximo (una hora), el cliente y los tres nodos de datos, donde el tiempo transcurre de arriba a abajo. De t0 a t1
no renueva la concesión, HDFS asume que el cliente ha abandonado el sistema y se encuentra la etapa de configuración de la canalización. El intervalo de t1 a t2
cerrará automáticamente el archivo en nombre del autor, recuperando la concesión. corresponde a la etapa de transmisión de datos, donde t1...
La concesión del autor no impide que otros clientes lean el archivo; un archivo Es el momento en que se envía el primer paquete de datos y t2 es el momento en
puede tener varios lectores simultáneos. que se recibe la confirmación del último paquete. En este caso, una operación
hflush transmite el segundo paquete. La indicación hflush viaja con los datos del
paquete y no es una operación independiente. El intervalo final de t2 a t3
corresponde a la etapa de cierre de la canalización.
Un archivo HDFS consta de bloques. Cuando se necesita un nuevo bloque, el
para este bloque.
NameNode asigna un bloque con un ID único y determina una lista de DataNodes
para alojar réplicas del bloque. Los DataNodes forman una canalización, cuyo orden En un clúster de miles de nodos, las fallas de un nodo (generalmente fallas de
minimiza la distancia total de red desde el cliente hasta el último DataNode. Los almacenamiento) son frecuentes. Una réplica almacenada en un DataNode puede
bytes se envían a la canalización como una secuencia de paquetes. Los bytes que corromperse debido a fallas en la memoria, el disco o la red. HDFS genera y
una aplicación escribe primero se almacenan en el búfer del cliente. Una vez que almacena sumas de comprobación para cada bloque de datos de un archivo HDFS.
se llena el búfer de paquetes (normalmente 64 KB), los datos se envían a la El cliente HDFS verifica las sumas de comprobación durante la lectura para detectar
canalización. El siguiente paquete puede enviarse a la canalización antes de recibir cualquier corrupción causada por el cliente, los DataNodes o la red.
la confirmación de los paquetes anteriores. El número de paquetes pendientes está
limitado por el tamaño de la ventana de paquetes pendientes del cliente. Cuando un cliente crea un archivo HDFS, calcula la secuencia de suma de
comprobación de cada bloque y la envía a un DataNode junto con los datos. Un
DataNode almacena las sumas de comprobación en un archivo de metadatos
separado del archivo de datos del bloque. Cuando HDFS lee un archivo, los datos
Tras escribir datos en un archivo HDFS, HDFS no garantiza que sean visibles
y las sumas de comprobación de cada bloque se envían al cliente. El cliente calcula
para un nuevo lector hasta que se cierre el archivo. Si una aplicación de usuario
la suma de comprobación de los datos recibidos y verifica que las nuevas sumas
necesita la garantía de visibilidad, puede ejecutar explícitamente la operación
de comprobación calculadas coincidan con las recibidas. De lo contrario, el cliente
hflush . A continuación, el paquete actual se envía inmediatamente a la canalización,
notifica al NameNode la réplica dañada y obtiene una réplica diferente del bloque
y la operación hflush esperará hasta que todos los DataNodes de la canalización
de otro DataNode.
confirmen la transmisión correcta del paquete. De esta forma, todos los datos
escritos antes de la operación hflush serán visibles para los lectores.
Cuando un cliente abre un archivo para leerlo, obtiene la lista de bloques y la
ubicación de cada réplica del NameNode. Las ubicaciones de cada bloque se
ordenan según su distancia al lector. Al leer el contenido de un bloque, el cliente
prueba primero la réplica más cercana. Si el intento de lectura falla, prueba la
siguiente réplica en orden. Una lectura puede fallar si el DataNode de destino no
está disponible, si el nodo ya no aloja una réplica del bloque o si la réplica está
dañada al comprobar las sumas de comprobación.

HDFS permite que un cliente lea un archivo que esté abierto para escritura.
Al leer un archivo abierto para escritura, el NameNode desconoce la longitud del
último bloque que aún se está escribiendo. En este caso, el cliente solicita a una de
las réplicas la longitud más reciente antes de comenzar a leer su contenido.

El diseño de E/S de HDFS está especialmente optimizado para sistemas de

procesamiento por lotes, como MapReduce, que requieren un alto rendimiento para
lecturas y escrituras secuenciales. Sin embargo, se han realizado numerosos
esfuerzos para mejorar su tiempo de respuesta de lectura/escritura para que sea
compatible con aplicaciones como Scribe, que proporciona transmisión de datos en
tiempo real a HDFS, o HBase, que proporciona acceso aleatorio en tiempo real a
tablas de gran tamaño.

B. Colocación del bloque

Para un clúster grande, puede que no sea práctico conectar todos los nodos

Figura 2. Canalización de datos durante la construcción del bloque en una topología plana. Una práctica común es distribuir los nodos en varios racks.
Los nodos de un rack comparten un switch, y los switches del rack se conectan
Si no se produce ningún error, la construcción del bloque pasa por tres etapas, mediante uno o más switches de núcleo.
como se muestra en la Fig. 2, que ilustra una canalización de tres Nodos de Datos La comunicación entre dos nodos en diferentes racks debe realizarse a través de
(DN) y un bloque de cinco paquetes. En la imagen, múltiples conmutadores. En la mayoría de los casos, el ancho de banda de la red...

Uso autorizado con licencia limitado a: UNIVERSITAT OBERTA DE CATALUNYA. Descargado el 23 de febrero de 2025 a las [Link] UTC desde IEEE Xplore. Se aplican restricciones.
Machine Translated by Google

La velocidad entre nodos del mismo rack es mayor que la velocidad entre nodos para ejecutarse en nodos de clúster, pero siempre que un host pueda conectarse
de diferentes racks. La figura 3 describe un clúster con dos racks, cada uno con a NameNode y DataNodes, puede ejecutar el cliente HDFS).
tres nodos.
Esta política reduce el tráfico de escritura entre racks y entre nodos y, en
general, mejora el rendimiento de escritura. Dado que la probabilidad de fallo de
/ un rack es mucho menor que la de un nodo, esta política no afecta la fiabilidad ni
la disponibilidad de los datos. En el caso habitual de tres réplicas, puede reducir el
ancho de banda de red total utilizado al leer datos, ya que un bloque se coloca
solo en dos racks en lugar de tres.
Estante 0 Estante 1

La política de ubicación de réplicas HDFS predeterminada se puede resumir

de la siguiente manera:
DN00 DN01 DN02 DN10 DN11 DN12
1. Ningún nodo de datos contiene más de una réplica de cualquier
bloque.
Figura 3. Ejemplo de topología de clúster
2. Ningún rack contiene más de dos réplicas del mismo bloque, siempre
HDFS estima el ancho de banda de red entre dos nodos según su distancia. que haya suficientes racks en el clúster.
Se asume que la distancia entre un nodo y su nodo principal es uno. La distancia
entre dos nodos se puede calcular sumando sus distancias a su ancestro común
más cercano. Cuanto menor sea la distancia entre dos nodos, mayor será el ancho C. Gestión de replicación
de banda que podrán utilizar para transferir datos.
El NameNode se esfuerza por garantizar que cada bloque siempre tenga la
cantidad prevista de réplicas. El NameNode detecta si un bloque presenta una
HDFS permite al administrador configurar un script que devuelve la replicación insuficiente o excesiva cuando llega un informe de bloque de un
identificación del rack de un nodo a partir de su dirección. El NameNode es el DataNode. Cuando un bloque presenta una replicación excesiva, el NameNode
punto central que resuelve la ubicación del rack de cada DataNode. Cuando un selecciona una réplica para eliminar. El NameNode preferirá no reducir el número
DataNode se registra con el NameNode, este ejecuta un script configurado para de racks que alojan réplicas y, en segundo lugar, preferirá eliminar una réplica del
determinar a qué rack pertenece. Si no se configura dicho script, el NameNode DataNode con la menor cantidad de espacio de disco disponible. El objetivo es
asume que todos los nodos pertenecen a un mismo rack. equilibrar la utilización del almacenamiento entre los DataNodes sin reducir la
disponibilidad del bloque.
rack único predeterminado

La ubicación de las réplicas es fundamental para la fiabilidad de los datos de Cuando un bloque presenta una replicación insuficiente, se coloca en la cola
HDFS y el rendimiento de lectura/escritura. Una buena política de ubicación de de prioridad de replicación. Un bloque con una sola réplica tiene la máxima
réplicas debería mejorar la fiabilidad de los datos, la disponibilidad y el uso del prioridad, mientras que un bloque con un número de réplicas superior a dos tercios
ancho de banda de la red. Actualmente, HDFS ofrece una interfaz configurable de su factor de replicación tiene la mínima prioridad. Un subproceso en segundo
para la política de ubicación de bloques, de modo que los usuarios e investigadores plano escanea periódicamente la cabecera de la cola de replicación para decidir
puedan experimentar y probar cualquier política óptima para sus aplicaciones. dónde colocar las nuevas réplicas. La replicación de bloques sigue una política
similar a la de la colocación de nuevos bloques. Si solo hay una réplica, HDFS
coloca la siguiente réplica en un rack diferente. Si el bloque tiene dos réplicas, si
La política de ubicación de bloques HDFS predeterminada proporciona un
estas se encuentran en el mismo rack, la tercera réplica se coloca en un rack
equilibrio entre minimizar el costo de escritura y maximizar la confiabilidad de los
diferente; de lo contrario, se coloca en un nodo diferente dentro del mismo rack
datos, la disponibilidad y el ancho de banda de lectura agregado.
que la réplica existente. El objetivo es reducir el coste de creación de nuevas
Al crear un nuevo bloque, HDFS coloca la primera réplica en el nodo donde se
réplicas.
encuentra el escritor, la segunda y la tercera en dos nodos diferentes en un rack
distinto, y el resto en nodos aleatorios, con la restricción de que no se puede
colocar más de una réplica en un nodo ni más de dos en el mismo rack cuando el
número de réplicas es inferior al doble del número de racks. La decisión de colocar El NameNode también garantiza que no todas las réplicas de un bloque se
la segunda y la tercera réplica en un rack diferente distribuye mejor las réplicas de ubiquen en un mismo rack. Si detecta que las réplicas de un bloque terminan en

bloque de un mismo archivo en el clúster. Si las dos primeras réplicas se colocaran un rack, lo considera subreplicado y lo replica en otro rack utilizando la misma
en el mismo rack, dos tercios de las réplicas de bloque de cualquier archivo se política de ubicación de bloques descrita anteriormente.
ubicarían en el mismo rack.
Tras recibir la notificación de creación de la réplica, el bloque se sobrerreplica. El
NameNode decide entonces eliminar una réplica antigua, ya que la política de
sobrerreplicación prefiere no reducir el número de racks.
Una vez seleccionados todos los nodos de destino, estos se organizan como
una canalización según su proximidad a la primera réplica. Los datos se envían a
los nodos en este orden. Para la lectura, el NameNode comprueba primero si el
D. Balanceador
host del cliente se encuentra en el clúster. En caso afirmativo, las ubicaciones de
los bloques se devuelven al cliente según su proximidad al lector. El bloque se lee La estrategia de colocación de bloques de HDFS no tiene en cuenta la
desde los DataNodes en este orden de preferencia. (Es habitual en las aplicaciones utilización del espacio en disco de DataNode. Esto se hace para evitar colocar
MapReduce) datos nuevos (con mayor probabilidad de ser referenciados) en un pequeño subconjunto de...

Uso autorizado con licencia limitado a: UNIVERSITAT OBERTA DE CATALUNYA. Descargado el 23 de febrero de 2025 a las [Link] UTC desde IEEE Xplore. Se aplican restricciones.
Machine Translated by Google

Los nodos de datos. Por lo tanto, es posible que los datos no siempre se Para registrarse, así como las direcciones de host de los nodos que no tienen
distribuyan de forma uniforme entre ellos. El desequilibrio también se produce permiso para registrarse. El administrador puede ordenar al sistema que
cuando se añaden nuevos nodos al clúster. reevalúe estas listas de inclusión y exclusión. Un miembro actual del clúster que
se excluya se marca para su desmantelamiento. Una vez que un DataNode se
El balanceador es una herramienta que equilibra el uso del espacio en
marca como desmantelado, no se seleccionará como destino para la colocación
disco en un clúster HDFS. Toma un valor umbral como parámetro de entrada,
de réplicas, pero continuará atendiendo solicitudes de lectura. El NameNode
que es una fracción en el rango (0, 1). Un clúster está equilibrado si, para cada
comienza a programar la replicación de sus bloques a otros DataNodes. Una
nodo de datos, la utilización del nodo (relación entre el espacio utilizado en el
vez que el NameNode detecta que todos los bloques del DataNode que se
nodo y su capacidad total) difiere de la utilización del clúster completo (relación
desmantela están replicados, el nodo entra en estado desmantelado. A
entre el espacio utilizado en el clúster y su capacidad total) en un valor no
continuación, se puede eliminar del clúster de forma segura sin comprometer la
superior al umbral.
disponibilidad de los datos.

La herramienta se implementa como una aplicación que puede ser ejecutada

por el administrador del clúster. Mueve iterativamente las réplicas de los nodos G. Copia de datos entre clústeres
de datos con mayor utilización a los nodos de datos con menor utilización. Un
Al trabajar con grandes conjuntos de datos, copiar datos dentro y fuera de
requisito clave para el balanceador es mantener la disponibilidad de los datos.
un clúster HDFS resulta abrumador. HDFS ofrece una herramienta llamada
Al seleccionar una réplica para mover y decidir su destino, el balanceador
DistCp para la copia paralela de grandes volúmenes entre clústeres y dentro de
garantiza que la decisión no reduzca ni el número de réplicas ni el número de
ellos. Se trata de una tarea de MapReduce; cada tarea de mapeo copia una
racks.
parte de los datos de origen en el sistema de archivos de destino. El framework
MapReduce gestiona automáticamente la programación de tareas paralelas, la
El balanceador optimiza el proceso de balanceo minimizando la copia de detección de errores y la recuperación.
datos entre racks. Si el balanceador decide que es necesario mover una réplica
A a otro rack y el rack de destino contiene una réplica B del mismo bloque, los IV. ¡ PRÁCTICA EN YAHOO!

datos se copiarán de la réplica B en lugar de la réplica A.

Los grandes clústeres HDFS en Yahoo! incluyen alrededor de 3500 nodos.
Un nodo de clúster típico tiene:
Un segundo parámetro de configuración limita el ancho de banda consumido
∙ 2 procesadores Xeon de cuatro núcleos a 2,5
por las operaciones de reequilibrio. Cuanto mayor sea el ancho de banda
GHz ∙ Red Hat Enterprise Linux Server versión 5.1 ∙ Sun
permitido, más rápido podrá un clúster alcanzar el estado de equilibrio, pero con
Java JDK 1.6.0_13­b03
mayor competencia con los procesos de aplicación.
∙ 4 unidades SATA conectadas directamente (un terabyte cada una)
∙ 16 GB de
Escáner de bloque E
RAM ∙ Ethernet de 1 gigabit
Cada DataNode ejecuta un escáner de bloques que escanea periódicamente
sus réplicas y verifica que las sumas de comprobación almacenadas coincidan El setenta por ciento del espacio de disco se asigna a HDFS. El resto se
con los datos del bloque. En cada periodo de escaneo, el escáner ajusta el reserva para el sistema operativo (Red Hat Linux), los registros y el espacio para
ancho de banda de lectura para completar la verificación en un periodo distribuir la salida de las tareas de mapas.
configurable. Si un cliente lee un bloque completo y la verificación de la suma (Los datos intermedios de MapReduce no se almacenan en HDFS). Cuarenta
de comprobación es correcta, informa al DataNode. El DataNode lo considera nodos en un solo rack comparten un conmutador IP. Los conmutadores del rack
una verificación de la réplica. están conectados a cada uno de los ocho conmutadores centrales. Los
conmutadores centrales proporcionan conectividad entre racks y con recursos
El tiempo de verificación de cada bloque se almacena en un archivo de
externos al clúster. Para cada clúster, los hosts NameNode y BackupNode
registro legible. En cualquier momento, hay hasta dos archivos en el directorio
cuentan con hasta 64 GB de RAM; las tareas de aplicación nunca se asignan
principal del DataNode: el registro actual y el anterior. Los nuevos tiempos de
a estos hosts. En total, un clúster de 3500 nodos tiene 9,8 PB de almacenamiento
verificación se añaden al archivo actual. Por consiguiente, cada DataNode tiene
disponible en bloques que se replican tres veces, lo que genera un
una lista de escaneo en memoria ordenada según el tiempo de verificación de
almacenamiento neto de 3,3 PB para aplicaciones de usuario. Como
la réplica.
aproximación, mil nodos representan un PB de almacenamiento para
Cuando un cliente de lectura o un escáner de bloques detecta un bloque aplicaciones. A lo largo de los años de uso de HDFS (y en el futuro), los hosts
dañado, notifica al NameNode. El NameNode marca la réplica como dañada, seleccionados como nodos del clúster se benefician de tecnologías mejoradas.
pero no programa su eliminación inmediata. En su lugar, comienza a replicar
una copia correcta del bloque. Solo cuando el número de réplicas correctas Los nuevos nodos del clúster siempre cuentan con procesadores más rápidos,
alcanza el factor de replicación del bloque, se programa la eliminación de la discos más grandes y mayor RAM. Los nodos más lentos y pequeños se retiran
réplica dañada. Esta política busca preservar los datos el mayor tiempo posible. o se relegan a clústeres reservados para el desarrollo y las pruebas de Hadoop.
La elección de cómo aprovisionar un nodo de clúster es en gran medida una
Entonces, incluso si todas las réplicas de un bloque están corruptas, la política cuestión de compra económica de computación y almacenamiento.
permite al usuario recuperar sus datos de las réplicas corruptas. HDFS no impone una relación particular entre computación y almacenamiento
ni establece un límite en la cantidad de almacenamiento conectado a un nodo
de clúster.
F. Desmantelamiento
El administrador del clúster especifica qué nodos pueden unirse al clúster En un clúster grande de ejemplo (3500 nodos), hay aproximadamente 60
enumerando las direcciones de host de los nodos que tienen permiso. millones de archivos. Estos archivos tienen 63 millones de bloques. Como cada...

Uso autorizado con licencia limitado a: UNIVERSITAT OBERTA DE CATALUNYA. Descargado el 23 de febrero de 2025 a las [Link] UTC desde IEEE Xplore. Se aplican restricciones.
Machine Translated by Google

Un bloque suele replicarse tres veces; cada nodo de datos alberga 54 000 réplicas de Además de las fallas totales de los nodos, los datos almacenados pueden
bloques. Cada día, las aplicaciones de usuario crean dos millones de archivos nuevos corromperse o perderse. El escáner de bloques escanea todos los bloques de un clúster
en el clúster. Los 25 000 nodos de los clústeres Hadoop de Yahoo! proporcionan 25 PB grande cada quince días y encuentra alrededor de 20 réplicas defectuosas.
de almacenamiento de datos en línea. A principios de 2010, esta era una cifra modesta, proceso.
pero en crecimiento.
Fracción de la infraestructura de procesamiento de datos de Yahoo!. Yahoo! comenzó a B. Cuidando los bienes comunes
investigar la programación de MapReduce con un sistema de archivos distribuido en
A medida que el uso de HDFS ha crecido, el propio sistema de archivos ha tenido
2004. El proyecto Apache Hadoop se fundó en 2006. A finales de ese año, Yahoo! había
que introducir mecanismos para compartir el recurso dentro de una comunidad de
adoptado Hadoop para uso interno y contaba con un clúster de 300 nodos para desarrollo.
usuarios amplia y diversa. La primera de estas características fue un marco de permisos
Desde entonces, HDFS se ha convertido en una parte integral del back office de Yahoo!.
basado en el esquema de permisos de Unix para archivos y directorios. En este marco,
La aplicación estrella de HDFS ha sido la producción del Mapa Web, un índice de la
los archivos y directorios tienen permisos de acceso independientes para el propietario,
World Wide Web que es un componente crítico de la búsqueda (75 horas de tiempo
para otros miembros del grupo de usuarios asociado al archivo o directorio y para todos
transcurrido, 500 terabytes de datos intermedios de MapReduce, 300 terabytes de salida
los demás usuarios. Las principales diferencias entre Unix (POSIX) y HDFS radican en
total). Cada vez más aplicaciones se están migrando a Hadoop, especialmente aquellas
que los archivos comunes en HDFS no tienen permisos de ejecución ni bits fijos.
que analizan y modelan el comportamiento del usuario.

En el marco de permisos actual, la identidad del usuario es débil: usted es quien su

Convertirse en un componente clave del conjunto tecnológico de Yahoo! implicó
host dice ser. Al acceder a HDFS, el cliente de la aplicación simplemente consulta al
abordar problemas técnicos que marcan la diferencia entre ser un proyecto de
sistema operativo local la identidad del usuario y la pertenencia a grupos. Se está
investigación y ser el custodio de muchos petabytes de datos corporativos. Principalmente,
desarrollando un modelo de identidad más robusto. En el nuevo marco, el cliente de la
se trata de la robustez y durabilidad de los datos. Pero también son importantes el
aplicación debe presentar al sistema de nombres las credenciales obtenidas de una
rendimiento económico, la posibilidad de compartir recursos entre los miembros de la
fuente confiable. Se pueden administrar las credenciales de diferentes maneras; la
comunidad de usuarios y la facilidad de administración por parte de los operadores del implementación inicial utilizará Kerberos. La aplicación de usuario puede usar el mismo
sistema.
marco para confirmar que el sistema de nombres también tiene una identidad confiable.

A. Durabilidad de los datos Además, el sistema de nombres también puede exigir credenciales de cada uno de los
La replicación de datos tres veces es una protección robusta contra la pérdida de nodos de datos que participan en el clúster.
datos debido a fallos de nodos no correlacionados. Es improbable que Yahoo!
El espacio total disponible para el almacenamiento de datos se establece según la
ha perdido un bloque de esta forma; para un clúster grande, la probabilidad de perder
cantidad de nodos de datos y el almacenamiento provisto para cada nodo.
un bloque durante un año es inferior a 0,005. La clave radica en que aproximadamente
Las primeras experiencias con HDFS demostraron la necesidad de implementar medidas
el 0,8 % de los nodos fallan cada mes. (Incluso si el nodo se recupera finalmente, no se
para asegurar la asignación de recursos en las comunidades de usuarios. No solo es
realiza ningún esfuerzo para recuperar los datos que pudiera haber alojado). Por lo tanto,
necesario garantizar la equidad en la distribución, sino que, cuando una aplicación de
para el clúster grande de ejemplo descrito anteriormente, se pierden uno o dos nodos
usuario puede implicar la escritura de datos por parte de miles de hosts, también es
cada día.
importante protegerse contra el consumo involuntario de recursos. En HDFS, dado que
Ese mismo clúster recreará las 54 000 réplicas de bloques alojadas en un nodo fallido
los metadatos del sistema siempre se encuentran en la RAM, el tamaño del espacio de
en aproximadamente dos minutos. (La re­replicación es rápida porque es un problema
nombres (número de archivos y directorios) también es un recurso finito. Para gestionar
paralelo que escala con el tamaño del clúster). La probabilidad de que varios nodos fallen
los recursos de almacenamiento y espacio de nombres, se puede asignar a cada
en dos minutos, de modo que se pierdan todas las réplicas de algún bloque, es realmente
directorio una cuota para el espacio total ocupado por los archivos en el subárbol del
baja.
espacio de nombres que comienza en ese directorio. También se puede establecer una
cuota independiente para el número total de archivos y directorios en el subárbol.
La falla correlacionada de los nodos es una amenaza diferente. La más

Un fallo común en este sentido es el fallo de un conmutador de rack o de núcleo. HDFS

puede tolerar la pérdida de un conmutador de rack (cada bloque tiene una réplica en otro
Si bien la arquitectura de HDFS presupone que la mayoría de las aplicaciones
rack). Algunos fallos de un conmutador de núcleo pueden desconectar una parte del
transmitirán grandes conjuntos de datos como entrada, el marco de programación
clúster de varios racks, en cuyo caso es probable que algunos bloques dejen de estar
MapReduce puede tender a generar numerosos archivos de salida pequeños (uno por
disponibles. En cualquier caso, la reparación del conmutador restaura las réplicas no
cada tarea de reducción), lo que sobrecarga aún más el espacio de nombres. Para mayor
disponibles en el clúster. Otro tipo de fallo relacionado es la pérdida accidental o
comodidad, un subárbol de directorios puede comprimirse en un único archivo Hadoop.
deliberada de la alimentación eléctrica del clúster. Si la pérdida de alimentación afecta a
varios racks, es probable que algunos bloques dejen de estar disponibles. Sin embargo, Un archivo HAR es similar a un archivo tar, JAR o Zip, pero el sistema de archivos puede
gestionar los archivos individuales del archivo, y un archivo HAR puede utilizarse de
restaurar la alimentación puede no ser una solución, ya que entre el 0,5 % y el 1 % de
forma transparente como entrada para una tarea MapReduce.
los nodos no sobrevivirán a un reinicio completo. Estadísticamente, y en la práctica, un
clúster grande perderá algunos bloques durante un reinicio. (La estrategia de reiniciar
deliberadamente un nodo a la vez durante semanas para identificar los nodos que no
C. Puntos de referencia
sobrevivirán a un reinicio no se ha probado).
Un objetivo de diseño de HDFS es proporcionar un ancho de banda de E/S muy
alto para grandes conjuntos de datos. Existen tres tipos de mediciones que prueban
este objetivo.

Uso autorizado con licencia limitado a: UNIVERSITAT OBERTA DE CATALUNYA. Descargado el 23 de febrero de 2025 a las [Link] UTC desde IEEE Xplore. Se aplican restricciones.
Machine Translated by Google

• ¿Cuál es el ancho de banda observado desde un banco de pruebas artificial? Lograr con el diseño y hardware actuales. La tasa de E/S en la última columna es la
¿marca? combinación de lectura de entrada y escritura de salida desde y hacia HDFS. En la
segunda fila, si bien la tasa para HDFS se reduce, la E/S total por nodo será
• ¿Qué ancho de banda se observa en un clúster de producción con una
aproximadamente el doble, ya que para el conjunto de datos más grande (¡petabytes!),
combinación de trabajos de usuario?
los intermediarios de MapReduce también deben escribirse y leerse en el disco. En la
• ¿Qué ancho de banda se puede obtener con la aplicación de usuario a gran prueba más pequeña, no es necesario transferir los intermediarios de MapReduce al
escala construida con el mayor cuidado? disco; se almacenan en la memoria intermedia de las tareas.

Las estadísticas que se presentan aquí se obtuvieron de clústeres de al menos

3500 nodos. A esta escala, el ancho de banda total es lineal con el número de nodos,
por lo que la estadística interesante es el ancho de banda por nodo. Estos puntos de Los clústeres grandes requieren que el NameNode de HDFS admita la cantidad de
referencia están disponibles como parte del código base de Hadoop. operaciones de cliente esperadas en un clúster grande. La prueba de rendimiento
NNThroughput consiste en un proceso de un solo nodo que inicia la aplicación
NameNode y ejecuta una serie de subprocesos de cliente en el mismo nodo. Cada
El benchmark DFSIO mide el rendimiento promedio de las operaciones de lectura,
subproceso de cliente realiza la misma operación de NameNode repetidamente llamando
escritura y anexión. DFSIO es una aplicación disponible como parte de la distribución
directamente al método Name­Node que la implementa. La prueba mide la cantidad de
Hadoop. Este programa MapReduce lee, escribe y anexa datos aleatorios de/a archivos
operaciones por segundo que realiza el NameNode. Está diseñada para evitar la
grandes.
sobrecarga de comunicación causada por las conexiones RPC y la serialización, por lo
Cada tarea de mapeo dentro del trabajo ejecuta la misma operación en un
que ejecuta clientes localmente en lugar de remotamente desde diferentes nodos. Esto
archivo distinto, transfiere la misma cantidad de datos e informa su velocidad
proporciona el límite superior del rendimiento puro de NameNode.
de transferencia a la tarea de reducción. Esta última resume las mediciones.
La prueba se ejecuta sin contención de otras aplicaciones, y el número de
tareas de mapeo se elige proporcional al tamaño del clúster. Está diseñada
para medir el rendimiento únicamente durante la transferencia de datos y
excluye los gastos generales de la programación de tareas, el inicio y la tarea Operación Rendimiento (operaciones/s)
de reducción. Abrir archivo para leer 126 100

• Lectura DFSIO: 66 MB/s por nodo Crear archivo 5600

Cambiar el nombre del archivo 8300

• Escritura DFSIO: 40 MB/s por nodo
Eliminar archivo 20 700
En un clúster de producción, el número de bytes leídos y escritos se reporta a un
Latido del nodo de datos 300 000
sistema de recopilación de métricas. Estos promedios se calculan durante varias
Informe de bloques (bloques/s) 639 700
semanas y representan la utilización del clúster por trabajos de cientos de usuarios. En
promedio, cada nodo estuvo ocupado por una o dos tareas de aplicación en cualquier
Tabla 3. Punto de referencia de rendimiento de NN
momento (menos que la cantidad de núcleos de procesador disponibles).

V. TRABAJO FUTURO
• Lectura de clúster ocupado: 1,02 MB/s por nodo
Esta sección presenta algunos de los trabajos futuros que el equipo de Hadoop en
• Escritura en clúster ocupado: 1,09 MB/s por nodo Yahoo está considerando; al ser Hadoop un proyecto de código abierto, implica que las
nuevas características y los cambios son decididos por la comunidad de desarrollo de
Bytes/s de E/S HDFS Hadoop en general.
Bytes Por
Los mapas de nodos reducen el tiempo de agregación El clúster de Hadoop no está disponible cuando su NameNode está inactivo. Dado
(TUBERCULOSIS)
(ES) Nodo
que Hadoop se utiliza principalmente como sistema por lotes, reiniciar el NameNode ha
(MEGABYTE)
sido una solución satisfactoria. Sin embargo, hemos implementado la conmutación por
1 1460 8000 2700 62 segundos 32 22.1
error automática. Actualmente, un BackupNode recibe todas las transacciones del
1000 3658 80 000 20 000 58 500 s 34.2 9.35 NameNode principal. Esto permitirá una conmutación por error a un BackupNode
templado o incluso activo si enviamos informes de bloques tanto al NameNode principal
Tabla 2. Punto de referencia de ordenación para un terabyte y un petabyte de datos.
como al BackupNode. Algunos usuarios de Hadoop externos a Yahoo! han experimentado
Cada registro de datos tiene 100 bytes con una clave de 10 bytes. El programa de
con la conmutación por error manual.
prueba es un procedimiento de ordenación general, no especializado para el tamaño
del registro. En la ordenación de terabytes, el factor de replicación de bloques se Nuestro plan es utilizar Zookeeper, la tecnología de consenso distribuido de Yahoo,
estableció en uno, una ventaja modesta para una prueba corta. para crear una solución de conmutación por error automatizada.
En la clasificación de petabytes, el factor de replicación se estableció en dos para
La escalabilidad del NameNode [13] ha sido una lucha clave.
que la prueba se completara con confianza en caso de una falla de nodo (no
Dado que NameNode mantiene todos los espacios de nombres y las
inesperada).
ubicaciones de los bloques en memoria, el tamaño del montón de NameNode
A principios de 2009, Yahoo! participó en la competencia Gray Sort [9]. La ha limitado la cantidad de archivos y bloques direccionables. El principal
naturaleza de esta tarea enfatiza la capacidad del sistema para mover datos desde y desafío con NameNode ha sido que, cuando su uso de memoria se acerca al
hacia el sistema de archivos (en realidad, no se trata de ordenar). El aspecto competitivo máximo, deja de responder debido a la recolección de elementos no utilizados
significa que los resultados de la Tabla 2 se acercan a lo mejor que una aplicación de de Java y, en ocasiones, requiere un reinicio. Si bien hemos recomendado...
usuario puede lograr.

Uso autorizado con licencia limitado a: UNIVERSITAT OBERTA DE CATALUNYA. Descargado el 23 de febrero de 2025 a las [Link] UTC desde IEEE Xplore. Se aplican restricciones.
Machine Translated by Google

Aunque obligamos a nuestros usuarios a crear archivos más grandes, esto no ha

REFERENCIAS
sucedido, ya que requeriría cambios en el comportamiento de la aplicación. Hemos
añadido cuotas para gestionar el uso y hemos proporcionado una herramienta de [1] Apache Hadoop. [Link]
archivo. Sin embargo, esto no soluciona de forma fundamental el problema de [2] PH Carns, WB Ligon III, RB Ross y R. Thakur. “PVFS: Un sistema de archivos paralelo para
escalabilidad. clústeres Linux”, en Actas de la 4.ª Exposición y Conferencia Anual de Linux, 2000, págs.
317–327.
Nuestra solución a corto plazo para la escalabilidad consiste en permitir que [3] J. Dean, S. Ghemawat, “MapReduce: procesamiento de datos simplificado en clústeres grandes”,
varios espacios de nombres (y NameNodes) compartan el almacenamiento físico en actas del 6.º Simposio sobre diseño e implementación de sistemas operativos, San
dentro de un clúster. Estamos ampliando nuestros identificadores de bloque para que Francisco, CA, diciembre de 2004.

lleven como prefijo identificadores de grupo de bloques . Los grupos de bloques son [4] A. Gates, O. Natkovich, S. Chopra, P. Kamath, S. Narayanam, C.
Olston, B. Reed, S. Srinivasan, U. Srivastava. “Construcción de un sistema de flujo de datos
similares a los LUN en un sistema de almacenamiento SAN, y un espacio de nombres
de alto nivel sobre MapReduce: La experiencia de Pig”, en Proc. of Very Large Data Bases,
con su grupo de bloques es similar a un volumen del sistema de archivos.
vol. 2, n.º 2, 2009, págs. 1414­1425

Este enfoque es bastante simple y requiere cambios mínimos en el sistema. [5] S. Ghemawat, H. Gobioff, S. Leung. “El sistema de archivos de Google”, en Actas del Simposio
ACM sobre Principios de Sistemas Operativos, Lake George, NY, octubre de 2003, págs.
Ofrece varias ventajas además de la escalabilidad: aísla los espacios de nombres de
29–43.
diferentes conjuntos de aplicaciones y mejora la disponibilidad general del clúster.
[6] FP Junqueira, BC Reed. “La vida y obra de un cuidador de zoológico”, en Actas del 28.º
También generaliza la abstracción del almacenamiento en bloques para permitir que
Simposio de la ACM sobre Principios de Computación Distribuida, Calgary, AB, Canadá,
otros servicios utilicen el servicio de almacenamiento en bloques con, posiblemente, 10­12 de agosto de 2009.
una estructura de espacio de nombres diferente. Planeamos explorar otros enfoques [7] Sistema de archivos Lustre. [Link]
de escalado, como almacenar solo una parte del espacio de nombres en memoria y
[8] MK McKusick, S. Quinlan. “GFS: Evolución en avance rápido”, ACM Queue, vol. 7, n.º 7, Nueva
una implementación verdaderamente distribuida del NameNode en el futuro. En York, NY. Agosto de 2009.
particular, nuestra suposición de que las aplicaciones crearían una pequeña cantidad [9] O. O'Malley, AC Murthy. Hadoop ordena un petabyte en 16,25 horas y
de archivos grandes era errónea. Como se mencionó anteriormente, cambiar el Un terabyte en 62 segundos. Mayo de 2009.
comportamiento de las aplicaciones es difícil. Además, estamos viendo nuevas clases [Link]
yte_en_162.html
de aplicaciones para HDFS que necesitan almacenar una gran cantidad de archivos
pequeños. [10] R. Pike, D. Presotto, K. Thompson, H. Trickey, P. Winterbottom, “Uso de espacios de nombres
en Plan9”, Operating Systems Review, 27(2), abril de 1993, páginas 72–76.

La principal desventaja de tener múltiples espacios de nombres independientes [11] S. Radia, "Políticas de nombres en el sistema Spring", en Actas del 1er Taller IEEE sobre
Servicios en Entornos Distribuidos y en Red,
es el costo de su administración, especialmente si el número es elevado. También
Junio de 1994, págs. 164–171.
planeamos usar espacios de nombres centrados en aplicaciones o trabajos en lugar
[12] S. Radia, J. Pachl, “La visión por proceso de nombres y ejecución remota”, IEEE Parallel and
de espacios de nombres centrados en clústeres.
Distributed Technology, vol. 1, n.° 3, agosto de 1993, págs. 71–80.
Esto es análogo a los espacios de nombres por proceso que se utilizaron para lidiar
con la ejecución remota en sistemas distribuidos a fines de los años 80 y principios de [13] KV Shvachko, “Escalabilidad de HDFS: Los límites del crecimiento”, ;login:.
los 90 [10][11][12]. Abril de 2010, págs. 6–16.

[14] W. Tantisiriroj, S. Patil, G. Gibson. “Sistemas de archivos con uso intensivo de datos para
Actualmente, nuestros clústeres tienen menos de 4000 nodos. Creemos que
servicios de Internet: Una rosa con otro nombre...” Informe técnico CMU­PDL­08­114,
podemos escalar a clústeres mucho más grandes con las soluciones descritas Laboratorio de Datos Paralelos, Universidad Carnegie Mellon, Pittsburgh, PA, octubre de
anteriormente. Sin embargo, consideramos prudente tener varios clústeres en lugar de 2008.
un solo clúster grande (por ejemplo, tres clústeres de 6000 nodos en lugar de uno de [15] A. Thusoo, JS Sarma, N. Jain, Z. Shao, P. Chakka, S. Anthony, H. Liu, P. Wyckoff, R. Murthy,
18 000), ya que esto permite una disponibilidad y un aislamiento mucho mejores. Para “Hive: una solución de almacenamiento sobre un marco Map­Reduce”, en Proc. of Very
ello, planeamos proporcionar una mayor cooperación entre clústeres. Por ejemplo, Large Data Bases, vol. 2, n.º 2,
Agosto de 2009, págs. 1626­1629.
mediante el almacenamiento en caché de archivos a los que se accede remotamente o
[16] J. Venner, Pro Hadoop. Prensa, 22 de junio de 2009.
la reducción del factor de replicación de bloques cuando los conjuntos de archivos se
[17] S. Weil, S. Brandt, E. Miller, D. Long, C. Maltzahn, “Ceph: un sistema de archivos distribuido
replican entre clústeres.
escalable y de alto rendimiento”, en Proc. del 7.º
Simposio sobre diseño e implementación de sistemas operativos, Seattle, WA, noviembre
de 2006.
VI. RECONOCIMIENTO [18] B. Welch, M. Unangst, Z. Abbasi, G. Gibson, B. Mueller, J. Small, J.
Zelenka, B. Zhou, “Rendimiento escalable del sistema de archivos paralelos Panasas”, en
Agradecemos a todos los miembros del equipo HDFS de Yahoo!, tanto actuales
las actas de la 6.ª Conferencia USENIX sobre tecnologías de archivos y almacenamiento,
como pasados, por su arduo trabajo en la creación del sistema de archivos. San José, California, febrero de 2008
Agradecemos a todos los autores y colaboradores de Hadoop por sus valiosas [19] T. White, Hadoop: La guía definitiva. O'Reilly Media, Yahoo! Press, 5 de junio de 2009.
contribuciones. Corinne Chandel realizó las ilustraciones para este artículo.

10

Uso autorizado con licencia limitado a: UNIVERSITAT OBERTA DE CATALUNYA. Descargado el 23 de febrero de 2025 a las [Link] UTC desde IEEE Xplore. Se aplican restricciones.