distribuido de Hadoop.(Hadoop distributed filesystem) • Diseñado para la administración de un sistema de ficheros en una arquitectura multinodo. • Optimizado para el almacenamiento de ficheros de gran tamaño (cientos de megabytes, gigabytes o terabytes). • HDFS está construido sobre la idea “write- once, read many times”
caro. Esta diseñado para trabajar con clústeres de bajo coste ya que tiene una estrategia diseñada para soportar fallos en cualquiera de los nodos. “Mas posibilidad de fallos cuanto mas grande es el clúster.”
latencia de acceso a datos. • Aplicaciones que necesiten muchos ficheros de pequeño tamaño. • Aplicaciones que tengan múltiples escritores y modificaciones arbitrarias en los ficheros.
que son almacenados en el sistema de ficheros como unidades independientes. • Es la unidad mínima que se puede leer o escribir. • En HDFS el tamaño de los bloques es muy grande, 64MB por defecto (Configurable).
mejora la tolerancia a los fallos. • Cada bloque de un fichero es replicado en base a un factor de replicación entre las diferentes máquinas que componen el clúster. De esta manera si alguna de las máquinas falla tenemos una copia de ese bloque siempre disponible. $ hdfs fsck / -files -blocks
Mantienen la estructura de árbol y los metadatos de todos los ficheros y directorios. • Esta información se almacena en disco en dos ficheros: ▫ - Namespace Image ▫ - EditLog
exactamente igual que hacerlo en tu ordenador personal. • HDFS esta diseñado para almacenar ficheros de gran tamaño. Fichero mayores de 500 MB es lo normal. • Los datos se almacenan en HDFS según el patrón: “Write one, read often”. Lo normal es no modificar el contenido de los ficheros y si hay que añadir se hace al final del mismo.
bloques en base al factor de replicación. • Todos los bloques de un fichero tienen el mismo tamaño, excepto el último que puede tener el mismo tamaño que los demás o ser mas pequeño.
barato y poco fiable, es por ello por lo que realiza la replicación de bloques. Si falla uno de los nodos coge una copia del bloque de otro nodo del clúster. • El factor de replicación es configurable, para arquitecturas singlenode es 1 para el resto es 3 por defecto.
en uno de los nodos de un rack, y las otras dos copias se meten en nodos diferentes de otro rack del cluster. De esta manera nos aseguramos que siempre vamos a tener disponible una copia del bloque.
es menor que el índice de replicación. Cuando HDFS detecta esta situación manda realizar una copia del bloque. • Sobre-replicación: Cuando el número de copias del nodo es mayor que el índice de replicación. Cuando HDFS detecta esta situación manda borrar una copia del bloque.
incluso miles de ordenadores individuales donde los ficheros son almacenados en sus discos duros. • Cada uno de esos ordenadores individuales es un servidor con su propia memoria, disco duro, procesador y un sistema operativo instalado, normalmente Linux aunque Windows también es soportado.
ficheros de cada uno de los nodos que componen el cluster. • Un cluster Hadoop está compuesto de las siguientes clases de servidores: ▫ Slave nodes ▫ Master nodes
los datos. • En cada uno de estos nodos corre un “daemon” llamados Datanode. • Los procesos Datanode sirven para llevar la cuenta de los bloques de datos que están almacenados en ese nodo. • Regularmente se comunican con los master nodes para notificarlos del estado de los datos que guardan.
ficheros en el sistema de ficheros. El usuario de Hadoop no tiene constancia de la ubicación de los bloques del fichero que quiere consultar en el clúster. • HDFS esta preparado para los fallos y es por eso por lo que realiza copia de los bloques de los ficheros y los reparte entre los slavenodes.
usuario guarda un fichero en HDFS este se divide en bloques y tres copias de estos bloques se guardan a lo largo del cluster de Hadoop. • El namenode actúa de “libro de direcciones” en HDFS. Sabe que bloques componen un determinado fichero y en que datanodes están guardados sus bloques y sus replicas.
en HDFS. Si este falla el acceso a los datos del cluster HDFS es imposible. • En los master nodes corren los procesos Name nodes que se encargan de guardar toda la información respecto a los bloques y que datanodes los contienen. Toda esta información se guarda en un fichero llamado fsimage. • Todos los cambios de datos se registran en un log. Este log se llama edits y se guarda en el name node.
namenode es informar a las aplicaciones de cuantos bloques necesitan y guardar la ubicación de los mismos dentro del cluster. Proceso de inicio de un namenode: ▫ 1 ) Carga el fsimage y lo guarda en memoria. ▫ 2) Carga el fichero edits y replica los cambios para actualizar los meta-datos de los bloques en memoria. ▫ 3) Los procesos de los Data nodes envían los informes de los bloques que contienen al namenode.
nodes envían de manera periódica al name node una señal indicándoles que están activos(Normalmente cada tres segundos, este valor es configurable) • Cada 6 horas (también configurable) envían al name node el estado de los bloques que contienen.
petición al name node para crear un nuevo fichero. • 2) El name node determina cuantos bloques son necesarios. • 3) El cliente escribe las primeras copias de los bloques según le planifica el namenode. (Algoritmo de replicación) • 4) Cada bloque se escribe en HDFS y un proceso se encarga de escribir el resto de replicas a otros data nodes identificados por el namenode. • Una vez que el proceso datanode sabe que todas las replicas se han escrito, el cliente cierra el fichero y notifica al namenode.
petición al namenode de un fichero. • 2) El name node determina que bloques pertenecen a ese fichero y elige en base a la proximidad de unos bloques con otros cual es el camino mas eficiente. • 3) El cliente accede a los bloques mediante la dirección dada por el namenode.
se guardan el fichero edits. • Periódicamente se lee el fichero edits y los cambios registrados se pasan al fichero fsimage. • Del checkpointing se encarga uno de estos cuatro posibles daemons: ▫ Secondary NameNode ▫ Checkpoint Node ▫ Backup Node ▫ Standby Namenode
el diario de cambios del sistema de ficheros, lo llama edits.new • El fichero edits no acepta más cambios y se copia al servicio de checkpointing además del fichero fsimage. • El checkpointing service une estos dos ficheros creando el fichero fsimage.ckpt • El checkpointing service copia fsimage.ckpt al NameNode • El NameNode sobreescribe el fichero fsimage con el fichero fsimage.ckpt • El NameNode renombra edits.new a edits.
<property> <name>fs.default.name</name> <value>hdfs://localhost:8020</value> <description>Nombre del filesystem por defecto.</description> </property> </configuration>
<property> <name>dfs.namenode.name.dir</name> <value>file:/home/hadoop/workspace/dfs/name</value> <description>Path del filesystem donde el namenode almacenará los metadatos.</description> </property> <property> <name>dfs.datanode.data.dir</name> <value>file:/home/hadoop/workspace/dfs/data</value> <description>Path del filesystem donde el datanode almacenerá los bloques.</description> </property> <property> <name>dfs.replication</name> <value>1</value> <description>Factor de replicación. Lo ponemos a 1 porque sólo tenemos 1 máquina.</description> </property> </configuration>
cetaciemat
matleenalaakso
copilot
signer
guvalif
ponponmikankan
matsuolab
terahide
mariliarochas
cbtlibrary
masakamayama
dougneiner
mclloyd
irinanazarova
erikaheidi
chriscoyier
lauravandoore
kastner
gr2m
rmw
trishagee
thoeni
lara
