Heterogeneous model task scheduling method and system based on parallel strategy metadata

Abstract

The application provides a heterogeneous model task scheduling method and system based on parallel strategy metadata, wherein the method comprises the following steps: a central scheduler receives a computing task request containing a model identifier and a task parameter group; a task strategy predefined for a corresponding model version is obtained by querying model metadata according to the model identifier; a scheduling decision is made based on the task strategy, and the task is distributed to a computing node; an environment identifier is obtained and an isolated runtime environment is loaded by querying a model-environment mapping table according to the model identifier; data is obtained and the task is executed in the isolated runtime environment through a data service layer; the computing node reports task status and log information, and the central scheduler provides a monitoring interface for querying according to the model identifier after aggregation. By predefining a task strategy for a model version, the scheduling system has business semantic perception capability, and the parallel processing efficiency is improved while the data consistency is ensured.

Description

Technical Field

[0001] This invention relates to the field of computer task scheduling technology, and more specifically, to a heterogeneous model task scheduling method and system based on parallel policy metadata. Background Technology

[0002] In large-scale computing scenarios driven by business operations such as medical insurance fund supervision, it is necessary to deploy and run a large number of computing models for different business rules. Due to frequent adjustments to business rules, models need to be iterated rapidly, resulting in a complex situation where multiple versions of the same model coexist in the production environment. These models are usually developed by different teams at different times, and their operating environments vary, exhibiting significant environmental heterogeneity.

[0003] In existing task scheduling technologies, workflow systems based on directed acyclic graphs (DAGs) allow users to statically define dependencies between tasks. However, this approach suffers from rigid scheduling strategies: when there are no data conflicts between tasks, static sequential execution can waste computational resources; blindly executing tasks in parallel may lead to data conflicts and inconsistent states due to concurrent writes to the same data table, resulting in incorrect calculation results. Furthermore, these systems lack awareness of upper-layer business logic, failing to understand business semantics such as model versions and data access risks, making it difficult to automatically make scheduling decisions based on the model's characteristics. When model versions or business logic change, developers must manually modify the scheduling code and redeploy, resulting in high maintenance costs and an inability to adapt to rapid iteration requirements.

[0004] Another type of scheduling system, while capable of dynamically allocating resources and loading specific runtime environments, primarily relies on general resource metrics such as CPU and memory for its scheduling strategy. It also lacks the ability to perceive the model's inherent business logic and data conflict risks, and cannot automatically identify which tasks can be safely parallelized and which must be executed sequentially. Therefore, when processing multi-version model tasks with different data access characteristics, existing technologies either sacrifice efficiency by using global sequential execution or bear the data risk by blindly pursuing parallelism, lacking an automated intelligent scheduling mechanism that balances efficiency and data consistency.

[0005] A patent search revealed an invention patent with publication number CN119806771A, which discloses a parallel task scheduling method based on dynamic node load and task correlation measurement. This method involves building a virtualized computing resource system on a server, a global scheduler based on reinforcement learning for sample allocation, and a local scheduler based on a hybrid-driven model. The preprocessing stage includes statistical analysis of computing resources, virtualization of computing resources, GPU virtualization reuse technology, and GPU acceleration. The global scheduling stage, optimized for parallel processing of test tasks, includes feasibility analysis of sample scheduling with fuzzy time, selection of computing nodes based on the EXP3 algorithm, and sample scheduling based on node load. The multi-level model parallelization stage, driven by domain knowledge and data hybridization, includes a model cohesion and coupling measurement mechanism, a model coupling pattern knowledge base, and a multi-level model parallelization method. However, this patent lacks a predefined strategy for model metadata and an isolated runtime environment design, lacks a unified monitoring and log aggregation mechanism, and does not adequately consider the environmental adaptability of heterogeneous models. Its scheduling flexibility and task traceability are also weak.

[0006] In summary, given the problems of the existing technologies, researching a heterogeneous model task scheduling method and system based on parallel policy metadata has become a critical task that urgently needs to be addressed. Summary of the Invention

[0007] To address the shortcomings of existing technologies, the purpose of this invention is to provide a heterogeneous model task scheduling method and system based on parallel policy metadata.

[0008] A heterogeneous model task scheduling method based on parallel policy metadata, provided by the present invention, includes the following steps:

[0009] Step S1: The central scheduler receives task requests. Each task request contains a model identifier and multiple tasks that the model corresponding to the model identifier needs to process. Each task corresponds to a task parameter group.

[0010] Step S2: The central scheduler queries the pre-stored model metadata based on the model identifier to obtain the predefined task strategy for the model version represented by the model identifier.

[0011] Step S3: Based on the task strategy, the central scheduler makes scheduling decisions for each task in the task request and distributes the decided tasks and corresponding model identifiers to the computing nodes.

[0012] Step S4: The compute node queries the preset model-environment mapping table based on the received model identifier to obtain the corresponding environment identifier, and loads the isolated runtime environment based on the environment identifier.

[0013] Step S5: In the isolated runtime environment, the compute node obtains the corresponding compute data through the data service layer according to the task parameter group in the task, and executes the task.

[0014] In step S6, the compute nodes report task status and log information to the central scheduler. The central scheduler aggregates the information and provides a monitoring interface to query and display it by model identifier.

[0015] Preferably, in step S2, the task strategy includes at least: a sequential execution strategy and a parallel execution strategy.

[0016] Preferably, in step S3, when the task strategy is a sequential execution strategy, the central scheduler bundles all tasks in the same task request into an execution group, schedules them to the same computing node, and instructs the computing node to execute the tasks in the execution group in sequence.

[0017] Preferably, in step S3, when the task strategy is a parallel execution strategy, the central scheduler also performs scheduling according to preset parallel rules. The parallel rules specify one or more business fields in the task parameter group as judgment fields for comparing all tasks:

[0018] If two tasks have the same value in the judgment field, it is determined that the two tasks are competing for resources, and the central scheduler will distribute the two tasks to the same computing node for serial execution.

[0019] If the two tasks have different values ​​in the judgment field, the two tasks are determined to be independent of each other, and the central scheduler will distribute the two tasks to different computing nodes for simultaneous execution.

[0020] Preferably, in step S2, the model metadata also includes a resource consumption fingerprint predefined for the model version.

[0021] Preferably, in step S3, the central scheduler monitors the real-time resource status of the computing nodes and, in conjunction with the resource consumption fingerprint and the real-time resource status, distributes the task and the corresponding model identifier to the target computing node.

[0022] Preferably, in step S4, the isolated runtime environment is a Conda environment or a Docker container;

[0023] The model-environment mapping table supports mapping multiple different model identifiers to the same environment identifier, thereby enabling runtime environment sharing;

[0024] When the runtime environment dependencies of two different model versions represented by two different model identifiers are compatible, both different model identifiers are mapped to the same target environment identifier.

[0025] This invention also provides a heterogeneous model task scheduling system based on parallel policy metadata, employing the aforementioned heterogeneous model task scheduling method based on parallel policy metadata, including:

[0026] The metadata storage module is used to store model metadata. The model metadata predefines the task strategy and resource consumption fingerprint for each model version and is indexed by the model identifier.

[0027] The model-environment mapping table is used to store the mapping relationship between model identifiers and environment identifiers;

[0028] The data service layer provides a unified data access point for all tasks, shielding the differences between heterogeneous data sources;

[0029] At least one computing node is used to receive distributed tasks and model identifiers, query the model-environment mapping table based on the model identifiers to obtain environment identifiers and load the isolated runtime environment; and obtain the data required for computing through the data service layer and execute tasks.

[0030] The central scheduler is connected to the metadata storage module and at least one computing node. It receives task requests, each of which contains a model identifier and multiple tasks that the model corresponding to the model identifier needs to process. Each task corresponds to a task parameter group. The scheduler queries the metadata storage module based on the model identifier to obtain the corresponding task policy and resource consumption fingerprint. Based on the task policy, the scheduler makes scheduling decisions for each task in the task request, monitors the real-time resource status of at least one computing node, and distributes the decided tasks and corresponding model identifiers to the target computing nodes in combination with the resource consumption fingerprint.

[0031] The compute nodes report real-time resource status, task status, and log information to the central scheduler. The central scheduler aggregates the received task status and log information and provides a unified monitoring interface for querying by model identifier.

[0032] Preferably, the task strategy includes at least: a sequential execution strategy and a parallel execution strategy.

[0033] Preferably, the data service layer further includes a data access monitoring module, and the central scheduler further includes a dynamic policy adjustment module;

[0034] The data access monitoring module is used to monitor the health status of the underlying data source. When an abnormal health status of the data source is detected, the model identifier that caused the abnormality is identified and an alarm message carrying the model identifier is sent to the dynamic policy adjustment module.

[0035] The dynamic policy adjustment module is used to receive alarm information, and according to the model identifier carried in the alarm information, temporarily overwrite the task policy of the model version represented by the model identifier with the sequential execution policy in memory, and guide the task distribution corresponding to the model identifier with the overwritten task policy until the alarm cancellation information is received.

[0036] The data access monitoring module is also used to send an alarm cancellation message to the dynamic policy adjustment module when the health status of the data source is detected to have returned to normal.

[0037] The dynamic policy adjustment module is also used to remove temporary policy overlays in memory based on the alarm clearance information and restore the use of predefined task policies in the metadata storage module for scheduling decisions.

[0038] Compared with the prior art, the present invention has the following beneficial effects:

[0039] 1. This invention enables the central scheduler to perceive data access risk semantics by predefining task strategies for model versions. For model versions with data contention risks, the system automatically adopts a sequential execution strategy, scheduling multiple sets of tasks for the same model to the sequential execution queue of the same computing node for serial processing, thus avoiding concurrent write conflicts at the source. For model versions with data isolation and no impact between tasks, the system automatically adopts a parallel execution strategy, distributing tasks to multiple computing nodes for concurrent execution. Compared to the static configuration of serial or blind parallelism in existing technologies, this invention achieves dynamic matching between scheduling decisions and model business characteristics, maximizing parallelism while ensuring data consistency.

[0040] 2. This invention uses a model-environment mapping table to dynamically associate model identifiers with environment identifiers. When the new version of the model is compatible with the runtime environment of the old version of the model, it is only necessary to map the new model identifier to the existing environment identifier in the mapping table, without having to repeatedly package and store the environment package; multiple model versions can share the same isolated runtime environment.

[0041] 3. This invention provides standardized data access interfaces for all models through a unified data service layer, shielding them from the differences in heterogeneous data sources such as underlying business databases, medical insurance data platforms, and file systems. Model developers do not need to concern themselves with details such as data source location, interface protocols, and authentication methods, and can focus on algorithm and business logic development. When the underlying data source changes, only the adaptation logic of the data service layer needs to be maintained, and all upper-layer models can continue to run without modifying their code. Attached Figure Description

[0042] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0043] Figure 1 A flowchart of a heterogeneous model task scheduling method based on parallel policy metadata is provided for an embodiment of the present invention. Detailed Implementation

[0044] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the protection scope of the present invention.

[0045] This invention provides a heterogeneous model task scheduling method and system based on parallel policy metadata, relating to the field of computational task scheduling technology. The method includes: a central scheduler receiving computational task requests containing model identifiers and task parameter groups; querying model metadata based on the model identifier to obtain a predefined task policy for the corresponding model version; making scheduling decisions based on the task policy and distributing tasks to computational nodes; computational nodes querying a model-environment mapping table based on the model identifier to obtain an environment identifier and loading an isolated runtime environment; obtaining data and executing tasks in the isolated runtime environment through a data service layer; and computational nodes reporting task status and log information, which the central scheduler aggregates and provides a monitoring interface for querying by model identifier. This invention, by predefining task policies for model versions, enables the scheduling system to have business semantic awareness capabilities, improving parallel processing efficiency while ensuring data consistency.

[0046] Example 1:

[0047] Figure 1 A flowchart of a heterogeneous model task scheduling method based on parallel policy metadata is provided for an embodiment of the present invention.

[0048] like Figure 1 As shown, this embodiment provides a heterogeneous model task scheduling method based on parallel policy metadata, including the following steps:

[0049] Step S1: The central scheduler receives task requests. Each task request contains a model identifier and multiple tasks that the model corresponding to the model identifier needs to process. Each task corresponds to a task parameter group.

[0050] In this embodiment, the central scheduler receives two task requests: the first task request requires the use of model A to process three tasks (corresponding to three task parameter groups), the identifier of model A is model_a:v1.0, where model_a is the model name and v1.0 is the model version number, which together uniquely identify a "model version"; the second task request requires the use of model B to process two tasks (corresponding to two task parameter groups), the identifier of model B is model_b:v2.0.

[0051] In step S2, the central scheduler queries the pre-stored model metadata based on the model identifier to obtain the predefined task strategy for the model version represented by the model identifier.

[0052] Specifically, the task strategy includes at least two strategies: sequential execution strategy and parallel execution strategy.

[0053] In this embodiment, the predefined task strategy for model version v1.0 corresponding to model identifier model_a:v1.0 is sequential execution, and the predefined task strategy for model version v2.0 corresponding to model identifier model_b:v2.0 is parallel execution.

[0054] In this embodiment, the model metadata also includes a resource consumption fingerprint predefined for the model version.

[0055] Step S3: Based on the task strategy, the central scheduler makes scheduling decisions for each task in the task request and distributes the decided tasks and corresponding model identifiers to the computing nodes.

[0056] When the task strategy is sequential execution, the central scheduler bundles all tasks in the same task request into an execution group, schedules them to the same computing node, and instructs the computing node to execute the tasks in the execution group in sequence.

[0057] When the task strategy is a parallel execution strategy, the central scheduler also performs scheduling according to preset parallel rules. The parallel rules specify one or more business fields in the task parameter group as judgment fields to compare all tasks:

[0058] If two tasks have the same value in the judgment field, it is determined that the two tasks are competing for resources, and the central scheduler will distribute the two tasks to the same computing node for serial execution.

[0059] If the two tasks have different values ​​in the judgment field, the two tasks are determined to be independent of each other, and the central scheduler will distribute the two tasks to different computing nodes for simultaneous execution.

[0060] Specifically, for model_b:v2.0, whose task strategy is parallel execution, its two tasks are treated as independent units. Based on resource awareness and load balancing principles, the two tasks corresponding to the two task parameter groups are concurrently distributed to computing node 1 and computing node 2. For model_a:v1.0, whose task strategy is sequential execution, the three tasks corresponding to its three task parameter groups are scheduled as an execution group to computing node 3, and computing node 3 is instructed to add the tasks in the execution group to the sequential execution queue.

[0061] In this embodiment, the central scheduler monitors the real-time resource status of computing nodes and, in conjunction with the resource consumption fingerprint and the real-time resource status, distributes tasks and corresponding model identifiers to target computing nodes.

[0062] In step S4, the compute node queries the preset model-environment mapping table based on the received model identifier to obtain the corresponding environment identifier, and loads the isolated runtime environment based on the environment identifier.

[0063] In this embodiment, the isolated runtime environment is a Conda environment or a Docker container;

[0064] The model-environment mapping table supports mapping multiple different model identifiers to the same environment identifier, thereby enabling runtime environment sharing;

[0065] When the runtime environment dependencies of two different model versions represented by two different model identifiers are compatible, both different model identifiers are mapped to the same target environment identifier.

[0066] Specifically, compute node 1, compute node 2 and compute node 3 query the model-environment mapping table according to the model identifier in their respective received tasks, obtain the corresponding environment identifier, and load and activate the isolated runtime environment corresponding to the environment identifier from the environment repository 500 stored in shared storage 4. The isolated runtime environment is either a Conda environment or a Docker container.

[0067] Step S5: In the isolated runtime environment, the computing node obtains the corresponding computing data through the data service layer according to the task parameter group in the task, and executes the task.

[0068] Specifically, compute node 1, compute node 2, and compute node 3, in their respective loaded isolated runtime environments, obtain the data required for task execution through the data service layer 30 and execute the tasks. Among them, the three tasks of model_a:v1.0 are executed sequentially in the sequential execution queue of compute node 3; the two tasks of model_b:v2.0 are executed in parallel on compute node 1 and compute node 2.

[0069] In step S6, the compute nodes report task status and log information to the central scheduler. The central scheduler aggregates the information and provides a monitoring interface to query and display it by model identifier.

[0070] Specifically, computing node 1, computing node 2 and computing node 3 report their respective task status and log information to the central scheduler 11. The central scheduler 11 aggregates the received information and queries and displays it by model identifier through its unified monitoring interface 700.

[0071] Example 2:

[0072] The present invention also provides a heterogeneous model task scheduling system based on parallel policy metadata. The heterogeneous model task scheduling system based on parallel policy metadata can be implemented by executing the process steps of the heterogeneous model task scheduling method based on parallel policy metadata. That is, those skilled in the art can understand the heterogeneous model task scheduling method based on parallel policy metadata as a preferred implementation of the heterogeneous model task scheduling system based on parallel policy metadata.

[0073] Specifically, the heterogeneous model task scheduling system based on parallel policy metadata includes:

[0074] The metadata storage module is used to store model metadata. The model metadata predefines the task strategy and resource consumption fingerprint for each model version and is indexed by the model identifier.

[0075] This embodiment uses medical insurance supervision as an example, with Model A (inpatient expense anomaly detection, identifier model_a:v1.0) and Model B (outpatient fraud identification, identifier model_b:v2.0). Model_a:v1.0 faces data contention risk due to the need to update a global shared table, so its task strategy is configured for sequential execution, with resource consumption fingerprints of {CPU: 4 cores, memory: 16GB}. Model_b:v2.0 isolates data by region, ensuring no impact between tasks, so its task strategy is configured for parallel execution, with resource consumption fingerprints of {CPU: 2 cores, memory: 4GB}.

[0076] The model-environment mapping table is used to store the mapping relationship between model identifiers and environment identifiers;

[0077] In this embodiment, model_a:v1.0 is mapped to the environment identifier env_py38_tf2; model_b:v2.0 is mapped to the environment identifier env_py37_torch1, and the corresponding environment packages are stored in the environment repository.

[0078] The data service layer provides a unified data access point for all tasks, shielding the differences between heterogeneous data sources;

[0079] At least one computing node is used to receive distributed tasks and model identifiers, query the model-environment mapping table based on the model identifiers, obtain the environment identifiers, and load the isolated runtime environment; and obtain the data required for computing through the data service layer and execute tasks.

[0080] In this embodiment, the heterogeneous data sources include business databases, medical insurance data platforms, and file systems.

[0081] The central scheduler, connected to the metadata storage module and at least one computing node, receives task requests. Each task request contains a model identifier and multiple tasks that the model corresponding to the model identifier needs to process. Each task corresponds to a task parameter group. The scheduler queries the metadata storage module based on the model identifier to obtain the corresponding task policy and resource consumption fingerprint. Based on the task policy, the scheduler makes scheduling decisions for each task in the task request, monitors the real-time resource status of at least one computing node, and distributes the decided tasks and corresponding model identifiers to the target computing nodes in combination with the resource consumption fingerprint.

[0082] The compute nodes report real-time resource status, task status, and log information to the central scheduler. The central scheduler aggregates the received task status and log information and provides a unified monitoring interface for querying by model identifier.

[0083] Specifically, the task strategy includes at least two strategies: sequential execution strategy and parallel execution strategy.

[0084] The data service layer also includes a data access monitoring module, and the central scheduler also includes a dynamic policy adjustment module;

[0085] The data access monitoring module is used to monitor the health status of the underlying data source. When an abnormal health status of the data source is detected, the model identifier that caused the abnormality is identified and an alarm message carrying the model identifier is sent to the dynamic policy adjustment module.

[0086] The dynamic policy adjustment module is used to receive alarm information, and according to the model identifier carried in the alarm information, temporarily overwrite the task policy of the model version represented by the model identifier with the sequential execution policy in memory, and guide the task distribution corresponding to the model identifier with the overwritten task policy until the alarm cancellation information is received.

[0087] The data access monitoring module is also used to send an alarm cancellation message to the dynamic policy adjustment module when the health status of the data source is detected to have returned to normal.

[0088] The dynamic policy adjustment module is also used to remove temporary policy overlays in memory based on the alarm clearance information and restore the use of predefined task policies in the metadata storage module for scheduling decisions.

[0089] This embodiment ensures data consistency of model_a:v1.0 through metadata-driven automated scheduling, while leveraging the parallel processing capabilities of model_b:v2.0 to improve the overall throughput of the cluster.

[0090] Example 3:

[0091] This embodiment elaborates on step S3 based on embodiment 1.

[0092] Taking the drug abuse monitoring model C (model identifier: model_c:v3.0) as an example, its business logic is as follows: tasks processing different cities can be performed in parallel, but tasks processing different hospitals within the same city must be performed serially due to the need to read and write to a shared cache. Therefore, when configuring the metadata of model_c:v3.0, its task strategy is configured as a parallel execution strategy, with the addition of the parallel rule: parallel_if(param[city]). This parallel rule indicates that tasks will only be executed in parallel if the values ​​of the city field in the task parameters are different.

[0093] The central scheduler received four task requests for model_c:v3.0, with the following task parameter groups:

[0094] Task 1: {city: Beijing, hospital: Peking Union Medical College Hospital}

[0095] Task 2: {city:Beijing,hospital:301}

[0096] Task 3: {city: Shanghai, hospital: Ruijin}

[0097] Task 4: {city: Guangzhou, hospital: Sun Yat-sen Memorial Hospital}

[0098] The central scheduler retrieves the parallel execution strategy and additional parallel rules for model_c:v3.0. Based on the city field specified in the rules, it analyzes the parameter groups of each task: the city field values ​​of task 1 and task 2 are the same (both are Beijing), so according to the rules, parallel execution is not allowed; the city field values ​​of task 1 and task 3, task 1 and task 4, task 2 and task 3, task 2 and task 4, and task 3 and task 4 are all different, so according to the rules, parallel execution is allowed.

[0099] Based on the above analysis results, the central scheduler makes scheduling decisions: Tasks 1 and 2, which have the same city field value, are treated as an execution group and scheduled as a whole to be executed serially in the sequential execution queue of computing node 1; Tasks 3 and 4 are treated as independent tasks and distributed to computing node 2 and computing node 3 for parallel execution, respectively.

[0100] The parallel rules adopted in this embodiment enable the scheduling system to perform fine-grained parallel control based on business fields, maximizing resource utilization while ensuring data consistency.

[0101] Meanwhile, the specific implementation of task distribution by the central scheduler in step S3, which combines resource consumption fingerprints and real-time resource status, will be elaborated, including the following steps:

[0102] The first step is for the central scheduler to maintain real-time resource status, recording the current number of available CPU cores, current available memory capacity, number of running tasks, and task queue length for each computing node.

[0103] The second step is that when a task is received, the central scheduler queries the resource consumption fingerprint of the model corresponding to the task based on the model identifier, and obtains the number of CPU cores and memory capacity required to execute the task.

[0104] The third step is for the central scheduler to traverse all computing nodes and filter out candidate nodes that meet the hard resource conditions. The hard resource conditions are: the number of available CPU cores of the node is greater than or equal to the number of CPU cores required by the task, and the available memory capacity is greater than or equal to the memory capacity required by the task.

[0105] The fourth step is to select the node with the shortest task queue length from the candidate nodes that meet the hard resource requirements as the target computing node. If multiple nodes have the same queue length, the node with the largest available memory capacity is selected.

[0106] The fifth step involves the central scheduler distributing tasks to the finally selected target computing nodes and updating the available resource information and task queue information of the nodes in the real-time resource status.

[0107] Example 4:

[0108] Based on Example 1, this embodiment optimizes the environment management in step S4 by reducing storage redundancy and improving operation and maintenance efficiency through an environment sharing mechanism.

[0109] The scenario in this embodiment is as follows: The hospital expense anomaly detection model has been iterated to a new version model_a:v1.1 based on version v1.0. After testing, it was found that v1.1 and v1.0 are fully compatible in terms of runtime environment dependencies, and there is no need to create a new independent environment package for it.

[0110] The implementation process is as follows: Map the new model identifier model_a:v1.1 to the existing environment identifier env_py38_tf2. At this point, a many-to-one mapping relationship is formed in the model-environment mapping table: both model_a:v1.0 and model_a:v1.1 are mapped to the same environment identifier env_py38_tf2.

[0111] When the system receives both `model_a:v1.0` and `model_a:v1.1` tasks simultaneously, the central scheduler schedules the two versions of the task to different compute nodes (such as compute node 1 and compute node 2) for parallel execution. The agent programs on compute node 1 and compute node 2 each query the model-environment mapping table based on the model identifier in the task, both obtaining the same environment identifier `env_py38_tf2`, and loading and activating the same environment package from the environment repository, thus executing their respective versions of the model code.

[0112] This embodiment significantly reduces storage consumption and management complexity through environment sharing, improving resource utilization and operational efficiency, and is particularly suitable for scenarios with rapid model version iteration. The isolated runtime environment can be specifically implemented as a Conda environment or a Docker container, etc.

[0113] This embodiment utilizes the aforementioned many-to-one environment mapping mechanism to enable multiple model versions to share the same isolated runtime environment. This reduces storage consumption and environment management complexity, while improving resource utilization and operational efficiency, making it particularly suitable for scenarios involving rapid model version iteration. The isolated runtime environment is specifically implemented as a Conda environment or a Docker container.

[0114] Example 5:

[0115] Example 5 elaborates on the closed-loop control system that achieves adaptive scheduling through dynamic feedback, based on Example 2.

[0116] The workflow is as follows:

[0117] During peak business periods, a large number of task requests for model_b:v2.0 flooded in. The central scheduler distributed the tasks concurrently to multiple computing nodes according to its preset parallel execution strategy, resulting in a surge in concurrent access pressure on the core business database.

[0118] The data access monitoring module detected that the database query latency exceeded the threshold, identified the pressure source as model_b:v2.0, and then sent a structured alarm to the dynamic strategy adjustment module. The alarm carried context information such as: source_model_id:model_b:v2.0.

[0119] Upon receiving an alarm, the dynamic policy adjustment module temporarily downgrades the effective scheduling policy of model_b:v2.0 from parallel execution to sequential execution in memory. This adjustment only affects runtime scheduling decisions and does not modify the persistent model metadata configuration in the metadata storage module.

[0120] Subsequently, all newly arriving model_b:v2.0 tasks are scheduled according to the sequential execution strategy and are aggregated into the sequential execution queue of the same compute node for serial processing, which actively reduces the pressure of concurrent access to the database.

[0121] Once the data access monitoring module detects that the database load has returned to normal, it sends a de-alarm signal. The dynamic policy adjustment module removes the temporary policy overwrite in memory, and the scheduling policy of model_b:v2.0 is restored to the parallel execution preset in the metadata database.

[0122] This embodiment uses a dynamic feedback mechanism to enable the scheduling system to perceive the health status of downstream data sources and proactively adjust strategies temporarily. It achieves closed-loop adaptive adjustment without disrupting the original configuration, ensuring efficient execution of computing tasks and preventing downstream service performance avalanche caused by task overload, thereby improving the overall system stability.

[0123] Those skilled in the art will understand that, besides implementing the system and its various devices, modules, and units provided by this invention in the form of purely computer-readable program code, the same functions can be achieved entirely through logical programming of the method steps, making the system and its various devices, modules, and units of this invention function in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, the system and its various devices, modules, and units provided by this invention can be considered as a hardware component, and the devices, modules, and units included therein for implementing various functions can also be considered as structures within the hardware component; alternatively, the devices, modules, and units for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0124] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features of the present invention can be arbitrarily combined with each other.

Claims

1. A heterogeneous model task scheduling method based on parallel policy metadata, characterized in that, Includes the following steps: Step S1: The central scheduler receives task requests. Each task request contains a model identifier and multiple tasks that the model corresponding to the model identifier needs to process. Each task corresponds to a task parameter group. Step S2: The central scheduler queries the pre-stored model metadata based on the model identifier to obtain the predefined task strategy for the model version represented by the model identifier. Step S3: Based on the task strategy, the central scheduler makes scheduling decisions for each task in the task request and distributes the decided tasks and corresponding model identifiers to the computing nodes. Step S4: The computing node queries a preset model-environment mapping table based on the received model identifier to obtain the corresponding environment identifier, and loads the isolated runtime environment based on the environment identifier. Step S5: In the isolated runtime environment, the computing node obtains the corresponding computing data through the data service layer according to the task parameter group in the task, and executes the task. In step S6, the computing node reports the task status and log information to the central scheduler. The central scheduler aggregates the information and provides a monitoring interface to query and display it according to the model identifier.

2. The heterogeneous model task scheduling method based on parallel policy metadata according to claim 1, characterized in that, In step S2, the task strategy includes at least: a sequential execution strategy and a parallel execution strategy.

3. The heterogeneous model task scheduling method based on parallel policy metadata according to claim 2, characterized in that, In step S3, when the task strategy is a sequential execution strategy, the central scheduler bundles all tasks in the same task request into an execution group, schedules them to the same computing node, and instructs the computing node to execute the tasks in the execution group in sequence.

4. The heterogeneous model task scheduling method based on parallel policy metadata according to claim 2, characterized in that, In step S3, when the task strategy is a parallel execution strategy, the central scheduler also performs scheduling according to preset parallel rules. The parallel rules specify one or more business fields in the task parameter group as judgment fields for comparing all tasks. If the field values ​​of the two tasks are the same in the judgment field, it is determined that the two tasks are competing for resources, and the central scheduler will distribute the two tasks to the same computing node for serial execution. If the field values ​​of the two tasks in the judgment field are different, it is determined that the two tasks do not affect each other, and the central scheduler will distribute the two tasks to different computing nodes for simultaneous execution.

5. The heterogeneous model task scheduling method based on parallel policy metadata according to claim 1, characterized in that, In step S2, the model metadata also includes a resource consumption fingerprint predefined for the model version.

6. The heterogeneous model task scheduling method based on parallel policy metadata according to claim 5, characterized in that, In step S3, the central scheduler monitors the real-time resource status of the computing nodes and, in conjunction with the resource consumption fingerprint and the real-time resource status, distributes the task and the corresponding model identifier to the target computing node.

7. The heterogeneous model task scheduling method based on parallel policy metadata according to claim 1, characterized in that, In step S4, the isolated runtime environment is a Conda environment or a Docker container; The model-environment mapping table supports mapping multiple different model identifiers to the same environment identifier, thereby enabling runtime environment sharing; When the runtime environment dependencies of two model versions represented by two different model identifiers are compatible, the two different model identifiers are mapped to the same target environment identifier.

8. A heterogeneous model task scheduling system based on parallel policy metadata, employing the heterogeneous model task scheduling method based on parallel policy metadata as described in any one of claims 1-7, characterized in that, include: The metadata storage module is used to store model metadata, which predefines task strategies and resource consumption fingerprints for each model version and is indexed by model identifiers. A model-environment mapping table is used to store the mapping relationship between the model identifier and the environment identifier; The data service layer provides a unified data access point for all tasks, shielding the differences between heterogeneous data sources; At least one computing node is used to receive distributed tasks and model identifiers, query the model-environment mapping table based on the model identifiers to obtain environment identifiers and load the isolated runtime environment; and obtain the data required for computing through the data service layer and execute tasks. A central scheduler, connected to both the metadata storage module and the at least one computing node, receives task requests. Each task request includes a model identifier and multiple tasks that the model corresponding to the model identifier needs to process. Each task corresponds to a task parameter group. The scheduler queries the metadata storage module based on the model identifier to obtain the corresponding task strategy and resource consumption fingerprint. Based on the task strategy, the scheduler makes scheduling decisions for each task in the task request, monitors the real-time resource status of the at least one computing node, and distributes the decided tasks and corresponding model identifiers to the target computing nodes in conjunction with the resource consumption fingerprint. The computing nodes report real-time resource status, task status, and log information to the central scheduler. The central scheduler aggregates the received task status and log information and provides a unified monitoring interface for querying by model identifier.

9. The heterogeneous model task scheduling system based on parallel policy metadata according to claim 8, characterized in that, The task strategy includes at least: sequential execution strategy and parallel execution strategy.

10. The heterogeneous model task scheduling system based on parallel policy metadata according to claim 9, characterized in that, The data service layer also includes a data access monitoring module, and the central scheduler also includes a dynamic strategy adjustment module; The data access monitoring module is used to monitor the health status of the underlying data source. When an abnormal health status of the data source is detected, the module identifies the model identifier that caused the abnormality and sends an alarm message carrying the model identifier to the dynamic strategy adjustment module. The dynamic strategy adjustment module is used to receive the alarm information, and according to the model identifier carried in the alarm information, temporarily overwrite the task strategy of the model version represented by the model identifier with the sequential execution strategy in memory, and guide the task distribution corresponding to the model identifier with the overwritten task strategy until the alarm cancellation information is received. The data access monitoring module is also used to send an alarm cancellation message to the dynamic strategy adjustment module when the health status of the data source is detected to have returned to normal. The dynamic policy adjustment module is also used to remove the temporary policy overlay in memory according to the alarm cancellation information, and restore the use of the predefined task policy in the metadata storage module for scheduling decisions.

Images