Index data aggregation method, device and equipment based on recursive multi-level down drilling

Abstract

The application discloses a kind of based on recursive multi-level drilling index data aggregation method, device and equipment, it is related to big data technical field, including: in response to received screening condition, according to preset rule, unconfigured condition node is checked and verified, determine the node state of unconfigured condition node, condition tree is recursively generated based on screening condition and node state, the condition group node of condition tree is semantically parsed and logically parsed, and optimization processing is carried out based on algebraic simplification rule, generates optimization query logic, according to optimization query logic and preset index information, the storage location of each index data in data storage system is parsed, data aggregation processing is carried out based on storage location, and aggregation result is obtained, and aggregation result is output to update drill view;The application achieves the effect that the flexibility and dynamic expansibility of data query are enhanced, the complex analysis capability of supporting multi-level unlimited drilling is achieved, end-to-end interaction delay is reduced, and the real-time accuracy of query result is guaranteed.

Description

Technical Field

[0001] This application relates to the field of big data technology, and in particular to a method, apparatus and equipment for index data aggregation based on recursive multi-level drill-down. Background Technology

[0002] In the vast financial market, there are hundreds of thousands of fund products, diverse in type and complex in structure. Financial industry professionals need to conduct in-depth analysis of these fund products, including assessing their historical performance, risk characteristics, return levels, and market rankings, to provide a scientific basis for investment decisions. At the same time, horizontal comparison of similar fund products can help identify high-quality funds in the market and provide a reference for asset allocation.

[0003] However, when faced with a massive pool of fund products and indicators, professionals in the financial industry often need to construct screening criteria from this vast pool of products and multi-dimensional indicators to meet diverse analytical needs. This process is extremely time-consuming and labor-intensive, especially given the highly time-sensitive and dynamically changing nature of financial data. Traditional static analysis tools struggle to meet the demands of real-time, dynamically updated data.

[0004] The complexity of financial data is reflected in the need for multi-dimensional and multi-indicator cross-analysis, high-frequency data updates and timeliness requirements, and multi-level data structures. The financial industry urgently needs an efficient data analysis tool that can quickly aggregate massive amounts of indicator data, support flexible configuration of dynamic indicators, meet the needs of recursive deep composite queries, and realize unlimited drill-down capabilities at multiple levels on the front end. Summary of the Invention

[0005] The main objective of this application is to provide a method, apparatus, and device for index data aggregation based on recursive multi-level drill-down, which achieves the effects of enhancing the flexibility and dynamic scalability of data query, supporting complex analysis capabilities with unlimited multi-level drill-down, reducing end-to-end interaction latency, and ensuring the real-time accuracy of query results.

[0006] To achieve the above objectives, this application proposes a recursive multi-level drill-down-based index data aggregation method, including: In response to the received filtering conditions, dynamic constraint verification is performed on nodes without configured conditions according to preset business rules to determine the node status of the nodes without configured conditions, and a condition tree is recursively generated based on the filtering conditions and the node status; wherein, the condition tree includes multi-level nested condition group nodes. Semantic and logical parsing are performed on the condition group nodes of the condition tree, and the condition tree is optimized based on algebraic simplification rules to generate optimized query logic; Based on the optimized query logic and preset indicator information, the storage location of each indicator data in the data storage system is dynamically parsed, data aggregation processing is performed based on the storage location to obtain the aggregation result, and the aggregation result is output to update the drill-down view.

[0007] In one embodiment, in response to the received filtering conditions, dynamic constraint verification is performed on nodes without configured conditions according to preset business rules to determine the node status of the nodes without configured conditions, and a condition tree is recursively generated based on the filtering conditions and the node status, including: Receive filter conditions input by the user through the interactive interface, and obtain the configured condition nodes based on the filter conditions; The node status of the unconfigured condition node is determined based on the dependency relationships and conflict rules in the preset business rules; The node state is rendered to the corresponding unconfigured condition node to update the display state in the interactive interface; The condition tree is recursively generated based on the filtering conditions configured by the user based on the updated display status and the availability status of the nodes without configured conditions.

[0008] In one embodiment, the step of performing semantic and logical parsing on the condition group nodes of the condition tree, and optimizing the condition tree based on algebraic simplification rules to generate optimized query logic includes: Semantic parsing is performed on the condition group nodes of the condition tree to obtain atomic conditions and composite conditions; wherein, the composite condition includes at least one logical operator; The atomic conditions and the composite conditions are sorted according to a preset logical priority rule to obtain a sorted condition tree; The sorted condition tree is iteratively simplified and flattened based on algebraic simplification rules, and the optimized query logic is output.

[0009] In one embodiment, the step of dynamically parsing the storage location of each indicator data in the data storage system based on the optimized query logic and preset indicator information includes: Obtain the indicator identifier in the optimized query logic; Based on the indicator metadata model recorded in the preset indicator information, match the storage field path corresponding to the indicator identifier.

[0010] In one embodiment, after matching the storage field path corresponding to the indicator identifier, the method further includes: When the same metric corresponds to different storage field paths in different data records, it automatically adapts to the corresponding path differences.

[0011] In one embodiment, the step of performing data aggregation processing based on the storage location to obtain an aggregation result, and outputting the aggregation result to update the drill-down view, includes: Based on the storage location obtained from the parsing, the original data is retrieved from the data storage system; The original data is subjected to data aggregation processing to obtain the aggregation result; Output the aggregation result, trigger the update of the current level drill-down view, and re-render the drill-down options of the next level according to the updated level drill-down view.

[0012] In one embodiment, the step of performing data aggregation processing based on the storage location to obtain the aggregation result further includes: When the aggregation result involves dynamic indicator calculation, identify the shared calculation path in different data aggregation processes; Based on the shared computation path, the cached intermediate aggregation results are obtained, the intermediate aggregation results are merged, and then output.

[0013] In one embodiment, prior to the data aggregation processing based on the storage location, the method further includes: A cache key is generated based on the optimized query logic and the storage location, and the aggregation result corresponding to the cache key is searched in the cache. If an aggregation result corresponding to the cache key exists in the cache, the aggregation result in the cache is returned directly, and the query instruction is skipped. If the cache does not contain an aggregation result corresponding to the cache key, the query instruction is executed, and the obtained aggregation result is written to the cache.

[0014] Furthermore, to achieve the above objectives, this application also proposes an index data aggregation device based on recursive multi-level drill-down, the device comprising: The recursive condition tree module is used to respond to the received filtering conditions, perform dynamic constraint verification on the unconfigured condition nodes according to the preset business rules, determine the node status of the unconfigured condition nodes, and recursively generate a condition tree based on the filtering conditions and the node status. The query optimization module is used to perform semantic and logical parsing on the condition group nodes of the condition tree, and optimize the condition tree based on algebraic simplification rules to generate optimized query logic. The query aggregation module is used to dynamically parse the storage location of each indicator data in the data storage system according to the optimized query logic and preset indicator information, perform data aggregation processing based on the storage location, obtain the aggregation result, and output the aggregation result to update the drill-down view.

[0015] Furthermore, to achieve the above objectives, this application also proposes an index data aggregation device based on recursive multi-level drilling. The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. The computer program is configured to implement the steps of the index data aggregation method based on recursive multi-level drilling as described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: By responding to received filtering conditions, dynamically constraining and verifying nodes without configured conditions according to preset business rules, determining the node status of nodes without configured conditions, recursively generating a condition tree based on filtering conditions and node status, performing semantic and logical parsing on the condition group nodes of the condition tree, and optimizing the condition tree based on algebraic simplification rules to generate optimized query logic, dynamically parsing the storage location of each indicator data in the data storage system based on the optimized query logic and preset indicator information, performing data aggregation processing based on the storage location to obtain the aggregation result, and outputting the aggregation result to update the drill-down view; by dynamically constraining and verifying nodes without configured conditions, the error rate of condition configuration is reduced and the filtering efficiency is improved. The improved efficiency of condition configuration is achieved by recursively generating a condition tree containing multi-level nested condition groups on the front end, supporting unlimited drill-down levels. This satisfies the needs of financial professionals for multi-dimensional and multi-level in-depth cross-analysis of massive amounts of fund products. The condition tree is optimized through semantic parsing, logical parsing, and algebraic simplification rules, eliminating redundant logical nodes, simplifying the query structure, and improving the execution efficiency of subsequent data aggregation processing. By returning the aggregation results to the front end to update the drill-down view, a recursive drill-down interaction loop of "filtering - results - re-filtering - re-results" is formed. This enhances the flexibility and dynamic scalability of data queries, supports complex analysis capabilities with unlimited multi-level drill-down, reduces end-to-end interaction latency, and ensures the real-time accuracy of query results. Attached Figure Description

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

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating the first embodiment of the index data aggregation method based on recursive multi-level drill-down in this application. Figure 2This is an optional flowchart of step S101 in the first embodiment of the index data aggregation method based on recursive multi-level drill-down in this application. Figure 3 This is an optional flowchart of step S102 in the first embodiment of the index data aggregation method based on recursive multi-level drill-down in this application; Figure 4 This is an optional flowchart of step S103, parsing the storage location, in the first embodiment of the index data aggregation method based on recursive multi-level drill-down in this application. Figure 5 This is an optional flowchart following step S402 in the first embodiment of the index data aggregation method based on recursive multi-level drill-down in this application. Figure 6 This is an optional flowchart of step S103 of the aggregation process in the first embodiment of the index data aggregation method based on recursive multi-level drill-down in this application. Figure 7 This is an alternative flowchart for the aggregation process in step S103 of the first embodiment of the index data aggregation method based on recursive multi-level drill-down in this application; Figure 8 This is an optional flowchart before the aggregation process in step S103 in the first embodiment of the index data aggregation method based on recursive multi-level drill-down in this application. Figure 9 This is a schematic diagram of a module of an index data aggregation device based on recursive multi-level drill-down according to an embodiment of this application; Figure 10 This is a schematic diagram of the structure of an index data aggregation device based on recursive multi-level drilling, according to an embodiment of this application. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] The main solution of this application embodiment is as follows: In response to received filtering conditions, dynamic constraint verification is performed on nodes without configured conditions according to preset business rules to determine the node status of nodes without configured conditions. A condition tree is recursively generated based on the filtering conditions and node status. Semantic and logical parsing is performed on the condition group nodes of the condition tree. The condition tree is then optimized based on algebraic simplification rules to generate optimized query logic. Based on the optimized query logic and preset indicator information, the storage location of each indicator data in the data storage system is dynamically parsed. Data aggregation is performed based on the storage location to obtain the aggregation result, and the aggregation result is output to update the drill-down view. By performing dynamic constraint verification on nodes without configured conditions, the error rate of condition configuration is reduced and the efficiency of filtering condition configuration is improved. The system achieves the desired effect by recursively generating a condition tree containing multi-level nested condition groups on the front end, supporting unlimited drill-down levels. This meets the needs of financial professionals for multi-dimensional and multi-level in-depth cross-analysis of massive fund products. By optimizing the condition tree through semantic parsing, logical parsing, and algebraic simplification rules, it eliminates redundant logical nodes, simplifies the query structure, and improves the execution efficiency of subsequent data aggregation processing. By returning the aggregation results to the front end to update the drill-down view, a recursive drill-down interaction loop of "filtering - results - re-filtering - re-results" is formed. This enhances the flexibility and dynamic scalability of data queries, supports complex analysis capabilities with unlimited multi-level drill-down, reduces end-to-end interaction latency, and ensures the real-time accuracy of query results.

[0023] In the vast financial market, there are hundreds of thousands of fund products, diverse in type and complex in structure. Financial industry professionals need to conduct in-depth analysis of these products, including assessing their historical performance, risk characteristics, return levels, and market rankings, to provide a scientific basis for investment decisions. Simultaneously, horizontal comparisons of similar fund products can help identify high-quality funds in the market, providing a reference for asset allocation. For researchers and investment managers, analyzing the performance of different fund products is not only the foundation for investment strategy formulation but also provides data support for the design and optimization of new fund products. Meanwhile, risk management departments need to monitor fund drawdowns, risk indicators, and market volatility in real time, promptly identify potential risk events, and achieve automated risk monitoring and management by setting risk warning indicators.

[0024] However, when faced with a massive pool of fund products and indicators, professionals in the financial industry often need to construct screening criteria from this vast pool of products and multi-dimensional indicators to meet diverse analytical needs. This process is extremely time-consuming and labor-intensive, especially given the highly time-sensitive and dynamically changing nature of financial data. Traditional static analysis tools struggle to meet the demands of real-time, dynamically updated data.

[0025] The complexity of financial data manifests in the need for multi-dimensional, multi-indicator cross-analysis, high-frequency data updates and timeliness requirements, and multi-level data structures. The financial industry urgently needs an efficient data analysis tool capable of rapidly aggregating massive amounts of indicator data, supporting flexible configuration of dynamic indicators, meeting the needs of recursive, deep, and complex queries, and enabling unlimited drill-down capabilities across multiple levels on the front end. Such a tool would not only significantly improve data analysis efficiency but also provide powerful support for investment decisions, risk management, product design, and market competitiveness monitoring.

[0026] This application provides a solution that reduces the error rate of condition configuration and improves the efficiency of filtering condition configuration by dynamically constraining and validating unconfigured condition nodes. It recursively generates a condition tree containing multi-level nested condition groups on the front end, supporting unlimited drill-down levels. This meets the needs of financial professionals for multi-dimensional and multi-level in-depth cross-analysis of massive amounts of fund products. The condition tree is optimized through semantic parsing, logical parsing, and algebraic simplification rules, eliminating redundant logical nodes, simplifying the query structure, and improving the execution efficiency of subsequent data aggregation processing. By returning the aggregation results to the front end to update the drill-down view, a recursive drill-down interaction loop of "filtering—results—re-filtering—re-results" is formed. This achieves enhanced data query flexibility and dynamic scalability, supports complex analysis capabilities with unlimited multi-level drill-down, reduces end-to-end interaction latency, and ensures the real-time accuracy of query results.

[0027] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of performing the above functions, a recursive multi-level drilling-based index data aggregation device, or other similar equipment. The following description uses a recursive multi-level drilling-based index data aggregation device as an example to illustrate this embodiment and the subsequent embodiments.

[0028] Based on this, the embodiments of this application provide a method for aggregating index data based on recursive multi-level drill-down, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the index data aggregation method based on recursive multi-level drill-down in this application.

[0029] In this embodiment, the index data aggregation method based on recursive multi-level drill-down includes steps S101 to S103. The following provides a detailed explanation of each step.

[0030] The method for aggregating index data based on recursive multi-level drill-down includes: Step S101: In response to the received filtering conditions, perform dynamic constraint verification on nodes without configured conditions according to preset business rules, determine the node status of nodes without configured conditions, and recursively generate a condition tree based on the filtering conditions and node status.

[0031] In some embodiments of this application, users input or modify filter conditions through a condition setting interface that supports multi-level nesting, such as selecting a certain indicator, operator, and value. Upon receiving the user's operation, constraint checks on all relevant nodes within the condition group are immediately triggered, rather than waiting until the user submits all conditions before unified verification. The system traverses the unconfigured condition nodes within the current condition group, determining whether each unconfigured node is allowed to be selected, should be hidden, or disabled based on preset business rules and the values ​​of configured nodes. After constraint verification, each unconfigured condition node is assigned a node state, such as: available, hidden, or disabled. This state is fed back to the front-end interface in real time, updating the rendering properties of the corresponding controls, ensuring that users can only configure reasonable and consistent combinations of conditions. The user-input filter conditions are merged with the node states after dynamic constraint verification to generate a condition tree carrying business semantics. The final generated condition tree not only contains the filter conditions actually configured by the user, i.e., condition nodes, but also integrates logical relationship nodes and condition group nodes. The available state of each node is marked in the tree structure, enabling the condition tree to carry complete business semantics.

[0032] It should be noted that the preset business rules are derived from the financial indicator metadata model, which defines the dependencies and conflict rules between various condition nodes. For example, when a user has selected "2026", the month condition can only be selected up to the "current month"; when a "stock" fund has been selected, the "bond" sub-condition will be automatically disabled.

[0033] Step S102: Perform semantic and logical parsing on the condition group nodes of the condition tree, and optimize the condition tree based on algebraic simplification rules to generate optimized query logic.

[0034] In some embodiments of this application, each condition node is converted into an atomic condition object, and condition group nodes and their logical relationships are converted into composite condition objects, while preserving the hierarchical structure to form a "condition logic tree." According to a preset rule, the priority is NOT > AND > OR, meaning the NOT operation takes precedence over the AND operation, and the AND operation takes precedence over the OR operation. The condition logic tree is then normalized, sorted, and reorganized based on this priority, making the previously implicit priorities explicit and ensuring that subsequent simplification and transformation do not produce ambiguity. Expression Based on priority, it should be resolved as Instead Simultaneously, the scope of the NOT operation is identified and processed, pushing NOT down to the atomic condition level. The condition tree after semantic and logical parsing may contain redundant nodes or repetitive expressions, directly impacting database query efficiency. By introducing an algebraic simplification mechanism for document-oriented database queries, and based on the fundamental laws of Boolean algebra, the condition tree undergoes multiple rounds of iterative simplification and flattening. During the simplification process, each round scans the condition tree, applying all applicable rules until the tree structure no longer changes, resulting in a concise, flattened, optimized query logic tree.

[0035] It should be noted that commonly used rules for algebraic simplification include, but are not limited to: The idempotency law is used to eliminate repeated atomic conditions. The absorption law is used to remove redundant branches when a condition already includes a broader set of conditions. The law of multiple negation is used to eliminate multiple negations; The associative and distributive laws are used to flatten tree structures, merging multiple levels of nested identical logical operators into a single level, thus reducing the depth of the tree.

[0036] It should be noted that algebraic simplification reduces branches and repetitions in query conditions, allowing the database to utilize composite indexes more effectively during query execution, reducing the scan range, and thus significantly improving query efficiency.

[0037] Step S103: Based on the optimized query logic and preset indicator information, dynamically parse the storage location of each indicator data in the data storage system, perform data aggregation processing based on the storage location, obtain the aggregation result, and output the aggregation result to update the drill-down view.

[0038] In some embodiments of this application, a pre-built financial indicator metadata model decouples the business semantics of indicators from the underlying physical storage, allowing the front-end condition tree to focus only on "what indicator I want to query," without needing to know "where this indicator is stored, what the field is called, or what the path is." All atomic conditions in the optimized query logic are traversed, and the indicator identifier involved in each condition is extracted. Using each indicator identifier as a key, the corresponding complete metadata record is searched in the pre-defined indicator metadata model. If no corresponding record is found, a configuration error message is returned; if found, all storage-related information for that indicator is read. When there is only one storage path in the indicator metadata, that path is used directly. When multiple candidate paths exist, the actual path to be used needs to be determined based on the path query rules and the current query context. After determining the actual storage field path corresponding to each indicator, the logical structure in the optimized query logic is combined with the field path, and the final query instruction is generated node by node according to the query syntax rules of data storage systems such as MongoDB.

[0039] It should be noted that the preset indicator information is a pre-built set of financial indicator metadata models. It is a "translation dictionary" that connects business semantics with the underlying storage. This model provides a structured description of each queryable indicator.

[0040] It should be noted that the raw data returned by the data storage system only contains basic data that meets static conditions. This data needs to be aggregated and calculated to form the statistical view that the user is interested in. After the aggregation calculation is completed, the result is encapsulated into a data structure that the front-end can render. The aggregation result is then returned to the front-end. Upon receiving the new result, the front-end's recursive condition setting interface automatically refreshes the drill-down view. If further drill-down is needed, the user can directly continue to drill down based on the current result, recursively triggering a new layer of data requests, forming a continuous interactive loop of "filtering → results → further filtering → more results".

[0041] Reference Figure 2 As shown, Figure 2 This is an optional flowchart of step S101 in the first embodiment of the index data aggregation method based on recursive multi-level drill-down in this application. The method may include, but is not limited to, steps S201 to S204.

[0042] Step S201: Receive the filter conditions input by the user through the interactive interface, and obtain the configured condition nodes based on the filter conditions.

[0043] It's important to note that the user interface is dynamically rendered by a recursive front-end component, supporting multi-level nested condition settings. Users do not need to fill in all conditions before submitting. Data for each configured condition is received immediately. The interface supports nested condition groups. Users can add sub-condition groups within a condition group, and multiple condition items can be configured within each sub-condition group. Upon receiving input, the nesting level and the condition group to which each condition item belongs need to be recorded. After receiving user input, each configured condition item is converted into a condition node data structure.

[0044] Step S202: Determine the node status of nodes without configured conditions based on the dependency relationships and conflict rules in the preset business rules.

[0045] It's important to note that dependencies describe how the optional state of one condition node is affected by the value of another condition node. When a condition node is configured, the range of valid values ​​for other unconfigured nodes that have a dependency on it will change accordingly. For example, when a user selects "Year = 2026", the optional range of the "Month" node is restricted to the current month. When a user selects "Fund Type = Equity", some options in the "Investment Style" node become unavailable.

[0046] It's important to note that conflict rules describe constraints where the values ​​of two or more condition nodes cannot be satisfied simultaneously. Once a user has configured the value for a condition node, any conflicting unconfigured nodes will be disabled or restricted. For example, "Fund Type = Equity" and "Investment Style = Bond" are mutually exclusive and cannot appear in the same condition group simultaneously.

[0047] In some embodiments of this application, all condition nodes within the current condition group are traversed, distinguishing between configured and unconfigured condition nodes. Value information for all configured condition nodes is collected to form a verification context. The system checks whether any unconfigured node's value conflicts with that of a configured node. If a conflict exists, the corresponding option for that node is marked as disabled. The system then checks whether the unconfigured node depends on the value of a configured node and whether this dependency restricts the range of options available to the unconfigured node. Based on the combined verification results of the conflict rules and dependencies, a node state is determined for each unconfigured condition node.

[0048] Step S203: Render the node state to the corresponding unconfigured condition node to update the display state in the interactive interface.

[0049] It should be noted that the condition tree supports multiple levels of nesting. Therefore, the rendering update of node states must be recursively propagated along the tree structure to ensure that unconfigured nodes in each level of the condition group can obtain the correct state and be displayed correctly.

[0050] It should be noted that the feedback process of node status in the front-end interface is real-time: whenever a user modifies the value of any configured condition node, the above verification process will be immediately re-executed to update the status of all related unconfigured nodes. For example, if a user changes the "year" from "2026" to "2025", the selectable range of the month node will immediately revert to the 12 months of the year.

[0051] It should be noted that the determination of node state is not done in isolation. It also needs to be combined with the logical relationship of the current condition group. During recursive rendering, the logical relationship of the current condition group will be automatically perceived and used as one of the parameters for constraint verification, thereby dynamically adjusting the determination result of node state.

[0052] Step S204: Recursively generate a condition tree based on the filter conditions configured by the user based on the updated display status and the availability status of nodes without configured conditions.

[0053] It should be noted that after the status is updated, for available status nodes, users can normally select fields, operators, and values ​​to complete the configuration; for disabled status nodes, users cannot perform any operations on the node, and the node remains unconfigured; for hidden status nodes, the node is not visible in the interface, and users will not attempt to configure it. Under these constraints, users continue to add, modify, or delete condition items, eventually forming a set of configured condition nodes.

[0054] It should be noted that the generated condition tree not only includes the condition nodes configured by the user, but also the placeholder information and status of the unconfigured condition nodes, corresponding to the complete structure of the interactive interface. The interface display is directly restored based on the status during the next rendering, without the need for recalculation.

[0055] In some embodiments of this application, the outermost condition group in the interactive interface is used as the starting object for recursive processing. For the condition group currently being processed, the logical relationship selected by the user in the interface is read. The read logical relationship will be used to assemble the subtree corresponding to the condition group in the future. All nodes in the current condition group are processed in sequence, and the subtree of the current condition group is assembled. After all child nodes of the top-level condition group have been processed and assembled, the entire condition tree is generated and the recursive process terminates.

[0056] Reference Figure 3 As shown, Figure 3 This is an optional flowchart of step S102 in the first embodiment of the index data aggregation method based on recursive multi-level drill-down in this application. The method may include, but is not limited to, steps S301 to S303.

[0057] Step S301: Perform semantic parsing on the condition group nodes of the condition tree to obtain atomic conditions and composite conditions.

[0058] It's important to note that an atomic condition is the smallest indivisible filtering unit, representing a complete and singular filtering decision. In the condition tree, an atomic condition corresponds to a leaf condition node. For example, "Fund Type = Equity" is an atomic condition, where "Fund Type" is the indicator, "=" is the operator, and "Equity" is the filter value. An atomic condition cannot be further broken down into smaller conditions; it is the smallest unit of query logic.

[0059] It's important to note that a compound condition is a condition composed of multiple atomic conditions combined using at least one logical operator. In the condition tree, a compound condition corresponds to a condition group node and its internal logical relationships. For example, "(Fund Type = Equity) and (1-Year Return > 10%)" is a compound condition, formed by combining two atomic conditions using the "AND" logical operator. Compound conditions can be nested, meaning a compound condition can contain sub-compound conditions, thus forming a multi-level structure.

[0060] In some embodiments of this application, starting from the root node of the condition tree, all nodes are traversed layer by layer. When a condition group node is traversed, its elements are extracted and encapsulated into an atomic condition object. When a condition group node is traversed, it is identified as a composite condition, the logical relationship of the condition group node is read, and all child nodes inside the condition group are used as the sub-condition list of the composite condition.

[0061] Step S302: Sort the atomic conditions and composite conditions according to the preset logical priority rules to obtain the sorted condition tree.

[0062] It's important to note that while nesting in the interface implicitly indicates priority, the nesting level can vary depending on the user's operational order. For example, if a user adds an OR condition before adding an AND subgroup, the resulting tree structure may not directly correspond to the standard priority order. Furthermore, AND and OR sub-nodes may appear together within the same condition group, requiring explicit control over which nodes are combined first and which are combined later to ensure the correct logic of subsequent database queries. Therefore, it's necessary to sort complex conditions and reorganize the logical relationships in the condition tree according to the priority order NOT > AND > OR, resulting in a condition tree with explicit priority and a standardized structure.

[0063] Step S303: Based on the algebraic simplification rules, iteratively simplify and flatten the sorted condition tree, and output the optimized query logic.

[0064] It should be noted that, starting from the root node of the condition tree, each composite condition node is examined layer by layer downwards. This involves eliminating repeated atomic conditions, eliminating double negations, and identifying and eliminating absorption patterns. Furthermore, it checks if a composite condition node contains another composite condition node with the exact same logical relationship. If so, the inner subgroup is broken down, and its child nodes are promoted to the outer layer, reducing the original two-layer structure to one. After each round of simplification, the simplified condition tree is compared with the previous version. If the structure of the condition tree has changed between rounds, it indicates that there is still redundancy or room for optimization, and the next round of simplification continues, repeating the above checking and processing procedures. If, after a round of simplification, the structure of the condition tree is exactly the same as the previous round, with no nodes deleted, merged, or adjusted, it means that all simplifiable redundancy has been cleared, and the condition tree has reached its simplest form. At this point, the iteration is considered converged, simplification stops, and the final result is output.

[0065] Reference Figure 4 As shown, Figure 4 This is an optional flowchart of step S103, parsing the storage location, in the first embodiment of the index data aggregation method based on recursive multi-level drill-down in this application. The method may include, but is not limited to, steps S401 to S402.

[0066] Step S401: Obtain the indicator identifier in the optimized query logic.

[0067] It should be noted that, starting from the root node of the optimized query logic, a depth-first traversal is performed on the entire logic tree to collect indicator labels.

[0068] Step S402: Match the storage field path corresponding to the indicator identifier based on the indicator metadata model recorded in the preset indicator information.

[0069] It should be noted that the preset indicator information is a pre-built set of financial indicator metadata models. This model provides a structured description of each queryable indicator, with each indicator identifier corresponding to a metadata record.

[0070] It's important to note that for each metric identifier, a lookup operation is performed in the metadata model. This lookup can be understood as comparing the metric identifier with the metric identifier field of each record in the metadata model. If a completely matching record is found, it means the metric is already registered in the metadata model, and the match is successful. If no matching record is found after traversing all records, it means the metric has not yet been included in metadata management. In cases of matching failure, a configuration error message is returned, informing maintenance personnel that the metric lacks metadata definition and that the corresponding metadata record needs to be added before queries can be supported. From the matched metadata records, the key attribute to read is the storage field path. The storage field path describes the specific field location of the metric's data within the nested document structure of the data storage system. Each metric has at least one registered storage field path. For example, the storage field path for the "Fund Type" metric might be registered as the "Type" field under the "Basic Information Document"; the storage field path for the "Maximum Drawdown" metric might be registered as the "Maximum Value" field in the "Drawdown Sub-document" under the "Risk Information Document." These paths directly point to the specific location in the database where the metric's data is actually stored.

[0071] Reference Figure 5 As shown, Figure 5 This is an optional flowchart following step S402 in the first embodiment of the index data aggregation method based on recursive multi-level drill-down in this application. The method may include, but is not limited to, steps S501 to S502.

[0072] Step S501: Match the storage field path corresponding to the indicator identifier.

[0073] Step S502: When the same indicator corresponds to different storage field paths in different data records, automatically adapt to the corresponding path differences.

[0074] It's important to note that in real-world financial data scenarios, the storage location of the same metric may differ across different fund products or data sources. For example, the metric of one-year return might be stored in a field under performance information in the data records of an equity fund, while it might be stored in a different field in the data records of a bond fund. To accommodate this heterogeneity, the metadata model may register more than one storage field path for this metric, instead providing a list of candidate paths. When multiple candidate paths exist, one cannot arbitrarily choose one; instead, the actual path used must be determined based on path selection rules and the current query context.

[0075] In some embodiments of this application, the path selection rules specify that when the query conditions limit the fund type to equity funds, the first path is used; when the fund type is limited to bond funds, the second path is used. Existing fund type conditions in the current query are read, and their values ​​are substituted into the rules to select the corresponding path. Alternatively, when the query context lacks conditions that trigger a specific path selection, a default path is used as the matching result.

[0076] It should be noted that when the actual path cannot be uniquely determined, all candidate paths are retained, and these paths are simultaneously overridden when generating subsequent query commands. An "OR" relationship is used to ensure that no record that might store the metric data is missed. For example, when querying both the first and second paths simultaneously, if the data on either path meets the criteria, the record is considered to meet the filtering requirements.

[0077] Reference Figure 6 As shown, Figure 6 This is an optional flowchart of step S103 of the index data aggregation method based on recursive multi-level drill-down in this application. The method may include, but is not limited to, steps S601 to S603.

[0078] Step S601: Obtain the original data from the data storage system based on the parsed storage location.

[0079] Step S602: Perform data aggregation processing on the original data to obtain the aggregation result.

[0080] Step S603: Output the aggregation result, trigger the update of the current level drill-down view, and re-render the drill-down options of the next level according to the updated level drill-down view.

[0081] It should be noted that the raw data returned by the data storage system only contains basic data that meets static conditions. This data needs to be aggregated and calculated to form the statistical view that the user is interested in. After the aggregation calculation is completed, the result is encapsulated into a data structure that the front-end can render. The aggregation result is then returned to the front-end. Upon receiving the new result, the front-end's recursive condition setting interface automatically refreshes the drill-down view. If further drill-down is needed, the user can directly continue to drill down based on the current result, recursively triggering a new layer of data requests, forming a continuous interactive loop of "filtering → results → further filtering → more results".

[0082] Reference Figure 7 As shown, Figure 7 This is another optional flowchart in step S103 of the first embodiment of the index data aggregation method based on recursive multi-level drill-down in this application. The method may include, but is not limited to, steps S701 to S702.

[0083] Step S701: When the aggregation result involves dynamic indicator calculation, identify the shared calculation path between different data aggregation processes.

[0084] It should be noted that the determination of a shared calculation path requires the following conditions to be met simultaneously: The two query commands target the same set of fund products, or one set is a subset of the other. For example, if user A targets all equity funds and user B targets a subset of all equity funds that meets additional conditions, then user B's calculation object is a subset of user A's. The dynamic indicator identifiers involved in the two query commands are consistent, such as both calculating "one-year return" or "maximum drawdown". The calculation of the dynamic indicator depends on the time interval specified by the user (e.g., "full year of 2024" or "February 1, 2024 to February 12, 2024"). The raw data required to calculate the dynamic indicator is the same, for example, both depend on the net asset value series of the same fund.

[0085] In some embodiments of this application, in each data aggregation process, the calculation requirements of dynamic indicators are marked as independent task descriptions. These task descriptions are extracted from each query instruction to form several independent dynamic calculation tasks. The dynamic calculation tasks extracted from multiple query instructions are compared pairwise or in batches. Based on the comparison results, it is determined whether there is a shared calculation path between two tasks. For example, task A calculates the one-year return of all equity funds, and task B calculates the one-year return of funds with a size greater than 1 billion among all equity funds. The result required by task B is completely contained in the result of task A; therefore, task B can reuse the intermediate results of task A, only needing to filter them. The identified shared paths are marked, and it is recorded which query instructions have shared relationships between their tasks. These relationships are then passed to the computation scheduling engine for arranging the computation order and caching strategy.

[0086] Step S702: Based on the shared computation path, obtain the cached intermediate aggregation results, merge the intermediate aggregation results and output them.

[0087] It's important to note that intermediate aggregation results refer to reusable, phased calculations generated during the dynamic indicator calculation process. It is not the final, complete aggregation result presented to the user, but it contains most of the computational work required to achieve the final result. For example, in the scenario of calculating the "one-year return of all equity funds," the intermediate aggregation result is the set of return values ​​for these funds within a specified time interval. It may exist in the form of "return values ​​corresponding to fund identifiers," without sorting or filtering out subsets of returns exceeding a certain threshold, but it already contains the basic calculated values ​​for all funds.

[0088] It should be noted that after obtaining the intermediate aggregation results, they need to be merged with other conditions of the current query to generate the final aggregation results required by the current query.

[0089] Reference Figure 8 As shown, Figure 8 This is an optional flowchart before the aggregation process in step S103 in the first embodiment of the index data aggregation method based on recursive multi-level drill-down in this application. The method may include, but is not limited to, steps S801 to S803.

[0090] Step S801: Generate a cache key based on the optimized query logic and storage location, and search for the aggregation result corresponding to the cache key in the cache.

[0091] It should be noted that the query logic and storage location are normalized to ensure that queries with the same semantics can obtain a consistent normalized form regardless of their original expression. The normalized form is then converted into a fixed-length identifier, which serves as the cache key.

[0092] Step S802: If an aggregation result corresponding to the cache key exists in the cache, the aggregation result in the cache is returned directly, and the query instruction is skipped.

[0093] It should be noted that a cache hit occurs when the aggregate result corresponding to the cache key is found in the cache. In this case, the result is read directly, skipping the subsequent database query execution and dynamic metric calculation process, and the result is immediately returned to the front end.

[0094] Step S803: If there is no aggregation result corresponding to the cache key in the cache, execute the query instruction and write the obtained aggregation result into the cache.

[0095] It should be noted that if the corresponding aggregation result is not found in the cache, it is considered a cache miss. In this case, the normal process continues: a query command is sent to the database to retrieve the raw data; calculations are performed on the metrics that need to be dynamically calculated; and the final result is obtained after aggregation. The result is written to the cache before or after it is returned.

[0096] This application also provides a data aggregation device for indicators based on recursive multi-level drill-down. Please refer to [reference needed]. Figure 9 The device includes: The recursive condition tree module 901 is used to respond to the received filtering conditions, perform dynamic constraint verification on the unconfigured condition nodes according to the preset business rules, determine the node status of the unconfigured condition nodes, and recursively generate a condition tree based on the filtering conditions and node status. The query optimization module 902 is used to perform semantic and logical parsing on the condition group nodes of the condition tree, and optimize the condition tree based on algebraic simplification rules to generate optimized query logic. The query aggregation module 903 is used to dynamically parse the storage location of each indicator data in the data storage system based on the optimized query logic and preset indicator information, perform data aggregation processing based on the storage location, obtain the aggregation result, and output the aggregation result to update the drill-down view.

[0097] The indicator data aggregation device based on recursive multi-level drill-down provided in this application adopts the indicator data aggregation method based on recursive multi-level drill-down in the above embodiments, achieving the effects of enhancing data query flexibility and dynamic scalability, supporting complex analysis capabilities with infinite multi-level drill-down, reducing end-to-end interaction latency, and ensuring real-time accuracy of query results. Compared with the prior art, the beneficial effects of the indicator data aggregation device based on recursive multi-level drill-down provided in this application are the same as those of the indicator data aggregation method based on recursive multi-level drill-down provided in the above embodiments, and other technical features in the indicator data aggregation device based on recursive multi-level drill-down are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0098] This application provides a data aggregation device for indexes based on recursive multi-level drilling. The data aggregation device for indexes based on recursive multi-level drilling includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the data aggregation method for indexes based on recursive multi-level drilling in the above embodiment 1.

[0099] The following is for reference. Figure 10 This document illustrates a structural diagram of a recursive multi-level drill-down-based index data aggregation device suitable for implementing embodiments of this application. The recursive multi-level drill-down-based index data aggregation device in this application embodiment may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 10 The indicator data aggregation device based on recursive multi-level drill-down shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0100] like Figure 10 As shown, the indicator data aggregation device based on recursive multi-level drill-down may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory 1002 or a program loaded from storage device 1003 into random access memory 1004. Random access memory 1004 also stores various programs and data required for the operation of the indicator data aggregation device based on recursive multi-level drill-down. The processing unit 1001, read-only memory 1002, and random access memory 1004 are interconnected via bus 1005. Input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to input / output interface 1006: input devices 1007 including, for example, touch screens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the index data aggregation device based on recursive multi-level drilling to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows index data aggregation devices based on recursive multi-level drilling with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0101] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0102] The indicator data aggregation device based on recursive multi-level drill-down provided in this application adopts the indicator data aggregation method based on recursive multi-level drill-down in the above embodiments, achieving the effects of enhancing data query flexibility and dynamic scalability, supporting complex analysis capabilities with infinite multi-level drill-down, reducing end-to-end interaction latency, and ensuring real-time accuracy of query results. Compared with the prior art, the beneficial effects of the indicator data aggregation device based on recursive multi-level drill-down provided in this application are the same as those of the indicator data aggregation method based on recursive multi-level drill-down provided in the above embodiments, and other technical features in this indicator data aggregation device based on recursive multi-level drill-down are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0103] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0104] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for aggregating index data based on recursive multi-level drill-down, characterized in that, The method includes: In response to the filtering conditions received through the interactive interface, dynamic constraint verification is performed on the unconfigured condition nodes according to the dependency relationships and conflict rules in the preset business rules. The node state of the unconfigured condition nodes is determined, and the node state is rendered into the corresponding unconfigured condition nodes to update the display state in the interactive interface. Based on the filtering conditions configured by the user based on the updated display state and the node state of the unconfigured condition nodes, a condition tree is recursively generated. The condition tree includes multi-level nested condition group nodes. Semantic and logical parsing are performed on the condition group nodes of the condition tree, and the condition tree is optimized based on algebraic simplification rules to generate optimized query logic; Based on the optimized query logic and preset indicator information, the storage location of each indicator data in the data storage system is dynamically parsed, data aggregation processing is performed based on the storage location to obtain the aggregation result, and the aggregation result is output to update the drill-down view.

2. The index data aggregation method based on recursive multi-level drill-down as described in claim 1, characterized in that, The process of performing semantic and logical parsing on the condition group nodes of the condition tree, and optimizing the condition tree based on algebraic simplification rules to generate optimized query logic includes: Semantic parsing is performed on the condition group nodes of the condition tree to obtain atomic conditions and composite conditions; wherein, the composite condition includes at least one logical operator; The atomic conditions and the composite conditions are sorted according to a preset logical priority rule to obtain a sorted condition tree; The sorted condition tree is iteratively simplified and flattened based on algebraic simplification rules, and the optimized query logic is output.

3. The index data aggregation method based on recursive multi-level drill-down as described in claim 1, characterized in that, The step of dynamically parsing the storage location of each indicator data in the data storage system based on the optimized query logic and preset indicator information includes: Obtain the indicator identifier in the optimized query logic; Based on the indicator metadata model recorded in the preset indicator information, match the storage field path corresponding to the indicator identifier.

4. The index data aggregation method based on recursive multi-level drill-down as described in claim 3, characterized in that, After matching the storage field path corresponding to the indicator identifier, the method further includes: When the same metric corresponds to different storage field paths in different data records, it automatically adapts to the corresponding path differences.

5. The index data aggregation method based on recursive multi-level drill-down as described in claim 1, characterized in that, The process of performing data aggregation based on the storage location to obtain an aggregation result, and outputting the aggregation result to update the drill-down view, includes: Based on the storage location obtained from the parsing, the original data is retrieved from the data storage system; The original data is subjected to data aggregation processing to obtain the aggregation result; Output the aggregation result, trigger the update of the current level drill-down view, and re-render the drill-down options of the next level according to the updated level drill-down view.

6. The index data aggregation method based on recursive multi-level drill-down as described in claim 1, characterized in that, The data aggregation process based on the storage location to obtain the aggregation result further includes: When the aggregation result involves dynamic indicator calculation, identify the shared calculation path in different data aggregation processes; Based on the shared computation path, the cached intermediate aggregation results are obtained, the intermediate aggregation results are merged, and then output.

7. The index data aggregation method based on recursive multi-level drill-down as described in claim 1, characterized in that, Before performing data aggregation processing based on the storage location, the method further includes: A cache key is generated based on the optimized query logic and the storage location, and the aggregation result corresponding to the cache key is searched in the cache. If an aggregation result corresponding to the cache key exists in the cache, the aggregation result in the cache is returned directly, and the query instruction is skipped. If the cache does not contain an aggregation result corresponding to the cache key, the query instruction is executed, and the obtained aggregation result is written to the cache.

8. A data aggregation device for indicators based on recursive multi-level drill-down, characterized in that, The device includes: The recursive condition tree module is used to respond to the filtering conditions received through the interactive interface, dynamically constrain and verify the unconfigured condition nodes according to the dependency relationships and conflict rules in the preset business rules, determine the node state of the unconfigured condition nodes, render the node state to the corresponding unconfigured condition nodes to update the display state in the interactive interface, and recursively generate a condition tree according to the filtering conditions configured by the user based on the updated display state and the node states of the unconfigured condition nodes; wherein, the condition tree includes multi-level nested condition group nodes; The query optimization module is used to perform semantic and logical parsing on the condition group nodes of the condition tree, and optimize the condition tree based on algebraic simplification rules to generate optimized query logic. The query aggregation module is used to dynamically parse the storage location of each indicator data in the data storage system according to the optimized query logic and preset indicator information, perform data aggregation processing based on the storage location, obtain the aggregation result, and output the aggregation result to update the drill-down view.

9. A data aggregation device for indicators based on recursive multi-level drill-down, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the index data aggregation method based on recursive multi-level drill-down as described in any one of claims 1 to 7.

Images