Methods and systems for providing a context-sensitive, non-intrusive data processing optimization framework

Abstract

A method of performing a data search in a data source is provided. Through the method, an operator optimization module using an intermediate representation of optimized and compiled operators optimizes and compiles operators of a data search pipeline in real time to generate optimized operators for the data search execution, taking into account runtime information and optimization rules. The method can be applied to one operator or multiple operators applied in any order or tree structure according to a query plan determined by the runtime information and the optimization rules.

Description

[0001] This application is a divisional application of the original application with the application number 202180098232.3 and the original filing date of 30 June 2021, the whole content of the original application is incorporated herein by reference. TECHNICAL FIELD

[0002] The present invention relates generally to the field of retrieving and processing information from data sources, and in particular to a method of retrieving information using an operator optimized and compiled based on execution of a data search. BACKGROUND

[0003] As the available data becomes more and more, the demand for optimizing and speeding up data search and access is increasing. Modern database systems can achieve efficient query processing by using cache-efficient algorithms and data structures, but in order to further improve query processing by preventing branch misprediction and cache miss as much as possible, database operators need to be significantly adjusted for CPU efficiency, which can be achieved by converting database queries into optimized machine code.

[0004] In order to process data sources arranged in many different types of columns, any of which can need to be processed at runtime, the data processing pipeline of modern database systems must rely on general-purpose logic. In order to manage the spectrum of data sets to be processed, many for loops are usually generated, nested in branches.

[0005] Generally, in order to maximize the performance of search execution and optimization using target computers, compiler passes can be applied to optimize code libraries. For cases where data processing logic is usually written in programming languages or structured query language (SQL), compiler passes basically act as interpreters of code libraries.

[0006] Existing methods generate code based on submitted data processing logic (i.e. SQL statements), but once the data processing logic is submitted, most variable aspects of the processing flow (e.g. data types, number of columns, and statistics) are fixed. Since the code used before optimization is general-purpose, this can result in a large number of unreachable code sections. Since database architects must provide general-purpose coding to achieve flexibility, but they cannot develop highly specific code due to time and resource constraints, there is a trade-off.

[0007] There is a need for methods and systems to eliminate or reduce one or more limitations of the prior art by optimizing operators in the data search pipeline for each data search.

[0008] This background information is provided to reveal information that can be pertinent to the present invention. It is not necessarily admitted that any of the above information constitutes prior art for the present invention. SUMMARY

[0009] In some examples of the invention, the operators of a data search pipeline can be prepared by a developer and compiled into intermediate representation (IR) code before the data search is invoked. At the time of executing the data search, the parameters of the data query and the data query processing engine and the optimization rules can be used to optimize the IR encoded operators of the data query being executed and compile them for the query processing engine hardware being used. In addition, to facilitate optimization, the functions of the operator files to be optimized can be annotated or tagged.

[0010] In embodiments, the data search includes runtime optimization and compilation of the pipeline operators and it can be executed in less time than a data search that uses operators that are not optimized and compiled for the data search at runtime. In other words, since the runtime optimization and compilation workflow according to embodiments can be executed fast enough, if a data search is executed with pre-compiled operators that are not optimized and compiled for the data search, the data search using this runtime optimization and compilation and using the resulting optimized operators takes less time than the data search would take if it was executed with the pre-compiled operators that are not optimized and compiled for the data search.

[0011] In embodiments, the operators can be configured in a high level programming language and compiled into an intermediate representation (IR) version. Annotations can be used to tag functions that are specialized when the operators are optimized and compiled for the data search at runtime. The optimization of the operators can use runtime information and optimization rules. When the data search is executed, the operators needed to complete the data search can be optimized, compiled, and executed to complete the data search.

[0012] The system that executes the data search according to embodiments should be able to compile the IR encoded operators using runtime information of the query processing engine that executes the data search. The system and the query processing engine can be separate entities or combined into one entity with common components.

[0013] Examples of the invention include a method of executing a data search that obtains at least one operator, runtime information of the data search, optimization rules, and by optimizing and compiling the at least one operator according to the runtime information of the data search and the optimization rules, obtains at least one optimized and compiled operator. The method then executes the data search using the at least one optimized and compiled operator.

[0014] In the above examples, the operators can be configured in a high level programming language and compiled into intermediate representation code of the at least one operator by a front end compiler.

[0015] In any of the above examples, the operators can include an annotation marker function that is specialized when at least one of the operators is optimized and compiled for the data search at runtime.

[0016] In any of the above examples, the runtime information can include data layout.

[0017] In any of the above examples, the runtime information can include data statistics.

[0018] In any of the above examples, the runtime information can include hardware information of the query processing engine.

[0019] In any of the above examples, the optimization rules can include global algorithms.

[0020] In any of the above examples, the optimization rules can be based on the runtime information.

[0021] In any of the above examples, the optimization rules can include algorithms specific to at least one of the operators.

[0022] In any of the above examples, optimizing the operators can include applying at least one optimization to code of the operators to improve efficiency of executing the data search.

[0023] In any of the above examples, optimizing the operators can be performed after invoking the data search and before the data search is completed, such that executing the data search includes executing the at least one optimized operator.

[0024] In any of the above examples, executing the data search can include optimizing and compiling a plurality of operators that can be subsequently executed by the data search according to a query plan defined by the optimizing and compiling.

[0025] Some examples of the disclosure include a system for executing a data search. The system includes at least one processor, at least one data storage medium, a query processing engine, a compiler, and at least one operator file configured in a programming language; wherein, upon execution of the query processing engine, the compiler is configured to obtain at least one optimized and compiled operator file by optimizing and compiling the at least one operator file according to the runtime information of the data search and according to optimization rules; and wherein executing the data search includes executing the at least one optimized and compiled operator file.

[0026] In the above examples, the at least one operator file can be configured in a high-level programming language and compiled into intermediate representation code prior to being optimized and executed by the query processing engine.

[0027] In any of the above examples, the system can further include an operator specialization module to receive at least one operator file and the runtime information from the query processing engine; and to optimize and compile the at least one operator file based on the runtime information.

[0028] In any of the above examples, the operator file can be configured in a high level programming language and compiled into intermediate representation code.

[0029] In any of the above examples, the operator file can include an annotation marker function that is specialized when the operator encoded in the operator file is optimized and compiled for the data search at runtime.

[0030] In any of the above examples, the runtime information can include data layout.

[0031] In any of the above examples, the runtime information can include data statistics.

[0032] In any of the above examples, the runtime information can include hardware information.

[0033] A computer program can include instructions that, when executed by a computer, can cause the computer to perform the above method.

[0034] A computer readable medium can include instructions that, when executed by a computer, can cause the computer to perform the above method. BRIEF DESCRIPTION OF DRAWINGS

[0035] Figure 1 is a block diagram of a data search processing pipeline according to the prior art.

[0036] Figure 2a is a block diagram of compiling a high level encoded operator into a compiled operator according to the prior art.

[0037] Figure 2b is a block diagram of compiling a high level encoded operator into a compiled operator according to an embodiment of the present invention.

[0038] Figure 3 is a block diagram of a process in which an operator can be specialized for a query according to an embodiment of the present invention.

[0039] Figure 4 is a block diagram of a process in which an operator can be specialized for a query according to an embodiment of the present invention.

[0040] Figure 5a is a block diagram of a method for generating an optimized operator according to an embodiment of the present invention.

[0041] Figure 5bis a block diagram of a data search processing pipeline according to an embodiment of the application, in which optimized operators can be used in the data search processing pipeline.

[0042] Figure 6 is a block diagram of a pre-compile stream and a runtime specialization stream for generating optimized operators according to an embodiment of the application.

[0043] Figure 7 is a flowchart of a method involved in preparing operators to be used when executing a query according to an embodiment of the application.

[0044] Figure 8 is a block diagram of an electronic device within a computing and communications environment that can be used to implement the apparatus and methods according to representative embodiments of the application.

[0045] Throughout the drawings, identical reference characters signify identical features. DETAILED DESCRIPTION

[0046] Modern analytic applications, such as data search and data processing software, can combine multiple functions from different libraries and frameworks to build increasingly complex workflows. In the case of data search applications, functions can be organized as “operators” that can be organized in a sequence, a tree, or more generally a query plan. Even though each function or operator can be implemented individually for high performance, the performance of the combined workflow is typically an order of magnitude below the hardware limit. Essentially, this is due to a lack of hardware-specific support, a lack of specialized operators for data operations, and high cost of data transfer. To address the above issues, embodiments include a framework for data-intensive applications that can provide multi-level, real-time acceleration, optimization, and compilation to support dynamic user-defined functions.

[0047] Embodiments can be adaptive, flexible, and extensible. In addition, it can be incrementally integrated into existing frameworks such as openLooKeng, Apache Spark, etc. without modifying the front-end application programming interfaces (APIs) of the existing frameworks. Embodiments have the ability to use runtime information as well as out-of-band information to enable real-time code compilation.

[0048] To retrieve data more efficiently, code generation with query-specific information can be used. For example, code generation can support user deletions of conditions, propagation of constant offsets, pointers, etc., and use of inline virtual function calls.

[0049] Figure 1A data search processing pipeline is shown according to existing approaches. For a given data source 105, a data search can activate an operation pipeline 110, each operation pipeline processing data into a new form until the requested data is generated. For example, a first operation can be reading (115) data, a second operation can be filtering (120), a third operation can be projecting (125), a fourth operation can be aggregating (130), and a final operation can be shuffling (135). Each operation can be viewed as a step towards presenting the requested data 140 from the original data set 145 of the data source 105. In some cases, code generation (150) can support users to remove conditions, propagate constant offsets, pointers, etc., and use inline virtual function calls.

[0050] One approach is to support code generation using specific data processing jobs. This can require fewer branches, fewer instructions, and support faster execution. However, for this specific code generation, the use of expert domain knowledge is typically complex, error-prone, and extremely difficult to debug. Thereafter, in practice, it can become very difficult to maintain and extend such query compilers over time as the complexity of the query compiler code base can increase to unmanageable levels as more and more optimizations are added.

[0051] Embodiments include an architectural framework that makes it easier to build and extend query optimizers and compilers, ultimately supporting programmers to create more sustainable compiler-based data management systems and dynamically define and customize processing of big data. This framework can improve data retrieval performance and hardware usage that is not possible with existing approaches.

[0052] Embodiments include a modular query compiler that can be described using several levels of abstraction. Each level of abstraction can be responsible for expressing a subset of optimizations. This can separate the concerns of different types of code optimizations. Further, by multiple levels of abstraction, embodiments can support a high-level query to be gradually transformed into low-level code, thereby supporting a more controlled code generation approach.

[0053] Figure 2a A high-level encoding operator is shown being compiled into a compiled operator according to existing approaches. A high-level (HL) language, such as SQL 205, can be used to create generic operator code 210 so that the compiled operator 212 can be similar for any query. Neither the initial operator code 210 nor the compiled operator 212 are dependent on the search. Although Figure 2aThe compilation can represent a single operator, but in practice, a SQL query can generate a series of operators for performing retrieval, filtering, transformation, and perhaps other operations. For example, if the query is to identify database employees with an age less than 25, three operations and corresponding operators can be required: i. retrieve data from the database; ii. filter the data by age; iii. filter the name from the output of the previous operation.

[0054] Figure 2b Compiling high-level encoding operators into compiled operators is shown according to embodiments of the application. A SQL language 205 or other high-level (HL) code can be used to write the operator code 210. However, embodiments relate to optimizing the operator for a given input data query, and thus, information 220 including data types, statistics of the data being queried, and SQL parameters can be received by an operator optimizer module 225 and applied to the operator code 210 before fully compiling the operator code 215 in order to optimize the operator for the input data query.

[0055] In one embodiment, the method can be using just-in-time compilation such that the operator is optimized and compiled during query execution in order to generate results faster than if the operator were generic or unoptimized. The optimization step can include designing a query plan that describes the flow of operations to be applied to a data source by the operator, selecting an algorithm for the operator, generating a specialized operator, and optionally, a user can define how and when to apply the operator in the query plan (i.e., injecting the operator). At this point, the database management system executing the query can execute the query plan using the injected optimized operator. Furthermore, to optimize the operator, embodiments can use runtime information.

[0056] To select an algorithm for the operation, embodiments can optimize the combination of the operator, data structure, access pattern, and operation parallelism. To select the appropriate method, embodiments can consider various inputs, including information from the data engine processing the data query, or information from the data search, such as data types, statistics, and SQL parameters. For example, using some data types can support the selection of some hash algorithms in the operator algorithm (i.e., a probed operator). This is more efficient than using a traditional filter that requires reading a single row. Furthermore, embodiments can use statistics to select a parallelism level and operator fusion mechanism.

[0057] Figure 3A process is shown in which an operator can be specialized for a query according to embodiments of the present application. At any time prior to a data search, an operator for performing an operation on data 302 in a database can be written in high-level (HL) code, such as C, C++, Rust, or another high-level code as a high-level coded operator 305. It can then be compiled into intermediate representation (IR) code in a template file called a template or including an IR coded operator 310 in an operator.tpl file, where the “.tpl” extension refers to a template file type. As IR code, the operator can be received (312) at an operator specialization module 315. When a data search 360 is performed by a query processing engine 320, it can also trigger the performance of operator specialization 345, where the operator specialization module 315 can further consider metadata from the data search 360 and from the query processing engine 320, which can be a structured query language (SQL) engine 320 that processes (325) data queries. The metadata can include parameters (i.e., “params” or system information) 330 of the query processing engine, data statistics 335 (i.e., statistical information about the data or data search), and data layout 340 of the data or data search. The IR coded operator 310 in the operator specialization module 315 can then be optimized for the data engine 320 and data search 360 by implementing an application programming interface (API) that enables just-in-time (JIT) compilation and optimization, thereby customizing (i.e., “specializing”) the operator for the query. This can be referred to as JIT API specialization 350. The result can be a shared in-memory operator file (i.e., operator.so) that is specialized for the query, which can be generated prior to completion of the data search to improve the efficiency of the data search. The resulting operator.so file including the optimized operator 355 can be placed in a data search pipeline 365 as a specialized operator among other operators 368, which can enable the data processing pipeline to be performed faster than if the operators were not specialized. The data processing pipeline can include multiple operators 368 in sequence (as shown) or in various other tree structures (not shown) that support generation of a final result 370. The optimized operator file 355 can also be shared and used as needed with other similar queries that are performed in parallel or in the future, and thus, it can be referred to as an “in-memory operator.so” file 355, where the “.so” extension refers to a shared object file type. Figure 3 The optimized operator file 355 can also be shared and used as needed with other similar queries that are performed in parallel or in the future, and thus, it can be referred to as an “in-memory operator.so” file 355, where the “.so” extension refers to a shared object file type.

[0058] Figure 4 Another diagram of the process to which an operator can be specialized for a query according to embodiments of the application. Initially, the operator can be written in high-level (HL) code, such as C++, Rust, or other high-level code, and is referred to as a HL-encoded operator 305, or more specifically, a "template.c" file, a "template.cpp" file, or a "template.rs" file. It can then be compiled (307) into intermediate representation (IR) code in a file referred to as a compiled template, which includes an IR-encoded operator 310. These files are not created during data search execution, but are prepared by a developer in anticipation of a data search, so that they are ready for further customization when the data search is executed. In other words, the files including the IR-encoded operator can be prepared at any time prior to the data search, and only when the data search is executed are the IR-encoded operators of the files optimized and compiled for data search execution. In some embodiments, the HL-encoded operator 305 is prepared (405) into an IR-encoded operator 310 that has been prepared for optimization for an anticipated query, so as to be used by an operator specialization module 315. Embodiments include preparation (405) of the IR-encoded operator 310, which can further optimize in conjunction with optimization (350) of the IR-encoded operator 310 for the data search. Embodiments can include an operator specialization module 315 for optimizing the IR-encoded operator 310. It will be appreciated that embodiments can be combined.

[0059] Once the IR-encoded operator 310 is prepared (405) for optimization, it can be received (312) by, i.e., loaded into, an operator specialization module 315, which can optimize (350) the IR-encoded operator 310 into an optimized operator 355 for use with a given data engine for a data query or data search, or in other words, an optimized operator 355.

[0060] In one embodiment, optimization of the IR-encoded operator 310 can be performed in more than one step. One step can be to take into account metadata from the query and the query processing engine, i.e., the hardware involved in the search. This step can be referred to as "hardening" 410, which is essentially optimizing the operator for the hardware of the query processing engine. Hardening involves making certain variables of the IR-encoded operator 310 concrete, defining them, or giving them more accurate values, which were previously unknown. The metadata can include parameters 330 of the data search and query processing hardware being used, statistics 335 of the data search, and data layout 340 of the data search.

[0061] If the IR code includes a virtual function reference to a specific library function, the compilation process can include replacing the virtual function reference with the actual code in the library, and the hardening process can be applied after this replacement. The process of hardening (410) can be considered input 415 to the metadata from query to operator specialization module 315.

[0062] To implement a data search according to an embodiment, in which the operator is particularly suited to the search itself, the embodiment can include two complementary workflows. One workflow can be performed during a project build, prior to the execution of the data search, and it can include the generation of an operator template created by a developer to accommodate certain data searches. The subsequent and complementary approach can be performed after the data search but prior to its completion, and it can include optimizing the operator based on characteristics of the data search itself. In another embodiment, this data search based optimization can be performed and completed in a short time between the start of the data search execution and the generation of the results, using the optimized operator to generate the results.

[0063] Figure 5a A method of generating an optimized operator according to an embodiment is shown. The method can be considered two workflows: a pre-compile workflow 505 and a runtime specialization workflow 510. As an initial step that can be performed prior to the execution of a data search, a developer can create an operator in HL code, such as C, C++, Rust, or other HL code. The resulting file can be referred to as an HL-encoded operator 305. Using an operator compiler 515, such as Clang or other, which in turn can use a global compiler 520, the HL-encoded operator 305 can be compiled into an IR-encoded operator 310. In one embodiment, the HL-encoded operator 305 can be written so that once compiled in the IR-encoded operator, it can accommodate various anticipated data searches from a query processing engine 320. A copy of the IR-encoded operator 310 can be kept (517) in a pre-optimized state, and it can be saved to a file or maintained in a registry, such as can be made available on demand, for further use.

[0064] At runtime, when a data search is invoked, another workflow can be executed and it can be identified as a runtime specialized flow 510. Upon execution of the data search, the operator specialization module 315 according to embodiments can receive (312) an IR-encoded operator according to embodiments. The operator specialization module 315 can also receive metadata from the data search itself, which can be used to specialize (i.e., customize or adapt) the IR-encoded operator 310. The metadata can be provided by the query processing engine 320 that executes the data search. The query processing engine 320 can include a metadata manager 525, a statistics manager 530, and a system information manager 535, which can provide the data layout 340, the data statistics 335, and the system information 330, respectively, to the operator specialization module 315 of embodiments.

[0065] The operator specialization module 315 according to embodiments can also receive (540) optimization rules 545, which can include global algorithms and algorithms specific to some operators.

[0066] In one embodiment, once the operator specialization module 315 receives (312) the IR-encoded operator 310, the system information 330, the data statistics 335, the data layout 340, and the optimization rules 545, the IR-encoded operator 310 can be compiled with a global compiler 520. In one embodiment, the global compiler 520 can be written using the LLVM 550 or GCC infrastructure, or another compilation infrastructure can be used by one embodiment. The compilation process can include applying optimizations to the IR-encoded operator 310 that are specific to the data received, especially specific to the data provided by the search requested by the query processing engine 320. Because it is performed after the search request, it can be referred to as just-in-time (JIT) compilation, and because its result can include an operator that is specialized for the specific search request, the compiler can be said to specialize the IR-encoded operation for the specific data search. For these reasons, the compilation in this step can be referred to as a step of JIT specializing and compiling (555) the IR-encoded operator 310.

[0067] In one embodiment, after an IR-encoded operator is received (213) and just-in-time (JIT) specialized and compiled (555) by the operator specialization module 315, the operator specialization module 315 can receive (560) the resulting file again. The compiling (555) effectively corresponds to the creation of an optimized operator 355. The specializing and compiling (555) can convert the IR-encoded operator to an optimized operator that is compiled for a specific target hardware 565 of the query processing engine 320, such as a central processing unit (CPU), a graphics processing unit (GPU), a tensor processing unit (TPU), a field programmable gate array (FPGA), or other hardware. The runtime specialization flow 510 according to the described embodiments can take as input an IR-encoded operator 310 and generate as output an optimized operator 355 that is specialized for a data search performed by the query processing engine 320 and encoded in the machine language of the target query processing engine 320 (i.e., compiled). Moreover, in an embodiment, this generation of an optimized operator according to the embodiments can be shorter in time than a data search using an unoptimized operator according to the embodiments.

[0068] Once the optimized operator 355 is generated in the pre-compile flow 505 and the runtime specialization flow 510 according to the embodiments, it can be used by the query processing engine 320 as part of a pipeline 365 of operators to perform a data search.

[0069] Figure 5b The optimized operator is shown, and it can be used in the data search processing pipeline 365 shown in Figure 3 The typical operations in a query processing engine data processing pipeline can include filtering 570, projection 575, aggregation 580, sorting 585, and other operations, and these operations can be performed in various orders or tree structures. In one embodiment, the order and tree structure of any of these operations can be replaced or defined by the optimized operator 355 created (350) by the pre-compile flow 505 and the runtime specialization flow 510 according to one embodiment.

[0070] By optimizing query operations at very low levels (i.e., using IR or machine-level encoding) and, thus, the query itself, embodiments can adapt query execution to the micro-architecture of a particular machine. Queries optimized using this low-level code optimization compilation, which also takes into account runtime data information, can be considered to be based on machine-level programming. These queries can be categorized by taxonomy that describes their results in terms of communication constraints and other hardware-related constraints.

[0071] Embodiments can include some specialization modules for performing some steps of the runtime specialization flow 510. Further, the pre-compiled flow 505 and the runtime specialization flow 510 can each handle multiple operators at the same time, not just one operator as shown for simplicity in Figure 5a and Figure 5b one operator in FIG. 5B for simplicity.

[0072] Figure 6 The pre-compiled flow 505 and the runtime specialization flow 510 according to embodiments are shown. To implement embodiments, a developer can initially configure and write one or more operators in a high-level programming language 305, such as C, C++, Rust, or another programming language. Once written, the developer can use an operator compiler frontend 515, such as Clang (depending on the compiler infrastructure used), to compile the HL-encoded operators 305 into IR-encoded operators 310. In the HL-encoded operators 305, the developer can specify which functions can involve specialization of the operator specialization module 315 by annotating the operator specialization module 315. For example, if the compiler to be used is built with the LLVM infrastructure, the annotations can be Clang annotations. The annotations can mark functions so that, once compiled into IR-encoded operators 310, the operator specialization module 315 can identify the annotated functions during the JIT specialization and compilation phase 555. The specialization process of these functions can be customized programmatically, which maps input and context information to specific optimization rules.

[0073] During runtime specialization flow 510, IR-encoded operators 310 invoked by the query can be received 312 by the operator specialization module 315 using a loading module called "operator loader" 605. In other words, during query / job execution, the operators required for the query / job are received in IR form ("IR template file") and executed by the operator loader portion of the IR code module, which can be used by the compiler. When the query processing engine 320 requests a data query or data search, runtime information 610 can also be provided (615) to the operator specialization module 315. In other words, during query / job execution, the query processing engine can provide runtime information about at least one of data layout, data statistics, and system information. This can generally be received (540) by the operator specialization module 315, or more specifically, it can be received (610) by a specialization module called hardening module 620, as further described below. Runtime information 610 may include information describing the system hardware 330, information about the data layout 340 of the query, and statistical information about the data 335.

[0074] The parameters and variables of the operator specialization module 315, which has already received (i.e., loaded) the IR-encoded operator 310, can be replaced by the parameters and variables of the runtime information 610 through a process that can be called hardening 615 and executed by a module called "hardening module" 620. Since the operator specialization module 315 goes through different stages, each stage can be identified differently, so that when the operator specialization module 315 receives the IR-encoded operator 310 through the loading module 605, the operator specialization module can be called the operator IR module, the IR operator module, or simply IR module 625, and after being hardened (615) by the hardening module 620, it can be called the hardened IR module 630. At this point, compilation 555 can be executed by the just-in-time (JIT) compilation module 635. The JIT module 635 is a compiler used for JIT compilation of the hardened operator IR module and applying rule-based optimizations to further optimize the code, remove unreachable code, remove unnecessary branches, apply function inlining, etc. Because compilation should be performed after the data query is initiated, the process of applying optimization and executing compilation can be referred to as just-in-time (JIT) compilation. During compilation 555, optimization of IR-encoded operators can be considered using optimization rule 545, which can be applied (555) to IR-encoded operators 310 by JIT module 635. Optimization rule 545 can include global configuration and session values, configuration and session values ​​specific to one or more operators, and configuration and session values ​​specific to the target hardware 565 of the query processing engine performing the data search. The operator code obtained through optimization and compilation 555 (including optimized operators 355) can be configured with global or operator-specific session and hardware values.

[0075] Optimizations applied to operators in IR code using (555) can include removing unreachable code, removing unnecessary branches, function inlining, and other optimizations. The just-in-time (JIT) compilation module 635 that performs optimizations on IR-encoded operators can be referred to as the JIT module 635. For example... Figure 6 As shown, the output of the process is one or more optimized operators 355 designed by the developers through HL code 305 (which are optimized at the IR level according to optimization rules 545 and runtime information 610 and compiled for target hardware 565 (555)), that is, one or more optimized operators 355 in the target machine code, which can be used in the processing pipeline 365 of data search performed by the query processing engine 320.

[0076] Figure 7 This is a flowchart of the steps involved in preparing an operator to be used when executing a query, according to an embodiment. Initially, the operator specialization module 315 may receive a pre-compiled IR-encoded operator template 312. If step 705 is yes, the received IR-encoded operator 310 has dependent modules. Dependent modules refer to static functions or library dependencies that need to be generated (i.e. emitted) with the operator. The operator specialization module 315 may also receive (710) pre-compiled IR-encoded dependent modules. If, in step 715, a specialization value is available for function parameters in the operator, such as data layout information and input / output information, the operator specialization module may replace (720) them with the specialization value. If, in step 725, there is a specialization statistic 335 for the input data of the query (i.e., the data defining the query being processed), the operator specialization module may replace (730) the predefined statistical value in the empty statistics object in the IR-encoded operator.

[0077] The operator specialization module 315 can also receive a global optimization configuration (735). If an operator-specific optimization exists in step 740, the operator specialization module can override the optimization (745) with the operator-specific optimization.

[0078] In one embodiment, the operator specialization module can prepare for JIT compilation (750) and update the IR code based on optimizations defined in the preceding steps. The compilation process may include or supplement with removing unreachable code, removing unreachable branches, adding logic to bypass (i.e., short-circuit) unused portions of code that will not be executed, and other optimizations based on received information (e.g., information from statistics object 755). If the query processing engine in step 760 involves special hardware, such as a field-programmable gate array (FPGA), graphics processing unit (GPU), or tensor processing unit (TPU), the compilation process may include generating machine code 760 for the special hardware or supplementing that generation 760. Otherwise, it may be sufficient to generate (765) machine code for the default target (e.g., the local machine).

[0079] The implementation supports compiler optimizations available in current query compilers, but also supports optimizations that have not yet been developed. More importantly, the implementation provides programmers with a high degree of flexibility not available in existing query compiler implementations.

[0080] The implementation enables the integration and support of hardware-specific solutions, as well as flexible data processing capabilities, without having to redesign the overall compilation flow of queries.

[0081] Advantages of the implementation can include user-defined optimizations, customizability, and maintainability. The implementation can use runtime information 610 to further optimize code 310, which ultimately leads to better utilization of hardware resources 565 and faster operation of the node cluster threatening the big data system 320.

[0082] The embodiment includes the use of user-generated operators 310, which are prepared for execution as pre-generated operators that can be dynamically optimized during runtime when performing data searches. This can meet user-specific needs and achieve a degree of optimization, flexibility, and user-friendliness, which is an improvement over general-purpose operators in the prior art.

[0083] The embodiments include a monitoring system for collecting data from queries, jobs, and systems, and metadata information of database data that can be consumed by the query optimizer for enabling context-sensitive code generation and for optimizing data processing pipelines.

[0084] The implementation includes a pre-optimizer algorithm that can select appropriate optimization methods and operators for a query based on runtime information collected by a monitoring system.

[0085] The implementation includes secondary optimizations for hardware-specific contexts to support the integration of hardware-specific optimization techniques that cannot be achieved through normal means without manual adjustments. For example, if any of the CPU, GPU, TPU, or FPGA platforms are available, ready to be used, and based on the data to be consumed, the optimizer can use them.

[0086] The embodiments include combinations of the described methods and systems, which generate and execute optimized machine code for selected targets using a just-in-time compiler.

[0087] The implementation may store optimized code, including operators optimized according to the implementation, in a cache for possible subsequent reuse.

[0088] Figure 8 This is a block diagram of an electronic device (ED) 952 shown within a computing and communication environment 950. The electronic device 952 can be used to implement the devices and methods disclosed herein. The electronic device 952 typically includes a processor 954, such as a central processing unit (CPU), and may also include a dedicated processor, such as a graphics processing unit (GPU), tensor processing unit (TPU), field-programmable gate array (FPGA), or other such processor; a memory 956; a network interface 958; and a bus 960 for connecting the components of the ED 952. Optionally, the ED 952 may also include components such as a mass storage device 962, a video adapter 964, and an I / O interface 968 (shown in dashed lines). The ED 952 according to embodiments may also include a cache.

[0089] Memory 956 may include any type of non-transitory system memory readable by processor 954, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or combinations thereof. In one embodiment, memory 956 may include more than one type of memory, such as ROM used at power-on and DRAM storing programs and data used during program execution. Bus 960 may be one or more of several bus architectures of any type, including a memory bus or memory controller, a peripheral bus, or a video bus.

[0090] The electronic device 952 may also include one or more network interfaces 958, which may include at least one of wired network interfaces and wireless network interfaces. Figure 7 As shown, network interface 958 may include a wired network interface for connecting to network 974, and may also include a wireless access network interface 972 for connecting to other devices via a wireless link. Network interface 958 enables electronic device 952 to communicate with remote entities, such as entities connected to network 974.

[0091] Mass storage 962 may include any type of non-transitory storage device for storing data, programs, and other information, and allows access to the data, programs, and other information via bus 960. For example, mass storage 962 may include one or more of a solid-state drive, hard disk drive, disk drive, or optical disk drive. In some embodiments, mass storage 962 may be located remotely from electronic device 952 and may be accessed via a network interface such as interface 958. In the illustrated embodiment, mass storage 962 differs from memory 956, which includes mass storage 962, and typically performs storage tasks compatible with higher latency, but its volatility is typically low or nonexistent. In some embodiments, mass storage 962 may be integrated with heterogeneous memory 956.

[0092] In some embodiments, electronic device 952 may be a standalone device, while in other embodiments, electronic device 952 may be located within a data center. In the art, a data center can be understood as a collection of computing resources (typically in the form of servers) that can be used as collective computing and storage resources. Within a data center, multiple servers may be connected together to provide a pool of computing resources, on which virtualized entities can be instantiated. Data centers may be interconnected to form a network comprising pools of computing and storage resources interconnected by connectivity resources. Connectivity resources may be physical connections such as Ethernet or optical communication links, and in some embodiments, may also include wireless communication channels. If two different data centers are connected via multiple different communication channels, the links can be grouped together using any of a variety of techniques, including forming a link aggregation group (LAG). It should be understood that any or all computing resources, storage resources, and connectivity resources (as well as other resources within the network) can be partitioned across different subnets, in some cases, in the form of resource slices. Different network slices can be created by slicing resources across multiple connected data centers or other sets of nodes.

[0093] In an embodiment, electronic device 952 may be used to compile HL and IR codes, to apply optimizations to IR codes, to store data, and to process data queries through pipelines of operators and / or optimized operators according to the embodiment.

[0094] An example of the present invention includes a method for performing a data search, the method comprising: obtaining at least one operator; obtaining runtime information of the data search; obtaining optimization rules; optimizing and compiling the at least one operator according to the runtime information of the data search and the optimization rules to obtain at least one optimized and compiled operator; and performing the data search using the at least one optimized and compiled operator.

[0095] In the example above, the operators can be configured using a high-level programming language and compiled by a front-end compiler into intermediate representation code of the at least one operator.

[0096] In any of the above examples, the operator may include a comment marking function that is specialized when at least one operator is optimized and compiled at runtime for data searching.

[0097] In any of the examples above, runtime information may include data layout.

[0098] In any of the examples above, runtime information may include data statistics.

[0099] In any of the examples above, runtime information may include hardware information about the query processing engine.

[0100] In any of the examples above, the optimization rules may include a global algorithm.

[0101] In any of the examples above, the optimization rules can be based on runtime information.

[0102] In any of the examples above, the optimization rules may include algorithms specific to at least one operator.

[0103] In any of the above examples, optimizing an operator may include applying at least one optimization to the operator's code to improve the efficiency of data retrieval when executing the operator.

[0104] In any of the examples above, the optimization operator can be executed after the data search is invoked and before the data search is completed, such that performing the data search includes executing at least one optimization operator.

[0105] In any of the examples above, performing a data search may include optimizing and compiling multiple operators, which can then be executed by the data search according to a query plan defined by the optimization and compilation.

[0106] Some examples of the present invention include a system for performing a data search, comprising: at least one processor, a data storage medium, a storage medium for a query processing engine, a storage medium for a compiler, and a storage medium for at least one operator file configured in a programming language; wherein, when the query processing engine is executed, the compiler is configured to obtain at least one optimized and compiled operator file by optimizing and compiling the at least one operator file according to the runtime information of the data search and according to optimization rules; and wherein performing the data search includes executing the at least one optimized and compiled operator file.

[0107] In the example above, at least one operator file can be configured with a high-level programming language and compiled into intermediate representation code before being optimized and executed by the query processing engine.

[0108] In any of the above examples, the system may further include an operator specialization module, which is used to receive at least one operator file and the runtime information from the query processing engine; and to optimize and compile at least one operator file based on the runtime information.

[0109] In any of the examples above, the operator file can be configured using a high-level programming language and compiled into intermediate representation code.

[0110] In any of the above examples, the operator file may include comment marker functions that are specialized when the operators encoded in the operator file are optimized and compiled at runtime for the data search.

[0111] In any of the examples above, runtime information may include data layout.

[0112] In any of the examples above, runtime information may include data statistics.

[0113] In any of the examples above, runtime information may include hardware information.

[0114] A computer program may include instructions that, when executed by a computer, cause the computer to perform the method according to any one of claims 1 to 12.

[0115] The computer-readable medium may include instructions that, when executed by a computer, cause the computer to perform the method according to any one of claims 1 to 12.

[0116] Embodiments have been described above in conjunction with various aspects of the present invention, and these embodiments can be implemented based on these aspects. Those skilled in the art will understand that embodiments can be implemented in conjunction with the aspects described therein, but may also be implemented together with other embodiments of that aspect. It will be apparent to those skilled in the art that embodiments are mutually exclusive or incompatible. Some embodiments may be described in conjunction with one aspect, but may also be applicable to other aspects, as will be apparent to those skilled in the art.

[0117] Although the invention has been described with reference to specific features and embodiments thereof, it will be apparent that various modifications and combinations can be made without departing from the scope of the invention. Therefore, the specification and drawings are simply to be regarded as a description of the invention as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations, or equivalents that fall within the scope of the invention.

Claims

1. A method for performing data search, characterized in that, The method includes: Obtain at least one operator, wherein the at least one operator is configured in a high-level programming language and compiled into intermediate representation code by a front-end compiler; the at least one operator includes a comment marking function, which is specialized when the at least one operator is optimized and compiled for the data search at runtime; Obtain the runtime information of the data search; Obtain optimization rules; Based on the runtime information and the optimization rules, optimize and compile the at least one operator to obtain at least one optimized and compiled operator; The data search is performed using at least one of the optimized and compiled operators.

2. The method according to claim 1, characterized in that, The runtime information includes the data layout.

3. The method according to claim 1, characterized in that, The runtime information includes data statistics.

4. The method according to claim 1, characterized in that, The runtime information includes hardware information of the query processing engine that performs the data search.

5. The method according to claim 1, characterized in that, The optimization rules include a global algorithm.

6. The method according to claim 1, characterized in that, The optimization rules are based on the runtime information.

7. The method according to claim 1, characterized in that, The optimization rules include algorithms specific to the at least one operator.

8. The method according to claim 1, characterized in that, Optimizing the at least one operator includes applying at least one optimization to the code of the at least one operator, which improves the efficiency of data searching when performing the at least one operator.

9. The method according to claim 1, characterized in that, The optimization of the at least one operator is performed after the data search is invoked and before the data search is completed, such that performing the data search includes performing the at least one optimized operator.

10. The method according to claim 1, characterized in that, Performing a data search involves optimizing and compiling multiple operators, which are then executed by the data search according to a query plan defined by the data search.

11. A system for performing data search, characterized in that, include: At least one processor; At least one storage medium, a query processing engine, a compiler, and at least one operator file configured in a programming language; Wherein, when the query processing engine is executed, the compiler is used to obtain at least one optimized and compiled operator file by optimizing and compiling the at least one operator file according to runtime information of the data search and optimization rules; the operator file includes annotation marker functions, which are specialized when the operators encoded in the operator file are optimized and compiled for the data search at runtime; and wherein executing the data search includes executing the at least one optimized and compiled operator file, which is configured in a high-level programming language and compiled into intermediate representation code by the front-end compiler before being optimized and executed by the query processing engine.

12. The system according to claim 11, characterized in that, It also includes an operator specialization module, which is used to receive at least one operator file and the runtime information from the query processing engine; and to optimize and compile at least one operator file based on the runtime information.

13. The system according to claim 11 or 12, characterized in that, Operator files are configured using a high-level programming language and compiled into intermediate representation code.

14. The system according to claim 11 or 12, characterized in that, The runtime information includes the data layout.

15. The system according to claim 11 or 12, characterized in that, The runtime information includes data statistics.

16. The system according to claim 11 or 12, characterized in that, The runtime information includes the hardware information of the query processing engine.

17. The system according to claim 11 or 12, characterized in that, The optimization rules include a global algorithm.

18. The system according to claim 11 or 12, characterized in that, The optimization rules are based on the runtime information.

19. The system according to claim 11 or 12, characterized in that, The optimization rules include algorithms specific to the at least one operator.

20. The system according to claim 11 or 12, characterized in that, The optimization of the at least one operator is performed after the data search is invoked and before the data search is completed, such that performing the data search includes performing the at least one optimized operator.

21. The system according to claim 11 or 12, characterized in that, Performing the data search involves optimizing and compiling multiple operators, which are then executed by the data search according to a query plan defined by the data search.

22. A computer program, characterized in that, The computer program includes instructions that, when executed by a computer, cause the computer to perform the method according to any one of claims 1 to 10.

23. A computer-readable medium, characterized in that, The computer-readable medium includes instructions that, when executed by a computer, cause the computer to perform the method according to any one of claims 1 to 10.

Images