Apache Spark admite cuatro métodos de implementación distribuidos, a saber, independiente, chispa en mesos y chispa en YARN . Entre ellos, Kubernetes, el primero es similar al modo adoptado por MapReduce 1.0, que implementa la tolerancia a fallas y la administración de recursos internamente, mientras que los dos últimos son Es la tendencia del desarrollo futuro. Parte de la tolerancia a fallas y la administración de recursos se completa con un sistema de administración de recursos unificado: deje que Spark se ejecute en un sistema de administración de recursos general, de modo que pueda compartir un recurso de clúster con otros marcos informáticos, como MapReduce El beneficio es reducir los costos de operación y mantenimiento y mejorar la utilización de los recursos (los recursos se asignan a pedido). Este artículo presentará estos cuatro métodos de implementación y comparará sus ventajas y desventajas.
modo autónomo
Es decir, el modo independiente, que viene con un servicio completo, se puede implementar por separado en un clúster sin depender de ningún otro sistema de administración de recursos. Hasta cierto punto, este modelo es la base de los otros dos. Aprendiendo del modelo de desarrollo Spark, podemos tener una idea general para desarrollar un nuevo marco informático: primero diseñe su modelo independiente. Para un desarrollo rápido, no es necesario considerar la tolerancia a fallas de los servicios (como maestro / esclavo) al principio , y luego desarrolle el Wrapper correspondiente, implemente el servicio en modo autónomo en el hilo o mesos del sistema de administración de recursos intactos, y el sistema de administración de recursos es responsable de la tolerancia a fallas del servicio en sí. En la actualidad, Spark no tiene ningún punto único de falla en modo autónomo, esto se logra con la ayuda de zookeeper, y la idea es similar a la solución de punto único de falla maestro de Hbase. Al comparar Spark de forma independiente con MapReduce, encontrará que los dos son exactamente iguales en términos de arquitectura:
1) Todos están compuestos por servicios maestro / esclavo, y al principio hubo un solo punto de falla en el maestro, que luego se resolvió a través de zookeeper (el JobTracker de Apache MRv1 todavía tiene un solo punto de falla, pero la versión CDH ha sido resuelto);
2) Los recursos de cada nodo se abstraen en ranuras de grano grueso, y se pueden ejecutar tantas tareas como ranuras haya al mismo tiempo. La diferencia es que MapReduce divide el espacio en el espacio del mapa y reduce el espacio, que solo puede ser utilizado por Tarea de mapa y Tarea de reducción, pero no se puede compartir. Esta es una de las razones de la ineficiencia de las tasas de recursos de MapReduce, mientras que Spark es más optimizado. No distingue entre tipos de ranuras. Solo hay una ranura que puede ser utilizada por varios tipos de tareas. Este método puede mejorar la utilización de recursos, pero no es lo suficientemente flexible como para personalizar los recursos de las ranuras para diferentes tipos de tareas. En resumen, estos dos métodos tienen sus propias ventajas y desventajas.
Modo Spark On Mesos
Este es un modelo adoptado por muchas empresas y se recomienda oficialmente (por supuesto, una de las razones es la relación de consanguinidad). Es precisamente porque el soporte para Mesos se consideró al comienzo del desarrollo de Spark , por lo que en la actualidad, Spark que se ejecuta en Mesos será más flexible y más natural que en YARN. Actualmente, en el entorno Spark On Mesos, los usuarios pueden elegir uno de los dos modos de programación para ejecutar sus propias aplicaciones (consulte el " Modo de programación Mesos en Spark " de Andrew Xia ):
1) Modo Grueso: El entorno operativo de cada aplicación consiste en un Dirver y varios Ejecutores, entre ellos, cada Ejecutor ocupa varios recursos y puede ejecutar múltiples Tareas (correspondientes a cuántos "slots"). Antes de que cada tarea del programa de aplicación se ejecute oficialmente, debe solicitar todos los recursos en el entorno en ejecución, y siempre debe ocupar estos recursos durante el proceso de ejecución. Incluso si no los usa, estos recursos se recuperan después de la el programa se ejecuta. Por ejemplo, cuando envías una aplicación, especificas usar 5 ejecutores para ejecutar tu aplicación. Cada ejecutor ocupa 5 GB de memoria y 5 CPU. Cada ejecutor tiene 5 ranuras. Mesos necesita asignar el ejecutor primero. Recursos e iniciarlos, y luego comience a programar tareas. Además, durante la ejecución del programa, el maestro y el esclavo de Mesos no conocen el estado de ejecución de cada tarea dentro del ejecutor. El ejecutor informa directamente el estado de la tarea al Driver a través del mecanismo de comunicación interna. Hasta cierto punto, Se puede considerar que cada aplicación utiliza Mesos construyó un clúster virtual para su propio uso.
2) Modo de grano fino: en vista del hecho de que el modo de grano grueso causará una gran cantidad de desperdicio de recursos, Spark On Mesos también proporciona otro modo de programación: modo de grano fino, este modo es similar a la computación en la nube actual, la idea es Asignar bajo demanda. Al igual que el modo de grano grueso, cuando se inicia la aplicación, el ejecutor se iniciará primero, pero los recursos ocupados por cada ejecutor son solo los recursos necesarios para su propia operación, y no es necesario considerar las tareas a ejecutar en el Después de eso, mesos asignará dinámicamente a cada ejecutor. Se puede ejecutar una nueva tarea cada vez que se asignan algunos recursos, y los recursos correspondientes se pueden liberar inmediatamente después de que se finaliza una sola tarea. Cada tarea informará el estado al esclavo Mesos y al Maestro Mesos, lo cual es conveniente para una administración más detallada y tolerancia a fallas. Este modo de programación es similar al modo de programación MapReduce. Cada tarea es completamente independiente. La ventaja es que es conveniente para el control y el aislamiento de los recursos, pero las desventajas también son obvias. La demora corta en la operación del trabajo es grande.
Modo Spark On YARN
Este es el modelo de implementación más prometedor. Pero limitado al desarrollo de YARN en sí, actualmente solo admite el modo de grano grueso (modo de grano grueso). Esto se debe a que los recursos del contenedor en YARN no se pueden escalar dinámicamente. Una vez que se inicia el contenedor, los recursos disponibles no se pueden cambiar, pero esto ya está en el plan YARN.
Spark on yarn admite dos modos:
1) hilo-cluster: adecuado para el entorno de producción;
2) hilo-cliente: adecuado para interacción y depuración, espero ver el resultado de la aplicación de inmediato
La diferencia entre yarn-cluster y yarn-client es el yarn appMaster. Cada instancia de la aplicación yarn tiene un proceso appMaster, que es el primer contenedor iniciado para la aplicación; es responsable de solicitar recursos del ResourceManager y, después de obtener los recursos, dígale al NodeManager que inicie el contenedor. La implementación interna de los modos de hilo-clúster y hilo-cliente sigue siendo bastante diferente. Si necesita usarlo en un entorno de producción, elija yarn-cluster; si solo es un programa de depuración, puede elegir yarn-client.
Modo de Kubernetes
No
para resumir:
Estos cuatro métodos de implementación distribuidos tienen sus propias ventajas y desventajas y, por lo general, es necesario decidir qué solución adoptar de acuerdo con la situación real. Al elegir una solución, a menudo es necesario considerar la ruta técnica de la empresa (adoptar el ecosistema Hadoop u otros ecosistemas) y las reservas de talento técnico relacionadas. Lo anterior implica muchos modos de implementación de Spark. Es difícil decir qué modo es bueno. Debe basarse en sus necesidades. Si solo está probando la aplicación Spark, puede elegir el modo local. Y si no tiene muchos datos, Standalone es una buena opción. Cuando necesite administrar los recursos del clúster (Hadoop, Spark, etc.) de manera unificada, puede elegir Yarn o Mesos, pero el costo de mantenimiento será mayor.
· Desde un punto de vista comparativo, Mesos parece ser una mejor opción para Spark y se recomienda oficialmente.
· Pero si ejecuta Hadoop y Spark al mismo tiempo, Yarn es una mejor opción por compatibilidad. · Si no solo está ejecutando hadoop, encienda. Docker también se ejecuta en la gestión de recursos y Mesos es más versátil.
· ¡El modo autónomo es más adecuado para clústeres informáticos a pequeña escala!