A block model-based index generation method, execution method, and program product

Abstract

The application provides an index generation method, an execution method and a program product based on a building block model. Through a multi-dimensional model division mechanism, indexes originally coupled together are divided into different types of building block models, including index models, data models and algorithm models, from the dimensions of control scheduling, data acquisition and data processing. Furthermore, based on different business and index requirements, the arrangement and low code configuration of the related index models, data models and algorithm models can be completed based on a more flexible configuration granularity within the index, to form corresponding multi-dimensional data implementation strategies and multi-dimensional algorithm implementation strategies, and then generate a DAG route corresponding to the index model, thereby improving the flexibility and reusability of the index generation method. In the actual business execution process, the target DAG route can be quickly constructed based on the index calculation request, and then each node in the target DAG route is executed layer by layer to obtain the index result of the index calculation request, thereby improving the efficiency of obtaining the index result.

Description

Technical Field

[0001] This application relates to the field of business data processing, and more specifically, to a method for generating indicators based on a building block model, an execution method, and a program product. Background Technology

[0002] In the process of enterprise digital transformation, how to construct a data indicator system for the routine processing of indicator data in various departments of the enterprise, so as to quickly and scientifically build a data indicator system, is an urgent problem to be solved in the industry.

[0003] In existing technologies, metrics are often configured solely from a business scenario perspective. However, due to the coarse-grained nature of metric configuration, users need relevant business and technical knowledge to achieve low-code metric configuration. Furthermore, as business needs evolve rapidly, coarse-grained metric configuration often fails to ensure reusability.

[0004] Therefore, existing indicator construction schemes significantly reduce the efficiency and applicability of indicator calculation based on low-code indicator configurations. Summary of the Invention

[0005] The purpose of this application is to provide a method for generating, executing, and producing indicators based on a building block model, which can improve the efficiency and applicability of indicator calculation under low-code indicator configuration.

[0006] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows:

[0007] In a first aspect, embodiments of this application provide a method for generating indicators based on a building block model, comprising:

[0008] Based on business activity requirements, determine the corresponding development metrics through the configuration interface;

[0009] The development metrics include target building block models corresponding to the business activity requirements; each target building block model includes at least one metric model; each metric model is used to characterize the scheduling and control requirements of the target metrics in the business activity requirements; each metric model includes at least one data model and at least one algorithm model; the data model characterizes the data acquisition method corresponding to the scheduling and control requirements; the algorithm model characterizes the data processing method corresponding to the scheduling and control requirements.

[0010] The configuration interface allows for the configuration of a multidimensional data implementation strategy for each data model. The multidimensional data implementation strategy includes the implementation method of the data corresponding to the data model, at least one data source, and at least one data structure type.

[0011] The configuration interface allows for the configuration of a multi-dimensional algorithm implementation strategy for each algorithm model. The multi-dimensional algorithm implementation strategy includes at least one execution engine and at least one algorithmic approach corresponding to the algorithm model.

[0012] Based on the multidimensional data implementation strategy of each data model and the multidimensional algorithm implementation strategy of each algorithm model, a directed acyclic graph low-code route corresponding to the indicator model is generated; the directed acyclic graph low-code route represents the low-code execution path of the development indicator.

[0013] Secondly, embodiments of this application provide a metric execution method based on a building block model, including:

[0014] Based on the received indicator calculation request, identify the identification information of the target indicator model;

[0015] The construction information of the target indicator model is obtained based on the identification information of the target indicator model;

[0016] Based on the constructed information, the target directed acyclic graph low-code route corresponding to the target index model is analyzed layer by layer;

[0017] Based on the target directed acyclic graph low-code routing, the nodes in each layer are executed one by one from the bottom layer to the top layer until the target directed acyclic graph low-code routing is completed and the indicator result corresponding to the indicator calculation request is obtained; each node represents the target data model or target algorithm model under the target indicator model.

[0018] Thirdly, embodiments of this application provide an index generation device based on a building block model, comprising:

[0019] A configuration module is used to determine corresponding development metrics through a configuration interface based on business activity requirements. The development metrics include target building block models corresponding to the business activity requirements. Each target building block model includes at least one metric model. Each metric model characterizes the scheduling and control requirements of the target metrics in the business activity requirements. Each metric model includes at least one data model and at least one algorithm model. The data model characterizes the data acquisition method corresponding to the scheduling and control requirements. The algorithm model characterizes the data processing method corresponding to the scheduling and control requirements. The module is used to configure multi-dimensional data implementation strategies for each data model through the configuration interface. These multi-dimensional data implementation strategies include the data implementation method corresponding to the data model, at least one data source, and at least one data structure type. The module also configures multi-dimensional algorithm implementation strategies for each algorithm model through the configuration interface. These multi-dimensional algorithm implementation strategies include at least one execution engine and at least one algorithmic approach corresponding to the algorithm model.

[0020] The generation module is used to generate a directed acyclic graph low-code route corresponding to the indicator model based on the multidimensional data implementation strategy of each data model and the multidimensional algorithm implementation strategy of each algorithm model; the directed acyclic graph low-code route represents the low-code execution path of the development indicator.

[0021] Fourthly, embodiments of this application provide an index execution device based on a building block model, comprising:

[0022] The identification module is used to identify the identification information of the target indicator model based on the received indicator calculation request; and to obtain the construction information of the target indicator model based on the identification information of the target indicator model.

[0023] The parsing module is used to parse the target directed acyclic graph low-code route corresponding to the target index model layer by layer according to the construction information;

[0024] The execution module is used to execute the nodes in each layer from the bottom layer to the top layer one by one according to the target directed acyclic graph low-code routing, until the target directed acyclic graph low-code routing is completed and the indicator result corresponding to the indicator calculation request is obtained; each node represents the target data model or target algorithm model under the target indicator model.

[0025] Fifthly, embodiments of this application provide an electronic device, including:

[0026] Memory, used to store one or more programs;

[0027] processor;

[0028] When the one or more programs are executed by the processor, they implement the method as described in any one of the first aspects above; or, the method as described in any one of the second aspects above.

[0029] Sixthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method as described in any one of the first aspects above; or, the method as described in any one of the second aspects above.

[0030] In a seventh aspect, embodiments of this application provide a program product that, when executed by a processor, implements the method as described in any one of the first aspects above; or, the method as described in any one of the second aspects above.

[0031] Compared to existing technologies, the indicator generation method, execution method, and program product based on a building block model provided in this application decomposes the originally coupled indicators into different types of building block models—indicator models, data models, and algorithm models—through a multi-dimensional model partitioning mechanism: indicator model, data model, and algorithm model. Furthermore, based on different business and indicator requirements, the relevant indicator models, data models, and algorithm models can be orchestrated and configured with low-level code at a more flexible configuration granularity within the indicator to form corresponding multi-dimensional data implementation strategies and multi-dimensional algorithm implementation strategies. This generates a DAG route corresponding to the indicator model, thereby improving the flexibility and reusability of the indicator generation method. In actual business execution, the target DAG route can be quickly constructed based on the indicator calculation request, and then each node within it can be executed layer by layer to obtain the indicator result of the indicator calculation request, thereby improving the efficiency of obtaining the indicator result.

[0032] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0033] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded 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.

[0034] Figure 1 This is a schematic diagram illustrating the relationship between business activities and a building block model, provided as an embodiment of the present invention.

[0035] Figure 2 This is a schematic diagram of an index model generation path provided in an embodiment of the present invention;

[0036] Figure 3 This is a schematic diagram of a building block model according to an embodiment of the present invention;

[0037] Figure 4 A flowchart illustrating a method for generating indicators based on a building block model, provided in an embodiment of the present invention;

[0038] Figure 5 A flowchart illustrating another method for generating metrics based on a building block model provided in an embodiment of the present invention;

[0039] Figure 6 A flowchart illustrating another method for generating metrics based on a building block model provided in an embodiment of the present invention;

[0040] Figure 7 A schematic diagram of a data model construction provided in an embodiment of the present invention;

[0041] Figure 8 This is a schematic diagram of a multidimensional polymorphic development mechanism provided in an embodiment of the present invention;

[0042] Figure 9 A flowchart illustrating another method for generating metrics based on a building block model provided in an embodiment of the present invention;

[0043] Figure 10 A schematic diagram of a partial arrangement provided for an embodiment of the present invention;

[0044] Figure 11 A schematic diagram of a configuration interface for low-code development of a data model provided in an embodiment of the present invention;

[0045] Figure 12 A schematic diagram of a data source configuration interface provided in an embodiment of the present invention;

[0046] Figure 13 This is a schematic diagram of a configuration interface for low-code development of an algorithm model provided in an embodiment of the present invention;

[0047] Figure 14 A schematic diagram of an index design process provided in an embodiment of the present invention;

[0048] Figure 15 A schematic diagram of an indicator development process provided for the implementation of this invention;

[0049] Figure 16 A flowchart illustrating a metric execution method based on a building block model provided in an embodiment of the present invention;

[0050] Figure 17 A flowchart illustrating a metric execution method based on a building block model provided in an embodiment of the present invention;

[0051] Figure 18 A flowchart illustrating a metric execution method based on a building block model is provided in this embodiment of the invention.

[0052] Figure 19 A schematic diagram of an index generation device based on a building block model provided in an embodiment of the present invention;

[0053] Figure 20 A schematic diagram of a benchmark execution device based on a building block model provided in an embodiment of the present invention;

[0054] Figure 21 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0055] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0056] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0057] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. The terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0058] In the existing technology, during the digital transformation of enterprises, the configuration scheme of indicators can help enterprises quickly build a scientific and dynamic indicator system, reduce the threshold for data application, and achieve efficient business insights and decision support.

[0059] In existing technologies, configuring indicators mainly involves the following three steps:

[0060] 1) Pre-configured data source.

[0061] The original data source for indicators can be pre-specified within the system through methods such as encoding, SQL queries, and file reading, for example, by writing SQL statements to query the transaction order table in the database.

[0062] 2) Data source mapping to atomic metrics.

[0063] Data fields from pre-defined data sources are mapped to atomic indicators via interface configuration. For example, the purchase amount field in a transaction order table is directly mapped to the purchase amount indicator. Among them, atomic indicators are the most basic and indivisible indicators in the indicator system, with clear and singular business meanings.

[0064] 3) Atomic indicator configuration expressions are used to implement derived indicators.

[0065] Using atomic indicators, derived indicators can be created by configuring simple arithmetic expressions through the interface. For example, transaction amount can be used as a derived indicator by configuring the expression [buy amount + sell amount]. These derived indicators are based on atomic indicators and are created by combining them using certain calculation rules (such as addition, subtraction, multiplication, division, statistical functions, etc.) or fixed parameters (such as time range, business scenario, etc.).

[0066] However, the inventors discovered during real-world R&D that building an indicator platform solely based on metrics has the following problems:

[0067] 1) Pre-configured data sources are implemented through coding or SQL configuration, which poses a certain barrier for non-professionals. From a low-code perspective, it is impossible to achieve a code-free configuration process from 0 to 1.

[0068] 2) Low-code configuration indicators have a large granularity (the smallest being an atomic indicator), making it impossible to dynamically arrange and adjust the indicators internally to adapt to diverse business scenarios, resulting in relatively poor flexibility and reusability.

[0069] 3) The same indicator (with the same algorithm) cannot solve the problem of integrating heterogeneous data from multiple sources.

[0070] Taking the total assets indicator commonly used by financial institutions as an example, the data of the operations department comes from the valuation system, and the data of the investment department comes from the trading system. In the existing technical solution, the two departments will each set up a data source and define an indicator, resulting in duplicate data processing and indicator definition.

[0071] 4) The same indicator (same data) cannot solve the problem of local algorithm differences.

[0072] The sales department calculates sales growth based on actual transaction amount (actual customer payment), while the marketing department calculates sales growth based on actual transaction amount plus discount amount (because discounts are part of marketing promotion activities). Existing technical solutions would define these as two different metrics, increasing management and application complexity.

[0073] Therefore, the inventors, through research on the internal business activities of the metrics platform, discovered that simply decomposing the data structure from the metric dimension and then constructing the aforementioned metrics cannot solve the many problems mentioned above. Optionally, Figure 1 This is a schematic diagram illustrating the relationship between business activities and a building block model, provided as an embodiment of the present invention. (See attached diagram.) Figure 1The core improvement of this application lies in introducing the concept of a "building block model." This model refers to the model corresponding to each business activity after the original data structure for a specific indicator is broken down into multiple business activities corresponding to that indicator. For example, if the business activities within an indicator are broken down into control scheduling, data acquisition, and data processing, then for a given indicator, control scheduling corresponds to at least one building block model, data acquisition corresponds to at least one building block model, and / or data processing corresponds to at least one building block model.

[0074] Optionally, the building block model for the internal business activities of the above three indicators has three types: Building Block Model 1 - Indicator Model: used to indicate the control and scheduling of the corresponding indicator in the internal business activities; Building Block Model 2 - Data Model: used to indicate the data types involved in data acquisition and the matching data sources; Building Block Model 3 - Algorithm Model: used to indicate the algorithms involved in data processing. Furthermore, each model uses a multi-dimensional and polymorphic extension mechanism to achieve compatibility with multiple and heterogeneous data sources, compatibility with algorithm model calibers, and compatibility with multiple routes for indicators. For example, the indicator model can correspond to multiple Directed Acyclic Graph (DAG) routes: DAG route 1, DAG route 2, ..., DAG route n, etc.; the data model can correspond to multiple different data sources and data structures: DB, MQ, Cache, etc.; and the algorithm model can correspond to different algorithm calibers and different execution engines: Java, C++, and Python, etc.

[0075] Optionally, the indicator model can be divided into: atomic indicator models and derived indicator models. Both types of indicator models are generated through a basic building block model. Specifically, Figure 2 This is a schematic diagram of an index model generation path provided in an embodiment of the present invention. See [link / reference]. Figure 2 In the atomic indicator model, the data model is a necessary element, corresponding to the essential data acquisition in the indicator business activities. After data acquisition, it can be directly mapped to atomic indicators, or an algorithm model can be applied to jointly generate atomic indicators (the algorithm model corresponds to the processing and calculation in the indicator business activities).

[0076] In derived indicator models, since they are processed and calculated based on atomic or derived indicators (collectively referred to as indicator models in the diagram), indicator models and algorithm models are essential elements. Data models, as optional additional data sources, can also be used as components of derived indicator models.

[0077] This application, through the aforementioned multi-dimensional model partitioning mechanism, enables more refined configuration based on activities targeting different metrics in real-world scenarios. It also expands and orchestrates different building block models to address the problems of the existing technologies.

[0078] The following provides a schematic diagram of an indicator model, a data model, and an algorithm model, illustrating the relationship between the three. Specifically, Figure 3 This is a schematic diagram of a building block model according to an embodiment of the present invention. See also: Figure 3 In (a), the profit and loss data PL and cost data COST form the data model (light red quadrilateral), the profit and loss IPL forms the atomic indicator model (orange rectangle), the return algorithm DIV and standard deviation STD form the algorithm model (green diamond), and the daily return IR and return standard deviation IR_STD form the derived indicator model (blue rectangle). The corresponding... Figure 3 (b) in the diagram represents the corresponding DAG.

[0079] To illustrate how the "building block model" introduced in this application constructs indicators, the following provides a possible implementation of an indicator generation method based on the building block model. Specifically, Figure 4 A flowchart illustrating a method for generating metrics based on a building block model, as provided in this embodiment of the invention, is shown below. Figure 4 The method includes:

[0080] Step 100: Determine the corresponding development metrics through the configuration interface based on business activity requirements.

[0081] The development metrics include target building block models corresponding to business activity requirements; each target building block model contains at least one metric model; the metric model is used to characterize the scheduling and control requirements of the target metrics in the business activity requirements; each metric model contains at least one data model and at least one algorithm model; the data model characterizes the data acquisition method corresponding to the scheduling and control requirements; the algorithm model characterizes the data processing method corresponding to the scheduling and control requirements. For example... Figure 3 In (a), if the user wants to calculate the STD, then the STD is the development metric. If the user only wants to obtain the profit / loss IPL, then the profit / loss IPL is the development metric.

[0082] Step 101: Configure a multidimensional data implementation strategy for each data model through the configuration interface.

[0083] The multidimensional data implementation strategy includes the implementation method of the data model corresponding to the data, at least one data source, and at least one data structure type.

[0084] Step 102: Configure a multi-dimensional algorithm implementation strategy for each algorithm model through the configuration interface.

[0085] Optionally, the multidimensional algorithm implementation strategy includes at least one execution engine and at least one algorithm caliber corresponding to the algorithm model.

[0086] Regarding the algorithmic definitions, taking portfolio return as an example, there are two possible definitions: unit net asset value return (using unit net asset value to calculate portfolio return); and asset net asset value return (using asset net asset value and capital inflows and outflows to calculate portfolio return). Similarly, taking sales revenue as an example, there are two possible definitions: sales revenue = actual transaction amount (customer's actual payment); and sales revenue = actual transaction amount + discount amount. Therefore, these algorithmic definitions serve to indicate the specifications for the calculation logic, statistical rules, and business implications of implementing the corresponding algorithmic model.

[0087] Step 103: Based on the multidimensional data implementation strategy of each data model and the multidimensional algorithm implementation strategy of each algorithm model, generate the directed acyclic graph low-code route for the corresponding index model.

[0088] Optionally, the low-code execution path of the development metrics can be obtained by using a directed acyclic graph low-code routing representation.

[0089] The indicator generation method based on a building block model provided in this invention decomposes originally coupled indicators into different types of building block models—indicator models, data models, and algorithm models—through a multi-dimensional model partitioning mechanism. These models are based on dimensions such as control scheduling, data acquisition, and data processing. Furthermore, based on different business and indicator requirements, the relevant indicator models, data models, and algorithm models can be orchestrated and configured with low-level code at a more flexible configuration granularity within the indicator. This forms corresponding multi-dimensional data implementation strategies and multi-dimensional algorithm implementation strategies, thereby generating a DAG route corresponding to the indicator model. This improves the flexibility and reusability of the indicator generation method.

[0090] Optionally, regarding the determination of development metrics, the following is one possible implementation method. Specifically, in Figure 4 On this basis, Figure 5 A flowchart illustrating another method for generating metrics based on a building block model, as provided in this embodiment of the invention, is shown below. Figure 5 Step 100 includes:

[0091] Step 100-1: Determine the target block model using the block model library provided in the configuration interface.

[0092] Optionally, the block model library contains a variety of different block models. For the "indicator model," the indicator logic can be edited through user selection (click, drag), fuzzy matching suggestions, auto-completion, etc., thereby completing the no-code development of the indicator model.

[0093] For example, fuzzy matching prompts: if the building block model library has two indicator models, portfolio return rate A and portfolio return rate B, entering "portfolio return" will fuzzy match the above two indicators and display them in the configuration interface for the user to select. For example, auto-completion: if the building block model library has the portfolio return rate A indicator model (but not the portfolio return rate B model), entering "portfolio return" will fuzzy match the portfolio return rate A indicator, and auto-completion can be performed to reduce user operations.

[0094] Step 100-2: Extract the target data and target algorithm contained in the development indicators.

[0095] Step 100-3: Retrieve the data model corresponding to the target data from the building block model library.

[0096] Step 100-4: Retrieve the algorithm model corresponding to the target algorithm from the building block model library.

[0097] As can be seen from the above examples, since the user provided in this application can configure the data model involved in the indicator model with finer granularity through the configuration interface, it can realize the two-dimensional polymorphism implementation and mapping from attribute information to data source, thereby enabling indicator construction to access multiple mainstream data sources without code, thus solving the problems of data source not being able to be fully configured with low code and heterogeneous data silos in the existing technology.

[0098] Optionally, regarding the configuration of the algorithm model, the following provides a possible implementation method. Specifically, in Figure 4 On this basis, Figure 6 A flowchart illustrating another method for generating metrics based on a building block model, as provided in this embodiment of the invention, is shown below. Figure 6 Step 101 includes:

[0099] Step 101-1: Determine the basic data information of the data model through the configuration interface.

[0100] Step 101-2: Map at least one data source to each attribute information through the configuration interface.

[0101] The data source represents the source of the data for the corresponding data type.

[0102] Step 101-3: Determine at least one attribute information for each data model through the configuration interface.

[0103] Among them, attribute information represents at least one data type corresponding to development indicators.

[0104] Specifically, Figure 7 This is a schematic diagram of a data model construction provided in an embodiment of the present invention. See also: Figure 7For a data model, it can be divided into multiple attributes based on attribute type: attribute 1, attribute 2, ..., attribute n. Then, for each attribute, its corresponding data source can be mapped; for example, attribute 1 can be mapped to data sources such as database field A, message data field a, etc. Based on the data source, the interpreter to be invoked is determined. This interpreter performs simple data cleaning by parsing JSON extended configuration information, generating dynamic SQL queries to the database table, and executing a rule engine. No pre-developed data source or written SQL statements is required.

[0105] Step 102 includes:

[0106] Step 102-1: Determine the basic algorithm information of the algorithm model through the configuration interface.

[0107] The basic information of the algorithm includes the input data and output data corresponding to the corresponding data model.

[0108] Step 102-2: Select the corresponding execution engine and algorithm caliber for the algorithm model through the configuration interface.

[0109] Step 102-3: Determine the execution logic of the algorithm model through the configuration interface.

[0110] As can be seen from the above examples, since the user can configure the algorithm model involved in the indicator model through the configuration interface, the two-dimensional polymorphic implementation of the algorithm basic information and the execution engine can be realized. This can solve the redundant design and development of different algorithms for the same concept indicator in the prior art, reduce management and application complexity, support diverse algorithm execution engines, introduce rich algorithm libraries and custom algorithms, and support low-code development of complex algorithm models.

[0111] Optionally, steps 101 and 102 aim to provide a multi-dimensional and polymorphic development mechanism, such as scenarios involving multi-source heterogeneous data of the same indicator model or differences in algorithmic calibers of the same indicator model. The multi-dimensional data implementation strategy and multi-dimensional algorithm implementation strategy shown in the above examples of this application are illustrated below with a possible implementation method. Specifically, Figure 8 This is a schematic diagram of a multidimensional polymorphic development mechanism provided in an embodiment of the present invention. (See attached diagram.) Figure 8 The dimensions involved in the data model mainly include two dimensions: implementation method and multi-source heterogeneity.

[0112] The implementation methods include various forms of data acquisition such as mapping tables, message queues, SQL, caching, and HTTP interfaces. Multi-source heterogeneity enables polymorphic switching of data under the same data model by configuring multiple sets of data sources or mapping multiple structures.

[0113] See also Figure 8The main dimensions of this algorithm model include: execution engine and algorithm caliber.

[0114] The execution engine can execute its logic through processes such as Java, C++, and Python, and supports the integration of mature standard third-party algorithm libraries. Furthermore, it provides algorithmic definitions to address differences in algorithms for the same metric.

[0115] Optionally, for the indicator model, different combinations of data models and algorithm models can be used to construct different DAG routes; therefore, see [link to relevant documentation]. Figure 8 Each indicator model can correspond to multiple different DAG routes.

[0116] Alternatively, for DAG routing, see above. Figure 3 In (b), the DAG of the block model is drawn from top to bottom according to the hierarchical dependency relationship of the DAG as the product of the design stage.

[0117] Optionally, since the building block models in the examples above are clearly defined (with clear interface) and possess polymorphic extension characteristics, the configuration interface in this application example also has a dynamic adjustment function for DAG routing. It can perform local orchestration adjustments for DAG routing under the indicator model and achieve low-code configuration through a visual interface. Specifically, in Figure 4 On this basis, Figure 9 A flowchart illustrating another method for generating metrics based on a building block model, as provided in this embodiment of the invention, is shown below. Figure 9 Following step 103, the following is also included:

[0118] Step 104: Replace at least one subordinate node in the directed acyclic graph low-code route with the target subordinate node through the configuration interface.

[0119] Among them, the lower-level nodes correspond to the data model or algorithm model to be replaced; the target lower-level nodes correspond to the target data model or target algorithm model.

[0120] Specifically, the above text Figure 3 For example, in (b), Figure 10 This diagram illustrates a partial orchestration method provided in an embodiment of the present invention. For the index model IR_STD, its lower-level node, the algorithm model STD, can be implemented using the Java STD algorithm. Users can replace the node-algorithm model STD with an algorithm model STD_C implemented in C++ that supports vector computation through a configuration interface, thereby improving performance without affecting other lower-level nodes of the index model IR_STD. It is evident that the block-based architecture allows for more flexible construction of index models.

[0121] For the DAG routes generated by the configuration, one possible implementation is to start from the lowest-level nodes (leaf nodes) and proceed upwards layer by layer to complete the low-code configuration development. The following provides a possible implementation method for low-code development of the data model:

[0122] If the leaf node is a reusable building block model, skip this step. In this deconstruction design, the leaf node must be a data model; specifically... Figure 11 This is a schematic diagram of a configuration interface for low-code development of a data model provided in an embodiment of the present invention. (See also...) Figure 11 The following is an example of its low-code development configuration:

[0123] In the model information area of ​​the configuration interface, configure the basic data information of the data model, including the unique code of the data model, description information, etc.

[0124] In the model implementation area of ​​the configuration interface, select the data source (implementation type) of the data model. Taking the selection of database table type as an example, the interface will then display a list of database tables. The list content can be read from database management information or a preset list according to the permission settings.

[0125] In the model implementation area of ​​the configuration interface, after selecting a table name or entering a known table name, the table field information (field name, field description, data type, etc.) will be automatically displayed in the model attribute area of ​​the configuration interface. The primary key field is filled into the mapping field column of the input attribute area by default, and other fields are filled into the mapping field column of the output attribute area by default. The model attribute code column is automatically generated according to the field name and camelCase rules, and the data model attribute name column is automatically generated according to the field description. This step achieves batch automated configuration with simple operation, realizing the mapping between the unified attributes of the data model and the specific implementation table.

[0126] Based on the automated configuration, fine-tuning can be performed as needed, such as adding or removing attributes, adjusting names, etc. After completion, the configuration data is saved as the construction information of the data model and registered to the data model factory in the building block model library.

[0127] The development methods for other data source types, such as message queues, caches, files, and HTTP interfaces, are similar. The main focus is on establishing mapping relationships between data model attributes and various specific data structures, shielding heterogeneous data from different sources when applying the data model to the upper-level modular model. To simultaneously adapt to multiple data structure types and allow for flexible expansion, the data model's construction information is in semi-structured JSON format.

[0128] The above message data field is a description of the attributes of the data under the corresponding message queue.

[0129] Optionally, Figure 12 This is a schematic diagram of a data source configuration interface provided in an embodiment of the present invention. See also: Figure 12When the data source type is a message queue, its configuration interface can display real-time stream information and real-time stream data source configuration, which includes: data source connection, message format configuration, etc. As shown in Figure 12, the real-time stream information is the real-time stream encoding tradestream.

[0130] Optionally, for algorithm models, when the algorithm model has generality and reusability, low-code development of the algorithm model can be carried out, such as some commonly used statistical analysis algorithms (variance) and business model algorithms (VaR) in professional fields. Figure 13 This is a schematic diagram of a configuration interface for low-code development of an algorithm model provided in an embodiment of the present invention. (See attached diagram.) Figure 13 The following is an example of its low-code development configuration:

[0131] In the algorithm model information area of ​​the configuration interface, configure the basic algorithm information of the algorithm model, including unique code, algorithm name, input data sequence information, output result information, etc.

[0132] In the algorithm model implementation area of ​​the configuration interface, select the execution engine and algorithm. Taking the Java execution engine as an example, it is based on the high-performance, lightweight rule engine Aviator. You can write code snippets to implement business logic. Aviator has built-in commonly used functions and also supports custom functions (UDFs) to implement complex algorithms.

[0133] Configure the execution logic of the algorithm model, or select multiple algorithms to combine.

[0134] Save the configuration data as the construction information of the algorithm model (JSON format) and register it with the algorithm model factory in the building block model library.

[0135] Optionally, for low-code development of the indicator model, the configuration example is as follows:

[0136] In the indicator information area of ​​the interface, configure the basic information of the indicator, including the indicator code, indicator name, etc.

[0137] In the indicator editing area of ​​the interface, search for various block models that the indicator depends on from the block model repository, and complete the indicator configuration of the indicator model through an IDE-like interactive or drag-and-drop editing method, supplemented by operator commands.

[0138] Save the indicator model configuration data as indicator model construction information (JSON format) and register it in the indicator model factory in the building block model library.

[0139] Optionally, in the above example of this application, the configuration interface can dynamically adjust the nodes (block model) of the target DAG route in a visual way, thereby quickly adapting to business changes in an intuitive and low-cost manner.

[0140] Based on the above examples, and in conjunction with the appendix to this application... Figure 3 The design and development phases based on the block model involved in this application are illustrated by example.

[0141] Specifically, during the design phase, the examples provided in this application can follow a "top-down" design approach: that is, first clarify the development metrics, and then determine the corresponding target building block models, such as metric models, data models and / or algorithm models.

[0142] Optional, Figure 14 A schematic diagram of an indicator design process provided in an embodiment of the present invention is shown below. Figure 14 The design phase execution steps are as follows:

[0143] Step 1: Analyze and deconstruct the development indicators to obtain the target data and target algorithm required for the development indicators.

[0144] like Figure 3 As shown, if the development indicator is the standard deviation of returns "IR_STD", then according to the analysis structure, it can be confirmed that the data required for "IR_STD" includes: "Profit and Loss Data PL", "Cost Data COST", "Profit and Loss IPL", "Return Calculation", "Daily Return IR", and "Standard Deviation", etc. It should be noted that for some derived indicator models or atomic indicator models involved in some indicators, they can also be obtained through the analysis structure in step 1.

[0145] Step 2: In the building block model library, search based on the required data or algorithm to identify whether the data model corresponding to the data or the algorithm model corresponding to the algorithm is a reusable building block model.

[0146] It should be noted that if a derived index model or an atomic index model is parsed in step 1, a search will also be performed in step 2 to confirm whether it is a reusable building block model.

[0147] If yes, it means that existing block models in the block model library can be directly reused, i.e., proceed to step 3. If no, a new block model needs to be defined, i.e., proceed to step 5.

[0148] Step 3: Determine whether there are heterogeneous or heterogeneous data or algorithm differences in the data model or algorithm model;

[0149] If yes, proceed to step 4; otherwise, proceed to step 6.

[0150] Step 4: Perform polymorphic extension design on the data model or algorithm model.

[0151] The polymorphic extension design refers to matching different data sources for the data model; or matching different execution engines and different algorithmic approaches for the algorithm model.

[0152] Step 5: Define a new block model and register it to the block model library.

[0153] It should be noted that for the new block model obtained in step 5, step 3 can also be performed based on actual needs to confirm whether it needs to be configured in a heterogeneous or heterogeneous manner.

[0154] Step 6: Construct the DAG of development metrics based on the hierarchical dependencies between the metric model, data model, and algorithm model.

[0155] In one possible implementation, the DAG of the development metric can be used to represent the hierarchical dependencies between the development metric and various data and algorithms. To achieve low-code configuration, the following describes a bottom-up development DAG routing approach. The core logic is: for a development metric, configure it layer by layer from the bottom-most node of its DAG upwards.

[0156] Continue to combine Figure 3 Example illustration:

[0157] First, regarding the reference Figure 3 As shown in (a), the data models "Profit and Loss Data (PL)" and "Cost Data (COST)" are the lowest-level nodes in the DAG. Therefore, we first need to configure a multi-dimensional data implementation strategy for them. Optionally, Figure 15 A schematic diagram of an indicator development process provided for the implementation of this invention is shown below. Figure 15 The development phase involves the following steps:

[0158] For step 101 shown in the example above, one possible implementation process is as follows:

[0159] Step 1.1: Configure the basic data information of the data model.

[0160] The basic information in this data may include, but is not limited to: the unique code of the data model, descriptive information, etc.

[0161] Step 1.2: Configure the data source for the data model.

[0162] Here, the data source can refer to the specific implementation type of the data. Taking the selection of the database table type as an example, after selection, the interface will display a list of database tables. The list content can be read from database management information or a preset list according to the permission settings.

[0163] Step 1.3: Configure data model mapping.

[0164] Step 1.4: Save the construction information and register the block model library.

[0165] For step 102 shown in the example above, one possible implementation process is as follows:

[0166] Step 2.1: Configure the basic information of the algorithm model.

[0167] Step 2.2: Select the execution engine and algorithm.

[0168] Step 2.3: Configure the execution logic and algorithm combination of the algorithm model.

[0169] Step 2.4: Save the construction information and register the block model library.

[0170] After completing the configuration and development of the data model and indicator model, corresponding to step 103 above, one possible implementation flow for the configuration and development process of the corresponding indicator model is as follows:

[0171] Step 3.1: Configure the basic information of the indicators in the indicator model.

[0172] Step 3.2: Find and select the building block model and configure the editing indicator logic.

[0173] Step 3.3: Save the construction information and register the block model library.

[0174] Step 3.4: Reusability identification and saving as a framework model.

[0175] Optionally, if the indicator model developed in steps 3.1 to 3.3 is reusable, it can be saved as a framework model in step 3.4 for subsequent reuse.

[0176] Specifically, with Figure 3 Taking the data model PL as an example (PL is a unique code), create a new "Data Model PL" in the configuration interface, create an implementation method (valuation) under this data model, select "Valuation Database" as the corresponding data source, and display all data tables under this data source in the linked list. Select the table "portfolio_valuation" for automatic mapping. The system will analyze the table's primary key (such as portfolio_id, business_date) and business fields (such as valuation_pl), and automatically generate two input attributes portfolioId (query condition 1) and businessDate (query condition 2) and one output attribute pl (return result). After saving, its JSON representation is as follows.

[0177] {"impl_id":"valuation","tableName":"portfolio_valuation", "mappings":{"portfolioId":"portfolio_id","businessDate":"business_date","pl":"valuation_pl"}}

[0178] Where impl_id is the unique identifier ID of the current implementation, tableName is the table name, and the mappings node describes the one-to-one mapping relationship between the data model attributes and the table fields. In this example, portfolioId, businessDate, and pl are data model attributes, and portfolio_id, business_date, and valuation_pl are fields of the portfolio_valuation table.

[0179] At this point, if you want to expand multi-source heterogeneous data, you can create another implementation method (trading) under this data model. Select "trading database" as the corresponding data source, select the portfolio_trade table as the data table, and map the fields port_id, trade_date, and trade_pl based on the data model attributes defined above. After saving, its JSON representation is as follows.

[0180] {"impl_id":"trade","tableName":"portfolio_trade", "mappings":{"portfolioId":"port_id","businessDate":"trade_date","pl":"trade_pl"}}

[0181] It should be noted that during parsing and execution, the interpreter corresponding to the data model dynamically decides which implementation method to use based on context parameters, and constructs a dynamic SQL statement to query the data and obtain the results. An example of the constructed SQL statement is as follows:

[0182] The SQL statement example for constructing the valuation corresponding to the "implementation method" is as follows:

[0183] select portfolio_id,business_date,valuation_pl from portfolio_valuation where portfolio_id=? and business_date=?

[0184] The example SQL statement constructed according to the "implementation method" of the transaction is as follows:

[0185] select port_id,trade_date,trade_pl from portfolio_valuation whereport_id=? and trade_date=?

[0186] Based on the example above, the same method can be used to create the cost data model COST, which will not be repeated here.

[0187] See also Figure 3 As shown in (a), after completing the configuration and development of the underlying data model "Profit and Loss Data (PL)" and "Cost Data (COST)", the indicator model of the upper-level node can be configured and developed, or the multi-dimensional algorithm implementation strategy of the algorithm model can be configured, as follows:

[0188] Optionally, you can create an atomic indicator model in the configuration interface, taking the indicator model IPL as an example (IPL is a unique code).

[0189] Specifically, in the configuration interface, create a new "Indicator Model IPL", select its "Implementation Method" as a mapping table, select the output attribute pl of the data model PL created in step 1, and save to complete the indicator construction. Its JSON representation is as follows.

[0190] {"constructTemplate":"mapping","indicatorBricks":[{"brickCode":"PL$pl","brickType":"0"}]}

[0191] Where `constructTemplate` is the construction template type, corresponding to the "implementation method", which in this example is a mapping table. The `indicatorBricks` array represents the set of building block models that constitute the current indicator. In this example, there is only one building block model (PL). `brickCode` represents the specific model code and attributes, and `brickType` represents the model type. In this example, 0 represents the data model.

[0192] It should be noted that during parsing and execution, the interpreter of the indicator model selects the execution template according to the construction template type and executes it to obtain the indicator results.

[0193] Optionally, you can create an algorithm model in the configuration interface, taking the yield algorithm DIV as an example (DIV is a unique code).

[0194] Specifically, create a new "Algorithm Model DIV", and under this algorithm model, create a new "Implementation Method (Java)". Select "Java" as the execution engine, define the arithmetic expression as DIV=PL / COST, and save it. Its JSON identifier method is as follows.

[0195] {"impl_id":"div_java","engine":"java","arithmeticExpression":"DIV=PL / COST","params":[{"paramCode" :"PL","dataType":"0","index":"0"},{"paramCode":"COST","dataType":"0","index":"1"}],"result":"DIV"}

[0196] Where impl_id is the unique identifier ID of the current implementation, engine is the execution engine, arithmeticExpression is the arithmetic expression, params is the set of input parameters, and result is the output result value.

[0197] It should be noted that during parsing and execution, the interpreter corresponding to the algorithm model obtains the corresponding execution engine based on the engine identifier, and executes arithmeticExpression to obtain the algorithm output result.

[0198] Similar to data models, algorithmic models can also be polymorphically extended by adding an "implementation method" (such as C++).

[0199] See also Figure 3 As shown in (a), after completing the configuration of the underlying "algorithm model DIV", the derived index model of the upper-level node can be configured as follows:

[0200] Optionally, you can create a "derived indicator model" in the configuration interface, taking the daily return indicator model IR as an example (IR is a unique code).

[0201] Specifically, create a new "Indicator Model IR" in the configuration interface, select its "Implementation Method" as logical expression, select the profit and loss indicator model IPL, cost data model COST, and rate of return algorithm model DIV from the above steps, and implement the indicator business logic by dragging and dropping or entering and editing in the configuration page. After saving, its JSON representation is as follows.

[0202] {"constructTemplate":"expression","indicatorBricks":[{"brickCode":"IPL","brickType":"1"},{"brickCode":"COST$cos t","brickType":"0"},{"brickCode":"DIV","brickType":"2"}],"arithmeticExpression":{"expression":"IPL / COST$cost"}}

[0203] Here, "constructTemplate" is the construction template type, corresponding to "implementation method". In this example, it is a logical expression. The "indicatorBricks" array represents the set of building block models that constitute the current indicator. In this example, it includes the profit and loss indicator model IPL (brickType=1 represents the indicator model), the cost data model COST attribute cost (represented as COST$cost, brickType=0 represents the data model), and the rate of return algorithm model DIV (brickType=2 represents the algorithm model).

[0204] It should be noted that during parsing and execution, the interpreter corresponding to the indicator model selects the execution template according to the construction template type, parses the indicator dependencies and constructs a DAG, and executes the DAG layer by layer to obtain the indicator results.

[0205] As can be seen in the above example, the DAG corresponding to the development metric is determined through the "top-down" design phase, which reflects the hierarchical dependencies between various metric models, data models, and algorithm models under that development metric. Then, in the "bottom-up" development phase, the building block models corresponding to the nodes of each layer in the DAG under that development metric are configured. For example, multi-dimensional data implementation strategies are configured for data models; or multi-dimensional algorithm implementation strategies are configured for algorithm models; or atomic or derived metric models are configured, thus ultimately forming the DAG route corresponding to the metric model. It should be noted that this DAG route not only includes the execution path constructed from various building block models such as metric models, data models, and algorithm models, but also includes the configuration information of each building block model under each path, persisted based on the above design and development phases.

[0206] Building upon the aforementioned indicator generation method based on a block model, this application also provides an indicator execution method based on a block model, specifically involving two stages: indicator parsing and execution. For indicator parsing, a top-down parsing process is constructed based on DAG routing. For the parsed target DAG route, the entire execution process is completed using a bottom-up decaying hierarchical execution method. Specifically, Figure 16 A flowchart illustrating a metric execution method based on a building block model, provided in an embodiment of the present invention, is shown below. Figure 16 The method includes:

[0207] Step 200: Identify the identifier information of the target indicator model based on the received indicator calculation request.

[0208] Step 201: Obtain the construction information of the target indicator model based on the identification information of the target indicator model.

[0209] Step 202: Analyze the target DAG route corresponding to the target index model layer by layer based on the constructed information.

[0210] Step 203: Based on the target DAG route, execute the nodes in each layer from the bottom layer to the top layer one by one until the target directed acyclic graph low-code route is completed and the indicator result corresponding to the indicator calculation request is obtained.

[0211] Each node represents the target data model or target algorithm model under the target index model.

[0212] The indicator execution method based on a building block model provided in this invention, because the target indicator model is configured in a finer-grained manner, includes a corresponding target data model and a target algorithm model, it can quickly construct a target DAG route based on the indicator calculation request during actual business execution, and then execute each node in it layer by layer to obtain the indicator result of the indicator calculation request. Because the target indicator model has a finer configuration granularity, its corresponding target DAG route can be implemented in a low-code or code-free manner. At the same time, the target data model and target algorithm model have better flexibility and reusability, thereby improving the efficiency of obtaining indicator results.

[0213] Alternatively, for constructing the target DAG route, one possible implementation is provided below, specifically in... Figure 16 On this basis, Figure 17 A flowchart illustrating a metric execution method based on a building block model, provided in an embodiment of the present invention, is shown below. Figure 17 Step 202 includes:

[0214] Step 202-1: Determine the model type of the target index model based on the construction information.

[0215] Step 202-2: Call the corresponding model parser to parse the model according to its type.

[0216] Step 202-3: Based on the parsing results, create the corresponding node in the target DAG route.

[0217] Optionally, in addition to calling the model parser for parsing, the DAG creator can also be called to create nodes in the DAG route. Specifically, in Figure 17 On this basis, Figure 18 A flowchart illustrating a metric execution method based on a building block model provided in this embodiment of the invention is shown below. Figure 18 Step 202-3 includes:

[0218] Step 202-3a: Create indicator nodes corresponding to the target indicator model.

[0219] Then, based on the established indicator nodes, steps 202-1, 202-2, and 202-3 are re-executed. First, since the model type of the indicator node was determined to be "indicator model" in step 202-1, step 202-2 includes:

[0220] Step 202-2a: Determine if the target indicator model has a lower-level dependency.

[0221] If the specific solution exists, proceed to step 202-2b; otherwise, stop parsing.

[0222] Step 202-2b: Analyze the target indicator model according to the model parser corresponding to the target indicator model to determine the target data model and / or target algorithm model contained in the lower level of the indicator node.

[0223] Correspondingly, step 202-3 includes:

[0224] Step 202-3b: Create data nodes corresponding to the target data model; and / or,

[0225] Step 202-3c: Create the algorithm node corresponding to the target algorithm model.

[0226] Furthermore, for each layer's target data model and / or target algorithm model, it can be determined whether there are lower-level dependencies, and then the lower-level block model can be parsed and nodes created. Specifically, a possible implementation method is provided below:

[0227] Determine if the target data model has lower-level dependencies. If so, parse the model using the corresponding model parser to determine if the target data model contains corresponding lower-level target data models and / or lower-level target algorithm models; and / or,

[0228] If the target algorithm model has lower-level dependencies, it is determined that the target algorithm model contains corresponding lower-level target data models and / or lower-level target algorithm models.

[0229] Therefore, step 202-3 includes:

[0230] Create subordinate data nodes corresponding to the subordinate target data model; and / or,

[0231] Create the lower-level algorithm node corresponding to the lower-level target algorithm model.

[0232] Optionally, for step 203, it is based on the nodes of each level of the target DAG route, and is executed in a decaying layer from bottom to top. The following is a possible implementation:

[0233] Step 203-1: Create a DAG hierarchical list of the target DAG route, and initialize it as an empty set.

[0234] Step 203-2: Traverse the DAG nodes in the target DAG route and find the Sink Node (SN) with a degree of 0.

[0235] Here, the SN node can be understood as an edge in the target DAG route that does not point to other nodes, for example... Figure 3 In (b), the lowest level nodes include nodes PL and COST.

[0236] Step 203-3: Determine if an SN is found. If found, add all found SNs to the DAG layer list.

[0237] Step 203-4: Remove all SN nodes that have been added to the DAG hierarchical list from the target DAG route.

[0238] It should be noted that for each round of recursion, all number pairs (SNs) at the same level will eventually be added to the DAG layer list. Specifically, for the first round of recursion, such as... Figure 3 The nodes PL, COST, and DIV in (b) will all be added to the DAG layer list.

[0239] Step 203-5: Decrement the out-degree of the predecessor node of the target SN by 1. If the predecessor node depends on N SNs, then decrease the out-degree by N. At this time, a new SN may appear in the target DAG route.

[0240] Return to step 203-2 and execute recursively. The recursion terminates when it is determined in step 203-3 that there is no SN. This completes the bottom-up attenuation layering.

[0241] Specifically, continue with Figure 3 Taking (b) as an example, in the first round of recursion, the SN is obtained as node PL, node DIV, and node COST. The predecessor node of node PL is node IPL, so the out-degree of node IPL is reduced by 1. The predecessor nodes of nodes DIV and COST are both nodes IR, so the out-degree of node IR is reduced by 2. At this time, the out-degrees of nodes IPL and IR are both 0, so they become the new SN in the next round of recursion.

[0242] Step 203-6: Traverse the hierarchical list, and complete the process in parallel within each level.

[0243] Optionally, regarding the "dynamic adjustment function" involved in the "indicator generation method based on the block model" stage, in the "indicator execution method based on the block model" stage, the locally adjusted DAG routes can be maintained through a "priority routing table." One possible implementation is as follows:

[0244] Step 1: Design a priority routing table for metrics and record the default DAG routes.

[0245] The default DAG route can be a DAG route that has not been locally orchestrated.

[0246] Step 2: Provide a DAG routing management interface in the configuration interface. On the DAG routing management interface, click on the node to be orchestrated and adjusted in the DAG route to view its polymorphic model implementation.

[0247] Step 3: Select the appropriate model implementation method and click Save to update the metric priority routing table.

[0248] Step 4: When the metric is executed, read the metric priority routing table and use it as the highest priority DAG route.

[0249] Optionally, this highest-priority DAG route can be pre-configured by the user. If not configured, it can be executed based on the system's default DAG route.

[0250] To illustrate the steps and technical effects of the aforementioned block-based index generation method, this application also provides a block-based index generation device. Specifically, Figure 19 This is a schematic diagram of a block-based index generation device provided in an embodiment of the present invention. (See attached diagram.) Figure 19 The indicator generation device 30 based on the block model includes a configuration module 301 and a generation module 302.

[0251] The configuration module 301 is used to determine the corresponding development indicators through the configuration interface according to the needs of business activities; to configure multi-dimensional data implementation strategies for each data model through the configuration interface; and to configure multi-dimensional algorithm implementation strategies for each algorithm model through the configuration interface.

[0252] The generation module 302 is used to generate the DAG route of the corresponding indicator model based on the multidimensional data implementation strategy of each data model and the multidimensional algorithm implementation strategy of each algorithm model.

[0253] Optionally, the configuration module 301 is specifically used for: determining the target block model through the block model library provided by the configuration interface; determining at least one attribute information for each data model through the configuration interface; mapping at least one data source for each attribute information through the configuration interface; and constructing corresponding execution code for each data source through the interpreter.

[0254] Optionally, the configuration module 301 is specifically used for: determining the basic algorithm information of the algorithm model through the configuration interface; selecting the corresponding execution engine for the algorithm model through the configuration interface; and determining the execution logic of the algorithm model through the configuration interface.

[0255] Optionally, the configuration module 301 is specifically used to: replace at least one subordinate node in the directed acyclic graph low-code route with the target subordinate node through the configuration interface.

[0256] To illustrate the steps and technical effects of the aforementioned block-based indicator execution method, this application also provides a block-based indicator execution device. Specifically, Figure 20 This is a schematic diagram of a block-based index execution device provided in an embodiment of the present invention. (See attached diagram.) Figure 20 The indicator execution device 40 based on the block model includes: an identification module 401, a parsing module 402, and an execution module 403.

[0257] The identification module 401 is used to identify the identification information of the target indicator model according to the received indicator calculation request; and to obtain the construction information of the target indicator model according to the identification information of the target indicator model.

[0258] The parsing module 402 is used to parse the target directed acyclic graph low-code route corresponding to the target index model layer by layer according to the construction information.

[0259] The execution module 403 is used to execute the nodes in each layer from the bottom layer to the top layer according to the target directed acyclic graph low-code routing, until the target directed acyclic graph low-code routing is completed and the indicator result corresponding to the indicator calculation request is obtained.

[0260] Optionally, the parsing module 402 is specifically used for: determining the model type of the target indicator model based on the construction information; calling the corresponding model parser to perform parsing based on the model type; and creating the corresponding node in the target directed acyclic graph low-code route based on the parsing result.

[0261] Optionally, the parsing module 402 is specifically used for: creating indicator nodes corresponding to the target indicator model; determining whether the target indicator model has lower-level dependencies, and if so, parsing according to the model parser corresponding to the target indicator model to determine the target data model and / or target algorithm model contained in the lower level of the indicator node; creating data nodes corresponding to the target data model; and / or creating algorithm nodes corresponding to the target algorithm model.

[0262] Optionally, the parsing module 402 is specifically used for: determining whether the target data model has lower-level dependencies; if so, parsing according to the model parser corresponding to the target data model to determine whether the target data model contains corresponding lower-level target data models and / or lower-level target algorithm models; and / or determining whether the target algorithm model has lower-level dependencies; if so, parsing according to the model parser corresponding to the target algorithm model to determine whether the target algorithm model contains corresponding lower-level target data models and / or lower-level target algorithm models; creating lower-level data nodes corresponding to the lower-level target data models; and / or creating lower-level algorithm nodes corresponding to the lower-level target algorithm models.

[0263] This invention also provides an electronic device that can execute all the steps of the examples described above to achieve the corresponding technical effects. Specifically, Figure 21 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. See also: Figure 21 The electronic device 50 includes: a memory 501 and a processor 500;

[0264] Memory 501 is used to store one or more programs;

[0265] Processor 500;

[0266] When one or more programs are executed by a processor, the electronic device 50 can achieve the steps and corresponding technical effects when it performs the steps shown in the above method examples.

[0267] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0268] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0269] If a function is implemented as a software module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a program product. This program product is stored in a computer-readable storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0270] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

[0271] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within this application. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A method for generating indicators based on a building block model, characterized in that, include: Based on business activity requirements, determine the corresponding development metrics through the configuration interface; The development metrics include target building block models corresponding to the business activity requirements. The target building block model decomposes the data structure of the development metrics into models corresponding to the following types of business activities: at least one metric model, at least one data model, and at least one algorithm model. The metric model is used to characterize the scheduling and control requirements of the target metrics in the business activity requirements. The data model characterizes the data acquisition method corresponding to the scheduling and control requirements. The algorithm model characterizes the data processing method corresponding to the scheduling and control requirements. The configuration interface allows for the configuration of a multidimensional data implementation strategy for each data model. The multidimensional data implementation strategy includes the implementation method of the data corresponding to the data model, at least one data source, and at least one data structure type. The configuration interface allows for the configuration of a multi-dimensional algorithm implementation strategy for each algorithm model. The multi-dimensional algorithm implementation strategy includes at least one execution engine and at least one algorithmic approach corresponding to the algorithm model. Based on the multidimensional data implementation strategy of each data model and the multidimensional algorithm implementation strategy of each algorithm model, a directed acyclic graph low-code route corresponding to the indicator model is generated; the directed acyclic graph low-code route represents the low-code execution path of the development indicator; each indicator model includes at least one data model and at least one algorithm model; The configuration interface allows you to replace at least one lower-level node in the directed acyclic graph low-code route with a target lower-level node; the lower-level node corresponds to the data model or algorithm model to be replaced; the target lower-level node corresponds to the target data model or target algorithm model.

2. The method according to claim 1, characterized in that, Following the step of determining the corresponding development metrics through the configuration interface based on business activity requirements, the method further includes: The target block model is determined using the block model library provided by the configuration interface; the block model library contains multiple block models. Extract the target data and target algorithm contained in the development metrics; Retrieve the data model corresponding to the target data from the building block model library; Retrieve the algorithm model corresponding to the target algorithm from the building block model library.

3. The method according to claim 1, characterized in that, The step of configuring a multidimensional data implementation strategy for each data model through the configuration interface includes: The basic data information of the data model is determined through the configuration interface; The configuration interface determines at least one attribute information for each data model; the attribute information represents at least one data type corresponding to the development metric. The configuration interface maps at least one data source to each attribute information; the data source represents the data source of the corresponding data type. The step of configuring a multi-dimensional algorithm implementation strategy for each algorithm model through the configuration interface includes: The basic information of the algorithm model is determined through the configuration interface. The basic information of the algorithm includes the input data and output data corresponding to the corresponding data model. Select the corresponding execution engine and algorithm caliber for the algorithm model through the configuration interface; The execution logic of the algorithm model is determined through the configuration interface.

4. A method for implementing metrics based on a building block model, characterized in that, include: Based on the received indicator calculation request, identify the identification information of the target indicator model; The construction information of the target indicator model is obtained based on the identification information of the target indicator model; Based on the constructed information, the target directed acyclic graph low-code route corresponding to the target index model is analyzed layer by layer; The target directed acyclic graph low-code route is generated by the index generation method based on the building block model according to any one of claims 1-3; Based on the target directed acyclic graph low-code routing, the nodes in each layer are executed one by one from the bottom layer to the top layer until the target directed acyclic graph low-code routing is completed and the indicator result corresponding to the indicator calculation request is obtained; each node represents the target data model or target algorithm model under the target indicator model.

5. The method according to claim 4, characterized in that, The step of parsing the target directed acyclic graph low-code route corresponding to the target index model layer by layer according to the constructed information includes: The model type of the target index model is determined based on the constructed information; The corresponding model parser is invoked to perform parsing based on the model type; Based on the parsing results, create the corresponding node in the target directed acyclic graph low-code route.

6. The method according to claim 5, characterized in that, The step of creating the corresponding node in the low-code route of the target directed acyclic graph based on the parsing result includes: Create the indicator nodes corresponding to the target indicator model; The step of calling the corresponding model parser to perform parsing according to the model type includes: If the target indicator model has a lower-level dependency, then the model is parsed according to the model parser corresponding to the target indicator model to determine the target data model and / or target algorithm model contained in the lower level of the indicator node. The step of creating the corresponding node in the low-code route of the target directed acyclic graph based on the parsing result includes: Create data nodes corresponding to the target data model; and / or, Create the algorithm node corresponding to the target algorithm model.

7. The method according to claim 6, characterized in that, The step of calling the corresponding model parser to perform parsing according to the model type includes: If the target data model has lower-level dependencies, it is determined that the target data model contains corresponding lower-level target data models and / or lower-level target algorithm models; and / or, If the target algorithm model has a lower-level dependency, then the model is parsed according to the model parser corresponding to the target algorithm model to determine that the target algorithm model contains a corresponding lower-level target data model and / or a lower-level target algorithm model. The step of creating the corresponding node in the low-code route of the target directed acyclic graph based on the parsing result includes: Create the lower-level data nodes corresponding to the lower-level target data model; and / or, Create the lower-level algorithm node corresponding to the lower-level target algorithm model.

8. An index generation device based on a block model, characterized in that, include: A configuration module is used to determine corresponding development metrics through a configuration interface based on business activity requirements. The development metrics include target building block models corresponding to the business activity requirements. Each target building block model decomposes the data structure of the development metrics into models corresponding to the following types of business activities: at least one metric model, at least one data model, and at least one algorithm model. The metric model represents the scheduling and control requirements of the target metrics in the business activity requirements. The data model represents the data acquisition method corresponding to the scheduling and control requirements. The algorithm model represents the data processing method corresponding to the scheduling and control requirements. A multi-dimensional data implementation strategy is configured for each data model through the configuration interface. This multi-dimensional data implementation strategy includes the data implementation method corresponding to the data model, at least one data source, and at least one data structure type. A multi-dimensional algorithm implementation strategy is configured for each algorithm model through the configuration interface. This multi-dimensional algorithm implementation strategy includes at least one execution engine and at least one algorithmic approach corresponding to the algorithm model. The generation module is used to generate a directed acyclic graph low-code route corresponding to the indicator model based on the multidimensional data implementation strategy of each data model and the multidimensional algorithm implementation strategy of each algorithm model; the directed acyclic graph low-code route represents the low-code execution path of the development indicator; each indicator model includes at least one data model and at least one algorithm model; The configuration module is further configured to replace at least one lower-level node in the directed acyclic graph low-code routing with a target lower-level node through a configuration interface; the lower-level node corresponds to the data model to be replaced or the algorithm model to be replaced; the target lower-level node corresponds to the target data model or the target algorithm model.

9. A pointer execution device based on a block model, characterized in that, include: The identification module is used to identify the identification information of the target indicator model based on the received indicator calculation request; and to obtain the construction information of the target indicator model based on the identification information of the target indicator model. The parsing module is used to parse the target directed acyclic graph low-code route corresponding to the target index model layer by layer according to the construction information; The target directed acyclic graph low-code route is generated by the index generation method based on the building block model according to any one of claims 1-3; The execution module is used to execute the nodes in each layer from the bottom layer to the top layer one by one according to the target directed acyclic graph low-code routing, until the target directed acyclic graph low-code routing is completed and the indicator result corresponding to the indicator calculation request is obtained; each node represents the target data model or target algorithm model under the target indicator model.

10. An electronic device, characterized in that, include: Memory, used to store one or more programs; processor; When the one or more programs are executed by the processor, the method of any one of claims 1-3 is implemented; or, the method of any one of claims 4-7 is implemented.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-3; or, as described in any one of claims 4-7.

12. A program product, characterized in that, When the program product is executed by the processor, it implements the method as described in any one of claims 1-3; or, the method as described in any one of claims 4-7.

Images