HDFS.pdf

Almacenamiento Escalable
HDFS
Fernando Díaz Gómez
fdiaz@uva.es
Departamento de Informática, Universidad de Valladolid

Agenda
I. Diseño HDFS
1) Arquitectura
2) HDFS federado
3) HDFS HA
II. Configuración Hadoop
1) Configuración básica
2) Configuración segura
III. Administración HDFS
1) Estructuras de datos persistentes
2) Administración HDFS
IV. Formatos de Almacenamiento
1) Aspectos a Considerar
2) Formatos
3) Análisis Comparativo
4) Conclusiones

Diseño HDFS
1) Arquitectura
2) HDFS federado
3) HDFS HA
Almacenamiento escalable

Almacenamiento Escalable -4-
Arquitectura HDFS

Arquitectura HDFS: Bloques (i)
 Bloques HDFS:
 Los ficheros en HDFS se
dividen en bloques HDFS
que se almacenan como
unidades independientes,
pero en este caso en
diferentes nodos del clúster
 Además pueden replicarse
los bloques en diferentes
nodos
 Por defecto los bloques
HDFS tienen 128Mb

Arquitectura HDFS: Bloques (ii)
 Bloques HDFS:
 A diferencia de un sistema de ficheros convencional, un fichero en HDFS que ocupe menos de
un bloque (bien porque el fichero sea pequeño, o el último bloque del fichero no lo ocupe por
completo) no ocupa realmente todo el bloque en el almacenamiento subyacente.
 Por ejemplo, un fichero de 1MB se le asignaría un bloque HDFS (que por defecto tiene capacidad
para 128 MB) pero sólo ocupa realmente 1MB de espacio en disco, no los 128 MB.
 A nivel de clúster es la unidad de transferencia
 Los bloques HDFS son grandes comparativamente respecto a los bloques de disco y la razón es
minimizar el coste de las búsquedas. Si el bloque el lo suficientemente grande, el tiempo que lleva
transferir los datos desde el disco es significativamente mayor que el tiempo de buscar el comienzo
del bloque.
 De este modo, la transferencia de un fichero grande de bloques múltiples opera a la tasa de
transferencia del disco

Arquitectura HDFS: Bloques (iii)
 Hacer uso de la abstracción de bloques en un sistema distribuido conlleva
varios beneficios:
 El primero, un fichero puede ser mayor que cualquiera de los discos individuales del clúster
 Segundo, hacer que la unidad de abstracción sea un bloque en vez de un fichero, simplifica el
subsistema de almacenamiento.
 Además, los bloques se ajustan bien con los mecanismos de replicación para soportar
tolerancia de fallos y disponibilidad. Para protegerse contra la corrupción de bloques y el fallo
de disco o máquinas, cada bloque se replica en un pequeño de máquinas físicamente separadas
(típicamente el factor de replicación es tres).
 El mandato fsck de HDFS trata con bloques. Por ejemplo, el siguiente mandato
listará los bloques que forman cada fichero en el sistema de ficheros:
% hdfs fsck / -files -blocks

Arquitectura HDFS:
NameNodes y DataNodes (ii)
 El NameNode (NN) es el demonio que se ejecuta en el nodo maestro y está
encargado de gestionar el espacio de nombres del sistema de ficheros.
 Mantiene el árbol del sistema de ficheros y los metadatos de todos los ficheros y directorios del
árbol.
 Esta información se almacena persistentemente en el disco local (del NameNode) en forma de
dos ficheros: la imagen del espacio de nombres (namespace image) y el registro de edición (edit
log).
 El NameNode también conoce los DataNodes en los que todos los bloques de
un fichero dado se localizan. Sin embargo, no almacena las localizaciones de los
bloques de forma persistente ya que esta información se reconstruye a partir de
los DataNodes cuando se arranca el sistema.

Arquitectura HDFS:
NameNodes y DataNodes (iii)
 Un cliente accede al sistema de fichero sen nombre del usuario mediante
la comunicación con el NameNode y los DataNodes.
 El cliente exhibe una interfaz de sistema de ficheros similar a POSIX (Portable Operating
System Interface) de forma que el usuario no necesita conocer nada acerca de los
NameNodes y los DataNodes para operar.
 El DataNode (DN) es el demonio que se ejecuta en todos los nodos
esclavos del clúster HDFS y los DataNodes son realmente los trabajadores
del sistema de ficheros:
 Son los responsables de almacenar y recuperar bloques cuando así se les solicita (por parte
de los clientes o del NN),
 y de mantener informado al NN periódicamente con la lista de bloques que almacenan.

Arquitectura HDFS:
NameNodes y DataNodes (iv)
 Así pues, HDFS exhibe dos capas principales:
 Espacio de Nombres (namespace, con estado persistente en SF local del
NN)
 Formado por los directorios, ficheros y bloques
 Soporta todas las operaciones relacionadas con el espacio de nombres:
creación, borrado, modificación y listado de ficheros y directorios
 Servicio de almacenamiento de bloques, distinguiéndose a su vez entre:
 Gestión de bloques (responsabilidad del NN, con estado volátil en la memoria
del NN)
 Soporta pertenencia al clúster de los DNs, gestionando su registro y sus heart
beats periódicos
 Procesa los informes de bloques y mantiene la localización de los bloques
 Soporta las operaciones relacionadas con bloques tales como creación, borrado,
modificación y obtención de la localización de los bloques
 Gestiona la ubicación de las réplicas, replicación de bloques infra replicados y
eliminación de bloques sobre replicados
 Almacenamiento, proporcionado por los DNs mediante el almacenamiento
de bloques en sus sistemas de ficheros locales y permitiendo los accesos de
lectura/escritura

Conceptos HDFS:
NameNodes y DataNodes (v)
 Es importante hacer al NameNode resistente a fallos. Hadoop
proporciona dos mecanismos:
 La primera forma es hacer una copia de seguridad de los ficheros que
componen el estado de los metadatos del sistema de ficheros.
 Hadoop puede configurarse de modo que el NN escribe su estado persistente en varios
sistemas de ficheros. Estas escrituras son síncronas (bloqueantes) y atómicas. La elección
de configuración usual es escribir tanto en el SF local como en un SF NFS montado en
remoto.

Arquitectura HDFS:
NameNodes y DataNodes (v)
 NameNode resistente a fallos (cont.) :
 La segunda vía consiste en ejecutar un NameNode secundario, que a pesar de su
nombre no actúa realmente como un NN realmente.
 Su papel principal es consolidar periódicamente (habitualmente sobre una máquina física
diferente) el estado persistente del SF mediante la combinación de la imagen del espacio de
nombres con el registro de edición, con el fin de prevenir que este registro sea
excesivamente grande.
 Mantiene una copia del la imagen consolidada del espacio de nombres, que eventualmente podría
utilizarse en caso de fallo del NN primario.
 Sin embargo, el estado del NN secundario presenta un desfase respecto al primario, por lo
que en caso de fallo total del primario, la pérdida (parcial) de datos sería casi segura.
 En este caso, lo que se suele hacer es copiar los ficheros de los metadatos del NN que están
respaldados en la unidad NFS al secundario y ejecutarlo como si fuera el nuevo primario.

HDFS federado (i)
 El NN mantiene una referencia de cada fichero y bloque del sistema de
ficheros en memoria, lo que se traduce en que para clústeres muy
grandes, con muchos ficheros, la memoria se convierte en un factor de
limitación para el escalado
 HDFS federado (HDFS federation) se introdujo a partir de la versión 2.x, y
permite a un clúster escalar mediante la adición de NNs, cada uno de los
cuales maneja una parte del espacio de nombres del sistema de
ficheros.
 Por ejemplo, un NN1 podría manejar todos los ficheros almacenados bajo /user y un
segundo NN2 los ficheros bajo /share.

HDFS federado (ii)
 En un HDFS federado
 Cada NN gestiona un volumen del espacio de nombres (namespace
volume) que se compone de los metadatos del espacio de nombres y un
pool de bloques con todos los bloques de los ficheros de ese espacio de
nombres
 Los volúmenes del espacio de nombres son independientes unos de otros
(por lo que el fallo de un NN no afecta a la disponibilidad de los
namespaces gestionados por los otros)
 A nivel de almacenamiento, el pool de bloques no se particiona de
modo que todos los DNs se registran contra todos los NN del clúster y
almacenan bloques de los diferentes pools de bloques gestionados en
cada espacio de nombres
 Para acceder a un clúster HDFS federado, los clientes utilizan tablas de
montaje en el lado cliente que establecen la correspondencia entre las
rutas de los ficheros y los NNs asociados. Esto se gestiona utilizando la
interfaz ViewFileSystem y URIs precedidas por el esquema
viewfs://

HDFS HA (i)
 La combinación de replicación de metadatos del NameNode sobre varios
sistemas de ficheros y el uso de un nodo secundario para crear puntos de
control (checkpoints), son técnicas adecuadas para protegerse frente a la pérdida
de datos, pero no soportan el concepto de alta disponibilidad del sistema de
ficheros. El NameNode sigue siendo el elemento crítico (SPOF, single point of
failure)
 Si falla, todos los clientes (incluidos los trabajos MapReduce) serían incapaces de leer, escribir o
listar ficheros, ya que el NN es el único repositorio de los metadatos y de la tabla de
correspondencia fichero-bloques
 Para recuperar un NN caído, un administrador iniciaría un nuevo NN primario con una de las
réplicas de los metadatos del sistema de ficheros y los clientes usarían este nuevo NN. Se trataría
de un arranque en frío (start from cold).
 En grandes clústeres, el tiempo para arrancar en frío un NN puede ser considerable (30 minutos o más)

HDFS HA (ii)
 Hadood 2 introdujo un remedio a eta situación incorporando en su diseño la
noción de alta disponibilidad, o HDFS HA (high availability). En esta solución se
manejan dos NNs en configuración activo-espera_activa (active-standby).
 Para implementarlo, se requieren algunas modificaciones de diseño:
 Los dos NN deben utilizar algún almacenamiento de alta disponibilidad para compartir el log de
edición. Cuando “aparece” un NN en standby, se lee hasta el final del log de edición compartido
para sincronizar su estado con el NN activo, y luego continúa leyendo nuevas entradas a medida
que son escritas por el NN activo.
 Los DNs deben enviar sus informes de bloques a ambos NNs ya que la correspondencia de bloques
se mantiene en la memoria de un NN, no en disco.
 Los clientes deben configurarse para manejar la conmutación de NN en caso de fallo (failover),
utilizando un mecanismo transparente para los usuarios
 El papel de NN secundario es asumido por el NN en espera, siendo el encargado entonces de
generar puntos de control periódicos del espacio de nombres del NN activo.

HDFS HA (iii): Failover y fencing
 La conmutación en caso de fallo (failover) puede iniciarla manualmente el
administrador, por ejemplo en caso de realizar un mantenimiento rutinario. En
este caso, se puede hablar de una conmutación “elegante” (graceful failover),
ya que el controlador correspondiente puede organizar una transición
ordenada en el cambio de papeles de ambos NNs
 HDFS también soporta una conmutación automática en caso de fallo
sobrevenido (no esperado) del NN activo actual (automatic failover), pero para
ello se requiere la inclusión de dos nuevos componentes al despliegue HDFS: el
servicio de quorum ZooKeeper y el proceso controlador de conmutación
(ZKFC, ZKFailoverController):

HDFS HA (iv): Apache ZooKeeper
 Apache ZooKeeper es un servicio de alta disponibilidad para el
mantenimiento de pequeñas cantidades de datos de coordinación,
notificando a los clientes cambios en los mismos y monitorizando fallos
en los clientes. La implementación del failover automático en HDFS HA
confía al servicio ZooKeeper lo siguiente:
 Detección de fallos. Cada una de las máquinas NN del clúster mantiene una sesión
persistente ZooKeeper. Si la máquina falla, la sesión ZK expirará, y se notificará al resto de
NNs que debería dispararse una conmutación por fallo
 Elección del NN activo. ZooKeeper proporciona un mecanismo simple para la elección
exclusiva de un nodo como activo. Si el NN activo actual falla, otro nodo puede ganar el
control de un cerrojo de exclusión especial en ZooKeeper, indicando que se convertirá en el
siguiente activo

HDFS HA (v): Failover y fencing
 El ZKFailoverController (ZKFC) es un nuevo componente, un cliente
ZooKeeper, que también monitoriza y gestiona el estado del NN. Cada
máquina que ejecuta un NN también ejecuta un ZKFC, siendo éste el
responsable de:
 Monitorizar la salud del NN. El ZKFC periódicamente interroga (ping) a su NN local. En tanto que
el NN responda a tiempo, ZKFC lo considera en buen estado “de salud”. Si el nodo cae, se bloquea
o no responde se marcará como en estado “no saludable”
 Gestión sesión ZooKeeper. Cuando el NN local está en buen estado, ZKFC mantiene abierta la
sesión en ZooKeeper. Si el NN local es el activo, mantiene también un cerrojo especial en
Zookeeper. Si la sesión expira, el cerrojo se liberará automáticamente.
 Elección basada en ZooKeeper. Si el NN local está en buen estado y ZKFC observa que ningún
otro nodo mantiene el cerrojo especial, tratará de adquirirlo. Si lo consigue, se considera como
“ganador de la elección” y se responsabilizará de ejecutar los pasos para hacer la conmutación y
convertirse en el NN activo (básicamente, los comentados antes para hacer la transición al estado
activo, si acaso, precedidos por el aislamiento, mediante fencing, del nodo previamente activo).

HDFS HA (vi): log edición compartido
 Existen dos alternativas para soportar el almacenamiento
compartido de alta disponibilidad: una más sencilla, basada
en compartir el log de edición en una unidad NFS y otra,
más sofisticada, basada en un gestor (transaccional) de
diario por quorum (QJM, quorum journal manager).
 QJM es una implementación dedicada de HDFS, diseñada
con el único propósito de soportar el log de edición HA, por
lo que es la opción recomendada en la mayoría de
despliegues de un clúster HDFS
 Si el NN activo falla, el NN en standby sí puede tomar el control
rápidamente (en decenas de segundo), pudiéndose afirmar entonces
que el clúster tiene alta disponibilidad

1) Configuración básica Hadoop
2) Configuración segura Hadoop
Configuración Hadoop

Configuración (i)
 Cada componente de Hadoop se configura utilizando un fichero XML
 Las propiedades comunes aparecen en core-site.xml,
 Y las propiedades exclusivas de HDFS, MapReduce y YARN aparecen en el fichero
correspondiente, denominados : hdfs-site.xml, mapred-site.xmly yarn-
site.xml.
 Estos ficheros se localizan habitualmente en el subdirectorio /etc/hadoop
 Hadoop puede ejecutarse en uno de estos tres modos:
 Modo standalone (o local): No hay demonios ejecutándose y todo se ejecuta en una única
JVM (Java Virtual Machine).
 Modo pseudo distribuido: Los demonios Hadoop se ejecutan en la máquina local (cada uno
en su propia JVM), simulando por tanto un clúster a pequeña escala.
 Modo completamente distribuido: Los demonios de Hadoop se ejecutan (distribuidas) sobre
un clúster real de máquinas.

Configuración (ii)
 Para ejecutar Hadoop en un modo particular, se necesita hacer dos cosas:
 Fijar las propiedades adecuadas y arrancar los demonios de Hadoop
 La siguiente tabla muestra el mínimo conjunto de propiedades a configurar
para cada modo
Componente Propiedad Standalone Pseudo distribuido Completamente distribuido
Common fs.defaultFS file:/// (defecto) hdfs://localhost/ hdfs://namenode/
HDFS dfs.replication N/A 1 3 (defecto)
MapReduce mapreduce.frame
work.name
local (defecto) yarn yarn
YARN yarn.resourcemanager.hostname
yarn.nodemanager.auxservices
N/A
N/A
localhost
mapreduce_shuffle
resourcemanager
mapreduce_shuffle

Configurar un clúster Hadoop: Configuración
de Hadoop
 Ficheros configuración (bajo /etc/hadoop/)
Fichero Formato Descripción
hadoop-env.sh Script bash Variables de entorno utilizadas en los scripts para ejecutar Hadoop
mapred-env.sh Script bash Variables de entorno utilizadas en los scripts para ejecutar MapReduce (sobrescriben hadoop-env.sh)
yarn-env.sh Script bash Variables de entorno utilizadas en los scripts para ejecutar YARN (sobrescriben hadoop-env.sh)
core-site.xml Configuración Hadoop XML Opciones de configuración del núcleo de Hadoop: propiedades E/S communes a HDFS, MapReduce, y
YARN
hdfs-site.xml Configuración Hadoop XML Opciones de configuración de los demonios HDFS: namenode, namenode secundario y datanodes
mapred-site.xml Configuración Hadoop XML Opciones de configuración de los demonios MapReduce: job history server
yarn-site.xml Configuración Hadoop XML Opciones de configuraciónde los demonios YARN: resource manager, servidor proxy web y node
managers
slaves Configuración Hadoop XML Una lista de máquinas (una por línea) en la que se puede ejecutar un datanode y un node manager
log4j.properties Propiedades Java Propiedades de los ficheros de log del sistema: log de auditoria del sistema y log de tareas
hadoop-policy.xml Configuración Hadoop XML Opciones de configuración de las ACL cuando se ejecuta Hadoop en modo seguro

de Hadoop
 Gestión de la configuración
 Hadoop no tiene una única ubicación global para la información de configuración.
 En su lugar, cada nodo Hadoop del clúster mantiene su propio conjunto de ficheros de configuración, y
los administradores tienen la responsabilidad de garantizar que se mantengan sincronizados en todo el
sistema.
 Existen herramientas de shell paralelas que pueden ayudar a hacer esto, como dsh o pdsh, u otras
herramientas como scp.
 Propiedades del entorno (environment settings)
 Java: la ubicación de la implementación de Java a usar está determinada por la configuración de
JAVA_HOME en hadoop-env.sh o la variable de entorno de shell JAVA_HOME
 Archivos de log del sistema: los archivos de log del sistema generados por Hadoop, típicamente,
bajo /var/log
 Tamaño del montón de memoria (heap): de forma predeterminada, Hadoop asigna 1,000 MB (1
GB) de memoria a cada demonio que ejecuta

de Hadoop: propiedades importantes
 Las propiedades principales se establecen en los archivos de configuración: core-
site.xml, hdfs-site.xml y yarn-site.xml.
 Para encontrar la configuración real de un demonio en ejecución, puede visitarse la página /conf de su servidor
web asociado. Por ejemplo, http://resource-manager-host:8088/conf muestra la configuración
con la que se ejecuta el administrador de recursos. Por ejemplo:
<?xml version="1.0"?>

<configuration>
<property>
<name>fs.defaultFS</name>
<value>hdfs://namenode/</value>
</property>
</configuration>
<?xml version="1.0"?>

<configuration>
<property>
<name>dfs.namenode.name.dir</name>
<value>/disk1/hdfs/name,/remote/hdfs/name</value>
</property>
<property>
<name>dfs.datanode.data.dir</name>
<value>/disk1/hdfs/data,/disk2/hdfs/data</value>
</property>
<property>
<name>dfs.namenode.checkpoint.dir</name>
<value>/disk1/hdfs/namesecondary,/disk2/hdfs/namesecondary</value>
</property>
</configuration>

Nombre de propiedad Tipo Valor por defecto Descripción
fs.defaultFS URI file:/// Sistema de archivos por defecto. La URI define el nombre de
host y el puerto en el que se ejecuta el servidor RPC del
namenode. El puerto predeterminado es 8020. Esta
propiedad se establece en core-site.xml. Este valor se
utiliza para resolver rutas relativas.
dfs.namenode.name.dir Nombres directorios
separados por coma
file://${hadoop.tmp.dir
}/dfs/name
La lista de directorios donde el namenode almacena sus
metadatos persistentes. El namenode almacena una copia
de los metadatos en cada directorio de la lista.
dfs.datanode.data.dir Nombres directorios
separados por coma
}/dfs/data
Una lista de directorios donde el datanode almacena
bloques. Cada bloque se almacena en un único directorio.
dfs.namenode.checkpoint.dir Nombres directorios
separados por coma
}/dfs/namesecondary
Una lista de directorios donde el namenode secundario
almacena puntos de control. Almacena una copia del punto
de control en cada directorio de la lista.
• HDFS: opciones principales de configuración.

Nombre propiedad Tipo Valor por defecto Descripción
yarn.resourcemanager.hostname Hostname 0.0.0.0 El nombre de host en la que se ejecuta el administrador de recursos. En
adelante, abreviado por $ {y.rm.hostname}.
yarn.resourcemanager.address Hostname y
port
${y.rm.hostname}:8032 El nombre de host y puerto en el que se ejecuta el servidor RPC del
administrador de recursos.
yarn.nodemanager.local-dirs Nombres directorios
separados por coma
${hadoop.tmp.dir}/nm-
local-dir
Una lista de directorios donde los node manager permiten que los
contenedores almacenen datos intermedios. Los datos se borran cuando
finaliza la aplicación.
yarn.nodemanager.aux-services Nombres directorios
separados por coma
Una lista de servicios auxiliares ejecutados por cada node manager. La
clase definida por la propiedad
yarn.nodemanager.auxservices.servicename.class
implementa un servicio. Por defecto, no se especifican servicios auxiliares.
yarn.nodemanager.resource.memory-mb int 8192 La cantidad de memoria física (en MB) que se puede asignar a los
contenedores que se ejecutan en el node manager.
• YARN: opciones principales de configuración.

 Otras propiedades de Hadoop
 Pertenencia al clúster (cluster membership): para ayudar en la adición y eliminación de
nodos en el futuro, puede especificarse un fichero que contenga una lista de máquinas
autorizadas que puedan unirse al clúster como datanodes o node managers. El archivo se
especifica mediante las propiedades dfs.hosts y
yarn.resourcemanager.nodes.include-path, y las correspondientes
propiedades de dfs.hosts.exclude y
yarn.resourcemanager.nodes.exclude-path especifican los archivos
utilizados para la retirada (decommission).
 Tamaño del búfer: Hadoop utiliza un tamaño de búfer de 4 KB para sus operaciones de E/S.
Esta es una configuración conservadora, y con hardware y sistemas operativos modernos
(128 KB es una opción común). Se puede modificar este valor (en bytes) utilizando la
propiedad io.file.buffer.size en core-site.xml.

 Otras propiedades de Hadoop (cont.)
 Tamaño del bloque HDFS: el tamaño del bloque HDFS es de 128 MB por defecto, pero muchos
clústeres usan más (por ejemplo, 256 MB). La propiedad dfs.blocksize en hdfs-site.xml
sirve para fijar el tamaño en bytes.
 Papelera (trash): los sistemas de archivos de Hadoop tienen una facilidad de papelera, por la que
los archivos eliminados no se eliminan sino que se mueven a una carpeta trash, donde permanecen
por un período mínimo antes de que el sistema los elimine permanentemente. El período mínimo
(en minutos) se establece mediante la propiedad de configuración fs.trash.interval en
core-site.xml. De forma predeterminada, el intervalo de la papelera es cero, lo que
deshabilita la papelera.
 Lecturas locales en cortocircuito: al leer un archivo desde HDFS, el cliente se comunica con el
datanode y los datos se envían al cliente a través de una conexión TCP. Si el bloque que se está
leyendo está en el mismo nodo que el cliente, es más eficiente para el cliente descartar la conexión
red y leer los datos del bloque directamente desde el disco. Esto se denomina lectura local en
cortocircuito y puede hacer que las aplicaciones como HBase tengan un mejor rendimiento. Se
pueden habilitar las lecturas locales en cortocircuito configurando
dfs.client.read.shortcircuit a true.

Configurar un clúster Hadoop: Seguridad
 Las primeras versiones de Hadoop suponían que un grupo de usuarios
cooperantes utilizaría los clústeres HDFS y MapReduce dentro de un
entorno seguro.
 Los permisos de archivos HDFS proporcionan solo un mecanismo de autorización, que
controla lo que un usuario específico puede hacer con un archivo concreto. Por ejemplo, un
archivo puede ser leído solo por un determinado grupo de usuarios, por lo que cualquier
persona que no pertenezca a ese grupo, no está autorizada para leerlo.
 Lo que faltaba era un mecanismo de autenticación seguro para asegurar a Hadoop que el
usuario que busca realizar una operación en el clúster es quien dice ser y por lo tanto puede
ser fiable.

Configurar un clúster Hadoop: Seguridad
 Es habitual restringir el acceso a los datos que contienen información de
identificación personal (como el nombre completo o la dirección IP de un usuario
final) a un pequeño conjunto de usuarios (del grupo) dentro de la organización
que está autorizado para acceder a dicha información.
 Los datos menos confidenciales (o anónimos) pueden estar disponibles para un
conjunto más amplio de usuarios.
 Sin embargo, para cumplir con los requisitos reglamentarios para la protección de
datos, se debe implementar una autenticación segura para los clústeres
compartidos.
 En su diseño, Hadoop no administra las credenciales de los usuarios; en cambio, se basa en
Kerberos, un protocolo de autenticación de red de código abierto maduro, para autenticar al
usuario. Por el contrario, Kerberos no administra los permisos.

Configurar un clúster Hadoop: Seguridad:
Kerberos y Hadoop
 A alto nivel, hay tres pasos que un cliente debe seguir para acceder a un servicio
utilizando Kerberos, cada uno de los cuales implica un intercambio de mensajes
con un servidor:
1. Autenticación. El cliente se autentica ante el Servidor de autenticación y recibe un Ticket-
Granting Ticket (TGT) con un timestamp. Normalmente lo realiza explícitamente el usuario
mediante el comando kinit, que le pedirá una contraseña.
2. Autorización. El cliente utiliza el TGT para solicitar un ticket de servicio (service ticket) del
servidor de Ticket-Granting.
3. Petición de servicio. El cliente utiliza el ticket de servicio para autenticarse en el servidor que
proporciona el servicio que utiliza el cliente. En el caso de Hadoop, este podría ser el
namenode o el administrador de recursos.
 Juntos, el Servidor de autenticación y el Servidor de concesión de Ticket-
Granting forman el Centro de distribución de claves (KDC, Key
DistributionCenter).

Kerberos y Hadoop

Kerberos y Hadoop
 Ejemplo:
 El primer paso es habilitar la autenticación Kerberos configurando la propiedad
hadoop.security.authentication en core-site.xml a kerberos.
 La configuración predeterminada es simple, lo que significa que debe emplearse el antiguo comportamiento compatible con
versiones anteriores (pero inseguro), basado en usar el nombre de usuario del sistema operativo para determinar la
identidad.
 También se necesita habilitar la autorización de nivel de servicio configurando
hadoop.security.authorization a true en el mismo fichero.
 Se pueden configurar las listas de control de acceso (ACL) en el archivo de configuración hadoop-policy.xml
para controlar qué usuarios y grupos tienen permiso para conectarse a cada servicio de Hadoop.
 El formato para una ACL es una lista de nombres de usuarios separados por comas, seguido de un espacio en blanco,
seguido de una lista de nombres de grupos separados por comas.
 Con la autenticación Kerberos activada, si se intenta copiar un archivo local a HDFS, falla. Podemos conseguirlo
mediante la autenticación en el KDC, usando kinit
% kinit
Password for hadoop-user@LOCALDOMAIN: password
% hadoop fs -put quangle.txt .
% hadoop fs -stat %n quangle.txt
quangle.txt

Administración HDFS
1) Estructuras de datos persistentes
2) Administración HDFS

HDFS: Estructuras de datos persistentes
 Estructura de directorios del Namenode
 Un NN en ejecución tiene una estructura de directorio como esta:
${dfs.namenode.name.dir}/
├── current
│ ├── VERSION
│ ├── edits_0000000000000000001-0000000000000000019
│ ├── edits_inprogress_0000000000000000020
│ ├── fsimage_0000000000000000000
│ ├── fsimage_0000000000000000000.md5
│ ├── fsimage_0000000000000000019
│ ├── fsimage_0000000000000000019.md5
│ └── seen_txid
└── in_use.lock
 Recuérdese que la propiedad dfs.namenode.name.dir es una lista de directorios, con los mismos contenidos
replicados en cada directorio. Este mecanismo proporciona resiliencia, en particular si uno de los directorios está montado con NFS,
como se recomienda.
 El fichero in_use.lock es un fichero de bloqueo (lock file) que el NN utiliza para bloquear el directorio de almacén. Esto
evita que otra instancia de NN se ejecute al mismo tiempo con el mismo directorio de almacenamiento (y posiblemente lo
corrompa).

 Estructura de directorios del Namenode (cont.)
 El fichero VERSION es un fichero con propiedades Java que contiene información acerca de la versión de HDFS que se
está ejecutando:
#Mon Sep 29 09:54:36 BST 2014
namespaceID=1342387246
clusterID=CID-01b5c398-959c-4ea8-aae6-1e0d9bd8b142
cTime=0
storageType=NAME_NODE
blockpoolID=BP-526805057-127.0.0.1-1411980876842
layoutVersion=-57
 layoutVersion es un entero negativo que define la versión de las estructuras de datos persistentes de HDFS. Siempre que
cambie el esquema de datos, el número de versión se decrementa y, por tanto, HDFS necesita actualizarse
 namespaceID es un identificado único para el espacio de nombres (namespace) del sistema de ficheros, que se crea cuando se
formatea el NN por primera vez.
 clusterID es un identificador único para el clúster HDFS como un todo. Es importante para HDFS federado.
 blockpoolID es un identificador único para el pool de bloques que contiene todos los ficheros del espacio de nombres
gestionado por este NN. (https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-hdfs/Federation.html)
 cTime mantiene la fecha de creación del almacenamiento del NN.
 storageType especifica que este directorio de almacenamiento contiene estructuras de datos para un NN (valor
NAME_NODE).

 La imagen del sistema de ficheros y log de edición
 Cuando un cliente del sistema de ficheros realiza una operación de escritura (como la creación o
movimiento de un fichero), la transacción se registra primero en el log de edición (edit log). El NN
también tiene una representación en memoria de los metadatos del sistema de ficheros, que se
actualiza una vez de que el log de edición se ha modificado. Los metadatos en memoria se utilizan
para servir peticiones de lectura.
 Conceptualmente, el log de edición es una entidad única, pero se representa por un número de ficheros
en disco. Cada archivo se denomina segmento y su nombre tiene como prefijo edits seguido por un
sufijo que indica los ID de las transacciones que contiene.
 Solo un archivo está abierto a la vez para escritura
(edits_inprogress_000000000000000000020 en el ejemplo anterior), y se vuelca (flush) y se
sincroniza (sync) después de cada transacción, antes de devolver un código de éxito al cliente.
 En el caso de NNs que escriben en varios directorios, la escritura debe volcarse y sincronizarse con cada
copia, antes de informar del éxito al cliente. Esto asegura que no se pierda ninguna transacción debido
a un fallo del nodo.

 La imagen del sistema de ficheros y log de edición (cont.)
 Cada fichero fsimage es un punto de control persistente completo de los metadatos del
sistema de archivos. (El sufijo indica la última transacción consolidada en la imagen).
 Sin embargo, no se actualiza en cada operación de escritura sobre el sistema de ficheros, ya que
escribir el archivo fsimage, que puede llegar a tener un tamaño de gigabytes, sería muy lento.
 Esto no compromete la resiliencia porque si falla el NN, el estado más reciente de sus metadatos
puede reconstruirse cargando la última imagen del disco en la memoria, para luego aplicar sobre
ellos cada una de las transacciones del log de edición, a partir de la informada en el nombre de la
imagen cargada.
 De hecho, esto es lo que hace precisamente el NN cuando arranca.

 Cada fichero fsimage contiene, de forma serializada, todos los inodos de directorios y
ficheros del sistema de archivos.
 Cada inode es una representación interna de los metadatos de un fichero o directorio y
contiene información tal como: el nivel de replicación del fichero, los tiempos de
modificación y acceso, los permisos de acceso, el tamaño del bloque y los bloques que
conforman el archivo. Para los directorios, se almacenan el tiempo de modificación, los
permisos y los metadatos de cuota.
 Un fichero fsimage no registra los DNs donde están almacenados los bloques. En su lugar,
el NN mantiene esta correspondencia en memoria, y la construye interrogando a los DNs
por sus listas de bloques cuando se unen al clúster y después, periódicamente, para
garantizar que la tabla de correspondencia se mantenga actualizada.

 Proceso de consolidación
 Si el NN fuera reiniciado, podría llevar mucho tiempo aplicar las transacciones de su log de edición
(más, si fuera muy largo).
 Para prevenir esta situación el NN secundario produce checkpoints de los metadatos del sistema
de ficheros que mantiene el principal en memoria. El proceso de consolidación es como sigue:
1. El secundario le pide al primario que “rote” (roll) su fichero de ediciones actual, por lo que las
nuevas ediciones irán a un nuevo fichero. El primario también actualiza el archivo seen_txid
en todos sus directorios de almacenamiento.
2. El secundario recupera la última imagen y los ficheros de edición del primario (utilizando HTTP
GET).
3. El secundario carga la imagen en memoria, aplica cada transacción registrada por los ficheros
de edición, creando entonces un nuevo fichero de imagen, ya fusionado.
4. El secundario devuelve el nuevo fichero fsimage al primario (utilizando HTTP PUT), y el primario
lo guarda como un fichero temporal con extensión .ckpt.
5. El primario renombra la el fichero temporal de la imagen para que esté disponible.

HDFS: persistencia
 La imagen del sistema de
ficheros y log de edición (cont.)
 Proceso de consolidación (cont.)

 Proceso de consolidación (cont.)
 Al final del proceso, el primario tiene un fichero fsimage actualizado y un fichero de
ediciones actuales (inprogress edits) corto (no necesariamente vacío, ya que pueden
haberse recibido algunas ediciones mientras se estaba llevando a cabo la consolidación).
 Es posible que un administrador ejecute este proceso manualmente mientras el NN este
en modo seguro (safe mode), utilizando el mandato:
% hdfs dfsadmin -saveNamespace
 La planificación del proceso de consolidación se controla mediante dos parámetros de
configuración:
 El NN secundario crea un nuevo checkpoint cada hora
(dfs.namenode.checkpoint.period en segundos), o antes si el log de edición
alcanza un millón de transacciones desde el ultimo checkpoint
(dfs.namenode.checkpoint.txns), lo que se comprueba cada minuto
(dfs.namenode.checkpoint.check.period en segundos).

 Estructura de directorios del NN secundario
 La distribución de los directorios de checkpoint del secundario
(dfs.namenode.checkpoint.dir) es idéntica al del NameNode.
 Esto es así por diseño, ya que en caso de caída total del NN (cuando no hay otras copias de
respaldo recuperables, incluso desde NFS), permite la recuperación a partir del NN
secundario.
 Esto puede conseguirse …
 Bien copiando el directorio de almacenamiento adecuado a un nuevo NN, o
 Si el secundario se convierte en el nuevo NN primario, mediante el uso de la opción -
importCheckpoint cuando se arranca el demonio del NN.
 La opción -importCheckpoint cargará los metadatos del NN a partir del ultimo checkpoint
disponible en el directorio definido por la propiedad dfs.namenode.checkpoint.dir, pero
solo si no hay metadatos en el directorio dfs.namenode.name.dir, con el fin de garantizar de
que no hay riesgo de sobrescribir metadatos previos.

 Estructura de directorio del Datanode
 A diferencia de los namenode, los DNs no necesitan formatearse explícitamente, ya que ellos
crean automáticamente sus directorios de almacenamiento cuando arrancan. A continuación se
muestran los ficheros y directorios claves:
${dfs.datanode.data.dir}/
├── current
│ ├── BP-526805057-127.0.0.1-1411980876842
│ │ └── current
│ │ ├── VERSION
│ │ ├── finalized
│ │ │ ├── blk_1073741825
│ │ │ ├── blk_1073741825_1001.meta
│ │ │ ├── blk_1073741826
│ │ │ └── blk_1073741826_1002.meta
│ │ └── rbw
│ └── VERSION
└── in_use.lock

 Estructura de directorio del Datanode
 Los bloques HDFS se almacenan en ficheros con prefijo blk_. Contienen datos sin procesar (raw
data) de la parte correspondiente del fichero almacenado.
 Cada bloque tiene un fichero de metadatos asociado, cuyo nombre incluye el sufijo .meta. Está
compuesto por un encabezado con la versión y tipo de información, seguido de una serie de
checksums para las secciones del bloque
 Cada bloque pertenece a un grupo de bloques (block pool), y cada grupo de bloques tiene su
propio directorio de almacenamiento cuyo nombre se forma a partir de su ID (es el mismo ID de
grupo de bloques que aparece en el fichero VERSION del namenode).
 Cuando el número de bloques en un directorio crece hasta cierto tamaño, el DN crea un nuevo
subdirectorio en el que se colocan los nuevos bloques y sus metadatos asociados. Se crea un nuevo
subdirectorio cada vez que el número de bloques en un directorio llega a 64 (establecido por la propiedad
de configuración dfs.datanode.numblocks).
 Si la propiedad de configuración dfs.datanode.data.dir especifica varios directorios en diferentes
unidades (de disco), los bloques se escriben de forma rotatoria (no debe confundirse con la replicación de
bloques que se encuentra en distintos DNs).

Administración HDFS: Modo Seguro
 Cuando se arranca el NameNode, la primera tarea que se realiza es cargar su
fichero de imagen en memoria (fsimage) y aplicar las ediciones registradas en
el log de edición.
 Una vez reconstruida en memoria una imagen consistente de los metadatos del sistema de
ficheros, se crea un nuevo fichero fsimage (siendo el NN el que, efectivamente, construye el
nuevo checkpoint, sin recurrir al namenode secundario) y un log de edición vacío.
 Durante todo este proceso, el NN se está ejecutando en modo seguro (safe
mode), lo que significa que solo ofrece una vista de solo lectura del sistema de
ficheros a los clientes.
 Estrictamente hablando, en el modo seguro, está garantizado que funcionen solo las
operaciones que accedan a los metadatos del FS (como por ejemplo, listar un directorio).
 La lectura de un fichero funcionará solo cuando los bloques están disponibles en el conjunto
actual de DNs del clúster, y
 Las modificaciones de archivos (escrituras, borrados o renombrado) siempre fallarán.

 Recuérdese que las ubicaciones de bloque en el sistema no se guardan persistentemente por
parte del NN. Esta información reside con los DNs, en forma de listas de bloques que
almacenan cada uno de los DNs.
 Durante el transcurso normal de operación del sistema, el NN mantiene una correspondencia
de ubicación de bloques y ficheros, almacenada en memoria.
 El modo seguro se necesita para dar tiempo a los DNs a enviar al namenode sus listas de
bloques, de modo que el namenode consiga un número suficiente de ubicaciones de bloques
como para ejecutar el sistema de archivos de manera efectiva
 Se sale del modo seguro cuando se alcanza la condición de replicación mínima, más una
extensión de tiempo de 30 segundos (dfs.namenode.safemode.extension).
 La condición de replicación mínima se alcanza cuando el 99,9% de los bloques
(dfs.namenode.safemode.threshold-pct) del sistema de ficheros global alcanzan su nivel de replicación
mínimo (que por defecto es 1 y se establece mediante dfs.namenode.replication.min).

 Entrada y salida del modo seguro
 Para ver si el NN está en modo Seguro, se puede utilizar el mandato dfsadmin:
% hdfs dfsadmin -safemode get
Safe mode is ON
 Algunas veces se quiere esperar a que el NN salga del modo seguro antes de realizar un mandato,
especialmente dentro de un script. La opción de esperar se logra con:
% hdfs dfsadmin -safemode wait
# mandato para leer o escribir un fichero
 Para entrar en el modo seguro, utiliza el siguiente mandato:
% hdfs dfsadmin -safemode enter
Safe mode is ON
 Para dejar que el NN abandone el modo seguro::
% hdfs dfsadmin -safemode leave
Safe mode is OFF

Administración HDFS: registro de auditoría
 HDFS puede registrar todas las peticiones de acceso al sistema de ficheros.
El registro de auditoria se implementa utilizando la API LOG4J al nivel INFO
 En la configuración por defecto está desactivada, pero es fácil habilitarla añadiendo la
siguiente línea a hadoop-env.sh:
export HDFS_AUDIT_LOGGER="INFO,RFAAUDIT“
 Una línea de registro se escribe en el fichero de auditoría (hdfs-audit.log) para cada
evento HDFS. A continuación se muestra un ejemplo para un petición de listado del estado
sobre /user/tom:
2014-09-30 21:35:30,484 INFO FSNamesystem.audit: allowed=true ugi=tom
(auth:SIMPLE) ip=/127.0.0.1 cmd=listStatus src=/user/tom dst=null perm=null proto=rpc

Administración HDFS: Herramientas
 dfsadmin
 La herramienta dfsadmin es una herramienta multipropósito para obtener información acerca del estado de
HDFS, al igual que para realizar operaciones de administración sobre HDFS. Se invoca con hdfs dfsadmin y
requiere privilegios de root.
 Utiliza el mandato –help para obtener más información. Algunos de los mandatos dfsadmin son:
Mandato Descripción
-help Muestra ayuda para un mandato dado o para todos los mandatos si no se especifica ninguno.
-report Muestra estadísticas del SF e información sobre los DNs conectados.
-metasave Vuelca información a un fichero del directorio de log de Hadoop sobre los bloques que se están
replicándose o borrándose, y también una lista de DNs.
-safemode Cambiar o consultar el estado de modo seguro.
-saveNamespace Guardar la imagen del SF actual en memoria en un nuevo fichero fsimage y resetaer el fichero edits.
-fetchImage Recupera el ultimo fsimage mantenido por el namenode y lo guarda en un fichero local.
-refreshNodes Actualizar el conjunto de DNs a los que está permitido conectarse con el namenode.

 dfsadmin (cont.)
Mandato Descripción
-upgradeProgress Obtiene información del progreso de una actualización HDFS o fuerza a hacer una actualización.
-finalizeUpgrade Elimina los directorios de almacenamiento del NN y DNs de la version anterior. Se utiliza después de que
se haya aplicado una actualización y el clúster se ejecute correctamente en la nueva versión.
-setQuota Establece cuotas de directorio. Las cuotas fijan un límite en el número de nombres (ficheros o
directorios) del árbol de directorios.
-clrQuota Borra las cuotas de directorio especificadas.
-setSpaceQuota Establece cuotas de espacio en directorios. Las cuotas de espacio establecen un límite en el tamaño de
los archivos que se pueden almacenar en un árbol de directorios.
-clrSpaceQuota Borra las cuotas de espacio especificadas.
-allowSnapshot Habilita la creación de snapshots para el directorio especificado.
-disallowSnapshot Deshabilita la creación de snapshots para el directorio especificado.

 Chequeo del sistema de ficheros (fsck)
 Hadoop proporciona la utilidad fsck para comprobar el estado de los ficheros de HDFS. La herramienta busca
por bloques “perdidos” en todos los DNs, así como los bloques sobre o infra replicados. A continuación se
muestra un ejemplo:
% hdfs fsck /
......................Status: HEALTHY
Total size: 511799225 B
Total dirs: 10
Total files: 22
Total blocks (validated): 22 (avg. block size 23263601 B)
Minimally replicated blocks: 22 (100.0 %)
Over-replicated blocks: 0 (0.0 %)
Under-replicated blocks: 0 (0.0 %)
Mis-replicated blocks: 0 (0.0 %)
Default replication factor: 3
Average block replication: 3.0
Corrupt blocks: 0
Missing replicas: 0 (0.0 %)
Number of data-nodes: 4
Number of racks: 1
The filesystem under path '/' is HEALTHY

 fsck recorre recursivamente recorre el espacio de nombres del SF, comenzando en la ruta dada y
verifica los archivos que encuentra. Visualiza un punto por cada archivo que comprueba. Para
verificar un archivo, fsck recupera los metadatos de los bloques del archivo y busca problemas o
inconsistencias.
 Condiciones informadas por fsck:
 Bloques sobre replicados: estos son bloques que exceden el factor de replicación establecido para el
fichero al que pertenecen. Normalmente, la replicación excesiva no es un problema, y HDFS eliminará
automáticamente el exceso de réplicas
 Bloques infra replicados: estos son bloques que no alcanzan el factor de replicación particular del
fichero al que pertenecen. HDFS creará automáticamente nuevas réplicas de bloques infra replicados
hasta que cumplan con la replicación establecida.
 Bloques mal replicados: estos son bloques que no satisfacen la política de ubicación de réplicas de
bloques. Por ejemplo, para un nivel de replicación de tres en un clúster multirack, si las tres réplicas de
un bloque están en el mismo bastidor, entonces el bloque está mal replicado porque las réplicas deben
extenderse en, al menos, dos racks para lograr resiliencia. HDFS volverá a replicar automáticamente los
bloques mal replicados para que cumplan con la política de ubicación en el rack.

 Condiciones informadas por fsck (cont.):
 Bloques dañados (corrupt): Estos son bloques cuyas réplicas están todas corruptas. Los bloques con al
menos una réplica no corrupta no se informan como corruptos; el NameNode replicará la réplica no
corrupta hasta que se cumpla el factor de replicación correspondiente.
 Réplicas perdidas (missing): Estos son bloques sin réplicas en ninguna parte del clúster.
 Los bloques dañados o perdidos son la principal causa de preocupación, ya que se traducen en
pérdida de datos. Por defecto, fsck mantiene los ficheros con bloques dañados o perdidos, pero
le puedes indicar que realice sobre ellos una de las siguientes acciones:
 Mover los ficheros afectados al directorio /lost+found de HDFS, usando la opción -move. Los
ficheros se dividen en cadenas de bloques contiguos para tratar de ayudar en cualquier intento de
recuperación.
 Borrar los ficheros afectados, usando la opción -delete. Los archivos no pueden recuperarse después
de borrarse.

 Encontrar todos los bloques de un archivo. La herramienta fsck proporciona una manera fácil
de averiguar qué bloques están en un archivo concreto. Por ejemplo:
% hdfs fsck /user/tom/part-00007 -files -blocks -racks
/user/tom/part-00007 25582428 bytes, 1 block(s): OK
0. blk_-3724870485760122836_1035 len=25582428 repl=3 [/default-
rack/10.251.43.2:
50010,/default-rack/10.251.27.178:50010, /default-rack/10.251.123.163:50010]
 En este ejemplo, el fichero /user/tom/part-00007 está formado por un bloque y se
muestran los DataNodes donde se encuentra las réplicas del bloque. Las opciones utilizadas de
fsck son las siguientes:
 La opción -files muestra la línea con el nombre de fichero, tamaño, número de bloques y su
estado (por si faltan bloques).
 La opción –blocks muestra información sobre cada bloque en el fichero, una línea por bloque.
 La opción -racks muestra la ubicación del rack y direcciones del DataNode para cada bloque.

 Escáner de bloques del DataNode (datanode block scanner)
 Cada DataNode ejecuta un escáner de bloques, que verifica periódicamente todos los bloques
almacenados en el mismo.
 Esto permite detectar y corregir los bloques defectuosos antes de que los clientes los lean.
 El escáner mantiene una lista de bloques por verificar y los escanea uno por uno, en busca de errores
de suma de comprobación (checksums).
 Los bloques se verifican cada tres semanas para protegerse frente a errores de disco a lo largo del
tiempo (este período está controlado por la propiedad dfs.datanode.scan.period.hours,
que de manera predeterminada es de 504 horas). Los bloques defectuosos son comunican al
NameNode para corregirlos.

 Balanceador (balancer)
 Con el tiempo, la distribución de bloques a lo largo de los datanodes puede
desequilibrarse.
 Un clúster desequilibrado puede afectar al principio de localidad explotado por MapReduce, así como
ejercer una mayor presión sobre los datanodes altamente utilizados, por lo que es mejor evitarlo.
 El balanceador es un demonio de Hadoop que redistribuye los bloques moviéndolos
de los datanodes sobre utilizados a los datanodes infrautilizados, mientras que se
mantiene, al mismo tiempo, la política de ubicación de réplicas de bloques, que hace
que la pérdida de datos sea improbable al colocar réplicas de bloques en diferentes
racks.
 El balanceador mueve los bloques hasta que se considera que el clúster está equilibrado, lo que significa
que la utilización de cada datanode (relación del espacio utilizado en el nodo respecto a la capacidad total
del nodo) no difiere de la utilización del clúster (relación del espacio utilizado en el clúster respecto a la
capacidad total del clúster) en más de un umbral determinado (expresado en porcentaje).

Monitorización
 Monitorización
 El propósito de la monitorización es detectar cuándo el clúster no proporciona el
nivel de servicio esperado.
 Los demonios maestros son los más importantes de monitorear: los NameNode
(primario y secundario) y el administrador de recursos (resource manager).
 Es de esperar que se produzcan fallos en los datanodes y los administradores de nodos (node
managers), en particular, en clústeres más grandes, por lo que debe proporcionar capacidad
adicional para que el clúster pueda tolerar tener un pequeño porcentaje de nodos caídos de
este tipo de nodos en cualquier momento

Monitorización
 Logging
 Los archivos de registro (log) del sistema generados por Hadoop se almacenan, por defecto,
en $HADOOP_HOME/logs. Esto se puede cambiar usando la configuración
HADOOP_LOG_DIR en hadoop-env.sh. Una opción común es /var/log/hadoop,
que se fija incluyendo la siguiente línea en hadoop-env.sh:
export HADOOP_LOG_DIR=/var/log/hadoop
 Todos los demonios de Hadoop generan archivos de registro que pueden ser muy útiles
para descubrir qué está sucediendo en el sistema. Hay dos tipos de archivos de registro:
 El primero es la salida de log escrita a través de LOG4J. Este archivo tiene extensión .log.
 El segundo fichero de log es la salida estándar combinada y el registro de errores estándar. Este
archivo de registro, cuyo nombre termina en .out, generalmente contiene poca o ninguna
salida, ya que Hadoop usa LOG4J para el registro.

Monitorización
 Logging: Estableciendo niveles de registro
 Al analizar un error, es muy conveniente poder cambiar, temporalmente, el nivel de registro para
un componente particular del sistema.
 Los demonios de Hadoop tienen una página web para cambiar el nivel de registro de cualquier
nombre de registro LOG4J, que se puede encontrar en /logLevel en la interfaz web del demonio
correspondiente. Por convención, los nombres de log en Hadoop corresponden a los nombres de
las clases que realizan el registro.
 Por ejemplo, para habilitar el registro de depuración para todas las clases relacionadas con el
administrador de recursos, visitaríamos su interfaz de usuario web en http://resource-manager-
host:8088/logLevel y fijaríamos el nombre de registro
org.apache.hadoop.yarn.server.resourcemanager al valor DEBUG.
 Lo mismo se puede conseguir desde la línea de mandatos de la siguiente manera:
% hadoop daemonlog -setlevel resource-manager-host:8088
org.apache.hadoop.yarn.server.resourcemanager DEBUG
 O cambiando el archivo log4j.properties en el directorio de configuración. En este caso,
añadiendo la línea:
log4j.logger.org.apache.hadoop.yarn.server.resourcemanager=DEBUG

Mantenimiento HDFS: Procedimientos
Administración Rutinarios
 Backups de los metadatos
 Si los metadatos persistentes del NameNode se pierden o se dañan, todo el sistema de
archivos se vuelve inutilizable, por lo que es fundamental que se realicen copias de seguridad
de estos ficheros.
 Deben conservarse varias copias de diferentes edades (por ejemplo, una hora, un día, una
semana y un mes) para protegerse contra la corrupción de estos ficheros, ya sea en las copias
o en los ficheros de metadatos actuales almacenados en el namenode.
 Una forma sencilla de hacer copias de seguridad es usar el comando dfsadmin para
descargar una copia del fichero fsimage más reciente del namenode:
% hdfs dfsadmin -fetchImage fsimage.backup

 Backups de datos
 Aunque HDFS está diseñado para almacenar datos de manera fiable, la pérdida de datos puede
ocurrir, como en cualquier sistema de almacenamiento. Por lo tanto, una estrategia de copia de
seguridad es esencial.
 Con los grandes volúmenes de datos, decidir qué datos respaldar y dónde almacenarlos es un desafío. La
clave aquí es priorizar los datos.
 Es común tener una política de copia de seguridad para directorios de usuarios en HDFS. Por ejemplo,
pueden tener cuotas de espacio y respaldarse todas las noches.
 La herramienta distcp es ideal para realizar copias de seguridad en otros clústeres HDFS
(preferiblemente ejecutándose en una versión diferente del software, para evitar la pérdida debido a
errores en HDFS) u otros sistemas de archivos Hadoop (como S3) porque puede copiar archivos en
paralelo.
 HDFS permite a los administradores y usuarios tomar instantáneas (snapshots) del sistema de archivos.
 Una instantánea es una copia de solo lectura de un subárbol del sistema de archivos en un momento dado.
 Las instantáneas son muy eficientes ya que no copian datos; simplemente registran los metadatos y la lista de
bloques de cada archivo

 Comprobación del sistema de ficheros (fsck)
 Es aconsejable ejecutar la herramienta fsck de HDFS regularmente (es decir,
diariamente) en todo el sistema de archivos para buscar activamente los bloques
perdidos o dañados
 Balanceador del sistema de ficheros
 Es aconsejable ejecutar la herramienta de balanceo con regularidad para mantener
equilibrados los DataNodes del sistema de archivos.

Formatos de Almacenamiento
1) Aspectos a Considerar
2) Formatos
3) Análisis Comparativo
4) Conclusiones

Formatos de Almacenamiento
 La elección del formato de almacenamiento más apropiado es esencial para conseguir un
rendimiento óptimo y alcanzar los objetivos de negocio:
 El sistema de archivos permite almacenar los formatos de datos habituales (texto, binarios, imágenes…).
 Hadoop proporciona formatos de almacenamiento optimizados para abordar las necesidades del Data Lake:
 Gestión del espacio de almacenamiento, optimización del tiempo de procesamiento, así como el de lectura y
escritura de los datos, o el uso de ancho de banda.
 Aspecto a considerar para la elección del formato:
 Almacenamiento por filas o por columnas.
 Evolución del esquema.
 Divisibilidad.
 Compresión.
Diseño HDFS
Formatos
Aspectos a Considerar
Formatos
Análisis Comparativo
Conclusiones

Formato Contenedor
 El fichero contiene una cabecera y una secuencia de
bloques de datos:
 Cada bloque de datos contiene, internamente, una secuencia
de bloques comprimidos (con el compresor elegido) separados
por un carácter espacial (sync marker):
 Cada bloque comprimido puede decodificarse independientemente
del resto de bloques.
 La cabecera proporciona los metadatos necesarios para
interpretar el contenido (por ejemplo, el sync marker).
Formatos
Conclusiones
Fuente: “Hadoop Application Architectures”
(Grover, et al. 2015)
Diseño HDFS
Formatos

¿Filas o Columnas?
 La decisión de almacenar los datos por
filas o por columnas es fundamental para
satisfacer los objetivos del proyecto:
 El almacenamiento por columnas es preferible
cuando es necesario llevar a cabo consultas
analíticas que acceden a un (pequeño)
subconjunto de los atributos de los datos.
Formatos
Conclusiones
Fuente: “An Introduction to Big Data Formats” (Nexla, 2019)
 El almacenamiento por filas proporciona un mejor rendimiento cuando las operaciones
acceden a todos (o la mayoría) de los atributos de los datos.
Diseño HDFS
Formatos

Almacenamiento por Filas
 Los formatos orientados a filas almacenan de forma contigua toda la información
perteneciente a un mismo registro:
 Los datos se procesan leyendo el fichero de “izquierda a derecha” y de “principio a fin”.
 Estos formatos son apropiados cuando los registros se procesan completamente,
pero sobrecargan las operaciones que sólo requieren algunos de los campos.
Formatos
Conclusiones
Emma,Prod1,100.00,2018-04-02; Liam,Prod2,79.99,2018-04-02;
Noah,Prod3,19.99,2018-04-01; Olivia,Prod2,79.99,2018-04-03
Diseño HDFS
Formatos

Almacenamiento por Columnas
 Los formatos orientados a columnas almacenan secuencialmente los valores asociados
con cada campo de los registros:
 Esta “agrupación” de datos permite operar eficientemente sobre cada columna, ya que los valores
correspondientes están almacenados de forma contigua.
 Además, no obliga a procesar las columnas que no participen en la operación.
 Estos formatos son apropiados cuando las operaciones analizan sólo algunos (pocos)
campos de los registros.
Formatos
Conclusiones
Emma,Liam,Noah,Olivia; Prod1,Prod2,Prod3,Prod4; 100.00,
79.99,19.99,79.99;2018-04-02,2018-04-02,2018-04-01,2018-04-03
Diseño HDFS
Formatos

Evolución del Esquema
 El esquema de una colección de datos en el Data Lake comprende la descripción de
cada uno de los campos (nombre y tipo de datos):
 La forma más simple de esquema es la cabecera del fichero.
 Si no se prevén cambios en el esquema de los datos, este aspecto es irrelevante.
 En caso contrario, es necesario considerar lo siguiente:
 ¿El formato permite añadir, eliminar o actualizar la descripción de un campo?
 ¿Las diferentes versiones del esquema son “compatibles”?
 ¿El formato es legible para humanos? ¿Es necesario?
 ¿El esquema se procesa eficientemente? ¿El espacio que ocupa el esquema es relevante?
Formatos
Conclusiones
Diseño HDFS
Formatos

Divisibilidad
 La divisibilidad de los ficheros tiene un gran impacto en el rendimiento de las
operaciones de procesamiento:
 Hadoop trata de paralelizar lo máximo posible el procesamiento de los datos contenidos en
cada fichero.
 Para ello, requiere poder operar independientemente sobre cada parte del fichero.
 Un formato es divisible (splittable) si facilita que sus contenidos se puedan
procesar independientemente:
 Los formatos orientados a columnas son divisibles por definición.
 Los formatos orientados a filas requieren que se puedan identificar subconjuntos de filas con
significado propio y completo.
Formatos
Conclusiones
Diseño HDFS
Formatos

Compresión
 Comprimir los datos ayuda a reducir el espacio de almacenamiento utilizado y a
mejorar el rendimiento de las operaciones de transferencia:
 Es necesario considerar los tradeoffs espacio-tiempo de cada compresor:
 Los compresores más efectivos suelen menos eficiente en las operaciones de (des)compresión.
 La compresión es un mecanismo de optimización muy efectivo en Hadoop:
 Además de los tradeoffs espacio-tiempo, es necesario considerar si el fichero comprimido es
divisible.
Formatos
Conclusiones
Diseño HDFS
Formatos

Compresión
 gzip y bzip2 son más efectivos, pero su velocidad de (des)compresión no es competitiva en la mayoría de los procesos
del Data Lake.
 Snappy, LZ4 y LZO obtienen buenos tradeoffs, aunque destacan por su eficiencia (sobre todo los dos primeros):
 Snappy y LZ4 no son directamente divisibles porque están diseñados para operar con un formato contenedor.
 LZO es divisible si se indexa el fichero comprimido, por lo que es ideal para texto plano (que no se almacena en un formato
contenedor), aunque también puede usarse en formatos contenedor.
Formatos
Conclusiones
Compresor Extensión ¿Divisible? Efectividad
(ratio de compresión)
Eficiencia
(velocidad de (des)compresión)
gzip .gz ✕ Media-alta Media
bzip2 .bz2 ✔ Alta Lenta
Snappy .snappy ✕ Media Rápida
LZO .lzo ✕* Media Rápida
LZ4 .lz4 ✕ Media Rápida
* LZO puede ser divisible si se le añade un índice al fichero comprimido.
Diseño HDFS
Formatos

¿Qué compresor uso?
1) Almacenar los datos utilizando un formato de contenedor, ya que todos ellos
permiten integrar compresión y ser divisibles.
2) En caso de no poder optar por 1), utilizar un formato de compresión divisible.
3) En caso de no poder optar por 2):
 Dividir los datos en chunks y comprimir cada uno de ellos independientemente con el compresor
más adecuado.
 El tamaño del chunk debe elegirse cuidadosamente para que cuando se comprima ocupe,
aproximadamente, un bloque del sistema de archivos (128MB).
4) Almacenar los datos en planos (sin compresión).
Formatos
Conclusiones
Diseño HDFS
Formatos

Formatos
 Orientados a filas:
 Text:
 Plano: CSV, texto…
 Estructurado: JSON, XML…
 SequenceFile.
 Avro.
 Orientados a columnas:
 ORC.
 Parquet.
Formatos
Conclusiones
Fuente: https://pxhere.com/ (@mohamed hassan)
Diseño HDFS
Formatos

CSV
 CSV (Comma Separated Values) es un formato tabular en que cada fila es un
registro y cada columna (separada por comas) proporciona el valor de un campos:
 Es un formato muy simple y ampliamente soportado en Hadoop:
 Es fácil de editar y una persona puede leerlo directamente.
 Se parsea de forma eficiente y muchas aplicaciones tienen utilidades para operar con él.
 Características:
 Proporciona un esquema simple y es compacto (los “metadatos” se declaran en una
línea de cabecera única).
 Los ficheros CSV son divisibles en formato plano y también comprimido (bzip2 o lzo
indexado).
Formatos
Conclusiones
Característica Soporte
Tipo de almacenamiento Filas
Evolución del Esquema ✕
Divisibilidad ✔
Compresión ✔
Legible ✔
Tipos Complejos ✕
 No permite asociar tipos de datos con las columnas y los datos complejos no pueden procesarse directamente.
 Presenta algunos problemas en la importación (por ejemplo, con valores NULL), no soporta bien los caracteres
especiales y no tiene una forma estandarizada de presentar datos binarios.
Diseño HDFS
Formatos

JSON
 JSON (JavaScript Object Notation) es un formato semi-estructurado que
organiza los datos en forma de pares (clave, valor):
 Su uso es muy común para propósitos de intercambio de datos (servicios web REST).
 Es un formato muy utilizado en bases de datos NoSQL y plataformas empresariales,
además de estar soportado en múltiples lenguajes de programación.
 Características:
 Almacena los datos y los metadatos de forma integrada, facilitando la evolución del
esquema.
Formatos
Conclusiones
Divisibilidad ✔*
Compresión ✔
Legible ✔
Tipos Complejos ✔
 Soporta estructuras jerárquicas y simplifica el almacenamiento de datos relacionados dentro del mismo
documento.
 La divisibilidad de un fichero JSON depende de la organización interna de sus objetos.
Diseño HDFS
Formatos

SequenceFile
 SequenceFile proporciona un formato binario que almacena los datos
(por filas) en forma de pares (clave,valor):
 Formato completamente integrado en el ecosistema Hadoop.
 Ocupa menos espacio que los ficheros textuales.
 Puede utilizarse para almacenar múltiples ficheros pequeños:
 Cada fichero se considera un registro del Sequence File.
Formatos
Conclusiones
Fuente: “Hadoop: The Definitive
Guide” (White, 2015)
 SequenceFile soporta compresión a nivel de registro y de bloque:
 Cada bloque combina múltiples registros, que se comprimen como una misma unidad
lógica.
 La compresión a nivel de bloque proporciona mejores resultados.
 Ofrece una variante indexada (MapFile) que permite acceder eficientemente
a los datos por el valor de clave.
https://stackoverflow.com/questions/34243134/what-is-sequence-file-in-hadoop
Divisibilidad ✔
Compresión ✔
Legible ✕
Tipos Complejos ✔
Diseño HDFS
Formatos

Avro
 Avro es un formato contenedor orientado a fila desarrollado en el
ámbito de Hadoop:
 Los datos se codifican en binario y se agrupan en bloques, haciendo el formato
altamente divisible y compresible (a nivel de bloque).
 Soporta tipos de datos nativos y complejos.
 El esquema (descrito en JSON) está integrado en el mismo fichero que los datos.
 El formato destaca por su capacidad para adaptarse a la evolución del
esquema:
Formatos
Conclusiones
Tipo de almacenamiento Columnas
Evolución del Esquema ✔
Divisibilidad ✔
Compresión ✔
Legible ✕
Tipos Complejos ✔
 Se pueden añadir, eliminar o modificar campos de acuerdo con las necesidades que se presenten.
 Es capaz de leer datos utilizando un esquema diferente al usado cuando fueron escritos:
 Un “cliente viejo” puede leer los datos escritos por un “cliente nuevo”.
 Un “cliente nuevo” puede leer los datos escritos por un “cliente viejo”.
Diseño HDFS
Formatos

 Facilita acceder sólo a los bloques que contienen datos que satisfacen los predicados de consulta.
 Los índices almacenan información estadística variada (presencia de NULLs, COUNT, MAX, MIN, SUM…).
 El soporte de ORC se ha incrementado recientemente:
 Hive, Pig, MapReduce, Spark…
ORC
Formatos
Conclusiones
 ORC (Optimized Row Columnar) fue diseñado originalmente
para optimizar el almacenamiento y el rendimiento (de las
operaciones analíticas) de Hive:
 ORC divide el fichero en stripes de filas (64MB por defecto) y los codifica
(independientemente) por columnas, eligiendo la mejor opción para cada una.
 Soporta los tipos de datos primitivos habituales y los tipos complejos de Hive.
 Proporciona 3 niveles de indexación: fichero, stripe y fila (conjuntos 10000 filas):
Divisibilidad ✔
Compresión ✔
Legible ✕
Tipos Complejos ✔
Diseño HDFS
Formatos

Parquet
 Parquet es un formato contenedor orientado a columnas optimizado para
WORM:
 La escritura es lenta en comparación con la lectura (que es muy rápida).
 Su diseño tiene numerosos puntos en común con ORC:
 Divide el fichero en chunks de filas y los codifica independientemente columna a
columna:
 Proporciona varios mecanismos de compresión para explotar la regularidad de los datos.
 Soporta para tipos de datos primitivos y complejos.
 Almacena el esquema al final del fichero, soportando su evolución.
 Parquet está muy integrado en Hadoop, lo que facilita “su integración en
cualquier proyecto, con independencia del framework de procesamiento
elegido, el modelo de datos planteado o el lenguaje de programación utilizado”.
Formatos
Conclusiones
Divisibilidad ✔
Compresión ✔
Legible ✕
Tipos Complejos ✔
Diseño HDFS
Formatos

Resumen
Formatos
Conclusiones
Característica CSV JSON SequenceFile Avro ORC Parquet
Tipo de almacenamiento Filas Filas Filas Columnas Columnas Columnas
Evolución del Esquema ✕ ✕ ✕ ✔ ✔ ✔
Divisibilidad ✔ ✔* ✔ ✔ ✔ ✔
Compresión ✔ ✔ ✔ ✔ ✔ ✔
Legible ✔ ✔ ✕ ✕ ✕ ✕
Tipos Complejos ✕ ✔ ✔ ✔ ✔ ✔
Diseño HDFS
Formatos

 Benchmark realizado sobre una colección de datos
“estrecha” (3 columnas) basada en registros de Netflix:
 El análisis del espacio de almacenamiento se hace sobre la
configuración por defecto de cada formato.
 La evaluación del rendimiento implementa en Spark diferentes
escenarios de interés en el ámbito del Data Lake.
Formatos
Conclusiones
Fuente: https://luminousmen.com/post/big-data-file-formats
Diseño HDFS
Formatos

Espacio
Formatos
Conclusiones
 Los formatos contenedor (con almacenamiento
binario) son más efectivos:
 CSV + compresión obtendría resultados más competi-
tivos, pero peores que Avro y Parquet.
 JSON es una mala opción para almacenar raw data, ya
que ocupa mucho más espacio que cualquiera de los
otros formatos.
Diseño HDFS
Formatos

Rendimiento (Escritura)
Formatos
Conclusiones
 El proceso de escritura es más eficiente utilizando
formatos textuales:
 No necesitan recopilar y almacenar tanta meta-
información.
 No requieren codificar (binario) los datos.
Diseño HDFS
Formatos

Rendimiento (Acceso Aleatorio)
Formatos
Conclusiones
 Este experimento evalúa el rendimiento de la
operación de búsqueda de los registros que
satisfacen un determinado predicado:
 El almacenamiento columnar de Parquet favorece la
consulta, ya que el predicado se evalúa sobre la
columna requerida.
 En el resto de los casos, es necesario leer los registros
completos y evaluar el campo solicitado.
Búsqueda
Diseño HDFS
Formatos

Rendimiento (Otros)
Formatos
Conclusiones
MIN, MAX, COUNT Lectura de datos
Diseño HDFS
Formatos

Rendimiento (Otros)
Formatos
Conclusiones
GROUP BY DISTINCT
Diseño HDFS
Formatos

Conclusiones
 La elección de un formato de almacenamiento debe considerar diferentes factores:
 El soporte para la evolución del esquema, el soporte para diferentes tipos de datos, integración con
diferentes herramientas, la posible modificación del esquema de los datos, …
 Si el factor principal es el rendimiento, los formatos contenedor son claramente la mejor opción:
 Son divisibles, soportan compresión, organizan los datos de manera más efectiva, optimizan los tiempos
de acceso y soportan la declaración de estructuras de datos complejas, aunque no permiten que una
persona lea directamente los datos y son más lentos en la escritura.
 Avro es más apropiado para el almacenamiento del raw data (Landing Zone), porque la ingesta se lleva a
cabo sobre el registro completo.
 Parquet/ORC son más apropiado para propósitos analíticos (smart data), que suelen acceder sólo a
algunos campos.
Formatos
Conclusiones
Diseño HDFS
Formatos

Conclusiones
 JSON es un estándar para la comunicación en la Web, pero no es una buena opción para el
almacenamiento de los datos en el Data Lake:
 Ocupa mucho espacio y su rendimiento no es competitivo en ninguno de los escenarios habituales.
 CSV es un formato muy simple, pero ofrece un comportamiento aceptable en términos
generales:
 El exceso de espacio es asumible, en algunos casos (y los ficheros se podrían comprimir), y es formato el
más eficiente en operaciones de escritura.
 Su rendimiento en operaciones de acceso es aceptable y tiene soporte eficiente en múltiples
aplicaciones.
 CSV es un formato aceptable para la Work Zone.
Formatos
Conclusiones
Diseño HDFS
Formatos

Qué hemos aprendido…

 HDFS es un sistema de ficheros escalable y robusto que se basa en el almacenamiento
replicado de los bloques que componen los ficheros
 Su arquitectura se basa en dos tipos de nodos: NameNode y DataNode
 HDFS soporta otras funcionalidades como:
 En clústeres muy grandes, con muchos ficheros, la memoria utilizada por el NameNode se convierte en
un factor de limitación para el escalado. Para mitigar este efecto, el espacio de nombres de HDFS puede
dividirse y gestionarse independientemente por varios NameNodes disjuntos, que constituyen un HDFS
federado
 El NameNode es un elemento clave para el funcionamiento del sistema HDFS. Para prevenir
disrupciones del servicio de almacenamiento proporcionado por HDFS en caso de caída del NameNode,
HDFS HA propone una arquitectura más compleja con el fin de garantizar la continuidad del servicio, es
decir, proporcionar un servicio de alta disponibilidad

 Hadoop, en general, y HDFS, en particular, es un sistema complejo, con múltiples opciones
de configuración. En este tema hemos introducido los aspectos básicos de la
configuración de Hadoop y HDFS
 La interfaz de mandatos administrativos de HDFS, dfsadmin permite obtener
información acerca del estado de HDFS, al igual que para realizar operaciones de
administración sobre HDFS

 La elección del formato de almacenamiento es determinante para el éxito del proyecto:
 Es necesario considerar la forma en la que almacenan los datos (tradeoffs espacio-tiempo), si
permiten modificar el esquema de los datos, son divisibles y/o soportan compresión.
 Los formatos contenedor (Avro, Parquet, ORC) son los que proporcionan el mejor rendimiento:
 La elección depende de los objetivos del proyecto y/o de la zona del Data Lake en la que se almacenen
los datos.
 CSV son una buena opción para la Working Zone porque simplifica el debug del código de
transformación.
 El diseño lógico de los datos también contribuye a optimizar las decisiones de almacenamiento:
 Es necesario dejar de pensar “en términos relacionales”.
Capa de Almacenamiento
HDFS
Formatos
Consideraciones Prácticas

Referencias
 The Apache Software Foundation. HDFS Architecture. https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-
hdfs/HdfsDesign.html. Última consulta, septiembre 2020.
 Kirill B. Big Data File Formats. 2020. https://luminousmen.com/post/big-data-file-formats. Última consulta, septiembre 2020.
 Rahul Bhatia. Big Data File Formats. 2019. https://blog.clairvoyantsoft.com/big-data-file-formats-3fb659903271. Última consulta,
septiembre 2020.
 Chandan Gaur. Introduction to Data Serialization in Apache Hadoop. 2019. https://www.xenonstack.com/blog/data-serialization-
hadoop/. Última consulta, septiembre 2020.
 Ian Hellström. An Overview of File and Serialization Formats in Hadoop. 2015. https://databaseline.tech/an-overview-of-file-and-
serialization-formats-in-hadoop/. Última consulta, septiembre 2020.
 Nexla. An Introduction to Big Data Formats. White Paper. 2019. https://www.nexla.com/resource/introduction-big-data-formats-
understanding-avro-parquet-orc/. Última consulta, septiembre 2020.
 Tom White. Hadoop: The Definitive Guide. O’Reilly. 2015.

Disclaimer
Esta presentación se difunde únicamente con fines docentes.
Las imágenes utilizadas pueden pertenecer a terceros y, por tanto, son propiedad de sus autores.

HDFS.pdf

Recommandé

Recommandé

Contenu connexe

Similaire à HDFS.pdf

Similaire à HDFS.pdf (20)

Dernier

Dernier (13)

HDFS.pdf