一、總體介紹

1.1 背景介紹

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

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

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

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

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

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

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

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

1.2 挑戰(zhàn)和困難

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

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

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

二、整體方案

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

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

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

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

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

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

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

在硬件方面，自研的DPU計(jì)算引擎擁有強(qiáng)大的Snappy壓縮、解壓縮能力，滿足日益復(fù)雜的計(jì)算場景。

三、核心加速階段

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

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

3.1 策略選擇階段

3.1.1 面臨挑戰(zhàn)

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

3.1.2 解決方案與原理

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

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

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

3.1.3 優(yōu)勢與效果

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

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

3.2 壓縮解壓縮階段

3.2.1 面臨挑戰(zhàn)

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

3.2.2 解決方案與原理

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

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

3.2.3 優(yōu)勢與效果

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

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

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

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

四、加速效果

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

4.1 壓縮解壓縮加速效果

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

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

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

4.2 端到端整體加速效果

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

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

4.3 結(jié)果分析

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

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

五、未來規(guī)劃

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

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

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

5.2 未來規(guī)劃

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

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

審核編輯 黃宇