A cluster resource scheduling method and device, electronic equipment and storage medium

Abstract

Embodiments of the present application provide a cluster resource scheduling method and device, electronic equipment and storage medium, relating to the technical field of big data, to balance resource use cost and violation rate. The method is: when the resource scheduling trigger condition is met, the current resource state information and the to-be-executed task state information of the cluster are obtained; the resource state information and the to-be-executed task state information are input into a resource scheduling model to obtain a target resource scheduling strategy output by the resource scheduling model, wherein the resource scheduling model is obtained by modeling the resource scheduling strategy selection process as a Markov decision process for reinforcement learning, the state space of the Markov decision process includes combinations of different resource state information and different to-be-executed task state information, the action space of the Markov decision process includes each resource scheduling strategy, and the reward function of the Markov decision process is composed of an SLA compliance rate and a resource cost; and the target resource scheduling strategy is executed.

Description

Technical Field

[0001] This application relates to the field of big data technology, and in particular to a cluster resource scheduling method, apparatus, electronic device and storage medium. Background Technology

[0002] Against the backdrop of the rapid development of big data and artificial intelligence technologies, the demand for computing power in scenarios such as massive data processing and AI model training has exploded. Hadoop, as an open-source distributed computing platform, has become a core tool in the field of big data processing. YARN is the resource management cluster of Hadoop clusters, which is responsible for allocating and managing resources for various distributed computing tasks.

[0003] Existing YARN cluster resource scheduling technologies either rely on manual configuration or fixed rules, leading to scheduling delays, or their algorithmic characteristics cannot balance global optimization with personalized needs, making it difficult to cope with the scheduling challenges in multi-tenant, complex task dependencies, and elastic scaling scenarios. Current YARN cluster resource scheduling fails to adequately adapt to the differences in task load among different users and the unevenness of the same user's load across different time periods. This often results in a contradiction between "resource idleness and task blocking," for example, a large amount of resources being wasted during some periods, while tasks violate Service Level Agreements (SLAs) due to the inability to acquire resources in a timely manner during other periods. Simultaneously, resource usage costs continue to rise with increasing computing power demands.

[0004] Therefore, how to balance resource usage costs and SLA violation rates by optimizing scheduling strategies while ensuring service quality is an urgent problem to be solved. Summary of the Invention

[0005] This application provides a cluster resource scheduling method, apparatus, electronic device, and storage medium to balance resource usage costs and SLA violation rates. Under the premise of ensuring SLA, it maximizes the reduction of cluster resource usage costs, thereby achieving global optimization of cluster resources and task requirements.

[0006] In a first aspect, embodiments of this application provide a cluster resource scheduling method, the method comprising: When the resource scheduling triggering conditions are met, the current resource status information of the cluster and the status information of the tasks to be executed are obtained. The resource scheduling triggering conditions include: the current available resources of the cluster do not meet the configuration requirements of at least one task to be executed. The configuration requirements of a task to be executed are determined based on the load level of the task to be executed. Resource status information and task status information are input into the resource scheduling model to obtain the target resource scheduling strategy output by the resource scheduling model. The resource scheduling model is obtained by modeling the resource scheduling strategy selection process as a Markov decision process and performing reinforcement learning. The state space of the Markov decision process includes combinations of different resource status information and different task status information, and the action space of the Markov decision process includes each resource scheduling strategy. The reward function of the Markov decision process consists of the SLA achievement rate and resource cost. Execute the target resource scheduling strategy.

[0007] Secondly, embodiments of this application also provide a cluster resource scheduling device, the device comprising: The acquisition module is used to acquire the current resource status information and the status information of tasks to be executed in the cluster when the resource scheduling trigger conditions are met. The resource scheduling trigger conditions include: the current available resources of the cluster do not meet the configuration requirements of at least one task to be executed. The configuration requirements of a task to be executed are determined based on the load level of the task to be executed. The scheduling strategy determination module is used to input resource status information and task status information into the resource scheduling model to obtain the target resource scheduling strategy output by the resource scheduling model. The resource scheduling model is obtained by modeling the resource scheduling strategy selection process as a Markov decision process and performing reinforcement learning. The state space of the Markov decision process includes combinations of different resource status information and different task status information, and the action space of the Markov decision process includes various resource scheduling strategies. The reward function of the Markov decision process consists of the SLA achievement rate and resource cost. The scheduling and execution module is used to execute the target resource scheduling strategy.

[0008] Thirdly, embodiments of this application also provide an electronic device, including: Processor; and Stored program memory, The program includes instructions that, when executed by the processor, cause the processor to perform the cluster resource scheduling method as described in the first aspect.

[0009] Fourthly, embodiments of this application also provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute the cluster resource scheduling method as described in the first aspect.

[0010] Fifthly, this application provides a computer program product that, when invoked by a computer, causes the computer to execute the cluster resource scheduling method steps as described in the first aspect.

[0011] The beneficial effects of this application are as follows: In the cluster resource scheduling method provided in this application embodiment, firstly, when the resource scheduling triggering condition is met, the current resource status information and the status information of the tasks to be executed are obtained. The resource scheduling triggering condition includes: the currently available resources of the cluster do not meet the configuration requirements of at least one task to be executed, and the configuration requirements of a task to be executed are determined based on the load level of that task. Then, the resource status information and the status information of the tasks to be executed are input into the resource scheduling model to obtain the target resource scheduling strategy output by the resource scheduling model. The resource scheduling model is obtained by modeling the resource scheduling strategy selection process as a Markov decision process and performing reinforcement learning. The state space of the Markov decision process includes combinations of different resource status information and different task status information, and the action space of the Markov decision process includes various resource scheduling strategies. The reward function of the Markov decision process consists of the SLA achievement rate and resource cost. Finally, the target resource scheduling strategy is executed. In this way, by using the trigger condition that "currently available resources do not meet the configuration requirements of each task to be executed" and dynamically determining configuration requirements using load levels, real-time perception and automatic response to resource supply and demand contradictions are achieved. This avoids the scheduling lag caused by traditional solutions relying on manual configuration or fixed rules. Furthermore, the resource scheduling model is built based on a Markov decision process, and its reward function is composed of SLA achievement rate and resource cost. This allows the model to learn to balance service quality and economic cost simultaneously during training, overcoming the shortcomings of existing technologies that are difficult to balance dual-objective optimization. Under the premise of ensuring SLA, it maximizes the reduction of cluster resource usage costs, thereby achieving global optimization of cluster resources and task requirements. At the same time, the state space covers different combinations of resource and task states, and the action space contains multiple resource scheduling strategies, enabling the model to adapt to dynamic changes in cluster resources (such as node failures and load fluctuations) and diverse task characteristics, improving decision stability and generalization ability in complex scenarios.

[0012] Furthermore, other features and advantages of this application will be set forth in the following description and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described herein are used to provide a further understanding of this application, constitute a part of this application, and do not constitute an improper limitation of this application. In the accompanying drawings: Figure 1This is a schematic diagram of an optional system architecture applicable to the embodiments of this application.

[0014] Figure 2 This is a schematic diagram illustrating the implementation process of a cluster resource scheduling method provided in an embodiment of this application.

[0015] Figure 3 This is a schematic diagram of a cluster resource scheduling device provided in an embodiment of this application.

[0016] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While some embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this application. It should be understood that the drawings and embodiments of this application are for illustrative purposes only and are not intended to limit the scope of protection of this application.

[0018] It should be understood that the steps described in the method embodiments of this application may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this application is not limited in this respect.

[0019] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description. It should be noted that the concepts of "first", "second", etc., mentioned in this application are used only to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0020] It should be noted that the terms "a" and "a plurality of" used in this application are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0021] The names of the messages or information exchanged between multiple devices in the embodiments of this application are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0022] The following explanations of some terms used in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0023] (1) Service Level Agreement (SLA): The service quality standard agreed upon by the user and the service provider. In this embodiment of the application, it specifically refers to the constraint that the task must be completed before the specified deadline. Failure to meet this constraint is considered a violation of the SLA.

[0024] (2) SLA violation rate: The ratio of the number of tasks not completed before the deadline to the total number of tasks within a certain period of time is a core indicator for measuring service quality.

[0025] (3) Deep Reinforcement Learning (DRL): an artificial intelligence technology that integrates the perception capabilities of deep learning with the decision-making capabilities of reinforcement learning. It extracts complex environmental features through deep neural networks, allowing the agent to learn the optimal decision-making strategy through trial and error in interaction with the environment.

[0026] (4) Markov Decision Process (MDP): It is a mathematical model describing sequential decision problems and the core theoretical foundation of reinforcement learning. Its core characteristic is that "the future state depends only on the current state and is independent of the past" (Markov property). MDP is like "agent leveling up": the agent (such as the scheduler) is in a dynamic environment (such as a Hadoop cluster). Each step first observes the current state (such as the remaining resources and the backlog of tasks), and then selects an action from the available actions (such as scheduling tasks and expanding nodes). The environment will change to a new state, and the agent will also be given a "reward and punishment" (such as a positive reward for reasonable scheduling and a negative reward for wasting resources). This cycle continues until the goal is achieved. The core is that "the next state only looks at the present and does not dwell on the past", which ultimately allows the agent to learn the optimal strategy that can get the most cumulative rewards.

[0027] (5) Proximal Policy Optimization (PPO) algorithm: This is a deep reinforcement learning algorithm (similar to a "problem-solving tool") specifically designed to solve optimization problems described by the MDP framework. The goal is to find the optimal policy that maximizes long-term cumulative rewards. The PPO algorithm is based on MDP. By fitting the policy function and value function, it learns the optimal decision in the state space and action space defined by the MDP. For example, the Hadoop cluster scheduling process is first modeled as an MDP (defining cluster state and task state as the state space, scheduling and scaling as the action space, etc.), and then the PPO algorithm is used to train the model to find a scheduling policy that balances resource costs and SLA violation rates. The core idea of ​​the PPO algorithm is to improve upon the policy gradient algorithm by limiting the magnitude of policy updates to improve the algorithm's stability and performance. It mainly solves the problems of large fluctuations and slow convergence that are common in traditional policy gradient algorithms during training.

[0028] Based on the above explanations of terms and related terminology, the design concept of the embodiments of this application will be briefly introduced below: Against the backdrop of the rapid development of big data and artificial intelligence technologies, the demand for computing power in scenarios such as massive data processing and AI model training has exploded. Hadoop, as an open-source distributed computing platform, has become a core tool in the field of big data processing. However, the traditional task scheduler of Hadoop clusters has significant shortcomings: it fails to adequately adapt to the differences in task load among different users and the unevenness of the load of the same user during different time periods. This leads to a common contradiction in the cluster: "resource idleness and task blocking coexist." During some periods, a large amount of resources are wasted due to idleness, while during other periods, tasks violate SLAs because they cannot obtain resources in time. At the same time, the cost of resource usage continues to rise with the increase in computing power demand. How to balance the cost of resource usage and the SLA violation rate by optimizing the scheduling strategy while ensuring service quality has become the core pain point for the efficient operation of Hadoop clusters.

[0029] In existing technologies, resource scheduling for YARN clusters (i.e., Hadoop clusters with the YARN resource management framework deployed) typically employs the following three methods: (1) Heterogeneous perception and dynamic load: To address the performance differences among cluster nodes and the diversity of task characteristics, a feedback-based dynamic scheduling mechanism is designed. A lightweight monitoring agent is deployed to collect 13 indicators such as node CPU utilization and disk I / O to construct a node health model; at the same time, task characteristics (such as compute-intensive and I / O-intensive) are extracted to achieve accurate matching between tasks and nodes.

[0030] (2) Combination of static resource pre-allocation and partition scheduling: First, fixed resource partitions are pre-allocated for different users and task types based on historical load data, and then the utilization rate of idle resources is optimized through a dynamic adjustment mechanism. For example, in the hybrid mode of "dedicated cluster + shared cluster", core business occupies dedicated resource partitions to ensure stability, while non-core business reuses idle resources in shared partitions to reduce costs. This method cannot capture the time-varying nature of task load (such as peak and valley) and the dynamic changes of cluster resources (such as node failure, expansion and contraction) in real time, resulting in delayed or rigid scheduling decisions.

[0031] (3) Dynamic scheduling scheme based on mixed integer programming (MIP): With the goal of "minimizing resource cost + SLA violation rate", a mixed integer programming model is constructed. Task scheduling order, resource allocation, node scaling decisions, etc. are set as integer variables. The cluster resource limit, task dependency relationship, deadline, etc. are used as constraints. The optimal scheduling scheme is solved in real time by solvers such as Gurobi and CPLEX. Suitable scenarios: Enterprise-level clusters with a moderate number of tasks and clear constraints, such as batch processing of financial data and scheduling of scientific research computing tasks. Advantages: It can accurately meet the global optimal solution under multiple constraints and has strong stability. Disadvantages: The solution complexity increases exponentially with the number of tasks. The response latency is high when facing large-scale sudden tasks. It is difficult to adapt to dynamic load fluctuations. In addition, when dealing with the dual objectives of resource cost and SLA violation rate, fixed weight or fixed priority sorting is often used. It is not possible to flexibly adjust the optimization tendency according to the user's business needs. It is easy to have a single objective optimal but a global suboptimal situation.

[0032] Existing YARN cluster resource scheduling technologies generally suffer from core defects such as difficulty in simultaneously balancing resource usage costs and SLA violation rates, insufficient adaptability to dynamic load and resource changes, and lack of flexibility in multi-objective optimization. They either rely on manual configuration or fixed rules, leading to scheduling lag, or the characteristics of the algorithms cannot take into account both global optimization and personalized needs, making it difficult to cope with scheduling challenges in multi-tenant, complex task-dependent, and elastic scaling scenarios.

[0033] In view of this, this application provides a cluster resource scheduling method, apparatus, electronic device, and storage medium, which specifically includes: when a resource scheduling trigger condition is met, acquiring the current resource status information and task status information of the cluster, wherein the resource scheduling trigger condition includes: the current available resources of the cluster do not meet the configuration requirements of each task to be executed, and the configuration requirements of a task to be executed are determined based on the load level of the task to be executed; then inputting the resource status information and task status information to be executed into a resource scheduling model to obtain the target resource scheduling strategy output by the resource scheduling model, wherein the resource scheduling model is obtained by modeling the resource scheduling strategy selection process as a Markov decision process and performing reinforcement learning, the state space of the Markov decision process includes: combinations of different resource status information and different task status information to be executed, the action space of the Markov decision process includes: each resource scheduling strategy, and the reward function of the Markov decision process consists of the SLA achievement rate and resource cost; finally, executing the target resource scheduling strategy. In this way, by using the trigger condition that "currently available resources do not meet the configuration requirements of each task to be executed" and dynamically determining configuration requirements using load levels, real-time perception and automatic response to resource supply and demand contradictions are achieved. This avoids the scheduling lag caused by traditional solutions relying on manual configuration or fixed rules. Furthermore, the resource scheduling model is built based on a Markov decision process, and its reward function is composed of SLA achievement rate and resource cost. This allows the model to learn to balance service quality and economic cost simultaneously during training, overcoming the shortcomings of existing technologies that are difficult to balance dual-objective optimization. Under the premise of ensuring SLA, it maximizes the reduction of cluster resource usage costs, thereby achieving global optimization of cluster resources and task requirements. At the same time, the state space covers different combinations of resource and task states, and the action space contains multiple resource scheduling strategies, enabling the model to adapt to dynamic changes in cluster resources (such as node failures and load fluctuations) and diverse task characteristics, improving decision stability and generalization ability in complex scenarios.

[0034] In particular, the preferred embodiments of this application will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments of this application and the features in the embodiments can be combined with each other without conflict.

[0035] See Figure 1The diagram illustrates an optional system architecture applicable to an embodiment of this application. This system architecture may include: terminal devices (101a, 101b) and server 102. The terminal devices (101a, 101b) and server 102 can interact via a communication network. The communication network may employ wireless communication or wired communication methods. For example, the terminal devices (101a, 101b) can access the network and communicate with server 102 via cellular mobile communication technology. This cellular mobile communication technology may include, for example, 5G (5th generation mobile networks) or next-generation mobile communication technology. Optionally, the terminal devices (101a, 101b) can access the network and communicate with server 102 via short-range wireless communication. This short-range wireless communication method may include, for example, wireless fidelity (Wi-Fi) technology.

[0036] This application embodiment does not impose any limitation on the number of communication devices involved in the above system architecture. For example, the above system architecture may include more terminal devices, or it may include fewer terminal devices, or it may also include other network devices. Figure 1 As shown, only terminal devices (101a, 101b) and server 102 are described as examples. The following is a brief introduction to the above communication devices and their respective functions.

[0037] A terminal device (101a, 101b) is a device that can provide voice and / or data connectivity to a user, and may be a device that supports wired and / or wireless connections.

[0038] For example, terminal devices (101a, 101b) may include, but are not limited to: mobile phones, tablets, laptops, handheld computers, mobile internet devices (MID), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminal devices in industrial control, wireless terminal devices in autonomous driving, wireless terminal devices in smart grids, wireless terminal devices in transportation safety, wireless terminal devices in smart cities, or wireless terminal devices in smart homes, etc.

[0039] In addition, the terminal devices (101a, 101b) may have related clients installed. The client may be software, such as an application (APP), browser, short video software, or webpage, mini-program, etc. It should be noted that the terminal devices (101a, 101b) in this application embodiment may be the aforementioned clients related to cluster resource scheduling.

[0040] Server 102 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0041] It is worth mentioning that the server 102 in this embodiment can model the resource scheduling strategy selection process as a Markov decision process, determine the state space, action space and reward function of the Markov decision process; use reinforcement learning algorithm to train the policy network under the Markov decision process to obtain the resource scheduling model, input the resource state information and the state information of the task to be executed into the resource scheduling model, obtain the target resource scheduling strategy output by the resource scheduling model, and execute the target resource scheduling strategy.

[0042] The cluster resource scheduling method provided by the exemplary embodiments of this application will be described below in conjunction with the above system architecture and with reference to the accompanying drawings. It should be noted that the above system architecture is only shown for the purpose of understanding the spirit and principles of this application, and the embodiments of this application are not limited in any way.

[0043] See Figure 2 The diagram illustrates the implementation flow of a cluster resource scheduling method provided in this application embodiment. Taking a server as an example, the specific implementation flow of this method is as follows: S20: When the resource scheduling trigger condition is met, obtain the current resource status information and the status information of the tasks to be executed in the cluster.

[0044] The resource scheduling triggering conditions include: the current available resources of the cluster do not meet the configuration requirements of at least one task to be executed, and the configuration requirements of a task to be executed are determined based on the load level of the task to be executed.

[0045] In this embodiment, the currently available resources of the cluster include: the number of idle nodes and idle CPU / memory. The fact that the currently available resources of the cluster do not meet the configuration requirements of at least one pending task means that the currently available resources of the cluster do not meet the configuration requirements of any single pending task. Specifically, the total configuration requirements of at least one pending task can be compared with the currently available resources of the cluster.

[0046] For example, after obtaining the configuration requirements of a task to be executed (requiring 5 nodes), if the total number of nodes required for all tasks to be executed is 15 and the number of idle nodes in the cluster is 10, then the resource scheduling trigger condition is met. As another example, after obtaining the configuration requirements of a task to be executed (requiring 50 CPU cores), if the total number of CPU cores required for all tasks to be executed is 120 and the number of idle CPU cores in the cluster is 100, then the resource scheduling trigger condition is met.

[0047] Optionally, in this embodiment of the application, the resource scheduling triggering condition further includes: the first real-time monitoring indicator of the cluster reaches a preset first indicator threshold and / or the load prediction result status of the cluster reaches the scheduling condition.

[0048] The first real-time monitoring metric includes at least one of the following: resource gap rate for each task, queue congestion for each queue, and node load balancing. The resource gap rate for a task is equal to the ratio of the difference between the resources requested by the task and the currently available resources to the resources requested by the task. The queue congestion for a queue is equal to the ratio of the number of tasks to be executed in the queue to the maximum concurrency of the queue. The node load balancing is equal to the variance of the resource utilization of all nodes.

[0049] For example, the cluster monitoring system continuously collects the first real-time monitoring index (e.g., once every 5 seconds), and triggers resource scheduling when any of the following threshold conditions are met: (1) The resource gap rate of a certain task to be executed is greater than the corresponding first gap rate threshold (e.g., the first gap rate threshold for a task to be executed with a load level of L1 to L2 is 0.8, the first gap rate threshold for a task to be executed with a load level of L3 is 0.6, and the first gap rate threshold for a task to be executed with a load level of L4 to L5 is 0.4); (2) The queue congestion of a certain queue is greater than the first congestion threshold (e.g., the first congestion threshold is 1.5, which means that the number of tasks to be executed in the queue exceeds the maximum concurrency by 50%); (3) The node load balance is greater than the first balance threshold (e.g., the first balance threshold is 1.2, which means that the load imbalance exceeds the reasonable range).

[0050] For example, the load prediction result of the cluster reaching the scheduling condition includes, but is not limited to, the following three ways: (1) Deploy a load prediction model to predict the task submission volume and resource demand in the future (e.g., 1 hour), input the prediction result as the status information of the task to be executed into the resource scheduling model, and obtain the predicted resource scheduling strategy output by the resource scheduling model. If the predicted resource scheduling strategy needs to be expanded, the load prediction result of the cluster reaches the scheduling condition and triggers resource scheduling; (2) Predict the task submission volume and resource demand in the future. If the current available resources of the cluster do not meet the configuration requirements of at least one task to be executed in the future, the load prediction result of the cluster reaches the scheduling condition and triggers resource scheduling; (3) Deploy an indicator prediction model to predict the resource gap rate, queue congestion and node load balance in the future (e.g., 1 hour). If the indicator prediction result reaches the preset first indicator threshold, the load prediction result of the cluster reaches the scheduling condition and triggers resource scheduling.

[0051] By introducing real-time monitoring threshold triggers, specific abnormal states such as resource shortages, queue congestion, and load imbalances can be detected. Even if overall resources can still meet total demand, scheduling can be initiated promptly for local bottlenecks to prevent problems from escalating. Simultaneously, load prediction triggers allow the scheduling system to proactively expand resources or adjust queues based on predictions of future load trends (such as forecasting upcoming task surges), effectively preventing SLA violations and further reducing the contradiction between idle resources and task congestion. These three triggering conditions (resource insufficiency, monitoring thresholds, and prediction triggers) complement each other, forming a complete triggering system of "passive response + proactive prevention," ensuring rapid intervention in scheduling under any abnormal or anticipated changes.

[0052] In this embodiment of the application, when the resource scheduling triggering conditions are met, a scheduling triggering event (including: triggering conditions, resource status information and task information to be executed) is generated, and the scheduling triggering event is pushed to the resource policy determination module through a message queue.

[0053] The resource status information includes, but is not limited to: node resource utilization (CPU / memory utilization), number of available nodes, queue resource distribution, and node health status. The information on tasks to be executed includes, but is not limited to: the number of tasks to be executed, the load level of each task, SLA constraints, and total resource requirements.

[0054] In addition, it is worth noting that in the embodiments of this application, the configuration requirements of a task to be executed are determined based on the load level of the task to be executed, and the load level of a task to be executed is determined based on the task attribute data, current resource status information and historical scheduling data of the task to be executed.

[0055] Optionally, in this embodiment of the application, a possible implementation is provided for determining the configuration requirements of a task to be executed, specifically by performing the following operations: SA1: In response to a submission request for a task to be evaluated, the task attribute data of the task to be evaluated, the historical scheduling data of similar tasks to be evaluated, and the resource status information are quantified to obtain a feature dataset. Based on the feature dataset, a multi-dimensional risk assessment is performed to obtain the multi-dimensional risk of the task to be evaluated.

[0056] In this embodiment, when a user submits a task through a computing framework such as YARN / MapReduce, the submitted task is treated as a task to be evaluated. In response to the submission request for the task to be evaluated, three types of core data are obtained through three parallel methods: interface listening, node agent collection, and historical data statistics. The three types of core data include: task attribute data, historical scheduling data of similar tasks to the task to be evaluated, and resource status information. The three types of core data are stored in the corresponding database (Redis / InfluxDB / MySQL) to ensure data real-time performance and traceability. Then, the task attribute data of the task to be evaluated, the historical scheduling data of similar tasks to the task to be evaluated, and the resource status information are quantified to obtain a feature dataset. Based on the feature dataset, a multi-dimensional risk assessment is performed to obtain the multi-dimensional risk of the task to be evaluated.

[0057] The task attribute data includes, but is not limited to: resource requirements (CPU / memory requirements), SLA constraints (SLA deadline), task priority and dependencies. Resource status information includes, but is not limited to: node resource utilization, number of available nodes, queue resource distribution and node health status. Historical scheduling data of similar tasks to be evaluated includes: execution baseline of similar tasks, SLA achievement rate and resource consumption baseline.

[0058] Optionally, in this application embodiment, the specific methods for obtaining and storing three types of core data are described: (1) Task attribute data: By listening to the YARN / MapReduce task submission interface, the task resource requirements, SLA deadline, priority and other attributes are captured, the dependency graph (workflow task) and configuration file are parsed to obtain the dependency relationship, and the task attribute data is stored in the Redis cache; (2) Resource status information: By using the Agent client deployed on each node, the basic information of the node and the resource utilization rate are collected periodically, the queue load data is obtained by calling the YARN ResourceManager API, and the data is stored in the InfluxDB time series database after being summarized; (3) Historical scheduling data: By using Hive SQL scripts to periodically count the execution time, SLA achievement rate, resource consumption baseline and other data of similar tasks, the data is stored in the MySQL relational database.

[0059] Optionally, in this embodiment, the feature dataset includes: task-side features, cluster-side features, and historical features. Task-side features include, but are not limited to, resource demand magnitude, SLA sensitivity, dependency complexity, and type coefficient. Cluster-side features include, but are not limited to, cluster resource shortage rate, queue congestion, and node load balancing. Historical features include, but are not limited to, average latency, average SLA violation rate, and average resource utilization for similar tasks. When the task attribute data of the task to be evaluated, the historical scheduling data of similar tasks to be evaluated, and the resource status information are quantified to obtain the feature dataset, the three types of unstructured and qualitative core data are transformed into computable numerical features and quantified according to task-side, cluster-side, and historical-side categories. Specifically, task-side features include: quantifying resource demand levels (high / medium / low) according to preset thresholds, mapping SLA sensitivity based on priority (SLA sensitivity of 1 for core tasks and 0.5 for non-core tasks), using a depth-first search algorithm to calculate dependency complexity, and mapping type coefficients by task type; cluster-side features include: calculating cluster resource gap rate (considering both CPU and memory, cluster resource gap rate = 1 - currently available cluster resources / total resource demand of all tasks), queue congestion, and node load balancing to ensure consistency in feature quantification; and historical features include: extracting average latency, average SLA violation rate, and average resource utilization for similar tasks as evaluation baselines.

[0060] Optionally, in this embodiment, the multi-dimensional risks include: SLA default risk, resource overload risk, and cost consumption risk. This embodiment provides a possible implementation for performing multi-dimensional risk assessment based on a feature dataset to obtain the multi-dimensional risks of the task to be assessed, specifically by performing the following operations: SA11: Using a linear regression model based on a feature dataset, it estimates the task execution time of the task to be evaluated, and determines the risk of SLA default based on the task execution time and SLA deadline.

[0061] In this embodiment of the application, the SLA risk level of the task to be executed is determined based on the range to which the difference between the task execution time and the SLA deadline belongs, and the SLA risk level is quantified into a risk value to obtain the SLA default risk.

[0062] Optionally, in this embodiment, the quantification value of SLA default risk can also be adjusted by the SLA sensitivity in the task-side features. Specifically, the SLA sensitivity is used as a multiplier and multiplied by the basic SLA default risk obtained based on the task execution duration and SLA deadline to obtain the final SLA default risk. In this case, the SLA default risk of high-sensitivity tasks is amplified, while the SLA default risk of low-sensitivity tasks is reduced.

[0063] SA12: Determines resource overload risk based on the cluster's resource shortage rate, queue congestion for the task to be evaluated, and node load balancing.

[0064] The queue congestion level of the task to be evaluated refers to the congestion level of the queue to which the task to be evaluated belongs.

[0065] In this embodiment of the application, the resource shortage rate of the cluster, the queue congestion degree corresponding to the task to be evaluated, and the node load balancing degree are weighted and calculated to obtain the resource overload risk.

[0066] Optionally, in this embodiment, the resource overload risk can also be penalized by the dependency complexity in the resource-side features. For example, the resource overload risk of tasks with high dependency complexity can be amplified (e.g., multiplied by 1.2) to reflect the fact that their actual resource occupation time is longer.

[0067] SA13: Based on the resource requirements of the task to be evaluated and the available resources of a single node, determine the estimated number of nodes, and based on the estimated number of nodes, the cost per node per unit time, and the task execution duration, obtain the cost consumption risk.

[0068] In this embodiment of the application, the ratio between the resource requirement of the task to be evaluated and the available resources of a single node is calculated to obtain the estimated number of nodes. Then, the product of the estimated number of nodes, the unit time node cost, and the task execution time is calculated to obtain the cost consumption risk.

[0069] Optionally, in this embodiment of the application, the cost consumption risk can also be calibrated by the resource demand level in the task-side features. That is, the cost consumption risk is adjusted proportionally according to the resource demand level (high / medium / low) to reflect the cost fluctuation differences of tasks of different levels in resource competition. The higher the resource demand level, the higher the cost consumption risk.

[0070] In this way, the linear regression model is used to predict the execution time, which is more accurate than simple rules by utilizing historical data of similar tasks. The resource overload risk comprehensively considers three levels: the overall cluster (gap rate), the local queue (congestion), and the node distribution (balance), which fully reflects the risk of the task execution environment. By introducing the cost consumption risk, the cost of resource use can be quantified when making decisions, providing a direct basis for balancing SLA and resource costs in the future, and avoiding cost overruns caused by blind expansion.

[0071] SA2: Based on the task priority in multi-dimensional risk and task attribute data, determine the risk score of the task to be evaluated, and use the load level corresponding to the score range to which the risk score belongs as the load level of the task to be evaluated.

[0072] The load level can be divided into five levels, L1-L5, but this application does not impose any restrictions on this.

[0073] In this embodiment of the application, the coefficients of multi-dimensional risks and task priorities are weighted and summed to obtain the risk score of the task to be evaluated.

[0074] For example, the risk score of the task to be evaluated is calculated as follows: 0.4 × SLA default risk + 0.3 × resource overload risk + 0.2 × cost consumption risk + 0.1 × task priority coefficient. In this embodiment, the value of the weighting coefficient is not restricted.

[0075] SA3: Based on the resource configuration template and task attribute data that match the load level, determine the configuration requirements of the task to be evaluated and treat the task to be evaluated as a task to be executed.

[0076] In this embodiment, a preset resource configuration template is associated with each load level. After obtaining the load level of the task to be evaluated, the resource configuration template library is queried to obtain a resource configuration template that matches the load level of the task to be evaluated. Then, based on the resource configuration template and the resource requirement level in the task attribute data, the configuration requirements of the task to be evaluated are determined.

[0077] The configuration requirements include: node requirements / resource requirements, queue allocation (dedicated / shared), and scaling strategies. Resource configuration templates include: scaling strategies, queue types, and resource reservation ratios.

[0078] For example, the resource configuration template associated with the L5 load level is {expansion strategy: priority expansion, queue type: dedicated queue, resource reservation ratio: 15%}.

[0079] In this way, by integrating task attributes, historical baselines, and real-time resource status for feature quantification, the resource requirements, SLA urgency, and execution risks of a task are comprehensively characterized, achieving accurate load assessment and providing a reliable quantitative basis for subsequent scheduling. Furthermore, based on load level matching with preset resource configuration templates (such as priority expansion + dedicated queues for L5 level), high-load, high-risk tasks receive more resource guarantees, while low-load tasks avoid over-allocation, achieving a fine-grained match between resource supply and task demand. In addition, the load level classification and template matching mechanism give the scheduling strategy clear business semantics, allowing operations personnel to intervene in scheduling behavior by adjusting template parameters or weight coefficients, enhancing the system's interpretability and human controllability.

[0080] Furthermore, in this embodiment of the application, after obtaining the configuration requirements of the task to be evaluated, the configuration requirements, load level, and multi-dimensional risks are integrated into a standardized evaluation report, which is pushed to the scheduling strategy determination module through a RESTful API to directly support subsequent resource scheduling operations. At the same time, the standardized evaluation report is stored in a MongoDB database for audit traceability and algorithm iteration optimization, forming a complete closed loop of "evaluation-application-feedback-optimization".

[0081] S21: Input the resource status information and the status information of the task to be executed into the resource scheduling model to obtain the target resource scheduling strategy output by the resource scheduling model.

[0082] The target resource scheduling strategy includes resource adjustment decisions and / or task allocation decisions. The resource scheduling model is obtained by modeling the resource scheduling strategy selection process as a Markov decision process and performing reinforcement learning. The state space of the Markov decision process includes combinations of different resource state information and different task state information to be executed. The action space of the Markov decision process includes each resource scheduling strategy. The reward function of the Markov decision process consists of the SLA achievement rate and resource cost.

[0083] For example, one state in the state space is the integration of resource status information (e.g., [32 nodes, CPU utilization 75%, queue congestion 1.4]) and pending task status information (e.g., [12 pending tasks, 3 pending tasks with load level L5]). The action space contains three core actions: scaling up (adding new nodes), scaling down (taking offline nodes), and queue resource adjustment (allocating dedicated queues / adjusting priorities).

[0084] One of the resource scheduling strategies includes: scaling up / down decisions: number of nodes to scale up (e.g., "add 4 compute nodes"), number of nodes to scale down (e.g., "take 2 idle nodes offline"), and node type (compute node / storage node); queue configuration: task allocation queues (dedicated queue / shared queue), queue priority (P1-P5), and maximum concurrency adjustment (e.g., increasing the maximum concurrency of queues for tasks with load level L5 to 20); and resource allocation: CPU / memory allocation per task and node resource reservation ratio (e.g., reserving 15% resource redundancy for tasks with load level L5).

[0085] In this embodiment, when the resource status information and the status information of the task to be executed are input into the resource scheduling model to obtain the target resource scheduling strategy output by the resource scheduling model, the current state is constructed based on the resource status information and the status information of the task to be executed, and the current state is input into the resource scheduling model so that the resource scheduling model selects the target resource scheduling strategy from the action space and stores the target resource scheduling strategy in JSON format in the MySQL scheduling table, and pushes it to the scheduling execution module.

[0086] The current state is an element in the state space.

[0087] In this way, by directly constructing a state vector from the current resource status information and the status information of the tasks to be executed, and inputting it into the resource scheduling model, the action output can be obtained in one step, avoiding complex iterative calculations. This allows scheduling decisions to be completed in milliseconds, meeting the requirements of online real-time scheduling. Furthermore, the model selects actions based on the current state, meaning that each scheduling decision is tailored to the specific situation of the cluster and tasks at that time, rather than applying a fixed template, thereby improving the accuracy and adaptability of the scheduling strategy. At the same time, the action space contains a variety of resource scheduling strategies (such as expansion, reduction, queue adjustment, etc.), and the model can flexibly select single actions or combinations of actions according to the state, enhancing the flexibility of the scheduling scheme.

[0088] Optionally, in this embodiment, a near-end policy optimization algorithm is used to iteratively train the policy network under a Markov decision process based on a training sample set to obtain a resource scheduling model.

[0089] Each training sample set includes: sample resource status information and sample task status information. Training is divided into two phases: the initial training phase (before the model goes live) and the optimization training phase (after the model goes live). In the initial training phase, a large amount of empirical data can be generated by simulating historical scheduling logs, or the agent can interact with the environment in a simulation environment to train the sample set. In the optimization training phase, the training sample set comes entirely from online interactions in a real production environment and is continuously expanded through a closed-loop feedback mechanism.

[0090] During one iteration of training, the following operations are performed: SB1: Based on the sample resource status information and sample task status information in the current training samples, determine the sample action corresponding to the current training sample, execute the sample action, obtain the sample SLA achievement rate and sample resource cost corresponding to the sample action, and perform a weighted sum of the sample SLA achievement rate and sample resource cost to obtain the sample reward value corresponding to the sample action.

[0091] In this embodiment of the application, the sample reward value = α × sample SLA compliance rate + β × sample resource cost, where α is the weighting coefficient of SLA compliance rate and β is the weighting coefficient of resource cost, and the weighting coefficients can be adjusted.

[0092] Optionally, in this embodiment, the sample reward value = α × sample SLA achievement rate + β × sample resource cost - γ × load imbalance penalty, where γ is the weighting coefficient for load imbalance, and the weighting coefficient can be adjusted. In this way, introducing a load imbalance penalty allows the model to learn a resource scheduling strategy that satisfies task requirements and balances SLA, cost, and load balancing.

[0093] SB2: Adjust the parameters of the policy network based on the sample reward value.

[0094] In this embodiment, the parameters of the policy network are updated by maximizing the expected cumulative reward.

[0095] In this way, the PPO algorithm limits the magnitude of policy updates through a pruning mechanism, avoiding the training oscillations and divergence problems common in traditional reinforcement learning. This ensures that the model converges to a stable optimal policy. The resource scheduling policy selection process is modeled as a Markov decision process, continuously optimizing the evaluation policy through reinforcement learning, thus improving the quality of resource scheduling policy selection. Simultaneously, the reward function is obtained by a weighted sum of SLA achievement rate and resource cost. The weights can be flexibly adjusted according to business needs (e.g., emphasizing SLA or cost), enabling the trained model to adapt to personalized optimization objectives in different scenarios. While ensuring training stability, it allows users to flexibly balance the two optimization objectives, significantly reducing SLA violation rate and resource cost, and outputting a node number and resource queue allocation scheme that meets task requirements and balances SLA and cost.

[0096] S22: Execute the target resource scheduling strategy.

[0097] In this embodiment, the cluster's resources are dynamically adjusted and tasks are scheduled according to the target resource scheduling strategy. The resource adjustment decision in the target resource scheduling strategy is a scaling up / scaling down operation, and the task allocation decision is a queue adjustment operation. Specifically, during the scheduling phase, scaling up, scaling down, and queue adjustment operations are performed according to the target resource scheduling strategy to ensure accurate configuration implementation. The scaling up execution process, scaling down execution process, and queue adjustment execution process are described below: (1) Expansion execution process: Resource application: Call the cloud platform API (e.g., AWSEC2 / ECSAPI) to apply for a specified number of nodes according to the target resource scheduling policy. The node configuration matches the existing nodes in the cluster (e.g., 16 cores 64GB); Node initialization: After the new node starts, the Hadoop client and Agent collection component are automatically installed. It joins the cluster through SSH key authentication and synchronizes the cluster configuration (queue rules, resource scheduling policy); Resource allocation: Register the CPU / memory resources of the new node to YARNResourceManager and allocate them to the target queue (e.g., dedicated queue) according to the target resource scheduling policy, and mark them as "available"; Task scheduling: Assign the tasks to be executed to the new node according to priority (load level or task priority or a combination of load level and task priority) and start the task execution. The entire expansion process takes ≤3 minutes (including node startup and initialization).

[0098] (2) Scaling down execution process: Node screening: According to the principle of "lowest load priority", idle nodes (CPU utilization < 30% and memory utilization < 20%, lasting for 5 minutes) are screened, and nodes with running tasks are excluded; Task migration: If there are low load level tasks (L1-L2) on the screened nodes, the tasks are migrated to other available nodes through YARN's NodeManager API to ensure that the tasks are not interrupted; Safe shutdown: After the migration is completed, the node is removed from the cluster (marked as "unavailable"), the Agent component is stopped, and the node resources are released through the cloud platform API; Resource reclamation: The CPU / memory resources corresponding to the node are reclaimed, the queue resource statistics are updated, and the scaling down process takes ≤ 1 minute.

[0099] Optionally, expansion or reduction execution processes can be verified before execution. Verification is performed only after successful verification. Expansion verification includes, but is not limited to: whether the total number of nodes is less than the maximum number of nodes, whether the expansion cost is less than the maximum expansion cost, and whether the time since the last scheduling operation is greater than the cooldown period. Reduction verification includes, but is not limited to: whether the total number of nodes is less than the minimum number of nodes, screening for nodes that can be taken offline, whether tasks can be migrated, and whether the time since the last scheduling operation is greater than the cooldown period.

[0100] (3) Queue adjustment execution process: Queue creation / adjustment: If the solution requires a dedicated queue, call the YARN API to create a queue (such as "l5_task_queue"), configure the maximum concurrency and resource ratio (such as accounting for +40% of the total cluster resources); Priority update: Adjust the execution priority of tasks through the queue configuration file. Set the execution priority of tasks with load levels of L4-L5 to P1-P2 to ensure resource preemption priority; Task redistribution: Redistribute tasks to be executed according to the new queue rules. Tasks with high load levels are given priority to enter the dedicated queue to avoid resource contention; After execution, the system generates a scheduling execution report, records the operation content, execution results, and time consumption, and stores it in the MongoDB scheduling log table.

[0101] Furthermore, in this embodiment, after executing the target resource scheduling strategy, end-to-end status monitoring is initiated to ensure that the scheduling effect meets expectations. This embodiment provides a possible implementation for end-to-end status monitoring, the specific process of which is as follows: S23: Monitor the resource status and task execution status of the cluster to obtain various second real-time monitoring indicators.

[0102] The second real-time monitoring indicators include: resource gap rate of each task, queue congestion of each queue, SLA compliance rate, and node load balancing.

[0103] In this embodiment of the application, when monitoring the resource status of the cluster, the Agent component collects node resource indicators (CPU / memory usage, disk IO) every 10 seconds, and the queue monitoring module collects queue load (number of tasks to be executed / running) every 5 seconds. The data is stored in InfluxDB. When monitoring the task execution status of the cluster, the task execution progress (e.g., "30% completed"), resource consumption (e.g., "Currently occupying 8 cores and 32GB of memory"), and SLA achievement status (e.g., "Remaining time 1.2 hours, estimated execution time 1.0 hour") are tracked to obtain various second real-time monitoring indicators.

[0104] S24: When one of the second real-time monitoring indicators fails to meet the corresponding effect verification condition, the latest resource status information and the latest task status information to be executed are input into the resource scheduling model, the resource scheduling model outputs the latest resource scheduling strategy, and the latest resource scheduling strategy is executed.

[0105] In this embodiment of the application, when each of the second real-time monitoring indicators meets the corresponding effect verification conditions, the task is completed, node resources are released, and the process ends.

[0106] For example, the effect verification conditions corresponding to each second real-time monitoring indicator are as follows: the resource gap rate of a certain task is ≤ the preset second gap rate threshold (e.g., the second gap rate threshold for a task to be executed with a load level of L4 is 0.4); the queue congestion degree of a certain queue is ≤ the second congestion degree threshold (e.g., the second congestion degree threshold is 1.0, and the queue is running normally); the SLA compliance rate is ≥ the compliance rate threshold (e.g., the compliance rate threshold is 95%); the node load balancing degree is ≤ the second load balancing degree threshold (e.g., the second load balancing degree threshold is 1.0).

[0107] In this way, through real-time monitoring and effect verification, once the scheduling effect is found to be unsatisfactory, a secondary scheduling is immediately triggered, forming a closed loop of "decision-execution-monitoring-re-decision". This enables the scheduling system to self-correct and continuously improve performance. Furthermore, through comprehensive verification indicators, the scheduling results are ensured to meet the overall optimization goals from multiple dimensions, avoiding the deterioration of other aspects due to the optimization of a single indicator.

[0108] Optionally, if the cluster's SLA compliance rate is less than the preset third compliance rate threshold or the resource cost is greater than the preset cost threshold, the configuration requirements of a task to be executed will be redefined based on the task attribute data, the latest historical scheduling data, and the latest resource status information of the task to be executed.

[0109] Furthermore, in this embodiment, after obtaining the effect verification result, the scheduling execution result and monitoring data (each second real-time monitoring indicator) are fed back to the resource scheduling model and the load assessment module to update the parameters of the resource scheduling model and the reward function, as well as update the load level assessment rules, forming a closed-loop optimization, supporting the online learning and continuous evolution of the model, and adapting to long-term load drift.

[0110] For example, the scheduling execution result is that the resource gap rate decreases from 0.7 to 0.3 after expanding by 4 nodes; the PPO algorithm updates the reward function parameters based on feedback data and optimizes the decision logic of the MDP model. For example, if the cost exceeds the budget after expansion, β (cost weight) is adjusted from 0.3 to 0.5; the load assessment module adjusts the feature quantification rules according to the scheduling execution result. For example, the weight coefficient of queue congestion is adjusted from 0.3 to 0.35 to improve the accuracy of assessment; if the scheduling scheme of a certain load level of pending tasks (e.g., expanding L5 load by 16 nodes) continues to meet the target, it is updated to the default configuration template, and subsequent similar tasks can be directly reused to improve scheduling efficiency.

[0111] In summary, the cluster resource scheduling method provided in this application's embodiments formally defines a multi-objective optimization problem that minimizes resource usage costs and SLA violation rates. It models the resource scheduling strategy selection process as a Markov decision process, comprehensively characterizing the cluster resource state and task load state. While ensuring training stability, it allows users to flexibly balance the two optimization objectives, significantly reducing SLA violation rates and resource costs. This solves the core contradiction of traditional scheduling schemes, which struggle to simultaneously address dual-objective optimization and have weak adaptability to dynamic scenarios. It provides an intelligent and flexible task load scheduling solution for scenarios such as cloud-based big data processing.

[0112] Furthermore, based on the same technical concept, embodiments of this application provide a cluster resource scheduling apparatus for implementing the above-described method flow of embodiments of this application. For example, see [link to relevant documentation]. Figure 3 As shown, the cluster resource scheduling device 300 may include: an acquisition module 301, a scheduling strategy determination module 302, a scheduling execution module 303, a training module 304, a load assessment module 305, and a feedback module 306, wherein: The acquisition module 301 is used to acquire the current resource status information and the status information of the tasks to be executed when the resource scheduling triggering conditions are met. The resource scheduling triggering conditions include: the current available resources of the cluster do not meet the configuration requirements of at least one task to be executed, and the configuration requirements of a task to be executed are determined based on the load level of the task to be executed. The scheduling strategy determination module 302 is used to input resource status information and task status information to the resource scheduling model to obtain the target resource scheduling strategy output by the resource scheduling model. The resource scheduling model is obtained by modeling the resource scheduling strategy selection process as a Markov decision process and performing reinforcement learning. The state space of the Markov decision process includes combinations of different resource status information and different task status information, and the action space of the Markov decision process includes various resource scheduling strategies. The reward function of the Markov decision process is composed of SLA achievement rate and resource cost. The scheduling execution module 303 is used to execute the target resource scheduling strategy.

[0113] In an optional embodiment, the resource scheduling triggering condition further includes: The cluster's first real-time monitoring indicator reaches a preset first indicator threshold and / or the cluster's load prediction result status meets the scheduling conditions; wherein, the first real-time monitoring indicator includes at least one of the following: resource gap rate of each task, queue congestion of each queue, and node load balancing.

[0114] In an optional embodiment, when the resource status information and the task status information to be executed are input into the resource scheduling model to obtain the target resource scheduling strategy output by the resource scheduling model, the scheduling strategy determination module 302 is further configured to: Based on resource status information and task status information, the current state is constructed and input into the resource scheduling model, enabling the resource scheduling model to select the target resource scheduling strategy from the action space.

[0115] In an optional embodiment, the resource scheduling model is obtained by training a training module, wherein the training module 304 is used for: A near-end policy optimization algorithm is employed, and the policy network is iteratively trained under a Markov decision process based on a training sample set to obtain a resource scheduling model. During each iteration of training, the following operations are performed: Based on the sample resource status information and sample task status information in the current training sample, determine the sample action corresponding to the current training sample, execute the sample action, obtain the sample SLA achievement rate and sample resource cost corresponding to the sample action, and perform a weighted sum of the sample SLA achievement rate and sample resource cost to obtain the sample reward value corresponding to the sample action. The parameters of the policy network are adjusted based on the sample reward values.

[0116] In an optional embodiment, load assessment module 305: In response to a submission request for a task to be evaluated, the task attribute data of the task to be evaluated, the historical scheduling data of similar tasks to be evaluated, and the resource status information are quantified to obtain a feature dataset. Based on the feature dataset, a multi-dimensional risk assessment is performed to obtain the multi-dimensional risk of the task to be evaluated. Based on the task priority in the multi-dimensional risk and task attribute data, the risk score of the task to be evaluated is determined, and the load level corresponding to the score range to which the risk score belongs is used as the load level of the task to be evaluated. Based on the resource configuration template and task attribute data that match the load level, the configuration requirements of the task to be evaluated are determined, and the task to be evaluated is treated as a task to be executed.

[0117] In one optional embodiment, the multi-dimensional risks include: SLA default risk, resource overload risk, and cost consumption risk. When performing a multi-dimensional risk assessment based on the feature dataset to obtain the multi-dimensional risks of the task to be assessed, the load assessment module is also used for 305: Using a linear regression model based on the feature dataset, the task execution time of the task to be evaluated is estimated, and the risk of SLA default is determined based on the task execution time and SLA deadline. Based on the cluster's resource shortage rate, the queue congestion degree of the task to be evaluated, and the node load balancing degree, the risk of resource overload is determined. Based on the resource requirements of the task to be evaluated and the available resources of a single node, the estimated number of nodes is determined, and based on the estimated number of nodes, the cost per node per unit time, and the task execution duration, the cost consumption risk is obtained.

[0118] In an optional embodiment, the feedback module 306 is used to: The cluster's resource status and task execution status are monitored to obtain various second real-time monitoring indicators, including: resource gap rate of each task, queue congestion of each queue, SLA compliance rate, and node load balancing. When one of the second real-time monitoring indicators fails to meet the corresponding effect verification condition, the latest resource status information and the latest pending task status information are input into the resource scheduling model. The resource scheduling model then outputs the latest resource scheduling strategy and executes it.

[0119] Based on the description of the method and apparatus embodiments above, an exemplary embodiment of the present invention also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, which, when executed by the at least one processor, causes the electronic device to perform a method according to an embodiment of the present invention.

[0120] This application also provides a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of this application.

[0121] This application also provides a computer program product, including a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of this application.

[0122] See Figure 4The diagram shown below illustrates the structure of an electronic device 400 that can serve as a server or client in this application, and is an example of a hardware device that can be applied to various aspects of this application. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0123] like Figure 4 As shown, the electronic device 400 includes a computing unit 401, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 402 or a computer program loaded from a storage unit 408 into a random access memory (RAM) 403. The RAM 403 may also store various programs and data required for the operation of the device 400. The computing unit 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0124] Multiple components in electronic device 400 are connected to I / O interface 405, including: input unit 406, output unit 407, storage unit 408, and communication unit 409. Input unit 406 can be any type of device capable of inputting information to electronic device 400. Input unit 406 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device. Output unit 407 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 408 may include, but is not limited to, disks and optical discs. Communication unit 409 allows electronic device 400 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers and / or chipsets, such as Bluetooth devices, WiFi devices, worldwide interoperability for microwave access (WiMax) devices, cellular communication devices, and / or the like.

[0125] The computing unit 401 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 401 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 401 performs the various methods and processes described above. For example, in some embodiments, the above-described cluster resource scheduling method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 408. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 400 via ROM 402 and / or communication unit 409. In some embodiments, the computing unit 401 can be configured to perform the above-described cluster resource scheduling method by any other suitable means (e.g., by means of firmware).

[0126] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0127] In the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM) or flash memory, optical fibers, compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0128] As used in this application, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device, PLD) used to provide machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0129] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0130] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0131] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other.

[0132] Furthermore, it should be understood that the above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of the invention. Therefore, any equivalent variations made in accordance with the claims of this invention are still within the scope of this application.

Claims

1. A cluster resource scheduling method, characterized in that, include: When the resource scheduling triggering condition is met, the current resource status information and the status information of the tasks to be executed are obtained. The resource scheduling triggering condition includes: the current available resources of the cluster do not meet the configuration requirements of at least one task to be executed. The configuration requirements of a task to be executed are determined based on the load level of the task to be executed. The resource status information and the task status information to be executed are input into the resource scheduling model to obtain the target resource scheduling strategy output by the resource scheduling model. The resource scheduling model is obtained by modeling the resource scheduling strategy selection process as a Markov decision process and performing reinforcement learning. The state space of the Markov decision process includes combinations of different resource status information and different task status information to be executed. The action space of the Markov decision process includes various resource scheduling strategies. The reward function of the Markov decision process is composed of SLA achievement rate and resource cost. Execute the target resource scheduling strategy.

2. The method as described in claim 1, characterized in that, The resource scheduling triggering conditions also include: The first real-time monitoring indicator of the cluster reaches a preset first indicator threshold and / or the load prediction result of the cluster reaches the scheduling condition; wherein, the first real-time monitoring indicator includes at least one of the following: resource gap rate of each task, queue congestion of each queue and node load balancing.

3. The method as described in claim 1, characterized in that, The step of inputting the resource status information and the task status information to be executed into the resource scheduling model to obtain the target resource scheduling strategy output by the resource scheduling model includes: Based on the resource status information and the task status information to be executed, a current state is constructed, and the current state is input into the resource scheduling model, so that the resource scheduling model selects a target resource scheduling strategy from the action space.

4. The method as described in claim 1, characterized in that, The resource scheduling model was trained using the following method: A near-end policy optimization algorithm is employed, and the policy network is iteratively trained under the Markov decision process based on the training sample set to obtain a resource scheduling model; wherein, during one iteration of training, the following operations are performed: Based on the sample resource status information and sample task status information in the current training sample, determine the sample action corresponding to the current training sample, execute the sample action, obtain the sample SLA achievement rate and sample resource cost corresponding to the sample action, and perform a weighted sum of the sample SLA achievement rate and the sample resource cost to obtain the sample reward value corresponding to the sample action. The parameters of the policy network are adjusted based on the sample reward value.

5. The method as described in claim 1, characterized in that, The method further includes: In response to a submission request for a task to be evaluated, the task attribute data of the task to be evaluated, the historical scheduling data of similar tasks of the task to be evaluated, and the resource status information are quantified to obtain a feature dataset. Based on the feature dataset, a multi-dimensional risk assessment is performed to obtain the multi-dimensional risk of the task to be evaluated. Based on the multi-dimensional risks and the task priorities in the task attribute data, the risk score of the task to be evaluated is determined, and the load level corresponding to the score range to which the risk score belongs is taken as the load level of the task to be evaluated. Based on the resource configuration template matching the load level and the task attribute data, the configuration requirements of the task to be evaluated are determined, and the task to be evaluated is set as a task to be executed.

6. The method as described in claim 5, characterized in that, The multi-dimensional risks include: SLA default risk, resource overload risk, and cost consumption risk. Therefore, the multi-dimensional risk assessment based on the feature dataset yields the multi-dimensional risks of the task to be assessed, including: Using a linear regression model, based on the feature dataset, the task execution time of the task to be evaluated is estimated, and based on the task execution time and the SLA deadline, the risk of SLA default is determined. Based on the resource shortage rate of the cluster, the queue congestion degree and node load balancing degree of the task to be evaluated, the resource overload risk is determined; Based on the resource requirements of the task to be evaluated and the available resources of a single node, the estimated number of nodes is determined, and based on the estimated number of nodes, the unit time node cost, and the task execution duration, the cost consumption risk is obtained.

7. The method as described in claim 1, characterized in that, After executing the target resource scheduling policy, the method further includes: The resource status and task execution status of the cluster are monitored to obtain various second real-time monitoring indicators, including: resource gap rate of each task, queue congestion of each queue, SLA compliance rate, and node load balancing. When one of the second real-time monitoring indicators fails to meet the corresponding effect verification condition, the latest resource status information and the latest task status information to be executed are input into the resource scheduling model, and the resource scheduling model outputs the latest resource scheduling strategy and executes the latest resource scheduling strategy.

8. A cluster resource scheduling device, characterized in that, include: The acquisition module is used to acquire the current resource status information and the status information of tasks to be executed in the cluster when the resource scheduling triggering conditions are met. The resource scheduling triggering conditions include: the current available resources of the cluster do not meet the configuration requirements of at least one task to be executed, and the configuration requirements of a task to be executed are determined based on the load level of the task to be executed. The scheduling strategy determination module is used to input the resource status information and the task status information to be executed into the resource scheduling model to obtain the target resource scheduling strategy output by the resource scheduling model. The resource scheduling model is obtained by modeling the resource scheduling strategy selection process as a Markov decision process and performing reinforcement learning. The state space of the Markov decision process includes combinations of different resource status information and different task status information to be executed. The action space of the Markov decision process includes various resource scheduling strategies. The reward function of the Markov decision process is composed of the SLA achievement rate and resource cost. The scheduling execution module is used to execute the target resource scheduling strategy.

9. An electronic device, characterized in that, include: processor; as well as Stored program memory, The program includes instructions that, when executed by the processor, cause the processor to perform the method as described in any one of claims 1-7.

10. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-7.

Images