A multi-source heterogeneous distributed spatio-temporal data node joint query method and system

Abstract

The application discloses a kind of multi-source heterogeneous distributed spatio-temporal data node's joint query method and system, belong to the field of data management and query analysis of earth science spatio-temporal data.The method is first to the earth science spatio-temporal data set is standardized cataloguing and registration, simultaneously, to realize the mapping and matching of different time system, with global unified time axis index is built;Subsequently, parse client query request, through the logical execution plan of extended spatio-temporal function verification generation, and introduce custom rules to volcano optimizer, to generate the physical execution plan of minimum cost;Finally, using dynamic code generation technology, physical operator is converted into distributable execution code, via spatial distributed computing framework efficiently executes and returns result.The application solves the problem of multi-source data spatio-temporal alignment difficult, low query efficiency in the field of earth science, provides high-performance, scalable solution for complex spatio-temporal analysis.

Description

Technical Field

[0001] This invention belongs to the field of data management and query analysis of spatiotemporal data in Earth science, and particularly relates to a joint query method and system for multi-source heterogeneous distributed spatiotemporal data nodes. Background Technology

[0002] With the ever-increasing volume of data in fields such as Earth science, remote sensing, meteorology, and environmental monitoring, especially in the cloud-native era, data storage and processing technologies are undergoing profound changes. Traditional Geographic Information Systems (GIS) typically rely on centralized data storage architectures, migrating different types of data to a unified data center for management and querying. However, this approach faces several challenges when processing large-scale, heterogeneous, and widely distributed spatiotemporal Earth science data, including data transmission, storage redundancy, and query performance.

[0003] Earth science spatiotemporal data is characterized by diverse storage media and methods. Data formats include vector data, raster data, and time-series data, among others. This variety of storage formats makes the unified management of multi-source, heterogeneous Earth science data costly. Particularly in geological and deep-time Earth science research, spatiotemporal data often exhibits multi-scale characteristics. Deep-time Earth science spatiotemporal data displays significant multi-scale features in the time dimension, with a vast span of geological time granularity, typically involving timescales from millions to billions of years. This makes the management and retrieval of Earth science spatiotemporal data even more complex. Existing technologies often lack targeted optimization and support when processing these deep-time data spanning vast time spans.

[0004] Furthermore, joint queries across data sources are quite difficult to implement. While software such as GeoMesa and Apache Sedona can perform spatial analysis of spatiotemporal data using SQL, they primarily focus on distributed spatial analysis and computation of spatiotemporal data, lacking joint query methods and targeted optimizations for heterogeneous distributed Earth science spatiotemporal data. Moreover, their spatiotemporal data is mostly expressed in a consistent timescale format, lacking optimization for the multi-timescale characteristics of deep-time Earth science spatiotemporal data. Summary of the Invention

[0005] The purpose of this invention is to solve the problems existing in the prior art and to provide a joint query method and system for multi-source heterogeneous distributed spatiotemporal data nodes.

[0006] To achieve the above-mentioned objectives, the present invention specifically adopts the following technical solution:

[0007] In a first aspect, the present invention provides a joint query method for multi-source heterogeneous distributed spatiotemporal data nodes, comprising the following steps:

[0008] S1. For the geoscience spatiotemporal dataset in the data source that requires spatiotemporal joint query, perform metadata standardization cataloging and register it as a data schema in a hash table maintained in computer memory. At the same time, maintain a unified time axis index globally in memory to be responsible for all time scale-related matching.

[0009] S2. Obtain the query request uploaded by the client in the form of Structured Query Language, parse and validate the query request, and add support for parsing the spatial function for the time scale matching function in the validation process, thereby generating a logical execution plan;

[0010] S3. The Volcano Optimizer optimizes the logical execution plan through a variety of predefined rules and converts the logical execution plan into the least costly physical execution plan based on the spatiotemporal data of Earth science.

[0011] S4. A dynamic code generation method is used to convert the physical execution operators in the physical execution plan into executable code blocks for the spatial distributed computing framework. During the query execution process, the code blocks are compiled into executable class bytecode using a just-in-time compiler, and the class bytecode is distributed to the spatial distributed computing framework through a class distribution server. After receiving the class bytecode, the framework executes the physical execution plan in a distributed manner, aggregates the query results, and converts them into an enumerator format that the client can recognize. Finally, the query result data stream is formed and returned to the client.

[0012] Based on the above scheme, each step can be implemented in the following preferred manner.

[0013] As a preferred embodiment of the first aspect mentioned above, in step S1, the metadata in the Earth Science Spatiotemporal Dataset is organized in accordance with the unified standard of the Spatiotemporal Asset Catalog and saved in JSON format; the metadata includes the unique identifier ID of the Earth Science Spatiotemporal Dataset, text description, spatial range, time range, time scale, data storage type, storage identifier, and data format.

[0014] As a preferred embodiment of the first aspect above, in step S1, the unified time axis index includes an extensible registry for converting different time scales in the geoscience spatiotemporal dataset into numerical intervals on an absolute time axis; when registering a geoscience spatiotemporal dataset, its corresponding numerical interval is inserted into the segment tree as a node, and the unique identifier ID of all geoscience spatiotemporal datasets that completely cover the numerical interval is stored.

[0015] As a preferred embodiment of the first aspect above, the process of generating the logic execution plan in step S2 is as follows:

[0016] S21. The SQL parser parses the query request into an abstract syntax tree;

[0017] S22. The SQL validator verifies the abstract syntax tree: if both the first and second verification conditions are met, the abstract syntax tree is transformed into a logical execution plan; otherwise, the query is terminated. The first verification condition is that the data pattern of the data source involved in the query has been registered in the hash table, and the second verification condition is that the spatial function and time scale matching function used by the abstract syntax tree have been registered in the function table located in memory.

[0018] As a preferred embodiment of the first aspect, in step S22, the processing logic of the time scale matching function is to convert the two time variables into a numerical range respectively through a unified time axis index, and then use the segment tree data structure in the unified time axis index to determine whether the numerical ranges corresponding to the two time variables overlap: if they overlap, the time scale matching function returns a value of 1; if they do not overlap, the time scale matching function returns a value of 0.

[0019] As a preferred embodiment of the first aspect above, in step S3, the rules used by the volcano optimizer include: constant spatiotemporal filtering pruning rules, spatial connection matching rules, spatial connection mode selection rules, predicate pushdown optimization, and projection pushdown optimization rules.

[0020] The constant spatiotemporal filtering pruning rule first matches the logical filtering operators in the logical execution plan and extracts the constant spatial range and time conditions specified by the client. Then, using the unified time axis index and registry in S1, it aligns the time conditions with the time scale of the geoscience spatiotemporal dataset and filters out geoscience spatiotemporal datasets that cannot be aligned in time as the first dataset to be pruned. Next, it filters out geoscience spatiotemporal datasets whose spatial bounding boxes do not fall within the constant spatial range as the second dataset to be pruned. Finally, it rewrites the first and second datasets into an empty result set operator.

[0021] The spatial connection matching rule is used to convert a logical connection operator into a logical spatial connection operator when a logical connection operator with a connection condition of a spatial function is matched.

[0022] The spatial connection method selection rule first obtains the spatial bounding boxes of the Earth science spatiotemporal dataset corresponding to the child nodes on both sides of the logical spatial connection operator; when the spatial connection type of the two spatial bounding boxes is the intersection connection type, no pruning is performed, and the logical spatial connection operator is converted into a spatial connection physical execution operator; otherwise, pruning is performed.

[0023] As a preferred embodiment of the first aspect mentioned above, the specific execution process of step S4 is as follows:

[0024] S41. During the initial configuration phase of the Volcano Optimizer, the execution specification and transformation rules of the spatial distributed computing framework are registered to the Volcano Optimizer. The Volcano Optimizer replaces the target features of the physical execution plan with the execution specification of the spatial distributed computing framework, performs dynamic programming search on the transformation rules, and uses the transformation rules to convert the physical execution operators that perform projection operations, filtering operations, join operations, and aggregation operations into physical execution operators oriented towards the spatial distributed computing framework.

[0025] S42. In the physical execution phase, the plan tree composed of physical execution operators is traversed from bottom to top, and the code generation interface is called to translate the physical execution operators into code blocks executable by the spatial distributed computing framework; then the just-in-time compiler is called to compile the code blocks into class bytecode executable by the spatial distributed computing framework; then the class bytecode is sent to each execution node of the spatial distributed computing framework through a custom class dispatch server.

[0026] S43. After executing the bytecode loading class of the computing node and starting the query task, the data source adapter is first driven to load the data stream of the heterogeneous data source into the memory of the spatial distributed computing framework; for the spatial attribute column in the data stream, the spatial constructor provided by the spatial distributed computing framework is called to parse the geospatial data of different formats into lightweight geometric objects with a unified coordinate reference system, and generate a spatial distributed dataset containing geometric objects.

[0027] S44. Taking the spatially distributed dataset as input, a global spatial partitioning algorithm is used to repartition it to ensure that spatially adjacent features are distributed to the same execution node, thereby generating the partitioned spatially distributed dataset.

[0028] S45. The execution nodes of the spatial distributed computing framework execute spatial joins and other query logic in parallel based on spatial indexes and partition data to generate result sets. After the calculation is completed, the result sets of each execution node are aggregated and converted into an enumerator format that can be recognized by the client. Finally, the query results are returned to the client in a streaming manner through this enumerator format.

[0029] Secondly, the present invention provides a joint query system for multi-source heterogeneous distributed spatiotemporal data nodes, comprising:

[0030] The data acquisition module is used to acquire query requests uploaded by the client in the form of Structured Query Language;

[0031] The result acquisition module is used to take the data source that needs to be spatiotemporally queried as the target data source, and use the joint query method of multi-source heterogeneous distributed spatiotemporal data nodes described in any of the above-mentioned first aspect schemes to query the geoscience spatiotemporal data stream corresponding to the query request from the target data source, visualize the geoscience spatiotemporal data stream and return it to the client for rendering and display.

[0032] Thirdly, the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the joint query method for multi-source heterogeneous distributed spatiotemporal data nodes as described in any of the solutions of the first aspect above.

[0033] Fourthly, the present invention provides a computer electronic device, which includes a memory and a processor;

[0034] The memory is used to store computer programs;

[0035] The processor is configured to, when executing the computer program, implement the joint query method for multi-source heterogeneous distributed spatiotemporal data nodes as described in any of the solutions of the first aspect above.

[0036] Compared with the prior art, the present invention has the following advantages:

[0037] This invention discloses a joint query method and system for multi-source heterogeneous distributed spatiotemporal data nodes. Addressing the challenges of dispersed data storage, heterogeneous formats, and inconsistent timescale systems (such as the mixing of geological ages and standard times) in existing Earth science spatiotemporal data, which hinder unified spatiotemporal joint analysis, this invention constructs a data schema registration mechanism based on metadata standardization and a globally unified timeline index based on segment trees. Mapping relationships are established between all relevant timescales to support rapid conversion and matching of different timescales, thereby promoting spatiotemporal alignment of multi-source heterogeneous data. Simultaneously, by introducing custom constant spatiotemporal filtering and pruning rules, spatial connection matching rules, and spatial connection mode selection rules into the Volcano optimizer, optimizations are made for the spatiotemporal filtering conditions and spatial connection characteristics, respectively. A minimum-cost physical execution plan generation mechanism is designed to adaptively adjust the query path, thus constructing a more efficient query logic. Furthermore, considering the high performance requirements of large-scale spatiotemporal data processing, a combined execution method of dynamic code generation technology and a spatial distributed computing framework is adopted. This solves the problems of high computational resource consumption and low efficiency in querying massive amounts of Earth science spatiotemporal data, providing a high-performance and scalable solution for complex spatiotemporal analysis tasks in the Earth science field. Attached Figure Description

[0038] Figure 1 This is a schematic diagram of the steps of the present invention;

[0039] Figure 2 This is a schematic diagram illustrating the process of querying data from a data source as provided in this embodiment;

[0040] Figure 3 This is a comparison chart of query time for different connection strategies provided in this embodiment;

[0041] Figure 4 This is a system block diagram of the present invention;

[0042] Figure 5 This is a schematic diagram of the components of a computer electronic device according to the present invention. Detailed Implementation

[0043] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Many specific details are set forth in the following description to provide a thorough understanding of the present invention. However, the present invention can be practiced in many other ways different from those described herein, and those skilled in the art can make similar modifications without departing from the spirit of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below. Technical features in the various embodiments of the present invention can be combined accordingly without mutual conflict.

[0044] In the description of this invention, it should be understood that the terms "first" and "second" are used only for descriptive purposes and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined with "first" and "second" may explicitly or implicitly include at least one of those features.

[0045] like Figure 1 As shown, in a preferred embodiment of the present invention, the joint query method for multi-source heterogeneous distributed spatiotemporal data nodes includes the following steps S1 to S4. The specific implementation process of each step will be described in detail below.

[0046] S1. For the geoscience spatiotemporal dataset in the data source that requires spatiotemporal joint query, perform metadata standardization cataloging and register it as a data schema in a hash table maintained in computer memory. At the same time, maintain a unified time axis index globally in memory to be responsible for all time scale-related matching.

[0047] It should be noted that in step S1 of this invention, the metadata in the Earth Science Spatiotemporal Data Set is organized in accordance with the unified standard of the Spatiotemporal Asset Catalog Specification and saved in JSON format; the metadata includes the unique identifier ID of the Earth Science Spatiotemporal Data Set, text description, spatial range, time range, time scale, data storage type, storage identifier and data format.

[0048] In a preferred embodiment of this invention, metadata is extracted from geospatial-temporal datasets stored in different locations (such as relational databases, object storage, local file systems, network file servers, etc.) and in different formats (such as vector data Shapefile, GeoJSON, raster data GeoTIFF, NetCDF, time-series data CSV, etc.). This metadata is then organized according to a unified standard, conforming to the Spatio-Temporal Asset Catalog (STAC) specification, and saved in JSON format. This metadata includes core metadata such as the unique identifier ID of the geospatial-temporal dataset, text description, spatial extent, temporal extent, and time scale. Furthermore, to adapt to multi-source, heterogeneous geospatial-temporal data, multiple attribute fields are required, such as data storage type, geospatial-temporal dataset storage identifier, and other metadata such as data format.

[0049] This embodiment further utilizes a unified driver to read metadata-related dimensional information and register it as a data schema. The driver reads the metadata information of the Earth Science Spatiotemporal Data Set, identifies its data storage type, storage identifier, and data format, encapsulates it into a data schema object, and stores it in a hash table maintained in memory for subsequent use.

[0050] It should be noted that in S1 of this invention, the unified time axis index includes an extensible registry for converting different time scales in the geoscience spatiotemporal dataset into numerical intervals on the absolute time axis; when a geoscience spatiotemporal dataset is registered, its corresponding numerical interval is inserted into the segment tree as a node, and the unique identifier ID of all geoscience spatiotemporal datasets that completely cover the numerical interval is stored.

[0051] In a preferred embodiment of the present invention, to achieve unified querying of different time systems and independent indexing of different spatial dimensions, a hash table located in memory maintains a unified time axis index globally in memory during startup or metadata registration. This index is used for rapid matching between different time scales. Specifically, this embodiment defines a unified, continuous "absolute time axis," which is a pre-defined system that matches different geological time scales using a fixed benchmark, typically based on the International Stratigraphic Scale. A preferred implementation is to use the "International Stratigraphic Scale (December 2024 Edition)" as the standard for the absolute time axis. The aforementioned unified time axis index includes an extensible registry for converting different time scales (such as "Cretaceous," "85 Ma," "2024-01-01," etc.) in Earth science spatiotemporal datasets into numerical ranges on the absolute time axis. The system uses a segment tree data structure to maintain numerical ranges. Each node in the segment tree represents a numerical range on the absolute timeline and stores the unique identifier ID of all geospatial datasets that completely cover that range. The unified timeline index is built upon this "absolute timeline." When a geospatial dataset is registered, its corresponding numerical range is inserted into the segment tree. The unified timeline index is specifically designed for efficiently handling queries involving intersections and containment relationships of time ranges. Indicates the starting point of the time range of the Earth science spatiotemporal dataset. This indicates the end point of the time range for the Earth Science Spatiotemporal Data Set.

[0052] S2. Obtain the query request uploaded by the client in the form of Structured Query Language (SQL), parse and validate the query request, and add support for the parsing of spatial functions for time scale matching functions in the validation process, thereby generating a logical execution plan.

[0053] It should be noted that, in step S2 of this invention, the process of generating the logic execution plan is as follows:

[0054] S21. The SQL parser parses the query request into an abstract syntax tree, which is used for subsequent validation and logical execution plan generation.

[0055] In this embodiment S21, the SQL syntax parser uses the Apache Calcite parser based on Java CC. This selection of the parser is merely a preferred option; those skilled in the art can choose other parsers that match their specific needs, and therefore no restrictions are imposed.

[0056] S22. The SQL validator verifies the abstract syntax tree: if both the first and second verification conditions are met, the abstract syntax tree is transformed into a logical execution plan; otherwise, the query is terminated. The first verification condition is that the data pattern of the data source involved in the query has been registered in the hash table, and the second verification condition is that the spatial function and time scale matching function used by the abstract syntax tree have been registered in the function table located in memory.

[0057] In this embodiment, S22, the SQL validator verifies the compliance of the abstract syntax tree. This verification process includes checking whether the data schema of the data source involved in the query has been registered in a hash table in memory; and whether the spatial functions and time-scale matching functions used by the abstract syntax tree have been registered in a function table in memory. If neither of these verification criteria is met, or if one of these criteria is not met, the verification fails, and the query is terminated. If both verification criteria are met, the abstract syntax tree is considered to have passed the verification, and it is then converted into a logical execution plan. The method for converting the abstract syntax tree into a logical execution plan can be to use a semantic analyzer (such as the semantic analyzer in Apache Calcite) to traverse the abstract syntax tree, combine the metadata information registered in S1 to perform column name parsing and type deduction, and recursively map the SQL semantic nodes to the corresponding relational algebra operators, i.e., the logical execution plan. This process is common practice in the field and will not be elaborated further.

[0058] Furthermore, the concept of the spatial functions mentioned above refers to the spatial functions in the OpenGIS specification, such as ST_Intersects(geom1, geom2) / / spatial intersection function, and there are no restrictions on this.

[0059] Furthermore, the processing logic of the aforementioned timescale matching function is to convert each of the two time variables into a numerical range using a unified time axis index. Then, using the segment tree data structure within the unified time axis index, it determines whether the numerical ranges corresponding to the two time variables overlap: if they overlap, the timescale matching function returns 1; otherwise, it returns 0. For example, the aforementioned timescale matching function is T_OVERLAP(time_seg1, time_seg2), where time_seg1 and time_seg2 represent the two time variables, which can be a geological era name (e.g., 'Cretaceous'), a time value (e.g., '80 Ma'), or a standard date range, etc. In addition, spatial functions and timescale matching functions need to be predefined and registered in a function table in memory. This function table is a global registry located in computer memory, specifically used to store various predefined and declared functions. When the SQL validator examines the abstract syntax tree, it queries this table to confirm whether the functions used in the abstract syntax tree are syntactically correct and available; if the function used is not registered in the function table, the query request will be terminated.

[0060] Furthermore, the obtained logical execution plan is an intermediate representation independent of the specific data source implementation. Its core is a tree structure built upon relational algebra operators, consisting of various logical operators (RelNodes). The logical execution plan can be optimized by matching optimization rules. For example, as shown below, a SQL query request involving multiple data source spaces will be transformed into a logical execution plan presented as a logical operator tree:

[0061] # SQL raw query request

[0062] SELECT a.name

[0063] FRoM postgis.tableA a

[0064] JoIN geoison.tableB b

[0065] ON ST_Intersects(a.geom, b.geom)

[0066] WHERE a.id >= 10;

[0067] #Logical Execution Plan

[0068] LogicalProject(name=[a.name])

[0069] LogicalSpatialJoin(condition=ST_Intersectcs(a.geom, b.geom))

[0070] LogicalFilter(condition=a.id>=10)

[0071] LogicalTableScan(table=[postgis, tableA])

[0072] LogicalTableScan(table=[geojson, tableB])

[0073] S3. The Volcano Optimizer optimizes the logical execution plan using a variety of predefined rules and converts the logical execution plan into the least costly physical execution plan based on the geoscience spatiotemporal data type.

[0074] It should be noted that in S3 of this invention, firstly, constant spatiotemporal filtering pruning rules, spatial connection matching rules, spatial connection mode selection rules, and predicate pushdown optimization and projection pushdown optimization rules for different geospatial data need to be written. Among them, the constant spatiotemporal filtering pruning rules, spatial connection matching rules, and spatial connection mode selection rules are specially designed for this invention, while the predicate pushdown optimization and projection pushdown optimization rules directly adopt existing methods. These rules involved in this invention will be further introduced later. Secondly, these rules are applied to the Volcanno PLAnner. This optimizer applies the various rules defined above and iterates repeatedly using the idea of ​​top-down dynamic programming (memory search) to finally obtain a physical execution plan with minimum cost. Among them, the Volcano Optimizer is a classic cost-based database query optimization framework. It utilizes a scalable rule engine for logical and physical transformations and employs a top-down dynamic programming algorithm to efficiently find the physical execution plan with the lowest execution cost in the search space. The cost of the physical execution plan includes the number of rows of geospatial data to be processed, CPU computing resources consumed, memory consumption, and I / O operations. For example, the logical execution plan given above can ultimately be converted into a physical execution plan, as shown below:

[0075] #Physical Execution Plan

[0076] EnumerableProject(name=[$1])

[0077] EnumerableSpatialJoin(condition= ST_Intersectcs(a.geom, b.geom))

[0078] JdbcToEnumerableConverter

[0079] JdbcProject(id=[$0], name=[$1], geom=[$2])

[0080] JdbcFilter(condition=[>=($0, 10)])

[0081] JdbcTableScan(table=[postgis, tableA])

[0082] EnumerableProject(geom=[$1])

[0083] EnumerableTableScan(table=[geojson, tableB])

[0084] The physics execution plan is a tree composed of physics execution operators (i.e., the physics execution operator tree). During query execution, Earth science spatiotemporal data is retrieved starting from its root node. The root node requests Earth science spatiotemporal data from its child nodes, and this request is passed down the physics execution operator tree until it reaches the leaf nodes (i.e., the various types of TableScan physics execution operators). The physics execution operators in the leaf nodes are responsible for retrieving the Earth science spatiotemporal data and performing operations such as aggregation, joining, and filtering on the returned Earth science spatiotemporal data in memory, finally returning the final query result.

[0085] In this embodiment, considering that the predicate pushdown optimization rule and the projection pushdown optimization rule are existing technologies, only these two rules will be briefly described. The predicate pushdown optimization rule is a standard rule for database optimization, namely: when the input of a logical filter operator LogicalFilter is another logical join operator LogicalJoin (i.e., Join first, then Filter), the LogicalFilter is pushed down to before LogicalJoin (i.e., Filter first, then Join). Furthermore, the projection pushdown optimization rule is also a standard rule for database optimization, namely, when the logical projection operator LogicalProject is above the table scan operator LogicalTableScan, the columns that need to be projected are pushed down into the table scan operator, scanning only the necessary columns to reduce IO costs.

[0086] In addition to the two existing rules mentioned above, this invention also designs constant spatiotemporal filtering pruning rules, spatial connectivity matching rules, and spatial connectivity mode selection rules, as detailed below:

[0087] 1) The constant spatiotemporal filtering pruning rule first matches the logical filter operator LogicalFilter in the logical execution plan and extracts the constant spatial range (e.g., 'POLYGON(...)') and time condition (e.g., T_OVERLAP(t, 'Cretaceous')) specified by the client. Then, using the unified time axis index in S1 and the registry, the time condition is aligned with the time scale of the geoscience spatiotemporal dataset, and geoscience spatiotemporal datasets that cannot be aligned in time are filtered out as the first datasets that need to be pruned. Next, geoscience spatiotemporal datasets whose spatial bounding boxes do not fall within the constant spatial range are filtered out as the second datasets that need to be pruned. Finally, the first and second datasets are rewritten into an empty result set operator (EmptyResultSet).

[0088] In this embodiment, the constant spatiotemporal filtering pruning rule is executed early in the logical optimization phase of query optimization. Its core purpose is to significantly reduce the number of data sources participating in the query plan based on the filtering conditions in the WHERE clause. The specific execution steps are as shown above and will not be repeated here.

[0089] 2) The spatial connection matching rule is used to convert a logical connection operator into a logical spatial connection operator when a logical connection operator with a connection condition of a spatial function (such as ST_Intersects) is matched.

[0090] In this embodiment, the spatial join matching rule is executed during the physical optimization phase of query optimization. Its core purpose is to select the most efficient physical execution algorithm for the logical join operator. Its specific execution function is as shown above and will not be repeated here.

[0091] 3) The spatial connection method selection rule first obtains the spatial bounding boxes (bboxes) of the Earth science spatiotemporal dataset corresponding to the child nodes on both sides of the logical spatial connection operator (if there is filter pushdown, it is the spatial bounding box of the data after pushdown); when the spatial connection type of the two spatial bounding boxes is the intersection connection type (the "intersection" here includes the case where one spatial bounding box "contains" another spatial bounding box), no pruning is performed, and the logical spatial connection operator is converted into a spatial connection physical execution operator; otherwise, pruning is performed.

[0092] In this embodiment, the spatial join method selection rule is executed during the physical optimization phase of query optimization. Its core purpose is to select the most efficient physical execution algorithm for the logical spatial join operator. When the Volcano optimizer plans to this operator, it will take the above steps to optimize the physical execution plan. Specifically, the rule uses the spatial join type of two spatial bounding boxes for pruning judgment: if the two spatial bounding boxes do not intersect (i.e., IF NOT ST_Intersects(bbox1,bbox2) is calculated), the cardinality (i.e., the number of output rows) of this spatial join can be determined to be 0 (or close to 0), and pruning is performed; if the two spatial bounding boxes intersect, no pruning is performed, and the logical spatial join operator is converted into a spatial join physical execution operator. The spatial join physical execution operator can have multiple implementations, including spatial hash join, spatial index nested join, etc. Here, the optimizer will estimate the cost of each available spatial join physical execution operator and select the lowest one.

[0093] Furthermore, in this embodiment, the aforementioned logical filtering operator, logical projection operator, logical connection operator, and their corresponding physical execution operators, along with the table scan operator and empty result set operator, are common operators in the field and will not be elaborated further. The other two operators (logical spatial connection operator and spatial connection physical execution operator) are custom operators extended by this invention to address the characteristics of geospatial data in Earth sciences. Specifically, the logical spatial connection operator is used to identify spatial topological relationships (such as intersection, containment, etc.) between two geospatial datasets in the logical execution plan. It is derived from the logical connection operator through the aforementioned spatial connection matching rules and serves as the logical basis for subsequently selecting a specific physical execution algorithm. The spatial connection physical execution operator is a concrete implementation of the logical spatial connection operator at the physical execution layer. It encapsulates a spatial index-based connection algorithm or a spatial hash connection algorithm, enabling the acceleration of matching calculations for large-scale geometric elements by utilizing the spatial distribution characteristics of the data.

[0094] S4. A dynamic code generation method is used to convert the physical execution operators in the physical execution plan into executable code blocks for the spatial distributed computing framework. During the query execution process, the code blocks are compiled into executable class bytecode using a just-in-time compiler, and the class bytecode is distributed to the spatial distributed computing framework through a class distribution server. After receiving the class bytecode, the framework executes the physical execution plan in a distributed manner, aggregates the query results, and converts them into an enumerator format that the client can recognize. Finally, the query result data stream is formed and returned to the client.

[0095] It should be noted that in S4 of this invention, for data sources such as relational databases like PostGIS, the corresponding TableScan operator connects via JDBC (Java Database Connectivity) and converts the physical execution plan into a query statement, thus enabling the querying of corresponding geospatial data. For data sources supporting the STAC API service, the corresponding table scan operator converts the physical execution plan into a STAC API query. The querying of geospatial data can then be achieved through the STAC API service. For other data sources that do not support the STAC API, such as GeoJSON files, the corresponding TableScan operator can also achieve the querying of geospatial data by reading them into memory as a temporary in-memory table.

[0096] It should be noted that in S4 of this invention, for data sources such as relational databases like PostGIS, the corresponding table scan operator connects via JDBC (Java Database Connectivity) and converts its corresponding physical execution plan into a query Statement object, thus enabling the querying of corresponding geospatial data. For data sources supporting the STAC API service, the corresponding table scan operator converts its corresponding physical execution plan into a STAC API query. The querying of geospatial data can then be achieved through the STAC API service. For other data sources that do not support the STAC API, such as GeoJSON files, the corresponding table scan operator reads them into memory as a temporary in-memory table, which also enables the querying of geospatial data.

[0097] Furthermore, the above process describes the execution method of the leaf nodes (table scan operators) in the physical execution plan. This execution method is customizable; this embodiment only provides a reference for data querying methods. More suitable data querying methods can be implemented as needed based on different types of data sources. After a leaf node retrieves geospatial data, it converts the retrieved geospatial data into a unified memory structure, enabling upper-level leaf nodes (such as Filter, Join, and Project) to process the retrieved geospatial data in a unified manner. In memory, upper-level aggregation and processing are performed on the geospatial data obtained from various data sources. Non-leaf nodes in the physical execution operator tree are responsible for processing the geospatial data obtained from the leaf nodes in memory. This process is executed from bottom to top according to the structure of the physical execution operator tree.

[0098] In this embodiment, to improve the computational efficiency of the physical execution plan, the present invention introduces a spatial distributed computing framework at the physical execution layer, such as Apache Sedona. This framework implements a spatial distributed dataset (SpatialRDD) and a global spatial partitioning algorithm, enabling efficient distributed execution of spatiotemporal queries. The specific execution process of step S4 above is as follows:

[0099] S41. Registration of Transformation Rules and Transformation of Physical Execution Operators: During the initial configuration phase of the Volcano Optimizer, the execution convention and transformation rules of the spatial distributed computing framework are registered with the Volcano Optimizer. The Volcano Optimizer performs dynamic programming search on the transformation rules by replacing the target features of the physical execution plan with the execution convention of the spatial distributed computing framework, and uses the transformation rules to transform the physical execution operators that perform projection operations, filtering operations, join operations, and aggregation operations into physical execution operators oriented towards the spatial distributed computing framework.

[0100] In this embodiment S41, the execution specification of the spatial distributed computing framework refers to a set of protocols that define the data interaction standards and operator behavior patterns under the framework. Specifically, it requires that the input and output data structures of the physical execution operators participating in the computation must be adapted to the spatial distributed dataset, and that their computational logic must support parallel scheduling and execution on the distributed computing framework. The conversion rules of the spatial distributed computing framework refer to a set of mapping logic pre-registered in the optimizer, used to identify physical execution operators that meet specific conditions and convert them into physical execution operators specific to this framework. The target characteristics of the physical execution plan refer to the final state attribute constraints set by the Volcano optimizer during dynamic programming search. Specifically, it requires that the root node and its subordinate operators of the final output physical execution plan tree must conform to the execution specification of the spatial distributed computing framework, thereby ensuring that the generated plan can be distributed to the distributed computing framework for execution. The above-mentioned physical execution operators can convert operations such as projection, filtering, joining, and aggregation into corresponding execution code in the spatial distributed computing framework. The following describes each operation.

[0101] 1) Projection Operation: If the physical execution plan contains a projection operator (i.e., a physical projection operator, corresponding to a SELECT statement in SQL), this operator will extract or calculate the required columns from its sub-operators based on the projection list, and discard unnecessary columns. If the projection operator involves spatial function calculations (such as reprojection) or time scale transformation calculations, the corresponding functions need to be called for the calculations.

[0102] 2) Filtering operation: For filtering conditions that cannot be pushed down to the data source during the S3 optimization phase, such as complex calculations involving columns from multiple data sources, or filtering functions that the data source does not support (such as user-defined functions), the physical filtering operator will traverse the data in its child operators, apply the filtering predicate (corresponding to the WHERE condition in SQL) to each row, and only return the data rows that meet the predicate conditions, and pass them to the parent operator.

[0103] 3) Join operation: When the physical execution plan contains physical join operators (including physical non-space join operators and physical space join operators), the corresponding join calculation will be performed in memory.

[0104] In this embodiment, for non-spatial joins, a preferred implementation is an indexed nested-loop join. Since this implementation is well-known to those skilled in the art, it will only be briefly described below. For spatial joins, calculations are required based on the physical execution operator selected in S3.

[0105] A preferred implementation of indexed nested-loop join follows this process:

[0106] A) Construction phase: The physical connection operator first pulls all data from one of its child nodes (usually the dataset with lower cost in the S3 cost estimation, called the "construction side").

[0107] For non-spatial joins, such as equi-joins based on non-spatial fields, a preferred implementation is to use hash joins for computation. This involves constructing a hash table where the key is the join field. For spatial joins, it's first necessary to check if the spatial coordinate systems of the child nodes on both sides of the physical join operator are the same. Only two operators with the same spatial coordinate systems can be joined spatially. After this check, a spatial index, such as an R-tree, is dynamically constructed in memory for the "construction side" data.

[0108] B) Probe Phase: After the construction side is processed, the physical connection operator pulls data from another child node (called the probe side) row by row.

[0109] For non-spatial joins, for each data row retrieved from the "probe side," its join field is used as the key to query the in-memory hash table. Matching "build-probe" data row pairs are merged into a new data row, which is then passed to the parent operator as the result of the physical join operator. For spatial joins, for each data row retrieved from the "probe side," its spatial geometry object is used to query the spatial index for "build-side" row objects that meet the spatial join criteria. For example, for an "intersection" type spatial join, the spatial index needs to be queried to find all "build-side" spatial geometry objects that intersect with the "probe side," and all matching row pairs are merged into a new data row, which is then passed to the parent operator as the result of the physical join operator.

[0110] 4) Aggregation Operations: If the query contains aggregate functions such as GROUP BY, COUNT, and AVG, the physical plan will have a physical aggregation operator. This operator is usually located above the physical join operator or physical filter operator. This operator pulls all rows from its child nodes and maintains a grouped aggregation table (usually implemented as a hash table) in memory, where the keys are the columns of GROUP BY, and the values ​​are the accumulated state of the aggregate functions (such as the current count of COUNT, the current sum of SUM, and the current sum and count of AVG). For each input row, the corresponding "value" is found based on its GROUP BY column, and the aggregation state is updated. After all child node data has been processed, the physical aggregation operator traverses this grouped aggregation table, calculates the final aggregate value, and outputs it as the result set.

[0111] S42. Code Block Generation and Bytecode Distribution: During the physical execution phase, the plan tree composed of physical execution operators is traversed from bottom to top. The code generation interface is called to translate the physical execution operators into code blocks executable by the spatial distributed computing framework. Then, the just-in-time compiler is called to compile the code blocks into bytecode executable by the spatial distributed computing framework. After that, the bytecode is sent to each execution node (Executor) of the spatial distributed computing framework through a custom class distribution server to ensure that the custom query and computation logic can be correctly loaded and called in the distributed environment.

[0112] In this embodiment S42, the aforementioned just-in-time (JIT) compiler and class distribution server can be built based on existing technologies or existing technology frameworks. Specifically: a feasible example of a JIT compiler is to use the Janino embedded compiler. Janino is a lightweight, high-performance Java compiler that can directly compile dynamically generated code strings into Java bytecode in memory. A feasible example of a class distribution server is a class loading service built on the Netty network framework or the Jetty lightweight web server. This server runs as a standalone or embedded network service to store the compiled bytecode and respond to class loading requests from distributed computing nodes, transmitting the bytecode to each computing node via the network.

[0113] S43. Unified Spatial Objectification of Heterogeneous Data Sources: After the execution node loads the class bytecode and starts the query task, it first drives the data source adapter to load the data streams of heterogeneous data sources into the memory of the spatial distributed computing framework. For the spatial attribute columns in the data stream, it calls the spatial constructor provided by the spatial distributed computing framework to parse the geospatial data of different formats (such as WKT, WKB or GeoJSON) into lightweight geometric objects with a unified coordinate reference system, and generates a spatial distributed dataset containing geometric objects.

[0114] In this embodiment S43, the aforementioned data source adapter is a component independently developed by this invention based on data sources of different formats. By implementing a standard data access interface, it shields the underlying storage details and enables the reading of heterogeneous data streams. For example, for a RESTful API type data source, the query can be converted into a corresponding API request, and the query can be executed to obtain the data stream. The aforementioned spatial constructor is prior art. A feasible example is to use a constructor operator provided by a spatial distributed computing framework that conforms to the OpenGIS simple feature specification, such as ST_GeomFromWKT, ST_GeomFromWKB, or ST_GeomFromGeoJSON; its main function is to parse and instantiate raw spatial data in text or binary format into lightweight geometric objects in memory.

[0115] Furthermore, the aforementioned spatially distributed dataset will serve as the standard input object for subsequent distributed spatial computation, thus shielding the differences in underlying heterogeneous data sources.

[0116] S44. Distributed Spatial Index Construction and Partitioning Strategy: Taking the spatially distributed dataset as input, a global spatial partitioning algorithm (such as KDB-Tree or Quad-Tree) is used to repartition it to ensure that spatially adjacent features are distributed to the same execution node, thereby generating a partitioned spatially distributed dataset to minimize the data shuffle overhead across nodes in subsequent join calculations.

[0117] Furthermore, in the memory partition of each execution node in this embodiment S44, a local spatial index (such as an R-Tree or Quad-Tree) is constructed for the "build-side" data. This local index, combined with the global partitioning strategy, can significantly reduce the computational complexity of spatial intersection and inclusion queries in a distributed environment.

[0118] S45. Distributed Execution and Result Return: Based on spatial indexes and partition data, each execution node of the spatial distributed computing framework executes spatial joins and other query logic in parallel to generate a result set. After the calculation is completed, the result sets of each execution node are aggregated and converted into an enumerator format that can be recognized by the client. Finally, the query results are returned to the client in a streaming manner through this enumerator format.

[0119] In this embodiment, S44~S45 are operations in the existing spatial distributed computing framework, so their specific implementation process will not be described in detail.

[0120] To better demonstrate the specific implementation and technical effects of the present invention, the joint query method for multi-source heterogeneous distributed spatiotemporal data nodes shown in steps S1 to S4 of the above preferred implementation is applied to a specific example.

[0121] Example

[0122] The specific implementation process of the joint query method for multi-source heterogeneous distributed spatiotemporal data nodes used in this embodiment is as follows: Figure 2 As shown, no further details will be provided.

[0123] The data sources used in this embodiment are: PBDB paleontology database, which is open source data and is accessible via API (hereinafter referred to as API data source); and PostGIS, a spatial database storing and relating the distribution of global continental plates in different geological eras (hereinafter referred to as pg data source), with spatial attribute columns stored as polygons in WKB format, totaling 6129 records.

[0124] To demonstrate overall feasibility, this embodiment first conducted a spatiotemporal joint query verification, querying the spatial inclusion of tectonic plates and paleontological fossils within 50 Ma.

[0125] Using the same two data sources, an ablation experiment was conducted on the constant spatiotemporal filtering pruning rules in S3. The SQL remained the same, but the condition for T_OVERLAP was set to a geological era (e.g., Paleozoic) that exceeds the time range of the pg data source. Experiments were conducted with and without applying the constant spatiotemporal filtering pruning rules, and the results are shown in Table 1. As can be seen from the results in Table 1, the constant spatiotemporal filtering pruning rules can significantly accelerate query efficiency when users encounter time range mismatches due to erroneous input or broad queries, verifying the high efficiency of this method in multi-source heterogeneous environments.

[0126] Table 1. Query performance of the present invention with / without applying constant spatiotemporal filtering pruning rules.

[0127] Furthermore, experiments were conducted to test the time required for spatial join queries using the method of the present invention under different data volumes to verify the effectiveness of the invention. The results are as follows: Figure 3 As shown, by modifying the LIMIT statement in the API data source to limit the amount of data in the left table of the spatial join, the average query time of three spatial join implementations—EnumerableNestedLoopJoin, EnumerableSpatialJoin, and SparkSpatialJoin—was recorded. As the data volume increases, the average query time of the nested loop join without spatial indexes rises rapidly. When the data volume in the left table of the spatial join reaches 5000 rows, the nested loop join experiences a memory overflow error. In contrast, the spatial join operators EnumerableSpatialJoin based on memory spatial indexes and SparkSpatialJoin based on the distributed computing framework Spark show relatively stable performance. Furthermore, as the data scale increases, the performance advantage of the spatial join operator based on the distributed computing framework becomes increasingly apparent.

[0128] In summary, the ablation experiment results show that the joint query method proposed in this invention effectively solves the performance problem of joint queries of multi-source heterogeneous spatiotemporal data by introducing spatial index optimization, and proves the flexibility and robustness of this invention in handling tasks ranging from lightweight metadata queries to large-scale geological reconstruction.

[0129] It should also be noted that the joint query method for multi-source heterogeneous distributed spatiotemporal data nodes in the above embodiments can essentially be executed by a computer program or module. Therefore, similarly, based on the same inventive concept, another preferred embodiment of the present invention also provides a joint query system for multi-source heterogeneous distributed spatiotemporal data nodes corresponding to the joint query method for multi-source heterogeneous distributed spatiotemporal data nodes provided in the above embodiments, such as... Figure 4 As shown, it includes:

[0130] The data acquisition module is used to acquire query requests uploaded by the client in the form of Structured Query Language;

[0131] The result acquisition module is used to take the data source that needs to be queried in spatiotemporal joint query as the target data source, and use the joint query method of multi-source heterogeneous distributed spatiotemporal data nodes described in the above embodiments to query the geoscience spatiotemporal data stream corresponding to the query request from the target data source. After visualizing the geoscience spatiotemporal data stream, it is returned to the client for rendering and display.

[0132] It is understood that the joint query method for multi-source heterogeneous distributed spatiotemporal data nodes described in S1-S4 above can essentially be implemented by a computer program. Similarly, based on the same inventive concept, another preferred embodiment of the present invention also provides a computer electronic device corresponding to the joint query method for multi-source heterogeneous distributed spatiotemporal data nodes provided in the above embodiments, such as... Figure 5 As shown, it includes a memory and a processor;

[0133] The memory is used to store computer programs;

[0134] The processor is configured to implement the joint query method for multi-source heterogeneous distributed spatiotemporal data nodes in the above embodiments when executing the computer program.

[0135] Furthermore, the logical instructions in the aforementioned memory can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0136] Therefore, based on the same inventive concept, another preferred embodiment of the present invention also provides a computer-readable storage medium corresponding to the joint query method for multi-source heterogeneous distributed spatiotemporal data nodes provided in the above embodiments. The storage medium stores a computer program, which, when executed by a processor, can realize the joint query method for multi-source heterogeneous distributed spatiotemporal data nodes in the above embodiments.

[0137] It is understood that the aforementioned storage media may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Furthermore, the storage media may also be various media capable of storing program code, such as USB flash drives, external hard drives, magnetic disks, or optical discs.

[0138] It is understood that the processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0139] It should also be noted that those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the system described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here. In the embodiments provided in this application, the division of steps or modules in the system and method is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple modules or steps may be combined or integrated together, and a module or step may also be split.

[0140] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the invention. Those skilled in the art can make various changes and modifications without departing from the spirit and scope of the invention. Therefore, all technical solutions obtained through equivalent substitution or transformation fall within the protection scope of the present invention.

Claims

1. A joint query method for multi-source heterogeneous distributed spatiotemporal data nodes, characterized in that, Includes the following steps: S1. For the geoscience spatiotemporal dataset in the data source that requires spatiotemporal joint query, perform metadata standardization cataloging and register it as a data schema in a hash table maintained in computer memory. At the same time, maintain a unified time axis index globally in memory to be responsible for all time scale-related matching. S2. Obtain the query request uploaded by the client in the form of Structured Query Language, parse and validate the query request, and add support for parsing the spatial function for the time scale matching function in the validation process, thereby generating a logical execution plan; S3. The Volcano Optimizer optimizes the logical execution plan through a variety of predefined rules and converts the logical execution plan into the least costly physical execution plan based on the spatiotemporal data of Earth science. S4. The physical execution operators in the physical execution plan are converted into executable code blocks in the spatial distributed computing framework using dynamic code generation. During the query execution process, the code blocks are compiled into executable class bytecode using a just-in-time compiler, and the class bytecode is distributed to the spatial distributed computing framework through a class distribution server. After receiving the class bytecode, the framework executes the physical execution plan in a distributed manner, aggregates the query results, and converts them into an enumerator format that can be recognized by the client. Finally, the query result data stream is formed and returned to the client. The specific execution process of step S4 is as follows: S41. During the initial configuration phase of the Volcano Optimizer, the execution specification and transformation rules of the spatial distributed computing framework are registered to the Volcano Optimizer. The Volcano Optimizer replaces the target features of the physical execution plan with the execution specification of the spatial distributed computing framework, performs dynamic programming search on the transformation rules, and uses the transformation rules to convert the physical execution operators that perform projection operations, filtering operations, join operations, and aggregation operations into physical execution operators oriented towards the spatial distributed computing framework. S42. In the physical execution phase, the plan tree composed of physical execution operators is traversed from bottom to top, and the code generation interface is called to translate the physical execution operators into code blocks that can be executed by the spatial distributed computing framework. The code block is then compiled into executable bytecode for the spatial distributed computing framework using a just-in-time compiler. The bytecode is then sent to each execution node of the spatial distributed computing framework via a custom class dispatch server. S43. After executing the bytecode loading class of the computing node and starting the query task, the data source adapter is first driven to load the data stream of the heterogeneous data source into the memory of the spatial distributed computing framework; for the spatial attribute column in the data stream, the spatial constructor provided by the spatial distributed computing framework is called to parse the geospatial data of different formats into lightweight geometric objects with a unified coordinate reference system, and generate a spatial distributed dataset containing geometric objects. S44. Taking the spatially distributed dataset as input, a global spatial partitioning algorithm is used to repartition it to ensure that spatially adjacent features are distributed to the same execution node, thereby generating the partitioned spatially distributed dataset. S45. The execution nodes of the spatial distributed computing framework execute spatial joins and other query logic in parallel based on spatial indexes and partition data to generate result sets; After the calculation is completed, the result sets of each execution node are aggregated and converted into an enumerator format that can be recognized by the client; finally, the query results are returned to the client in a streaming manner through this enumerator format.

2. The joint query method for multi-source heterogeneous distributed spatiotemporal data nodes as described in claim 1, characterized in that, In step S1, the metadata in the Earth Science Spatiotemporal Dataset is organized in accordance with the unified standard of the Spatiotemporal Asset Catalog and saved in JSON format. The metadata includes the unique identifier ID of the Earth Science Spatiotemporal Dataset, text description, spatial extent, temporal extent, time scale, data storage type, storage identifier, and data format.

3. The joint query method for multi-source heterogeneous distributed spatiotemporal data nodes as described in claim 2, characterized in that, In step S1, the unified time axis index includes an extensible registry for converting different time scales in the geoscience spatiotemporal dataset into numerical intervals on the absolute time axis; when a geoscience spatiotemporal dataset is registered, its corresponding numerical interval is inserted into the segment tree as a node, and the unique identifier ID of all geoscience spatiotemporal datasets that completely cover the numerical interval is stored.

4. The joint query method for multi-source heterogeneous distributed spatiotemporal data nodes as described in claim 1, characterized in that, In step S2, the process of generating the logical execution plan is as follows: S21. The SQL parser parses the query request into an abstract syntax tree; S22. The SQL validator verifies the abstract syntax tree: if both the first and second verification conditions are met, the abstract syntax tree is transformed into a logical execution plan; otherwise, the query is terminated. The first verification condition is that the data pattern of the data source involved in the query has been registered in the hash table, and the second verification condition is that the spatial function and time scale matching function used by the abstract syntax tree have been registered in the function table located in memory.

5. The joint query method for multi-source heterogeneous distributed spatiotemporal data nodes as described in claim 4, characterized in that, In step S22, the processing logic of the time scale matching function is to convert the two time variables into a numerical range respectively through a unified time axis index, and then use the segment tree data structure in the unified time axis index to determine whether the numerical ranges corresponding to the two time variables overlap: if they overlap, the time scale matching function returns a value of 1; if they do not overlap, the time scale matching function returns a value of 0.

6. The joint query method for multi-source heterogeneous distributed spatiotemporal data nodes as described in claim 3, characterized in that, In step S3, the rules used by the volcano optimizer include: constant spatiotemporal filtering pruning rules, spatial connection matching rules, spatial connection mode selection rules, predicate pushdown optimization, and projection pushdown optimization rules; The constant spatiotemporal filtering pruning rule first matches the logical filtering operators in the logical execution plan and extracts the constant spatial range and time conditions specified by the client. Then, using the unified time axis index and registry in S1, it aligns the time conditions with the time scale of the geoscience spatiotemporal dataset and filters out geoscience spatiotemporal datasets that cannot be aligned in time as the first dataset to be pruned. Next, it filters out geoscience spatiotemporal datasets whose spatial bounding boxes do not fall within the constant spatial range as the second dataset to be pruned. Finally, it rewrites the first and second datasets into an empty result set operator. The spatial connection matching rule is used to convert a logical connection operator into a logical spatial connection operator when a logical connection operator with a connection condition of a spatial function is matched. The spatial connection method selection rule first obtains the spatial bounding boxes of the Earth science spatiotemporal dataset corresponding to the child nodes on both sides of the logical spatial connection operator; when the spatial connection type of the two spatial bounding boxes is the intersection connection type, no pruning is performed, and the logical spatial connection operator is converted into a spatial connection physical execution operator; otherwise, pruning is performed.

7. A joint query system for multi-source heterogeneous distributed spatiotemporal data nodes, characterized in that, include: The data acquisition module is used to acquire query requests uploaded by the client in the form of Structured Query Language; The result acquisition module is used to take the data source that needs to be spatiotemporally queried as the target data source, and use the joint query method of multi-source heterogeneous distributed spatiotemporal data nodes as described in any one of claims 1 to 6 to query the geoscience spatiotemporal data stream corresponding to the query request from the target data source, visualize the geoscience spatiotemporal data stream and return it to the client for rendering and display.

8. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the joint query method for multi-source heterogeneous distributed spatiotemporal data nodes as described in any one of claims 1 to 6.

9. A computer electronic device, characterized in that, Including memory and processor; The memory is used to store computer programs; The processor is configured to implement the joint query method for multi-source heterogeneous distributed spatiotemporal data nodes as described in any one of claims 1 to 6 when executing the computer program.

Images