Sailfish-Exploring Heterogeneous Query Acceleration on Discrete CPU-FPGA Architecture.pdf

章芋文

7页

4次

2023-08-29

免费下载

Sailﬁsh: Exploring Heterogeneous Query

Acceleration on Discrete CPU-FPGA Architecture

Xing Wei

1,2

, Yaofeng Tu

1,2

, Yinjun Han

1,2

, Zhenghua Chen

, Xuecheng Qi

, Daojun Hua

{wei.xing6, tu.yaofeng, han.yinjun, chen.zhenghua, qi.xuecheng, hua.daojun}@zte.com.cn

State Key Laboratory of Mobile Network and Mobile Multimedia Technology, China

ZTE Corporation, China

Abstract—The hardware of modern server is being increasingly

heterogeneous as advanced accelerators, such as FPGAs, are used

together with multicore CPUs to meet the computing requirement

of analytical query workloads. Unfortunately, the earlier database

engines are designed for homogeneous servers, where query

execution is only parallelized across CPUs, but ignores the

prized FPGA resources. To exploit the available heterogeneous

resources, emerging work try to construct the cross-device query

pipeline, wherein a part of the operators run on the FPGA-

end and the rest run on the CPU-end respectively. However,

when running such a pipeline, the CPU-end and FPGA-end

operators could obtain mismatched computing resources, which

easily cause uneven processing performance between two ends,

thereby limiting whole pipeline performance or wasting comput-

ing resources. Of note, it is nearly impossible for query optimizers

to assign the matched computing resources to make CPU-end and

FPGA-end have the similar processing performance, as several

factors (e.g., operator selectivity) affect processing performance.

To tackle this problem, we propose the heterogeneous motion

operator, which can adjust the runtime computing resources (e.g.,

parallelism) of CPU-end, so as to match FPGA-end processing

performance. In addition, we further implement an FPGA

accelerator that supports parallel processing of hash join. By

integrating our motion operator into PostgreSQL with the above

FPGA accelerator, we build a prototype called Sailﬁsh, whose

experimental performance exceeds the native acceleration scheme

by a huge margin.

Index Terms—Database, Heterogeneous System, FPGA

I. INTRODUCTION

The past few years have witnessed the rapid transformation

of Field Programmable Gate Array (FPGA) from the speciﬁc

processor to the advanced multi-function accelerator adopted

by various analytical, data-intensive applications. Comparing

to CPU and GPU, FPGA can organize its processing units into

the speciﬁc hardware circuit for target acceleration scenarios,

thereby omitting the costs of loading and parsing instructions.

Hence, FPGAs are being used in many deployment scenarios,

ranging from the supercomputing used for HPC applications to

platform-as-a-service that provides FPGA-accelerated virtual

machines. Until now, the widely-used CPU-FPGA platform is

still discrete, in which the FPGA board with many computing

and private memory resources is attached via PCIe bus as the

peripheral of CPU.

Unfortunately, traditional analytical DBMSs solely operate

on CPUs. In the past decades, to meet the strict performance

requirement of big data analysis, database engines attempt to

exploit the CPU parallelism (e.g., multi-thread and SIMD)

and node parallelism (e.g., massively parallel processing) to

speed up the query execution, yet FPGA has not attracted

attentions. Recently, a part of emerging database engines

[1]–[3] are being increasingly deployed on a heterogeneous

platform with discrete CPU and FPGA, which aim at uti-

lizing FPGA-end computing resources to facilitate the query

execution. To achieve the heterogeneous query acceleration,

earlier works [4]–[6] try to ofﬂoad those CPU-heavy operators

(e.g., HashJoin) into FPGA-end, which can undertake a part

of CPU-end computing burden. Instead of speeding up an

independent operator, later works [2], [7]–[9] aggressively

hand over the contiguous operators within a pipeline to FPGA-

end with the help of reconﬁgurable capacity in advanced

FPGA (e.g., Xilinx FPGA Virtex-II). It is worth noting that

deploying a group of contiguous operators on FPGA-end can

not only ofﬂoad more computing tasks from CPU-end, but also

amortize the overheads of cross-device data transfer and/or

synchronization into more operators, especially on discrete

CPU-FPGA architecture.

Despite the progresses made in leveraging FPGA to speedup

database, there still exists a critical issue about the mismatched

computing resources between CPU and FPGA during runtime.

More precisely, for a pipeline that leaves a part of contiguous

operators to FPGA-end, the rest of pipeline running on CPU-

end could take too many or too few computing resources (i.e.,

worker thread or process) to make its processing performance

go beyond or lag behind FPGA-end. If CPU-end provides the

higher performance, the whole pipeline will be limited by the

FPGA-end and waste the extra CPU-end computing resources.

Otherwise, the whole pipeline will be restricted to CPU-end.

Consider the processing performance of CPU-end and FPGA-

end are affected by several factors (e.g., operator selectivity),

it is very difﬁcult for query optimizer to allocate the properly

computing resources that match the FPGA-end.

In this paper, we propose the heterogeneous motion operator

to address the above issues. Such an operator is in charge of

adjusting the runtime parallelism of CPU-end operators within

the same pipeline, so as to match the processing performance

of FPGA-end. In addition, the motion operator also plays as

the coordinator to manage the cross-device data ﬂow so that

the pipeline across CPU-end and FPGA-end can run on the

iterator model. Based on above efforts, we further implement a

prototype called as Sailﬁsh that integrates the motion operator

into PostgreSQL, and take only about 30% onboard resources

198

2023 IEEE 39th International Conference on Data Engineering Workshops (ICDEW)

DOI 10.1109/ICDEW58674.2023.00036

Authorized licensed use limited to: ZTE CORPORATION. Downloaded on August 29,2023 at 02:13:41 UTC from IEEE Xplore. Restrictions apply.

   

























 





!"

#

$

%!

&'("  '("



Fig. 1. A Taxonomy of Operators’ Fitness to FPGA Acceleration.

to construct the FPGA-end accelerator that facilitates parallel

hash join. Notably, the remaining onboard resources could still

speedup other operators (e.g., Aggregation and Scan). We also

conduct the experiment to verify that our design could always

take proper CPU-end computing resources to ﬁt the FPGA-end

accelerator, thereby eliminating the wasted resources.

Outline. In the rest of paper, we ﬁrst describe the background

and related work about FPGA-based database acceleration in

section II. Then, we state the design of Sailﬁsh and detail the

heterogeneous motion operator in section III. In the following,

we evaluate our design in section IV. Finally, we conclude our

paper and discuss further work in section V.

II. B

ACKGROUND AND RELATED WORK

A. Revisiting Heterogeneous Query Acceleration

In this section, we ﬁrstly revisit the existing strategies that

leverage FPGA to accelerate query execution, and then identify

the potential performance issue on heterogeneous environment.

x Operator Acceleration: In DBMS, a SQL can be usually

translated into the execution plan including several operators,

such as Join and Aggregation. To enable them to run

faster, FPGA as a candidate accelerator can offer a large

amount of programmable computing resources (i.e., FPGA

Logic Cells) as speciﬁc kernels or processing engines (PEs)

to execute those operators. But considering the characteristics

of FPGA [10], some compute-intensive operators are friendly

to FPGA, while they belong to the control-intensive area,

i.e., having many branch predication, FPGA could perform

worse than CPU since they need to consume many hardware

resources to form the speciﬁc control logic [11]. As depicted

in Fig. 1, we conduct a taxonomy of existing query operators

in terms of computing and control perspectives, and derived

several operators ﬁtting to the FPGA acceleration. Speciﬁcally,

HashJoin and HashAgg are both typical compute-intensive

























 

 !"

#

 $% &'

 !"()

 !"*)

 &'

Fig. 2. Query Execution with FPGA Acceleration.

operators, and there exist massive implementation methods

for these two operators. For example, Halstead et al. [4]

implemented an end-to-end multithreading hash join on FPGA,

whose experimental results can show the speedup between 2×

and 3.4× over the multi-core approaches on the uniform and

skewed datasets. Eryilmaz et al. [6] further implemented an

aggregation operator that could be conﬁgured for the different

number of groups, which is 2.2× faster than the HashAgg

on CPU.

y Pipeline Acceleration: Recently, emerging work [2],

[7], [8], [12] try to leave a set of contiguous operators

within a pipeline to FPGA. For example, as shown in Fig. 2,

the query pipeline {Scan

→ Filter

→ HashJoin →

Aggregation} can be split into two parts, wherein the part

including HashJoin and Aggregation can be handled by

FPGA device. Considering the pipeline design [11] in FPGA,

the FPGA-end operators can be mapped into a speciﬁc state

machine and avoid unnecessary loads and stores of the

intermediate results [13]. Even though the implementation

of these operators in FPGA is trivial, the acceleration of

combination of these operators is non-trivial in FPGA. To

pipeline the FPGA-end operators, some typical researches [7],

[8] utilize the query-to-hardware compilers to generate the

hardware circuit logic automatically, and leverage the low-

latency reconﬁgurable function of advanced FPGA to deploy

the logic in the real-time fashion. Meanwhile, the other works,

such as doppioDB [2], build a shared data buffer for multiple

FPGA-end operators, and coordinate the data ﬂow within the

buffer to pipeline the speciﬁc operators rapidly.

B. Achilles’ Heel of Existing Acceleration Schemes

As stated earlier, the advantages of taking FPGA as database

accelerator are quite signiﬁcant (e.g., replenishing computing

resources), but how to make full of them is a really tough task.

When pushed to the limit, in the FPGA-attached heterogeneous

database bottlenecks can be attributed to the data transmission

and mismatched computing resources.

199

Authorized licensed use limited to: ZTE CORPORATION. Downloaded on August 29,2023 at 02:13:41 UTC from IEEE Xplore. Restrictions apply.

Sailﬁsh: Exploring Heterogeneous Query

Acceleration on Discrete CPU-FPGA Architecture

Xing Wei

1,2

, Yaofeng Tu

1,2

, Yinjun Han

1,2

, Zhenghua Chen

, Xuecheng Qi

, Daojun Hua

{wei.xing6, tu.yaofeng, han.yinjun, chen.zhenghua, qi.xuecheng, hua.daojun}@zte.com.cn

State Key Laboratory of Mobile Network and Mobile Multimedia Technology, China

ZTE Corporation, China

Abstract—The hardware of modern server is being increasingly

heterogeneous as advanced accelerators, such as FPGAs, are used

together with multicore CPUs to meet the computing requirement

of analytical query workloads. Unfortunately, the earlier database

engines are designed for homogeneous servers, where query

execution is only parallelized across CPUs, but ignores the

prized FPGA resources. To exploit the available heterogeneous

resources, emerging work try to construct the cross-device query

pipeline, wherein a part of the operators run on the FPGA-

end and the rest run on the CPU-end respectively. However,

when running such a pipeline, the CPU-end and FPGA-end

operators could obtain mismatched computing resources, which

easily cause uneven processing performance between two ends,

thereby limiting whole pipeline performance or wasting comput-

ing resources. Of note, it is nearly impossible for query optimizers

to assign the matched computing resources to make CPU-end and

FPGA-end have the similar processing performance, as several

factors (e.g., operator selectivity) affect processing performance.

To tackle this problem, we propose the heterogeneous motion

operator, which can adjust the runtime computing resources (e.g.,

parallelism) of CPU-end, so as to match FPGA-end processing

performance. In addition, we further implement an FPGA

accelerator that supports parallel processing of hash join. By

integrating our motion operator into PostgreSQL with the above

FPGA accelerator, we build a prototype called Sailﬁsh, whose

experimental performance exceeds the native acceleration scheme

by a huge margin.

Index Terms—Database, Heterogeneous System, FPGA

I. INTRODUCTION

The past few years have witnessed the rapid transformation

of Field Programmable Gate Array (FPGA) from the speciﬁc

processor to the advanced multi-function accelerator adopted

by various analytical, data-intensive applications. Comparing

to CPU and GPU, FPGA can organize its processing units into

the speciﬁc hardware circuit for target acceleration scenarios,

thereby omitting the costs of loading and parsing instructions.

Hence, FPGAs are being used in many deployment scenarios,

ranging from the supercomputing used for HPC applications to

platform-as-a-service that provides FPGA-accelerated virtual

machines. Until now, the widely-used CPU-FPGA platform is

still discrete, in which the FPGA board with many computing

and private memory resources is attached via PCIe bus as the

peripheral of CPU.

Unfortunately, traditional analytical DBMSs solely operate

on CPUs. In the past decades, to meet the strict performance

requirement of big data analysis, database engines attempt to

exploit the CPU parallelism (e.g., multi-thread and SIMD)

and node parallelism (e.g., massively parallel processing) to

speed up the query execution, yet FPGA has not attracted

attentions. Recently, a part of emerging database engines

[1]–[3] are being increasingly deployed on a heterogeneous

platform with discrete CPU and FPGA, which aim at uti-

lizing FPGA-end computing resources to facilitate the query

execution. To achieve the heterogeneous query acceleration,

earlier works [4]–[6] try to ofﬂoad those CPU-heavy operators

(e.g., HashJoin) into FPGA-end, which can undertake a part

of CPU-end computing burden. Instead of speeding up an

independent operator, later works [2], [7]–[9] aggressively

hand over the contiguous operators within a pipeline to FPGA-

end with the help of reconﬁgurable capacity in advanced

FPGA (e.g., Xilinx FPGA Virtex-II). It is worth noting that

deploying a group of contiguous operators on FPGA-end can

not only ofﬂoad more computing tasks from CPU-end, but also

amortize the overheads of cross-device data transfer and/or

synchronization into more operators, especially on discrete

CPU-FPGA architecture.

Despite the progresses made in leveraging FPGA to speedup

database, there still exists a critical issue about the mismatched

computing resources between CPU and FPGA during runtime.

More precisely, for a pipeline that leaves a part of contiguous

operators to FPGA-end, the rest of pipeline running on CPU-

end could take too many or too few computing resources (i.e.,

worker thread or process) to make its processing performance

go beyond or lag behind FPGA-end. If CPU-end provides the

higher performance, the whole pipeline will be limited by the

FPGA-end and waste the extra CPU-end computing resources.

Otherwise, the whole pipeline will be restricted to CPU-end.

Consider the processing performance of CPU-end and FPGA-

end are affected by several factors (e.g., operator selectivity),

it is very difﬁcult for query optimizer to allocate the properly

computing resources that match the FPGA-end.

In this paper, we propose the heterogeneous motion operator

to address the above issues. Such an operator is in charge of

adjusting the runtime parallelism of CPU-end operators within

the same pipeline, so as to match the processing performance

of FPGA-end. In addition, the motion operator also plays as

the coordinator to manage the cross-device data ﬂow so that

the pipeline across CPU-end and FPGA-end can run on the

iterator model. Based on above efforts, we further implement a

prototype called as Sailﬁsh that integrates the motion operator

into PostgreSQL, and take only about 30% onboard resources

198

2023 IEEE 39th International Conference on Data Engineering Workshops (ICDEW)

DOI 10.1109/ICDEW58674.2023.00036

Authorized licensed use limited to: ZTE CORPORATION. Downloaded on August 29,2023 at 02:13:41 UTC from IEEE Xplore. Restrictions apply.

   

























 





!"

#

$

%!

&'("  '("



Fig. 1. A Taxonomy of Operators’ Fitness to FPGA Acceleration.

to construct the FPGA-end accelerator that facilitates parallel

hash join. Notably, the remaining onboard resources could still

speedup other operators (e.g., Aggregation and Scan). We also

conduct the experiment to verify that our design could always

take proper CPU-end computing resources to ﬁt the FPGA-end

accelerator, thereby eliminating the wasted resources.

Outline. In the rest of paper, we ﬁrst describe the background

and related work about FPGA-based database acceleration in

section II. Then, we state the design of Sailﬁsh and detail the

heterogeneous motion operator in section III. In the following,

we evaluate our design in section IV. Finally, we conclude our

paper and discuss further work in section V.

II. B

ACKGROUND AND RELATED WORK

A. Revisiting Heterogeneous Query Acceleration

In this section, we ﬁrstly revisit the existing strategies that

leverage FPGA to accelerate query execution, and then identify

the potential performance issue on heterogeneous environment.

x Operator Acceleration: In DBMS, a SQL can be usually

translated into the execution plan including several operators,

such as Join and Aggregation. To enable them to run

faster, FPGA as a candidate accelerator can offer a large

amount of programmable computing resources (i.e., FPGA

Logic Cells) as speciﬁc kernels or processing engines (PEs)

to execute those operators. But considering the characteristics

of FPGA [10], some compute-intensive operators are friendly

to FPGA, while they belong to the control-intensive area,

i.e., having many branch predication, FPGA could perform

worse than CPU since they need to consume many hardware

resources to form the speciﬁc control logic [11]. As depicted

in Fig. 1, we conduct a taxonomy of existing query operators

in terms of computing and control perspectives, and derived

several operators ﬁtting to the FPGA acceleration. Speciﬁcally,

HashJoin and HashAgg are both typical compute-intensive

























 

 !"

#

 $% &'

 !"()

 !"*)

 &'

Fig. 2. Query Execution with FPGA Acceleration.

operators, and there exist massive implementation methods

for these two operators. For example, Halstead et al. [4]

implemented an end-to-end multithreading hash join on FPGA,

whose experimental results can show the speedup between 2×

and 3.4× over the multi-core approaches on the uniform and

skewed datasets. Eryilmaz et al. [6] further implemented an

aggregation operator that could be conﬁgured for the different

number of groups, which is 2.2× faster than the HashAgg

on CPU.

y Pipeline Acceleration: Recently, emerging work [2],

[7], [8], [12] try to leave a set of contiguous operators

within a pipeline to FPGA. For example, as shown in Fig. 2,

the query pipeline {Scan

→ Filter

→ HashJoin →

Aggregation} can be split into two parts, wherein the part

including HashJoin and Aggregation can be handled by

FPGA device. Considering the pipeline design [11] in FPGA,

the FPGA-end operators can be mapped into a speciﬁc state

machine and avoid unnecessary loads and stores of the

intermediate results [13]. Even though the implementation

of these operators in FPGA is trivial, the acceleration of

combination of these operators is non-trivial in FPGA. To

pipeline the FPGA-end operators, some typical researches [7],

[8] utilize the query-to-hardware compilers to generate the

hardware circuit logic automatically, and leverage the low-

latency reconﬁgurable function of advanced FPGA to deploy

the logic in the real-time fashion. Meanwhile, the other works,

such as doppioDB [2], build a shared data buffer for multiple

FPGA-end operators, and coordinate the data ﬂow within the

buffer to pipeline the speciﬁc operators rapidly.

B. Achilles’ Heel of Existing Acceleration Schemes

As stated earlier, the advantages of taking FPGA as database

accelerator are quite signiﬁcant (e.g., replenishing computing

resources), but how to make full of them is a really tough task.

When pushed to the limit, in the FPGA-attached heterogeneous

database bottlenecks can be attributed to the data transmission

and mismatched computing resources.

199

Authorized licensed use limited to: ZTE CORPORATION. Downloaded on August 29,2023 at 02:13:41 UTC from IEEE Xplore. Restrictions apply.

of 7

免费下载

关注

评论