E-commerce order management method based on cloud data analysis

Abstract

The invention relates to the technical field of e-commerce and cloud computing, and discloses an e-commerce order management method based on cloud data analysis. The method comprises the following steps: clustering cloud order time sequence data to form a plurality of differentiated data clusters; performing multi-level feature extraction on each cluster to generate a cluster-level feature description vector; analyzing the vector by using a trained time sequence mode matching model, and identifying a potential processing delay mode; according to the identified mode, actively triggering a resource pre-allocation strategy and executing a corresponding instruction; and finally, completing order transfer state judgment in combination with the deployed system operation data and the delay mode. According to the method, the features are extracted from the order group and the historical delay mode is matched, so that the processing delay risk is predicted in advance and the resources are dynamically pre-adjusted, and the processing efficiency and the operation stability of the order system are improved.

Description

Technical Field

[0001] This invention relates to the fields of e-commerce and cloud computing technology, specifically to an e-commerce order management method based on cloud data analysis. Background Technology

[0002] In e-commerce operations, the efficiency of order data processing directly impacts user experience and platform operating costs. Existing technologies typically monitor massive amounts of mixed raw order flow data or issue alerts based on simple thresholds. These methods treat order data with different characteristics and stages as a whole, resulting in a relatively singular analytical dimension. Due to the significant temporal and group differences inherent in order data, this coarse-grained analysis method struggles to accurately depict the complex and dynamic state characteristics exhibited by different order groups during the flow process, leading to a superficial understanding of the system's operational status.

[0003] Existing solutions for order processing delays are mostly reactive, meaning they only address the issue after delays occur and system metrics deteriorate, relying on alerts or manual experience to allocate resources and troubleshoot problems. This approach lacks the ability to identify and predict delay patterns in advance, resulting in delayed resource adjustments. When faced with peak traffic surges such as promotional events, the system's inability to identify potential, specific delay risk patterns in advance hinders effective resource preparation, easily leading to order backlogs, processing timeouts, and other problems that impact overall operational smoothness. Summary of the Invention

[0004] The purpose of this invention is to provide an e-commerce order management method based on cloud data analysis to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides an e-commerce order management method based on cloud data analysis, the method comprising: Obtain the order time-series data set stored in the cloud, perform a clustering operation on the order time-series data set, and generate multiple differentiated order time-series data clusters; Perform multi-level feature extraction operations on the multiple differentiated order time-series data clusters to form cluster-level feature description vectors; Based on the trained temporal pattern matching model, a matching analysis is performed on the cluster-level feature description vector to identify at least one potential processing delay pattern. Based on the at least one potential processing delay pattern, a resource pre-allocation strategy is triggered to generate a set of resource allocation instructions; The resource allocation instruction set is executed, the system runtime data after execution is obtained, and the order flow status is comprehensively determined by combining the at least one potential processing delay mode.

[0006] Preferably, the order time-series data set stored in the cloud is obtained, and a clustering operation is performed on the order time-series data set to generate multiple differentiated order time-series data clusters, including: Retrieve the stream of original order records generated within a preset time window from the specified cloud storage node; The original order record stream is parsed to extract order time-series data containing creation timestamps, payment status markers, product category codes, and user identifiers, which are then aggregated to form an initial order time-series data set. Based on the preset temporal similarity measurement rules, the similarity distance between different order temporal data in the initial order temporal data set is calculated; Based on the calculated similarity distance, the density peak clustering algorithm is used to process the initial order time series data set, and order time series data with similarity distance less than the threshold are classified into the same group; Output multiple independent data groups after clustering, and define each independent data group as a differentiated order time series data cluster.

[0007] Preferably, multi-level feature extraction operations are performed on the multiple differentiated order time-series data clusters to form cluster-level feature description vectors, including: For each differentiated order time series data cluster, the total number of order time series data contained in that cluster is counted as a quantitative feature; Calculate the average time interval of all order time series data within each differentiated order time series data cluster, and use it as a density feature; Identify the frequency of occurrence of product category codes within each differentiated order time-series data cluster, and extract the most frequent product category codes to form category distribution features; Extract the number of unique user identifiers within each differentiated order time-series data cluster as a user scale feature; The quantity features, density features, category distribution features, and user scale features extracted from each differentiated order time-series data cluster are sequentially concatenated and normalized to generate a fixed-dimensional numerical vector, which is then defined as the cluster-level feature description vector.

[0008] Preferably, based on a trained temporal pattern matching model, a matching analysis is performed on the cluster-level feature description vector to identify at least one potential processing delay pattern, including: Obtain historical order operation and maintenance logs, and mark the event segments in the historical order operation and maintenance logs that have clear processing delays; Historical order data within a specific time window prior to the occurrence of the event segment is extracted. Following the same process as generating the cluster-level feature description vector, a historical cluster-level feature description vector sample set is constructed, and each sample is associated with a pattern label representing the severity of the delay. The historical cluster-level feature description vector sample set and its associated pattern labels are used to supervise the training and validation of the temporal pattern matching model built on the deep residual network until the model converges. The currently generated cluster-level feature description vector is input into the trained temporal pattern matching model; The temporal pattern matching model outputs at least one pattern label that has the highest matching degree with the cluster-level feature description vector, and defines the at least one output pattern label as at least one potential processing delay pattern.

[0009] Preferably, based on the at least one potential processing delay pattern, a resource pre-allocation strategy is triggered to generate a set of resource allocation instructions, including: A pre-defined mapping table exists between potential processing delay modes and resource allocation templates; Query the mapping table for the at least one potential processing delay pattern and obtain the corresponding at least one initial resource allocation template; Read the real-time resource load snapshot of the current cloud platform, which includes the utilization rate of computing nodes and the utilization rate of database connection pool; The parameters in the at least one initial resource allocation template are dynamically adjusted using the compute node utilization and database connection pool utilization included in the real-time resource load snapshot. At least one resource allocation template that has been dynamically corrected is transformed into a series of operation commands that can be directly recognized and executed by the cloud platform scheduling system, and these operation commands are integrated into a resource allocation instruction set.

[0010] Preferably, the resource allocation instruction set is executed, the system runtime data after execution is obtained, and a comprehensive determination of the order flow status is made in conjunction with the at least one potential processing delay mode, including: The set of resource allocation instructions is sent to the cloud platform scheduling system, which then executes the instructions to adjust the number of virtual computing instances or the size of the database connection pool. During the monitoring period after the resource allocation instruction set is executed, runtime metrics of the target system are collected. These runtime metrics include average order processing time, number of erroneous transactions, and queue waiting depth. The collected runtime metrics are compared and analyzed with the expected threshold range implied by the at least one potential processing latency pattern; If all the runtime indicators fall within their corresponding expected threshold range, an order flow status determination result indicating a normal status is generated. If any runtime metric exceeds its corresponding expected threshold range, an order flow status determination result is generated, indicating an abnormal status and accompanied by an identifier for the exceeding metric.

[0011] Preferably, based on a preset temporal similarity measurement rule, the similarity distance between different order time-series data in the initial order time-series dataset is calculated, including: Extract the creation timestamps from the two order time series data respectively, and calculate the absolute time difference between the creation timestamps of the two order time series data; Extract the product category codes from the time-series data of the two orders respectively. If the product category codes are the same, the code similarity is set to a specific value; if the product category codes are different, the code similarity is set to another specific value. The absolute time difference and the encoding similarity are weighted and summed, and the summation result is defined as the similarity distance between the two order time series data. The weighting coefficient is preset based on historical order processing experience.

[0012] Preferably, the frequency of occurrence of product category codes within each differentiated order time-series data cluster is identified, and the most frequent product category codes are extracted to form category distribution features, including: Iterate through all the product category codes contained in the order time series data within a differentiated order time series data cluster; Count the number of times each product category code appears in the order time series data cluster to form a code frequency statistics table; Select a pre-defined number of product category codes that appear most frequently from the code frequency statistics table; The selected pre-defined number of product category codes are arranged in descending order of frequency of occurrence to form an ordered code sequence, which is then used as the category distribution feature of the order time-series data cluster.

[0013] Preferably, the parameters in the at least one initial resource allocation template are dynamically adjusted using the compute node utilization and database connection pool utilization included in the real-time resource load snapshot, including: Read an initial resource allocation template, which includes a baseline expansion amount for computing resources and a baseline number of connections for the database connection pool; Obtain the current computing node utilization rate in the real-time resource load snapshot and divide it by the standard utilization rate threshold to obtain a computing resource adjustment coefficient; Multiply the baseline expansion amount by the computing resource adjustment coefficient to obtain the corrected computing resource expansion amount; Obtain the current database connection pool utilization rate in the real-time resource load snapshot, and divide it by the standard connection pool utilization rate threshold to obtain a connection pool adjustment coefficient; Multiply the baseline number of connections by the connection pool adjustment factor to obtain the corrected number of database connection pool connections; The modified computing resource expansion quantity is used to replace the baseline expansion quantity, and the modified database connection pool connection quantity is used to replace the baseline connection quantity, thereby completing the dynamic modification of the initial resource allocation template.

[0014] Preferably, the collected runtime metrics are compared and analyzed with the expected threshold range implied by the at least one potential processing latency pattern, including: Based on the at least one potential processing delay pattern, query the preset pattern-threshold mapping knowledge base to obtain the average order processing time threshold range, the upper limit of the number of erroneous transactions threshold, and the upper limit of the queue waiting depth threshold corresponding to each potential processing delay pattern; The actual average processing time of collected orders is compared with the threshold range of average processing time of orders obtained by querying, to determine whether the actual average processing time of collected orders falls within the threshold range of average processing time of orders. The number of erroneous transactions actually collected is compared with the upper limit of the erroneous transaction number threshold obtained by querying, and it is determined whether the number of erroneous transactions actually collected is less than or equal to the upper limit of the erroneous transaction number threshold. The actual queue waiting depth is compared with the upper limit of the queue waiting depth threshold obtained from the query, and it is determined whether the actual queue waiting depth is less than or equal to the upper limit of the queue waiting depth threshold.

[0015] Compared with existing technologies, the beneficial effects of this invention are as follows: By clustering cloud-based order time-series data, the massive and chaotic order flow is divided into multiple order time-series data clusters with relatively consistent internal characteristics. Based on this, multi-level feature extraction operations are performed on each cluster to generate a cluster-level feature description vector that comprehensively reflects the behavioral characteristics and state changes of the order group over time. This elevates the analysis object from discrete single orders or chaotic overall data to the level of order groups with similar characteristics. The generated vector can more precisely and structurally represent the operational status of different order sets, providing a high-information-density input foundation for subsequent deep pattern analysis and overcoming the noise interference and dimensionality curse problems caused by directly processing raw data.

[0016] A pre-trained temporal pattern matching model is used to perform real-time matching analysis on the aforementioned cluster-level feature description vectors. This model can learn from historical data and identify various complex temporal patterns related to processing latency. When the feature vector of the current order cluster highly matches a certain potential latency pattern, the system can identify it before the latency actually occurs or spreads on a large scale. Based on this identification result, the system automatically triggers the corresponding resource pre-allocation strategy and generates specific resource allocation instructions. This transforms resource scheduling from passive remediation after latency occurs to proactive intervention based on pattern recognition. It enables the system to supplement computing, storage, or network resources in advance at specific stages based on the micro-characteristics of the current order flow, thereby curbing the deterioration of identified latency patterns and maintaining the smooth flow of order processing. Attached Figure Description

[0017] Figure 1 This is a schematic diagram illustrating the working principle of the e-commerce order management method based on cloud data analysis described in this invention.

[0018] Figure 2 A flowchart for generating differentiated order time-series data clusters.

[0019] Figure 3 A flowchart for forming cluster-level feature description vectors.

[0020] Figure 4 A graph showing the changes in the utilization rate of compute nodes and database connection pools at different time points.

[0021] Figure 5 This is a comparison chart of the average order processing time monitoring cycle before and after resource allocation under the medium delay mode. Detailed Implementation

[0022] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0023] Please see Figure 1This invention provides an e-commerce order management method based on cloud data analysis. The method includes: obtaining a set of order time-series data within a time window from cloud storage; performing a clustering operation on the set to divide it into multiple order time-series data clusters with similar internal characteristics but differences between each other, based on the time-series and content characteristics of the data; performing multi-level feature extraction operations on each of the divided order time-series data clusters to quantify its statistical and distribution characteristics, forming a cluster-level feature description vector that can characterize the overall state of the cluster; inputting the generated cluster-level feature description vector into a pre-trained time-series pattern matching model, which identifies at least one potential processing delay pattern from the vector through comparative analysis; triggering a resource pre-allocation strategy associated with the identified potential processing delay pattern, generating a set of specific resource allocation instructions; executing the resource allocation instructions to adjust system resources, and collecting system runtime data after adjustment, combining it with the expected standards corresponding to the previously identified potential processing delay patterns to complete a comprehensive judgment of the current order flow status.

[0024] In one embodiment of the present invention, see [reference] Figure 2 The process involves acquiring a set of order time-series data stored in the cloud, performing clustering operations on this set to generate multiple differentiated order time-series data clusters. The specific implementation is as follows: The original order record stream generated within a preset time window is retrieved from a designated cloud storage node. This stream is parsed to extract order time-series data containing creation timestamps, payment status markers, product category codes, and user identifiers, which are then aggregated to form an initial order time-series data set. Based on preset time-series similarity measurement rules, the similarity distance between different order time-series data in the initial set is calculated. Creation timestamps are extracted from two separate order time-series data sets, and the absolute time difference between their creation timestamps is calculated. Product category codes are also extracted from the two sets. If the product category codes are the same, the code similarity is assigned a specific value; otherwise, a different value is assigned. The absolute time difference and code similarity are weighted and summed, and the sum is defined as the similarity distance between the two order time-series data sets. The weighting coefficients are preset based on historical order processing experience. Based on the calculated similarity distance, the density peak clustering algorithm is used to process the initial order time series data set, grouping order time series data with similarity distances less than a threshold into the same group. Multiple independent data groups are output after clustering, and each independent data group is defined as a differentiated order time series data cluster.

[0025] In practice, the process begins with a designated cloud storage node, retrieving a stream of raw order records generated within a preset time window, which can be the past hour. This stream contains a series of order events recorded in JSON format, with each record including fields such as timestamp, order status, product information, and user information. The raw order record stream is then parsed to extract four key data items: creation timestamp, payment status marker, product category code, and user identifier. The parsing process involves reading each JSON record one by one, extracting the `create_time`, `payment_status`, `category_code`, and `user_id` fields, and combining these four fields into a structured data entry. All data entries parsed within the preset time window are aggregated to form the initial order time-series data set.

[0026] In some embodiments, the similarity distance between different order time series data in the initial order time series data set is calculated based on a preset temporal similarity measurement rule, which defines the specific calculation steps. For any two order time series data to be compared, the creation timestamps are extracted from both order time series data. The creation timestamps are stored in Unix milliseconds. The absolute time difference between the creation timestamps of the two order time series data is calculated; the absolute time difference is the absolute value of the difference between the two. The product category codes are extracted from both order time series data. The product category codes are strings. If the product category codes are the same, the code similarity is assigned a value of 0; if the product category codes are different, the code similarity is assigned a value of 1. The preset temporal similarity measurement rule performs a weighted sum of the absolute time difference and the code similarity. The weighting coefficients are preset based on historical order processing experience. The sum is defined as the similarity distance between the two order time series data. The formula for calculating the similarity distance is expressed as:

[0027] in: This represents the similarity distance between the calculated time-series data of two orders. and These represent the creation timestamps of the two order time series data. This represents the calculated absolute time difference. This represents the code similarity score, which is assigned a value of 0 or 1 based on whether the product category codes are the same. and It is a weighting coefficient pre-set based on historical order processing experience, and it meets the following requirements: .

[0028] In practice, based on the calculated similarity distance, the density peak clustering algorithm is used to process the initial order time-series data set. The clustering process takes all order time-series data as objects and the pairwise similarity distance matrix as input. The density peak clustering algorithm automatically calculates the local density of each order time-series data point and the distance to higher density points, and identifies cluster centers accordingly. Order time-series data with similarity distances less than a preset threshold θ are classified into the same group represented by the same cluster center. Multiple independent data groups are output after clustering. Each independent data group is defined as a differentiated order time-series data cluster. Order time-series data within each cluster have high similarity in creation time and product category, while different order time-series data clusters differ in these characteristics.

[0029] In one embodiment of the present invention, see [reference] Figure 3 To achieve this, a multi-level feature extraction operation is performed on multiple differentiated order time-series data clusters to form a cluster-level feature description vector. The specific implementation is as follows: For each differentiated order time-series data cluster, the total number of order time-series data contained within the cluster is counted, serving as a quantity feature. The average time interval of all order time-series data within each differentiated order time-series data cluster is calculated, serving as a density feature. The frequency of occurrence of product category codes within each differentiated order time-series data cluster is identified, and the most frequent product category codes are extracted to form a category distribution feature. The product category codes contained in all order time-series data within a differentiated order time-series data cluster are traversed, and the number of times each product category code appears within the order time-series data cluster is counted, forming a code frequency statistics table. A pre-set number of product category codes with the highest frequency of occurrence are selected from the code frequency statistics table. These pre-set number of product category codes are arranged in descending order of frequency of occurrence, forming an ordered code sequence. This ordered code sequence serves as the category distribution feature of the order time-series data cluster. The number of unique user identifiers within each differentiated order time-series data cluster is extracted and used as a user scale feature. The quantity feature, density feature, category distribution feature, and user scale feature extracted for each differentiated order time-series data cluster are sequentially concatenated and normalized to generate a fixed-dimensional numerical vector, which is defined as the cluster-level feature description vector.

[0030] In practical implementation, for a differentiated order time-series data cluster to be processed, the total number of order time-series data contained within the differentiated order time-series data cluster is counted. The total number of order time-series data is an integer value, which is recorded as a quantitative feature representing the size of the order time-series data cluster. The average time interval of all order time-series data within the differentiated order time-series data cluster is calculated. The calculation of the average time interval requires extracting the creation timestamp from each order time-series data within the cluster, arranging all creation timestamps in ascending order, and calculating the average of the differences between adjacent timestamps. The average time interval is a floating-point value, which is recorded as a density feature representing the temporal tightness of the order time-series data cluster. The frequency of occurrence of product category codes within each differentiated order time-series data cluster is identified, and the top few product category codes are extracted to form category distribution features. This process follows defined steps. The product category codes contained in all order time-series data within a differentiated order time-series data cluster are traversed. The product category codes are of string type. The frequency of each unique product category code within the differentiated order time-series data cluster is counted, resulting in a code frequency statistics table. This table uses the product category code as the key and the frequency of occurrence as the value. A predetermined number of product category codes with the highest frequency of occurrence are selected from the code frequency statistics table. This predetermined number is a fixed integer, such as 3. These selected product category codes are then arranged in descending order of frequency of occurrence, forming an ordered code sequence. This ordered code sequence serves as the category distribution feature of the differentiated order time-series data cluster, reflecting the main product composition within the cluster.

[0031] In practice, the number of unique user identifiers within each differentiated order time-series data cluster is extracted. The number of unique users is the total number of unique users obtained after performing a set deduplication operation on the user identifier field across all order time-series data within the cluster; this integer value is recorded as the user scale feature. The quantity feature, density feature, category distribution feature, and user scale feature extracted for each differentiated order time-series data cluster are then sequentially concatenated. Sequential concatenation means connecting their numerical representations into a longer numerical sequence according to a predetermined order: quantity feature, density feature, category distribution feature, and user scale feature. This long numerical sequence is then normalized using a max-min scaling method to linearly transform the value of each feature to the [0,1] interval, ultimately generating a fixed-dimensional numerical vector. This numerical vector is defined as a cluster-level feature description vector characterizing the overall characteristics of the differentiated order time-series data cluster.

[0032] Optionally, the average time interval in the density feature is calculated using the formula:

[0033] in: This represents the calculated average time interval. This indicates the total number of order time-series data contained within this differentiated order time-series data cluster. This represents the value of the k-th creation timestamp within the differentiated order time-series data cluster, sorted in ascending order. This represents the summation of the differences between all adjacent timestamps. For an order time series data cluster containing 5 order time series data, the creation timestamps after ascending sorting are [1000, 1050, 1100, 1200, 1250]. Then the average time interval is calculated as ((1050-1000) + (1100-1050) + (1200-1100) + (1250-1200)) / 4 = 62.5.

[0034] In one embodiment of the present invention, based on a trained temporal pattern matching model, matching analysis is performed on cluster-level feature description vectors to identify at least one potential processing delay pattern. The specific implementation is as follows: Historical order operation and maintenance logs are obtained, and event segments with clear processing delays are marked from these logs. Historical order data within a specific time window before the event segment occurs are extracted. Following the same process as generating cluster-level feature description vectors, a historical cluster-level feature description vector sample set is constructed, and each sample is associated with a pattern label representing the severity of the delay. The historical cluster-level feature description vector sample set and its associated pattern labels are used to perform supervised training and validation of the temporal pattern matching model built on a deep residual network until the model converges. The temporal pattern matching model built on a deep residual network includes an input layer, a feature mapping layer, multiple residual blocks, a global pooling layer, and an output layer. The input layer receives cluster-level feature description vectors of fixed dimensions. The feature mapping layer maps the input vectors to a feature space of a preset dimension using a 1×1 convolutional kernel, achieving dimensionality regularization and preliminary feature extraction. Multiple residual blocks are concatenated sequentially. Each residual block consists of two convolutional layers and a skip connection. The convolutional layers use 3×3 kernels for feature enhancement. The skip connection directly passes the input of the residual block to the output and superimposes it with the output of the convolutional layers, effectively mitigating the vanishing gradient problem and enhancing the transfer and preservation of deep features. A global pooling layer performs global average pooling on the feature map output by the residual block, compressing the spatial dimension and retaining key global features. The output layer is a fully connected layer that outputs the matching probability distribution of each potential processing delay mode through a Softmax activation function, completing the mode classification mapping. The currently generated cluster-level feature description vector is input into the trained temporal pattern matching model. The temporal pattern matching model outputs at least one mode label with the highest matching degree to the cluster-level feature description vector, and this at least one mode label is defined as at least one potential processing delay mode.

[0035] In practical implementation, historical order operation and maintenance logs are obtained. These logs record various operational events and status changes during the system's processing of historical orders. Event segments with clear processing delays are manually or rule-basedly marked from these logs. A clear processing delay refers to a recording interval where the order status transition time exceeds a preset threshold. Historical order data within a specific time window preceding the event segment is extracted. The length of this specific time window is a predefined fixed value, such as 30 minutes. The extracted historical order data is processed using the same process as generating cluster-level feature description vectors. This process includes clustering and multi-level feature extraction, constructing a historical cluster-level feature description vector sample set. Each historical cluster-level feature description vector sample is associated with a pattern label representing the severity of the delay. The pattern label is a discrete classification identifier, such as "mild delay" or "severe delay".

[0036] The process of performing density peak clustering followed by feature extraction is based on the need for precise analysis of the group differences in order time-series data. The original order time-series dataset contains massive amounts of discrete data with different temporal and content characteristics. Directly extracting features from the entire dataset would result in features that fail to accurately reflect the behavioral characteristics of specific order groups due to the mixing of order data with different feature attributes, leading to feature ambiguity and information redundancy. Density peak clustering, based on the similarity distance between order time-series data, categorizes order data with similar features into differentiated order time-series data clusters. This ensures consistency in the temporal distribution, product category, and user scale of order data within each cluster, while maintaining significant differences in features between clusters. Multi-level feature extraction based on the clustered clusters focuses on the core features of the same group, effectively filtering out noise interference from the mixing of data from different groups. This makes the extracted cluster-level feature description vectors more targeted and discriminative, providing high-quality feature input for the accurate identification of potential processing delay patterns. This is a crucial preliminary step for early prediction of delay risks.

[0037] In some embodiments, a temporal pattern matching model based on a deep residual network (DRN) is trained and validated using a historical cluster-level feature description vector sample set and its associated pattern labels. The DRN is a feedforward neural network structure containing skip connections. During training, the historical cluster-level feature description vector sample set is randomly divided into a training subset and a validation subset. The training subset is used to iteratively update the weight parameters of the DRN, while the validation subset is used to monitor the model's performance on unseen data during training to prevent overfitting. Supervised training uses the cross-entropy loss function.

[0038] in: This represents the average loss value of a batch of data. This indicates the number of historical cluster-level feature description vector samples in this batch. This indicates the total number of pattern label categories. It is an indicator function, when the sample The true label is the category The value is 1 if it is true and 0 otherwise. This represents the predicted samples of the time-series pattern matching model. Category The probability. The training process minimizes the loss function using the backpropagation algorithm. Until the model converges, which means that the value of the loss function on the validation subset no longer decreases significantly over multiple consecutive training epochs.

[0039] Optionally, the severity of latency represented by the pattern label can be graded based on the actual latency recorded in historical order operation logs. For example, events with a processing latency between 1 and 5 minutes can be labeled as "mild latency," and events with a processing latency exceeding 5 minutes can be labeled as "severe latency." The structure configuration of the deep residual network can include multiple residual blocks, each containing a fully connected layer, a batch normalization layer, and an activation function. The last layer of the network is a Softmax layer used to output the probability distribution. The optimizer used during training can be Adam, the learning rate can be set to 0.001, and the batch size can be set to 32.

[0040] It is understandable that the quality of the historical cluster-level feature description vector sample set directly affects the recognition capability of the temporal pattern matching model, and the samples need to cover various different latency scenarios. The temporal pattern matching model extracts the complex mapping relationship between features and pattern labels from historical samples through supervised learning. After the model is trained, its parameters are fixed and used to quickly analyze and match patterns on new and unknown cluster-level feature description vectors. The identified potential processing latency patterns are predictive judgments of the possible processing latency of the order set represented by the current order temporal data cluster in the future.

[0041] In one embodiment of the present invention, a mapping table between potential processing latency patterns and resource allocation templates is pre-set. At least one potential processing latency pattern is queried from the mapping table to obtain at least one corresponding initial resource allocation template. A real-time resource load snapshot of the current cloud platform is read, including compute node utilization and database connection pool utilization. Using the compute node utilization and database connection pool utilization contained in the real-time resource load snapshot, the parameters in at least one initial resource allocation template are dynamically corrected. An initial resource allocation template is read, containing a baseline expansion quantity for compute resources and a baseline number of connections for the database connection pool. The current compute node utilization in the real-time resource load snapshot is obtained and divided by a standard utilization threshold to obtain a compute resource adjustment coefficient. The baseline expansion quantity is multiplied by the compute resource adjustment coefficient to obtain the corrected compute resource expansion quantity. The current database connection pool utilization in the real-time resource load snapshot is obtained and divided by a standard connection pool utilization threshold to obtain a connection pool adjustment coefficient. The baseline number of connections is multiplied by the connection pool adjustment coefficient to obtain the corrected number of database connection pool connections. The corrected compute resource expansion quantity replaces the baseline expansion quantity, and the corrected number of database connection pool connections replaces the baseline number of connections, completing the dynamic correction of the initial resource allocation template. The at least one dynamically corrected resource allocation template is then transformed into a series of operation commands that can be directly recognized and executed by the cloud platform scheduling system. These operation commands are integrated into a resource allocation instruction set.

[0042] In practice, a resource pre-allocation strategy is triggered based on at least one potential processing latency pattern, generating a set of resource allocation instructions. The implementation process relies on a pre-defined mapping relationship and the reading of the cloud platform's real-time load. A pre-defined mapping table exists between potential processing latency patterns and resource allocation templates. This table is stored in a structured form in the configuration database. Table 1 illustrates an exemplary mapping relationship, where each row defines an initial resource allocation strategy framework corresponding to a potential processing latency pattern. At least one potential processing latency pattern is queried from the mapping table to obtain at least one corresponding initial resource allocation template. For example, if the identified potential processing latency pattern is "severe latency," the initial resource allocation template corresponding to this pattern is retrieved from the mapping table. This initial resource allocation template includes a baseline expansion quantity for computing resources and a baseline number of connections for the database connection pool.

[0043] Table 1: Mapping Table of Potential Processing Latency Patterns and Initial Resource Allocation Templates

[0044] In some embodiments, a real-time resource load snapshot of the current cloud platform is read. This snapshot is periodically generated by the cloud platform's monitoring system and provides a query interface. The real-time resource load snapshot includes compute node utilization and database connection pool utilization. Compute node utilization is a percentage of CPU utilization, and database connection pool utilization is the percentage ratio of currently used connections to the maximum number of connections in the connection pool. The compute node utilization and database connection pool utilization contained in the real-time resource load snapshot are used to dynamically adjust parameters in at least one initial resource allocation template. An initial resource allocation template is read; for example, the initial resource allocation template corresponding to "heavy latency" includes a baseline expansion quantity of 5 for compute resources and a baseline number of 20 for the database connection pool. The current compute node utilization in the real-time resource load snapshot is obtained and divided by a standard utilization threshold to obtain a compute resource adjustment coefficient. The standard utilization threshold is a preset baseline value, such as 70%. The baseline expansion quantity is multiplied by the compute resource adjustment coefficient to obtain the corrected compute resource expansion quantity. Obtain the current database connection pool utilization rate from the real-time resource load snapshot and divide it by a standard connection pool utilization rate threshold to obtain a connection pool adjustment factor. The standard connection pool utilization rate threshold is a preset baseline value, such as 80%. Multiply the baseline connection number by the connection pool adjustment factor to obtain the corrected database connection pool connection number. Replace the baseline expansion quantity with the corrected computing resource expansion quantity, and replace the baseline connection number with the corrected database connection pool connection number, thus completing the dynamic correction of the initial resource allocation template.

[0045] In practical implementation, the calculations during the dynamic correction process can be performed using the following formula:

[0046] in: This represents the final resource quantity obtained after dynamic adjustment, which can be the calculated resource expansion quantity or the number of database connection pool connections. This represents the baseline resource quantity read from the initial resource allocation template, which can be the baseline expansion quantity or the baseline number of connections. This represents the current resource utilization rate read from a real-time resource load snapshot, which can be compute node utilization or database connection pool utilization. This represents the preset standard resource utilization threshold, which can be either the standard utilization threshold or the standard connection pool utilization threshold. The compensation coefficient is a configurable positive real number parameter.

[0047] See Figure 4The cloud platform resource load monitoring scenario presented showcases the dynamic changes in compute node utilization and database connection pool utilization at different time points, while also indicating the standard thresholds (70%) for compute nodes and (80%) for database connection pools. Specifically, the graph uses time as the horizontal axis and compute node utilization (left vertical axis) and database connection pool utilization (right vertical axis) as the dual vertical axes, clearly showing the fluctuation characteristics of these two resource utilization rates through line graphs: At 08:00, compute node utilization was at 65% (below the standard threshold of 70%), and database connection pool utilization was at 72% (below the standard threshold of 80%); as time progressed to 12:00, both showed an upward trend, with compute node utilization reaching 85% (far exceeding the standard threshold) and database connection pool utilization reaching 87% (above the standard threshold); at 14:00, there was a phased decline, with compute node utilization dropping to 72% and database connection pool utilization dropping to 75%; at 16:00, it reached a peak, with compute node utilization at 90% and database connection pool utilization at 92%; subsequently, from 18:00 to 20:00, it gradually declined, with compute node utilization returning to 70% (close to the standard threshold) at 20:00, and database connection pool utilization dropping to 66%. The core value of the graph lies in its intuitive presentation of the time-dimensional fluctuation pattern of cloud platform resource load, providing real-time data support for the dynamic correction stage in the resource pre-allocation strategy. By observing the degree of deviation between resource utilization and standard threshold at different time points, the resource adjustment coefficient can be accurately calculated, thereby realizing the dynamic optimization of the initial resource allocation template.

[0048] In one embodiment of the present invention, a set of resource allocation instructions is executed, and the system runtime data after execution is obtained. Combined with at least one potential processing delay mode, a comprehensive determination of the order flow status is completed. The specific implementation is as follows: The set of resource allocation instructions is sent to the cloud platform scheduling system, which executes the instructions to adjust the number of virtual computing instances or the size of the database connection pool. During the monitoring period after the resource allocation instruction set is executed, runtime metrics of the target system are collected. These metrics include average order processing time, number of erroneous transactions, and queue waiting depth. The collected runtime metrics are compared and analyzed with the expected threshold range implied by at least one potential processing delay mode. Based on at least one potential processing delay mode, a preset mode-threshold mapping knowledge base is queried. This mode-threshold mapping knowledge base is jointly constructed through historical operation and maintenance data statistical analysis and business requirement calibration. The system retrieves the average order processing time threshold range, the upper limit of the number of erroneous transactions threshold, and the upper limit of the queue waiting depth threshold corresponding to each potential processing latency mode. It compares the actual collected average order processing time with the queried average order processing time threshold range to determine if the actual collected average order processing time falls within the threshold range. It then compares the actual collected number of erroneous transactions with the queried upper limit of the number of erroneous transactions threshold to determine if the actual collected number of erroneous transactions is less than or equal to the upper limit of the number of erroneous transactions threshold. Finally, it compares the actual collected queue waiting depth with the queuing upper limit of the queue waiting depth threshold to determine if the actual collected queue waiting depth is less than or equal to the upper limit of the queue waiting depth threshold. If all runtime metrics fall within their corresponding expected threshold ranges, a normal order flow status determination result is generated. If any runtime metric exceeds its corresponding expected threshold range, an abnormal order flow status determination result is generated with an flag indicating the exceeded metric.

[0049] In some embodiments, runtime metrics of the target system are collected during a monitoring period following the completion of the resource allocation instruction set. The monitoring period is a preset fixed duration, such as 10 minutes, calculated from the moment the resource allocation instruction is confirmed to have been executed. The runtime metrics of the target system are collected by querying monitoring probes and system performance monitoring tools deployed on the order processing chain. The collected runtime metrics include average order processing time, number of erroneous transactions, and queue waiting depth. Average order processing time is the average time taken from creation to final status update for all completed orders within the statistical period. The number of erroneous transactions is the total number of order transactions that failed or rolled back due to system errors within the statistical period. The queue waiting depth is the backlog of order messages waiting to be processed in the message queue at the end of the statistical period. The collected runtime metrics are compared and analyzed with the expected threshold range implied by at least one potential processing delay pattern. This comparison and analysis process requires querying a preset pattern-threshold mapping knowledge base, which stores the threshold values ​​of various metrics corresponding to different potential processing delay patterns in key-value pairs.

[0050] In practice, based on at least one potential processing delay pattern, a pre-defined pattern-threshold mapping knowledge base is queried to obtain the average order processing time threshold range, the upper limit of the error transaction number threshold, and the upper limit of the queue waiting depth threshold corresponding to each potential processing delay pattern. The actual collected average order processing time is compared with the average order processing time threshold range obtained from the pattern-threshold mapping knowledge base to determine whether the actual collected average order processing time falls within the threshold range. The actual collected number of error transactions is compared with the upper limit of the error transaction number threshold obtained from the pattern-threshold mapping knowledge base to determine whether the actual collected number of error transactions is less than or equal to the upper limit of the error transaction number threshold. The actual collected queue waiting depth is compared with the upper limit of the queue waiting depth threshold obtained from the pattern-threshold mapping knowledge base to determine whether the actual collected queue waiting depth is less than or equal to the upper limit of the queue waiting depth threshold. In the case of multiple potential processing delay patterns, the most stringent threshold is used for judgment.

[0051] Optionally, the comprehensive determination of the order flow status is generated through a logical determination function, the output of which can be formally represented as:

[0052] in: The output indicates the determination result of the order flow status. This represents the logical AND operator. The index represents three runtime metrics. Indicates the number of actual data collected. The value of the runtime metric. This represents the first value obtained from the pattern-threshold mapping knowledge base corresponding to the current potential processing delay pattern. The threshold or threshold range of the indicator. Indicates that for the first The comparison operators for the metrics. If all runtime metrics fall within their corresponding expected threshold ranges, i.e., the logical judgment function result is true, a structured data object is generated as the order flow status judgment result representing a normal status. This data object contains the status code "NORMAL" and a timestamp.

[0053] It is understandable that the monitoring cycle setting needs to ensure that the effects of resource allocation operations are fully reflected in the system's runtime metrics. The establishment of the pattern-threshold mapping knowledge base relies on the analysis and summarization of system metrics under historical normal operating conditions and various delay modes. The order flow status determination result is a comprehensive evaluation of the effectiveness of the resource pre-allocation strategy and the current system health. A normal status determination result indicates that the system is operating within the expected range after resource allocation, and potential processing delay risks are mitigated. An abnormal status determination result indicates that resource allocation may not have achieved the expected results or that new anomalies have occurred, requiring further alarm or manual intervention procedures. The order flow status determination result provides clear, data-driven conclusions for operational decisions.

[0054] See Figure 5 In the verification of the resource pre-allocation strategy under the medium latency mode, the trend of the average order processing time before and after resource allocation was presented over eight monitoring periods. The threshold range (10 to 15 minutes) for the average order processing time under this mode was also marked. Specifically, the average order processing time before resource allocation (red line) fluctuated significantly, exceeding the upper threshold (15 minutes) multiple times, reflecting the processing efficiency risk under the medium latency mode without resource allocation. After resource allocation (green line), the average order processing time remained within the threshold range and was generally lower than before allocation, indicating that the resource pre-allocation strategy effectively alleviated the order processing latency problem under the medium latency mode. The lower threshold (10 minutes) and the upper threshold (15 minutes) constitute the expected indicator range for system operation under this latency mode. The time data after resource allocation all fell within this range, corresponding to the order flow status judgment result of "NORMAL".

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

[0056] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for e-commerce order management based on cloud data analysis, characterized in that, The method includes: Obtain the order time-series data set stored in the cloud, perform a clustering operation on the order time-series data set, and generate multiple differentiated order time-series data clusters; Perform multi-level feature extraction operations on the multiple differentiated order time-series data clusters to form cluster-level feature description vectors; Based on the trained temporal pattern matching model, a matching analysis is performed on the cluster-level feature description vector to identify at least one potential processing delay pattern. Based on the at least one potential processing delay pattern, a resource pre-allocation strategy is triggered to generate a set of resource allocation instructions; The resource allocation instruction set is executed, the system runtime data after execution is obtained, and the order flow status is comprehensively determined by combining the at least one potential processing delay mode.

2. The e-commerce order management method based on cloud data analysis according to claim 1, characterized in that, Obtain a set of order time-series data stored in the cloud, perform clustering operations on the order time-series data set, and generate multiple differentiated order time-series data clusters, including: Retrieve the stream of original order records generated within a preset time window from the specified cloud storage node; The original order record stream is parsed to extract order time-series data containing creation timestamps, payment status markers, product category codes, and user identifiers, which are then aggregated to form an initial order time-series data set. Based on the preset temporal similarity measurement rules, the similarity distance between different order temporal data in the initial order temporal data set is calculated; Based on the calculated similarity distance, the density peak clustering algorithm is used to process the initial order time series data set, and order time series data with similarity distance less than the threshold are classified into the same group; Output multiple independent data groups after clustering, and define each independent data group as a differentiated order time series data cluster.

3. The e-commerce order management method based on cloud data analysis according to claim 2, characterized in that, Perform multi-level feature extraction operations on the multiple differentiated order time-series data clusters to form cluster-level feature description vectors, including: For each differentiated order time series data cluster, the total number of order time series data contained in that cluster is counted as a quantitative feature; Calculate the average time interval of all order time series data within each differentiated order time series data cluster, and use it as a density feature; Identify the frequency of occurrence of product category codes within each differentiated order time-series data cluster, and extract the most frequent product category codes to form category distribution features; Extract the number of unique user identifiers within each differentiated order time-series data cluster as a user scale feature; The quantity features, density features, category distribution features, and user scale features extracted from each differentiated order time-series data cluster are sequentially concatenated and normalized to generate a fixed-dimensional numerical vector, which is then defined as the cluster-level feature description vector.

4. The e-commerce order management method based on cloud data analysis according to claim 3, characterized in that, Based on the trained temporal pattern matching model, a matching analysis is performed on the cluster-level feature description vector to identify at least one potential processing delay pattern, including: Obtain historical order operation and maintenance logs, and mark the event segments in the historical order operation and maintenance logs that have clear processing delays; Historical order data within a specific time window prior to the occurrence of the event segment is extracted. Following the same process as generating the cluster-level feature description vector, a historical cluster-level feature description vector sample set is constructed, and each sample is associated with a pattern label representing the severity of the delay. The historical cluster-level feature description vector sample set and its associated pattern labels are used to supervise the training and validation of the temporal pattern matching model built on the deep residual network until the model converges. The currently generated cluster-level feature description vector is input into the trained temporal pattern matching model; The temporal pattern matching model outputs at least one pattern label that has the highest matching degree with the cluster-level feature description vector, and defines the at least one output pattern label as at least one potential processing delay pattern.

5. The e-commerce order management method based on cloud data analysis according to claim 4, characterized in that, Based on the at least one potential processing latency pattern, a resource pre-allocation strategy is triggered to generate a set of resource allocation instructions, including: A pre-defined mapping table exists between potential processing delay modes and resource allocation templates; Query the mapping table for the at least one potential processing delay pattern and obtain the corresponding at least one initial resource allocation template; Read the real-time resource load snapshot of the current cloud platform, which includes the utilization rate of computing nodes and the utilization rate of database connection pool; The parameters in the at least one initial resource allocation template are dynamically adjusted using the compute node utilization and database connection pool utilization included in the real-time resource load snapshot. At least one resource allocation template that has been dynamically corrected is transformed into a series of operation commands that can be directly recognized and executed by the cloud platform scheduling system, and these operation commands are integrated into a resource allocation instruction set.

6. The e-commerce order management method based on cloud data analysis according to claim 5, characterized in that, Execute the set of resource allocation instructions, obtain the system runtime data after execution, and combine it with the at least one potential processing delay mode to complete a comprehensive determination of the order flow status, including: The set of resource allocation instructions is sent to the cloud platform scheduling system, which then executes the instructions to adjust the number of virtual computing instances or the size of the database connection pool. During the monitoring period after the resource allocation instruction set is executed, runtime metrics of the target system are collected, including average order processing time, number of erroneous transactions, and queue waiting depth. The collected runtime metrics are compared and analyzed with the expected threshold range implied by the at least one potential processing latency pattern; If all the runtime indicators fall within their corresponding expected threshold range, an order flow status determination result indicating a normal status is generated. If any runtime metric exceeds its corresponding expected threshold range, an order flow status determination result is generated, indicating an abnormal status and accompanied by an identifier for the exceeding metric.

7. The e-commerce order management method based on cloud data analysis according to claim 2, characterized in that, Based on a preset temporal similarity measurement rule, the similarity distance between different order time-series data in the initial order time-series dataset is calculated, including: Extract the creation timestamps from the two order time series data respectively, and calculate the absolute time difference between the creation timestamps of the two order time series data; Extract the product category codes from the time-series data of the two orders respectively. If the product category codes are the same, the code similarity is set to a specific value; if the product category codes are different, the code similarity is set to another specific value. The absolute time difference and the encoding similarity are weighted and summed, and the summation result is defined as the similarity distance between the two order time series data. The weighting coefficient is preset based on historical order processing experience.

8. The e-commerce order management method based on cloud data analysis according to claim 3, characterized in that, Identify the frequency of product category codes within each differentiated order time-series data cluster, and extract the most frequent product category codes to construct category distribution features, including: Iterate through all the product category codes contained in the order time series data within a differentiated order time series data cluster; Count the number of times each product category code appears in the order time series data cluster to form a code frequency statistics table; Select a pre-defined number of product category codes that appear most frequently from the code frequency statistics table; The selected pre-defined number of product category codes are arranged in descending order of frequency of occurrence to form an ordered code sequence, which is then used as the category distribution feature of the order time-series data cluster.

9. The e-commerce order management method based on cloud data analysis according to claim 5, characterized in that, Using the compute node utilization and database connection pool utilization included in the real-time resource load snapshot, the parameters in the at least one initial resource allocation template are dynamically adjusted, including: Read an initial resource allocation template, which includes a baseline expansion amount for computing resources and a baseline number of connections for the database connection pool; Obtain the current computing node utilization rate in the real-time resource load snapshot and divide it by the standard utilization rate threshold to obtain a computing resource adjustment coefficient; Multiply the baseline expansion amount by the computing resource adjustment coefficient to obtain the corrected computing resource expansion amount; Obtain the current database connection pool utilization rate in the real-time resource load snapshot, and divide it by the standard connection pool utilization rate threshold to obtain a connection pool adjustment coefficient; Multiply the baseline number of connections by the connection pool adjustment factor to obtain the corrected number of database connection pool connections; The modified computing resource expansion quantity is used to replace the baseline expansion quantity, and the modified database connection pool connection quantity is used to replace the baseline connection quantity, thereby completing the dynamic modification of the initial resource allocation template.

10. The e-commerce order management method based on cloud data analysis according to claim 6, characterized in that, The collected runtime metrics are compared and analyzed with the expected threshold range implied by the at least one potential processing latency pattern, including: Based on the at least one potential processing delay pattern, query the preset pattern-threshold mapping knowledge base to obtain the average order processing time threshold range, the upper limit of the number of erroneous transactions threshold, and the upper limit of the queue waiting depth threshold corresponding to each potential processing delay pattern; The actual average processing time of collected orders is compared with the threshold range of average processing time of orders obtained by querying, to determine whether the actual average processing time of collected orders falls within the threshold range of average processing time of orders. The number of erroneous transactions actually collected is compared with the upper limit of the erroneous transaction number threshold obtained by querying, and it is determined whether the number of erroneous transactions actually collected is less than or equal to the upper limit of the erroneous transaction number threshold. The actual queue waiting depth is compared with the upper limit of the queue waiting depth threshold obtained from the query, and it is determined whether the actual queue waiting depth is less than or equal to the upper limit of the queue waiting depth threshold.

Images