Data query method

Abstract

Embodiments of the present application relate to the field of Internet, and disclose a data query method. The method comprises: obtaining a query request; performing keyword extraction on query description information included in the query request to obtain one or more query parameters; searching for a plurality of query sub-services matched with the one or more query parameters; selecting a target query sub-service from the plurality of query sub-services, wherein the load of the target query sub-service is less than the load of other query sub-services, or, among the one or more query parameters, the number of query parameters that can be queried by the target query sub-service is more than the number of query parameters that can be queried by other query sub-services; calling the target query sub-service to perform data query based on the one or more query parameters, obtaining query data, and outputting the query data. The embodiments of the present application can intelligently select the optimal query sub-service and call the query sub-service to perform data query, thereby effectively improving the efficiency of data query.

Description

Technical Field

[0001] This application relates to the Internet field, and in particular to data query methods. Background Technology

[0002] A query engine is a retrieval technology that retrieves data from the internet that matches a user's needs based on the query algorithm and then returns that data to the user. Currently, query algorithms are typically fixed and unique; for example, a query engine retrieves data matching any user's needs based on that algorithm and the user's specific requirements. If the algorithm's computational power is weak, the query engine's efficiency will be low. Therefore, improving the query efficiency of query engines is a pressing technical problem that needs to be solved. Summary of the Invention

[0003] This application provides a data query method that can effectively improve the efficiency of data query.

[0004] On one hand, embodiments of this application provide a data query method, which includes:

[0005] Obtain a query request; wherein the query request includes query description information;

[0006] Keyword extraction is performed on the query description information to obtain one or more query parameters;

[0007] Find multiple query sub-services that match the one or more query parameters; wherein each of the multiple query sub-services has the function of querying query data indicated by at least one of the one or more query parameters;

[0008] Select a target query subservice from the plurality of query subservices; wherein the load of the target query subservice is less than the load of the other query subservices, or, among the one or more query parameters, the number of query parameters that the target query subservice can query is greater than the number of query parameters that the other query subservices can query.

[0009] The target query sub-service is invoked to perform a data query based on one or more query parameters, obtain the query data, and output the query data.

[0010] In one embodiment, the method further includes: the one or more query parameters include at least one query dimension and at least one query metric; the method of finding multiple query sub-services that match the one or more query parameters includes:

[0011] Traverse the at least one query metric to determine the query sub-service that matches the at least one query dimension and the currently traversed query metric; wherein each determined query sub-service has the function of querying the corresponding query metric under the at least one query dimension.

[0012] After the traversal is complete, each determined query sub-service will be treated as a set of query sub-services that match one or more query parameters.

[0013] In one embodiment, selecting the target query sub-service from the plurality of query sub-services includes:

[0014] For any query metric, a target query sub-service is selected from the query sub-service cluster corresponding to the query metric, and an association is established between the query metric and the selected target query sub-service; wherein, the query sub-service cluster includes at least one query sub-service that can query the query metric.

[0015] The invocation of the target query sub-service, based on one or more query parameters, to perform data query and obtain query data includes:

[0016] The target query sub-service is invoked, and data is queried based on the query metrics associated with the target query sub-service and the at least one query dimension to obtain the query data.

[0017] In one embodiment, selecting a target query sub-service from the query sub-service cluster corresponding to any query metric includes:

[0018] Get the amount of query data for each query subservice in the query subservice cluster corresponding to any one of the query metrics;

[0019] The query subservice with the smallest amount of query data is selected as the target query subservice.

[0020] In one embodiment, the method further includes: if the amount of query data based on the query indicator is not obtained from any query sub-service in the query sub-service cluster corresponding to any query indicator, then the query sub-service in the query sub-service cluster corresponding to any query indicator and arranged at a preset position is taken as the target query sub-service.

[0021] In one embodiment, the method further includes: obtaining the query metrics that can be queried by the query sub-services associated with each query metric;

[0022] If a first query sub-service and a second query sub-service exist among the query sub-services associated with the at least one query indicator, then the association between the target query indicator and the second query sub-service associated with the second query sub-service is deleted, and the association between the target query indicator and the first query sub-service is established; wherein, the query indicators that the first query sub-service can query include the target query indicator.

[0023] In one embodiment, the method further includes: if there is a third query sub-service in the target query sub-service with a load higher than a preset threshold, then recall the fourth query sub-service; wherein the fourth query sub-service can query at least one target query indicator associated with the third query sub-service, and the load of the fourth query sub-service is lower than the preset threshold.

[0024] Delete the association between the third query sub-service and at least one target query indicator, and establish an association between the third query sub-service and the at least one target query indicator.

[0025] In one embodiment, the one or more query parameters include at least one query dimension and at least one query metric; the method further includes:

[0026] Obtain a query type prediction strategy, which includes a set of query dimensions and a set of query metrics;

[0027] If the at least one query dimension includes at least the query dimensions in the query dimension set, and the at least one query indicator includes at least the query indicators in the query indicator set, then the estimated query type of the query request is the target query type.

[0028] Output a prompt message, which indicates that the query type of the query request is the target query type.

[0029] In one embodiment, the method further includes: if any query dimension in the query dimension set is different from the at least one query dimension, or any query metric in the query metric set is different from the at least one query metric, then the method of finding multiple query sub-services that match the one or more query parameters is triggered, a target query sub-service is selected from the multiple query sub-services, the target query sub-service is called, data is queried based on the one or more query parameters, query data is obtained, and the query data is output.

[0030] In one embodiment, the one or more query parameters further include at least one filtering condition, and the query type prediction strategy further includes a set of filtering conditions; if the at least one query dimension includes at least the query dimensions in the query dimension set, and the at least one query metric includes at least the query metrics in the query metric set, then the predicted query type of the query request is the target query type, including:

[0031] If the at least one filtering condition includes at least the filtering conditions in the set of filtering conditions, and the number of the at least one filtering condition is greater than the number of filtering conditions included in the set of filtering conditions, and if the at least one query dimension includes at least the query dimension in the set of query dimensions, and the at least one query indicator includes at least the query indicator in the set of query indicators, then the estimated query type of the query request is the target query type.

[0032] On the other hand, embodiments of this application provide a data query device, which includes:

[0033] An input unit is used to obtain a query request; wherein the query request includes query description information;

[0034] The processing unit is used to extract keywords from the query description information to obtain one or more query parameters;

[0035] The processing unit is further configured to find multiple query sub-services that match the one or more query parameters; wherein each of the multiple query sub-services has the function of querying query data indicated by at least one of the one or more query parameters;

[0036] The processing unit is further configured to select a target query sub-service from the plurality of query sub-services; wherein the load of the target query sub-service is less than the load of other query sub-services, or, among the one or more query parameters, the number of query parameters that the target query sub-service can query is greater than the number of query parameters that other query sub-services can query.

[0037] The processing unit is also used to call the target query sub-service to perform data query based on one or more query parameters to obtain query data;

[0038] The output unit is used to output the query data.

[0039] On the other hand, embodiments of this application provide a computer device including a processor, a storage device, and a communication interface, wherein the processor, storage device, and communication interface are interconnected, wherein the storage device is used to store a computer program that supports a terminal in executing the above-described method, the computer program including program instructions, and the processor is configured to invoke the program instructions to execute the following steps:

[0040] Obtain a query request; wherein the query request includes query description information;

[0041] Keyword extraction is performed on the query description information to obtain one or more query parameters;

[0042] Find multiple query sub-services that match the one or more query parameters; wherein each of the multiple query sub-services has the function of querying query data indicated by at least one of the one or more query parameters;

[0043] Select a target query subservice from the plurality of query subservices; wherein the load of the target query subservice is less than the load of the other query subservices, or, among the one or more query parameters, the number of query parameters that the target query subservice can query is greater than the number of query parameters that the other query subservices can query.

[0044] The target query sub-service is invoked to perform a data query based on one or more query parameters, obtain the query data, and output the query data.

[0045] On the other hand, embodiments of this application provide a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor, cause the processor to perform the data query method described in any of the above aspects.

[0046] On the other hand, embodiments of this application provide a computer product, the computer product including a computer program, the computer program being adapted to be loaded by a processor and execute the data query method described in any of the above aspects.

[0047] In this embodiment, after obtaining a query request, keywords are extracted from the query description information included in the query request to obtain one or more query parameters. Multiple query sub-services matching the one or more query parameters are searched. A target query sub-service is selected from these sub-services and invoked. The target query sub-service performs a data query based on the one or more query parameters to obtain and output the query data. This embodiment can intelligently select the optimal query sub-service, where the load of the optimal query sub-service is less than the load of other query sub-services, or, among the one or more query parameters, the number of query parameters that the optimal query sub-service can query is greater than the number of query parameters that other query sub-services can query. Therefore, invoking this query sub-service for data querying can effectively improve the efficiency of data querying. Attached Figure Description

[0048] 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, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0049] Figure 1 This is a schematic diagram of the architecture of a query engine provided in an embodiment of this application;

[0050] Figure 2 This is a schematic diagram of code data for a filtering condition provided in an embodiment of this application;

[0051] Figure 3 This is a schematic diagram of code data for a request input parameter provided in an embodiment of this application;

[0052] Figure 4 This is a schematic diagram of a request parameter structure provided in an embodiment of this application;

[0053] Figure 5 This is a schematic diagram of code data for a query result provided in an embodiment of this application;

[0054] Figure 6 This is a schematic diagram of a query result structure provided in an embodiment of this application;

[0055] Figure 7 This is a schematic diagram of the architecture of a query sub-service provided in an embodiment of this application;

[0056] Figure 8 This is a schematic diagram of a class diagram illustrating an implementation method for a customized development query sub-service provided in an embodiment of this application;

[0057] Figure 9 This is a flowchart illustrating a data query method provided in an embodiment of this application;

[0058] Figure 10 This is a flowchart illustrating another data query method provided in an embodiment of this application;

[0059] Figure 11 This is a schematic diagram of the structure of a data query device provided in an embodiment of this application;

[0060] Figure 12 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

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

[0062] Query engines can be used to retrieve data that meets user needs. They can be applied in various scenarios. In one example, a query engine can be used to query advertising data, such as the performance-based cash expenditure of advertisers A and B between October 1st and October 31st, 2022, or the click volume of advertiser C on October 1st, 2022, and so on. In another example, a query engine can be used to query medical data, such as retrieving user A's medical records between October 1st and October 31st, 2022. In yet another example, a query engine can be used to query traffic data, such as retrieving the number of traffic violations committed by vehicle A between October 1st and October 31st, 2022. Given the complexity of user needs in daily use, effectively improving the efficiency of data retrieval is a pressing technical challenge.

[0063] The data query method provided in this application can be applied to a data query device. For example, the data query device may include a data query component, a data query plugin, a data query function, or a data query algorithm. For instance, the data query device can run within a query engine. After a user submits query description information in the query engine's query area, the query engine can generate a query request containing that query description information and send it to the data query device. The data query device can then perform a data query based on the query description information. Similarly, after a user submits query description information in the query engine's query area, the query engine can generate a query request containing that query description information and invoke the data query device to perform a data query based on that query description information. The query engine can run in a computer device, which includes, but is not limited to, electronic devices such as smartphones, in-vehicle devices, wearable devices, or computers.

[0064] In the specific implementation of this application, user-related data is involved, such as query description information. When the embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with local laws, regulations and standards.

[0065] It is understood that the data query scheme mentioned in this application is introduced using advertising data as an example, and will not limit the scope of this application. The data query scheme mentioned in this application can also be applied to scenarios of querying other data, such as medical data or traffic data, and this application does not limit it.

[0066] by Figure 1 Taking the schematic diagram of the query engine architecture shown as an example, the query engine can include at least a parameter model, a routing configuration module, an intelligent query optimizer, and query sub-services.

[0067] In one embodiment, a parameter model can be constructed before implementing the data query method provided in this application. The parameter model can include request input parameters (i.e., query parameters) and query results (i.e., query data). The parameter model is designed to be simple and easy to use while also being compatible with various personalized and complex queries. Therefore, the interface uses the Thrift Remote Procedure Call (RPC) framework to ensure that clients using various programming languages ​​can use it. Thrift is a lightweight, cross-language RPC framework primarily used for RPC communication between various services. It uses its own Interface Description Language (IDL) as an intermediate language and leverages a code generation engine to generate RPC server / client template code in various mainstream languages. Thrift supports a variety of programming languages, including C++, Java, Python, PHP, Ruby, Erlang, Haskell, C#, Cocoa, Javascript, Node.js, Smalltalk, OCaml, and Golang.

[0068] The configuration of the IDL content of the RPC interface can include the configuration of the request input parameters and the configuration of the query results.

[0069] Optionally, the configuration of the request input parameters can include one or more of the following:

[0070] Sub-service identifier (service name): If the query description information in the query request does not include a sub-service identifier, the data query device can determine the target query sub-service using the data query method provided in this application and call the target query sub-service to perform the data query. For customized scenarios, when submitting a query request, the user can enter a sub-service identifier, and then the data query device can call the query sub-service corresponding to the sub-service identifier entered by the user to perform the data query.

[0071] Dimensions: Dimension parameters represent which dimensions of data a user wants to query. For example, dimensions can include ad creatives, ad campaigns, ad groups, search keywords, advertiser identifiers (i.e., advertiser IDs), campaign account IDs, agencies, enterprise IDs, or store IDs. For instance, if a user wants to query data at the ad group and ad account granularity, they can pass ['compaign_id', 'advertiser_id'] when submitting the query request, where 'compaign_id' represents the ad group identifier and 'advertiser_id' represents the ad account identifier.

[0072] Metrics: Metric parameters are used to represent which metrics a user wants to query. For example, metrics can include spending metrics for various types of ads, impressions, clicks, click-through rate (CTR), cost per thousand impressions (CPM), cost per click (CPC), likes, or favorites. For instance, if a user wants to query impressions, clicks, and cost, they can pass in ['show_cnt', 'click_cnt', 'cost'], where show_cnt represents impressions, click_cnt represents clicks, and cost represents cost. The default aggregation method for metrics is SUM, meaning the query results include data for each metric.

[0073] Complex Metrics: Complex metrics can be used to indicate the aggregation method of at least one metric. If the query description in the query request does not include complex metrics, the default aggregation method for at least one metric in the query description is SUM, meaning the query results include the query data for each metric. When users want to query results with other aggregation methods, they can submit complex metrics such as MAX, MIN, AVERGAE, COUNT, or COUNT_DISTINCT. MAX indicates that the query results include the maximum value of at least one metric in the query description. MIN indicates that the query results include the minimum value of at least one metric in the query description. AVERGAE indicates that the query results include the mean of at least one metric in the query description. COUNT indicates that the query results include the sum of at least one metric in the query description. COUNT_DISTINCT indicates that the query results include the sum of the unique values ​​of at least one metric in the query description. For example, if a user wants to query the maximum value of at least one click, they can pass in [{'fieldName':'click_cnt', 'aggType':'MAX'}].

[0074] Sorting: Sorting can be used to indicate which field to sort by, such as sorting by a dimension or by a metric. For example, if a user wants the query results to be sorted in descending order of cost, they can pass in [{'fieldName':'cost', 'sortDesc':'DESC'}], where DESC indicates descending order, that is, sorting from largest to smallest.

[0075] Filtering conditions (filters): Filtering conditions can include multiple settings variables. Optionally, filtering conditions can contain up to 8 settings variables, but for different filtering scenarios, only a number of parameters less than 8 is needed. Specifically, `fieldName` is a required field and can be used to indicate which field to filter. `inNumValues` can be used to indicate multi-value filtering of numeric data. `inStrValues` can be used to indicate multi-value filtering of string data. In the case of `inNumValues` or `inStrValues`, the operator defaults to `IN` (in). `numValue` can be used to indicate single-value filtering of numeric data. `strValue` can be used to indicate single-value filtering of string data. In the case of `numValue` or `strValue`, the operator defaults to `EQUAL` (=). `dateTimeUpper` and `dateTimeLower` correspond to the upper and lower thresholds of dates, respectively; in this case, the operator defaults to `BETWEEN`. The above settings variables can filter various types of single-value, multi-value, and date data with very simple filtering parameters. If there are special filters, the value of the operator can be customized to achieve personalized effects. Figure 2 The code data shown in the filter condition describes data with a query date range between October 1, 2022 and October 31, 2022, and advertiser accounts "5483bde92e1d93358f1" and "5634fb2d9eb57874db24".

[0076] Count (limit): This indicates the maximum number of records that can be displayed per page when paginating. If the query description in the query request does not include a count, the default maximum number of records displayed per page is 500.

[0077] Offset: This indicates the page number on which content is displayed in a paginated layout. If the query description in the query request does not include the number of records, the default offset is 0. For example, assuming a maximum of 500 records per page, the offset for records 1 to 500 is 0, meaning records with an offset of 0 are displayed on the first page; the offset for records 501 to 1000 is 1, meaning records with an offset of 1 are displayed on the second page.

[0078] by Figure 3Taking the code data of the request parameters shown as an example, the request parameters describe the cash expenditure of the two advertisers "5483bde92e1d93358f1" and "5634fb2d9eb57874db24" between October 1, 2022 and October 31, 2022.

[0079] For example, the structure of the request parameters can be as follows: Figure 4 As shown, it includes dimensions, metrics, filtering conditions, etc.

[0080] The embodiments of this application, through the configuration of the above-described request input parameters, are simple and easy to use, while also supporting personalized and complex queries.

[0081] Optionally, the query results configuration can include one or more of the following:

[0082] Response information: Response information may include status codes, messages, etc., and can be used to indicate whether an API request was successfully responded to. Figure 5 Taking the code data of the query results shown as an example, "code": 0 indicates interface 0, and "success": true indicates that the interface request was successfully responded to.

[0083] Querying data: Querying data can include two parts: dimensions and metrics. Dimensions can be represented using a map.<string,string> This means that metrics can be used with map.<string,double> Indicated. With Figure 5 For example, the query data describes that advertiser "5483bde92e1d93358f1" had a cash cost of 0, while advertiser "5634fb2d9eb57874db24" had a cash cost of 204522.

[0084] Partition Time: Partition Time can be empty. If the query is for the latest partition data of offline data, the latest partition value of the offline data will be returned, allowing users to know the latest data date. For example, offline data for different time periods is stored in different partitions, and the partition value is used to uniquely identify the partition. Suppose the query engine responds to a query request to retrieve the performance cash consumption of advertiser "5483bde92e1d93358f1" between October 1, 2022 and October 31, 2022. Due to the large volume of data queries, to let users know which day's offline data the query engine is currently retrieving, it can return the partition value of the partition where the currently queried offline data is located. For example, if the query engine is retrieving the offline data of advertiser "5483bde92e1d93358f1" on October 10, 2022, then the query engine can return the partition value of the partition where the offline data of advertiser "5483bde92e1d93358f1" on October 10, 2022 is located.

[0085] Total: The total number can be used to indicate the total number of records in the query.

[0086] For example, the structure of the query results can be as follows: Figure 6 As shown, the results include response information and query data. Optionally, query results can be merged according to dimensions, such as merging different indicators under the same dimension. Optionally, the query results can also be sorted, paginated, or formatted to obtain the retrieved data (i.e., query data), and then the retrieved data can be output.

[0087] In one embodiment, before implementing the data query method provided in this application, routing configuration can be performed through the routing configuration module.

[0088] The underlying layer of the query engine in this application embodiment is composed of multiple query sub-services from different business lines. The indicator data required for a single query may come from multiple query sub-services. Therefore, the identifier of each query sub-service, as well as the dimensions and indicators that the query sub-service can provide, are configured in the routing configuration stage to facilitate the intelligent query optimizer to perform parsing and optimization.

[0089] The route configuration phase is also the metric and dimension definition phase. A dimension or metric with the same meaning can only be identified by one field, and duplicate definitions are not allowed. In other words, one field uniquely identifies one dimension or metric. Only after definition can it be selected in the route configuration phase. The configuration phase requires filling in the data source, sub-service name, dimension, metric, and derived metrics, as detailed below:

[0090] Data source: Data sources can include two types: system-connected data sources (MySQL, Doris, ClickHouse, or Elasticsearch, etc.) and customized data sources (i.e. customized query sub-services). Different data sources can be selected according to specific business scenarios.

[0091] Sub-service name (serviceName): A unique identifier for the queried sub-service; different queried sub-services cannot have the same identifier. For example, the naming convention for sub-services in the data source accessed by the system can be database_table_service, where the database name is the database identifier of the database containing the queried sub-service, and the table name is the identifier of the space within that database. Customized data sources can be named according to business scenarios.

[0092] Dimensions: The query dimensions supported by each query sub-service. For example, if a query sub-service can support querying data at the granular level of ad groups and advertiser accounts, then the dimension fields associated with that query sub-service should be entered as ['compaign_id', 'advertiser_id'].

[0093] Metrics: The metrics that each query sub-service supports querying. For example, if a query sub-service can support querying data on impressions, clicks, and costs, then the metric fields associated with that query sub-service should be entered as ['show_cnt', 'click_cnt', 'cost'].

[0094] Derivative metrics: Derivative metrics refer to metrics obtained by processing the above metrics. Derivative metrics can include click-through rate (CTR), display rate, etc. For example, if a query sub-service can support querying CTR, then the associated derived metric field for that query sub-service can be ['click_rate']. The calculation method for derived metrics is entered as [{'click_rate':'sum(click_cnt) / sum(show_cnt)'}], where sum(click_cnt) can represent the total number of clicks, and sum(show_cnt) can represent the total number of displays.

[0095] In this embodiment, routing configuration information can be stored in Elasticsearch, while dimension, metric, and derived metric mapping information is stored as arrays. The calculation method for derived metrics is stored as a JSON array, facilitating fast filtering and retrieval and ensuring system query performance. Elasticsearch is the core distributed search and analytics engine of the Elastic Stack. Elasticsearch provides near real-time search and analysis for all types of data. Whether it's structured or unstructured text, numerical data, or geospatial data, Elasticsearch can efficiently store and index it in a way that supports fast search. The number of dimensions, metrics, or derived metrics can be one or more, consisting of one or more dimension identifiers, metric identifiers, or derived metric identifiers; therefore, dimensions, metrics, and derived metrics can be stored as arrays. The calculation method for derived metrics needs to indicate which metrics were used for calculation and the logical operators between the metrics; therefore, the calculation method for derived metrics is stored as a JSON array.

[0096] Table 1 below illustrates the routing configuration information for two types of query sub-services: system access data sources and user-defined queries.

[0097] Table 1

[0098]

[0099] As shown in Table 1, for the query sub-service named ads_doris_ads_advertiser_mix_metrics_day_service, the data source for this query sub-service is the data source accessed by the system, namely Doris. The dimensions that this query sub-service can query include ad group (compaign_id) and advertiser account (advertiser_id). The metrics that this query sub-service can query include impressions (show_cnt), clicks (click_cnt), and cost. The derived metrics that this query sub-service can query include click-through rate (click_rate), which is calculated as sum(click_cnt) / sum(show_cnt). For the query subservice named rtb_realtime_calc_service, the data source for this query subservice is user-defined, i.e., a customized data source. The dimensions that this query subservice can query include the store merchant account (brand_user_id) and the seller account (v_seller_id). The metrics that this query subservice can query include the hourly cumulative fee (hourly_fee) and the execution budget (budget_utilization). This query subservice does not have any derived metrics that can be queried.

[0100] by Figure 7 Taking the schematic diagram of the query sub-service architecture as an example, the query sub-service is divided into two types: automatically generated query sub-service (DB subServer) based on the data source type accessed by the system, and customized query sub-service (user-defined subServer).

[0101] Automatic Generation of Query Sub-Services: The automatic generation of query sub-services is fully automated, requiring no code development. First, based on the sub-service name (database name_table name_service) and data source in the routing configuration, the corresponding cluster, database name, and table name for the query sub-service can be parsed. Second, based on the storage engine type and the query plan generated by the intelligent query optimizer (including various basic data such as dimensions, metrics, and filtering conditions), the corresponding sqlBuilder module is selected to construct the corresponding execution SQL. Finally, the data source (Datasource) corresponding to the current storage engine is selected for connection, and the doQuery query (i.e., calling the query sub-service to query data) is executed to obtain the query results. The query results can be merged based on dimensions (i.e., join & order based on dimension primary keys), and then transformed or formatted to obtain the query data, which is then returned. The entire process automatically constructs the query logic for generating query sub-services based on various information in the context environment. No code writing is required; only the routing information of the relevant query sub-services needs to be configured in the routing configuration stage to enable the new query sub-services to be integrated into the system.

[0102] Customized query sub-services are designed for scenarios that cannot be generalized, such as those requiring calls to third-party data interfaces or hard-coded data. Through customized coding, the query engine can cover all commercial business scenarios. The implementation diagram of customized query sub-services is shown in Figure 8. Different specific implementations represent different customization approaches. The name of the customized query sub-service is defined using the `@Component` annotation.

[0103] Based on this query engine, after receiving a query request, the intelligent query optimizer extracts keywords from the query description information included in the query request to obtain one or more query parameters. It then finds multiple query sub-services that match one or more query parameters, selects the target query sub-service from the multiple query sub-services (i.e., generates the optimal query path), and then calls the target query sub-service to perform data query based on one or more query parameters to obtain query results. The query results can be merged according to dimensions, and the query results can be sorted, paginated, or formatted to obtain the retrieved data, which is then output.

[0104] In one implementation, the query engine may also include a query type prediction module. For details regarding the intelligent query optimizer's functionality, please refer to [link to relevant documentation]. Figure 9 For details regarding the data query methods shown, and the functions of the query type prediction module, please refer to [link / reference]. Figure 10 The data query methods shown are described below. The various modules within the query engine work together to give it high scalability, high availability, and intelligent optimization capabilities.

[0105] The query engine in this embodiment can handle all data query scenarios for commercial data teams and meet the diverse needs of different users. The underlying query engine supports cross-engine and cross-database data association, possesses strong scalability, and is compatible with various data sources, including databases such as MySQL, Doris, ClickHouse, and Elasticsearch. Furthermore, users can obtain data from any combination of dimensions and metrics through this query engine, and it is very simple and easy to use. The definition of dimensions and metrics is standardized and concise, greatly improving the reliability and standardization of the data.

[0106] Based on the above description, please refer to Figure 9 , Figure 9 This is a flowchart illustrating a data query method provided in an embodiment of this application; as shown below. Figure 9 The data query method shown includes, but is not limited to, steps S901 to S905, wherein:

[0107] S901, Obtain the query request, which includes query description information.

[0108] For example, when a data query device detects that a user has submitted a query description in the query area of ​​the query engine, it can generate a query request that includes that query description. The query description describes the user's query requirements.

[0109] S902, extract keywords from the query description information to obtain one or more query parameters.

[0110] The data query device extracts keywords from the query description information, which can be understood as: performing route parsing on the query description information, that is, parsing fields such as dimensions, metrics, or filtering conditions in the request input parameters to obtain one or more query parameters, which may include dimensions, metrics, or filtering conditions.

[0111] S903, find multiple query subservices that match one or more query parameters.

[0112] Each of the multiple query sub-services has the function of querying data indicated by at least one of the query parameters. A description of the query sub-services can be found above.

[0113] In one implementation, one or more query parameters include at least one query dimension and at least one query indicator; the data query device may find multiple query sub-services that match one or more query parameters by: traversing at least one query indicator to determine query sub-services that match at least one query dimension and the currently traversed query indicator; wherein each determined query sub-service has the function of querying the corresponding query indicator under at least one query dimension; after the traversal is completed, each determined query sub-service is used as multiple query sub-services that match one or more query parameters.

[0114] For example, all dimensions in the query parameters can be treated as a whole and then combined with each metric. For instance, if the query parameters contain 2 dimensions ['compaign_id', 'advertiser_id'], 3 metrics ['show_cnt', 'click_cnt', 'cost'], and 2 filter conditions dtm and advertiser_id, then the parsed combinations include 3, namely {'dimensions': ['compaign_id', 'advertiser_id'], 'metrics': 'show_cnt'}, {'dimensions': ['compaign_id', 'advertiser_id'], 'metrics': 'click_cnt'}, and {'dimensions': ['compaign_id', 'advertiser_id'], 'metrics': 'cost'}. Secondly, the dimensions and metrics in each combination are compared with the dimensions and metrics associated with each query sub-service in the routing table. If the dimensions and metrics in a combination are all subsets of the dimensions and metrics associated with a certain query sub-service in the routing table, and the filtering conditions in the query parameters are also subsets of the filtering conditions associated with that query sub-service in the routing table, then the query sub-service matching that combination is the aforementioned query sub-service (that is, this query sub-service can query this metric under the dimensions and filtering conditions in the query parameters). The number of query sub-services matching the same combination can be multiple (i.e., there are multiple ways to query this metric under the dimensions and filtering conditions in the query parameters). Therefore, a mapping relationship can be established between each query metric and the query sub-service, thus revealing which query sub-services can be used to query each query metric.

[0115] In one implementation, the query engine provides users with a general parameter model, but its underlying implementation is compatible with multiple data sources. Different storage engines have slightly different SQL syntax and aggregate functions. This embodiment provides various calculation functions in ANSI SQL syntax, shielding users from the syntax of the underlying data source. If the current query request ultimately queries the ClickHouse data source, the data query device can rewrite `count(*)` to `count()` and `countDistinct(...)` to `uniqExact(...)`.

[0116] S904: Select the target query subservice from multiple query subservices.

[0117] Specifically, the load of the target query subservice is less than the load of other query subservices, or, among one or more query parameters, the number of query parameters that the target query subservice can query is greater than the number of query parameters that other query subservices can query.

[0118] In one implementation, for any given query metric, a target query sub-service can be selected from the query sub-service cluster corresponding to that metric, and an association is established between the metric and the selected target query sub-service. The query sub-service cluster includes at least one query sub-service capable of querying any given query metric. Further, the target query sub-service is invoked, and data is queried based on the associated query metric and at least one query dimension to obtain the query data.

[0119] In one implementation, the method for selecting a target query subservice from the query subservice cluster corresponding to any query metric can be as follows: obtain the query data volume of each query subservice in the query subservice cluster corresponding to any query metric, and select the query subservice with the smallest query data volume as the target query subservice.

[0120] In one implementation, if the amount of query data based on any query indicator is not obtained from any query sub-service in the query sub-service cluster corresponding to any query indicator, then the query sub-service in the query sub-service cluster corresponding to any query indicator and arranged in a preset position is taken as the target query sub-service.

[0121] In this embodiment, the same metric may hit multiple query sub-services, and the multiple query sub-services hit by any metric constitute the query sub-service cluster corresponding to that metric. Based on the baseline data statistically obtained during the large query prediction phase, the amount of data in the underlying query table of each query sub-service can be determined. At this point, the query sub-service with the smallest data volume and the coarsest data granularity is selected as the data source for that metric, i.e., the query sub-service with the smallest data volume and the coarsest data granularity is selected as the target query sub-service corresponding to that metric. If the amount of data in the underlying data source of any query sub-service is not statistically determined, the first query sub-service can be selected by default based on the sub-service name sorting as the target query sub-service corresponding to that metric, or a query sub-service can be randomly selected as the target query sub-service corresponding to that metric. This method enables a one-to-one mapping between query metrics and query sub-services. Optionally, if a certain metric hits both the automatically generated query sub-service and the customized development query sub-service of the data source type, the customized development query sub-service is given higher priority by default, i.e., the customized development query sub-service is selected as the target query sub-service corresponding to that metric.

[0122] In one implementation, after establishing the association between any query metric and the selected target query sub-service, each query metric corresponds to a query sub-service. However, there may be multiple query metrics corresponding to the same query sub-service. In this case, the metrics corresponding to the same query sub-service can be merged into a set, ultimately forming a one-to-one correspondence between the metric set and the query sub-service. For example, if show_cnt and click_cnt both ultimately map to the query sub-service ads_doris_ads_advertiser_mix_metrics_day_service, then the two can be merged to obtain ['show_cnt', 'click_cnt']->ads_doris_ads_advertiser_mix_metrics_day_service, ['cost']->rtb_realtime_calc_service. This allows the current query process to be split into parallel queries on the two query sub-services.

[0123] In one implementation, the query metrics that can be queried by the query sub-services associated with each query metric can be obtained; if there is a first query sub-service and a second query sub-service among the query sub-services associated with at least one query metric, the association between the target query metric and the second query sub-service associated with the second query sub-service is deleted, and the association between the target query metric and the first query sub-service is established; wherein, the query metrics that can be queried by the first query sub-service include the target query metric.

[0124] For example, the underlying data of ads_doris_ads_advertiser_mix_metrics_day_service is relatively small, coarse-grained, and contains only two metrics: ['show_cnt', 'click_cnt']. In contrast, rtb_realtime_calc_service contains fine-grained data, a larger amount of data, and three metrics: ['show_cnt', 'click_cnt', 'cost']. In this case, querying sub-services via ads_advertiser_mix_metrics_day_service to retrieve ['show_cnt', 'click_cnt'] and via rtb_realtime_calc_service to retrieve ['cost'] would be problematic. However, since querying fine-grained detailed data is unavoidable, querying all metrics via rtb_realtime_calc_service would lower the system load without changing the query time. Therefore, this embodiment of the application can optimize the system by reducing the number of sub-services queried.

[0125] In one implementation, if a third query sub-service in the target query sub-service has a load higher than a preset threshold, a fourth query sub-service is recalled; wherein the fourth query sub-service can query at least one target query indicator associated with the third query sub-service, and the load of the fourth query sub-service is lower than the preset threshold; the association between the at least one target query indicator associated with the third query sub-service and the third query sub-service is deleted, and the association between the at least one target query indicator and the fourth query sub-service is established.

[0126] In this embodiment of the application, if the load of the query sub-service is detected to be too high, the next-level query sub-service of the indicator will be recalled from the query sub-service cluster with lower load. If an available query sub-service can be recalled, the target query sub-service corresponding to each indicator will be updated to ensure the stability of the system load.

[0127] S905 calls the target query sub-service to perform data query based on one or more query parameters, obtains the query data, and outputs the query data.

[0128] In one implementation, after determining the target query sub-services, if there are multiple target query sub-services corresponding to each query metric in the query parameters, parallel queries are performed to ensure query efficiency. For example, an asynchronous multi-threaded execution scheme using CompletableFuture + Executor thread pool can be used for parallel queries, effectively guaranteeing query performance. After the query is completed, all returned metrics are concatenated and merged in memory based on dimension values ​​to obtain the query data.

[0129] In this embodiment, after obtaining a query request, keywords are extracted from the query description information included in the query request to obtain one or more query parameters. Multiple query sub-services that match one or more query parameters are searched. A target query sub-service is selected from the multiple query sub-services, wherein the load of the target query sub-service is less than the load of other query sub-services, or the number of query parameters that the target query sub-service can query is greater than the number of query parameters that other query sub-services can query. Therefore, the target query sub-service is the optimal query sub-service. Then, the target query sub-service is called to perform data query based on one or more query parameters, obtain query data, and output query data, which can effectively improve the efficiency of data query.

[0130] Based on the above description, please refer to Figure 10 , Figure 10 This is a flowchart illustrating another data query method provided in an embodiment of this application; as shown below. Figure 10 The data query scheme shown includes, but is not limited to, steps S1001 to S1008, wherein:

[0131] S1001, Obtain query request; wherein, the query request includes query description information.

[0132] S1002, extract keywords from the query description information to obtain one or more query parameters. The one or more query parameters include at least one query dimension and at least one query indicator.

[0133] For details of steps S1001 and S1002 in this embodiment, please refer to the description of steps S901 and S902 in the above embodiment. They will not be repeated in this embodiment.

[0134] S1003, Obtain the query type prediction strategy. The query type prediction strategy includes the query dimension set and the query indicator set.

[0135] The parameter model and routing configuration provide the basic information needed for queries, but the high availability of the system needs to be guaranteed by the large query prediction module. Based on this, it is possible to determine whether the current query request is a large query and to handle it in a timely manner by degrading it. The judgment of whether the current query is a large query is based on a set of verification rules designed on a large amount of query statistics. Furthermore, it involves offline statistics every day on the data volume of various dimensions, the daily incremental average, and the detailed data volume. It is necessary to look at not only the amount of data returned by the current query, but also the amount of data scanned in the storage engine by the current query.

[0136] Based on an offline big data platform, the system compiles daily statistics on various granularities of commercial data, including effective ad units, ad creatives, advertisers, ad groups, professional accounts, agencies, clients, and group data. For example, it might show 10 million ad units, 1 million ad creatives, 100,000 advertisers, and 50,000 ad groups running ads daily, accumulating to 1 million advertisers, 200,000 professional accounts, and 50,000 clients, thus calculating the latest active, incremental, and existing data. HyperLogLog can be used to calculate the data aggregation base, enabling rapid statistical analysis of massive datasets in the tens of billions.

[0137] The data source cluster also requires a large amount of statistical data. It is necessary to obtain benchmark test data of standard aggregation calculation SQL under a single request. The test statistics can be performed according to the data in the following table, but there are differences in different business scenarios.

[0138] Table 2

[0139]

[0140] As shown in Table 2, for 100,000 rows of data, the time required to calculate 5 indicators under 1 dimension is 1 second (s), the time required to calculate 10 indicators under 3 dimensions is 1.5 seconds, the time required to calculate 10 indicators under 5 dimensions is 2 seconds, and the time required to calculate 15 indicators under 10 dimensions is 3 seconds. For 1 million rows of data, the time required to calculate 5 indicators under 1 dimension is 2 seconds, the time required to calculate 10 indicators under 3 dimensions is 2.5 seconds, the time required to calculate 10 indicators under 5 dimensions is 2.5 seconds, and the time required to calculate 15 indicators under 10 dimensions is 4 seconds. For 10 million rows of data, the time required to calculate 5 indicators under 1 dimension is 3 seconds, the time required to calculate 10 indicators under 3 dimensions is 4 seconds, the time required to calculate 10 indicators under 5 dimensions is 4 seconds, and the time required to calculate 15 indicators under 10 dimensions is 6 seconds. For 100 million rows of data, it takes 5 seconds to statistically analyze 5 indicators under 1 dimension, 7 seconds to statistically analyze 10 indicators under 3 dimensions, 8 seconds to statistically analyze 10 indicators under 5 dimensions, and 10 seconds to statistically analyze 15 indicators under 10 dimensions. Therefore, the embodiments of this application can perform rapid statistical analysis on extremely large-scale data.

[0141] S1004, if at least one query dimension includes at least one query dimension in the query dimension set, and at least one query metric includes at least one query metric in the query metric set, then the estimated query type of the query request is the target query type.

[0142] S1005, Output a prompt message. The prompt message indicates that the query type of the query request is the target query type.

[0143] S1006 If any query dimension in the query dimension set is different from at least one query dimension, or any query metric in the query metric set is different from at least one query metric, then find multiple query sub-services that match one or more query parameters.

[0144] In one implementation, one or more query parameters may further include at least one filter condition, and the query type prediction strategy may further include a set of filter conditions. If at least one filter condition includes at least the filter conditions in the filter condition set, the number of at least one filter condition is greater than the number of filter conditions contained in the filter condition set, at least one query dimension includes at least the query dimensions in the query dimension set, and at least one query metric includes at least the query metrics in the query metric set, then the predicted query type of the query request is the target query type. If any filter condition in the filter condition set is different from at least one filter condition, the number of at least one filter condition is less than or equal to the number of filter conditions contained in the filter condition set, any query dimension in the query dimension set is different from at least one query dimension, or any query metric in the query metric set is different from at least one query metric, then multiple query sub-services matching one or more query parameters are searched.

[0145] In this embodiment, the query elements estimated by the query type estimation strategy may include one or more of the following: data source, dimension, metric, and filtering conditions. If the query parameters of the query request are larger than the range of query data indicated by the hit rule, the query request is considered to have hit the large query rule, meaning that the query type of the query request is the target query type, and that is, the load required to respond to the query request is high. For query requests where the query parameters and the range of query data indicated by the hit rule cannot be compared, it is considered that the large query rule has not been hit.

[0146] Table 3

[0147]

[0148] As shown in Table 3, the set of query dimensions, query metrics, duration threshold, and filter conditions indicated by the rules are determined together based on the cardinality statistics and the size of the cluster. Since the computing power of clusters of different sizes is different, the corresponding values ​​of clusters of different sizes are different. It is necessary to set an initial value based on the statistical indicators and continuously optimize it according to the specific production environment.

[0149] S1007, Select the target query sub-service from multiple query sub-services.

[0150] S1008 calls the target query sub-service to perform data query based on one or more query parameters, obtains the query data, and outputs the query data.

[0151] For details of steps S1007 and S1008 in this embodiment, please refer to the description of steps S903 to S905 in the above embodiment. They will not be repeated in this embodiment.

[0152] In this embodiment, a general and easy-to-use parameter model is provided. Based on the routing configuration rules, the current query is split into multiple subqueries with optimal decisions through a self-designed intelligent query optimizer. At the same time, a large query prediction module is provided, which can automatically degrade some abnormal queries. Since each subquery is independent of each other, the results of the subqueries are finally merged. Therefore, the current query request can achieve cross-database and cross-engine data query association.

[0153] This application also provides a computer storage medium storing program instructions, which, when executed, are used to implement the corresponding methods described in the above embodiments.

[0154] Please see again Figure 11 , Figure 11 This is a schematic diagram of the structure of a data query device provided in an embodiment of this application.

[0155] In one implementation of the data query device according to the embodiments of this application, the data query device includes the following structure.

[0156] Input unit 1101 is used to obtain a query request; wherein, the query request includes query description information;

[0157] Processing unit 1102 is used to extract keywords from the query description information to obtain one or more query parameters;

[0158] The processing unit 1102 is further configured to find multiple query sub-services that match the one or more query parameters; wherein each of the multiple query sub-services has the function of querying query data indicated by at least one of the one or more query parameters;

[0159] The processing unit 1102 is further configured to select a target query sub-service from the plurality of query sub-services; wherein the load of the target query sub-service is less than the load of other query sub-services, or, among the one or more query parameters, the number of query parameters that the target query sub-service can query is greater than the number of query parameters that other query sub-services can query.

[0160] The processing unit 1102 is also used to call the target query sub-service to perform data query based on one or more query parameters to obtain query data;

[0161] Output unit 1103 is used to output the query data.

[0162] In one embodiment, the one or more query parameters include at least one query dimension and at least one query metric; when searching for multiple query sub-services that match the one or more query parameters, the processing unit 1102 is configured to:

[0163] Traverse the at least one query metric to determine the query sub-service that matches the at least one query dimension and the currently traversed query metric; wherein each determined query sub-service has the function of querying the corresponding query metric under the at least one query dimension.

[0164] After the traversal is complete, each determined query sub-service will be treated as a set of query sub-services that match one or more query parameters.

[0165] In one embodiment, when the processing unit 1102 selects a target query sub-service from the plurality of query sub-services, it is configured to:

[0166] For any query metric, a target query sub-service is selected from the query sub-service cluster corresponding to the query metric, and an association is established between the query metric and the selected target query sub-service; wherein, the query sub-service cluster includes at least one query sub-service that can query the query metric.

[0167] When the processing unit 1102 calls the target query sub-service to perform a data query based on one or more query parameters and obtain the query data, it is used to:

[0168] The target query sub-service is invoked, and data is queried based on the query metrics associated with the target query sub-service and the at least one query dimension to obtain the query data.

[0169] In one embodiment, when the processing unit 1102 selects a target query sub-service from the query sub-service cluster corresponding to any query metric, it is configured to:

[0170] Get the amount of query data for each query subservice in the query subservice cluster corresponding to any one of the query metrics;

[0171] The query subservice with the smallest amount of query data is selected as the target query subservice.

[0172] In one embodiment, the processing unit 1102 is further configured to, if the amount of query data for data querying based on the query indicator is not obtained from any query sub-service in the query sub-service cluster corresponding to the query indicator, use the query sub-service arranged at a preset position in the query sub-service cluster corresponding to the query indicator as the target query sub-service.

[0173] In one embodiment, the processing unit 1102 is further configured to:

[0174] Get the query metrics that can be queried by the query sub-services associated with each query metric;

[0175] If a first query sub-service and a second query sub-service exist among the query sub-services associated with the at least one query indicator, then the association between the target query indicator and the second query sub-service associated with the second query sub-service is deleted, and the association between the target query indicator and the first query sub-service is established; wherein, the query indicators that the first query sub-service can query include the target query indicator.

[0176] In one embodiment, the processing unit 1102 is further configured to:

[0177] If a third query subservice in the target query subservice has a load higher than a preset threshold, then a fourth query subservice is recalled; wherein, the fourth query subservice can query at least one target query indicator associated with the third query subservice, and the load of the fourth query subservice is lower than the preset threshold.

[0178] Delete the association between the third query sub-service and at least one target query indicator, and establish an association between the third query sub-service and the at least one target query indicator.

[0179] In one embodiment, the one or more query parameters include at least one query dimension and at least one query metric; the processing unit 1102 is further configured to:

[0180] Obtain a query type prediction strategy, which includes a set of query dimensions and a set of query metrics;

[0181] If the at least one query dimension includes at least the query dimensions in the query dimension set, and the at least one query indicator includes at least the query indicators in the query indicator set, then the estimated query type of the query request is the target query type.

[0182] Output a prompt message, which indicates that the query type of the query request is the target query type.

[0183] In one embodiment, the processing unit 1102 is further configured to:

[0184] If any query dimension in the query dimension set is different from the at least one query dimension, or if any query metric in the query metric set is different from the at least one query metric, then the process of finding multiple query sub-services that match the one or more query parameters is triggered. A target query sub-service is selected from the multiple query sub-services, the target query sub-service is called, and data is queried based on the one or more query parameters to obtain the query data and output the query data.

[0185] In one embodiment, the one or more query parameters further include at least one filtering condition, and the query type estimation strategy further includes a set of filtering conditions; when the processing unit 1102 estimates that the query type of the query request is the target query type if the at least one query dimension includes at least the query dimensions in the query dimension set, and the at least one query indicator includes at least the query indicators in the query indicator set, the processing unit 1102 is used to:

[0186] If the at least one filtering condition includes at least the filtering conditions in the set of filtering conditions, and the number of the at least one filtering condition is greater than the number of filtering conditions included in the set of filtering conditions, and if the at least one query dimension includes at least the query dimension in the set of query dimensions, and the at least one query indicator includes at least the query indicator in the set of query indicators, then the estimated query type of the query request is the target query type.

[0187] In this embodiment, after the input unit 1101 obtains the query request, the processing unit 1102 extracts keywords from the query description information included in the query request to obtain one or more query parameters. It then searches for multiple query sub-services that match the one or more query parameters, selects a target query sub-service from among these, where the load of the target query sub-service is less than the load of other query sub-services, or the number of query parameters that the target query sub-service can query is greater than the number of query parameters that other query sub-services can query. Therefore, the target query sub-service is the optimal query sub-service. The processing unit 1102 then calls the target query sub-service to perform a data query based on one or more query parameters to obtain the query data. The output unit 1103 outputs the query data, which effectively improves the efficiency of data querying.

[0188] Please see again Figure 12 , Figure 12This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. The computer device in this embodiment includes a power supply module and other structures, and includes a processor 1201, a storage device 1202, and a communication interface 1203. The processor 1201, the storage device 1202, and the communication interface 1203 can exchange data, and the processor 1201 implements the corresponding data query method.

[0189] Storage device 1202 may include volatile memory, such as random-access memory (RAM); storage device 1202 may also include non-volatile memory, such as flash memory, solid-state drive (SSD), etc.; storage device 1202 may also include a combination of the above types of memory.

[0190] Processor 1201 may be a central processing unit (CPU). Processor 1201 may also be a combination of CPU and GPU. In the client, multiple CPUs and GPUs may be included as needed for corresponding data processing. In one embodiment, storage device 1202 is used to store program instructions. Processor 1201 can invoke program instructions to implement the various methods described above in the embodiments of this application.

[0191] In a first possible implementation, the processor 1201 of the computer device invokes program instructions stored in the storage device 1202 to obtain a query request; wherein the query request includes query description information; keywords are extracted from the query description information to obtain one or more query parameters; multiple query sub-services that match the one or more query parameters are searched; wherein each of the multiple query sub-services has the function of querying query data indicated by at least one of the one or more query parameters; a target query sub-service is selected from the multiple query sub-services; wherein the load of the target query sub-service is less than the load of other query sub-services, or, among the one or more query parameters, the number of query parameters that the target query sub-service can query is greater than the number of query parameters that other query sub-services can query; the target query sub-service is invoked to perform data query based on the one or more query parameters to obtain query data; and the query data is output.

[0192] In one embodiment, the one or more query parameters include at least one query dimension and at least one query metric; when searching for multiple query sub-services that match the one or more query parameters, the processor 1201 is configured to:

[0193] Traverse the at least one query metric to determine the query sub-service that matches the at least one query dimension and the currently traversed query metric; wherein each determined query sub-service has the function of querying the corresponding query metric under the at least one query dimension.

[0194] After the traversal is complete, each determined query sub-service will be treated as a set of query sub-services that match one or more query parameters.

[0195] In one embodiment, when the processor 1201 selects a target query subservice from the plurality of query subservices, it is configured to:

[0196] For any query metric, a target query sub-service is selected from the query sub-service cluster corresponding to the query metric, and an association is established between the query metric and the selected target query sub-service; wherein, the query sub-service cluster includes at least one query sub-service that can query the query metric.

[0197] When the processor 1201 invokes the target query sub-service to perform a data query based on one or more query parameters and obtain query data, it is used to:

[0198] The target query sub-service is invoked, and data is queried based on the query metrics associated with the target query sub-service and the at least one query dimension to obtain the query data.

[0199] In one embodiment, when the processor 1201 selects a target query sub-service from the query sub-service cluster corresponding to any of the query metrics, it is configured to:

[0200] Get the amount of query data for each query subservice in the query subservice cluster corresponding to any one of the query metrics;

[0201] The query subservice with the smallest amount of query data is selected as the target query subservice.

[0202] In one embodiment, the processor 1201 is further configured to, if the amount of query data for data querying based on the query indicator is not obtained from any query sub-service in the query sub-service cluster corresponding to the query indicator, use the query sub-service arranged at a preset position in the query sub-service cluster corresponding to the query indicator as the target query sub-service.

[0203] In one embodiment, the processor 1201 is further configured to:

[0204] Get the query metrics that can be queried by the query sub-services associated with each query metric;

[0205] If a first query sub-service and a second query sub-service exist among the query sub-services associated with the at least one query indicator, then the association between the target query indicator and the second query sub-service associated with the second query sub-service is deleted, and the association between the target query indicator and the first query sub-service is established; wherein, the query indicators that the first query sub-service can query include the target query indicator.

[0206] In one embodiment, the processor 1201 is further configured to:

[0207] If a third query subservice in the target query subservice has a load higher than a preset threshold, then a fourth query subservice is recalled; wherein, the fourth query subservice can query at least one target query indicator associated with the third query subservice, and the load of the fourth query subservice is lower than the preset threshold.

[0208] Delete the association between the third query sub-service and at least one target query indicator, and establish an association between the third query sub-service and the at least one target query indicator.

[0209] In one embodiment, the one or more query parameters include at least one query dimension and at least one query metric; the processor 1201 is further configured to:

[0210] Obtain a query type prediction strategy, which includes a set of query dimensions and a set of query metrics;

[0211] If the at least one query dimension includes at least the query dimensions in the query dimension set, and the at least one query indicator includes at least the query indicators in the query indicator set, then the estimated query type of the query request is the target query type.

[0212] Output a prompt message, which indicates that the query type of the query request is the target query type.

[0213] In one embodiment, the processor 1201 is further configured to:

[0214] If any query dimension in the query dimension set is different from the at least one query dimension, or if any query metric in the query metric set is different from the at least one query metric, then the process of finding multiple query sub-services that match the one or more query parameters is triggered. A target query sub-service is selected from the multiple query sub-services, the target query sub-service is called, and data is queried based on the one or more query parameters to obtain the query data and output the query data.

[0215] In one embodiment, the one or more query parameters further include at least one filtering condition, and the query type estimation strategy further includes a set of filtering conditions; when the processor 1201 estimates that the query type of the query request is the target query type if the at least one query dimension includes at least the query dimensions in the query dimension set, and the at least one query metric includes at least the query metrics in the query metric set, then the processor 1201 is configured to:

[0216] If the at least one filtering condition includes at least the filtering conditions in the set of filtering conditions, and the number of the at least one filtering condition is greater than the number of filtering conditions included in the set of filtering conditions, and if the at least one query dimension includes at least the query dimension in the set of query dimensions, and the at least one query indicator includes at least the query indicator in the set of query indicators, then the estimated query type of the query request is the target query type.

[0217] In this embodiment, after receiving a query request, the processor 1201 extracts keywords from the query description information included in the query request to obtain one or more query parameters. It then searches for multiple query sub-services that match the one or more query parameters and selects a target query sub-service from among them. The target query sub-service has a lower load than the other query sub-services, or the target query sub-service can query more query parameters than the other query sub-services. Therefore, the target query sub-service is the optimal query sub-service. The processor then calls the target query sub-service to perform data query based on the one or more query parameters, obtains the query data, and outputs the query data, which can effectively improve the efficiency of data query.

[0218] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc. The computer-readable storage medium can mainly include a program storage area and a data storage area. The program storage area can store the operating system, at least one application program required for a function, etc.; the data storage area can store data created based on the use of blockchain nodes, etc.

[0219] The above-disclosed embodiments are merely some of the embodiments of this application, and should not be construed as limiting the scope of this application. Those skilled in the art can understand that all or part of the processes for implementing the above embodiments, and equivalent changes made in accordance with the claims of this application, still fall within the scope of this application.

Claims

1. A data query method, characterized in that, include: Obtain a query request; wherein the query request includes query description information; Keyword extraction is performed on the query description information to obtain one or more query parameters; the one or more query parameters include at least one query indicator; Find multiple query sub-services that match the one or more query parameters; wherein each of the multiple query sub-services has the function of querying query data indicated by at least one of the one or more query parameters; Select a target query subservice from the plurality of query subservices; wherein, among the one or more query parameters, the number of query parameters that the target query subservice can query is greater than the number of query parameters that other query subservices can query. The target query sub-service is invoked to perform a data query based on one or more query parameters, obtain the query data, and output the query data. If a third query subservice in the target query subservice has a load higher than a preset threshold, then a fourth query subservice is recalled; wherein, the fourth query subservice can query at least one target query indicator associated with the third query subservice, and the load of the fourth query subservice is lower than the preset threshold. Delete the association between the third query sub-service and at least one target query indicator, and establish the association between the third query sub-service and the at least one target query indicator. The fourth query sub-service is invoked to perform a data query based on the at least one target query indicator.

2. The method according to claim 1, characterized in that, The one or more query parameters further include at least one query dimension; the search for multiple query sub-services that match the one or more query parameters includes: Traverse the at least one query metric to determine the query sub-service that matches the at least one query dimension and the currently traversed query metric; wherein each determined query sub-service has the function of querying the corresponding query metric under the at least one query dimension. After the traversal is complete, each identified query sub-service will be treated as a set of query sub-services that match one or more query parameters.

3. The method according to claim 2, characterized in that, The step of selecting the target query sub-service from the plurality of query sub-services includes: For any query metric, a target query sub-service is selected from the query sub-service cluster corresponding to the query metric, and an association is established between the query metric and the selected target query sub-service; wherein, the query sub-service cluster includes at least one query sub-service that can query the query metric. The invocation of the target query sub-service, based on one or more query parameters, to perform data query and obtain query data includes: The target query sub-service is invoked, and data is queried based on the query metrics associated with the target query sub-service and the at least one query dimension to obtain the query data.

4. The method according to claim 3, characterized in that, The step of selecting a target query sub-service from the query sub-service cluster corresponding to any of the query metrics includes: Get the amount of query data for each query subservice in the query subservice cluster corresponding to any query indicator, and perform data query based on any query indicator. The query subservice with the smallest amount of query data is selected as the target query subservice.

5. The method according to claim 4, characterized in that, The method further includes: If the amount of query data based on the query indicator is not obtained from any query sub-service in the query sub-service cluster corresponding to any query indicator, then the query sub-service in the query sub-service cluster corresponding to the query indicator and arranged in a preset position is taken as the target query sub-service.

6. The method according to claim 3, characterized in that, The method further includes: Get the query metrics that can be queried by the query sub-services associated with each query metric; If a first query sub-service and a second query sub-service exist among the query sub-services associated with the at least one query indicator, then the association between the target query indicator and the second query sub-service associated with the second query sub-service is deleted, and the association between the target query indicator and the first query sub-service is established; wherein, the query indicators that the first query sub-service can query include the target query indicator.

7. The method according to claim 1, characterized in that, The one or more query parameters include at least one query dimension and at least one query metric; the method further includes: Obtain a query type prediction strategy, which includes a set of query dimensions and a set of query metrics; If the at least one query dimension includes at least the query dimensions in the query dimension set, and the at least one query indicator includes at least the query indicators in the query indicator set, then the estimated query type of the query request is the target query type. Output a prompt message, which indicates that the query type of the query request is the target query type.

8. The method according to claim 7, characterized in that, The method further includes: If any query dimension in the query dimension set is different from the at least one query dimension, or if any query metric in the query metric set is different from the at least one query metric, then the process of finding multiple query sub-services that match the one or more query parameters is triggered. A target query sub-service is selected from the multiple query sub-services, the target query sub-service is called, and data is queried based on the one or more query parameters to obtain the query data and output the query data.

9. The method according to claim 7, characterized in that, The one or more query parameters further include at least one filtering condition, and the query type prediction strategy further includes a set of filtering conditions; if the at least one query dimension includes at least the query dimensions in the query dimension set, and the at least one query metric includes at least the query metrics in the query metric set, then the predicted query type of the query request is the target query type, including: If the at least one filtering condition includes at least the filtering conditions in the set of filtering conditions, and the number of the at least one filtering condition is greater than the number of filtering conditions included in the set of filtering conditions, and if the at least one query dimension includes at least the query dimension in the set of query dimensions, and the at least one query indicator includes at least the query indicator in the set of query indicators, then the estimated query type of the query request is the target query type.

10. A data query device, characterized in that, The data query device includes: An input unit is used to obtain a query request; wherein the query request includes query description information; The processing unit is configured to extract keywords from the query description information to obtain one or more query parameters; the one or more query parameters include at least one query indicator; The processing unit is further configured to find multiple query sub-services that match the one or more query parameters; wherein each of the multiple query sub-services has the function of querying query data indicated by at least one of the one or more query parameters; The processing unit is further configured to select a target query sub-service from the plurality of query sub-services; wherein, among the one or more query parameters, the number of query parameters that the target query sub-service can query is greater than the number of query parameters that other query sub-services can query. The processing unit is also used to call the target query sub-service to perform data query based on one or more query parameters to obtain query data; Output unit, used to output the query data; The processing unit is further configured to: recall a fourth query sub-service if a third query sub-service in the target query sub-service has a load higher than a preset threshold; wherein the fourth query sub-service can query at least one target query indicator associated with the third query sub-service, and the load of the fourth query sub-service is lower than the preset threshold; delete the association between the at least one target query indicator associated with the third query sub-service and the third query sub-service, and establish an association between the at least one target query indicator and the fourth query sub-service; and invoke the fourth query sub-service to perform data query based on the at least one target query indicator.

11. A computer device, characterized in that, The computer device includes a processor, a storage device, and a communication interface, which are interconnected. The storage device stores a computer program that supports the terminal in executing the above-described method. The computer program includes program instructions, and the processor is configured to invoke the program instructions to execute the data query method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which includes program instructions that, when executed by a processor, cause the processor to perform the data query method as described in any one of claims 1 to 9.

13. A computer product, characterized in that, The computer product includes a computer program adapted to be loaded by a processor and executed as described in any one of claims 1 to 9.

Images