Index query method and device, electronic equipment and storage medium

Abstract

The invention is suitable for the technical field of data query, and provides an index query method and device, electronic equipment and a storage medium, and the index query method comprises the following steps: obtaining a first type of query language statement input by a user; performing grammar analysis on the first type of query language statement based on a predefined grammar rule to generate a corresponding analysis tree; traversing the analytic tree, identifying a query target in the first type of query language statement, and constructing a query semantic object based on the query target, the query target including one or more of an index and a physical table; and according to the query semantic object, generating a second type of query language statement corresponding to the first type of query language statement for an underlying data system to perform index query. According to the scheme, by introducing the query semantic object and supporting mixed recognition and processing of the index and the physical table, the problems that in an existing query mode, flexibility is insufficient, dynamic parameters cannot be expressed, and multi-source joint query cannot be supported are solved.

Description

Technical Field

[0001] The present application belongs to the field of data query technology, and in particular relates to an indicator query method, device, electronic device and storage medium. Background Art

[0002] In modern data analysis and business intelligence systems, data query languages ​​based on a unified indicator system have become widely used in enterprise-level data platforms. These indicator query languages ​​typically utilize standardized indicator models, shielding the underlying data table structure, simplifying query operations for business personnel, and improving query efficiency and data consistency.

[0003] Most current metric query languages ​​only support calling standard metrics pre-defined within the platform. They lack the flexibility to reference underlying physical tables and do not support joint queries across multiple data sources (such as physical tables and metrics) within a query statement. This necessitates pre-modeling all fields as standard metrics recognizable by the platform in certain scenarios where mixed data sources are needed to generate analytical reports, increasing modeling costs and reducing flexibility. Summary of the Invention

[0004] In view of this, the embodiments of the present application provide an indicator query method, device, electronic device and storage medium. By introducing query semantic objects and supporting the mixed identification and processing of indicators and physical tables, it solves the problems of insufficient flexibility, inability to express dynamic parameters and inability to support multi-source joint queries in existing query methods.

[0005] A first aspect of an embodiment of the present application provides an indicator query method, the indicator query method comprising:

[0006] Get the first type of query language statement input by the user;

[0007] Performing grammatical parsing on the first type of query language statements based on predefined grammatical rules to generate a corresponding parse tree;

[0008] Traversing the parse tree, identifying a query target in the first type of query language statement, and constructing a query semantic object based on the query target, wherein the query target includes one or more of an indicator and a physical table, and the query semantic object is an intermediate representation structure for representing the user's query intent;

[0009] According to the query semantic object, a second type of query language statement corresponding to the first type of query language statement is generated for the underlying data system to perform indicator query. The second type of query language is the query language of the underlying data system.

[0010] The indicator query method provided in the embodiments of this application automatically converts user-friendly language into system query language by parsing the first-class query language statement entered by the user into a parse tree, constructing a query semantic object, and generating a second-class query language statement recognizable by the underlying data system. This improves query flexibility and compatibility, reduces the complexity of direct user operation of the underlying data system, and improves query efficiency.

[0011] In a possible implementation, traversing the parse tree, identifying a query target in the first type of query language statement, and constructing a query semantic object based on the query target includes:

[0012] Traversing the parse tree, and identifying a query target in the first type of query language statement based on clause content corresponding to a source clause in the parse tree and indicator metadata of an indicator platform;

[0013] When the query target is an indicator, extracting dynamic parameters associated with the indicator from the first type of query language statement, and constructing a query semantic object based on the query target and the dynamic parameters;

[0014] When the query target is a physical table, a query semantic object is constructed based on the query target.

[0015] In one possible implementation, traversing the parse tree and identifying a query target in the first-category query language statement based on clause content corresponding to a source clause in the parse tree and indicator metadata of an indicator platform includes:

[0016] Traversing the parse tree, if the corresponding clause content in the source clause contains a target identifier, searching whether the target identifier exists in the indicator metadata in the indicator platform;

[0017] If the search result is that the query target exists, the query target is identified as an indicator;

[0018] If the search result is that the table does not exist, the query target is identified as a physical table.

[0019] In a possible implementation, traversing the parse tree, identifying a query target in the first type of query language statement, and constructing a query semantic object based on the query target further includes:

[0020] Traversing the parse tree, and identifying multiple query targets in the first type of query language statement based on clause contents corresponding to source clauses in the parse tree and indicator metadata of the indicator platform;

[0021] When the query target is multiple indicators, extracting dynamic parameters associated with each indicator from the first type of query language statement, and constructing query semantic sub-objects based on each indicator and the corresponding dynamic parameter to generate multiple corresponding second type query language sub-statements;

[0022] When the query target is multiple physical tables, constructing query semantic sub-objects based on each physical table to generate multiple corresponding second-category query language sub-statements;

[0023] When the query target includes indicators and physical tables, dynamic parameters associated with the indicators are extracted from the first type of query language statements, a first query semantic object is constructed based on the indicators and the corresponding dynamic parameters, and a second query semantic object is constructed based on the physical table to generate corresponding second type query language sub-statements respectively.

[0024] In a possible implementation, the source clause of the parse tree includes a relation node, and the relation node includes a non-associative query structure and an associative query structure;

[0025] When the first type of query language statement includes a query target, identifying the query target as a subquery, a physical table, or an index through the non-associative query structure, wherein the non-associative query structure includes queries of subqueries, physical tables, and indexes;

[0026] When the first type of query language statement includes multiple query targets, the association relationship among the multiple query targets is queried through the nested form of the association query structure, wherein the association query structure includes multiple relationship nodes.

[0027] In a possible implementation, generating, based on the query semantic object, a second type of query language statement corresponding to the first type of query language statement for use by an underlying data system in performing an indicator query includes:

[0028] If the query semantic object is constructed based on the indicator and the dynamic parameter, identifying the indicator and the dynamic parameter according to the query semantic object;

[0029] Mapping the query semantics in the query semantic object with the query syntax of the second type of query language to generate a standard query statement that complies with the specification of the underlying data system;

[0030] According to the dynamic parameters in the query semantic object, the corresponding query intent is parsed, and the query conditions, dimension aggregation method or time granularity information in the standard query statement are adjusted or constructed;

[0031] Fill the parsed parameter values ​​in the standard query statement, or replace the placeholders in the standard query statement, to generate a second type of query language statement corresponding to the first type of query language statement.

[0032] In a possible implementation, the dynamic parameters include one or more of an analysis dimension, a time dimension, an aggregation method, a conditional limitation, and a version number.

[0033] A second aspect of an embodiment of the present application provides an indicator query device, the indicator query device comprising:

[0034] An acquisition module, used for acquiring a first-class query language statement input by a user;

[0035] A parsing module, configured to perform grammatical parsing on the first type of query language statements based on predefined grammatical rules and generate a corresponding parse tree;

[0036] a traversal module, configured to traverse the parse tree, identify a query target in the first type of query language statement, and construct a query semantic object based on the query target, wherein the query target includes one or more of an indicator and a physical table, and the query semantic object is an intermediate representation structure for representing the user's query intent;

[0037] A generation module is used to generate a second type of query language statement corresponding to the first type of query language statement based on the query semantic object, so as to provide the underlying data system with indicator query, and the second type of query language is the query language of the underlying data system.

[0038] In a possible implementation, the traversal module includes:

[0039] A first target identification submodule is configured to traverse the parse tree and identify a query target in the first type of query language statement based on clause contents corresponding to source clauses in the parse tree and indicator metadata of the indicator platform;

[0040] a first construction submodule, configured to, when the query target is an indicator, extract dynamic parameters associated with the indicator from the first type of query language statement, and construct a query semantic object based on the query target and the dynamic parameters;

[0041] The second construction submodule is configured to construct a query semantic object based on the query target when the query target is a physical table.

[0042] In one possible implementation, the first target recognition submodule includes:

[0043] a retrieval unit, configured to traverse the parse tree and, if the corresponding clause content in the source clause contains a target identifier, retrieve whether the target identifier exists in the indicator metadata in the indicator platform;

[0044] A first judgment unit, configured to identify the query target as an indicator if the search result is yes;

[0045] The second judgment unit is configured to identify the query target as a physical table if the search result shows that the query target does not exist.

[0046] In a possible implementation, the traversal module further includes:

[0047] A second target identification submodule is configured to traverse the parse tree and identify multiple query targets in the first type of query language statement based on clause contents corresponding to source clauses in the parse tree and indicator metadata of the indicator platform;

[0048] a third construction submodule for extracting dynamic parameters associated with each indicator from the first type of query language statement when the query target is multiple indicators, and constructing query semantic sub-objects based on each indicator and the corresponding dynamic parameter to generate multiple corresponding second type query language sub-statements;

[0049] a fourth construction submodule, configured to, when the query target is a plurality of physical tables, construct a query semantic sub-object based on each physical table to generate a plurality of corresponding second-category query language sub-statements;

[0050] The fifth construction submodule is used to extract dynamic parameters associated with the indicators from the first type of query language statement when the query target includes indicators and physical tables, construct a first query semantic object based on the indicators and the corresponding dynamic parameters, and construct a second query semantic object based on the physical table to generate corresponding second type query language sub-statements respectively.

[0051] In a possible implementation, the source clause of the parse tree includes a relation node, and the relation node includes a non-associative query structure and an associative query structure;

[0052] The non-associative query structure includes queries on subqueries, physical tables, and indicators, and is used to identify the query target as a subquery, a physical table, or an indicator through the non-associative query structure when the first type of query language statement includes a query target;

[0053] The associated query structure includes a plurality of relationship nodes, and is used to query the associated relationships among the plurality of query targets through the nested form of the associated query structure when the first type of query language statement includes a plurality of query targets.

[0054] In a possible implementation, the generating module includes:

[0055] a third identification submodule, configured to identify the indicator and the dynamic parameter according to the query semantic object if the query semantic object is constructed based on the indicator and the dynamic parameter;

[0056] a mapping submodule, configured to map the query semantics in the query semantic object with the query syntax of the second type of query language to generate a standard query statement that complies with the specification of the underlying data system;

[0057] A parsing submodule, configured to parse the corresponding query intent according to the dynamic parameters in the query semantic object, and adjust or construct the query conditions, dimension aggregation method or time granularity information in the standard query statement;

[0058] The statement generation submodule is used to fill the parsed parameter values ​​in the standard query statement, or replace the placeholders in the standard query statement, to generate a second type of query language statement corresponding to the first type of query language statement.

[0059] In a possible implementation, the dynamic parameters queried in the indicator query device include one or more of analysis dimension, time dimension, aggregation method, condition limitation, and version number.

[0060] A third aspect of an embodiment of the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the indicator query method described in the first aspect when executing the computer program.

[0061] A fourth aspect of an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the indicator query method described in the first aspect above.

[0062] A fifth aspect of an embodiment of the present application provides a computer program product. When the computer program product is run on an electronic device, the electronic device executes the indicator query method described in the first aspect above.

[0063] The beneficial effects of the second to fifth aspects mentioned above can all refer to the beneficial effects described in the first aspect mentioned above, and this application will not repeat them here. BRIEF DESCRIPTION OF THE DRAWINGS

[0064] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0065] Figure 1 This is a flow chart of an indicator query method provided in an embodiment of the present application;

[0066] Figure 2 This is a schematic diagram of a process for constructing a query semantic object provided by an embodiment of the present application;

[0067] Figure 3 This is another flowchart of constructing a query semantic object provided by an embodiment of the present application;

[0068] Figure 4 It is a schematic diagram of the structure of the parse tree;

[0069] Figure 5 This is a schematic diagram of the structure of an indicator query device provided in an embodiment of the present application;

[0070] Figure 6 It is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0071] In the following description, specific details such as specific system structures and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obscuring the description of the present application with unnecessary detail.

[0072] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, integers, steps, operations, elements and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or collections thereof.

[0073] It will also be understood that the term "and / or" used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

[0074] As used in this specification and the appended claims, the term "if" can be interpreted as "when" or "upon" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" can be interpreted as meaning "upon determination" or "in response to determining" or "upon detection of [described condition or event]" or "in response to detecting [described condition or event]," depending on the context.

[0075] In addition, in the description of the present application specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.

[0076] It should be understood that the size of the serial numbers of each step in this embodiment does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of this application.

[0077] In modern data analysis and business intelligence systems, data query languages ​​based on a unified indicator system have become widely used in enterprise-level data platforms. These indicator query languages ​​typically utilize standardized indicator models, shielding the underlying data table structure, simplifying query operations for business personnel, and improving query efficiency and data consistency.

[0078] Most current metric query languages ​​only support calling standard metrics pre-defined within the platform. They lack the flexibility to reference underlying physical tables and do not support joint queries across multiple data sources (such as physical tables and metrics) within a query statement. This necessitates pre-modeling all fields as standard metrics recognizable by the platform in certain scenarios where mixed data sources are needed to generate analytical reports, increasing modeling costs and reducing flexibility.

[0079] To address the above issues, this application proposes a method, device, electronic device, and storage medium for querying metrics. By parsing a user-entered first-class query language statement into a parse tree, constructing a query semantic object, and generating a second-class query language statement recognizable by the underlying data system, this method achieves automatic conversion from user-friendly language to system query language. This improves query flexibility and compatibility, reduces the complexity of direct user manipulation of the underlying data system, and improves query efficiency.

[0080] The indicator query method, device, electronic device, storage medium and computer program provided in the embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0081] Figure 1 A flow chart of an indicator query method provided by an embodiment of the present application is shown as follows: Figure 1As shown, the method may include the following steps:

[0082] Step 101: Obtain a first type of query language statement input by a user.

[0083] The first type of query language statement refers to a query request entered by the user, which includes an indicator or physical table as the query target. Specifically, it can be implemented using SQL-like syntax combined with indicator identifiers. For example, MQL can be used as the first type of query language.

[0084] In the embodiment of the present application, a first type of query language statement input by a user through a graphical interface may be first received. For example, to query the monthly sales trend of each region in 2025, the user input is:

[0085] SELECT *

[0086] FROM M_001{dim=(area_name),gran=(month),ver=(latest)}

[0087] WHERE_stat_date>='2025-01'.

[0088] Step 102: parse the first type of query language statement based on predefined grammatical rules to generate a corresponding parse tree.

[0089] Among them, syntax parsing refers to converting natural language or SQL-like statements into structured syntax representation. Specifically, ANTLR can be used to define syntax rules, and a parse tree can be constructed through lexical analysis and syntax analysis to form a hierarchical syntax structure.

[0090] Among them, the parse tree refers to a tree-like data structure generated by grammatical rules, which contains the hierarchical relationship of query clauses. Specifically, the recursive descent parser can generate nodes and subtrees for subsequent semantic recognition and conversion.

[0091] Taking the first-class query language as MQL language as an example, in an embodiment of the present application, a custom MQL grammar file can be written: MetricSql.g4, and an ANTLR tool can be used to generate a parser based on the custom MQL grammar file, wherein the MQL grammar file includes predefined grammar rules, and the first-class query language statement is grammatically parsed based on the predefined grammar rules, that is, the first-class query language statement (for example, SELECT*FROM M_001{dim=(area_name), gran=(month), ver=(latest)}WHERE_stat_date>='2025-01') is parsed using the above-generated parser to generate a tree structure containing nodes and edges, that is, a parse tree.

[0092] Among them, the parser defines the grammatical structure of the first-class query language, including the formats of clauses such as select, from, where, order by, group by, limit, and having.

[0093] For example, after MQL parsing the input "SELECT * FROM M_001{dim=(area_name), gran=(month), ver=(latest)}WHERE_stat_date>='2025-01'", the clauses in the parse tree can be obtained as follows:

[0094]

[0095] Step 103: traverse the parse tree, identify the query target in the first type of query language statement, and construct a query semantic object based on the query target.

[0096] The query target refers to the source object from which data needs to be obtained, including one or more indicators and physical tables. Specifically, the identifier in the source clause can be parsed to match the indicator metadata or physical table name to achieve unified identification of hybrid data sources.

[0097] Among them, the query semantic object is an intermediate representation structure used to express the user's query intention. Specifically, an object-oriented model can be used to store indicator parameters, table associations and dynamic conditions as an intermediate layer for generating underlying query statements.

[0098] In an embodiment of the present application, the query target can be a single indicator or a single physical table, or multiple indicators or multiple physical tables, or a combination of indicators and physical tables. Different query semantic objects can be constructed for different forms of query targets.

[0099] In one possible implementation, see Figure 2 When the query target is a single index or a single physical table, step 103 may specifically include the following steps:

[0100] Step 201 traverses the parse tree and identifies the query target in the first type of query language statement based on the clause content corresponding to the source clause in the parse tree and the indicator metadata of the indicator platform.

[0101] Step 202: When the query target is an indicator, dynamic parameters associated with the indicator are extracted from the first type of query language statement, and a query semantic object is constructed based on the query target and the dynamic parameters.

[0102] Step 203: When the query target is a physical table, a query semantic object is constructed based on the query target.

[0103] In some solutions of the present application, in the process of constructing a query semantic object by traversing the parse tree, the target identifier in the source clause may not match the indicator metadata, resulting in the inability to accurately distinguish whether the query target is an indicator or a physical table, thereby affecting the accuracy of constructing the query semantic object.

[0104] In order to solve the above problems, the present application proposes to identify the query target according to the clause content corresponding to the source clause and the indicator metadata of the indicator platform when traversing the parse tree.

[0105] Among them, the clause content corresponding to the source clause is represented by the node structure in the parse tree, and the node structure contains the text content of the target identifier. The indicator metadata of the indicator platform can be stored in the form of key-value pairs, where the key is the indicator identifier and the value is the physical table path and calculation logic associated with the indicator. Dynamic parameters are defined as variable parameters bound to indicators, including one or more of the time dimension, analysis dimension, aggregation method, conditional restriction, and version number. The query target of the physical table can be achieved by matching the table name in the source clause with the table registration information of the underlying data system.

[0106] Specifically, when traversing the parse tree, the node corresponding to the source clause is parsed into a text string and compared with the key set of the indicator metadata through a string matching algorithm. If the match is successful, the query target is determined to be an indicator. At this time, dynamic parameters need to be extracted from the custom clause of the first type of query language statement. If the match fails, a query semantic object based on the physical table is directly generated, or the table name corresponding to the source clause is passed to the metadata service of the underlying data system for verification. After the verification is passed, a query semantic object based on the physical table is generated. All of the above methods are acceptable, and this application does not limit this.

[0107] This process achieves a unified semantic expression of queries from mixed data sources by decoupling indicator metadata from dynamic parameters.

[0108] Exemplarily, the parse tree is traversed to identify the query target in the first type of query language statement based on the clause content corresponding to the source clause in the parse tree and the indicator metadata of the indicator platform. Specifically, each node of the parse tree can be traversed to check whether the source clause contains a target identifier. If the target identifier is contained, the identifier is further searched in the metadata of the indicator platform.

[0109] When the query target is a metric, dynamic parameters associated with the metric are extracted from the first-category query language statement. A query semantic object is constructed based on the query target and dynamic parameters. For example, the conditional clauses in the statement can be parsed to extract dynamic parameters such as time range, dimension, and filter conditions. Information such as the metric name, parameter type, and parameter value are then encapsulated in the query semantic object.

[0110] When the query target is a physical table, a query semantic object is constructed based on the query target. Information such as the table name and field list can be directly encapsulated into the query semantic object without extracting dynamic parameters.

[0111] Through the above technical solution, this application realizes the unified identification and processing of indicators and physical tables. This method not only retains the convenience of indicator query, but also increases the flexibility of direct access to physical tables, which can better meet the needs of complex data analysis.

[0112] In a possible implementation, step 201 may specifically include:

[0113] Traverse the parse tree. If the corresponding clause content in the source clause contains the target identifier, then search whether the target identifier exists in the indicator metadata in the indicator platform.

[0114] If the search result is existence, the query target is identified as an indicator;

[0115] If the search result is that the table does not exist, the query target is identified as a physical table.

[0116] In a possible implementation, when the query target is multiple indicators or multiple physical tables or a combination of indicators and physical tables, see Figure 3 , the above step 103 may specifically include the following steps:

[0117] Step 301 , traverse the parse tree, and identify multiple query targets in the first type of query language statement based on the clause content corresponding to the source clause in the parse tree and the indicator metadata of the indicator platform.

[0118] Step 302: When the query target is multiple indicators, the dynamic parameters associated with each indicator are extracted from the first type of query language statement, and query semantic sub-objects are constructed based on each indicator and the corresponding dynamic parameters to generate multiple corresponding second type query language sub-statements.

[0119] Step 303: When the query target is multiple physical tables, construct query semantic sub-objects based on each physical table to generate multiple corresponding second-type query language sub-statements.

[0120] Step 304: When the query target includes indicators and physical tables, dynamic parameters associated with the indicators are extracted from the first type of query language statements, a first query semantic object is constructed based on the indicators and the corresponding dynamic parameters, and a second query semantic object is constructed based on the physical table to generate corresponding second type query language sub-statements respectively.

[0121] In some solutions of the present application, only a single query target can be processed when traversing the parse tree, and joint queries of multiple indicators or physical tables cannot be supported. As a result, multi-source data needs to be pre-modeled as standard indicators before query operations can be performed, which increases data modeling costs and reduces query flexibility.

[0122] In order to solve the above problems, the present application further proposes to traverse the parse tree and identify multiple query targets in the first type of query language statement based on the clause content corresponding to the source clause in the parse tree and the indicator metadata of the indicator platform.

[0123] Among them, after the clause content corresponding to the source clause is parsed into a tree structure, each node is accessed through a traversal algorithm. When it is detected that the source clause contains multiple identifiers, the multi-target processing mode can be triggered. Each query target is independently mapped to a query semantic sub-object, which contains a target type identifier, a dynamic parameter set, and an association relationship tag. The query semantic sub-object of the physical table type is directly associated with the underlying data table structure, and the sub-object of the indicator type is attached with a dynamic parameter mapping table. Multiple second-class query language sub-statements are connected through the joint query operator to form the final standard query statement.

[0124] Specifically, when traversing the parse tree, when the source clause contains multiple target identifiers, each identifier is independently checked to see if it is a predefined item in the indicator metadata. If the identifier exists in the indicator metadata, it is classified as an indicator type; otherwise, it is classified as a physical table type. For indicator type targets, dynamic parameters are parsed into a set of key-value pairs and stored in sub-objects. For example, when a query statement contains two indicators and a physical table, the dynamic parameters corresponding to the two indicators are extracted separately and generate independent sub-objects, while the physical table generates a sub-object without parameters. All sub-objects are converted into corresponding SQL sub-query fragments, and finally combined into a complete query statement through the UNION or JOIN operator. In this way, query targets from different sources are processed independently and then associated, avoiding forced unified modeling as standard indicators, reducing data preparation costs and improving query flexibility.

[0125] For example, when the query target is multiple indicators, the dynamic parameters associated with each indicator are extracted from the first-type query language statement. Based on each indicator and its corresponding dynamic parameters, query semantic sub-objects are constructed to generate multiple corresponding second-type query language sub-statements. Specifically, for each identified indicator, its corresponding dynamic parameters, such as analysis dimension, time dimension, and aggregation method, are extracted. Then, based on each indicator and its dynamic parameters, a query semantic sub-object is constructed, containing information such as the indicator identifier and dynamic parameters. Finally, each query semantic sub-object is converted into a corresponding second-type query language sub-statement.

[0126] When the query targets multiple physical tables, a query semantic sub-object is constructed for each physical table to generate multiple corresponding second-category query language sub-statements. Furthermore, a query semantic sub-object containing the table name, field information, and other information can be constructed for each identified physical table. Each query semantic sub-object is then converted into a corresponding second-category query language sub-statement.

[0127] When the query target includes both indicators and physical tables, the dynamic parameters associated with the indicators are extracted from the first-category query language statement. Based on the indicators and the corresponding dynamic parameters, a first query semantic object is constructed, and based on the physical tables, a second query semantic object is constructed to generate corresponding second-category query language sub-statements. This allows for simultaneous processing of mixed query scenarios involving both indicators and physical tables. For the indicator portion, its dynamic parameters are extracted and the first query semantic object is constructed; for the physical table portion, the second query semantic object is constructed. Finally, both query semantic objects are converted into corresponding second-category query language sub-statements.

[0128] Through the above technical solution, this application realizes the identification and processing of multiple query targets, and supports a variety of query scenarios including indicators, physical tables, and mixed indicators and physical tables. This method improves the flexibility and expressiveness of the query language, enabling users to operate multiple data sources simultaneously in one query statement. At the same time, by constructing query semantic objects as intermediate representations, efficient conversion from the first type of query language to the second type of query language is achieved, thereby improving query efficiency. In addition, this method also supports the extraction and processing of dynamic parameters, enhancing the customization capability of queries.

[0129] See also Figure 4 The structure diagram of the parse tree shown in the figure includes select, from, where, order by, group by, limit, and having nodes. In the process of traversing the parse tree, each node in the tree can be processed.

[0130] The key lies in processing relation nodes. Relation nodes have two branches: a non-associative query structure and an associative query structure. In a non-associative query structure, the form clause contains only one query target, represented in the tree by primaryRelation. This primaryRelation has three branches: subQuery, metricTable (metric or physical table), and variableMetric (variable metric). Ultimately, this branches into a physical table or subquery in the physical SQL. In an associative query structure, this is represented in the tree by joinRelation, which contains two child nodes, each of which is also a relation node. This "nested tree" structure allows any associative query to be represented. Specifically, when a first-class query language statement includes multiple query targets, the associative relationships between these multiple query targets are queried using the nested form of the associative query structure.

[0131] If it's a subquery, continue traversing the query nodes in the subquery. If it's a metric or physical table, lookup the metric (lookup metric) and determine if it's a metric. If not, get the physical table query node (table). If it's a metric, get the metricQuery node, which contains a subQuery child node. If it's a variable metric, lookup the metric and parse the variable parameters (lookup variableMetric), obtaining the metric metadata and parameters (dimension = ?, granularity = ?, version = ?, etc.), thus getting the metricQuery node.

[0132] For the metricTable node, the indicator platform is searched based on the identifier. If the indicator exists, the indicator base table and its time dimension fields, analysis dimension fields, and metric value fields are extracted. Combined with the aggregation method and statistical period, this is encapsulated into a MetricDefinition. A SubQuery is then constructed, and the two are assembled into a MetricQuery. Encapsulating the MetricDefinition in the MetricQuery is primarily used to extract relevant information about the indicator during subsequent optimization. If the indicator does not exist, the physical table is queried, represented by a Table. This node supports both indicators and physical tables, thus implementing the MQL syntax-compatible querying of indicators and physical tables proposed in this solution.

[0133] For the variableMetric node, this node represents a metric query with dynamic parameters. The process of searching for metrics is the same as that of the metricTable node. The difference is that after obtaining the MetricDefinition, the incoming dynamic parameters will overwrite the attributes in the MetricDefinition.

[0134] The dim parameter indicates the analysis dimension for this query. Empty parentheses indicate no analysis dimension and aggregation by time is sufficient. Non-empty parentheses indicate the dimension to be queried. Multiple dimensions are separated by commas. The resulting analysis dimension set overwrites the analysis dimension set in the MetricDefinition and is reflected in the GROUP BY clause in the final physical SQL statement.

[0135] The parameter "gran" indicates the time granularity of the query result set. By default, aggregation is based on the statistical period configured by the indicator platform (hour, day, week, month, quarter, year). For example, if the statistical period is daily, specifying a monthly granularity will change the time aggregation in the final physical SQL from "DATE_FORMAT(time_column,'%Y-%m-%d')" to "DATE_FORMAT(time_column,'%Y-%m-01'). This parameter also supports a special value, "RANGE," which indicates that the query will treat the entire range of the query time condition as a complete statistical period. This feature allows aggregation of indicators within any time range, greatly improving the flexibility of indicator data retrieval.

[0136] The parameter "ver" indicates the version number of the metric being queried. Because changes are common throughout a metric's lifecycle, in some specific data retrieval scenarios, simply viewing the latest version of the metric isn't sufficient. Changes to the metric require administrator review before they take effect. Administrators need to see the latest version of the data to verify its accuracy, while non-administrator users or other upper-layer data-retrieval applications need to see the data from the pre-modified version. This parameter allows you to specify the version to retrieve data from, for example, specifying ver=(latest) when reviewing a metric.

[0137] In a possible implementation, when processing the above parameters, a parameter verification process is included.

[0138] Step 104 : Generate a second type of query language statement corresponding to the first type of query language statement based on the query semantic object, so as to provide the underlying data system with an indicator query.

[0139] Among them, the second type of query language is the query language of the underlying data system, such as SQL language or its variants.

[0140] In one possible implementation, a second type of query language statement corresponding to the first type of query language statement is generated based on the query semantic object for the underlying data system to perform indicator query, including:

[0141] If the query semantic object is constructed based on indicators and dynamic parameters, then identify the indicators and dynamic parameters based on the query semantic object;

[0142] Mapping the query semantics in the query semantic object with the query syntax of the second-category query language to generate a standard query statement that complies with the specifications of the underlying data system;

[0143] According to the dynamic parameters in the query semantic object, the corresponding query intent is parsed, and the query conditions, dimension aggregation method or time granularity information in the standard query statement are adjusted or constructed;

[0144] Fill the parsed parameter values ​​in the standard query statement, or replace the placeholders in the standard query statement, to generate a second type of query language statement corresponding to the first type of query language statement.

[0145] In one possible implementation, the system generates a corresponding physical query statement based on the query semantic object carried in the user request, including the identification and parsing of dynamic parameters, and then assembles a query statement that complies with the underlying data system specifications based on the parsing results.

[0146] The dynamic parameters in the query semantic object may include analysis dimension, time dimension, aggregation method, condition limitation or version number.

[0147] For example, let's assume a metric-based query is configured with a time dimension field named date_col and a default statistical period of "Daily." If the user doesn't enter any granularity control parameters (i.e., no dynamic parameter passing), the system will default to daily granularity for time dimension aggregation when generating a second-type query language statement (e.g., SQL statement) for the metric query, and assemble the grouping logic in the statement accordingly, as shown below:

[0148] GROUP BY DATE_FORMAT(date_col,'%Y-%m-%d')

[0149] If a user enters the dynamic parameter gran=(month) in a first-class query language statement, the system will perform semantic analysis on the parameter before generating the query statement, identifying it as a "month" granularity. Based on the configured rules, the system converts the "month" granularity into a corresponding SQL expression and dynamically constructs the time dimension aggregation logic. The generated query statement then replaces the time grouping with a monthly aggregation: GROUP BY DATE_FORMAT(date_col,'%Y-%m-01').

[0150] In another possible implementation, the identification of indicators and dynamic parameters can be implemented based on predefined structured fields in the query semantic object, with dynamic parameters stored as key-value pairs. Standard query statements are generated using a grammar mapping rule base, which contains the correspondence between the syntax elements of the second-category query language and the elements of the query semantic object. The placeholder replacement process uses a parameter template matching mechanism to traverse the key-value pairs of dynamic parameters and replace the preset markers in the standard query statement one by one.

[0151] For example, in SQL systems, the time dimension parameter is mapped to the date range condition in the where clause, and the analysis dimension is mapped to the column name in the group by clause. After generating the standard query statement, the actual value of the dynamic parameter is filled in the placeholder position. For example, if the dynamic parameter includes the time dimension {date_range: "2023-01-01 to 2023-01-31"}, the corresponding placeholder ${date_range} is replaced with the specific date range expression.

[0152] The indicator query method provided in the embodiments of this application automatically converts user-friendly language into system query language by parsing the first-class query language statement entered by the user into a parse tree, constructing a query semantic object, and generating a second-class query language statement recognizable by the underlying data system. This improves query flexibility and compatibility, reduces the complexity of direct user operation of the underlying data system, and improves query efficiency.

[0153] See also Figure 5 , shows a structural diagram of an indicator query device provided in an embodiment of the present application. For the sake of convenience, only the parts related to the embodiment of the present application are shown.

[0154] The indicator query device 500 includes:

[0155] An acquisition module 501 is used to acquire a first type of query language statement input by a user;

[0156] A parsing module 502 is configured to parse the first type of query language statement based on predefined grammatical rules and generate a corresponding parse tree;

[0157] A traversal module 503 is configured to traverse the parse tree, identify the query target in the first type of query language statement, and construct a query semantic object based on the query target. The query target includes one or more indicators and physical tables. The query semantic object is an intermediate representation structure used to represent the user's query intent.

[0158] The generation module 504 is used to generate a second type of query language statement corresponding to the first type of query language statement according to the query semantic object, so as to provide the underlying data system with indicator query. The second type of query language is the query language of the underlying data system.

[0159] In the embodiment of the present application, the traversal module 503 includes:

[0160] A first target identification submodule is configured to traverse the parse tree and identify the query target in the first type of query language statement based on the clause content corresponding to the source clause in the parse tree and the indicator metadata of the indicator platform;

[0161] A first construction submodule is configured to extract dynamic parameters associated with the indicators from the first type of query language statement when the query target is an indicator, and to construct a query semantic object based on the query target and the dynamic parameters;

[0162] The second construction submodule is used to construct a query semantic object based on the query target when the query target is a physical table.

[0163] In this embodiment of the present application, the first target recognition submodule includes:

[0164] A retrieval unit is used to traverse the parse tree and, if the corresponding clause content in the source clause contains a target identifier, search whether the target identifier exists in the indicator metadata in the indicator platform;

[0165] A first judgment unit, configured to identify the query target as an indicator if the search result is found to exist;

[0166] The second judgment unit is configured to identify the query target as a physical table if the search result indicates that the table does not exist.

[0167] In the embodiment of the present application, the traversal module 503 further includes:

[0168] A second target identification submodule is used to traverse the parse tree and identify multiple query targets in the first type of query language statement based on the clause content corresponding to the source clause in the parse tree and the indicator metadata of the indicator platform;

[0169] a third construction submodule for extracting dynamic parameters associated with each indicator from the first-type query language statement when the query target is multiple indicators, and constructing query semantic sub-objects based on each indicator and the corresponding dynamic parameter to generate multiple corresponding second-type query language sub-statements;

[0170] A fourth construction submodule is configured to, when the query target is a plurality of physical tables, construct a query semantic sub-object based on each physical table to generate a plurality of corresponding second-category query language sub-statements;

[0171] The fifth construction submodule is used to extract dynamic parameters associated with the indicators from the first type of query language statement when the query target includes indicators and physical tables, construct a first query semantic object based on the indicators and the corresponding dynamic parameters, and construct a second query semantic object based on the physical table to generate corresponding second type query language sub-statements respectively.

[0172] In an embodiment of the present application, the source clause of the parse tree includes a relation node, and the relation node includes a non-associative query structure and an associative query structure;

[0173] A non-associative query structure, including a subquery, a physical table, and an index query, is used to identify the query target as a subquery, a physical table, or an index through the non-associative query structure when a query target is included in a first-category query language statement;

[0174] The associated query structure includes multiple relationship nodes and is used to query the associated relationships of the multiple query targets through the nested form of the associated query structure when the first type query language statement includes multiple query targets.

[0175] In the embodiment of the present application, the generating module 504 includes:

[0176] a third identification submodule, configured to identify the indicators and dynamic parameters according to the query semantic object if the query semantic object is constructed based on the indicators and dynamic parameters;

[0177] A mapping submodule is used to map the query semantics in the query semantic object with the query syntax of the second type of query language to generate a standard query statement that complies with the specifications of the underlying data system;

[0178] The parsing submodule is used to parse the corresponding query intent based on the dynamic parameters in the query semantic object, and adjust or construct the query conditions, dimension aggregation method or time granularity information in the standard query statement;

[0179] The statement generation submodule is used to fill the parsed parameter values ​​in the standard query statement, or replace the placeholders in the standard query statement, to generate a second type of query language statement corresponding to the first type of query language statement.

[0180] In an embodiment of the present application, the dynamic parameters queried in the indicator query device include one or more of analysis dimension, time dimension, aggregation method, condition limitation, and version number.

[0181] The indicator query device 500 provided in the embodiment of the present application can be applied to the indicator query method provided in the aforementioned embodiment. For details, please refer to the description of the indicator query method provided in the aforementioned embodiment, which will not be repeated here.

[0182] Figure 6 Schematic diagram of the structure of the electronic device provided in the embodiment of the present application. Figure 6 As shown, the electronic device 600 of this embodiment includes: at least one processor 610 ( Figure 6 Only one is shown in the figure) a processor, a memory 620, and a computer program 621 stored in the memory 620 and executable on the at least one processor 610, wherein the processor 610 implements the steps in the above-mentioned indicator query method embodiment when executing the computer program 621.

[0183] The electronic device 600 may be a server, a physical server, a computing device, etc. The electronic device may include, but is not limited to, a processor 610 and a memory 620. It will be understood by those skilled in the art that Figure 6 This is merely an example of the electronic device 600 and does not constitute a limitation on the electronic device 600 . The electronic device 600 may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the electronic device 600 may also include input and output devices, network access devices, etc.

[0184] The processor 610 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. A general-purpose processor may be a microprocessor or any conventional processor.

[0185] In some embodiments, the memory 620 may be an internal storage unit of the electronic device 600, such as a hard disk or memory of the electronic device 600. In other embodiments, the memory 620 may also be an external storage device of the electronic device 600, such as a plug-in hard disk equipped on the electronic device 600, a Smart Media Card (SMC), a Secure Digital (SD) card, a Flash Card, etc. Furthermore, the memory 620 may include both an internal storage unit of the electronic device 600 and an external storage device. The memory 620 is used to store an operating system, application programs, a boot loader, data, and other programs, such as the program code of the computer program. The memory 620 may also be used to temporarily store data that has been output or is about to be output.

[0186] In a specific implementation, the processor 610, memory 620, and computer program 621 described in the embodiments of the present application can execute the embodiments of the indicator query method of the present application, which will not be repeated here.

[0187] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0188] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0189] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0190] In the embodiments provided in the present application, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic device embodiments described above are merely schematic. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0191] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0192] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0193] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the process in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and when the computer program is executed by the processor, it can implement the steps of the above-mentioned various method embodiments. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0194] The present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed through a computer program product. When the computer program product runs on an electronic device, the electronic device can implement the steps in the above-mentioned method embodiments when executing.

[0195] The above embodiments are intended only to illustrate the technical solutions of the present application and are not intended to limit them. Although the present application has been described in detail with reference to the above embodiments, those skilled in the art should understand that they may still modify the technical solutions described in the above embodiments or replace some of the technical features therein with equivalents; and such modifications or replacements do not deviate from the spirit and scope of the technical solutions of the embodiments of the present application and should be included within the scope of protection of the present application.

Claims

1. An indicator query method, characterized in that: The indicator query method includes: Get the first type of query language statement input by the user; Performing grammatical parsing on the first type of query language statements based on predefined grammatical rules to generate a corresponding parse tree; Traversing the parse tree, identifying a query target in the first type of query language statement, and constructing a query semantic object based on the query target, wherein the query target includes one or more of an indicator and a physical table, and the query semantic object is an intermediate representation structure for representing the user's query intent; According to the query semantic object, a second type of query language statement corresponding to the first type of query language statement is generated for the underlying data system to perform indicator query. The second type of query language is the query language of the underlying data system.

2. The index query method according to claim 1, characterized in that: The traversing the parse tree, identifying a query target in the first type of query language statement, and constructing a query semantic object based on the query target includes: Traversing the parse tree, and identifying a query target in the first type of query language statement based on clause content corresponding to a source clause in the parse tree and indicator metadata of an indicator platform; When the query target is an indicator, extracting dynamic parameters associated with the indicator from the first type of query language statement, and constructing a query semantic object based on the query target and the dynamic parameters; When the query target is a physical table, a query semantic object is constructed based on the query target.

3. The index query method according to claim 2, characterized in that: Traversing the parse tree and identifying a query target in the first type of query language statement according to clause content corresponding to a source clause in the parse tree and indicator metadata of an indicator platform includes: Traversing the parse tree, if the corresponding clause content in the source clause contains a target identifier, searching whether the target identifier exists in the indicator metadata in the indicator platform; If the search result is that the query target exists, the query target is identified as an indicator; If the search result is that the table does not exist, the query target is identified as a physical table.

4. The index query method according to claim 1, characterized in that: The traversing the parse tree, identifying the query target in the first type of query language statement, and constructing a query semantic object based on the query target further includes: Traversing the parse tree, and identifying multiple query targets in the first type of query language statement based on clause contents corresponding to source clauses in the parse tree and indicator metadata of the indicator platform; When the query target is multiple indicators, extracting dynamic parameters associated with each indicator from the first type of query language statement, and constructing query semantic sub-objects based on each indicator and the corresponding dynamic parameter to generate multiple corresponding second type query language sub-statements; When the query target is multiple physical tables, constructing query semantic sub-objects based on each physical table to generate multiple corresponding second-category query language sub-statements; When the query target includes indicators and physical tables, dynamic parameters associated with the indicators are extracted from the first type of query language statements, a first query semantic object is constructed based on the indicators and the corresponding dynamic parameters, and a second query semantic object is constructed based on the physical table to generate corresponding second type query language sub-statements respectively.

5. The indicator query method according to any one of claims 2 to 4, characterized in that: The source clause of the parse tree includes a relation node, and the relation node includes a non-association query structure and an association query structure; When the first type of query language statement includes a query target, identifying the query target as a subquery, a physical table, or an index through the non-associative query structure, wherein the non-associative query structure includes queries of subqueries, physical tables, and indexes; When the first type of query language statement includes multiple query targets, the association relationship among the multiple query targets is queried through the nested form of the association query structure, wherein the association query structure includes multiple relationship nodes.

6. The index query method according to claim 2, characterized in that: Generating, based on the query semantic object, a second type of query language statement corresponding to the first type of query language statement for use by an underlying data system in performing an indicator query, includes: If the query semantic object is constructed based on the indicator and the dynamic parameter, identifying the indicator and the dynamic parameter according to the query semantic object; Mapping the query semantics in the query semantic object with the query syntax of the second type of query language to generate a standard query statement that complies with the specification of the underlying data system; According to the dynamic parameters in the query semantic object, the corresponding query intent is parsed, and the query conditions, dimension aggregation method or time granularity information in the standard query statement are adjusted or constructed; Fill the parsed parameter values ​​in the standard query statement, or replace the placeholders in the standard query statement, to generate a second type of query language statement corresponding to the first type of query language statement.

7. The index query method according to claim 6, characterized in that: The dynamic parameters include one or more of analysis dimension, time dimension, aggregation method, condition limitation, and version number.

8. An indicator query device, characterized in that: The indicator query device includes: An acquisition module, used for acquiring a first-class query language statement input by a user; A parsing module, configured to perform grammatical parsing on the first type of query language statements based on predefined grammatical rules and generate a corresponding parse tree; a traversal module, configured to traverse the parse tree, identify a query target in the first type of query language statement, and construct a query semantic object based on the query target, wherein the query target includes one or more of an indicator and a physical table, and the query semantic object is an intermediate representation structure for representing the user's query intent; A generation module is used to generate a second type of query language statement corresponding to the first type of query language statement based on the query semantic object, so as to provide the underlying data system with indicator query, and the second type of query language is the query language of the underlying data system.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images