A big data-based software development information real-time reporting management method

Abstract

The application discloses a kind of based on big data's software development information real-time reporting management method, it is related to software engineering technical field, including, through event index composite data sliding window aggregation, according to sliding window statistics establishment node index time sequence matrix and calculate delay prediction value, in combination with historical stable interval median and absolute median difference generate delay threshold baseline set and initial risk occupancy amount;Through node index time sequence matrix, delay prediction value, delay threshold baseline set and initial risk occupancy amount, determine reporting interval, priority score, batch threshold and retry backoff delay, multi-channel scheduling generates scheduled reporting flow;Scheduled reporting flow is in real time risk analysis, calculate risk index, risk level and correction factor, correct and atomized update backfill corrected reporting instruction set and flow control state.The application is improved by risk index, risk level and correction factor cooperative control, and the stability and reliability of multi-node reporting management.

Description

Technical Field

[0001] This invention relates to the field of software engineering technology, and in particular to a real-time reporting and management method for software development information based on big data. Background Technology

[0002] With the development of big data technology and distributed architecture, software development is usually carried out in parallel in a multi-node, multi-branch, and multi-tool environment. During this process, a large amount of multi-source event data and operational metrics are generated. Conventional software development information reporting methods usually adopt a fixed reporting interval and centralized data aggregation approach. Event data collected by each node is uploaded to the central processing end for aggregation and analysis. Information reporting is achieved through time-triggered or task queue mechanisms. By introducing standardized data formats and basic flow control strategies, general load fluctuations can be addressed.

[0003] As the scale and number of nodes in software projects increase, conventional software development information reporting methods become increasingly inadequate in handling large-scale concurrent reporting, asynchronous event jitter, and dynamic latency compensation. The fixed reporting interval mechanism has limitations in adapting to load fluctuations between nodes, causing latency backlogs on some nodes and data reporting ahead of schedule, affecting data timeliness and consistency. Furthermore, the static threshold monitoring strategy is insufficient in responding to sudden changes in risk, and cannot perform real-time risk adjustment when multi-source event data surges, resulting in a decrease in reporting efficiency and reliability. Summary of the Invention

[0004] In view of the aforementioned existing problems, the present invention is proposed.

[0005] Therefore, this invention provides a real-time reporting and management method for software development information based on big data to solve the problems of information reporting delay and inability to coordinate risk response in multi-node environments in existing technologies.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0007] This invention provides a real-time reporting and management method for software development information based on big data, comprising:

[0008] Deploy collection agents on multiple nodes to collect multi-source event data and operational metrics, preprocess the multi-source event data and operational metrics, and generate composite event metric data.

[0009] The event indicator composite data is aggregated by sliding window. By calculating the sliding window statistics, a node indicator time series matrix is ​​established. Based on the node indicator time series matrix, the delay prediction value is calculated. The delay threshold baseline set is generated by combining the median and absolute median difference of the historical stable interval, and the initial risk occupancy is output.

[0010] Based on the node indicator time series matrix, delay prediction value, delay threshold baseline set and initial risk occupancy, the reporting interval and priority score of each node are calculated. The batch threshold and retry backoff delay are determined according to the reporting interval. Multi-channel scheduling is performed according to the priority score to generate the scheduled reporting stream.

[0011] Real-time risk analysis is performed on the scheduled reporting stream to identify continuous failures, delay exceeding limits, and jitter anomalies. A set of risk indices is calculated, a set of risk levels is determined, and a set of correction factors is generated.

[0012] Based on the risk index set, risk level set, and correction factor set, the reporting interval, batch threshold, and retry backoff delay are dynamically corrected to obtain the corrected reporting instruction set and flow control status. The corrected reporting instruction set and flow control status are then atomically updated and fed back.

[0013] As a preferred embodiment of the real-time reporting and management method for software development information based on big data described in this invention, the multi-nodes include code hosting nodes, build nodes, test nodes, and deployment nodes.

[0014] As a preferred embodiment of the real-time reporting and management method for software development information based on big data described in this invention, the steps for preprocessing multi-source event data and operational indicators to generate composite event indicator data are as follows:

[0015] Deploy collection agents across multiple nodes to collect multi-source event data and operational metrics, perform time alignment, duplicate detection, and anomaly removal, and generate a standardized set of multi-source event data and a standardized set of operational metrics.

[0016] The standardized multi-source event data set and the standardized operational indicator set are normalized and their fields are uniformly mapped. They are then matched and merged based on node identifiers and timestamps to generate a node-level fused data set.

[0017] Perform quality assessment on the node-level fused dataset to obtain composite data of event metrics.

[0018] As a preferred embodiment of the real-time reporting and management method for software development information based on big data described in this invention, the steps of performing sliding window aggregation on composite event indicator data and establishing a time-series matrix of node indicators by calculating sliding window statistics are as follows:

[0019] Perform sliding window aggregation on the composite data of event indicators, and extract a subset of the composite data of event indicators according to the sliding window width and step size;

[0020] For each event indicator composite data subset, calculate the window mean, window variance, and window jitter intensity, and then concatenate them in chronological order to generate a time series matrix of node indicators.

[0021] As a preferred embodiment of the real-time reporting and management method for software development information based on big data described in this invention, the steps are as follows: Based on the time-series matrix of node indicators, the predicted delay value is calculated; combined with the median and absolute median difference of historical stable intervals, a baseline set of delay thresholds is generated; and the initial risk occupancy is output.

[0022] Based on the node identifier, the node indicator time series matrix is ​​partitioned, and the delayed prediction value is calculated by weighted moving linear regression function to obtain the node delayed prediction value sequence.

[0023] The predicted node delay values ​​are compared with the combined node feature sequences to extract historical stable intervals.

[0024] By calculating the median and absolute median difference of historical stable intervals, a set of stable statistics is generated. The delay threshold baseline set for each node is calculated using the threshold baseline generation function. The deviation between the node delay prediction value sequence and the delay threshold baseline set is compared to calculate the initial risk occupancy.

[0025] As a preferred embodiment of the real-time reporting and management method for software development information based on big data described in this invention, the following steps are taken: Based on the node indicator time series matrix, latency prediction value, latency threshold baseline set, and initial risk occupancy, the reporting interval and priority score of each node are calculated; and the batch threshold and retry backoff delay are determined according to the reporting interval.

[0026] Based on the node indicator time series matrix, delay prediction value, delay threshold baseline set and initial risk occupancy, after loading according to the node identifier, feature weighted fusion is performed to generate a comprehensive load intensity set. By calculating the reporting interval and priority score, a reporting interval set and a priority score set are generated.

[0027] Based on the reporting interval, calculate the batch threshold for each node and generate a set of batch thresholds;

[0028] Based on the reporting interval set, the predicted delay value, the delay threshold baseline set, and the initial risk occupancy, the retry backoff delay is calculated, the retry backoff delay set is obtained, and the reporting interval set, priority score set, batch threshold set, and retry backoff delay set are encapsulated to generate a dynamic scheduling result set.

[0029] As a preferred embodiment of the real-time reporting and management method for software development information based on big data described in this invention, the step of generating a scheduled reporting stream by performing multi-channel scheduling based on priority scoring includes the following steps:

[0030] After loading the dynamic scheduling result set according to the node identifier, sort it from high to low according to the priority score, and then allocate channels. According to the range of priority scores, the nodes are allocated hierarchically, and a channel allocation result set is generated.

[0031] Perform intra-channel scheduling on the channel allocation result set, and execute dynamic scheduling strategy based on the reporting interval set and batch threshold set to generate intra-channel data set to be sent;

[0032] Calculate the reporting weight for the set of data to be sent in the channel, obtain the reporting weight set in the channel, and aggregate the reporting weight set in the channel with the set of data to be sent in the channel to generate a scheduled reporting stream.

[0033] As a preferred embodiment of the real-time reporting and management method for software development information based on big data described in this invention, the steps of performing real-time risk analysis on the scheduled reporting stream, identifying continuous failures, delay exceeding limits, and jitter anomalies, calculating a risk index set, determining a risk level set, and generating a correction factor set are as follows.

[0034] After partitioning the scheduled reporting streams according to node identifiers, continuous failure detection is performed. By statistically analyzing the reporting result sequence, a set of continuous failure rates is generated. The baseline set of delay thresholds is then jointly analyzed with the reporting delay sequence in the scheduled reporting streams to calculate the average delay and generate a set of delay over-limit ratios.

[0035] The set of delay exceedance ratios and the reported delay sequence are differentially processed to calculate the continuous delay change rate and generate a jitter intensity set.

[0036] The risk index set is calculated by weighting and fusing the continuous failure rate set, the latency exceeding the limit ratio set, and the jitter intensity set. The node risk status is divided into different risk levels according to the risk index set to obtain the risk level set. The average latency, latency threshold baseline, continuous failure rate set, and jitter intensity set are then weighted and fused to generate a weighted factor set.

[0037] As a preferred embodiment of the real-time reporting and management method for software development information based on big data described in this invention, the steps of dynamically correcting the reporting interval, batch threshold, and retry backoff delay based on a risk index set, a risk level set, and a correction factor set, and obtaining the corrected reporting instruction set and flow control status, are as follows:

[0038] The risk index set, risk level set, and correction factor set are adjusted for reporting interval, batch threshold, and retry backoff delay, and then integrated to generate a corrected reporting instruction set.

[0039] The revised reporting instruction set, along with the risk index set, risk level set, and correction factor set, are summarized to generate a flow control status set.

[0040] As a preferred embodiment of the real-time reporting and management method for software development information based on big data described in this invention, the steps of atomically updating and re-feeding back the corrected reporting instruction set and flow control status are as follows:

[0041] The modified reporting instruction set and flow control status are hashed and locked by nodes and transactions to generate a locked status set. The locked status set is then subjected to instruction difference detection, hash verification and atomic update. The modified reporting instruction set and flow control status are atomically written to generate an atomic update result set.

[0042] The atomic update result set is fed back into the state. The corrected reporting instruction set and flow control state are jointly encoded and fed back into the state to generate a feedback stream. The node indicator time series matrix is ​​updated to generate a closed-loop synchronization result set.

[0043] The beneficial effects of this invention are as follows: by performing sliding window aggregation and delay threshold baseline set generation on composite event indicator data, dynamic statistics and delay prediction analysis of the time series matrix of node indicators are realized, ensuring the timeliness and continuity of the reporting process; through real-time collaborative control of risk index, risk level and correction factor, the stability and reliability of multi-node reporting management are improved. Attached Figure Description

[0044] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0045] Figure 1 A flowchart for a real-time reporting and management method for software development information based on big data.

[0046] Figure 2 A flowchart for generating composite data of event metrics.

[0047] Figure 3 A flowchart for establishing the time series matrix of node indicators and generating the baseline for delay thresholds.

[0048] Figure 4 This is a flowchart for dynamic correction of risk analysis and reporting parameters. Detailed Implementation

[0049] 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.

[0050] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0051] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0052] Reference Figures 1-4 This is one embodiment of the present invention, which provides a real-time reporting and management method for software development information based on big data, including the following steps:

[0053] S1. Deploy collection agents on multiple nodes to collect multi-source event data and operational metrics, preprocess the multi-source event data and operational metrics, and generate composite event metric data.

[0054] The multiple nodes include code hosting nodes, build nodes, test nodes, and deployment nodes.

[0055] Multi-source event data includes code commit records, build logs, test results, and deployment status.

[0056] Performance metrics include resource usage, network bandwidth, latency, and packet loss rate.

[0057] Deploy collection agents across multiple nodes to collect multi-source event data and operational metrics, perform time alignment, duplicate detection, and anomaly removal, and generate standardized multi-source event data sets and standardized operational metric sets.

[0058] Furthermore, lightweight data acquisition agents are deployed on multiple nodes of the software development environment. Each acquisition agent registers with the node through a message middleware registry center and generates a unique node identifier locally. Multi-source event data and operational metrics are collected in real time to generate a node sampling data set. The acquisition agents synchronize time based on the global time service (NTP protocol) and record the timestamp of the sampling. Time alignment, duplicate detection, and anomaly removal are performed on the node sampling data set to generate a standardized multi-source event data set and a standardized operational metric set.

[0059] It should be noted that time alignment refers to normalizing the sampling time of each node to the global time base; duplicate detection refers to using a hash index to remove duplicate event records; and anomaly detection refers to identifying and removing records with abnormal sampling delays through a time delay distribution deviation detection algorithm.

[0060] The standardized multi-source event data set and the standardized operational indicator set are normalized and their fields are uniformly mapped. Then, they are matched and merged according to node identifiers and timestamps to generate a node-level fused data set.

[0061] Furthermore, by using the min-max normalization method, the standardized multi-source event data set and the standardized operational indicator set are normalized and then uniformly mapped to generate a standardized sampling data set. Through key-value matching within the time window, the standardized sampling data set is fused. Based on node identifiers and timestamps, the data is matched and merged to construct a composite vector of event indicators. The composite vectors of event indicators of all nodes at all time steps are summarized to generate a node-level fused data set.

[0062] It should be noted that unified field mapping refers to mapping event fields from different source formats to a unified structure.

[0063] Perform quality assessment on the node-level fused dataset to obtain composite data of event metrics.

[0064] Furthermore, the node-level fused data set is subjected to quality assessment. Data quality scores are obtained through weighted fusion, all data quality scores are statistically analyzed, and a data quality score set is generated. The node-level fused data set and the corresponding data quality score set are matched and jointly mapped according to node identifier and time index to generate event indicator composite data.

[0065] S2. Perform sliding window aggregation on the composite data of event indicators, establish a node indicator time series matrix by calculating the sliding window statistics, calculate the delay prediction value based on the node indicator time series matrix, generate a delay threshold baseline set by combining the median and absolute median difference of the historical stable interval, and output the initial risk occupancy.

[0066] Perform sliding window aggregation on the composite data of event indicators, and extract a subset of the composite data of event indicators according to the sliding window width and step size.

[0067] Furthermore, the event indicator composite data is loaded in ascending order by timestamp, the sliding window width and step size are set, and the nodes are partitioned by key to generate a set of event indicator composite data to be aggregated. The set of event indicator composite data to be aggregated is then aggregated by sliding window, and a subset of event indicator composite data within the window is extracted according to the sliding window width and step size.

[0068] The composite data subset of event metrics includes latency, packet loss rate, bandwidth availability, and CPU utilization.

[0069] It should be noted that the sliding window width is determined based on the statistical average of the node reporting cycle and is sufficient to cover a complete reporting cycle. The step size is inversely proportional to the node reporting jitter intensity and is used to control the smoothness of the update.

[0070] For each event indicator composite data subset, calculate the window mean, window variance, and window jitter intensity, and then concatenate them in chronological order to generate a time series matrix of node indicators.

[0071] Furthermore, using an integral approximation sliding statistics method, the window mean, window variance, and window jitter intensity are calculated for each event indicator composite data subset. The window mean, window variance, and window jitter intensity are then statistically analyzed to generate a set of window statistics. This set of window statistics is then standardized by mapping to unit intervals and suppressing extreme values, resulting in a standardized set of window statistics. Finally, by concatenating node-level single-window features in chronological order from the standardized set of window statistics, a window feature vector is constructed. This window feature vector is then used to generate node-level feature rows arranged in ascending order over time, thus constructing a time-series matrix of node indicators.

[0072] It should be noted that, using the sliding statistical method with integral approximation, the window mean, window variance, and window jitter intensity are calculated for each subset of composite data for each event indicator, expressed as:

[0073] ;

[0074] ;

[0075] ;

[0076] in, Represents the window average. Indicates the width of the sliding window. Indicates the current time and location. Indicates node identifier, Represents the integral variable (time). This represents a subset of composite data representing event metrics. Indicates window variance. This indicates the intensity of window jitter.

[0077] Based on the node identifier, the node indicator time series matrix is ​​partitioned, and the delayed prediction value is calculated using a weighted moving linear regression function to obtain the node delayed prediction value sequence.

[0078] Furthermore, the node indicator time series matrix is ​​partitioned according to node identifier. The delay sequence, packet loss rate sequence, bandwidth availability sequence, and CPU availability sequence are extracted from the node indicator time series matrix of each node and linearly normalized to generate a node feature combination sequence. The delay prediction value is calculated by using a weighted sliding linear regression function, and the delay prediction values ​​are arranged in time order to obtain the node delay prediction value sequence.

[0079] It should be noted that the delayed predicted value is calculated using a weighted moving linear regression function, expressed as follows:

[0080] ;

[0081] in, Indicates node identifier exist The predicted delay value of time location, Indicates node identifier The intercept term, Indicates node identifier The regression coefficient of the first One portion, Indicates the node feature combination sequence in The first time position Each component.

[0082] It should be noted that, Using the least squares method, in the nearest... Sliding updates within a time step are represented as follows:

[0083] ;

[0084] in, Indicates the width of the sliding window. Indicates node identifier The feature matrix within the window, Indicates node identifier The corresponding delayed observation vector, Indicates node identifier The time decay weight matrix.

[0085] It should be noted that node identifiers are generated step-by-step using an exponential decay function. The time decay weights are constructed into a time decay weight matrix using the diag function.

[0086] The exponential decay function is expressed as:

[0087] ;

[0088] in, Indicates the time decay weight. Indicates the time decay coefficient. This indicates the most recent time position within the sliding window. This indicates the time position corresponding to the historical sample in the time series matrix of node indicators.

[0089] It should be noted that the time decay coefficient is used to control the weight decay rate of historical samples of node identifiers within the sliding time window. It is set by calculating the ratio of the volatility of node operation indicators to the length of the time interval of continuous historical samples covered by the current sliding window, and the value range is [0.01, 0.1]. The node delay prediction value sequence is compared with the node feature combination sequence to extract the historical stable interval.

[0090] Furthermore, based on the node delay prediction value sequence, the absolute value of the difference between adjacent prediction values ​​is calculated through the time step to obtain the delay change amplitude of adjacent time steps, thus obtaining the delay fluctuation amplitude sequence; based on the node feature combination sequence, at the same time step interval, the feature change rate is obtained by calculating the Euclidean distance increment of the node feature combination vector in the node feature combination sequence, setting the delay fluctuation threshold and the feature change threshold, and making a judgment according to the stability judgment condition. When the stability judgment condition is met, the time index of the node delay prediction value sequence and the node feature combination sequence is scanned to extract the time period set that meets the continuous stability condition, and the corresponding start time and end time are recorded to generate the historical stable interval.

[0091] It should be noted that the delay fluctuation threshold is set by statistically analyzing the fluctuation amplitude of the node delay prediction value sequence within the historical stable interval, taking the sum of the median and absolute median difference of the fluctuation amplitude of the node delay prediction value sequence within the historical stable interval. The value range of the delay fluctuation threshold is [0, b], where b is the maximum absolute value of the difference between adjacent prediction values ​​of the node delay prediction value sequence within the historical stable interval. The feature change threshold is set by statistically analyzing the feature change rate of the node feature combination sequence within the historical stable interval, taking the weighted value of the mean and standard deviation of the feature change rate of the node feature combination sequence within the historical stable interval. The value range of the feature change threshold is [0, c], where c represents the maximum value of the Euclidean distance increment of the node feature combination vector in the node feature combination sequence between adjacent time steps within the historical stable interval. The stability judgment condition is that the delay change amplitude within consecutive time steps is lower than the delay fluctuation threshold, and the feature change rate is lower than the feature change threshold.

[0092] By calculating the median and absolute median difference of historical stable intervals, a set of stable statistics is generated. The delay threshold baseline set for each node is calculated using the threshold baseline generation function. The deviation between the node delay prediction value sequence and the delay threshold baseline set is compared to calculate the initial risk occupancy.

[0093] Furthermore, by calculating the median and absolute median difference of the historical stable intervals, a set of stable statistics is generated. Based on the node delay prediction value sequence and the set of stable statistics, the delay threshold baseline for each node is calculated using the threshold baseline generation function. All delay threshold baselines are statistically analyzed to obtain the delay threshold baseline set.

[0094] It should be noted that the latency threshold baseline for each node is calculated using the threshold baseline generation function, and is expressed as follows:

[0095] ;

[0096] in, Indicates node identifier The baseline of the delay threshold, For node identification The median of the delayed sequence within the historical stable interval. Indicates node identifier The absolute median difference of the delayed sequence within the historical stable interval. This represents the soft threshold gain constant. Represents the variance sensitivity coefficient. This indicates the amount of window variance compression. This represents the jitter penalty coefficient. This indicates the amount of window jitter compression.

[0097] It should be noted that the soft threshold gain constant is set by statistically analyzing the gradient rate of change of prediction deviation in the distribution of node historical delay prediction errors, selecting a constant value that achieves the optimal balance between the smoothness of the threshold baseline generation function and the response sensitivity; the variance sensitivity coefficient is set by performing regression analysis on the correlation between the node delay prediction value sequence and the window variance sequence, taking the normalized value of the regression slope; the jitter penalty coefficient is set by statistically analyzing the negative correlation between the node delay prediction value sequence and the window jitter intensity sequence, taking the value after smoothing and normalizing the absolute value of the correlation coefficient; the window variance compression is a dimensionless transformation of the window variance; and the window jitter compression is a dimensionless transformation of the jitter intensity.

[0098] Furthermore, the deviation between the node delay prediction value sequence and the delay threshold baseline set is compared, and the initial risk occupancy is calculated by normalizing the over-limit deviation method.

[0099] It should be noted that the initial risk occupancy is calculated using the normalized out-of-limit deviation method and is expressed as follows:

[0100] ;

[0101] in, This indicates the initial risk occupancy.

[0102] S3. Based on the node indicator time series matrix, delay prediction value, delay threshold baseline set and initial risk occupancy, calculate the reporting interval and priority score of each node, determine the batch threshold and retry backoff delay according to the reporting interval, and perform multi-channel scheduling according to the priority score to generate the scheduled reporting stream.

[0103] Based on the node indicator time series matrix, delay prediction value, delay threshold baseline set, and initial risk occupancy, after loading according to the node identifier, feature weighted fusion is performed to generate a comprehensive load intensity set. By calculating the reporting interval and priority score, a reporting interval set and a priority score set are generated.

[0104] Furthermore, based on the node indicator time series matrix, latency prediction value, latency threshold baseline set, and initial risk occupancy, corresponding loading is performed according to the node identifier to generate a node input set. Proportional balancing correction is performed based on the real-time volatility of the node indicator time series matrix, latency prediction value, latency threshold baseline set, and initial risk occupancy in the node input set. Initial weights are assigned to each indicator based on the node operating status sensitivity of each node's operating indicators in the node indicator time series matrix, and then weighted and fused to calculate the comprehensive load intensity. All comprehensive load intensities are statistically analyzed to generate a comprehensive load intensity set. The reporting interval of each node is obtained by weighted summation of comprehensive load intensity, latency prediction value, and risk occupancy. The priority score of each node is obtained by weighted summation using latency prediction value, packet loss rate, and bandwidth availability as the main factors. All reporting intervals and priority scores are statistically analyzed to generate a reporting interval set and a priority score set.

[0105] It should be noted that the sensitivity of the node operation status of each node operation index in the node index time series matrix is ​​obtained by approximating the partial derivative of the change in the node operation index with respect to the change in the comprehensive load intensity within the most recent sliding window.

[0106] Based on the reporting interval, calculate the batch threshold for each node and generate a set of batch thresholds.

[0107] Furthermore, based on the reporting interval, a batch threshold for each node is calculated using a dynamic batch reshaping algorithm, and all batch thresholds are statistically analyzed to generate a batch threshold set.

[0108] It should be noted that the batch threshold for each node is calculated using a dynamic batch reshaping algorithm, expressed as:

[0109] ;

[0110] in, Indicates the batch threshold. This indicates the upper limit of the batch threshold. This indicates the lower limit of the batch threshold. Indicates node identifier Average arrival rate, Indicates node identifier The reporting interval This represents the risk adjustment coefficient.

[0111] It should be noted that the node identifier The average arrival rate is calculated in the node index time series matrix based on the number of arrivals of composite event index data of the node in adjacent time windows and the time interval; It is set by the statistical variance of the historical operational stability of the node, and is used to control the degree of impact of risk on the batch threshold.

[0112] Based on the reporting interval set, the predicted delay value, the delay threshold baseline set, and the initial risk occupancy, the retry backoff delay is calculated, the retry backoff delay set is obtained, and the reporting interval set, priority score set, batch threshold set, and retry backoff delay set are encapsulated to generate a dynamic scheduling result set.

[0113] Furthermore, by weighting and fusing the reporting interval set, the predicted delay value, the baseline set of delay thresholds, and the initial risk occupancy, the retry backoff delay is calculated. All retry backoff delays are statistically analyzed to generate a retry backoff delay set. The reporting interval set, priority score set, batch threshold set, and retry backoff delay set are then subjected to consistency verification by node identifier and timestamp, and field integrity and value validity verification are performed. Out-of-bounds records are removed. The reporting interval, priority score, batch threshold, and retry backoff delay of each node are encapsulated into a node scheduling record with a unified field name. All node scheduling records are statistically analyzed to generate a dynamic scheduling result set, and the metadata of this encapsulation is attached.

[0114] After loading the dynamic scheduling result set according to the node identifier, sort it from high to low according to the priority score and allocate channels. According to the priority score range, the nodes are allocated hierarchically, and each scheduled channel is assigned a unique channel identifier, generating a channel allocation result set.

[0115] Furthermore, the dynamic scheduling result set is loaded according to node identifiers, and the node identifiers, priority scores, and scheduling cycle identifiers are extracted to establish a priority sorting view. After confirming the uniqueness of each node, a sorting input table is formed. The nodes in the sorting input table are sorted from high to low priority scores. When the priority scores of nodes are the same, they are stably sorted according to the lexicographical order of the node identifiers to generate a priority sorting list. Based on the priority sorting list, after the channel resources are initialized, a boundary threshold is set by statistically analyzing the distribution of node priority scores within the historical scheduling cycle. The upper quantile of the node priority score distribution within the historical scheduling cycle is taken as the boundary threshold between high-priority channels and medium-priority channels, and the lower quantile of the node priority score distribution within the historical scheduling cycle is taken as the boundary threshold. The quantile is used as the dividing threshold between medium-priority and low-priority channels. Nodes are mapped to the multi-channel scheduling table for hierarchical allocation based on this threshold. When the upper quantile of the node priority score distribution in the historical scheduling period is less than the node's priority score, the node is mapped to a high-priority channel. When the lower quantile of the node priority score distribution in the historical scheduling period is less than the node's priority score and less than the upper quantile, the node is mapped to a medium-priority channel. When the node's priority score is less than the lower quantile, the node is mapped to a low-priority channel. All channel allocation records are appended with set-level metadata, and after consistency verification, they are aggregated into a channel allocation result set.

[0116] The channel allocation result set is used for in-channel scheduling. Based on the reporting interval set and the batch threshold set, a dynamic scheduling strategy is executed to generate a set of data to be sent within the channel.

[0117] Furthermore, channel allocation result sets are scheduled within the channel. Based on the reporting interval set and batch threshold set, a reporting time trigger threshold is set. When the reporting interval of a node reaches the reporting time trigger threshold, data reporting is triggered immediately. When the number of events in the node's buffer queue exceeds the batch threshold, data reporting is triggered immediately. When the number of consecutive transmission failures exceeds one, the next reporting attempt of the corresponding node is suspended according to the retry backoff delay. For high-priority channels, an event direct transmission trigger mechanism is enabled, immediately calling the reporting instruction of the corresponding node in the reporting instruction set, packaging the event data into a single frame message, and immediately initiating transmission. For medium-priority and low-priority channels, a joint trigger mechanism of reporting interval trigger and batch threshold trigger is adopted. The event data of the current batch is extracted from the buffer queue, packaged according to the batch threshold, and data compression and transmission are performed. The channel mapping results of all nodes are formed into channel allocation records, and set-level metadata is attached to each channel allocation record. After performing consistency verification, the channel allocation records are summarized to generate a set of data to be sent within the channel.

[0118] It should be noted that the reporting time trigger threshold is set by the mean and standard deviation of the node's historical reporting intervals.

[0119] Calculate the reporting weight for the set of data to be sent in the channel, obtain the reporting weight set in the channel, and aggregate the reporting weight set in the channel with the set of data to be sent in the channel to generate a scheduled reporting stream.

[0120] Furthermore, by using a scheduling weight function, the reporting weights of the data set to be sent within the channel are calculated, all reporting weights are statistically analyzed, and a set of reporting weights within the channel is obtained. The set of reporting weights within the channel is then weighted and aggregated with the set of data to be sent within the channel. The node data aggregated according to the reporting weights is then spliced ​​together in a time series to generate a scheduled reporting stream.

[0121] It should be noted that the reporting weight is calculated for the set of data to be sent within the channel using the scheduling weight function, expressed as:

[0122] ;

[0123] in, Indicates the reporting weight. Indicates priority scoring. This represents the traversal index for summation within the channel. Indicates the channel identifier.

[0124] S4. Perform real-time risk analysis on the scheduled reporting stream, identify continuous failures, delay exceeding limits and jitter anomalies, calculate the risk index set, determine the risk level set, and generate the correction factor set.

[0125] After the scheduled reporting streams are partitioned and managed according to node identifiers, continuous failure detection is performed. By statistically analyzing the reporting result sequence, a continuous failure rate set is generated. The latency threshold baseline set is then jointly analyzed with the reporting latency sequence in the scheduled reporting streams to calculate the average latency and generate a latency exceedance ratio set.

[0126] Furthermore, the scheduled reporting streams are loaded from the channel allocation result set. The reporting event sequence corresponding to each node is extracted according to the node identifier, scheduling cycle identifier, and channel identifier to generate a reporting stream loading table. For each node in the reporting stream loading table, a corresponding reporting sliding window structure is established. The window length and window step size are set according to the reporting interval set and batch threshold set of the channel to which the node belongs. For example, the window length is twice the reporting interval, and the window step size is half the reporting interval. The counters and timestamp indices within each window are initialized, and the events in the most recent complete window from the historical reporting events are loaded into the corresponding window, generating a window initialization state table. The window initialization state tables of all nodes are bound to the channel identifier to generate a real-time reporting stream window initialization set. Continuous failure detection is performed on the real-time reporting stream window initialization set. Each reporting result in the process is identified, with successful reporting results recorded as 0 and failed reporting results recorded as 1, generating a binary failure sequence. A weighted exponential smoothing function is used to calculate the continuous failure rate and cumulative number of failures within the current time window, obtaining a continuous failure rate set. The reporting delay sequence of each data packet in the real-time reporting stream window initialization set is read and compared item by item with the delay threshold baseline set. When the delay threshold baseline in the delay threshold baseline set is greater than the reporting delay sequence, the over-limit indicator value is recorded as 1. When the delay threshold baseline in the delay threshold baseline set is less than or equal to the reporting delay sequence, the over-limit indicator value is recorded as 0, generating an over-limit indicator sequence. Within the time range with the reporting sliding window as the interval, the node delay sequence is integrated and averaged to calculate the average delay. The delay over-limit ratio is calculated by integrating and averaging the node delay sequence, generating a delay over-limit ratio set.

[0127] It should be noted that when generating the dynamic scheduling result set, a scheduling cycle identifier is generated based on the global scheduling clock; each reporting sliding window structure includes a time index, an event index, and a delay record unit;

[0128] The set of delay exceedance ratios and the reported delay sequence are differentially processed to calculate the continuous delay change rate and generate a jitter intensity set.

[0129] Furthermore, by using a time-series gradient weighted smoothing algorithm, the set of delay exceeding the limit proportions and the reported delay sequence are differentially processed to calculate the continuous delay change rate. A jitter threshold is set. When the continuous delay change rate is greater than the jitter threshold, the current node is marked as having a jitter anomaly. The continuous delay change rate is averaged over time and the peak value is extracted within a sliding window to generate the jitter intensity. All jitter intensities are counted to generate a jitter intensity set.

[0130] It should be noted that the jitter threshold is set by the sum of the median and the absolute median difference of the historical continuous delay change rate distribution. The jitter threshold ranges from [0, g], where g is the maximum value of the continuous delay change rate within the sliding window.

[0131] The risk index set is calculated by weighting and fusing the continuous failure rate set, the latency exceeding the limit ratio set, and the jitter intensity set. The node risk status is divided into different risk levels according to the risk index set to obtain the risk level set. The average latency, latency threshold baseline, continuous failure rate set, and jitter intensity set are then weighted and fused to generate a weighted factor set.

[0132] Furthermore, by weighted and fused the continuous failure rate set, the latency exceedance ratio set, and the jitter intensity set, a risk index is calculated, and all risk indices are statistically analyzed to obtain a risk index set. Statistical analysis of the distribution characteristics of historical risk index sets is performed to set risk level thresholds. Based on these thresholds, the risk status of nodes is divided into different risk levels, and corresponding risk level labels are generated. The risk level labels obtained from node-by-node comparisons are summarized to obtain a risk level set. Weighted and fused the average latency, latency threshold baseline, continuous failure rate set, and jitter intensity set, a preliminary correction factor is generated. This preliminary correction factor is subject to risk normalization constraints to generate correction factors. All correction factors are statistically analyzed to obtain a correction factor set.

[0133] It should be noted that applying risk normalization constraints to the preliminary correction factor means limiting the maximum value of the preliminary correction factor to 1, thereby keeping the result of the preliminary correction factor within the range [0,1].

[0134] It should be noted that the risk level thresholds include an upper risk level threshold and a lower risk level threshold. The upper risk level threshold is set by summing and compensating the upper quantile of the historical risk index set based on the average deviation range of the historical risk index, and its value range is (0, l). The lower risk level threshold is set by summing and compensating the lower quantile of the historical risk index set based on the difference range of the average deviation range of the historical risk index, and its value range is [0, l), where l is the maximum value in the risk index set. The value of the upper risk level threshold is greater than that of the lower risk level threshold.

[0135] S5. Based on the risk index set, risk level set, and correction factor set, dynamically correct the reporting interval, batch threshold, and retry backoff delay, obtain the corrected reporting instruction set and flow control status, and atomically update and re-feed back the corrected reporting instruction set and flow control status.

[0136] The risk index set, risk level set, and correction factor set are adjusted for reporting interval, batch threshold, and retry backoff delay, and then integrated to generate a corrected reporting instruction set.

[0137] Furthermore, the risk index set, risk level set, and correction factor set are loaded according to node identifiers. The reporting interval is corrected using a reporting interval correction function to obtain the corrected reporting interval; the batch threshold is corrected using a batch threshold correction function to obtain the corrected batch threshold; and the retry backoff delay is corrected using a retry backoff delay correction function to obtain the corrected retry backoff delay. The corrected reporting interval, corrected batch threshold, and corrected retry backoff delay are aggregated according to node identifiers to generate a node correction parameter set. The node correction parameter set is encapsulated, and based on the node identifier, historical stable interval information, and priority score, a reporting control command is generated for each node. All reporting control commands are integrated through merging and deduplication, indexing and structured encapsulation, and consistency verification and serialization output to generate a corrected reporting command set.

[0138] It should be noted that the reporting interval correction function is expressed as:

[0139] ;

[0140] in, This indicates the revised reporting interval. The reporting interval adjustment factor indicates the risk level. Indicates the correction factor. This represents the risk amplification factor. This indicates a risk index.

[0141] It should be noted that the risk level reporting interval adjustment coefficient is set using the exponentially weighted moving average control chart method, with a value range of [0, 1]; the risk amplification coefficient is set using the Z-score standardization and Sigmoid dynamic mapping method, with a value range of [0.5, 3].

[0142] The batch threshold correction function is expressed as:

[0143] ;

[0144] in, This indicates the corrected batch threshold. The batch threshold adjustment coefficient represents the risk level. This represents the risk response rate constant.

[0145] It should be noted that the batch threshold adjustment coefficient for risk levels is set by a linear function relationship between the node's risk index and the historical operational stability range, and is adjusted according to the adjustment slope constant corresponding to different risk levels; the risk response rate constant is set by fitting the change curve of the node's risk index and risk response amplitude, and is adjusted according to the response sensitivity coefficient corresponding to the risk level.

[0146] The retry backoff delay correction function is expressed as:

[0147] ;

[0148] in, This indicates the corrected retry backoff delay. The retry backoff delay adjustment coefficient indicates the risk level. Represents the amplification rate constant. This indicates the risk trigger threshold.

[0149] It should be noted that the retry backoff delay adjustment coefficient for risk levels is determined by offline statistical analysis of the retry conflict rate and delay distribution under different risk levels in historical reporting data, combined with the target collision rate to inversely deduce the target backoff delay, and then the optimal amplification coefficient is determined based on the expected values ​​of the risk index and correction factor. The amplification rate constant is determined by performing logistic regression fitting on the historical risk index set and backoff delay samples to make the amplification function achieve the optimal response slope at the risk trigger threshold. The risk trigger threshold is determined by calculating the crossover inflection point of the delay over-limit ratio and the continuous failure rate in the historical risk index sequence to minimize the comprehensive error of the risk false alarm rate and the risk missed alarm rate. The value range of the risk trigger threshold is [0, 1].

[0150] The revised reporting instruction set, along with the risk index set, risk level set, and correction factor set, are summarized to generate a flow control status set.

[0151] Furthermore, the revised reporting instruction set, risk index set, risk level set, and correction factor set are matched to generate a node summary table. This node summary table is then input into the data aggregation process. Joint analysis is performed on the risk indicators and reporting parameters of each node. Based on the changing trends of risk levels and correction factors, the operational status category of the node within the current reporting cycle is identified. In the node summary table, the reporting priority identifier and flow control status identifier of each node are marked according to its operational status category. The node summary table is then integrated and synchronized in terms of fields and time. When there are time differences in the timestamps of node data from different source sets during the time synchronization of the node summary table, the node data with the latest timestamp is used for synchronization overlay. The reporting parameters and status identifiers of each node in the time-synchronized node summary table are then structurally encapsulated to generate node flow control status entries. All node flow control status entries are sorted and indexed according to the node identifier, using the node identifier as the primary key and the timestamp as the index to generate a flow control status set.

[0152] It should be noted that the node's operating status categories during the current reporting period include low-risk stable status, medium-risk controlled status, and high-risk flow-limited status.

[0153] It should be noted that, according to the node's operating status category, the node's reporting priority identifier and flow control status identifier are marked respectively. Specifically, the flow control status identifier of low-risk stable nodes is set to "normal reporting", the flow control status identifier of medium-risk controlled nodes is set to "controlled reporting", and the flow control status identifier of high-risk flow-limited nodes is set to "rate-limited reporting".

[0154] The corrected reporting instruction set and flow control status are hashed and locked by nodes and transactions to generate a locked status set. The locked status set is then subjected to instruction difference detection, hash verification and atomic update. The corrected reporting instruction set and flow control status are atomically written to generate an atomic update result set.

[0155] Furthermore, the revised reporting instruction set and flow control status are matched according to node identifiers to generate a node instruction mapping table. This table is then hashed, and based on the node identifier and timestamp information, a unique hash identifier code for each node is calculated using a high-performance unencrypted hash algorithm (MurmurHash3). The generated hash identifier codes are then used for transaction locking. A lightweight transaction lock is requested for each node, and a global transaction control lock is established. Lock revocation is performed for hash identifier code duplication, lock timeout, and node resource conflict, resulting in a set of locked states. Finally, the locked state set is subjected to instruction difference detection and compared with the current... The node instruction mapping table is compared with the historical node instruction mapping table of the previous reporting period. Differences in the reporting interval, batch threshold, and retry backoff delay fields are detected. When a difference is detected, the current difference field is recorded in the difference list table. When no difference is detected, the current node status is marked as "no update", and the difference list table is obtained. The difference list table is hash-verified, and the current hash identifier of the node is compared with the hash identifier saved in the previous period. When the hash identifier is consistent and there is no field difference, the update is skipped. When either the hash identifier is inconsistent or a field difference is detected, an atomic update operation is triggered, and an atomic update result set is generated.

[0156] It should be noted that atomic update operation refers to synchronously writing the corrected reporting instruction set and flow control status of the difference node using the transaction commit method.

[0157] It should be noted that after the atomic writing of the corrected reporting instruction set and flow control status is completed, the status of the write result of each node is determined. When the write process completes all transaction locking, hash verification, and consistency verification without interruption, the update status of the current node is marked as successful. When either hash verification or consistency verification fails, the update status of the current node is marked as rollback. When lock revocation is performed during the transaction locking phase, the update status of the current node is marked as rollback. The update status of all nodes, together with the corresponding node identifier, transaction batch number, and timestamp, form an atomic update result set.

[0158] The atomic update result set is fed back into the state. The corrected reporting instruction set and flow control state are jointly encoded and fed back into the state to generate a feedback stream. The node indicator time series matrix is ​​updated to generate a closed-loop synchronization result set.

[0159] Furthermore, the atomic update result set is loaded according to the node identifier, and the update status, update timestamp, and transaction batch number information corresponding to each node are extracted. Nodes with a successful update status are marked as rechargeable nodes, while nodes with a rollback status are not recharged. The corrected reporting instruction set of the rechargeable nodes is jointly encoded with the corresponding flow control status. The node joint encoding string is encoded and compressed according to a fixed format (e.g., UTF-8) and bound to the timestamp field to generate a node recharge stream. The node recharge stream is input to the node indicator acquisition agent. The node indicator acquisition agent extracts the node indicator vector of the previous reporting period from the current node indicator time series matrix according to the node identifier, and uses the reporting parameters in the node recharge stream as update input to update the corresponding node records in the node indicator time series matrix. After all node indicator time series matrices are updated, the updated node indicator time series matrix is ​​jointly verified with the current recharge stream to generate a closed-loop synchronization result set.

[0160] Among them, nodes with an update status of rollback will not be re-fed. The node indicator collection agent records the rollback transaction log according to the node identifier, and re-analyzes the transaction batch number, node operation indicators, and scheduled reporting flow of the rollback node in real time.

[0161] It should be noted that the joint verification of the updated node indicator time series matrix with the current backflow includes node identifier consistency, timestamp matching, and data integrity check code comparison. When all joint verifications pass, a closed-loop synchronization result set is generated.

[0162] This embodiment also provides a computer device applicable to the real-time reporting and management method of software development information based on big data, including: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to realize the real-time reporting and management method of software development information based on big data proposed in the above embodiment.

[0163] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0164] This embodiment also provides a storage medium storing a computer program. When executed by a processor, the program implements the real-time reporting and management method for software development information based on big data, as proposed in the above embodiments. 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.

[0165] In summary, this invention achieves dynamic statistical analysis and delay prediction of the time series matrix of node indicators by performing sliding window aggregation and generating a baseline set of delay thresholds on composite event indicator data, thus ensuring the timeliness and continuity of the reporting process; and improves the stability and reliability of multi-node reporting management through real-time collaborative control of risk index, risk level, and correction factor.

[0166] 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 method for real-time reporting and management of software development information based on big data, characterized in that: include, Deploy collection agents on multiple nodes to collect multi-source event data and operational metrics, preprocess the multi-source event data and operational metrics, and generate composite event metric data. The event indicator composite data is aggregated by sliding window. By calculating the sliding window statistics, a node indicator time series matrix is ​​established. Based on the node indicator time series matrix, the delay prediction value is calculated. The delay threshold baseline set is generated by combining the median and absolute median difference of the historical stable interval, and the initial risk occupancy is output. Based on the node indicator time series matrix, delay prediction value, delay threshold baseline set and initial risk occupancy, the reporting interval and priority score of each node are calculated. The batch threshold and retry backoff delay are determined according to the reporting interval. Multi-channel scheduling is performed according to the priority score to generate the scheduled reporting stream. Real-time risk analysis is performed on the scheduled reporting stream to identify continuous failures, delay exceeding limits, and jitter anomalies. A set of risk indices is calculated, a set of risk levels is determined, and a set of correction factors is generated. Based on the risk index set, risk level set, and correction factor set, the reporting interval, batch threshold, and retry backoff delay are dynamically corrected to obtain the corrected reporting instruction set and flow control status. The corrected reporting instruction set and flow control status are then atomically updated and fed back. The steps are as follows: Based on the time-series matrix of node indicators, the predicted delay value is calculated; combined with the median and absolute median difference of historical stable intervals, a baseline set of delay thresholds is generated; and the initial risk occupancy is output. Based on the node identifier, the node indicator time series matrix is ​​partitioned, and the delayed prediction value is calculated by weighted moving linear regression function to obtain the node delayed prediction value sequence. The predicted node delay values ​​are compared with the combined node feature sequences to extract historical stable intervals. By calculating the median and absolute median difference of historical stable intervals, a set of stable statistics is generated. The delay threshold baseline set for each node is calculated using the threshold baseline generation function. The deviation between the node delay prediction value sequence and the delay threshold baseline set is compared. The initial risk occupancy is calculated using the normalized over-limit deviation method. The steps for performing real-time risk analysis on the scheduled reporting stream, identifying consecutive failures, latency exceeding limits, and jitter anomalies, calculating a risk index set, determining a risk level set, and generating a correction factor set are as follows: After partitioning the scheduled reporting streams according to node identifiers, continuous failure detection is performed. By statistically analyzing the reporting result sequence, a set of continuous failure rates is generated. The baseline set of delay thresholds is then jointly analyzed with the reporting delay sequence in the scheduled reporting streams to calculate the average delay and generate a set of delay over-limit ratios. The set of delay exceedance ratios and the reported delay sequence are differentially processed to calculate the continuous delay change rate and generate a jitter intensity set. The set of consecutive failure rates, the set of latency exceeding limits, and the set of jitter intensity are weighted and fused to calculate the risk index set. Based on the risk index set, the node risk status is divided into different risk levels to obtain the risk level set. The average latency, latency threshold baseline, set of consecutive failure rates, and set of jitter intensity are weighted and fused to generate the weighting factor set. The steps are as follows: Based on the risk index set, risk level set, and correction factor set, the reporting interval, batch threshold, and retry backoff delay are dynamically corrected to obtain the corrected reporting instruction set and flow control status. The risk index set, risk level set, and correction factor set are adjusted for reporting interval, batch threshold, and retry backoff delay, and then integrated to generate a corrected reporting instruction set. The revised reporting instruction set, along with the risk index set, risk level set, and correction factor set, are summarized to generate a flow control status set. The flow control status set includes flow control status identifiers corresponding to normal reporting, controlled reporting, and rate-limited reporting. The steps for atomically updating and re-feeding back the corrected reporting instruction set and flow control status are as follows: The modified reporting instruction set and flow control status are hashed and locked by nodes and transactions to generate a locked status set. The locked status set is then subjected to instruction difference detection, hash verification, and atomic updates using transaction commit. The modified reporting instruction set and flow control status are atomically written to generate an atomic update result set. The atomic update result set is fed back into the state. The corrected reporting instruction set and flow control state are jointly encoded and fed back into the state to generate a feedback stream. The node indicator time series matrix is ​​updated to generate a closed-loop synchronization result set.

2. The real-time reporting and management method for software development information based on big data as described in claim 1, characterized in that: The multiple nodes include code hosting nodes, build nodes, test nodes, and deployment nodes.

3. The real-time reporting and management method for software development information based on big data as described in claim 2, characterized in that: The steps for preprocessing multi-source event data and operational metrics to generate composite event metric data are as follows: Deploy collection agents across multiple nodes to collect multi-source event data and operational metrics, perform time alignment, duplicate detection, and anomaly removal, and generate a standardized set of multi-source event data and a standardized set of operational metrics. The standardized multi-source event data set and the standardized operational indicator set are normalized and their fields are uniformly mapped. They are then matched and merged based on node identifiers and timestamps to generate a node-level fused data set. Perform quality assessment on the node-level fused dataset to obtain composite data of event metrics.

4. The real-time reporting and management method for software development information based on big data as described in claim 3, characterized in that: The steps for performing sliding window aggregation on the composite data of event indicators and establishing a time-series matrix of node indicators by calculating sliding window statistics are as follows. Perform sliding window aggregation on the composite data of event indicators, and extract a subset of the composite data of event indicators according to the sliding window width and step size; For each event indicator composite data subset, calculate the window mean, window variance, and window jitter intensity, and then concatenate them in chronological order to generate a time series matrix of node indicators.

5. The real-time reporting and management method for software development information based on big data as described in claim 4, characterized in that: The process involves calculating the reporting interval and priority score for each node based on the node indicator time series matrix, predicted delay values, baseline delay thresholds, and initial risk occupancy. The batch threshold and retry backoff delay are then determined according to the reporting interval. The steps are as follows: Based on the node indicator time series matrix, delay prediction value, delay threshold baseline set and initial risk occupancy, after loading according to the node identifier, feature weighted fusion is performed to generate a comprehensive load intensity set. By calculating the reporting interval and priority score, a reporting interval set and a priority score set are generated. Based on the reporting interval, calculate the batch threshold for each node and generate a set of batch thresholds; Based on the reporting interval set, the predicted delay value, the delay threshold baseline set, and the initial risk occupancy, the retry backoff delay is calculated, the retry backoff delay set is obtained, and the reporting interval set, priority score set, batch threshold set, and retry backoff delay set are encapsulated to generate a dynamic scheduling result set.

6. The real-time reporting and management method for software development information based on big data as described in claim 5, characterized in that: The steps for multi-channel scheduling based on priority scores to generate a scheduled reporting stream are as follows: After loading the dynamic scheduling result set according to the node identifier, sort it from high to low according to the priority score, and then allocate channels. According to the range of priority scores, the nodes are allocated hierarchically, and a channel allocation result set is generated. Perform intra-channel scheduling on the channel allocation result set, and execute dynamic scheduling strategy based on the reporting interval set and batch threshold set to generate intra-channel data set to be sent; Calculate the reporting weight for the set of data to be sent in the channel, obtain the reporting weight set in the channel, and aggregate the reporting weight set in the channel with the set of data to be sent in the channel to generate a scheduled reporting stream.

Images