Batch processing type business system general platform construction method and device, equipment and medium

Abstract

This invention discloses a general platform construction method for batch processing business systems, comprising: firstly splitting the batch processing business system into multiple independent business units; secondly splitting each business unit into a task sequence of orthogonal combinations of horizontal and vertical tasks, with the data flow as the main backbone, the orthogonal task sequences acting on the data flow sequentially from top to bottom; matching corresponding components for each horizontal or vertical task according to the task's operation type and data requirements, forming independent tasks by matching components according to task type, and connecting the tasks into business units according to the data flow processing order, achieving integration between business units through a cross-unit data flow accessor; and outputting the structured data flow processed by the business units. By extracting the two-dimensional general rules of data flow driving and horizontal and vertical changes in batch processing business systems, a unified and standardized architecture template is constructed, enabling the architecture to have cross-industry and cross-scenario universality.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and specifically to a general platform construction method, apparatus, equipment, and medium for batch processing business systems. Background Technology

[0002] Batch processing systems are information systems that centrally process business data in batches. Their core characteristic is that they do not respond to individual requests in real time, but rather accumulate similar business data to a certain scale, process it centrally within a specific time window, and output the results. Typical scenarios include monthly payroll calculation, quarterly financial statement generation, and annual supply chain data aggregation. As a key support for enterprise business operations, this type of system currently faces the following core technical pain points:

[0003] Lack of architectural versatility: Existing systems mostly adopt a general layered architecture of "startup control layer - business logic layer - data access layer", but it lacks fine-grained architectural guidance for the core characteristics of batch processing business such as "data flow driven and multi-step batch collaboration". This leads to the common existence of customized development mode of "one architecture for one business", poor system reusability and difficulty in cross-scenario expansion.

[0004] Business and technology are tightly coupled: business logic is directly embedded in the code implementation, lacking abstraction and separation of core business entities such as "data flow rules", "batch calculation logic" and "cross-step / cross-module data association". System iteration requires modification of core code, resulting in high maintenance costs and risks, and it cannot adapt to rapid changes in business rules.

[0005] Insufficient digital support: The data flow path is implicit and business operations are untraceable, making it difficult to transform data assets and operational logic in batch processing into manageable and analyzable digital resources, which restricts the enterprise's need for refined governance of business processes during digital transformation.

[0006] Platform-based construction lacks a basis: Due to the lack of fine-grained commonality analysis and entity mining, the existing architecture cannot provide theoretical support and practical tools for building a general platform foundation for batch processing business systems, resulting in enterprises having to repeatedly invest resources to build similar systems, leading to low construction efficiency.

[0007] Therefore, there is an urgent need for a general architecture solution that can achieve standardized decomposition, component-based integration, digital governance, and platform-based construction of batch processing business systems, thereby breaking through existing technical bottlenecks. Summary of the Invention

[0008] The purpose of this invention is to provide a general platform construction method, apparatus, equipment and medium for batch processing business systems, thereby solving the problems of poor generality of existing batch processing business system architectures, low component reuse rate, insufficient digital support, and lack of basis for platform construction.

[0009] This invention is achieved through the following technical solution:

[0010] In a first aspect, the first embodiment of the present invention provides a general platform construction method for a batch processing business system, comprising:

[0011] Batch processing business systems are split into multiple independent business units based on the single responsibility principle. Each business unit focuses on a single business objective and contains independent inputs, processing logic, and outputs.

[0012] With the data stream as the main body, each business unit is further divided into a task sequence of orthogonal combination of horizontal and vertical tasks. The horizontal tasks adjust the number of data stream records, the vertical tasks adjust the data stream field information, and the orthogonal combination of task sequences acts on the data stream sequentially from top to bottom.

[0013] Based on the operation type and data requirements of the task, a corresponding component is matched for each horizontal or vertical task. The component includes a calculator and an accessor, and the accessor includes a cross-cell data flow accessor.

[0014] Components are matched according to task type to form independent tasks, and tasks are linked together into business units according to the data flow processing order. Integration between business units is achieved through cross-unit data flow accessors.

[0015] The structured data stream processed by the business unit is output externally through configuration-based mapping.

[0016] Furthermore, the calculator includes a horizontal calculator, a vertical calculator, and a value calculator. The horizontal calculator is used to support the data stream quantity adjustment logic of the horizontal task, the vertical calculator is used to support the operation of adjusting the data stream content of the vertical task, and the value calculator is used to support the per-data stream value calculation in the horizontal and vertical tasks.

[0017] Furthermore, the step of matching corresponding component combinations for each horizontal or vertical task based on the task's operation type and data requirements specifically includes:

[0018] For a horizontal task, a matching accessor and one horizontal calculator or a matching accessor, an evaluation calculator and one horizontal calculator.

[0019] For append or modify operations on vertical tasks, match the evaluator, accessor, and one vertical calculator;

[0020] For the delete operation in the vertical task, there is a matching accessor and a vertical calculator.

[0021] Furthermore, the process of matching components by task type to form independent tasks, chaining tasks into business units according to the data flow processing order, and integrating business units through cross-unit data flow accessors specifically includes:

[0022] Match calculators and accessors by task type to verify interface compatibility;

[0023] Tasks are processed sequentially according to the data stream, with the output of the preceding task providing data support for the subsequent task.

[0024] Data flow references between business units are implemented through cross-unit data flow accessors. Integration between different business units is completed by declarative reference, and the source business unit identifier and source field name are declared during integration.

[0025] Furthermore, the accessor also includes an external data accessor, an intra-cell data stream accessor, and a literal value accessor for standardizing the declaration and retrieval of data sources.

[0026] Secondly, another embodiment of the present invention provides a general platform construction apparatus for a batch processing business system, comprising:

[0027] The first-level splitting module is used to split batch processing business systems into multiple independent business units according to a single responsibility. Each business unit focuses on a single business objective and contains independent inputs, processing logic, and outputs.

[0028] The secondary splitting module uses the data flow as the main backbone to split each business unit into a task sequence of orthogonal combinations of horizontal and vertical tasks. The horizontal tasks adjust the number of data flow records, the vertical tasks adjust the data flow field information, and the orthogonal combination of task sequences acts on the data flow sequentially from top to bottom.

[0029] The three-level splitting module is used to match corresponding components for each horizontal or vertical task according to the task's operation type and data requirements. The components include a calculator and an accessor, and the accessor includes a cross-unit data flow accessor.

[0030] The integration module is used to match components according to task type to form independent tasks, chain tasks into business units according to data flow processing order, and realize the integration between business units through cross-unit data flow accessors.

[0031] The output module outputs the structured data stream processed by the business unit to the outside world through a configurable mapping method.

[0032] Furthermore, the calculator includes a horizontal calculator, a vertical calculator, and a value calculator. The horizontal calculator is used to support the data stream quantity adjustment logic of the horizontal task, the vertical calculator is used to support the operation of adjusting the data stream content of the vertical task, and the value calculator is used to support the per-data stream value calculation in the horizontal and vertical tasks.

[0033] Furthermore, the three-level splitting module includes a component matching unit. For horizontal tasks, the component matching unit matches an accessor and one horizontal calculator, or matches an accessor, an evaluation calculator, and one horizontal calculator. For append or modification operations in vertical tasks, it matches an evaluation calculator, an accessor, and one vertical calculator. For deletion operations in vertical tasks, it matches an accessor and one vertical calculator.

[0034] Thirdly, another embodiment of the present invention provides an electronic device comprising: a processor, an input device, an output device, and a memory, wherein the processor, the input device, the output device, and the memory are interconnected, the memory is used to store a computer program, the computer program includes program instructions, and the processor is configured to invoke the program instructions to execute the method described in the first embodiment above.

[0035] Fourthly, another embodiment of the present invention provides a computer-readable storage medium storing a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to perform the method described in the first embodiment above.

[0036] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0037] This invention provides a general platform construction method, apparatus, device, and medium for batch processing business systems. By extracting the two-dimensional general laws of data flow driving and horizontal and vertical changes in batch processing business, a unified and standardized architecture template is constructed, enabling the architecture to have cross-industry and cross-scenario universality. This fundamentally solves the problems of existing batch processing systems having "one architecture per business," high degree of customization, and poor reusability.

[0038] It adopts a two-layer architecture with a unified upper template layer and a flexible lower implementation layer to achieve deep decoupling between business logic and technical implementation. Through discrete components such as horizontal tasks, vertical tasks, calculators, and accessors, it achieves high reusability, composability, and scalability, significantly reducing development and maintenance costs and avoiding redundant construction.

[0039] The data flow, data source, calculation logic, and operation steps in the batch processing process are made explicit and structured, forming a traceable system for the entire chain of results, operations, and inputs. This supports digital governance of business processes, problem localization, compliance auditing, and optimization analysis, thereby improving enterprises' data governance and digital transformation capabilities.

[0040] It provides a standardized three-level decomposition and three-level integration construction method, transforming traditional coding development into platform-based configuration and component combination, significantly shortening the development cycle, improving system delivery efficiency and stability, and supporting rapid business iteration and smooth expansion.

[0041] It provides a general-purpose platform foundation that can be directly deployed and used, offering a clear path and implementation tools for the platformization and ecosystem construction of enterprise batch processing business systems, supporting the large-scale and standardized construction of business systems, and promoting the transformation and upgrading of development paradigms. Attached Figure Description

[0042] To more clearly illustrate the technical solutions of the exemplary embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of the present invention and should not be considered as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort. In the drawings:

[0043] Figure 1 A flowchart illustrating a general platform construction method for a batch processing business system provided in the first embodiment of the present invention;

[0044] Figure 2 EvoBase platform architecture diagram;

[0045] Figure 3 A flowchart illustrating the analysis and breakdown process of the company's monthly departmental cost accounting system;

[0046] Figure 4 This is a schematic diagram of two-dimensional changes in the data flow;

[0047] Figure 5 This is a schematic diagram illustrating the construction and integration process of the EvoBase platform. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the embodiments and accompanying drawings. The illustrative embodiments and descriptions of the present invention are only used to explain the present invention and are not intended to limit the present invention.

[0049] The purpose of this invention is to construct a general platform for batch processing business systems—the EvoBase platform—through a general platform construction method for batch processing business systems, and to explain the underlying architectural pattern and conceptual approach—the EvoBase architecture—to address the problems of poor generality, low component reusability, insufficient digital support, and lack of a basis for platform construction in existing batch processing business systems. The EvoBase platform is a concrete implementation of the EvoBase architecture. The core innovation of the EvoBase architecture lies in revealing the essential data flow-driven characteristics of batch processing business systems, making them explicit, structured, and central, and extracting the two-dimensional universal laws of horizontal and vertical changes in data flow. The EvoBase platform then translates this concept into an operable and reusable technical entity, constructing a two-layer architecture with a unified upper-layer template and flexible lower-layer components, and defining standardized decomposition and integration rules for direct user use. Its core universality stems from the deep exploration and abstraction of the commonalities of batch processing business systems.

[0050] like Figure 1 As shown, the first embodiment of the present invention provides a general platform construction method for a batch processing business system, which includes the following steps:

[0051] Batch processing business systems are split into multiple independent business units based on the single responsibility principle. Each business unit focuses on a single business objective and contains independent problem inputs, processing logic, and outputs.

[0052] With the data stream as the main body, each business unit is further divided into a task sequence of orthogonal combination of horizontal and vertical tasks. The horizontal tasks adjust the number of data stream records, the vertical tasks adjust the data stream field information, and the orthogonal combination of task sequences acts on the data stream sequentially from top to bottom.

[0053] Based on the operation type and data requirements of the task, a corresponding component is matched for each horizontal or vertical task. The component includes a calculator and an accessor, and the accessor includes a cross-cell data flow accessor.

[0054] Components are matched according to task type to form independent tasks, and tasks are linked together into business units according to the data flow processing order. Integration between business units is achieved through cross-unit data flow accessors.

[0055] The structured data stream processed by the business unit is output externally through configuration-based mapping.

[0056] Definition of the core concepts in this embodiment:

[0057] Business Units: In the EvoBase platform, business systems are broken down into independent business units based on functional boundaries. Each business unit implements a single business function, containing independent inputs, processing logic, and outputs, and is the first-level unit of system decomposition.

[0058] Data Flow: The structured data carrier that runs through the business units of the EvoBase platform, composed of multiple fields such as employee ID, basic salary, performance-based salary, and actual salary. Its core characteristic is task-by-task structured alignment; the field definitions of all records in the input and output data flows of any task must be completely consistent, such as field names and data types. The structure of the data flow can undergo holistic and atomic changes between different tasks. The data flow is the core thread of the business unit; all business operations revolve around the processing of the data flow. Its two-dimensional change pattern (horizontal change: quantity adjustment; vertical change: content adjustment) is the core foundation for the universality of the EvoBase architecture.

[0059] Horizontal tasks (horizontal changes): In the EvoBase platform, this refers to operations that adjust the quantity dimension of data. Its unique and exclusive core function is to change the number of records in the data stream. It has atomicity (a single task only implements one quantity adjustment) and holistic nature (acts on all records in the current data stream), specifically including:

[0060] Initialization: Generate an initial data stream from scratch;

[0061] Expansion: Expanding the number of data streams one by one, i.e., from one to many;

[0062] Deduplication / Filtering / Aggregation: Deduplicat data stream records by specific fields, filter them by specific conditions, or aggregate and merge them by key fields.

[0063] The types of lateral tasks are finite and enumerable, and complex quantity adjustment requirements can be achieved through combination; the data stream output by lateral tasks must meet the structured alignment characteristics per task.

[0064] Vertical Tasks (Vertical Changes): In the EvoBase platform, this refers to operations that adjust the content dimension of the data stream. Its unique and exclusive core function is to change the field information (field value or number of fields) of the data stream. It has atomicity (a single task only handles one type of content adjustment) and holistic nature (acts on all current data stream records), specifically including:

[0065] Append: Adds a new field to the data stream; this operation is performed record-by-record, processing each record independently, and supports concurrency;

[0066] Modify: Correct the calculated field values; this operation is performed line by line.

[0067] Delete: Removes one or more specified fields from the data stream. This operation applies to all records in the entire data stream to ensure the structure of the output data stream is aligned.

[0068] The types of operations in vertical tasks are limited and enumerable, and complex changes in data stream content can be achieved through combination; the data stream output by vertical tasks must meet the structured alignment characteristics of each task.

[0069] Calculators: Core components in the EvoBase platform for implementing task operation logic. They are the concrete embodiment of business logic, possessing characteristics such as clearly defined type, single function, enumerable pre-defined or extensible addition capabilities, and discrete combinability. They are divided into three categories: horizontal calculators, vertical calculators, and evaluation calculators.

[0070] Horizontal Calculators: Support the logic for adjusting the number of data streams in horizontal tasks, such as data stream expansion calculators, data stream filtering calculators, and data stream aggregation calculators. They directly correspond to the finite enumerable types of horizontal tasks (the data stream initialization task that generates the initial data stream from scratch corresponds to the data stream expansion calculator); each horizontal task needs to match one and only one horizontal calculator; the platform has pre-built commonly used horizontal calculators and supports user-defined extensions.

[0071] Vertical calculators: Support operations that allow vertical tasks to adjust the content of the data stream, such as field append calculators, field modification calculators, and field deletion calculators. They directly correspond to the limited enumerable types of vertical tasks. Each vertical task needs to match one and only one vertical calculator. The platform has all vertical calculators pre-built.

[0072] Evaluation Calculator: Supports evaluation calculations per data stream in both horizontal and vertical tasks, providing data sources or conditional results for the expansion or filtering of horizontal tasks, and providing field value sources for the "append" and "modify" operations of vertical tasks. The evaluation calculator is mainly used for scenarios involving evaluation calculations per data stream (the "delete" operation of vertical tasks does not require an evaluation calculator), covering various needs from simple operations (such as addition, subtraction, multiplication, and division) to complex business logic (such as individual income tax tiered calculation and commission ratio calculation). The platform has pre-built commonly used evaluation calculators and supports user-defined extensions. Logically, the calculation object of the evaluation calculator is a single data stream, but the actual input data range is not limited to a single data stream. For example, the input of the binary ranking calculator is: a. the "score" field of the current data stream; b. a list of "score" field values ​​from all data streams or data streams grouped in the same group as the current data stream. The calculation process is to calculate the ranking of a in the list b, and the return value is an integer ranking. Here, the data source of a is the current single data stream, while the data source of b includes other data streams.

[0073] Accessors: Standardized components in the EvoBase platform that provide the data sources required for tasks, ensuring data traceability, and possessing characteristics such as clearly defined types, single function, scalable or declarative reference, and discrete composability. Specifically, they include:

[0074] External data accessor: Obtains data from outside the EvoBase platform, such as global input or environment variables, reading employee information from the database, and obtaining procurement contract data through API interfaces; typical database reading and API call scenarios require specifying the data acquisition method, data source address, data acquisition range, data filtering conditions, etc.

[0075] Intra-unit data flow accessor: Declare references to existing data flow fields (one or more) in the current business unit by field name (one or more);

[0076] Cross-unit data stream accessor: Declares a reference to data stream fields (one or more) output by other business units by using a business unit identifier and field name (one or more). This requires that the referenced business unit (i.e., the source business unit) has been completed.

[0077] Literal accessors: Used to declare literal constants on the spot, such as tax rate "0.03", month "2025-10", grade "A", etc., or to specify field names (used in combination with intra-cell data stream accessors, cross-cell data stream accessors, or specific calculators to indicate the field name to be referenced or manipulated).

[0078] Core Concept Example Explanation: In actual business processes, a horizontal task (such as expansion) is often closely linked to a vertical task (such as appending a new field). To simplify the example description and the expression of the business process, this embodiment combines and merges such adjacent horizontal and vertical tasks in some examples. However, it must be clear that this merging is only a simplification of expression; in the EvoBase platform, the underlying logic is always that of mutually independent orthogonal tasks with single responsibilities. Taking the production department expenditure statistics business unit for a specified month as an example, assuming: ① whether the department is a production department needs to be determined based on specific conditions, ② the department expenditure only includes procurement costs and employee salaries, its two-dimensional data flow change process is as follows (using a simplified merged presentation):

[0079] i. Horizontal Task (Initialization): Based on the input month, generate an initial data stream from scratch, outputting one record containing the field [Month]. This step is essentially a merged presentation of "horizontally expanding the number of records" followed by "vertically appending the month field".

[0080] ii. Horizontal Task (Expansion): Retrieve the complete list of departments, expand the data stream, and output N records with the fields [Month, Department ID]. This step is essentially a merged presentation of "horizontally expanding the number of records" followed by "vertically appending the Department ID field".

[0081] iii. Horizontal Task (Filtering): Based on the specified month, filter the data stream records of "Production Department" according to the conditions, and output K records (K≤N), with the fields being [month, department ID].

[0082] iv. Vertical Task (Append): Add a "Purchase Cost" field to each production department record, and output K records with the fields [Month, Department ID, Purchase Cost].

[0083] v. Horizontal Task (Expansion): Based on department employee information, expand each department record to include all employee records under that department, outputting M records. Assuming that in a special scenario, the number of employees in each production department is E, then M = K * E, with fields [Month, Department ID, Procurement Cost, Employee ID]. This step is essentially a merging of "horizontally expanding the number of records" followed by "vertically appending the employee ID field".

[0084] vi. Vertical Task (Append): Add an "Employee Salary" field to each employee record, outputting M records with the fields [Month, Department ID, Procurement Cost, Employee ID, Employee Salary].

[0085] vii. Horizontal Task (Aggregation): Group the data stream by "Department ID", calculate the total salary for each department, merge multiple employee records into one department record, and output K records with the fields [Month, Department ID, Procurement Cost, Total Salary]. This step is essentially a merging of "horizontal aggregation of record count" followed by "vertical appending of the department salary total field and deleting employee-related fields".

[0086] viii. Vertical Task (Append): Add a "Total Expenditure" field (value = procurement cost + total salary) to each department record, and output K records with the fields [month, department ID, procurement cost, total salary, total expenditure].

[0087] like Figure 2 As shown, the EvoBase platform adopts a two-layer structure with a unified template layer on the upper layer and a flexible implementation layer on the lower layer. The two layers are associated through task and component mapping, which ensures both architectural consistency and scenario flexibility. This layered design is an important guarantee for its core universality.

[0088] The unified template layer comprises entities: business units, data flows, horizontal tasks, and vertical tasks. Its core characteristics are standardization, templating, framing, and constraint. Its core function is to create structural patterns for business units, data flows, and horizontal / vertical tasks. Horizontal tasks are only responsible for adjusting the number of data flows, while vertical tasks are only responsible for adjusting the content of data flows. The two are orthogonally combined to form business logic, ensuring architectural consistency and universality. It constrains data flows with core rules such as "structured alignment per task" and task atomicity. The decomposition of horizontal and vertical tasks defines the task specifications that lower-level components must implement.

[0089] The flexible implementation layer comprises entities: calculators and accessors. Its core characteristics are replaceability, fillability, reusability, and extensibility. Its core function is to provide implementation solutions for specific business logic and data acquisition: horizontal tasks acquire data through accessors and perform calculations with the evaluation calculator to generate the adjustment criteria required by the horizontal calculator, such as expanding data sources and filtering conditions, thereby adjusting the number of records in the data stream; vertical tasks acquire data through accessors and perform calculations with the evaluation calculator to generate the operation data required by the vertical calculator, such as appending field values ​​and modifying field values, thereby adjusting the content of the data stream; through different combinations of calculators and accessors, it adapts to the personalized needs of various business scenarios, ensuring architectural flexibility; the same horizontal or vertical task can have different, selectable combinations of implementation solutions.

[0090] By extracting the two-dimensional change patterns of data flow and designing a two-layer architecture and standardized tasks, it breaks away from dependence on specific business scenarios and can cover batch processing business systems in many industries such as finance, human resources, supply chain, finance, and retail. It solves the industry pain point of "one architecture for one business" and provides a unified architecture governance and evolution foundation for batch processing business systems.

[0091] Analysis and decomposition process:

[0092] The analysis and decomposition process is based on a top-down logical hierarchical decomposition of the EvoBase architecture template. At the solution level, it breaks down complex systems into building entities that combine at different levels and granularities. The decomposition process specifically follows a three-level decomposition rule:

[0093] Level 1 decomposition (system decomposition into business units): Batch processing business systems are decomposed into independent business units according to functional boundaries, with each business unit focusing on a single business objective; the decomposition standard is single responsibility; this standard is uniformly applicable to all batch processing business scenarios;

[0094] Two-level splitting (business unit splitting into task sequences): Taking the data flow as the main backbone, each business unit is split into a task sequence of horizontal and vertical orthogonal combinations from top to bottom according to the business logic sequence; orthogonal combination means that horizontal tasks only change the number of data flows, and vertical tasks only change the content of data flows. The two have independent responsibilities and can be freely connected in the order of horizontal to vertical or vertical to horizontal; the orthogonal combination of task sequences acts on the data flow in a strict sequence from top to bottom, that is, the next task can only start after the previous task is completely finished. Since the essence of all batch processing business units is the processing of data flows, this splitting rule has universality;

[0095] Three-level splitting (tasks are split into calculators and accessors): Based on the task's operation type and data requirements, corresponding components are matched for each horizontal / vertical task, with the following matching rules:

[0096] Horizontal tasks: require matching one horizontal calculator, one or more accessors, and (optionally) one or more evaluation calculators; when the task requires dynamic calculation of the adjustment basis, such as filter conditions or expanded lists, an evaluation calculator must be matched; for simple initialization tasks, such as generating an initial data stream containing a "month" field or a deduplication / aggregation task specifying a field name, an evaluation calculator is not required; the horizontal calculator determines the quantity adjustment type, and the accessor specifies the field on which the adjustment is based or provides the data required for the calculation;

[0097] Vertical tasks (such as append / modify): require matching one vertical calculator, one or more evaluation calculators, and one or more accessors; the vertical calculator determines the content adjustment type, the accessor provides the evaluation calculator with the data required for calculation, and the evaluation calculator calculates and generates field values;

[0098] Vertical tasks (such as deletion): require matching one vertical calculator and one or more accessors; the vertical calculator determines the type of field to be deleted, and the accessors specify the name of the field to be deleted.

[0099] In the EvoBase platform, business systems are no longer independently developed collections of code, but rather combinations of platform-pre-built or user-defined extension components. Therefore, core components such as the dataflow extension calculator, intra-unit dataflow accessor, and cross-unit dataflow accessor can be reused in all batch processing business units, significantly reducing development and maintenance costs. When adding new business scenarios, there is no need to modify the upper-layer architecture template; simply adding a calculator / accessor to the EvoBase platform allows for rapid assembly and adaptation to new requirements. Component extensions do not affect existing business units, ensuring smooth system evolution. This transformation guarantees the long-term viability of the system.

[0100] Building the integration process:

[0101] After analyzing and decomposing the EvoBase architecture at the solution level, users can then perform actual building and integration on the EvoBase platform. This is a bottom-up building process: users use the standardized tools provided by the platform to create or combine entities of different granularities and levels as needed, ultimately building a complete system. Specifically, it follows a three-level combination and result output process:

[0102] First-level combination (components form tasks): On the platform, components are matched according to task type to form independent tasks. The component combination rules are consistent with the three-level splitting steps in the decomposition process. If the component (calculator, accessor) does not exist, it needs to be created through the platform tools. During the combination process, the compatibility of the component interface needs to be verified (e.g., the data type of the accessor output must be compatible with the input type required by the evaluation calculator).

[0103] Secondary combination (tasks are linked into business units): On the platform, horizontal and vertical tasks are linked into complete business units according to the data flow processing order. When linking, it is necessary to ensure that the data flow output by the preceding task meets the access requirements of the subsequent task. For example, if the subsequent horizontal filtering task requires "department ID" as a related field for related filtering, then the preceding vertical task needs to provide this field. Data collaboration and declarative referencing between tasks are realized through structured data flow, without the need to hardcode the association logic.

[0104] Three-level combination (business unit formation system): On the platform, data flow references between business units are realized through cross-unit data flow accessors. Integration between different business units is completed by declarative reference. During integration, the source business unit identifier and source field name must be declared. This integration mode is applicable to all batch processing scenarios that include cross-business unit result references. Integration is achieved by declarative reference, which can effectively manage the coupling between business units and support digital tracking and tracing of cross-module data association.

[0105] Output Results: After the business unit completes its processing, the structured data stream is output externally on the platform through a configured mapping method. Taking a typical database persistent output method as an example, the configuration includes: database connection information (such as address, port, username, and password), data writing strategy (such as full overwrite, incremental insertion, and update insertion), and the mapping relationship between data stream fields and database table fields (such as data stream field names, database table field names, and format conversion strategies). Similar mapping configurations can be implemented for other external output methods (such as writing to files, network output, etc.). Through external mapping configuration based on structured data streams, the output of results can be completed without customized development, while simultaneously establishing a two-way traceability channel between business processing and external results.

[0106] This invention provides a general platform construction method for batch processing business systems. By extracting the two-dimensional general rules of data flow driving and horizontal and vertical changes in batch processing business, a unified and standardized architecture template is constructed, enabling the architecture to have cross-industry and cross-scenario universality. This fundamentally solves the problems of existing batch processing systems having "one architecture per business", high degree of customization, and poor reusability.

[0107] The embodiments of this invention adopt a two-layer architecture of an upper unified template layer and a lower flexible implementation layer, which achieves deep decoupling between business logic and technical implementation. Through discrete components such as horizontal tasks, vertical tasks, calculators, and accessors, it achieves high reusability, composability, and scalability, significantly reducing development and maintenance costs and avoiding redundant construction.

[0108] The data flow, data source, calculation logic, and operation steps in the batch processing process are made explicit and structured, forming a traceable system for the entire chain of results, operations, and inputs. This supports digital governance of business processes, problem localization, compliance auditing, and optimization analysis, thereby improving enterprises' data governance and digital transformation capabilities.

[0109] It provides a standardized three-level decomposition and three-level integration construction method, transforming traditional coding development into platform-based configuration and component combination, significantly shortening the development cycle, improving system delivery efficiency and stability, and supporting rapid business iteration and smooth expansion.

[0110] It provides a general-purpose platform foundation that can be directly deployed and used, offering a clear path and implementation tools for the platformization and ecosystem construction of enterprise batch processing business systems, supporting the large-scale and standardized construction of business systems, and promoting the transformation and upgrading of development paradigms.

[0111] Taking the "Enterprise Monthly Departmental Cost Accounting System" as an example, this paper details how to build the EvoBase platform using the general platform construction method of batch processing business systems, and verifies the feasibility and universality of the platform.

[0112] (I) System Requirements

[0113] The system needs to achieve three core functions:

[0114] 1. Calculate the actual monthly salary of all employees (actual salary = basic salary + performance-based salary - social security deduction - individual income tax).

[0115] 2. Calculate the monthly procurement cost for each department (procurement cost = total amount of all procurement contracts for the department within the specified month).

[0116] 3. Summarize the total monthly cost for each department (total cost = departmental procurement cost + departmental total salary).

[0117] (II) Analysis and Decomposition Process

[0118] like Figure 3 As shown, the first-level split is as follows: the batch processing business system is split into three business units according to the single responsibility principle: "Employee salary calculation unit" (responsible for calculating the actual monthly salary of employees), "Department procurement cost unit" (responsible for calculating the monthly procurement cost of the department), and "Department total cost summary unit" (responsible for summarizing the total monthly cost of the department). Each unit focuses on a single business objective, and the splitting logic conforms to the general splitting standard of all batch processing systems.

[0119] Two-level decomposition: Taking the data flow as the main framework, it decomposes into orthogonal combinations of horizontal and vertical tasks, fully demonstrating the core law of two-dimensional changes in the data flow. A diagram illustrating the two-dimensional changes in the data flow is shown below. Figure 4 As shown:

[0120] Employee salary calculation unit: Horizontal task 1 (initialize month), horizontal task 2 (expand employee ID), vertical task 1 (calculate gross salary), vertical task 2 (calculate deductions), vertical task 3 (calculate actual salary);

[0121] Departmental Procurement Cost Unit: Horizontal Task 1 (Initial Month), Horizontal Task 2 (Extended Department ID), Vertical Task 1 (Summary Procurement Amount);

[0122] Departmental total cost summary unit: Horizontal task 1 (initialize month), horizontal task 2 (expand department ID), vertical task 1 (reference purchase cost), horizontal task 3 (expand employee ID), vertical task 2 (reference employee salary), horizontal task 4 (summarize salary by department), vertical task 3 (calculate total cost).

[0123] For the sake of simplification, the above two-level breakdown combines adjacent horizontal and vertical tasks.

[0124] Three-level splitting: Based on the task type and data calculation requirements, the corresponding components are matched, as shown in Table 1:

[0125] Table 1 Task and Component Matching Table

[0126] Employee salary calculation unit Horizontal Task 1 (Initializing the Month) Data Stream Expansion Calculator (for expanding the number of data streams from zero to many) Field Append Calculator (for appending month fields to data stream content) External data accessor (gets external input months, such as 2025-10) Employee salary calculation unit Lateral Task 2 (Expanding Employee IDs) Data Stream Expansion Calculator (for expanding the number of data streams from few to many) Field Append Calculator (for appending employee ID fields to data stream content) Intra-cell data stream accessor (gets a specified month) External data accessor (gets a list of all employee IDs for a specified month) Employee salary calculation unit Vertical Task 1 (Calculate Gross Wages) Field append calculator and value calculator (used to calculate gross salary = basic salary + performance-based salary) Intra-unit data stream accessor (get employee ID); External data accessor (get basic salary and performance-based salary for a specified employee ID). Employee salary calculation unit Vertical Task 2 (Calculate Deductions) Field appending calculator and evaluation calculator (calculates individual income tax and social security contributions based on gross salary using the social security API and individual income tax API, and calculates total deductions). Intra-unit data stream accessor (retrieves gross pay) Employee salary calculation unit Vertical Task 3 (Calculate Actual Wages) Field append calculator and value calculator (used to calculate Actual Work = Gross Salary - Deductions) Intra-unit data stream accessor (retrieves gross pay and deductions) Departmental Procurement Cost Unit Horizontal Task 1 (Initializing the Month) Data Stream Expansion Calculator (for expanding the number of data streams from zero to many) Field Append Calculator (for appending month fields to data stream content) External data accessor (gets external input months, such as 2025-10) Departmental Procurement Cost Unit Horizontal Task 2 (Extended Department ID) Data Stream Expansion Calculator (for expanding the number of data streams from few to many) Field Append Calculator (for appending department ID fields to data stream content) Intra-cell data stream accessor (gets a specified month) External data accessor (gets a list of company / department IDs for a specified month) Departmental Procurement Cost Unit Vertical Task 1 (Summarizing Procurement Amounts) Field append calculator and value calculator (used to calculate the total amount of purchase contracts). Intra-unit data stream accessor (retrieves a specified month and department ID); External data accessor (retrieves the total purchase contract amount for a specified month and department ID). Departmental Total Cost Summary Unit Horizontal Task 1 (Initializing the Month) Data Stream Expansion Calculator (for expanding the number of data streams from zero to many) Field Append Calculator (for appending month fields to data stream content) External data accessor (gets external input months, such as 2025-10) Departmental Total Cost Summary Unit Horizontal Task 2 (Extended Department ID) Data Stream Expansion Calculator (for expanding the number of data streams from few to many) Field Append Calculator (for appending department ID fields to data stream content) Intra-cell data stream accessor (gets a specified month) External data accessor (gets a list of company / department IDs for a specified month) Departmental Total Cost Summary Unit Vertical Task 1 (Referencing Procurement Costs) Field Append Calculator Intra-cell data flow accessor (gets the specified month and department ID); Cross-cell data flow accessor (gets the procurement cost for the specified month and department ID). Departmental Total Cost Summary Unit Lateral Task 3 (Expanding Employee IDs) Data Stream Expansion Calculator (for expanding the number of data streams from few to many) Field Append Calculator (for appending employee ID fields to data stream content) Intra-cell data stream accessor (gets a specified month) External data accessor (gets a list of all employee IDs for a specified month) Departmental Total Cost Summary Unit Vertical Task 2 (Referring to actual employee salaries) Field Append Calculator Intra-cell data flow accessor (gets a specified month and employee ID); Cross-cell data flow accessor (gets the actual salary for a specified month and employee ID). Departmental Total Cost Summary Unit Horizontal Task 4 (Salary Summary by Department) Data Stream Aggregation Calculator (for aggregating data streams from most to least number), Field Deletion Calculator (for removing employee ID and employee salary fields from data stream content), Field Append Calculator (for appending the department's total salary field to data stream content). Literal accessor (specifies aggregation and merging of employee actual salary fields grouped by department ID; specifies field deletion). Departmental Total Cost Summary Unit Vertical Task 3 (Calculate Total Cost) Field append calculator and value calculator (calculates total department cost = procurement cost + total salary) Intra-unit data stream accessor (retrieves procurement costs and total wages)

[0127] (III) Construction of the integration process

[0128] like Figure 5 As shown, the first-level combination: on the EvoBase platform, components are matched according to task type to form independent tasks. If a component does not exist, it needs to be created through the corresponding EvoBase platform tools. The component combination rules are consistent with the three-level splitting steps implemented in the analysis and decomposition process.

[0129] Secondary combination: Tasks are linked together on the platform according to the data flow processing order to form a complete business unit. Taking the "Department Total Cost Summary Unit" as an example, the linking order is "Horizontal Task 1, Horizontal Task 2, Vertical Task 1, Horizontal Task 3, Vertical Task 2, Horizontal Task 4, Vertical Task 3". During the linking process, the data flow fields output by the preceding task provide data support for the subsequent task to ensure data collaboration.

[0130] Three-level combination: On the platform, inter-unit integration is achieved through cross-unit data flow accessors. The "Department Total Cost Summary Unit" references fields from the "Employee Salary Calculation Unit" and the "Department Procurement Cost Unit" respectively through cross-unit data flow accessors, thereby achieving loosely coupled integration of the three business units in a declarative manner.

[0131] Results are stored in the database: Configure the mapping relationship between the output data stream of the "Department Total Cost Summary Unit" and the database table "dept_monthly_cost" on the platform, as shown in Table 2; at the same time, the database connection information and data writing strategy also need to be configured; the system automatically completes data storage based on the configuration, without the need for customized development.

[0132] Table 2 Mapping Relationship Table

[0133] month month Direct mapping (format: YYYY-MM, e.g., 2025-10) Department ID dept_id direct mapping Total wages salary_total direct mapping Procurement costs procurement cost direct mapping Total cost total_cost direct mapping

[0134] (iv) Implementation Results

[0135] Reusability: The three business units built on the EvoBase platform reused a large number of the platform's pre-built core components, verifying the general reusability value of the components.

[0136] Efficiency: When adding the "Department Sales Commission Calculation" function, only two components need to be added to the EvoBase platform: the commission formula calculator and the sales data external accessor. Existing components such as the data flow extension calculator, field append calculator, and cross-cell data flow accessor can be reused. The modification of including sales commissions in department costs can be achieved without modifying the upper-level architecture template, which reflects the flexibility and scalability of the architecture and the improvement of development efficiency.

[0137] Traceability: When the total cost of a department in a certain month is abnormal, the entire result-operation-data chain can be fully restored through the components, tasks, and data flow information of the EvoBase platform, meeting the needs of digital governance and compliance audit. For example, the calculation logic of "total cost" can be traced to "total salary + procurement cost" through the evaluation calculator; the cross-unit data flow accessor can be used to locate that the data of the "procurement cost" field comes directly from the "department procurement cost unit", and the data of the "total salary" field comes from the summary of the results of the "employee salary calculation unit"; and so on, until the complete "result-operation-data" chain can be traced.

[0138] Universality: This implementation process can be directly reused in other business batch processing scenarios such as "quarterly financial statement system" and "annual inventory system" without changing the core architecture logic, which verifies the cross-scenario universality of the EvoBase platform.

[0139] Platformization: Based on the EvoBase platform, the construction of the "Enterprise Monthly Departmental Cost Accounting System" has undergone a fundamental transformation: from a traditional software project requiring extensive coding, testing, and deployment, it has been transformed into a "configuration and composition" process on the EvoBase platform. The role of developers has shifted from "code writers" to "business rule designers" and "platform asset assimilation builder," which is precisely the biggest change and value brought about by platformization. This development approach, which prioritizes heavy-duty components, accumulates assets, and uses discrete combinations, will have increasingly significant marginal effects on development efficiency, delivery quality, and asset governance.

[0140] Taking the "XX Commodity Exchange Market Maker Management System" as an example, this illustrates the practical application of the EvoBase platform in batch processing scenarios within the financial sector: The system needs to implement three core batch processing functions: market maker performance evaluation, obligation management, and incentive calculation. The implementation process is as follows:

[0141] 1. Analysis and Decomposition Process: The first-level decomposition divides the system into three business units: "Market Maker Performance Indicator Calculation Unit," "Market Maker Obligation Completion Rate Statistics Unit," and "Market Maker Incentive Calculation Unit." The second-level decomposition, based on the two-dimensional change pattern of the data flow, breaks down the task sequence for each unit, such as "Initializing Date Range, Expanding Market Maker Data, Expanding Contract / Product Data, Calculating Additional Performance Indicator Results, and Aggregating Results by Market Maker." The third-level decomposition matches components, such as matching the vertical task "Calculating Trading Volume Score" with "Field Addition Calculator," "Trading Volume Score Evaluation Calculator," and "External Data Accessor."

[0142] 2. Building the integration process: Match components according to task type to form independent tasks. If a component does not exist, it needs to be created through the corresponding EvoBase platform tool; string tasks together according to the data flow processing order to form a complete business unit; achieve inter-unit integration through cross-unit data flow accessor; and write the processing results to the database through mapping configuration.

[0143] 3. Implementation Results: The system can support batch calculations of tens of millions of units per day; the component reuse rate is high; the development cycle is shortened by about 40% compared with the traditional architecture; and the applicability of the EvoBase platform in high-concurrency and high-complexity batch processing scenarios such as finance has been verified.

[0144] Another embodiment of the present invention provides a general platform construction device for batch processing business systems, comprising: a first-level splitting module, used to split the batch processing business system into multiple independent business units according to a single responsibility, each business unit focusing on a single business objective, and each business unit containing independent input, processing logic, and output; a second-level splitting module, using data flow as the backbone, splitting each business unit into a task sequence of orthogonal combinations of horizontal and vertical tasks, wherein the horizontal tasks adjust the number of data flow records, the vertical tasks adjust the data flow field information, and the orthogonal combination of task sequences acts on the data flow sequentially from top to bottom; a third-level splitting module, used to match corresponding components for each horizontal or vertical task according to the operation type and data requirements of the task, the components including calculators and accessors, the accessors including cross-unit data flow accessors; an integration module, used to match components according to task type to form independent tasks, chain tasks into business units according to the data flow processing order, and realize the integration between business units through cross-unit data flow accessors; and an output module, used to output the structured data flow processed by the business units externally through a configurable mapping method.

[0145] The calculator includes a horizontal calculator, a vertical calculator, and a value calculator. The horizontal calculator is used to support the data stream quantity adjustment logic of the horizontal task. The vertical calculator is used to support the operation of adjusting the data stream content of the vertical task. The value calculator is used to support the per-data stream value calculation in the horizontal and vertical tasks.

[0146] The three-level splitting module includes a component matching unit. For horizontal tasks, the component matching unit matches an accessor and one horizontal calculator, or matches an accessor, an evaluation calculator, and one horizontal calculator. For append or modification operations in vertical tasks, it matches an evaluation calculator, an accessor, and one vertical calculator. For deletion operations in vertical tasks, it matches an accessor and one vertical calculator.

[0147] The execution process of each module can be carried out according to the general platform construction method and steps of a batch processing business system provided in the first embodiment, and will not be described in detail in this embodiment.

[0148] The general platform construction apparatus and the general platform construction method for batch processing business systems provided in this embodiment of the invention are based on the same inventive concept and have the same beneficial effects, and will not be described again here.

[0149] Another embodiment of the present invention provides an electronic device, which includes a processor, an input device, an output device, and a memory. The processor, the input device, the output device, and the memory are interconnected. The memory is used to store a computer program, which includes program instructions. The processor is configured to call the program instructions to execute the method described in the first embodiment above.

[0150] It should be understood that, in the embodiments of the present invention, the processor may be a Central Processing Unit (CPU), but it may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0151] Input devices may include touchpads, microphones, etc., and output devices may include displays (LCDs, etc.), speakers, etc.

[0152] The memory may include read-only memory and random access memory, and provides instructions and data to the processor. A portion of the memory may also include non-volatile random access memory. For example, the memory may also store information about the device type.

[0153] In specific implementations, the processor, input device, and output device described in the embodiments of the present invention can execute the implementation of the method embodiments described in the embodiments of the present invention, or they can execute the implementation of the system embodiments described in the embodiments of the present invention, which will not be repeated here.

[0154] The present invention also provides an embodiment of a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor, cause the processor to perform the method described in the first embodiment above.

[0155] The computer-readable storage medium can be an internal storage unit of the terminal described in the foregoing embodiments, such as the terminal's hard drive or memory. The computer-readable storage medium can also be an external storage device of the terminal, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card equipped on the terminal. Furthermore, the computer-readable storage medium can include both internal storage units and external storage devices of the terminal. The computer-readable storage medium is used to store the computer program and other programs and data required by the terminal. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0156] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0157] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the terminals and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0158] In the several embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices or units, or may be electrical, mechanical or other forms of connection.

[0159] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be covered within the scope of the claims and specification of the present invention.

Claims

1. A general platform construction method for a batch-type service system, characterized by, include: Batch processing business systems are split into multiple independent business units based on the single responsibility principle. Each business unit focuses on a single business objective and contains independent inputs, processing logic, and outputs. With the data stream as the main body, each business unit is further divided into a task sequence of orthogonal combination of horizontal and vertical tasks. The horizontal tasks adjust the number of data stream records, the vertical tasks adjust the data stream field information, and the orthogonal combination of task sequences acts on the data stream sequentially from top to bottom. Based on the operation type and data requirements of the task, a corresponding component is matched for each horizontal or vertical task. The component includes a calculator and an accessor, and the accessor includes a cross-cell data flow accessor. Components are matched according to task type to form independent tasks, and tasks are linked together into business units according to the data flow processing order. Integration between business units is achieved through cross-unit data flow accessors. The structured data stream processed by the business unit is output externally through configuration-based mapping.

2. The method of claim 1, wherein, The calculator includes a horizontal calculator, a vertical calculator, and a value calculator. The horizontal calculator is used to support the data stream quantity adjustment logic of the horizontal task. The vertical calculator is used to support the operation of adjusting the data stream content of the vertical task. The value calculator is used to support the per-data stream value calculation in the horizontal and vertical tasks.

3. The method of claim 2, wherein, The process of matching corresponding component combinations for each horizontal or vertical task based on the task's operation type and data requirements specifically includes: For lateral tasks, either a matching accessor and one lateral calculator, or a matching accessor, an evaluation calculator, and one lateral calculator. For append or modify operations on vertical tasks, match the evaluator, accessor, and one vertical calculator; For the delete operation in the vertical task, there is a matching accessor and a vertical calculator.

4. The method of claim 3, wherein, The process of matching components by task type to form independent tasks, chaining tasks into business units according to the data flow processing order, and integrating business units through cross-unit data flow accessors specifically includes: Match calculators and accessors by task type to verify interface compatibility; Tasks are processed sequentially according to the data stream, with the output of the preceding task providing data support for the subsequent task. Data flow references between business units are implemented through cross-unit data flow accessors. Integration between different business units is completed by declarative references, and the source business unit identifier and source field name are declared during integration.

5. The method of claim 1, wherein, The accessor also includes an external data accessor, an intra-cell data stream accessor, and a literal value accessor, used to standardize the declaration and acquisition of data sources.

6. A general platform construction device for batch processing business systems, characterized in that, The apparatus for implementing the method as described in any one of claims 1-5 includes: The first-level splitting module is used to split batch processing business systems into multiple independent business units according to a single responsibility. Each business unit focuses on a single business objective and contains independent inputs, processing logic, and outputs. The secondary splitting module uses the data flow as the main backbone to split each business unit into a task sequence of orthogonal combinations of horizontal and vertical tasks. The horizontal tasks adjust the number of data flow records, the vertical tasks adjust the data flow field information, and the orthogonal combination of task sequences acts on the data flow sequentially from top to bottom. The three-level splitting module is used to match corresponding components for each horizontal or vertical task according to the task's operation type and data requirements. The components include a calculator and an accessor, and the accessor includes a cross-unit data flow accessor. The integration module is used to match components according to task type to form independent tasks, chain tasks into business units according to the data flow processing order, and realize the integration between business units through cross-unit data flow accessors. The output module outputs the structured data stream processed by the business unit to the outside world through a configurable mapping method.

7. The apparatus according to claim 6, characterized in that, The calculator includes a horizontal calculator, a vertical calculator, and a value calculator. The horizontal calculator is used to support the data stream quantity adjustment logic of the horizontal task. The vertical calculator is used to support the operation of adjusting the data stream content of the vertical task. The value calculator is used to support the per-data stream value calculation in the horizontal and vertical tasks.

8. The apparatus according to claim 7, characterized in that, The three-level splitting module includes a component matching unit. For horizontal tasks, the component matching unit matches an accessor and one horizontal calculator, or matches an accessor, an evaluation calculator, and one horizontal calculator. For append or modification operations in vertical tasks, it matches an evaluation calculator, an accessor, and one vertical calculator. For deletion operations in vertical tasks, it matches an accessor and one vertical calculator.

9. An electronic device, comprising: The processor, input device, output device, and memory are interconnected, the memory being used to store a computer program, the computer program including program instructions, characterized in that the processor is configured to invoke the program instructions to perform the method as described in any one of claims 1-5.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 1-5.

Images