Tabla de contenido
SlotSelectionStrategy (estrategia de selección de espacios)
SlotPool (grupo de recursos de tragamonedas)
Grupo para compartir tragamonedas
1.Grupo de ranuras compartidas
Abstracción de recursos
Los recursos involucrados en Flink se dividen en dos niveles: recursos del clúster y recursos propios de Flink. Los recursos del clúster administran recursos de hardware, incluida CPU, memoria, GPU, etc., que son administrados por el marco de administración de recursos (yarn, k8s, Mesos), y Flink solicita y libera recursos del marco de administración de recursos.
Flink solicita un contenedor de recursos (Contenedor de Yarn o Pod de K8S) desde el marco de administración de recursos y ejecuta un proceso de TaskManager en un contenedor. Los recursos del contenedor son relativamente gruesos para Flink. Por ejemplo, un solo contenedor puede usar 1 núcleo de CPU y memoria 8G. Debido a los diferentes tipos de computación, una tarea que ocupa un contenedor puede no utilizar completamente los recursos, por lo que se usará un solo contenedor. por múltiples contenedores.Flink compartir tareas
Flink divide los recursos aplicados y cada parte se llama Task Slot, como se muestra a continuación
En las versiones anteriores a la 1.14, se trataba de una gestión de recursos detallada (la versión 1.14 agregó una gestión de recursos detallada, que todavía era una versión beta en Flink; consulte FLIP-169, FLIP-156 y FLIP-56 para obtener más detalles), y los recursos A un TaskMnanager se le asignó la misma cantidad. Dividido en n partes (n proviene del archivo de configuración flink-conf.yaml), es decir, se pueden ejecutar hasta n tareas en el TaskManager. En la figura anterior, 1 TaskManager contiene 3 espacios para tareas.
En términos generales, existen tres roles principales en el marco de programación de recursos de Flink, a saber, JobMaster (en lo sucesivo, JM), ResourceManager (en lo sucesivo, RM) y TaskManager. Las tareas escritas por el usuario primero se compilarán en JobGraph, y luego los recursos se inyectarán y enviarán a JM. La función de JM es administrar la aplicación de recursos y la implementación de ejecución de JobGraph.
El componente relacionado con la programación en JM es el Programador, que genera una serie de SlotRequests basadas en JobGraph, luego agrega estos SlotRequests para generar un ResourceRequirement y lo envía a RM. Después de que RM reciba la declaración de recursos, primero verificará las capacidades de recursos existentes en el cluster Si puede satisfacer sus necesidades, enviará una solicitud a TM para pedirle que ofrezca un espacio al JM correspondiente (la asignación de espacios aquí la completa el componente SlotManager). Si los recursos existentes no son suficientes, solicitará nuevos recursos de K8 externos o Yarn a través del controlador interno. Finalmente, después de que JM reciba suficientes espacios, comenzará a implementar operadores y el trabajo podrá ejecutarse.
Administrador de recursos
efecto:
-
Solicite un contenedor para iniciar una nueva MT o solicite un espacio para un trabajo
-
Manejar la salida anormal de JobManager y TaskManager
-
Almacene en caché el TaskManager (es decir, el contenedor) y espere un período de tiempo antes de liberar los contenedores no utilizados para evitar aplicaciones repetidas y liberación de recursos.
-
Conciencia de latidos de JobManager y TaskManager
Hay 3 controladores ResourceManager integrados en Flink, que corresponden a diferentes marcos de gestión de recursos.
Administrador de ranuras
SlotManager enfrenta diferentes objetos y proporciona diferentes funciones
-
Proporcione acciones de administración como registro, cancelación del registro y salida inactiva para TaskManager.
-
Para trabajos de Flink, reciba solicitudes y lanzamientos de espacios, informes de recursos, etc. Cuando los recursos son insuficientes, SlotManager almacena temporalmente las solicitudes de recursos en la cola de espera. SlotManager notifica a ResourceManager que solicite más recursos e inicie un nuevo TaskManager. Después de que TaskManager se registre con SlotManager, SlotManager tendrá nuevos recursos, que se obtienen secuencialmente de la cola de espera. Distribuyendo recursos.
SlotSelectionStrategy (estrategia de selección de espacios)
Cuando Flink decide en qué TaskManager se ejecutará una tarea, hará una selección basada en la estrategia. Hay diferentes estrategias de selección al seleccionar Slot. SlotSelecionStrategy es la interfaz definida por la estrategia. Su sistema de clases es como se muestra a continuación.
Las estrategias de selección generalmente se dividen en dos categorías.
-
UbicaciónPreferenciaSlotSelectionStrategy
Las estrategias de posición primero se dividen en dos categorías:
-
Estrategia predeterminada: DefaultLocationPreferenceSlotSelectionStrategy. Esta estrategia no considera la distribución uniforme de los recursos. Seleccionará el primero del conjunto de Sloy disponible que cumpla las condiciones, y así sucesivamente.
-
Estrategia equilibrada: EvenlySpreadOutLocationPreperenceSlotSelectionStrategy. Esta estrategia considera la asignación equilibrada de recursos. Seleccionará la ranura con la mayor cantidad de recursos restantes del conjunto de ranuras disponibles que cumpla con las condiciones e intentará permitir que cada TaskManager soporte la presión informática de manera equilibrada.
2. Se ha asignado la estrategia de selección de prioridad de ranura PreviousAllocationSlotSelectionStrategy
Si actualmente no hay espacios libres asignados, se seguirá utilizando la estrategia de ubicación limitada para asignar y solicitar espacios.
SlotPool (grupo de recursos de tragamonedas)
El programador de JobMaster primero obtiene Slots de SlotPool para programar tareas. Cuando SlotPool no tiene suficientes recursos de Slot para ejecutar el trabajo, primero intentará obtener recursos de ResoucureManager. Si ResourceManager no está disponible actualmente, ResouceManager rechaza la solicitud de recursos o la solicitud expira , el recurso Si la aplicación falla, el inicio del trabajo falla.
Después de que JobMaster solicite recursos, retendrá la ranura localmente para evitar que el trabajo falle debido a excepciones de ResourceManager. Para el procesamiento por lotes, mantener el recurso JobMaster primero puede evitar solicitar recursos del ResourceManager varias veces. Al mismo tiempo, la falta de disponibilidad del ResourceManager no afectará la ejecución continua del trabajo. Solo los recursos insuficientes harán que la ejecución del trabajo falle.
Cuando el trabajo se haya ejecutado o el trabajo esté completamente iniciado y queden recursos restantes, JobMaster devolverá los recursos restantes al ResourceManager.
Grupo para compartir tragamonedas
Condiciones de espacios compartidos: subtareas de diferentes tareas del mismo trabajo
Flink tiene dos tipos de grupos para compartir
1.Grupo de ranuras compartidas
Restricciones de uso compartido no obligatorias. El uso compartido de ranuras verifica si hay una ranura compartida según el ID de JobVerties en el grupo. Solo asegúrese de que el mismo ID de JobVertex no pueda aparecer en una ranura compartida.
Entre los Slots que cumplan con los requisitos de recursos, busque un Slot que no tenga el mismo JobVertex ID y seleccione un Slot de acuerdo con la estrategia de selección de Slots. Si no hay ningún Slot que cumpla con las condiciones, solicite un nuevo Slot.
2.CoLocationGroup
CoLocationGroup, también conocido como grupo de intercambio de restricciones locales, tiene restricciones obligatorias para compartir espacios. CoLocationGroup se usa en operaciones iterativas, es decir, se llama en la API de IterativeStream. Las tareas en operaciones iterativas deben compartir la misma ranura del TaskManager. CoLocationGroup puede verse como un caso especial de SlotSharingGroup.
Cabe señalar aquí que durante el proceso de conversión de JobGraph a ExecutionGraph, a cada ExecutionVertex se le asigna un número escrito de acuerdo con el grado de paralelismo. El ExecutionVertex calculado iterativamente con el mismo número se colocará en el grupo de restricciones compartido local y compartirá el mismo Objeto CoLocationContraint. Durante la programación Cuando, puede encontrar la información de ranura de otras tareas en este grupo según el número.
El uso compartido de CoLocation verifica si la ranura asignada con la misma restricción CoLocationConstraint está disponible en función de la CoLocationConstraint asociada con cada ExecutionVertex en el grupo. Al programar la ejecución del trabajo, primero busque el TaskManager implementado por otras tareas en esta restricción. Si no, solicite un nuevo Ranura. Si hay una, comparte la ranura en el Administrador de tareas.