Introducción a HDFS
HDFS es un sistema de archivos distribuido de alto rendimiento y alta tolerancia a fallos, adecuado para su implementación en máquinas económicas.
Concepto de diseño HDFS
Soporte para conjuntos de datos muy grandes
Las aplicaciones que se ejecutan en HDFS tienen grandes conjuntos de datos. Un tamaño de archivo típico en HDFS suele estar entre G bytes y T bytes. Por lo tanto, HDFS está diseñado para admitir un gran almacenamiento de archivos, se puede expandir a cientos de nodos en un clúster y puede almacenar grandes cantidades de datos.
Por ejemplo, ¿todavía usa MySQL para almacenar 10 mil millones de datos en una tabla determinada? Qué tan alta es su configuración para una máquina y luego considere la eficiencia de la consulta. Si se utiliza almacenamiento distribuido, es decir, estos datos se almacenan en más de N máquinas, y cada máquina solo almacena parte de estos 10 mil millones de datos, por ejemplo, una máquina almacena 5 millones de datos, el posicionamiento de HDFS es para este enorme almacenamiento de datos.
Error de hardware
HDFS puede constar de cientos o miles de servidores, cada uno de los cuales almacena parte de los datos del sistema de archivos. La probabilidad de falla de la máquina que almacena estos datos sigue siendo bastante alta. Por ejemplo, el disco está dañado, no se puede leer ni escribir, y la red falla. Esta máquina no puede funcionar normalmente.
Por lo tanto, la detección de errores y la recuperación rápida y automática son los principales objetivos arquitectónicos de HDFS. Una vez que HDFS detecta un problema con una máquina en el clúster, puede recuperarse de la falla.
Procesamiento de datos en streaming
Las aplicaciones que se ejecutan en HDFS son diferentes de las aplicaciones ordinarias que solemos escribir. Cuando HDFS lee y escribe datos en el sistema de archivos, se basa en el concepto de flujo. El denominado procesamiento de flujo consiste en leer archivos en lotes. Escriba para garantizar la lectura y escritura de archivos de alto rendimiento, no la lectura y escritura de archivos de baja latencia.
HDFS se utiliza en escenarios de procesamiento por lotes sin conexión, especialmente el almacén de datos sin conexión actual, que se utiliza para el análisis de datos. Nuestro análisis sin conexión actual consiste en extraer los datos del sistema de origen en HDFS esta mañana temprano, y luego el procesamiento implica procesar este lote de datos por lote, en lugar de calcular uno por uno.
Modelo de coherencia de datos simplificado
Al mismo tiempo, admite la lectura y escritura de archivos, y necesita lidiar con una gran cantidad de conflictos de simultaneidad. Piense en los bloqueos de lectura y escritura agregados al conjunto de lectura y escritura al escribir código. Si no lo hace ' Si lo agregas, habrá más problemas. Para el almacenamiento distribuido de conjuntos de datos a gran escala como HDFS, su modelo debe simplificarse. Sus archivos solo se pueden escribir una vez, y luego solo se pueden agregar, y los datos anteriores no se pueden modificar casualmente.
Entonces, su filosofía es: escribir una vez, listo muchas veces, escribir una vez, luego leer varias veces, de modo que no haya conflicto de concurrencia de lectura y escritura de datos, y cómo mantener la coherencia de los datos.
Este modelo de escritura única y lectura múltiple también puede mejorar en gran medida el rendimiento de HDFS.
Computación móvil, no mueva datos
Piénselo, cuando leemos datos, ¿es más rápido leer datos del disco local o de otras máquinas en la red? Si los datos están más cerca de la máquina, mayor será la velocidad y mayor la eficiencia.
Por lo tanto, en los datos distribuidos en varias máquinas, para la computación distribuida, debe acercar sus tareas de computación a estos datos, en lugar de transferir datos a través de la red en el clúster.
Arquitectura distribuida del modo maestro-esclavo
NameNode suma DataNode
La arquitectura clásica en los sistemas distribuidos es maestro-esclavo. HDFS utiliza esta arquitectura maestro-esclavo. Un clúster HDFS se compone de un NameNode y varios DataNodes.
NameNode es un proceso, un proceso JVM y también un sistema. Podemos pensar en NameNode como este maestro (puede entenderse como un gran administrador). En un clúster HDFS ordinario, solo hay un NameNode. Es responsable de administrar el espacio de nombres del sistema de archivos y el acceso del cliente a los archivos.
DataNode también es un proceso.Cada máquina del clúster tiene un proceso DataNode, que es el principal responsable del almacenamiento de datos en la máquina.
Espacio de nombres del sistema de archivos
Espacio de nombres, ¿cómo entender? En lo que respecta a la carpeta de nuestra computadora, los datos almacenados están en este directorio -> método de archivo, y el directorio puede ser el siguiente nivel de directorio.
Por ejemplo, la siguiente estructura de directorio en mi computadora, / documentos / almacén de datos / Este directorio tiene el método de construcción del almacén de datos de archivos xxx.doc y el directorio / 12_data, el directorio / 12_data tiene 04_gran estructura técnica del sistema de datos xxx .doc Estos documentos.
Por lo tanto, la relación correspondiente entre la estructura jerárquica del sistema de archivos y los archivos es el denominado Namspace del sistema de archivos, que se almacena en el NameNode.
bloquear bloque de archivos
En un clúster HDFS, un archivo grande se dividirá en N bloques múltiples para dividir y almacenar en diferentes máquinas. Por ejemplo, si hay un archivo grande de 1G, HDFS lo dividirá, por ejemplo, 128M, luego se dividirá en 8 bloques de archivos y luego se colocará en una máquina diferente, es decir, el DataNode, el DataNode es el responsable Store estos bloques de archivos.
El NameNode sabe en cuántos bloques de archivos se divide un archivo y en qué DataNode se almacena cada bloque de archivos, por lo que NameNode es el administrador principal de un clúster HDFS.
Cuando desee leer el archivo grande de arriba, primero le preguntará al administrador del NameNode, a qué bloque de archivo corresponde el archivo y dónde se encuentra cada bloque de archivo, y luego el NameNode le indica en qué DataNodes están, luego puede ir al DataNode correspondiente.
Mecanismo de gestión de la persistencia de metadatos del sistema de archivos
Editlog y FsImage
El HDFS se almacena en el NameNode. Para cualquier operación de modificación en los metadatos del sistema de archivos, NameNode registrará las operaciones una por una en un registro de operaciones llamado EditsLog.
Por ejemplo, si se crea un archivo en HDFS, Namenode insertará un registro en Editlog para indicarlo; de manera similar, al modificar el coeficiente de copia del archivo también se insertará un registro en Editlog. Namenode almacena este registro de edición en el sistema de archivos del sistema operativo local. Cree un directorio en hdfs, hadoop fs -mkdir -p / usr / dir1, cree una jerarquía de directorios
Luego, toda la estructura de organización del sistema de archivos, incluida la asignación de bloque de datos a archivo, atributos de archivo, etc., se almacena en un archivo llamado FsImage, que también se coloca en el sistema de archivos local donde se encuentra Namenode.
Antes de que NameNode almacene los metadatos en el archivo FsImage, ahora se almacenarán en la memoria durante un período de tiempo.Si el archivo se escribe cada vez que cambian los metadatos, el rendimiento es muy bajo. Por lo tanto, NameNode leerá el archivo Editlog en el disco de vez en cuando, lo aplicará todo a la caché fsimage en la memoria y luego volcará la fsimage al disco nuevamente, y luego guardará el archivo Editlog previamente aplicado. .
operación del puesto de control
En lo anterior, se lee el editlog del disco y se aplica a la FsImage, luego se guarda la FsImage en el disco, y finalmente se borra el Editslog. Esta operación se llama checkpoint. Podemos configurar el intervalo del checkpoint por nosotros mismos y comenzar en el NameNode En ese momento, también primero leerá el registro de ediciones y Fsimage del disco para construir datos en caché en la memoria.
dfs.namenode.checkpoint.period：这个参数配置几秒钟执行一次checkpoint
dfs.namenode.checkpoint.txns：这个参数配置当edits log里有多少条数据的时候，就执行一次checkpoint
复制代码
SecondaryNameNode y BackupNode en la era de hadoop 1.x
SecondaryNameNode
En la era de Hadoop 1.x, cuando se inició NameNode, FsImage se leyó en la memoria y luego el contenido del registro de EditsLog se restauró a fsimgae, manteniendo los metadatos en la memoria actualizados y luego escribiendo la última fsimage Ir a el disco y, finalmente, borre el archivo Editlog.
A continuación, el cliente está operando continuamente el clúster HDFS y los metadatos del NameNode se modificarán continuamente. Estas modificaciones son para modificar directamente el caché de FsImage en la memoria, y el archivo de registro para modificar los metadatos se agregará al registro de ediciones archivo.
Hay un problema. El registro de modificaciones de los metadatos siempre se agregará al archivo de registro de ediciones. Si se agrega todo el tiempo, será cada vez más grande. No estará disponible hasta el próximo reinicio de NameNode y el registro de ediciones se fusiona con fsimage. Vacío. Si el registro de ediciones es grande, llevará mucho tiempo fusionarse, lo que puede hacer que el inicio de NameNode sea cada vez más lento.
Entonces, una forma de pensar es fusionar el registro de ediciones y fsimage con regularidad. Después de la combinación, escriba la nueva fsimage en el disco y borre el registro de ediciones al mismo tiempo, para que el registro de ediciones no sea demasiado grande.
Entonces hdfs tiene otra función como NameNode secundario, se implementará en otra máquina, se dedicará a fusionar el registro de ediciones y fsimage, ejecutarlo cada vez, cuando se ejecute, dígale a NameNode que no escriba el registro de ediciones actual Ahora, abra un nuevo registro de ediciones para escribir. Luego, extraiga el archivo fsimage y edite el registro del NameNode en el local, combínelos en la memoria y envíelos al NameNode después de que se complete la combinación.
Esta operación es la llamada operación de punto de control, por lo que el registro de ediciones no será demasiado grande.
BackupNode
BackupNode también es un mecanismo proporcionado en Hadoop 1.x. Su idea es optimizar y reemplazar la idea combinada de checkpoint de descargar el registro de ediciones y fsimage.
La idea del nodo de respaldo es almacenar una copia de los datos de fsimage al igual que el nodo de nombre en la memoria y, al mismo tiempo, recibir el flujo de datos del registro de ediciones enviado por el nodo de nombre y escribir uno en su propio registro de ediciones local. después de obtener el flujo de datos del registro de ediciones.
Al mismo tiempo, el registro de ediciones se reproducirá en la fsimage en la memoria del usuario, de modo que la fsimage en la memoria sea la misma que la fsimage en la memoria de namenode.
El nodo de respaldo también realizará periódicamente una operación de punto de control, escribirá fsimage en su memoria esta vez en su propio disco, reemplazará el archivo fsimage antiguo y luego borrará el registro de ediciones.
Un NameNode solo se puede vincular a un nodo de respaldo. La ventaja de usar un nodo de respaldo es que no tiene que permitir que el nodo de nombre mantenga dicho archivo de registro de ediciones, y no necesita escribir en el disco usted mismo. Simplemente mantenga la fsimage en su propia memoria y luego recíbala cada vez. Cuando necesite una operación para modificar metadatos, aplíquela a la fsimage en su memoria y, al mismo tiempo, envíe el flujo de datos del registro de ediciones al nodo de respaldo.
Cada vez que se reinicia el namenode, debe usar -importCheckpoint para cargar fsimage de otros lugares en el suyo esta vez, y estos datos -importCheckpoint se toman del nodo de respaldo.
Lo anterior es la gestión de metadatos en Hadoop 1.x. Hadoop 2.x ya no es tan divertido.
Mecanismo de alta disponibilidad HA de doble instancia en la era hadoop 2.x
Defectos de la gestión de metadatos de Hadoop 1.x
En la era de Hadoop 1.x, NameNode vinculado a un NameNode secundario para administrar metadatos provocará la pérdida de metadatos y problemas de alta disponibilidad.
Problemas de alta disponibilidad. Una vez que el NameNode falla o deja de funcionar, todo el clúster no estará disponible. Problema de pérdida de datos. Si el disco de NamaNode está dañado, se producirá una cierta pérdida de datos. Se perderá el registro de ediciones después del último punto de control.
En Hadoop 2.x, se resuelve el problema de la pérdida de metadatos y la alta disponibilidad.
Entonces NameNode
El clúster Hadoop 2.x iniciará dos NameNodes, uno en el estado activo y el otro en el estado de espera. Podemos entender que el estado activo es el maestro y el estado de espera es el de espera. Todas las operaciones del cliente se envían al NameNode en el estado activo, y el NameNode en el estado de espera se utilizará como una espera activa para que el NameNode activo sincronice continuamente los metadatos.
Nodo de diario
El NameNode en el estado de espera no solicita metadatos directamente del NameNode. También hay un intermediario, el Journal Node, que almacena el registro de ediciones. Generalmente, el Journal Node también es un clúster, comenzando con tres.
Cuando NameNode tiene cambios en los metadatos, escribirá el registro de ediciones en la mayoría de los nodos del clúster de nodos de Journal. Por ejemplo, ahora hay 3 grupos de nodos de diario y la mayoría de los nodos son 3/2 + 1 = 2. Es decir, si NameNode escribe el registro de ediciones en 2 grupos, la escritura se considera correcta.
Entonces StandbyNameNode siempre monitoreará los cambios del registro de ediciones en el JournalNode. Mientras haya cambios, extraerá el nuevo registro de ediciones al local y luego lo aplicará a su propia memoria, manteniéndolo consistente con el NameNode activo.
Cuando el NameNode activo cuelga, el NameNode en espera lo percibirá inmediatamente y luego se asegurará de que lee todos los registros de ediciones del nodo de diario, y la fsimage en la memoria también son los datos más recientes, y luego cambia a la activa NameNode.
De esta manera, se resuelve el problema de la pérdida de datos. Una máquina está inactiva y la otra máquina se cambia inmediatamente al nodo de nombre activo para continuar brindando servicios al mundo exterior, y también se resuelve el problema de alta disponibilidad.
ZKFC (ZKFailoverController)
Entonces, ¿cómo dos NameNodes cambian automáticamente después de que uno falla?
Se basa en el proceso ZKFailoverController, ZKFC para abreviar. Cada NameNode tendrá un proceso ZKFC. Ellos monitorearán constantemente el estado de los dos NameNodes y mantendrán el estado de los dos NameNodes en Zookeeper.
Si el NameNode activo está inactivo, HealthMonitor en ZKFC lo monitoreará, y luego FailoverController en ZKFC notificará al NameNode que está inactivo, y luego FailoverController encontrará un componente ActiveStandbyElector para reelección.
ActiveStandbyElector volverá a elegir un NameNode en espera como NameNode principal basado en zk.
Luego, zk notificará al componente ActiveStandbyElector en ZKFC en el NameNode en espera, notificará al FailoverController para cambiar el estado de espera al estado activo, y luego al FailoverController para notificar al NameNode que cambie al NameNode activo.
De esta manera, es posible cambiar entre activo y en espera, y se realiza HA.
¿Cómo gestiona la instancia dual Hadoop 2.x HA los metadatos?
En Hadoop 1.x, el nodo de respaldo realizará periódicamente una operación de punto de control, esta vez escribirá fsimage en su memoria en su propio disco, reemplazará el antiguo archivo fsimage y luego borrará el registro de ediciones.
En Hadoop 2.x, el NameNode en espera es en realidad similar al nodo de respaldo en 1.x, y realizará una operación de punto de control con regularidad.
El Standby NameNode ejecutará un subproceso en segundo plano llamado CheckpointerThread, que es una vez por hora de forma predeterminada, o si no se combinan 1 millón de registros de ediciones en fsimage, se realizará una operación de punto de control.
Escriba la última fsimage en la memoria en el disco, borre el registro de ediciones y finalmente envíe el último archivo fsimage al NameNode activo, reemplazando la antigua fsimage del NameNode activo, y también borre el archivo de registro de ediciones anterior en el NameNode activo.
Mecanismo de almacenamiento distribuido para datos de archivos grandes
Si necesita cargar un archivo muy grande, cuando el cliente hdfs envía el comando de carga, NameNode primero dividirá el archivo en varios bloques de acuerdo con el tamaño del archivo. 2.x por defecto es 128 M, 1.x es 64 M.
El NameNode planificará en qué DataNode se almacenará cada archivo de bloque. Distribuirá los datos tanto como sea posible de acuerdo con la situación de almacenamiento de datos de cada DataNode, y luego el cliente hdfs cargará el bloque de archivos en cada DataNode. Después del DataNode recibe los datos, almacenará estos bloques de archivos en diferentes directorios de archivos, establecerá una cierta estructura jerárquica para almacenar estos bloques de archivos y no los pondrá en una carpeta.
Cuando el DataNode se inicia, también escanea su directorio de datos de archivo local e informa al NameNode la lista de archivos bloqueados de los archivos que guarda.
Mecanismo de tolerancia a fallos basado en copias
Para almacenar un archivo grande basado en la división de bloques, el problema de almacenamiento está resuelto y no tiene nada de malo. Pero hay otro problema. Si una máquina falla, como un consumo excesivo de recursos, tiempo de inactividad o reinicio, entonces no se puede acceder al bloque almacenado en esta máquina. Originalmente, un archivo se dividía en Hay 10 bloques y ahora uno está defectuoso, y solo hay 9 bloques normales. Luego, cuando el cliente lee, sus datos están incompletos.
Mecanismo de copia
Entonces, ¿cómo resolver las diversas fallas de la máquina entre los grupos anteriores para la tolerancia a fallas? La respuesta es el mecanismo de copia.
Hay un parámetro en HDFS llamado factor de replicación, lo que significa que cada bloque se copiará por usted y se colocará en diferentes máquinas. El tiempo de inactividad de una máquina no afectará, y la otra máquina tendrá exactamente la misma copia de seguridad.
Cuando HDFS escribe un archivo, cada bloque tiene 3 copias por defecto. El NameNode primero seleccionará 3 DataNodes. Cada DataNode colocará un bloque y lo devolverá al cliente. Luego, el cliente transmitirá el bloque al primer DataNode. Después de un DataNode escribe este bloque en el local, este DataNode copiará el bloque al segundo DataNode. Después de que el segundo DataNode escriba en el local, copiará el bloque al tercer DataNode.
Conciencia de rack
La comunicación entre las máquinas en el clúster HDFS es para comunicarse. Las máquinas y las máquinas pueden existir en diferentes racks. La transmisión de datos entre las máquinas en el mismo rack es definitivamente más rápida que las máquinas en diferentes racks.
Un bloque generalmente tiene 3 copias por defecto, luego NameNode colocará 2 copias en una máquina en un estante y una copia en una máquina en otro estante.
La transmisión de datos en el mismo bastidor es muy rápida Otro punto es que incluso si todas las máquinas de su bastidor están caídas, las máquinas del otro bastidor tendrán una copia de este bloque, que puede proporcionar servicios normalmente.
Modo seguro
Cuando el NameNode recién se inicia, ingresará a un modo llamado modo seguro, modo seguro, en este modo, el clúster hdfs no realizará la replicación de bloques
En este momento, NameNode esperará para obtener el informe de latido y bloque de cada DataNode, y luego observará la situación general del bloque en el clúster y cuántas copias de cada bloque, el valor predeterminado es tener 3 copias, si es un bloque tiene 3 copias, entonces está bien, seguro
Si un cierto porcentaje (80%) del bloque tiene suficientes 3 copias, el nodo de nombre saldrá del modo seguro.
NameNode siempre ha estado en modo seguro porque no ha alcanzado un cierto ratio, por ejemplo, solo el 50% de los bloques tienen 3 copias.
En este momento, si se encuentra que la cantidad de copias de un determinado bloque no es suficiente (por ejemplo, solo hay 2 copias), indique al DataNode que replique suficientes copias
Mecanismo federal
Todos los archivos, directorios e información de configuración en HDFS se almacenan en el NameNode. Cuando su clúster HDFS tiene decenas de miles y cientos de miles de unidades, la cantidad de datos es extremadamente grande y el tamaño de sus metadatos puede ser de cientos de gigabytes. Obviamente, no es factible en un NameNode.
Para resolver este problema, HDFS ha desarrollado un mecanismo de federación, es decir, hay varios NameNodes en un clúster, y cada NameNode almacena una parte de los metadatos. No importa cómo aumenten los metadatos, la máquina NameNode se puede escalar horizontalmente para resolver el problema La situación es que muchas empresas simplemente no utilizan este mecanismo federal y no tienen este tamaño.
Bajo el mecanismo de federación, cada NameNode activo almacena parte de los metadatos y luego se adjunta un NameNode en espera a cada NameNode activo, de esta manera se resuelven los problemas de expansión horizontal y alta disponibilidad.
Aunque hay varios NameNodes, todavía hay un conjunto de DataNodes y los bloques se almacenan en un clúster de DataNode. Solo significa que cada DataNode informará su latido y el informe de bloque a todos los NameNodes.
hdfs-11.png
Sígueme
** ¡Que pruebes los fuegos artificiales y sigas creyendo que el mundo lo vale! **
Enlace original: https://juejin.cn/post/6915947365648039950
Si cree que este artículo es útil para usted, puede seguir mi cuenta oficial y responder a la palabra clave [Entrevista] para obtener una compilación de los puntos de conocimiento básicos de Java y un paquete de regalo para la entrevista. Hay más artículos técnicos de productos secos y materiales relacionados para compartir, ¡que todos aprendan y progresen juntos!
