1. ¿Cuál es el proceso de lectura y escritura de HDFS?
El proceso de lectura y escritura de HDFS (Hadoop Distributed File System) es el siguiente:
Proceso de escritura:
El cliente envía una solicitud de escritura a NameNode, solicitando la creación de un nuevo archivo en HDFS.
El NameNode asigna algunos bloques de datos (128 MB por defecto) para el archivo e información sobre en qué DataNodes almacenar estos bloques de datos.
NameNode devuelve al cliente una lista de DataNodes disponibles para escribir datos.
El cliente selecciona el DataNode más cercano y le envía una solicitud para escribir un bloque de datos.
El DataNode reconoce la solicitud de escritura al cliente y le envía un reconocimiento de escritura.
El cliente comienza a escribir bloques de datos en el DataNode.
DataNodes almacena bloques de datos escritos en el disco local.
El DataNode envía un reconocimiento de que la escritura se completó al cliente.
El cliente notifica al NameNode que se ha escrito el bloque de datos.
NameNode actualiza la información de metadatos del archivo y escribe esta información en el almacenamiento persistente.
Proceso de lectura:
El cliente envía una solicitud de lectura al NameNode.
El NameNode devuelve información de ubicación del bloque de datos para el archivo y una lista de DataNodes que almacenan esos bloques de datos.
El cliente selecciona el DataNode más cercano y le envía una solicitud para leer el bloque de datos.
DataNodes devuelve bloques de datos a los clientes.
El cliente lee el bloque de datos y envía un reconocimiento al DataNode.
Si los datos que se van a leer abarcan varios bloques de datos, el cliente repetirá los pasos 3 a 5 hasta que se lea todo el archivo.
El cliente cierra el archivo, finalizando el proceso de lectura.
Cabe señalar que la operación de escritura de HDFS adopta un mecanismo de escritura canalizado, es decir, cuando se escribe un bloque de datos, el cliente puede continuar escribiendo el siguiente bloque de datos para mejorar la eficiencia de escritura. Además, las operaciones de lectura de HDFS también admiten la optimización de la localidad de datos, es decir, las lecturas de datos se realizan preferentemente en los nodos de datos que almacenan bloques de datos para reducir la sobrecarga de transmisión de la red.
2. ¿Qué daño habrá si hay demasiados archivos HDFS pequeños y cómo evitarlos?
La presencia de una gran cantidad de archivos pequeños en HDFS puede causar los siguientes peligros:
Enorme sobrecarga de metadatos: la información de metadatos de HDFS se almacena en NameNode y cada archivo corresponde a una información de metadatos en HDFS. Si hay una gran cantidad de archivos pequeños, NameNode necesita administrar una gran cantidad de información de metadatos, lo que ejercerá una presión excesiva sobre NameNode y provocará una degradación del rendimiento.
Baja utilización de bloques de datos: HDFS adopta el modo de almacenamiento de bloques de datos, que divide archivos grandes en múltiples bloques de datos y los almacena en diferentes DataNodes. Si el tamaño del archivo es más pequeño que el tamaño del bloque de datos, también se almacenará en un bloque de datos separado, lo que generará un desperdicio de espacio de almacenamiento y reducirá la utilización del espacio de almacenamiento.
Baja eficiencia de lectura de datos: cuando hay muchos archivos pequeños, habrá una gran cantidad de archivos pequeños en HDFS, lo que hará que NameNode administre una gran cantidad de información de metadatos, aumente la sobrecarga de transmisión de la red y reduzca la eficiencia de lectura de datos.
Para evitar el problema de demasiados archivos pequeños, se pueden tomar las siguientes medidas:
Combinar archivos pequeños: combine varios archivos pequeños en un archivo grande para reducir la cantidad de archivos pequeños en HDFS.
Combine archivos pequeños en SequenceFile: SequenceFile es un formato de archivo binario proporcionado por Hadoop, que puede combinar varios archivos pequeños en un SequenceFile, lo que reduce la cantidad de archivos pequeños en HDFS.
Use archivos HAR: un archivo HAR es un formato de archivo que combina varios archivos pequeños en un solo archivo y comprime e indexa los archivos para un acceso rápido.
Limite la creación de archivos pequeños: puede
dfs.namenode.fs-limits.max-files-per-directorylimitar la cantidad de archivos pequeños en un solo directorio a través de los parámetros HDFS.Use otros sistemas de archivos: si la cantidad de archivos pequeños es grande, puede considerar usar otros sistemas de archivos, como HBase, que puede manejar mejor una gran cantidad de archivos pequeños.
3. ¿Cuál es la arquitectura y el principio de funcionamiento del clúster YARN?
YARN (Yet Another Resource Negotiator) es un administrador de recursos en Hadoop. Su función principal es administrar los recursos en el clúster y coordinar las aplicaciones que se ejecutan en el clúster. A través de su arquitectura y principio de funcionamiento únicos, YARN realiza una gestión eficiente de los recursos del clúster y una ejecución eficiente de las aplicaciones.
La arquitectura del clúster YARN es la siguiente:
ResourceManager (RM): ResourceManager es el componente central de todo el clúster de YARN. Es responsable de administrar los recursos del clúster, como CPU, memoria, disco, etc., y administrar las aplicaciones que se ejecutan en el clúster. Las funciones principales de ResourceManager incluyen la asignación de recursos para las aplicaciones, la supervisión del uso de los recursos del clúster y el manejo de las solicitudes de inicio y detención de aplicaciones.
NodeManager (NM): NodeManager es un componente de agente que se ejecuta en cada nodo.Es responsable de administrar los recursos en el nodo, como CPU, memoria, disco, etc., e interactúa con ResourceManager para administrar la asignación y el reciclaje de recursos. Las funciones principales de NodeManager incluyen iniciar y detener contenedores, procesar información sobre el estado de los contenedores, administrar recursos locales, etc.
ApplicationMaster (AM): ApplicationMaster es un componente en cada aplicación que se ejecuta en el clúster, que es responsable de coordinar los recursos para la aplicación, manejar la asignación de tareas, monitorear el estado de la aplicación, etc. Cada aplicación tendrá un ApplicationMaster correspondiente.
Contenedor: El contenedor es un concepto básico en YARN. Es una representación abstracta de los recursos, incluidos la CPU, la memoria, el disco y otros recursos, así como el entorno de ejecución necesario para ejecutar las aplicaciones. Container es iniciado y administrado por NodeManager, que es responsable de ejecutar una tarea específica.
Un clúster de YARN funciona de la siguiente manera:
El programa de aplicación envía el programa de aplicación al ResourceManager, incluida la información de descripción y los requisitos de recursos del programa de aplicación.
ResourceManager asigna un ApplicationMaster para la aplicación y ApplicationMaster solicita recursos de ResourceManager, coordina recursos para la aplicación, maneja la asignación de tareas, supervisa el estado de la aplicación, etc.
De acuerdo con la solicitud de ApplicationMaster, ResourceManager asigna recursos y notifica a NodeManager que inicie Container en el nodo correspondiente.
NodeManager inicia el Contenedor en el nodo correspondiente y es ejecutado por la tarea de coordinación de ApplicationMaster en el Contenedor.
ApplicationMaster informa el estado de ejecución de tareas a ResourceManager y solicita más recursos para ejecutar tareas en más contenedores.
Una vez completada la aplicación, ApplicationMaster notifica a ResourceManager que libere recursos y detenga la ejecución del contenedor.
4. ¿Cuál es la diferencia entre las tablas internas y externas de Hive?
Hive es una herramienta de almacenamiento de datos en el ecosistema de Hadoop, que puede asignar datos estructurados al HDFS de Hadoop y consultar los datos de manera similar a SQL. En Hive, los datos se pueden almacenar en tablas internas o tablas externas, y sus diferencias son las siguientes:
Ubicación de almacenamiento: los datos de la tabla interna se almacenan en el directorio HDFS administrado por Hive, mientras que los datos de la tabla externa se almacenan en la ruta especificada por el usuario, que puede ser HDFS o un sistema de archivos local.
Gestión de datos: la tabla interna es gestionada por Hive. Cuando se elimina la tabla interna, se eliminarán los metadatos y los datos de la tabla. La tabla externa es administrada por el usuario, cuando se elimina la tabla externa, solo se eliminarán los metadatos, pero no se eliminarán los datos.
Respaldo y recuperación de datos: Hive administra el respaldo y la recuperación de datos de las tablas internas, mientras que los propios usuarios administran el respaldo y la recuperación de datos de las tablas externas.
Importación y exportación de datos: la importación y exportación de datos de tablas internas debe usar comandos específicos o API de Hive, mientras que la importación y exportación de datos de tablas externas puede usar Hadoop u otras herramientas.
Uso compartido de datos: solo Hive puede identificar y acceder a las tablas internas, mientras que varias aplicaciones o herramientas, incluido Hive, pueden acceder a los datos de las tablas externas.
En resumen, la principal diferencia entre las tablas internas y las tablas externas radica en la ubicación de almacenamiento de los datos, los métodos de administración y las estrategias de copia de seguridad y recuperación. En aplicaciones prácticas, debe optar por utilizar tablas internas o tablas externas según la situación real. Las tablas internas deben usarse si Hive administra los datos y no es necesario compartirlos con otras aplicaciones o herramientas. Las tablas externas deben usarse cuando los datos deben compartirse entre múltiples aplicaciones o herramientas y deben ser administrados por los propios usuarios.
5. ¿Cuál es la diferencia entre Flink y Spark Streaming?
Tanto Flink como Spark Streaming son marcos de trabajo de procesamiento de flujos en tiempo real, los cuales pueden procesar flujos de datos en tiempo real y admitir múltiples escenarios de aplicaciones de procesamiento de flujos. Las diferencias entre ellos son las siguientes:
Modelo de procesamiento de datos: Flink y Spark Streaming adoptan diferentes modelos de procesamiento de datos. Flink adopta un modelo basado en eventos, que trata el flujo de datos como una secuencia de eventos y los procesa tan pronto como llegan. Spark Streaming utiliza un modelo basado en microlotes, que divide el flujo de datos en una serie de pequeños lotes para su procesamiento.
Precisión: la precisión de procesamiento de transmisión de Flink puede alcanzar el nivel de milisegundos, mientras que el intervalo de lote predeterminado de Spark Streaming es de varios segundos, con menor precisión.
Gestión de estado: el mecanismo de gestión de estado de Flink es muy flexible y puede equilibrar la memoria y el disco para admitir escenarios de aplicaciones más complejos. El mecanismo de administración de estado de Spark Streaming es relativamente simple y solo admite el almacenamiento del estado en la memoria.
Programación de tareas: Flink adopta una estrategia de programación de tareas basada en prioridades, que puede ajustar automáticamente la asignación de recursos en el clúster. Si bien Spark Streaming usa el programador de tareas de Spark, el programador solo considera los recursos de CPU y memoria, y no puede considerar otros factores, como el ancho de banda de la red.
Escenarios de aplicación: Flink es adecuado para escenarios de aplicación con altos requisitos de baja latencia y alto rendimiento, como análisis de transacciones financieras, monitoreo de red en tiempo real, etc. Spark Streaming es adecuado para escenarios que requieren menos procesamiento de datos en tiempo real pero requieren un procesamiento por lotes a gran escala, como el análisis por lotes fuera de línea.
En resumen, tanto Flink como Spark Streaming tienen sus propias ventajas y escenarios aplicables, y la elección específica debe hacerse de acuerdo con los escenarios y requisitos de la aplicación específica. Si necesita lograr un procesamiento de datos en tiempo real de baja latencia y alto rendimiento, puede considerar usar Flink; si necesita procesar por lotes datos a gran escala, puede considerar usar Spark Streaming.
6. ¿Cuál es la diferencia entre un esquema de estrella y un esquema de copo de nieve?
El esquema de estrella y el esquema de copo de nieve son los dos métodos de modelado de datos más utilizados en los almacenes de datos. Sus principales diferencias son las siguientes:
Complejidad estructural: el esquema en estrella contiene solo una tabla de hechos y varias tablas de dimensiones, y todas las tablas de dimensiones están directamente relacionadas con la tabla de hechos. En comparación con el modelo de estrella, el modelo de copo de nieve tiene un paso más, que consiste en normalizar las tablas de dimensiones, de modo que los atributos de las tablas de dimensiones también puedan convertirse en nuevas tablas de dimensiones, generando así más tablas de dimensiones, lo que puede reducir la redundancia. también aumenta la complejidad del modelo.
Flexibilidad: el esquema en estrella es relativamente simple, fácil de entender y mantener, y también tiene un buen rendimiento de consulta. Sin embargo, su flexibilidad es relativamente baja y es difícil lidiar con algunos escenarios de consulta complejos. El modelo de copo de nieve es relativamente flexible y puede admitir más escenarios de consulta, pero también aumenta la complejidad de la consulta.
Espacio de almacenamiento: hay una gran cantidad de datos redundantes en el esquema de estrella y el esquema de copo de nieve normaliza las tablas de dimensiones, lo que puede reducir los datos redundantes y ahorrar espacio de almacenamiento.
Legibilidad: el esquema en estrella es relativamente simple, fácil de entender y mantener, y también tiene buena legibilidad. Sin embargo, la estructura del modelo de copos de nieve es más complicada y la legibilidad es relativamente baja.
En resumen, el modelo estrella es más adecuado para escenarios de análisis de datos simples, como estadísticas de datos, análisis de informes, etc.; mientras que el modelo de copo de nieve es más adecuado para escenarios de análisis de datos complejos, como minería de datos, análisis OLAP, etc. Al mismo tiempo, en aplicaciones específicas, se debe seleccionar el método de modelado de datos adecuado de acuerdo con factores como la escala de datos, los escenarios de consulta y los requisitos de la aplicación.
Para el video de operación específico, puede ver la repetición de la transmisión en vivo de ayer.
La mayor expectativa para ChatGPT es cómo ayudará a aprender la eficiencia, cómo ayudará a trabajar y cómo usarlo como una herramienta de productividad. Esto es realmente muy importante, y también es el centro de nuestra atención.
Continuaré prestando atención y daré la bienvenida a todos para discutir juntos.