Unified sql query method for heterogeneous data sources

Abstract

The application belongs to the technical field of database systems, and discloses a unified SQL query method for heterogeneous data sources, which comprises an access adaptation module, a parsing conversion module, an optimization verification module, an SQL execution module and the like. The access adaptation module accesses a configuration client interface, and an interface sends a query request to a background. Then, the parsing conversion module parses the query request according to interface configuration information, directly performs abnormal processing and returns error information if the parsing fails, and optimizes an execution plan of the request otherwise. Data is queried in a bottom-layer database according to transmission parameters and cache requirements in the query request. Finally, the obtained data is converted into a unified format and returned to a front end. The application separates a query language from data storage, enables a multi-database system to transparently access bottom-layer data, ensures a high interoperation accuracy between different data sources, and effectively improves the expansibility and application range of a heterogeneous source unified query system.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of database systems, and particularly relates to a unified SQL query method for heterogeneous data sources. BACKGROUND

[0002] SQL is the most widely used data query and analysis language at present, and a database management system should fully utilize the SQL language to improve the work quality and efficiency of a computer application system, however, the traditional single database technology is difficult to adapt to the current complex and changeable mass data processing business. In order to adapt to the mass data processing in the big data era, the data types are extended from the traditional structured data to real-time data flow and various types of unstructured data, which has given birth to a series of NoSQL and NewSQL technologies to solve the problems that the relational database cannot solve, but in actual application, the relational database cannot be completely abandoned. The cross-platform and unified query operation of heterogeneous databases, structured and semi-structured data of various data sources has become a supporting technology for research and application.

[0003] With the development of data processing business, enterprises begin to manage business data by using different database products according to their own business characteristics, and describe data by using different data models, which forms a situation that different technologies solve different scene applications: for example, an enterprise may manage data by using multiple mainstream databases such as Oracle, MySQL and PostgreSQL; the data of each department may be stored in different file types such as CSV, XML and JSON; and various real-time businesses need to use NoSQL analysis and processing such as HBase and MongoDB. Research shows that each enterprise application program involves at least two to three different types of query systems on average, and many real analysis businesses also put forward the demand for convenient and efficient cross-platform query.

[0004] In contrast to the rapid development of database systems, the existing research work on unified SQL query has certain problems and deficiencies in ease of use, uniformity and efficiency: first, the existing work has not provided a unified SQL query language suitable for cross-platform query, and the ease of use is not high; second, due to the different characteristics and different syntax rules of heterogeneous databases, the mutual access between databases needs to be realized by writing data conversion interfaces, which has high learning cost and large workload, and has poor expansibility; in addition, the existing work can only optimize single cross-platform SQL query, which may seriously affect the performance of cross-platform query. SUMMARY

[0005] In order to solve the above technical problems, the application provides a universal multi-database unified query access framework, which is adapted to SQL and NoSQL query operations, hides the details of the underlying heterogeneous database, realizes the unified scheduling of SQL and NoSQL databases, and ensures that the query method has good scalability.

[0006] In order to achieve the above purpose, the application is realized by the following technical solutions:

[0007] The application is a unified SQL query method for heterogeneous data sources, which comprises the following steps:

[0008] Step 1, receiving the access request, i.e. SQL request, sent by the client and the source database and target database identifiers corresponding to the SQL request, and transmitting the SQL request and the source database identifier to the access adaptation module;

[0009] Step 2, the access adaptation module receives the SQL request of step 1 and the source database identifier corresponding to the SQL request, the access adaptation module preloads the corresponding API or JDBC according to the source database and target database identifiers obtained by the client, and then sends the query request to the parsing and conversion module, wherein the parsing and conversion module comprises a SQL parsing module, a semantic analysis module and a syntax rewriting module;

[0010] Step 3, the parsing and conversion module parses the SQL request and the source database identifier corresponding to the SQL request transmitted in step 2, generates an abstract syntax tree (AST) structure through the SQL parsing module, obtains a target SQL request, calls the semantic analysis module to perform semantic extraction and analysis on the AST, obtains a corresponding logical execution tree, saves and updates the meta information, directly performs exception processing and returns error information if the parsing fails, and successfully rewrites the logical execution tree into an access format supported by the target database platform through the syntax rewriting module;

[0011] Step 4, the optimization verification module verifies the correctness of the target SQL request according to the meta information stored in the logical execution tree, further optimizes the target SQL request according to the rule-based calculation if the verification is passed, reduces the data operation amount of the SQL request on the target platform, and improves the overall efficiency of the logical execution plan;

[0012] Step 5, importing the converted SQL request output in step 4 into the unified execution module, connecting the underlying database corresponding to the target database identifier, querying the data, and converting the obtained data into a unified format and returning to the front end.

[0013] Further, the step 2 comprises the following steps:

[0014] Step 21, the adaptation access module receives the SQL request of the client, and records the source database and target database identifiers corresponding to the SQL request;

[0015] Step 22, according to the source database and target database identifiers, preloading the corresponding API or JDBC, preparing to create a connection (Connection) with the underlying database;

[0016] Step 23, the SQL request to be executed and the source database identifier corresponding to the SQL request are sent to the parsing and conversion module.

[0017] Further, the step 3 specifically includes the following steps:

[0018] Step 31, a unified intermediate representation model is designed for the SQL request of the heterogeneous database, and a unified metadata storage format is provided for all data sources, which is used to generate a logical execution tree;

[0019] Step 32, interface information is obtained from the adaptation access module, including the SQL request and the source database identifier, and the corresponding SQL syntax parser is loaded, which is composed of a lexical analyzer (SqlLexer) and a syntax analyzer (SqlParser) generated by the ANTLR tool. First, the lexical analyzer is responsible for analyzing the lexicon, and by splitting the SQL, the input character sequence is decomposed into a series of lexical symbols (tokens). Then, the syntax analyzer checks whether the sequence structure of the lexical symbol conforms to the syntax rule, judges whether the statement is legal, and assembles the lexical symbol into an abstract syntax tree structure according to the syntax rule;

[0020] Step 33, the SQL parsing module inputs the SQL request statement into the SQL syntax parser, and after lexical analysis and syntax analysis, the query request is converted into an abstract syntax tree (AST) structure according to the defined syntax rule;

[0021] Step 34, the semantic analysis module obtains the abstract syntax tree structure, calls the semantic analyzer to perform tree traversal on the abstract syntax tree, controls the semantic analysis process of the abstract syntax tree through the Visitor access mode, extracts the abstract syntax tree node information in a bottom-up order, encapsulates the corresponding metadata information into the intermediate representation model, and generates a logical execution tree;

[0022] Step 35, after the syntax rewriting module obtains the logical execution tree, the syntax rewriter is called to map the logical execution tree structure, and the logical query plan represented by the intermediate representation model is rewritten and converted into a query request that can be executed in the target source.

[0023] Further, the step 31 designs the intermediate representation model as a conversion medium, provides a unified metadata description for all data sources, changes the direct conversion mode from the source library to the target library into the mode of converting the source library data into the intermediate mode and then converting the intermediate mode into the target library data, improves the scalability of the system, and reduces the development cost in the multi-database integration processing process.

[0024] Further, the step 4 specifically includes the following steps:

[0025] Step 41, a design verification optimization module is designed, which is divided into a design query verifier and a query optimizer. The query verifier formulates a metadata verification rule, and the application scope of the verification rule is all heterogeneous databases supported by the framework. The query optimizer formulates a rule for optimizing the query request;

[0026] Step 42, a target SQL request is obtained from the parsing conversion module, the syntax and semantic correctness of the target request are verified according to the stored metadata information through the query verifier, if the conversion SQL request verification is incorrect, an exception is handled, and error information is directly returned;

[0027] Step 43, if the target SQL request passes the syntax and semantic verification, the query optimizer is called to optimize the target SQL request. The query optimizer adopts a rule-based optimization (RBO) mode, defines a series of optimization rules, including column pruning, maximum and minimum elimination, projection elimination, predicate pushdown, and Join elimination. The optimization optimizer search process can be regarded as a process of judging whether each syntax block of the SQL matches the optimization format (Pattern) according to the specified priority order. If it matches, the SQL statement is optimized according to the optimization rule (Rule), and the cycle is re-entered until there is no syntax block that can be matched, and the optimization is completed.

[0028] Further, the step 5 specifically includes the following steps:

[0029] Step 51, the unified execution module loads the corresponding API or JDBC according to the target data source mark obtained in step 1, establishes the corresponding underlying database connection through the connection pool, and waits for the target SQL request input in step 4;

[0030] Step 52, the target SQL statement is obtained, and the database query operation is performed through the connector: if the accessed database is a relational database, the queried data is directly returned to the access adaptation module; if the access result is a non-relational mode, the underlying return result is converted into a relational table structure;

[0031] Step 53, the unified execution module closes the connection of the underlying database, returns the relational form query result to the access adaptation module, and the access adaptation module integrates the query result.

[0032] The step 53 is based on the business environment of the system, and the advantages of maintaining the integrity of the transaction based on the easy understanding and maintenance of the relational table format, the data adaptation module selects the relationalization of the NoSQL query data, that is, the non-relational storage structure such as key value, document and graph is converted into a relational table structure, and finally the SQL query results of multiple databases are combined and output to the client.

[0033] The beneficial effects of the present application are:

[0034] The present application designs and realizes a set of efficient and flexible cross-platform unified SQL query system, hides the difference of the underlying library by introducing an intermediate model, so as to realize the unified management of databases with different architectures. Developers can realize cross-platform access and interoperation of heterogeneous databases by calling a unified access interface, thereby reducing the repeated work overhead in system development, and having important significance for storage and processing of multi-source heterogeneous data.

[0035] Specifically:

[0036] (1) The present application adopts a multi-database integration scheme mainly using a relational database, and realizes data adaptation and access adaptation by SQL query, fully utilizes the reliability and portability of SQL syntax and the flexibility of NoSQL, and avoids the shortcomings of NoSQL, such as lack of unified standard and poor universality.

[0037] (2) The present application adopts a database connection pool to uniformly manage the connection of the underlying library, realizes common access to multiple heterogeneous databases. By establishing a buffer pool for database connection, the connection speed and stability of query access are improved by avoiding frequent creation and closing of connection.

[0038] (3) The present application designs an intermediate representation format, provides a unified metadata description model for relational or non-relational data sources, changes the direct conversion mode from source library to target library into the mode of converting source library data into intermediate mode and then converting intermediate mode data into target library data, which helps to shield the operation difference between different execution platforms and improve the flexibility and scalability of the framework. BRIEF DESCRIPTION OF DRAWINGS

[0039] Figure 1 It is a flowchart of the SQL query method of the present application.

[0040] Figure 2 It is a general architecture diagram of the unified access framework of multi-source heterogeneous databases.

[0041] Figure 3 It is a flowchart of SQL query request analysis and conversion. DETAILED DESCRIPTION

[0042] Embodiments of the present application will be described below with reference to drawings. Many practical details are described below in order to provide a thorough understanding of embodiments of the present application. However, it will be apparent to those skilled in the art that the present application can be practiced without these specific details. In other instances, well-known methods, procedures, components, and networks have not been described in detail so as not to unnecessarily obscure aspects of the present application.

[0043] As shown in Figures 1-2 The present application is a unified SQL query method for heterogeneous data sources, comprising the following steps:

[0044] Step 1, receiving an access request, i.e. a SQL request, sent by a client, and the source database and target database identifiers corresponding to the SQL request, and transmitting the SQL request and the source database identifier to an access adaptation module. Based on SQL reliability and portability, the unified SQL query method for heterogeneous data sources has a standardized mode, and mainly uses SQL statement queries, and data adaptation and access adaptation are both implemented by SQL queries.

[0045] Step 2, the access adaptation module receives the SQL request and the source database identifier corresponding to the SQL request in step 1, and the access adaptation module preloads the corresponding API or JDBC according to the source database and target database identifiers obtained by the client, and then sends the query request to a parsing and conversion module, wherein the parsing and conversion module comprises a SQL parsing module, a semantic analysis module and a syntax rewriting module.

[0046] The step 2 comprises the following steps:

[0047] Step 21, the access adaptation module receives the SQL request of the client, and records the source database and target database identifiers corresponding to the SQL request;

[0048] Step 22, preloading the corresponding API or JDBC according to the source database and target database identifiers, and preparing to create a connection (Connection) with the underlying database;

[0049] Step 23, sending the SQL request to be executed and the source database identifier corresponding to the SQL request to the parsing and conversion module.

[0050] Step 3, as shown in Figure 3 The parsing and conversion module parses the SQL request and the source database identifier corresponding to the SQL request transmitted in step 2, generates an abstract syntax tree (AST) structure through the SQL parsing module to obtain a target SQL request, calls the semantic analysis module to perform semantic extraction and analysis on the AST to obtain a corresponding logical execution tree, saves and updates the meta information, directly performs exception processing and returns error information if the parsing fails, and successfully rewrites the logical execution tree into an access format supported by the target database platform through the syntax rewriting module.

[0051] The step 3 analysis reconstruction module parses the SQL request transmitted in step 2 and the source database identification corresponding to the SQL request, and specifically includes the following steps:

[0052] Step 31, a unified intermediate representation model is designed for the SQL request of the heterogeneous database, and a unified metadata storage format is provided for all data sources, which is used to generate a logical execution tree.

[0053] The intermediate representation model is designed as a conversion medium, and a unified metadata description is provided for all data sources. The direct conversion mode from the source database to the target database is changed to the mode of converting the source database data into the intermediate mode and then converting the intermediate mode into the target database data, which improves the scalability of the system and reduces the development cost in the process of multi-database integration processing.

[0054] Semantic analysis can be divided into expression analysis and statement analysis. Expression analysis is responsible for extracting and encapsulating the structures representing logical relations, calculation expressions, and object names, variables, and constants in the AST as metadata, and analyzing the data types, and finally filling in the statement attribute to analyze the semantic legality and data dependency of the model. The main task of statement analysis is to analyze the calculation operation of the SQL statement on the data set and describe the syntax block of each clause of the SQL in a structured form. Each syntax block can be described by combining several Entity entities. The unified formal representation of each entity is:

[0055] Entity = <Type, Field, Expr, Relation>

[0056] Where Type is the Entity type name, indicating the physical attribute type of the entity; Field indicates the element set to which the entity belongs, which can be a homogeneous or subclass entity; Expr stores the data or parameters of the Entity in the form of an expression; and the entity relationship Relation ∈ (Entity × Entity) is used to describe the semantic association between entities, including entity condition expressions or stored relationship data.

[0057] Step 32, get interface information from the adaptive access module, including SQL request and source database identification, load the corresponding SQL syntax parser, the SQL syntax parser is composed of a lexical analyzer (SqlLexer) and a syntax analyzer (SqlParser) generated by ANTLR tool, the lexical analyzer is responsible for analyzing the lexicon first, by splitting SQL, i.e. decomposing the input character sequence into a series of lexical symbols (token), then the syntax analyzer checks whether the sequence structure of the lexical symbol conforms to the syntax rule, judges whether the statement is legal, and assembles the lexical symbol into an abstract syntax tree structure according to the syntax rule;

[0058] Step 33, the SQL parsing module inputs the SQL request statement into the SQL syntax parser, and through lexical analysis and syntax analysis, converts the query request into an abstract syntax tree (AST) structure according to the defined syntax rule;

[0059] Step 34, the semantic analysis module obtains the abstract syntax tree structure, calls the semantic analyzer to perform tree traversal on the abstract syntax tree, controls the semantic analysis process of the abstract syntax tree through the Visitor access mode, extracts and analyzes the abstract syntax tree node information in a bottom-up order, encapsulates the corresponding metadata information into the intermediate representation model, and generates a logical execution tree. Taking the SELECT query statement as an example, the encapsulated model structure is as follows:

[0060] SELECT [ALL|DISTINCT] <entity1[,entity2,...]>

[0061] FROM <entity[join:condition_expr],...>

[0062] WHERE <condition_expr>

[0063] ORDER BY <entity1[ASC|DESC][,entity2,...]>

[0064] The specific steps are: accessing the root node of the AST, judging the SQL statement type, generating the corresponding statement logical structure, then obtaining the child node set, and accessing down in DFS order; if the current node is a rule node and the subtree rooted at it represents a SQL clause, then generate the corresponding SQL operation item and assign it to the statement, and then continue to access and parse down; if the current node is a rule node and the subtree rooted at it represents an expression, then generate the corresponding expression structure and access down to fill in its operands and attributes; if the current node is a leaf node, obtain the node content, if it is a constant or identifier, encapsulate it as a basic expression structure and fill it into the expression; otherwise, end the current access. After the traversal ends, the statement object is returned, and the abstract syntax tree is converted into a logical execution tree;

[0065] Step 35, after the syntax rewriting module obtains the logical execution tree, it calls the syntax rewriter to map the logical execution tree structure, and converts the logical query plan represented by the intermediate representation model into a query request that can be executed on the target source.

[0066] After semantic analysis and metadata extraction and binding, the abstract syntax tree is converted into a unified intermediate representation model encapsulating the SQL query task, and the role of the rewriter is to generate the target statement based on the intermediate model. For the dialect of a relational database, it can be converted into a semantically consistent target source form according to the intermediate model; for

[0067] NoSQL database, its structure can be one-to-one mapped and converted, for example, the table, column, attribute and data object of a relational database are respectively corresponding to the collection, document, field, value and other data structures of the NoSQL database MongoDB. After the analyzer generates the logical execution tree of the SQL, the SQL data is converted into the NoSQL form through this mapping relationship, and finally the SQL to MongoDB statement reconstruction is realized. Taking "SELECT * FROM people WHERE status = "A" ORDER BY user_id DESC;" as an example, the analysis shows that the query entity is the people table, and the status = "A" is the filtering condition to obtain all attributes of the entity, and the result set is sorted in descending order according to the user_id column. The reconstructed MongoDB statement corresponding to it is "db.people.find({status:"A"}).sort({user_id:-1})".

[0068] Step 4, the optimization verification module verifies the correctness of the target SQL request according to the meta information stored in the logical execution tree, and if the verification is passed, it further optimizes the target SQL request according to the rule-based calculation, reduces the data operation amount of the SQL request on the target platform, and improves the overall efficiency of the logical execution plan.

[0069] Specifically comprising the following steps:

[0070] Step 41, a design verification optimization module is designed, which is divided into a design query verifier and a query optimizer, the query verifier formulates metadata verification rules, and the application scope of the verification rules is all heterogeneous databases supported by the framework; the query optimizer formulates rules for optimizing query requests;

[0071] Step 42, a target SQL request is obtained from the parsing conversion module, the syntax and semantic correctness of the target request are verified according to stored metadata information through the query verifier, if the converted SQL request verification is incorrect, an exception is handled, and error information is directly returned;

[0072] Step 43, if the target SQL request passes the syntax and semantic verification, the query optimizer is called to optimize the target SQL request. The query optimizer adopts a rule-based optimization (RBO) mode, defines a series of optimization rules, including column pruning, maximum and minimum elimination, projection elimination, predicate pushdown, Join elimination, etc. The optimization optimizer search process can be regarded as a process of judging whether each syntax block of the SQL matches the optimization format (Pattern) according to the specified priority order. If it matches, the SQL statement is optimized according to the optimization rule (Rule), and the cycle is re-entered until there is no syntax block that can be matched, and the optimization is completed.

[0073] Taking a "student query for obtaining full marks" as an example, the commonly used SQL writing method is: SELECT*FROM Student t,Grade g WHERE t.S_id=g.S_id AND g.grade=100.

[0074] The corresponding relational algebra of the Select statement is:

[0075]

[0076] According to the algebraic expression, when the statement is executed, the database will first full-table scan all the Student student information table and the Grade student score table, and then filter according to the where condition, which increases the query calculation amount. This situation can be optimized by predicate pushdown, that is, the filtering condition expression (such as =,!=, like, in, between, etc.) is as close as possible to the data source (Student table and Grade table) to be filtered, that is, the "grade = 100" limit is applied to Grade first, and then the connection operation is performed, so as to preferentially filter useless data and improve the SQL execution efficiency. The corresponding relational algebra is:

[0077]

[0078] The converted corresponding sentence is: SELECT * FROM Student RIGHT JOIN t1 (SELECT * FROM Grade WHERE grade = 100) t2 ON t1.S_id = t2.S_id. After optimization, the database filters most of the useless data in the Grade table during the inner query, greatly reducing the temporary table space overhead and improving the query efficiency.

[0079] Step 5, the converted SQL request output in step 4 is imported into the unified execution module, the connection target database identifier corresponds to the underlying database, the data is queried, and the obtained data is converted into a unified format and returned to the front end.

[0080] Specifically, the following steps are included:

[0081] Step 51, the unified execution module loads the corresponding API or JDBC according to the target data source mark obtained in step 1, establishes a connection with the corresponding underlying database through a connection pool, and waits for the target SQL request input in step 4;

[0082] Step 52, the target SQL statement is obtained, and a database query operation is performed through a connector: if the accessed database is a relational database, the query data is directly returned to the access adaptation module; if the access result is a non-relational mode, the underlying return result is converted into a relational table structure;

[0083] Step 53, the unified execution module closes the connection of the underlying database, returns the relational form query result to the access adaptation module, and the access adaptation module integrates the query result.

[0084] The step 53, based on the business environment of the system, and the advantages of easy understanding and maintenance of the relational table format and the integrity of the transaction, the data adaptation module selects the relationalization of the NoSQL query data, that is, the key value, document and graph non-relational storage structure is converted into a relational table structure, and finally the multi-database SQL query result is merged and output to the client.

[0085] The above only describes the embodiments of the present application and is not used to limit the present application. For those skilled in the art, the present application can have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application shall be included in the scope of the claims of the present application.

Claims

1. A method for unified SQL query oriented to heterogeneous data sources, characterized in that: The unified SQL query of the heterogeneous data source comprises the following steps: Step 1, receiving an access request, i.e. an SQL request, sent by a client and source database and target database identifiers corresponding to the SQL request, and transmitting the SQL request and the source database identifier to an access adaptation module; Step 2, the access adaptation module receives the SQL request and the source database identifier corresponding to the SQL request in step 1, preloads a corresponding API or JDBC according to the source database and target database identifiers obtained by the client, and then sends a query request to a parsing and conversion module, wherein the parsing and conversion module comprises an SQL parsing module, a semantic analysis module and a syntax rewriting module; Step 3, the parsing and conversion module parses the SQL request and the source database identifier corresponding to the SQL request transmitted in step 2, generates an abstract syntax tree structure through the SQL parsing module to obtain a target SQL request, calls the semantic analysis module to perform semantic extraction and analysis on the AST to obtain a corresponding logical execution tree, and saves and updates meta information, directly performs exception processing and returns error information if the parsing fails, and rewrites the logical execution tree into an access format supported by the target database platform through the syntax rewriting module if the parsing succeeds; Step 4, the optimization and verification module verifies the correctness of the target SQL request according to the meta information stored in the logical execution tree, and the optimization and verification module is divided into a design query verifier and a query optimizer, the query optimizer further optimizes the target SQL request according to rule-based calculation if the verification passes, a series of optimization rules are defined, including column pruning, maximum and minimum elimination, projection elimination, predicate pushdown and Join elimination, the optimizer searches according to a specified priority order, and it is considered that the SQL blocks are matched with the optimization format in a loop, the SQL statement is optimized according to the optimization rule if it is matched, and the loop is re-entered until there is no matched block, and the optimization is completed; Step 5, importing the optimized SQL request output in step 4 into a unified execution module, connecting a bottom-layer database corresponding to the target database identifier, querying data, and converting the obtained data into a unified format and returning to the front end; wherein, A unified intermediate representation model is designed for the SQL request of the heterogeneous database, the intermediate representation model is a conversion medium, a unified meta data description is provided for all data sources, a direct conversion mode from a source database to a target database is changed into a mode of converting data from a source database to an intermediate mode and then converting data from the intermediate mode to a target database. 2.The method of claim 1, wherein: The step 2 comprises the following steps: Step 21, the access adaptation module receives an SQL request of a client and records source database and target database identifiers corresponding to the SQL request; Step 22, preloading a corresponding API or JDBC according to the source database and target database identifiers, and preparing to create a connection with a bottom-layer database; Step 23, sending an SQL request to be executed and the source database identifier corresponding to the SQL request to a parsing and conversion module. 3.The method of claim 1, wherein: The step 3 parsing and reconstruction module parses the SQL request and the source database identifier corresponding to the SQL request transmitted in step 2, and specifically comprises the following steps: Step 31, design a unified intermediate representation model for SQL requests of heterogeneous databases, provide a unified metadata storage format for all data sources, and generate a logical execution tree; Step 32, obtain interface information from the adaptive access module, including SQL requests and source database identification, load the corresponding SQL syntax parser, which consists of a lexical analyzer and a syntax analyzer generated by the ANTLR tool, first the lexical analyzer is responsible for analyzing the lexicon, by splitting SQL, i.e. decomposing the input character sequence into a series of lexical symbols, then the syntax analyzer checks whether the sequence structure of the lexical symbols conforms to the syntax rules, judges whether the statement is legal, and assembles the lexical symbols into an abstract syntax tree structure according to the syntax rules; Step 33, the SQL parsing module inputs the SQL request statement into the SQL syntax parser, and after lexical analysis and syntax analysis, the query request is converted into an abstract syntax tree structure according to the defined syntax rules; Step 34, the semantic analysis module obtains the abstract syntax tree structure, calls the semantic analyzer to perform tree traversal on the abstract syntax tree, controls the semantic analysis process of the abstract syntax tree through the Visitor access mode, extracts and analyzes the abstract syntax tree node information in a bottom-up order, encapsulates the corresponding metadata information into the intermediate representation model, and generates a logical execution tree; Step 35, after obtaining the logical execution tree, the syntax rewriting module calls the syntax rewriter to map the logical execution tree structure, and rewrites the logical query plan represented by the intermediate representation model into a query request that can be executed on the target source. 4.The method of claim 1, wherein: The step 4 specifically includes the following steps: Step 41, the query verifier formulates metadata verification rules, and the verification rules are applicable to all heterogeneous databases supported by the framework; the query optimizer formulates rules to optimize the query request; Step 42, obtain the target SQL request from the parsing and conversion module, verify the syntax and semantic correctness of the target request according to the stored metadata information through the query verifier, if the converted SQL request verification is incorrect, perform exception handling and directly return error information; Step 43, if the target SQL request passes the syntax and semantic verification, call the query optimizer to optimize the target SQL request.

5. The method of claim 1, wherein: The step 5 specifically includes the following steps: Step 51, the unified execution module loads the corresponding API or JDBC according to the target data source mark obtained in step 1, establishes the corresponding underlying database connection through the connection pool, and waits for the target SQL request input in step 4; Step 52, obtain the target SQL statement, execute the database query operation through the connector: if the accessed database is a relational database, the query data is directly returned to the access adaptation module; if the access result is a non-relational mode, convert the underlying return result into a relational table structure; Step 53, the unified execution module closes the connection of the underlying database, returns the query result in relational form to the access adaptation module, and the access adaptation module integrates the query result.

Images