Spark基于DPU Snappy壓縮算法的異構(gòu)加速方案

一、總體介紹

1.1 背景介紹

Apache Spark是專為大規(guī)模數(shù)據(jù)計算而設(shè)計的快速通用的計算引擎，是一種與 Hadoop 相似的開源集群計算環(huán)境，但是兩者之間還存在一些不同之處，這些不同之處使 Spark 在某些工作負載方面表現(xiàn)得更加優(yōu)越。換句話說，Spark 啟用了內(nèi)存分布數(shù)據(jù)集，除了能夠提供交互式查詢外，它還可以優(yōu)化迭代工作負載。Spark SQL是Spark的計算模塊之一，專門用于處理結(jié)構(gòu)化的數(shù)據(jù)。Spark SQL允許用戶使用標準的SQL語句來執(zhí)行SQL的查詢和讀寫，也可以使用Hive SQL來執(zhí)行對Hive倉庫的查詢和讀寫。

在Spark作業(yè)中，數(shù)據(jù)通常在內(nèi)存中進行計算和操作，并且通過網(wǎng)絡(luò)進行節(jié)點間的數(shù)據(jù)傳輸。Snappy壓縮算法已經(jīng)被廣泛應(yīng)用于各種大數(shù)據(jù)處理框架中，并且通常是默認的壓縮選項。在Spark系統(tǒng)中，用戶無需額外的配置即可使用Snappy壓縮算法，這使得它成為Spark處理數(shù)據(jù)的首選壓縮方式之一。

Snappy壓縮算法是一種同時具備非常高的壓縮速度，和較為合理的壓縮率的壓縮算法。Snappy壓縮具有速度快、占用內(nèi)存小、通用性強的優(yōu)點，被廣泛應(yīng)用于大規(guī)模數(shù)據(jù)處理、網(wǎng)絡(luò)傳輸、數(shù)據(jù)庫存儲、機器學習、圖像處理等多個領(lǐng)域。

目前使用Snappy算法進行壓縮解壓縮的場景全部基于CPU進行，CPU除了需要維持整個計算場景的數(shù)據(jù)調(diào)度，還需要額外的算力進行壓縮解壓縮計算。CPU作為通用處理芯片，在大數(shù)據(jù)高密集型的數(shù)據(jù)計算上并無明顯優(yōu)勢，這使得大部分應(yīng)用場景下基于CPU運算時計算算力成為性能的主要瓶頸。

中科馭數(shù)自研的基于KPU架構(gòu)的DPU芯片作為專用的數(shù)據(jù)處理芯片，在處理復雜的數(shù)據(jù)計算時相比于CPU擁有極高的性能提升。因此將Snappy壓縮解壓縮算法由CPU卸載到DPU，可以極大的提升計算性能。在復雜場景下，CPU專注于數(shù)據(jù)傳遞和計算任務(wù)調(diào)度，DPU專注于壓縮解壓縮計算。

中科馭數(shù)HADOS是一款敏捷異構(gòu)軟件平臺，能夠為網(wǎng)絡(luò)、存儲、安全、大數(shù)據(jù)計算等場景進行提速。對于大數(shù)據(jù)計算場景，HADOS可以認為是一個異構(gòu)執(zhí)行庫，提供了數(shù)據(jù)類型、向量數(shù)據(jù)結(jié)構(gòu)、表達式計算、IO和資源管理等功能。為了發(fā)揮CPU與DPU各自的性能優(yōu)勢，我們開發(fā)了HADOS-RACE項目，結(jié)合HADOS平臺，既能夠發(fā)揮CPU高速穩(wěn)定的計算調(diào)度能力，又可以發(fā)揮DPU的向量化執(zhí)行能力。

我們通過實驗發(fā)現(xiàn)，Spark讀數(shù)據(jù)的解壓和寫數(shù)據(jù)的壓縮過程，在耗時上占比比較高，將Snappy壓縮解壓縮的計算任務(wù)通過HADOS-RACE卸載到DPU上, 相比于純CPU計算，性能可提升約2倍。

本文將簡單介紹基于DPU的Snappy壓縮解壓縮計算原理，并介紹如何基于DPU和HADOS-RACE來加速Snappy壓縮解壓縮計算，為大規(guī)模數(shù)據(jù)分析和處理提供更可靠的解決方案。

1.2 挑戰(zhàn)和困難

在數(shù)據(jù)處理和傳輸?shù)念I(lǐng)域，快速且高效的壓縮算法對于提高系統(tǒng)性能至關(guān)重要。然而，盡管Snappy壓縮解壓縮算法以其快速的壓縮和解壓縮速度而聞名，但其卻存在一個不容忽視的挑戰(zhàn)，即對CPU和內(nèi)存資源的大量占用，從而導致性能下降的問題。

Snappy算法在壓縮和解壓縮數(shù)據(jù)時需要進行復雜的計算和處理。雖然它以其高效的算法設(shè)計和優(yōu)化而著稱，但在處理大量數(shù)據(jù)時，仍會對CPU提出較高的要求。特別是在需要快速壓縮或解壓縮大文件時，Snappy算法的CPU消耗可能會變得更為顯著，從而導致系統(tǒng)整體性能的下降。對于CPU性能較低的系統(tǒng)而言，這一挑戰(zhàn)尤為嚴峻，可能導致系統(tǒng)響應(yīng)變慢，甚至造成任務(wù)阻塞和性能瓶頸。

綜上所述，Snappy壓縮解壓縮算法的高效性和速度帶來了性能優(yōu)勢，但其對CPU的大量占用也成為其性能低下的一個主要挑戰(zhàn)。

二、整體方案

圖一：Spark基于DPU Snappy壓縮算法的異構(gòu)加速整體方案

上圖所示為Spark SQL的一個涉及FileScan、Shuffle、Aggregate、OrderBy計算的完整數(shù)據(jù)流轉(zhuǎn)過程，Spark SQL的數(shù)據(jù)處理首先需要讀取HDFS分布式文件存儲系統(tǒng)中的Snappy壓縮文件，然后會對Snappy壓縮文件進行解壓縮處理，從而得到計算所需的數(shù)據(jù)。拿到數(shù)據(jù)后根據(jù)SQL的邏輯進行相應(yīng)的計算，常見的計算比如Filter、Aggregate、Join、Order By等，經(jīng)過數(shù)據(jù)計算拿到想要輸出的結(jié)果數(shù)據(jù)。最后會將結(jié)果數(shù)據(jù)寫出并按Snappy格式進行壓縮，得到的壓縮文件會寫回到HDFS中存儲。

圖二：基于DPU的算子卸載加速流程

上圖所示為Spark將算子卸載到DPU進行計算的一個通用流程。首先Spark將SQL進行解析并得到最終的物理執(zhí)行計劃，然后將物理執(zhí)行計劃轉(zhuǎn)化為具體的算子操作，Spark會通過HADOS-RACE Plugin將具體算子卸載到DPU進行處理。在DPU處理過程中，首先需要執(zhí)行FileScan算子，將數(shù)據(jù)從HDFS文件系統(tǒng)中讀取出來并對Snappy壓縮文件執(zhí)行解壓縮操作。中間過程是對解壓縮的數(shù)據(jù)進行計算，得到最終的結(jié)果數(shù)據(jù)。最后會將結(jié)果數(shù)據(jù)按Snappy格式壓縮并導出到HDFS中存儲。

在對整個Spark計算過程進行性能分析后，發(fā)現(xiàn)Snappy壓縮和解壓縮是兩個耗時非常高的過程，占整個計算過程的比重較高。因此我們需要對Snappy的壓縮和解壓縮過程進行加速。

我們采用軟硬件結(jié)合的方式，在數(shù)據(jù)壓縮解壓縮鏈路的軟硬件兩大方面都進行了全面提升和加速。

在軟件方面，基于硬件對不同場景、數(shù)據(jù)量的壓縮解壓縮表現(xiàn)，HADOS-RACE可以靈活選擇合適的壓縮、解壓縮的硬件平臺。

在硬件方面，自研的DPU計算引擎擁有強大的Snappy壓縮、解壓縮能力，滿足日益復雜的計算場景。

三、核心加速階段

圖三：基于DPU的整體加速流程圖

加速階段如上圖所示，核心數(shù)據(jù)加速方案分為兩個階段，分別為 1.智能壓縮解壓縮策略選擇階段；2.對數(shù)據(jù)壓縮解壓縮階段。

3.1 策略選擇階段

3.1.1 面臨挑戰(zhàn)

在數(shù)據(jù)壓縮解壓縮過程中，壓縮解壓縮策略選擇階段是整個過程的開始。傳統(tǒng)的硬件體系結(jié)構(gòu)中，數(shù)據(jù)的壓縮和解壓縮過程通常只能依賴CPU完成，沒有其他策略可以選擇，從而無法利用GPU、DPU等其他處理器資源。這種局限性導致數(shù)據(jù)壓縮解壓縮過程會大量占用CPU資源，從而降低系統(tǒng)的性能。

3.1.2 解決方案與原理

近年來，隨著數(shù)據(jù)處理領(lǐng)域的不斷發(fā)展和硬件技術(shù)的進步，DPU、GPU等計算資源的加入為數(shù)據(jù)壓縮解壓縮帶來了新的可能性。這些不同的硬件平臺具有各自獨特的特點和優(yōu)勢，可以根據(jù)不同的場景和需求來選擇合適的硬件平臺進行數(shù)據(jù)壓縮解壓縮。

HADOS-RACE的IO模塊負責將數(shù)據(jù)從硬盤讀入內(nèi)存中，并將其交由Compressor模塊進行卸載策略判斷。通過IO模塊的數(shù)據(jù)加載過程，系統(tǒng)能夠根據(jù)數(shù)據(jù)的特點和硬件平臺的性能選擇合適的壓縮解壓縮策略，從而實現(xiàn)數(shù)據(jù)處理的優(yōu)化和提升。

在HADOS-RACE中，基于硬件對不同場景、數(shù)據(jù)量的性能表現(xiàn)，可以靈活配置壓縮解壓縮策略。例如，當數(shù)據(jù)量比較小的時候，可以直接通過CPU進行壓縮解壓縮，減少了內(nèi)存和DPU硬件之間的數(shù)據(jù)傳輸，從而提高了系統(tǒng)的性能和效率。而對于大規(guī)模數(shù)據(jù)處理的場景，可以利用DPU等硬件資源進行并行計算，加速數(shù)據(jù)的處理速度。

3.1.3 優(yōu)勢與效果

HADOS-RACE的智能策略選擇模塊在數(shù)據(jù)加載過程中發(fā)揮了重要作用，通過分析數(shù)據(jù)的特征和硬件平臺的性能，實現(xiàn)了對壓縮解壓縮策略的選擇。這種靈活配置的策略不僅提高了數(shù)據(jù)處理的效率，也降低了系統(tǒng)的資源消耗，為數(shù)據(jù)處理和應(yīng)用提供了更好的支持。

我們可以根據(jù)一定的策略選擇合適的硬件平臺來進行數(shù)據(jù)壓縮解壓縮，從而實現(xiàn)數(shù)據(jù)壓縮解壓縮的優(yōu)化和提升。這為未來的數(shù)據(jù)壓縮解壓縮領(lǐng)域的發(fā)展帶來了新的機遇和挑戰(zhàn)，也為用戶提供了更加靈活和高效的數(shù)據(jù)壓縮解壓縮方案。

3.2 壓縮解壓縮階段

3.2.1 面臨挑戰(zhàn)

由于CPU在數(shù)據(jù)處理方面具有較強的通用性和靈活性，因此壓縮解壓縮算法通常被設(shè)計為在CPU上執(zhí)行。然而，與DPU相比，CPU的并行處理能力相對較弱，無法充分發(fā)揮硬件資源的潛力。在大規(guī)模數(shù)據(jù)處理的場景下，數(shù)據(jù)壓縮解壓縮過程可能成為CPU的瓶頸，導致系統(tǒng)性能下降。此外，由于數(shù)據(jù)壓縮解壓縮是一個計算密集型任務(wù)，當系統(tǒng)中同時存在其他需要CPU資源的任務(wù)時，壓縮解壓縮過程可能會與其他任務(wù)產(chǎn)生競爭，進一步加劇了CPU資源的緊張程度，導致系統(tǒng)整體的響應(yīng)速度變慢。

3.2.2 解決方案與原理

在傳統(tǒng)的硬件體系結(jié)構(gòu)中，數(shù)據(jù)的壓縮和解壓縮過程通常只能依賴CPU完成。然而，隨著芯片技術(shù)的不斷發(fā)展和創(chuàng)新，現(xiàn)代計算機系統(tǒng)已經(jīng)實現(xiàn)了DPU等計算資源的利用，從而在數(shù)據(jù)處理領(lǐng)域帶來了革命性的變化。DPU的并行計算能力遠遠超過CPU，使得它成為處理大規(guī)模數(shù)據(jù)的理想選擇。近年來，隨著DPU技術(shù)的日益成熟和運用，數(shù)據(jù)壓縮解壓縮過程已經(jīng)可以借助DPU來執(zhí)行，從而大大減少了對CPU資源的占用，提升了系統(tǒng)的性能和效率。

隨著DPU芯片技術(shù)的不斷發(fā)展和成熟，DPU已經(jīng)成為了處理大規(guī)模數(shù)據(jù)的強大工具。DPU的并行計算能力遠遠超過CPU，能夠同時處理大量數(shù)據(jù)，極大地加快了數(shù)據(jù)處理的速度。因此，現(xiàn)在可以利用DPU來執(zhí)行數(shù)據(jù)的壓縮和解壓縮過程，從而減少了對CPU資源的占用，提升了系統(tǒng)的性能和效率。

3.2.3 優(yōu)勢與效果

DPU在數(shù)據(jù)壓縮解壓縮中的應(yīng)用，主要體現(xiàn)在以下幾個方面：

首先，DPU能夠同時處理多個數(shù)據(jù)塊，實現(xiàn)真正的并行計算。在數(shù)據(jù)壓縮解壓縮過程中，可以將大規(guī)模數(shù)據(jù)劃分成多個小塊，然后通過DPU同時對這些數(shù)據(jù)塊進行壓縮或解壓縮，極大地提高了處理速度。

此外，DPU的計算能力可以輕松處理大規(guī)模數(shù)據(jù)，從而滿足了現(xiàn)代大數(shù)據(jù)處理的需求?？梢岳肈PU來執(zhí)行數(shù)據(jù)的壓縮和解壓縮過程，從而提高系統(tǒng)的性能和效率。

綜上所述，利用DPU進行數(shù)據(jù)壓縮解壓縮等算力的卸載，已經(jīng)成為了計算機系統(tǒng)的重要趨勢。通過充分利用DPU的并行計算能力和卡上內(nèi)存，可以大大減少對CPU資源的占用，提升系統(tǒng)的性能和效率。相信在未來的snappy數(shù)據(jù)壓縮解壓縮領(lǐng)域，DPU將會發(fā)揮越來越重要的作用。

四、加速效果

基于目前HADOS-RACE已經(jīng)實現(xiàn)的Snappy壓縮解壓縮方案，制定了對應(yīng)的性能測試計劃。首先生成snappy測試數(shù)據(jù)，使用基于CPU和DPU的Spark分別對數(shù)據(jù)進行處理，記錄各自的Snappy壓縮解壓縮階段和Spark整體端到端的耗時和吞吐。執(zhí)行的測試語句為：select * from table where a1 is not null and a2 is not null（盡量減少中間的計算過程，突出Snappy壓縮解壓縮的過程）。

4.1 壓縮解壓縮加速效果

單獨分析Snappy壓縮解壓縮階段，基于CPU的Snappy解壓縮，吞吐量為300MB/s。而將解壓縮任務(wù)卸載到DPU后，DPU核內(nèi)計算的吞吐量可達到1585MB/s?？梢钥吹剑贒PU進行Snappy解壓縮，相比基于CPU進行Snappy解壓縮，性能可提升約5倍。

對于系統(tǒng)整體而言，壓縮解壓縮計算的輸入數(shù)據(jù)和輸出數(shù)據(jù)，如果需要傳輸?shù)紺PU繼續(xù)做計算，則有額外的PCIe數(shù)據(jù)傳輸?shù)臅r間損耗，由于不同的數(shù)據(jù)量及壓縮比帶來的整體效果差別較大，所以以下測試數(shù)據(jù)僅供參考。表格中的DPU數(shù)據(jù)均為結(jié)合PCIe傳輸消耗的結(jié)果。壓縮前的數(shù)據(jù)量均為128MB，但是由于數(shù)據(jù)內(nèi)容不同導致壓縮比不同，進而導致吞吐的不同，從以下測試結(jié)果中可以看出，壓縮率越大，計算占比越高，DPU表現(xiàn)的越好。

圖四：基于DPU的Snappy壓縮解壓縮方案測試結(jié)果

4.2 端到端整體加速效果

基于CPU的Spark計算過程總體比基于DPU的Spark計算過程耗時減少了約50%。相當于基于DPU的端到端執(zhí)行性能是基于CPU端到端性能的兩倍。詳細測試結(jié)果如下所示：

圖五：基于DPU加速的端到端方案測試結(jié)果

4.3 結(jié)果分析

從測試結(jié)果中可以看到，在壓縮率約為50%至70%時，基于DPU進行Snappy解壓縮相比基于CPU進行Snappy解壓縮，性能有1.1至1.5倍提升，其他情況下解壓縮性能均有下降。造成這一現(xiàn)象的原因是，此次測試沒有對DPU進行流程優(yōu)化，從主機向DPU板卡傳輸數(shù)據(jù)時，DPU并沒有并發(fā)執(zhí)行計算任務(wù)。DPU的計算流程還有著極大的優(yōu)化空間，優(yōu)化后，DPU中的計算任務(wù)可以以流水線的形式進行調(diào)度，則數(shù)據(jù)傳輸過程將不會占用整體計算時間。

從Spark整個執(zhí)行過程來看，基于DPU的Spark計算過程總體比基于CPU的Spark計算過程有2倍的性能提升。單獨從Snappy壓縮解壓縮階段看，在壓縮率20%至100%之間，基于DPU的Snappy解壓縮，相比于基于CPU的Snappy解壓縮，性能上可以有1.5至5倍的性能提升。

五、未來規(guī)劃

5.1 現(xiàn)有優(yōu)勢

性能方面，得益于DPU做算力卸載的高效性和智能策略選擇算法，相對于傳統(tǒng)壓縮解壓縮方式，基于DPU進行snappy壓縮解壓縮具備較為明顯的性能優(yōu)勢。

資源占用方面，得益于將CPU的計算卸載到DPU上執(zhí)行，服務(wù)器的CPU、內(nèi)存、IO和網(wǎng)絡(luò)資源占用等方面都有明顯降低。特別是CPU資源，可以將壓縮解壓縮卸載到DPU的同時完成其他數(shù)據(jù)計算處理任務(wù)。

5.2 未來規(guī)劃

優(yōu)化和完善現(xiàn)有功能，繼續(xù)增加其他算力的卸載。

未來計劃在存算分離場景下適配snappy壓縮解壓縮功能。從遠端讀取數(shù)據(jù)后，首先數(shù)據(jù)會直接經(jīng)過壓縮或解壓縮計算，從DPU卡出來的數(shù)據(jù)已經(jīng)是經(jīng)過壓縮解壓縮的，無需多余的數(shù)據(jù)傳輸和計算。

審核編輯 黃宇