Order and income double-dimension multi-level real-time statistical method and system

Abstract

The application belongs to the technical field of real-time statistics, and discloses a kind of order and income double-dimension multi-level real-time statistics method and system, comprising: incremental statistics writing is carried out to business event data, and real-time incremental statistics event stream is obtained;Multi-level aggregation statistics result set is obtained by memory real-time statistics;Idempotent persistent writing is carried out to multi-level aggregation statistics result set, and multi-level persistent statistics data set is obtained, and is folded and mapped to relational data table, to generate uniform dimension folding storage table;Hierarchical consistency data source summary is carried out to uniform dimension folding storage table, to obtain multi-source statistics data set, and cross-pipe correlation calculation is carried out, to obtain cross-dimension correlation statistics result;According to external entity type parameter, dynamic condition splicing query is carried out to cross-dimension correlation statistics result, and query result is carried out to anomaly detection, to obtain double-dimension multi-level real-time statistics result.The application can realize high real-time, low cost, high robustness multi-dimension operation statistics.

Description

Technical Field

[0001] This invention relates to the field of real-time statistical technology, and in particular to a method and system for real-time statistical analysis of orders and revenue across multiple levels. Background Technology

[0002] With the large-scale deployment of smart logistics last-mile infrastructure, such as food delivery lockers, restaurant lockers, and community storage lockers, operation and management have become increasingly complex, exhibiting multi-level characteristics: platform, province / region, company, and merchant; multi-dimensional characteristics: orders and revenue; and multi-granular characteristics: global summary, device details, and real-time ranking. Operators need to monitor order volume, revenue, and ranking changes at each level in real time to support refined operational decisions. However, existing technological solutions have the following significant shortcomings when dealing with thousands of merchants and tens of thousands of devices: 1. Severe statistical latency, failing to meet real-time decision-making requirements: Traditional solutions typically employ scheduled full scans of business tables for statistical aggregation. In scenarios with massive order volumes, the time complexity of a full table scan is... Furthermore, as the amount of data increases, the time taken for a single statistical analysis expands from seconds to minutes. More seriously, due to the fixed interval of scheduled tasks, which is usually 5-30 minutes, there is a blind spot in the statistical data. Operations personnel always see outdated data from several minutes ago, making it impossible to respond promptly to sudden traffic surges or abnormal fluctuations.

[0003] 2. Multi-level independent table creation causes storage and maintenance costs to increase linearly with each level: Existing systems typically create independent statistical tables and aggregation tasks for each operational level—platform, province / region, company, and merchant. Assuming the system contains P provinces / regions, C companies, and T merchants, then at least [number missing] tables need to be maintained. A set of statistical tables and corresponding scheduled tasks are required. Each new operational level or statistical indicator necessitates changes to the table structure, addition of aggregation logic, and adjustments to scheduled tasks, resulting in increased development and maintenance costs. The growth is represented by N, where N is the number of levels and M is the number of indicators. Calculations show that in a typical scenario involving 500 merchants, 50 companies, and 30 provinces, the traditional solution requires maintaining approximately 580 statistical tables, resulting in over 99% storage redundancy.

[0004] 3. Order and revenue statistics are fragmented and lack a unified framework: In the existing system, order statistics, such as delivery orders, shipping orders, and locker orders, and revenue statistics, such as locker fees, overdue fees, and refunds, are usually implemented independently by different modules, with incompatible data structures, aggregation logic, and query interfaces. This not only leads to code duplication and maintenance difficulties, but also makes cross-dimensional correlation analysis, such as anomaly detection like an increase in a merchant's order volume but a decrease in revenue, require additional data correlation calculations, further increasing the system burden.

[0005] 4. High risk of fault propagation due to the coupling of statistics and business processes: In traditional solutions, statistical calculations are usually embedded within business processes and executed synchronously. For example, data is written to the statistics table immediately after an order is created. If the statistical write fails due to lock contention or connection pool exhaustion, it may trigger a business transaction rollback, causing serious consequences such as statistical failures affecting core business operations. In addition, synchronous writes increase the response latency of business interfaces and degrade the user experience.

[0006] 5. Excessive Database Pressure and Poor System Scalability: Traditional solutions directly apply high-frequency statistical calculations to relational databases. Under the triple pressure of high-concurrency writes (e.g., real-time order or payment events), high-concurrency reads (e.g., frequent dashboard refreshes by operations staff), and scheduled full scans (e.g., statistical tasks scanning the entire table), the database is prone to lock contention and connection pool exhaustion, creating performance bottlenecks. Especially during peak business periods, such as the lunch rush from 11:00 AM to 1:00 PM, order writes, statistical aggregation, and dashboard queries simultaneously compete for database resources, causing a surge in business interface response latency, which can even affect the user's order placement experience. To alleviate the pressure, expensive hardware upgrades are often required, such as adding read-only replicas or upgrading instance specifications, violating the principle of low-cost operation. Furthermore, in a multi-tenant independent database architecture, each merchant's statistical tasks need to connect to their respective tenant database to perform aggregation calculations. 500 merchants mean 500 database connections under concurrent pressure, further exacerbating resource consumption.

[0007] 6. Disconnected Global Summary and Device Details Data, Inability to Collaborate with Multiple Data Sources: Existing systems typically treat the overall operational dashboard and individual device statistical analysis as two independent systems. Device-level daily statistics, such as turnover rate, midday peak orders, and order distribution across different statuses, are stored in a tenant's independent database, while global operational data, such as total platform orders and revenue rankings, are stored in a platform-wide database. When operations personnel need to query device details from the overall dashboard or aggregate device turnover rates to company or provincial efficiency metrics, the system requires cross-database queries or even manual export and merging. This disconnected dashboard and device details architecture leads to inconsistent data definitions and broken drill-down links.

[0008] 7. Missing Real-Time Rankings and Inability to Integrate Historical and Real-Time Rankings: In traditional solutions, ranking data, such as Top 10 merchants and revenue rankings, is usually generated based on offline batch calculations, resulting in poor timeliness. Real-time ranking data is scattered in memory, while historical ranking data is stored in a relational database. The two cannot be integrated and displayed in the same query, causing the rankings seen by operations personnel to always be outdated.

[0009] In summary, existing technologies can no longer meet the stringent requirements of modern smart terminal operations for millisecond-level real-time performance, multi-level coverage, dual-dimensional unification, multi-granularity collaboration, and business decoupling. Therefore, there is an urgent need to design an innovative statistical method based on event-driven, in-memory computing, and multi-data source collaboration to fundamentally resolve the contradiction between the real-time nature of operational data and system costs.

[0010] Therefore, how to provide a real-time statistical method and system for both order and revenue at multiple levels is an urgent problem to be solved. Summary of the Invention

[0011] This invention provides a method and system for real-time statistics of orders and revenue across multiple levels, addressing the aforementioned technical problems in the prior art.

[0012] According to a first aspect of the present invention, a multi-level real-time statistical method for two dimensions of orders and revenue is provided.

[0013] In one embodiment, the multi-level real-time statistical method for both orders and revenue includes: For the business event data generated by the operation of the received smart terminal, an incremental statistical write is performed to the memory database using a bypass asynchronous write mode to obtain a real-time incremental statistical event stream. Real-time in-memory statistics are performed on real-time incremental statistical event streams based on multiple types of collaborative data structures to obtain multi-level aggregated statistical result sets. According to the preset timed data storage rules, the multi-level aggregated statistical result set is written idempotently to obtain the multi-level persistent statistical data set. Then, combined with the dimension placeholder identification mechanism, the multi-level persistent statistical data set is folded and mapped to the relational data table to generate a unified dimension folded storage table. Based on a multi-layer data source collaboration strategy, a hierarchical consistency data source aggregation is performed on the unified dimension folded storage table to obtain a multi-source statistical data set. Cross-pipeline association calculations are then performed on the multi-source statistical data set to obtain cross-dimensional association statistical results. Based on the external entity type parameter in the external query request, dynamic condition concatenation query is performed on the cross-dimensional correlation statistical results, and anomaly detection is performed on the query results in combination with historical baseline data to obtain real-time statistical results of two dimensions and multiple levels.

[0014] According to a second aspect of the present invention, a multi-level real-time statistical system for both order and revenue dimensions is provided.

[0015] In one embodiment, the order and revenue dual-dimensional multi-level real-time statistics system includes: The incremental statistics module is used to incrementally write the received business event data generated by the operation of smart terminals to the memory database in a bypass asynchronous write mode to obtain a real-time incremental statistics event stream. The multi-level aggregation module is used to perform real-time in-memory statistics on real-time incremental statistical event streams based on multiple types of collaborative data structures, and obtain a multi-level aggregated statistical result set. The folding mapping module is used to perform idempotent persistent writing of multi-level aggregated statistical result sets according to preset timed data storage rules, obtain multi-level persistent statistical data sets, and combine the dimension placeholder identification mechanism to fold and map the multi-level persistent statistical data sets to relational data tables, generating a unified dimension folding storage table. The cross-pipeline association module is used to perform hierarchical consistency data aggregation on a unified dimension folded storage table based on a multi-layer data source collaboration strategy, to obtain a multi-source statistical data set, and to perform cross-pipeline association calculations on the multi-source statistical data set to obtain cross-dimensional association statistical results. The dynamic condition concatenation query module is used to perform dynamic condition concatenation queries on cross-dimensional correlation statistical results based on the external entity type parameters in the external query request, and to perform anomaly detection on the query results in combination with historical baseline data, so as to obtain real-time statistical results with two dimensions and multiple levels.

[0016] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects: 1. This invention abandons the traditional full-scale timed scanning based on the database, which is usually once every 5-30 minutes, and instead uses business event-driven bypass incremental writing. This reduces statistical latency from minutes to milliseconds, allowing operations personnel to see order volume, revenue, and rankings almost synchronously with actual business transactions. This enables timely detection and response to sudden traffic spikes or abnormal fluctuations, resulting in a qualitative leap in statistical real-time performance.

[0017] 2. This invention addresses three sub-problems in statistical scenarios: aggregation, sorting, and lifecycle. It designs hash tables, ordered sets, and key-level expiration as an inseparable collaborative network, driven by the same event for concurrent writes. Any operation synchronously affects the consistency state of all three. This collaborative design ensures that the selection and binding of these three data structures are holistic, forming an inseparable organic whole.

[0018] 3. This invention uses a unified data model based on placeholder semantics, namely a dimension placeholder identification mechanism, to replace approximately 580 independent statistical tables in traditional solutions with three core tables. In a typical scenario involving 500 merchants, 50 companies, and 30 provinces, the number of tables can be reduced by 99.5%. Adding an operational level, such as a regional level, requires no changes to the table structure or the addition of new aggregation tasks; only entity type mapping needs to be added at the query layer. Development and maintenance costs are significantly reduced. Down to The memory footprint of in-memory databases is reduced by more than 60% due to placeholder reuse and unified key naming, storage costs are reduced by more than 99%, and linear scalability is supported.

[0019] 4. This invention completely migrates high-frequency real-time statistical calculations—namely, order accumulation, revenue aggregation, and ranking updates—from a relational database to an in-memory database. The database only undertakes two lightweight responsibilities: periodically receiving aggregated results in batches and handling historical queries; it no longer participates in the real-time statistical process. During peak business periods, such as the midday rush, the statistical pressure is entirely handled by the in-memory database, which always maintains low load. In a multi-tenant independent database architecture, the concurrent statistical connection pressure from 500 tenant databases is avoided. Calculations show that this architecture reduces database statistical-related input / output operations by over 95%, lowers database pressure by over 95%, and completely eliminates performance bottlenecks.

[0020] 5. This invention employs a collaborative architecture with a large dashboard layer (global aggregation across the entire platform database), a small dashboard layer (synchronization of tenant database device details to the entire platform database), and a today's ranking layer (real-time ranking of an ordered set of in-memory databases). This allows operations personnel to drill down from macro trends to individual device turnover rates within a single dashboard, and then identify abnormal merchants by combining real-time rankings, breaking down the barriers between the global dashboard and device analysis in traditional solutions. The cross-database synchronization pipeline solves the data aggregation problem in multi-tenant independent database architectures, and eliminates the need for inter-tenant database access, ensuring the security of multi-tenant data isolation. Regarding consistency, this invention does not pursue strong consistency across the three layers of data. Instead, it designs a hierarchical consistency model with second-level (today's ranking), minute-level (large dashboard aggregation), and hourly (device details), precisely matching the cost and benefit of consistency: the more real-time the data, the lighter it is (i.e., only in-memory operations), while the more heavyweight the data, the more allowable lag (i.e., batch calculation and synchronization), thus achieving an optimal balance between data timeliness and system cost. Through the collaboration of three data sources, a unified operational perspective encompassing global, detailed, and ranking data is realized.

[0021] 6. This invention eliminates information silos through a unified framework encompassing both orders and revenue, and eliminates the reversal state machine through negative increment semantics. That is, order statistics and revenue statistics adopt a completely symmetrical architecture. Refunds, reversals, and discounts are all written to the same hash field and ordered set via negative increment atomic operations, eliminating the need for separate reversal pipelines or reverse transactions. This eliminates the state machine complexity of traditional revenue statistics while ensuring statistical accuracy. Both pipelines share the same key naming system, database write process, and aggregation logic, achieving a code reusability rate of over 80% and supporting cross-dimensional correlation analysis.

[0022] 7. This invention completely decouples business processes from statistics, preventing the propagation of faults. All statistical writes are executed in a "write-and-forget" mode, without blocking the main business flow. Even if the in-memory database is temporarily unavailable or a statistical write fails, core business operations such as order creation and settlement are not affected. This design downgrades the availability requirements of the statistical system from strong dependency to a best-effort approach, significantly improving the overall system robustness. Simultaneously, a timed database write mechanism serves as eventual consistency compensation for real-time writes, ensuring no data loss.

[0023] 8. This invention features high concurrency and scalability, supporting multiple levels of devices and merchants. It migrates all high-frequency statistical writes and real-time queries to an in-memory database, completely eliminating lock contention and connection pool pressure inherent in relational databases. The write end executes over twenty atomic operations in batches through concurrent tasks, while the query end isolates today's queries within the in-memory database layer using a tiered strategy of hot and cold data. In an architecture with 500 independent database tenants, the overall system throughput is increased by more than 10 times.

[0024] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention. Attached Figure Description

[0025] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0026] Figure 1 This is a flowchart illustrating a multi-level, real-time statistical method for two dimensions of orders and revenue, according to an exemplary embodiment. Figure 2 This is a schematic diagram illustrating the structure of a multi-level, real-time statistical system for orders and revenue in two dimensions, according to an exemplary embodiment. Figure 3 This is a schematic diagram of the data processing flow under a dual-pipeline symmetrical architecture in a real-time statistical method for orders and revenue with two dimensions and multiple levels, according to an exemplary embodiment. Figure 4 This is a timeline flowchart illustrating a multi-level, real-time statistical method for orders and revenue in a dual-dimensional context, based on an exemplary embodiment, in practical application.

[0027] Figure label: 201. Incremental Statistics Module; 202. Multi-level Aggregation Module; 203. Folding Mapping Module; 204. Cross-pipeline Association Module; 205. Dynamic Conditional Concatenation Query Module. Detailed Implementation

[0028] The following description and accompanying drawings fully illustrate specific embodiments described herein to enable those skilled in the art to practice them. Some portions and features of certain embodiments may be included in or replace portions and features of other embodiments. The scope of the embodiments herein includes the entire scope of the claims and all available equivalents thereof. The various embodiments described herein are presented in a progressive manner, with each embodiment focusing on its differences from other embodiments; similar or identical parts between embodiments can be referred to interchangeably.

[0029] The modules in the apparatus or system of this application can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0030] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0031] Figure 1 An embodiment of a multi-level, real-time statistical method for order and revenue analysis based on the present invention is shown.

[0032] In this optional embodiment, the multi-level real-time statistical method for both orders and revenue includes: Step S101: The received business event data generated by the operation of the smart terminal is incrementally written to the memory database in a bypass asynchronous writing mode to obtain a real-time incremental statistical event stream.

[0033] In this optional embodiment, the received business event data generated by the operation of the smart terminal is incrementally written to the memory database using a bypass asynchronous write mode to obtain a real-time incremental statistical event stream, including: Event monitoring and capture processing is performed on the smart terminal operation business link to obtain business event data, and the business event data is classified based on event type identifier to obtain a classified business event set; Based on the event type identifier, the incremental direction and write operation type are mapped to the categorized business event set to obtain the incremental statistical operation instruction set; Based on the bypass asynchronous method, the incremental statistics operation instruction set is submitted to the in-memory database in batches through concurrent tasks for atomic incremental operations, resulting in a real-time incremental statistics event stream.

[0034] It should be noted that business event data includes: food delivery order creation, delivery order creation, vending machine order status change, settlement completion, and refund processing data. Event type identifiers are used to distinguish the types of the above business operations, specifically including: food delivery order creation, delivery order creation, vending machine order status change, settlement completion, and refund processing completion. The categorized business event sets specifically include: events that call the order statistics write method after food delivery order creation; events that call the order statistics write method after delivery order creation; events that call the device order incremental write method after vending machine order status change (supporting both positive and negative increments); events that call the revenue incremental write method after settlement completion; and events that call the revenue incremental write method after refund processing (i.e., passing in a negative amount). A real-time incremental statistics event stream is obtained through a business event-based bypass decoupling real-time statistics write mechanism. This abandons the traditional timed full scan of the business table statistical mode, instead, after each business event is successfully completed, incremental statistics operation instruction sets are submitted to the memory cache layer in batches via concurrent tasks in a bypass asynchronous manner (i.e., submit and forget mode) for incremental writing. The specific mapping rules between incremental directions and write operation types include: calling the order statistics write method after a food delivery order is created; calling the order statistics write method after a delivery order is created; calling the device order incremental write method after a locker order status change (this write supports positive and negative increments; the increment is positive one when created and negative one when canceled); calling the revenue incremental write method after settlement is completed; and calling the revenue incremental write method after refund processing is completed, i.e., passing in a negative amount. The incremental statistics operation instruction set generated by the above mapping rules is submitted to the in-memory database in batches via concurrent tasks for atomic incremental operations, resulting in a real-time incremental statistics event stream. All write operations are executed in asynchronous discard mode, using concurrent tasks to batch execute multiple in-memory database atomic operations without blocking the main business process path.

[0035] Even if statistical writes occasionally fail, such as when the in-memory database is temporarily unavailable, core business operations such as order creation and settlement will not be affected. Simultaneously, the system uses a scheduled database write mechanism to periodically perform a full synchronization of the day's data as eventual consistency compensation for real-time writes, ensuring no data loss. This mechanism reduces statistical latency from minutes in traditional solutions to milliseconds and achieves complete separation between business logic and statistical logic.

[0036] Step S102: Perform real-time memory statistics on the real-time incremental statistical event stream based on multiple collaborative data structures to obtain a multi-level aggregated statistical result set.

[0037] In this optional embodiment, real-time in-memory statistics are performed on the real-time incremental statistical event stream based on multiple types of collaborative data structures to obtain a multi-level aggregated statistical result set, including: Each incremental statistical event in the real-time incremental statistical event stream is parsed and normalized to obtain a set of statistical dimension attributes. The entity type parameters in the set of statistical dimension attributes are then format-validated and standardized to obtain standardized incremental statistical events. Based on the set of statistical dimension attributes and combined with the multi-type collaborative data structure of the in-memory database, the standardized incremental statistical events are atomically incrementally written and key-level validity period configured within the same concurrent batch to obtain the updated multidimensional statistical data. The updated multidimensional statistical data is fully scanned and structured and merged according to the preset time trigger conditions to obtain a multi-level aggregated statistical result set.

[0038] It should be noted that each incremental statistical event in the real-time incremental statistical event stream is an atomic incremental operation instruction generated by business events and to be written to the in-memory database, such as hash table atomic increment, ordered set atomic increment, and validity period refresh operations; the statistical dimension attribute set includes attributes such as date, hour, merchant identifier, company identifier, province identifier, site identifier, and entity type used to construct the key naming convention; the entity type parameters include: platform-wide, merchant, company, province, and site, which are parameters used to distinguish different statistical levels and to achieve dimension folding in conjunction with placeholder semantics; standardized incremental statistical events include: incremental statistical events that conform to the unified key naming convention and entity type parameter standard after format validation and standardization conversion of the entity type parameters in the statistical dimension attribute set; and multiple collaborative data structure packages. Includes: hash tables, which carry multi-dimensional aggregation results; ordered sets, which carry real-time sorting status; and key-level expiration, which carries the data lifecycle; updated multi-dimensional statistical data includes: the latest statistical values ​​of all related dimensions such as total volume across the entire platform, time-based statistics, rankings at each level, provincial data, and spatial distribution, stored in the in-memory database; preset time trigger conditions include: triggering every five minutes, a backup synchronous trigger from 00:05 to 00:09 every day, and a monthly summary trigger from 02:00 to 02:04 on the first day of each month; the multi-level aggregated statistical result set covers a complete dataset of daily summary across the entire platform, hourly summary across the entire platform, daily summary of merchants, hourly summary of merchants, daily summary of companies, hourly summary of companies, daily summary of revenue, hourly summary of revenue, various rankings, and multi-dimensional aggregation results such as provinces / entities / maps.

[0039] like Figure 3As shown, business events include food delivery, parcel delivery, vending machines, revenue sharing, and refunds. These events flow into a statistical engine with a dual-pipeline symmetrical architecture. This engine includes order and revenue pipelines, enabling multi-dimensional incremental aggregation via hash tables, real-time ranking via ordered sets, and supporting negative number correction and three-segment encoding. It also connects to a shared layer, which provides a unified key space, entity type parameters, key-level expiration, and bypass asynchronous write capabilities. Data from the statistical engine is persisted according to a scheduled data persistence strategy: 5 minutes, midnight backup, and monthly summary. After persistence, the data forms a three-layer data source: a main data layer, a secondary data layer, and a ranking layer. The secondary data layer is the tenant database. Daily / monthly device statistics (i.e., data from 500 tenant databases) are synchronized across databases to the dashboard layer. The dashboard layer is a daily / hourly / monthly summary table for the entire platform database. There is also a ranking layer that maintains today's real-time rankings based on in-memory ordered sets. Data from these three data sources is sent to the query layer, which supports placeholder semantics, five levels per table, and [other features]. (i.e., -1 indicates the entire platform) and cross-pipeline correlation analysis, and output the query layer results to the operation dashboard. Through problem-oriented collaborative design based on in-memory database multi-data structure, a multi-level aggregated statistical result set is obtained. Specifically, this invention is not an independent application of hash tables, ordered sets, and expiration mechanisms, but a data structure collaborative network built based on the intelligent terminal operation statistics scenario, that is, multiple types of collaborative data structures, in which hash tables carry multi-dimensional aggregation results, ordered sets carry real-time sorting status, and key-level validity carries the data lifecycle. The three share a unified key naming system and entity type parameters, and are concurrently written by the same business event. Incremental operations on any structure simultaneously affect the data consistency of the other two; for example, changes in ranking scores must be strictly synchronized with changes in aggregate values, and expiration time refreshes must cover all keys generated by the same event. This binding relationship makes the three form an inseparable statistical closed loop, rather than a simple superposition of three tools.

[0040] The specific steps for obtaining multi-level aggregated statistical result sets are as follows: Step 1: Obtain standardized incremental statistical events by defining a unified key naming convention. All in-memory database keys follow a unified pattern, with different dimensions carried by different positions within the keys, forming a hierarchical naming system. The key naming convention for the order statistics pipeline is as follows: Daily summary key for the entire platform: "Order:Dashboard:Total:{Date}", Hourly key for the entire platform: "Order:Dashboard:Hour:{Date}:{Hour}", Daily summary key for merchants: "Order:Dashboard:Merchant:{Date}:{Merchant ID}", Hourly key for merchants: "Order:Dashboard:Merchant:Hour:{Date}:{Hour}:{Merchant ID}", Daily summary key for the company: "Order:Dashboard:Company:{Date}:{Company ID}", Hourly key for the company: "Order:Dashboard:Company:Hour:{Date}:{Hour}:{Company ID}". The key naming convention for the revenue statistics pipeline is as follows: Total revenue key: "Revenue:Dashboard:Total:{Date}", Hourly revenue key: "Revenue:Dashboard:Hour:{Date}:{Hour}". Each ranking corresponds to an independent ordered set key, such as the merchant ranking key "orders:dashboard:merchant:ranking:{date}", the company ranking key "orders:dashboard:company:ranking:{date}", and the revenue merchant ranking key "revenue:dashboard:merchant:ranking:{date}". At the provincial level, there are also provincial time period keys and provincial merchant ranking keys. At the entity level, there are also entity province ranking keys and entity city ranking keys. Map data also has an independent hash table key.

[0041] Step 2: Scan layer by layer from coarse to fine granular according to the dimension level. During the database synchronization, the system scans the updated multidimensional statistical data in the following order: (1) Full platform dimension: directly read the full platform daily summary hash table, parse the order type of each field and map it to an enumeration value, and mark it as a full platform summary row with hour equal to negative one, merchant ID equal to negative one, and company ID equal to negative one; (2) Full platform hour dimension: traverse from zero to twenty-three hours and read the full platform hour hash table hour by hour; (3) Merchant dimension: scan all keys matching "order:dashboard:merchant:{date}:merchantID1" through the pattern matching command, parse the key suffix "merchantID1" to obtain the merchant ID, and query the merchant name from the merchant table. And write; (4) Merchant hour dimension: Scan all keys matching "order:dashboard:merchant:hour:{date}:merchantID2" through pattern matching command, and parse the "merchantID2" format in the suffix; (5) Company dimension: Scan all keys matching "order:dashboard:company:{date}:companyID" through pattern matching command, parse the "companyID" suffix of the key to obtain the company identifier, and query the database to obtain the list of merchant identifiers associated with the company, and generate a detailed record for each associated merchant; (6) Company hour dimension: Same as above, parse the "hour:company identifier" format in the suffix, and expand it into a detailed record of the associated merchant.

[0042] The above steps retrieve all keys that meet the criteria, resulting in "Order:Dashboard:Merchant:20260120:MerchantID1", "Order:Dashboard:Merchant:20260120:MerchantID2", and "Order:Dashboard:Merchant:20260120:MerchantID3". We can directly obtain all merchant IDs with orders placed on the current date. With the key, we can retrieve the order volume for each merchant. Then, we can query the merchant table to determine if there is redundancy, and write the merchant names to the database.

[0043] Step 3: Parse the hash table fields and map them to database fields. Each hash table field is an order type identifier string, such as "foodOrder", "deliveryOrder", and "deviceOrder". Through the mapping function from field name to enumeration value, that is, "foodOrder" maps to 1, "deliveryOrder" maps to 2, and "deviceOrder" maps to 3, it is converted into an order type value in the database. The field value is the cumulative count value of this type in this dimension.

[0044] Step 4: Summarize all dimension scan results and perform batch write to obtain a multi-level aggregated statistical result set. All dimension rows generated in Steps 2 and 3 are summarized into a list and written to the database order basic details table in one go using a batch write statement with insert or update semantics, utilizing a composite unique key to ensure idempotency.

[0045] To address the multi-dimensional aggregation problem, a hash table structure is chosen: hash tables inherently support the mapping from fields to values, allowing a single key to carry multiple statistical indicators, and replacing the dimension representation method of multi-table joins in relational databases with field encoding. The order pipeline uses order type names, such as "deviceOrder", "foodOrder", and "deliveryOrder", as hash table fields; the revenue pipeline uses a three-segment encoding to compress revenue type, entity type, and entity identifier into a single field. Refunds, reversals, and reductions are all written to the same field via negative increments, reducing the storage complexity of multi-dimensional aggregation from... Down to .

[0046] To address the real-time ranking issue, an ordered set structure is chosen: ordered sets naturally support automatic sorting by score. Entity identifiers are used as members, and statistical values ​​are used as scores. Each business event updates the scores through atomic incremental operations; insertion automatically sorts the data, eliminating the need for additional sorting calculations. The same ranking logic—ordered set incremental and reverse range queries—is reused across all ranking scenarios, including merchant ranking, company ranking, site ranking, provincial / regional merchant ranking, entity province ranking, entity city ranking, and income ranking, differing only in key names.

[0047] To address data lifecycle issues, a key-level expiration mechanism is adopted: the expiration date is bound to each write operation, and the expiration date is refreshed with each write, for example, every seven days. New keys are automatically generated for data on the current day, and expired data is automatically cleaned up, eliminating the need for additional cleanup tasks and data archiving logic, thus achieving zero-maintenance data lifecycle management.

[0048] The three structures share a unified key naming system, such as "{statistical type}:{dashboard}:{dimensional}:{date}", a unified date partitioning rule, and unified entity type parameters, all driven by the same business event for concurrent writes. When a single business event occurs, such as a cabinet order changing its status to completed, the system executes more than twenty atomic operations concurrently through a single concurrent task call. These operations include hash table atomic increments, ordered set atomic increments, and expiration date refreshes, simultaneously updating all related dimensions such as total volume across the entire platform, time-based statistics, rankings at each level, provincial data, and spatial distribution. The total time consumed depends on the slowest single operation rather than the sum of all operations, avoiding the serial latency of calculating each dimension sequentially in traditional solutions.

[0049] Step S103: According to the preset timed data storage rules, the multi-level aggregated statistical result set is written idempotently to obtain a multi-level persistent statistical data set. Then, combined with the dimension placeholder identification mechanism, the multi-level persistent statistical data set is folded and mapped to a relational data table to generate a unified dimension folded storage table.

[0050] In this optional embodiment, according to preset timed write rules, the multi-level aggregated statistical result set is idempotently persisted to obtain a multi-level persistent statistical data set. Then, using a dimension placeholder identifier mechanism, the multi-level persistent statistical data set is folded and mapped to a relational data table to generate a unified dimension-folded storage table, including: Based on the preset timed data entry rules, the multi-level aggregated statistical result set is scanned and traversed to obtain the aggregation keys of each dimension. The aggregation keys of each dimension are then parsed and dimension identifiers are extracted and encapsulated into a multi-level statistical data set. The multi-level statistical data set is written row by row into the basic detail table of the relational database using idempotent persistence write rules to obtain the multi-level statistical data table. The database unique index is then used to perform conflict detection and overwrite update processing on the duplicate write records in the multi-level statistical data table to obtain the multi-level persistent statistical data set. According to the preset placeholder mapping rules, the entity identifier field of the multi-level persistent statistical data set is filled with the target dimension placeholder value to obtain the multi-dimensional statistical record dataset. Then, according to the entity type parameter, the multi-dimensional statistical record dataset is folded into the target record row of the same relational data table to generate a unified dimension folded storage table.

[0051] It should be noted that the aggregation keys for each dimension are used to identify key information for different statistical dimensions, specifically including combined fields such as date, hour, merchant identifier, company identifier, province identifier, site identifier, and entity type; the multi-level statistical data set is a dataset encapsulated after parsing the aggregation keys for each dimension and extracting the dimension identifiers; the basic detail tables of the relational database include: the order basic detail table and the revenue basic detail table, which are used to carry the raw statistical data synchronously written from the in-memory database; the multi-level statistical data table includes: an intermediate state data table obtained after writing the multi-level statistical data set row by row into the basic detail tables of the relational database using idempotent persistence write rules; conflict detection and overwrite update processing utilize the database's unique index, such as the combined unique key of date, hour, and merchant type, to detect duplicate write records in the multi-level statistical data table and perform overwrite update operations to ensure that the same statistical record, no matter how many times it is synchronized, will ultimately remain unchanged. The results are all the values ​​written last time; the multi-level persistent statistical data set is a complete statistical data set stored in a relational database after conflict detection and overwrite update processing, ensuring eventual data consistency; the preset placeholder mapping rules include: if entity type = full platform, then merchant identifier = -1 and company identifier = -1; if entity type = merchant, then merchant identifier = entity ID and company identifier = -1; if entity type = company, then company identifier = entity ID; if entity type = province, then province identifier = entity ID; if entity type = site, then site identifier = entity ID; the target dimension placeholder value is -1, which represents a full platform or an inapplicable placeholder value; the multi-dimensional statistical record dataset is the dataset obtained by filling the entity identifier field of the multi-level persistent statistical data set with the target dimension placeholder value; the unified dimension folded storage table is a single physical table that achieves multi-level reuse through placeholder semantics, replacing the traditional solution. Zhang's independent statistical table; the target record behavior of the same relational data table is stored in a unified dimension folded storage table. The specific data rows of the platform summary row and the entity dimension row are distinguished by the combination of entity type parameters and placeholder values. That is, the query is located by explicitly including conditions such as "merchant ID=-1 AND company ID=-1".

[0052] The scheduled data write mechanism (i.e., the preset scheduled data write rules) is implemented through a backend service and includes three levels of scheduled rules. The specific rules of the scheduled data write mechanism are as follows: Rule 1: Real-time synchronization is triggered every five minutes. Specific execution includes: (1) fully scanning the daily data of the order hash table in the in-memory database and writing it into the database order basic details table; (2) aggregating the order basic details table to generate a daily order summary table and an hourly order summary table; (3) fully scanning the daily data of the revenue hash table in the in-memory database and writing it into the database revenue basic details table; (4) aggregating the revenue basic details table to generate a daily revenue summary table. Regarding concurrency control, a distributed lock in the in-memory database ensures single-instance execution. The lock's validity period is four minutes, slightly shorter than the five-minute interval, ensuring that the lock will not hinder the next synchronization due to abnormal unrelease.

[0053] Rule 2: Daily Midnight Backup Synchronization. The trigger condition is the time window from 00:05 to 00:09 daily. The execution process is exactly the same four-step process as Rule 1, but the operation object is changed to yesterday's data. Its purpose is to compensate for eventual consistency; even if Rule 1 caused some write failures during yesterday's peak period due to temporary unavailability of the in-memory database, the midnight backup synchronization will overwrite all of yesterday's data, ensuring the eventual integrity of yesterday's data. Regarding concurrency control, the lock validity period is extended to ten minutes, considering the potentially large data volume that the midnight backup might handle.

[0054] Rule 3: Monthly Summary on the 1st of Each Month. The trigger condition is the time window from 2:00 AM to 2:04 AM on the 1st of each month. The execution involves aggregating the previous month's data from the daily revenue summary table by year and month, and writing it to the monthly revenue summary table.

[0055] Regarding the database write strategy, all insert operations employ idempotent semantics for insert or update, implemented using unique database indexes, such as combined unique keys for date, hour, and merchant type. Regardless of how many times a statistical record is synchronized, the final result is always the value written last. This allows for the safe overlay of five-minute real-time synchronization and midnight backup synchronization; the former guarantees real-time performance, while the latter guarantees integrity, and the two do not conflict.

[0056] Multi-level reuse is achieved through a unified data model based on placeholder semantics. Specifically, the system uses entity type parameters in conjunction with placeholder semantics, where the special value -1 represents "universal" or "not applicable." This allows the system to replace the traditional approach with three core database tables. Storage architecture for Zhang's independent statistical tables.

[0057] In the details table, the system achieves multi-level reuse through the mapping rules between entity type parameters and placeholders. The mapping logic is as follows: If entity type = all platforms, then merchant identifier = -1 and company identifier = -1; if entity type = merchant, then merchant identifier = entity ID and company identifier = -1; if entity type = company, then company identifier = entity ID; if entity type = province, then province identifier = entity ID; if entity type = site, then site identifier = entity ID.

[0058] In the above steps, "Merchant ID equals -1" and "Company ID equals -1" in the database table serve as placeholders for the entire platform. When querying the entire platform dimension, the WHERE condition explicitly includes "Merchant ID = -1 AND Company ID = -1", thus distinguishing the entire platform summary row from the entity dimension row, allowing them to coexist in the same physical table. This is the core mechanism of dimension folding capability: without introducing physical wide tables or multi-table joins, it dynamically expands or collapses statistical dimensions during the query phase through placeholder values.

[0059] Adding a new operational level requires no changes to the table structure or the addition of new aggregation tasks; only the addition of entity type mappings at the query layer is needed. Development and maintenance costs are reduced accordingly. Down to This placeholder semantics is also applied to key naming in in-memory databases. By reusing keys, the number of keys is significantly reduced, resulting in a reduction of storage space usage by more than 60%.

[0060] This query method avoids table scans or joins based on the number of levels, decoupling the complexity of statistical queries from the number of levels. As a result, when adding new operational levels, the query performance remains constant and is not affected by the expansion of the level scale.

[0061] Step S104: Based on the multi-layer data source collaboration strategy, the unified dimension folded storage table is aggregated with hierarchical consistency data sources to obtain a multi-source statistical data set. Then, cross-pipeline association calculations are performed on the multi-source statistical data set to obtain cross-dimensional association statistical results.

[0062] In this optional embodiment, based on a multi-layer data source collaboration strategy, a hierarchical consistency data source aggregation is performed on the unified dimension folded storage table to obtain a multi-source statistical data set. Cross-pipeline correlation calculations are then performed on the multi-source statistical data set to obtain cross-dimensional correlation statistical results, including: Based on the hierarchical consistency rules in the multi-layer data source collaboration strategy, data source routing determination and hierarchical parallel reading processing are performed on the unified dimension folded storage table to obtain a hierarchical statistical subset.

[0063] In this optional embodiment, based on the hierarchical consistency rules in the multi-layer data source collaboration strategy, the unified dimension folded storage table undergoes data source routing determination and hierarchical parallel read processing to obtain a hierarchical statistical subset including: Perform data source routing determination on the unified dimension folded storage table, and combine the date partition field and entity type parameter in the unified dimension folded storage table to determine the data source routing mapping relationship of each statistical record; Based on the first routing path in the data source routing mapping relationship, perform an ordered set reverse range query on the real-time ranking layer to obtain real-time sorted snapshot data, and perform entity identifier association verification on the sorted snapshot data to obtain the first real-time statistical subset; Based on the second routing path in the data source routing mapping relationship, daily and hourly summary data are read from the global summary dashboard layer to obtain summary data. The summary data is then subjected to data integrity verification and missing data marking to obtain the second historical summary subset. Based on the third routing path in the data source routing mapping relationship, the device-level daily statistical details are read from the device detail disk layer to obtain the daily statistical details data. The field integrity is checked and outlier filtering is performed on the daily statistical details data to obtain the third device detail subset. The first real-time statistics subset, the second historical summary subset, and the third equipment details subset are integrated to obtain a hierarchical statistics subset.

[0064] Based on the entity type parameter, the hierarchical statistical subsets are associated, merged, and time-aligned to obtain a multi-source statistical data set; Alignment processing is performed on the multi-dimensional statistical values ​​in the multi-source statistical data set to obtain a dual-pipeline statistical data set. Cross-pipeline aggregation and derived index calculation processing are then performed on the dual-pipeline statistical data set to obtain cross-dimensional correlation statistical results.

[0065] In this optional embodiment, the multi-dimensional statistical values ​​of the multi-source statistical data set are aligned to obtain a dual-pipeline statistical data set. The dual-pipeline statistical data set is then subjected to cross-pipeline aggregation and derived index calculation to obtain cross-dimensional correlation statistical results, including: Based on the entity type parameters and entity identifiers of each statistical record in the multi-source statistical data set, extract the order dimension statistical values ​​and revenue dimension statistical values ​​belonging to the same entity identifier from the multi-source statistical data set; The statistical values ​​of the order dimension and the revenue dimension are aligned with the entity identifier according to a unified key naming system to obtain a dual-pipeline statistical data set after entity dimension alignment; Based on the symmetrical order and revenue statistics pipelines, the system reads the order and revenue statistics indicators under each entity identifier for the dual-pipeline statistical data set. It then performs cross-pipeline mapping and aggregation processing on the order and revenue statistics indicators belonging to the same entity identifier. Based on the mapping and aggregation results, it calculates derived indicators to obtain cross-dimensional correlation statistics results.

[0066] It should be noted that the sources of the multi-layer data source collaboration strategy include: an in-memory database, which carries real-time incremental statistics at the second level; a relational database, which carries persistent aggregation at the minute level; and a device-side reporting interface, which carries raw detailed data. The multi-layer data source collaboration strategy is a collaborative scheduling and query routing mechanism for the above three levels of data sources. The hierarchical consistency data source aggregation is a data source hierarchy system formed by defining the three levels of data sources in the multi-layer data source collaboration strategy according to their real-time performance, completeness, and authority. The multi-source statistical data set includes: a collection of real-time incremental statistical results, persistent aggregation results, and raw detailed data obtained from the in-memory database, relational database, and device-side reporting interface, respectively. The cross-dimensional correlation statistical result is a comprehensive statistical result obtained by aggregating order statistical indicators, revenue statistical indicators, and device status indicators from the multi-source statistical data set according to a unified dimension key. Data source routing determination: based on the time range, dimension granularity, and real-time consistency of the query request... To meet real-time requirements, the system automatically selects whether to retrieve data from an in-memory database, a relational database, or a device-side interface. The hierarchical statistical subsets include: a first real-time statistical subset, a second historical summary subset, and a third device detail subset. The first real-time statistical subset includes second-level incremental statistical data retrieved from the in-memory database within the last 5 minutes. The second historical summary subset includes minute-level persistent summary statistical data retrieved from the relational database for data older than 5 minutes. Daily statistical detail data includes fields such as order volume, revenue amount, and device operation count, retrieved from the basic detail table in the relational database by date dimension. The complete daily detailed record; the third device detailed subset includes: the original cabinet order status change logs and sensor data obtained from the device-side reporting interface without aggregation processing; the dual-pipeline statistical data set includes: the set of indicators such as order volume, delivery time, and fulfillment rate output from the order statistics pipeline, and the set of indicators such as settlement amount, refund amount, and revenue sharing details output from the revenue statistics pipeline; cross-pipeline aggregation is the process of horizontally concatenating and aligning the output results of the order statistics pipeline and the revenue statistics pipeline according to the same dimension key, such as date, merchant, and site; derived indicator calculation is based on the basic indicators after cross-pipeline aggregation, with... The average order value is calculated based on the acquired order volume and revenue. Cross-dimensional statistical results include: number of orders created, number of completed deliveries, number of overdue orders, number of canceled orders, and average delivery time. Order statistics include: number of orders created, number of completed deliveries, number of overdue orders, number of canceled orders, and average delivery time. Revenue statistics include: total settlement revenue, total refund amount, net revenue, number of transactions completed in the split billing process, and number of abnormal settlement transactions. Cross-pipeline mapping and aggregation processing involves establishing a mapping table that associates order IDs with settlement serial numbers, and performing precise matching and merging of the statistical results from the order dimension and the revenue dimension through this mapping table.

[0067] By employing a collaborative statistical architecture based on three layers of data sources—large-cap, small-cap, and today's ranking—a tiered statistical subset is obtained. The system constructs a three-layer complementary data statistical system, enabling collaborative queries through a unified entity type parameter system.

[0068] The first layer is the main data layer, which is the platform-wide database: it stores global operational statistics, including daily order summaries, hourly order summaries, daily revenue summaries, and monthly revenue summaries for the entire platform and each level. The data is sourced from the in-memory database and is periodically written to and aggregated.

[0069] The second layer is the sub-database, or tenant-independent database: it stores daily device-level statistics for each merchant, including total orders, order counts for each status, peak-hour orders, turnover rate, and revenue; as well as monthly device-level statistics, with data generated independently by scheduled tasks in each tenant's database. Since device-level statistics need to be generated in the tenant-independent database, involving the merchant's device order table, payment table, and other business tables, the system is designed with a cross-database synchronization pipeline from the sub-database to the main database: after the scheduled task generates daily device statistics records in each tenant's database, it dynamically obtains a connection to the tenant's database and synchronizes the data record by record to the device statistics summary table in the entire platform database, using insert or update statements to ensure idempotency. The synchronized data is indexed in the entire platform database by province, city, company, site, etc., supporting querying device details from any dimension in the global main database.

[0070] The third layer is today's ranking layer, which is an ordered set in the in-memory database. It stores today's real-time ranking data using an ordered set data structure, including merchant order rankings, company order rankings, site order rankings, and merchant / company / site revenue rankings. This data originates from incremental writes via business events. When querying from the front end, the system automatically determines the ranking: if querying today's ranking, it directly retrieves the data from the ordered set in the in-memory database using a reverse range query and associates it with the database query name; if querying historical rankings, it retrieves the data from the aggregation table based on daily statistics.

[0071] This three-tier architecture enables a unified operational perspective, providing a global overview, detailed breakdowns, and daily rankings. Furthermore, the cross-database synchronization pipeline solves the data aggregation problem in a multi-tenant independent database architecture, eliminating the need for mutual access between tenant databases and ensuring the security of multi-tenant data isolation.

[0072] The three-tiered consistency guarantee: This invention does not pursue strong consistency across the three layers of data. Instead, it designs differentiated consistency models based on the operational decision-making scenarios served by each layer. The "Today's Ranking" layer serves second-level operational responses, such as traffic surge alerts, using business event-driven bypass writes with a latency of seconds. The "Big Data Layer" serves minute-level trend judgments, such as real-time dashboards during midday peak hours, using a memory database with scheduled writes every five minutes, resulting in a latency of minutes. The "Small Data Layer" serves hourly-level refined analysis, such as drill-down on equipment turnover rates, using independent calculations in the tenant database followed by cross-database synchronization, resulting in a latency of hours. The "Big Data Layer" and "Today's Ranking" layer employ an eventual consistency model, while the "Small Data Layer" and "Big Data Layer" achieve near real-time consistency through an idempotent synchronization pipeline. This tiered consistency design precisely matches the costs and benefits of consistency: more real-time data is more lightweight, requiring only memory operations; more heavyweight data is more allowed to lag, requiring batch calculations and synchronization, thus achieving an optimal balance between data timeliness and system cost.

[0073] A unified statistical framework based on a symmetrical dual-pipeline architecture of orders and revenue is used to obtain cross-dimensional correlation statistical results. The system constructs two structurally symmetrical but content-independent statistical pipelines: the order statistics pipeline and the revenue statistics pipeline. The two pipelines adopt the same architectural pattern: the same key naming system, such as "{type}:{dashboard}:{dimension}:{date}"; the same data structure type, such as hash tables for aggregation and sorted sets for ranking; and the same write mode, such as event-driven concurrent incremental writes, with only the hash table field encoding rules differing.

[0074] The revenue pipeline uses a three-stage field encoding, namely "Revenue Type: Entity Type: Entity Identifier," to carry revenue data across all dimensions within a single hash table key. Refunds, reversals, and fee reductions are all written to the same hash field and ordered set via atomic negative increment operations, eliminating the need for separate reversal pipelines or reverse transactions. This eliminates the state machine complexity in revenue statistics while ensuring statistical accuracy. The symmetrical design of the dual pipelines results in a code reusability rate exceeding 80% and supports cross-dimensional correlation analysis. For example, it enables anomaly detection such as an increase in order volume but a decrease in revenue for a merchant, eliminating the information silos between order and revenue statistics found in traditional solutions.

[0075] The specific analysis of cross-pipeline correlation includes: retrieving the daily order volume of a specified merchant from the order statistics pipeline. The system constructs a daily summary key for the merchant based on a unified key naming convention: "Order:Dashboard:Merchant:{Date}:{Merchant ID}", and calls a hash table full-field read command to obtain the daily order volume of each type for that merchant. For example, reading the value of the "deviceOrder" field represents the number of vending orders for that merchant that day, reading the value of the "foodOrder" field represents the number of food delivery orders for that merchant that day, and reading the value of the "deliveryOrder" field represents the number of delivery orders for that merchant that day. Retrieving the daily revenue of the same merchant from the revenue statistics pipeline. The system constructs a total revenue key: "Revenue:Dashboard:Total:{Date}", and calls a hash table full-field read command to obtain all revenue data. Since all merchant revenue data in the revenue pipeline is aggregated into the same total revenue key, and different merchants are distinguished by a three-segment code "Revenue Type:Entity Type:Entity Identifier" field prefix, the system constructs target fields according to the coding rules: "1:3:{Merchant Identifier}" represents the merchant's grid usage fee revenue, with the coding meaning: Revenue Type 1 = Grid Usage Fee, Entity Type 3 = Merchant; "2:3:{Merchant Identifier}" represents the merchant's grid overdue fee revenue, with the coding meaning: Revenue Type 2 = Overdue Fee, Entity Type 3 = Merchant. The values ​​of these two fields are read from the hash table, with the amounts stored in cents. After being converted to yuan, they are summed to obtain the merchant's total daily revenue. Cross-pipeline derived metrics are calculated. Based on the obtained order volume and revenue amount, the system calculates the average order value, i.e. This metric cannot be obtained from a single pipeline; it must be calculated across pipelines.

[0076] Step S105: Based on the external entity type parameter in the external query request, perform dynamic condition concatenation query on the cross-dimensional correlation statistical results, and combine historical baseline data to perform anomaly detection on the query results to obtain two-dimensional, multi-level real-time statistical results.

[0077] In this optional embodiment, based on the external entity type parameter in the external query request, dynamic conditional concatenation query is performed on the cross-dimensional correlation statistical results, and anomaly detection is performed on the query results in conjunction with historical baseline data to obtain two-dimensional, multi-level real-time statistical results, including: The external query request is parsed and parameters are extracted to obtain the external entity type parameters. Based on the external entity type parameters, the target dynamic condition splicing fragment is obtained from the preset mapping rule library. Based on the target dynamic condition splicing fragments, and combined with the time range condition, the routing target of the external query request is determined, and the routing determination result is obtained; By combining external entity type parameters, target dynamic condition splicing fragments, and routing determination results, cross-dimensional correlation statistical results are dynamically spliced ​​and queried to obtain query results. Based on the deviation rate between the query results and historical baseline data, abnormal state identification is performed to obtain two-dimensional, multi-level real-time statistical results.

[0078] In this optional embodiment, the external entity type parameters, target dynamic condition splicing fragments, and routing determination results are combined to dynamically splice and query the cross-dimensional correlation statistical results, obtaining query results. Based on the deviation rate between the query results and historical baseline data, abnormal state identification is performed, resulting in two-dimensional, multi-level real-time statistical results, including: Based on the external entity type parameters and target dynamic conditions, the cross-dimensional correlation statistical results are dynamically structured and processed to generate a query statement. The query statement is used to query the target data source indicated by the routing determination result to obtain the query result after filtering by entity dimension. Based on the query results, the historical statistical average of the same entity identifier within a preset historical time period is queried from the historical statistical records of the unified dimension folded storage table, and the historical statistical average is used as the historical baseline data. The deviation rate is calculated based on the current statistical values ​​in the query results and the historical baseline data. The query results are then marked as abnormal based on the preset anomaly detection threshold to obtain real-time statistical results in two dimensions and multiple levels.

[0079] It should be noted that external query requests are statistical data query instructions initiated by front-end applications or third-party systems, containing parameters such as time range, dimension granularity, and entity type; the preset mapping rule base stores a set of configurations that correspond to the query parameters and the underlying data source, table name, and field name, such as routing rules for real-time 5-minute queries to the in-memory database, historical summary queries to relational database unified dimension folded storage tables, and device detail queries to the device-side interface; the time range condition is the start and end time specified in the query request, which is used to determine data freshness and trigger data source routing; the routing determination result is the target data source identifier and corresponding query execution strategy output after matching the time range condition with the preset mapping rule base; the target dynamic condition concatenation fragment is an SQL WHERE clause or in-memory database query filter automatically generated based on the routing determination result, such as "merchant identifier = -1 AND Company identifier = -1” is used for cross-platform queries; real-time statistical query results are incremental statistical values ​​within the last 5 minutes; the target data source indicated by the routing determination result includes: one or a combination of in-memory database, relational database, and device-side reporting interface; the historical statistical records of the unified dimension folded storage table are persistent multidimensional statistical data rows older than 5 minutes; the deviation rate is the percentage difference between the real-time statistical query results and the historical statistical records of the unified dimension folded storage table under the same dimension key, which is used to verify data consistency; the preset anomaly judgment threshold is when the deviation rate exceeds... This refers to the threshold value that determines data synchronization anomalies and triggers alarms or compensation mechanisms; the dual-dimensional, multi-level real-time statistical results can simultaneously cover order and revenue dimensions, and support real-time comprehensive statistical output with five levels of granularity: platform / merchant / company / province / site, after cross-pipeline mapping and aggregation processing.

[0080] During queries, the system dynamically constructs WHERE conditions based on entity type parameters, enabling independent queries across five operational levels—platform, province / region, company, merchant, and site—using the same table structure. The specific steps for dynamically constructing WHERE conditions are as follows: Step 1: Construct the basic WHERE condition. All queries should use date range filtering as the basic condition, in the format "WHERE Statistical Date ≥ @Start Date AND Statistical Date ≤ @End Date", ensuring that the query is limited to the specified time window.

[0081] Step 2: Dynamically add entity filtering conditions based on the entity type parameter. The system defines the mapping relationship between the entity type parameter and the WHERE condition fragment as follows: When the entity type parameter value is 1, i.e., merchant dimension, add "AND Merchant ID=@Entity ID"; when the entity type parameter value is 2, i.e., company dimension, add "AND Company ID=@Entity ID"; when the entity type parameter value is 3, i.e., site dimension, add "AND Site ID=@Entity ID"; when the entity type parameter value is 4, i.e., province dimension, add "AND Province ID=@Entity ID"; when the entity type parameter is not passed or is empty, i.e., the entire platform, no entity condition is added, or "AND Merchant ID=-1 AND Company ID=-1" is added to only obtain the entire platform summary row.

[0082] Step 3: Concatenate the statements to generate a complete SQL statement. Taking the query of daily order details for merchant 1001 from January 1st to January 7th, 2024 as an example, the query object is the daily equipment statistics summary table. The data in this table comes from the cross-database synchronization step at the small disk level. The system receives the parameters "Entity type=1, Entity identifier=1001, Start date=2024-01-01, End date=2024-01-07". After dynamically adding entity filtering conditions, the system maps to obtain the appended condition fragment "AND Merchant identifier=1001". This is concatenated with the basic condition in step one to form the complete WHERE clause: "WHERE Statistics date≥'2024-01-01' AND Statistics date≤'2024-01-07' AND Merchant identifier=1001". Finally, the complete SQL statement is generated: "SELECT Statistics date, Merchant identifier, Company identifier, Site identifier, Province identifier, City identifier, Total number of orders FROM Daily Equipment Statistics Summary Table WHERE Statistics date≥'2024-01-01' AND "Statistics Date ≤ '2024-01-07' AND Merchant ID = 1001 ORDER BY Statistics Date DESC, Total Orders DESC".

[0083] Step 4: This dynamic splicing mode is reused uniformly in all the following query methods: Operational efficiency query, i.e., "AND Merchant ID=@Entity ID" or "AND Company ID=@Entity ID"; Scenario proportion query is the same as the above query; Time-segmented order statistics query, i.e., "AND Merchant ID=@Entity ID AND Company ID=-1"; Operational overview query, i.e., "AND Device Group.Merchant ID=@Entity ID" or "AND Device Group.Company ID=@Entity ID"; Daily revenue details query, i.e., the splicing rules are the same as those for daily order details query.

[0084] The system compares data using historical baselines. It queries the merchant's average daily order volume and average daily revenue over the past seven days from the database aggregation table as the historical baseline: `SELECT AVG(Total Orders) AS Average Daily Orders, AVG(Revenue Amount) AS Average Daily Revenue FROM Daily Device Statistics Summary Table WHERE Merchant Identifier = @Merchant Identifier AND Statistics Date ≥ @Seven Days Ago AND Statistics Date < @Today`. Simultaneously, it calculates... .

[0085] The above cross-pipeline association analysis relies on four unified elements shared by the two pipelines: (1) Shared entity type parameters, namely the entity types of the order pipeline, where 1=company, 2=site, and 3=merchant; the entity type values ​​are completely consistent with those in the three-segment coding of the revenue pipeline, ensuring that no additional type conversion is required when locating the same entity across pipelines; (2) Shared key naming system, namely the order pipeline key prefix is ​​“order:dashboard:”, the revenue pipeline key prefix is ​​“revenue:dashboard:”, and the date format is unified as an eight-digit number of year, month, and day, so that the data of the two pipelines of the same entity can be located through the same date; (3) Shared data access layer, namely the two pipelines reuse the same data access instance, avoiding the overhead of cross-connection queries; (4) Shared entity identifier, namely the identifier of the same entity in the two pipelines is completely consistent. For example, merchant 1001 uses the same merchant identifier 1001 in the order pipeline key “order:dashboard:merchant:{date}:1001” and the revenue pipeline field “{revenue type}:3:1001”, so that no additional entity mapping table is required for association analysis.

[0086] Figure 2 An embodiment of a multi-level, real-time statistical system for orders and revenue based on the present invention is shown.

[0087] In this optional embodiment, the order and revenue dual-dimensional multi-level real-time statistics system includes: The incremental statistics module 201 is used to incrementally write the received business event data generated by the operation of the smart terminal to the memory database in a bypass asynchronous writing mode to obtain a real-time incremental statistics event stream. The multi-level aggregation module 202 is used to perform real-time memory statistics on real-time incremental statistical event streams based on multiple types of collaborative data structures, and obtain a multi-level aggregated statistical result set. The folding mapping module 203 is used to perform idempotent persistent writing of the multi-level aggregated statistical result set according to the preset timed data storage rules, to obtain the multi-level persistent statistical data set, and to fold and map the multi-level persistent statistical data set to the relational data table in combination with the dimension placeholder identification mechanism, thereby generating a unified dimension folding storage table. The cross-pipeline association module 204 is used to perform hierarchical consistency data source aggregation on the unified dimension folded storage table based on the multi-layer data source collaboration strategy, to obtain a multi-source statistical data set, and to perform cross-pipeline association calculation on the multi-source statistical data set to obtain cross-dimensional association statistical results. The dynamic condition concatenation query module 205 is used to perform dynamic condition concatenation queries on cross-dimensional correlation statistical results based on the external entity type parameters in the external query request, and to perform anomaly detection on the query results in combination with historical baseline data, so as to obtain real-time statistical results of two dimensions and multiple levels.

[0088] In summary, this invention decomposes the problem of smart terminal operation statistics into three sub-problems: aggregation, sorting, and lifecycle. These sub-problems are mapped to different data structures in an in-memory database. Through a unified event-driven mechanism and key space model, multiple data structures can form a synergy at the statistical semantic level, i.e., multiple collaborative data structures, rather than being used independently as storage tools.

[0089] Based on this, the present invention achieves complete decoupling of statistics and business through business event bypass writing, completes real-time incremental statistics by using problem-oriented collaborative design of multiple data structures in memory database, achieves single-table support for all levels by using a unified data model with placeholder semantics, and achieves seamless connection between global summary, device details and real-time ranking through a three-layer data source collaborative architecture of large disk and full platform database, small disk and tenant database, and today's ranking and memory ordered set.

[0090] like Figure 4 As shown, the business service performs Layer 1 real-time writes at the second level, through... The process involves order reversal, IncrIncome (amount) revenue writing, and SAdd / SRem maintenance of the online terminal map. Data is written to Redis, and the synchronization service performs a two-layer, five-minute scheduled synchronization. First, it acquires the distributed lock Realtime:Lock, calls HGetAll / ZRevRange to read Redis data, and uses INSERT ON DUPLICATE KEY UPDATE to write it to MySQL. This data is then aggregated to obtain daily and hourly summaries. The synchronization service then performs a three-layer, daily 00:05 backup process, acquiring the distributed lock DailyFull:Lock to complete yesterday's full synchronization and dual-pipeline aggregation. Next, a four-layer monthly summary is executed at 02:00 on the 1st of each month, aggregating last month's revenue and writing it to the monthly summary. The query layer uses a dual-engine architecture for the operations dashboard. Today's overview and ranking data are obtained from Redis via HGetAll, while historical data such as order trends and hourly trends are queried from MySQL via SELECT. Simultaneously, data not yet written to the database today is rolled back and supplemented, completing the data flow of the entire statistical chain.

[0091] This invention is not limited to the structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this invention is limited only by the appended claims.

Claims

1. A multi-level, real-time statistical method for orders and revenue, characterized in that, include: For the business event data generated by the operation of the received smart terminal, an incremental statistical write is performed to the memory database using a bypass asynchronous write mode to obtain a real-time incremental statistical event stream. Real-time in-memory statistics are performed on real-time incremental statistical event streams based on multiple types of collaborative data structures to obtain multi-level aggregated statistical result sets. According to the preset timed data storage rules, the multi-level aggregated statistical result set is written idempotently to obtain the multi-level persistent statistical data set. Then, combined with the dimension placeholder identification mechanism, the multi-level persistent statistical data set is folded and mapped to the relational data table to generate a unified dimension folded storage table. Based on a multi-layer data source collaboration strategy, a hierarchical consistency data source aggregation is performed on the unified dimension folded storage table to obtain a multi-source statistical data set. Cross-pipeline association calculations are then performed on the multi-source statistical data set to obtain cross-dimensional association statistical results. Based on the external entity type parameter in the external query request, dynamic condition concatenation query is performed on the cross-dimensional correlation statistical results, and anomaly detection is performed on the query results in combination with historical baseline data to obtain real-time statistical results of two dimensions and multiple levels.

2. The real-time statistical method for dual-dimensional and multi-level statistics of orders and revenue according to claim 1, characterized in that, The received business event data generated by the operation of the smart terminal is incrementally written to the memory database using a bypass asynchronous write mode to obtain a real-time incremental statistical event stream, including: Event monitoring and capture processing is performed on the smart terminal operation business link to obtain business event data, and the business event data is classified based on event type identifier to obtain a classified business event set; Based on the event type identifier, the incremental direction and write operation type are mapped to the categorized business event set to obtain the incremental statistical operation instruction set; Based on the bypass asynchronous method, the incremental statistics operation instruction set is submitted to the in-memory database in batches through concurrent tasks for atomic incremental operations, resulting in a real-time incremental statistics event stream.

3. The real-time statistical method for dual-dimensional and multi-level statistics of orders and revenue according to claim 1, characterized in that, The method of performing real-time memory statistics on real-time incremental statistical event streams based on multi-class collaborative data structures to obtain a multi-level aggregated statistical result set includes: Each incremental statistical event in the real-time incremental statistical event stream is parsed and normalized to obtain a set of statistical dimension attributes. The entity type parameters in the set of statistical dimension attributes are then format-validated and standardized to obtain standardized incremental statistical events. Based on the set of statistical dimension attributes and combined with the multi-type collaborative data structure of the in-memory database, the standardized incremental statistical events are atomically incrementally written and key-level validity period configured within the same concurrent batch to obtain the updated multidimensional statistical data. The updated multidimensional statistical data is fully scanned and structured and merged according to the preset time trigger conditions to obtain a multi-level aggregated statistical result set.

4. The real-time statistical method for dual-dimensional and multi-level statistics of orders and revenue according to claim 1, characterized in that, The process of writing multi-level aggregated statistical result sets to a multi-level persistent statistical data set according to preset timed data storage rules, and then folding and mapping the multi-level persistent statistical data set to a relational data table using a dimension placeholder identification mechanism to generate a unified dimension folding storage table includes: Based on the preset timed data entry rules, the multi-level aggregated statistical result set is scanned and traversed to obtain the aggregation keys of each dimension. The aggregation keys of each dimension are then parsed and dimension identifiers are extracted and encapsulated into a multi-level statistical data set. The multi-level statistical data set is written row by row into the basic detail table of the relational database using idempotent persistence write rules to obtain the multi-level statistical data table. The database unique index is then used to perform conflict detection and overwrite update processing on the duplicate write records in the multi-level statistical data table to obtain the multi-level persistent statistical data set. According to the preset placeholder mapping rules, the entity identifier field of the multi-level persistent statistical data set is filled with the target dimension placeholder value to obtain the multi-dimensional statistical record dataset. Then, according to the entity type parameter, the multi-dimensional statistical record dataset is folded into the target record row of the same relational data table to generate a unified dimension folded storage table.

5. The real-time statistical method for dual-dimensional and multi-level statistics of orders and revenue according to claim 1, characterized in that, The multi-layer data source collaboration strategy involves hierarchically and consistently aggregating the unified-dimensional folded storage table to obtain a multi-source statistical data set. Cross-pipeline correlation calculations are then performed on this multi-source statistical data set to obtain cross-dimensional correlation statistical results, including: Based on the hierarchical consistency rules in the multi-layer data source collaboration strategy, data source routing determination and hierarchical parallel reading processing are performed on the unified dimension folded storage table to obtain a hierarchical statistical subset. Based on the entity type parameter, the hierarchical statistical subsets are associated, merged, and time-aligned to obtain a multi-source statistical data set; Alignment processing is performed on the multi-dimensional statistical values ​​in the multi-source statistical data set to obtain a dual-pipeline statistical data set. Cross-pipeline aggregation and derived index calculation processing are then performed on the dual-pipeline statistical data set to obtain cross-dimensional correlation statistical results.

6. The real-time statistical method for dual-dimensional and multi-level statistics of orders and revenue according to claim 5, characterized in that, The process of performing data source routing determination and hierarchical parallel reading on the unified dimension folded storage table according to the hierarchical consistency rules in the multi-layer data source collaboration strategy yields a hierarchical statistical subset, including: Perform data source routing determination on the unified dimension folded storage table, and combine the date partition field and entity type parameter in the unified dimension folded storage table to determine the data source routing mapping relationship of each statistical record; Based on the first routing path in the data source routing mapping relationship, perform an ordered set reverse range query on the real-time ranking layer to obtain real-time sorted snapshot data, and perform entity identifier association verification on the sorted snapshot data to obtain the first real-time statistical subset; Based on the second routing path in the data source routing mapping relationship, daily and hourly summary data are read from the global summary dashboard layer to obtain summary data. The summary data is then subjected to data integrity verification and missing data marking to obtain the second historical summary subset. Based on the third routing path in the data source routing mapping relationship, the device-level daily statistical details are read from the device detail disk layer to obtain the daily statistical details data. The field integrity is checked and outlier filtering is performed on the daily statistical details data to obtain the third device detail subset. The first real-time statistics subset, the second historical summary subset, and the third equipment details subset are integrated to obtain a hierarchical statistics subset.

7. The real-time statistical method for dual-dimensional and multi-level statistics of orders and revenue according to claim 5, characterized in that, The process of aligning multi-dimensional statistical values ​​from the multi-source statistical data set yields a dual-pipeline statistical data set. Cross-pipeline aggregation and derived index calculation are then performed on this dual-pipeline statistical data set to obtain cross-dimensional correlation statistical results, including: Based on the entity type parameters and entity identifiers of each statistical record in the multi-source statistical data set, extract the order dimension statistical values ​​and revenue dimension statistical values ​​belonging to the same entity identifier from the multi-source statistical data set; The statistical values ​​of the order dimension and the revenue dimension are aligned with the entity identifier according to a unified key naming system to obtain a dual-pipeline statistical data set after entity dimension alignment; Based on the symmetrical order and revenue statistics pipelines, the system reads the order and revenue statistics indicators under each entity identifier for the dual-pipeline statistical data set. It then performs cross-pipeline mapping and aggregation processing on the order and revenue statistics indicators belonging to the same entity identifier. Based on the mapping and aggregation results, it calculates derived indicators to obtain cross-dimensional correlation statistics results.

8. The real-time statistical method for dual-dimensional and multi-level statistics of orders and revenue according to claim 1, characterized in that, The process of dynamically concatenating conditions for cross-dimensional correlation statistical results based on external entity type parameters in external query requests, and combining historical baseline data to perform anomaly detection on the query results, yields two-dimensional, multi-level real-time statistical results, including: The external query request is parsed and parameters are extracted to obtain the external entity type parameters. Based on the external entity type parameters, the target dynamic condition splicing fragment is obtained from the preset mapping rule library. Based on the target dynamic condition splicing fragments, and combined with the time range condition, the routing target of the external query request is determined, and the routing determination result is obtained; By combining external entity type parameters, target dynamic condition splicing fragments, and routing determination results, cross-dimensional correlation statistical results are dynamically spliced ​​and queried to obtain query results. Based on the deviation rate between the query results and historical baseline data, abnormal state identification is performed to obtain two-dimensional, multi-level real-time statistical results.

9. The real-time statistical method for dual-dimensional and multi-level statistics of orders and revenue according to claim 8, characterized in that, The process of combining external entity type parameters, target dynamic condition splicing fragments, and routing determination results to dynamically splice and query cross-dimensional correlation statistical results yields query results. Based on the deviation rate between the query results and historical baseline data, anomaly identification is performed, resulting in dual-dimensional, multi-level real-time statistical results, including: Based on the external entity type parameters and target dynamic conditions, the cross-dimensional correlation statistical results are dynamically structured and processed to generate a query statement. The query statement is used to query the target data source indicated by the routing determination result to obtain the query result after filtering by entity dimension. Based on the query results, the historical statistical average of the same entity identifier within a preset historical time period is queried from the historical statistical records of the unified dimension folded storage table, and the historical statistical average is used as the historical baseline data. The deviation rate is calculated based on the current statistical values ​​in the query results and the historical baseline data. The query results are then marked as abnormal based on the preset anomaly detection threshold to obtain real-time statistical results in two dimensions and multiple levels.

10. A multi-level, real-time statistical system for orders and revenue, characterized in that, The system includes: The incremental statistics module is used to incrementally write the received business event data generated by the operation of smart terminals to the memory database in a bypass asynchronous write mode to obtain a real-time incremental statistics event stream. The multi-level aggregation module is used to perform real-time in-memory statistics on real-time incremental statistical event streams based on multiple types of collaborative data structures, and obtain a multi-level aggregated statistical result set. The folding mapping module is used to perform idempotent persistent writing of multi-level aggregated statistical result sets according to preset timed data storage rules, obtain multi-level persistent statistical data sets, and combine the dimension placeholder identification mechanism to fold and map the multi-level persistent statistical data sets to relational data tables, generating a unified dimension folding storage table. The cross-pipeline association module is used to perform hierarchical consistency data aggregation on a unified dimension folded storage table based on a multi-layer data source collaboration strategy, to obtain a multi-source statistical data set, and to perform cross-pipeline association calculations on the multi-source statistical data set to obtain cross-dimensional association statistical results. The dynamic condition concatenation query module is used to perform dynamic condition concatenation queries on cross-dimensional correlation statistical results based on the external entity type parameters in the external query request, and to perform anomaly detection on the query results in combination with historical baseline data, so as to obtain real-time statistical results with two dimensions and multiple levels.

Images