本發(fā)明涉及到MapReduce引擎數(shù)據(jù)處理領域，特別是涉及到一種基于內(nèi)存的MapReduce引擎數(shù)據(jù)處理方法和裝置。

背景技術：

自大數(shù)據(jù)處理技術Hadoop問世以來，其中的數(shù)據(jù)處理引擎MapReduce性能的優(yōu)化一直是業(yè)界比較關心的問題。

以reduce為例，每個Map輸出文件(MOF)中的整個分區(qū)(partition，P1)會被拷貝到Reduce端，然后所有分區(qū)(P1，P1，P1)會合并成為一個有序的總的集合(P1)，最后做Reduce，由于數(shù)據(jù)量的不可控，上述拷貝環(huán)節(jié)內(nèi)存溢出不可避免，隨后合并及進行Reduce過程中也會產(chǎn)生更多硬盤IO的訪問。

目前業(yè)界在MapReduce中減少IO的方法主要是用壓縮(compression)與結合(combination)，基于內(nèi)存的mapreduce就是mellanox公司的UDA(Unstructured DataAccelerator)做過流水線化(Pipelining)的嘗試，但是它主要是基于硬件的加速技術，而且由于shuffle協(xié)議的設計限制，每個批次只shuffle少量數(shù)據(jù)，沒有實現(xiàn)大吞吐量。

技術實現(xiàn)要素：

本發(fā)明的主要目的為提供一種通過軟件實現(xiàn)的數(shù)據(jù)大吞吐量的基于內(nèi)存的MapReduce引擎數(shù)據(jù)處理方法和裝置。

為了實現(xiàn)上述發(fā)明目的，本發(fā)明首先提出一種基于內(nèi)存的MapReduce引擎數(shù)據(jù)處理方法，包括：

將每個分區(qū)的Map輸出結果數(shù)據(jù)進行粒度切割，并將切割后的粒度進行排序；

將每個分區(qū)切割后的粒度進行多批次shuffle,并將各批次的數(shù)據(jù)依次進行拷貝、合并和reduce的流水線式數(shù)據(jù)處理，將reduce進程處理的數(shù)據(jù)控制在內(nèi)存中。

進一步地，所述將每個分區(qū)切割后的粒度進行多批次shuffle,并將各批次的數(shù)據(jù)依次進行拷貝、合并和reduce的流水線式數(shù)據(jù)處理，將reduce進程處理的數(shù)據(jù)控制在內(nèi)存中的步驟，包括：

Reduce進程的每個處理過程為自主運行的子線程，各子線程之間通過共享的先進先出異步的消息隊列進行通信。

進一步地，所述將每個分區(qū)切割后的粒度進行多批次shuffle,并將各批次的數(shù)據(jù)依次進行拷貝、合并和reduce的流水線式數(shù)據(jù)處理，將reduce進程處理的數(shù)據(jù)控制在內(nèi)存中的步驟，包括：

所述流水線式數(shù)據(jù)處理多批次并發(fā)運行，根據(jù)可用內(nèi)存的大小除以每個批次配置的內(nèi)存大小控制并發(fā)的批次數(shù)。

進一步地，所述將每個分區(qū)的Map輸出結果數(shù)據(jù)進行粒度切割，并將切割后的粒度進行排序的步驟之前，包括：

通過所述流水線式處理指定批次數(shù)據(jù)后，同步所有reduce一次；

所述將每個分區(qū)的Map輸出結果數(shù)據(jù)進行粒度切割，并將切割后的粒度進行排序的步驟之后，包括：

按相對bucket ID排序來存MOF文件，相應地按同樣順序來預緩存。

進一步地，所述將每個分區(qū)切割后的粒度進行多批次shuffle,并將各批次的數(shù)據(jù)依次進行拷貝、合并和reduce的流水線式數(shù)據(jù)處理，將reduce進程處理的數(shù)據(jù)控制在內(nèi)存中的步驟，包括：

粒度內(nèi)部數(shù)據(jù)選擇性地排序，如果粒度內(nèi)部數(shù)據(jù)未排序，則拷貝后在reduce端進行排序。

本發(fā)明還提供一種基于內(nèi)存的MapReduce引擎數(shù)據(jù)處理裝置，包括：

切割單元，用于將每個分區(qū)的Map輸出結果數(shù)據(jù)進行粒度切割，并將切割后的粒度進行排序；

流水線單元，用于將每個分區(qū)切割后的粒度進行多批次shuffle,并將各批次的數(shù)據(jù)依次進行拷貝、合并和reduce的流水線式數(shù)據(jù)處理，將reduce進程處理的數(shù)據(jù)控制在內(nèi)存中。

進一步地，所述流水線單元，包括：

共享通信模塊，用于Reduce進程的每個處理過程為自主運行的子線程，各子線程之間通過共享的先進先出異步的消息隊列進行通信。

進一步地，所述流水線單元，包括：

并發(fā)運行模塊，用于所述流水線式數(shù)據(jù)處理多批次并發(fā)運行，根據(jù)可用內(nèi)存的大小除以每個批次配置的內(nèi)存大小控制并發(fā)的批次數(shù)。

進一步地，所述基于內(nèi)存的MapReduce引擎數(shù)據(jù)處理裝置，還包括：

同步單元，通過所述流水線式處理指定批次數(shù)據(jù)后，同步所有reduce一次；

存儲單元，按相對bucket ID排序來存MOF文件，相應地按同樣順序來預緩存。

進一步地，所述流水線單元，包括：

粒度內(nèi)部數(shù)據(jù)處理模塊，用于粒度內(nèi)部數(shù)據(jù)選擇性地排序，如果粒度內(nèi)部數(shù)據(jù)未排序，則拷貝后在reduce端進行排序。

本發(fā)明的基于內(nèi)存的MapReduce引擎數(shù)據(jù)處理方法和裝置，通過純軟件方式對MapReduce的reduce進程進行流水線化(pipelining)設計，即對數(shù)據(jù)進行了分批并發(fā)處理，每個批次的shuffle或拷貝，合并(merge)與reduce可控制在內(nèi)存中(In-Memory)中進行，極大地減少了IO的訪問與延遲；還可以根據(jù)可用內(nèi)存的多少來調(diào)節(jié)并發(fā)批次的數(shù)目，從而提高了mapreduce引擎的吞吐量與整體性能，實測結果是原來的1.6倍-2倍以上。

附圖說明

圖1為本發(fā)明一實施例的基于內(nèi)存的MapReduce引擎數(shù)據(jù)處理方法的流程示意圖；

圖2為本發(fā)明一實施例的流水線化的Reduce進程示意圖；

圖3為本發(fā)明一實施例的基于內(nèi)存的MapReduce引擎數(shù)據(jù)處理方法的流程示意圖；

圖4為本發(fā)明一實施例的Reduce進程間按批次同步處理基于zookeeper的示意圖；

圖5為本發(fā)明一實施例的bucket ID的映射關系的示意圖；

圖6為本發(fā)明一實施例的基于內(nèi)存的MapReduce引擎數(shù)據(jù)處理裝置的結構示意框圖；

圖7為本發(fā)明一實施例的流水線單元的結構示意框圖；

圖8為本發(fā)明一實施例的基于內(nèi)存的MapReduce引擎數(shù)據(jù)處理裝置的結構示意框圖。

本發(fā)明目的的實現(xiàn)、功能特點及優(yōu)點將結合實施例，參照附圖做進一步說明。

具體實施方式

應當理解，此處所描述的具體實施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。

參照圖1，本發(fā)明實施例提供一種基于內(nèi)存的MapReduce引擎數(shù)據(jù)處理方法，包括步驟：

S1、將每個分區(qū)的Map輸出結果數(shù)據(jù)進行粒度切割，并將切割后的粒度進行排序；

S2、將每個分區(qū)切割后的粒度進行多批次shuffle,并將各批次的數(shù)據(jù)依次進行拷貝、合并和reduce的流水線式數(shù)據(jù)處理，將reduce進程處理的數(shù)據(jù)控制在內(nèi)存中。

如上述步驟S1所述，對原來每個分區(qū)(partition)的數(shù)據(jù)進行了更細粒度(bucket)的切割，為了實現(xiàn)后續(xù)流水化的數(shù)據(jù)處理，bucket之間必須有序。本實施例中，

如上述步驟S2所述，為了實現(xiàn)流水化作業(yè)，相比原生的shuffle整個分區(qū)的協(xié)議，新的shuffle協(xié)議會把一個分區(qū)進行多批次(pass)shuffle,每個批次只按次序拷貝原來整個分區(qū)數(shù)據(jù)的子集(bucket)，這樣通過調(diào)整bucket的大小，reduce進程的處理的數(shù)據(jù)就可控制在內(nèi)存中。通過純軟件方式對MapReduce的reduce進程進行流水線化(pipelining)設計，即對數(shù)據(jù)進行了分批次處理，每個批次的shuffle或拷貝，合并(merge)與reduce可控制在內(nèi)存中(In-Memory)中進行，極大地減少了IO的訪問與延遲；還可以根據(jù)可用內(nèi)存的多少來調(diào)節(jié)并發(fā)批次的數(shù)目，從而提高了mapreduce引擎的吞吐量與整體性能。

參照圖2，本實施例中，上述將每個分區(qū)切割后的粒度進行多批次shuffle,并將各批次的數(shù)據(jù)依次進行拷貝、合并和reduce的流水線式數(shù)據(jù)處理，將reduce進程處理的數(shù)據(jù)控制在內(nèi)存中的步驟S2，包括：

S21、Reduce進程的每個處理過程為自主運行的子線程，各子線程之間通過共享的先進先出異步的消息隊列進行通信。

如上述步驟S21所述，拷貝線程(fetcher)完成后會通知合并線程(merger)，合并線程完成后會通知reduce線程(reducer)，由于每個批次間保持有序，reducer可以不必等剩余的數(shù)據(jù)拷貝過來而直接做reduce計算，整個過程中，數(shù)據(jù)訪問可以控制在內(nèi)存中進行，延遲會大幅度地降低。

本實施例中，上述將每個分區(qū)切割后的粒度進行多批次shuffle,并將各批次的數(shù)據(jù)依次進行拷貝、合并和reduce的流水線式數(shù)據(jù)處理，將reduce進程處理的數(shù)據(jù)控制在內(nèi)存中的步驟S2，包括：

S22、上述流水線式數(shù)據(jù)處理多批次并發(fā)運行，根據(jù)可用內(nèi)存的大小除以每個批次配置的內(nèi)存大小控制并發(fā)的批次數(shù)。

如上述步驟S22所述，根據(jù)內(nèi)存的可用大小適配地進行并發(fā)運行，相比原生方法，吞吐量極大提高。

本實施例中，上述將每個分區(qū)切割后的粒度進行多批次shuffle,并將各批次的數(shù)據(jù)依次進行拷貝、合并和reduce的流水線式數(shù)據(jù)處理，將reduce進程處理的數(shù)據(jù)控制在內(nèi)存中的步驟，包括：

S23、上述粒度內(nèi)部數(shù)據(jù)選擇性地排序，如果粒度內(nèi)部數(shù)據(jù)未排序，則拷貝后在reduce端進行排序。

如上述步驟S23所述，如果粒度內(nèi)部的數(shù)據(jù)不排序，則可以拷貝后在reduce端進行排序，這樣就把一些排序的cpu消耗從map端轉移到了reduce端，這對map端cpu成為瓶頸的作業(yè)具有減壓幫助。

參照圖3、圖4和圖5，本實施例中，上述將每個分區(qū)的Map輸出結果數(shù)據(jù)進行粒度切割，并將切割后的粒度進行排序的步驟S1之前，包括：

S11、同步單元，通過所述流水線式處理指定批次數(shù)據(jù)后，同步所有reduce一次；

上述將每個分區(qū)的Map輸出結果數(shù)據(jù)進行粒度切割，并將切割后的粒度進行排序的步驟S1之后，包括：

S12、存儲單元，按相對bucket ID排序來存MOF文件，相應地按同樣順序來預緩存。

如上述步驟S11所述，由于reduce啟動順序的差異化，以及節(jié)點計算能力還有網(wǎng)絡的差異化，每個reduce運行的批次(pass)差異化有時會很明顯，比如一個reduce在運行pass 0，另一個reduce在運行pass 5，如此對于MOF的按批次的預緩存是個考驗，內(nèi)存可能不夠cache這么多從0到5批次的數(shù)據(jù)，需要一種同步機制來鎖住(lock)批次，等所有reduce完成相同批次的處理后，統(tǒng)一進入下一批次的處理，以保證MOF的cache被擊中(hit)。參照圖4，由于各個reduce可能分布在不用的節(jié)點上，本實施例采用了hadoop系統(tǒng)中的節(jié)點同步機制zookeeper來實現(xiàn)，控制每隔開指定數(shù)量的批次同步一次所有reduce，也就是說reduce之間差異化不會超過指定數(shù)量個批次。

參照圖5，如上述步驟S12所述，由于多批次shuffle，每個reduce都從相對的bucket 0開始按順序進行，我們按相對bucket ID排序來存MOF文件，相應地按同樣順序來預緩存(cache)的新方法，有效地減少了隨機IO的幾率，增加了cache擊中(hit)幾率。

本實施例中，由于流水線化后成了基于內(nèi)存的計算，內(nèi)存的使用與管理對性能的影響也非常大，基于Java虛擬機(JVM)管理的內(nèi)存受垃圾回收(Garbbage Collection)性能的限制，明顯不適合本發(fā)明。本發(fā)明采用了從系統(tǒng)直接分配內(nèi)存然后自己管理，而不使用JVM。

在一具體實施例中，做一種對比試驗，進行4、實驗數(shù)據(jù)比較分析，如下：

(1)測試環(huán)境：4數(shù)據(jù)節(jié)點

hadoop軟件-三大供應商CDH,HDP,MAPR結果類似

CPU 2x8核

RAM 128GB

Disk 2TBx12

(2)實測結果，如下表：

從上表可以看出，本發(fā)明顯著提高了MapReduce自身的數(shù)據(jù)處理能力，大概是原來的1.6倍-2倍。

本實施例的基于內(nèi)存的MapReduce引擎數(shù)據(jù)處理方法，通過純軟件方式對MapReduce的reduce進程進行流水線化(pipelining)設計，即對數(shù)據(jù)進行了分批并發(fā)處理，每個批次的shuffle或拷貝，合并(merge)與reduce可控制在內(nèi)存中(In-Memory)中進行，極大地減少了IO的訪問與延遲；還可以根據(jù)可用內(nèi)存的多少來調(diào)節(jié)并發(fā)批次的數(shù)目，從而提高了mapreduce引擎的吞吐量與整體性能，實測結果是原來的1.6倍-2倍以上。

參照圖6，本發(fā)明實施例還提供一種基于內(nèi)存的MapReduce引擎數(shù)據(jù)處理裝置，包括：

切割單元10，用于將每個分區(qū)的Map輸出結果數(shù)據(jù)進行粒度切割，并將切割后的粒度進行排序；

流水線單元20，用于將每個分區(qū)切割后的粒度進行多批次shuffle,并將各批次的數(shù)據(jù)依次進行拷貝、合并和reduce的流水線式數(shù)據(jù)處理，將reduce進程處理的數(shù)據(jù)控制在內(nèi)存中。

如上述切割單元10，對原來每個分區(qū)(partition)的數(shù)據(jù)進行了更細粒度(bucket)的切割，為了實現(xiàn)后續(xù)流水化的數(shù)據(jù)處理，bucket之間必須有序。本實施例中，

如上述流水線單元20，為了實現(xiàn)流水化作業(yè)，相比原生的shuffle整個分區(qū)的協(xié)議，新的shuffle協(xié)議會把一個分區(qū)進行多批次(pass)shuffle,每個批次只按次序拷貝原來整個分區(qū)數(shù)據(jù)的子集(bucket)，這樣通過調(diào)整bucket的大小，reduce進程的處理的數(shù)據(jù)就可控制在內(nèi)存中。通過純軟件方式對MapReduce的reduce進程進行流水線化(pipelining)設計，即對數(shù)據(jù)進行了分批次處理，每個批次的shuffle或拷貝，合并(merge)與reduce可控制在內(nèi)存中(In-Memory)中進行，極大地減少了IO的訪問與延遲；還可以根據(jù)可用內(nèi)存的多少來調(diào)節(jié)并發(fā)批次的數(shù)目，從而提高了mapreduce引擎的吞吐量與整體性能。

參照圖7，本實施例中，上述流水線單元20，包括：

共享通信模塊21，用于Reduce進程的每個處理過程為自主運行的子線程，各子線程之間通過共享的先進先出異步的消息隊列進行通信。

如上述共享通信模塊，拷貝線程(fetcher)完成后會通知合并線程(merger)，合并線程完成后會通知reduce線程(reducer)，由于每個批次間保持有序，reducer可以不必等剩余的數(shù)據(jù)拷貝過來而直接做reduce計算，整個過程中，數(shù)據(jù)訪問可以控制在內(nèi)存中進行，延遲會大幅度地降低。

本實施例中，上述流水線單元20，包括：

并發(fā)運行模塊22，用于所述流水線式數(shù)據(jù)處理多批次并發(fā)運行，根據(jù)可用內(nèi)存的大小除以每個批次配置的內(nèi)存大小控制并發(fā)的批次數(shù)。

如上述并發(fā)運行模塊，根據(jù)內(nèi)存的可用大小適配地進行并發(fā)運行，相比原生方法，吞吐量極大提高。

本實施例中，上述流水線單元20，包括：

粒度內(nèi)部數(shù)據(jù)處理模塊23，用于粒度內(nèi)部數(shù)據(jù)選擇性地排序，如果粒度內(nèi)部數(shù)據(jù)未排序，則拷貝后在reduce端進行排序。

如上述粒度內(nèi)部數(shù)據(jù)處理模塊23，如果粒度內(nèi)部的數(shù)據(jù)不排序，則可以拷貝后在reduce端進行排序，這樣就把一些排序的cpu消耗從map端轉移到了reduce端，這對map端cpu成為瓶頸的作業(yè)具有減壓幫助。

參照圖8，本實施例中，上述基于內(nèi)存的MapReduce引擎數(shù)據(jù)處理裝置，還包括：

同步單元110，通過所述流水線式處理指定批次數(shù)據(jù)后，同步所有reduce一次；

存儲單元120，按相對bucket ID排序來存MOF文件，相應地按同樣順序來預緩存。

如上述同步單元110，由于reduce啟動順序的差異化，以及節(jié)點計算能力還有網(wǎng)絡的差異化，每個reduce運行的批次(pass)差異化有時會很明顯，比如一個reduce在運行pass 0，另一個reduce在運行pass 5，如此對于MOF的按批次的預緩存是個考驗，內(nèi)存可能不夠cache這么多從0到5批次的數(shù)據(jù)，需要一種同步機制來鎖住(lock)批次，等所有reduce完成相同批次的處理后，統(tǒng)一進入下一批次的處理，以保證MOF的cache被擊中(hit)。參照圖4，由于各個reduce可能分布在不用的節(jié)點上，本實施例采用了hadoop系統(tǒng)中的節(jié)點同步機制zookeeper來實現(xiàn)，控制每隔開指定數(shù)量的批次同步一次所有reduce，也就是說reduce之間差異化不會超過指定數(shù)量個批次。

參照圖5，如上述存儲單元120，由于多批次shuffle，每個reduce都從相對的bucket 0開始按順序進行，我們按相對bucket ID排序來存MOF文件，相應地按同樣順序來預緩存(cache)的新方法，有效地減少了隨機IO的幾率，增加了cache擊中(hit)幾率。

本實施例中，由于流水線化后成了基于內(nèi)存的計算，內(nèi)存的使用與管理對性能的影響也非常大，基于Java虛擬機(JVM)管理的內(nèi)存受垃圾回收(Garbbage Collection)性能的限制，明顯不適合本發(fā)明。本發(fā)明采用了從系統(tǒng)直接分配內(nèi)存然后自己管理，而不使用JVM。

在一具體實施例中，做一種對比試驗，進行4、實驗數(shù)據(jù)比較分析，如下：

(1)測試環(huán)境：4數(shù)據(jù)節(jié)點

hadoop軟件-三大供應商CDH,HDP,MAPR結果類似

CPU 2x8核

RAM 128GB

Disk 2TBx12

(2)實測結果，如下表：

從上表可以看出，本發(fā)明顯著提高了MapReduce自身的數(shù)據(jù)處理能力，大概是原來的1.6倍-2倍。

本實施例的基于內(nèi)存的MapReduce引擎數(shù)據(jù)處理裝置，通過純軟件方式對MapReduce的reduce進程進行流水線化(pipelining)設計，即對數(shù)據(jù)進行了分批并發(fā)處理，每個批次的shuffle或拷貝，合并(merge)與reduce可控制在內(nèi)存中(In-Memory)中進行，極大地減少了IO的訪問與延遲；還可以根據(jù)可用內(nèi)存的多少來調(diào)節(jié)并發(fā)批次的數(shù)目，從而提高了mapreduce引擎的吞吐量與整體性能，實測結果是原來的1.6倍-2倍以上。

以上所述僅為本發(fā)明的優(yōu)選實施例，并非因此限制本發(fā)明的專利范圍，凡是利用本發(fā)明說明書及附圖內(nèi)容所作的等效結構或等效流程變換，或直接或間接運用在其他相關的技術領域，均同理包括在本發(fā)明的專利保護范圍內(nèi)。