Distributed storage resource scheduling system based on edge computing

Abstract

This invention discloses a distributed storage resource scheduling system based on edge computing, relating to the technical field of resource scheduling. The system includes a cloud computing center and multiple edge nodes subordinate to the cloud computing center. The cloud computing center is used for reading first-level tasks, matching a first edge node from among the multiple edge nodes based on the first-level task. The data resource base of the second-level task in the first edge node is divided into multiple sub-data. Migration sub-data in the second-level task is determined from the multiple sub-data based on the execution level of the second-level task. A second edge node is matched from among the multiple edge nodes based on the migration sub-data. The first-level task is distributed to the first edge node. The first edge node is used to extract the context information of the second-level task. The second-level task is encapsulated based on the context information to obtain a migration task. The migration task is then disassembled and distributed to the second edge node. This invention can effectively avoid conflicts between latency-sensitive services.

Description

Technical Field

[0001] This invention relates to the technical field of resource scheduling, and in particular to a distributed storage resource scheduling system based on edge computing. Background Technology

[0002] In existing research on heterogeneous edge computing task scheduling and resource management technologies, resource scheduling research is limited to load balancing of multiple edge nodes, and it is difficult to consider the situation of resource preemption within a single node.

[0003] For example, in Yu Xiaofei's book, "Research on Heterogeneous Edge Computing Task Scheduling and Resource Management in Cloud-Edge-Device Collaboration," the limitations of a single edge node are overcome, and a cross-regional collaborative framework is proposed. The multi-edge server joint networking framework designed by the author uses virtualization technology to pool heterogeneous processors (such as CPUs and GPUs) to form a hybrid computing cluster (HCC), providing services according to business type (such as compute-intensive and latency-sensitive). For parallel tasks (such as FFT and Gaussian elimination), an algorithm for proportional pre-allocation of energy consumption margin is proposed to minimize the scheduling length under energy consumption constraints. This algorithm allocates the total energy consumption budget according to task characteristics, maximizing energy efficiency.

[0004] However, the original paper provides services based on business type (such as computationally intensive or latency-sensitive). Therefore, there will inevitably be resource competition among latency-sensitive businesses. Due to their latency-sensitive nature, if a latency-sensitive task is at a disadvantage in the competition, it is very easy for the business to time out.

[0005] Therefore, how to avoid conflicts between delay-sensitive business processes has become an urgent technical problem to be solved. Summary of the Invention

[0006] The technical problem solved by this invention is that resource competition exists between latency-sensitive services, which can easily lead to service timeouts.

[0007] To address the aforementioned technical problems, this invention provides the following technical solution: a distributed storage resource scheduling system based on edge computing, comprising a cloud computing center and multiple edge nodes subordinate to the cloud computing center; the cloud computing center is used to: respond to the reading of a first-level task, match a first edge node from among the multiple edge nodes according to the first-level task; divide the data resource base of the second-level task in the first edge node to obtain multiple sub-data; determine the migration sub-data in the second-level task from among the multiple sub-data according to the execution level of the second-level task; match a second edge node from among the multiple edge nodes according to the migration sub-data; and distribute the first-level task to the first edge node; the first edge node is used to: extract the context information of the second-level task; encapsulate the second-level task according to the context information to obtain a migration task; and disassemble the migration task to the second edge node.

[0008] Preferably, the cloud computing center is further configured to: respond to receiving a task to be assigned, parse the task to be assigned, and obtain the latency nature, task duration, and resource consumption of the task to be assigned; if the latency nature of the task to be assigned is latency-sensitive, and the task duration is shorter than a preset time threshold, and the resource consumption is greater than a preset consumption threshold, then the task to be assigned is determined as a first-level task; if the latency nature of the task to be assigned is latency-sensitive, and the task duration is longer than or equal to the preset time threshold, and the resource consumption is less than or equal to the preset consumption threshold, then the task to be assigned is determined as a second-level task; read the configuration file of the task to be assigned to determine the data resource base required for the execution of the task to be assigned; match the data resource base from a pre-stored global cache directory, and determine the execution edge node for executing the task to be assigned from multiple edge nodes; and assign the task to be assigned to the execution edge node.

[0009] Preferably, the migration task includes a description file and task information corresponding to multiple sub-data. The description file includes environment configuration information, resource requirement information, and startup command information. The environment configuration information describes the environment support required when the multiple sub-data are executed. The resource requirement information describes the hardware resource requirements and data resource requirements when the multiple sub-data are run. The startup command information describes the startup command when the multiple sub-data are run.

[0010] Preferably, the global cache directory includes node information of multiple edge nodes and data resource information cached by each edge node; the cloud computing center is also used to monitor the running status of multiple edge nodes; matching a second edge node from multiple edge nodes based on migration sub-data includes: selecting resource-sufficient nodes from multiple edge nodes that can meet the hardware resource requirements of the migration task based on the running status of multiple edge nodes; determining the fit between the data resource information cached by the edge nodes and the resource requirement information based on the resource requirement information of the migration task and the data resource information in the global cache directory; sorting multiple edge nodes based on the fit between the data resource information and the resource requirement information; and selecting a second edge node from the resource-sufficient nodes based on the fit.

[0011] Preferably, the second edge node is used to: receive migration tasks; execute migration tasks to obtain return data; and return the return data to the initiator of the second-level task.

[0012] Preferably, the initiating end has mobility; the cloud computing center is also used to determine the transition edge node where the initiating end is currently located based on the coverage of multiple edge nodes and the current location of the initiating end; the second edge node is also used to send the returned data to the transition edge node; the transition edge node is used to return the returned data to the initiating end.

[0013] Preferably, the process of selecting a second edge node from resource-sufficient nodes based on adaptability includes: extracting data dependency tags, data timeliness tags, and data volume tags from the migration sub-data, wherein the data dependency tags are used to identify the association between resource demand information and data resource information of resource-sufficient nodes, the data timeliness tags are used to identify data access latency sensitivity, and the data volume tags are used to identify the data size level of task information; extracting resource sufficiency tags, data locality tags, and network coupling tags from resource-sufficient nodes, wherein the resource sufficiency tags are used to identify the remaining hardware resource capacity, the data locality tags are used to identify the matching degree between locally cached data and migration sub-data, and the network coupling tags are used to identify the communication latency level between resource-sufficient nodes and the first edge node; constructing a semantic system between tasks, data, and nodes based on the data dependency tags, data timeliness tags, and data volume tags of the migration sub-data, as well as the resource sufficiency tags, data locality tags, and network coupling tags of resource-sufficient nodes; and selecting a second edge node from resource-sufficient nodes based on the semantic system.

[0014] Preferably, the process of selecting second edge nodes from resource-sufficient nodes based on a semantic system includes: abstracting multiple edge nodes into graph nodes, wherein each graph node's node attributes include: resource adequacy, current load, and migration task context compatibility; abstracting the resource coupling relationships of multiple edge nodes into graph edges, wherein each graph edge's edge attributes include: data migration cost and task dependency; determining the conflict value between graph nodes and graph edges based on the semantic system, wherein if the semantic labels of resource-sufficient nodes and migration sub-data do not match, the conflict value is increased; generating a conflict matrix between tasks and nodes, wherein the matrix element values ​​of the conflict matrix are the comprehensive conflict values ​​between resource-sufficient nodes and migration sub-data, and the comprehensive conflict values ​​are used to quantify migration risk; and selecting second edge nodes from resource-sufficient nodes based on the conflict matrix.

[0015] Preferably, the process of selecting second edge nodes from resource-sufficient nodes based on the conflict matrix includes: classifying risk levels according to the range of conflict values; performing a secondary sorting of nodes with the same risk level based on the resource margin label of resource-sufficient nodes; and determining the second edge nodes based on the risk classification results.

[0016] Preferably, after determining the second edge node based on the risk classification results, the cloud computing center is further configured to: if the risk level of the resource-sufficient node is low and the resource margin label is high redundancy, generate a dismantling instruction to dismantle the migration task to the second edge node; if the risk level of the resource-sufficient node is medium and the resource margin label is not high redundancy, monitor the resource status of the second edge node, and generate a dismantling instruction to dismantle the migration task to the second edge node when the resource margin of the second edge node is increased to high redundancy.

[0017] The beneficial effects of this invention are as follows: In response to the reading of the first-level task, a first edge node is matched from multiple edge nodes according to the first-level task, and the data resource base of the second-level task in the first edge node is divided into multiple sub-data. The migration sub-data in the second-level task is determined from the multiple sub-data according to the execution level of the second-level task. A second edge node is matched from multiple edge nodes according to the migration sub-data. In order to avoid the competition conflict between the first-level task and the second-level task when the latency-sensitive first-level task may compete for resources with the latency-sensitive second-level task in the first edge node, the second-level task is migrated to the second edge node, thereby avoiding the competition conflict between the first-level task and the second-level task and ensuring that the execution resources of the first-level task and the second-level task are sufficient. Attached Figure Description

[0018] Figure 1 This is a schematic diagram illustrating an application scenario of the distributed storage resource scheduling system based on edge computing provided in Embodiment 1 of the present invention. Figure 2 A schematic diagram of the basic structure of a distributed storage resource scheduling system based on edge computing provided in Embodiment 1 of the present invention; Figure 3 This is a basic flowchart illustrating the process of a cloud computing center allocating tasks to be assigned, as provided in Embodiment 1 of the present invention. Figure 4 A basic flowchart illustrating the migration preparation process performed by a cloud computing center as provided in Embodiment 1 of the present invention; Figure 5 This is a basic flowchart illustrating the process of determining the second edge node executed by the cloud computing center in Embodiment 3 of the present invention. Detailed Implementation

[0019] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0020] Example 1, referring to Figures 1-4 As an embodiment of the present invention, a distributed storage resource scheduling system based on edge computing is provided, including a cloud computing center and multiple edge nodes under the cloud computing center.

[0021] Edge computing is a distributed computing model that pushes computing power down to network edge nodes (closer to data sources or users), which can reduce data transmission latency; distributed storage resource scheduling refers to the process of dynamically allocating storage and computing resources according to task requirements; latency-sensitive tasks specifically refer to task types that have strict requirements for response time (such as milliseconds), and excessive latency will significantly affect the implementation of functions; the global cache directory is a pre-stored index of commonly used data resources on each edge node, used to quickly locate the location of the data required by the task.

[0022] like Figure 1As shown, the system comprises a multi-layered framework. The top layer is the application layer, which includes task initiators such as cloud platform applications, hosts, and data management servers, responsible for proposing specific computing or storage requirements. The middle layer is the cloud computing center, which serves as the task scheduling hub and undertakes the core responsibility of task allocation and dismantling. The bottom layer is the heterogeneous network access layer, consisting of multiple edge nodes distributed in different geographical locations. Relying on diverse network environments (such as 5G, Wi-Fi, and fiber optics), these nodes provide users with nearby computing and storage resource support.

[0023] like Figure 3 As shown, the process of allocating tasks to be assigned in the cloud computing center includes S1110~S1160: S1110, in response to receiving the task to be assigned, the task to be assigned is parsed to obtain the latency nature, task duration, and resource consumption of the task to be assigned; S1120, if the latency nature of the task to be assigned is latency-sensitive, and the task duration is shorter than a preset time threshold, and the resource consumption is greater than a preset consumption threshold, then the task to be assigned is determined as a first-level task; S1130, if the latency nature of the task to be assigned is latency-sensitive, and the task duration is longer than or equal to a preset time threshold, and the resource consumption is less than or equal to a preset consumption threshold, then the task to be assigned is determined as a second-level task; S1140, the configuration file of the task to be assigned is read to determine the data resource base required for the execution of the task to be assigned; S1150, based on the data resource base, a matching is performed from the pre-stored global cache directory to determine the execution edge node for executing the task to be assigned from multiple edge nodes; S1160, the task to be assigned is assigned to the execution edge node.

[0024] When the cloud computing center receives a task to be assigned, it first enters the parsing stage to extract the key attributes of the task: latency (whether it is latency-sensitive), task duration (shorter or longer than a preset threshold based on experience), and resource consumption (greater or less than a preset threshold based on experience). Based on these three indicators, the task is divided into different priorities: if the task has high real-time requirements (latency-sensitive), short duration (shorter than the time threshold), and high resource requirements (greater than the consumption threshold), it is designated as a first-level task. These tasks usually require fast response and consume a lot of resources, so execution efficiency must be prioritized; if the task is latency-sensitive but has a long duration and low resource consumption, it is classified as a second-level task. Its immediacy requirements are slightly less stringent, and it can be flexibly scheduled according to resource load.

[0025] After classification, the system reads the task's configuration file to determine the basic data resources required for its execution (such as training models, historical logs, etc.). Then, it queries the pre-stored global cache directory, which records the data resource information cached by each edge node. By matching the data required by the task with the cached content of the edge node, the system filters out candidate nodes with high data localization and low transmission latency, and finally assigns the task to the most suitable execution edge node.

[0026] Taking the real-time traffic analysis task for autonomous vehicles as an example, this task requires synchronously processing image data collected by cameras while the vehicle is in motion. It is extremely sensitive to latency (a latency exceeding 100ms may lead to decision-making errors), and each task lasts approximately 20 seconds (shorter than the preset 30-second threshold). Furthermore, it requires high computing power for image recognition model inference (resource consumption exceeds the threshold), thus it is classified as a Level 1 task by the cloud computing center. Further analysis of its configuration file reveals that the task requires the latest road sign model file (approximately 500MB) and historical congestion data (approximately 1GB). A query of the global cache directory shows that the model file is already cached by the nearest edge node A (due to frequent access by other autonomous vehicles in the area recently), and historical congestion data can also be quickly retrieved from node A's local storage. Based on this, the cloud computing center assigns the task to node A for execution, avoiding the time-consuming process of fetching large files from the remote cloud computing center and ensuring that the analysis results are returned to the vehicle within 50ms, meeting the real-time requirements.

[0027] like Figure 4 As shown, if it is identified that the first-level task and the second-level task may be assigned to the same edge node, causing a conflict, the cloud computing center also performs migration preparation for the continuous second-level task before the sudden first-level task is issued. The migration preparation process performed by the cloud computing center includes S1210~S1250: S1210, in response to the reading of the first-level task, the first edge node is matched from multiple edge nodes according to the first-level task; S1220, the data resource base of the second-level task in the first edge node is divided into multiple sub-data; S1230, the migration sub-data in the second-level task is determined from multiple sub-data according to the execution degree of the second-level task; S1240, the second edge node is matched from multiple edge nodes according to the migration sub-data; S1250, the first-level task is issued to the first edge node.

[0028] To address the core conflict of resource competition among edge nodes, the S1210~S1250 provides a dynamic migration mechanism for task conflict scenarios. When latency-sensitive Level 1 tasks (requiring fast response and high resources) and continuous Level 2 tasks (long-term operation and stable resource consumption) may be assigned to the same edge node, the cloud computing center will initiate migration preparation in advance.

[0029] By splitting and transferring some of the second-level task data, resource space is freed up for the first-level tasks, while minimizing interruption to the continuous execution of the second-level tasks. Continuous second-level tasks are those with long execution cycles (e.g., hours or days) that rely on continuous data input (e.g., long-term anomaly detection in community surveillance footage), and their resource consumption exhibits steady-state characteristics. Migration preparation, through data redistribution, prioritizes ensuring the resource needs of critical tasks without terminating secondary tasks.

[0030] When the cloud computing center receives a Level 1 task and resolves its target edge node (i.e., the first edge node), it first checks whether the node is running a continuous Level 2 task. If a conflict exists, the system first performs semantic segmentation on the Level 2 task data on the first edge node: based on the task's execution progress (such as the data period already processed, the number of model iterations completed), the data is split into "active data being processed" and "idle data to be processed." For example, if the Level 2 task is "processing abnormal behavior detection of community surveillance video over the past 7 days," and the analysis of the first 3 days has been completed (active data), the remaining 4-7 days of video recordings are "idle data to be processed" (migrated sub-data).

[0031] Next, the system will match a second edge node with low load, low network latency, and high data support from the heterogeneous network access layer based on the attributes of the migrated sub-data (such as data volume and access frequency), for example, an idle edge node in an adjacent area, and migrate this part of the data to be processed there. Finally, the cloud computing center will distribute the first-level task to the first edge node that carried out the data transfer, ensuring that it can immediately start high-priority tasks, while the migrated second-level tasks will continue to execute unfinished analysis from the second edge node.

[0032] Taking a smart city scenario of real-time traffic accident recognition and long-term community monitoring as an example: An edge node A is continuously running a second-level task—processing nearly 7 days of surveillance footage from Gate 3 of the community, detecting abnormal behavior (such as falls or left-behind objects). The analysis of the first 3 days has been completed, and the remaining 4-7 days of footage are pending processing. At this time, the cloud computing center receives a first-level task from intersection X: real-time traffic accident recognition (latency sensitive, requiring results to be returned within 50ms, task duration 20 seconds, high resource consumption). The system detects a task allocation conflict (both pointing to node A), and thus initiates migration preparation: First, it determines that node A is the target node for the first-level task (S1210). Then, it splits the data for the second-level task on node A—retaining the processed 3 days of footage (active data), and marking the unprocessed 4-7 days of footage as migration sub-data (S1220-S1230). Subsequently, the system queries the global cache directory, finds the adjacent node B (load only 30%, network latency difference from node A less than 10ms), and migrates the 4-7 days of footage to node B (S1240). Finally, the first-level task was dispatched to node A for execution. Node A no longer needed to handle the idle data of the second-level task, and was able to quickly start traffic accident recognition and return results within 50ms. Meanwhile, the migrated second-level task continued to process 4-7 days of video recordings on node B. The overall progress was not affected, which ensured both the low latency requirements of the first-level task and the continuity of the second-level task.

[0033] Correspondingly, the first edge node is used to execute S2110~S2130: S2110, extract the context information of the second-level task; S2120, encapsulate the second-level task according to the context information to obtain the migration task; S2130, disassemble the migration task to the second edge node.

[0034] Preferably, the migration task includes a description file and task information corresponding to multiple sub-data. The description file includes environment configuration information, resource requirement information, and startup command information. The environment configuration information describes the environment support required when the multiple sub-data are executed. The resource requirement information describes the hardware resource requirements and data resource requirements when the multiple sub-data are run. The startup command information describes the startup command when the multiple sub-data are run.

[0035] Preferably, the global cache directory includes node information of multiple edge nodes and data resource information cached separately for each edge node; the cloud computing center is also used to monitor the running status of multiple edge nodes.

[0036] After the cloud computing center completes the preparatory work for allocating the first-level tasks, the first edge node (the node that originally carried the second-level tasks) needs to cooperate in distributing the migration tasks. The global cache directory and status monitoring provide the underlying support for resource matching and operation monitoring throughout the process. Context information is a "state snapshot" of task execution, containing key information such as process identifiers, dependency library versions, and intermediate result storage paths. Its purpose is to allow migrated tasks to continue running directly from their original progress without needing to be initialized from scratch. Migration task encapsulation packages "environmental requirements + data resources + execution instructions" into independently deployable units, preventing task failures due to missing information. The global cache directory is not only an index of data resources but also integrates the basic attributes (such as CPU core count, memory capacity, and network bandwidth) and real-time status (such as load rate and online status) of each edge node, essentially acting as a resource map for the cloud computing center, helping to quickly locate suitable migration targets. Status monitoring is the cloud computing center's health monitoring of edge nodes. Through periodic heartbeat checks or event triggers, it monitors the node's operational status in real time, ensuring that scheduling decisions can dynamically adapt to changes.

[0037] Upon receiving a migration instruction from the cloud computing center (originating from the allocation requirements of the first-level task), the first edge node first extracts the context information of the second-level task. For example, if the second-level task is long-term anomaly detection in a community monitoring station, the context will include the Python version the task depends on, the TensorFlow framework version, the progress of processed data (e.g., "comprehensive analysis of the first 3 days of video recordings completed"), and the storage path of intermediate results (e.g., anomaly behavior annotation files). Based on this context, the node packages the sub-data to be migrated (e.g., unprocessed 4-7 days of video recordings) with the environmental requirements and execution instructions to generate a migration task.

[0038] The migration task description file explicitly states that it requires a Python 3.8 runtime environment, a resource quota of 1 CPU core + 2GB memory, and the startup command is 'python anomaly_detection.py --data_path / migrated_data'. The task information corresponding to the sub-data will associate the migration data with the specific execution steps (e.g., "process the recording / migrated_data / 4-7_day.mp4 and output the abnormal results to / tmp / anomaly_4-7.csv"). Finally, the first edge node disassembles (i.e., deploys) the encapsulated migration task to the second edge node, sends the description file and sub-data to the target node via a secure transmission protocol, and triggers the startup command.

[0039] Taking a smart city scenario as an example: When node A (the first edge node) needs to migrate 4-7 days of video recordings from the second-level task of community surveillance to node B (the second edge node), it first extracts the context of the task—relying on TensorFlow 2.5, having processed up to day 3, and storing intermediate results in ` / tmp / detection_log`. Then, node A packages this context and sub-data: the description file specifies "requires TensorFlow 2.5, 1 CPU core, and the startup command is 'python detect.py --resume / tmp / detection_log'", and the sub-data task information is associated with "processing 4-7 days of video recordings, outputting to ` / tmp / anomaly`". After receiving the migration task, node B checks its own environment according to the description file (if TensorFlow 2.5 is not installed, it retrieves the pre-compiled package from the global cache directory and installs it), allocates 1 CPU core, starts the task, and loads the existing detection logs, seamlessly connecting to subsequent video analysis. Meanwhile, the cloud computing center is constantly monitoring the node status: confirming that node B is online via heartbeat packets, and finding that node B's load is only 25% through resource monitoring (meeting migration requirements); if node B's load suddenly spikes to 80% during the process, the cloud computing center will promptly pause the migration or adjust the sub-data partitioning ratio to ensure that both tasks run stably.

[0040] Edge nodes ensure the continuity of the second-level tasks by encapsulating context and migration tasks; the cloud computing center, through a global cache directory and status monitoring, achieves precise matching of migration target nodes and process control. The combination of these two approaches satisfies the low-latency requirements of the first-level tasks while avoiding interruptions and restarts of the second-level tasks. For example, the community monitoring task did not stop because traffic accident identification has a higher priority; instead, it continued running by migrating some data to adjacent nodes, truly achieving seamless coexistence of multiple priority tasks and maximizing the distributed resource advantages of edge nodes.

[0041] To better match the second edge node, further, before matching the second edge node from multiple edge nodes based on the migration sub-data, the first edge node encapsulates the migration task. The process of determining the second edge node executed by the cloud computing center, namely, the sub-steps of S1240, include S1241~S1244: S1241, selecting resource-sufficient nodes from multiple edge nodes that can meet the hardware resource requirements of the migration task based on the running status of multiple edge nodes; S1242, determining the fit between the data resource information cached by the edge node and the resource requirement information based on the resource requirement information of the migration task and the data resource information of the global cache directory; S1243, sorting multiple edge nodes according to the fit between the data resource information and the resource requirement information; S1244, selecting the second edge node from the resource-sufficient nodes based on the fit. Specifically, in S1244, the resource-sufficient node with the highest fit can be determined as the second edge node.

[0042] The matching logic for the second edge node is further refined through S1241~S1244. After the migration task is encapsulated from the first edge node, the cloud computing center does not randomly select the target node, but uses a three-layer screening process of hardware filtering, data adaptation, and comprehensive sorting to ensure that the selected node can both support the migration task and minimize data transmission and startup costs.

[0043] Among them, resource-sufficient nodes refer to edge nodes that meet the "hardware resource requirements" (such as the number of CPU cores, memory capacity, and storage IOPS) of the migration task, which are the basic prerequisites for task operation; adaptability refers to the degree to which the data resources on which the second-level task depends are cached in each edge node; the data resource information in the global cache directory is a list of commonly used data (such as model files and historical logs) that have been cached in each edge node, providing a basis for judging the degree of data localization.

[0044] First, the cloud computing center, based on the hardware resource requirements of the migration task (such as the number of CPU cores and memory capacity, derived from the migration task description file encapsulated by the first edge node), and combined with the real-time monitoring of the edge node's running status (node ​​resource usage data synchronized through the global cache directory), filters out all nodes with sufficient resources—that is, edge nodes whose hardware configuration can meet the requirements for running the migration task. This step is a fundamental threshold, ensuring that the nodes have the capacity to handle task execution.

[0045] Next, the core assessment of data adaptability begins: the cloud computing center extracts the data resource requirements of the migration task (identifying which data is necessary for task execution, such as historical anomaly annotation files from community monitoring, model parameters, etc.) and precisely compares this information with the data resource information in the global cache directory (recording the data list and versions cached by each edge node), calculating the adaptability of each resource-sufficient node. Here, adaptability is a purely quantitative indicator of data locality: if a node has cached all the data required by the task, the adaptability is recorded as the highest (e.g., 100 points); if only some key data is cached, the adaptability is proportionally reduced (e.g., caching 80% of key data earns 80 points); if no data is cached at all, the adaptability is recorded as 0 points. Subsequently, the system sorts resource-sufficient nodes from highest to lowest adaptability, ultimately selecting the node with the highest adaptability as the second edge node—that is, the node that caches the most complete set of data required by the task—ensuring that the migration task can directly call local data to start after landing, without waiting for remote data transmission.

[0046] Previously, due to the need for Node A's resources for the first-level task (traffic accident identification), Node A needed to migrate some data for the second-level task (4-7 days of video recording analysis of community surveillance). The data resource requirements for this migration task were clearly defined as "processed 3 days of anomaly annotation data (version v1.2) + TensorFlow 2.5 model file (version 2023.08)". The cloud computing center first selected nodes with sufficient resources: Node B (roadside unit edge node, 2 CPU cores, 4GB memory, 30% load, cached "3 days of anomaly annotation data v1.2" but not the model file), Node C (community service center edge node, hardware met and cached "TensorFlow 2.5 model 2023.08" but not the annotation data), and Node D (regional aggregation edge node, hardware met and cached both "3 days of anomaly annotation data v1.2" and "TensorFlow 2.5 model 2023.08").

[0047] The adaptation calculation phase begins: the migration task requires two sets of key data. Node D caches all of them (adaptability score 100), while nodes B and C each cache 50% (adaptability score 50). Therefore, the system selects node D, with the highest adaptation score, as the second edge node. After the migration task is issued, node D directly calls the locally cached annotation data and model files to start the analysis, without needing to pull data from the cloud or other nodes. The task initialization time is reduced from the original 150ms to 5ms, seamlessly connecting with the existing progress of node A (which has already processed the first 3 days of data). This ensures that the community monitoring and analysis task is not interrupted due to resource migration, with an overall progress delay of only 2 seconds (far below the 10-second threshold allowed by the business).

[0048] By prioritizing data locality in the matching logic, the system ensures efficient initiation of migration tasks and maintains proactive collaboration in conflict scenarios. The first-level task (traffic accident identification) quickly acquires resources, while the second-level task (community monitoring and analysis) avoids restarts or long wait times by migrating to node D where data is already available. For smart city scenarios requiring multiple parallel services and high data dependence, this provides crucial support for edge computing to reduce end-to-end latency and improve resource utilization.

[0049] In this embodiment, in response to the reading of a first-level task, a first edge node is matched from multiple edge nodes based on the first-level task. The data resource base of the second-level task in the first edge node is divided into multiple sub-data. Based on the execution level of the second-level task, migration sub-data in the second-level task is determined from the multiple sub-data. Based on the migration sub-data, a second edge node is matched from multiple edge nodes. In order to avoid resource competition between the latency-sensitive first-level task and the latency-sensitive second-level task in the first edge node, the second-level task is migrated to the second edge node, thereby avoiding the competition conflict between the first-level task and the second-level task and ensuring that the execution resources of the first-level task and the second-level task are sufficient.

[0050] Example 2: The second edge node is used to execute S3310~S3130: S3110, receive the migration task; S3120, execute the migration task and obtain the returned data; S3130, return the returned data to the initiator of the second-level task.

[0051] Preferably, the initiating end has mobility; the cloud computing center is also used to determine the transition edge node where the initiating end is currently located based on the coverage of multiple edge nodes and the current location of the initiating end; the second edge node is also used to send the returned data to the transition edge node; the transition edge node is used to return the returned data to the initiating end.

[0052] When the second edge node completes the migration task and generates return data, if the initiating end (such as a vehicle terminal or mobile terminal) has moved to the coverage area of ​​the new edge node, the system will transfer the data through a transition edge node to ensure that the results are accurately delivered.

[0053] Among them, the mobility of the initiating device refers to the characteristic that the network access point of the task initiating device (such as a moving vehicle or mobile robot) switches from the original edge node to a new coverage node due to the change of physical location; the transition edge node is the current access node dynamically matched by the cloud computing center according to the real-time location of the initiating device and the coverage of the edge node, which undertakes the responsibility of data relay and avoids the return data not being delivered due to the change of the location of the initiating device.

[0054] First, the second edge node receives the migration task, which has been selected and distributed by the cloud computing center based on data compatibility. This task carries complete context and sub-data (such as the 4-7 day video recording analysis task received by node D in the previous example). Next, the node executes the task and generates return data, which may include analysis results (such as "5 abnormal behaviors were detected in 4-7 days"), intermediate logs, or updated model parameters. Finally, the node needs to send the returned data back to the initiating node. However, due to the mobility of the initiating node, direct transmission may result in data loss or delay due to location offset. Therefore, a transitional edge node is introduced as a relay.

[0055] For special handling of mobile initiators, the cloud computing center will simultaneously perform location tracking and node matching operations.

[0056] By monitoring the location information of the initiating end (such as GPS coordinates and base station signals) and combining it with the coverage area of ​​each edge node (pre-stored geofencing data), the system determines the current actual transition edge node where the initiating end is located (for example, if a vehicle terminal moves from the coverage area of ​​node A into the coverage area of ​​node B, the transition edge node changes to node B). Subsequently, the second edge node sends the returned data to this transition edge node (instead of directly to the initiating end), and the transition edge node pushes the data to the initiating end through its local network (such as 5G slicing or Wi-Fi Direct). This design utilizes the localized communication capabilities of edge nodes to shorten the data transmission path and ensure that the mobile initiating end can receive results in real time.

[0057] Consider a smart city mobile scenario: Assume the initiator is a moving ambulance, initially located within the coverage of node A (an edge node near the hospital), initiating a second-level task of "real-time traffic navigation + patient vital sign monitoring." As the ambulance moves into the coverage area of ​​node B (an edge node near the emergency center), the cloud computing center uses GPS to determine its current transitional edge node as node B. At this point, node D (the second edge node) completes its migration task (analyzing real-time traffic conditions along the ambulance's route) and generates return data suggesting a right turn to avoid congestion, with an estimated arrival at the emergency center in 5 minutes. Node D does not directly send data to the ambulance but instead sends the result to transitional edge node B. Node B pushes the data to the ambulance's onboard terminal via a vehicle-to-everything (V2X) link, ensuring the driver receives navigation instructions within 100ms. Simultaneously, patient vital sign monitoring data is synchronized to the hospital's backend via node B. If the data were sent directly from node D to the moving ambulance without the transitional edge node, data packet loss might occur because the ambulance has already left node D's coverage area, delaying emergency decision-making.

[0058] In Example 2, the system supports flexible access from mobile initiators while ensuring the timeliness and accuracy of returned data. It is particularly suitable for scenarios such as vehicle navigation and mobile robot collaboration that require simultaneous movement, computation, and feedback, further amplifying the core advantages of edge computing localization services.

[0059] Example 3, as Figure 5 As shown, a second edge node is selected from resource-sufficient nodes based on adaptability, including steps S1310~S1390: S1310: Extract data dependency tags, data timeliness tags, and data volume tags from the migration sub-data. The data dependency tag identifies the association between resource requirement information and data resource information of resource-sufficient nodes; the data timeliness tag identifies data access latency sensitivity; and the data volume tag identifies the data size level of the task information. S1320: Extract resource sufficiency tags, data locality tags, and network coupling tags from resource-sufficient nodes. The resource sufficiency tag identifies the remaining hardware resource capacity; the data locality tag identifies the matching degree between locally cached data and the migration sub-data; and the network coupling tag identifies the communication latency level between resource-sufficient nodes and the first edge node. S1330: Based on the data dependency tags, data timeliness tags, and data volume tags of the migration sub-data, and the resource sufficiency tags and data locality tags of resource-sufficient nodes... S1340: Construct a semantic system between tasks, data, and nodes using attribute tags and network coupling degree tags; S1350: Abstract multiple edge nodes into graph nodes, where each graph node's attributes include: resource sufficiency, current load, and migration task context compatibility; S1360: Abstract the resource coupling relationships of multiple edge nodes into graph edges, where each graph edge's attributes include: data migration cost and task dependency; S1370: Based on the semantic system, determine the conflict value between graph nodes and graph edges, where if the semantic tags of resource-sufficient nodes and migration sub-data do not match, the conflict value is increased; S1380: Generate a conflict matrix between tasks and nodes, where the matrix element values ​​are the comprehensive conflict value between resource-sufficient nodes and migration sub-data, and the comprehensive conflict value is used to quantify migration risk; S1390: Divide risk levels according to the conflict value range, and perform a secondary sorting of nodes with the same risk level according to the resource sufficiency tag of resource-sufficient nodes; S1300: Determine the second edge node based on the risk classification results.

[0060] By refining the risk assessment and matching requirements of edge node migration tasks through S1310~S1390, the selection logic of the second edge node has been upgraded. It has shifted from a single data adaptability to multi-dimensional label fusion and graph model quantitative analysis. The optimal target node is determined by more comprehensive factors (data characteristics, node resources, network relationships, migration risks), avoiding migration failure or performance degradation caused by ignoring implicit factors (such as data timeliness and network latency).

[0061] Among them, the data dependency label of the migration sub-data indicates the strength of the association between the task data and the node cache, such as "strong dependency" indicating that the task needs to call the key intermediate results already cached by the node; the data timeliness label indicates the sensitivity of the data to access latency, such as "high timeliness" for real-time monitoring data and "low timeliness" for historical logs; the data volume label indicates the data size level, such as "large" (>1GB), "medium" (500MB-1GB), "small" (<500MB); the resource sufficiency label of the resource-sufficient node indicates the remaining hardware capacity, such as "high" (remaining CPU>50%, memory>40%), "medium", "low"; the data locality label, i.e. the data adaptability described in Example 1, indicates the degree of matching between the local cache and the migration data; the network coupling label indicates the communication latency level between the node and the first edge node, such as "low" (RTT<20ms), "medium", "high" (RTT>100ms).

[0062] First, the cloud computing center extracts the three major data tags of the migrated sub-data and the three major node tags of the resource-sufficient nodes. Based on these tags, a semantic system of task-data-node is constructed. For example, if the migrated sub-data is "real-time community monitoring anomaly labeling data" (data timeliness tag = high, data volume = medium), and the resource-sufficient node is "node D that caches this data and has high network coupling (RTT = 15ms)," then the relationship between the two in the semantic system is "high timeliness data needs to be matched with low latency nodes."

[0063] Next, the system abstracts edge nodes into graph nodes. Each node's attributes integrate resource sufficiency (remaining hardware capacity), current load (real-time operating pressure), and migration task context compatibility (whether it can support the environment the task depends on). The resource coupling relationships between nodes are abstracted into graph edges, with edge attributes including data migration cost (time / bandwidth consumption for migrating data from the first edge node to the target node) and task dependency (whether the target node depends on data from other nodes). Subsequently, conflict values ​​are calculated based on a semantic system: if a node's label does not match the label of the migrated sub-data (e.g., high-time-sensitivity data matching a node with low network coupling), the conflict value increases. For example, node E caches some data but has high network coupling (RTT=80ms), conflicting with the label of high-time-sensitivity data, thus increasing the conflict value. This approach combines the semantic system and graph structure to analyze conflicts.

[0064] Based on the conflict values, the system generates a conflict matrix, where each element represents the comprehensive conflict value of each resource-sufficient node (quantifying migration risk). Risk levels are then categorized according to conflict value ranges (e.g., "low risk" < 20 points, "medium risk" 20-50 points, "high risk" > 50 points). Nodes of the same risk level are then sorted a second time by resource margin label (prioritizing nodes with more remaining resources to avoid excessive load after migration). Finally, the node with the lowest risk level and highest resource margin is selected as the second edge node.

[0065] Continuing the case study of a smart city ambulance scenario: The migration task is for node A to migrate the sub-data of "4-7 days of community surveillance video anomaly analysis". Its data tags are: Data Dependency = Strong (requires calling the 3-day anomaly annotations already cached by node A), Data Timeliness = Medium (analysis needs to start within 1 minute), Data Size = Medium (800MB). Nodes with sufficient resources include: Node D (caches all data, network coupling = low (RTT = 15ms), resource sufficiency = high (remaining CPU = 60%, memory = 50%)), Node E (caches some data, network coupling = medium (RTT = 50ms), resource sufficiency = medium (remaining CPU = 40%, memory = 30%)), and Node F (does not cache data, network coupling = high (RTT = 100ms), resource sufficiency = high).

[0066] Semantic System Construction: Node D's labels perfectly match the migrated data (strong dependency + medium timeliness + medium volume → low conflict). Node E's conflict value increases due to incomplete caching (low data locality), and Node F has an extremely high conflict value due to uncached data (data locality = 0). Graph Model Analysis: Node D's graph node attributes are "high resource margin, 30% load, context compatibility (supports TensorFlow 2.5)", and its graph edge attributes are "data migration cost = low (migrating the remaining 50% of data from node A takes only 20ms), task dependency = high (can directly connect to node A's progress)". Node E's graph edge migration cost = medium (requires migrating 80% of data from node A, 500ms), and task dependency = medium. Conflict Matrix Display: Node D's overall conflict value = 10 points (low risk), Node E = 35 points (medium risk), and Node F = 80 points (high risk). Node D was ultimately selected as the second edge node. After the migration task started, due to the low network coupling and abundant resources of node D, the migration of 800MB of data was completed in only 30ms. The task started within 100ms, perfectly connecting with the progress of node A, and did not occupy too many resources of node D (more than 50% of the CPU was still available).

[0067] By capturing implicit relationships between data, nodes, and networks through multi-dimensional labels, and quantifying abstract factors into comparable risk values ​​using a graph model, the semantic system relies on node data information from a global cache directory. The node load of the graph model comes from state monitoring, and the calculation of migration costs incorporates the network coupling between nodes (derived from geofencing data of the coverage area). For mobile scenarios such as ambulances that are "data-dependent, time-sensitive, and resource-sensitive," this truly achieves secure, efficient, and seamless task collaboration between edge nodes.

[0068] Preferably, after S1390, the cloud computing center is further configured to: if the risk level of the resource-sufficient node is low and the resource margin label is high redundancy, generate a dismantling instruction to dismantle the migration task to the second edge node; if the risk level of the resource-sufficient node is medium and the resource margin label is not high redundancy, monitor the resource status of the second edge node, and generate a dismantling instruction to dismantle the migration task to the second edge node when the resource margin of the second edge node is increased to high redundancy.

[0069] After completing the risk classification and screening of the second edge node, the task dismantling is not triggered directly. Instead, the execution strategy is dynamically adjusted based on the resource redundancy of the node. This ensures that low-risk tasks are migrated as much as possible, while avoiding execution fluctuations of medium-risk tasks due to insufficient node resources.

[0070] Among them, the resource margin label is high redundancy, which means that the remaining hardware resources of the node far exceed the task requirements (such as remaining CPU > 60%, memory > 50%), and have sufficient buffer space to cope with sudden task loads; the risk level is low, which corresponds to the above conflict value < 20 points, that is, the task undertaker with a high degree of matching in data, network and resources.

[0071] For low-risk, high-redundancy tasks, execution can proceed immediately. If a node with sufficient resources has a low risk level (conflict value < 20 points) and a high resource redundancy label (remaining hardware resources far exceed task requirements), it indicates that the node not only has data matching and smooth network connectivity, but also sufficient resource reserves to handle the migration task execution, and will not be affected by resource contention. In this case, the cloud computing center directly generates a dismantling command, quickly distributing the migration task from the first edge node to this node, maximizing the utilization of the node's idle resources and shortening the task startup time.

[0072] For medium-risk nodes with low redundancy, execution needs to be delayed, and resource monitoring is required. If a node's risk level is medium (20 points ≤ conflict value ≤ 50 points) and its resource margin label is not high redundancy (remaining resources barely meet task requirements), the task will not be immediately dismantled. Instead, resource status monitoring will be initiated (by continuously monitoring the node's CPU and memory utilization). The dismantling command will only be generated when the node's resource margin increases to high redundancy (e.g., the node releases resources due to the completion of other tasks), to avoid a surge in node load caused by forced migration. For example, if node E originally has 40% remaining CPU (low redundancy), even if it is a medium-risk node, the task should only be executed after its remaining CPU increases to over 60%, ensuring that the node has sufficient resources to handle sudden requests during task execution.

[0073] Suppose the cloud computing center selects three candidate nodes: Node D (low risk = 10 points, resource margin = high redundancy (remaining CPU = 65%, memory = 55%)), Node E (medium risk = 35 points, resource margin = medium (remaining CPU = 40%, memory = 30%)), and Node F (high risk = 80 points, excluded). For Node D, because it meets the low risk + high redundancy criteria, the cloud computing center immediately generates a dismantling command to migrate the "4-7 days of video recording analysis of the community monitoring" task to Node D. The task starts within 100ms, seamlessly connecting with the progress of Node A. For Node E (if its risk level drops to medium due to conflict), the cloud computing center will initiate resource monitoring: when Node E's remaining CPU rises to 62% and memory rises to 52% (reaching the high redundancy standard) due to the completion of other short-term tasks, a dismantling command will be generated again. At this time, the task will be migrated to Node E for execution, avoiding task delays or lags caused by insufficient resources.

[0074] In Example 3, for the second edge node matching process of migration tasks in a distributed edge computing scenario, an intelligent scheduling method based on semantic modeling, coupling conflict quantification and multi-dimensional dynamic matching is proposed.

[0075] Traditional solutions for matching second edge nodes typically employ a single-dimensional selection strategy based on static resource reserves such as CPU and memory. This approach suffers from three fundamental flaws: First, it simplifies data characteristics, focusing only on data volume without modeling data dependencies (e.g., whether data depends on cached data from other nodes) and time sensitivity (e.g., the network latency requirements of real-time data). This leads to task failures after migration due to dependency breaks or excessive latency. Second, it fragments node capabilities, assessing only single-machine resource redundancy without considering the network coupling between nodes and the original task nodes (e.g., migrating large amounts of data across regions can consume WAN bandwidth), causing global resource contention. Third, it staticizes the matching process, failing to anticipate node resource fluctuations (e.g., nodes with recent load spikes may appear redundant but are actually unstable), leading to interruptions in migration tasks due to resource contention. These problems essentially stem from the failure to explicitly define the implicit coupling conflict within the task-data-node ternary relationship, making traditional matching methods ill-suited to the complexities of dynamic edge environments.

[0076] In Example 3, the matching of the second edge node is reconstructed into semantic explicitness, conflict quantification prediction, and dynamic matching avoidance.

[0077] First, a semantic system for tasks, data, and nodes is constructed, using multi-dimensional semantic tags to explicitly express implicit relationships. For migrated sub-data, tags are extracted: data dependency (indicating whether data depends on cached data from other nodes, e.g., related data depends on external nodes), data timeliness (indicating sensitivity to access latency, e.g., real-time data requires <10ms latency), and data volume (indicating migration cost, e.g., large volume is defined as >5GB). For candidate edge nodes, tags are extracted: resource sufficiency (indicating remaining hardware capacity, e.g., high redundancy is >70% remaining resources), data locality (indicating the proportion of locally cached matching data, e.g., strong locality is >80%), and network coupling (indicating communication latency with the original task node, e.g., neighboring nodes are RTT <10ms). These tags transform the key attributes of tasks, data, and nodes into computable semantic units, solving the problem that traditional methods cannot understand the intrinsic relationships between data and nodes.

[0078] Secondly, implicit risks are quantified through a coupling conflict matrix, transforming semantic label differences into measurable conflict values. Four conflict dimensions are defined: 1. Data dependency breakage risk: If the migrated data is related data and the candidate node does not cache its dependencies, the conflict value increases by 2; 2. Data locality loss risk: If the migrated data is real-time data and the candidate node has no locality, the conflict value increases by 1; 3. Migration cost risk: If the candidate node is a remote node and the migrated data is large-volume, the conflict value increases by 1; 4. Resource fluctuation risk: If the recent resource utilization fluctuation of the candidate node is >20%, the conflict value increases by 1. The final output is a coupling conflict value (0-5 points), making implicit risks explicit into comparable quantitative indicators. For example, if a migrated sub-data consisting of related data, real-time data, and large volume matches a candidate node with no locality, a remote node, and large resource fluctuations, the conflict value will be close to 5 points, allowing the system to pre-determine it as a high-risk node.

[0079] Finally, a dynamic matching system is implemented across three dimensions: risk, resources, and context, to achieve the globally optimal node selection. The comprehensive scoring model integrates three indicators: migration risk (40% weight, using the inverse ratio after conflict value normalization); resource adaptation (30% weight, calculating the matching ratio between task resource requirements and actual node resources, e.g., CPU requirement matching degree = candidate node remaining CPU / task CPU requirement); and context continuity (30% weight, evaluating the consistency between the node's environment configuration and the original node, e.g., a +1 score for matching container image versions and dependency library versions). The comprehensive scoring formula is: Node matching score = 0.4 × (1 - conflict value / 5) + 0.3 × resource requirement matching degree + 0.3 × context matching degree.

[0080] Then, nodes with a score > 0.8 are selected as high-priority candidates. If multiple nodes exist, the node with the lowest network latency to the first edge node is selected. If there are no high-priority nodes, the expansion of the cloud computing center's elastic resource pool is triggered.

[0081] By using semantic modeling and conflict quantification, the failure rate of migration tasks caused by data dependency breaks or resource fluctuations is reduced; prioritizing neighboring nodes and strong local nodes shortens migration latency; resource utilization is improved, and the global matching strategy avoids resource crowding out of the original task nodes, thus improving the overall resource utilization of edge nodes.

[0082] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program code. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0083] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A distributed storage resource scheduling system based on edge computing, characterized in that, The cloud computing center and a plurality of edge nodes subordinate to the cloud computing center; the cloud computing center is configured to: in response to reading of a first-level task, match a first edge node from the plurality of edge nodes according to the first-level task; split a data resource basis of a second-level task in the first edge node to obtain a plurality of sub-data; determine a migration sub-data in the second-level task from the plurality of sub-data according to an execution degree of the second-level task; match a second edge node from the plurality of edge nodes according to the migration sub-data; issue the first-level task to the first edge node; the first edge node is configured to: extract context information of the second-level task; encapsulate the second-level task according to the context information to obtain a migration task; and disassemble the migration task to the second edge node; wherein the cloud computing center is further configured to: in response to receiving a to-be-assigned task, parse the to-be-assigned task to obtain a time delay property, a task duration and a resource occupation of the to-be-assigned task; if the time delay property of the to-be-assigned task is delay-sensitive, the task duration is shorter than a preset time threshold, and the resource occupation is greater than a preset occupation threshold, determine the to-be-assigned task as the first-level task; if the time delay property of the to-be-assigned task is delay-sensitive, the task duration is longer than or equal to the preset time threshold, and the resource occupation is less than or equal to the preset occupation threshold, determine the to-be-assigned task as the second-level task; read a configuration file of the to-be-assigned task to determine a data resource basis required when the to-be-assigned task is executed; match the data resource basis from a pre-stored global cache directory to determine an execution edge node for executing the to-be-assigned task from the plurality of edge nodes; and assign the to-be-assigned task to the execution edge node.

2. The system of claim 1, wherein, The migration task includes a description file and task information corresponding to the plurality of sub-data, the description file includes environment configuration information, resource requirement information and start command information; the environment configuration information is used to describe environment support required when the plurality of sub-data are executed, the resource requirement information is used to describe hardware resource requirement and data resource requirement when the plurality of sub-data are run, and the start command information is used to describe a start command when the plurality of sub-data are run.

3. The system of claim 2, wherein, The global cache directory includes node information of the plurality of edge nodes and data resource information cached by the plurality of edge nodes respectively; and the cloud computing center is further configured to listen to running states of the plurality of edge nodes. The matching the second edge node from the plurality of edge nodes according to the migration sub-data comprises: screening resource sufficient nodes from the plurality of edge nodes according to running states of the plurality of edge nodes, the resource sufficient nodes being able to meet hardware resource demand of the migration task; determining an adaptation degree of data resource information cached by the edge node and resource demand information of the migration task according to the resource demand information and the data resource information of the global cache directory; sorting the plurality of edge nodes according to the adaptation degree of the data resource information and the resource demand information; and screening the second edge node from the resource sufficient nodes according to the adaptation degree.

4. The system of claim 3, wherein, The second edge node is configured to: receive the migration task; execute the migration task to obtain return data; and return the return data to an initiating end of the second-level task.

5. The system of claim 4, wherein, The initiating end has mobility, and the cloud computing center is further configured to determine a transition edge node in which the initiating end is currently located according to a coverage range of the plurality of edge nodes and a current position of the initiating end; the second edge node is further configured to send the return data to the transition edge node; and the transition edge node is configured to return the return data to the initiating end.

6. The system of claim 5, wherein, The screening the second edge node from the resource sufficient nodes according to the adaptation degree comprises: extracting a data dependency label, a data timeliness label and a data volume label of the migration sub-data, wherein the data dependency label is used to identify an association relationship between the resource demand information and data resource information of the resource sufficient node, the data timeliness label is used to identify a data access delay sensitivity type, and the data volume label is used to identify a data size level of the task information; extracting a resource sufficiency label, a data locality label and a network coupling degree label of the resource sufficient node, wherein the resource sufficiency label is used to identify a hardware resource remaining capability, the data locality label is used to identify a matching degree of local cache data and the migration sub-data, and the network coupling degree label is used to identify a communication delay level of the resource sufficient node and the first edge node; constructing a semantic system among tasks, data and nodes according to the data dependency label, the data timeliness label and the data volume label of the migration sub-data, and the resource sufficiency label, the data locality label and the network coupling degree label of the resource sufficient node; and screening the second edge node from the resource sufficient nodes according to the semantic system.

7. The system of claim 6, wherein, The filtering the second edge node from the resource sufficient node according to the semantic system comprises: abstracting the plurality of edge nodes as graph nodes, wherein the node attribute of each graph node comprises: resource margin, current load, migration task context compatibility; abstracting the resource coupling relationship of the plurality of edge nodes as graph edges, the edge attribute of each graph edge comprises: data migration cost and task dependency degree; determining the conflict value of the graph node and the graph edge based on the semantic system, wherein if the resource sufficient node and the semantic label of the migration sub-data do not match, the conflict value is increased; generating a conflict matrix between tasks and nodes, the matrix element value of the conflict matrix is the comprehensive conflict value of the resource sufficient node and the migration sub-data, and the comprehensive conflict value is used to quantify the migration risk; and filtering the second edge node from the resource sufficient node according to the conflict matrix.

8. The system of claim 7, wherein, The filtering the second edge node from the resource sufficient node according to the conflict matrix comprises: dividing the risk level according to the conflict value range; performing secondary sorting on the nodes of the same risk level according to the resource margin label of the resource sufficient node; and determining the second edge node according to the risk classification result.

9. The system of claim 8, wherein, After the second edge node is determined according to the risk classification result, the cloud computing center is further configured to: if the risk level of the resource sufficient node is low and the resource margin label is high redundancy, generating a disassembly instruction for disassembling the migration task to the second edge node; and if the risk level of the resource sufficient node is medium and the resource margin label is not high redundancy, monitoring the resource state of the second edge node, and generating a disassembly instruction for disassembling the migration task to the second edge node when the resource margin of the second edge node is improved to high redundancy.

Images