Si hallas algún fallo en tu código o proyecto, recuerda probar siempre en un entorno de testing antes subir el código al trabajo final.
Solución:
HDFS realmente no está diseñado para muchos archivos pequeños.
Para cada archivo nuevo que lea, el cliente tiene que hablar con el nodo de nombre, que le da la(s) ubicación(es) de los bloques del archivo, y luego el cliente transmite los datos desde el nodo de datos.
Ahora, en el mejor de los casos, el cliente hace esto una vez y luego descubre que es la máquina con los datos y puede leerlos directamente desde el disco. Esto será rápido: comparable a las lecturas directas de disco.
Si no es la máquina la que tiene los datos, entonces debe transmitir los datos a través de la red. Entonces está limitado por las velocidades de E/S de la red, que no deberían ser terribles, pero aún así un poco más lentas que la lectura directa del disco.
Sin embargo, está obteniendo un caso aún peor, donde la sobrecarga de hablar con el nodo de nombre se vuelve significativa. Con solo archivos de 1 KB, está llegando al punto en el que está intercambiando tantos metadatos como datos reales. El cliente debe realizar dos intercambios de red separados para obtener los datos de cada archivo. Agregue a esto que el namenode probablemente esté siendo golpeado por todos estos subprocesos diferentes y, por lo tanto, podría convertirse en un cuello de botella.
Entonces, para responder a su pregunta, sí, si usa HDFS para algo para lo que no está diseñado, será lento. Combine sus archivos pequeños y use MapReduce para obtener la ubicación de los datos y tendrá un rendimiento mucho mejor. De hecho, debido a que podrá aprovechar mejor las lecturas de disco secuenciales, no me sorprendería si la lectura de un archivo HDFS grande fuera incluso más rápido que leer muchos archivos locales pequeños.
solo para agregar a lo que Joe ha dicho, otra diferencia entre HDFS y otros sistemas de archivos es que mantiene la E / S del disco lo menos posible al almacenar datos en bloques más grandes (normalmente 64M o 128M) en comparación con FS tradicional donde el tamaño del bloque FS es en el orden de KB. por esa razón, siempre dicen que HDFS es bueno para procesar pocos archivos grandes en lugar de grandes archivos pequeños. la razón detrás de esto es el hecho de que, aunque ha habido avances significativos en componentes como cpu, ram, etc. en los últimos tiempos, la E/S del disco es un área en la que todavía no hemos avanzado tanto. esta era la intención detrás de tener bloques tan grandes (a diferencia del FS tradicional) y mantener el uso del disco lo menos posible.
además, si el tamaño del bloque es demasiado pequeño, tendremos un mayor número de bloques. lo que significa más metadatos. esto puede volver a degradar el rendimiento, ya que es necesario cargar más cantidad de información en la memoria. para cada bloque, que se considera un objeto en HDFS, tiene alrededor de 200B de metadatos asociados. si tiene muchos bloques pequeños, solo aumentará los metadatos y podría terminar con problemas de RAM.
Hay una publicación muy buena en la sección del blog de Cloudera que habla sobre el mismo tema. Puedes visitar eso aquí.
Comentarios y puntuaciones del post
Nos encantaría que puedieras dar recomendación a este tutorial si te fue útil.