WO2025243100A1 - 过滤器构建方法、装置及设备 - Google Patents

过滤器构建方法、装置及设备

Info

Publication number
WO2025243100A1
WO2025243100A1 PCT/IB2025/053233 IB2025053233W WO2025243100A1 WO 2025243100 A1 WO2025243100 A1 WO 2025243100A1 IB 2025053233 W IB2025053233 W IB 2025053233W WO 2025243100 A1 WO2025243100 A1 WO 2025243100A1
Authority
WO
WIPO (PCT)
Prior art keywords
filter
key
operator
construction
target
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/IB2025/053233
Other languages
English (en)
French (fr)
Inventor
徐中
楼江航
黄贵
方孝健
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Cloud Intelligence Singapore Holding Pvt Ltd
Original Assignee
Cloud Intelligence Singapore Holding Pvt Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cloud Intelligence Singapore Holding Pvt Ltd filed Critical Cloud Intelligence Singapore Holding Pvt Ltd
Publication of WO2025243100A1 publication Critical patent/WO2025243100A1/zh
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/242—Query formulation
    • G06F16/2433—Query languages
    • G06F16/2445—Data retrieval commands; View definitions
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2255—Hash tables
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/242—Query formulation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2453—Query optimisation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24552—Database cache management

Definitions

  • the filter construction process, transmission process, and filter calculation process all incur certain performance overhead, which can reduce the data query performance of the data system in some scenarios.
  • the present disclosure provides a filter construction method, apparatus, and device to avoid the impact of filter construction overhead on the data query performance of the data system.
  • embodiments of the present disclosure provide a filter construction method, comprising: generating an operator chain corresponding to a data query plan based on the data query plan, the operator chain including multiple linearly connected operators, the operators including connection operators and scan operators; obtaining filter construction information corresponding to the operator chain based on the connection operators and scan operators, the filter construction information including the correspondence between the construction channels of the connection operators and the filtering channels of the scan operators in the operator chain; determining a target connection key for constructing the filter from the connection keys included in the operator chain based on the performance gains and/or performance overhead of the filter corresponding to the filter construction information; and constructing a filter at the construction end of the target connection key, the target connection key being used to filter data based on the filter when executing the data query plan.
  • embodiments of this disclosure also provide a data query method, comprising: responding to a data query plan, constructing a filter in an operator chain corresponding to the data query plan based on the filter construction method of the first aspect; executing the operator chain corresponding to the data query plan, and filtering data based on the filter to obtain a data query result corresponding to the data query plan.
  • embodiments of this disclosure also provide a filter construction apparatus, comprising: a generation module, used to generate an operator chain corresponding to the data query plan according to the data query plan, the operator chain including multiple linearly connected operators, the operators including connection operators and scan operators;
  • the present disclosure provides a data query apparatus, comprising: a filter construction device as described in the third aspect, configured to acquire filter construction information corresponding to the operator chain based on the connection operator and the scan operator, wherein the filter construction information includes the correspondence between the construction channels of the connection operator and the filtering channels of the scan operator in the operator chain; a determination module, configured to determine the target connection key to be constructed as a filter among the connection keys contained in the operator chain based on the performance gain and/or performance overhead of the filter corresponding to the filter construction information; and a construction module, configured to construct a filter at the construction end of the target connection key, wherein the target connection key is used to filter data based on the filter when executing a data query plan.
  • the present disclosure provides a data query apparatus, comprising: a filter construction device as described in the third aspect, configured to construct a filter in the operator chain corresponding to the data query plan in response to the data query plan; and an execution device, configured to filter data based on the filter when executing the operator chain corresponding to the data query plan.
  • the present disclosure also provides a computer-readable storage medium storing computer-executable instructions thereon, wherein when the computer-executable instructions are executed by a processor, the filter construction method as described in the first aspect is implemented, and/or, the data query method as described in the second aspect is implemented.
  • embodiments of this disclosure provide a computer program product, including computer instructions, which, when executed by a processor, implement the filter construction method as provided in the first aspect, and/or implement the data query method as provided in the second aspect.
  • filter construction method for a data query plan, filter construction information corresponding to the operator chain corresponding to the data query plan is obtained to determine the connection keys where filters can be constructed. Then, the performance gains and/or performance overhead brought by each filter are calculated respectively, and based on the performance gains and/or performance overhead, it is determined whether to construct a filter in the corresponding connection key.
  • the performance gains and performance overhead brought by constructing filters can be fully considered, thereby selectively constructing filters and avoiding the impact of the overhead of constructed filters on system performance.
  • Figure 1 is a schematic diagram of a filter construction method according to an embodiment of the present disclosure
  • Figure 2 is a flowchart of a filter construction method according to an embodiment of the present disclosure
  • Figure 3 is a schematic diagram of an operator chain corresponding to a data query plan according to an embodiment of the present disclosure
  • Figure 4 is a schematic diagram of the principle of obtaining filter construction information according to an embodiment of the present disclosure
  • Figure 5 is a schematic diagram of the parallelism of the operator chain according to an embodiment of the present disclosure
  • Figure 6 is a schematic diagram of the principle of constructing a filter according to an embodiment of the present disclosure
  • Figure 7 is a schematic diagram of the principle of constructing a filter according to an embodiment of the present disclosure
  • Figure 8 is a flowchart of a data query method according to an embodiment of the present disclosure
  • Figure 9 is a schematic diagram of the principle of a pass filter according to an embodiment of the present disclosure
  • Figure 10 is a schematic diagram of the principle of the execution process of a scan operator according to an embodiment of the
  • Figure 13 is a schematic diagram of the structure of a data query device provided in an embodiment of this disclosure
  • Figure 14 is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure.
  • Runtime Filter A query optimization technique used to improve the query performance of distributed database systems or massively parallel processing (MPP) databases.
  • Runtime filters are mainly used to accelerate join operations in large data warehouses and big data systems. When executing distributed join queries, runtime filters can dynamically create filtering conditions and apply these conditions to the data partitions to be processed during query execution, thereby reducing unnecessary data scanning and processing.
  • a Bloom filter is a space-efficient probabilistic data structure used to test whether an element is a member of a set.
  • a Bloom filter can quickly determine whether an element is definitely not in a set or might be in a set; therefore, it has a characteristic that allows for a certain error rate: it may produce false positives (i.e., it judges an element to be in the set when it is not), but it will never produce false negatives (i.e., if it judges an element not to be in the set, then that element is definitely not in the set).
  • the inventors discovered that in related technologies, for data systems using runtime filtering, for the Hashjoin operator, a certain type of data summary is constructed from the build end of the Hashjoin operator and passed to the probe end for pre-filtering. Specifically, from the Scan operator to the Probe side of the Join operator, each node in this data processing chain has the opportunity to gain performance benefits, including but not limited to at least one of the following:
  • runtime filter builder and filter operators need to be inserted at the build and probe ends of the join operator, respectively, to perform filter construction and filtering operations.
  • rules for runtime filter merging, pushdown, and transposition need to be introduced into the optimizer, making the optimizer design more complex.
  • This complexity also expands the search space of cost-based optimization (CBO), increasing optimizer overhead.
  • CBO cost-based optimization
  • the construction of runtime filters often relies on operator cost estimation. For example, the size of the constructed filter needs to be initialized based on the output rows of the Join operator and the estimated cardinality of the Join construction end. However, the estimated results differ significantly from the actual output rows, severely impacting the filter's accuracy.
  • this disclosure provides a filter construction method, apparatus, and device.
  • filter construction information corresponding to the operator chain of the data query plan is obtained to determine the join keys where filters can be constructed.
  • the performance gains and/or performance overhead of each filter are calculated separately, and based on the performance gains and/or performance overhead, it is determined whether to construct a filter in the corresponding join key.
  • the performance benefits and overhead of building filters are fully considered, thus selectively building filters and avoiding the impact of filter overhead on system performance.
  • Figure 1 is a schematic diagram of a filter building method provided by an embodiment of this disclosure.
  • the scenario includes: a data query plan and an electronic device.
  • the data query plan represents the sequence of operations used to execute a Structured Query Language (SQL) query. That is, the data query plan can be an SQL execution plan.
  • SQL Structured Query Language
  • the process of generating an execution plan from SQL is called query optimization.
  • the SQL statement submitted by the user is first parsed by a parser to obtain the data query plan in this embodiment of the disclosure.
  • the electronic device can be a terminal or a server.
  • the terminal can be a personal digital assistant (PDA) device, a handheld device with wireless communication capabilities (e.g., a smartphone, tablet), a computing device (e.g., a personal computer, PC), an in-vehicle device, a wearable device (e.g., a smartwatch, smart bracelet), a smart home device (e.g., a smart display device), etc.
  • PDA personal digital assistant
  • the electronic device can be equipped with a database system, such as the MPP database mentioned above.
  • FIG2 is a schematic flowchart of a filter construction method provided by an embodiment of this disclosure. As shown in FIG2, the filter construction method includes the following steps:
  • the operator chain includes multiple linearly connected operators, including join operators and scan operators.
  • the SQL statement submitted by the user is first parsed by a parser, which can convert it into an intermediate representation, typically an Abstract Smantics Tree (AST), i.e., the data query plan in this embodiment.
  • AST is then passed to the query optimizer, whose task is to determine the most efficient way to execute the data query plan.
  • the optimizer evaluates different query execution strategies, including choosing which join method to use (such as nested loops, hash joins, or sort-merge joins), determining the order of operations, and selecting indexes.
  • this evaluation phase typically relies on statistical information, such as data distribution, index characteristics, table size, etc., which helps the optimizer estimate the cost of various execution strategies. Furthermore, after evaluating all possible execution strategies and their costs, the optimizer selects the lowest-cost execution plan and generates a data query plan or execution plan tree.
  • the data query plan details how the database engine executes the query, including the order of operations, the algorithms used, and the data structures. Finally, the database execution engine executes the query operation according to the execution plan and returns the results to the user, aiming to provide database users with fast and efficient query performance.
  • generating the operator chain corresponding to the data query plan involves the following steps:
  • the execution plan tree corresponding to the data query plan is usually composed of a series of interconnected nodes. Each node represents a query operation, such as a select, join, or aggregate operation.
  • operator pipeline segments Specifically, when generating operator pipelines based on the data query plan, it is usually started from the leaf node (usually a scan node) of the execution plan tree corresponding to the data query plan, and the execution plan tree is traversed upwards to identify the operation sequences that can be executed in parallel. Among them, operators that do not need to wait for the preceding operations to complete all outputs (i.e., streaming operators) can be organized into a pipeline. In some optional implementations, during the identification process, operators can be marked as pipeline producers (data sources) and consumers (data receivers).
  • the Pipeline includes two operator execution modes: Mode 1: Blocking execution, where an operation must wait for all its inputs to be processed before it can execute; Mode 2: Non-blocking execution, where an operator can immediately process the output of an upstream operator without waiting for all inputs to complete.
  • Mode 1 Blocking execution, where an operation must wait for all its inputs to be processed before it can execute
  • Mode 2 Non-blocking execution, where an operator can immediately process the output of an upstream operator without waiting for all inputs to complete.
  • the Pipeline allows another operation to begin processing the output of the previous operation while one operation is processing the current batch of data, thereby improving the overall performance of database queries.
  • independent query operations can be combined into one or more...
  • Each Pipeline is an “execution unit” that can be executed independently or in parallel. Different Pipelines may be connected through intermediate data structures (such as buffers).
  • Figure 3 is a schematic diagram of an operator chain corresponding to a data query plan provided in an embodiment of this disclosure. As shown in Figure 3, it is an execution plan tree corresponding to a data execution plan containing two Join operators. This data execution plan includes operator chain 1, operator chain 2, and operator chain 3.
  • the filter construction information includes the correspondence between the construction channels of the join operator and the filtering channels of the scan operator in the operator chain.
  • the filter construction information indicates that the filter built on a certain build key column of the join operator (Hashjoin) will be matched against the scan operator in the pipeline to which the HashJoin operator belongs.
  • a filter build information S contains a build channel for the Hash Join operator.
  • the target join key for building the filter from the join keys contained in the operator chain. For example, after a record is read from the Scan operator, a hash table probe is performed on the Hash Join operator; its memory access cost is C. After introducing the Runtime Filter, the Scan operator needs to perform K mappings on this record.
  • the memory access overhead and mapping computation overhead for each mapping position are 2.
  • the mapping computation overhead is generally much smaller than the memory access overhead, so C*2 can be approximated as the pure memory access overhead.
  • the performance overhead increased by introducing the Runtime Filter is: R ⁇ K ⁇ C 2 ;
  • the performance gain brought by introducing the Runtime Filter is: (1 — fpp)(1 — selectvity) ⁇ R ⁇ CL .
  • fpp is the false positive rate of the filter
  • (1 - fpp) is the correction value for false positives
  • (1 — selectvity) is the selection rate of the Hashjoin operator.
  • the performance gain and/or performance overhead corresponding to each filter are calculated based on the above scheme.
  • the performance overhead of its corresponding Nth filter is: R - K - C2
  • the performance gain is: (1 - fpp)(1 - selectivity) ⁇ R ⁇ CL .
  • step S204 Construct a filter at the Build end of the target join key.
  • the target join key is used to filter data based on the filter when executing the data query plan.
  • the performance benefits and overhead of constructing filters are fully considered, thus selectively constructing filters and avoiding the impact of filter overhead on system performance.
  • Example 1 In this embodiment, step S202 is described in detail with specific examples: When obtaining filter construction information corresponding to the operator chain based on the join operator and scan operator, the specific steps include:
  • the first identifier information of the build key includes the table name and column name information of the connection key; the second identifier information of the probe key includes the table name and column name information of the probe key.
  • a Pipeline and its scheduling information are collectively referred to as a Pipeline Fragment.
  • a Pipeline Fragment is the basic unit of a Pipeline under the scheduling mechanism, and each Pipeline Fragment is configured with an in-fragment runtime filter manager (Fragment-RF-Manager).
  • the build channel in the filter build information is obtained from the metadata of the join operator; and based on the second identifier information of the probe key on the join key, the filter channel corresponding to the build channel is obtained from the metadata of the scan operator.
  • Figure 4 is a schematic diagram of the principle of obtaining filter build information according to an embodiment of this disclosure.
  • the second identifier information i.e., the table name and column name information of the Probe key
  • the corresponding channel is searched in the metadata of the Scan operator to obtain the Filter Channel (i.e., Channels).
  • step S203 Based on the construction channel and filtering channel corresponding to the connection key contained in the operator chain, obtain the filter construction information corresponding to the operator chain.
  • the filter construction information corresponding to each operator chain can be obtained. So, Example 2
  • a specific implementation of step S203 is described in detail: Specifically, when determining the target connection key to be constructed for the filter in the connection key contained in the operator chain based on the performance gain and/or performance overhead of the filter corresponding to the filter construction information, at least one of the following methods is included, but is not limited to:
  • the filter's performance gain must exceed its corresponding performance overhead for the system to benefit from the performance gain. That is, if the performance gain C1 - fpp)(l - selectvity) ⁇ R ⁇ C ⁇ is greater than the performance overhead R ⁇ K ⁇ ⁇ , then the join key corresponding to that filter is the target join key. Specifically, if (1 — fpp)(l — selectvity) ⁇ R ⁇ C x > R ⁇ K ⁇ C 2 , then the join key corresponding to that filter is the target join key.
  • the performance overhead of the filter is obtained. If the performance overhead is not greater than a preset performance overhead, the connection key corresponding to the filter is determined as the target connection key. In some embodiments, a preset performance overhead can also be used. If the performance overhead of a filter is less than the preset performance overhead, it is considered that building the filter will not cause a performance regression in the system, and the connection key corresponding to the filter is the target connection key. It should be noted that the specific value of the preset performance overhead is not limited in the embodiments of this disclosure. In the embodiments of this disclosure, only the performance overhead of the filter needs to be calculated, and the performance benefit of the filter does not need to be calculated, which greatly reduces the amount of calculation and can improve the efficiency of filter construction.
  • a performance gain can be preset. If the performance gain value corresponding to a filter is less than the preset performance gain, it is considered that constructing the filter will bring performance benefits to the system, and then the filter is selected.
  • the connection key is the target connection key. It should be noted that the specific value of the preset performance gain is not limited in this embodiment. In this embodiment, only the performance gain of the filter needs to be calculated, without calculating the performance overhead, which greatly reduces the computational load and improves the filter construction efficiency.
  • step S203 is described in detail with specific examples: Specifically, when determining the target connection key of the filter to be constructed from the connection keys contained in the operator chain based on the performance gain and/or performance overhead of the filter corresponding to the filter construction information, the following steps are included:
  • Method 1 If the memory access efficiency ratio is less than the selection rate, determine that the join operator corresponding to the filter is the target join key that meets the preset requirements; if the memory access efficiency ratio is greater than or equal to the selection rate, determine that the join operator corresponding to the filter is not the target join key. Specifically, if (1 - fpp) (1 - selectvity), then the join operator corresponding to the filter is the target join key. The join key is used to indicate the target.
  • Method 2 If the selection rate (1 - Selectivity) is greater than or equal to the preset selection rate, the join key corresponding to the filter is determined to be the target join key; if the selection rate (1 - Selectivity) is less than the preset selection rate, the join operator corresponding to the filter is determined not to be the target join key.
  • the memory access efficiency ratio corresponding to the filter may not be calculated; only the selection rate corresponding to the filter is used to determine whether the filter can cause performance regression in the system. It should be understood that the preset selection rate is not specifically limited in this embodiment.
  • Method 3 If the difference between the memory access efficiency ratio and the preset memory access efficiency ratio is less than the first preset value, the join key corresponding to the filter is determined to be the target join key based on the line number in the build. Similarly, in this scheme, the filtering rate can be omitted, and the performance regression of the filter can be determined solely based on the memory access efficiency ratio corresponding to the filter. It should be understood that this disclosure does not specifically limit the size of the preset memory access efficiency ratio or the first preset value; for example, the preset memory access efficiency ratio can be 1. This scheme significantly reduces the computational load, thereby improving system performance to a certain extent.
  • the values of Ci, C2, and Selectivity can be calculated by combining existing information. These values can be substituted into the formula in Method 1 above, or directly compared using Methods 2 and 3. If the conditions are met, the Runtime Filter can be enabled. This forms an adaptive Runtime Filter switching mechanism, greatly improving the automation of filter construction and thus improving data query efficiency.
  • the Join operator often exhibits significant deviations in cardinality and selectivity estimation, which is difficult to avoid in databases. Therefore, the selectivity obtained by the above scheme may differ significantly from the true value.
  • this embodiment of the present disclosure can also determine whether the connection key corresponding to the filter is the target connection key through at least one of the following situations: Situation 1: If the number of rows on the Build side is greater than a second preset value or less than a third preset value, then the connection key corresponding to the filter is determined to be the target connection key. Situation 2: If the number of rows on the Build side is less than or equal to the second preset value, or the number of rows on the Build side is greater than or equal to the third preset value, then the connection key corresponding to the filter is determined not to be the target connection key.
  • the number of rows on the Build side can be inferred from the hash table memory space usage to determine the second preset value.
  • the memory space occupied by the physical machine e.g., L1 cache space
  • the cache size is 32KB, and the hash table occupies memory space (e.g., load factor).
  • the number of lines in the Build is r. Therefore, we can conclude that r ⁇ 4096.
  • the lower bound of the number of lines in the Build is 4096, as one of the conditions for enabling the Runtime Filter. That is, the second preset value can be set to 4096.
  • the value of K • color is also close to 1, and it is impossible to bring any benefit to the system.
  • the third preset value can be determined based on the memory space occupied by the Runtime Filler. For example, taking the Runtime Filter memory space occupied (e.g., L3 Cache Size) as an example, if the physical machine's L3 Cache Size is known to be 16MB, then next_power_of_2(r / 8) * 8Bytes > 16 MB, where the number of lines r on the Build side is between 10 million and 20 million. Therefore, we can roughly agree that having less than 20 million lines on the Build side is one of the conditions for enabling the Runtime Filter; that is, the third preset value can be set to 20 million.
  • L3 Cache Size e.g., L3 Cache Size
  • the join key corresponding to the filter is determined to be the target join key; that is, the target join key can be used to construct the filter. If the number of rows in the Build phase is less than or equal to 4096, or greater than or equal to 20 million, then the join key corresponding to the filter is determined to be not the target join key; that is, the target join key does not require a filter. In some optional cases, the decision to disable the filter can be made after its construction based on the filter's filtering properties. When building the Runtime Filter in the Build phase, the filtering properties of the Probe phase are not yet known.
  • each pipeline can be executed by multiple degrees of parallelism.
  • the following steps are also included:
  • the parallelism level Based on the parallelism level, set the same number of threads as the parallelism level for the operator chain. These threads are used to execute the connection operators in the operator chain.
  • the parallelism level of the operator chain can be determined based on the assessed available system resources, including the number of CPU cores, memory capacity, and I/O capability. It should be understood that the parallelism level setting should not exceed the resource limits that the system can effectively process; otherwise, it may lead to excessive context switching, resource contention, and performance degradation.
  • the distribution and partitioning of data are crucial for achieving effective parallel processing. Data needs to be divided into a sufficient number of partitions so that multiple processors or nodes can work in parallel. The uniformity of data distribution also affects load balancing, thereby affecting the efficiency of parallel execution.
  • Figure 5 is a schematic diagram of the parallelism of the operator chain provided in this embodiment.
  • parallelism levels of 3, 3, and 4 can be set for these three operator chains, respectively.
  • Embodiment Six In some embodiments, when building a filter at the Build end of the target join key, the following steps are specifically included:
  • the Hashjoin operator can be divided into different data partitioning patterns (the data partitioning pattern corresponding to the Hashjoin operator is the data partitioning pattern corresponding to the target join key in the Hashjoin operator) according to different data partitioning and parallel strategies.
  • the data partitioning patterns include two modes: the first partitioning pattern (Broadcast pattern) and the second partitioning pattern (Local pattern).
  • the first partitioning mode represents that all partitions on the Build side of the target join key correspond to the same hash table, meaning that all partitions on the Build side share a single hash table.
  • the second partitioning mode represents that each partition on the Build side of the target join key corresponds to a different hash table, meaning that each partition on the Build side maintains its own independently.
  • a target join key with the second partitioning mode (Local mode)
  • a shared filter can be built for all partitions.
  • filters corresponding to each target join key are built separately.
  • Scenario 1 If the target join key is in the first partitioning mode, for each thread corresponding to the target join key, a filter component corresponding to that thread is built, and the filter components of the threads corresponding to the target join key are merged to obtain the filter corresponding to the target join key.
  • FIG. 6 is a schematic diagram of the filter construction principle provided in one embodiment of this disclosure. As shown in Figure 5, since different threads may map to the same memory region at the same time, allocating a memory block and having each thread write directly to it would incur significant concurrency safety overhead. Therefore, in this embodiment, an additional locking mechanism is needed to ensure that writing to the memory region is concurrency-safe.
  • a filter component can be built locally for each thread, with a size consistent with the final filter size.
  • each thread writes data to its local component.
  • each thread acquires a write lock and merges the filter components into a unified filter.
  • merging the filter components involves ORing all bits of the memory region with all bits of the target filter's memory region and then assigning the result. This process is very fast due to its prefetch capability, so write locks can be used to queue the components within each thread for execution.
  • Scenario 2 If the target join key is in the second partition mode, a local filter is built for each partition corresponding to the target join key to obtain the filter corresponding to the target join key.
  • each partition uses its own independent hash table, and all data within each Chunk comes from the same table partition.
  • one thread may handle the construction of hash tables and filters for multiple partitions; or multiple threads may jointly complete the construction of hash tables and filters within a single partition.
  • Figure 7 is a schematic diagram of the principle of filter construction provided in an embodiment of this disclosure. As shown in Figure 5, if the target join key is in the first partition mode, during the filter construction process, firstly, a local filter (Partial Runtime Filter) is formed for each partition . Further, one thread performs partition judgment on each Chunk to find the Partial Runtime Filter corresponding to the Chunk.
  • Partial Runtime Filter Partial Runtime Filter
  • step S801 In response to the data query plan, construct a filter in the operator chain corresponding to the data query plan. It should be noted that the implementation of step S801 is described in the embodiment corresponding to the filter construction method in the above examples, and will not be repeated here.
  • Embodiment 1 Execute the operator chain corresponding to the data query plan, and filter the data based on the filter to obtain the data query results corresponding to the data query plan.
  • the Fragment-RF-Manager component mentioned in Embodiment 1 can be used to pass the constructed filter to the scan operator.
  • a lightweight design is adopted, and the filter is passed only through memory, without the need for mechanisms such as the client-server model.
  • Figure 9 is a schematic diagram of the principle of passing the filter provided in an embodiment of the present disclosure.
  • the filter passing process specifically includes the following operations: First, the Runtime Filters built in parallel under different modes are stored in the field of Fragment-RF-Manager; Further, when processing each Chunk, the Scan operator checks whether the field of Fragment-RF-Manager contains Runtime Filter field data; If it exists, the Runtime Filter is used for additional data filtering; if it does not exist, the data query plan is executed according to the normal mode without Runtime Filter.
  • Figure 10 is a schematic diagram of the execution process of the Scan operator provided in an embodiment of this disclosure. As shown in Figure 10, the execution process of the Scan operator specifically includes the following stages: In the scheduling stage, the scheduler registers the Runtime Filter Manager (hereinafter referred to as RF Manager) to the Scan operator;
  • RF Manager Runtime Filter Manager
  • RF item RF Manager
  • RF item RF Manager
  • RF item key Determines whether the item indicates that a created Runtime Filter already exists.
  • Process 1 When no Runtime Filter exists, it includes the following operations: Operation 1: Using the Logical Row Group component, enumerate the readable logical data range; Operation 2: Using the Stripe Loader component, execute the IO prefetch task for each column.
  • Operation 3 Combining Operations 1 and 2, obtain the filter column, perform filter calculations, and obtain the filter result (e.g., a bitmap).
  • Operation 4 Apply the bitmap to the Project column obtained from Operations 1 and 2.
  • Process Two When an item in RF Manager is detected to have a pre-created Runtime Filter, the following operations are included: First, for each filter built in the operator chain, obtain the filtering effect of the filter in the data filtering process during the execution of the data query plan.
  • the filtering effect when executing the data query plan based on the operator chain, first, add the Runtime Filter column to the Stripe Loader component, create 10 prefetch tasks belonging to this column, then register the RF item to the filter, perform data filtering through the filter, and at the same time, perform validity checks on the first N chunks of each batch through the effect checker (the first N chunks are the effect check samples). It should be understood that the value of N is not particularly limited in this embodiment. Furthermore, if the filtering effect is not less than the threshold, the filter will continue to be used for data filtering during the execution of the data query plan; if the filtering effect is less than the threshold, the filter will be stopped during the execution of the data query plan.
  • the filter can perform filtering calculations on Blocks and Runtime Filters, detect the existence of each position in the Block, and obtain a Bitmap. For the Bitmap, the filtering effect is statistically collected. If the filtering effect exceeds the threshold (the threshold is, for example, when%), the filter will continue to be used for data filtering.
  • the threshold is, for example, when
  • the validity check provided in this embodiment can disable this filter, thereby avoiding the performance impact of the poorly filtering filter on the system and improving system performance.
  • the filter provided in this disclosure can be at least one of a Bloom filter and a blocked Bloom filter. Bloom filters are the most common implementation of runtime filters; they are data digests that can represent the existence of a batch of data with less storage space.
  • a Bloom filter for each data point, uses a mapping function K times to map the data to different locations (one bit) in a memory space, setting the bit at each mapped location to 1. When it's necessary to determine the existence of data, this K mapping process is repeated. If all mapped bits are 1, the data is considered present. Conversely, if any bit is 0, the data is considered absent. It's important to note that Bloom filters have a certain error rate, misclassifying non-existent data as present. This characteristic is also known as a false positive, and the error rate fpp typically ranges from 0.03 to 0.1.
  • a Runtime Filter filters Filtered_rows rows on a dataset with a total number of rows (total_rows ).
  • the average cost per row is L; the average cost per row in the computation chain is M.
  • M * Filtered_rows > L * total_rows i.e., LV.
  • the data for the Scan operator resides entirely in memory and does not require a 10 operation.
  • the overhead of building, computing, and passing a Runtime Filter must be lower than this execution overhead to have a chance of achieving positive performance gains. In other words, if this stringent performance requirement can be met, the Runtime Filter can also gain benefits in other execution scenarios.
  • the memory access efficiency of the Runtime Filter can be improved to reduce the memory access efficiency ratio mentioned above, thereby improving the system's performance gains.
  • the filter can also use a blocking Bloom filter, which offers better memory access performance.
  • a blocking Bloom filter which offers better memory access performance.
  • the two mapped bits of each record are read and checked.
  • the number of memory accesses can be approximated as 1. This is because, although the number of mappings is fixed at 2, the target location span is less than 512 bits. Thanks to the CPU's cache and prefetch capabilities, it is highly likely that the data can be contained within a single cache line in a single memory access.
  • an adaptive Runtime Filter switch can be designed by combining the performance benefit formula mentioned above and the context information.
  • the hash table memory space occupies next_power_of_2(r / Load Factor) * 4 Bytes; according to the blocked Bloom Filter algorithm, the Runtime Filter memory space occupies next_power_of_2(r / 8) * 8 Bytes.
  • ⁇ next_power_of_2(x) ⁇ represents the smallest integer power of 2 greater than ⁇ x ⁇
  • ⁇ r ⁇ represents the number of rows in the build process
  • ⁇ Load Factor ⁇ is a hash table parameter, typically between 0.25 and 0.75
  • ⁇ Ci ⁇ depends on the hash table's memory footprint and the physical machine's CPU architecture. It should be noted that if the hash table's memory footprint exceeds the size of the L3/L2/L1 Cache, then ⁇ Ci ⁇ approximates the main memory access speed (250 cycles), L3 access speed (50 cycles), and L2 access speed (15 cycles), respectively, and so on.
  • ⁇ C2 ⁇ is calculated as follows: if the Runtime Filter's memory space exceeds the size of the L3/L2/L1 Cache, then ⁇ C2 ⁇ approximates the main memory access speed (250 cycles), L3 access speed (50 cycles), and L2 access speed (15 cycles), respectively, and so on. Furthermore, based on the Blocked Bloom Filter algorithm, since the memory access span after mapping each record is less than 512 bits, K can be approximated as 1, as described above. In summary, after constructing the hash table, the values of Ci, C2, and Selectivity parameters are calculated using existing information. These are then substituted into the performance benefit formula to see if they are satisfied. If satisfied, the Runtime Filter can be enabled , thus forming an adaptive Runtime Filter switching mechanism.
  • the Runtime Filter is shared by all partitions, so only a single Runtime Filter needs to satisfy the performance benefit relationship.
  • the Runtime Filter is divided into local partial Runtime Filters within multiple partitions.
  • Scenario 1 The number of lines on the build side is too large, and both Ci and C2 are equal to the main memory access latency. In this case, it is unnecessary to enable the Runtime Filter because it is close to 1, which cannot satisfy the size relationship in the benefit model. The memory space occupied by the Runtime Filter will exceed the L3 Cache size. We can deduce the number of lines on the build side at this time and use the number of lines on the build side as the threshold for judgment.
  • Scenario 2 The number of rows on the build side is too small, and the values of Ci and C2 are not significantly different, approaching 1.
  • the memory access latency G is already very small, and the hash table can often be accommodated in the LI Cache.
  • the size of the number of rows on the build side can be inferred from the memory space usage of the hash table.
  • r is the number of rows on the build side
  • r ⁇ 4096 the lower bound of the number of rows on the build side.
  • Scenario 3 The filtering performance is very poor, i.e., the selectivity is larger than the estimated value. It is impossible to constrain this using the number of rows on the build side, because the filtering performance on the probe side is not yet known when building the Runtime Filter.
  • the filter construction apparatus 1200 includes: a generation module 1201, which generates an operator chain corresponding to a data query plan based on the data query plan.
  • the operator chain includes multiple linearly connected operators, including connection operators and scan operators; an acquisition module 1202, which acquires filter construction information corresponding to the operator chain based on the connection operators and scan operators.
  • the filter construction information includes the correspondence between the construction channels of the connection operators and the filtering channels of the scan operators in the operator chain; a determination module 1203, which determines the target connection key of the filter to be constructed from the connection keys included in the operator chain based on the performance benefits and/or performance overhead of the filter corresponding to the filter construction information; and a construction module 1204, which constructs a filter at the construction end of the target connection key.
  • the target connection key is used to filter data based on the filter when executing the data query plan.
  • the acquisition module 1202 is specifically configured to: acquire first identification information of the construction key and second identification information of the probe key of the connection operator in the operator chain; for each connection key on the connection operator, based on the first identification information of the construction key on the connection key, obtain the construction channel in the filter construction information from the metadata of the connection operator; and, based on the second identification information of the probe key on the connection key, obtain the filter channel corresponding to the construction channel from the metadata of the scan operator; and acquire the filter construction information corresponding to the operator chain according to the construction channel and filter channel corresponding to the connection key contained in the operator chain.
  • the determining module 1203 is specifically used for at least one of the following: For each filter corresponding to the filter construction information, obtaining the performance gain of the filter; if the performance gain is not less than a preset performance gain, then determining the connection key corresponding to the filter as the target connection key; For each filter corresponding to the filter construction information, obtaining the performance overhead of the filter; if the performance overhead is not greater than a preset performance overhead, then determining the connection key corresponding to the filter as the target connection key; For each filter corresponding to the filter construction information, obtaining the performance overhead and performance gain of the filter; if the performance overhead is less than the performance gain, then determining the connection key corresponding to the filter as the target connection key.
  • the determining module 1203 is specifically used for: For each filter corresponding to the filter construction information, obtaining the performance overhead and performance gain of the filter; obtaining the memory access efficiency ratio corresponding to the filter based on the performance overhead and performance gain; obtaining the screening rate of the connection operator after false positive correction; determining whether the connection key corresponding to the filter is the target connection key based on the memory access efficiency ratio and/or the screening rate.
  • the determining module 1203 is specifically used for at least one of the following: if the memory access efficiency ratio is less than the screening rate, determine that the join operator corresponding to the filter is a target join key that meets the preset requirements; if the memory access efficiency ratio is greater than or equal to the screening rate, determine that the join operator corresponding to the filter is not a target join key; if the screening rate is greater than or equal to the preset screening rate, determine that the join key corresponding to the filter is a target join key; if the screening rate is less than the preset screening rate, determine that the join operator corresponding to the filter is not a target join key; if the difference between the memory access efficiency ratio and the preset memory access efficiency ratio is less than a first preset value, determine whether the join key corresponding to the filter is a target join key based on the number of rows in the build process.
  • the determining module 1203 is specifically used for: if the number of rows in the build process is greater than a second preset value or less than a third preset value, then determine that the join key corresponding to the filter is a target join key; if the number of rows in the build process is less than or equal to the second preset value, or greater than or equal to the third preset value, then determine that the join key corresponding to the filter is not a target join key.
  • the determining module 1203 is further configured to: determine the number of parallelisms for each operator chain; and set up a number of threads equal to the number of parallelisms for each operator chain, the threads being used to execute the join operators in the operator chain.
  • the constructing module 1204 is specifically configured to: determine the data partitioning pattern corresponding to the target join key; and construct a filter at the construction end of the target join key according to the data partitioning pattern of the target join key; wherein the data partitioning pattern includes a first partitioning pattern and a second partitioning pattern, the first partitioning pattern being used to characterize that each partition at the construction end of the target join key corresponds to the same hash table, and the second partitioning pattern being used to characterize that each partition at the construction end of the target join key corresponds to a different hash table.
  • the construction module 1204 is specifically used for: if the target connection key is a first partition mode, constructing a filter component corresponding to each thread for the target connection key, and merging the filter components of the threads corresponding to the target connection key to obtain the filter corresponding to the target connection key; if the target connection key is a second partition mode, constructing a local filter corresponding to each partition for the target connection key to obtain the filter corresponding to the target connection key.
  • the filter is at least one of a Bloom filter and a blocking Bloom filter. It should be noted that the filter construction device provided in this disclosure is used to execute the technical solutions in the aforementioned corresponding method embodiments, and its implementation principle and technical effects are similar, and will not be repeated here.
  • FIG13 is a schematic diagram of the structure of a data query device provided in an embodiment of this disclosure.
  • the data query device 1300 provided in this embodiment includes: a filter construction device 1200, used to construct filters in the operator chain corresponding to the data query plan in response to the data query plan; and a query module 1301, used to execute the operator chain corresponding to the data query plan, and filter data based on the filters to obtain the data query result corresponding to the data query plan.
  • the query module 1301 is further used to: for each filter constructed in the operator chain, obtain the filtering effect of the filter in the process of executing the data query plan; if the filtering effect is not less than a threshold, then continue to use the filter for data filtering in the process of executing the data query plan; if the filtering effect is less than the threshold, then stop using the filter for data filtering in the process of executing the data query plan.
  • the functions performed by each module in the data query device provided in this embodiment correspond to the technical solutions in the aforementioned corresponding method embodiments, and their implementation principles and technical effects are similar, and will not be repeated here.
  • Figure 14 is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure.
  • the electronic device 1400 includes: at least one processor 1401 (only one processor is shown in Figure 14); and a memory 1402 communicatively connected to the at least one processor.
  • the memory 1402 stores instructions executable by the at least one processor 1401, which, when executed, enable the electronic device 1400 to perform the technical solutions described in any of the foregoing method embodiments.
  • the memory 1402 can be independent or integrated with the processor 1401.
  • the memory 1402 can be implemented using any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, etc.
  • SRAM static random access memory
  • EEPROM electrically erasable programmable read-only memory
  • EPROM erasable programmable read-only memory
  • PROM programmable read-only memory
  • ROM read-only memory
  • magnetic storage flash memory
  • flash memory etc.
  • the memory includes a disk or optical disk.
  • the processor 1401 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc.
  • a general-purpose processor may be a microprocessor or any conventional processor.
  • the steps of the methods disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.
  • the memory 1402 is a device independent of the processor 1401
  • the electronic device 1400 further includes: a bus 1403 for connecting the memory 1402 and the processor 1401.
  • the bus 1403 may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc.
  • ISA Industry Standard Architecture
  • PCI Peripheral Component Interconnect
  • EISA Extended Industry Standard Architecture
  • Buses can be categorized as address buses, data buses, control buses, etc.
  • the buses in the accompanying drawings are not limited to only one bus or one type of bus.
  • Figure 14 only schematically shows some components and does not imply that the electronic device 1400 includes only the components shown in Figure 14.
  • the electronic device 1400 further includes: a firewall, a load balancer, a communication component, a power supply component, and other components.
  • the electronic device 1400 may be a mobile terminal, a server, or other devices.
  • the aforementioned communication components are configured to facilitate wired or wireless communication between the device containing the communication components and other devices.
  • the device containing the communication components can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G/LTE, 5G, or combinations thereof.
  • the communication components receive broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.
  • the communication components also include a Near Field Communication (NFC) module to facilitate short-range communication.
  • NFC Near Field Communication
  • the NFC module may be implemented based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wideband (UWB), Bluetooth (BT), and other technologies.
  • RFID Radio Frequency Identification
  • IrDA Infrared Data Association
  • UWB Ultra Wideband
  • Bluetooth Bluetooth
  • the electronic device 1400 can execute the technical solutions of any of the aforementioned filter construction method embodiments, and/or execute the technical solutions of any of the aforementioned data query method embodiments. Their implementation principles and technical effects are similar and will not be repeated here.
  • the embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects.
  • this disclosure can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
  • embodiments of this disclosure also provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the technical solutions of any of the aforementioned filter construction method embodiments, and/or to execute the technical solutions of any of the aforementioned data query method embodiments.
  • the storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium.
  • the storage medium can also be a component of the processor.
  • the processor and storage medium can be located in an Application Specific Integrated Circuit (ASIC).
  • ASIC Application Specific Integrated Circuit
  • the processor and storage medium can exist as discrete components in the electronic device.
  • this disclosure provides a computer program product, including a computer program that, when executed by a processor, implements the technical solutions of any of the aforementioned filter construction method embodiments, and/or executes the technical solutions of any of the aforementioned data query method embodiments. Accordingly, this disclosure also provides a chip, including a processing module and a communication interface, the processing module capable of executing the technical solutions of any of the aforementioned filter construction method embodiments, and/or executing the technical solutions of any of the aforementioned data query method embodiments.
  • the chip also includes a storage module (e.g., a memory), the storage module being used to store instructions, the processing module being used to execute the instructions stored in the storage module, and the execution of the instructions stored in the storage module causing the processing module to execute the technical solutions of the aforementioned method embodiments.
  • a storage module e.g., a memory
  • the storage module being used to store instructions
  • the processing module being used to execute the instructions stored in the storage module
  • the execution of the instructions stored in the storage module causing the processing module to execute the technical solutions of the aforementioned method embodiments.
  • the functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium.
  • This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this disclosure.
  • the aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本公开实施例提供一种过滤器构建方法、装置及设备，对于数据查询计划，获取该数据查询计划对应的算子链对应的过滤器构建信息，以确定可以构建过滤器的连接键，再分别计算每个过滤器所带来的性能收益和/或性能开销，基于性能收益和/或性能开销来确定是否在对应的连接键中构建过滤器。在本公开实施例中，能够充分考虑构建过滤器所带来的性能收益和性能开销，从而选择性的构建过滤器，能够避免构建的过滤器的开销影响系统性能。

Description

过滤器构建方法、 装置及设备 本公开要求 申请号为 202410657157. 5 的中国专利申请的优先权， 该中国专利申请于 2024年 05月 24日提交中国专利局， 申请名称为 “过滤器构建方法、 装置及设备" ， 其全 部内容通过引用结合在本公开中。 技术领域 本公开涉及数据过滤技术领 域， 尤其涉及一种过滤器构建方法、 装置及设备。 背景技术 随着 大数据时代的到来， 分布式数据库、 大规模并行处理系统 (Mass i ve l y Para l l e i Process i ng, MPP) 等数据系统凭借其高效的数据处理和管理方式， 应用越来越广泛。 相 关技术中， 为了提升数据系统的查询性能，通常可以在这些数据系统中构建过滤器， 从而使用过滤器来创建过滤条件， 在数据查询执行过程中采用这些过滤条件对数据进行过 滤， 进而减少不必要的数据扫描和处理过程， 提升数据的查询效率。 然 而， 过滤器的构建过程、 传递过程以及过滤计算过程均会产生一定的性能开销， 在 一些场景中， 会降低数据系统的数据查询性能。 发明内容 本公开的 多个方面提供一种过滤器构建方法、 装置及设备， 以避免构建的过滤器的 开销影响数据系统的数据查询性能。 第一方面， 本公开实施例提供一种过滤器构建方法， 包括： 根据数据查询计划生成数据查询计划对应的算子链 ， 算子链包括多个线性连接的算 子， 算子包括连接算子和扫描算子； 根据连接算子和扫描算子 ， 获取算子链对应的过滤器构建信息， 过滤器构建信息包 含算子链中连接算子的构建通道与扫描算子的过滤通道之间的对应关系； 根据过滤器构建信息对应的过滤器的性能收益和 /或性能开销， 在算子链包含的连接 键中， 确定待构建过滤器的目标连接键； 在 目标连接键的构建端构建过滤器， 目标连接键用于在执行数据查询计划时基于过 滤器过滤数据。 第二方面， 本公开实施例还提供一种数据查询方法， 包括： 响应于数据查询计划， 基于第一方面的过滤器构建方法， 在数据查询计划对应的算 子链中构建过滤器； 执行数据查询计划对应的算子链 ， 并基于过滤器过滤数据， 获得数据查询计划对应 的数据查询结果。 第三方面， 本公开实施例还提供一种过滤器构建装置， 包括： 生成模块 ， 用根据数据查询计划生成数据查询计划对应的算子链， 算子链包括多个 线性连接的算子， 算子包括连接算子和扫描算子； 获取模块 ， 用于根据连接算子和扫描算子， 获取算子链对应的过滤器构建信息 ， 过 滤器构建信息包含算子链中连接算子的构建通道与扫描算子的过滤通道之间的对应关 系 ； 确定模块， 用于根据过滤器构建信息对应的过滤器的性能收益和 /或性能开销， 在算 子链包含的连接键中， 确定待构建过滤器的目标连接键； 构建模块， 用于在目标连接键的构建端构建过滤器 ， 目标连接键用于在执行数据查 询计划时基于过滤器过滤数据。 第四方面， 本公开实施例提供一种数据查询装置， 包括： 如 第三方面的过滤器构建装置， 用于响应于数据查询计划， 在数据查询计划对应的 算子链中构建过滤器； 执行装置 ， 用于在执行数据查询计划对应的算子链时， 基于过滤器过滤数据。 第五方面， 本公开实施例还提供一种计算机可读存储介质， 其上存储有计算机执行 指令， 计算机执行指令被处理器执行时， 实现如第一方面提供的过滤器构建方法， 和 / 或， 实现如第二方面的数据查询方法。 第六方面， 本公开实施例提供一种计算机程序产品， 包括计算机指令， 该计算机指 令被处理器执行时， 实现如第一方面提供的过滤器构建方法， 和 /或， 实现如第二方面的 数据查询方法。 本公开实施例提供的过滤器构建方法中， 对于数据查询计划， 获取该数据查询计划 对应的算子链对应的过滤器构建信息， 以确定可以构建过滤器的连接键， 再分别计算每 个过滤器所带来的性能收益和 /或性能开销， 基于性能收益和 /或性能开销来确定是否在对 应的连接键中构建过滤器。 在本公开实施例中， 能够充分考虑构建过滤器所带来的性能 收益和性能开销， 从而选择性的构建过滤器， 能够避免构建的过滤器的开销影响系统性 能。 附图说明 此处所说 明的附图用来提供对本公开的进一步理解， 构成本公开的一部分， 本公开的 示意性实施例及其说明用于解释本公开， 并不构成对本公开的不当限定。 在附图中： 图 1为本公开实施例提供的一种过滤器构建方法的场景示意图； 图 2为本公开实施例提供的一种过滤器构建方法的流程示意图一； 图 3为本公开实施例提供的一种数据查询计划对应的算子链的示意图； 图 4为本公开一实施例提供的获取过滤器构建信息的原理示意图； 图 5为本公开实施例提供的算子链并行度示意图； 图 6为本公开一实施例提供的构建过滤器的原理示意图一； 图 7为本公开一实施例提供的构建过滤器的原理示意图一； 图 8为本公开一实施例提供的数据查询方法的流程示意图； 图 9为本公开一实施例提供的传递过滤器的原理示意图； 图 10为本公开一实施例提供的扫描算子的执行过程的原理示意图； 图 11为本公开一实施例提供的数据查询计划 Q5执行过程的原理示意图； 图 12为本公开一实施例提供的过滤器构建装置的结构示意图； 图 13为本公开一实施例提供的数据查询装置的结构示意图； 图 14为本公开一实施例提供的电子设备的结构示意图。 具体实施方式 为使本公开的 目的、 技术方案和优点更加清楚， 下面将结合本公开具体实施例及相 应的附图对本公开技术方案进行清楚、 完整地描述。 显然， 所描述的实施例仅是本公开 一部分实施例， 而不是全部的实施例。 基于本公开中的实施例， 本领域普通技术人员在 没有做出创造性劳动前提下所获得的所有其他实施例， 都属于本公开保护的范围。 首先， 对本公开实施例中出现的部分词语的含义进行相关说明： 运行时过滤 (Runtime Filter) : 一种查询优化技术， 用于改进分布式数据库系统或大 规模并行处理 (Massive Parallel Processing, MPP) 数据库中的查询性能。 运行时过滤器 主要用于加速大型数据仓库和大数据系统中的联接操作， 在执行分布式联接查询时， 运 行时过滤器能够动态地创建过滤条件， 并在查询执行过程中将这些条件应用于即将处理 的数据分区， 从而减少不必要的数据扫描和处理。 布隆过滤器 (Bloom Filter) 是一种空间效率极高的概率型数据结构， 用于测试一个 元素是否是一个集合的成员。 布隆过滤器可以快速地判断一个元素一定不在集合中或可 能在集合中， 因此它有一个允许一定错误率的特性： 它可能会产生假阳性错误 (即判断 元素在集合中， 而实际上并不在) ， 但绝不会产生假阴性错误 (即如果判断元素不在集 合中， 则该元素一定不在集合中) 。 发 明人发现， 相关技术中， 对于采用运行时过滤的数据系统， 针对哈希连接 (Hashjoin) 算子， 从 Hashjoin算子的构建 (Build) 端构建出某种类型的数据摘要 (Synopsis) , 传递到探查 (Probe) 端进行提前的数据过滤。 具体的， 从扫描 (Scan) 算 子到连接 (Join) 算子的 Probe侧， 这一数据处理链路上的各个节点都有机会获得性能收 益， 具体性能收益情况包括但不限于如下至少一项：
① Scan算子的数据量减少， 从而减少输入 /输出 (Input/Output, 10)开销或下推过滤器 (Filter) 的计算开销；
②数据交互 (Exchange) 的数据量减少， 从而提升 Exchange速度；
③参与 Probe的数据量减少， 提升 Hashjoin算子的处理速度；
④减少扫描算子的探查端 (Scan-Probe) 链路上的项目 (Project) 、 过滤 (Filter) 等 的表达式计算开销。 然 而， 在这些节点中也可能会产生一定的性能开销， 具体性能开销情况包括但不限 于如下至少一项：
①额外 引入 Runtime Filter构建、 传递和过滤计算的开销。
②给优化器和调度器 带来复杂性。 具体的， 在一些场景中， 需要在 Join算子的构建端和 Probe端各自安插运行时过滤 构建 (Runtime Filter Builder) 算子和 Filter算子， 分别执行过滤器的构建和过滤操作， 同时还需要在优化器中引入 Runtime Filter合并、 下推、 转置等规则， 这使得优化器设计 更复杂， 也让基于代价的优化方式 (Cost-Based Optimization, CBO) 搜索空间膨胀， 增 加优化器开销。 另外， Runtime Filter的构建往往依赖算子的代价估算， 例如， 需要根据 Join算子的 输出结果行、 Join 构建端的估算结果 (Estimated Cardinality) 来初始化所构建的 Filter 的 大小， 但是估算结果和真实输出行差异较大， 严重影响 Filter的正确率。 综上 ， 如果这部分性能开销不能被性能收益所抵消， 那么构建 Runtime Filter会给数 据系统带来严重的性能回退。 有 鉴于此， 本公开实施例提供一种过滤器构建方法、 装置及设备， 对于数据查询计 划， 获取该数据查询计划对应的算子链对应的过滤器构建信息， 以确定可以构建过滤器 的连接键， 再分别计算每个过滤器所带来的性能收益和 /或性能开销， 基于性能收益和 /或 性能开销来确定是否在对应的连接键中构建过滤器。 在本公开实施例中， 能够充分考虑 构建过滤器所带来的性能收益和性能开销， 从而选择性的构建过滤器， 能够避免构建的 过滤器的开销影响系统性能。 以下结合附图， 详细说明本公开各实施例提供的技术方案。 图 1为本公开实施例提供的一种过滤器构建方法的场景示意图。 如图 1所示， 该场 景中包括： 数据查询计划和电子设备。 其 中， 数据查询计划代表了用于执行结构化查询语言 (Structured Query Language, SQL) 查询的操作序列。 也就是说 ， 数据查询计划可以为 SQL执行计划 (SQL execution plan) , 在数据库 中， 从 SQL生成执行计划的过程称为查询优化， 用户提交的 SQL语句首先经过解析器进 行语法分析， 从而获得本公开实施例中的数据查询计划。 在一 些实施例中， 电子设备可以为终端或者服务器， 例如， 终端可以是个人数字处 理 (personal Personal digital Digital assistantAssistant, PDA) 设备、 具有无线通信功能的 手持设备 (例如智能手机、 平板电脑) 、 计算设备 (例如个人电脑 (Personal Personal Computer, PC) ) 、 车载设备、 可穿戴设备 (例如智能手表、 智能手环) 、 智能家居设 备 (例如智能显示设备) 等。 在 本公开实施例中， 电子设备可以部署有数据库系统， 例如上述的 MPP数据库。 在 执行本公开实施例的方案时， 电子设备再获得数据查询计划时， 用于为数据查询计划构 建对应的过滤器， 并在查询数据的过程中， 应用所构建的过滤器进行数据过滤， 并输出 数据查询结果。 下面， 结合上述图 1示出的应用场景， 通过具体实施例对本公开的技术方案进行详 细说明。 需要说明的是， 下面这几个具体的实施例可以相互结合， 对于相同或相似的概 念或过程可能在某些实施例中不再赘述。 需要说明的是， 本公开的实施例的执行主体为电子设备， 参考图 2 , 图 2为本公开 实施例提供的一种过滤器构建方法的流程示意图一。 如图 2所示， 该过滤器构建方法包 括如下步骤：
S201、 根据数据查询计划生成数据查询计划对应的算子链。 其 中， 算子链 （Pipeline） 包括多个线性连接的算子， 算子包括连接算子和扫描算 子。 在一些可选的实施例 中， 用户提交的 SQL语句首先经过解析器进行语法分析， 可以 将其转换为一种中间表示形式， 通常是一棵解析树 （Abstract Smantics Tree, AST） , 也 即本公开实施例中的数据查询计划。 然后， 解析树被传递给查询优化器， 通过优化器的 任务获得执行该数据查询计划的最有效方式。 具体的 ， 优化器会评估不同的查询执行策略， 包括选择使用哪种连接（Join）方式 （如 嵌套循环、 哈希连接或排序合并连接等） ， 决定操作的顺序， 以及选择索引。 应理解， 这个评估阶段通常依赖于统计信息， 如数据分布、 索引特性、 表大小等， 这些信息帮助 优化器估计各种执行策略的成本。 进一 步的， 在评估了所有可能的执行策略及其成本之后， 优化器选择成本最低的执 行计划， 生成一个数据查询计划或执行计划树。 数据查询计划详细描述了数据库引擎如 何执行查询， 包括操作的顺序、 使用的算法和数据结构。 最后 ， 数据库执行引擎根据执行计划执行查询操作， 并返回结果给用户， 旨在为数 据库用户提供快速、 高效的查询性能。 具体的 ， 在根据数据查询计划生成数据查询计划对应的算子链时， 具体包括如下几 个步骤：
①分析数据查询计划对应的执行计划树 ； 其 中， 数据查询计划对应的执行计划树通常是由一系列互相连接的节点组成， 每个 节点代表一个查询操作， 如选择 （Select） 、 连接 （Join） 或聚合 （Aggregate） 操作。
②识别算子链 （Pipeline） 段； 具体的 ， 在基于数据查询计划生成算子链时， 通常从数据查询计划对应的执行计划 树的叶节点 （通常是扫描节点） 开始， 向上遍历执行计划树， 从而识别可并行执行的操 作序列。 其中， 无需等待前序操作完成全部输出的算子（即， 流式算子） 可以被组织成一 个 Pipeline o 在一些可选的实施 方式中， 在识别的过程中， 算子可以被标记为 Pipeline的生产者 （数据来源） 和消费者 （数据接收者） 。
③构建 Pipeline ; 应理解 ， 在构建 Pipeline时， 必须考虑查询操作之间的数据依赖性和流控制， 确保数 据以正确的顺序流动。 例如， 排序或某些聚合操作可能是 Pipeline的结束点 （即， 阻塞算 子） ， 因为它们需要全部输入数据被输入后才能开始处理。 在 一些实施例中， Pipeline中包含如下两种算子执行模式： 模 式一： 阻塞性 (Blocking) 执行， 即某个操作需要等待其所有输入都被处理之后才 可以执行； 模 式二： 非阻塞性 (Non-blocking) 执行， 即算子可以立即处理上游算子的输出， 而 不需要等待所有输入处理完成。 也就是说， Pipeline允许当一个操作正在处理当前的数据批次时， 另一个操作可以同 时开始处理上一个操作的输出结果， 从而提高数据库查询的整体性能。 进 一步的， 根据数据流和依赖性， 将相互独立的查询操作组合成一个或多个
Pipeline o 每个 Pipeline是一个 “执行单元”， 可以独立或并行地执行， 不同的 Pipeline可能 会通过中间的数据结构 (如缓冲区) 连接起来。
④优化 Pipeline : 在 一些可选的实施方式中， 在 Pipeline构建完成后， 可以进行对 Pipeline进一步的优 化， 例如减少 Pipeline中间结果的大小、 优化数据传输、 在可能的情况下融合操作以减少 上下文切换等等。 需要说明的是， 在构建 Pipeline过程中， 可以平衡资源使用、 并行计算的潜力和各种 算子的特性， 以便充分利用系统资源并优化查询性能。 参考图 3, 图 3为本公开实施例提供的一种数据查询计划对应的算子链的示意图。 如 图 3所示为包含两个 Join算子的数据执行计划对应的执行计划树， 该数据执行计划包括 算子链 1、 算子链 2和算子链 3。
5202、 根据连接算子和扫描算子， 获取算子链对应的过滤器构建信息。 其中， 过滤器构建信息包含算子链中连接算子的构建通道与扫描算子的过滤通道之 间的对应关系。 也就是说， 滤器构建信息用于指示： 将连接算子 (Hashjoin) 算子上某个 构建键 (Build key) 列上构建的 Filter, 匹配到 Hash Join算子所属 Pipeline中扫描算子
(Scan) 的某一列上， 交给 Scan算子的该列进行过滤计算。 具体的， 一个过滤器构建信息 S包含 Hash Join算子的一个构建通道 (Build
Channel) 和 Scan算子的一个过滤通道 (Filter Channel) , 其中， 通道指的是数据列在执 行器数据单元 (Chunk) 中的位置。 也即， 过滤器构建信息 S = { Channel； , Channels } 应理 解， 一个 Hash Join算子可能有多对连接键 (Join key) , 一个 Pipeline内部有多个 Hashjoin算子。 本步骤中， 过滤器构建信息 S的数量等于所有 Hashjoin算子的所有 Join key数量之和， 也即， 过滤器构建信息 S与 Hash Join算子的所有 Join key —一对应。
5203、 根据过滤器构建信息对应的过滤器的性能收益和 /或性能开销， 在算子链包含 的连接键中， 确定待构建过滤器的目标连接键。 示例性的， 一条记录从 Scan算子中读出后， 在 Hash Join算子上进行哈希表探测， 它 的访存开销为 C 引入 Runtime Filter后， 在 Scan算子中， 对该条记录需要进行 K 次映射， 每个映射 位置的访存开销和映射计算开销是 。2。 其中， 映射计算开销一般远小于访存开销， 因此 C* 2可以近似为单纯的访存开销。 进一 步的， 引入 Runtime Filter所增加的性能开销为： R ■ K ■ C2 ; 引入 Runtime Filter所带来的性能收益为： ( 1 — fpp) ( 1 — selectvity) ■ R・CL。 其 中， fpp为过滤器的假阳性误判率， 相应的， ( 1 - fpp) 为过滤器假阳性的修正 值， ( 1 — selectvity) 为 Hashjoin算子的筛选率。 本步骤中， 基于上述方案计算各过滤器对应的性能收益和 /或性能开销。 示例性的， 对于任意 Hashjoin算子中的 Join key N, 其对应的第 N过滤器的性能开销为： R - K - C2 , 性能收益为： ( 1 - fpp) ( 1 - selectvity) ■ R・CL, 若该第 N过滤器的性能开销和 /或性 能收益满足预设要求， 则确定构建该第 N过滤器不会造成系统的性能回退， 则该第 N过 滤器对影的 Join key N即为目标连接键。 至于根据性能收益和/或性能开销， 确定满足预设要求的过滤器的具体方式， 在后续 实施例中示出。
S204、 在目标连接键的 Build端构建过滤器。 其 中， 目标连接键用于在执行数据查询计划时基于过滤器过滤数据。 本公开实施例中， 能够充分考虑构建过滤器所带来的性能收益和性能开销， 从而选 择性的构建过滤器， 能够避免构建的过滤器的开销影响系统性能。 实施例一 本实施例中， 结合具体示例对上述步骤 S202进行详细说明： 在根据连接算子和扫描算子 ， 获取算子链对应的过滤器构建信息时， 具体包括如下 步骤：
①获取算子链 中的连接算子的构建键的第一标识信息和探查键的第二标识信息。 其 中， 连接算子的构建键的第一标识信息包括： 连接键 (Build key) 的表名和列名信 息； 探查键的第二标识信息包括： 探查键 (Probe key) 的表名和列名信息。 需要说明的是， 一个 Pipeline以及它的调度信息， 合称为一个算子链片段 (Pipeline Fragment) , 一个 Pipeline Fragment是 Pipeline在调度机制下的基本单位， 每个 Pipeline Fragment配置有一个片段内运行时过滤器管理器 ( Fragment- RF-Manager) 。
②针对每个连接算子上 的连接键， 基于连接键上的构建键的第一标识信息， 从连接 算子的元数据中获得过滤器构建信息中的构建通道； 以及， 基于连接键上的探查键的第 二标识信息， 从扫描算子中的元数据中获得与构建通道对应的过滤通道。 具体 的， 请参见图 4, 图 4为本公开一实施例提供的获取过滤器构建信息的原理示意 图。 如图 4所示， 对于构建通道 (Channel； ), 在自顶向下的遍历执行计划树的过程中， 当 遇到一个 Hash Join算子， 我们获取算子所归属 Pipeline Fragment 的 Fragment-RF- Manager, 将 Hashjoin算子每对 Join key 上的 ｛Build key, 探查键 (Probe key) ｝ 等信 息， 注册保存至 Fragment-RF-Manager 中， 同时， 根据第一标识信息 （即， Build key的 表名和列名信息） ， 查找 Hash Join算子的元数据， 从而找到构建通道 Build Channel （即， Channel；）o 对于过滤通道 （Channels） , 在自顶向下的遍历执行计划树的过程中， 当遍历到 Scan 算子时， 根据 Fragment-RF-Manager 收集得到的所有 ｛Build key, Probe key｝ 信息， 依 次读出第二标识信息 （即 Probe key的表名和列名信息） ， 同时， 根据第二标识信息， 在 Scan算子的元数据中查找其对应的通道， 得到 Filter Channel （即， Channels） 。
③根据算子链 中包含的连接键对应的构建通道与过滤通道， 获取算子链对应的过滤 器构建信息。 综上 ， 针对每个算子链， 执行上述步骤 ①②， 即可获得每个算子链对应的过滤器构 建信息 So 实施例二 本实施例 中， 结合具体示例对上述步骤 S203的一种实现方式进行详细说明： 具体的 ， 在根据过滤器构建信息对应的过滤器的性能收益和/或性能开销， 在算子链 包含的连接键中， 确定待构建过滤器的目标连接键时， 包括但不限于如下至少一种方 式：
①针对每个过滤器构建信息对应的过滤器， 获取过滤器的性能收益， 响应于性能收 益不小于预设性能收益， 则确定过滤器对应的连接键为目标连接键。 需要说明的是， 过滤器的性能收益需要超过其对应的性能开销， 才能使系统带来性 能收益。 也即， 若过滤器对应的性能收益 C1 - fpp） Cl - selectvity） ■ R ■ C±大于性能 开销 R・ K・勺， 则该过滤器对应的 Join key为目标连接键。 即， 若（1 — /pp）（l — selectvity） ■ R ■ Cx > R ■ K ■ C2, 则该过滤器对应的 Join key为 目标连接键。
②针对每个过滤器构建信息对应的过滤器， 获取过滤器对应的性能开销， 响应于性 能开销不大于预设性能开销， 则确定过滤器对应的连接键为目标连接键。 在一些实施例 中， 还可以预设性能开销， 若某一过滤器对应的性能开销值小于该预 设性能开销， 则认为构建该过滤器不会造成系统的性能回退， 那么该过滤器对应的连接 键即为目标连接键。 需要说明的是， 对于预设性能开销的具体数值， 本公开实施例不做 限定。 本公开是实施例 中， 只需要计算过滤器的性能开销， 而无需计算过滤器的性能收 益， 其计算量大大降低， 能够提升过滤器的构建效率。
③针对每个过滤器构建信息对应的过滤器， 获取过滤器的对应的性能开销和性能收 益， 响应于性能开销小于性能收益， 则确定过滤器对应的连接键为目标连接键。 类似的， 在一些实施例中， 还可以预设性能收益， 若某一过滤器对应的性能收益值 小于该预设性能收益， 则认为构建该过滤器会给系统带来性能收益， 那么该过滤器对应 的连接键即为目标连接键。 需要说明的是， 对于预设性能收益的具体数值， 本公开实施 例不做限定。 本公开是实施例 中， 只需要计算过滤器的性能收益， 而无需计算过滤器的性能开 销， 其计算量大大降低， 能够提升过滤器的构建效率。 实施例三 本实施例 中， 结合具体示例对上述步骤 S203的另一种实现方式进行详细说明： 具体的 ， 在根据过滤器构建信息对应的过滤器的性能收益和/或性能开销， 在算子链 包含的连接键中， 确定待构建过滤器的目标连接键时， 包括如下步骤：
①针对每个过滤器构建信息对应的过滤器， 获取过滤器的对应的性能开销和性能收 益； 获得过滤器的对应的性 能开销和性能收益的方式请参见上述实施例， 此处不做赘 述。
②根据性 能开销和性能收益， 获得过滤器对应的访存效率比； 其 中， 访存效率比为 K •学， 代表过滤器的访存效率和 Hashjoin 的哈希表访存效率的 Ci 比值。
③获取经过假 阳性修正的连接算子的筛选率； 其 中， (1 — fpp) 为过滤器假阳性的修正值， (1 — selectvity) 为 Hash Join算子的 筛选率， 经过假阳性修正的连接算子的筛选率即为 (1 - fpp) (1 — selectvity) 。
④根据访存 效率比和 /或筛选率， 确定过滤器对应的连接键是否为目标连接键。 具体的 ， 在根据访存效率比和 /或筛选率， 确定过滤器对应的连接键是否为目标连接 键， 包括如下至少一种方式： 方式一： 若访存效率比小于筛选率， 确定过滤器对应的连接算子为满足预设要求的 目标连接键， 若访存效率比大于或等于筛选率， 确定过滤器对应的连接算子并非目标连 接键。 具体的 ， (1 - fpp) (1 - selectvity) , 则该过滤器对应的连接算子为目 标连接键。 反之 ， (1 - fpp) (1 - selectvity) , 则该过滤器对应的连接算子并非目 标连接键。 方式二： 若筛选率 (1 - Selectivity)大于或等于预设筛选率， 确定过滤器对应的连接 键为目标连接键， 若筛选率 (1 - Selectivity)小于预设筛选率， 确定过滤器对应的连接算子 并非目标连接键。 也就是说 ， 在本方案中， 也可以不计算过滤器对应的访存效率比， 只根据过滤器对 应的筛选率来确定该过滤器是否能够给系统带来性能回退， 应理解， 对于预设筛选率的 大小， 本公开实施例不做特别限定。 通过本 方案， 可以大幅减少计算量， 进而一定程度的提升系统的性能。 方式三： 若访存效率比与预设访存效率比的差值小于第一预设值， 根据 Build端行 数， 确定过滤器对应的连接键是否为目标连接键。 类似的， 在本方案中， 还可以不计算筛选率， 只根据过滤器对应的访存效率比来确 定该过滤器是否能够给系统带来性能回退， 应理解， 对于预设访存效率比、 第一预设值 的大小， 本公开实施例不做特别限定， 例如， 预设访存效率比可以为 1。 通过 本方案， 可以大幅减少计算量， 进而一定程度的提升系统的性能。 另外， 通过 本实施例， 在构建完成哈希表后， 综合已有信息即可计算出 Ci、 C2和 Selectivity 的数 值， 将其代入上述方式一中的公式， 或者通过方式二、 方式三直接进行比对， 如果满足 则可以开启 Runtime Filter, 这就形成了一套自适应的 Runtime Filter开关机制， 使得系统 构建过滤器的自动化程度大幅提升， 进而提升数据查询效率。 实施例四 发明人发现， Join算子在进行基数估计、 选择度估计， 往往会出现较大的偏差， 这在 数据库中是很难避免的。 因此， 上述方案获得的 selectivty可能与真实值有较大差异。 有 鉴于此， 本公开实施例在 Selectivity估计值不准确时， 还可以通过如下至少一种情况来确 定过滤器对应的连接键是否为目标连接键： 情况一、 若 Build端行数大于第二预设值或者 Build端行数小于第三预设值， 则确定 过滤器对应的连接键为目标连接键。 情况二、 若 Build端行数小于或等于第二预设值， 或者， Build端行数大于或等于第 三预设值， 则确定过滤器对应的连接键并非目标连接键。 需要说明的是， 当构建 (Build) 端行数过少时， K •刍的值也接近于 1, 不可能为系 Ci 统带来收益。 在实际应用中， 可以根据哈希表内存空间占用来反推 Build 端行数， 从而确 定第二预设值。 示例性的， 例如获知物理机占用的内存空间 (例如， L1 缓存空间
(Cache Size) ) 为 32KB, 哈希表占用内存空间 (例如, 负载因子 Load_Factor) 为
0.5, 则满足 next_power_of_2(r / Load Factor)* 4Bytes < 32KB, Build端行数为 r, 综上可 以得出 r <4096 o 我们大致约定 Build端行数下界为 4096, 作为开启 Runtime Filter的条件 之一， 也即第二预设值可以设置为 4096 o 类似的， 当 Build端行数过多时， K •色的值也接近于 1, 也不可能为系统带来收益。
& 在实际应用中, 可以根据 Runtime Filler内存空间占用尺寸, 来确定第三预设值。 示例性 的， 以 Runtime Filter内存空间占用 (例如， L3 Cache Size) 为例， 获知物理 机器 L 3 Cache Size 为 16MB, 贝 0 next_power_of_2(r / 8) * 8Bytes> 16 MB, 其中， Build 端行数 r在 1000万到 2000万之间。 因此， 我们可以大致约定， 将 Build端总行数小于 2000万行作为开启 Runtime Filter的条件之一， 也即， 第三预设值可以设置为 2000万。 综上 ， 若 Build端行数大于 4096或者 Build端行数小于 2000万时， 则确定过滤器对 应的连接键为目标连接键， 也即， 该目标连接键可以构建过滤器。 若 Build端行数小于或等于 4096, 或者， Build端行数大于或等于 2000万， 则确定过 滤器对应的连接键并非目标连接键， 也即， 该目标连接键无需构建过滤器。 在一 些可选地情况中， 可以在过滤器构建后， 根据过滤器的过滤性来确定是否要关 闭过滤器。 在 Build端构建 Runtime Filter时， 尚且不能知道 Probe端过滤性情况， 因此， 在构建过滤器前， 无法通过 Probe端过滤性来确定是否能够构建过滤器， 只能在构建过滤 器后， 根据其过滤性判断是否关闭该过滤器， 从而尽可能避免该过滤器继续给系统带来 性能损失。 有 鉴于此， 我们可以在 Scan端引入一个动态的采样检查机制， 对每个批次内前 5~10 个 Chunk检查其过滤性， 当前 5~10个 Chunk的过滤性很差时， 则终止这个批次下 Runtime Filter的过滤计算， 也即关闭该过滤器。 当然， 这时 Runtime Filter已经构建完 成， 无法避免前 5~10个 Chunk的性能损失， 但是， 可以避免其继续为系统带来性能损 失。 实施例五 可以理解的是， 为充分利用系统的 CPU多核并行能力， 每个 Pipeline都可以交由多 个并行度来执行。 本公开实施例中， 在根据数据查询计划生成数据查询计划对应的至少 一个算子链之后， 还包括如下步骤：
①针对每个算子链 ， 确定算子链的并行度数量；
②根据并行度数量 ， 为算子链设置与并行度数量相同数量的线程， 线程用于执行算 子链中的连接算子。 具体 的， 可以根据评估的可用系统资源确定算子链的并行度数量， 其中， 系统资源 包括 CPU核心的数量、 内存容量和 10能力。 应理解， 并行度的设置不应超过系统能够 有效处理的资源限制， 否则可能导致过度的上下文切换、 资源竞争和性能下降。 另外， 数据的分布和划分方式对于实现有效的并行处理至关重要。 数据需要被划分 成足够多的分区， 以便多个处理器或节点可以并行工作。 数据分布的均匀性也会影响负 载平衡， 从而影响并行执行的效率。 请参考 图 5, 图 5为本公开实施例提供的算子链并行度示意图。 如图 5所示， 对于图 3所示的 3个算子链， 可以分别给这 3个算子链设置 3、 3、 4个并行度。 本公开实施例中， 通过为 Pipeline设置并行度， 可以大幅提高系统资源的利用率， 由 于设置多个并行度后， 允许在多个核心 /处理器上同时处理不同的查询阶段， 可以大幅提 升系统的数据查询性能。 实施例六 在一 些实施例中， 在目标连接键的 Build端构建过滤器时， 具体包括如下步骤：
①确定 目标连接键对应的数据分区模式；
②根据 目标连接键的数据分区模式， 在目标连接键的 Build端构建过滤器。 在一 些实施例中， 在一个 Pipeline Fragment内部， 根据数据分区和并行策略的不同， 可以将 Hashjoin算子划分为不同的数据分区模式 （Hashjoin算子对应的数据分区模式即 该 Hashjoin算子中目标连接键 （Join key） 对应的数据分区模式） ， 其中， 数据分区模式 包括第一分区模式 （Broadcast模式） 和第二分区模式 （Local模式） 两种模式。 其 中， 第一分区模式用于表征目标连接键的 Build端的各个分区对应于同一个哈希 表， 也即， Build端各个分区共享一个哈希表； 第二分区模式用于表征目标连接键的 Build 端的每个分区对应于不同的哈希表， 也即， Build端每个分区有各自独立维护的哈希表。 对应 的， 对于数据分区模式为第二分区模式 （Local模式） 的目标连接键， 可以为所 有分区构建一个共享的过滤器， 对于数据分区模式为第一分区模式 （Broadcast模式） 的 目标连接键， 分别构建各目标连接键对应的过滤器。 在构建过滤器 时， 具体包括如下几种情况： 情况一： 若目标连接键为第一分区模式， 针对目标连接键对应的每个线程， 构建线 程对应的过滤器分量， 并将目标连接键对应的线程的过滤器分量进行合并， 获得目标连 接键对应的过滤器。 具体 的， 在 Broadcast模式下， 在 Hash Join算子的 Build端， 各个线程共享同一个哈 希表， 也最终共享同一个过滤器。 在构建哈希表完成， 并确定需要构建过滤器的目标连 接键后， 各个线程协作共同开始构建过滤器。 请参考 图 6, 图 6为本公开一实施例提供的构建过滤器的原理示意图一。 如图 5所 示， 由于不同线程在同一时刻进行位置映射时， 有概率会映射到同一块内存区域， 如果 申请一块内存， 并由直接由各个线程进行写入的话， 则需要大量的并发安全开销， 有鉴 于此， 本公开实施例中， 需要额外的锁机制去确保内存区域的写入是并发安全的。 为了避免并发安全开销， 可以选择为每个线程本地构建一个过滤器分量 （RF component） , 其大小和最终 过滤器大小一致。 构建过程中， 每个线程写数据到本地的分 量中， 每个线程在构建完成后， 再获取一把写锁， 将过滤器分量合并至统一的过滤器 中。 需要说明的是， 过滤器分量的合并是将内存区域的全部比特位和目标过滤器内存区 域的全部比特位进行或预算并赋值。 这个过程由于预载 （prefetch） 的能力会非常快速， 因此可以通过写锁来对各个线程内的分量进行排队执行。 情况二： 若目标连接键为第二分区模式， 针对目标连接键对应的每个分区， 构建分 区对应的局部过滤器， 以获得目标连接键对应的过滤器。 具体 的， 在 Local模式下， 每个分区使用自己独立的哈希表， 每个 Chunk内的所有数 据， 都来自于同一个表分区， 此时， 一个线程可能处理多个分区的哈希表构建与过滤器 的构建； 也可能多个线程共同完成一个分区内的哈希表构建与过滤器的构建。 请参考 图 7, 图 7为本公开一实施例提供的构建过滤器的原理示意图一。 如图 5所 示， 若目标连接键为第一分区模式时， 在构建过滤器的过程中， 首先， 为每个分区形成 一个局部过滤器（Partial Runtime Filter） o 进一 步的， 一个线程对每个 Chunk进行分区判断， 找到 Chunk对应分区的 Partial
Runtime Filter。 更进一 步的， 将持有该 Partial Runtime Filter的分区写锁， 再进行数据写入， 避免其 他线程对同一个分区的 Partial Runtime Filter进行修改时所产生的并发安全问题。 最后， 将结果保存在 Partial Runtime Filter的数组中， 数组的每个位置存放对应分区 的 Partial Runtime Filter, 不再对每个 Partial Runtime Filter进行合并。 实施例七 请参考 图 8, 图 8为本公开一实施例提供的数据查询方法的流程示意图。 如图 8所 示， 在进行数据查询时， 具体包括如下步骤：
5801、 响应于数据查询计划， 在数据查询计划对应的算子链中构建过滤器。 需要说明的是， 步骤 S801的实现方式请参考上述实施例中的过滤器构建方法对应的 实施例， 此处不做赘述。
5802、 执行数据查询计划对应的算子链， 并基于过滤器过滤数据， 获得数据查询计 划对应的数据查询结果。 具体 的， 可以利用实施例一种提到的 Fragment- RF-Manager组件， 来将构建好的过滤 器传递到扫描算子中。 在本公开实施例中， 采用轻量化的设计， 过滤器的传递仅通过内 存， 而不需要通过服务器-客户机 （Client-Server） 模式等机制进行传递。 请参考图 9, 图 9为本公开一实施例提供的传递过滤器的原理示意 图。 如图 9所示， 在传递过滤器过程 中， 具体包括如下操作： 首先， 将不同模式下并行构建好的 Runtime Filter, 保存在 Fragment-RF-Manager的字 段中； 进一步的， Scan算子在处理每个 Chunk时， 都检测 Fragment-RF-Manager的字段 中是否包含 Runtime Filter字段数据； 如果存在， 则使用 Runtime Filter进行额外的数据过 滤， 若不存在， 按照没有 Runtime Filter的普通模式来执行数据查询计划。 具体 的， 请参考图 10, 10为本公开一实施例提供的扫描算子的执行过程的原理示意 图。 如图 10所示， 在 Scan算子的执行过程中， 具体包括如下几个阶段： 在调度 阶段， 调度器将 Runtime Filter管理器 （后文称 RF Manager） 注册到 Scan算 子中；
Scan在执行期间， 会枚举出 RF Manager的各个 Runtime Filter项目 （后文称 RF item） , 检测每个项目 （item） 是否已经存在创建好的 Runtime Filter （即， 基于过滤器项 目键值
（RF item key） 确定 item中是否表示已经存在创建好的 Runtime Filter） 。 在 Scan算子的执行阶段， Scan算子在动态检出 Runtime Filter 前后， 存在如下两种 流程： 流程一 : 当不存在 Runtime Filter 时， 包括如下操作： 操作 1、 利用逻辑行 （Logical Row Group） 组件， 枚举出可读的逻辑数据范围； 操作 2、 利用线性加载 （Stripe Loader） 组件， 执行各个列的 IO预取任务 （Prefetch
IO Task） ； 操作 3、 结合操作 1和操作 2, 获得过滤列， 执行过滤计算， 获得过滤结果 （例如 是， 位图 （Bitmap） ） 。 操作 4、 将 Bitmap 应用到操作 1和操作 2得到的 Project列。 流程二 ： 当 RF Manager中的某个 item被检测出存在创建好的 Runtime Filter时， 包 括如下操作： 首先， 针对算子链中所构建的每个过滤器， 获取过滤器在执行数据查询计划的过程 中进行数据过滤的过滤效果。 具体 的， 基于算子链执行数据查询计划时， 首先， 将 Runtime Filter列加入 Stripe Loader组件中， 创建属于该列的 10预取任务， 再将 RF item 注册到过滤器中， 通过过滤 器进行数据过滤， 同时通过效果检查器对每个批次的前 N个 Chunk进行有效性检查 （前 N 个 Chunk即为效果检查样本） ， 应理解， 对于 N的值， 本公开实施例不做特别限定。 进一 步的， 若过滤效果不小于阈值， 则在执行数据查询计划的过程中继续使用过滤 器进行数据过滤； 若过滤效果小于阈值， 则在执行数据查询计划的过程中停止采用过滤 器进行数据过滤。 具体 的， 过滤器可以对 Block和 Runtime Filter进行过滤计算， 检测 Block每个位置 的存在性， 获得 Bitmap o 针对上述 Bitmap, 统计收集过滤效果， 如果过滤效果超过阈值 （阈值例如时
25%） , 则过滤器的有效性检查可以通过。 也即， 当前 N个 Chunk通过有效性检查时， 则采用 Runtime Filter继续执行后续的 Chunko 如 果过滤效果未超过阈值， 则将拒绝 Runtime Filter的执行。 也即， 当前 N个 Chunk 未通过有效性检查时， 禁用 Runtime Filter执行后续的 Chunko 示例性 的， 请参考图 11 , 图 11为本公开一实施例提供的数据查询计划 Q5执行过程 的原理示意图。 如图 11所示， 在 Q5的执行过程中， 存在一个大的 Pipeline, 该 Pipeline 包括如下三对 Join关系： l_orderkey = o_orderkey
Lsuppkey = s_suppkey n_nationkey = s_nationkey 应 当理解的是， 本公开实施例中， 有效性检查可以由接口 RfefficiencyChecker完成。 基 于本公开实施例， 可以形成 Q5对应的三种 Runtime Filter, 对 Pipeline内行项目
（Llineitem） 表 Scan的过滤效果为 60亿行 ＞ 3.1亿行。 因此， 根据上述实施例四所提供的收益计算方法， 可以得出 n_nationkey = s_nationkey 对应的 Build端行数过小 （25 行） ， 则该 Join key所形成的 Runtime Filter 被禁用。 根据 本实施例中提供的有效性检查方法， 可以得出， l.suppkey = s_suppkey 所形成 的 Runtime Filter, 在 Scan侧采样检出的过滤性低于 25%, 因此在 Scan过滤过程中被禁 用 O 综上 ， 最终真正产生实际效果的是 l_orderkey = o_orderkey所形成的 Runtime Filter , 因此， 继续使用 l_orderkey = o_orderkey所形成的 Runtime Filter过滤数据， 禁用 n_nationkey = s_nationkey 另口 l_suppkey = s_suppkey所形成的 Runtime Filter过滤数据。 综上 ， 由于 l_suppkey = s_suppkey 所形成的 Runtime Filter的过滤性较差， 还会额外 引入 Lsuppkey的 10开销， 通过本公开实施例中提供的有效性检查， 可以禁用该过滤 器， 从而避免过滤效果较差的过滤器对系统带来的性能影响， 进而提升系统性能。 实施例八 在一 些实施例中， 本公开实施例提供的过滤器可以为布隆过滤器 (Bloom Filter) 和 阻塞布隆过滤器 (Blocked Bloom Filter) 中的至少一种。 其 中， Bloom Filter是 Runtime Filter 最主要的实现方式， 它是一种数据摘要， 可以 以更小的存储空间来表示一批数据的存在性。
Bloom Filter在进行数据过滤过程中， 针对一条数据， 利用 K次映射函数， 将数据映 射到一段内存空间的不同位置 (一个比特位) ， 每个被映射到的位置将比特位设置为 1。 当需要判断数据的存在性时， 重复刚刚的 K次映射过程， 如果检查所有映射得到的比特 位为 1, 则判定数据存在。 反之， 如果存在比特位为 0的情况， 则判定数据不存在。 需要说明的是， Bloom Filter有一定的错误率， 将不存在的数据判定为存在。 这一特 性也称为假阳性 (False-Positive) , 错误率 fpp —般取 0.03〜 0.1。 以 Bloom Filter为例， 有以下推论： 在一个 Pipeline算子链中， 从 Scan算子到 Hashjoin算子的执行链路越复杂， 对 Runtime Filter本身性能要求越低； 反之， 执行链路越简单， 对 Runtime Filter本身性能要 求越高 O 证 明： 一个 Runtime Filter在总行数为 total_rows的数据集上的过滤行数为 Filtered_rows? 每行的平均开销为 L; 计算链路每行平均开销为 M。 如 果 Runtime Filter是有效的， 必须满足 M * Filtered_rows > L * total_rows , 也即 L V 当 Runtime Filter算法相同时， 代表过滤性的分数， 是个定值， 因此， 当 M越小、 复 杂性越低， 开销 L也就需要更小， 对 Runtime Filter性能要求更严格。 基 于这个推论， 我们构造一个足够简单的场景。 假设一个 Pipeline由 Scan算子和 Hashjoin算子构成：
Hashjoin的一对 Join key对 Probe侧数据的选择率是 Selectivity
(0<Selectivity<l) 。 设 Probe端输入行数为 Ro
Scan算子的数据全部存在于内存中， 不需要经过 10操作；
Scan算子到 Join算子的执行链路上没有其他计算耗时算子。 这样 的条件下， 对 Runtime Filter的性能要求是最苛刻的。 因为此时的执行开销最 低， 仅包括 Hashjoin Probe端的哈希表探测， 整个过程均发生在内存中， 不存在 10开 销、 中间算子计算开销。
Runtime Filter的构建、 计算和传递开销必须低于这个执行开销， 才能有机会获得正 向性能收益。 换 言之， 如果能满足这种苛刻的性能要求， Runtime Filter也就能在其他的执行场景 获得收益。 在一 些实施例中， 可以通过升 Runtime Filter的访存效率， 来减小上文提到的访存效 率比。 进而提升系统的性能收益。 考虑针对 大规模数据集下的复杂查询， Hashjoin的哈希表无法完全容纳在 CPU L1/L2/L3缓存内， 探测过程相当于是对主存的随机访问， 访存效率 C 1-240 cycle o 传 统的 Bloom Filter实现， 是给定元素数量和容错率， 根据经典的 Bloom Filter计算 公式得出映射次数 K和内存大小来构建； 读取时， 一条记录的 K次映射会随机散布到内 存区域的不相邻位置， 访存时无法利用预取、 Cache line等特性， 访存效率完全是数据所 在区域 ( Ll/L2/L3/main memory) 访问速度的 K倍。 因此， 如果对 Bloom Filter的访问也是 K次对主存的随机访问， 则访存效率 C2 = K*240 cycle, K>=1, C2>Ci是不可接受的； 且 ， Bloom Filter必须至少 fit in L3 Cache, 也就是能被 L3容纳下。 近几年主流 CPU 架构中， 典型的 L3大小是 10MB-64MB, 访问速度是 3O~8Ocycle, 由一个 Socket内的多 个物理 CPU核共享。 另外， 其映射次数 K不能太大。 综上 ， 为了改善上述问题， 本公开实施例中， 过滤器还可以使用访存性能更好的阻 塞布隆过滤器 (Blocked Bloom Filter)。 接下来， 对 Blocked Bloom Filter的构建过程和访存 效率比进行说明： 具体 的， 在构建 Blocked Bloom Filter时， 首先， 使用数组大小近似为 (元素数量 /8) 的长数组来构造内存区域， 其中， 每条记录的映射次数 K=2, 每条记录的映射位置在内 存区域中跨度不超过 512bito 进一 步的， 在读取 Blocked Bloom Filter时， 每条记录的映射次数 K=2, 将每条记录 的两个映射比特位读出并检查， 在新的 Blocked Bloom Filter算法下， 访存次数可以近似 为 1。 这是因为， 映射次数虽然固定为 2次， 但是映射的目标位置跨度小于 512bit, 得益 于 CPU 的缓存 (Cache) 以及读取 (Prefetch) 能力， 大概率可以在单次访存中， 容纳于 一个缓存行 (Cache line) 内部。 相应 的， 对于 Blocked Bloom Filter, 在完成调度并完成 Hash Join算子的哈希表构建 后， 结合上文的性能收益公式， 以及上下文信息， 可以设计出一套自适应的 Runtime Filter开关。 其中， Selectivity可以利用数据库本身的统计信息和代价估计模型， 进行估 算； fpp值取 0.03-0.1, 影响较小； Ci和 C2的大小取决于哈希表和 Runtime Filter各自 占用的内存空间大小， 而哈希表和 Runtime Filter大小， 都取决于 Build端的行数。 在 本实施例中， 哈希表内存空间占用为 next_power_of_2(r / Load Factor)* 4Bytes : 根 据 blocked Bloom Filter算法， Runtime Filter内存空间占用为 next_power_of_2(r / 8)* 8ByteSo 其 中， next_power_of_2(x) 代表大于 x的最小 2的整数次赛， r代表 Build端行数， Load Factor是哈希表参数， 一般取 0.25-0.75 ; Ci 取决于哈希表内存占用大小， 以及物理 机器的 CPU架构信息。 需要说明的是， 如果哈希表内存占用超过 L3/L2/L1 Cach e大小， 则 Ci分别近似于主 存访问速度 (250cycle) 、 L3 访问速度 (50cycle)、 L2访问速度 ( 15cycle) , 以此类推。 应理解 ， C2的计算同上， 如果 Runtime Filter 内存空间占用超过 L3/L2/L1 Cache大 小， 则 C2分别近似于主存访问速度 (250cycle) 、 L3 访问速度 (50 cycle)、 L2访问速度 ( 15cycle) , 以此类推。 另外， 在 Blocked Bloom Filter算法实现的基础上， 由于每行记录映射后的访存跨度 小于 512bit, 则 K可以近似为 1, 上文已有叙述。 综上 ， 在构建哈希表完成后， 综合已有信息计算出 Ci, C2 和 Selectivity 参数值， 代入性能收益公式看是否满足， 如果满足则可以开启 Runtime Filtero 这就形成了一套自 适应的 Runtime Filter开关机制。 另外， 对于 Broadcast模式和 Local模式， 需要做一些额外的调整。 示例性 的， 在 Broadcast模式下， Runtime Filter被所有分区共享， 因此只要唯一的 Runtime Filter满足性能收益关系即可； 在 Local模式下， Runtime Filter 划分为多个分区 内的局部 parital Runtime Filter, 在计算性能收益关系中的 C2值时， 需要考虑 Build端所 有分区的总行数是否能够容纳在 L1/L2/L3 Cache中。 在一 些实施例中， Join算子的基数估计、 选择度估计， 往往会出现较大的偏差， 这在 数据库中是很难避免的。 因此， 在 selectivty与真实值有较大差异时， 我们需要为性能收 益模型计算一个大致的边界， 尽量避免出现误判。 当 Selectivity估计值不准确， 我们需要考虑下列三种情形， 来大致划定边界阈值： 情形 1 : Build端行数过多， Ci 、 C2均等于主存访问延迟， 此时是没有必要开启 Runtime Filter的， 因为接近于 1了， 不可能满足收益模型中的大小关系。 Runtime Filter 内存空间占用将超过 L3 Cache大小， 我们可以反推此时 Build 端行数， 将 Build端行数 作为判断的阈值。 例如， 获知物理机器 L3 Cache Size = 16MB, 贝 0 next_power_of_2(r / 8) * 8Bytes> 16 MB, r为 Build端行数， 在 1000万到 2000万之间。 因此， 我们可以大致约 定， 将 Build端总行数 1、于 2000万行作为开启 Runtime Filter的条件之一。 情形 2： Build端行数过少， Ci、 C2 数值差别不大， 此时也接近于 1了， 访存延迟 G 本身就很小， 哈希表往往能容纳在 LI Cache中。 可以根据哈希 表 内存空间占用来反推 Build 端行数的大小。 例如获知物理机器 L Id Cache Size = 32KB , 哈希表 Load_Factor = 0.5 , 则满足 next_power_of_2(r / Load Factor)* 4Bytes < 32KB, r为 Build端行数， r <4096。 我们大致约定 Build端行数下界为 4096, 作为开启 Runtime Filter的条件之一。 情形 3 : 过滤性非常差， 即 Selectivity相比于估计值偏大时， 无法通过 Build端行数 来约束， 因为在 Build端构建 Runtime Filter时， 尚且不能知道 Probe端过滤性情况。 因 此， 我们可以在 Scan侧引入一个动态的采样检查机制， 对每个批次内前 5~1。个 Chunk 检查其过滤性的好坏； 当前 5~10个 Chunk的过滤性很差时， 则终止这个批次下 Runtime Filter的过滤计算。 当然， 这时 Runtime Filter已经构建完成， 无法避免这构建过程以及处 理这 5~10个 Chunk时对应的性能损失。 参考 图 12, 图 12为本公开一实施例提供的过滤器构建装置的结构示意图。 如图 12 所示， 该过滤器构建装置 1200包括： 生成模块 1201 , 用根据数据查询计划生成数据查询计划对应的算子链， 算子链包括 多个线性连接的算子， 算子包括连接算子和扫描算子； 获取模块 1202, 用于根据连接算子和扫描算子， 获取算子链对应的过滤器构建信 息 ， 过滤器构建信息包含算子链中连接算子的构建通道与扫描算子的过滤通道之间的对 应关系 ； 确定模块 1203, 用于根据过滤器构建信息对应的过滤器的性能收益和 /或性能开销， 在算子链包含的连接键中， 确定待构建过滤器的目标连接键； 构建模块 1204, 用于在目标连接键的构建端构建过滤器 ， 目标连接键用于在执行数 据查询计划时基于过滤器过滤数据。 在一些可选地实施例 中， 获取模块 1202具体用于： 获取算子链中的连接算子的构建 键的第一标识信息和探查键的第二标识信息； 针对每个连接算子上的连接键， 基于连接 键上的构建键的第一标识信息， 从连接算子的元数据中获得过滤器构建信息中的构建通 道； 以及， 基于连接键上的探查键的第二标识信息， 从扫描算子中的元数据中获得与构 建通道对应的过滤通道； 根据算子链中包含的连接键对应的构建通道与过滤通道， 获取 算子链对应的过滤器构建信息。 在一些可选地实施例 中， 确定模块 1203具体用于如下至少一种： 针对每个过滤器构建信息对应的过滤器， 获取过滤器的性能收益， 响应于性能收益 不小于预设性能收益， 则确定过滤器对应的连接键为目标连接键； 针对每个过滤器构建信息对应的过滤器， 获取过滤器对应的性能开销， 响应于性能 开销不大于预设性能开销， 则确定过滤器对应的连接键为目标连接键； 针对每个过滤器构建信息对应的过滤器， 获取过滤器的对应的性能开销和性能收 益， 响应于性能开销小于性能收益， 则确定过滤器对应的连接键为目标连接键。 在一些可选地实施例 中， 确定模块 1203具体用于： 针对每个过滤器构建信息对应的 过滤器， 获取过滤器的对应的性能开销和性能收益； 根据性能开销和性能收益， 获得过 滤器对应的访存效率比； 获取经过假阳性修正的连接算子的筛选率； 根据访存效率比和 / 或筛选率， 确定过滤器对应的连接键是否为目标连接键。 在一些可选地实施例 中， 确定模块 1203具体用于如下至少一种： 若访存 效率比小于筛选率， 确定过滤器对应的连接算子为满足预设要求的目标连接 键， 若访存效率比大于或等于筛选率， 确定过滤器对应的连接算子并非目标连接键； 若 筛选率大于或等于预设筛选率， 确定过滤器对应的连接键为目标连接键， 若筛选 率小于预设筛选率， 确定过滤器对应的连接算子并非目标连接键； 若访存 效率比与预设访存效率比的差值小于第一预设值， 根据构建端行数， 确定过 滤器对应的连接键是否为目标连接键。 在一些可选地实施例 中， 确定模块 1203具体用于： 若构建端行数大于第二预设值或 者构建端行数小于第三预设值， 则确定过滤器对应的连接键为目标连接键； 若构建端行 数小于或等于第二预设值， 或者， 构建端行数大于或等于第三预设值， 则确定过滤器对 应的连接键并非目标连接键。 在一 些可选地实施例中， 确定模块 1203还用于： 针对每个算子链， 确定算子链的并 行度数量； 根据并行度数量， 为算子链设置与并行度数量相同数量的线程， 线程用于执 行算子链中的连接算子。 在一 些可选地实施例中， 构建模块 1204具体用于： 确定目标连接键对应的数据分区 模式； 根据目标连接键的数据分区模式， 在目标连接键的构建端构建过滤器； 其 中， 数据分区模式包括第一分区模式和第二分区模式， 第一分区模式用于表征目 标连接键的构建端的各个分区对应于同一个哈希表， 第二分区模式用于表征目标连接键 的构建端的每个分区对应于不同的哈希表。 在一 些可选地实施例中， 构建模块 1204具体用于： 若目标连接键为第一分区模式， 针对目标连接键对应的每个线程， 构建线程对应的过滤器分量， 并将目标连接键对应的 线程的过滤器分量进行合并， 获得目标连接键对应的过滤器； 若目标连接键为第二分区 模式， 针对目标连接键对应的每个分区， 构建分区对应的局部过滤器， 以获得目标连接 键对应的过滤器。 在一 些可选地实施例中， 过滤器为布隆过滤器和阻塞布隆过滤器中的至少一种。 需要说明的是， 本公开实施例提供的过滤器构建装置， 用于执行前述相应方法实施 例中的技术方案， 其实现原理和技术效果类似， 在此不再赘述。 参考 图 13, 图 13为本公开一实施例提供的数据查询装置的结构示意图。 如图 13所 示， 本公开实施例提供的数据查询装置 1300, 包括： 过滤 器构建装置 1200, 用于响应于数据查询计划， 在数据查询计划对应的算子链中 构建过滤器； 查询模块 1301 , 用于执行数据查询计划对应的算子链， 并基于过滤器过滤数据， 获 得数据查询计划对应的数据查询结果。 在一 些可选地实施例中， 查询模块 1301还用于： 针对算子链中所构建的每个过滤 器， 获取过滤器在执行数据查询计划的过程中进行数据过滤的过滤效果； 若过滤 效果不小于阈值， 则在执行数据查询计划的过程中继续使用过滤器进行数据 过滤； 若过滤 效果小于阈值， 则在执行数据查询计划的过程中停止采用过滤器进行数据过 滤。 需要说明的是， 本公开实施例提供的数据查询装置中各部分模块所执行的功能， 对 应于前述相应方法实施例中的技术方案， 其实现原理和技术效果类似， 在此也不再赘 述。 参考 图 14, 图 14为本公开一实施例提供的电子设备的结构示意图。 如图 14所示， 该电子设备 1400包括： 至少一个处理器 1401 （图 14中仅示出了一个处理器） ； 以及， 与至少一个处理器通信连接的存储器 1402o 其中， 存储器 1402存储有可被至少一个处理 器 1401执行的指令， 指令被至少一个处理器 1401执行， 以使电子设备 1400能够执行前 述任一方法实施例中的技术方案。 可选的， 存储器 1402既可以是独立的， 也可以跟处理器 1401集成在一起。 存储器 1402可以由任何类型的易失性或非易失性存储设备或者它们的组合实现， 如静态随机存 取存储器 （SRAM） , 电可擦除可编程只读存储器 （EEPROM） , 可擦除可编程只读存储 器 （EPROM） , 可编程只读存储器 （PROM） , 只读存储器 （ROM） , 磁存储器， 快闪 存储器， 磁盘或光盘。 处理器 1401 , 与存储器 1402耦合， 用于执行存储器 1402中的计 算机程序， 以用于执行上述方法实施例中任一过滤器构建方法实施例的技术方案， 和 / 或， 执行前述任一数据查询方法实施例的技术方案。 应理解 ， 上述处理器 1401可以是处理单元 （英文： Central Processing Unit, 简称： CPU） , 还可以是其他通用处理器、 数字信号处理器 （英文： Digital Signal Processor, 简 称： DSP） 、 专用集成电路 （英文： Application Specific Integrated Circuit, 简称： ASIC） 等。 通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。 结合发明 所公开的方法的步骤可以直接体现为硬件处理器执行完成， 或者用处理器中的硬件及软 件模块组合执行完成。 可选地， 当存储器 1402是独立于处理器 1401之外的器件时， 电子设备 1400还包 括： 总线 1403, 用于连接存储器 1402和处理器 1401 o 其中， 总线 1403可以是工业标准 体系结构 （Industry Standard Architecture, ISA） 总线、 外部设备互连 （Peripheral Component, PCI） 总线或扩展工业标准体系结构 （Extended Industry Standard Architecture, EISA） 总线等。 总线可以分为地址总线、 数据总线、 控制总线等。 为便于 表示， 本公开附图中的总线并不限定仅有一根总线或一种类型的总线。 需要说明的是， 图 14中仅示意性给出部分组件， 并不意味着电子设备 1400只包括 图 14所示组件。 在一些实施例中， 该电子设备 1400还包括： 防火墙、 负载均衡器、 通 信组件、 电源组件等其它组件。 可选的， 电子设备 1400可以为移动终端、 服务器等设 备。 上述 的通信组件被配置为便于通信组件所在设备和其他设备之间有线或无线方式的 通信。 通信组件所在设备可以接入基于通信标准的无线网络， 如 WiFi, 2G、 3G、 4G/LTE, 5G等移动通信网络， 或它们的组合。 在一个示例性实施例中， 通信组件经由广 播信道接收来自外部广播管理系统的广播信号或广播相关信息。 在一个示例性实施例 中， 通信组件还包括近场通信 （NFC） 模块， 以促进短程通信。 例如， 在 NFC模块可基 于射频识别 （RFID） 技术， 红外数据协会 （IrDA） 技术， 超宽带 （UWB） 技术， 蓝牙 （BT） 技术和其他技术来实现。 需要说明的是， 本公开实施例提供的电子设备 1400可以执行前述任一过滤器构建方 法实施例的技术方案， 和 /或， 执行前述任一数据查询方法实施例的技术方案， 其实现原 理和技术效果类似， 在此不再赘述。 本领域内的技术人员应明白， 本公开的实施例可提供为方法、 系统、 或计算机程序 产品。 因此， 本公开可采用完全硬件实施例、 完全软件实施例、 或结合软件和硬件方面 的实施例的形式。 而且， 本公开可采用在一个或多个其中包含有计算机可用程序代码的 计算机可用存储介质 （包括但不限于磁盘存储器、 CD-ROM, 光学存储器等） 上实施的 计算机程序产品的形式。 相应地 ， 本公开实施例还提供一种计算机可读存储介质， 计算机可读存储介质中存 储有计算机执行指令， 当处理器执行计算机执行指令时， 用于实现前述任一过滤器构建 方法实施例的技术方案， 和 /或， 执行前述任一数据查询方法实施例的技术方案。 一种示例性 的， 存储介质耦合至处理器， 从而使处理器能够从该存储介质读取信 息， 且可向该存储介质写入信息。 当然， 存储介质也可以是处理器的组成部分。 处理器 和存储介质可以位于专用集成电路 (Application Specific Integrated Circuits , 简称： ASIC) 中。 当然， 处理器和存储介质也可以作为分立组件存在于电子设备中。 相应地 ， 本公开实施例提供一种计算机程序产品， 包括计算机程序， 该计算机程序 被处理器执行时实现前述任一过滤器构建方法实施例的技术方案， 和 /或， 执行前述任一 数据查询方法实施例的技术方案。 相应地 ， 本公开实施例还提供了一种芯片， 包括： 处理模块与通信接口， 该处理模 块能执行前述方法实施例中任一过滤器构建方法实施例的技术方案， 和 /或， 执行前述任 一数据查询方法实施例的技术方案。 进一 步地， 该芯片还包括存储模块 (如， 存储器) ， 存储模块用于存储指令， 处理 模块用于执行存储模块存储的指令， 并且对存储模块中存储的指令的执行使得处理模块 执行前述方法实施例中的技术方案。 本领域普通技术人员可以意识到， 结合本文中所公开的实施例描述的各示例的单元 及算法步骤， 能够以电子硬件、 计算机软件或者计算机软件和电子硬件的结合来实现。 这些功能究竟以硬件还是软件方式来执行， 取决于技术方案的特定应用和设计约束条 件。 专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能， 但是这 种实现不应认为超出本公开的范围。 功 能如果以软件功能单元的形式实现并作为独立的产品销售或使用时， 可以存储在 一个计算机可读取存储介质中。 针对这样的理解， 本公开的技术方案本质上或者说对现 有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来， 该计算 机软件产品存储在一个存储介质中， 包括若干指令用以使得一台计算机设备 (可以是个 人计算机， 服务器， 或者网络设备等) 执行本公开各个实施例方法的全部或部分步骤。 而前述的存储介质包括： U盘、 移动硬盘、 只读存储器 (Read-Only Memory, ROM) 、 随机存取存储器 (Random Access Memory, RAM) 、 磁碟或者光盘等各种可以存储程序 代码的介质。 还 需要说明的是， 术语 “包括”、 “包含 ”或者其任何其他变体意在涵盖非排他性的包 含， 从而使得包括一系列要素的过程、 方法、 商品或者设备不仅包括那些要素， 而且还 包括没有明确列出的其他要素， 或者是还包括为这种过程、 方法、 商品或者设备所固有 的要素。 在没有更多限制的情况下， 由语句 “包括一个 ..... ”限定的要素， 并不排除在包括 要素的过程、 方法、 商品或者设备中还存在另外的相同要素。 需要说明的是， 在上述实施例及附图中的描述的一些流程中， 包含了按照特定顺序 出现的多个操作， 但是应该清楚了解， 这些操作可以不按照其在本文中出现的顺序来执 行或并行执行， 操作的序号如 S201、 S202等， 仅仅是用于区分开各个不同的操作， 序号 本身不代表任何的执行顺序。 另外， 这些流程可以包括更多或更少的操作， 并且这些操 作可以按顺序执行或并行执行。 需要说明的是， 本文中的 “第一”、 “第二 ”等描述， 是用于 区分不同的消息、 设备、 模块等， 不代表先后顺序， 也不限定 “第一 ”和 “第二 ”是不同的类 型。

Claims

权 利 要 求 书
1、 一种过滤器构建方法， 其中， 包括： 根据数据查询计划生成所述数据查询计划对应的算子链， 所述算子链包括多个线性连接 的算子， 所述算子包括连接算子和扫描算子； 根据所述连接算子和所述扫描算子， 获取算子链对应的过滤器构建信息， 所述过滤器构 建信息包含所述算子链中连接算子的构建通道与扫描算子的过滤通道之间的对应关系； 根据所述过滤器构建信息对应的过滤器的性能收益和 /或性能开销， 在所述算子链包含 的连接键中， 确定待构建过滤器的目标连接键； 在所述 目标连接键的构建端构建过滤器， 所述目标连接键用于在执行所述数据查询计划 时基于所述过滤器过滤数据。
2、 根据权利要求 1所述的过滤器构建方法， 其中， 所述根据所述连接算子和所述扫描 算子， 获取所述算子链对应的过滤器构建信息， 包括： 获取所述算子链 中的所述连接算子的构建键的第一标识信息和探查键的第二标识信息； 针对每个所述连接算子上的连接键， 基于所述连接键上的构建键的所述第一标识信息， 从所述连接算子的元数据中获得所述过滤器构建信息中的构建通道； 以及， 基于所述连接键 上的探查键的所述第二标识信息， 从所述扫描算子中的元数据中获得与所述构建通道对应的 过滤通道； 根据所述算子链 中包含的所述连接键对应的构建通道与过滤通道， 获取所述算子链对应 的过滤器构建信息。
3、 根据权利要求 1或 2所述的过滤器构建方法， 其中， 所述根据所述过滤器构建信息 对应的过滤器的性能收益和 /或性能开销， 在所述算子链包含的连接键中， 确定待构建过滤 器的目标连接键， 包括如下至少一种： 针对每个所述过滤器构建信息对应的过滤器， 获取所述过滤器的性能收益， 响应于所述 性能收益不小于预设性能收益， 则确定所述过滤器对应的连接键为所述目标连接键； 针对每个所述过滤器构建信息对应的过滤器， 获取所述过滤器对应的性能开销， 响应于 所述性能开销不大于预设性能开销， 则确定所述过滤器对应的连接键为所述目标连接键； 针对每个所述过滤器构建信息对应的过滤器， 获取所述过滤器的对应的性能开销和性能 收益， 响应于所述性能开销小于所述性能收益， 则确定所述过滤器对应的连接键为所述目标 连接键。
4、 根据权利要求 1或 2所述的过滤器构建方法， 其中， 所述根据所述过滤器构建信息 对应的过滤器的性能收益和 /或性能开销， 在所述算子链包含的连接键中， 确定待构建过滤 器的目标连接键， 包括： 针对每个所述过滤器构建信息对应的过滤器， 获取所述过滤器的对应的性能开销和性能 收益； 根据所述性能开销和所述性能收益， 获得所述过滤器对应的访存效率比；
22 获取经过假 阳性修正的连接算子的筛选率； 根据所述访存 效率比和 /或所述筛选率， 确定所述过滤器对应的连接键是否为所述目标 连接键。
5、 根据权利要求 4所述的过滤器构建方法， 其中， 所述根据所述访存效率比和/或所述 筛选率， 确定所述过滤器对应的连接键是否为所述目标连接键， 包括如下至少一种： 若所述访存 效率比小于所述筛选率， 确定所述过滤器对应的连接算子为所述目标连接 键， 若访存效率比大于或等于所述筛选率， 确定所述过滤器对应的连接算子并非所述目标连 接键； 若所述 筛选率大于或等于预设筛选率， 确定所述过滤器对应的连接键为目标连接键， 若 所述筛选率小于所述预设筛选率， 确定所述过滤器对应的连接算子并非所述目标连接键； 若所述访存 效率比与预设访存效率比的差值小于第一预设值， 根据所述构建端行数， 确 定所述过滤器对应的连接键是否为所述目标连接键。
6、 根据权利要求 5所述的过滤器构建方法， 其中， 所述根据所述构建端行数， 确定所 述过滤器对应的连接键是否为所述目标连接键， 包括： 若所述构建端行数 大于第二预设值或者所述构建端行数小于第三预设值， 则确定所述过 滤器对应的连接键为所述目标连接键； 若所述构建端行数 小于或等于所述第二预设值， 或者， 所述构建端行数大于或等于所述 第三预设值， 则确定所述过滤器对应的连接键并非所述目标连接键。
7、 根据权利要求 1至 6中任一项所述的过滤器构建方法， 其中， 在根据所述数据查询 计划生成所述数据查询计划对应的至少一个算子链之后， 还包括： 针对每个算子链 ， 确定所述算子链的并行度数量； 根据所述并行度数量 ， 为所述算子链设置与所述并行度数量相同数量的线程， 所述线程 用于执行所述算子链中的连接算子。
8、 根据权利要求 1至 7中任一项所述的过滤器构建方法， 其中， 所述在所述目标连接 键的构建端构建过滤器， 包括： 确定所述 目标连接键对应的数据分区模式； 根据所述 目标连接键的数据分区模式， 在所述目标连接键的构建端构建过滤器； 其 中， 所述数据分区模式包括第一分区模式和第二分区模式， 所述第一分区模式用于表 征所述目标连接键的构建端的各个分区对应于同一个哈希表， 所述第二分区模式用于表征所 述目标连接键的构建端的每个分区对应于不同的哈希表。
9、 根据权利要求 8所述的过滤器构建方法， 其中， 所述根据所述目标连接键的数据分 区模式， 构建所述目标连接键对应的过滤器， 包括： 若所述 目标连接键为所述第一分区模式， 针对所述目标连接键对应的每个线程， 构建所 述线程对应的过滤器分量， 并将所述目标连接键对应的线程的过滤器分量进行合并， 获得所 述目标连接键对应的过滤器； 若所述 目标连接键为所述第二分区模式， 针对所述目标连接键对应的每个分区， 构建所 述分区对应的局部过滤器， 以获得所述目标连接键对应的过滤器。
10、 根据权利要求 1至 9中任一项所述的过滤器构建方法， 其中， 所述过滤器为布隆过 滤器和阻塞布隆过滤器中的至少一种。
11、 一种数据查询方法， 其中， 包括： 响应于数据查询计划， 基于权利要求 1至 10中任一项所述的过滤器构建方法， 在所述 数据查询计划对应的算子链中构建过滤器； 执行所述数据查询计划对应的所述算子链 ， 并基于所述过滤器过滤数据， 获得所述数据 查询计划对应的数据查询结果。
12、 根据权利要求 11所述的数据查询方法， 其中， 还包括： 针对所述算子链 中所构建的每个过滤器， 获取所述过滤器在执行所述数据查询计划的过 程中进行数据过滤的过滤效果； 若所述过滤 效果不小于阈值， 则在执行所述数据查询计划的过程中继续使用所述过滤器 进行数据过滤； 若所述过滤 效果小于阈值， 则在执行所述数据查询计划的过程中停止采用所述过滤器进 行数据过滤。
13、 一种过滤器构建装置， 其中， 包括： 生成模块 ， 用根据数据查询计划生成所述数据查询计划对应的算子链， 所述算子链包括 多个线性连接的算子， 所述算子包括连接算子和扫描算子； 获取模块 ， 用于根据所述连接算子和所述扫描算子， 获取算子链对应的过滤器构建信 息 ， 所述过滤器构建信息包含所述算子链中连接算子的构建通道与扫描算子的过滤通道之 间的对应关系 ； 确定模块， 用于根据所述过滤器构建信息对应的过滤器的性能收益和 /或性能开销， 在 所述算子链包含的连接键中， 确定待构建过滤器的目标连接键； 构建模块， 用于在所述目标连接键的构建端构建过滤器 ， 所述目标连接键用于在执行 所述数据查询计划时基于所述过滤器过滤数据。
14、 一种数据查询装置， 其中， 包括： 权利要求 13所述的过滤器构建装置， 用于响应于数据查询计划， 在所述数据查询计划 对应的算子链中构建过滤器； 查询模块 ， 用于在执行所述数据查询计划对应的所述算子链时， 基于所述过滤器过滤数 据。
15、 一种计算机可读存储介质， 其中， 所述计算机可读存储介质中存储有计算机执行指 令， 当处理器执行所述计算机执行指令时， 实现如权利要求 1至 10中任一项所述的过滤器 构建方法， 和 /或， 实现如权利要求 11至 12所述的数据查询方法。
16、 一种计算机程序产品， 包括计算机程序， 所述计算机程序被处理器执行时， 实现权 利要求 1至 10中任一项所述的过滤器构建方法， 和 /或， 实现如权利要求 11至 12所述的数 据查询方法。
25
PCT/IB2025/053233 2024-05-24 2025-03-27 过滤器构建方法、装置及设备 Pending WO2025243100A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202410657157.5 2024-05-24
CN202410657157.5A CN121009102A (zh) 2024-05-24 2024-05-24 过滤器构建方法、装置及设备

Publications (1)

Publication Number Publication Date
WO2025243100A1 true WO2025243100A1 (zh) 2025-11-27

Family

ID=97732710

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2025/053233 Pending WO2025243100A1 (zh) 2024-05-24 2025-03-27 过滤器构建方法、装置及设备

Country Status (2)

Country Link
CN (1) CN121009102A (zh)
WO (1) WO2025243100A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113407807A (zh) * 2020-12-15 2021-09-17 腾讯科技（深圳）有限公司 搜索引擎的查询优化方法、装置、电子设备
CN114443680A (zh) * 2021-12-31 2022-05-06 阿里云计算有限公司 数据库管理系统、相关装置、方法和介质
CN115309777A (zh) * 2022-10-10 2022-11-08 北京奥星贝斯科技有限公司 数据查询的方法及装置
CN116775697A (zh) * 2023-07-06 2023-09-19 北京火山引擎科技有限公司 数据库中的数据表查询方法、装置、计算设备和存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113407807A (zh) * 2020-12-15 2021-09-17 腾讯科技（深圳）有限公司 搜索引擎的查询优化方法、装置、电子设备
CN114443680A (zh) * 2021-12-31 2022-05-06 阿里云计算有限公司 数据库管理系统、相关装置、方法和介质
CN115309777A (zh) * 2022-10-10 2022-11-08 北京奥星贝斯科技有限公司 数据查询的方法及装置
CN116775697A (zh) * 2023-07-06 2023-09-19 北京火山引擎科技有限公司 数据库中的数据表查询方法、装置、计算设备和存储介质

Also Published As

Publication number Publication date
CN121009102A (zh) 2025-11-25

Similar Documents

Publication Publication Date Title
Nykiel et al. MRShare: sharing across multiple queries in MapReduce
Koliousis et al. Saber: Window-based hybrid stream processing for heterogeneous architectures
Zhu et al. Looking ahead makes query plans robust: Making the initial case with in-memory star schema data warehouse workloads
US9262457B2 (en) On-demand hash index
CN109522428B (zh) 一种基于索引定位的图计算系统的外存访问方法
Raman et al. Pgx. iso: parallel and efficient in-memory engine for subgraph isomorphism
CN102354289A (zh) 一种并发事务的调度方法和相关装置
US12353412B2 (en) Runtime statistics feedback for query plan cost estimation
Xiang et al. cuTS: scaling subgraph isomorphism on distributed multi-GPU systems using trie based data structure
US11409746B2 (en) Method and apparatus for processing query using N-ary join operators
US20260079680A1 (en) Operator Compilation Method and Apparatus
CN108710640B (zh) 一种提高Spark SQL的查询效率的方法
Li et al. Losha: A general framework for scalable locality sensitive hashing
WO2024198934A1 (zh) 数据处理方法、装置、系统、电子设备及存储介质
Choi et al. OurRocks: offloading disk scan directly to GPU in write-optimized database system
Ma et al. Gloria: Graph-based sharing optimizer for event trend aggregation
Jeong et al. UPP: Universal Predicate Pushdown to Smart Storage
CN116610700A (zh) 查询语句检测方法及装置、存储介质
CN108763489B (zh) 一种优化Spark SQL执行工作流的方法
WO2008085340A1 (en) Accelerating queries using secondary semantic column enumeration
CN118861097B (zh) 一种基于dpu执行结构化查询语句聚合计算的方法和系统
CN114661756A (zh) 基于异构架构的图上两点间k跳约束下的简单路径查询系统和方法
Liu et al. Bitblender: Scalable bloom filter acceleration on fpgas with dynamic scheduling
CN121009102A (zh) 过滤器构建方法、装置及设备
CN114138330B (zh) 基于知识图谱的代码克隆检测优化方法、装置和电子设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 25807274

Country of ref document: EP

Kind code of ref document: A1