Para ampliar la respuesta de Paul Mackles, creo que hay un par de preguntas aquí.
En términos generales, a nosotros (Cloudera) nos gusta usar * discos * (no solo particiones) para el sistema operativo y los discos de datos utilizados por el nodo de datos (DN) y / o el rastreador de tareas (TT). Esto tiene que ver con los patrones comunes de E / S del sistema operativo versus el de los procesos de Hadoop hasta cierto punto. Más aún, esto es para aislar fallas de los sabores humanos, de configuración y de hardware.
El disco del sistema operativo
- ¿Qué son las certificaciones de Big Data? ¿Es necesario tener una buena carrera en el dominio de big data?
- Cómo engañar a los algoritmos de 'Big Data' para evitar el perfil y la orientación precisos de mí mismo
- ¿Qué cursos debo hacer para convertirme en científico de decisiones?
- Cómo comenzar a aprender ciencia de datos desde cero sin un fondo de codificación
- ¿Cómo uso el aprendizaje automático para datos espaciales?
El disco del sistema operativo se puede particionar de cualquier forma que tenga sentido para usted, con la vista puesta en el hecho de que a Hadoop le encanta generar registros. En CDH, colocamos esos registros en / var / log / de forma predeterminada, aunque puede moverlos si lo desea. Por lo general, tampoco desea que los registros de Hadoop vayan a uno de los discos de datos, ya que generalmente crea suficiente contención para degradar el rendimiento de la unidad, sin mencionar el desequilibrio en el consumo de espacio que crea.
En la mayoría de los casos, la gente tiende a no preocuparse por las fallas del disco del sistema operativo por las razones que mencionó Paul Mackles, excepto por el nombre (NN) (aunque incluso eso es menos común ahora con el soporte NN HA y QJM). Si pisa fuerte y exige redundancia de disco del sistema operativo, definitivamente no desea RAID 5; tirarás demasiado espacio (R5 requiere 3 discos como mínimo). RAID 1 (reflejo) es mucho más apropiado. Todos los discos de datos siempre deben ser JBOD (sin RAID, cada disco con un sistema de archivos discreto, montado por separado).
Los discos de datos
Hay dos escuelas de pensamiento sobre cómo usar los discos restantes para datos. Los presentaré en el orden en que los veo en la naturaleza.
* Datos DN y TT en los mismos discos
Este es, con mucho, el escenario de implementación más común. Divide cada disco de datos en una partición gigante que abarca todo el disco y lo monta en / data / . En este directorio, crea “mapeado / local” para el TT y “dfs / dn” para el DN. Configura HDFS para reservar espacio para los datos locales de MapRed (establezca dfs.datanode.du.reserved en hdfs-site.xml en la cantidad de bytes que se dejarán para asignar en cada disco).
* Datos DN y TT en discos dedicados
Esto es menos común, pero también tiene algún mérito. En este caso, aún crea una partición grande en cada disco, los monta igual que antes, pero solo le da al DN una cierta cantidad de discos, dejando algunos al TT para los datos locales mapeados. La idea aquí es que los DN tienen un perfil de E / S diferente al TT y terminan usando los discos de manera muy diferente. La desventaja de esto es que sacrifica un poco de capacidad y rendimiento, ya que al TT generalmente se le da un recuento de husillos mucho menor que el DN. Los discos TT terminan viendo una mala utilización (en la mayoría de los casos), aunque generalmente es más predecible.
Finalmente, si solo está haciendo un POC y solo tiene un disco, agrúpelo todo en una sola partición y termine con él. Sin embargo, no desea ejecutar la producción de esta manera. Si solo tiene una unidad por nodo, querrá repensar su perfil de hardware para su clúster.
(Enchufe desvergonzado) Hay un buen libro que habla de todo esto. Guiño, guiño, empujar, empujar. 😉 Operaciones de Hadoop: Eric Sammer: 9781449327057: Amazon.com: Libros
