A test data processing method and device, a storage medium and an electronic device

Abstract

The specification discloses a test data processing method and device, a storage medium and an electronic equipment, wherein the method comprises: performing shunt collection on business data of experimental test type, synchronizing full-amount inventory data to an offline storage engine, collecting incremental real-time data to a message middleware, based on global unified test index metadata, outputting first-time offline index data through batch processing engine on full-amount data, outputting second-time real-time index data through stream processing engine on incremental data; writing two types of index data into heterogeneous partitions of an online query engine respectively; and performing cross-partition data aggregation in the online query engine in response to cross-time-effect observation request, and outputting real-time evaluation index. The embodiment of the specification realizes quasi-real-time and high-consistency observation of massive test experiment indexes.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a test data processing method, apparatus, storage medium, and electronic device. Background Technology

[0002] With the rapid development of internet platform transactions, conducting experimental testing (such as A / B testing) for corresponding internet products and services has become a core means of validating product and service strategies and driving business service decisions. In relevant testing platforms, efficiently and accurately collecting experimental indicator data quickly is a crucial step in evaluating internet products and services, affecting the timely discovery of problems in service solutions and providing timely guidance on traffic switching directions.

[0003] In related technologies, the common approach is to directly write the experimental hit data into an online relational database and calculate real-time metrics by constructing SQL queries. However, this processing architecture is only suitable for small-scale data volumes. As the scale of business data increases dramatically, the time complexity of this calculation and query method will explode, easily affecting the normal operation of online platform services. Furthermore, in the platform's complex distributed business architecture, once the experimental process introduces database sharding and table partitioning, or if the various metric data are distributed across multiple microservice systems, the traditional metric retrieval scheme based on join queries in a single relational database will become completely ineffective.

[0004] To cope with the massive data volume of metric collection and reduce the impact on online production databases, some traditional experimental testing platforms often employ offline batch processing after periodic data collection for metric calculation. However, this approach has extremely low timeliness, with metric data output typically experiencing delays of several hours or even days. The lag and uncontrollability of metric refresh time intervals severely hinder the platform's real-time perception of the overall performance of the experimental tests. Summary of the Invention

[0005] This specification provides a test data processing method, apparatus, storage medium, and electronic device, which can efficiently, accurately, and quickly retrieve test experimental index data, achieving near real-time and highly consistent observation of massive test experimental indexes. The technical solution is as follows: Firstly, this specification provides a test data processing method, the method comprising: For experimental and test-type business data in the business system, perform split collection, synchronize all existing data to the offline data storage engine, and collect incremental real-time data to the message middleware; Based on globally unified test indicator metadata, the batch processing link engine aggregates and calculates the full amount of existing data in the offline data storage engine to produce offline indicator data with the first timeliness. The stream processing link engine consumes the incremental real-time data in the message middleware and performs streaming state aggregation and calculation to produce real-time indicator data with the second timeliness. The offline indicator data and real-time indicator data are written into the heterogeneous partition of the online query analysis and processing engine, respectively. In response to a cross-time observation request for the target test experiment, the online query analysis and processing engine performs cross-partition data aggregation on the offline indicator data and the real-time indicator data, and outputs a real-time evaluation indicator for the target test experiment.

[0006] Secondly, this specification provides a test data processing apparatus, the apparatus comprising: The traffic splitting and acquisition module is used to perform traffic splitting and acquisition of experimental and test business data in the business system, synchronize all existing data to the offline data storage engine, and collect incremental real-time data to the message middleware. The aggregation calculation module is used to aggregate and calculate the full amount of existing data in the offline data storage engine based on globally unified test indicator metadata, and to produce offline indicator data with the first timeliness through the batch processing link engine, and to consume incremental real-time data in the message middleware through the stream processing link engine to perform streaming state aggregation and calculation to produce real-time indicator data with the second timeliness. The data writing module is used to write the offline indicator data and the real-time indicator data into the heterogeneous partition of the online query analysis and processing engine, respectively. The indicator calculation module is used to respond to cross-time observation requests for the target test experiment by performing cross-partition data aggregation on the offline indicator data and the real-time indicator data in the online query analysis and processing engine, and outputting real-time evaluation indicators for the target test experiment.

[0007] Thirdly, this specification provides a computer storage medium storing at least one instruction adapted for loading by a processor and executing method steps of one or more embodiments of this specification.

[0008] Fourthly, this specification provides a computer program product storing at least one instruction adapted to be loaded by a processor and to execute the method steps of one or more embodiments of this specification.

[0009] Fifthly, this specification provides an electronic device that may include: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the method steps of one or more embodiments of this specification.

[0010] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following: In one or more embodiments of this specification, by performing split collection on existing and incremental test business data, and independently calculating based on globally unified test indicator metadata using a dual-track link of batch processing and stream processing, the generated offline and real-time indicators are written into heterogeneous partitions of the online query analysis and processing engine. Finally, in response to cross-time-sensitive observation requests, cross-partition data aggregation is performed at the engine's underlying layer. This effectively overcomes the computational performance bottleneck faced by large-scale data join queries in traditional test platforms, the extremely low timeliness of a single offline batch processing architecture, and the technical defects such as inconsistencies in indicator definitions and data tearing at the intersection of stream and batch processes that are easily caused by conventional stream-batch separation architectures. Thus, while avoiding the high-cost backtracking of full detailed data, it achieves efficient, accurate, and near-real-time collection of massive experimental indicator data. This not only ensures the consistency and alignment of real-time evaluation indicators that integrate long-cycle historical baseline data and the latest dynamic data in mathematical logic, improving the platform's throughput stability in the face of high-volume concurrent queries, but also enables the business side to perceive the overall performance of the experiment with zero latency. This provides data support for business processes such as quickly identifying product service solution problems, timely guiding the direction of flow switching, and decisively shutting down inferior experiments. Attached Figure Description

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

[0012] Figure 1 This is a schematic diagram of a test data processing system provided in this manual; Figure 2 This is a flowchart illustrating a test data processing method provided in this manual; Figure 3 This is an example scenario architecture diagram corresponding to the test data processing method provided in this manual; Figure 4 This is a schematic diagram of a streaming state aggregation calculation process provided in this manual; Figure 5 This is a schematic diagram of a data synchronization process provided in this manual; Figure 6 This is a schematic diagram of the structure of a test data processing device provided in this specification; Figure 7 This is a schematic diagram of the structure of an electronic device provided in this specification. Detailed Implementation

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

[0014] In the description of this specification, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. In the description of this specification, it should be noted that, unless otherwise expressly specified and limited, "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. Those skilled in the art can understand the specific meaning of the above terms in this specification based on the specific circumstances. Furthermore, in the description of this specification, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0015] The present specification will now be described in detail with reference to specific embodiments.

[0016] Please see Figure 1 This is a schematic diagram of a test data processing system provided in this specification. Figure 1 As shown, the test data processing system may include at least a client cluster and a service platform 100.

[0017] The client cluster may include at least one client, such as Figure 1 As shown, it specifically includes client 1 corresponding to user 1, client 2 corresponding to user 2, ..., client n corresponding to user n, where n is an integer greater than 0.

[0018] Each client in a client cluster can be an electronic device with communication capabilities, including but not limited to: wearable devices, handheld devices, personal computers, tablets, in-vehicle devices, smartphones, computing devices, or other processing devices connected to a wireless modem. Electronic devices may have different names in different networks, such as: user equipment, access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, electronic device, wireless communication device, user agent or user device, cellular phone, cordless phone, personal digital assistant (PDA), and electronic devices in 5G networks or future evolved networks.

[0019] The service platform 100 can be a standalone server device, such as a rack-mount, blade, tower, or cabinet-type server device, or a workstation, mainframe, or other hardware device with strong computing power; or it can be a server cluster composed of multiple servers. The servers in the service cluster can be composed in a symmetrical manner, wherein each server is functionally and hierarchically equivalent in the transaction chain, and each server can provide services independently. The independent provision of services can be understood as not requiring the assistance of other servers.

[0020] In one or more embodiments of this specification, the service platform 100 can establish a communication connection with the client corresponding to at least one user in the client cluster, and complete the data interaction during the test data processing based on the communication connection. The test data processing method provided in the embodiments of this specification can be widely applied to large-scale experimental platforms (such as data middleware systems of e-commerce platforms and short video platforms) under high-concurrency Internet services.

[0021] It should be noted that the service platform 100 establishes a communication connection with at least one client in the client cluster via a network for interactive communication. This network can be a wireless network or a wired network. Wireless networks include, but are not limited to, cellular networks, wireless LANs, infrared networks, or Bluetooth networks. Wired networks include, but are not limited to, Ethernet, Universal Serial Bus, or Controller Area Networks. In one or more embodiments of the specification, technologies and / or formats including Hypertext Markup Language (HTML), Extensible Markup Language (XML), etc., are used to represent data exchanged over the network (such as target compressed packets). Furthermore, conventional encryption technologies such as Secure Sockets Layer (SSL), Transport Layer Security (TLS), Virtual Private Networks (VPNs), and Internet Protocol (IP) security can be used to encrypt all or some links. In other embodiments, customized and / or dedicated data communication technologies can be used to replace or supplement the aforementioned data communication technologies.

[0022] The test data processing system embodiments provided in this specification and the test data processing methods described in one or more embodiments belong to the same concept. The execution entity corresponding to the test data processing method involved in one or more embodiments in this specification can be the aforementioned service platform 100; the execution entity corresponding to the test data processing method involved in one or more embodiments in this specification can also be the electronic device corresponding to the client, specifically determined based on the actual application environment. The implementation process of the test data processing system embodiments can be detailed in the following method embodiments, and will not be repeated here.

[0023] based on Figure 1 The following is a detailed description of the test data processing methods provided by one or more embodiments of this specification, as illustrated in the schematic diagram of the scenario.

[0024] Please see Figure 2 This specification provides a flowchart illustrating a test data processing method according to one or more embodiments. This method can be implemented using a computer program and can run on a test data processing device based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone utility application. The test data processing device can be a service platform.

[0025] Specifically, the test data processing method includes: S102: Perform traffic splitting and collection on experimental and test-type business data in the business system, synchronize all existing data to the offline data storage engine, and collect incremental real-time data to the message middleware; Full-volume stock data refers to historical business data that was generated and persistently stored before a specific time point. This type of data is typically massive in scale, with lower requirements for processing timeliness, but extremely high requirements for computational integrity.

[0026] Incremental real-time data refers to dynamic data that is continuously generated after a specific time segment, reflecting the latest business changes as the business system continues to operate. This type of data has extremely high timeliness value and is usually produced in a streaming, small-scale, high-frequency format.

[0027] Offline data storage engines refer to storage media or database systems that support low-cost persistence of massive amounts of data and are suitable for large-scale batch processing operations, such as the distributed file system HDFS, object storage OSS, and data warehouse Hive.

[0028] Message middleware refers to middleware software used in distributed systems to implement asynchronous communication, traffic shaping, and decoupling. In this solution, it is used to buffer and transmit real-time streaming data, such as Kafka, RocketMQ, or Pulsar.

[0029] To illustrate, a unified timeframe (e.g., midnight each day) is defined in the business system as the baseline for data splitting and synchronization. For historical data generated before this timeframe (i.e., data from T-1 day and earlier), the acquisition module uses full table scans or snapshot mirroring technology to fully read the historical test data stored in the business database. It then uses batch data synchronization tools (such as DataX) to synchronize this data in one go or in batches to an offline data storage engine (such as a distributed file system or data warehouse) to lay the foundation for historical background data, thus completing the acquisition of all existing data. Simultaneously, for data generated after this timeframe, a Change Data Capture (CDC) mechanism is enabled in the business database to monitor the underlying change logs (such as redo logs and Binlogs) in real time. When the business system generates new experimental test records, the acquisition service immediately parses the log content and transforms the changed data into a standard message carrier, continuously and with low latency pushing it to a specific topic queue in the message middleware, thereby achieving seamless splitting of incremental real-time data and all existing data on the physical link.

[0030] For example, such as Figure 3 As shown, Figure 3 This is an example scenario architecture diagram corresponding to the test data processing methods involved in this specification. Figure 3 In the middle, the test data processing method relies on the layered architectural thinking. The content on the far right is the globally unified test indicator metadata in S104, such as including but not limited to the schema definition of the data model, the definition of basic experimental information, the metadata of indicator information, and the common task scheduling. This part of the content is the basic information that all experimental platforms have.

[0031] exist Figure 3 The business layer in the example scenario architecture shown: This layer mainly focuses on different business domains in the business system. During the experiment for a certain business, business data will be continuously generated. This business data is usually distributed in business logs and business databases. Execute S102 to perform diversion and collection of business data of the experimental test class in the business system. exist Figure 3 The example scenario architecture illustrates the storage layer: In the batch processing platform, all existing data is synchronized to the offline data storage engine in the storage layer (such as...). Figure 3The large-scale data storage engine shown typically has a time-to-delivery (T) timeframe. This embodiment introduces a unified stream and batch real-time metric calculation capability. Therefore, while maintaining the original capabilities, a message middleware storage engine is added, and incremental real-time data is collected to the message middleware. For example, asynchronous subscription to binlogs is used to asynchronously and near-real-time collect experimental data. By combining the message middleware with an offline data storage engine, the data storage cost of the large-scale data storage engine and the real-time data forwarding capability of the message middleware are combined. The core objective of this business layer is to retain all experimental data that needs to be observed for subsequent metric data retrieval.

[0032] S104: Based on globally unified test indicator metadata, the batch processing link engine aggregates and calculates the full amount of existing data in the offline data storage engine to produce offline indicator data with the first timeliness, and consumes incremental real-time data in the message middleware through the stream processing link engine to perform streaming state aggregation and calculation to produce real-time indicator data with the second timeliness. Globally unified test metric metadata refers to standardized descriptive data used throughout the entire data processing system to uniformly define the calculation logic, data dimensions, statistical calibers, and business rules of test metrics. It is a shared metric dependency between stream processing and batch processing, ensuring mathematical equivalence in test logic when heterogeneous computing engines process the same metric.

[0033] A batch processing engine refers to a distributed computing framework used to process large-scale, non-continuous, static datasets. Its characteristics include high throughput and the ability to perform full reprocessing or in-depth mining of historical data. (See reference...) Figure 3 The batch processing part of the indicators shown in the middle calculation layer, for the full stock data of T-1, can perform batch processing calculations by combining the indicator caliber of the predefined test indicator metadata, and write the calculation results into the result table in the result layer.

[0034] A stream processing pipeline engine refers to a distributed computing framework used to consume continuous data streams in real time and maintain intermediate computational states in memory. Its characteristics include extremely low data triggering latency and the ability to update computation results in real time as data flows in. (See reference...) Figure 3 The middle computing layer shows the batch processing part of the indicators, while for the incremental real-time data of day T, the real-time computing engine (such as Flink) performs streaming computing according to the preset operators, and periodically writes the current streaming computing results into the online query engine of the result layer.

[0035] First-timeliness / second-timeliness refers to the time period from data generation to its calculation as an observable indicator. First-timeliness typically corresponds to days (T-1 days or TH hours) on the offline side; second-timeliness typically corresponds to seconds or minutes (near real-time within T) on the streaming side.

[0036] To illustrate, global test metric metadata is loaded from a unified configuration center and mapped to offline computing tasks (such as SparkSQL) recognizable by the batch processing engine and real-time computing tasks (such as FlinkSQL) recognizable by the stream processing engine. The batch processing engine, triggered by a scheduling cycle, reads all existing data from the offline storage engine, performs deep aggregation according to the statistical criteria defined by the metadata, and produces first-time offline metric data covering a long historical period, which is periodically overwritten or appended to the result database. Simultaneously, the stream processing engine remains resident, subscribing to incremental real-time data streams from the message middleware, and maintaining the current period's metric median value in the in-memory state according to the same metadata definition. As each new data point passes through, the stream processing engine performs incremental streaming state aggregation calculations, instantly producing second-time real-time metric data reflecting the latest business changes. In this way, although the two engines are different, their computational logic is strongly aligned under the constraints of the metadata, thus eliminating the caliber discrepancy between batch and stream computations, and obtaining the cumulative result for T-1 days and the incremental result for day T.

[0037] Alternatively, you can also refer to the following methods: Step S2: In the common dependency area corresponding to the batch processing link engine and the stream processing link engine, centrally maintain globally unified test indicator metadata, including test data model constraint specifications and target indicator calculation methods. In a complex distributed heterogeneous computing system, a common dependency area refers to a centralized component or service module, independent of individual execution engines (such as streaming engines and batch engines), specifically designed for the unified definition, storage, and distribution of shared rules and configuration items. (See also: [example of a common dependency area]). Figure 3 The rightmost content shown corresponds to the common dependency area.

[0038] Test data model constraint specifications refer to the underlying structural requirements for test data input into the computing engine, such as specifying the field names of data tables, data type definitions, primary key index rules, and whether null values ​​are allowed, to ensure that the data entering the batch and stream processing tracks is consistent in format.

[0039] The calculation caliber of the target metric refers to the mathematical calculation logic and filtering conditions defined at the business level for a specific evaluation metric. For example, it specifies the value fields of the numerator and denominator, the deduplication logic (such as deduplication based on device ID or user ID), and the specific time window boundaries.

[0040] As an example, R&D and business personnel can use the test maintenance terminal to transform abstract test requirements into structured test data model constraints (such as JSON Schema format) and target indicator calculation methods (such as unified abstract syntax trees or domain-specific languages ​​DSL) through a unified visual indicator management platform, and persistently store them in a highly available configuration center database to achieve centralized maintenance of globally unified test indicator metadata.

[0041] Step S4: Synchronously load the test indicator metadata into the batch processing link engine and the stream processing link engine to execute the steps in S104 described above: the batch processing link engine aggregates and calculates the full amount of existing data in the offline data storage engine to produce offline indicator data with the first time limit, and the stream processing link engine consumes the incremental real-time data in the message middleware to perform streaming state aggregation and calculation to produce real-time indicator data with the second time limit.

[0042] As an illustration, when the computational coordination node controlling the batch processing link engine and the stream processing link engine starts up or is checked periodically, the client initiates a subscription to the configuration center via Remote Procedure Call (RPC). The control configuration center then distributes the latest version of the test metric metadata and synchronously loads it into the memory of both link engines, and then executes S104.

[0043] In this specification, the common dependency area and metadata synchronous loading mechanism in steps S2-S4 is adopted to achieve deep decoupling between the test data processing logic and the underlying heterogeneous computing engine. Specifically, the test data model constraint specifications and target indicator calculation methods are globally centralized and dynamically distributed to the batch processing and stream processing dual-track links. This completely eliminates the inconsistency of indicator methods caused by the independent development of two sets of calculation code in the traditional batch-stream separation architecture from the root of the system architecture, ensuring that the first-time offline indicator data and the second-time real-time indicator data are from the same source and aligned. At the same time, this mechanism supports a unified interface mode with single-point configuration and global dual-end effect, reducing the daily iteration and maintenance costs of complex experimental indicator systems.

[0044] S106: Write the offline indicator data and real-time indicator data into the heterogeneous partition of the online query analysis and processing engine respectively; Indicative, can be achieved using, for example Figure 3The online query analysis and processing engine, as shown in the mid-result layer, utilizes a tiered scheduling mechanism for hot and cold data to achieve heterogeneous partitioned data storage and synchronizes T-1 offline metric data. Specifically, for the first-time offline metric data, which is characterized by its large volume, minimal modification after a single write (immutable attribute), and the need for extensive scanning, a large-scale data import tool is used to batch write it to the engine's static columnar storage disk partition. This partition employs deep compression and a heavily pre-aggregated index mechanism to save storage costs and improve read-only scan performance. Meanwhile, for the second-time real-time metric data, which is characterized by its relatively small volume, extremely high write frequency, and the need for continuous overwriting and updates, the stream processing engine continuously appends it to the dynamically active log structure merge tree partition built on memory or high-speed solid-state drives using micro-batch or continuous streaming modes. Through this heterogeneous partitioning of physical media and underlying structure, the platform perfectly isolates I / O lock contention caused by large-scale offline writes and high-frequency real-time writes within the same engine, ensuring high overall system availability.

[0045] S108: In response to a cross-time observation request for the target test experiment, the offline indicator data and the real-time indicator data are aggregated across partitions in the online query analysis and processing engine, and a real-time evaluation indicator for the target test experiment is output.

[0046] Cross-time observation requests refer to data query instructions initiated by the service platform's business caller or front-end visualization dashboard, whose time span covers both historical stock periods (such as T-1 days) and current incremental periods (such as T days).

[0047] Cross-partition data aggregation refers to the technical process of extracting result sets stored in different physical media or different logical model partitions (i.e., the aforementioned heterogeneous partitions) into memory at the execution computing layer of the underlying database, and then performing further merging calculations (such as accumulation, deduplication and union calculation) based on the identifier of a specific business dimension.

[0048] Real-time evaluation metrics refer to the final quantitative test evaluation values ​​that are mathematically and logically aligned and include the latest business dynamics up to the moment the query is triggered, after cross-partition aggregation calculation.

[0049] This example illustrates how the distributed query optimizer built into the online query analysis and processing engine is used to perform cross-time-sensitive aggregation operations. When the service platform receives a cross-time-sensitive observation request for a target test experiment, the engine's coordinating node first performs lexical and syntactic parsing on the time interval parameters carried in the request, dynamically routes it, and rewrites it into two parallel subquery execution trees. One static subquery tree is configured to push down to a heterogeneous partition storing offline indicator data, using range scanning to quickly extract the historical indicator set for the first timeframe; the other dynamic subquery tree is configured to push down to a heterogeneous partition storing real-time indicator data, extracting the real-time incremental indicator set for the second timeframe. The service platform engine's computing nodes perform relational algebra-level joint operations (such as equi-joins and merge joins) in memory, perform secondary grouping of the extracted two data slices based on the target test experiment identifier, and perform aggregation function calculations (such as Sum and Count). During this process, the system uses a read-time merging mechanism to solve the problem of overlapping data from different timeframes within the same dimension, ultimately outputting a mathematically consistent real-time evaluation indicator to the front end.

[0050] This specification describes a method for collecting existing and incremental test business data in a distributed manner. Based on globally unified test indicator metadata, it utilizes a dual-track calculation mechanism of batch and stream processing to independently compute the resulting offline and real-time indicators. These indicators are then written into heterogeneous partitions of the online query analysis and processing engine. Finally, in response to cross-time-sensitive observation requests, cross-partition data aggregation is performed at the engine's underlying layer. This effectively overcomes the computational performance bottlenecks faced by traditional testing platforms in large-scale data join queries, the extremely low timeliness of single offline batch processing architectures, and the technical defects such as inconsistent indicator definitions and data tearing at the intersection of stream and batch processes that are easily caused by conventional stream-batch separation architectures. Thus, while avoiding the high-cost backtracking of full detailed data, it achieves efficient, accurate, and near-real-time collection of massive experimental indicator data. This not only ensures the mathematical consistency and alignment of real-time evaluation indicators that integrate long-cycle historical baseline data and the latest dynamic data, improving the platform's throughput stability in handling high-volume concurrent queries, but also enables the business side to perceive the overall performance of the experiment with zero latency. This provides data support for quickly identifying product service solution problems, timely guiding the direction of traffic switching, and decisively shutting down substandard experiments.

[0051] Optional, such as Figure 4 As shown, Figure 4 This is a schematic diagram of a streaming state aggregation calculation process. Specifically, the process involves consuming incremental real-time data from the message middleware through a stream processing engine to perform streaming state aggregation calculations and produce real-time indicator data with a second timeframe. The following method can be used as a reference: S202: Update the running parameters of the stream processing operator based on the input dynamic observation command carrying the target fine-grained test dimension through the stream processing link engine; Target fine-grained testing dimensions refer to more refined observation perspectives specified by the platform's business side through command input, beyond the macro-level experimental evaluation metrics. Examples include specific user group characteristic intervals (such as only newly registered users), specific geographical intervals, and shorter time aggregation intervals (such as adjusting from minute-level windows to second-level windows).

[0052] Dynamic observation commands refer to control signals issued in real time by entities such as front-end consoles and business systems during the experimental run. These signals carry metadata information of the aforementioned test dimensions and are used to trigger changes in the underlying stream computing logic.

[0053] Stream processing operators refer to the basic computational execution units in the directed acyclic graph of a stream processing engine, such as filtering operators for data cleaning, windowing operators for time segmentation, and reduction operators for state aggregation. Runtime parameters refer to configuration variables that determine the specific execution behavior of a stream processing operator, such as the window size and sliding step in a windowing operator, and the matching rules in a filtering operator.

[0054] As an illustration, upon receiving a dynamic observation command carrying the target fine-grained test dimension, it is transformed into a standard configuration message and written to the control flow queue. The stream processing engine listens to this control flow queue while processing the incremental real-time data stream. Upon receiving the command, the engine uses a broadcast state mode to broadcast the dimension variables carried in the command (such as new audience filtering labels or new time window thresholds) to the local memory of all relevant stream processing operators in the distributed cluster. Each operator, without interrupting the execution of its current task, directly reads its local memory to update its internal operating parameters.

[0055] In one feasible implementation, the process of updating the running parameters of the stream processing operator based on the input dynamic observation command carrying the target fine-grained test dimension through the stream processing link engine can be carried out in the following way: Step A2: Parse the dynamic observation command to determine the target dimension type corresponding to the target fine-grained test dimension; The target dimension type refers to the result of a structured classification of the analytical intent carried in the dynamic observation command. For example, it is usually used to distinguish whether the current command is intended to change the time segmentation of the data or to change the spatial / attribute selection range of the data.

[0056] Step A4: In response to the target dimension type being a time interval dimension, the state aggregation time window parameter of the stream processing operator is updated to a time interval window that matches the time interval dimension; The state aggregation time window parameter refers to the configuration attributes that define the data accumulation period in memory when the stream processing link engine performs state calculations, such as the window length and sliding step size of the scrolling window and sliding window.

[0057] Step A6: In response to the target dimension type being a test user group interval dimension, the input data filtering conditions of the stream processing operator are updated to a test user group feature set that matches the test user group interval dimension.

[0058] The test user group interval dimension refers to the boundary of a specific audience group based on the combination of objective attributes or behavioral tags of the test object, such as recently active newly registered users or high-value users in a specific region.

[0059] Input data filtering conditions refer to Boolean logic expressions, predicate pushdown rules, etc., deployed on the front end of the directed acyclic graph of stream processing, used to intercept and discard non-target data that does not meet specific attributes.

[0060] Indicatively, after the control flow coordination node of the A2 stream processing link engine receives the dynamic observation command, it uses a JSON parser to extract the metadata fields in the command header and determines the target dimension type of the target fine-grained test dimension through pattern matching. In response to the target dimension being a time interval dimension, step A4 is executed. The coordinating node encapsulates the new time interval value into a broadcast message and sends it to the window operator executing the state aggregation. Upon receiving the message, the window operator directly modifies the trigger threshold of the timer in its internal state machine, seamlessly updating the original state aggregation time window parameters to a time interval window that matches the time interval dimension (for example, changing the frequency of state refresh from the original 5-minute scrolling to 1-minute sliding).

[0061] In response to the target dimension type being the test user group interval dimension, step A6 is executed. The coordinating node extracts the audience tags from the instruction, encapsulates them into a rule base, and sends it to the broadcast state of the front-end filtering operator. When processing each subsequent data, the filtering operator uses the updated input data filtering conditions to compare tags, allowing only data that matches the test user group feature set to flow into the downstream aggregation node.

[0062] In this specification, based on steps A2-A6, while reducing the system's runtime load, the front-end experimental dashboard is endowed with zero-interruption and ultra-fast cross-temporal and spatial dimension exploration capabilities. This allows the business side to freely switch between micro-time characteristics such as "high-frequency second-level" within the same stream computing link to capture transient fluctuations in indicators without R&D intervention, and to narrow the observation field to a very narrow specific high-level audience, thus providing business service assurance.

[0063] S204: Based on the updated running parameters, the stream processing operator performs streaming state aggregation calculation on the incremental real-time data to produce second-time real-time indicator data including the target fine-grained test dimension.

[0064] Indicatively, the stream processing operator S202, which performs hot parameter updates, immediately applies new operating parameters upon receiving the next continuous influx of incremental real-time data. For example, the filtering operator begins to intercept data that does not conform to the new population dimension, and the windowing operator begins to generate slices according to the new time window, thereby performing streaming state aggregation calculations. Finally, the stream computing output seamlessly switches and begins to continuously produce second-time real-time indicator data including the target fine-grained test dimension.

[0065] In this specification, based on the above S202-S204, by introducing the aforementioned stream processing operator parameter update and streaming state aggregation mechanism based on dynamic observation instructions, seamless hot loading of underlying calculation rules and zero-latency dynamic sinking of business analysis dimensions are achieved under the premise of ensuring uninterrupted consumption of underlying incremental real-time data streams and strong consistency of global intermediate calculation states. This enables the business side to quickly and accurately obtain real-time indicator data under specific fine-grained test dimensions (such as specific groups or specific time windows) based on the macro fluctuations of the overall market during test and experiment operation. This not only significantly improves the adaptive response capability and agile troubleshooting efficiency of large-scale experimental monitoring platforms, but also provides underlying technical support for quickly identifying strategy anomalies in specific audience groups and decisively implementing refined business adjustments.

[0066] In one feasible implementation, such as Figure 5 As shown, Figure 5 This is a schematic diagram of a data synchronization process. Specifically, it involves the splitting and collection of experimental and test-type business data from the business system, synchronizing all existing data to the offline data storage engine, and collecting incremental real-time data to the message middleware. The following approach can be used as a reference: S302: Extract the test fact data snapshot of the experimental test class in the business database into full stock data through the timed data synchronization task, and import the full stock data into the offline data storage engine in batches; Test fact data snapshots refer to a globally consistent read-only copy of the original records of objective test behaviors (such as exposure, clicks, conversions, etc.) generated in the business database at a specific time segment.

[0067] S304: By enabling the asynchronous log collection service, subscribe to the incremental change log of the business database, parse the incremental real-time data from the incremental change log, and continuously push the incremental real-time data to the message middleware.

[0068] Asynchronous log collection service refers to a bypass daemon process that runs independently of the main business system. It obtains data changes by simulating a database slave or listening to the file system, without blocking or delaying the data writing transactions of the main business system.

[0069] Incremental change logs refer to append-type binary files that are automatically generated by the underlying database of the business and record each data insertion, update, and deletion operation in chronological order.

[0070] As an example, a dedicated change data capture component (such as the Canal or Debezium component) can be deployed as an asynchronous log collection service. This change data capture component masquerades as a slave instance of the database and subscribes to the incremental change logs of the master database in real time. When the log stream flows in, the component deserializes and parses its structure, accurately filters and extracts the incremental real-time data belonging to the experimental test category, serializes it into a standard message format, and continuously and with low latency pushes it to the specified topic in the message middleware.

[0071] In this specification, based on S302-S304, a timed data synchronization task is used to extract historical fact data snapshots during non-peak business periods to complete the batch import of full data. Simultaneously, an asynchronous log collection service is introduced to bypass and listen to the underlying change logs to achieve low-latency push of incremental data. This completely decouples the data extraction layer from the core business system physically and logically, ensuring the integrity and security of the massive base data required for offline computing, while also giving real-time computing extremely high timeliness and responsiveness.

[0072] In one feasible implementation, in actual business operations, user traffic segmentation identifiers (experimental group / control group) often only exist on the front end (such as in the tracking points of the APP or Web), while the final conversion result of the business (such as successful order payment or refund) is recorded in the backend database. To overcome the data gap between the front end and back end in the data middle platform and the underlying architecture of A / B testing, the following method can be used to implement the asynchronous log collection service described in S304, subscribing to the incremental change logs of the business database, parsing incremental real-time data from the incremental change logs, and continuously pushing the incremental real-time data to the message middleware: S402: Obtain the business status change logs generated in the business database through the asynchronous log collection service; Business state change logs refer to the underlying data streams that are automatically generated by the underlying relational or transactional databases in the backend of a business system when performing data insertion, update, and deletion operations. These logs typically contain only pure business attributes and often lack the experimental context information from the front-end user interface.

[0073] S404: Merge and extract the business status change log with the test object behavior tracking log collected by the front end of the log server to obtain incremental real-time data carrying a unified test experiment identifier, and write the incremental real-time data into the corresponding topic queue of the message middleware.

[0074] Test object behavior tracking logs refer to data collection code pre-embedded in the client (such as mobile applications or web front-ends) that records user interaction behaviors (such as clicks, swipes, and page dwells) in real time. These logs typically carry front-end environment information and test experiment routing indicators.

[0075] In illustrative terms, step S402 involves using an asynchronous log collection service (e.g., a monitoring component based on Change Data Capture (CDC) technology) deployed on the database service node to capture the underlying redo logs of the database in real time, and then delivering a highly concise business state change log to the first-level raw message queue. Simultaneously, the front-end log server receives test object behavior tracking logs from various clients and delivers them to the second-level raw message queue.

[0076] In step S404, a distributed stream computing engine is introduced as the merging hub to consume the two original message queues mentioned above. The stream computing engine opens a bidirectional sliding state time window in memory and uses the extracted globally unique identifier as the association primary key to perform dual-stream interval joint operations. At this time, when the business-side state change log and the front-end behavior tracking log with experimental attributes successfully match within the time window, the engine extracts the former's business state result and the latter's unified test experiment identifier, merges and assembles them into a complete incremental real-time data, and finally writes it into the core topic queue of the message middleware in a standardized wide table structure for downstream aggregation and consumption.

[0077] This specification, based on steps S402-S404, overcomes the data discontinuity defects caused by the physical separation of the front-end experimental diversion context and the back-end actual business result data in traditional testing platforms, as well as the technical pain points such as high latency, high computing power consumption, and easy time-series mismatch caused by the reliance on downstream offline data warehouses for heavy cross-table joint queries in conventional solutions. Thus, it realizes the mapping between front-end experimental behavior and back-end conversion results at the front-end edge layer of data flow, improving the accuracy of the calculation of test indicators involving deep business conversion and the near real-time end-to-end response capability.

[0078] Optionally, in response to the cross-time-dependent observation request for the target test experiment, the online query analysis and processing engine performs cross-partition data aggregation of the offline indicator data and the real-time indicator data. This can be done in the following way: S502: Based on the consumption position of the message middleware and the global water level of the stream processing link engine, maintain at least one experimental transaction time version sequence on the online query analysis and processing engine side; The consumption point refers to the cursor in the message middleware used to precisely identify the physical reading progress of messages by the stream processing program under a specific topic or partition.

[0079] The global watermark refers to a global clock marker in the flow processing framework used to measure the logical progress of events over time, effectively tolerating and handling out-of-order and delayed data phenomena in distributed networks. When the system detects that a certain watermark has been reached, there is usually no more out-of-order or delayed data arriving earlier than that timestamp.

[0080] The experimental transaction epoch version sequence refers to a set of discrete time segments or global batch identifiers generated and maintained in the underlying database or coordinating node in a stream-batch integrated system across heterogeneous storage and computing engines to ensure global visibility and strong consistency of data during high-concurrency read-write interactions. Each "epoch" version number in this sequence strictly maps to and delineates a set of experimental test data (i.e., a complete experimental transaction) that is logically absolutely complete and securely persisted to disk, serving as a snapshot benchmark for subsequent concurrent query isolation.

[0081] As an illustration, an independent global transaction coordination service is deployed in the cluster management node or external management gateway of the pre-defined online query analysis and processing engine. During execution, this global transaction coordination service asynchronously calls the management and monitoring interface of the upstream message middleware according to a preset high-frequency micro-batch cycle (e.g., millisecond-level scheduling) to retrieve the latest consumption points of each physical data partition, precisely defining the physical ingestion boundary of the incremental business data stream. Simultaneously, it asynchronously calls the task manager interface of the stream processing link engine to capture the global watermark after alignment of the underlying stream computation operators, determining the logical time boundary of the current data processing. Subsequently, the global transaction coordination service performs an anti-out-of-order intersection calculation on the extracted consumption points and the global watermark in its memory to determine the safe data section boundary that has completely penetrated the computation link and is absolutely free of out-of-order omissions. When the calculation confirms the existence of a new security boundary, the coordination service initiates a status submission request to the metadata management module of the online query analysis and processing engine. This drives the module to generate a brand new, monotonically increasing integer value or global timestamp as the experimental transaction time record version, and appends it to the internal transaction dictionary table for persistence. In this way, the monotonically increasing experimental transaction time record version sequence is continuously maintained on the engine side in a centralized control mode.

[0082] S504: In response to a cross-time observation request for a target test experiment, determine the target experiment transaction time record version corresponding to the arrival time of the cross-time observation request, and construct a multi-version concurrency control read-only snapshot based on the target experiment transaction time record version; Multi-version concurrency control (MVCC) refers to a technical mechanism that maintains multiple historical versions of data within the database to ensure that read and write operations do not block each other. In this specification, it is used to ensure that while real-time data is being written frequently, cross-time-based queries can still read a static view of a specific version without interference.

[0083] A read-only snapshot refers to a logical image dynamically generated in the underlying storage engine based on a specific version number. This snapshot remains static throughout the query lifecycle, ensuring that the causal consistency of the data is not compromised by subsequent influxes of new incremental data during complex cross-partition aggregation calculations.

[0084] Multi-Version Concurrency Control (MVCC) read-only snapshots refer to a consistent data view that a database system builds for query operations at a specific point in time. This view allows query operations to read all clean data prior to the locked version while non-blocking the isolation of dirty data from newer versions that are being written or not yet fully committed.

[0085] As an illustration, when the online query analysis processing engine receives a cross-time observation request for a target test experiment, it first intercepts the physical arrival time of the request and immediately accesses the transaction dictionary table or memory metadata area maintained in step S502. By comparing the physical time with the commit status of each experimental transaction time period version, it determines the highest version number that has passed the end-to-end alignment check before the request arrival time and marks it as the target experimental transaction time period version. Then, it calls the multi-version concurrency control interface to quickly initialize a globally consistent read-only snapshot descriptor in memory based on the target experimental transaction time period version. This descriptor defines which underlying storage blocks or data shards belong to this version view through a bitmap or transaction linked list. Thus, a logical protective wall is built for subsequent data read operations, ensuring that all subsequent operators of the request can only run within the locked read-only snapshot range, completely shielding incomplete data segments being written.

[0086] In one feasible implementation, specifically executing step S504 involves determining the target experimental transaction timeframe version corresponding to the arrival time of the cross-time observation request, and constructing a multi-version concurrency control read-only snapshot based on the target experimental transaction timeframe version. This can be achieved using the following method: Step B2: Lock the target experimental transaction time version corresponding to the arrival time of the cross-time observation request, and set the target experimental transaction time version as the global visibility boundary. At the same time, continuously monitor the spatiotemporal water level of the stream processing link engine, block the snapshot construction operation for the target experimental transaction time version, until the spatiotemporal water level is detected to cross the target experimental transaction time version. Global visibility boundary refers to the logical timeframe used in multi-version concurrency control mechanisms to strictly define whether data is visible to the current query. Data with an underlying commit version number less than or equal to this boundary is visible to the current query, while data with a version number greater than this boundary will be forcibly isolated and hidden.

[0087] The spatiotemporal watermark is a two-dimensional alignment marker that integrates time (logical event time) and space (the ingestion progress of various distributed physical partitions). The spatiotemporal watermark will only advance when the event time of all physical partitions reaches a certain threshold, indicating that the data before this section has been physically and logically persisted to disk across the entire network.

[0088] Blocking the snapshot construction operation for the target experimental transaction version refers to actively suspending the local execution thread of the current query task during the initialization phase of the query execution plan, temporarily halting view generation, and waiting for the underlying asynchronous network I / O to completely flush the last few batches of data in transit to disk. This operation only blocks the current query and does not block the continuous writing of underlying business data.

[0089] As an illustration, when a cross-time observation request arrives, the master node of the online query analysis and processing engine locks the target experimental transaction time version and sets it as the global visibility boundary of the current query session. At this time, the master node does not issue a snapshot command but instead starts a listener to continuously monitor the spatiotemporal watermarks sent from the upstream stream processing engine to each physical node. Due to the slight network time difference in the distributed environment, the master node will actively block the next step of the current snapshot building operation (i.e., let the query request enter a short-term waiting queue). The blocking will not be lifted until the master node has accurately detected that the spatiotemporal watermarks of all underlying data nodes have crossed the set target experimental transaction time version (i.e., confirm that there is no late data in transit).

[0090] Step B4: Traverse the heterogeneous partitions of the online query analysis and processing engine, and filter out the target test data blocks whose underlying storage commit version number is less than or equal to the global visibility boundary; As an illustration, the master node issues metadata scanning instructions carrying the global visibility boundary to each heterogeneous partition of the engine (including offline columnar storage nodes and real-time memory nodes). It controls the underlying storage nodes to traverse their respective directory trees, skipping file-level detailed scanning, and directly compares the underlying storage commit version number carried in the storage block header to filter out all target test data blocks with version numbers less than or equal to the boundary.

[0091] Step B6: Assemble the selected target test data blocks into a logical view to generate a multi-version concurrency control read-only snapshot.

[0092] In a schematic representation, each lower-level node returns the physical addresses of the selected data blocks to the master node. The master node assembles these scattered address pointers into a logical view, generating a lightweight, multi-version concurrency control read-only snapshot descriptor in memory. Subsequent aggregation operators only need to read the data based on the descriptor.

[0093] In this specification, based on steps B2-B6, after locking the target experimental transaction time version and setting global visibility boundaries, a creative approach is introduced to continuously monitor the underlying spatiotemporal water level and an adaptive blocking mechanism for snapshot construction operations. Subsequently, the heterogeneous partitions are traversed to filter legal blocks and a lightweight logical view assembly is implemented. This overcomes the limitations of occasional data omissions (i.e., phantom reads) caused by the micro-time difference between the logical version allocation of the master node and the physical disk write of the underlying data in extreme high-concurrency and distributed network jitter scenarios. It avoids the risk of memory overflow and IO avalanche crashes caused by massive physical data copying when building a globally consistent snapshot in traditional databases. Thus, the misalignment between logical time and physical space is perfectly matched in the underlying computing architecture, ensuring that the indicators of the entire experimental test platform are absolutely accurate and highly available in extreme network environments.

[0094] S506: Extract data slices based on the multi-version concurrency control read-only snapshot, and perform cross-partition data aggregation on the offline indicator data and the real-time indicator data within the data range defined by the data slices.

[0095] Data slicing refers to a logically continuous set of data that is free from temporal conflicts, filtered and extracted from the underlying physical storage under specific multi-version concurrency control read-only snapshot boundaries.

[0096] This example illustrates the use of a column-oriented MPP (Massively Parallel Processing) architecture to perform cross-partition aggregation. Specifically, the engine's distributed query planner transforms the version number condition of the multi-version concurrency control read-only snapshot into a low-level filtering predicate and pushes it down to each data storage node. The storage nodes use this filtering predicate to extract a first data slice representing the historical cumulative cardinality from the offline static partition, and a second data slice representing the latest incremental state from the real-time active partition. To achieve ultra-fast aggregation, the engine's compute nodes allocate contiguous address spaces in memory to directly receive columnar data blocks from these slices. The control compute nodes bypass the traditional row-by-row parsing mode and directly invoke the processor's underlying single-instruction multiple-data-stream hardware instruction set to perform vectorized bitwise logical operations (such as bitmap merging for UV deduplication metrics and vector addition for PV count metrics) on the offline and real-time data slices in contiguous memory. This mechanism achieves cross-partition computation convergence with an extremely high CPU cache hit rate within the safe range defined by the data slices.

[0097] This specification, based on S502-S506, utilizes cross-domain time-series calculations through the consumption points of the message middleware and the global watermark of the stream processing engine. A monotonically increasing experimental globally consistent version sequence is dynamically maintained within the underlying online query analysis and processing engine. This allows for precise targeting of the target version in response to cross-time-dependent observation requests, and the construction of a multi-version concurrent control read-only snapshot. Finally, within the strictly defined, absolutely secure data slice scope of this snapshot, cross-domain aggregation is performed on stream-batch dual-track data in heterogeneous partitions. This effectively overcomes the challenges posed by high-concurrency read / write intersections in traditional stream-batch integrated architectures and distributed databases, due to the high-frequency streaming micro-batch write operations upstream and the macro-level cross-region query operations at the front end. This approach avoids data pollution defects such as dirty reads, phantom reads, and data tearing during underlying merging calculations, which are inevitably caused by overlapping and interleaving on the timeline. It also completely avoids the precipitous drop in system throughput and query link blockage avalanche caused by conventional solutions that forcibly introduce global table locks or distributed cross-database locks to ensure strong consistency. Thus, it builds a safe execution environment for cross-domain association calculations between underlying heterogeneous physical storage media without pausing the continuous reading of upstream real-time incremental data. This ensures the consistency and time sequence alignment of long-cycle offline historical data and the latest real-time incremental data during aggregation, and fundamentally guarantees low error and anti-jump in the calculation results of massive complex state-type aggregation indicators.

[0098] Optionally, considering the technical challenges of data inflation due to simple accumulation and storage and network I / O paralysis caused by retaining full details when performing precise deduplication of massive users across computing engines and time periods in a stream-batch separation architecture, the following method can be used to achieve precise deduplication in a stream-batch heterogeneous architecture: Step C2: Identify the target test metrics that belong to the deduplication statistics type in the target test experiment, and at the output end of the batch processing link engine and the stream processing link engine, serialize the data corresponding to the target test metrics into native bitmap data blocks with the test experiment identifier as the key, and write the native bitmap data blocks into the heterogeneous partition respectively; Among them, the target test index of deduplication statistics refers to the test index that cannot be merged across dimensions by simple algebraic accumulation in experimental evaluation, but is based on the unique identifier of the entity (such as user ID, device MAC address) for deduplication counting, such as the number of unique visitors, the number of unique devices, etc.

[0099] Native bitmap data blocks refer to a data structure with extremely high compression ratios that uses contiguous memory bits to map and record large-scale discrete integer sets. When an entity performs an action, its corresponding bit is set to 1; otherwise, it is set to 0.

[0100] Indicatively, scanning metadata identifies target test metrics for the current computation task, such as unique visitor conversion rate, which fall under the category of deduplication statistics. This triggers the engine's bitmap computation topology. Internally, within the batch processing and stream processing engines, a globally consistent ID mapping dictionary is used to hash or map the native string-type user identifiers to consecutive integer values ​​of a preset number of bits (e.g., 32 bits). The engine's aggregation operator directly maintains the bitmap structure in memory, highlighting (setting to 1) the bits corresponding to the incoming integer values. Instead of outputting traditional detailed records or simple counts, the engine uses an underlying serialization protocol (such as Protobuf) to serialize the entire bitmap object in memory into compact native bitmap data blocks (byte arrays). Finally, using the test experiment identifier as the key, these serialized offline and real-time bitmap data blocks are written to the corresponding columns of the heterogeneous partitions (i.e., offline static partitions and real-time active partitions) of the online query analysis and processing engine.

[0101] In this specification, based on step C2, the deduplication statistics are actively identified at the data output end of the heterogeneous engine, and the state aggregation is forcibly completed in memory using a bitmap structure. Then, it is serialized into a native bitmap data block with the experimental identifier as the key and written into the underlying heterogeneous partition. Under the conditions of limited storage space and extremely high data write throughput, the global micro state of each test entity access is preserved. This not only reduces the storage cost of massive detailed data by several orders of magnitude, but also provides a standard underlying data carrier for the downstream engine to perform hardware-level single-instruction stream bitmap merging with a time complexity of only O(1) when performing cross-partition secure aggregation. This fundamentally realizes near-zero error accurate deduplication analysis across time and space and across architecture in the experimental testing field.

[0102] Furthermore, referring to step C2 above, specifically performing cross-partition data aggregation of the offline indicator data and the real-time indicator data in the online query analysis and processing engine to output real-time evaluation indicators for the target test experiment can be done in the following way: In the online query analysis and processing engine, cross-partition data aggregation is performed on the offline indicator data and the real-time indicator data. The default detailed data joint scan execution plan of the online query analysis and processing engine is intercepted in parallel, and the vectorized merging routing mechanism for the native bitmap data block is triggered to complete the cross-partition data aggregation and output the real-time evaluation indicators for the target test experiment.

[0103] in: The detailed data joint scan execution plan refers to the default physical execution route generated by traditional relational or analytical databases when faced with cross-table / cross-partition queries. This route typically reads massive detailed log records from the underlying disk or memory row by row, and then pulls them into memory to perform a costly hash join to complete deduplication and aggregation.

[0104] Parallel interception identifies the current bitmap aggregation scenario through rule matching during the parsing of the abstract syntax tree and the generation of the physical execution plan, thereby forcibly blocking and discarding the default inefficient detailed scanning route.

[0105] Vectorized merging routing mechanism refers to bypassing the traditional row-by-row iterator model at the execution layer and directly distributing blocks of offline and real-time native bitmap data in memory to processor computing units that support single instruction multiple data streams. It utilizes the underlying bit-by-bit logic or instructions to complete the high-speed superposition of multiple sets of bitmap states and radix calculation within an extremely short CPU clock cycle.

[0106] As an illustration, the query planning layer of the online query analysis and processing engine can be deeply customized with a rule-based optimizer. When the engine receives a cross-partition aggregation query request, if the optimizer detects that the data type of the target aggregation field is the native bitmap data block structure unique in the aforementioned steps during the SQL or query abstract syntax tree parsing stage, it immediately triggers a parallel interception mechanism, directly suspending and discarding the default scan execution plan process. Subsequently, the optimizer triggers a vectorized merge routing mechanism, forcibly rewriting the execution route of the query and routing it to the engine's underlying pre-built dedicated bitmap execution operator. During execution on the compute node, this dedicated operator directly calls the CPU's advanced extended instruction set, loading the offline bitmap extracted from the heterogeneous partition and the real-time bitmap into a contiguous register block. Through hardware-level instructions, it instantly completes the OR (or) logic merging of tens of millions of bits, and then uses a fast bit set radix calculation instruction to directly obtain the deduplicated true value, thereby quickly outputting the real-time evaluation index of the target test experiment. By adopting the aforementioned approach, row-by-row reading and comparison are eliminated at the kernel level of the architecture. The high-complexity large-scale cross-partition set intersection and deduplication operations are reduced to low-time-complexity bitwise logical operations on continuous memory blocks. This not only improves the system's cross-time query aggregation performance by several orders of magnitude, but also ensures high-precision near real-time output of experimental evaluation indicators with low computational resource overhead in high-concurrency experimental scenarios.

[0107] In one feasible implementation, the specific execution of the vectorized merging routing mechanism for triggering the native bitmap data block to output real-time evaluation metrics for the target test experiment can be carried out in the following manner: Step D2: Extract the first time-lapse offline bitmap slice and the second time-lapse real-time bitmap slice with the same test experiment identifier from the heterogeneous partition; The first-time offline bitmap slice and the second-time real-time bitmap slice refer to the binary data segments generated in the aforementioned steps, which respectively represent the deduplication status of users in the historical static period (e.g., day T-1) and the current dynamic period (e.g., day T-0). Physically, they are represented as highly compressed byte arrays.

[0108] Step D4: Load the first time-sensitive offline bitmap slice and the second time-sensitive real-time bitmap slice into the contiguous memory address of the online query analysis and processing engine computing node; Step D6: Invoke the processor's Single Instruction Multiple Data (SID) instruction set to perform a bitwise OR operation on the first real-time offline bitmap slice and the second real-time bitmap slice located in the contiguous memory address, and generate a deduplicated real-time evaluation index.

[0109] Single Instruction Multiple Data (SIMD) instruction set refers to a hardware-level acceleration technology built into microprocessors in the industry. It allows the CPU to perform the same arithmetic or logical operation on multiple data points simultaneously using a single machine instruction within one clock cycle, thereby achieving a significant leap in computational throughput.

[0110] Indicatively, in step D2, the engine's underlying storage scanner bypasses the conventional buffer pool and uses the operating system's file descriptors to locate the underlying data block belonging to the target test experiment in the heterogeneous partition, quickly extracting the first time-sensitive offline bitmap slice and the second time-sensitive real-time bitmap slice.

[0111] In step D4, the engine uses techniques such as memory-mapped file technology and zero-copy network protocols to bypass-map and load the bitmap slices extracted from different storage media into aligned contiguous memory addresses pre-allocated by the computing nodes.

[0112] In step D6, the compute node's execution engine detects the highest-order vectorization extension set supported by the current server CPU. It invokes the processor's Single Instruction Multiple Data (SID) instruction set to load the offline and real-time bitmap data from contiguous memory into a 512-bit wide register. The CPU can simultaneously perform a bitwise OR operation on up to 512 user status flags (i.e., merge 512 bits at once) in just one clock cycle. Through pipelined fast bitwise OR operations within the register, the heterogeneous data streams are instantly stitched together. Subsequently, hardware-level instructions are invoked to calculate the Hamming weight of the merged bitmap (i.e., the total number of bits set to 1), thereby rapidly generating the deduplicated real-time evaluation metrics.

[0113] In this specification, by loading offline and real-time bitmap slices with the same test identifier from heterogeneous partitions into contiguous memory addresses, and directly calling the processor's single instruction multiple data instruction set to perform large-scale bitwise logical OR operations at the hardware level to generate the final evaluation metrics, the complex business deduplication logic is reduced in dimensionality and mapped to lightweight and fast low-level register bit operations in the micro-hardware architecture, without avoiding any detailed data deserialization and frequent garbage collection overhead of memory objects. This not only pushes the CPU's cache hit rate and instruction pipeline throughput to their physical limits, achieving a leap in deduplication performance, but also, under the constraint of extremely low hardware cost, endows a large-scale real-time A / B testing platform with the ability to cope with instantaneous traffic surges and the demand for second-level refresh of large disks.

[0114] The following will combine Figure 6 This manual provides a detailed description of the test data processing device provided. It should be noted that... Figure 6 The test data processing device shown is used to execute this specification. Figures 1-5 The methods of the embodiments shown are illustrated only in connection with this specification for ease of explanation. For specific technical details not disclosed, please refer to this specification. Figures 1-5 The example shown.

[0115] Please see Figure 6 This diagram illustrates the structure of the test data processing device described in this specification. The test data processing device 1 can be implemented as all or part of a user electronic device through software, hardware, or a combination of both. According to some embodiments, the test data processing device 1 includes a split acquisition module 11, an aggregation calculation module 12, a data writing module 13, and an indicator calculation module 14, specifically used for: The diversion and acquisition module 11 is used to perform diversion and acquisition of experimental and test business data in the business system, synchronize all existing data to the offline data storage engine, and collect incremental real-time data to the message middleware. The aggregation calculation module 12 is used to aggregate and calculate the full amount of existing data in the offline data storage engine based on globally unified test indicator metadata, and to produce offline indicator data with the first timeliness through the batch processing link engine, and to consume incremental real-time data in the message middleware through the stream processing link engine to perform streaming state aggregation and calculation to produce real-time indicator data with the second timeliness. Data writing module 13 is used to write the offline indicator data and real-time indicator data into the heterogeneous partition of the online query analysis and processing engine, respectively. The indicator calculation module 14 is used to respond to cross-time observation requests for the target test experiment by performing cross-partition data aggregation on the offline indicator data and the real-time indicator data in the online query analysis and processing engine, and outputting real-time evaluation indicators for the target test experiment.

[0116] It should be noted that the test data processing device provided in the above embodiments is only illustrated by the division of the above functional modules when executing the test data processing method. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the test data processing device and the test data processing method embodiments provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.

[0117] The serial numbers in this specification are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0118] This specification also provides a computer storage medium capable of storing multiple instructions adapted to be loaded and executed by a processor as described above. Figures 1-5 The test data processing method described in the illustrated embodiment can be found in the following document for a detailed execution process. Figures 1-5 The specific details of the illustrated embodiments will not be elaborated here.

[0119] This specification also provides a computer program product that stores at least one instruction, said at least one instruction being loaded and executed by the processor as described above. Figures 1-5 The test data processing method described in the illustrated embodiment can be found in the following document for a detailed execution process. Figures 1-5 The specific details of the illustrated embodiments will not be elaborated here.

[0120] Please refer to Figure 7 This is a structural block diagram of an electronic device provided in an embodiment of this specification. The electronic device in this specification may include one or more of the following components: a processor 1010, a memory 1020, an input device 1030, an output device 1040, and a bus 1050. The processor 1010, memory 1020, input device 1030, and output device 1040 may be connected to each other via the bus 1050.

[0121] Processor 1010 may include one or more processing cores. Processor 1010 connects to various parts of the electronic device using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 1020, and by calling data stored in memory 1020. Optionally, processor 1010 may be implemented using at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), or programmable logic array (PLA). Processor 1010 may integrate one or a combination of central processing unit (CPU), graphics processing unit (GPU), and modem. The CPU mainly handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem is used for wireless communication. It is understood that the modem may also not be integrated into processor 1010 and may be implemented separately through a communication chip.

[0122] The memory 1020 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 1020 may include non-transitory computer-readable storage medium. The memory 1020 may be used to store instructions, programs, code, code sets, or instruction sets.

[0123] The input device 1030 is used to receive input instructions or data, and includes, but is not limited to, a keyboard, mouse, camera, microphone, or touch device. The output device 1040 is used to output instructions or data, and includes, but is not limited to, a display device and a speaker. In this embodiment, the input device 1030 can be a temperature sensor for acquiring the operating temperature of the electronic device. The output device 1040 can be a speaker for outputting audio signals.

[0124] In addition, those skilled in the art will understand that the structure of the electronic device shown in the above figures does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements. For example, the electronic device may also include radio frequency circuits, input units, sensors, audio circuits, wireless fidelity (WIFI) modules, power supplies, Bluetooth modules, etc., which will not be described in detail here.

[0125] In the embodiments of this specification, the executing entity for each step can be the electronic device described above. Optionally, the executing entity for each step can be the operating system of the electronic device. The operating system can be Android, iOS, or other operating systems; this specification does not limit this.

[0126] exist Figure 7 In the electronic device, the processor 1010 can be used to call a program stored in the memory 1020 and execute it to implement the test data processing method as described in the various method embodiments of this specification.

[0127] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0128] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the data, features, and information involved in this specification were all obtained under full authorization.

[0129] The above-disclosed embodiments are merely preferred embodiments of this specification and should not be construed as limiting the scope of this specification. Therefore, any equivalent variations made in accordance with the claims of this specification shall still fall within the scope of this specification.

Claims

1. A test data processing method, characterized in that, The method includes: For experimental and test-type business data in the business system, perform split collection, synchronize all existing data to the offline data storage engine, and collect incremental real-time data to the message middleware; Based on globally unified test indicator metadata, the batch processing link engine aggregates and calculates the full amount of existing data in the offline data storage engine to produce offline indicator data with the first timeliness. The stream processing link engine consumes the incremental real-time data in the message middleware and performs streaming state aggregation and calculation to produce real-time indicator data with the second timeliness. The offline indicator data and real-time indicator data are written into the heterogeneous partition of the online query analysis and processing engine, respectively. In response to a cross-time observation request for the target test experiment, the online query analysis and processing engine performs cross-partition data aggregation on the offline indicator data and the real-time indicator data, and outputs a real-time evaluation indicator for the target test experiment. The cross-partition data aggregation of the offline indicator data and the real-time indicator data in the online query analysis and processing engine includes: Based on the consumption point of the message middleware and the global water level of the stream processing link engine, at least one experimental transaction time version sequence is maintained at the online query analysis and processing engine end. In response to a cross-time observation request for a target test experiment, determine the target experiment transaction time record version corresponding to the arrival time of the cross-time observation request, and construct a multi-version concurrency control read-only snapshot based on the target experiment transaction time record version; Data slices are extracted based on the multi-version concurrency control read-only snapshot, and cross-partition data aggregation is performed on the offline indicator data and the real-time indicator data within the data range defined by the data slices.

2. The method according to claim 1, characterized in that, The process of consuming incremental real-time data from the message middleware through a stream processing link engine to perform streaming state aggregation calculations and produce second-time real-time indicator data includes: The stream processing link engine updates the runtime parameters of the stream processing operators based on the input dynamic observation instructions carrying the target fine-grained test dimension; Based on the updated operating parameters, the stream processing operator performs streaming state aggregation calculations on the incremental real-time data, producing second-time real-time indicator data that includes the target fine-grained test dimension.

3. The method according to claim 2, characterized in that, The process of updating the running parameters of the stream processing operator through the stream processing link engine based on the input dynamic observation command carrying the target fine-grained test dimension includes: Parse the dynamic observation command to determine the target dimension type corresponding to the target fine-grained test dimension; In response to the target dimension type being a time interval dimension, the state aggregation time window parameter of the stream processing operator is updated to a time interval window that matches the time interval dimension. In response to the target dimension type being a test user group interval dimension, the input data filtering conditions of the stream processing operator are updated to a test user group feature set that matches the test user group interval dimension.

4. The method according to claim 1, characterized in that, The process of performing traffic splitting and collection on experimental and test-type business data in the business system, synchronizing all existing data to the offline data storage engine, and collecting incremental real-time data to the message middleware includes: The test fact data snapshot of the experimental test class in the business database is extracted into full stock data through a timed data synchronization task, and the full stock data is imported into the offline data storage engine in batches. By enabling asynchronous log collection service, the incremental change logs of the business database are subscribed to, incremental real-time data is parsed from the incremental change logs, and the incremental real-time data is continuously pushed to the message middleware.

5. The method according to claim 4, characterized in that, The step of enabling an asynchronous log collection service, subscribing to the incremental change logs of the business database, parsing incremental real-time data from the incremental change logs, and continuously pushing the incremental real-time data to the message middleware includes: The business status change logs generated in the business database are obtained through the asynchronous log collection service; The business status change logs are merged and extracted with the test object behavior tracking logs collected by the front end of the log server to obtain incremental real-time data carrying a unified test experiment identifier, and the incremental real-time data is written into the corresponding topic queue of the message middleware.

6. The method according to claim 1, characterized in that, The method further includes: In the common dependency area corresponding to the batch processing link engine and the stream processing link engine, globally unified test indicator metadata, including test data model constraint specifications and target indicator calculation methods, is centrally maintained. The test metric metadata is synchronously loaded into the batch processing link engine and the stream processing link engine to execute the steps of aggregating and calculating the full amount of existing data in the offline data storage engine through the batch processing link engine to produce offline metric data with a first timeliness, and consuming the incremental real-time data in the message middleware through the stream processing link engine to perform streaming state aggregation and calculation to produce real-time metric data with a second timeliness.

7. The method according to claim 1, characterized in that, The process of determining the target experimental transaction time-series version corresponding to the arrival time of the cross-time-series observation request, and constructing a multi-version concurrency control read-only snapshot based on the target experimental transaction time-series version, includes: Lock the target experimental transaction time version corresponding to the arrival time of the cross-time observation request, and set the target experimental transaction time version as the global visibility boundary. At the same time, continuously monitor the spatiotemporal water level of the stream processing link engine, block the snapshot construction operation for the target experimental transaction time version, until the spatiotemporal water level is detected to cross the target experimental transaction time version. Traverse the heterogeneous partitions of the online query analysis and processing engine to filter out target test data blocks whose underlying storage commit version number is less than or equal to the global visibility boundary; The selected target test data blocks are assembled into a logical view to generate a multi-version concurrency control read-only snapshot.

8. The method according to claim 1, characterized in that, The step of writing the offline indicator data and real-time indicator data into the heterogeneous partition of the online query analysis and processing engine includes: Identify the target test metrics that belong to the deduplication statistics type in the target test experiment, and at the output end of the batch processing link engine and the stream processing link engine, serialize the data corresponding to the target test metrics into native bitmap data blocks with the test experiment identifier as the key, and write the native bitmap data blocks into the heterogeneous partition respectively. The process of cross-partition data aggregation of the offline indicator data and the real-time indicator data in the online query analysis and processing engine, and outputting real-time evaluation indicators for the target test experiment, includes: In the online query analysis and processing engine, cross-partition data aggregation is performed on the offline indicator data and the real-time indicator data. The default detailed data joint scan execution plan of the online query analysis and processing engine is intercepted in parallel, and the vectorized merging routing mechanism for the native bitmap data block is triggered to complete the cross-partition data aggregation and output the real-time evaluation indicators for the target test experiment.

9. The method according to claim 8, characterized in that, The triggering of the vectorized merging routing mechanism for the native bitmap data block to output real-time evaluation metrics for the target test experiment includes: Extract the first time-sensitive offline bitmap slice and the second time-sensitive real-time bitmap slice with the same test experiment identifier from the heterogeneous partition; The first time-sensitive offline bitmap slice and the second time-sensitive real-time bitmap slice are loaded into the contiguous memory addresses of the computing node of the online query analysis and processing engine; The processor's Single Instruction Multiple Data (SID) instruction set is invoked to perform a bitwise logical OR operation on the first real-time offline bitmap slice and the second real-time bitmap slice located in the contiguous memory address, generating a deduplicated real-time evaluation index for the target test experiment.

10. A test data processing device, characterized in that, The device includes: The traffic splitting and acquisition module is used to perform traffic splitting and acquisition of experimental and test business data in the business system, synchronize all existing data to the offline data storage engine, and collect incremental real-time data to the message middleware. The aggregation calculation module is used to aggregate and calculate the full amount of existing data in the offline data storage engine based on globally unified test indicator metadata, and to produce offline indicator data with the first timeliness through the batch processing link engine, and to consume incremental real-time data in the message middleware through the stream processing link engine to perform streaming state aggregation and calculation to produce real-time indicator data with the second timeliness. The data writing module is used to write the offline indicator data and the real-time indicator data into the heterogeneous partition of the online query analysis and processing engine, respectively. The indicator calculation module is used to respond to cross-time observation requests for the target test experiment, and to perform cross-partition data aggregation on the offline indicator data and the real-time indicator data in the online query analysis and processing engine, and output the real-time evaluation indicator for the target test experiment. The cross-partition data aggregation of the offline indicator data and the real-time indicator data in the online query analysis and processing engine includes: Based on the consumption point of the message middleware and the global water level of the stream processing link engine, at least one experimental transaction time version sequence is maintained at the online query analysis and processing engine end. In response to a cross-time observation request for a target test experiment, determine the target experiment transaction time record version corresponding to the arrival time of the cross-time observation request, and construct a multi-version concurrency control read-only snapshot based on the target experiment transaction time record version; Data slices are extracted based on the multi-version concurrency control read-only snapshot, and cross-partition data aggregation is performed on the offline indicator data and the real-time indicator data within the data range defined by the data slices.

11. A computer storage medium, characterized in that, The computer storage medium stores a plurality of instructions, which are adapted to be loaded by a processor and executed by the steps of the method as described in any one of claims 1 to 9.

12. A computer program product, characterized in that, The computer program product stores at least one instruction, which is loaded by a processor and executed according to any one of claims 1 to 9.

13. An electronic device, characterized in that, include: Processor and memory; The memory stores a computer program adapted to be loaded by the processor and executed according to any one of claims 1 to 9.

Images