Stream computing task acceleration method and device

Abstract

The invention provides a stream computing task acceleration method. The method comprises the steps that real-time resource use indexes of task managers and nodes in stream computing operation are monitored; hot spot machines caused by vertical stretching are found and marked; identifying a performance bottleneck TM of which the real-time resource use index is continuously higher than a first preset threshold and a resource idle TM of which the real-time resource use index is lower than a second preset threshold; calculating a shareable idle limit, and summarizing the shareable idle limit to construct a job-level virtual resource pool; dynamically adjusting the resource limitation of the performance bottleneck TM on line by a progressive step length, and allocating the required resource quantity from a virtual resource pool; and continuously monitoring and iteratively adjusting based on a closed-loop feedback mechanism, and meanwhile, changing the dynamic recovery limit according to the idle TM load. The invention further correspondingly provides a stream computing task acceleration device. According to the method, the performance bottleneck can be dynamically eliminated, safe and efficient redistribution of resources in the operation is realized, the performance bottleneck is effectively solved, and the overall performance of the operation is improved.

Description

Technical Field

[0001] This invention relates to the fields of cloud computing and distributed computing technology, and in particular to a method and apparatus for accelerating runtime performance of stream computing tasks. Background Technology

[0002] Apache Flink is an open-source, distributed, high-performance stream processing framework whose core design is "stateful stream computing." Apache Flink can run real-time computing tasks of various scales on unbounded data streams with low latency, high throughput, and exactly-once state consistency guarantees, making it the de facto standard for stream computing. Traditionally, Flink tasks are typically deployed on Hadoop YARN clusters, only meeting basic task orchestration needs and providing coarse-grained resource management. To achieve better containerization, isolation, and elasticity, the industry is migrating it on a large scale to Kubernetes environments. This trend is closely related to the core business scenarios supported by Flink, such as real-time e-commerce recommendations, risk control and anti-fraud, and IoT monitoring. These scenarios require computing engines with extreme real-time response capabilities and dynamic scalability under fluctuating business loads, and Kubernetes is the ideal platform to achieve this operational agility and resource elasticity.

[0003] However, this migration process introduces many challenges.

[0004] 1. Rigid resource limits: In Kubernetes, the resource requests and limits of a Pod are fixed at creation. For stateful workloads like Flink Task Manager, fixed resource quotas cannot adapt to their dynamically changing computing needs.

[0005] 2. Performance is limited by the bottleneck Task Manager (TM): Stream computing jobs consist of multiple parallel tasks distributed across different Task Managers. Due to data skew or differences in computational complexity, the load between TMs is often severely unbalanced. Under static resource constraints, the throughput and latency of the entire job will be determined by the TM with the highest load, resulting in the "weakest link" effect.

[0006] 3. Limitations of Existing Vertical Scaling Technologies: The VPA (Vertical Pod Autoscaler) component provided by the Kubernetes community can adjust Pod resources based on historical usage, but it has fundamental flaws when applied to stateful streaming tasks. Adjusting resource requests typically requires rebuilding the Pod, which leads to the loss of Flink™ local state, causing job failures and restarts, failing to meet the high availability requirements of production environments. Furthermore, VPA adjustment requests increase the total budget for job resources, reducing the number of tasks that can run on the same cluster resources, thus increasing costs.

[0007] Existing technologies include solutions based on complex predictive models such as Markov decision processes (e.g., scaling methods and devices for stream processing engines, CN110941489A). The drawback of these solutions is that they attempt to use a complex and uncertain "brain" (MDP) to direct scaling, but neglect the most critical "state safety" bottom line for stateful tasks. Furthermore, their engineering complexity and insufficient global control over resources and nodes may lead to uncontrolled job resources, making it impossible to guarantee optimization under fixed costs. Summary of the Invention

[0008] In view of the problems in the background art, the purpose of this invention is to provide a solution that can dynamically and securely reallocate resources in a cloud-native environment without restarting the stateful task manager (TM), and ensure that the overall resource consumption of the job does not exceed the total budget, so as to optimize the runtime performance of stream computing tasks.

[0009] The statefulness, interconnectedness, and dynamism of stream computing tasks, along with their deployment constraints in cloud-native environments, collectively constitute a unique technical problem domain. Existing general-purpose resource management and acceleration solutions are designed to address the entirely different problem of resource contention among stateless processes in a single-machine environment. Directly applying conventional general-purpose computing techniques to stateful stream computing without creative modification not only fails to solve existing problems but also introduces catastrophic consequences such as state loss and job failures. Therefore, this invention proposes a complete, novel, and specifically targeted technical solution addressing the pain points in this field.

[0010] Specifically, this invention proposes a method for accelerating stream computing tasks, comprising: monitoring real-time resource usage metrics of each TM and node in a stream computing job; identifying and marking hotspot machines caused by vertical scaling; identifying performance bottleneck TMs whose real-time resource usage metrics exceed a first preset threshold and resource idle TMs whose real-time resource usage metrics fall below a second preset threshold within a set duration; calculating shareable idle quota and aggregating it to construct a job-level virtual resource pool, wherein the shareable idle quota is the difference between the resource request amount and the actual usage amount of the resource idle TMs; dynamically adjusting the resource limits of the performance bottleneck TMs online in incremental steps, with the required resources allocated from the virtual resource pool; continuously monitoring and iteratively adjusting based on a closed-loop feedback mechanism, while dynamically reclaiming quota according to changes in the load of idle TMs.

[0011] The present invention also proposes a stream computing task acceleration device, which includes a computer program that performs the method described above when executed.

[0012] This invention monitors real-time resource metrics of each Task Manager (TM) and node in a streaming computing job using a custom controller; identifies and prioritizes high-load nodes caused by vertical scaling; identifies performance bottleneck TMs with CPU utilization consistently above the high-water mark threshold and resource-idle TMs consistently below the low-water mark threshold; calculates the difference between the resource requests and actual usage of resource-idle TMs as the shareable idle quota, and aggregates these to construct a job-level virtual resource pool; dynamically adjusts the resource limits of performance bottleneck TMs online in incremental steps, allocating the required resources from the virtual resource pool and updating the resources.limits.cpu field online without triggering reconstruction; continuously monitors and iteratively adjusts based on a closed-loop feedback mechanism, while dynamically reclaiming quotas according to changes in the load of idle TMs.

[0013] This invention abandons the uncertainty of prediction and instead adopts a progressive closed-loop control mechanism based on direct perception of real-time physical load. By strictly limiting the adjustment of resources.limits.cpu to online dynamics without triggering container reconstruction, the state safety and continuity of stateful flow computing tasks are fundamentally guaranteed. Simultaneously, the unique "virtual resource pool" and resource quota accounting model ensure efficient and secure internal reallocation of resources while maintaining a strictly constant total resource budget for the job, thus overcoming performance bottlenecks at zero additional cost. This method not only avoids the engineering challenges brought by complex models but also achieves more robust and direct adaptive optimization to fluctuating production environment loads by introducing node-level hotspot handling and progressive feedback adjustment.

[0014] This invention introduces a closed-loop control mechanism of progressive vertical scaling and resource quota management. While ensuring task status safety and preventing job-level resource budget overruns, it dynamically eliminates performance bottlenecks, achieving safe and efficient resource reallocation within the job. This effectively solves performance bottlenecks caused by load imbalance and improves overall job performance. Typically, the performance bottleneck of stream computing tasks lies in insufficient CPU processing power due to increased data volume. When creating a TM (Streaming Machine), one core is paired with at least 4GB of memory. With JVM memory reclamation, memory generally does not become a bottleneck. Therefore, this invention primarily addresses performance bottlenecks by expanding CPU capacity.

[0015] In one implementation, the present invention achieves lossless performance acceleration: under the premise of ensuring that the total resource application budget for the operation is not exceeded, the resource constraints of the bottleneck™ are dynamically removed, directly overcoming the "barrel effect" and achieving a significant improvement in operation performance.

[0016] In one implementation, the present invention achieves absolute state security: by strictly avoiding modifications to resources.requests.cpu and only operating on resources.limits.cpu, which can be updated online, the risk of state loss due to container reconstruction is fundamentally eliminated, ensuring the continuity and reliability of stream computing tasks.

[0017] In one implementation, the present invention achieves efficient resource utilization: by constructing a virtual resource pool and an accounting mechanism, it achieves "peak shaving and valley filling" under a fixed total resource budget, dynamically allocating idle resources to components that urgently need resources, thereby significantly improving the overall utilization rate of cluster resources.

[0018] In one embodiment, the present invention achieves excellent stability and adaptability: the progressive allocation and closed-loop feedback mechanism enables the system to respond smoothly to load changes, avoids system oscillations caused by excessive single adjustments, has strong adaptability, and is suitable for the characteristics of flow fluctuations in production environments.

[0019] In one implementation, the present invention achieves high cloud-native compatibility: as an additional controller implementation in Kubernetes, the present invention does not require modification of the underlying code of the Flink stream computing engine, is transparent to users, and has good versatility and scalability. Attached Figure Description

[0020] To facilitate understanding of the invention, it will be described in more detail with reference to the specific embodiments shown in the accompanying drawings. These drawings depict only typical embodiments of the invention and should not be considered as limiting the scope of protection of the invention.

[0021] Figure 1 This is a diagram showing the overall system architecture of the device of the present invention.

[0022] Figure 2 This is a flowchart of the method of the present invention.

[0023] Figure 3 This is a flowchart illustrating one embodiment of the method of the present invention.

[0024] Figure 4 This is a schematic diagram comparing the load and resource limitations of each TM in a stream computing job before and after applying the method of this invention. Detailed Implementation

[0025] The embodiments of the present invention are described below with reference to the accompanying drawings to enable those skilled in the art to better understand and implement the present invention. However, the listed embodiments are not intended to limit the present invention. In the absence of conflict, the following embodiments and the technical features in the embodiments can be combined with each other, wherein the same components are indicated by the same reference numerals.

[0026] The following reference Figure 1-4 The technical solution of the present invention will be described below.

[0027] First Implementation Method like Figure 1 The overall system architecture of the present invention is described as shown.

[0028] The device of the present invention includes a Dynamic Scaling Controller, specifically comprising three units: (1) a monitoring data interface, used to obtain raw metrics from the metric storage cluster and perform aggregation calculations (maximum value, average value, etc.) within a preset time window; (2) a decision engine, which automatically generates corresponding operation instructions (expanding or shrinking a Pod) based on a closed-loop control cycle of "monitoring -> identification -> small-step adjustment -> re-monitoring"; and (3) a resource allocator, which executes the resource adjustment based on the results produced by the decision engine by calling the Kubernetes API Server interface. The Dynamic Scaling Controller is deployed as an independent Deployment in the target Kubernetes cluster. The Dynamic Scaling Controller is granted specific RBAC permissions to listen to Pod and node events, obtain resource metrics, and update Pod definitions.

[0029] The device of the present invention further includes: a complete monitoring system, (1) an indicator collector for collecting performance indicators of all Pods and nodes in the Kubernetes cluster and then writing them to the indicator storage cluster in real time.

[0030] The apparatus of this invention also includes a Flink Kubernetes Operator. The Flink Kubernetes Operator deploys and manages Flink jobs, ensuring native compatibility with the Kubernetes environment.

[0031] All communication between components uses the HTTPS protocol based on TLS certificates, ensuring the security and integrity of data transmission.

[0032] Second Implementation Method This invention also proposes a method for accelerating stream computing tasks, comprising S1-S4.

[0033] S101, monitor the real-time physical resource usage indicators of each task manager (TM) in the monitoring stream computing job and the real-time physical resource indicators of the node where it is located; based on the real-time physical resource usage indicators, identify nodes with excessive load due to vertical scaling and prioritize their handling, identify performance bottleneck TMs with resource utilization rates continuously higher than the first preset threshold (high water level threshold), and resource idle TMs with resource utilization rates continuously lower than the second preset threshold (low water level threshold).

[0034] S102, calculate the difference between the resource request amount and the actual usage amount of the resource idle TM, use it as the shareable idle quota, and summarize it to form a job-level virtual resource pool.

[0035] S103, dynamically increase the resource limits of the performance bottleneck™ in incremental steps, wherein the resources required for expansion come from the virtual resource pool, and the increase operation is implemented by updating the resources.limits.cpu field online without triggering a rebuild. The "dynamically increase in incremental steps" includes: the step size is a preset percentage of the resource request value resources.requests.cpu of the performance bottleneck™, which defaults to 20%.

[0036] S104, continuously monitor and iteratively adjust and reclaim resource quotas based on feedback. Continuous monitoring and iterative adjustment based on feedback includes: if the resource utilization rate of the performance bottleneck TM is still higher than the first preset threshold after adjustment, and the virtual resource pool still has available quota, then continue to increase its resource limits; if its resource utilization rate has dropped to a reasonable range, then stop adjusting. Resource quota reclamation includes: when the resource utilization rate of an idle resource TM increases, causing its shareable idle quota to decrease, gradually reduce the resource limits of the performance bottleneck TM previously expanded in S103 as needed. More specifically, the specific execution steps of resource quota reclamation include: first, sorting the expanded TMs from largest to smallest according to resources.limits.cpu / resources.requests.cpu, and then reducing them one step at a time. When adjusting to an unexpanded TM, re-sorting and starting again, until the shared resource pool quota is positive.

[0037] Preferably, before dynamically increasing the resource limit of the performance bottleneck TM, a node capacity check is performed. If the remaining allocable resources of the node where the performance bottleneck TM is located are insufficient, the next iteration cycle is directly entered.

[0038] Third Implementation Method Reference Figure 3 This embodiment describes a method comprising steps S201-S204.

[0039] S201: Monitors real-time physical resource metrics for each TM in the target stream computing job and for all nodes in the cluster.

[0040] The metrics collector continuously collects real-time physical resource metrics for each TM in the target stream computing job and for all nodes in the cluster. The core metrics include physical CPU utilization and / or memory usage.

[0041] S202: Take action against hotspot machines.

[0042] When monitoring detects that the physical CPU utilization of a node consistently exceeds a set threshold (e.g., 85%), it will affect the performance of all tasks running on that node and create instability risks. Therefore, the hotspot machine should be addressed immediately. The specific steps are as follows: 1) Identify Transaction Managers (TMs) that have been expanded in previous cycles and sort the TMs on the node as follows: The controller first filters out all TMs on the node whose resources.limits.cpu / resources.requests.cpu ratio is greater than 1 (i.e., they have been expanded). Then, they are sorted in descending order according to the actual CPU load exceeding the limit. The larger this value, the more excess resources the TM is using on the node, the higher its priority, and the more likely it should be scaled down.

[0043] 2) Progressive scaling down for each target TM: The controller reduces the limits of each target TM by one step (e.g., 20% of its requests value) according to the sorting results, and accumulates the amount of CPU resources reduced.

[0044] 3) Achieve the goal: When the cumulative reduction in CPU cores meets the set number, the scaling down will stop. This goal aims to safely reduce the node's CPU level to a stable range. The set number of cores is calculated as: (Current physical CPU level of the node - 60%) * Total CPU of the node.

[0045] S203, Performance Bottleneck Identification and Shared Quota Calculation.

[0046] 1) Performance Bottleneck™ Identification: If the CPU utilization of a certain™ continuously exceeds the high watermark threshold (e.g., 95%) for a stable period of time (e.g., 5 minutes), it is marked as a “Performance Bottleneck™” and resource expansion is required.

[0047] 2) Idle Resource TM Identification and Quota Calculation: If the CPU utilization of a TM is consistently below the low watermark threshold (e.g., 80%), it is marked as an "Idle Resource TM". The core principle is to calculate the difference between the requested resource amount multiplied by the low watermark threshold and the actual usage, which serves as the TM's 'shareable idle quota'. Here, the portion between the low watermark threshold and the resource limit is not used for sharing; this is primarily to account for fluctuations during Task Manager operation. For example, if a TM requests 2 CPU cores but only uses an average of 0.5 cores, its shareable quota is 2 * 0.8 - 0.5 = 1.1 cores.

[0048] 3) Job-level Virtual Resource Pool Construction: Aggregate the shareable idle quota of all idle TMs to form a job-level "virtual allocable resource pool". This pool represents the total amount of elastic resources that can be safely redistributed within the job without modifying any TM resource requests.

[0049] 4) Node capacity verification: Before subsequent resource allocation, verify whether the node where the target "performance bottleneck™" is located has enough remaining allocable resources (e.g., the node's CPU physical water level is below 60%) to avoid triggering node-level resource competition.

[0050] S204: Progressive resource allocation and closed-loop feedback control.

[0051] 1) Small-step resource allocation: For identified "performance bottlenecks™", the controller does not attempt to estimate their precise resource shortfall, but instead adopts a gradual strategy. During the initial adjustment, the increment is calculated based on the current CPU limit value, in preset steps (e.g., increasing `resources.requests.cpu` by 20%). Subsequently, the Kubernetes API is called to dynamically update the `resources.limits.cpu` field of the™ online, increasing its resource limit. This operation does not trigger a restart, ensuring the continuity of Flink production operations.

[0052] 2) Closed-loop feedback and iterative adjustment: After the adjustment is completed, the system enters the next monitoring cycle and makes feedback judgments based on the new monitoring data, including the following two situations.

[0053] In the first scenario, the performance bottleneck™ monitoring works as follows: If the CPU utilization of the™ is still higher than the high watermark threshold and there is still available quota in the virtual pool, then small-step resource allocation is repeated to continue increasing the resource limit for it; if the CPU utilization of the™ has dropped to a reasonable range, then the expansion operation is stopped and the current resource limit is considered to be the optimal solution to meet its load.

[0054] The second scenario involves monitoring idle resource pools (TMs). If the load on a particular TM increases, causing a reduction in its shareable quota, the controller will promptly update the virtual resource pool quota. If the quota deduction becomes negative, it means that resources need to be reclaimed from TMs that have already been expanded. First, the limits of all expanded TMs are adjusted to the actual load observed in the current period. If a shortfall still exists, resources are sorted by expansion size, and 20% of the original resources are deducted sequentially until the virtual resource pool quota is positive.

[0055] Through the closed-loop control cycle of "monitoring -> identification -> minor adjustments -> re-monitoring" described above, the system can automatically and adaptively drive the load of each processing unit (TM) to tend towards balance in order to meet the processing needs under different input data volumes. Ultimately, while keeping the total resource request volume of the job constant, by dynamically adjusting the resource limits of each TM, the system achieves fine-grained scheduling and maximum utilization of cluster resources within the job, thereby significantly improving the overall throughput of the job and reducing data processing latency.

[0056] Fourth Implementation Method To more clearly illustrate the detailed workflow of this invention, a Flink stream processing job containing three Task Managers (TMs) will be used as an example. This job runs on a Kubernetes cluster, with each TM having 1 CPU request and an initial limit of 1 core. Therefore, the total resource request budget for this job is 3 cores. The controller's decision cycle is set to 5 minutes, the high-water mark threshold is set to 95%, the low-water mark threshold is set to 80%, and the incremental step size is set to 20% of the requests value.

[0057] First decision-making cycle: S301 monitors and identifies the average CPU utilization of each working node's TM over a set period of time.

[0058] Specifically, the controller queries the Prometheus cluster to obtain the average CPU utilization of each TM over the past 5 minutes. For example, TM-1 is at 98%, TM-2 at 30%, and TM-3 at 60%. TM-1's utilization consistently exceeds the 95% threshold and is marked as a "performance bottleneck TM". TM-2 and TM-3 both have utilization rates below 80% and are marked as "resource idle TMs".

[0059] S302, handle the hotspot machine.

[0060] Specifically, the controller checks the overall CPU utilization of each TM node. If it exceeds 85%, hotspot machine handling is required, referring to S202. This case does not involve this situation and will not be explained separately.

[0061] S303 calculates the shareable idle quota of the resource idle TM marked in S301.

[0062] Specifically, as in the example described above, TM-2 and TM-3 are "Resource Idle TMs". The formula for calculating the shareable quota is resources.cpu.request * low watermark threshold – number of cores currently in actual use. Therefore, the shareable quota for TM-2 is 1 core * 80% - 0.3 cores = 0.5 cores. The shareable quota for TM-3 is 1 core * 80% - 0.6 cores = 0.2 cores. The total quota for the virtual resource pool is 0.5 cores + 0.2 cores = 0.7 cores.

[0063] S304, Verify “Performance Bottleneck™” node: The controller verifies the node where TM-1 is located to confirm whether the node resources are sufficient (e.g., the average physical load in the previous cycle is less than 60%). If not, the controller skips this round of adjustment and proceeds directly to the next cycle.

[0064] S305, Incremental Adjustment Step Size: The controller calculates the adjustment step size as 1 core * 20% = 0.2 cores. Subsequently, it calls the Kubernetes API to dynamically update the `resources.limits.cpu` field of TM-1 from 1 core to 1.2 cores online. This operation does not trigger a container restart, ensuring the continuity of Flink task status. The remaining quota of the virtual resource pool is updated to 0.7 cores - 0.2 cores = 0.5 cores.

[0065] Second decision-making cycle: S401, Monitoring and Feedback: A new round of monitoring data for all TMs shows that TM-1's CPU utilization remains as high as 117% (due to its increased physical resource limit of 1.2 cores, resulting in enhanced computing power and processing of more data, but the load remains high), indicating that the performance bottleneck has not been completely resolved. The utilization rates of TM-2 and TM-3 have not changed significantly.

[0066] S402, further adjustment: The virtual resource pool still has 0.5 cores of quota, and the node resources are sufficient. The controller adds another 0.2 cores of resource to TM-1, increasing its limits from 1.2 cores to 1.4 cores. The remaining quota of the virtual resource pool is reduced to 0.3 cores.

[0067] Third decision cycle and convergence: S501, Monitoring and Convergence: Monitoring revealed that TM-1's CPU utilization stabilized at 132% (relative to the 1.4-core limit), indicating that its data processing capacity and input load were balanced and no longer a bottleneck. The controller stopped expanding TM-1's capacity. At this point, TM-1 effectively improved its processing capacity by borrowing idle capacity from TM-2 and TM-3, resulting in a significant increase in overall job throughput.

[0068] Dynamic resource recycling case study: 1. Scenario Change: After a period of time, the business load changes. The CPU utilization of TM-2 increases to 0.5 cores, and its shareable quota decreases to 0.8 cores - 0.5 cores = 0.3 cores. The utilization of TM-3 increases to 0.85 cores, and its shareable quota decreases to 0 cores (0.8 cores - 0.85 cores = -0.05 cores, the quota is negative, indicating that it has no idle resources to share, and the total quota of the resource pool should be 0, not a negative value).

[0069] 2. Quota recalculation and triggering recycling: Since the cumulative capacity has been expanded by 0.4 cores, the total virtual resource pool quota is recalculated to 0.3 cores + 0 cores - 0.4 cores = -0.1 cores, triggering the resource recycling mechanism.

[0070] 3. Perform Reclamation: After sorting all TMs by expansion size, adjust the expanded TM-1 (currently limited to 1.4 cores) to the actual physical usage observed in the current period, reducing it from 1.4 cores to 1.3 cores. This reclamation releases 0.1 cores of resources, turning the virtual resource pool quota positive and restoring system balance. If the resource pool quota is still negative after adjusting all expanded TMs to the actual physical usage, start again from the first TM and reduce it step by step according to the preset step size until the resource pool quota turns positive. This process is also an online update and does not require restarting the container.

[0071] This invention, through the aforementioned continuously running closed-loop control cycle of "monitoring -> identification -> calculation -> minor adjustment -> re-monitoring," can automatically and adaptively drive the load of each TM within a stream computing job to tend towards balance. Ultimately, under the premise that the total resource request amount (i.e., total budget) of the job remains strictly constant, by dynamically and safely adjusting the resource limits of each TM, it achieves fine-grained scheduling and maximum utilization of cluster resources within the job, thereby significantly improving the overall throughput of the job and reducing data processing latency. Figure 4 The diagram visually illustrates the optimization effects of resource allocation and load within a job before and after applying this invention.

[0072] The embodiments described above are merely preferred embodiments of the present invention. The terms "in one embodiment," "in another embodiment," "in yet another embodiment," or "in still another embodiment" used in this specification all refer to one or more of the same or different embodiments according to this disclosure. Ordinary variations and substitutions made by those skilled in the art within the scope of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for accelerating stream computing tasks, characterized in that, include: Monitor the real-time resource usage metrics of each Task Manager™ and node in the streaming computing job; Identify and mark machines that are experiencing hotspots due to vertical scaling. Identify performance bottlenecks™ and resource idleness™ that are above a first preset threshold and below a second preset threshold for real-time resource usage metrics within a set duration. Calculate the shareable idle quota and aggregate it to construct a job-level virtual resource pool, where the shareable idle quota is the difference between the resource request amount and the actual usage amount of Resource Idle™; The resource limits of the performance bottleneck™ are dynamically adjusted online in incremental steps, and the required resources are allocated from the virtual resource pool. The system continuously monitors and iteratively adjusts based on a closed-loop feedback mechanism, while dynamically recovering credit based on changes in the load of idle TMs.

2. The method for accelerating stream computing tasks according to claim 1, characterized in that, The real-time resource usage metrics include: physical CPU utilization and / or memory usage.

3. The method for accelerating stream computing tasks according to claim 1, characterized in that, The operations for handling hotspot machines include: Identify the TMs that have been expanded in the previous cycle and sort the TMs on the current node according to the actual CPU load over-utilization. Progressively reduce the size of each target TM; The reduction in CPU capacity will stop when the cumulative reduction reaches the set number of cores.

4. The method for accelerating stream computing tasks according to claim 1, characterized in that, The operation of allocating resources from a virtual resource pool includes: Before allocating resources, verify whether the node containing the target performance bottleneck TM has enough remaining allocable resources to avoid triggering node-level resource contention.

5. The method for accelerating stream computing tasks according to claim 1, characterized in that, The incremental step-size dynamic online scaling of the performance bottleneck™ is achieved by updating the resources.limits.cpu field online without triggering container rebuilding.

6. The method for accelerating stream computing tasks according to claim 1, characterized in that, The progressive step size is a preset percentage of the resource request value resources.requests.cpu of the performance bottleneck™.

7. The method for accelerating stream computing tasks according to claim 1, characterized in that, Operations based on a closed-loop feedback mechanism for continuous monitoring and iterative adjustment include: If the resource utilization rate of the performance bottleneck™ is still higher than the first preset threshold after adjustment, and the virtual resource pool still has available quota, then the resource limit will continue to be increased; if its resource utilization rate has dropped to a reasonable range, then the adjustment will stop.

8. The method for accelerating stream computing tasks according to claim 1, characterized in that, The operation of dynamically reclaiming quota based on changes in the load of idle TMs includes: when the resource utilization of an idle TM increases, causing its shareable idle quota to decrease, the resource limits of the previously expanded performance bottleneck TMs are gradually reduced as needed.

9. The method for accelerating stream computing tasks according to claim 8, characterized in that, The operation of dynamically recovering credit based on changes in idle TM load includes: Sort the expanded TMs in descending order of resources.limits.cpu / resources.requests.cpu, and adjust them one step at a time. When adjusting to an unexpanded TM, reorder and start again, until the shared resource pool quota becomes positive.

10. A streaming computing task acceleration device, characterized in that, Includes a computer program, which, when executed, implements the method as described in any one of claims 1-9.

Images