本發(fā)明涉及在線集群調度技術領域，尤其涉及一種處理Hadoop集群任務數(shù)據(jù)傾斜的負載均衡方法和裝置。

背景技術：

Hadoop是一個以可靠、高效、可伸縮的方式對大量數(shù)據(jù)進行分布式處理的軟件框架。Hadoop集群(cluster)主要的任務部署分為客戶端(Client)機器、主節(jié)點(Master nodes)和從節(jié)點(Slave nodes)3個部分,如圖1所示。數(shù)據(jù)存儲(Hadoop分布式文件系統(tǒng)，Hadoop Distributed File System，HDFS)和對運行在這個數(shù)據(jù)之上的并行計算(MapReduce)的監(jiān)督是Hadoop的兩個關鍵功能模塊，這兩個關鍵功能模塊主要由主節(jié)點負責。HDFS采用主從(Master/Slave)結構模型，一個HDFS集群是由一個名字節(jié)點(NameNode)和若干個數(shù)據(jù)節(jié)點(DataNode)組成的。MapReduce框架是由一個單獨運行在主節(jié)點上的作業(yè)追蹤器(JobTracker)和運行在每個集群從節(jié)點上的任務追蹤器(TaskTracker)共同組成。HDFS和MR共同組成Hadoop分布式系統(tǒng)體系結構的核心。

Hadoop是一個實現(xiàn)了MapReduce模式的開源的分布式并行編程框架，它以其通用、方便實用等特征在云計算和大數(shù)據(jù)處理時代得到了廣泛應用。MapReduce是一種用于大規(guī)模數(shù)據(jù)集(大于1TB)的并行運算的編程模型。MapReduce工作過程包括兩個階段：Map階段和Reduce階段。Map階段包含多個Map任務，Reduc階段包含多個Reduce任務。 在正式執(zhí)行Map函數(shù)前，需要對輸入數(shù)據(jù)進行分片，每個Map任務處理一個邏輯分片(split)。split包含了數(shù)據(jù)起始位置、數(shù)據(jù)長度、數(shù)據(jù)所在節(jié)點等元數(shù)據(jù)信息，其劃分方法通常由用戶自己決定。split的數(shù)量決定了Map任務的數(shù)量。

HDFS實現(xiàn)Hadoop體系結構中對分布式存儲的底層支持存儲。

NameNode執(zhí)行文件系統(tǒng)的命名空間，如打開、關閉、重命名文件或目錄等，也負責數(shù)據(jù)塊到具體DataNode的映射。DataNode既是數(shù)據(jù)存儲節(jié)點，也是計算節(jié)點，它負責處理文件系統(tǒng)客戶端的文件讀寫，并在NameNode的統(tǒng)一調度下進行數(shù)據(jù)庫的創(chuàng)建、刪除和復制工作。

Job Tracker主要負責調度Job的每一個子任務task運行于Task Tracker上，并監(jiān)控它們，如果發(fā)現(xiàn)有失敗的task就重新運行它。Job Tracker還負責跟蹤任務的執(zhí)行進度、資源使用量等信息，并將這些信息告訴任務調度器(Task Scheduler)，以便于調度器在資源出現(xiàn)空閑時將這些資源分配給合適的任務。Task Tracker主動周期性地調用心跳RPC函數(shù)，向Job Tracker匯報節(jié)點和任務運行狀態(tài)信息，同時領取Job Tracker返回心跳包的各種命令并執(zhí)行相應的操作。Task Tracker使用“slot”等量劃分本節(jié)點上的資源量。slot是一個邏輯概念，是Hadoop的資源單位，一個節(jié)點的slot的數(shù)量用來表示某個節(jié)點的資源的容量或者說是能力的大小。slot分為Map slot和Reduce slot兩種，分別供Map Task和Reduce Task使用。每個作業(yè)申請資源以slot為單位，每個節(jié)點會確定自己的計算能力以及存儲器，確定自己包含的slot總量。當某個作業(yè)要開始執(zhí)行時，先向Job Tracker申 請slot，一個任務獲取到一個slot后才有機會運行，而Hadoop調度器的作用就是將各個Task Tracker上的空閑slot分配給任務使用。

Hadoop集群系統(tǒng)中的核心技術是任務調度，在云計算研究中，MapReduce環(huán)境的在線作業(yè)調度帶來了新的課題和挑戰(zhàn)，引起了越來越多的重視。最初，Hadoop默認的FIFO(先入先出)調度器專為周期性執(zhí)行大規(guī)模批量作業(yè)而設計。隨著MapReduce集群系統(tǒng)的用戶數(shù)量的增加，計算能力調度器和Hadoop公平調度器(HFS:Hadoop Fair Scheduling)的出現(xiàn)，提供了更高效的集群共享方式，但是，現(xiàn)有的調度器還不能提供對最小化在線作業(yè)集完工時間的支持，當提交在線作業(yè)為一個作業(yè)集時，完工時間可能較長因而導致總能耗較高。

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

本發(fā)明要解決的技術問題是：提供一種處理MapReduce數(shù)據(jù)傾斜的負載均衡方法和裝置，能夠減輕數(shù)據(jù)傾斜程度，加快任務處理速度。

為解決上述技術問題，第一方面，本發(fā)明實施例提供了一種處理MapReduce數(shù)據(jù)傾斜的負載均衡方法，所述方法包括以下四大步驟：

對輸入數(shù)據(jù)進行抽樣分析，確定平均每個Reduce節(jié)點上任務數(shù)量；

根據(jù)任務的個數(shù)和時間系數(shù)，按照基于時間系數(shù)的任務數(shù)量從大到小降序排序，數(shù)量相同則按照序號排序；

按照資源剩余容量最大的原則以及所排任務順序依次分配任務，直到所有任務分配完畢；

將分配方式提交給自定義的Partition函數(shù)，執(zhí)行任務處理過程；

根據(jù)第一方面，在第一種可能的實現(xiàn)方式中，所述對輸入數(shù)據(jù)進行抽樣分析，確定平均每個Reduce節(jié)點上任務數(shù)量；

對輸入的文件，各個節(jié)點根據(jù)自己擁有的文件塊進行計算，使用API計算文件的行數(shù)；

運行Map程序統(tǒng)計各個節(jié)點上樣本key值的頻率，并記錄該節(jié)點key的總個數(shù)，總個數(shù)可以通過獲得文件行數(shù)乘以每行key值獲?。?/p>

運行Reduce程序匯總所有key的頻率，并統(tǒng)計出各個key最終頻率，同時匯總所有key的總個數(shù)，根據(jù)抽樣頻率和總個數(shù)，估算出每個key的具體數(shù)量。

根據(jù)第一方面，在第二種可能的實現(xiàn)方式中，所述為所述各個key處理的時間有顯著不同時，每個不同key，設定一個時間系數(shù)t,對任意一個key k_i，t_i的大小定義為該key執(zhí)行時間和執(zhí)行最慢的key的執(zhí)行時間的比值；對每個不同key進行一次執(zhí)行，將該key的執(zhí)行時間進行記錄，增加時間系數(shù)后，可以通過在分配時候把時間系數(shù)考慮進去，解決key值處理時間不同的情形。

根據(jù)第一方面，在第三種可能的實現(xiàn)方式中，所述根據(jù)key的個數(shù)和時間系數(shù)，按照基于時間系數(shù)的key數(shù)量從大到小降序排序，數(shù)量相同則按照序號排序。

根據(jù)第一方面的第四種可能的實現(xiàn)方式，取出key選擇Reduce剩余數(shù)量最大的分配；若該Reduce剩余容量足夠分配，則直接分配給 Reduce，分配后修改Reduce剩余容量數(shù)目；若該Reduce剩余容量不夠，則分配Reduce剩余容量大小并將已經(jīng)分配的k_i標記為k_{i_1}，取出Reduce剩余數(shù)量最大的分配，直到該key分配完畢。

根據(jù)第一方面，在第五種可能的實現(xiàn)方式中，所有調整執(zhí)行完成后，按照調整的結果對輸入文件進行key替換，并將分配方式提交給自定義的Partition函數(shù)。

第二方面，本發(fā)明實施例提供了一種處理MapReduce數(shù)據(jù)傾斜的負載均衡方法裝置，所述裝置四大模塊包括：

抽樣模塊，用于對輸入數(shù)據(jù)進行抽樣分析，確定平均每個Reduce節(jié)點上任務數(shù)量；

排序模塊，根據(jù)任務的個數(shù)和時間系數(shù)，基于時間系數(shù)的任務數(shù)量從大到小降序排序，數(shù)量相同則按照序號排序；

分配模塊，按照資源剩余容量最大的原則以及所排任務順序依次分配任務，直到所有任務分配完畢；

執(zhí)行模塊，用于按照所述順序執(zhí)行任務。

根據(jù)第二方面，在第一種可能的實現(xiàn)方式中，所述抽樣模塊：

對輸入的文件，各個節(jié)點根據(jù)自己擁有的文件塊進行計算，使用API計算文件的行數(shù)；

運行Map程序統(tǒng)計各個節(jié)點上樣本key值的頻率，并記錄該節(jié)點key的總個數(shù)，總個數(shù)可以通過獲得文件行數(shù)乘以每行key值獲?。?/p>

運行Reduce程序匯總所有key的頻率，并統(tǒng)計出各個key最終頻率，同時匯總所有key的總個數(shù)，根據(jù)抽樣頻率和總個數(shù)，估算出每個key 的具體數(shù)量。

并且獲取不同key的時間系數(shù)，通過在分配時候把時間系數(shù)考慮進去，解決key值處理時間不同的情形。

根據(jù)第二方面，在第二種可能的實現(xiàn)方式中，所述排序模塊：

根據(jù)key的個數(shù)和時間系數(shù)，按照基于時間系數(shù)的key數(shù)量從大到小降序排序，數(shù)量相同則按照序號排序。

根據(jù)第二方面，在第三種可能的實現(xiàn)方式中，所述分配模塊：

取出key選擇Reduce剩余數(shù)量最大的分配；若該Reduce剩余容量足夠分配，則直接分配給Reduce，分配后修改Reduce剩余容量數(shù)目；若該Reduce剩余容量不夠，則分配Reduce剩余容量大小并將已經(jīng)分配的k_i標記為k_{i_1}，取出Reduce剩余數(shù)量最大的分配，直到該key分配完畢。

根據(jù)第二方面，在第四種可能的實現(xiàn)方式中，所述執(zhí)行模塊：

在所述根據(jù)任務執(zhí)行順序，依次執(zhí)行任務，直到任務全部完成。

第三方面，本發(fā)明實施例提供了一種處理Hadoop集群任務數(shù)據(jù)傾斜的負載均衡裝置，包括第二方面或第二方面任一種可能的實現(xiàn)方式所述的調度裝置。

第四方面，本發(fā)明實施例提供了一種處理Hadoop集群任務數(shù)據(jù)傾斜的負載均衡的功耗降低方法，其特征在于，所述Hadoop集群系統(tǒng)使用第一方面或第一方面任一種可能的實現(xiàn)方式所述的方法進行調度。

附圖說明

圖1是本發(fā)明一種實施例的Hadoop集群系統(tǒng)部署示意圖；

圖2是本發(fā)明一種實施例的處理MapReduce數(shù)據(jù)傾斜的負載均衡方法流程圖；

圖3是本發(fā)明一種實施例的處理MapReduce數(shù)據(jù)傾斜的負載均衡裝置示意圖；

具體實施方式

下面根據(jù)附圖和實施例，對本發(fā)明的具體實施方式作進一步詳細說明。以下實施例用于說明本發(fā)明，但不用來限制本發(fā)明的范圍。

如圖2所示，本發(fā)明實施例提供了一種處理MapReduce數(shù)據(jù)傾斜的負載均衡方法，該方法包括步驟：

S101.對輸入數(shù)據(jù)進行抽樣分析，確定平均每個Reduce節(jié)點上任務數(shù)量。

S102.根據(jù)任務的個數(shù)和時間系數(shù)，按照基于時間系數(shù)的任務數(shù)量從大到小降序排序，數(shù)量相同則按照序號排序。

S103.按照資源剩余容量最大的原則以及所排任務順序依次分配任務，直到所有任務分配完畢。

S104.將分配方式提交給自定義的Partition函數(shù)，執(zhí)行任務處理過程。

本領域技術人員可以理解，在本發(fā)明各實施例的方法中，各步驟的序號大小并不意味著執(zhí)行順序的先后，各步驟的執(zhí)行順序應以其功能和內在邏輯確定，而不應對本發(fā)明具體實施例的實施過程構成任何限定。

如圖3所示，本發(fā)明實施例還提供了一種實施例的Hadoop集群任務數(shù)據(jù)傾斜的負載均衡裝置的調度裝置300，該裝置300包括：

抽樣模塊310，用于對輸入數(shù)據(jù)進行抽樣分析，確定平均每個Reduce節(jié)點上任務數(shù)量；

對輸入的文件，各個節(jié)點根據(jù)自己擁有的文件塊進行計算，使用API計算文件的行數(shù)；

運行Map程序統(tǒng)計各個節(jié)點上樣本key值的頻率，并記錄該節(jié)點key的總個數(shù)，總個數(shù)可以通過獲得文件行數(shù)乘以每行key值獲取；

運行Reduce程序匯總所有key的頻率，并統(tǒng)計出各個key最終頻率，同時匯總所有key的總個數(shù)，根據(jù)抽樣頻率和總個數(shù)，估算出每個key的具體數(shù)量。

并且獲取不同key的時間系數(shù)，通過在分配時候把時間系數(shù)考慮進去，解決key值處理時間不同的情形。

排序模塊320，用于根據(jù)任務的個數(shù)和時間系數(shù)，按照基于時間系數(shù)的任務數(shù)量從大到小降序排序，數(shù)量相同則按照序號排序；

分配模塊330，用于按照資源剩余容量最大的原則以及所排任務順序依次分配任務，直到所有任務分配完畢。

執(zhí)行模塊340，用于將分配方式提交給自定義的Partition函數(shù)，執(zhí)行任務處理過程。

本發(fā)明實施例還提供了一種包括本發(fā)明實施例的圖3所示的調度裝置的Hadoop集群系統(tǒng)，該集群系統(tǒng)可按照圖1所示的架構部署，該調度裝置可為圖1中所示的任務調度器。

以下通過具體實例來進一步說明本發(fā)明各實施例：

假設一個MapReduce任務，有4種keys(k₁,k₂,k₃,k₄)，運行在4個Reducers(R₁,R₂,R₃,R₄)上，根據(jù)抽樣分析后，得到k₁,k₂,k₃,k₄的數(shù)量分別是1000,100,50,20。則在默認情況下R₁,R₂,R₃,R₄分別分配到的key數(shù)量分別為1000,100,50,20，可以看出R₁分配到的key的數(shù)值明顯大于其他幾個，產生數(shù)據(jù)傾斜，最后導致R₂,R₃,R₄都在等待R₁執(zhí)行完成，總完工時間較長，產生大量能耗。

按照本發(fā)明實施例的方法，對該作業(yè)集進行處理的過程如下：

S510.計算出key的均值k_avg為292，將R₁,R₂,R₃,R₄剩余值設置為292；

S520.取出k₁進行分配，選擇R₁進行分配，由于k₁數(shù)量大于R₁剩余數(shù)量，所以將k₁分配292個key到R₁，并標記為k_{1_2}；

S530.繼續(xù)執(zhí)行，由于k₁剩余數(shù)量大于R₂剩余數(shù)量，因此將k₁剩下部分標記為k_{1_2}分配到R₂，分配key數(shù)量為292，同理將k_{1_3}分配到R₃，分配key數(shù)量為292，分配后k₁剩余數(shù)量為124，小于R₄剩余數(shù)量，故將剩余的124個key全部分配到R₄，標記為k_{1_4}；

同理，取出k₂,k₃,k₄分配到R₄上；

此時R₁,R₂,R₃,R₄分配到的key的數(shù)量分別為292，292，292，294，實現(xiàn)了key值的理想負載均衡。

另一具體實例進一步說明本發(fā)明各實施例：

計算key數(shù)量時候，增加時間系數(shù)，即基于時間系數(shù)的key數(shù)量k^t_i＝k_i×t_i，平均key值則變成了

具體分配時，分配到reduce上數(shù)量為R^t＝R/t。

增加時間系數(shù)后，上述例子中，k^t₁＝500，則按照key均衡調整，k₁分配到R₁上，標記為k_{1_1}，數(shù)量為60，k_{1_2}分配到R₂上，數(shù)量為40，k₂分配到R₂上，數(shù)量100，則兩個ReduceR₁，R₂執(zhí)行時間相同，均為300個單位時間，達到了負載均衡的目的。

本領域普通技術人員可以理解實現(xiàn)上述實施例方法中的全部或部分流程，是可以通過計算機程序來指令相關的硬件來完成，所述的程序可存儲于一臺計算機可讀取存儲介質中，該程序在執(zhí)行時，可包括如上述各方法的實施例的流程。其中，所述的存儲介質可為磁碟、光盤、只讀存儲記憶體(Read-Only Memory，ROM)或隨機存儲記憶體(Random Access Memory，RAM)等。

以上所述，僅為本發(fā)明的具體實施方式，但本發(fā)明的保護范圍并不局限于此，任何熟悉本技術領域的技術人員在本發(fā)明揭露的技術范圍內，可輕易想到的變化或替換，都應涵蓋在本發(fā)明的保護范圍之內。因此，本發(fā)明的保護范圍應該以權利要求的保護范圍為準。