database - data - hadoop

tamaño del bloque de datos en HDFS, ¿por qué 64 MB? (8)

Si el tamaño del bloque se estableció en menos de 64, habría una gran cantidad de bloques en todo el clúster, lo que hace que NameNode administre una enorme cantidad de metadatos.
Como necesitamos un Mapper para cada bloque, habría muchos Mappers, cada uno de los cuales procesará una porción de datos, que no es eficiente.

El tamaño de bloque de datos predeterminado de HDFS / hadoop es de 64 MB. El tamaño del bloque en el disco generalmente es de 4 KB. ¿Qué significa el tamaño de bloque de 64 MB? -> ¿Significa que la unidad de lectura más pequeña del disco es 64 MB?

En caso afirmativo, ¿cuál es la ventaja de hacer eso? -> fácil para el acceso continuo de archivos grandes en HDFS?

¿Podemos hacer lo mismo usando el tamaño de bloque original de 4 KB en el disco?

A continuación se muestra lo que explica el libro "Hadoop: The Definitive Guide", 3ª edición (p45).

¿Por qué un bloque en HDFS es tan grande?
Los bloques HDFS son grandes en comparación con los bloques de disco, y la razón es minimizar el costo de las búsquedas. Al hacer que un bloque sea lo suficientemente grande, el tiempo para transferir los datos del disco puede ser significativamente mayor que el tiempo para buscar el inicio del bloque. Por lo tanto, el tiempo para transferir un archivo grande hecho de múltiples bloques opera a la velocidad de transferencia del disco.
Un cálculo rápido muestra que si el tiempo de búsqueda es de alrededor de 10 ms y la velocidad de transferencia es de 100 MB / s, para hacer que el tiempo de búsqueda sea el 1% del tiempo de transferencia, necesitamos hacer que el tamaño del bloque sea de alrededor de 100 MB. El valor predeterminado es en realidad 64 MB, aunque muchas instalaciones HDFS usan bloques de 128 MB. Esta cifra se seguirá revisando al alza a medida que las velocidades de transferencia crezcan con las nuevas generaciones de unidades de disco.
Sin embargo, este argumento no debería tomarse demasiado lejos. Las tareas de mapa en MapReduce normalmente operan en un bloque a la vez, por lo que si tiene muy pocas tareas (menos que los nodos en el clúster), sus trabajos se ejecutarán más lentamente de lo que lo harían de otra manera.

El diseño de HDFS se inspiró originalmente en el diseño de Google File System (GFS). Estas son las dos razones para tamaños de bloques grandes como se indica en el documento GFS original (nota 1 en terminología GFS vs HDFS terminología: fragmento = bloque, chunkserver = nodo de datos, maestro = namenode, nota 2: el formato en negrita es mío):

Un gran tamaño de porción ofrece varias ventajas importantes. En primer lugar , reduce la necesidad de los clientes de interactuar con el maestro porque las lecturas y escrituras en el mismo fragmento requieren solo una solicitud inicial al maestro para la información de ubicación del fragmento. La reducción es especialmente significativa para nuestras cargas de trabajo porque las aplicaciones generalmente leen y escriben archivos de gran tamaño de forma secuencial. [...] Segundo , dado que en una gran porción, un cliente es más probable que realice muchas operaciones en un trozo dado, puede reducir la sobrecarga de red al mantener una conexión TCP persistente al servidor de fragmentos durante un período de tiempo prolongado. En tercer lugar, reduce el tamaño de los metadatos almacenados en el maestro. Esto nos permite mantener los metadatos en la memoria, lo que a su vez trae otras ventajas que discutiremos en la Sección 2.6.1.

Finalmente, debo señalar que el tamaño predeterminado actual en Apache Hadoop es de 128 MB.

En HDFS, el tamaño del bloque controla el nivel de eliminación de la duplicación. Cuanto menor sea el tamaño del bloque, tus bloques estarán distribuidos de manera más uniforme en los DataNodes. Cuanto mayor sea el tamaño del bloque, es posible que sus datos estén distribuidos de forma menos equitativa en su clúster.

Entonces, ¿qué sentido tiene elegir un tamaño de bloque más alto en lugar de un valor bajo? Si bien, en teoría, la distribución equitativa de datos es algo bueno, tener un tamaño de bloques demasiado bajo tiene algunos inconvenientes importantes. La capacidad de NameNode es limitada, por lo que tener un tamaño de bloques de 4KB en lugar de 128MB significa también tener 32768 veces más información para almacenar. MapReduce también podría beneficiarse de datos igualmente distribuidos al lanzar más tareas de mapas en más NodeManager y más núcleos de CPU, pero en la práctica se perderán beneficios teóricos al no poder realizar lecturas secuenciales y almacenadas temporalmente y debido a la latencia de cada tarea de mapa.

En el tamaño de bloque del sistema operativo normal es 4K y en hadoop es de 64 Mb. Porque para mantener fácilmente los metadatos en Namenode.

Supongamos que tenemos solo 4k de tamaño de bloque en hadoop y estamos tratando de cargar 100 MB de datos en este 4k, entonces aquí necesitamos más y más bloques de 4k requeridos. Y namenode necesita mantener todos estos 4k bloques de metadatos.

Si usamos 64Mb de tamaño de bloque, los datos se cargarán en solo dos bloques (64mb y 36mb). Por lo tanto, el tamaño de los metadatos se reduce.

Conclusión: Para reducir la carga de namenode hdfc, prefiera 64mb (predeterminado) o 128mb de tamaño de bloque

La razón por la que Hadoop eligió 64MB fue porque Google eligió 64MB. La razón por la que Google eligió 64MB se debió a un argumento de Goldilocks.

Tener un tamaño de bloque mucho más pequeño provocaría un aumento de la sobrecarga de búsqueda.

Tener un tamaño de bloque moderadamente más pequeño hace que las tareas de mapa se ejecuten lo suficientemente rápido como para que el costo de programarlas sea comparable al costo de ejecutarlas.

Tener un tamaño de bloque significativamente mayor comienza a disminuir el paralelismo de lectura disponible disponible y, en última instancia, puede hacer que sea difícil programar tareas locales para las tareas.

Consulte la publicación de investigación de Google: MapReduce http://research.google.com/archive/mapreduce.html

Tiene más que ver con las búsquedas en disco de la unidad de disco duro (unidades de disco duro). Con el tiempo, el tiempo de búsqueda del disco no había progresado mucho en comparación con el rendimiento del disco. Por lo tanto, cuando el tamaño del bloque es pequeño (lo que conduce a demasiados bloques) habrá demasiadas búsquedas de disco que no son muy eficientes. A medida que progresamos de HDD a SDD, el tiempo de búsqueda de disco no tiene mucho sentido ya que están moviendo partes en SSD.

Además, si hay demasiados bloques, se forzará el nodo de nombre. Tenga en cuenta que Name Node tiene que almacenar los metadatos completos (datos sobre bloques) en la memoria. En Apache Hadoop, el tamaño de bloque predeterminado es 64 MB y en Cloudera Hadoop el valor predeterminado es 128 MB.

What does 64MB block size mean?

El tamaño de bloque es la unidad de datos más pequeña que un sistema de archivos puede almacenar. Si almacena un archivo de 1k o 60Mb, ocupará un bloque. Una vez que cruce el límite de 64Mb, necesita un segundo bloque.

If yes, what is the advantage of doing that?

HDFS está diseñado para manejar archivos grandes. Digamos que tienes un archivo de 1000Mb. Con un tamaño de bloque de 4k, tendría que realizar 256,000 solicitudes para obtener ese archivo (1 solicitud por bloque). En HDFS, esas solicitudes pasan por una red y vienen con muchos gastos generales. Cada solicitud debe ser procesada por el Nodo de Nombre para descubrir dónde se puede encontrar ese bloque. ¡Eso es mucho tráfico! Si usa bloques de 64Mb, el número de solicitudes baja a 16, lo que reduce en gran medida el costo de los gastos generales y la carga en el Nodo de nombre.