一種基于多線程的MapReduce執(zhí)行系統(tǒng)的制作方法
【專利摘要】本發(fā)明公開了一種基于多線程的MapReduce執(zhí)行系統(tǒng)，包括：實現(xiàn)一個多線程的MapReduce執(zhí)行引擎：將原有Hadoop中Map/Reduce任務的多進程執(zhí)行模式改為多線程方式；提取Map任務和Reduce任務中對內存使用的細節(jié)特征，根據這些特征將MapReduce流程細粒度地分為多個階段，并將原有Hadoop中shuffle過程由Reduce的拉取改為Map的主動推送；在MapReduce多線程執(zhí)行引擎內部實現(xiàn)統(tǒng)一的內存管理模塊和I/O管理模塊，統(tǒng)一管理各個任務線程對內存的使用；設計全局的內存調度和IO調度算法，在作業(yè)執(zhí)行過程中動態(tài)調度系統(tǒng)資源。本發(fā)明能夠在用戶完全無需修改原有MapReduce程序的基礎上，最大化內存使用，充分利用磁盤帶寬，解決原有Hadoop中一直存在的I/O瓶頸問題。
【專利說明】—種基于多線程的MapReduce執(zhí)行系統(tǒng)
【技術領域】
[0001]本發(fā)明屬于大數(shù)據分布式計算領域,更具體地,涉及一種I/O高效的MapReduce執(zhí)行系統(tǒng)。
【背景技術】
[0002]通用的Hadoop系統(tǒng)是普及最廣的一個MapReduce開源系統(tǒng)，它以多進程的方式運行任務，各個任務在運行時沒有任何聯(lián)系，管理上的簡單導致了資源的粗放使用。目前系統(tǒng)普遍場景就是多個CPU與多塊磁盤將內存劃分成不同的獨立分區(qū)來運行程序。CPU資源嚴重過剩，但是調度卻以CPU為核心，極大增加了系統(tǒng)的等待時間；內存使用相互隔離，而且Reduce的執(zhí)行必須等到所有Map完成之后才能開始，內存浪費嚴重；同時磁盤讀寫不合理，并行訪問磁盤，降低了磁盤效率。節(jié)點的性能無法達到理論上的最大值，且相去甚遠，主要的原因就是硬件資源的配置不協(xié)調，各部件都是分散的工作沒有協(xié)調統(tǒng)一的管理。學術界和企業(yè)界對這類問題也進行了 一些積極探索。
[0003]MapReduce Online系統(tǒng)中最明顯的改進就是提前了 Reduce進程的執(zhí)行時間，平衡了 Map與Reduce任務之間的資源使用空隙，提高了系統(tǒng)的資源利用率。但是這也只是一種粗粒度的管理，杯水車薪，沒有解決根本問題。
[0004]One-Pass系統(tǒng)緩解了內存不足的問題,通過使用hash的方式代替Merge Sort,減小了系統(tǒng)對內存的需求，避開了內存管理這個問題，而且它改變了原來的排序屬性，減小了系統(tǒng)的使用范圍。
[0005]ThemisMR系統(tǒng)首先在硬件上進行定制，爭取達到硬件之間的順滑。其次在軟件層次主要有兩點兒創(chuàng)新。一是將I/O讀寫次數(shù)控制到2次，避免了頻繁的I/O讀寫對性能的影響；二是動態(tài)的自適應的內存分配使不同種類的任務得到最優(yōu)的內存分配。但它是用C++重寫的MapReduce計算系統(tǒng),在可用性,容錯性等方面不能同Hadoop相比,而且也喪失了現(xiàn)有程序的兼容性，很難得到廣泛使用。

【發(fā)明內容】

[0006]針對現(xiàn)有技術的缺陷，本發(fā)明的目的在于提供一種基于多線程的MapReduce執(zhí)行系統(tǒng)，旨在解決現(xiàn)有方法中存在的高成本、低效率、高門檻、以及可用性差的問題。
[0007]為實現(xiàn)上述目的，本發(fā)明提供了一種基于多線程的MapReduce執(zhí)行系統(tǒng)，包括:
[0008](I) MapReduce多線程任務執(zhí)行模塊，米用多線程方式執(zhí)行Hadoop中的Map/Reduce 任務；
[0009](2)細粒度任務執(zhí)行模塊，用于提取Map任務和Reduce任務的內存使用特征，并根據這些特征將MapReduce流程分為多個階段,并且，采用Map主動推送方式進行Hadoop的shuffle 過程；
[0010](3)內存管理模塊，用于統(tǒng)一管理各個任務線程對內存的使用，包括動態(tài)分配和回收各個任務執(zhí)行過程中使用的內存；[0011](4)1/0管理模塊，用于統(tǒng)一管理各個任務線程在執(zhí)行過程中對本地磁盤的讀寫請求，最小化磁盤I/O等待時間。
[0012]與現(xiàn)有技術相比，本方法具有以下的有益效果:
[0013](I)細粒度的資源管理
[0014]將Map任務和Reduce任務對資源的使用情況細分成幾個階段，在每個階段都有對資源的釋放和回收，并對每個階段設置不同的優(yōu)先級。在出現(xiàn)資源爭用時可首先根據不同優(yōu)先級來分配資源，而在同等優(yōu)先級的資源請求間分配時遵循FIFO原則。
[0015](2)高效的資源共享機制
[0016]由于資源管理器和各個任務都執(zhí)行進程的各個線程，各個任務對資源的共享可以在統(tǒng)一的地址空間內直接實現(xiàn)，避免了消息傳遞和資源拷貝的開銷。采用分層的資源管理機制，盡可能減輕最頂層的資源管理壓力，下放資源管理負擔給下層調度器，以此來減少資源的競爭。
[0017](3)良好的可擴展性和兼容性
[0018]本系統(tǒng)為資源申請，分配，回收都提供了統(tǒng)一的接口，調度算法的實現(xiàn)也是可配置的。用戶可根據實際情況對資源管理進行擴展升級。Hadoop原有的接口并沒有改變，而且對于各個任務的執(zhí)行線程做了類加載器的隔離，避免了靜態(tài)變量的相互干擾，因此原有的MapReduce程序可以不做任何修改直接運行在本系統(tǒng)上。
[0019](4)保有原Hadoop的高可用性,容錯性
[0020]本發(fā)明僅對Hadoop的執(zhí)行部分進行優(yōu)化，其他部分未作改變，因此原有Hadoop優(yōu)良特性都能繼續(xù)發(fā)揮作用。每個Map任務的中間結果依然是寫磁盤的,在Reduce失效時，仍然能夠僅重啟該Reduce任務即可。此外本系統(tǒng)通過殺死任務相關線程的方式來殺死任務，仍然支持原有Hadoop的投機性執(zhí)行系統(tǒng)。
【專利附圖】

【附圖說明】
[0021]圖1是多線程MapReduce執(zhí)行系統(tǒng)的整體結構圖。
[0022]圖2是內存管理模塊的結構示意圖。
[0023]圖3是I/O管理模塊的結構示意圖。
【具體實施方式】
[0024]為了使本發(fā)明的目的、技術方案及優(yōu)點更加清楚明白，以下結合附圖及實施例，對本發(fā)明進行進一步詳細說明。應當理解，此處所描述的具體實施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。
[0025]Hadoop之所以被廣泛使用，一個重要的原因是其成熟的代碼和高可用性。本發(fā)明目的是在保持它原有的優(yōu)良特性的同時提高其執(zhí)行效率，為此，系統(tǒng)接口跟原有的Hadoop一模一樣，用戶在使用本發(fā)明時無需修改其原有的MapReduce程序。用戶在其所在節(jié)點上通過JobClient提交作業(yè)給JobTracker, JobTracker對作業(yè)進行調度,并初始化作業(yè)，待準備就緒后在各個TaskTracker通過心跳聯(lián)系JobTracker時,JobTracker就將初始化好的作業(yè)任務按照固有的調度算法分配給各個TaskTracker。該部分跟原有的Hadoop —模一樣。
[0026]如圖1所示，本發(fā)明基于多線程的MapReduce執(zhí)行系統(tǒng)主要架構如下:[0027](I) MapReduce多線程任務執(zhí)行模塊(TaskExecutor),米用多線程方式執(zhí)行Hadoop中的Map/Reduce任務。其中，原有Hadoop中Map/Reduce任務的多進程執(zhí)行模式被改為多線程方式，具體為:在MapReduce集群中的任一個TaskTracker節(jié)點上，除了原有的TaskTracker進程之外,還開啟一個多線程任務執(zhí)行引擎，當TaskTracker被分配到一個Map任務或Reduce任務時，將該任務交給多線程任務執(zhí)行引擎以多線程的方式執(zhí)行。
[0028]其中,TaskTracker在獲取任務后,將其加入待執(zhí)行任務列表中。TaskExecutor周期性地訪問TaskTracker,當有空余的任務槽時就從TaskTracker中拉取任務,對任務進行初始化并開啟相應的線程來開啟該任務。
[0029](2)細粒度任務執(zhí)行模塊，用于提取Map任務和Reduce任務的內存使用特征，并根據這些特征將MapReduce流程分為多個階段,并且，采用Map主動推送方式進行Hadoop的shuffle過程。內存使用的方式包括Map任務中的排序緩沖區(qū)，Map任務中的發(fā)送緩沖區(qū)和Reduce任務中的接收緩沖區(qū)。其中，原有Hadoop中shuffle過程由Reduce的拉取改為Map的主動推送，具體為:一旦Map任務執(zhí)行完成，將其結果數(shù)據緩存在發(fā)送緩沖區(qū)中，然后主動推送發(fā)送緩沖區(qū)中的數(shù)據到Reduce任務的接收緩沖區(qū)中。
[0030]所述細粒度任務執(zhí)行具體為:將Map任務分為Map函數(shù)執(zhí)行、中間部分結果排序、將部分結果歸并為最終結果和最終結果推送。其中，中間部分結果存放在排序緩沖區(qū)中，每個Map任務的最終結果放在發(fā)送緩沖區(qū)中。將Reduce任務分為Map數(shù)據接收、數(shù)據排序、Reduce函數(shù)執(zhí)行和Reduce結果寫到HDFS。其中Reduce任務從Map端接收過來的數(shù)據就放在接收緩沖區(qū)中。
[0031](3)內存管理模塊，用于統(tǒng)一管理各個任務線程對內存的使用，包括動態(tài)分配和回收各個任務執(zhí)行過程中使用的內存。
[0032]內存管理模塊采用分層的結構來管理所有Map任務和Reduce任務的內存使用請求。如圖2所不，內存管理模塊分為三層:最上一層為全局內存管理模塊，中間一層為Map內存管理模塊和Reduce內存管理模塊，最下一層為具體的Map任務和Reduce任務。其中，全局內存管理模塊用于協(xié)調Map內存管理模塊和Reduce內存管理模塊的內存使用配額；Map內存管理模塊用于管理所有Map任務的內存使用請求；Reduce內存管理用于所有Reduce任務的內存使用請求。
[0033]內存管理模塊在分配內存時主要根據各個內存使用類型的優(yōu)先級的原則，具體為:發(fā)送緩沖區(qū) > 發(fā)送緩沖區(qū) > 接收緩沖區(qū)，而內存回收時的優(yōu)先級跟分配時的優(yōu)先級相反。當內存請求類型相同時，采用FIFO的策略來分配內存；當內存請求類型不同時，根據優(yōu)先級來處理內存使用請求。
[0034](4)1/0管理模塊，用于統(tǒng)一管理各個任務線程在執(zhí)行過程中對本地磁盤的讀寫請求，最小化磁盤I/o等待時間。如圖3所示，I/O管理模塊包括寫請求管理子模塊和讀請求管理子模塊，在讀/寫請求管理子模塊中針對同一個文件的讀/寫請求都對應一個讀/寫請求隊列，用于緩存所要讀/寫的數(shù)據。隊列有一個上限，超過隊列上限時，讀/寫操作會被阻塞。隊列中對內存的申請和釋放也是需要內存管理模塊的統(tǒng)一管理。
[0035]I/O管理模塊主要用到交錯I/O和異步I/O的技術。其中交錯I/O是指多個I/O請求按照一定的粒度交錯地進行I/o的方式。由于并發(fā)I/O會導致磁盤尋道，而串行I/O雖然效率最高但會喪失公平性，因此用交錯I/o的方式來提高磁盤效率的同時保持一定的公平性。異步I/o是指I/O管理模塊用獨立的線程來進行I/O操作，以重疊CPU計算和磁盤 I/O。
[0036]I/O管理模塊對多個I/O請求的調度主要根據I/O優(yōu)先級的原則，優(yōu)先級的設置為:
[0037](I)主動I/O〉被動1/0，其中，主動I/O是指系統(tǒng)主動進行的I/O操作，比如為了容錯需要將Map的結果數(shù)據主動寫磁盤；被動I/O是指由于內存不足需要將緩沖區(qū)中的數(shù)據先寫到磁盤中。
[0038](2)被動I/O主要用于內存回收，其優(yōu)先級跟內存分配時的優(yōu)先級順序相反，即:接收緩沖區(qū) > 發(fā)送緩沖區(qū) > 排序緩沖區(qū)。
[0039]處理不同優(yōu)先級的請求時，直接按照優(yōu)先級大小的順序來完成I/O操作；處理相同優(yōu)先級的請求時，采用交錯I/o的方式。
[0040]在本實施例中，ResourceScheduler也即內存管理模塊和I/O管理模塊，它們都以單例模式在MapReduce多線程任務執(zhí)行模塊中運行，各個任務對內存的使用都是通過內存管理模塊來調度分配，各個任務進行的磁盤讀寫操作都是通過I/O管理模塊來統(tǒng)一管理。
[0041]為了驗證本發(fā)明系統(tǒng)的可行性和有效性，在真實環(huán)境下配置本發(fā)明系統(tǒng)，對Hadoop典型應用集合進行實驗。
[0042]本發(fā)明的Hadoop集群基本硬件和軟件配置如表1所示:
[0043]
【權利要求】
1.一種基于多線程的MapReduce執(zhí)行系統(tǒng),包括: (1)MapReduce多線程任務執(zhí)行模塊,米用多線程方式執(zhí)行Hadoop中的Map/Reduce任務; (2)細粒度任務執(zhí)行模塊，用于提取Map任務和Reduce任務的內存使用特征，并根據這些特征將MapReduce流程分為多個階段，并且,采用Map主動推送方式進行Hadoop的shuffle 過程； (3)內存管理模塊，用于統(tǒng)一管理各個任務線程對內存的使用，包括動態(tài)分配和回收各個任務執(zhí)行過程中使用的內存； (4)I/O管理模塊，用于統(tǒng)一管理各個任務線程在執(zhí)行過程中對本地磁盤的讀寫請求，最小化磁盤i/o等待時間。
2.根據權利要求1所述的基于多線程的MapReduce執(zhí)行系統(tǒng)，其中，所述采用多線程方式執(zhí)行Hadoop中的Map/Reduce任務具體為:在MapReduce集群中的任一個TaskTracker節(jié)點上，除了原有的TaskTracker進程之外,還開啟一個多線程任務執(zhí)行引擎，當TaskTracker被分配到一個Map任務或Reduce任務時,將該任務交給多線程任務執(zhí)行引擎以多線程的方式執(zhí)行。
3.根據權利要求1所述的基于多線程的MapReduce執(zhí)行系統(tǒng)，其中，所述內存使用的方式包括Map任務中的排序緩沖區(qū)，Map任務中的發(fā)送緩沖區(qū)和Reduce任務中的接收緩沖區(qū)。
4.根據權利要求1所述的基于多線程的MapReduce執(zhí)行系統(tǒng)，其中，所述細粒度任務執(zhí)行具體為^fMap任務分為Map函數(shù)執(zhí)行、中間部分結果排序、將部分結果歸并為最終結果和最終結果推送；將Reduce任務分為Map數(shù)據接收、數(shù)據排序、Reduce函數(shù)執(zhí)行和Reduce結果寫到HDFS。
5.根據權利要求3所述的基于多線程的MapReduce執(zhí)行系統(tǒng)，其中，所述Map主動推送具體為:一旦Map任務執(zhí)行完成，將其結果數(shù)據緩存在所述發(fā)送緩沖區(qū)中，然后主動推送所述發(fā)送緩沖區(qū)中的數(shù)據到Reduce任務的所述接收緩沖區(qū)中。
6.根據權利要求1所述的基于多線程的MapReduce執(zhí)行系統(tǒng)，其中，所述內存管理模塊和所述I/O管理模塊以單例模式在MapReduce多線程任務執(zhí)行模塊中運行，各個任務對內存的使用通過內存管理模塊來調度分配，各個任務進行的磁盤讀寫操作通過I/O管理模塊來統(tǒng)一管理。
7.根據權利要求1所述的基于多線程的MapReduce執(zhí)行系統(tǒng)，其中，所述內存管理模塊分為三層:最上一層為全局內存管理模塊，中間一層為Map內存管理模塊和Reduce內存管理模塊，最下一層為具體的各個Map任務和Reduce任務。
8.根據權利要求7所述的基于多線程的MapReduce執(zhí)行，其中，全局內存管理模塊用于協(xié)調Map內存管理模塊和Reduce內存管理模塊的內存使用配額；Map內存管理模塊用于管理所有Map任務的內存使用請求；Reduce內存管理用于所有Reduce任務的內存使用請求。
9.根據權利要求1所述的基于多線程的MapReduce執(zhí)行系統(tǒng)，其中，內存管理模塊在分配內存時根據各個內存使用類型的優(yōu)先級的原則，具體為:發(fā)送緩沖區(qū) > 發(fā)送緩沖區(qū) > 接收緩沖區(qū)，而回收內存時的優(yōu)先級跟分配內存時的優(yōu)先級相反。
10.根據權利要求9所述的基于多線程的MapReduce執(zhí)行系統(tǒng)，其中，當內存請求類型相同時，采用FIFO的策略來分配內存；當內存請求類型不同時,根據優(yōu)先級來處理內存使用請求。
11.根據權利要求1所述的基于多線程的MapReduce執(zhí)行系統(tǒng)，其中，I/O管理模塊包括寫請求管理子模塊和讀請求管理子模塊，在讀/寫請求管理子模塊中針對同一個文件的讀/寫請求都對應一個讀/寫請求隊列，用于緩存所要讀/寫的數(shù)據。
12.根據權利要求3所述的基于多線程的MapReduce執(zhí)行系統(tǒng)，其中，I/O管理模塊使用交錯I/O和異步1/0，其中交錯I/O是指多個I/O請求按照一定的粒度交錯地進行I/O ；異步I/O是指I/O管理模塊用獨立的線程來進行I/O操作，以重疊CPU計算和磁盤I/O。
13.根據權利要求12所述的基于多線程的MapReduce執(zhí)行系統(tǒng)，其中，I/O管理模塊對多個I/o請求的調度根據I/O優(yōu)先級的原則，所述優(yōu)先級的設置為: (1)主動I/O〉被動1/0，其中，主動I/O是指系統(tǒng)主動進行的I/O操作；被動I/O是指由于內存不足需要將緩沖區(qū)中的數(shù)據先寫到磁盤中； (2)被動I/O用于內存回收，其優(yōu)先級跟內存分配時的優(yōu)先級順序相反，即:接收緩沖區(qū)〉發(fā)送緩沖區(qū)〉排序緩沖區(qū)。
14.根據權利要求13所述的基于多線程的MapReduce執(zhí)行系統(tǒng)，其中，處理不同優(yōu)先級的請求時，直接按照優(yōu)先級大小的順序來完成I/O操作；處理相同優(yōu)先級的請求時,采用所述交錯I/O的方式。
【文檔編號】G06F9/50GK103605576SQ201310602222
【公開日】2014年2月26日 申請日期:2013年11月25日 優(yōu)先權日:2013年11月25日
【發(fā)明者】石宣化, 金海 , 陳明, 吳松, 陸路 申請人:華中科技大學