Execution graph and data query method and system

Abstract

The invention provides an execution graph and data query method and system. The execution graph comprises one or more execution items, each execution item corresponds to an operator, the operators are obtained by disassembling operators defined by SQL specifications, and each execution item is executed by an FPGA logic unit in the FPGA; wherein the SQL query plan can be converted into at least one execution graph, the at least one execution graph is used for the FPGA to construct a query acceleration assembly line, and the query acceleration assembly line is composed of a plurality of FPGA logic units in sequence and used for the FPGA to query a query result corresponding to the SQL query plan. Therefore, when data query is carried out, the query acceleration assembly line can be constructed based on the execution graph, and data query is carried out based on the query acceleration assembly line, so that the query efficiency can be improved through the processing mode of the assembly line, meanwhile, the problem of data ping-pong can be reduced or avoided, and the query performance is improved.

Description

Technical Field

[0001] This application relates to the field of data processing technologies, and in particular, to an execution graph, a data query method, and a system. Background Art

[0002] With the advent of the big data era, online analytical processing (OLAP) queries for massive data have placed higher demands on computing power. At the same time, the rapid development of artificial intelligence (AI) has also led to an exponential growth in the data processing requirements of intelligent computing centers. When processing massive and complex data, higher requirements are put forward for the parallelism, low latency, and flexibility of data processing. In this context, field programmable gate arrays (FPGAs), with their highly parallel architectures, low latency characteristics, and customizable capabilities, have become an important acceleration means for data processing in intelligent computing centers. In related technologies, when performing data queries based on FPGAs, the central processing unit (CPU) usually identifies operators that conform to a preset query pattern from structured query language (SQL) query statements and places them on the FPGA for query acceleration. However, this query method has low query efficiency and also has a "data ping-pong" problem (the execution result of the previous sub-query needs to be first transmitted from the FPGA back to the CPU when it exceeds the FPGA cache, and then passed from the CPU to the FPGA as a parameter when executing the next sub-query), reducing the query performance. Summary of the Invention

[0003] This application provides an execution graph, a data query method, and a system, which are used to solve the problem of low query performance in related technologies when performing data queries based on FPGAs.

[0004] To solve the above technical problems, this application is implemented as follows: In a first aspect, an execution graph is provided, including one or more execution items, each execution item corresponding to an operator disassembled from the operators defined in the structured query language SQL specification, and each execution item is executed by an FPGA logic unit in a field programmable gate array (FPGA); wherein, the SQL query plan can be transformed into at least one of the execution graphs, and the at least one execution graph is used for the FPGA to construct a query acceleration pipeline, and the query acceleration pipeline is composed of multiple FPGA logic units in sequence and is used for the FPGA to query the query result corresponding to the SQL query plan.

[0005] In a second aspect, there is provided a data query method based on the execution described in the first aspect, including: Receiving an SQL query plan; Converting the SQL query plan into at least one execution graph; Constructing an acceleration task according to the at least one execution graph and the input data tables involved in the SQL query plan; Triggering the FPGA to execute the acceleration task.

[0006] In a third aspect, there is provided a data query method based on the execution described in the first aspect, including: Obtaining an acceleration task to be processed; Constructing a query acceleration pipeline according to the acceleration task; Performing data query according to the query acceleration pipeline.

[0007] In a fourth aspect, there is provided a data query system based on the execution described in the first aspect, including: A CPU, which receives an SQL query plan, converts the SQL query plan into at least one execution graph, constructs an acceleration task according to the at least one execution graph and the input data tables involved in the SQL query plan, and triggers the FPGA to execute the acceleration task; The FPGA, which obtains an acceleration task to be processed, constructs a query acceleration pipeline according to the acceleration task, and performs data query according to the query acceleration pipeline.

[0008] In a fifth aspect, there is provided an electronic device, including: A processor; A memory for storing executable instructions of the processor; Wherein, the processor is configured to execute the instructions to implement the method described in the second aspect or the third aspect.

[0009] In a sixth aspect, there is provided a computer-readable storage medium, when the instructions in the storage medium are executed by a processor of an electronic device, enabling the electronic device to execute the method described in the second aspect or the third aspect.

[0010] In a seventh aspect, there is provided a computer program product, the computer program product includes a non-transitory computer-readable storage medium storing a computer program, and the computer program is operable to cause a computer to execute some or all of the steps in the method described in the second aspect, or execute some or all of the steps in the method described in the third aspect.

[0011] In the embodiments of the present application, when performing data query based on FPGA, the SQL query plan can be converted into at least one execution graph. The execution graph includes one or more execution items, each execution item corresponds to an operator and is executed by an FPGA logic unit. The at least one execution graph is used for the FPGA to construct a query acceleration pipeline, which is composed of multiple FPGA logic units in sequence and can be used for the FPGA to query the query result corresponding to the SQL query plan. In this way, since the query acceleration pipeline can be constructed based on the execution graph and data query can be performed based on the query acceleration pipeline when performing data query, the query efficiency can be accelerated by the pipeline processing method, and at the same time, the "data ping-pong" problem can be reduced or avoided, thereby improving the query performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the technical solutions in the present application or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments recorded in the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0013] Figure 1 is a schematic diagram of a heterogeneous acceleration method for data query based on FPGA in the related art; Figure 2 is a schematic diagram of an execution graph in an embodiment of the present application; Figure 3 is a schematic diagram of an execution graph in an embodiment of the present application; Figure 4 is a schematic flowchart of a data query method in an embodiment of the present application; Figure 5 is a schematic flowchart of a data query method in an embodiment of the present application; [[ID=E22]] Figure 6 is a schematic structural diagram of a data query system in an embodiment of the present application; Figure 7 is a schematic diagram of a data query system in an embodiment of the present application; Figure 8 is a schematic structural diagram of an acceleration task in an embodiment of the present application; Figure 9 is a schematic diagram of data caching performed on the FPGA side in an embodiment of the present application; Figure 10 is a schematic flowchart of data query performed on the CPU side in an embodiment of the present application; Figure 11 is a schematic flowchart of data query performed on the FPGA side in an embodiment of the present application; Figure 12 It is a schematic diagram of data reading in an embodiment of the present application; Figure 13 It is a schematic diagram of the structure of an electronic device in an embodiment of the present application; Figure 14 It is a schematic diagram of the structure of a data query device in an embodiment of the present application; Figure 15 It is a schematic diagram of the structure of a data query device in an embodiment of the present application. Detailed implementation manners

[0014] With the advent of the big data era, OLAP queries for massive data pose higher requirements for computing power. However, with the failure of "Moore's Law", purely relying on CPU computing is difficult to provide matching economic computing power. Therefore, data query heterogeneous acceleration based on Graphics Processing Unit (GPU) and / or FPGA has been proposed. In addition, the rapid development of AI has also led to an exponential growth in the data processing requirements of intelligent computing centers. Traditional computing architectures face performance bottlenecks when processing massive and complex data. Intelligent computing centers need to efficiently process large-scale data sets, support tasks such as real-time data analysis, deep learning training, and inference, which pose higher requirements for the parallelism, low latency, and flexibility of data processing. FPGA, with its highly parallel architecture, low latency characteristics, and customizable capabilities, has become an important acceleration means for data processing in intelligent computing centers. Therefore, developing an efficient, flexible, and easily integrable FPGA-accelerated data processing technology is of great significance for improving the overall performance and energy efficiency of intelligent computing centers.

[0015] In the related art, when performing data queries based on FPGA, data queries are implemented by combining with CPU. Please refer to Figure 1 . Figure 1 It is a schematic diagram of a data query heterogeneous acceleration method based on FPGA in the related art. When performing data queries, the specific implementation process is as follows: (1) Query pattern recognition: Identify common query patterns from common query SQL statements.

[0016] (2) Operator decomposition: Decompose independent query operators (such as Scan, Join, and Agg) or operator combinations from the above query patterns.

[0017] (3) Operator solidification: Implement the functions of the decomposed operators and solidify them in the FPGA logic.

[0018] (4) Query accelerated execution: When a query request occurs, the CPU side identifies the operators that match the preset query pattern from the SQL query statement and places them on the FPGA for query acceleration execution.

[0019] However, due to the operator hardening, a query plan tree (generated according to the SQL query statement) will be disassembled into multiple relatively independent subqueries. When the execution result of the previous subquery exceeds the FPGA cache, it needs to be transferred from the FPGA back to the CPU first, and then passed from the CPU to the FPGA as a parameter when executing the next subquery, resulting in the "data ping-pong" problem, which reduces the query efficiency and performance. In addition, due to the limited internal resources of the FPGA, it is impossible to harden independent acceleration modules for each operator or operator combination ( Figure 1 the logical block shown), and it can only support the acceleration of some operators or operator combinations. That is to say, it can only accelerate the pre-set query patterns or SQL query statements, and other queries cannot be accelerated. This will result in low FPGA utilization rate, and further reduce the query efficiency. On the other hand, the usage frequencies of different operators are not the same, and the hardened operators with low usage frequencies will also lead to low FPGA utilization rate, and further reduce the query efficiency.

[0020] It can be seen that in the related technology, when performing data query based on the FPGA, the query efficiency is low, there is the "data ping-pong" problem, and the query performance is reduced.

[0021] The present application provides an execution graph, a data query method and system. When performing data query based on the FPGA, the SQL query plan can be converted into at least one execution graph. The execution graph includes one or more execution items, and each execution item corresponds to an operator and is executed by an FPGA logic unit. The at least one execution graph is used for the FPGA to construct a query acceleration pipeline. The query acceleration pipeline is composed of multiple FPGA logic units in sequence and can be used for the FPGA to query the query result corresponding to the SQL query plan. In this way, since the query acceleration pipeline can be constructed based on the execution graph and data query can be performed based on the query acceleration pipeline when performing data query, the query efficiency can be accelerated by the pipeline processing method, and at the same time, the "data ping-pong" problem can be reduced or avoided, thereby improving the query performance.

[0022] Furthermore, when performing data query on the FPGA side of the present application, the input data required for the query can be accessed from the CPU side as needed, rather than reading all the table data from the CPU side to the FPGA side, which can avoid the transmission of redundant data and improve the data transmission efficiency.

[0023] Furthermore, the present application can also use cache to cache the intermediate result data on the FPGA side. Combining with the pipeline processing method, the "data ping-pong" problem can be further solved, and the heterogeneous acceleration performance can be improved.

[0024] Furthermore, the FPGA logic unit in the present application is a reloadable logic unit, which can solve the problem of limited FPGA resources caused by operator solidification in the related art, thereby improving the utilization rate of the FPGA. On this basis, the query efficiency can be further improved.

[0025] The technical solution provided by the present application can be applied to a stand-alone database or a distributed database (and / or big data) system equipped with an FPGA board.

[0026] In order to enable those skilled in the art to better understand the technical solution in the present application, the technical solution in the present application will be clearly and completely described below in conjunction with the drawings in one or more embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0027] The terms "first", "second", etc. in the present application and the claims are used to distinguish similar objects, rather than to describe a specific order or sequence. It should be understood that such data can be interchanged under appropriate circumstances so that the present application can be implemented in an order other than those illustrated or described herein. In addition, "and / or" in the present application and the claims means at least one of the connected objects, and the character " / " generally means that the associated objects before and after are in an "or" relationship.

[0028] The following details the technical solutions provided by the embodiments of the present application in conjunction with the drawings.

[0029] Figure 2 It is a schematic diagram of an execution graph of an embodiment of the present application.

[0030] Figure 2 An execution graph shown includes multiple execution items (or, alternatively, may include one execution item, Figure 2For example, taking an execution graph including multiple execution items as an example, they are execution item 1, execution item 2, … execution item N (N is a positive integer greater than 1). Each execution item corresponds to an operator. Here, the correspondence means that an execution item can be used to implement the operation or function of the operator it corresponds to. The operator is disassembled from the operators defined in the SQL specification. For example, it can be addition, subtraction, multiplication, division, greater than, less than, etc. Each execution item can be executed by an FPGA logic unit in the FPGA, that is, the function of each execution item can be implemented by an FPGA logic unit in the FPGA. Among them, the FPGA includes multiple FPGA logic units. The FPGA logic unit can specifically be a Logic Processing Unit (LPE), and the LPE is the smallest functional unit in the FPGA.

[0031] Based on the execution graph in the embodiments of the present application, when performing data query based on the FPGA, the SQL query plan can be converted into at least one execution graph, and the at least one execution graph can be used for the FPGA to construct a query acceleration pipeline. The query acceleration pipeline is composed of multiple FPGA logic units in sequence (since each FPGA logic unit can be used to execute an execution item, therefore, it can also be that the query acceleration pipeline is composed of multiple execution items in sequence). The query acceleration pipeline can be used for the FPGA to query the query result corresponding to the SQL query plan.

[0032] In this way, since when performing data query, a query acceleration pipeline can be constructed based on the execution graph and data query can be performed based on the query acceleration pipeline, the query efficiency can be accelerated through the pipeline processing method, and at the same time, the "data ping-pong" problem can be reduced or avoided, thereby improving the query performance.

[0033] In the embodiments of the present application, each execution item in the execution graph can include multiple fields. The multiple fields are used to describe the relevant information of the execution item, and can be used for the CPU side to convert the SQL query plan into at least one execution graph, and can also be used for the FPGA side to construct a query acceleration pipeline.

[0034] In some embodiments, each execution item can include the following fields (1) to (7): (1) Type, used to indicate whether this execution item is executed together with the next execution item.

[0035] The next execution item can be the next execution item adjacent to this execution item to be loaded when this execution item is loaded during data query.

[0036] If the type field in the execution item is used to indicate that this execution item is not to be executed together with the next execution item, after this execution item is loaded, this execution item can be executed without continuing to load the next execution item for joint execution. If the type field in the execution item is used to indicate that this execution item is to be executed together with the next execution item, after this execution item is loaded, it is necessary to continue loading the next execution item and execute it together with the next execution item.

[0037] In some embodiments, the length of the type field can be a specified length. For example, it can be 8 bits.

[0038] In some embodiments, the values of the type field can include a first preset type value and a second preset type value. When the value of the type field is the first preset type value, the type field is used to indicate that this execution item is to be executed together with the next execution item. When the value of the type field is the second preset type value, the type field is used to indicate that this execution item is not to be executed together with the next execution item. For example, the length of the type field is 8 bits, the upper 6 bits are reserved, and the value of 0b01 (the second preset type value) means that this execution item is executed after being loaded, that is, this execution item is not executed together with the next execution item. The value of 0b10 (the first preset type value) means that this execution item is not executed after being loaded, and the next execution item needs to be loaded, that is, this execution item is executed together with the next execution item.

[0039] (2) The opcode, which is used to indicate the operator corresponding to the execution item (that is, it is used to indicate what kind of operator and operation this execution item is used for).

[0040] As described above, the operator is disassembled from the operators defined in the SQL specification. In some embodiments, the operator can include at least one of the following types: Filter operator; Hash Build operator; Hash Probe operator; Hash Groupby operator; Calc operator; Agg operator; Project operator; Merge operator.

[0041] Each type of operator can include multiple operators. For example, the Filter operator can include greater than, equal to, less than, greater than or equal to, less than or equal to, not equal to, logical AND, logical OR, etc. The Calc operator can include addition, subtraction, multiplication, division, etc. The Agg operator can include max(), min(), sum(), avg(), count(*) / count(any), etc. Examples are not given one by one here.

[0042] In some embodiments, the length of the opcode field can be a specified length. For example, it can be 16 bits.

[0043] In some embodiments, different operators may correspond to different operation codes. Optionally, the correspondence between the operation codes and the operators may be as shown in Table 1 (Table 1 is only for illustrative purposes and can be adjusted as needed).

[0044] Table 1

[0045] (3) Unit ID, which is used to indicate the FPGA logic unit that executes this execution item.

[0046] The FPGA includes multiple FPGA logic units. To distinguish different FPGA logic units, different unit IDs can be used to identify different FPGA logic units. By setting the unit ID field in the execution item, the FPGA logic unit used to execute this execution item can be indicated. Among them, different execution items may correspond to different unit IDs, that is, different execution items can be executed by different FPGA logic units.

[0047] In some embodiments, the length of the unit ID may be a specified length, such as 8 bits.

[0048] In some embodiments, according to the type of the operator corresponding to the execution item, the FPGA logic units in the FPGA can be divided into multiple groups. The multiple groups of FPGA logic units correspond to multiple unit ID ranges. Different types of operators correspond to different unit ID ranges. Each unit ID range corresponds to multiple FPGA logic units (or can also correspond to one FPGA logic unit). The multiple FPGA logic units are used to execute the execution items corresponding to one type of operator.

[0049] Optionally, considering that in practical applications, the usage frequencies of different types of operators are different. The higher the usage frequency, the more FPGA logic units are required for data query, and the lower the usage frequency, the fewer FPGA logic units are required for data query. Therefore, in order to meet the usage requirements of different types of operators for FPGA logic units and improve the resource utilization rate and query efficiency of FPGAs, when partitioning the FPGA logic units in an FPGA, the partitioning can be performed according to the usage frequencies of different types of operators (the usage frequencies can be obtained by counting the actual usage of different types of operators). Specifically, for operators with a higher usage frequency, more FPGA logic units can be partitioned for them, and for operators with a lower usage frequency, fewer FPGA logic units can be partitioned for them. Thus, different numbers of FPGA logic units can be partitioned for operators with different usage frequencies, corresponding to obtaining multiple different unit ID ranges. Among them, for any unit ID range, the number of FPGA logic units corresponding to the unit ID range is related to the usage frequency of the operator corresponding to the unit ID range. The higher the usage frequency of the corresponding operator, the more FPGA logic units corresponding to the unit ID range.

[0050] Optionally, when partitioning the FPGA logic units in an FPGA, only some of the FPGA logic units can be partitioned, and the remaining FPGA logic units serve as spare FPGA logic units. In this way, during data query, when there are not enough FPGA logic units within the unit ID range corresponding to a certain type of operator to execute the corresponding execution item, idle FPGA logic units can be selected from the spare FPGA logic units to execute the execution item, ensuring that the execution item can be smoothly executed by the FPGA logic units.

[0051] Optionally, to improve the flexibility of using FPGA logic units and thus improve the resource utilization rate of FPGAs, the FPGA logic units can be set as reloadable logic units, that is, the same FPGA logic unit can implement the functions of different operators at different times. For example, after partitioning the FPGA logic units in an FPGA, a certain FPGA logic unit is partitioned to execute the execution item corresponding to the Filter operator. Then, during subsequent data query, if this FPGA logic unit is not used and the FPGA logic units corresponding to other types of operators are insufficient, this FPGA logic unit can be reloaded to implement the functions of other types of operators.

[0052] In some embodiments, the correspondence between the operator type and the unit ID range can be as shown in Table 2 (Table 2 is only for illustrative purposes and can be adjusted as needed).

[0053] Table 2

[0054] As can be seen from Table 2, different types of operators correspond to different ranges of unit IDs, and each range of unit IDs corresponds to the same or different numbers of FPGA logic units. Among them, for operators with higher usage frequencies, more FPGA logic units can be allocated to them, and for operators with lower usage frequencies, fewer FPGA logic units can be allocated to them. For example, the usage frequency of the Filter type operator is higher than that of the Groupby type operator, and the number of FPGA logic units allocated to the Filter type operator in Table 2 (16, that is, the number of FPGA logic units corresponding to 0x80~0x8F) is more than the number of FPGA logic units allocated to the Groupby type operator (8, that is, the number of FPGA logic units corresponding to 0xB8~0xBF). In addition, the FPGA also includes unallocated spare FPGA logic units, such as the FPGA logic units with unit IDs from 0xB0 to 0xB7. These FPGA logic units are not allocated to any type of operator and can be used as spare FPGA logic units during data query. Of course, the already allocated FPGA logic units in Table 2 can also be overloaded with the functions of other types of operators. For example, for the FPGA logic unit with unit ID 0x8F, during data query, if this FPGA logic unit is not used and the FPGA logic units corresponding to the Merge type operator are insufficient, it can be overloaded with the functions of the Merge type operator to improve the resource utilization rate of the FPGA and thus improve the query performance.

[0055] (4) Destination ID, which is used to indicate the FPGA logic unit or address into which the execution result of this execution item flows.

[0056] If the execution result of the execution item is used as the input of the next execution item, this destination ID can be the ID of the FPGA logic unit used to execute the next execution item. For specific explanations, please refer to the above explanations of the unit ID, which will not be repeated here. If the execution result of the execution item needs to be cached as an intermediate result, this destination ID can be the address of the cache location. For example, if it needs to be cached in the cache of the FPGA, the destination ID can be the address in this cache.

[0057] In some embodiments, there is a corresponding relationship between the type of the FPGA logic unit or address into which the execution result of the execution item flows and the value / value range of the destination ID. This corresponding relationship can be as shown in Table 3 (Table 3 is only for illustrative purposes and can be adjusted as needed).

[0058] Table 3

[0059] (5) Output column number, which is used to indicate the column serial number of the execution result of this execution item in the result data table, and the result data table is used to store the query result corresponding to the SQL query plan.

[0060] In some embodiments, the column serial number of the execution result of the execution item in the result data table can start from 0, that is, the output column number can be numbered starting from 0.

[0061] Optionally, if the execution result of this execution item is not output as a column in the result data table, the output column number can be a preset value. For example, it can be 0x00.

[0062] (6) Source location, which is used to indicate the source of the parameters (or input data) required when executing this execution item.

[0063] In some embodiments, the length of the source location field can be a specified length, such as 8bit.

[0064] In some embodiments, the sources indicated by the source location may include at least one of the following: Input data table; constant; FPGA logic unit.

[0065] The input data table is the data table involved in the SQL query plan, and is usually given in the SQL query plan. Optionally, the input data table may include a host table or an in-card table. Among them, when the parameter source is the input data table, it means that the parameter is the data in the input data table. When the parameter source is a constant, it means that the parameter is a constant. When the parameter source is the FPGA logic unit, it means that the parameter is the execution result of the execution item executed by the FPGA logic unit. [[ID=2"4]]

[0066] Different parameter sources can correspond to different source location values. For example, when the parameter source is the input data table, the source location value can be the first preset location value. When the parameter source is a constant, the source location value can be the second preset location value. When the parameter source is the FPGA logic unit, the source location value can be the ID of the FPGA logic unit.

[0067] The number of source location fields can be one or more. When there is one source of the parameters required when executing this execution item, the number of source location fields is 1. When there are multiple sources of the parameters required when executing this execution item, the number of source location fields is multiple. One source location is used to indicate one parameter source, and different source locations are used to indicate different parameter sources.

[0068] (7) Data, which is used to indicate the value of the parameter required when executing this execution item or the column serial number of the parameter in the input data table, and the input data table is the data table involved in the SQL query plan.

[0069] In some embodiments, the length of the data field can be a specified length, such as 64 bit, or it can be extended as needed, and specific limitations are not made here.

[0070] The number of data fields can be one or more, and specifically can be the same as the number of source location fields. Among them, when the number of both the source location field and the data field is one, the one data field is used to indicate one parameter required for executing this execution item, and the one source location field is used to indicate the source of the one parameter. When the number of both the source location field and the data field is multiple, the multiple data fields are used to indicate multiple parameters required for executing this execution item, and the multiple source location fields are used to indicate the sources of the multiple parameters. For example, the number of both the source location field and the data field is 2, which are respectively represented as source location 1, source location 2, data 1, and data 2. Data 1 is used to indicate parameter 1 required when executing this execution item, data 2 is used to indicate parameter 2 required when executing this execution item, source location 1 is used to indicate the source of parameter 1, and source location 2 is used to indicate the source of parameter 2.

[0071] In some embodiments, the value taken by the data field (hereinafter may be expressed as the data value) is related to the parameter source. For example, when the parameter source is the input data table, the data value can be the column serial number starting from 0. When the parameter source is the FPGA logic unit, the data value can be the first preset data value. When the parameter source is a constant, the data value can be the value of the constant.

[0072] It should be noted that for the above fields (1) to (7), in some possible embodiments, the execution item may include some of these 7 fields. For example, the execution item may include the above fields (2) to (7) and does not include field (1), that is, does not include the type field. In this case, it can be defaulted that this execution item is executed together with the next execution item or not executed together with the next execution item.

[0073] Optionally, in some embodiments, the execution item may further include a padding area. The padding area is an invalid data area used to maintain byte alignment. In practical applications, when the execution item satisfies byte alignment, the padding area may not be included. When it does not satisfy byte alignment, the padding area needs to be included. Among them, to maintain byte alignment, the padding area can be long or short, and specifically can be determined according to the actual situation, and specific limitations are not made here.

[0074] To facilitate understanding of the execution graph provided by the embodiments of the present application, the following will use Figure 3Take the execution graph shown as an example for illustration.

[0075] Figure 3 The execution graph shown includes multiple execution items. Taking one of the execution items as an example, the fields in this execution item include type, opcode, unit ID, destination ID, output column number, source location 1, source location 2, data 1, data 2, and padding area. The uses and descriptions of each field are shown in Table 4.

[0076] Table 4 Execution Graph Specification Table

[0077] Based on the execution graph provided by the embodiments of the present application, when performing data query, the CPU side can convert the SQL query plan into at least one execution graph, and the FPGA side can construct a query acceleration pipeline according to the at least one execution graph and perform data query according to the query acceleration pipeline. In this way, the query efficiency can be accelerated through the pipeline processing method, and at the same time, the "data ping-pong" problem can be reduced or avoided, thereby improving the query performance.

[0078] Figure 4 It is a schematic flowchart of the data query method according to an embodiment of the present application. Figure 4 The data query method shown is implemented based on the execution graph provided by the embodiments of the present application. This data query method can be applied to the CPU side, that is Figure 4 The data query method shown can be executed by the CPU side. For example, it can be executed by software or hardware installed on the CPU side. Figure 4 The data query method shown includes the following steps.

[0079] Step S402: Receive the SQL query plan.

[0080] The SQL query plan is generated according to the SQL query statement. In some embodiments, the database (and / or big data) system can run on the CPU side. When the database (and / or big data) system receives a SQL query request, it can parse the SQL query request and generate a SQL query plan. When the CPU side receives the SQL query plan, it can obtain the SQL query plan from the database (and / or big data) system.

[0081] Step S404: Convert the SQL query plan into at least one execution graph.

[0082] In the case of receiving the SQL query plan, the SQL query plan can be converted into at least one execution graph according to the relevant specifications of the execution graph provided by the embodiments of the present application.

[0083] In some embodiments, converting the SQL query plan into at least one execution graph may include: Decompose the operators involved in the SQL query plan into at least one operator; For each operator, convert the operator into an execution item according to the description of the execution item in the execution graph; Generate at least one execution graph according to the execution items obtained by converting at least one operator.

[0084] The SQL query plan usually gives the operators involved in data query. When converting the SQL query plan into an execution graph, these operators can be first decomposed into operators to obtain at least one operator. For each operator, the operator can be converted into an execution item according to the description of the execution item in the execution graph. Each operator can be correspondingly converted into one execution item, and at least one operator can be correspondingly converted into at least one execution item. At least one execution graph can be generated according to the at least one execution item, and one execution graph includes one or more execution items. In this way, according to the specification of the execution graph, the SQL query plan can ultimately be converted into at least one execution graph.

[0085] Based on Figure 2 As can be seen from the embodiments shown, the execution item includes fields such as type, opcode, unit ID, destination ID, output column number, source location, and data. When converting the operator into an execution item according to the description of the execution item in the execution graph, the values of each field can be determined according to the description of each field in the execution item, so that the operator can be converted into an execution item. Specifically, it can include the following steps S1 to S6: Step S1: Determine the type value in the execution item according to whether the execution item is executed together with the next execution item.

[0086] Whether the execution item is executed together with the next execution item is related to the operator or the type of the operator corresponding to the execution item. For example, if the operator is a Filter type operator, the execution item corresponding to the operator can be executed together with the next execution item. If the operator is a Project type operation and the current projection column is at a multiple of 16, the execution item corresponding to the operator can be executed immediately and not together with the next execution item.

[0087] In some embodiments, when determining the type value in the execution item according to whether the execution item is executed together with the next execution item, it can include: In the case where the execution item is executed together with the next execution item, determine that the type value in the execution item is the first preset type value; In the case where the execution item is not executed together with the next execution item, determine that the type value in the execution item is the second preset type value.

[0088] For example, the first preset type value can be 0x01 and the second preset type value can be 0x02. Or, the first preset type value can be 0x02 and the second preset type value can be 0x01.

[0089] Step S2: Determine the opcode value in the execution item according to the operator.

[0090] Different operators can correspond to different opcode values.

[0091] In some embodiments, the corresponding relationship between different operators and different opcode values (hereinafter referred to as the first corresponding relationship for the convenience of distinguishing from other corresponding relationships) can be preset. When determining the opcode value according to the operator, it can be determined according to the first corresponding relationship. Specifically, it can include: Obtain the first corresponding relationship between different operators and different opcode values determined in advance; According to the first corresponding relationship, determine the opcode value corresponding to the operator as the opcode value in the execution item.

[0092] The first corresponding relationship can be as shown in Table 1 above. When determining the opcode value according to the operator, the opcode value corresponding to the operator can be found in the first corresponding relationship, and this opcode value is the opcode value in the execution item corresponding to the operator. For example, taking Table 1 as an example, assuming the operator is "greater than" among the Filter type operators, the opcode value in the execution item corresponding to this operator is 0x0101.

[0093] Step S3: Use the ID of an unoccupied FPGA logic unit as the unit ID value in the execution item.

[0094] The unit ID in the execution item is the ID of the FPGA logic unit used to execute this execution item. When determining the unit ID value in the execution item, an unoccupied FPGA logic unit can be allocated for the execution item first, and then the ID of this FPGA logic unit is used as the unit ID value in the execution item.

[0095] In some embodiments, different unit ID ranges can be divided for different types of operators in advance to obtain the corresponding relationship between different types of operators and different unit ID ranges (hereinafter referred to as the second corresponding relationship for the convenience of distinguishing from other corresponding relationships). When determining the unit ID value in the execution item, it can be determined according to the second corresponding relationship. Specifically, it can include: Obtain the second corresponding relationship between different types of operators and different unit ID ranges determined in advance; According to the second corresponding relationship, determine the target unit ID range corresponding to the type of the operator; Select an unoccupied FPGA logic unit from multiple FPGA logic units corresponding to the target unit ID range; Determine the ID of the selected FPGA logic unit as the unit ID in the execution item.

[0096] The second correspondence can be as shown in Table 2 above. When determining the unit ID value in the execution item, first find the unit ID range corresponding to the type of the operator in the second correspondence according to the type of the operator, that is, the target unit ID range. The target unit ID range includes multiple unit IDs corresponding to multiple FPGA logic units. Then select an unoccupied FPGA logic unit from the multiple FPGA logic units corresponding to the target unit ID range to execute the execution item corresponding to the operator, and determine the ID of the selected FPGA logic unit as the unit ID value in the execution item corresponding to the operator. For example, taking Table 2 as an example, assume the operator is "greater than", which is an operator of the Filter type, then the corresponding target unit ID range is "0x80~0x8F". When determining the unit ID value in the execution item, the multiple FPGA logic units corresponding to the target unit ID range can be traversed in ascending order of the unit ID, and then the ID of an unoccupied FPGA logic unit is determined as the unit ID value in the execution item. For example, assume that the FPGA logic units with unit IDs "0x80~0x82" are occupied, and the FPGA logic units with unit IDs "0x83~0x8F" are unoccupied, then "0x83" can be determined as the unit ID in the execution item.

[0097] Optionally, in some embodiments, multiple FPGA logic units corresponding to the target unit ID range may all be occupied. In this case, an unoccupied FPGA logic unit can be selected from the spare FPGA logic units, and the ID of the FPGA logic unit is determined as the unit ID value in the execution item. For example, in Table 2, the FPGA logic units corresponding to "0xB0~0xB7" are spare FPGA logic units and are all unoccupied, then "0xB0" can be determined as the unit ID value in the execution item. Or, an unoccupied FPGA logic unit can be overloaded with the function of the current operator, and the ID of the FPGA logic unit is determined as the unit ID value in the execution item. For example, the FPGA logic unit corresponding to "0xAF" in Table 2 is unoccupied, then it can be overloaded as a logic unit implementing the "greater than" function, and "0xAF" is determined as the unit ID value in the execution item.

[0098] Step S4: Determine the destination ID value in the execution item according to the flow direction of the execution result of the execution item.

[0099] The flow of the execution result of an execution item is related to the operator corresponding to the execution item.

[0100] In some embodiments, the flow of the execution result of an execution item can be the input of the next execution item or can also be the intermediate result cache. Thus, when determining the destination ID value in the execution item according to the flow of the execution result of the execution item, it may include: When the flow of the execution result of the execution item is the input data of other execution items, determine the unit ID value in the other execution items as the destination ID value in the execution item; When the flow of the execution result of the execution item is the intermediate result cache, determine the cache address as the destination ID value in the execution item.

[0101] The flow of the execution result of an execution item and the value / value range of the destination ID can have a certain corresponding relationship, and this corresponding relationship can be, for example, Table 3 above. When determining the destination ID value, the destination ID value can be determined according to the flow of the execution result of the execution item and this corresponding relationship. For example, taking Table 3 as an example, if the operator is an operator of the Filter type and the execution result of the corresponding execution item needs to be the input of AND, a value that is not occupied can be selected between "0x80~0x8F" as the destination ID value. Another example is that if the operator is an operator of the Project type and the execution result of the corresponding execution item needs to be output to the host table, "0x0F" can be used as the destination ID value.

[0102] Step S5: Determine the output column number in the execution item according to the position of the execution result of the execution item in the result data table.

[0103] The result data table is used to store the query result corresponding to the SQL query plan. The column numbers in the result data table can start from 0. In practical applications, the execution result of the execution item may be output as a column in the result data table or may not be output as a column in the result data table. Thus, when determining the output column number in the execution item according to the position of the execution result of the execution item in the result data table, it may include: When the execution result of the execution item is output as a column in the result data table, determine the output column number in the execution item as the column serial number starting from 0; Among them, when the execution result of the execution item is not output as a column in the result data table, determine the output column number in the execution item as the first preset value, and this first preset value can be, for example, 0x00.

[0104] Step S6: Determine the source position value and data value in the execution item according to the source of the parameters required when executing the execution item.

[0105] In some embodiments, the sources of the source location indication may include at least one of the following: Input data tables; constants; FPGA logic units.

[0106] Correspondingly, the data value may be a value in the input data table, or it may be a constant, or it may be the execution result of a certain FPGA logic unit for a certain execution item.

[0107] Thus, when determining the source location value and the data value in the execution item, it may include: When the source of the parameters required when executing the execution item is the input data table, determine that the source location value in the execution item is the first preset location value, and the data value is the column sequence number starting from 0, where the number of input data tables is one or more. When the number of input data tables is multiple, different input data tables correspond to different first preset location values; When the source of the parameters required when executing the execution item is the FPGA logic unit, determine that the source location value in the execution item is the ID of the FPGA logic unit, and the data value is the first preset data value; When the source of the parameters required when executing the execution item is a constant, determine that the source location value in the execution item is the second preset location value, and the data value is the value of the constant.

[0108] After converting the operator into an execution item according to the above steps S1 to S6, optionally, it can also be determined whether the execution item satisfies byte alignment. If not, a padding area can be set in the execution item. If it is aligned, there is no need to set a padding area in the execution item. Among them, the padding area can be filled with 0x00. The length of the padding area can be long or short, and can be determined according to the actual situation, and no specific limitation is made here.

[0109] Step S406: Construct an acceleration task according to at least one execution graph and the input data tables involved in the SQL query plan.

[0110] The input data tables involved in the SQL query plan will be given in the SQL query plan. After converting the SQL query plan into at least one execution graph, an acceleration task can be constructed according to the at least one execution graph and the input data tables involved in the SQL query plan. The acceleration task can be used to build a query acceleration pipeline on the FPGA.

[0111] In some embodiments, constructing an acceleration task according to at least one execution graph and the input data tables involved in the SQL query plan may include: Apply for an idle acceleration task; When there is an idle acceleration task, apply for a cache; In the case of successfully applying for a cache, update the cache address to the acceleration task. The cache address includes the execution graph address, the table data address, and the result data address; Save at least one execution graph to the cache pointed to by the execution graph address, and save the input data table to the cache pointed to by the table data address.

[0112] The CPU side caches multiple acceleration tasks, and the multiple acceleration tasks form a task queue. Each acceleration task consists of a task status, an execution graph address, a table data address, and a result data address. Among them, the task status includes idle (not assigned any acceleration task), assigned (already assigned to an acceleration task, but the execution graph, table data, and result data buffer areas involved in the task are not yet ready), pending (the execution graph, table data, and result data buffer areas involved in the task are already ready and waiting to be executed by the FPGA), being processed (the task is being executed by the FPGA), failed (the task has ended execution and the execution result is a failure), completed (the task has ended execution and the execution result is a success), etc. The execution graph address is the cache address of the execution graph, the table data address is the cache address of the input data table, and the result data address is the cache address of the result data table.

[0113] When constructing an acceleration task, an idle acceleration task can be applied for from multiple acceleration tasks cached on the CPU side. Optionally, the acceleration tasks can be managed by the task management module on the CPU side. When applying for an idle acceleration task, an idle acceleration task can be applied for from the task management module. For example, the cache bytes required for the execution graph, the cache bytes required for the input data table, and the cache bytes required for the result data can be used as parameters to apply for an idle acceleration task from the task management module. After receiving the application, the task management module can traverse multiple acceleration tasks and check if there is an idle acceleration task among them.

[0114] If there is an idle acceleration task, the cache can be applied for continuously. If there is no idle acceleration task, the application fails, and the idle acceleration task can be applied for again after waiting for a period of time.

[0115] When applying for a cache, optionally, the memory manager can be applied for a cache. After receiving the request, the memory manager can allocate a cache of a specified size for the acceleration task. This cache can be used to cache the execution graph, input data table, and result data table corresponding to the acceleration task.

[0116] In the case of successfully applying for a cache, the cache address can be updated to the acceleration task. The cache address includes an execution graph address, a table data address, and a result data address. Subsequently, at least one execution graph converted from an SQL query plan can be saved to the cache pointed to by the execution graph address, and the input data table can be saved to the cache where the table data address is executed. Thus, an acceleration task can be successfully constructed.

[0117] Optionally, in order to improve data query efficiency and enhance query performance, when saving the input data table to the cache pointed to by the table data address, data in the Apache Arrow format can be saved. Specifically, it can include: Determine whether the data in the input data table is in the Apache Arrow format; In the case where the data in the input data table is in the Apache Arrow format, save the data in the data data table to the cache pointed to by the table data address; In the case where the data in the input data table is not in the Apache Arrow format, convert the data in the input data table into data in the Apache Arrow format and then save it to the cache pointed to by the table data address.

[0118] In some embodiments, before applying for or constructing an acceleration task, the CPU side can perform some preparatory operations in advance so that an acceleration task can be successfully applied for or constructed. Specifically, it can include: Apply for huge page memory; In the case of successfully applying for huge page memory, divide the huge page memory into a task queue buffer area and a service data buffer area. The task queue buffer area is used to cache multiple acceleration tasks, and the service data buffer area is used to cache the execution graphs, input data tables, and result data tables of multiple acceleration tasks; Initialize the acceleration tasks in the task queue buffer area to the idle state, and initialize the service data buffer area to the unallocated state.

[0119] When applying for huge page memory, huge page memory of a specified size can be applied for. The huge page memory is shared memory and can be used to store multiple acceleration tasks and the execution graphs, input data tables, and result data tables of multiple acceleration tasks. After successfully applying for huge page memory, the huge page memory can be divided into two areas, namely the task queue buffer area and the service data buffer area. The task queue buffer area is used to store multiple acceleration tasks. The service data buffer area is used to store the execution graphs, input data tables, and result data tables of multiple tasks. Subsequently, the acceleration tasks in the task queue buffer area can be initialized to the idle state, and the service data buffer area can be initialized to the unallocated state. In this way, when performing data queries subsequently, idle acceleration tasks and caches can be allocated for data queries.

[0120] Optionally, after dividing the huge page memory into a task queue buffer area and a service data buffer area, the task queue buffer area can be handed over to the task management module for management, and the service data buffer area can be handed over to the memory management module for management. During subsequent data query processes, the task management module can allocate idle acceleration tasks for data query, and the memory management module can allocate caches for data query.

[0121] Optionally, in some possible implementation manners, if the CPU side can directly access the memory on the FPGA (for example, with the support of Compute Express Link (CXL)), acceleration tasks can also be directly created on the FPGA memory. For example, a task queue buffer area can be applied for on the FPGA memory, and a service data buffer area can be applied for on the CPU side. Or, if there is enough memory on the FPGA, both a task queue buffer area and a service data buffer area can be applied for on the FPGA memory.

[0122] Step S408: Trigger the FPGA to execute the acceleration task.

[0123] After successfully constructing the acceleration task, the status of the acceleration task can be updated to the pending state, and the FPGA is triggered to execute the acceleration task. For example, the CPU side can write a doorbell signal to the doorbell register of the FPGA to trigger the FPGA to start executing the acceleration task. When the FPGA executes the acceleration task, it can first construct a query acceleration pipeline according to the acceleration task, and then perform data query according to the query acceleration pipeline. The specific implementation manner can refer to the Figure 5 illustrated embodiments and will not be elaborated here.

[0124] In some implementation manners, after triggering the FPGA to execute the acceleration task, the CPU side can perform the following operations: Poll the status of the acceleration task; When the status of the acceleration task is being processed, continue to poll the status of the acceleration task; When the status of the task is completed, read the result data from the cache pointed to by the result data address of the acceleration task and return the result data to the querying party as the query result; When the status of the acceleration task is failed, return the failure information to the querying party.

[0125] As described above, the status of an acceleration task may include idle, assigned, pending, in - process, failed, and completed. In the case where an acceleration task is successfully constructed and the FPGA is triggered to execute the acceleration task, the status of the acceleration task will become in - process, failed, or successful. During the process of the FPGA executing the acceleration task, the FPGA can update the status of the acceleration task in real - time and return it to the CPU side, and the CPU side can poll the status of the acceleration task returned by the FPGA. If the status of the acceleration task is in - process, it can be indicated that the FPGA has not completed processing the acceleration task, and at this time, the status of the acceleration task can be polled continuously. If the status of the acceleration task is completed, it can be indicated that the FPGA has executed and completed the acceleration task successfully, and at this time, the result data can be read from the cache pointed to by the result data address of the acceleration task (after the FPGA executes and completes the acceleration task, it will cache the result data in the cache pointed to by this result data address), and the result data can be returned to the querying party as the query result. If the status of the acceleration task is failed, it can be indicated that the FPGA has executed and completed the acceleration task but failed, and at this time, the failure information can be returned to the querying party to inform the querying party that the data query has failed. Among them, the querying party can be a database (and / or big data) system running on the CPU side.

[0126] In some embodiments, the format of the result data of the acceleration task is in Apache Arrow format. When the CPU side returns the result data to the querying party, it may include: When the querying party supports the Apache Arrow format, return the result data to the querying party as the query result; When the querying party does not support the Apache Arrow format, convert the result data into the format supported by the querying party and then return it to the querying party.

[0127] In some embodiments, after the FPGA executes the acceleration task (the status of the acceleration task may be completed or failed), it may further include: Release the cache pointed to by the execution graph address in the acceleration task and set the execution graph address to a null pointer; Release the cache pointed to by the table data address in the acceleration task and set the table data address to a null pointer; Release the cache pointed to by the result data address in the acceleration task and set the result data address to a null pointer; Set the status of the acceleration task to idle.

[0128] The idle acceleration task can be used for subsequent new SQL queries.

[0129] In an embodiment of the present application, when performing data query, the CPU side can convert the SQL query plan into at least one execution graph according to the specification of the execution graph, construct an acceleration task based on the at least one execution graph and the input data tables involved in the SQL query plan, and then trigger the FPGA to execute the acceleration task. In this way, since the acceleration task is constructed according to the execution graph, and the execution graph includes one or more execution items, it is convenient for the FPGA to construct a query acceleration pipeline and perform data query based on the query acceleration pipeline, thereby accelerating the query efficiency through the pipeline processing method, and at the same time reducing or avoiding the "data ping-pong" problem and improving the query performance.

[0130] Figure 5 It is a schematic flowchart of a data query method according to an embodiment of the present application. Figure 5 The data query method shown is implemented based on the execution graph provided by the embodiment of the present application. This data query method can be applied to the FPGA side, that is Figure 5 The data query method shown can be executed by the FPGA side, for example, it can be executed by software or hardware installed on the FPGA side. Figure 5 The data query method shown includes the following steps.

[0131] Step S502: Obtain the acceleration task to be processed.

[0132] When the CPU side receives the SQL query plan, it can convert the SQL query plan into at least one execution graph, construct an acceleration task based on the at least one execution graph and the input data tables involved in the SQL query plan, and then trigger the FPGA to execute the acceleration task (the specific implementation method of the CPU side can be referred to Figure 4 the embodiment shown, and details are not described here). After receiving the trigger signal from the CPU side, the FPGA can obtain the acceleration task to be processed. For example, it can search for the acceleration task with the status of "to be processed" in the task queue buffer (storing multiple acceleration tasks), and obtain the acceleration task to be processed when found.

[0133] Optionally, if there is no acceleration task to be processed, the FPGA can resume the waiting state.

[0134] Step S504: Construct a query acceleration pipeline according to the acceleration task.

[0135] After obtaining the acceleration task to be processed, a query acceleration pipeline can be constructed according to the acceleration task.

[0136] In some embodiments, constructing a query acceleration pipeline according to the acceleration task may include: Read the execution graph from the cache pointed to by the execution graph address of the acceleration task; For each execution item in the execution graph, configure the FPGA logic unit corresponding to the unit ID in the execution item, determine the operation to be performed by the execution item according to the operation code in the execution item, and configure the output position of the execution result of the execution item according to the destination ID in the execution item; According to the operations performed by each execution item in the execution graph and the output positions of the execution results of each execution item, form a query acceleration pipeline in sequence with the configured FPGA logic units.

[0137] Specifically, an acceleration task consists of a task status, an execution graph address, a table data address, and a result data address. The cache pointed to by the execution graph address stores the execution graph, the cache pointed to by the table data address stores the input data table, and the cache pointed to by the result data address stores the result data. After the FPGA obtains an acceleration task to be processed, it can first read the execution graph from the cache pointed to by the execution graph address of the acceleration task. This execution graph is transformed from the SQL query plan and may specifically include one or more execution graphs.

[0138] After reading the execution graph, it is possible to traverse the execution items in the execution graph and construct a query acceleration pipeline. Among them, when constructing the query acceleration pipeline, for each execution item in the execution graph, the FPGA logic unit corresponding to the unit ID in the execution item can be configured first so that the FPGA logic unit executes the execution item. Then, determine what operation the execution item performs according to the operation code in the execution item. Then, configure the output position of the execution result of the execution item according to the destination ID in the execution item so that the execution result of the execution item can flow smoothly into the corresponding FPGA logic unit or address. Finally, according to the operations performed by each execution item in the execution graph and the output positions of the execution results of each execution item, form a query acceleration pipeline in sequence with the configured FPGA logic units. That is to say, when constructing the query acceleration pipeline, according to the descriptions of the execution items in the execution graph, the FPGA logic units corresponding to the execution items can be "connected" together in sequence, thereby forming a query acceleration pipeline.

[0139] Step S505: Perform data query according to the query acceleration pipeline.

[0140] After constructing the query acceleration pipeline, data query can be performed according to the query acceleration pipeline, that is, start the acceleration pipeline to execute data query.

[0141] In some embodiments, performing data query according to the query acceleration pipeline may include: Read the corresponding column data from the cache pointed to by the table data address of the acceleration task according to the source position value and data value of each execution item in the execution graph; Send the read column data into the query acceleration pipeline and perform calculations through the FPGA logic units in the query acceleration pipeline.

[0142] Specifically, the source location in the execution item is used to indicate the source of the parameters required when executing this execution item. The source can be, for example, an input data table, a constant, or an FPGA logic unit. The data in the execution item is used to indicate the value of the parameters required when executing this execution item or the column number of the parameters in the input data table. The cache pointed to by the table data address of the acceleration task stores the input data tables involved in the SQL query plan. When performing data query, the corresponding column data can be read from the cache pointed to by the table data address of the acceleration task according to the source location value and the parameter value of each execution item in the execution graph. For example, if the source location value indicates the input data table 1 and the parameter value indicates the first column and the third column, then the data of the first column and the third column of the input data table 1 can be read from the cache pointed to by the table data address of the acceleration task. After that, the read data can be sent into the query acceleration pipeline, and these data will sequentially perform calculations through the FPGA logic units in the acceleration query pipeline, thereby enabling data query.

[0143] Since when reading input data from the CPU side, only the specified column data in the input data table can be read according to the source location value and the data value in the execution item, without reading all the data in the input data table, it is possible to avoid the transmission of redundant data between the CPU and the FPGA, thereby improving the data transmission efficiency and accelerating data query.

[0144] In this embodiment, the number of query acceleration pipelines constructed according to the acceleration task can be one or more, that is, a SQL query plan can be constructed into one or more query acceleration pipelines. Among them, if the number of query acceleration pipelines is multiple, the multiple query acceleration pipelines can be connected in sequence, that is, after executing one query acceleration pipeline, the next query acceleration pipeline needs to be executed in sequence.

[0145] In some embodiments, when the number of query acceleration pipelines is one, after the FPGA executes the query acceleration pipeline, it can write the execution result into the cache pointed to by the result data address of the acceleration task. Optionally, when performing the data writing operation, the execution result can be first converted into the Apache Arrow format, and then the result data in the Apache Arrow format can be written into the cache pointed to by the result data address of the acceleration task.

[0146] In some embodiments, when the number of query acceleration pipelines is multiple, when executing the current acceleration pipeline, if the pipeline is not the last one, its execution result can be written into the internal cache of the FPGA and participate in the execution process of the next query acceleration pipeline as input data. If the query acceleration pipeline is the last one, its execution result can be written into the cache pointed to by the result data address of the acceleration task, or first written into the internal cache of the FPGA, and then the execution results of multiple pipelines in the FPGA internal cache are written into the cache pointed to by the result data address of the acceleration task as result data. Optionally, when performing the data writing operation, the execution result can be first converted into the Apache Arrow format, and then the result data in the Apache Arrow format is written into the cache pointed to by the result data address of the acceleration task.

[0147] It should be noted that when the number of query acceleration pipelines is one, since in the process of data query, the FPGA side does not need to send the intermediate result to the CPU side and then have the CPU side return it to the FPGA (because the intermediate result will directly flow into the next execution item along with the pipeline), "data ping-pong" can be avoided. When the number of query acceleration pipelines is multiple, since the scale of the result data set processed by the pipeline has been greatly reduced, it can be cached in the cache on the FPGA side and used as the input of the next pipeline without sending it to the CPU side and then having the CPU side return it to the FPGA. Therefore, "data ping-pong" can also be avoided.

[0148] In some embodiments, during the process of the FPGA executing the acceleration pipeline, it can return the status of the acceleration task to the CPU side so that the CPU side can know the execution status of the acceleration task. Among them, when the status of the acceleration task is completed, the CPU side can read the result data from the cache pointed to by the result data address of the acceleration task and return the result data to the querying party as the query result. When the status of the acceleration task is failed, the CPU side can return the failure information to the querying party.

[0149] In the embodiments of the present application, when performing data query, the FPGA can obtain the acceleration task to be processed from the CPU side, construct a query acceleration pipeline according to the acceleration task, and perform data query according to the query acceleration pipeline. In this way, since when performing data query, a query acceleration pipeline can be constructed based on the execution graph and data query can be performed based on the query acceleration pipeline, the query efficiency can be accelerated by the pipeline processing method, and at the same time, the "data ping-pong" problem can be reduced or avoided, thereby improving the query performance.

[0150] Figure 6It is a schematic structural diagram of a data query system according to an embodiment of the present application. As Figure 6 shown, the data query system 60 includes a CPU 61 and an FPGA 62. Among them: The CPU 61 receives an SQL query plan; converts the SQL query plan into at least one execution graph; constructs an acceleration task according to the at least one execution graph and the input data tables involved in the SQL query plan; and triggers the FPGA to execute the acceleration task; The FPGA 62 obtains the acceleration task to be processed; constructs a query acceleration pipeline according to the acceleration task; and performs data query according to the query acceleration pipeline.

[0151] In the embodiment of the present application, the specific implementation manners of the steps executed by the CPU 61 can be referred to the Figure 4 embodiment shown, and will not be elaborated here. The specific implementation manners of the steps executed by the FPGA 62 can be referred to the Figure 5 embodiment shown, and will not be elaborated here either.

[0152] To facilitate the understanding of the execution graph and data query scheme provided by the embodiment of the present application, the following will be described by taking some more specific implementation manners as examples.

[0153] The embodiment of the present application is composed of an execution graph specification, an Accelerator module on the CPU side, a Controller module on the FPGA side, an LPE (i.e., an FPGA logic unit) with various operator functions in the dynamic area, and a Cache module, as Figure 7 shown. The following will explain each component.

[0154] 1. Execution graph specification.

[0155] The execution graph specification can be as shown in Table 4 above, and will not be elaborated here.

[0156] 2. Accelerator module on the CPU side.

[0157] This module runs on the CPU side together with the database (and / or big data) system as a plugin of the database (and / or big data) system. Its functions mainly include: (1) Create a heterogeneous acceleration task for data query.

[0158] The structure of the acceleration task is as Figure 8 shown, including task status, execution graph address, table 0 data address, table 1 data address, and result data address. The acceleration task can be managed by the task management module in the Accelerator module, including task allocation and recycling.

[0159] (2) Prepare the execution graph.

[0160] Convert the query plan into an execution graph according to the execution graph specification and store it in the shared cache pointed to by the execution graph address of the acceleration task. The execution graph can be generated by the execution graph module in the Accelerator module.

[0161] (3)Prepare the query input data.

[0162] Obtain the table data involved in the query (which can be obtained from disk) and store it in the shared cache pointed to by the table 0 data address and table 1 data address of the acceleration task. The input data can be formatted by the Arrow module to avoid redundant data reading and improve query performance.

[0163] (4)Trigger the FPGA to execute the acceleration task.

[0164] A doorbell signal can be written to the doorbell register of the FPGA to trigger the FPGA to start executing the acceleration task.

[0165] (5)Process the query result data.

[0166] Poll the status of the acceleration task and wait for the task to end. When the task ends successfully, read the result data from the shared cache pointed to by the result data address of the acceleration task and return it to the database (and / or big data) system. The result data is also formatted by the Arrow module.

[0167] 3. Controller module This module runs on the FPGA side, and its main functions include: (1)Read the acceleration task to obtain the execution graph address, table 0 data address, table 1 data address, and result data address.

[0168] (2)Construct a query acceleration pipeline.

[0169] Read and parse the execution graph from the shared cache pointed to by the execution graph address, and "connect" the corresponding various LPEs together according to the description of the execution items to form a data processing pipeline; (3)Execute query acceleration.

[0170] Read the data of the required columns from the shared cache pointed to by the table 0 data address and / or table 1 data address according to the "source location" and "data" values of the execution item, send it into the pipeline for processing, and cache the processing result in the Cache.

[0171] (4)Generate query results.

[0172] After processing all the input data, the processing results cached in the Cache are used to generate query results and written back to the shared cache pointed to by the result data address in the acceleration task. At the same time, the task status value is updated to end the data query acceleration task.

[0173] 4. LPE As Figure 7 shown by the dashed box in [reference], LPE is a basic functional module in the reconfigurable area on the FPGA board, corresponding to operators and / or operators, including LPEs such as greater than, less than, equal to, greater than or equal to, less than or equal to, not equal to, AND, and OR in the filtering class (Filter), LPEs such as addition, subtraction, multiplication, and division in the arithmetic calculation class (Calculate), LPEs such as HashBuild and Hash Probe in the connection class (HashJoin), and LPEs such as sum, max, min, avg, count, and group by in the aggregation class (Aggregate), as well as Project LPE. To support scenarios with multiple join conditions and multiple grouping conditions, Merge LPE is also created. When multiple LPEs are connected in sequence, a data processing pipeline is formed.

[0174] 5. Cache Module The Cache module is used for data caching. Specifically, it can be used by the LPE unit on the FPGA side to cache the execution results (or data related to the execution results) into the cache module. Taking one of the LPE units on the FPGA side as an example, when caching data, it can be as Figure 9 shown. Figure 9 When the LPE unit shown in [reference] caches data, it can cache the data to be cached into the cache module through a Double Data Rate (DDR) controller ( Figure 9 shows 2 DDR controllers, namely DDR controller 1 and DDR controller 2. The LPE unit can store different data through different DDR controllers. In specific implementations, it can also be 1 or more DDR controllers). Among them, when caching data into the cache module, it can be cached as hash table and temporary table data according to actual needs, such as Figure 9 the table data storage 1 and hash table 1 shown in [reference], or it can also be cached only as temporary table data, which is not specifically limited here. After caching the data into the cache module, when these data need to be read, the LPE unit can read the required data from the cache module through the DDR controller.

[0175] Based on Figure 7For the execution graph specification shown, the Accelerator module on the CPU side, the Controller module on the FPGA side, the LPE (i.e., the FPGA logic unit) with the functions of various operators in the dynamic area, and the Cache module, the specific implementation method during data query is as follows.

[0176] Step 1: Pre-split the operator into various operators and implement them in the logic units in the reconfigurable area of the FPGA.

[0177] 1. Split the operator operators.

[0178] Here, the operators defined by the SQL specification can be split into operators.

[0179] Optionally, split the filtering type operators in the operator, including greater than, less than, equal to, greater than or equal to, less than or equal to, not equal to, AND, and OR, etc.

[0180] Optionally, split the arithmetic calculation type operators in the operator, including addition, subtraction, multiplication, division, etc.

[0181] Optionally, split the operators in the hash join operator, including build, probe, etc.

[0182] Optionally, split the operators in the aggregation operator, including sum, max, min, avg, count, group by, etc.

[0183] Optionally, split the projection operator into projection operators.

[0184] Optionally, to support multiple join conditions during HashJoin and multiple grouping conditions during Groupby, a new Merge operator is defined, that is, the two input condition values are merged into one data output, and the Merge result can continue to perform Merge with the join condition or the grouping condition. Correspondingly, Merge operators can be created for multiple join conditions and multiple grouping conditions.

[0185] 2. Normalize the FPGA into multiple identical functional areas to support parallel execution of multiple acceleration tasks.

[0186] Optionally, one functional area can execute one acceleration task, and multiple functional areas can execute multiple acceleration tasks in parallel.

[0187] Optionally, when there are more resources in one functional area, multiple acceleration tasks can also be executed in parallel in one functional area.

[0188] 3. Implement the operator on the LPE in the reconfigurable functional area of the above-mentioned FPGA, that is, make the LPE have the function of the operator. Specifically, it can include: (1)Write functional code for the above operators; (2)Compile the above functional code into FPGA logic; (3)Plan the quantity of various operators. Optionally, more LPEs can be planned for operators with high usage frequency, and fewer LPEs can be planned for operators with low usage frequency; (4)Flash the operator logic onto the FPGA board according to the plan.

[0189] Step 2: Pre-define acceleration tasks and partition huge pages of memory.

[0190] 1. Define acceleration tasks.

[0191] As Figure 8 shown, the acceleration task can consist of the following five parts: Task status, used to track the usage of the task itself and the execution of the acceleration task; Execution graph address, pointing to the execution graph storage cache; Table 0 data address, pointing to the input data cache of the acceleration task; Table 1 data address, pointing to the input data cache of the acceleration task; Result data address, pointing to the result data cache of the acceleration task.

[0192] Among them, the task status can be divided into: Idle: Not assigned to any acceleration task; Allocated: Already assigned to an acceleration task, but the execution graph, table data, and result data buffer areas involved in the task are not yet ready; Pending: The execution graph, table data, and result data buffer areas involved in the task are already ready and waiting to be executed by the FPGA; Processing: The task is being executed by the FPGA; Failed: The task has ended execution and the result is a failure; Completed: The task has ended execution and the result is a success.

[0193] All acceleration tasks form a task queue.

[0194] 2. Partition huge pages of memory.

[0195] (1)Apply for huge pages of memory.

[0196] When the Accelerator starts, it applies to the system for a specified size of huge pages of memory to be used as shared memory.

[0197] Optionally, if the application fails, exit; Optionally, if the application is successful, the front part (e.g., 10KB) of the allocated huge page memory is used as the task queue buffer and managed by the task management module, and the remaining part is used as the business data buffer and managed by the memory management module.

[0198] (2) Initialization.

[0199] The task management module initializes the status of all acceleration tasks in the task queue to the idle state; The memory management module initializes all the memory in the business data buffer to the unallocated state.

[0200] Optionally, when the CPU side can directly access the memory on the FPGA (such as with the support of CXL), acceleration tasks can also be directly created on the FPGA memory.

[0201] Step 3: When a query request occurs, the Accelerator module creates a query acceleration task, triggers the FPGA to execute the query acceleration, and processes the result data. The process is as Figure 10 shown.

[0202] 1. Apply for a task.

[0203] Using the required cache bytes for the given execution graph, the required cache bytes for table 0 data, the required cache bytes for table 1 data, and the required cache bytes for result data as parameters, apply for an idle task from the task management module. The task management module circularly searches backward from the start position of the task queue to find the first task with the status of "idle".

[0204] Optionally, if a task with the status of "idle" is found, then apply to the memory management module to allocate caches for the execution graph, table 0 data, table 1 data, and result data involved in the task respectively.

[0205] Optionally, if the memory management module successfully allocates caches of the specified sizes for the execution graph, table 0 data, table 1 data, and result data, then update the execution graph cache address, table 0 data cache address, table 1 data cache address, and result data cache address to the idle task, and then update the task status to "allocated", and return the task to the Accelerator. The application for the task is successful.

[0206] Optionally, if the memory management module fails to allocate memory, then return a null pointer and exit the task application.

[0207] Optionally, if no task with the status of "idle" is found, then return a null pointer and exit the task application.

[0208] 2. Traverse the query plan tree and call the execution graph module to generate an execution graph.

[0209] (1)Reset the FPGA LPE status.

[0210] Mark all FPGA LPEs as available, that is, the LPEs in the FPGA are not occupied.

[0211] (2)Parse the data nodes in the plan tree.

[0212] Set the first data source (table or file) of the data node as host table 0, that is, 0x00. Obtain the corresponding metadata, including the names of each data column, the data types of each data column, whether each data column can be NULL, and the column sequence number.

[0213] Optionally, when the data node involves two tables, set the second data source (table or file) as host table 1, that is, 0x01. Obtain the corresponding metadata, including the names of each data column, the data types of each data column, whether each data column can be NULL, and the column sequence number.

[0214] (3)Parse the operator nodes in the plan tree to generate an execution graph.

[0215] (3.1)Optionally, parse the Filter operator node and generate an execution item for each filtering condition.

[0216] Set the "type" value to 0x02, that is, continue to load the next execution item and execute them together.

[0217] Set the "opcode" value: Set the corresponding "opcode" for the current Filter operator according to Table 1.

[0218] Set the "unit id" value: Select an unoccupied value between 0x80 and 0x8F as the "unit id".

[0219] Set the "destination id" value: Optionally, when the calculation result of this execution item is used as the input of AND, select an unoccupied value between 0x80 and 0x8F as the "destination id"; Optionally, when the calculation result of this execution item is used as the input of OR, select an unoccupied value between 0x80 and 0x8F as the "destination id"; Optionally, when the calculation result of this execution item is used as the final result of the Filter operator, use 0x00 as the "destination id".

[0220] Set the "output column number" value to 0x00, that is, the calculation result of this execution item is not output as a column in the result data table.

[0221] Set the "source location 1" value: Optionally, when the first parameter comes from table 0, set "source location 1" to 0x00; Optionally, when the first parameter is from Table 1, set "Source Location 1" to 0x01; Optionally, when the first parameter is from the previous LPE, set "Source Location 1" to the "Cell ID" of the previous LPE; Optionally, when the first parameter is a constant, set "Source Location 1" to 0x7F.

[0222] Set the value of "Source Location 2": Optionally, when the second parameter is from Table 0, set "Source Location 2" to 0x00; Optionally, when the second parameter is from Table 1, set "Source Location 2" to 0x01; Optionally, when the second parameter is from the previous LPE, set "Source Location 2" to the "Cell ID" of the previous LPE; Optionally, when the second parameter is a constant, set "Source Location 2" to 0x7F; Optionally, when there is only one parameter, set "Source Location 2" to 0x00.

[0223] Set the value of "Data 1": Optionally, when the first parameter is a column in the table, set the column number starting from 0 as "Data 1"; Optionally, when the first parameter is from the previous LPE, set 0x00 as "Data 1"; Optionally, when the first parameter is a constant, set the constant value as "Data 1".

[0224] Set the value of "Data 2": Optionally, when the second parameter is a column in the table, set the column number starting from 0 as "Data 2"; Optionally, when the second parameter is from the previous LPE, set 0x00 as "Data 2"; Optionally, when the second parameter is a constant, set the constant value as "Data 2"; Optionally, when there is only one parameter, set "Data 2" to 0x00.

[0225] (3.2) Optionally, parse the Project operator node and generate an execution item for each projection column.

[0226] Set the value of "Type": Optionally, when the current projection column is at a 16 - multiple position, set the "Type Value" to 0x01, i.e., execute immediately; Optionally, when the current projection column is at a non - 16 - multiple position, set the value of "Type" to 0x02, i.e., load the next execution item and execute together.

[0227] Set the "Opcode" value to 0x0700.

[0228] Set the "Unit ID" value: Select an unoccupied value between 0xA0 and 0xAF as the "Unit ID".

[0229] Set the "Destination ID" value to 0x0F, which means outputting it to the host table.

[0230] Set the Output Column Number value to the projection column number.

[0231] Set the Source Position 1 value: Optionally, when the projection parameters are from table 0, set "source position 1" to 0x00; Optionally, when the projection parameters are from Table 1, set "Source Position 1" to 0x01; Optionally, when the projection parameters come from the previous LPE, set "source position 1" to the "unit id" of the previous LPE; Optionally, when the projection parameter is a constant, set Source Location 1 to 0x7F.

[0232] Set "source position 2" to 0x00, that is, do not project from "source position 2".

[0233] Set the "data1" value: Optionally, when the projection parameter is a column in a table, set the column number starting from 0 to "data1"; Optionally, when the projection parameters come from the previous LPE, set 0x00 to "data 1"; Optionally, when the projection parameter is a constant, the constant value is set to "data 1".

[0234] Set the value of "Data 2" to 0x00, that is, do not project from "Data 2".

[0235] (3.3) Optionally, parse the HashJoin operator node and generate execution items.

[0236] (3.3.1) Optionally, when there are multiple join conditions, a Merge execution item is generated for the Build operation.

[0237] Set the "Type" value to 0x02, which means to continue loading the next execution item and execute it together.

[0238] Set the "Opcode" value to 0x0800.

[0239] Set the "unit id" value: Optionally, when all parameters of the Merge execution item are from internal table columns, select an unoccupied value between 0xD0 and 0xDF as the "unit id"; Optionally, when at least one parameter of this Merge execution item comes from the calculation result of the previous Merge LPE, use the "destination ID" recorded when generating the previous Merge execution item as the "unit ID" for this execution; Set the value of "destination ID": Optionally, when there are still connection conditions to be merged, select an unoccupied value between 0xD0 and 0xDF as the "destination ID", and record it for use as the "unit ID" of subsequent Merge execution items; Optionally, when all connection conditions have been merged, select an unoccupied value between 0xF0 and 0xF7 as the "destination ID", and record it for use as the "unit ID" of subsequent Build execution items.

[0240] Set the value of "output column number" to 0x00, that is, the calculation result of this execution item is not output as a column in the result data table.

[0241] Set the value of "source location 1" to 0x00.

[0242] Set the value of "source location 2" to 0x00.

[0243] Set the value of "data 1": Optionally, when the first parameter comes from Table 0, set the value of "data 1" to the column number of the connection condition column starting from 0; Optionally, when the first parameter comes from the calculation result of the previous Merge LPE, set the value of "data 1" to 0x00.

[0244] Set the value of "data 2": Optionally, when the first parameter comes from Table 0, set the value of "data 1" to the column number of the connection condition column starting from 0; Optionally, when the first parameter comes from the calculation result of the previous Merge LPE, set the value of "data 1" to 0x00.

[0245] Repeat all steps in (3.3.1) until all connection conditions are merged.

[0246] (3.3.2) Generate a Hash Build execution item.

[0247] Set the value of "type" to 0x01, that is, execute immediately.

[0248] Set the value of "opcode": Optionally, when using Hash space No. 0x00, the "opcode" is 0x0200; Optionally, when using Hash space 0x01, the "operation code" is 0x0201.

[0249] Set the value of "unit id": Optionally, when there is only one connection condition, select an unoccupied value between 0xF0 and 0xF7 as the "unit id"; Optionally, when there are multiple connection conditions, use the "destination id" recorded when generating the last Merge execution item in (3.3.1) as the "unit ID" of this execution item.

[0250] Set the value of "destination id" to 0x00, that is, cache it into the hash table specified by the "operation code".

[0251] Set the value of "output column number" to 0x00, that is, the calculation result of this execution item is not output as a column in the result data table.

[0252] Set the value of "source location 1" to 0x00, that is, Table 0 is the inner table.

[0253] Set the value of "source location 2" to 0x00, that is, "source location 2" is not used in Build.

[0254] Set the value of "data 1": Optionally, when there is only one connection condition, set the value of "data 1" to the column sequence number of the connection condition column starting from 0; Optionally, when there are multiple connection conditions, set the value of "data 1" to 0x00.

[0255] Set the value of "data 2" to 0x00, that is, "data 2" is not used in Build.

[0256] (3.3.3) Optionally, generate a Merge execution item for the Probe operation when there are multiple connection conditions.

[0257] Set the value of "type" to 0x02, that is, continue to load the next execution item and execute them together.

[0258] Set the value of "operation code" to 0x0800.

[0259] Set the value of "unit id": Optionally, when all parameters of this Merge execution item come from the outer table columns, select an unoccupied value between 0xD0 and 0xDF as the "unit id"; Optionally, when at least one parameter of this Merge execution item comes from the calculation result of the previous Merge LPE, use the "destination id" recorded when generating the previous Merge execution item as the "unit id" of this execution.

[0260] Set the value of "Destination ID": Optionally, when there are connection conditions that need to be merged, select an unoccupied value between 0xD0 and 0xDF as the "Destination ID", and record it for use as the "Unit ID" in subsequent Merge execution items; Optionally, when all connection conditions have been merged, select an unoccupied value between 0xF0 and 0xF7 as the "Destination ID", and record it for use as the "Unit ID" in subsequent Build execution items; Set the value of "Output Column Number": 0x00, that is, the calculation result of this execution item is not output as a column in the result data table.

[0261] Set the value of "Source Location 1": Optionally, when the first parameter comes from Table 1, set the value of "Source Location 1" to 0x01; Optionally, when the first parameter comes from the calculation result of the previous Merge LPE, set the value of "Source Location 1" to 0x00.

[0262] Set the value of "Source Location 2": Optionally, when the second parameter comes from Table 1, set the value of "Source Location 1" to 0x01; Optionally, when the second parameter comes from the calculation result of the previous Merge LPE, set the value of "Source Location 1" to 0x00.

[0263] Set the value of "Data 1": Optionally, when the first parameter comes from Table 1, set the value of "Data 1" to the column number of the connection condition column starting from 0; Optionally, when the first parameter comes from the calculation result of the previous Merge LPE, set the value of "Data 1" to 0x00.

[0264] Set the value of "Data 2": Optionally, when the first parameter comes from Table 1, set the value of "Data 1" to the column number of the connection condition column starting from 0; Optionally, when the first parameter comes from the calculation result of the previous Merge LPE, set the value of "Data 1" to 0x00.

[0265] Repeat all steps in (3.3.3) until all connection conditions are merged.

[0266] (3.3.4) Generate Hash Probe execution items.

[0267] Set the value of "Type": 0x01, that is, execute immediately.

[0268] Set the value of "Opcode": Optionally, when the Build operation uses the Hash space numbered 0x00, the "operation code" is 0x0300; Optionally, when the Build operation uses the Hash space numbered 0x01, the "operation code" is 0x0301.

[0269] Set the value of "unit id": Optionally, when there is only one join condition, select an unoccupied value between 0xF0 and 0xF7 as the "unit id"; Optionally, when there are multiple join conditions, use the "destination id" recorded when generating the last Merge execution item in (3.3.3) as the "unit ID" of this execution item.

[0270] Set the value of "destination id" to 0x20.

[0271] Set the value of "output column number" to 0x00, that is, the calculation result of this execution item is not output as a column in the result data table.

[0272] Set the value of "source location 1" to 0x01, that is, Table 1 is the outer table.

[0273] Set the value of "source location 2" to 0x00, that is, "source location 2" is not used in Probe.

[0274] Set the value of "data 1": Optionally, when there is only one join condition, set the value of "data 1" to the column sequence number of the join condition column starting from 0; Optionally, when there are multiple join conditions, set the value of "data 1" to 0x00.

[0275] Set the value of "data 2" to 0x00, that is, "data 2" is not used in Probe; Optionally, parse the Group by operator node to generate execution items.

[0276] Optionally, generate Merge execution items for Hash Groupby when there are multiple grouping conditions.

[0277] Set the value of "type" to 0x02, that is, continue to load the next execution item and execute them together.

[0278] Set the value of "operation code" to 0x0800.

[0279] Set the value of "unit id": Optionally, when all the parameters of this Merge execution item come from the outer table columns, select an unoccupied value between 0xD0 and 0xDF as the "unit id"; Optionally, when at least one parameter of this Merge execution item comes from the calculation result of the previous Merge LPE, use the "destination ID" recorded when generating the previous Merge execution item as the "unit ID" for this execution.

[0280] Set the value of "destination ID": Optionally, when there are also connection conditions that need to be merged, select an unoccupied value between 0xD0 and 0xDF as the "destination ID", and record it for use as the "unit ID" of subsequent Merge execution items; Optionally, when all connection conditions have been merged, select an unoccupied value between 0xF0 and 0xF7 as the "destination ID", and record it for use as the "unit ID" of subsequent Build execution items.

[0281] Set the value of "output column number": 0x00, that is, the calculation result of this execution item is not output as a column in the result data table.

[0282] Set the value of "source location 1": Optionally, when the first parameter comes from Table 1, set the value of "source location 1" to 0x01; Optionally, when the first parameter comes from the calculation result of the previous Merge LPE, set the value of "source location 1" to 0x00.

[0283] Set the value of "source location 2": Optionally, when the second parameter comes from Table 1, set the value of "source location 1" to 0x01; Optionally, when the second parameter comes from the calculation result of the previous Merge LPE, set the value of "source location 1" to 0x00.

[0284] Set the value of "data 1": Optionally, when the first parameter comes from Table 1, set the value of "data 1" to the column number of the connection condition column starting from 0; Optionally, when the first parameter comes from the calculation result of the previous Merge LPE, set the value of "data 1" to 0x00.

[0285] Set the value of "data 2": Optionally, when the first parameter comes from Table 1, set the value of "data 1" to the column number of the connection condition column starting from 0; Optionally, when the first parameter comes from the calculation result of the previous Merge LPE, set the value of "data 1" to 0x00.

[0286] Repeat all steps in (3.4.1) until all grouping conditions are merged.

[0287] (3.4.2) Generate the Hash Groupby execution item.

[0288] Set the "type" value: 0x02, that is, continue to load the next execution item and execute them together.

[0289] Set the "opcode" value: Optionally, when the Groupby operation uses the 0x00 hash space, the "opcode" is 0x0400; Optionally, when the Groupby operation uses the 0x01 hash space, the "opcode" is 0x0401.

[0290] Set the "unit id" value: Optionally, when there is only one grouping condition, select an unoccupied value between 0xB8 and 0xBF as the "unit id"; Optionally, when there are multiple grouping conditions, use the "destination id" recorded when generating the last Merge execution item in (3.4.1) as the "unit ID" of this execution item.

[0291] Set the "destination id" value to 0x00.

[0292] Set the "output column number" value: 0x00, that is, the calculation result of this execution item is not output as a column in the result data table.

[0293] Set the "source location 1" value: Optionally, when there is only one grouping condition and the grouping condition column comes from Table 0, set the "source location 1" value to 0x00; Optionally, when there is only one grouping condition and the grouping condition column comes from Table 1, set the "source location 1" value to 0x01; Optionally, when there are multiple grouping conditions, set the "source location 1" value to 0x00.

[0294] Set the "source location 2" value to 0x00, that is, "source location 2" is not used in Hash Groupby.

[0295] Set the "data 1" value: Optionally, when there is only one grouping condition, set the "data 1" value to the column sequence number of the grouping condition column starting from 0; Optionally, when there are multiple join conditions, set the "data 1" value to 0x00.

[0296] Set the "data 2" value to 0x00, that is, "data 2" is not used in Hash Groupby.

[0297] (3.5)Optionally, parse the Agg operator node and generate the execution item.

[0298] Set the "type" value: Optionally, when the current aggregation column is at a 16 - multiple position, set the "type value" to 0x01, that is, execute immediately; Optionally, when the current aggregation column is not at a 16 - multiple position, set the "type" value to 0x02, that is, load the next execution item and execute together.

[0299] Set the "opcode" value: Set the corresponding "opcode" according to Table 2.

[0300] Set the "unit id" value: Select an unoccupied value between 0xE0 and 0xEF as the "unit id".

[0301] Set the "destination id" value to 0x0F, that is, output to the host table.

[0302] Set the "output column number" value to the column sequence number starting from 0.

[0303] Set the "source location 1" value: Optionally, when the first parameter comes from Table 0, set "source location 1" to 0x00; Optionally, when the first parameter comes from Table 1, set "source location 1" to 0x01; Optionally, when the first parameter comes from the previous LPE, set "source location 1" to the "unit id" of the previous LPE; Optionally, when the first parameter is a constant, set "source location 1" to 0x7F.

[0304] Set the "source location 2" value: Optionally, when the aggregation operation is not grouped, set the "source location 2" value to 0x0M; Optionally, when the aggregation operation is grouped, set the "source location 2" value to the "unit id" of the Hash Groupby in (3.4).

[0305] Set the "data 1" value: Optionally, when the first parameter is a column in the table, set the column sequence number starting from 0 as "data 1"; Optionally, when the first parameter comes from the previous LPE, set 0x00 as "data 1"; Optionally, when the first parameter is a constant, set the constant value as "data 1".

[0306] Set the "data 2" value to 0x00, that is, "data 2" is not used in Agg.

[0307] (3.6) Optionally, parse the Calculate node and generate an execution item for each arithmetic calculation operation.

[0308] Set the "type" value: 0x02, that is, load the next execution item and execute it in parallel.

[0309] Set the "opcode" value: Set the corresponding "opcode" according to Table 2.

[0310] Set the "unit id" value: Optionally, when both parameters of this arithmetic calculation operation come from the table, select an unoccupied value between 0xC0 and 0xCF as the "unit id"; Optionally, when at least one parameter of this arithmetic calculation operation comes from the previous LPE, use its "destination id" as the "unit id".

[0311] Set the "destination id" value: Optionally, when the calculation result of this execution item is used as the input of the Filter LPE, select an unoccupied value between 0x80 and 0x8F as the "destination id"; Optionally, when the calculation result of this execution item is used as the input of the Project LPE, select an unoccupied value between 0xA0 and 0xAF as the "destination id"; Optionally, when the calculation result of this execution item is used as the input of the Agg LPE, select an unoccupied value between 0xE0 and 0xEF as the "destination id"; Optionally, when the calculation result of this execution item is used as the input of the Calc LPE, select an unoccupied value between 0xC0 and 0xCF as the "destination id".

[0312] Set the "output column number" value: 0x00, that is, the calculation result of this execution item is not output as a column in the result data table.

[0313] Set the "source location 1" value: Optionally, when the first parameter comes from Table 0, set "source location 1" to 0x00; Optionally, when the first parameter comes from Table 1, set "source location 1" to 0x01; Optionally, when the first parameter comes from the previous LPE, set "source location 1" to the "unit id" of the previous LPE; Optionally, when the first parameter is a constant, set "source location 1" to 0x7F.

[0314] Set the "source location 2" value: Optionally, when the second parameter comes from Table 0, set "source location 2" to 0x00; Optionally, when the second parameter comes from Table 1, set "source location 2" to 0x01; Optionally, when the second parameter comes from the previous LPE, set "source position 2" to the "unit id" of the previous LPE; Optionally, when the second argument is a constant, set "source location 2" to 0x7F; Optionally, when there is only one parameter, set "Source Location 2" to 0x00.

[0315] Set the "data1" value: Optionally, when the first parameter is a column in a table, set the column number starting from 0 to "data1"; Optionally, when the first parameter comes from the previous LPE, set 0x00 to "data 1"; Optionally, when the first parameter is a constant, the constant value is set to "data 1".

[0316] Set the "data2" value: Optionally, when the second parameter is a column in a table, set the column number starting from 0 to "data2"; Optionally, when the second parameter comes from the previous LPE, set 0x00 to "data 2"; Optionally, when the second parameter is a constant, the constant value is set to "data 2"; Optionally, when there is only one parameter, set "Data 2" to 0x00.

[0317] (4) Save the execution graph.

[0318] The execution graph composed of the generated execution items is saved to the shared cache pointed to by the "execution graph address" of the acceleration task applied for in 1.

[0319] 3. Read the query input data into the shared cache.

[0320] Optionally, when the data in Table 0 is in Apache Arrow format, it is directly read into the shared cache pointed to by the "Table 0 data address" of the acceleration task applied in 1.

[0321] Optionally, when the data in Table 0 is not in Apache ARROW format, use the Arrow module to convert it into Apache Arrow format data and save it to the shared cache pointed to by the "Table 0 data address" of the acceleration task applied in 1.

[0322] Optionally, when the data in Table 1 is in Apache Arrow format, it is directly read into the shared cache pointed to by the "Table 1 data address" of the acceleration task applied in 1.

[0323] Optionally, when the data in Table 1 is not in the Apache Arrow format, use the Arrow module to convert it into Apache Arrow format data and save it to the shared cache pointed to by the "Table 1 data address" of the acceleration task applied for in 1.

[0324] 4. Trigger the FPGA to execute the query acceleration task.

[0325] Set the status of the acceleration task applied for in 1 to "pending".

[0326] Write a doorbell signal to the doorbell register of the FPGA to trigger the FPGA to start executing the query acceleration task.

[0327] 5. Poll the task status to determine whether the query acceleration task is completed.

[0328] Optionally, when the detected status is "processing", continue polling.

[0329] Optionally, when the detected status is "failed", return the failure information to the database (and / or big data) system, exit polling, and enter 7.

[0330] Optionally, when the detected status is "completed", exit polling and enter 6.

[0331] 6. Process the result data.

[0332] Read the Arrow data from the cache pointed to by the "result data address" in the above task.

[0333] Optionally, when the database (and / or big data) system supports the Arrow data format, directly return it to the database (and / or big data) system; Optionally, when the database (and / or big data) system does not support the Arrow data format, call the Arrow module to convert the Arrow data into the format data supported by the database (and / or big data) system and return it.

[0334] 7. Deregister the acceleration task.

[0335] Call the memory management module to release the cache pointed to by the "execution graph address" in the above task and set the "execution graph address" to a null pointer.

[0336] Call the memory management module to release the cache pointed to by the "Table 0 data address" in the above task and set the "Table 0 data address" to a null pointer.

[0337] Call the memory management module to release the cache pointed to by the "Table 1 data address" in the above task and set the "Table 1 data address" to a null pointer.

[0338] Call the memory management module to release the cache pointed to by the "result data address" in the above task, and set the "result data address" to a null pointer.

[0339] Call the task management module to set the status of the above task to "idle".

[0340] Step 4: After the FPGA is triggered, the Controller module executes the data query acceleration task, and the process is as Figure 11 shown.

[0341] 1. Traverse the task queue and read the acceleration tasks to be processed.

[0342] Starting from the beginning position of the task queue memory area, access the tasks in sequence to find the tasks with the status of "to be processed".

[0343] Optionally, if a task with the status of "to be processed" is found, set the status of this task to "being processed" and proceed to 2.

[0344] Optionally, if no task with the status of "to be processed" is found, the FPGA resumes the waiting state and ends.

[0345] 2. Create an acceleration pipeline.

[0346] Read the execution graph from the cache pointed to by the "execution graph address" of the above task.

[0347] Traverse the execution items to create an acceleration pipeline: (1) Optionally, when the execution item is the Filter operator opcode: Configure the specified Filter operator according to the unit ID given by the execution item.

[0348] Determine the operation performed by the Filter operator according to the opcode given by the execution item, that is, select one of the operations of greater than, equal to, less than, greater than or equal to, less than or equal to, not equal to, logical AND, logical OR.

[0349] The filtering result (the execution result of the execution item) is output through the control signal line for other operators to perform data filtering.

[0350] (2) Optionally, when the execution item is the Project operator opcode: Configure the specified Project operator according to the unit ID given by the execution item.

[0351] Configure the output data sending position according to the destination ID.

[0352] Execute filtering on the input data according to the filtering control signal. The data not filtered is sent to the next-level operator for processing.

[0353] (3) Optionally, when the execution item is the Merge operator opcode: Configure the specified Merge operator according to the unit ID given by the execution item.

[0354] Configure the output data sending position according to the destination ID.

[0355] Filter the input data according to the filter control signal. The data not filtered is merged by the Merge operator, and the conditional data in two columns is merged into one column of data.

[0356] (4) Optionally, when the execution item is the Hash Build operator opcode: Configure the specified Hash Build operator according to the unit ID given by the execution item.

[0357] Filter the input conditional data according to the filter control signal. The unfiltered join conditional data is first subjected to a hash calculation, and a part of the bits of the calculated hash result is selected as the address, and the remaining bits of the data are used as the anti-collision value.

[0358] There is a DDR memory (Cache) externally connected to the FPGA, in which the hash table is stored.

[0359] Build the hash table: Index to a specific hash bucket in the hash table with the aforementioned address, and use the anti-collision value to match whether the condition already exists in the bucket.

[0360] Optionally, if there is no match, add an entry to the bucket, and store the anti-collision value and row information of the conditional data in the entry.

[0361] Optionally, if a match is found, add the row information to the corresponding entry record.

[0362] (5) Optionally, when the execution item is the Hash Probe operator opcode: Configure the specified Hash Probe operator according to the unit ID given by the execution item.

[0363] Configure the position where the output matching row information is sent according to the destination ID.

[0364] Filter the input conditional data according to the filter control signal. The unfiltered conditional data is first subjected to a hash calculation, and a part of the bits of the calculated hash result is selected as the address, and the remaining bits of the data are used as the anti-collision value.

[0365] Query the hash table: Index to a specific hash bucket in the hash table with the aforementioned address, and use the anti-collision value to match whether the condition already exists in the bucket.

[0366] Optionally, if there is no match, the current condition line ends and the next condition line is processed.

[0367] Optionally, if there is a match, the matching line information is retrieved one by one from the table entry record, combined with the input line information to form a line matching data, and sent to the next unit for processing.

[0368] (6) Optionally, when the execution item is the Hash Groupby operator opcode: Configure the specified Hash Groupby operator according to the unit ID given by the execution item.

[0369] Configure the location where the output row index information is sent according to the destination ID.

[0370] Filter the input condition data according to the filter control signal. The condition data that is not filtered is first subjected to a hash calculation, and the calculated hash result is distributed as an index for the agg operator to the specified agg operator.

[0371] (7) Optionally, when the execution item is the Agg operator opcode: Configure the specified Agg operator according to the unit ID given by the execution item.

[0372] Configure the location where the Agg calculation result is sent according to the destination ID.

[0373] Determine the operation performed by the Agg operator according to the opcode given by the execution item, that is, select one of the processing methods of only output, max, min, sum, avg, and count.

[0374] Filter the input data according to the filter control signal. The unfiltered input data performs the selected calculation.

[0375] Optionally, if there is no hash groupby operator in the execution graph, then the agg operator uses the default fixed condition index value.

[0376] Optionally, if the execution graph is configured with a hash groupby operator, then the agg operator uses the index value distributed by the hash groupby operator.

[0377] According to the condition index value, the agg operator queries the hash table.

[0378] Optionally, if the specified table entry does not exist, create the table entry and directly store the data in the table entry space.

[0379] Optionally, if the specified table entry exists, read the data in the table entry space, perform the specified calculation operation on the updated data, and store the result in the table entry space after the calculation is completed.

[0380] When all the input data is finished, the agg operator reads out all the table entry data from the hash table and sends it to the next unit specified by the destination ID.

[0381] (8) Optionally, when the execution item is the Calc operator opcode: Configure the specified Calc operator according to the unit ID given in the execution item.

[0382] Configure the location where the calculation result is delivered according to the destination ID.

[0383] Determine the operation to be performed by the Calc operator according to the opcode given in the execution item, that is, select one of the addition, subtraction, multiplication, and division operations.

[0384] Filter the input data according to the filter control signal. The unfiltered input data performs the selected calculation.

[0385] When the calculation of a row of data is completed, the calculation result is sent to the next unit specified by the destination ID.

[0386] 3. Start the pipeline.

[0387] After the control module completes the configuration of each operator in the pipeline, it starts to execute and begins to fetch the input data.

[0388] 4. Perform accelerated calculation.

[0389] The pipeline actively reads data in batches from the input data sources (Table 0 and / or Table 1), and the reading principle is as Figure 12 shown. The data sequentially passes through the LPE in the pipeline to perform calculations and writes the results to the Cache: Optionally, if there is still data to be processed, repeat step 4.

[0390] Optionally, if all the data has been processed, proceed to step 5.

[0391] Optionally, if an error occurs during the processing, set the task status to "failed" and return to step 1 to continue traversing the task queue.

[0392] 5. Write back the query result and complete the acceleration task.

[0393] Convert the table data in the Cache to the Apache Arrow format.

[0394] Write the above Apache Arrow data to the host cache pointed to by the "result data address" in the above task.

[0395] Update the "status" of the above task to "completed".

[0396] Repeat steps 1 - 5 until all the "pending" tasks in the task queue are processed.

[0397] An embodiment of the present application provides a heterogeneous acceleration method for data query based on FPGA. In this method, on the CPU side, the SQL query plan is converted into an execution graph according to the above specifications, and a query acceleration task is created together with the input data in Apache Arrow format (or other columnar storage formats) required for the query. Then, the FPGA is triggered to execute the acceleration task; on the FPGA side, the acceleration task is executed, that is, an acceleration pipeline is constructed according to the execution graph, the required column parameters are read from the input data into the pipeline for processing, and a columnar storage result table with the same format as the input data is generated and returned to the CPU side, thereby achieving heterogeneous acceleration of data query.

[0398] An embodiment of the present application also provides an efficient data transmission mechanism to avoid the transmission of redundant data. This mechanism uses huge page memory as a shared data buffer to store the input table data in Apache Arrow format (or other columnar storage formats). The "source location" and "data" fields of the execution item indicate which tables and which columns the operator parameters come from. According to this information, the specified data columns can be directly read from the columnar data to participate in the calculation, rather than reading all the table data from the CPU side to the FPGA side, thereby avoiding the transmission of redundant data and improving the data transmission efficiency.

[0399] As Figure 12 shown. Figure 12 There is an input data table tbl stored in the shared memory as shown in the figure. There are 4 columns of data in the table, namely col0, col1, col2, and col3. When the FPGA performs data query, according to the source location 1 and data 1 in the execution graph, only the two columns of data, col1 and col2, can be read from the tbl table, and the data of col0 and col3 are not read, thereby avoiding the redundant transmission of the data of col0 and col3 columns.

[0400] An embodiment of the present application also provides a cache mechanism, which can cache the intermediate operation results inside the FPGA and use them as the input data for the next calculation, avoiding unnecessary data ping-pong between the CPU and the FPGA.

[0401] The technical solutions provided by the embodiments of the present application can at least achieve the following technical effects: 1. Optimize the way of solidifying operators into dynamically reloadable operators, which solves the resource limitation problem to a certain extent and improves the utilization efficiency of FPGA logic units; 2. An efficient data transmission mechanism that accesses on demand, avoiding the transmission of redundant data; 3. Use Cache to cache the intermediate result data, which not only solves the "data ping-pong" problem but also improves the heterogeneous acceleration performance; 4. The FPGA-friendly execution graph mode enables more operations to be executed in parallel, improving heterogeneous acceleration performance; 5. The pipelined processing reduces the memory requirement, thereby reducing the server procurement cost.

[0402] The specific embodiments of the present application have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown to achieve the desired result. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0403] Figure 13 is a schematic structural diagram of an electronic device according to an embodiment of the present application. Please refer to Figure 13 , at the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and a memory. Among them, the memory may include a memory, such as a high-speed random access memory (Random-Access Memory, RAM), and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory, etc. Of course, the electronic device may also include other hardware required for other services.

[0404] The processor, network interface, and memory can be interconnected through an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of representation, Figure 13 only a bidirectional arrow is used in [the figure] to represent it, but it does not mean that there is only one bus or one type of bus.

[0405] The memory is used to store programs. Specifically, the program may include program code, and the program code includes computer operation instructions. The memory may include a memory and a non-volatile memory, and provide instructions and data to the processor.

[0406] The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming a data query device at the logical level. The processor executes the program stored in the memory and is specifically used to perform the following operations: Receive an SQL query plan; Convert the SQL query plan into at least one execution graph; Construct an acceleration task according to the at least one execution graph and the input data tables involved in the SQL query plan; Trigger the FPGA to execute the acceleration task.

[0407] Or specifically used to perform the following operations: Obtain the acceleration task to be processed; Construct a query acceleration pipeline according to the acceleration task; Perform data query according to the query acceleration pipeline.

[0408] The above method executed by the data query device disclosed in the embodiments of the present application Figure 13 can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit in the hardware of the processor or by instructions in software form. The above processor may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. It can implement or execute the various methods, steps, and logic block diagrams disclosed in the present application. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. The steps of the method disclosed in combination with the present application can be directly embodied as being executed and completed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module may be located in a mature storage medium in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor reads the information in the memory and combines its hardware to complete the steps of the above method.

[0409] The electronic device can also execute Figure 4 or Figure 5 the method, and implement the functions of the data query device in Figure 4 or Figure 5 the embodiments shown, which will not be elaborated herein.

[0410] Of course, in addition to the software implementation, the electronic device of the present application does not exclude other implementation manners, such as logic devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or a logic device.

[0411] The present application also provides a computer-readable storage medium storing one or more programs, where the one or more programs include instructions that, when executed by a portable electronic device including a plurality of application programs, can cause the portable electronic device to execute Figure 4 or Figure 5 the method of the illustrated embodiment, and specifically used to perform the following operations: Receive an SQL query plan; Convert the SQL query plan into at least one execution graph; Construct an acceleration task according to the at least one execution graph and the input data table involved in the SQL query plan; Trigger the FPGA to execute the acceleration task.

[0412] Or specifically used to perform the following operations: Obtain an acceleration task to be processed; Construct a query acceleration pipeline according to the acceleration task; Perform data query according to the query acceleration pipeline.

[0413] Figure 14 is a schematic structural diagram of a data query device 140 according to an embodiment of the present application. Please refer to Figure 14 , in a software implementation manner, the data query device 140 may include: a receiving module 141, a conversion module 142, a construction module 143, and a triggering module 144, where: The receiving module 141 receives an SQL query plan; The conversion module 142 converts the SQL query plan into at least one execution graph; The construction module 143 constructs an acceleration task according to the at least one execution graph and the input data table involved in the SQL query plan; The triggering module 144 triggers the FPGA to execute the acceleration task.

[0414] The data query device 140 provided by the present application can also execute Figure 4 the method, and implement the functions of the data query device 140 in Figure 4 the illustrated embodiment. The present application will not elaborate herein.

[0415] Figure 15It is a schematic structural diagram of a data query device 150 according to an embodiment of the present application. Please refer to Figure 15 , in a software implementation manner, the data query device 150 may include: an acquisition module 151, a construction module 152, and a query module 153, where: The acquisition module 151 acquires an acceleration task to be processed; The construction module 152 constructs a query acceleration pipeline according to the acceleration task; The query module 153 performs data query according to the query acceleration pipeline.

[0416] The data query device 150 provided by the present application can also execute Figure 5 the method, and implement the functions of the data query device 150 in the Figure 5 illustrated embodiment. Details are not described herein again in the present application.

[0417] The present application also proposes a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. The computer program can be operated to cause a computer to execute some or all of the steps in the above-mentioned data query method embodiment.

[0418] In summary, the above are only the preferred embodiments of the present application, and are not used to limit the protection scope of the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

[0419] The systems, devices, modules, or units illustrated in the above embodiments may be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0420] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0421] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0422] The various embodiments in this application are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the system embodiment is generally similar to the method embodiment, so the description is relatively simple. For relevant parts, refer to the partial description of the method embodiment.

Claims

1. An execution graph, comprising one or more execution items, each execution item corresponding to an operator, wherein the operator is decomposed from an operator defined in a structured query language (SQL) specification, and each execution item is executed by an FPGA logic unit in a field programmable gate array (FPGA); Among them, The SQL query plan can be converted into at least one execution graph, and the at least one execution graph is used for the FPGA to construct a query acceleration pipeline. The query acceleration pipeline is composed of multiple FPGA logic units in sequence and is used for the FPGA to query the query results corresponding to the SQL query plan.

2. The execution graph of claim 1, wherein each execution item includes the following fields: Type, used to indicate whether the execution item is executed together with the next execution item; Operation code, used to indicate the operator corresponding to the execution item; Unit ID, used to indicate the FPGA logic unit that executes the execution item; Destination ID, used to indicate the FPGA logic unit or address where the execution result of the execution item flows; Output column number, used to indicate the column number of the execution result of the execution item in the result data table, wherein the result data table is used to store the query result corresponding to the SQL query plan; A source location, used to indicate the source of the parameters required for executing the execution item; Data is used to indicate the value of the parameter or the column number of the parameter in the input data table, where the input data table is the data table involved in the SQL query plan.

3. The execution graph of claim 2, wherein the operator comprises at least one of the following types: Filter operator; Hash Build operator; Hash Probe operator; Hash Groupby operator; Calc operator; Agg operator; Project operator; Merge operator; in, Different types of operators correspond to different unit ID ranges, and each unit ID range corresponds to multiple FPGA logic units. The multiple FPGA logic units are used to execute execution items corresponding to one type of operator.

4. The execution graph of claim 3 , wherein for any unit ID range, the number of FPGA logic units corresponding to the unit ID range is related to the usage frequency of the operators corresponding to the unit ID range; Among them, The higher the usage frequency of the operator corresponding to the unit ID range, the greater the number of FPGA logic units corresponding to the unit ID range. The execution graph of claim 4 , wherein the FPGA logic unit is reloadable.

6. The execution graph of claim 2, wherein the source location has one or more fields, and the data has the same number of fields as the source location. Among them, In the case where there are multiple fields of the source location and the data, the multiple data are used to indicate multiple parameters required when executing the execution item, and the multiple source locations are used to indicate sources of the multiple parameters.

7. The execution graph of claim 2 or 6, wherein the source of each source location indication comprises at least one of the following: The input data table; constants; FPGA logic unit.

8. A data query method for an execution graph according to any one of claims 1 to 7, comprising: Receiving an SQL query plan; Converting the SQL query plan into at least one execution graph; Constructing an acceleration task according to the at least one execution graph and the input data tables involved in the SQL query plan; Triggering the FPGA to execute the acceleration task.

9. The method according to claim 8, wherein the converting the SQL query plan into at least one execution graph comprises: Decomposing the operators involved in the SQL query plan into at least one operator; For each operator, converting the operator into an execution item according to the description of the execution items in the execution graph; Generating at least one execution graph according to the execution items obtained by converting the at least one operator.

10. The method according to claim 9, wherein the converting the operator into an execution item according to the description of the execution items in the execution graph comprises: Determining the type value in the execution item according to whether the execution item is executed together with the next execution item; Determining the opcode value in the execution item according to the operator; Taking the ID of an unoccupied FPGA logic unit as the unit ID value in the execution item; Determining the destination ID value in the execution item according to the flow direction of the execution result of the execution item; Determining the output column number in the execution item according to the position of the execution result of the execution item in the result data table; Determining the source position value and the data value in the execution item according to the source of the parameters required when executing the execution item.

11. The method according to claim 10, wherein determining the type value in the execution item according to whether the execution item is executed together with the next execution item comprises: In the case where the execution item is executed together with the next execution item, determining the type value in the execution item as a first preset type value; In the case where the execution item is not executed together with the next execution item, determining the type value in the execution item as a second preset type value.

12. The method according to claim 10, wherein the determining the opcode value in the execution item according to the operator comprises: Obtaining a first correspondence relationship between different pre-determined operators and different opcode values; According to the first correspondence relationship, determining the opcode value corresponding to the operator as the opcode value in the execution item.

13. The method according to claim 10, wherein taking the ID of an unoccupied FPGA logic unit as the unit ID value in the execution item comprises: Obtaining a second correspondence relationship between different types of operators and different unit ID ranges; According to the second correspondence relationship, determining the target unit ID range corresponding to the type of the operator; Selecting an unoccupied FPGA logic unit from the multiple FPGA logic units corresponding to the target unit ID range; Determining the ID of the selected FPGA logic unit as the unit ID in the execution item.

14. The method according to claim 10, wherein the determining the destination ID value in the execution item according to the flow direction of the execution result of the execution item comprises: When the flow of the execution result of the execution item is used as the input data of other execution items, determine the unit ID value in the other execution items as the destination ID value in the execution item; When the flow of the execution result of the execution item is used as the intermediate result cache, determine the cache address as the destination ID value in the execution item.

15. The method according to claim 10, determining the output column number in the execution item according to the position of the execution result of the execution item in the result data table, includes: When the execution result of the execution item is output as a column in the result data table, determine the output column number in the execution item as the column sequence number starting from 0; Wherein, when the execution result of the execution item is not output as a column in the result data table, determine the output column number in the execution item as a first preset value.

16. The method according to claim 10, the determining the source position value and data value in the execution item according to the source of the parameters required when executing the execution item, includes: When the source of the parameters required when executing the execution item is the input data table, determine the source position value in the execution item as a first preset position value, and the data value as the column sequence number starting from 0, wherein the number of the input data tables is one or more, and when the number of the input data tables is multiple, different input data tables correspond to different first preset position values; When the source of the parameters required when executing the execution item is the FPGA logic unit, determine the source position value in the execution item as the ID of the FPGA logic unit, and the data value as a first preset data value; When the source of the parameters required when executing the execution item is a constant, determine the source position value in the execution item as a second preset position value, and the data value as the value of the constant.

17. The method according to claim 8, the constructing an acceleration task according to the at least one execution graph and the input data table involved in the SQL query plan, includes: Apply for an idle acceleration task; When there is an idle acceleration task, apply for a cache; When the cache is successfully applied for, update the cache address to the acceleration task, and the cache address includes an execution graph address, a table data address, and a result data address; Save the at least one execution graph to the cache pointed to by the execution graph address, and save the input data table to the cache pointed to by the table data address.

18. The method according to claim 17, the saving the input data table to the cache pointed to by the table data address, includes: Determine whether the data in the input data table is in Apache Arrow format; When the data in the input data table is in Apache Arrow format, save the data in the data data table to the cache pointed to by the table data address; When the data in the input data table is not in the Apache Arrow format, convert the data in the input data table into data in the Apache Arrow format and then save it to the cache pointed to by the table data address.

19. The method according to claim 17, before applying for an idle acceleration task, the method further includes: Applying for huge page memory; When the huge page memory is successfully applied for, divide the huge page memory into a task queue buffer area and a service data buffer area. The task queue buffer area is used to cache multiple acceleration tasks, and each acceleration task includes a task status, an execution graph address, a table data address, and a result data address. The service data buffer area is used to cache the execution graphs, input data tables, and result data tables of multiple acceleration tasks; Initialize the acceleration tasks in the task queue buffer area to the idle state, and initialize the service data buffer area to the unallocated state.

20. The method according to claim 8, after triggering the FPGA to execute the acceleration task, the method further includes: Poll the status of the acceleration task; When the status of the acceleration task is being processed, continue to poll the status of the acceleration task; When the status of the acceleration task is completed, read the result data from the cache pointed to by the result data address of the acceleration task, and return the result data to the querying party as the query result; When the status of the acceleration task is failed, return the failure information to the querying party.

21. The method according to claim 20, the result data is in the Apache Arrow format; returning the result data to the querying party as the query result includes: When the querying party supports the Apache Arrow format, return the result data to the querying party as the query result; When the querying party does not support the Apache Arrow format, convert the result data into a format supported by the querying party and then return it to the querying party.

22. The method according to claim 20 or 21, the method further includes: Release the cache pointed to by the execution graph address in the acceleration task, and set the execution graph address to a null pointer; Release the cache pointed to by the table data address in the acceleration task, and set the table data address to a null pointer; Release the cache pointed to by the result data address in the acceleration task, and set the result data address to a null pointer; Set the status of the acceleration task to idle.

23. A data query method based on the execution graph according to any one of claims 1 to 7, including: Obtain an acceleration task to be processed; Construct a query acceleration pipeline according to the acceleration task; Perform data query according to the query acceleration pipeline.

24. The method according to claim 23, the constructing a query acceleration pipeline according to the acceleration task includes: Read the execution graph from the cache pointed to by the execution graph address of the acceleration task; For each execution item in the execution graph, configure the FPGA logic unit corresponding to the unit ID in the execution item, determine the operation to be performed by the execution item according to the operation code in the execution item, and configure the output position of the execution result of the execution item according to the destination ID in the execution item; According to the operations performed by each execution item in the execution graph and the output positions of the execution results of each execution item, the configured FPGA logic units are sequentially combined to form the query acceleration pipeline.

25. The method according to claim 23, wherein the data query according to the query acceleration pipeline comprises: Read the corresponding column data from the cache pointed to by the table data address of the acceleration task according to the source position value and the data value of each execution item in the execution graph; Send the column data into the query acceleration pipeline and perform calculations through the FPGA logic units in the query acceleration pipeline.

26. The method according to claim 25, wherein the number of the query acceleration pipelines is one or more, and the multiple query acceleration pipelines are connected in sequence; the method further comprises: In the case where the number of the query acceleration pipelines is one, convert the execution result of the query acceleration pipeline into the Apache Arrow format and write it into the cache pointed to by the result data address of the acceleration task; In the case where the number of the query acceleration pipelines is multiple, convert the execution result of the last query acceleration pipeline into the Apache Arrow format and write it into the cache pointed to by the result data address of the acceleration task, and write the execution results of the other query acceleration pipelines into the internal cache of the FPGA and use them as input data to participate in the execution process of the next query acceleration pipeline.

27. A data query system based on the execution graph according to any one of claims 1 to 7, comprising: A CPU that receives an SQL query plan; Convert the SQL query plan into at least one execution graph; Construct an acceleration task according to the at least one execution graph and the input data table involved in the SQL query plan; Trigger the FPGA to execute the acceleration task; The FPGA that obtains the acceleration task to be processed; constructs a query acceleration pipeline according to the acceleration task; and performs data query according to the query acceleration pipeline.

28. An electronic device, comprising: A processor; A memory for storing executable instructions of the processor; Wherein the processor is configured to execute the instructions to implement the method according to any one of claims 8 to 26.

29. A computer-readable storage medium, when the instructions in the storage medium are executed by a processor of an electronic device, enable the electronic device to execute the method according to any one of claims 8 to 26.

30. A computer program product, the computer program product comprising a non-transitory computer-readable storage medium storing a computer program, the computer program being operable to cause a computer to execute some or all of the steps of the method according to any one of claims 8 to 26.

Images