A resource scheduling method, system, electronic device and medium

Abstract

The application discloses a resource scheduling method, system, electronic equipment and medium, and relates to the technical field of computers. The method first acquires each online model group in a Flink task; then acquires current running information of each online model group and historical running information corresponding to each online model group; and finally schedules resources according to the current running information of each online model group and the historical running information corresponding to each online model group. In the method, the change rule of the load can be acquired through the historical information of each model group, so that the reasonable scheduling of the resources can be realized according to the change rule of the load and the current running information. In addition, the application also provides a resource scheduling system, an electronic equipment and a computer readable storage medium, which correspond to the above-mentioned resource scheduling method and have the same effects.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a resource scheduling method and system, electronic device and medium. BACKGROUND

[0002] In the process of Flink task running, a fixed number of cores and memory are usually allocated to each model group to process the load input of the model group. However, load fluctuations are generally universal. A too low allocation scheme may cause a large number of accumulations in the model group, and each piece of data cannot be consumed in time. A too high allocation scheme may not cause accumulation, but may cause resource waste and increase the running cost.

[0003] Therefore, how to find a more appropriate resource allocation scheme is a problem to be solved by those skilled in the art. SUMMARY

[0004] The present application aims to provide a resource scheduling method, system, electronic device and medium for more reasonable allocation of resources.

[0005] To solve the above technical problems, the present application provides a resource scheduling method, comprising:

[0006] obtaining each online model group in a Flink task;

[0007] obtaining current running information of each online model group and historical running information corresponding to each online model group;

[0008] scheduling resources according to the current running information of each online model group and the historical running information corresponding to each online model group.

[0009] Preferably, the obtaining each online model group in a Flink task comprises:

[0010] in the case where there is no model group with abnormal offline or abnormal restart, obtaining each online model group;

[0011] in the case where there is a model group with abnormal offline or abnormal restart, scanning abnormal logs and obtaining abnormal log information;

[0012] determining memory occupation according to the abnormal log information;

[0013] if the memory meets a preset requirement, bringing online the model group with abnormal offline and obtaining each online model group;

[0014] if the memory does not meet the preset requirement, increasing the memory, and returning to the step of determining memory occupation according to the abnormal log information.

[0015] Preferably, the scheduling of the resources according to the current running information of each of the online model groups and the corresponding historical running information of each of the online model groups comprises:

[0016] performing binary classification on the corresponding historical running information of each of the online model groups and the current running information of each of the online model groups by using a machine learning model so as to determine an adjustment strategy of each of the online model groups; the adjustment strategy comprises increasing resources or reducing resources;

[0017] determining an adjustment step of each of the online model groups by fitting the current running information of each of the online model groups through a plurality of curve fitting methods;

[0018] scheduling the resources of each of the online model groups according to the adjustment step and the adjustment strategy.

[0019] Preferably, the scheduling of the resources of each of the online model groups according to the adjustment step and the adjustment strategy comprises:

[0020] obtaining an unstable model group in the online model groups;

[0021] offline the unstable model group;

[0022] scheduling the resources of the unstable model group according to the adjustment step and the adjustment strategy.

[0023] Preferably, before the scheduling of the resources of the unstable model group according to the adjustment step and the adjustment strategy, further comprising:

[0024] if the adjustment step and the adjustment strategy meet the configurable resources of the system, then entering the step of scheduling the resources of the unstable model group according to the adjustment step and the adjustment strategy;

[0025] if the adjustment step and the adjustment strategy do not meet the configurable resources of the system, then entering a step of performing global resource allocation according to the priority, the accumulation amount, and the input speed of the corresponding model group.

[0026] Preferably, after the obtaining of the current running information of each of the online model groups and the corresponding historical running information of each of the online model groups, further comprising:

[0027] if the online model group is stable, then judging the delay parameter, the processing speed, and the stability of the online model group;

[0028] If the delay parameter, the processing speed and the online model group stability of the online model groups meet corresponding preset requirements, the running data of the scheduled online model groups is stored.

[0029] Preferably, the preset requirements met by the delay parameter include that the average of the data delay processing time of each online model group is less than a threshold value.

[0030] The preset requirements met by the processing speed include that the average processing speed of each online model group within a first preset time is less than a preset multiple of the maximum processing speed of each online model group.

[0031] The preset requirements met by the stability of the online model groups include that the number of restarts of each online model group within a second preset time is less than a preset value.

[0032] Preferably, obtaining the corresponding historical running information of each online model group includes:

[0033] Obtaining the historical running information of each model group in the Flink task;

[0034] Obtaining the corresponding historical running information of each online model group from the historical running information of each model group.

[0035] To solve the above technical problems, the present application also provides a resource scheduling system, comprising:

[0036] A first obtaining module is configured to obtain each online model group in a Flink task;

[0037] A second obtaining module is configured to obtain the current running information of each online model group and the corresponding historical running information of each online model group;

[0038] A scheduling module is configured to schedule resources according to the current running information of each online model group and the corresponding historical running information of each online model group.

[0039] To solve the above technical problems, the present application also provides an electronic device, comprising:

[0040] A memory is configured to store a computer program;

[0041] A processor is configured to execute the computer program to implement the steps of the above-mentioned resource scheduling method.

[0042] To solve the above technical problems, the present application also provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the steps of the above-mentioned resource scheduling method.

[0043] The method for resource scheduling provided in the application first acquires each online model group in a Flink task; then acquires current running information of each online model group and historical running information corresponding to each online model group; and finally schedules resources according to the current running information of each online model group and the historical running information corresponding to each online model group. In the method, the change rule of the load can be acquired through the historical information of each model group, so that the resources can be reasonably scheduled according to the change rule of the load and the current running information.

[0044] In addition, the application further provides a system for resource scheduling, an electronic device and a computer readable storage medium, which correspond to the method for resource scheduling mentioned above and have the same effects. BRIEF DESCRIPTION OF DRAWINGS

[0045] In order to more clearly illustrate the embodiments of the application, the drawings needed in the embodiments will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor.

[0046] Figure 1 A flow chart of a method for resource scheduling provided by the application;

[0047] Figure 2 A structural diagram of a system for resource scheduling provided by an embodiment of the application;

[0048] Figure 3 A structural diagram of an electronic device provided by another embodiment of the application;

[0049] Figure 4 An application scenario schematic diagram of the method for resource scheduling provided by the embodiments of the application. DETAILED DESCRIPTION

[0050] The technical solutions in the embodiments of the application will be described clearly and completely in combination with the drawings in the embodiments of the application. Obviously, the described embodiments are only some of the embodiments of the application, not all the embodiments. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative labor are within the protection scope of the application.

[0051] The core of the application is to provide a method, system, electronic device and medium for resource scheduling, for realizing reasonable scheduling of resources.

[0052] For the convenience of understanding, the hardware structure used in the technical solution of the present application is introduced below. The hardware architecture of the resource scheduling method provided by the present application mainly includes a central processing unit (CPU) and a memory. The number of CUP cores, i.e., how many cores a CPU is composed of, the more the number of cores, the faster the running speed of the CPU and the better the performance. The running of the memory also determines the degree of the overall running speed of the computer. When performing resource allocation, the number of CPU cores and the memory are the basic units of resource allocation, representing the number of CPU cores and the memory used by the model group that can be called.

[0053] In order to enable personnel in the technical field to better understand the present application scheme, the present application is further described in detail below in combination with the drawings and specific embodiments. Figure 1 A flowchart of a resource scheduling method provided by the present application is shown in FIG. 1. Figure 1 As shown in the figure, the method comprises:

[0054] S10: Obtain each online model group in the Flink task.

[0055] Apache Flink is a distributed open source computing framework for data stream processing and batch data processing. It is based on the same Flink streaming execution model and can support both stream processing and batch processing application types. The Flink task implemented by the user is composed of two basic building blocks, Stream and Transformation. Stream is an intermediate result data, and Transformation is an operation that calculates and processes one or more input Streams and outputs one or more result Streams. A Flink task usually contains multiple model groups, which are objects of resource allocation. A model group can contain multiple workflows. In general, workflows that process the same topic or the same type of topic are grouped into the same model group. When a Flink task is executed, it is mapped to a Workflow. A Workflow is composed of a group of Streams and Operators, which is similar to a directed graph. It starts from one or more Source Operators and ends with one or more Sink Operators. The basic unit of model group allocation is the number of cores and memory, representing the number of CPU cores that can be called by the model group and the memory used. In general, the memory is equal to twice the number of cores minus one. If the number of model group workflows is too large, it will be increased to three times or four times. According to the running state of the model group, the model group can be divided into online model group and offline model group.

[0056] When retrieving online model groups in a Flink task, you can query all model groups for any abnormal offline or abnormal restarts. If such a situation occurs, the runtime logs of that model group will be scanned to determine the cause of the problem, propose a corresponding solution, and then re-launch the abnormal offline or abnormal restart model group. Finally, all online model groups in the Flink task will be retrieved. If no abnormal offline or abnormal restart model groups are found, all online model groups in the Flink task will be retrieved directly.

[0057] S11: Obtain the current running information of each online model group and the corresponding historical running information of each online model group.

[0058] Currently, during Flink task execution, a fixed number of cores and memory are typically allocated to each model group to handle its load input. However, load fluctuations are common, often leading to resource shortages or surpluses, meaning resources cannot be allocated rationally. This application analyzes the load variation patterns through historical execution information of online model groups, enabling more reasonable resource allocation. Based on the steps described above for obtaining information on each online model group in a Flink task, the execution information of each online model group is collected and processed to understand its historical execution information. The historical execution information (also known as metadata) of each online model group includes: input rate, backlog rate, backlog amount, processing rate, processing volume, current offset, final offset, operator type, number of operators, workflow type, number of workflows, etc.

[0059] When acquiring historical operational information for each online model group, the first step is to match and filter metrics for Flink, Kafka, and MySQL. Kafka is a distributed message queue. The message sender is called the Producer, and the message receiver is called the Consumer. Furthermore, a Kafka cluster consists of multiple Kafka instances, each instance (server) is called a broker. Both the Kafka cluster and the consumer rely on a ZooKeeper cluster to store metadata to ensure system availability. MySQL is the most popular relational database management system, and in web applications, MySQL is one of the best Relational Database Management System (RDBMS) applications. During matching, Flink, Kafka, and MySQL metrics are matched based on the task ID; during filtering, metrics can be collected based on the importance of the model group. Then, metrics are collected from Flink, Kafka, and MySQL. Metrics can be collected at a fixed frequency or a non-fixed frequency; the frequency is not limited here. In implementation, to more accurately obtain the load variation pattern, a fixed frequency of metric collection is chosen, without specifying the exact value of the fixed frequency. It should be noted that the collected metrics are relatively simple and do not require calculation, such as current offset and final offset. After collecting the metrics, they are written to a single file; the file format is not limited, and a .txt file is acceptable. This file is read into a directly usable feature format, such as pandas.DataFrame, and new metrics such as input rate, processing rate, and stacking rate are constructed based on these metrics. For example, processing rate = (final offset - current offset) / collection interval. Finally, the historical running information of each online model group is output. It should be noted that the method of obtaining the historical information of each online model group is not limited; it can be done by directly obtaining the historical running information of each online model group, or by obtaining the historical running information of all model groups and then querying the historical running information of the online model groups from the historical running information of all model groups, etc.

[0060] Obtaining the current running information of each online model group also includes input rate, accumulation rate, accumulation amount, processing rate, processing amount, current offset, final offset, operator type, number of operators, workflow type, number of workflows, etc.

[0061] S12: Schedule resources based on the current operating information of each online model group and the corresponding historical operating information of each online model group.

[0062] The above steps obtain the current operating information and corresponding historical operating information of each online model group. Then, a machine learning model is used to perform binary classification to determine the adjustment strategy of the model group, i.e., increase or decrease. The adjustment step size of the model group is determined by multiple curve fitting methods, i.e., the step size for increasing or decreasing, thereby realizing resource scheduling. It should be noted that after determining the adjustment strategy and step size, it is necessary to determine whether the adjustment strategy and step size meet the system's configurable resources. If not, global resource allocation is performed to ensure the stability of critical business flows. If the system's configurable resources are still not met after global allocation, the platform's alarm application programming interface (API) is invoked.

[0063] The resource scheduling method provided in this embodiment first obtains the online model groups in the Flink task; then, it obtains the current running information and historical running information of each online model group; finally, it schedules resources based on the current running information and historical running information of each online model group. In this method, since the load variation pattern can be obtained through the historical information of each model group, reasonable resource scheduling can be achieved based on the load variation pattern and the current running information.

[0064] In implementation, model groups that are abnormally offline or restarted often exist. When adjusting resources, if there are abnormally offline model groups, the resources previously allocated to them will remain unused. If there are a large number of abnormally offline model groups, this can lead to significant resource waste. If there are abnormally restarted model groups, resources will not have been allocated to them previously, resulting in a large backlog of data and preventing timely consumption of each piece of data. Therefore, in implementation, the first step is to determine if there are abnormally offline or restarted model groups. If so, these abnormal model groups are brought back online. Specifically, the online model groups in the Flink task include:

[0065] If no abnormal offline or abnormal restart model groups exist, obtain each online model group;

[0066] In the case of model groups that are abnormally offline or abnormally restarted, scan the exception logs and obtain the exception log information;

[0067] Determine memory usage based on the exception log information;

[0068] If the memory meets the preset requirements, then the abnormally offline model groups will be launched online and each online model group will be retrieved.

[0069] If the memory does not meet the preset requirements, increase the memory and return to the step of determining the memory usage based on the exception log information.

[0070] Each model group has a corresponding status database. The database is queried to check for any abnormally offline or restarted model groups. If none are found, all online model groups (i.e., all running model groups) are queried directly. If they are found, an exception log is scanned, and memory usage is determined based on the log information. If memory meets preset requirements, the abnormally offline model group is brought online, and all online model groups are retrieved. If memory does not meet preset requirements, memory is increased, and the process returns to the step of determining memory usage based on the exception log information. It should be noted that meeting preset requirements here means the memory size is sufficient for the operation of each model group. When specific strings appear in the log information, it indicates that the abnormal offline or restart was caused by insufficient memory. For exceptions caused by insufficient memory, workmemory is increased, the abnormal model group is brought online, and finally, all online model groups are queried. It should be noted that after increasing workmemory, the log information can be used to further determine if memory usage is sufficient. If not, workmemory can be increased multiple times to ensure sufficient memory. For exceptions not caused by insufficient memory, the model group is brought online directly, and all online model groups are queried. In implementation, if bringing a model group online fails, it can be repeated. There is no limit to the number of times a model can be re-uploaded. If the number of re-uploads is set to three, and the model still fails to go online after three attempts, then there is no need to re-upload the model group.

[0071] This embodiment takes into account model groups that have gone offline or restarted abnormally when acquiring online model groups in a Flink task. It acquires online model groups after bringing them online, thus ensuring that resource allocation and scheduling of model groups are performed as stably as possible, making resource scheduling more reasonable.

[0072] In implementation, to accurately schedule resources based on the current operating information of the online model groups and their historical operating information, a preferred embodiment includes scheduling resources based on the current operating information and corresponding historical operating information of each online model group, which includes:

[0073] Machine learning models are used to perform binary classification on the historical and current operating information of each online model group in order to determine the adjustment strategy for each online model group; the adjustment strategy includes increasing or decreasing resources.

[0074] The adjustment step size of each online model group is determined by fitting the current operating information of each online model group using multiple curve fitting methods.

[0075] Resources for each online model group are scheduled according to the adjustment step size and adjustment strategy.

[0076] When using a machine learning model to perform binary classification, the specific steps include:

[0077] (1) Extract the corresponding features from the metadata collected in the above steps. Since the metadata is collected at certain time intervals, it is equivalent to a time series. The corresponding features are extracted from the entire time series using a sliding window method. The features include the minimum, maximum, average and variance of input rate, processing rate, stacking rate, etc.

[0078] (2) Label the extracted feature data. The label indicates whether it is an increase or a decrease.

[0079] (3) Perform some feature engineering. Since the maximum and minimum values ​​collected are too simple for the model, feature engineering is used to combine simple features to construct higher-order features, such as cross features and data discretization.

[0080] (4) Use the LightGBM algorithm to calculate the importance of each feature and complete the feature selection.

[0081] (5) Use the above algorithm again to complete the training of the model. Input the previously collected data into the model to determine whether the model group should increase or decrease resources.

[0082] It should be noted that this embodiment uses the LightGBM algorithm to train the model. In practice, other algorithms can also be used to train the model. The specific algorithm used is not limited here.

[0083] The specific steps for determining the adjustment step size using multiple curve fitting methods are as follows:

[0084] (1) Fit multiple curves based on metadata;

[0085] (2) Select the curve with the highest correlation coefficient;

[0086] (3) Determine the number of kernels to be allocated based on the current input speed and the curve with the highest correlation coefficient obtained from the fitting.

[0087] After collecting and storing the metadata, we can determine the processing speed under various conditions. Based on the current input speed and the curve fitted from all the metadata, we can determine the allocated number of cores. If the model group's processing speed is less than the input speed, then the model group needs more resources. Increasing resources means increasing the processing speed, which requires increasing the number of cores. For example, based on the model group's historical operating information, we know that the processing speed with 2 cores is 1000, and with 3 cores it's 2000. By analyzing the curve with the highest correlation coefficient for different core counts, we can estimate the processing speed for other core counts. Then, we can allocate an appropriate number of cores to the model group based on the processing speed and the current input speed. For instance, if the processing speed with 4 cores is calculated to be 3000 based on the data from 2 and 3 cores, and the current input speed is 2900, then allocating 4 cores to the model group will satisfy the condition that the processing speed is greater than the input speed, thus reducing resource overload.

[0088] This embodiment utilizes a machine learning model and a multi-curve fitting method to adjust the resources of the model group. Based on the historical operating data of the model group, the load change pattern is derived, thereby enabling reasonable resource scheduling based on the load change pattern and current operating information.

[0089] In implementation, to improve the speed of resource adjustment for all model groups, as a preferred implementation method, resource scheduling is only performed on unstable model groups. Therefore, resource scheduling for each online model group according to the adjustment step size and adjustment strategy includes:

[0090] Retrieve unstable model groups from online model groups;

[0091] Unstable model groups offline;

[0092] Resources for unstable model groups are scheduled based on adjustment step size and adjustment strategy.

[0093] In implementation, the stability of the model group can be determined from the following aspects:

[0094] (1) Based on the results of historical allocation; if the model group has been adjusted multiple times in the historical allocation, it indicates that the model group is unstable, otherwise it is stable.

[0095] (2) Based on the maximum processing speed. If the current maximum processing speed drops below the input rate, it will cause backlog. Therefore, no resource adjustment is needed for the model group, indicating that the model group is stable.

[0096] (3) The model set is processing a large amount of accumulation. The model set is considered stable even when it is processing a large amount of accumulation.

[0097] (4) The processing speed is slightly greater than the input rate. When the processing speed is slightly greater than the input rate, it indicates that the model group will not accumulate, and the model group is considered stable. Otherwise, the model group is considered unstable.

[0098] (5) The input rate is approximately equal to the maximum processing speed. When the input rate is approximately equal to the maximum processing speed, it also indicates that the model group will not accumulate and the model group is stable. Conversely, the model group is considered unstable.

[0099] The above steps determine whether the model group is stable. In implementation, to reduce CPU usage, resource scheduling is only performed on unstable model groups. For example, if the adjustment strategy and adjustment step size determine that model group A needs increased resources, while model groups B and C need decreased resources, and assuming model group A is unstable while model groups B and C are stable, only model group A needs increased resources, while model groups B and C do not need decreased resources.

[0100] The method provided in this embodiment, which adjusts resources only for unstable model groups, can more quickly adjust the resources of all model groups and reduce CPU usage compared to adjusting resources for both stable and unstable model groups.

[0101] In implementation, the adjustment strategy and adjustment step size may fail to meet the system's configurable resources, resulting in ineffective adjustments to the model group resources. Therefore, a preferred implementation method includes, before scheduling the resources of the unstable model group according to the adjustment step size and adjustment strategy, the following steps:

[0102] If the adjustment step size and adjustment strategy meet the configurable resources of the system, then proceed to the step of scheduling the resources of the unstable model group according to the adjustment step size and adjustment strategy.

[0103] If adjusting the step size and strategy does not meet the system's configurable resources, then the process proceeds to the step of allocating global resources based on the priority, backlog, and input speed of the corresponding model group.

[0104] Before scheduling unstable resources based on adjustment step size and adjustment strategy, it is first determined whether the adjustment strategy and adjustment step size meet the system's configurable resources. If they do not exceed the system's configurable resources, unstable resources can be scheduled directly according to the adjustment step size and adjustment strategy. If they exceed the system's configurable resources, global resource allocation is performed. During global resource allocation, resources can be configured based on model group priority, backlog, input speed, etc. Model group priority is user-defined; certain model groups that must run can be considered high-priority model groups. When resources are insufficient but backlog is high, resources need to be added to the model group. However, if adding resources exceeds the system's configurable resources, resources can be allocated based on the model group priority. In implementation, global resource allocation can be performed based on any one or two of the three factors: model group priority, backlog, and input speed, or all three factors combined. To improve the accuracy of global resource allocation, it is preferable to allocate global resources based on all three factors. If the system's configurable resources are still not met after global resource allocation, the platform's alarm API is invoked.

[0105] The present embodiment provides a method to determine whether the adjustment strategy and adjustment step size meet the system's configurable resources before scheduling unstable resources according to the adjustment step size and adjustment strategy. This can effectively prevent the adjustment of model group resources from being ineffective and ensure the stability of critical business flows according to the global resource allocation scheme.

[0106] In the above embodiments, resource scheduling is performed for unstable model groups, but not for stable model groups. However, resource allocation may be unreasonable in stable model groups, therefore further judgment of the model group's operating status is needed. In implementation, after obtaining the current operating information and historical operating information of each online model group, the following steps are also included:

[0107] Assuming the online model group is stable, the assessment includes evaluating its latency parameters, processing speed, and overall stability.

[0108] If the latency parameters, processing speed, and stability of the online model group meet the corresponding preset requirements, then the running data of each online model group after scheduling is stored.

[0109] The above embodiments have described how to determine the stability of online model groups, which will not be repeated here. Determining the stability of online model groups includes assessing the stability of stable model groups identified before scheduling resources for unstable model groups, and also assessing the stability of all model groups after scheduling resources for unstable model groups. When online model groups are stable, the system assesses their latency parameters, processing speed, and overall stability. These three indicators describe the operational status of the model groups. Latency parameters reflect the timeliness of data processing, processing speed reflects the rationality of resource allocation, and model group stability means that frequent starting and stopping of the model groups will not cause data loss and processing speed instability. If the latency parameters, processing speed, and stability of the online model groups meet the corresponding preset requirements, the operational data of each online model group after scheduling is stored. The preset requirements for each indicator are not limited; reasonable preset requirements can be set according to actual conditions.

[0110] This embodiment, after acquiring the current operating information and corresponding historical operating information of each online model group, further assesses the latency parameters, processing speed, and stability of the online model groups, assuming the online model groups are stable. If the latency parameters, processing speed, and stability of the online model groups meet the corresponding preset requirements, the operating data of each online model group after scheduling is stored. Through the method provided in this embodiment, the rationality of the model group's resources can be further determined based on indicators reflecting the operating status of the model group, and the operating data is stored as historical operating data, resulting in a more comprehensive understanding of the patterns of load changes, thereby enabling reasonable resource scheduling based on load changes.

[0111] In the above embodiments, there are no restrictions on the preset conditions for the delay parameters, processing speed, and stability of the online model group. In practice, preferably, the preset requirements for the delay parameters include: the average data delay processing time of each online model group is less than a threshold.

[0112] The preset requirements for processing speed include: the average processing speed of each online model group is less than a preset multiple of the maximum processing speed of each online model group within a first preset time period;

[0113] The stability of the online model group meets the preset requirements, including that the number of times each online model group restarts within a second preset time period is less than a preset value.

[0114] In implementation, for the delay parameter, it is determined whether the average data delay processing time of all model groups is within N hours (N can be adjusted). According to formula (1), it is calculated whether the current backlog of data can be consumed within N hours in a scenario of continuous data inflow. The formula for calculating the consumption time of the backlog of each model group is shown in formula (1):

[0115]

[0116] In the above formula (1), L i Let represent the mean accumulation amount of the i-th model group within time Δt. Let represent the average processing speed of the i-th model group within time Δt. This represents the average load input speed of the i-th model group within the time interval Δt. The specific value of Δt is not limited.

[0117] The requirement for processing speed is that the average processing speed of the model group over a time interval Δt during operation cannot exceed a preset multiple of the maximum processing speed of the model group (based on the current configuration's upper limit of processing capacity). The specific values ​​of the first preset time and the preset multiple are not limited; appropriate values ​​for the first preset time and the preset multiple should be selected based on the actual situation.

[0118] The stability requirement for model groups is that the number of restarts for each online model group is less than a preset value within a second preset time period. The setting of the second preset time and preset value is not limited and can be determined based on the actual situation. For example, if a model group restarts no more than twice within three days, it is considered stable; if it restarts more than twice, it is considered unstable. It should be noted that the stability indicator used to judge the operational status of a model group differs from the stability determination mentioned above, and the criteria for judgment are also different.

[0119] It should be noted that, in implementation, the operating status of the model group can be determined based on any one or two of the three indicators: latency parameter, processing speed, and stability of the online model group, or a combination of all three indicators. For a more accurate assessment of the model group's operating status, it is preferable to determine it based on a combination of these three indicators.

[0120] This embodiment provides a method to further determine whether the resources of a model group are reasonable based on latency parameters, processing speed, and the stability of the online model group, thereby enabling timely scheduling of model groups with unreasonable resource allocation.

[0121] To quickly obtain historical operational information for online model groups and improve resource scheduling time, the implementation process includes obtaining the following historical operational information for each online model group:

[0122] Obtain historical execution information for each model group in a Flink task;

[0123] Obtain the historical operation information corresponding to each online model group from the historical operation information of each model group.

[0124] When resource scheduling is required, the historical execution information of each model group in the Flink task is stored in the database. When the historical execution information of an online model group needs to be retrieved, it can be obtained directly from the database. Since historical execution data is collected as metadata at regular intervals, if the historical execution information corresponding to each online model group is not saved in advance, it is impossible to allocate reasonable resources to the model group in a timely manner based on the current input speed. Secondly, online model groups may be added. If an online model group is not included in the historical execution information, it is impossible to analyze resource scheduling for that model group in a timely manner. However, by obtaining the historical execution information of each model group in the Flink task in advance, even if an online model group is added, the historical execution information corresponding to the added online model group can be found from the historical execution information of the existing model groups.

[0125] This embodiment provides a method for obtaining historical running information of each model group in a Flink task; and for obtaining historical running information of each online model group from the historical running information of each model group. Since the historical running information of the online model group is included in the historical running information of each model group obtained in advance, the historical running information of the online model group can be obtained quickly, thus improving the time for resource scheduling.

[0126] In the above embodiments, the resource scheduling method has been described in detail. This application also provides embodiments of resource scheduling systems and electronic devices. It should be noted that this application describes the embodiments of the device part from two perspectives: one is based on functional modules, and the other is based on hardware.

[0127] Figure 2 This application provides a structural diagram of a resource scheduling system according to an embodiment of the present application. This embodiment, based on functional modules, includes:

[0128] The first acquisition module 10 is used to acquire each online model group in the Flink task;

[0129] The second acquisition module 11 is used to acquire the current running information of each online model group and the historical running information corresponding to each online model group;

[0130] The scheduling module 12 is used to schedule resources based on the current running information of each online model group and the corresponding historical running information of each online model group.

[0131] Since the embodiments of the apparatus and the embodiments of the method correspond to each other, please refer to the description of the embodiments of the method for the embodiments of the apparatus, which will not be repeated here.

[0132] The resource scheduling system provided in this embodiment first acquires the online model groups in the Flink task through a first acquisition module. Then, it acquires the current running information and historical running information of each online model group through a second acquisition module. Finally, the scheduling module schedules resources based on the current running information and historical running information of each online model group. In this system, since the load variation pattern can be obtained through the historical information of each model group, reasonable resource scheduling can be achieved based on the load variation pattern and the current running information.

[0133] Figure 3 This is a structural diagram of an electronic device provided in another embodiment of this application. This embodiment is based on a hardware perspective, such as... Figure 3 As shown, the electronic device includes:

[0134] Memory 20 is used to store computer programs;

[0135] The processor 21 is configured to implement the steps of the resource scheduling method as described in the above embodiments when executing a computer program.

[0136] The electronic devices provided in this embodiment may include, but are not limited to, smartphones, tablets, laptops, or desktop computers.

[0137] The processor 21 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 21 may be implemented using at least one of the following hardware forms: Digital Signal Processor (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 21 may also include a main processor and a coprocessor. The main processor, also known as the CPU, is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 21 may also include an Artificial Intelligence (AI) processor, which is used to handle computational operations related to machine learning.

[0138] The memory 20 may include one or more computer-readable storage media, which may be non-transitory. The memory 20 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 20 is used to store at least the following computer program 201, which, after being loaded and executed by the processor 21, is capable of implementing the relevant steps of the resource scheduling method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 20 may also include an operating system 202 and data 203, and the storage method may be temporary or permanent storage. The operating system 202 may include Windows, Unix, Linux, etc. The data 203 may include, but is not limited to, the data involved in the resource scheduling method mentioned above.

[0139] In some embodiments, the electronic device may further include a display screen 22, an input / output interface 23, a communication interface 24, a power supply 25, and a communication bus 26.

[0140] Those skilled in the art will understand that Figure 3 The structures shown do not constitute a limitation on electronic devices and may include more or fewer components than those shown.

[0141] The electronic device provided in this application includes a memory and a processor. When the processor executes a program stored in the memory, it can implement the following method: a resource scheduling method, with the same effect as above.

[0142] Finally, this application also provides an embodiment corresponding to a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps described in the above method embodiments.

[0143] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0144] The computer-readable storage medium provided in this application includes the resource scheduling method mentioned above, with the same effect.

[0145] To enable those skilled in the art to better understand the technical solution of this application, the following description is provided in conjunction with the appendix. Figure 4 This application will now provide a more detailed description of the above. Figure 4 This is a schematic diagram illustrating an application scenario of the resource scheduling method provided in this application embodiment. The process includes:

[0146] S13: Automated indicator collection and processing;

[0147] S14: Model group runtime data;

[0148] S15: Check if there are any abnormal offline or abnormal restart model groups; if yes, proceed to step S16; otherwise, proceed to step S20.

[0149] S16: Exception log scan;

[0150] S17: Determine if there is insufficient memory. If yes, proceed to step S18; otherwise, proceed to step S19.

[0151] S18: Add workmemory;

[0152] S19: Online model group;

[0153] S20: Query all online model groups;

[0154] S21: Read the historical running data of the model group;

[0155] S22: A model for automated resource allocation;

[0156] S23: Output allocation scheme;

[0157] S24: Determine whether the model group is stable; if not, proceed to steps S25 to S28, and then proceed to step S30; if yes, proceed to step S29.

[0158] S25: Offline model group;

[0159] S26: Adjust the allocated resources;

[0160] S27: Online model group;

[0161] S28: If the connection fails after three attempts, an alarm will be triggered.

[0162] S29: Calculate whether each indicator meets the requirements;

[0163] S30: Historical data storage.

[0164] The resource scheduling method provided in this embodiment obtains historical operating information of online model groups through automated indicator collection and processing, then establishes an automated resource allocation model and outputs an allocation scheme. If the model group is unstable, it is first taken offline, then the allocated resources are adjusted, and after adjusting the allocated resources, the model group is brought back online. If the online process fails, it is repeated three times. If it still fails after three attempts, an alarm is triggered, and historical operating data is stored. When the model group is stable, it calculates whether various indicators meet the requirements. These indicators refer to the latency parameter, processing speed, and online model group stability mentioned in the previous embodiment. If the requirements are met, the historical operating data is stored. Therefore, this method, by obtaining the load variation pattern through the historical information of each model group, allows for reasonable resource scheduling based on the load variation pattern and current operating information.

[0165] The resource scheduling method, system, electronic device, and medium provided in this application have been described in detail above. The various embodiments in the specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

[0166] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A resource scheduling method, characterized in that, include: Retrieve the online model groups in the Flink task; Obtain the current operating information of each online model group and the corresponding historical operating information of each online model group; A machine learning model is used to perform binary classification on the historical operating information and the current operating information of each online model group in order to determine the adjustment strategy for each online model group; the adjustment strategy includes increasing or decreasing resources. The adjustment step size of each online model group is determined by fitting the current operating information of each online model group using multiple curves. If the adjustment step size and the adjustment strategy do not meet the system's configurable resources, then global resource allocation is performed based on at least one of the priority, stacking amount, and input speed of the corresponding model group.

2. The resource scheduling method according to claim 1, characterized in that, The process of obtaining the online model groups in the Flink task includes: In the absence of any abnormally offline or abnormally restarted model groups, obtain each of the aforementioned online model groups; In the case of model groups that are abnormally offline or abnormally restarted, scan the exception logs and obtain the exception log information; Determine memory usage based on the aforementioned exception log information; If the memory meets the preset requirements, then the abnormally offline model group is brought online and each of the online model groups is obtained; If the memory does not meet the preset requirements, the memory is increased, and the process returns to the step of determining memory usage based on the exception log information.

3. The resource scheduling method according to claim 2, characterized in that, After determining the adjustment step size of each online model group by fitting the current operating information of each online model group using multiple curve fitting methods, the process includes: If the adjustment step size and the adjustment strategy meet the configurable resources of the system, then the resources of each of the online model groups are scheduled according to the adjustment step size and the adjustment strategy.

4. The resource scheduling method according to claim 3, characterized in that, The step of scheduling the resources of each of the online model groups according to the adjustment step size and the adjustment strategy includes: Obtain the unstable model group from the online model group; The unstable model group was taken offline. The resources of the unstable model group are scheduled according to the adjustment step size and the adjustment strategy.

5. The resource scheduling method according to claim 4, characterized in that, The step of allocating global resources based on at least one of the priority, stacking amount, and input speed of the corresponding model group includes: The steps for global resource allocation based on the priority, backlog, and input speed of the corresponding model group.

6. The resource scheduling method according to claim 2, characterized in that, After obtaining the current running information of each online model group and the corresponding historical running information of each online model group, the method further includes: Assuming the online model group is stable, the following assessments are made regarding the latency parameters, processing speed, and stability of the online model group. If the latency parameter, processing speed, and stability of the online model group meet the corresponding preset requirements, then the running data of each online model group after scheduling is stored.

7. The resource scheduling method according to claim 6, characterized in that, The preset requirements that the delay parameter must meet include: the average data delay processing time of each of the online model groups is less than a threshold. The preset requirement that the processing speed must meet includes: the average processing speed of each online model group is less than a preset multiple of the maximum processing speed of each online model group within a first preset time period; The stability of the online model group meets the preset requirements, including that the number of times each online model group restarts within a second preset time period is less than a preset value.

8. The resource scheduling method according to any one of claims 1 to 7, characterized in that, Obtaining the historical operation information corresponding to each of the aforementioned online model groups includes: Obtain the historical execution information of each model group in the Flink task; Obtain the historical operation information corresponding to each online model group from the historical operation information of each model group.

9. A resource scheduling system, characterized in that, include: The first acquisition module is used to acquire the online model groups in the Flink task; The second acquisition module is used to acquire the current running information of each online model group and the historical running information corresponding to each online model group; The scheduling module is used to perform binary classification on the historical running information and current running information of each online model group using a machine learning model in order to determine the adjustment strategy of each online model group; the adjustment strategy includes increasing or decreasing resources; the current running information of each online model group is fitted by multiple curve fitting methods to determine the adjustment step size of each online model group; if the adjustment step size and the adjustment strategy do not meet the configurable resources of the system, global resource allocation is performed according to at least one of the priority, backlog, and input speed of the corresponding model group.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the resource scheduling method as described in any one of claims 1 to 8 when executing the computer program.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the resource scheduling method as described in any one of claims 1 to 8.

Images