Automatic driving data processing method and device, computer equipment and storage medium
By generating structured query statements in the autonomous driving data management system and converting them into abstract syntax trees, the problem that the existing tag system cannot carry rich information and support complex queries is solved, and the flexibility and accuracy of multidimensional composite queries and data retrieval are improved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-15
- Publication Date
- 2026-04-14
AI Technical Summary
In existing autonomous driving data management systems, the tagging system only supports Boolean type tags, which cannot carry rich information or support complex query conditions. Furthermore, manual tagging lacks standardized verification, resulting in poor data retrieval accuracy.
By generating structured query statements and converting them into abstract syntax trees, traversing tag names to obtain data types, constructing unstructured query statements, retrieving results from the target data query engine, and combining structured and unstructured queries to optimize data retrieval.
It supports diverse tag types and multi-dimensional composite queries, improving the flexibility and accuracy of data retrieval and optimizing the user experience.
Smart Images

Figure CN121858596A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data retrieval technology, and more specifically, to an autonomous driving data processing method, apparatus, computer device, and storage medium. Background Technology
[0002] With the rapid development of autonomous driving technology, vehicle perception, decision-making, and control algorithms are becoming increasingly complex. Data closed-loop has become a core support system for autonomous driving companies to achieve continuous algorithm iteration and optimization. Data closed-loop, through systematic processes such as data collection, scenario mining, and data feedback, continuously accumulates edge cases and typical operating condition data from real-world driving scenarios, feeding back into algorithm optimization and thus improving the system's robustness and generalization ability. However, without proper management, massive amounts of autonomous driving data often lead to difficulties in retrieving important data and waste of system resources due to full-scale data processing.
[0003] In related technologies, in order to respond to the management needs of massive amounts of autonomous driving data, a tagging strategy is often used to label each piece of autonomous driving data to record multi-dimensional attribute information such as data collection attributes, scene mining attributes, and data feedback attributes. Text tags are also assigned to each piece of autonomous driving data so that users can quickly locate target data from massive amounts of autonomous driving data through text tags.
[0004] However, when managing autonomous driving data based on related technologies, single text-based tags can only identify a binary state of "existence / non-existence," failing to accommodate continuous or structured information that is not enumerable, resulting in insufficient data description dimensions. Furthermore, existing tagging systems only support simple existence searches, unable to support range queries based on conditions such as "greater than," "less than," or "inclusive," nor can they support complex queries combining multiple conditions like temperature ranges or time intervals, making them ill-suited for the diverse data analysis scenarios in autonomous driving. Moreover, the manual tagging process lacks standardized verification mechanisms, making it prone to tag format errors. The lack of log recording for tagging operations makes it impossible to trace the source of errors, leading to poor tag data reliability and impacting the accuracy of subsequent data retrieval and analysis. Summary of the Invention
[0005] The purpose of this application is to provide an autonomous driving data processing method, device, computer equipment, and storage medium that can support diverse tag types, realize multi-dimensional composite queries, improve the automation level of data queries, and optimize user experience.
[0006] The embodiments of this application are implemented as follows: A first aspect of this application provides an autonomous driving data processing method, the method comprising: A structured query statement is generated based on the user's input information, and the structured query statement is converted into an abstract syntax tree. The abstract syntax tree includes multiple nodes and at least one label name, and each node corresponds to a query condition in the structured query statement. Based on the tag names in the abstract syntax tree, the data type corresponding to each tag name is queried from the structured database. The structured database stores multiple data tables corresponding to tags. Each data table corresponding to a tag stores the tag name, the data type corresponding to each tag name, and at least one level of child tags of the tag. Construct an unstructured query statement based on the abstract syntax tree and the data types corresponding to the tag names in the abstract syntax tree; Based on the unstructured query statement, the query results corresponding to the structured query statement are obtained from the target data query engine. The target data query engine stores at least one set of tag values corresponding to each tag.
[0007] As one possible implementation, based on the tag names in the abstract syntax tree, the data type corresponding to each tag name is queried from a structured database, including: Traverse each tag name in the abstract syntax tree, and for the current tag name encountered, determine the target data table corresponding to the current tag name; Read the data type of the current tag name from the target data table to obtain the data type corresponding to the current tag name.
[0008] As one possible implementation, an unstructured query statement is constructed based on the abstract syntax tree and the data types corresponding to the tag names in the abstract syntax tree, including: Recursively traverse each node in the abstract syntax tree. For the current node, obtain the label name corresponding to the current node to determine the data type of the current node. Based on the data type of the current node and the operators of the query conditions corresponding to the current node, determine the unstructured query object corresponding to the current node; The unstructured query objects corresponding to each node are nested and combined to construct an unstructured query statement.
[0009] As one possible implementation, the unstructured query object corresponding to the current node is determined based on the data type of the current node and the operators of the query conditions corresponding to the current node, including: Determine whether the current node is a relational operation node based on the operator of the query condition corresponding to the current node; If so, then based on the data type of the current node and the left or right operand of the operator of the query condition corresponding to the current node, generate the unstructured query object corresponding to the current node. If not, then based on the data type of the current node and the right operand of the operator of the query condition corresponding to the current node, generate the unstructured query object corresponding to the current node.
[0010] As one possible implementation, based on the data type of the current node and the left or right operand of the operator of the query condition corresponding to the current node, an unstructured query object corresponding to the current node is generated, including: If the operator of the query condition corresponding to the current node is the equals sign, then it is further determined whether the right operand of the current node is null. If it is, then a non-existent query object of the current node is generated based on the left operand of the current node and the data type of the left operand. If not, then an exact match query object of the current node is generated based on the right operand of the current node and the data type of the right operand. If the operator of the query condition corresponding to the current node is greater than, less than, greater than or equal to, or less than or equal to, then a range query object for the current node is generated based on the left operand of the current node and the data type of the left operand.
[0011] As one possible implementation, based on the data type of the current node and the right operand of the operator of the query condition corresponding to the current node, an unstructured query object corresponding to the current node is generated, including: If the operator of the query condition corresponding to the current node is a pattern matching operator, then the fuzzy query object of the current node is generated based on the right operand of the current node and the data type of the right operand. If the operator of the query condition corresponding to the current node is a multi-value matching operator, then the multi-value matching query object of the current node is generated based on the right operand of the current node and the data type of the right operand.
[0012] As one possible implementation, based on unstructured query statements, the query results corresponding to structured query statements are obtained from the target data query engine, including: Based on the unstructured query statement, send the corresponding query request to the target data query engine; The target data query engine performs a distributed search based on the query request to obtain at least one set of tag values that match the query request; Based on at least one set of tag values that match the query request, determine the tags corresponding to each set of tag values and the autonomous driving data packets corresponding to each tag, and use the autonomous driving data packets corresponding to each tag as the query results corresponding to the structured query statement.
[0013] As one possible implementation, the above-mentioned autonomous driving data processing method also includes: Obtain the original tag information input by the user, which includes the information of the tags arranged in hierarchical order; The original label information is structurally verified based on the preset structured data storage template. If the verification passes, the information of each tag in the original tag information will be stored in the structured database according to the hierarchy.
[0014] As one possible implementation, the original tag information is structurally validated based on a pre-defined structured data storage template, including: The original label information is recursively expanded to obtain the hierarchical path matrix corresponding to the original label information. The hierarchical path matrix includes the mapping relationship between key paths and label values. The key paths are used to indicate the path between the root node and the leaf node. Based on the preset structured data storage template, the structure of each label value in the hierarchical path matrix is verified to determine whether the original label information is valid. If so, the original label information will be stored in the structured database according to the preset structured data storage template; If not, an error message will be generated and sent to the user.
[0015] As one possible implementation, a structured query statement is generated based on user input, including: Obtain user input information on the graphical panel, including: the target label selected by the user and the query operator set by the user for the target label; Based on the data type of the target tag, dynamically render the corresponding input component, and obtain the query condition value entered or selected by the user through the input component; The system automatically generates structured query statements based on the target label, query operator, and query condition values.
[0016] A second aspect of this application provides an autonomous driving data processing apparatus, the apparatus comprising: The conversion module is used to generate a structured query statement based on the user's input information and convert the structured query statement into an abstract syntax tree. The abstract syntax tree includes multiple nodes and at least one label name, and each node corresponds to a query condition in the structured query statement. The query module is used to query the data type corresponding to each tag name from the structured database based on each tag name in the abstract syntax tree. The structured database stores multiple data tables corresponding to tags. Each data table corresponding to a tag stores the tag name, the data type corresponding to each tag name, and at least one level of sub-tags of the tag. The building module is used to construct unstructured query statements based on the abstract syntax tree and the data types corresponding to the tag names in the abstract syntax tree; The indexing module retrieves the query results corresponding to the structured query statement from the target data query engine based on the unstructured query statement. The target data query engine stores at least one set of tag values corresponding to each tag.
[0017] A third aspect of this application provides a computer device, which includes a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the computer program, it implements the steps of the autonomous driving data processing method described in the first aspect.
[0018] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the autonomous driving data processing method described in the first aspect.
[0019] The beneficial effects of the embodiments of this application include: This application provides an autonomous driving data processing method. It acquires user input information and dynamically generates a structured query statement based on this information. A conversion tool is then used to convert the structured query statement into an abstract syntax tree (API). The API includes multiple nodes and at least one tag name, with each node corresponding to a query condition in the structured query statement. The API traverses each node in the API to identify those with tag names, and retrieves the corresponding data type from a structured database based on the tag name. An unstructured query statement is constructed based on the API and the corresponding data types of the tag names. Based on the unstructured query statement, a query engine retrieves matching results from the target data query engine and displays them to the user. The metadata table for each tag in the structured database stores multiple tag names, the data types of each tag name, and the parent-child hierarchical structure between tag names. This allows each tag to carry and manage rich information, greatly expanding the descriptive dimensions of the tag system. Furthermore, the structured query statement nests multiple query conditions, supporting multi-condition data queries and significantly improving the flexibility and expressiveness of data retrieval. Furthermore, the efficient conversion between structured and unstructured query statements ensures both the accuracy of data queries and the performance of data queries on massive amounts of autonomous driving data. This allows for support for diverse tag types, enables multi-dimensional composite queries, improves the automation level of data queries, and optimizes the user experience. Attached Figure Description
[0020] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0021] Figure 1 This is a schematic diagram of the structure of a tag management system for autonomous driving data provided in an embodiment of this application; Figure 2 A flowchart illustrating the first autonomous driving data processing method provided in this application embodiment; Figure 3 This application provides an example of a data representation intent corresponding to a tag. Figure 4 A schematic diagram of a set of tag values provided in an embodiment of this application; Figure 5 A flowchart illustrating the second autonomous driving data processing method provided in this application embodiment; Figure 6 A flowchart illustrating the third autonomous driving data processing method provided in this application embodiment; Figure 7 A flowchart illustrating the fourth autonomous driving data processing method provided in this application embodiment; Figure 8 A flowchart illustrating the fifth autonomous driving data processing method provided in this application embodiment; Figure 9 A flowchart of the sixth autonomous driving data processing method provided in the embodiments of this application; Figure 10 A flowchart of the seventh autonomous driving data processing method provided in the embodiments of this application; Figure 11 A flowchart illustrating the eighth autonomous driving data processing method provided in this application embodiment; Figure 12 A flowchart of the ninth autonomous driving data processing method provided in the embodiments of this application; Figure 13 A flowchart of the tenth autonomous driving data processing method provided in the embodiments of this application; Figure 14 This application provides an example diagram of a data retrieval interaction. Figure 15 This is a schematic diagram of the structure of an autonomous driving data processing device provided in an embodiment of this application; Figure 16This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation
[0022] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.
[0023] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.
[0024] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.
[0025] Currently, the management technology for massive amounts of autonomous driving data mainly involves assigning one or more tags to each piece of autonomous driving data based on its specific attributes or scenarios. For example, in terms of weather conditions, autonomous driving data can be tagged with "sunny," "rainy," or "foggy"; in terms of traffic conditions, it can be tagged with "smooth," "congested," or "construction." This tagging-based approach to autonomous driving data processing allows users to locate the desired autonomous driving data through tags during subsequent data retrieval and analysis. However, the tags in the existing tagging system are all Boolean type tags, which can only represent binary states of "yes" or "no," and cannot carry richer information. This makes it impossible to use the non-enumerable key fields required for autonomous driving scenarios as retrieval tags for autonomous driving data. In addition, since the existing tagging system only supports Boolean type tags, tag retrieval can only support two filtering conditions: existence and non-existence. It cannot support query conditions such as greater than, less than, or contain one class, nor can it support complex search conditions such as temperature ranges or time intervals. Furthermore, the existing tagging system does not support multi-condition combination queries frequently required in autonomous driving scenarios, making it difficult to adapt to the diverse data analysis in autonomous driving scenarios.
[0026] In addition, the existing labeling system mainly relies on manual labeling, which lacks a standardized verification mechanism, making it prone to label format errors. Furthermore, the labeling operation is not logged, making it impossible to trace the source of errors, resulting in poor reliability of label data and affecting the accuracy of subsequent data retrieval and analysis.
[0027] To address this, this application provides an autonomous driving data processing method. The method dynamically generates a structured query statement based on user input and converts the structured query statement into a corresponding abstract syntax tree (API). It then traverses each tag name in the API and retrieves the data type corresponding to each tag name from a structured database. Based on the API and the data types corresponding to each tag name, it constructs an unstructured query statement. Finally, it retrieves at least one query result from a target data query engine that satisfies the query conditions of the structured query statement. This approach supports diverse tag types, enables multi-dimensional composite queries, improves the automation level of data queries, and optimizes the user experience.
[0028] The autonomous driving data processing method provided in the embodiments of this application will be explained in detail below with reference to the accompanying drawings.
[0029] Figure 1 A schematic diagram of the structure of a tag management system for autonomous driving data provided in this application is shown below. Figure 1 The label management system 10 for autonomous driving data provided in this application includes: a label management module 101, a label retrieval module 102, and a label verification module 103. The label retrieval module 102 and the label verification module 103 are both involved in the entire data closed-loop process.
[0030] Specifically, the fundamental purpose of the data closed-loop process is to transform real-world driving experience into fuel for continuous optimization of algorithm models, enabling autonomous driving systems to learn from every drive (even failed or marginal driving cases) just like human drivers, thereby becoming more comprehensive, reliable, and intelligent.
[0031] Furthermore, the data closed-loop process includes multiple stages such as data collection, quality inspection, scene mining, refeeding, and evaluation. Data collection involves continuously collecting massive amounts of real-world driving data from onboard sensors deployed in multiple autonomous vehicles. Quality inspection cleans and filters this massive amount of real-world driving data to remove low-quality autonomous driving data, preparing for subsequent labeling and mining. Scene mining accurately extracts valuable scene data for algorithm iteration from the massive amount of autonomous driving data after quality inspection and assigns machine-readable semantic information to this scene data. Refeeding involves reproducing and testing the mined key scene data in a high-fidelity, controllable virtual simulation environment to verify the effectiveness of algorithm repair schemes or new algorithms. This involves using the mined key scene data to reconstruct scenes on a simulation platform, connecting the new version of the perception, prediction, and planning control algorithms to be tested to the simulation platform, and running the new algorithms in the reproduced scenes to observe their performance and determine their robustness. Evaluation is used to conduct systematic and standardized quantitative assessment and qualitative analysis of the performance of the refeeding test results.
[0032] In addition, the tag management module 101 is used to establish a unified and scalable tag specification system to ensure the consistency and standardization of the entire tag management system 10. Specifically, the tag management module 101 defines the key and metadata of each tag, and calls a relational database (such as a MySQL database) to store these tag definitions, forming a unique tag dictionary or metadata table. For example, it defines data types as strings, integers, floating-point numbers, timestamps, enumerations, objects, lists, etc., defines hierarchical structures as parent-child relationships, and defines constraint rules as required, default values, value ranges, etc. The tag management module 101 can also provide a management interface or application programming interface (API) to allow users to dynamically create, modify, or deactivate certain tags according to business evolution. The tag management module 101 can ensure that the tags used by different users at different times for the same autonomous driving data are unified, thereby achieving unified tag management.
[0033] Furthermore, the tag retrieval module 102 can provide the tag management system 10 with powerful, flexible, and easy-to-use data query capabilities, enabling users to quickly and accurately locate the desired autonomous driving data from massive amounts of autonomous driving data. Specifically, the tag retrieval module 102 can provide multimodal query interfaces, such as graphical panels or structured query interfaces. The graphical panel provides users with an intuitive "selection + value filling" query method, dynamically rendering appropriate input components based on the data type corresponding to the user-selected tag. The structured query interface provides professional technicians with the ability to directly write structured query language (SQL) statements. The tag retrieval module 102 can also provide query transformation and execution functions, such as converting user query requests into query statements that the underlying storage engine can execute efficiently, or parsing structured query statements into abstract syntax trees, and recursively converting the abstract syntax trees into unstructured query statements. The tag retrieval module 102 can also utilize the inverted index, word segmentation, and other technologies of the underlying storage engine to achieve millisecond-level massive data retrieval. The tag retrieval module 102 can also display the query results in a clear list or graph for subsequent data analysis, annotation, and backfeeding.
[0034] It should also be noted that the tag verification module 103 is used to perform real-time or post-process rule checks during the data tagging process to ensure that the tag data entered into the tag management system 10 is accurate, compliant, and consistent. First, the tag verification module 103 verifies the data type of the tags to ensure that the tag data stored in the tag management system 10 conforms to the defined data type. Second, the tag verification module 103 also verifies the value range / enumeration, such as checking whether the input value of an enumeration-type tag is in a predefined valid list, or checking whether the value range of a numeric tag is within a predefined range of maximum and minimum values. Third, the tag verification module 103 also verifies the tag format, checking whether the timestamp format, string regular expression matching format, JSON structure, etc., conform to predefined specifications. Additionally, the tag verification module 103 also performs cross-tag business logic checks. Finally, the tag verification module 103 also recursively expands the user-inputted raw tag data to verify each child node in the user-inputted raw tag.
[0035] Figure 2 A flowchart of an autonomous driving data processing method provided in this application is shown below. Figure 2 This application provides an autonomous driving data processing method, including: S201. Generate a structured query statement based on the user's input information, and convert the structured query statement into an abstract syntax tree. The abstract syntax tree includes multiple nodes and at least one label name, and each node corresponds to a query condition in the structured query statement.
[0036] Optionally, the user's input information refers to the information entered by the user through a graphical panel or a structured query interface. The input information can be a structured query statement that the user customizes and edits in the structured query interface, or it can be a target label selected by the user on the graphical panel, the query operator set for the target label, and the entered query condition values. This application does not impose specific limitations on this.
[0037] Optionally, a corresponding structured query statement (SQL statement) is generated based on the user's input information. The JSqlParser tool is then used to parse the SQL statement to obtain the corresponding abstract syntax tree (AST). Here, the SQL statement is a human-readable text instruction written according to a specific syntax, used to tell the MySQL database user what they want to do; the abstract syntax tree is a tree-like representation of the structured query statement in computer memory, stripped of irrelevant details, and is an intermediate product of the database engine's understanding, analysis, and optimization of the structured query statement.
[0038] It should be noted that SQL statements are standard statements specifically used to manage relational databases; an abstract syntax tree is a data structure composed of multiple nodes, each node representing a syntax structure in a structured query statement, such as an operation, an expression, or an identifier.
[0039] It should also be noted that the root node in the abstract syntax tree represents the entire SQL statement, and each child node in the abstract syntax tree represents the various query conditions of the structured query statement.
[0040] Among them, the syntax writing rules based on SQL statements divide the nodes in the abstract syntax tree into various node types such as logical operation nodes, relational operation nodes, function call nodes, and bracket expression nodes. This application does not make specific limitations on this.
[0041] Specifically, logical operation nodes include: AND logical nodes and OR logical nodes, etc.; relational operation nodes include: equal to operation nodes, greater than operation nodes, less than operation nodes, greater than or equal to operation nodes, less than or equal to operation nodes, etc.; non-relational operation nodes include: pattern matching operation nodes and multi-value matching operation nodes, etc. This application does not make specific limitations on these.
[0042] Optionally, the abstract syntax tree also includes multiple label names, which are determined by the user's input information. The label names can be specific to license plate numbers, temperatures, weather, etc., and this application does not impose any specific limitations on them.
[0043] S202. Based on the tag names in the abstract syntax tree, query the data type corresponding to each tag name from the structured database. The structured database stores multiple data tables corresponding to tags. Each data table corresponding to a tag stores the tag name, the data type corresponding to each tag name, and at least one level of child tags of the tag.
[0044] The structured database is preferably a relational database. The structured database is only used to store metadata tables that define the structure, type and hierarchical relationship of all tags, and does not store the specific tag values of each tag.
[0045] For details, see Figure 3 ,according to Figure 3 The standard structured table shown stores the metadata of each tag in a structured database. For example... Figure 3 In the data table shown, `key_name` represents the tag name, `type` represents the data type, `basic_info` represents the tag name for basic information, and its data type is object (e.g., `object`). It is usually a parent tag used for grouping and managing the core metadata during data collection, such as vehicle model, collection segment, driver ID, etc.; `target_objects` represents the tag name for target objects, and its data type is usually list (e.g., `list`). It records detailed information for all key traffic participants (e.g., vehicles, pedestrians, cyclists, etc.) detected in the scene. Each list item may be an object containing attributes such as ID, type, location, and speed; `plate_no` represents the tag name for license plate numbers, and its data type is string (e.g., `string`). It uniquely identifies the test vehicle for data collection and is specifically used for data traceability; `data_id` is used for table... The data ID is represented by the following tags: `<data>`, `<integer>`, `<int>`, and `<autonomous>`. `<temperature>` represents the ambient temperature during data collection. `<quality>` represents the quality level of the data and is typically used as a label on a standard after data processing. `<item>` represents the list item's data label and is often used as a placeholder or part of a path for list elements. `<collect_time>` represents the collection time and is a timestamp, recording the precise moment of data collection.
[0046] Furthermore, `parent_id` is used to represent the hierarchical relationship, `sort` is used to represent the sorting relationship, and `enum_value` is used to represent the scenario value of the autonomous driving data. Specifically, the "-" under `parent_id` indicates the parent label, 1 indicates a first-level child label under the parent label, 2 indicates a second-level child label under the first-level child label, and 0-5 under `sort` indicates the sorting relationship of child nodes within the same level. This allows for nested label structures of any level.
[0047] Optionally, after the abstract syntax tree is constructed, all nodes involving tag names in the abstract syntax tree are traversed, and each extracted tag name is used as the query key to initiate a query to the structured database to retrieve the data type corresponding to each tag name and its possible hierarchical relationship information.
[0048] Optionally, a data table refers to a predefined metadata table for each tag stored in a structured database. Each tag's corresponding data table stores the tag name across multiple dimensions, the data type corresponding to each tag name, and the parent-child relationship between each tag name.
[0049] In one alternative implementation, the specific process of parsing an SQL statement into an abstract syntax tree is as follows: Statement statement = CCJSqlParserUtil.parse(sqlStr); Select select = (Select) statement; Expression where = plainSelect.getWhere(); The process involves first parsing the SQL statement into nodes of an abstract syntax tree (statament objects), then converting the nodes of the abstract syntax tree into query types (select), and finally obtaining the expression of the WHERE clause in the abstract syntax tree, thus completing the conversion between the SQL statement and the abstract syntax tree.
[0050] S203. Construct an unstructured query statement based on the abstract syntax tree and the data types corresponding to the label names in the abstract syntax tree.
[0051] The unstructured query statement is specifically implemented by the Elasticsearch query statement, and this application does not make specific limitations on it.
[0052] Optionally, traverse each node in the abstract syntax tree and construct the Elasticsearch query statement corresponding to the structured query statement based on the label name corresponding to each node, the data type corresponding to each label name, and the operators in the query conditions corresponding to each node.
[0053] S204. Based on the unstructured query statement, retrieve the query results corresponding to the structured query statement from the target data query engine, wherein the target data query engine stores at least one set of tag values corresponding to each tag.
[0054] The target data query engine can be the Elasticsearch query engine, but this application does not make any specific restrictions on it.
[0055] Optionally, the constructed unstructured query statement can be sent to the target data query engine to execute a distributed query in order to obtain query results that match the structured query statement.
[0056] For example, see Figure 4 The target objects in the label "basic_info" are cars and buses, the license plate number is "shan-xxxx", the identifier of the autonomous driving data is 1000, the ambient temperature when the autonomous driving data was collected is 27.5℃, the data quality of the autonomous driving data is correct, and the timestamp of the autonomous driving data is 1712220755000.0.
[0057] It is worth noting that the target data query engine stores at least one set of tag values corresponding to each tag. Each set of tag values has a certain timeliness. Each set of tag values includes the specific value of at least one tag name in the corresponding tag. This application does not make any specific limitations on this.
[0058] In this embodiment, user input information is obtained, and a structured query statement is dynamically generated based on the user input information. A conversion tool is invoked to convert the structured query statement into an abstract syntax tree (API). The API includes multiple nodes and at least one tag name, with each node corresponding to a query condition in the structured query statement. The nodes in the API are traversed to find those with tag names, and the data type corresponding to each tag name is queried from the structured database based on the tag name of each node. An unstructured query statement is constructed based on the API and the data types corresponding to each tag name in the API. Based on the unstructured query statement, query results matching the structured query statement are retrieved from the target data query engine and displayed to the user. The metadata table corresponding to each tag in the structured database stores multiple tag names, the data types of each tag name, and the parent-child hierarchical structure between tag names. This allows each tag to carry and manage rich information, greatly expanding the descriptive dimensions of the tag system. Furthermore, the structured query statement nests multiple query conditions, supporting data queries with multiple condition combinations, significantly improving the flexibility and expressiveness of data retrieval. Furthermore, the efficient conversion between structured and unstructured query statements ensures both the accuracy of data queries and the performance of data queries on massive amounts of autonomous driving data. This allows for support for diverse tag types, enables multi-dimensional composite queries, improves the automation level of data queries, and optimizes the user experience.
[0059] In one alternative implementation, see [link to implementation details]. Figure 5 The specific operation of step S202 above can be as follows: S501. Traverse each tag name in the abstract syntax tree, and for the current tag name encountered, determine the target data table corresponding to the current tag name.
[0060] Optionally, the current tag name refers to the tag name read when traversing the abstract syntax tree at the current moment. Based on the tag name, the corresponding metadata table is searched from the structured database, and the metadata table is used as the target data table corresponding to the current tag name.
[0061] S502. Read the data type of the current tag name from the target data table to obtain the data type corresponding to the current tag name.
[0062] Optionally, the data type of the current tag name can be read from the target data table to determine the data type corresponding to the current tag name.
[0063] In one alternative implementation, see [link to implementation details]. Figure 6 The specific operation of step S203 above can be as follows: S601. Recursively traverse each node in the abstract syntax tree. For the current node, obtain the label name corresponding to the current node to determine the data type of the current node.
[0064] Optionally, all nodes in the abstract syntax tree are recursively traversed, and the label name of the node carrying the label name field is obtained. Based on the data type corresponding to the label name, the data type of the current node is determined.
[0065] Here, the current node refers to a node in the abstract syntax tree with the label name field that is traversed at the current moment. The current node can be any node in the abstract syntax tree, and this application does not make any specific restrictions on it.
[0066] S602. Determine the unstructured query object corresponding to the current node based on the data type of the current node and the operator of the query condition corresponding to the current node.
[0067] The query conditions can be specific to relational operation query conditions, range query conditions, logical query conditions, etc., and this application does not make specific limitations on them.
[0068] Specifically, the operators included in the query conditions can be greater than, equal to, less than, pattern matching, multi-value matching, etc., and this application does not impose any specific limitations on them.
[0069] Optionally, an unstructured query object is constructed based on the data type of the current node and the operators of the query conditions corresponding to the current node. This unstructured query object carries the query intent parsed from the structured query statement and can be natively understood and efficiently executed by the target data query engine.
[0070] S603. Nest and combine the unstructured query objects corresponding to each node to construct an unstructured query statement.
[0071] Optionally, the unstructured query objects corresponding to each node in the abstract syntax tree can be nested and combined according to a specific syntax to obtain the unstructured query statement corresponding to the structured query statement.
[0072] In one alternative implementation, see [link to implementation details]. Figure 7 The specific operation of step S602 above can be as follows: S701. Determine whether the current node is a relational operation node based on the operator of the query condition corresponding to the current node.
[0073] Optionally, based on the operators in the query conditions indicated by the current node, it can be determined whether the current node is a relational operation node, which is a node in the abstract syntax tree that represents mathematical operation relations.
[0074] S702. If so, then generate the unstructured query object corresponding to the current node based on the data type of the current node and the left or right operand of the operator of the query condition corresponding to the current node.
[0075] Optionally, if the current node is a relational operation node, then an unstructured query object corresponding to the current node needs to be generated based on the data type of the current node and the left or right operand of the operator in the query condition corresponding to the current node. Here, the left operand refers to the value to the left of the operator in the query condition, and the right operand refers to the value to the right of the operator in the query condition.
[0076] S703. If not, then generate the unstructured query object corresponding to the current node based on the data type of the current node and the right operand of the operator of the query condition corresponding to the current node.
[0077] Optionally, if the current node is not a relational operation node, then an unstructured query object corresponding to the current node needs to be generated based on the data type of the current node and the right operand of the operator of the query condition corresponding to the current node.
[0078] In one alternative implementation, see [link to implementation details]. Figure 8 The specific operation of step S702 above can be as follows: S801. If the operator of the query condition corresponding to the current node is the equals sign, then further determine whether the right operand of the current node is null. If yes, then generate a non-existent query object for the current node based on the left operand of the current node and the data type corresponding to the left operand. If no, then generate an exact match query object for the current node based on the right operand of the current node and the data type corresponding to the right operand.
[0079] Optionally, if the operator of the query condition corresponding to the current node is the equals sign, it is necessary to further determine whether the right operand of the current node is null, so as to determine whether the generation method of the unstructured query object of the current node is a non-existence query or an exact match query.
[0080] Optionally, if the right operand of the equality operator for the query condition corresponding to the current node is null, a non-existence query object for the current node is generated based on the left operand and its corresponding data type. The query intent represented by the non-existence query object is to find all documents where a certain field is missing, has a null value, or is missing from the document. This is mainly used to filter data that has not yet been labeled with a problem category, or to filter out data fragments where certain sensor data is missing.
[0081] Optionally, if the right operand of the equals operator in the query condition corresponding to the current node is not null, then an exact match query object for the current node is generated based on the right operand and its corresponding data type. The exact match query object represents the query intent of retrieving all documents where the value of a certain field is exactly equal to a specified value.
[0082] In one optional implementation, when the operator of the query condition corresponding to the current node is the equality operator, the process of generating an unstructured query object is as follows: case EQUALS: if where.right is NullValue: return BoolQuery(must_not = ExistsQuery(where.left)) else: return TermQuery( field = ToKeyword(where.left, valueType), value = FormatValue(where.right) ) S802. If the operator of the query condition corresponding to the current node is the greater than operator, less than operator, greater than or equal to operator, or less than or equal to operator, then generate a range query object for the current node based on the left operand of the current node and the data type corresponding to the left operand.
[0083] Optionally, if the operator for the query condition corresponding to the current node is a greater than, less than, greater than or equal to, or less than or equal to operator, then a range query object for the current node is generated based on the left operand and its corresponding data type. The range query object is primarily used to handle interval filtering conditions based on continuous or ordered values in unstructured query statements. The query intent represented by the range query object is to find all documents whose field values fall within a specified numerical range, time range, or other ordered interval.
[0084] In one alternative implementation, see [link to implementation details]. Figure 9 The specific operation of step S703 above can be as follows: S901. If the operator of the query condition corresponding to the current node is a pattern matching operator, then the fuzzy query object of the current node is generated based on the right operand of the current node and the data type corresponding to the right operand.
[0085] Specifically, the pattern matching operator can be the LIKE operator, and the fuzzy query object is used to implement pattern matching or partial matching queries for text fields. The query intent represented by the fuzzy query object is used to find documents whose values in a certain text field contain a specific pattern or substring, and wildcard matching is supported.
[0086] S902. If the operator of the query condition corresponding to the current node is a multi-value matching operator, then the multi-value matching query object of the current node is generated according to the right operand of the current node and the data type corresponding to the right operand.
[0087] Optionally, the multi-value matching operator can specifically be the IN operator. The multi-value matching query object is used to perform multi-select matching on field values. The query intent represented by the multi-value matching query object is to find documents where the value of a certain field is equal to any value in a given list.
[0088] In one optional implementation, the process of generating the unstructured query object representing the node of the logical operator "AND" is as follows: case AND: return BoolQuery( must = [BuildQuery(where.left, valueType), BuildQuery(where.right, valueType)] ) In one optional implementation, the process of generating the unstructured query object representing the logical operator "OR" is as follows: case OR: return BoolQuery( should = [BuildQuery(where.left, valueType), BuildQuery(where.right, valueType)] ) In one alternative implementation, see [link to implementation details]. Figure 10 The specific operation of step S204 above can be as follows: S1001. Based on the unstructured query statement, send the corresponding query request to the target data query engine.
[0089] Optionally, the query request is a retrieval request encapsulated based on an unstructured query statement, and the query request is sent to the target data query engine based on the unstructured query statement.
[0090] S1002. The target data query engine performs a distributed search based on the query request to obtain at least one set of tag values that match the query request.
[0091] Optionally, the target data query engine performs a distributed search based on the query request to find at least one set of tag values that match the query request from multiple data fragments.
[0092] S1003. Based on at least one set of tag values that match the query request, determine the tags corresponding to each set of tag values and the autonomous driving data packets corresponding to each tag, and use the autonomous driving data packets corresponding to each tag as the query results corresponding to the structured query statement.
[0093] Optionally, based on at least one set of tag values that match the query request, at least one autonomous driving data package is recommended to the user in order of relevance.
[0094] In one alternative implementation, see [link to implementation details]. Figure 11 The aforementioned autonomous driving data processing method also includes: S1101. Obtain the original label information input by the user, which includes information about the labels arranged in order of hierarchy.
[0095] Optionally, the original label information refers to the label data that users assign to autonomous driving data, and the original label information can specifically be JSON format data.
[0096] Optionally, the original label information includes information on labels arranged in a hierarchical order, meaning that the original labels that users tag for autonomous driving data can be nested label information.
[0097] S1102. Perform structural verification on the original label information according to the preset structured data storage template.
[0098] Optionally, the preset structured data storage template is a tag storage template predefined by the structured database. Based on the preset structured data storage template, the data type, value range, business logic, etc. of each tag in the original tag information are verified.
[0099] S1103. If the verification passes, the information of each tag in the original tag information is stored in the structured database according to the hierarchy.
[0100] Optionally, if it is determined that the original tag information input by the user meets the definition of the preset structured data storage template, then the information of each tag in the original tag information is stored in the structured database according to the hierarchical structure specified by the structured data storage template.
[0101] In one alternative implementation, see [link to implementation details]. Figure 12 The specific operation of step S1102 above can be as follows: S1201. Recursively expand the original label information to obtain the hierarchical path matrix corresponding to the original label information. The hierarchical path matrix includes: the mapping relationship between key paths and label values. The key paths are used to indicate the path between the root node and the leaf node.
[0102] Optionally, the original tag information in JSON format input by the user is recursively expanded to obtain the hierarchical path matrix corresponding to the original tag information. The hierarchical path matrix is used to indicate the mapping relationship between the paths and tag values between each node in the original tag information.
[0103] In one optional implementation, the process of recursively expanding the original label information to obtain the corresponding hierarchical path matrix is as follows: function FlattenStructure(o, root, result): if root ≠ "": result.append({key: root, value: o}) switch o.type: case HASHMAP: for key, value in o.items(): new_root = root + "." + key if root ≠ "" else key FlattenStructure(value, new_root, result) case LIST: for index, value in enumerate(o): new_root = root + ".item" if root ≠ "" else "item" FlattenStructure(value, new_root, result) First, it is determined whether the current node in the expanded original tag information is the root node. If not, the current path and the corresponding tag value are recorded. Then, recursive processing is performed according to the data type of each tag in the original tag information. For dictionary-type tags, each key-value pair needs to be traversed, and for list-type tags, each element needs to be traversed, so as to obtain the hierarchical path matrix.
[0104] S1202. Based on the preset structured data storage template, perform structure verification on each label value in the hierarchical path matrix to determine whether the original label information is valid.
[0105] Optionally, based on the definition of the preset structured data storage template, the structure of each label value in the hierarchical path matrix is verified to determine whether the original label information is tagged according to a unified standard.
[0106] In one optional implementation, the verification process of the hierarchical path matrix is as follows: For each entry in matrix: key = entry.key value = entry.value switch expected_type: case OBJECT: If the value is not a HashMap: errMessage.add(f"[{key}] should be of type object") case LIST: If the value is not a List: errMessage.add(f"[{key}] should be a list") case STRING: if value is not String: errMessage.add(f"
{key}
[0107] Optionally, if the original label information of the user's tagging of autonomous driving data conforms to the definition rules of the preset structured data storage template, it means that the original label information is compliant, and the original label information is written into the structured database according to the preset structured data storage template.
[0108] S1204. If not, generate an error message and send it to the user.
[0109] Optionally, if the original label information used by the user to label the autonomous driving data does not conform to the definition rules of the preset structured data storage template, it indicates that the original label information is non-compliant, and an error message is sent to the user to inform the user that the currently entered original label information is unavailable and needs to be relabeled.
[0110] In one alternative implementation, see [link to implementation details]. Figure 13 The specific operation of step S201 above can be as follows: S1301. Obtain the user's input information on the graphical panel. The input information includes: the target label selected by the user and the query operator set by the user for the target label.
[0111] Optionally, see Figure 14 Users can select a tag name and set query operators for the selected tag name on the graphical panel. The target tag is the tag selected by the user from the tag list, and the query operator can be the query conditions set by the user.
[0112] S1302. Based on the data type of the target tag, dynamically render the corresponding input component, and obtain the query condition value entered or selected by the user through the input component.
[0113] Optionally, the graphical panel can be dynamically rendered based on the data type corresponding to the target label selected by the user, to provide a graphical interactive interface. This graphical interactive interface only displays input components that match the current target label. The user can select or enter corresponding query condition values through these input components. Query condition values can be time ranges, dates, weather, etc., and this application does not impose specific limitations on them.
[0114] S1303. Automatically generate structured query statements based on target labels, query operators, and query condition values.
[0115] Optionally, the graphical panel can automatically generate the corresponding SQL statement based on the target label, query operator, and query condition value.
[0116] The following describes the apparatus, device, and computer-readable storage medium used to execute the autonomous driving data processing method provided in this application. The specific implementation process and technical effects are described above and will not be repeated below.
[0117] Figure 15 This is a schematic diagram of the structure of an autonomous driving data processing device provided in this application. See also: Figure 15 The device includes: The conversion module 1501 is used to generate a structured query statement based on the user's input information and convert the structured query statement into an abstract syntax tree. The abstract syntax tree includes multiple nodes and at least one label name, and each node corresponds to a query condition in the structured query statement. The query module 1502 is used to query the data type corresponding to each tag name from the structured database based on each tag name in the abstract syntax tree. The structured database stores multiple data tables corresponding to tags. Each data table corresponding to a tag stores the tag name, the data type corresponding to each tag name, and at least one level of sub-tags of the tag. Module 1503 is used to construct unstructured query statements based on the abstract syntax tree and the data types corresponding to the tag names in the abstract syntax tree; Index module 1504 retrieves the query results corresponding to the structured query statement from the target data query engine based on the unstructured query statement. The target data query engine stores at least one set of tag values corresponding to each tag.
[0118] Optionally, the query module 1502 is specifically used to: traverse each tag name in the abstract syntax tree, determine the target data table corresponding to the current tag name for the current tag name traversed, and read the data type of the current tag name from the target data table to obtain the data type corresponding to the current tag name.
[0119] Optionally, the aforementioned construction module 1503 is specifically used for: recursively traversing each node in the abstract syntax tree; for the current node being traversed, obtaining the label name corresponding to the current node to determine the data type corresponding to the current node; determining the unstructured query object corresponding to the current node based on the data type corresponding to the current node and the operator of the query condition corresponding to the current node; and nesting and combining the unstructured query objects corresponding to each node to construct an unstructured query statement.
[0120] Optionally, the aforementioned construction module 1503 is further configured to: determine whether the current node is a relational operation node based on the operator of the query condition corresponding to the current node; if so, generate an unstructured query object corresponding to the current node based on the data type of the current node and the left or right operand of the operator of the query condition corresponding to the current node; if not, generate an unstructured query object corresponding to the current node based on the data type of the current node and the right operand of the operator of the query condition corresponding to the current node.
[0121] Optionally, the aforementioned construction module 1503 is further configured to: if the operator of the query condition corresponding to the current node is the equals sign, then further determine whether the right operand of the current node is null; if so, generate a non-existent query object for the current node based on the left operand of the current node and the data type corresponding to the left operand; if not, generate an exact match query object for the current node based on the right operand of the current node and the data type corresponding to the right operand; if the operator of the query condition corresponding to the current node is the greater than sign, less than sign, greater than or equal to sign, or less than or equal to sign, then generate a range query object for the current node based on the left operand of the current node and the data type corresponding to the left operand.
[0122] Optionally, the aforementioned construction module 1503 is further configured to: if the operator of the query condition corresponding to the current node is a pattern matching operator, then generate a fuzzy query object for the current node based on the right operand of the current node and the data type corresponding to the right operand; if the operator of the query condition corresponding to the current node is a multi-value matching operator, then generate a multi-value matching query object for the current node based on the right operand of the current node and the data type corresponding to the right operand.
[0123] Optionally, the index module 1504 is specifically used for: sending a corresponding query request to the target data query engine based on the unstructured query statement; the target data query engine performing a distributed search based on the query request to obtain at least one set of tag values that match the query request; determining the tags corresponding to each set of tag values and the autonomous driving data packets corresponding to each tag based on the at least one set of tag values that match the query request, and using the autonomous driving data packets corresponding to each tag as the query results corresponding to the structured query statement.
[0124] Optionally, the above-mentioned autonomous driving data processing device further includes: a verification module 1505, which is used to: obtain the original label information input by the user, the original label information including the information of the labels arranged in a hierarchical order; perform structural verification on the original label information according to the preset structured data storage template; if the verification is successful, store the information of each label in the original label information into the structured database in a hierarchical order.
[0125] Optionally, the aforementioned verification module 1505 is specifically used to: recursively expand the original label information to obtain the hierarchical path matrix corresponding to the original label information, the hierarchical path matrix including: the mapping relationship between key paths and label values, the key path being used to indicate the path between the root node and the leaf node; perform structural verification on each label value in the hierarchical path matrix according to a preset structured data storage template to determine whether the original label information is valid; if so, store the original label information in the structured database according to the preset structured data storage template; if not, generate an error message and send it to the user.
[0126] Optionally, the conversion module 1501 is specifically used to: obtain user input information on the graphical panel, including: the target label selected by the user and the query operator set by the user for the target label; dynamically render the corresponding input component according to the data type of the target label, and obtain the query condition value input or selected by the user through the input component; and automatically generate a structured query statement according to the target label, the query operator and the query condition value.
[0127] The above-described device is used to execute the method provided in the foregoing embodiments, and its implementation principle and technical effect are similar, so they will not be described again here.
[0128] These modules can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more microprocessors, or one or more Field Programmable Gate Arrays (FPGAs). Alternatively, when a module is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. Furthermore, these modules can be integrated together as a system-on-a-chip (SOC).
[0129] Figure 16 This is a schematic diagram of the structure of a computer device provided in this application. See also: Figure 16 The computer device includes: a memory 1601 and a processor 1602. The memory 1601 stores a computer program that can run on the processor 1602. When the processor 1602 executes the computer program, it implements the steps in any of the above method embodiments.
[0130] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the steps in the various method embodiments described above.
[0131] Optionally, this application also provides a program product, such as a computer-readable storage medium, including a program that, when executed by a processor, is used to perform any of the above-described embodiments of the autonomous driving data processing method.
[0132] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.
[0133] The units described as separate components may or may not be physically separate. 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 the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0134] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional units.
[0135] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute partial steps of the methods of the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0136] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
[0137] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.
Claims
1. An autonomous driving data processing method, characterized in that, The method includes: A structured query statement is generated based on the user's input information, and the structured query statement is converted into an abstract syntax tree. The abstract syntax tree includes multiple nodes and at least one tag name, and each node corresponds to a query condition in the structured query statement. Based on the tag names in the abstract syntax tree, the data type corresponding to each tag name is queried from the structured database. The structured database stores multiple data tables corresponding to tags. Each data table corresponding to a tag stores the tag name, the data type corresponding to each tag name, and at least one level sub-tag of the tag. Based on the abstract syntax tree and the data types corresponding to each tag name in the abstract syntax tree, construct an unstructured query statement; Based on the unstructured query statement, the query results corresponding to the structured query statement are obtained from the target data query engine, wherein the target data query engine stores at least one set of tag values corresponding to each tag.
2. The autonomous driving data processing method according to claim 1, characterized in that, The step of querying the data type corresponding to each tag name from the structured database based on each tag name in the abstract syntax tree includes: Traverse each tag name in the abstract syntax tree, and for the current tag name encountered, determine the target data table corresponding to the current tag name; Read the data type of the current tag name from the target data table to obtain the data type corresponding to the current tag name.
3. The autonomous driving data processing method according to claim 1, characterized in that, The step of constructing an unstructured query statement based on the abstract syntax tree and the data types corresponding to each tag name in the abstract syntax tree includes: Recursively traverse each node in the abstract syntax tree, and for the current node reached, obtain the tag name corresponding to the current node to determine the data type corresponding to the current node; Based on the data type of the current node and the operator of the query condition corresponding to the current node, determine the unstructured query object corresponding to the current node; The unstructured query objects corresponding to each node are nested and combined to construct the unstructured query statement.
4. The autonomous driving data processing method according to claim 3, characterized in that, The step of determining the unstructured query object corresponding to the current node based on the data type corresponding to the current node and the operator of the query condition corresponding to the current node includes: Based on the operator of the query condition corresponding to the current node, determine whether the current node is a relational operation node; If so, then based on the data type corresponding to the current node and the left or right operand of the operator of the query condition corresponding to the current node, generate the unstructured query object corresponding to the current node. If not, then an unstructured query object corresponding to the current node is generated based on the data type corresponding to the current node and the right operand of the operator of the query condition corresponding to the current node.
5. The autonomous driving data processing method according to claim 4, characterized in that, The step of generating an unstructured query object corresponding to the current node based on the data type corresponding to the current node and the left or right operand of the operator of the query condition corresponding to the current node includes: If the operator of the query condition corresponding to the current node is the equals sign, then determine whether the right operand of the current node is null. If yes, then generate a non-existent query object for the current node based on the left operand of the current node and the data type corresponding to the left operand. If no, then generate an exact match query object for the current node based on the right operand of the current node and the data type corresponding to the right operand. If the operator of the query condition corresponding to the current node is a greater than operator, a less than operator, a greater than or equal to operator, or a less than or equal to operator, then a range query object for the current node is generated based on the left operand of the current node and the data type corresponding to the left operand.
6. The autonomous driving data processing method according to claim 4, characterized in that, The step of generating an unstructured query object corresponding to the current node based on the data type corresponding to the current node and the right operand of the operator of the query condition corresponding to the current node includes: If the operator of the query condition corresponding to the current node is a pattern matching operator, then a fuzzy query object for the current node is generated based on the right operand of the current node and the data type corresponding to the right operand. If the operator of the query condition corresponding to the current node is a multi-value matching operator, then the multi-value matching query object of the current node is generated according to the right operand of the current node and the data type corresponding to the right operand.
7. The autonomous driving data processing method according to claim 1, characterized in that, The step of retrieving the query results corresponding to the structured query statement from the target data query engine based on the unstructured query statement includes: Based on the unstructured query statement, a corresponding query request is sent to the target data query engine; The target data query engine performs a distributed search based on the query request to obtain at least one set of tag values that match the query request; Based on at least one set of tag values that match the query request, the tags corresponding to each set of tag values and the autonomous driving data packets corresponding to each tag are determined, and the autonomous driving data packets corresponding to each tag are used as the query results corresponding to the structured query statement.
8. The autonomous driving data processing method according to claim 1, characterized in that, The method further includes: Obtain the original tag information input by the user, wherein the original tag information includes information on tags arranged in hierarchical order; The original tag information is structurally verified according to a preset structured data storage template; If the verification passes, the information of each tag in the original tag information is stored in the structured database according to the hierarchy.
9. The autonomous driving data processing method according to claim 8, characterized in that, The step of performing structural verification on the original tag information according to a preset structured data storage template includes: The original label information is recursively expanded to obtain the hierarchical path matrix corresponding to the original label information. The hierarchical path matrix includes: the mapping relationship between key paths and label values, where the key paths are used to indicate the path between the root node and the leaf node. Based on a preset structured data storage template, the structure of each tag value in the hierarchical path matrix is verified to determine whether the original tag information is valid. If so, the original tag information is stored in the structured database according to the preset structured data storage template; If not, an error message will be generated and sent to the user.
10. The autonomous driving data processing method according to claim 1, characterized in that, The step of generating a structured query statement based on user input includes: Obtain user input information on the graphical panel, the input information including: the target label selected by the user and the query operator set by the user for the target label; Based on the data type of the target tag, dynamically render the corresponding input component, and obtain the query condition value input or selected by the user through the input component; A structured query statement is automatically generated based on the target label, the query operator, and the query condition value.
11. An autonomous driving data processing device, characterized in that, The device includes: The conversion module is used to generate a structured query statement based on the user's input information and convert the structured query statement into an abstract syntax tree. The abstract syntax tree includes multiple nodes and at least one tag name, and each node corresponds to a query condition in the structured query statement. The query module is used to query the data type corresponding to each tag name from the structured database based on each tag name in the abstract syntax tree. The structured database stores multiple data tables corresponding to tags, and each data table corresponding to a tag stores the tag name, the data type corresponding to each tag name, and at least one level sub-tag of the tag. The construction module is used to construct unstructured query statements based on the abstract syntax tree and the data types corresponding to each tag name in the abstract syntax tree; The indexing module retrieves the query results corresponding to the structured query statement from the target data query engine based on the unstructured query statement, wherein the target data query engine stores at least one set of tag values corresponding to each tag.
12. A computer device, characterized in that, include: A memory and a processor, wherein the memory stores a computer program that can run on the processor, and when the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 10.
13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1 to 10.