Anzeige
Anzeige

Más contenido relacionado

Anzeige

HDFS.pdf

  1. Almacenamiento Escalable HDFS Fernando Díaz Gómez fdiaz@uva.es Departamento de Informática, Universidad de Valladolid
  2. 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
  3. Diseño HDFS 1) Arquitectura 2) HDFS federado 3) HDFS HA Almacenamiento escalable
  4. Almacenamiento Escalable -4- Arquitectura HDFS
  5. Almacenamiento Escalable -5- 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
  6. Almacenamiento Escalable -6- 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
  7. Almacenamiento Escalable -7- 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
  8. Almacenamiento Escalable -8- 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.
  9. Almacenamiento Escalable -9- 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.
  10. Almacenamiento Escalable -10- 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
  11. Almacenamiento Escalable -11- 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.
  12. Almacenamiento Escalable -12- 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.
  13. Almacenamiento Escalable -13- 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.
  14. Almacenamiento Escalable -14- 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://
  15. Almacenamiento Escalable -15- 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)
  16. Almacenamiento Escalable -16- 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.
  17. Almacenamiento Escalable -17- 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):
  18. Almacenamiento Escalable -18- 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
  19. Almacenamiento Escalable -19- 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).
  20. Almacenamiento Escalable -20- 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
  21. 1) Configuración básica Hadoop 2) Configuración segura Hadoop Configuración Hadoop Almacenamiento escalable
  22. Almacenamiento Escalable -22- 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.
  23. Almacenamiento Escalable -23- 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
  24. Almacenamiento Escalable -24- 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
  25. Almacenamiento Escalable -25- Configurar un clúster Hadoop: Configuración 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
  26. Almacenamiento Escalable -26- Configurar un clúster Hadoop: Configuración 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"?> <!-- core-site.xml --> <configuration> <property> <name>fs.defaultFS</name> <value>hdfs://namenode/</value> </property> </configuration> <?xml version="1.0"?> <!-- hdfs-site.xml --> <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>
  27. Almacenamiento Escalable -27- Configurar un clúster Hadoop: Configuración de Hadoop: propiedades importantes 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 file://${hadoop.tmp.dir }/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 file://${hadoop.tmp.dir }/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.
  28. Almacenamiento Escalable -28- Configurar un clúster Hadoop: Configuración de Hadoop: propiedades importantes 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.
  29. Almacenamiento Escalable -29- Configurar un clúster Hadoop: Configuración de Hadoop: propiedades importantes  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.
  30. Almacenamiento Escalable -30- Configurar un clúster Hadoop: Configuración de Hadoop: propiedades importantes  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.
  31. Almacenamiento Escalable -31- 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.
  32. Almacenamiento Escalable -32- 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.
  33. Almacenamiento Escalable -33- 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).
  34. Almacenamiento Escalable -34- Configurar un clúster Hadoop: Seguridad: Kerberos y Hadoop
  35. Almacenamiento Escalable -35- Configurar un clúster Hadoop: Seguridad: 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
  36. Administración HDFS 1) Estructuras de datos persistentes 2) Administración HDFS Almacenamiento escalable
  37. Almacenamiento Escalable -37- 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).
  38. Almacenamiento Escalable -38- HDFS: Estructuras de datos persistentes  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).
  39. Almacenamiento Escalable -39- HDFS: Estructuras de datos persistentes  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.
  40. Almacenamiento Escalable -40- HDFS: Estructuras de datos persistentes  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.
  41. Almacenamiento Escalable -41- HDFS: Estructuras de datos persistentes  La imagen del sistema de ficheros y log de edición (cont.)  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.
  42. Almacenamiento Escalable -42- HDFS: Estructuras de datos persistentes  La imagen del sistema de ficheros y log de edición (cont.)  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.
  43. Almacenamiento Escalable -43- HDFS: persistencia  La imagen del sistema de ficheros y log de edición (cont.)  Proceso de consolidación (cont.)
  44. Almacenamiento Escalable -44- HDFS: Estructuras de datos persistentes  La imagen del sistema de ficheros y log de edició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).
  45. Almacenamiento Escalable -45- HDFS: Estructuras de datos persistentes  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.
  46. Almacenamiento Escalable -46- HDFS: Estructuras de datos persistentes  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
  47. Almacenamiento Escalable -47- HDFS: Estructuras de datos persistentes  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).
  48. Almacenamiento Escalable -48- 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.
  49. Almacenamiento Escalable -49- Administración HDFS: Modo Seguro  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).
  50. Almacenamiento Escalable -50- Administración HDFS: Modo Seguro  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
  51. Almacenamiento Escalable -51- 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
  52. Almacenamiento Escalable -52- 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.
  53. Almacenamiento Escalable -53- Administración HDFS: Herramientas  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.
  54. Almacenamiento Escalable -54- Administración HDFS: Herramientas  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
  55. Almacenamiento Escalable -55- Administración HDFS: Herramientas  Chequeo del sistema de ficheros (fsck)  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.
  56. Almacenamiento Escalable -56- Administración HDFS: Herramientas  Chequeo del sistema de ficheros (fsck)  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.
  57. Almacenamiento Escalable -57- Administración HDFS: Herramientas  Chequeo del sistema de ficheros (fsck)  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.
  58. Almacenamiento Escalable -58- Administración HDFS: Herramientas  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.
  59. Almacenamiento Escalable -59- Administración HDFS: Herramientas  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).
  60. Almacenamiento Escalable -60- 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
  61. Almacenamiento Escalable -61- 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.
  62. Almacenamiento Escalable -62- 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
  63. Almacenamiento Escalable -63- 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
  64. Almacenamiento Escalable -64- Mantenimiento HDFS: Procedimientos Administración Rutinarios  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
  65. Almacenamiento Escalable -65- Mantenimiento HDFS: Procedimientos Administración Rutinarios  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.
  66. Formatos de Almacenamiento 1) Aspectos a Considerar 2) Formatos 3) Análisis Comparativo 4) Conclusiones Almacenamiento escalable
  67. Almacenamiento Escalable -67- 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 Configuración Hadoop Administración HDFS Formatos Aspectos a Considerar Formatos Análisis Comparativo Conclusiones
  68. Almacenamiento Escalable -68- 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). Aspectos a Considerar Formatos Análisis Comparativo Conclusiones Fuente: “Hadoop Application Architectures” (Grover, et al. 2015) Diseño HDFS Configuración Hadoop Administración HDFS Formatos
  69. Almacenamiento Escalable -69- ¿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. Aspectos a Considerar Formatos Análisis Comparativo 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 Configuración Hadoop Administración HDFS Formatos
  70. Almacenamiento Escalable -70- 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. Aspectos a Considerar Formatos Análisis Comparativo Conclusiones Fuente: “An Introduction to Big Data Formats” (Nexla, 2019) 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 Configuración Hadoop Administración HDFS Formatos
  71. Almacenamiento Escalable -71- 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. Aspectos a Considerar Formatos Análisis Comparativo Conclusiones Fuente: “An Introduction to Big Data Formats” (Nexla, 2019) 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 Configuración Hadoop Administración HDFS Formatos
  72. Almacenamiento Escalable -72- 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? Aspectos a Considerar Formatos Análisis Comparativo Conclusiones Diseño HDFS Configuración Hadoop Administración HDFS Formatos
  73. Almacenamiento Escalable -73- 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. Aspectos a Considerar Formatos Análisis Comparativo Conclusiones Diseño HDFS Configuración Hadoop Administración HDFS Formatos
  74. Almacenamiento Escalable -74- 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. Aspectos a Considerar Formatos Análisis Comparativo Conclusiones Diseño HDFS Configuración Hadoop Administración HDFS Formatos
  75. Almacenamiento Escalable -75- 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. Aspectos a Considerar Formatos Análisis Comparativo 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 Configuración Hadoop Administración HDFS Formatos
  76. Almacenamiento Escalable -76- ¿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). Aspectos a Considerar Formatos Análisis Comparativo Conclusiones Diseño HDFS Configuración Hadoop Administración HDFS Formatos
  77. Almacenamiento Escalable -77- Formatos  Orientados a filas:  Text:  Plano: CSV, texto…  Estructurado: JSON, XML…  SequenceFile.  Avro.  Orientados a columnas:  ORC.  Parquet. Aspectos a Considerar Formatos Análisis Comparativo Conclusiones Fuente: https://pxhere.com/ (@mohamed hassan) Diseño HDFS Configuración Hadoop Administración HDFS Formatos
  78. Almacenamiento Escalable -78- 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). Aspectos a Considerar Formatos Análisis Comparativo 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 Configuración Hadoop Administración HDFS Formatos
  79. Almacenamiento Escalable -79- 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. Aspectos a Considerar Formatos Análisis Comparativo Conclusiones Característica Soporte Tipo de almacenamiento Filas Evolución del Esquema ✕ 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 Configuración Hadoop Administración HDFS Formatos
  80. Almacenamiento Escalable -80- 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. Aspectos a Considerar Formatos Análisis Comparativo 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 Característica Soporte Tipo de almacenamiento Filas Evolución del Esquema ✕ Divisibilidad ✔ Compresión ✔ Legible ✕ Tipos Complejos ✔ Diseño HDFS Configuración Hadoop Administración HDFS Formatos
  81. Almacenamiento Escalable -81- 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: Aspectos a Considerar Formatos Análisis Comparativo Conclusiones Característica Soporte 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 Configuración Hadoop Administración HDFS Formatos
  82. Almacenamiento Escalable -82-  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 Aspectos a Considerar Formatos Análisis Comparativo 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): Característica Soporte Tipo de almacenamiento Columnas Evolución del Esquema ✔ Divisibilidad ✔ Compresión ✔ Legible ✕ Tipos Complejos ✔ Diseño HDFS Configuración Hadoop Administración HDFS Formatos
  83. Almacenamiento Escalable -83- 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”. Aspectos a Considerar Formatos Análisis Comparativo Conclusiones Característica Soporte Tipo de almacenamiento Columnas Evolución del Esquema ✔ Divisibilidad ✔ Compresión ✔ Legible ✕ Tipos Complejos ✔ Diseño HDFS Configuración Hadoop Administración HDFS Formatos
  84. Almacenamiento Escalable -84- Resumen Aspectos a Considerar Formatos Análisis Comparativo 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 Configuración Hadoop Administración HDFS Formatos
  85. Almacenamiento Escalable -85- Análisis Comparativo  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. Aspectos a Considerar Formatos Análisis Comparativo Conclusiones Fuente: https://luminousmen.com/post/big-data-file-formats Diseño HDFS Configuración Hadoop Administración HDFS Formatos
  86. Almacenamiento Escalable -86- Espacio Aspectos a Considerar Formatos Análisis Comparativo Conclusiones Fuente: https://luminousmen.com/post/big-data-file-formats  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 Configuración Hadoop Administración HDFS Formatos
  87. Almacenamiento Escalable -87- Rendimiento (Escritura) Aspectos a Considerar Formatos Análisis Comparativo Conclusiones Fuente: https://luminousmen.com/post/big-data-file-formats  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 Configuración Hadoop Administración HDFS Formatos
  88. Almacenamiento Escalable -88- Rendimiento (Acceso Aleatorio) Aspectos a Considerar Formatos Análisis Comparativo Conclusiones Fuente: https://luminousmen.com/post/big-data-file-formats  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 Configuración Hadoop Administración HDFS Formatos
  89. Almacenamiento Escalable -89- Rendimiento (Otros) Aspectos a Considerar Formatos Análisis Comparativo Conclusiones Fuente: https://luminousmen.com/post/big-data-file-formats MIN, MAX, COUNT Lectura de datos Diseño HDFS Configuración Hadoop Administración HDFS Formatos
  90. Almacenamiento Escalable -90- Rendimiento (Otros) Aspectos a Considerar Formatos Análisis Comparativo Conclusiones Fuente: https://luminousmen.com/post/big-data-file-formats GROUP BY DISTINCT Diseño HDFS Configuración Hadoop Administración HDFS Formatos
  91. Almacenamiento Escalable -91- 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. Aspectos a Considerar Formatos Análisis Comparativo Conclusiones Diseño HDFS Configuración Hadoop Administración HDFS Formatos
  92. Almacenamiento Escalable -92- 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. Aspectos a Considerar Formatos Análisis Comparativo Conclusiones Diseño HDFS Configuración Hadoop Administración HDFS Formatos
  93. Qué hemos aprendido… Almacenamiento escalable
  94. Almacenamiento Escalable -94- 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
  95. Almacenamiento Escalable -95- Qué hemos aprendido…  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
  96. Almacenamiento Escalable -96- Qué hemos aprendido…  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
  97. Referencias Almacenamiento
  98. Almacenamiento Escalable -98- 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.
  99. Almacenamiento Escalable -99- 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.
Anzeige