Backtracking call ticket re-pricing method based on mixed fragmentation and distribution calculation

Abstract

The invention discloses a backtracking call ticket re-pricing method based on mixed fragmentation and distributed calculation, relates to the technical field of communication information processing, and aims to solve the problems that an existing backtracking re-pricing scheme is lack of an influence pre-judgment and auditing mechanism due to rule hard coding and centralized processing, and the efficiency is low. The problem that massive historical call tickets cannot be efficiently, accurately and flexibly processed in a high-frequency charge change scene is solved, an influence range is accurately delineated through a space-time influence domain prediction algorithm to reduce a processing set, and an input basis is provided for gray release of a dynamic rule engine; the dynamic rule engine switches multi-version rules in real time to ensure flexible adaptive change; resource self-adaptive parallel computing is realized by combining a hybrid fragmentation strategy optimized by a genetic algorithm and elastic scheduling, and the processing efficiency is improved; and a difference auditing mechanism compares new and old results in real time to perform accurate verification, so that closed-loop quality control is formed, and collaborative improvement of efficiency, accuracy and flexibility of backtracking and re-pricing of mass call tickets is realized.

Description

Technical Field

[0001] This invention relates to the field of communication information processing technology, specifically to a method for re-pricing of retrospective call detail records based on hybrid fragmentation and distributed computing. Background Technology

[0002] With the development of mobile internet services and intensified market competition, telecommunications operators need to frequently adjust tariff standards and preferential policies, resulting in a large-scale demand for historical call detail records (CDRs) to be reviewed and re-priced. However, existing technologies are insufficient to meet the requirements of efficient, accurate, and flexible processing. In existing solutions, traditional centralized processing methods rely on hard-coded business logic, resulting in slow processing speeds and high latency when dealing with massive amounts of CDRs. Furthermore, rule adjustments require extensive manual modification and recompilation, leading to extremely poor flexibility. While some distributed billing solutions can improve efficiency to some extent, they lack dynamic rule engine support, making it impossible to achieve real-time loading and dynamic switching of multiple rule versions. Moreover, the lack of a precise difference auditing mechanism makes data or logical errors prone to occur during re-pricing, compromising accuracy. Simultaneously, existing technologies generally suffer from unreasonable resource scheduling, resulting in either node overload or idle resources. This leads to high consumption of computing and storage resources, high operating costs, and delayed assessment of the impact of re-pricing, easily causing user complaints and revenue losses. These technologies are ill-suited to the business scenarios of high-frequency rule changes and massive CDR review in the telecommunications industry.

[0003] Chinese Patent Publication No. CN112838932A discloses a method, apparatus, and computing device for repricing based on cumulative pricing. The method first determines the scope of call detail record (CDR) repricing and then obtains a set of CDRs. It then merges and summarizes the original resource quantities according to preset dimensions and deducts the accumulated quantity before repricing. Next, it calculates the incremental cost using the cumulative pricing method and updates the accumulated quantity summary information to avoid processing each CDR individually and improve efficiency. However, due to its lack of a mechanism for accurately predicting the scope of impact, lack of support for real-time loading and dynamic switching of multiple version rules, fixed segmentation strategy, and lack of flexible resource scheduling capabilities, it is difficult to adapt to personalized business needs and the efficient and accurate backtracking and repricing of massive CDRs.

[0004] The information disclosed in the background section is only intended to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The purpose of this invention is to address the problem that existing retrospective repricing schemes, due to hard-coded rules, centralized processing, and lack of impact prediction and auditing mechanisms, cannot efficiently, accurately, and flexibly handle massive historical call detail records (CDRs) in high-frequency tariff change scenarios. This invention proposes a retrospective CDR repricing method based on hybrid sharding and distributed computing. A spatiotemporal impact domain prediction algorithm is used to accurately define the impact range to narrow down the processing set, providing an input basis for the canary release of the dynamic rule engine. The dynamic rule engine switches between multiple rule versions in real time to ensure flexible adaptation to changes. A hybrid sharding strategy optimized by a genetic algorithm and elastic scheduling achieves adaptive parallel computing of resources, improving processing efficiency. A differential auditing mechanism compares the old and new results in real time for accurate verification, forming a closed-loop quality control, achieving a synergistic improvement in efficiency, accuracy, and flexibility for massive CDR retrospective repricing.

[0006] Based on this, one technical solution provided in this embodiment of the invention is: a method for re-pricing of retrospective call detail records based on hybrid fragmentation and distributed computing, comprising the following steps: The impact range of the re-pricing is assessed by a spatiotemporal impact domain prediction algorithm, and the set of call records to be traced is obtained from the billing call record database based on the impact range. Load multiple versions of pricing rules, and match the target pricing rule for each call detail record in the set of call detail records to be traced back by using preset rule hit conditions to construct a set of call detail records to be processed with rule version identifiers; A hybrid fragmentation strategy is used to dynamically fragment the call detail records (CDRs) set to be processed to obtain fragmented CDR sets. A flexible resource scheduling strategy is used to match a corresponding distributed computing node for each fragmented CDR set. Based on the distributed computing nodes and according to the preset backtracking mechanism, the call detail record (CDR) re-pricing is performed on each segment of CDR sets to obtain the preliminary re-pricing. The differential review mechanism determines the degree of difference between the initial re-approval price and the historical price, and determines the target re-approval price or early warning information for the corresponding segmented episode based on the degree of difference.

[0007] As a preferred approach, the steps of evaluating the impact range of repricing through a spatiotemporal impact domain prediction algorithm and then selecting the set of call detail records to be backtracked from the billing call detail record database based on the impact range are as follows: In response to the repricing event, the instruction retrieves the associated tariff rule change identifier, business impact time window, and business type identifier. Based on the tariff rule change identifier, the corresponding rule impact indicator is obtained from the multi-version rule base; according to the service impact time window, the total historical call records of the service type identifier are matched from the billing call record base; based on the total historical call records and the rule impact indicator, the predicted value of the spatiotemporal impact domain is determined; The impact range when the predicted value of the spatiotemporal impact domain exceeds a preset threshold is determined based on the rule-based impact indicators. Extract call detail records (CDRs) from the billing CDR database that belong to the scope of the impact and construct a set of CDRs to be traced back. The rules affect metrics including billing user coverage, call detail record (CDR) service type weight, and time window matching rate.

[0008] As a preferred embodiment, the step of determining the influence range when the predicted value of the spatiotemporal influence domain exceeds a preset threshold based on the rule-based influence index is as follows: Based on the billing user coverage rate, and combined with the association between user identifiers and service type identifiers, a list of affected users is determined; Based on the weight of the call detail record service type, and combined with the service classification mapping relationship defined in the rule hit condition field, a call detail record service classification list is determined. Based on the time window matching rate, and combined with the business impact time window, the effective re-pricing time interval is determined to generate a time window list; The scope of influence is formed by associating and integrating the list of affected users, the list of call detail records (CDRs) for different service categories, and the list of time windows.

[0009] As a preferred embodiment, the step of matching target pricing rules to each call detail record (CDR) in the set to be traced back using preset rule matching conditions to construct a set of CDRs to be processed with rule version identifiers is as follows: Based on the multi-version rule base, load at least two versions of the pricing rules associated with the current repricing event, and construct a rule index for each rule version that includes the rule version number and the rule hit conditions; Extract the key feature fields of each call detail record (CDR) in the set of CDRs to be traced back, match the key feature fields with the rule hit conditions in the rule index, and determine the initial target rule corresponding to the current CDR. The initial target rules are verified and adjusted based on the canary release strategy and traffic allocation algorithm to determine the unique target pricing rule corresponding to each call detail record and add a rule version identifier to the target pricing rule. All call detail records (CDRs) carrying the aforementioned rule version identifier are integrated to construct the set of CDRs to be processed.

[0010] As a preferred approach, the steps for verifying and adjusting the initial target rules based on the canary release strategy and traffic allocation algorithm to determine the unique target pricing rule corresponding to each call detail record are as follows: Based on the key feature fields of the call detail record, business attribute information is extracted, including user level and region priority. The traffic allocation weight of the current call detail record is determined based on the business attribute information and the preset weight coefficient. The initial target rule for the call detail record (CDR) whose traffic allocation weight exceeds the gray-scale release traffic threshold will be switched to a new gray-scale release rule version. Determine the version performance metrics for the new rule version, including rule hit rate, error rate, and response time; When the hit rate in the performance metrics is lower than the preset hit rate threshold, the error rate exceeds the preset error threshold, or the response time exceeds the preset latency threshold, the rule version is dynamically rolled back, and the corresponding call detail record pricing rule is adjusted back to the initial target rule. Based on the final rule version determination result, a unique target pricing rule and its corresponding rule version identifier are assigned to each call detail record (CDR).

[0011] As a preferred embodiment, the steps of dynamically fragmenting the call detail records (CDRs) set to be processed using a hybrid fragmentation strategy to obtain fragmented CDR sets are as follows: The resource status information of the distributed computing cluster is obtained in real time. The resource status information includes at least the number of available distributed computing nodes, the memory capacity of each distributed computing node, and the current load. The optimal shard size is determined based on the average available memory of distributed computing nodes, the load balancing factor, and the memory overhead of a single call detail record. The load balancing factor is a value obtained by dynamically optimizing the execution efficiency of historical tasks using a genetic algorithm. Based on the optimal segment size and the rule version identifier distribution of the call detail records (CDRs) set to be processed, the CDR set to be processed is dynamically segmented to generate multiple segmented CDR sets.

[0012] As a preferred embodiment, the step of matching the corresponding distributed computing node for each segmented call set using an elastic resource scheduling strategy is as follows: The computing performance metrics of each available distributed computing node in the distributed computing cluster are obtained in real time, including CPU utilization, memory utilization and task queue length. The resource matching degree between each available distributed computing node and each segmented call case is determined based on the data volume of each segmented call case set, the complexity of the rule version, and the computing performance indicators. Based on the resource matching degree, the fragmented segments are sorted in descending order, and the fragmented segments are preferentially allocated to the distributed computing nodes with the highest resource matching degree.

[0013] As a preferred embodiment, the step of matching each segmented call set with a corresponding distributed computing node through an elastic resource scheduling strategy further includes the following steps: During the execution of the matching task, the actual load and task execution progress of each distributed computing node are continuously monitored; If the actual load of any distributed computing node is detected to continuously exceed the preset load threshold or the task execution progress lags behind the preset plan value within a set time domain, then the unfinished part or all of the fragments on the current distributed computing node will be migrated to the distributed computing node with the second highest resource matching degree.

[0014] As a preferred embodiment, the steps for obtaining preliminary re-pricing by performing call detail record (CDR) re-pricing on each CDR segment based on a preset backtracking mechanism using distributed computing nodes are as follows: Identify the type of backtracking mechanism applicable to the fragmented single set on each distributed computing node, wherein the backtracking mechanism type includes a full backtracking mechanism or an incremental backtracking mechanism; Based on the type of the backtracking mechanism and the rule version identifier in the segmented call detail records, the corresponding target pricing rule and its key billing parameters are loaded from the local rule base or the central rule base. If it is a full rollback mechanism, then all historical call records of the user identifier involved in the segmented call record set within a single billing cycle are extracted as call records to be repriced; if it is an incremental rollback mechanism, then based on the effective time window of the rule change, call records in the segmented call record set that belong to the effective time window are selected as call records to be repriced. Based on the target pricing rules, the key billing parameters corresponding to the call detail records to be repriced are recalculated to generate the initial repricing price for each call detail record to be repriced. The key billing parameters include key billing parameters, free resource consumption, and cumulative resource usage.

[0015] As a preferred approach, the steps of determining the degree of difference between the preliminary re-approval price and the historical re-approval price through a differential review mechanism, and determining the target re-approval price or early warning information for the corresponding segmented call unit based on the degree of difference, are as follows: The system acquires and compares the preliminary re-billing price with the original historical billing price for each segment of call detail records in parallel, and calculates the difference value of at least one key billing parameter; then compares the difference value with a preset difference threshold. If none of the aforementioned differences exceed the corresponding difference threshold, the corresponding preliminary re-approval price will be determined as the final target re-approval price for the current call detail record to be re-approved. If any of the aforementioned differences exceeds the corresponding difference threshold, an early warning message will be triggered, and the corresponding call detail record (CDR) identifier, difference item, and difference value will be recorded in the anomaly list.

[0016] The present invention has at least the following substantial beneficial effects: (1) In view of the problems of lagging assessment of the impact range of repricing and redundant processing of invalid data in existing technologies, this application adopts a spatiotemporal impact domain prediction algorithm that integrates multi-dimensional rule impact indicators such as billing user coverage rate, call detail record service type weight and time window matching rate. First, it extracts the tariff rule change identifier, service impact time window and service type identifier associated with the repricing event. Then, it dynamically calculates the spatiotemporal impact domain prediction value in combination with the total historical call detail record volume. Then, it integrates the impact user list, call detail record service classification list and time window list to accurately lock the call detail record set to be traced back. This realizes the accurate prediction of the impact range of repricing in advance, greatly reduces the inclusion of invalid data in the processing process, lays an efficient data foundation for the subsequent repricing processing stage, and solves the problem of low processing efficiency caused by the ambiguous definition of the impact range in traditional solutions.

[0017] (2) In view of the problems that existing pricing rules rely on hard coding, lack flexibility in adapting to high-frequency business changes, and have high risk of taking effect, this application constructs an intelligent rule engine that supports real-time loading of multiple versions. First, it constructs a rule index containing the rule version number and the hit conditions for each rule version. Then, it matches the initial target rule based on the key feature fields of the call detail record. Combined with the traffic allocation algorithm based on user level and regional priority, and the dynamic verification and rollback mechanism of performance indicators such as rule hit rate and error rate, it realizes accurate matching and safe switching of pricing rules. It breaks through the limitation of the traditional solution's lagging rule updates and can quickly adapt to high-frequency business scenarios such as tariff adjustments and changes in preferential policies. At the same time, it ensures the stability of rule effectiveness through gray release and dynamic rollback, and avoids batch pricing errors.

[0018] (3) To address the issues of difficulty in ensuring accuracy and lack of real-time risk control in the re-pricing process, this application uses a hybrid sharding strategy that optimizes the load balancing factor through a genetic algorithm, dynamically determines the optimal shard size by combining the resource status of the distributed computing cluster, and then achieves optimal matching and adaptive load migration of sharded call detail records (CDRs) with computing nodes through an elastic resource scheduling mechanism that monitors performance indicators such as CPU utilization and memory usage in real time. Combined with a differential auditing mechanism that compares CDRs in parallel, this achieves efficient utilization of computing resources and accurate control of pricing results. This not only solves the problems of resource waste and node overload caused by traditional centralized processing or fixed sharding strategies, but also controls the risk of pricing errors during the processing through a real-time differential verification and early warning mechanism, ensuring the accuracy and reliability of the re-pricing results.

[0019] The above description of the invention is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0020] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings. The drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings.

[0021] Figure 1 This is a flowchart of the retrospective call detail record repricing method based on hybrid fragmentation and distributed computing according to an embodiment of the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only one preferred embodiment of this invention and are only used to explain this invention. They do not limit the scope of protection of this invention. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0023] Before discussing the exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe the operations (or steps) as sequential processes, many of the operations (or steps) can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but it may also have additional steps not included in the figures; the process may correspond to a method, function, procedure, subroutine, subroutine, etc.

[0024] Example 1: As Figure 1 As shown in the embodiments of the present invention, one technical solution provided is: a method for re-pricing of retrospective call detail records based on hybrid fragmentation and distributed computing, as shown in steps S1 to S5.

[0025] S1. Evaluate the impact range of re-pricing through the spatiotemporal impact domain prediction algorithm, and select the set of call records to be traced back from the billing call record database according to the impact range.

[0026] Understandably, in order to solve the problems of vague assessment of the impact range of re-pricing in existing technologies, invalid data redundancy caused by subjective judgment, and low efficiency of subsequent processing, this embodiment S1, through the collaborative design of steps S11 to S14, takes multi-dimensional indicator quantitative calculation and precise correlation screening as the core to achieve accurate prediction of the impact range of re-pricing and efficient locking of target single sets, laying an efficient data foundation for subsequent re-pricing processing.

[0027] S11. Retrieve the tariff rule change identifier, business impact time window, and business type identifier associated with the repricing event trigger instruction.

[0028] Understandably, in S11, in response to repricing event triggering instructions (such as tariff package upgrades, billing rule corrections, etc.), the core information associated with the event is extracted. Among these, the tariff rule change identifier refers to a unique identifier that distinguishes different billing rule adjustments (e.g., "2024 Domestic Data Package Upgrade V3.0"), the service impact time window refers to the time interval during which the rule change actually takes effect (e.g., "June 1, 2024 - June 30, 2024"), and the service type identifier refers to the category of communication service affected by the rule change (e.g., "Domestic 4G / 5G Mobile Data Service"). By extracting these core event-related information, the key elements of the repricing event are accurately captured, providing clear input for subsequent impact scope assessment.

[0029] S12. Obtain the corresponding rule impact indicator from the multi-version rule base based on the tariff rule change identifier; match the total historical call records of the service type identifier from the billing call record base according to the service impact time window; determine the spatiotemporal impact domain prediction value based on the total historical call records and the rule impact indicator; wherein, the rule impact indicator includes billing user coverage, call record service type weight and time window matching rate.

[0030] Understandably, in S12, based on the tariff rule change identifier, the corresponding rule impact indicators (including billing user coverage, call detail record (CDR) service type weight, and time window matching rate) are retrieved from the multi-version rule base. The billing user coverage refers to the proportion of users covered by the rule to the operator's total users; the CDR service type weight is a quantitative coefficient indicating the importance of different service types in repricing; and the time window matching rate is the proportion of historical CDR occurrences falling within the service impact time window) are retrieved. Simultaneously, based on the service impact time window, the total number of historical CDRs with the corresponding service type identifier is matched from the billing CDR base (e.g., 1.5 million domestic 4G / 5G mobile data CDRs within the aforementioned time window). The predicted spatiotemporal impact domain is calculated using the formula Impact = Σ(Billing User Coverage × Time Range Matching Rate × CDR Service Type Weight) × Total CDRs. Through multi-dimensional indicator quantification and data correlation calculation, a quantitative assessment of the impact range is achieved, avoiding the subjective judgment bias of traditional solutions.

[0031] S13. Determine the impact range when the predicted value of the spatiotemporal impact domain exceeds the preset threshold based on the rule-based impact index.

[0032] Understandably, in S13, it is determined whether the predicted value of the spatiotemporal impact domain exceeds the preset threshold. If it does, the list of affected users (such as 1.8 million users corresponding to a billing user coverage rate of 45%), the list of call detail record (CDR) service categories (such as mobile data services), and the list of time windows (such as June 1-30) are determined by combining the rule-based impact indicators. The three are then linked and integrated to form a precise impact range. Through the threshold judgment and the linkage and integration of multi-dimensional lists, the precise boundary of re-pricing is clarified, providing a clear basis for subsequent CDR screening.

[0033] S14. Extract call detail records with user identifiers belonging to the scope of influence from the billing call detail record database to construct a set of call detail records to be traced back.

[0034] Understandably, in S14, user-identified call detail records belonging to the affected area are extracted from the billing call detail record database to construct a set of call detail records to be traced back. Through targeted filtering based on precise boundaries, irrelevant call detail record data is significantly eliminated, effectively reducing the data burden of subsequent re-billing processing.

[0035] Furthermore, to address the issues of ambiguous boundaries in the scope of impact of existing technology re-pricing and incomplete or redundant coverage due to relying on a single dimension, Implementation S13 uses multi-dimensional precise decomposition and association integration design in steps S131 to S134 to achieve a refined definition of the scope of impact by taking rule-based impact indicators as the core and combining business association logic, providing clear and unambiguous boundary basis for the accurate screening of subsequent call detail records to be traced back.

[0036] As an optional embodiment of S13, as shown in S131 to S134.

[0037] S131. Based on the billing user coverage rate, determine the list of affected users by combining the association between user identifiers and service type identifiers.

[0038] Understandably, in S131, the billing user coverage rate (the proportion of users covered by the current tariff rule change to the total number of users of the corresponding service type) is used as the core basis. Combined with the preset association relationship between user identifiers (such as unique identifiers such as user mobile phone number, IMSI number, etc.) and service type identifiers (such as the "domestic mobile data service" identifier) ​​(i.e., a mapping table recording the service types that each user has activated), users who meet the coverage requirements and have activated the target service are screened out to form an affected user list. This step achieves accurate locking of affected users through quantitative screening of coverage rate and verification of service association, and avoids irrelevant users from being included in the re-pricing scope.

[0039] S132. Determine the call detail record service category list based on the call detail record service type weight and the service category mapping relationship defined in the rule hit condition field.

[0040] Understandably, in S132, based on the call detail record (CDR) service type weight (referring to the quantitative coefficient of the importance of different service types in the current repricing event), combined with the predefined service classification mapping relationship in the rule hit condition field (such as the mapping rule of subdividing "voice call" into subcategories such as local call, domestic long-distance, and international roaming), the service subcategories with weights that meet the preset requirements are selected, and a CDR service classification list is constructed. Through weight priority filtering and refined classification mapping, the specific service scenarios that the repricing needs to cover are clarified, avoiding non-core services from occupying processing resources.

[0041] S133. Based on the time window matching rate and the business impact time window, determine the effective re-pricing time interval to generate a time window list.

[0042] Understandably, in S133, based on the time window matching rate (referring to the overlap ratio between the historical call detail record occurrence time and the business impact time window), combined with the business impact time window (the time interval during which the rule change actually has an impact), abnormal time segments with matching rates below the threshold are eliminated, the effective repricing time interval is determined, and a time window list is generated. Through matching rate verification and time interval purification, it is ensured that the repricing only covers the time range of the actual impact of the rule change, and the interference of invalid time segments is eliminated.

[0043] S134. The affected user list, call detail record service category list and time window list are associated and integrated to form the affected scope.

[0044] Understandably, in S134, the aforementioned list of affected users (e.g., 1 million eligible users), the list of call detail records (CDRs) by service category (e.g., international roaming internet access, domestic long-distance calls), and the list of time windows (e.g., July 1st to July 10th) are integrated in three dimensions (i.e., CDRs that simultaneously meet the criteria of "belonging to affected users", "belonging to the target service category", and "occurring within the valid time interval") to ultimately form a precise and non-redundant scope of impact for re-pricing. Through the correlation verification and integration of multi-dimensional lists, a three-dimensional definition of the scope of impact is achieved, completely solving the problem of inaccurate CDR screening caused by the fuzzy boundaries of traditional solutions.

[0045] S2. Load multiple versions of pricing rules, and match the target pricing rule for each call detail record in the set of call detail records to be traced back by using preset rule hit conditions to construct a set of call detail records to be processed with rule version identifiers.

[0046] Understandably, to address the issues of existing technologies such as single-version pricing rules, lack of precise matching verification, inability to adapt to dynamic switching of multiple version rules leading to delayed rule updates and high risk of pricing errors, this embodiment employs methods such as steps S21-S24. Through a collaborative design involving multi-version rule loading, precise matching of key features, dynamic verification during gray-scale release, and integration of version identifiers, with rule indexing and full-process verification as the core, it achieves unique compatibility between call detail records and pricing rules, as well as version traceability. This provides a standardized and traceable data foundation for subsequent hybrid sharding and distributed computing.

[0047] As an optional embodiment of S2, as shown in S21~S34.

[0048] S21. Based on the multi-version rule base, load at least two versions of the pricing rules associated with the current repricing event, and construct a rule index for each rule version that includes the rule version number and the rule hit conditions.

[0049] Understandably, in S21, based on a multi-version rule library storing historically effective and currently pending pricing rules, at least two versions of pricing rules associated with the current repricing event are loaded (e.g., old rule V1.0: intra-family calls 0.08 yuan / minute, new rule V2.0: intra-family calls free). For each rule version, a rule index is built containing the rule version number (e.g., V1.0, V2.0) and the rule hitting conditions (e.g., "family shared package user + occurred after October 1, 2024 + call recipient is a family member"). By storing the core rule information in a structured and indexed manner, the full rule traversal retrieval during subsequent matching is avoided, significantly improving the basic efficiency of rule calling and matching.

[0050] S22. Extract the key feature fields of each call detail record in the set of call detail records to be traced back, match the key feature fields with the rule hit conditions in the rule index, and determine the initial target rule corresponding to the current call detail record.

[0051] Understandably, in S22, key feature fields of each call detail record (CDR) in the set of CDRs to be traced are extracted (including billing number 136XXXX9876, service type "voice call", call recipient 135XXXX4321, occurrence time "October 8, 2024", subscription package "family shared 5G package", and other core business information). These key feature fields are then compared precisely at the field level with the matching conditions in the rule index (such as verifying whether the user package type, call recipient affiliation, and occurrence time interval match). The initial target rule corresponding to each CDR is determined (such as the new CDR initial matching rule V2.0 mentioned above). Through precise mapping of the core dimensions of the business scenario, the initial adaptation between the rule and the CDR is achieved, ensuring that the candidate rule is highly consistent with the actual business scenario of the CDR.

[0052] S23. Based on the canary release strategy and traffic allocation algorithm, the initial target rule is verified and adjusted to determine the unique target pricing rule corresponding to each call detail record, and a rule version identifier is added to the target pricing rule.

[0053] Understandably, in S23, the initial target rule is dynamically verified and adjusted based on the canary release strategy and traffic allocation algorithm. The traffic allocation algorithm uses the formula: Traffic Allocation Weight = w1 × User Level + w2 × Region Priority (w1 and w2 are preset weight coefficients, such as w1=0.65, w2=0.35; user level is such as Platinum User Level 3, Regular User Level 1; region priority is such as prefecture-level city 0.7, township 0.4). If the calculated traffic allocation weight exceeds the canary release traffic threshold (e.g., 0.75), the initial target rule is switched to the new canary release rule version, while the performance of the new rule version is monitored in real time. The metrics (including rule hit rate, error rate, and response time, with preset thresholds of 97% for hit rate, 0.8% for error rate, and 40ms for response time) trigger a dynamic rollback mechanism for rule versions when any performance metric fails to meet the preset requirements (e.g., response time reaches 55ms). This mechanism adjusts the corresponding call detail record (CDR) pricing rules back to the initial target rules, ultimately assigning a unique target pricing rule to each CDR and adding a rule version identifier (e.g., V2.0+ rule ID: R_20241001). Gradual promotion of rule updates is achieved through quantitative weight allocation, combined with real-time performance closed-loop verification to ensure pricing stability and effectively avoid the risk of batch pricing errors.

[0054] S24. Integrate all call detail records (CDRs) carrying the rule version identifier to construct the set of CDRs to be processed.

[0055] Understandably, in S24, all call detail records (CDRs) carrying rule version identifiers are integrated in a unified data format to construct a set of CDRs to be processed with a standardized structure and clear rule associations. The version identifier enables precise binding of CDRs to pricing rules, providing clear and standardized data support for subsequent hybrid sharding based on rule version distribution, distributed computing node adaptation, and pricing result traceability.

[0056] Furthermore, to address the issues in existing technologies such as the lack of a gradient promotion mechanism for rule version switching, the high risk of batch pricing errors due to the absence of real-time performance verification, and the difficulty in guaranteeing the uniqueness of rule adaptation, Implementation S23 employs a closed-loop design that extracts business attribute information, calculates traffic allocation weights, gradient switches to new rules, monitors version performance, dynamically rolls back abnormal rules, and assigns unique version identifiers. With quantitative weight allocation and real-time performance verification as its core, it achieves secure and dynamic switching of batch pricing rules and unique adaptation of call detail records, ensuring the stability and traceability of the re-pricing process.

[0057] As an optional embodiment of S23, it is shown in steps S231 to S236.

[0058] S231. Extract service attribute information based on the key feature fields of the call detail record, wherein the service attribute information includes user level and region priority.

[0059] Understandably, in S231, business attribute information is extracted based on key feature fields of call detail records (such as subscription packages and location). Among them, user level refers to the classification of users based on their consumption amount and network duration (e.g., Diamond user level 3, Gold user level 2, and Ordinary user level 1), and regional priority refers to the quantitative coefficient set based on the regional economic level and business volume (e.g., provincial capital city 0.9, prefecture-level city 0.7, and township 0.4). By extracting these core attributes, a quantitative basis is provided for subsequent rule switching priority determination.

[0060] S232. Determine the traffic allocation weight of the current call detail record based on the service attribute information and the preset weight coefficient.

[0061] Understandably, in S232, based on the extracted business attribute information and preset weight coefficients (such as user level weight w1=0.6, regional priority weight w2=0.4), the current call detail record (CDR) traffic allocation weight is calculated using the formula traffic allocation weight = w1 × user level + w2 × regional priority (e.g., weight of diamond user + provincial capital city = 0.6 × 3 + 0.4 × 0.9 = 2.16). This quantitative calculation achieves priority ranking of CDRs to adapt to the new rules, avoiding indiscriminate switching.

[0062] S233. Switch the initial target rule of the call detail record (CDR) whose traffic allocation weight exceeds the gray-scale release traffic threshold to a new gray-scale release rule version.

[0063] Understandably, in S233, the calculated traffic allocation weight is compared with the preset gray-scale release traffic threshold. The initial target rule of the call detail record with the weight exceeding the threshold is switched to the new rule version of the gray-scale release (such as the new tariff discount rule V3.0). The risk of the new rule going live on all at once is reduced through the gradient promotion mode, and the rule is smoothly iterated.

[0064] S234. Determine the version performance metrics for the new rule version, including rule hit rate, error rate, and response time.

[0065] Understandably, in S234, the performance metrics of the new rule version are collected in real time. Among them, the rule hit rate refers to the proportion of new rules that successfully match call detail records, the error rate refers to the proportion of logical errors that occur during rule execution, and the response time refers to the time spent on rule matching and calculation (such as preset hit rate threshold of 98%, error rate threshold of 0.5%, and response time threshold of 30ms). Through multi-dimensional performance monitoring, a quality verification standard for rule effectiveness is established.

[0066] S235. When the hit rate in the performance indicators is lower than the preset hit rate threshold, or the error rate exceeds the preset error threshold, or the response time exceeds the preset latency threshold, the rule version is dynamically rolled back, and the corresponding call detail record pricing rule is adjusted back to the initial target rule.

[0067] Understandably, in S235, if any performance indicator is detected to be not in line with the preset requirements (such as an error rate of 1.2%), the rule version dynamic rollback mechanism will be triggered immediately to adjust the corresponding call detail record pricing rule back to the initial target rule (such as the old rule V2.0). This closed-loop error correction will prevent the spread of batch pricing errors and ensure the accuracy of the re-pricing results.

[0068] S236. Based on the final rule version determination result, assign a unique target pricing rule and its corresponding rule version identifier to the call detail record.

[0069] Understandably, in S236, the final rule version determines the result (new rule or old rule after rollback), and each call detail record (CDR) is assigned a unique target pricing rule and its rule version identifier (e.g., V3.0+ rule ID: R_20241101). The unique identifier enables precise binding between the CDR and the pricing rule, providing a clear basis for subsequent pricing result tracing and problem investigation.

[0070] S3. The call detail records (CDRs) set to be processed are dynamically fragmented using a hybrid fragmentation strategy to obtain fragmented CDR sets. A corresponding distributed computing node is matched for each fragmented CDR set using an elastic resource scheduling strategy.

[0071] Understandably, to address the issues of fixed and rigid sharding strategies in existing technologies, which cannot adapt to the dynamic fluctuations of distributed computing cluster resources and fail to consider business characteristics, leading to mismatches between sharding and node resources and business requirements, and consequently causing subsequent processing load imbalances and low efficiency, this embodiment adopts a design that combines real-time cluster resource perception, quantitative calculation of optimal shard size, and dynamic sharding based on business characteristics. With resource perception and genetic algorithm optimization as its core, it achieves precise matching between shard size and cluster resource capabilities and call detail record (CDR) service distribution, laying a solid foundation for subsequent elastic resource scheduling and efficient distributed processing.

[0072] As an optional embodiment of S3, the steps S311~S313 are shown in which the call detail records set to be processed is dynamically fragmented using a hybrid fragmentation strategy to obtain a fragmented call detail records set.

[0073] S311. Obtain resource status information of the distributed computing cluster in real time. The resource status information includes at least the number of available distributed computing nodes, the memory capacity of each distributed computing node, and the current load.

[0074] Understandably, in S311, the resource status information of the distributed computing cluster is obtained in real time. The number of available distributed computing nodes refers to the total number of nodes that are currently idle or under low load and can undertake sharding tasks. The memory capacity of each distributed computing node refers to the upper limit of physical memory that the node can use for call detail record storage and processing (e.g., a node has a memory capacity of 128GB). The current load refers to the current CPU utilization, memory utilization, and other resource usage of the node (e.g., a node currently has a CPU utilization of 28% and a memory utilization of 32%). By collecting these dynamic resource data in real time, the real-time resource capabilities of the cluster can be accurately controlled, providing a real and reliable basis for the subsequent calculation of the optimal shard size.

[0075] S312. Determine the optimal shard size based on the average available memory of distributed computing nodes, the load balancing factor, and the memory overhead of a single call detail record. The load balancing factor is a value obtained by dynamically optimizing the execution efficiency of historical tasks using a genetic algorithm.

[0076] Understandably, in S312, based on the average available memory of distributed computing nodes (i.e., the average of all available memory allocated to all available nodes), the load balancing factor (a dynamic adjustment coefficient obtained by iteratively optimizing historical re-pricing task execution efficiency, node load distribution, task completion latency, etc., based on a genetic algorithm, used to balance node load balancing and overall processing efficiency), and the memory overhead of a single call detail record (the amount of memory required for storage, parsing, and preliminary processing of a single call detail record, e.g., 3KB / record), the optimal shard size is calculated using the formula: Optimal shard size = Average available memory of distributed computing nodes × Load balancing factor / Memory overhead of a single call detail record. The optimal shard size is then calculated (e.g., (85GB × 0.78) / 3KB ≈ 22,550,000 records / shard). This step, through multi-dimensional quantitative modeling and load balancing factor optimized by a genetic algorithm, breaks through the limitations of traditional fixed sharding, achieving dynamic adaptation of shard size to the real-time resource capabilities of the cluster. This avoids both excessively large shards causing node memory overflow and excessively small shards causing resource idleness.

[0077] S313. Based on the optimal segment size and the rule version identifier distribution of the call detail records to be processed, the call detail records to be processed are dynamically segmented to generate multiple segmented call detail records.

[0078] Understandably, in S313, based on the calculated optimal fragment size and combined with the rule version identifier distribution of the call detail records (CDRs) to be processed (e.g., CDRs with rule version V1.0 account for 60%, V2.0 for 30%, and V3.0 for 10%), all CDRs to be processed with rule version identifiers are dynamically fragmented. CDRs with the same rule version are concentrated in the same or adjacent fragments as much as possible (e.g., each fragment contains approximately 22 million CDRs, and the proportion of CDRs with a single rule version in a single fragment is not less than 75%), generating multiple structurally well-structured fragmented CDR sets. By combining the fragmentation strategy with the core business characteristics (rule version distribution), the frequency of subsequent distributed computing nodes loading and switching different version pricing rules is reduced, the node computing overhead and rule adaptation time are reduced, and the continuity and efficiency of fragmentation processing are improved.

[0079] As an optional embodiment of S3, to address the problem that existing technology resource scheduling relies solely on a single performance indicator and fails to consider the differentiated needs of fragmented call sets, resulting in low compatibility between fragments and distributed computing nodes, unbalanced node load, and insufficient resource utilization, embodiment S3 uses an elastic resource scheduling strategy to match each fragmented call set with a corresponding distributed computing node. Specifically, through real-time collection of node performance indicators, dimensional quantification of computing resource matching degree, and association design based on matching degree priority allocation, the core is to achieve optimal scheduling of computing resources with precise matching of fragmentation characteristics and node capabilities, ensuring efficient and stable distributed processing. The specific implementation steps are shown in S311~S313.

[0080] S321. Obtain the computing performance indicators of each available distributed computing node in the distributed computing cluster in real time. The performance indicators include CPU utilization, memory utilization, and task queue length.

[0081] Understandably, in S321, the computing performance metrics of each available node in the distributed computing cluster are obtained in real time. Among them, CPU utilization refers to the proportion of CPU resources currently occupied by the node, memory utilization refers to the proportion of memory used by the node to the total available memory, and task queue length refers to the number of tasks currently waiting to be executed by the node. By collecting these dynamic performance data in real time, the real-time carrying capacity of each node can be accurately grasped, providing an objective and real-time basis for subsequent matching degree calculation.

[0082] S322. Determine the resource matching degree between each available distributed computing node and each segmented call set based on the data volume, rule version complexity, and computing performance indicators of each segmented call set.

[0083] Understandably, in S322, based on the differentiated characteristics of each segment's call detail record (CDR) set (data volume refers to the total number of CDRs contained in the segment, e.g., segment 1 contains 22 million CDRs, segment 2 contains 18 million CDRs; rule version complexity refers to the computational logic complexity of the pricing rules associated with the segment, quantified by a complexity coefficient, e.g., the complexity coefficient of the segment associated with the V3.0 multi-level discount rule is 1.7, and the complexity coefficient of the segment associated with the V1.0 basic rule is 0.9), combined with the computational performance indicators obtained from S321, the weighted formula is used: Resource matching degree = h1 × ( The resource matching degree is calculated using the formula: h1×(1-CPU utilization) + h2×(1-memory utilization) + h3×(1-task queue length / maximum queue length) + h4×(1-shard data volume / maximum node processing capacity) + h5×(1-rule complexity coefficient / maximum complexity coefficient). (W1-w5 are preset weight coefficients, with a total of 1, such as h1=0.3, h2=0.3, h3=0.1, h4=0.2, h5=0.1). Through multi-dimensional quantitative modeling, the limitations of single-indicator scheduling are overcome, and the precise matching between sharding requirements and node capabilities is achieved.

[0084] S323. Sort the fragmented segments in descending order according to the resource matching degree, and preferentially allocate them to the distributed computing node with the highest resource matching degree.

[0085] Understandably, in S323, the resource matching degree between each available node and the sharded session set is sorted in descending order (e.g., node A matches shard 1 with a matching degree of 0.4255, node B matches shard 1 with a matching degree of 0.382, and node C matches shard 1 with a matching degree of 0.315). The sharded session set is preferentially allocated to the distributed computing node with the highest matching degree (e.g., shard 1 is allocated to node A). Through the priority allocation strategy, it is ensured that high-demand shards are accurately matched with the nodes with the strongest adaptability, thereby achieving overall cluster load balancing, avoiding the situation where some nodes are overloaded and some nodes are idle, and significantly improving the utilization rate of computing resources and the efficiency of sharding processing.

[0086] As an optional embodiment of S3, in order to solve the problem that after the initial resource allocation, the distributed computing nodes may experience excessive load or delayed task progress due to load fluctuations or sudden task overlaps, which may affect the overall re-batch processing efficiency and stability, the step of matching the corresponding distributed computing node for each segmented session with an elastic resource scheduling strategy also includes steps as shown in S324~S325.

[0087] S324. During the execution of the matching task, continuously monitor the actual load and task execution progress of each distributed computing node.

[0088] It is understood that in S324 of this embodiment, during the task execution of the fragmented call detail records (CDRs) allocated to the distributed computing nodes, the actual load and task execution progress data of each node are continuously collected. The actual load refers to the real-time resource usage of the node (including CPU utilization, memory usage, etc.), the set time domain refers to the preset continuous monitoring duration (e.g., 10 minutes, to avoid misjudgment due to instantaneous fluctuations), and the task execution progress refers to the proportion of the number of CDRs re-pricing completed by the node to the total number of CDRs allocated to the node (e.g., node D is allocated 22 million CDRs, and 8.8 million have been completed, with a progress of 40%). Through real-time and continuous status monitoring, abnormal node operation can be captured in a timely manner, providing accurate data support for subsequent adjustment decisions.

[0089] S325. If it is detected that the actual load of any distributed computing node continuously exceeds the preset load threshold or the task execution progress lags behind the preset plan value within a set time domain, then the unfinished part or all of the fragments on the current distributed computing node will be migrated to the distributed computing node with the second highest resource matching degree.

[0090] Understandably, in S325, the preset load threshold is the maximum resource utilization ratio that a node can withstand for stable operation, and the preset plan value is a phased progress target set based on the total number of tasks and time limits. If it is detected that the actual load of any node continuously exceeds the preset threshold (CPU utilization ≥ 85% for 10 consecutive minutes) within a set time range (e.g., 10 minutes), or the task execution progress (e.g., 40%) lags behind the preset plan value (e.g., 50%), then the sharding migration mechanism is activated. The unfinished part or all of the shards on the node are migrated to the distributed computing node with the second highest resource matching degree (e.g., node E, which is second only to node D in the previous matching ranking). Through dynamic migration, the load pressure is distributed to avoid abnormal nodes from crashing due to overload, while ensuring that tasks proceed as planned and maintaining the overall processing efficiency and stability of the cluster.

[0091] S4. Based on the distributed computing nodes, the call detail record (CDR) re-pricing is performed on each segment of the CDR set according to the preset backtracking mechanism to obtain the preliminary re-pricing.

[0092] Understandably, to address the problem that existing backtracking mechanisms are singular and rigid, failing to adapt to differentiated processing needs based on segmented call detail records (CDRs), leading to redundancy in full backtracking or omissions in incremental backtracking, thus affecting the efficiency and accuracy of repricing, as an optional implementation, Implementation S4, through an associated design that identifies and adapts backtracking mechanism types, accurately loads rules and parameters, differentiates and filters CDRs to be repriced, and recalculates parameters according to regulations, focuses on mechanism adaptation and accurate calculation to achieve efficient adaptation and accurate result generation for segmented CDR repricing, ensuring the relevance and reliability of the repricing process; specific implementation steps S41~S44 are shown.

[0093] S41. Identify the type of backtracking mechanism applicable to the fragmented single set on each distributed computing node, wherein the backtracking mechanism type includes a full backtracking mechanism or an incremental backtracking mechanism.

[0094] Understandably, in S41, the appropriate backtracking mechanism type for each distributed computing node's segmented call detail records (CDRs) is identified. The full backtracking mechanism refers to a processing mode that recalculates all CDRs related to a user within a single billing cycle (e.g., a change in a user's overall package requires recalculating all data call detail records for the current month). The incremental backtracking mechanism refers to a processing mode that recalculates only the relevant CDRs within the effective time window of the rule change (e.g., adjustments to tariff discount rules only require calculating the voice call detail records generated after the adjustment). By identifying and adapting the mechanism type as needed, processing redundancy or data omissions caused by a single backtracking mode are avoided, laying the foundation for accurate processing in the future.

[0095] S42. Load the corresponding target pricing rule and its key billing parameters from the local rule base or the central rule base according to the backtracking mechanism type and the rule version identifier in the segmented call detail record set; wherein, the key billing parameters include key billing parameters, free resource consumption and cumulative resource usage.

[0096] Understandably, in S42, based on the identified backtracking mechanism type and the rule version identifier of the segmented call detail record (e.g., V2.0+ rule ID: R_20241001), the corresponding target batch pricing rule and its key billing parameters are loaded from the local rule base (which stores frequently used rules) of the distributed computing node or the central rule base (which stores all rules) of the cluster. The key billing parameters include the billing unit price (e.g., 0.19 yuan / MB), the amount of free resources consumed (e.g., 10GB of free traffic used in the current month) and the cumulative amount of resources used (e.g., 15GB of cumulative traffic used in the current month). Through the on-demand loading strategy of the local and central rule bases, the rule loading speed and storage resource consumption are balanced to ensure that the key parameters are accurately obtained.

[0097] It should be noted that the multi-version rule base serves as the core data source for all rules. It maintains data consistency with the central rule base of the distributed cluster through a real-time synchronization link. The central rule base then pushes rules to the local rule bases of each distributed computing node on demand through the high-speed network within the cluster and supports caching. The three form a hierarchical physical relationship of "core storage - cluster distribution - local caching".

[0098] S43. If it is a full rollback mechanism, then all historical call records of the user identifier involved in the segmented call record set within a single billing cycle are extracted as call records to be repriced; if it is an incremental rollback mechanism, then based on the effective time window of the rule change, the call records in the segmented call record set that belong to the effective time window are selected as call records to be repriced.

[0099] Understandably, in S43, if the full rollback mechanism is determined, all historical call records (including data, voice, SMS, and other types of call records) of the user identifier (such as mobile number 136XXXX9876) involved in the call record segment (such as October 1, 2024 - October 31, 2024) are extracted as call records to be re-priced, ensuring that all relevant call records are uniformly accounted for within the billing period. If the incremental rollback mechanism is determined, based on the effective time window of the rule change (such as October 15, 2024 - October 31, 2024), call records in the call record segment that belong to the time window are selected as call records to be re-priced, avoiding irrelevant historical call records from occupying processing resources. A balance between processing efficiency and data integrity is achieved through differentiated screening.

[0100] S44. Based on the target pricing rules, recalculate the key billing parameters corresponding to the call detail records to be repriced to generate the preliminary repricing price for each call detail record to be repriced.

[0101] Understandably, in S44, based on the loaded target pricing rules and combined with the business scenario of the call details to be repriced, the key billing parameters corresponding to each call detail are recalculated to generate the preliminary repricing price for each call detail to be repriced. Through precise matching and calculation of rules and parameters, the accuracy of the preliminary repricing result is ensured, providing a reliable foundation for subsequent differential review.

[0102] S5. Determine the degree of difference between the preliminary re-approval price and the historical price through the differential review mechanism, and determine the target re-approval price or early warning information for the corresponding segmented episode based on the degree of difference.

[0103] Understandably, to address the issues of existing technologies lacking a precise full-process verification mechanism for repricing results, resulting in delayed error detection and difficulty in traceability, which leads to batch errors impacting user experience and operator revenue, this embodiment employs a parallel comparison calculation of differences, confirmation of valid repricing, and triggering of anomaly warnings. With parallel verification and threshold determination as its core, it achieves real-time risk control and accurate output of repricing results, ensuring the reliability and traceability of repricing results. The specific steps are shown in S51~S53.

[0104] S51. Parallel acquisition and comparison of the preliminary re-rate and the original historical rate for each segment of call detail records, and calculation of the difference value of at least one key billing parameter; compare the difference value with a preset difference threshold.

[0105] Understandably, in S51, a distributed parallel processing architecture is used to synchronously obtain the preliminary re-pricing and the original historical pricing for each segment of call detail records (CDRs). For each CDR, at least one key billing parameter (including billing amount, free resource consumption, cumulative resource usage, etc., for example, selecting the billing amount as the core verification parameter) is precisely compared. This is done using the absolute difference formula: Absolute difference value = |Preliminary re-pricing key parameter value - Original historical pricing key parameter value|, or the relative difference formula: Relative difference value = |Preliminary re-pricing key parameter value - Original historical pricing key parameter value| / Original historical pricing key parameter value. The calculated difference value is then compared with a preset difference threshold. Parallel processing improves comparison efficiency, and by using quantitative difference calculation and threshold determination, accurate verification of the re-pricing results is achieved.

[0106] S52. If none of the difference values ​​exceed the corresponding difference threshold, the corresponding preliminary re-approval price is determined as the final target re-approval price of the current call detail record to be re-approved.

[0107] Understandably, in S52, if the difference values ​​of all key billing parameters do not exceed the corresponding preset thresholds (e.g., the difference value of a certain call detail record billing amount is 1.2 yuan < absolute threshold 2 yuan, and the relative difference value is 2.1% < relative threshold 5%), then the preliminary re-pricing is directly determined as the final target re-pricing price of the current call detail record to be re-priced. By directly confirming the valid result, redundant review processes are avoided, and the overall processing efficiency of re-pricing is improved.

[0108] S53. If any of the aforementioned difference values ​​exceeds the corresponding difference threshold, an early warning message will be triggered and the corresponding call detail record (CDR) identifier, difference item, and difference value will be recorded in the anomaly list.

[0109] Understandably, in S53, if the difference in any key billing parameter exceeds the corresponding preset threshold (e.g., a difference of 3 yuan in billing amount for a call detail record (CDR) > the absolute threshold of 2 yuan, or a relative difference of 6.45% > the relative threshold of 5%), an early warning message will be immediately triggered (e.g., a system pop-up notification or a background log alarm). The corresponding CDR identifier (e.g., CDR ID: Bill_20241015_136XXXX9876), the difference item (e.g., "billing amount"), and the difference value (e.g., 4 yuan, 6.45%) will be recorded in detail in the anomaly list. Through timely early warning and full-dimensional anomaly recording, errors can be accurately captured and traced, providing a clear basis for subsequent problem investigation and correction, and preventing the spread of erroneous results.

[0110] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0111] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0112] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0113] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0114] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0115] The specific embodiments described above are preferred embodiments of the retrospective call detail record repricing method based on hybrid fragmentation and distributed computing of the present invention, and are not intended to limit the specific scope of the present invention. The scope of the present invention includes but is not limited to the specific embodiments described above. All equivalent changes made in accordance with the shape and structure of the present invention are within the protection scope of the present invention.

Claims

1. A method for re-pricing retrospective call detail records based on hybrid fragmentation and distributed computation, characterized by: Includes the following steps: The impact range of the re-pricing is assessed by a spatiotemporal impact domain prediction algorithm, and the set of call records to be traced is obtained from the billing call record database based on the impact range. Load multiple versions of pricing rules, and match the target pricing rule for each call detail record in the set of call detail records to be traced back by using preset rule hit conditions to construct a set of call detail records to be processed with rule version identifiers; A hybrid fragmentation strategy is used to dynamically fragment the call detail records (CDRs) set to be processed to obtain fragmented CDR sets. A flexible resource scheduling strategy is used to match a corresponding distributed computing node for each fragmented CDR set. Based on the distributed computing nodes and according to the preset backtracking mechanism, the call detail record (CDR) re-pricing is performed on each segment of CDR sets to obtain the preliminary re-pricing. The differential review mechanism determines the degree of difference between the initial re-approval price and the historical price, and determines the target re-approval price or early warning information for the corresponding segmented episode based on the degree of difference.

2. The method for re-pricing of retrospective call detail records based on hybrid fragmentation and distributed computation as described in claim 1, characterized in that: The steps for evaluating the impact range of re-pricing through a spatiotemporal impact domain prediction algorithm, and then selecting the set of call detail records to be retrospectively analyzed from the billing call detail record database based on the impact range, are as follows: In response to the repricing event, the instruction retrieves the associated tariff rule change identifier, business impact time window, and business type identifier. Based on the tariff rule change identifier, the corresponding rule impact indicator is obtained from the multi-version rule base; according to the service impact time window, the total historical call records of the service type identifier are matched from the billing call record base; based on the total historical call records and the rule impact indicator, the predicted value of the spatiotemporal impact domain is determined; The impact range when the predicted value of the spatiotemporal impact domain exceeds a preset threshold is determined based on the rule-based impact indicators. Extract call detail records (CDRs) from the billing CDR database that belong to the scope of the impact and construct a set of CDRs to be traced back. The rules affect metrics including billing user coverage, call detail record (CDR) service type weight, and time window matching rate.

3. The method for re-pricing of retrospective call detail records based on hybrid fragmentation and distributed computation as described in claim 2, characterized in that: The steps for determining the influence range when the predicted value of the spatiotemporal influence domain exceeds a preset threshold based on the rule-based influence index are as follows: Based on the billing user coverage rate, and combined with the association between user identifiers and service type identifiers, a list of affected users is determined; Based on the weight of the call detail record service type, and combined with the service classification mapping relationship defined in the rule hit condition field, a call detail record service classification list is determined. Based on the time window matching rate, and combined with the business impact time window, the effective re-pricing time interval is determined to generate a time window list; The scope of influence is formed by associating and integrating the list of affected users, the list of call detail records (CDRs) for different service categories, and the list of time windows.

4. The method for re-pricing of retrospective call detail records based on hybrid fragmentation and distributed computation as described in claim 1, characterized in that: The steps for matching target pricing rules to each call detail record (CDR) in the set to be traced back using preset rule matching conditions to construct a set of CDRs to be processed with rule version identifiers are as follows: Based on the multi-version rule base, load at least two versions of the pricing rules associated with the current repricing event, and construct a rule index for each rule version that includes the rule version number and the rule hit conditions; Extract the key feature fields of each call detail record (CDR) in the set of CDRs to be traced back, match the key feature fields with the rule hit conditions in the rule index, and determine the initial target rule corresponding to the current CDR. The initial target rules are verified and adjusted based on the canary release strategy and traffic allocation algorithm to determine the unique target pricing rule corresponding to each call detail record and add a rule version identifier to the target pricing rule. All call detail records (CDRs) carrying the aforementioned rule version identifier are integrated to construct the set of CDRs to be processed.

5. The method for re-pricing of retrospective call detail records based on hybrid fragmentation and distributed computation as described in claim 4, characterized in that: The steps for verifying and adjusting the initial target rules based on the canary release strategy and traffic allocation algorithm to determine the unique target pricing rule corresponding to each call detail record are as follows: Based on the key feature fields of the call detail record, business attribute information is extracted, including user level and region priority. The traffic allocation weight of the current call detail record is determined based on the business attribute information and the preset weight coefficient. The initial target rule for the call detail record (CDR) whose traffic allocation weight exceeds the gray-scale release traffic threshold will be switched to a new gray-scale release rule version. Determine the version performance metrics for the new rule version, including rule hit rate, error rate, and response time; When the hit rate in the performance metrics is lower than the preset hit rate threshold, the error rate exceeds the preset error threshold, or the response time exceeds the preset latency threshold, the rule version is dynamically rolled back, and the corresponding call detail record pricing rule is adjusted back to the initial target rule. Based on the final rule version determination result, a unique target pricing rule and its corresponding rule version identifier are assigned to each call detail record (CDR).

6. The method for re-pricing of retrospective call detail records based on hybrid fragmentation and distributed computation as described in claim 1, characterized in that: The steps for dynamically fragmenting the call detail records (CDRs) set to be processed using a hybrid fragmentation strategy to obtain fragmented CDR sets are as follows: The resource status information of the distributed computing cluster is obtained in real time. The resource status information includes at least the number of available distributed computing nodes, the memory capacity of each distributed computing node, and the current load. The optimal shard size is determined based on the average available memory of distributed computing nodes, the load balancing factor, and the memory overhead of a single call detail record. The load balancing factor is a value obtained by dynamically optimizing the execution efficiency of historical tasks using a genetic algorithm. Based on the optimal segment size and the rule version identifier distribution of the call detail records (CDRs) set to be processed, the CDR set to be processed is dynamically segmented to generate multiple segmented CDR sets.

7. The method for re-pricing of retrospective call detail records based on hybrid fragmentation and distributed computation as described in claim 1 or 6, characterized in that: The steps for matching each segmented call set with a corresponding distributed computing node using an elastic resource scheduling strategy are as follows: The computing performance metrics of each available distributed computing node in the distributed computing cluster are obtained in real time, including CPU utilization, memory utilization and task queue length. The resource matching degree between each available distributed computing node and each segmented call case is determined based on the data volume of each segmented call case set, the complexity of the rule version, and the computing performance indicators. Based on the resource matching degree, the fragmented segments are sorted in descending order, and the fragmented segments are preferentially allocated to the distributed computing nodes with the highest resource matching degree.

8. The method for re-pricing of retrospective call detail records based on hybrid fragmentation and distributed computation as described in claim 7, characterized in that: The step of matching each fragmented call set with a corresponding distributed computing node through an elastic resource scheduling strategy also includes the following steps: During the execution of the matching task, the actual load and task execution progress of each distributed computing node are continuously monitored; If the actual load of any distributed computing node is detected to continuously exceed the preset load threshold or the task execution progress lags behind the preset plan value within a set time domain, then the unfinished part or all of the fragments on the current distributed computing node will be migrated to the distributed computing node with the second highest resource matching degree.

9. The method for re-pricing of retrospective call detail records based on hybrid fragmentation and distributed computation as described in claim 1, characterized in that: The steps for obtaining preliminary repricing rates by performing call detail record (CDR) repricing on each CDR segment based on a preset backtracking mechanism using distributed computing nodes are as follows: Identify the type of backtracking mechanism applicable to the fragmented single set on each distributed computing node, wherein the backtracking mechanism type includes a full backtracking mechanism or an incremental backtracking mechanism; Based on the type of the backtracking mechanism and the rule version identifier in the segmented call detail records, the corresponding target pricing rule and its key billing parameters are loaded from the local rule base or the central rule base. If it is a full rollback mechanism, then all historical call records of the user identifier involved in the segmented call record set within a single billing cycle are extracted as call records to be re-priced. If it is an incremental backtracking mechanism, then based on the effective time window of the rule change, the call records in the segmented call records set that belong to the effective time window are selected as call records to be re-priced. Based on the target pricing rules, the key billing parameters corresponding to the call detail records to be repriced are recalculated to generate the initial repricing price for each call detail record to be repriced. The key billing parameters include key billing parameters, free resource consumption, and cumulative resource usage.

10. The method for re-pricing of retrospective call detail records based on hybrid fragmentation and distributed computation as described in claim 9, characterized in that: The steps for determining the degree of difference between the preliminary re-approval price and the historical re-approval price through a differential review mechanism, and determining the target re-approval price or early warning information for the corresponding segmented episode based on the degree of difference, are as follows: The system acquires and compares the preliminary re-billing price with the original historical billing price for each segment of call detail records in parallel, and calculates the difference value of at least one key billing parameter; then compares the difference value with a preset difference threshold. If none of the aforementioned differences exceed the corresponding difference threshold, the corresponding preliminary re-approval price will be determined as the final target re-approval price for the current call detail record to be re-approved. If any of the aforementioned differences exceeds the corresponding difference threshold, an early warning message will be triggered, and the corresponding call detail record (CDR) identifier, difference item, and difference value will be recorded in the anomaly list.

Images