Aquí hay algunas cosas al azar que no creo haber escrito en otras respuestas. No lo he comprobado, así que espero que no haya duplicados. Algunos de estos son de charlas que he dado, por lo que se disculpa si se trata de repeticiones.
- Cuota todo
… incluso si solo se está ejecutando un flujo de trabajo en la caja. Las cuotas proporcionan una manera de evitar que ese trabajo fuera de control derribe la red. Para las personas que no miden la capacidad, alcanzar ese límite de cuota generalmente es una señal de que algo estaba por debajo de las especificaciones.
- Repensar las colas
No soy un fanático de la ‘cola dedicada’ como política estándar o como prioridad de tareas equitativas. En mi experiencia, ambos finalmente dañan la utilización de la red. En cambio, me gusta implementar el planificador de capacidad con colas basadas en SLA. Por ejemplo, una cola rápida (tiempos de tarea 15 minutos) con temporizadores de tareas que eliminan tareas que toman demasiado tiempo. Configure la cola rápida de modo que pueda robar en la ranura de la cola lenta. Esto brinda a los usuarios finales un incentivo real para escribir código eficiente. ¿Quiere ver que su trabajo se convierta en un puesto más rápido? ¡Escriba un código mejor y entre en el carril rápido!
- ¿Cuáles son las rutas de aprendizaje típicas del análisis de datos?
- ¿Cómo se ve la arquitectura de datos de una red publicitaria?
- ¿Por qué elegiste trabajar en ciencia de datos sobre finanzas cuantitativas?
- ¿Qué es la curva ROC?
- Cómo convertirse en un científico actuarial y de datos al mismo tiempo
- / tmp es un pozo de desesperación
Desde el principio, tenga un plan para limpiar / tmp regularmente. Hay muchos, muchos escenarios de falla que las herramientas como el cerdo y la colmena no manejan bien (principalmente debido al manejo inexistente de la señal) y, como resultado, dejan muchas cosas dando vueltas en / tmp. Por ejemplo, en LinkedIn (empresa), tenemos un script de administración programado regularmente que elimina archivos y directorios con más de 3 días de / tmp.
- El caché distribuido es el camino y la luz
Hay dos hábitos terribles que las personas nuevas en Hadoop tienden a hacer.
- Cree un jar grande y masivo que tenga todas las dependencias dentro de él. Esto conduce a ineficiencias increíbles en la capa de red y potencialmente al llenado de unidades en el Rastreador de tareas. Para 0.20.2, puede conducir a un bloqueo JT. Si se usa el mismo frasco para múltiples trabajos, esto tiene un efecto multiplicativo.
- Preinstale todas sus dependencias en las rutas de clase predeterminadas de Hadoop. Cuando estas dependencias necesitan actualizarse, eso es un tiempo de inactividad. Cuando uno quiere probar una nueva versión o por alguna otra razón necesita un frasco conflictivo, que termina en dolor y sufrimiento.
La respuesta a ambas: use la memoria caché distribuida para enviar contenido a los nodos de una manera bastante eficiente. Pueden estar vinculados a trabajos individuales o compartidos, dependiendo de la versión y la configuración.
- Más reductores pueden ralentizarlo
En muchos, muchos casos, los desarrolladores lanzan demasiados reductores en un trabajo en un intento de hacerlo ‘correr más rápido’. Sin embargo, no piensan en las consecuencias de esa decisión cuando todos esos reductores activan el equivalente de un DDoS durante la combinación o cuando el próximo trabajo en la tubería lee esa salida …
- RAM es el recurso más valioso que tienes
Todo el mundo habla de CPU o disco IO o red IO … pero el consumo real de recursos que reducirá su rendimiento está fuera de control del uso de RAM. En muchos sistemas operativos, abusar de la RAM va a destruir por completo los otros recursos, ya que dependen de la disponibilidad para crear memorias intermedias y cachés. Entonces, si tiene un archivo de diccionario de 1GB, piense en mmap () ‘en lugar de absorberlo todo en la RAM.
