一種基于任務(wù)負載的數(shù)據(jù)遷移方法
【專利摘要】本發(fā)明公開了一種基于任務(wù)負載的數(shù)據(jù)遷移方法，其實現(xiàn)過程為，在關(guān)系型數(shù)據(jù)庫中抽取數(shù)據(jù)，并對數(shù)據(jù)進行格式轉(zhuǎn)換；開始執(zhí)行數(shù)據(jù)遷移，該數(shù)據(jù)遷移過程采用MapReduce架構(gòu)，具體遷移過程為：首先在數(shù)據(jù)源導(dǎo)入數(shù)據(jù)，生成對應(yīng)的運行類打包成jar包，傳遞給Hadoop平臺存儲和處理。該基于任務(wù)負載的數(shù)據(jù)遷移方法與現(xiàn)有技術(shù)相比，解決了每個節(jié)點的任務(wù)處理能力、CPU運算速度和map分配數(shù)量的假設(shè)問題，通過任務(wù)的調(diào)度的優(yōu)化盡量避免出現(xiàn)部分節(jié)點負載過重或者過輕的現(xiàn)象，可以提高數(shù)據(jù)遷移效率，實用性強。
【專利說明】
一種基于任務(wù)負載的數(shù)據(jù)遷移方法
技術(shù)領(lǐng)域
[0001] 本發(fā)明涉及數(shù)據(jù)迀移技術(shù)領(lǐng)域，具體地說是一種實用性強的基于任務(wù)負載的數(shù)據(jù) 迀移方法。
【背景技術(shù)】
[0002] 隨著信息技術(shù)的不斷的發(fā)展，人類社會每年所產(chǎn)生的數(shù)據(jù)量正在以驚人的速度飛 速增長，我們的社會已經(jīng)進入到一個全新的信息化時代。但隨之而來的數(shù)據(jù)存儲的問題，逐 漸成為一個熱點話題。近些年，隨著云計算與大數(shù)據(jù)及其相關(guān)技術(shù)的的不斷發(fā)展，信息化產(chǎn) 業(yè)的格局正在逐漸被改變。在企業(yè)的實際應(yīng)用中，數(shù)據(jù)的存儲必須要求全天候的高可用性 指標，但隨著網(wǎng)絡(luò)存儲系統(tǒng)的規(guī)模越來越大，系統(tǒng)的故障次數(shù)也急劇增加。另外，雖然存儲 系統(tǒng)的規(guī)模越來越大，存儲設(shè)備越來越多，但存儲系統(tǒng)中的資源利用率卻仍然保持在一個 很低的水平。另一方面，在數(shù)據(jù)存儲量增長的情況下，系統(tǒng)需要滿足極高的可擴展性;大規(guī) 模的存儲系統(tǒng)往往是由不同的廠商提供的不同類型的具有極高的異構(gòu)性的存儲設(shè)備組成 的，這樣就造成了管理存儲系統(tǒng)具有較高的復(fù)雜性，同時導(dǎo)致系統(tǒng)在未來使用中的擴展將 成為一個很大的難題。在當(dāng)下技術(shù)條件下，選擇使用云存儲將能夠有效解決上述問題。
[0003] 通常情況下，企業(yè)的信息數(shù)據(jù)系統(tǒng)會包含多個不同的業(yè)務(wù)系統(tǒng)，而且不同的業(yè)務(wù) 系統(tǒng)都包含有各自的一套在線業(yè)務(wù)系統(tǒng)、歸檔系統(tǒng)和備份系統(tǒng)。企業(yè)出于對成本的考慮，存 儲系統(tǒng)會把在線業(yè)務(wù)平臺的數(shù)據(jù)迀移到后端的云存儲平臺。但是數(shù)據(jù)迀移的過程極為復(fù) 雜，需要解決的問題眾多。在數(shù)據(jù)迀移的諸多問題中，我們主要研究了其中一個問題，即關(guān) 系型數(shù)據(jù)將數(shù)據(jù)迀移至大數(shù)據(jù)平臺過程中，數(shù)據(jù)的迀移效率有待提高。我們通過對任務(wù)調(diào) 度機制的優(yōu)化以達到提高數(shù)據(jù)迀移效率的目的。
[0004] 一般情況下，使用者若不對Hadoop進行特殊設(shè)置，則在處理任務(wù)調(diào)度的過程中就 會采用FIFO調(diào)度，其運行原理如圖1所示。Hadoop在利用FIFO調(diào)度器進行作業(yè)是有如下假 設(shè)：
[0005] 分布式集群中，各個節(jié)點進行任務(wù)處理的能力是相同的。
[0006] 每個節(jié)點在對任務(wù)進行處理的過程中、其計算速度和運算能力保持不變，且不受 其他因素的影響。
[0007] 當(dāng)系統(tǒng)對相同的任務(wù)進行處理時，Map Reduce中的map和reduce所接受的任務(wù)分 配和任務(wù)計算的數(shù)量都是相等的。
[0008] 以上條件都會在理想條件下的假設(shè)，在現(xiàn)實的操作使用過程中，基本上很難滿足 以上三條假設(shè)。首先，由于不同節(jié)點的服務(wù)器的異構(gòu)性，很難實現(xiàn)其處理任務(wù)的能力完全相 同，例如在處理計算密集型任務(wù)時時，CPU的運行會變慢，當(dāng)對數(shù)據(jù)密集型的任務(wù)進行處理 時，磁盤的運轉(zhuǎn)速率也會下降。因此，在實際的使用中，各種因素的不穩(wěn)定性對整體數(shù)據(jù)迀 移的執(zhí)行過程，增加了諸多的不穩(wěn)定因素。
[0009] 基于此，現(xiàn)提供一種基于任務(wù)負載的數(shù)據(jù)迀移方法，是通過對任務(wù)調(diào)度機制進行 優(yōu)化從而提高數(shù)據(jù)迀移效率的一種方法。

【發(fā)明內(nèi)容】

[0010] 本發(fā)明的技術(shù)任務(wù)是針對以上不足之處，提供一種實用性強、基于任務(wù)負載的數(shù) 據(jù)迀移方法。
[0011] -種基于任務(wù)負載的數(shù)據(jù)迀移方法，其實現(xiàn)過程為：
[0012] 在關(guān)系型數(shù)據(jù)庫中抽取數(shù)據(jù)，并對數(shù)據(jù)進行格式轉(zhuǎn)換;開始執(zhí)行數(shù)據(jù)迀移，該數(shù)據(jù) 迀移過程采用MapReduce架構(gòu)，具體迀移過程為：首先在數(shù)據(jù)源導(dǎo)入數(shù)據(jù)，生成對應(yīng)的運行 類打包成jar包，傳遞給Hadoop平臺存儲和處理。
[0013] 在執(zhí)行數(shù)據(jù)迀移操作前，首先要完成相關(guān)基本信息的配置，該相關(guān)基本信息包括， 數(shù)據(jù)迀出的位置信息、數(shù)據(jù)迀移目的地的地址信息、數(shù)據(jù)迀移過程中使用map的數(shù)量以及現(xiàn) 有分布式集群各個節(jié)點的服務(wù)器基本的配置情況，完成基本的配置后，開始執(zhí)行數(shù)據(jù)迀移 操作。
[0014] 所述數(shù)據(jù)迀移的具體過程為：
[0015] 步驟一、首先設(shè)置參數(shù)，解析任務(wù)執(zhí)行的預(yù)設(shè)信息并設(shè)置數(shù)據(jù)源和數(shù)據(jù)輸出路徑；
[0016] 步驟二、在預(yù)設(shè)的數(shù)據(jù)源中獲取數(shù)據(jù)；
[0017] 步驟三、轉(zhuǎn)換數(shù)據(jù)格式，即將數(shù)據(jù)由原來的格式轉(zhuǎn)換為大數(shù)據(jù)平臺可存儲的數(shù)據(jù) 格式；
[0018] 步驟四、對數(shù)據(jù)進行劃分分配，下發(fā)至集群中的每個節(jié)點；
[0019]步驟五、最后將數(shù)據(jù)寫入到對應(yīng)的輸出路徑中。
[0020]所述步驟一的具體實現(xiàn)過程為：
[0021 ]首先解析關(guān)于任務(wù)執(zhí)行的系統(tǒng)預(yù)設(shè)信息，即設(shè)置待迀移數(shù)據(jù)的基本信息以及數(shù)據(jù) 迀移中的數(shù)據(jù)信息，該系統(tǒng)預(yù)設(shè)信息包括數(shù)據(jù)是否備份、數(shù)據(jù)的獲取路徑、數(shù)據(jù)的輸出路 徑、數(shù)據(jù)的原始格式、數(shù)據(jù)的輸出格式、對數(shù)據(jù)進行劃分和計算的Mapper類和Reducer類； [0022]然后設(shè)置數(shù)據(jù)源，即解析等待迀移的數(shù)據(jù)目前的存儲的置，為數(shù)據(jù)迀移操作做準 備；
[0023]最后設(shè)置數(shù)據(jù)的輸出路徑，即將數(shù)據(jù)格式轉(zhuǎn)換后的輸出數(shù)據(jù)保存的位置。
[0024]數(shù)據(jù)的輸出路徑采用HBase表。
[0025]所述步驟二在預(yù)設(shè)的數(shù)據(jù)源中獲取數(shù)據(jù)的具體過程為:通過Java編程的方式，利 用JDBC獲取預(yù)設(shè)的關(guān)系型數(shù)據(jù)庫中的數(shù)據(jù)源，獲取后輸出的結(jié)果集是名為ResultSet的 Java對象。
[0026]所述步驟三中的轉(zhuǎn)換數(shù)據(jù)格式是指將ResultSet對象經(jīng)數(shù)據(jù)格式轉(zhuǎn)換成為鍵值對 Key/Value 的形式。
[0027] 所述步驟四數(shù)據(jù)劃分及下發(fā)相關(guān)數(shù)據(jù)的過程為：啟動MapReduce，通過MapReduce 進行數(shù)據(jù)的劃分和計算，然后通過Map對任務(wù)進行分配，下發(fā)至集群中的每個節(jié)點，最后通 過Reduce進行計算，將最后的結(jié)果集寫入到目標地址，當(dāng)所有數(shù)據(jù)完整的寫入到大數(shù)據(jù)平 臺后，實現(xiàn)關(guān)系型數(shù)據(jù)庫數(shù)據(jù)迀移至大數(shù)據(jù)平臺的目的。
[0028]所述步驟四的具體實現(xiàn)過程為：
[0029] 在數(shù)據(jù)劃分及下發(fā)相關(guān)數(shù)據(jù)的過程中，通過MapReduce的map將任務(wù)分配到各個節(jié) 點中進行處理，即將數(shù)據(jù)劃分后分別分發(fā)至每個節(jié)點的TaskTracker中，然后把數(shù)據(jù)寫入到 用戶預(yù)設(shè)的HBase表中進行存儲。
[0030] 通過Map對任務(wù)進行分配，下發(fā)至集群中的每個節(jié)點的具體過程為：當(dāng)檢測到 TaskTracker有空閑的Slot時，系統(tǒng)對其I/O資源占用情況進行檢測，若該節(jié)點的I/O資源占 用為所有節(jié)點中最少，且該節(jié)點任務(wù)負載熵值滿足預(yù)設(shè)的閾值時，JobTracker將自動將任 務(wù)分配給該TaskTracker;反之，若發(fā)現(xiàn)此時該節(jié)點的I/O資源被大量占用或者任務(wù)負載熵 值較大，等待處理的任務(wù)較多，則不將任務(wù)分配給該節(jié)點。
[0031] 上述任務(wù)分配通過任務(wù)調(diào)度器完成，該任務(wù)調(diào)度器的具體操作過程為：
[0032]首先將系統(tǒng)文件mapred-s it e. xml中的相應(yīng)字段設(shè)置為任務(wù)調(diào)度器類 org · apache · hadoop · mapred · TaskScheduler，使得其可在后面的任務(wù)調(diào)度中被使用；
[0033] 然后實現(xiàn)基于任務(wù)負載的任務(wù)調(diào)度器的過程，對JobTracker中的AssignTask方法 進行設(shè)計編寫，這個方法的TaskTracker Status字段中包含有TaskTracker在心跳信息 Heartbeat中提交的相關(guān)信息，該相關(guān)信息包括MapSlot數(shù)量的最大值、ReduceSlot數(shù)量的 最大值、虛擬內(nèi)存最大值、物理內(nèi)存、剩余可用磁盤空間的大小、每個任務(wù)的執(zhí)行狀態(tài)、磁盤 存取狀態(tài)、剩余Slot數(shù)量、磁盤存取速率、CPU的實時狀態(tài)；
[0034] 在對任務(wù)進行分配過程中，JobTracker利用TaskTracker通過心跳信息Heartbeat 發(fā)送得到的信息來判斷將任務(wù)分配給哪些節(jié)點，其中主要參數(shù)有Slot使用情況、磁盤存取 狀態(tài)、任務(wù)阻塞、等待狀態(tài)。
[0035] 基于上述任務(wù)調(diào)度器，具體的任務(wù)調(diào)度情況為：
[0036] 如果節(jié)點的TaskTracker中所有的slot都已經(jīng)被占用，則任務(wù)調(diào)度器則拒絕將新 的任務(wù)分配至該TaskTracker;
[0037]若TaskTracker上尚且存在空閑的Slot，貝lj需要對磁盤占用情況，任務(wù)等待情況等 進行監(jiān)測判斷：
[0038] a).若當(dāng)前節(jié)點負載任務(wù)情況，依據(jù)任務(wù)負載均衡評測模型計算得到的Pl值高于 平均值則不將新任務(wù)分配給該節(jié)點；
[0039] b). 1若當(dāng)前節(jié)點負載情況，依據(jù)任務(wù)負載均衡評測模型計算得到的Pl值低于平均 值《，則該節(jié)點可以接受新任務(wù)。
[0040] 所述步驟五即為將數(shù)據(jù)寫入HBase:每個節(jié)點的TaskTracker對任務(wù)進行計算處理 輸出數(shù)據(jù)，將讀取到的鍵值對數(shù)據(jù)寫入HBase表;數(shù)據(jù)迀移過程隨著系統(tǒng)中Map任務(wù)全部結(jié) 束而結(jié)束，反之，若數(shù)據(jù)迀移尚未結(jié)束，則TaskTracker將繼續(xù)將任務(wù)分配給每個 TaskTracker進行處理。
[0041] 本發(fā)明的一種基于任務(wù)負載的數(shù)據(jù)迀移方法，具有以下優(yōu)點：
[0042] 本發(fā)明提出的一種基于任務(wù)負載的數(shù)據(jù)迀移方法，利用群智能算法中的人工蜂群 算法對任務(wù)調(diào)度機制進行優(yōu)化，Hadoop默認FIFO調(diào)度的一些假設(shè)，都是在理想條件下提出 的，但是在現(xiàn)實的操作使用過程中，基本上很難滿足這些假設(shè)。因而在實際的使用中，各種 因素的不穩(wěn)定性對整體數(shù)據(jù)迀移的執(zhí)行過程，增加了諸多的不穩(wěn)定因素，我們利用優(yōu)化的 的任務(wù)調(diào)度機制一定程度上解決了其中每個節(jié)點的任務(wù)處理能力、CPU運算速度和map分配 數(shù)量的假設(shè);利用任務(wù)調(diào)度機制的優(yōu)化來提高數(shù)據(jù)迀移的效率，由于原有的任務(wù)調(diào)度機制 可能導(dǎo)致分布式集群中部分節(jié)點任務(wù)負載較重或者較輕，這種情況的出現(xiàn)將會影響數(shù)據(jù)的 讀寫速率，從而一定程度上影響到了數(shù)據(jù)迀移的效率，我們通過任務(wù)的調(diào)度的優(yōu)化盡量避 免出現(xiàn)部分節(jié)點負載過重或者過輕的現(xiàn)象，可以提高數(shù)據(jù)迀移效率，實用性強，易于推廣。
【附圖說明】
[0043]附圖1為FIFO調(diào)度器原理示意圖。
[0044]附圖2為展示了基于ABC算法優(yōu)化的Hadoop任務(wù)調(diào)度過程。
[0045] 附圖3為數(shù)據(jù)迀移過程流程圖。
[0046] 附圖4為基于任務(wù)負載的數(shù)據(jù)迀移流程。
[0047] 附圖5為數(shù)據(jù)量與迀移時間示意圖。
[0048] 附圖6為對應(yīng)的map數(shù)量與效率。
【具體實施方式】
[0049]下面結(jié)合附圖和具體實施例對本發(fā)明作進一步說明。
[0050] 傳統(tǒng)的關(guān)系型數(shù)據(jù)庫如oraclejysql在過去很長一段時間內(nèi)占據(jù)了數(shù)據(jù)庫領(lǐng)域 的統(tǒng)治地位。但是對于關(guān)系型數(shù)據(jù)庫而言，當(dāng)存儲規(guī)模達到一定限度時，系統(tǒng)非常容易出現(xiàn) 死鎖等并發(fā)問題，從而導(dǎo)致數(shù)據(jù)在讀寫過程中性能嚴重下降，影響用戶對數(shù)據(jù)的查詢刪除 插入等操作。因此面對海量的數(shù)據(jù)的存儲和讀寫查詢工作，構(gòu)建一個可靠性高并且可擴展 性好的大數(shù)據(jù)平臺對的工業(yè)企業(yè)而言是極其緊迫的。于是此時面臨許多問題，關(guān)系型數(shù)據(jù) 庫數(shù)據(jù)如何迀移至大數(shù)據(jù)平臺使得效率更高，消耗資源更少;分布式存儲系統(tǒng)的數(shù)據(jù)如何 讓存儲才能使得數(shù)據(jù)讀取等更加迅速;哪些數(shù)據(jù)需要迀移至大數(shù)據(jù)平臺；數(shù)據(jù)迀移至大數(shù) 據(jù)平臺后，數(shù)據(jù)查詢、數(shù)據(jù)挖掘等怎么樣才能方便快捷高效;對于使用較頻繁的數(shù)據(jù)如何讓 處理才能使得數(shù)據(jù)的讀取和使用效率更高。
[0051] 如附圖2-4所示，針對將在線數(shù)據(jù)數(shù)據(jù)迀移到大數(shù)據(jù)平臺的需求，我們提出一種基 于任務(wù)調(diào)度機制的數(shù)據(jù)迀移方法。為了對上述方法進行實驗分析，我們使用了 Hadoop架構(gòu) 進行實現(xiàn)，并通過與Hadoop默認的FIFO任務(wù)調(diào)度機制進行比較，驗證方法的有效性。
[0052]本發(fā)明提供一種基于任務(wù)負載的數(shù)據(jù)迀移方法，本發(fā)明中數(shù)據(jù)的迀移過程采用了 MapReduce架構(gòu)，首先在數(shù)據(jù)源導(dǎo)入數(shù)據(jù)，生成對應(yīng)的運行類打包成jar包，傳遞給Hadoop平 臺存儲和處理。在這個過程中可以有效利用MapReduce的并行機制，同時利用基于任務(wù)負載 值的任務(wù)調(diào)度策略對數(shù)據(jù)迀移過程進行優(yōu)化，提高歉意效率。其中基于任務(wù)負載的任務(wù)調(diào) 度器運行原理就是根據(jù)每個節(jié)點的任務(wù)負載值 Pl，對集群中的個任務(wù)進行分配調(diào)度，這樣 可以有效減少任務(wù)等待時間，避免任務(wù)阻塞，從而提高任務(wù)處理效率，減少數(shù)據(jù)迀移的消耗 時長。
[0053]文中我們利用Hadoop架構(gòu)中的MapReduce框架完成對任務(wù)的分配和計算工作。在 執(zhí)行數(shù)據(jù)迀移操作前，我們首先要完成相關(guān)基本信息的配置，主要包含有，數(shù)據(jù)迀出的位置 信息(聲明數(shù)據(jù)源）、數(shù)據(jù)迀移目的地的地址信息、數(shù)據(jù)迀移過程中使用map的數(shù)量以及現(xiàn)有 分布式集群各個節(jié)點的服務(wù)器基本的配置情況等。完成基本的配置后，開始執(zhí)行數(shù)據(jù)迀移 操作。根據(jù)圖4與圖6我們對數(shù)據(jù)迀移的過程進行簡單描述：
[0054] ⑴設(shè)置參數(shù)。
[0055] 在應(yīng)用中，我們首先要對系統(tǒng)參數(shù)進行設(shè)置，主要包含以下信息：
[0056] ①解析關(guān)于任務(wù)執(zhí)行的系統(tǒng)預(yù)設(shè)信息:設(shè)置待迀移數(shù)據(jù)的基本信息以及數(shù)據(jù)迀移 中的數(shù)據(jù)信息，例如數(shù)據(jù)是否備份、數(shù)據(jù)的獲取路徑、數(shù)據(jù)的輸出路徑、數(shù)據(jù)的原始格式、數(shù) 據(jù)的輸出格式、對數(shù)據(jù)進行劃分和計算的Mapper類和Reducer類等。
[0057] ②設(shè)置數(shù)據(jù)源:解析等待迀移的數(shù)據(jù)目前的存儲的置，為數(shù)據(jù)迀移操作做準備。
[0058] ③設(shè)置數(shù)據(jù)的輸出路徑：就是將數(shù)據(jù)格式轉(zhuǎn)換后的輸出數(shù)據(jù)保存的位置，在大數(shù) 據(jù)平臺中可以是分布式文件系統(tǒng)或者是HBase、Hi Ve，在本文中我們設(shè)置的一個HBase表。 [0059]⑵在預(yù)設(shè)的數(shù)據(jù)源中獲取數(shù)據(jù)。
[0060]我們利用Java編程的方式，利用JDBC獲取預(yù)設(shè)的關(guān)系型數(shù)據(jù)庫中的數(shù)據(jù)源，獲取 后輸出的結(jié)果集是名為ResultSet的Java對象。
[0061]⑶數(shù)據(jù)由原來的格式轉(zhuǎn)換為大數(shù)據(jù)平臺可存儲的數(shù)據(jù)格式。
[0062]將ResultSet對象經(jīng)數(shù)據(jù)格式轉(zhuǎn)換成為鍵值對(Key/Value)的形式。
[0063] ⑷啟動MapReduce，利用MapReduce進行數(shù)據(jù)的劃分和計算，利用Map對任務(wù)進行分 配，下發(fā)至集群中的每個節(jié)點，利用Reduce進行計算，將最后的結(jié)果集寫入到目標地址，當(dāng) 所有數(shù)據(jù)完整的寫入到大數(shù)據(jù)平臺后，也就實現(xiàn)了關(guān)系型數(shù)據(jù)庫數(shù)據(jù)迀移至大數(shù)據(jù)平臺的 目的。具體過程如下：
[0064]執(zhí)行數(shù)據(jù)迀移操作后，首先利用MapReduce的map將數(shù)據(jù)劃分后分別分發(fā)至每個節(jié) 點的TaskTracker中，然后將數(shù)據(jù)寫入到用戶預(yù)設(shè)的HBase表中進行存儲。在執(zhí)行操作前的 配置中，我們需要對Map的數(shù)量進行設(shè)置，而在數(shù)據(jù)迀移前的數(shù)據(jù)分割會受到map數(shù)量的影 響，這也一定程度的對每個任務(wù)執(zhí)行的范圍產(chǎn)生了影響。當(dāng)檢測到TaskTracker有空閑的 Slot時，系統(tǒng)對其I/O資源占用情況進行檢測，若其資源占用較少，且該節(jié)點任務(wù)負載熵值 滿足預(yù)設(shè)的閾值時，JobTracker將自動將任務(wù)分配給該TaskTracker。反之，若發(fā)現(xiàn)此時該 節(jié)點的I/O資源被大量占用或者任務(wù)負載熵值較大，等待處理的任務(wù)較多，即使該 TaskTracker有空閑的Slot，為避免出現(xiàn)阻塞，從而影響數(shù)據(jù)迀移的效率，任務(wù)調(diào)度器也將 避免將任務(wù)分配給該節(jié)點。因此，系統(tǒng)利用基于任務(wù)負載的調(diào)度器，可以有效監(jiān)測識別系統(tǒng) 中每個TaskTracker的I/O占用率、CPU利用率、任務(wù)等待/阻塞等，從而進行優(yōu)化調(diào)度，提高 迀移系統(tǒng)的整體性能。
[0065] (5)數(shù)據(jù)寫入 HBase。
[0066]每個節(jié)點的TaskTracker對任務(wù)進行計算處理輸出數(shù)據(jù)，將讀取到的鍵值對數(shù)據(jù) 寫入HBase表。數(shù)據(jù)迀移過程的是隨著系統(tǒng)中Map任務(wù)全部結(jié)束而結(jié)束，反之，若數(shù)據(jù)迀移尚 未結(jié)束，則TaskTracker將繼續(xù)將任務(wù)分配給每個TaskTracker進行處理。
[0067] 根據(jù)本文中設(shè)計的基于ABC算法的任務(wù)調(diào)度，編寫了基于任務(wù)調(diào)度情況的調(diào)度器。 將系統(tǒng)文件m a p r e d - s i t e · X m 1中的相應(yīng)字段設(shè)置為任務(wù)調(diào)度器類 org.apache ?1^(1〇(^.1]^口代(1.1381^(3116(111161'，使得其可在后面的任務(wù)調(diào)度中被使用。實現(xiàn) 基于任務(wù)負載的任務(wù)調(diào)度器的過程，主要是對JobTracker中的AssignTask方法進行設(shè)計編 寫，這個方法的TaskTracker Status字段中包含有TaskTracker在Heartbeat (心跳信息）中 提交的相關(guān)信息，其中有MapSlot數(shù)量的最大值、ReduceSlot數(shù)量的最大值、虛擬內(nèi)存最大 值、物理內(nèi)存、剩余可用磁盤空間的大小、每個任務(wù)的執(zhí)行狀態(tài)、磁盤存取狀態(tài)。在以上數(shù)據(jù) 中，對任務(wù)處理影響較大的因素主要是剩余Slot數(shù)量、磁盤存取速率還有CPU的實時狀態(tài)。
[0068] 在對任務(wù)進行分配過程中，JobTracker利用TaskTracker通過Heartbeat (心跳信 息)發(fā)送得到的信息來判斷將任務(wù)分配給哪些節(jié)點，其中主要參數(shù)有Slot使用情況、磁盤存 取狀態(tài)、任務(wù)阻塞、等待狀態(tài)等。在數(shù)據(jù)迀移過程中，關(guān)于任務(wù)的調(diào)度情況可分為以下幾種： [0069]①如果節(jié)點的TaskTracker中所有的slot都已經(jīng)被占用，則任務(wù)調(diào)度器盡量避免 將新的任務(wù)分配至該TaskTracker。
[0070]②若TaskTracker上尚且存在空閑的Slot，貝lj需要對磁盤占用情況，任務(wù)等待情況 等進行監(jiān)測判斷：
[0071] a).若當(dāng)前節(jié)點負載任務(wù)情況，依據(jù)任務(wù)負載均衡評測模型計算得到的Pl值高于 平均值?，則不將新任務(wù)分配給該節(jié)點。
[0072] b). 1若當(dāng)前節(jié)點負載情況，依據(jù)任務(wù)負載均衡評測模型計算得到的Pl值低于平均 值《，則該節(jié)點可以接受新任務(wù)。
[0073] 具體實例如下所述的基于任務(wù)調(diào)度優(yōu)化的數(shù)據(jù)迀移方法數(shù)據(jù)測試與結(jié)果分析：
[0074] 根據(jù)預(yù)設(shè)，我們對基于任務(wù)調(diào)度的數(shù)據(jù)迀移進行數(shù)據(jù)測試，與此同時，在同樣條件 下對Hadoop默認FIFO調(diào)度器進行相同數(shù)據(jù)量的測試。將兩者得到的最終結(jié)果進行分析比 較。
[0075] 在實驗過程中，我們分七種數(shù)據(jù)量進行測試，每沒組數(shù)據(jù)進行六次實驗，最后利用 六次實驗中的平均值作為比較值，這樣是為了保證數(shù)據(jù)的準確性。
[0076]基于系統(tǒng)默認FIFO調(diào)度器的數(shù)據(jù)測試結(jié)果，如下表所示：
[0077] 表1 FIFO調(diào)度器
[0080]對基于ABC算法的Hadoop任務(wù)調(diào)度器的設(shè)計進行數(shù)據(jù)迀移的性能測試，測試結(jié)果 如表2所示：
[0081 ] 表2基于ABC算法的Hadoop任務(wù)調(diào)度器
[0083] 對表1和表2實驗中平均時間數(shù)據(jù)進行對比，如圖5所示。
[0084] 根據(jù)表1和表2,我們首先對測試數(shù)據(jù)進行簡單分析，為了保證數(shù)據(jù)的可靠性和準 確率我們只對測試數(shù)據(jù)的平均值進行對比分析。當(dāng)數(shù)據(jù)量為31250時，使用系統(tǒng)默認調(diào)度器 進行數(shù)據(jù)迀移消耗時長比后者少；當(dāng)數(shù)據(jù)量為62500和125000時，雖然六次測試中各不相 同，且個別情況下差距也比較大，但是取平均值后連著消耗時間相近；當(dāng)數(shù)據(jù)量達到25000、 500000直到2000000時，基于ABC算法的任務(wù)調(diào)度器比FIFO調(diào)度器消耗時間更少，并且隨著 數(shù)據(jù)量的不斷增加，兩者消耗時間的差值依次是2，1，5,11。另外根據(jù)圖5,可以很明顯的看 出，在數(shù)據(jù)量高于1000000條時，圖像中紅色線條明顯高于藍色線條。于是我們可以總結(jié)為， 當(dāng)數(shù)據(jù)量逐漸增加時，在相等條件下，基于ABC算法的任務(wù)調(diào)度器效率越來越高，所消耗時 間越來越少，數(shù)據(jù)迀移效率越來越高。
[0085] 除了對不同數(shù)據(jù)量進行數(shù)據(jù)迀移的差別之外，我們還對數(shù)據(jù)迀移過程中分配不同 的map數(shù)量進行了測試。Hadooop提供一個參數(shù)mapred · map · tasks，該參數(shù)可用于設(shè)置map個 數(shù)，因此我們可以通過這個參數(shù)來控制map的數(shù)量。不過，通過這種方式設(shè)置map的個數(shù)，并 不是每次都有效的。主要原因在于mapred · map · tasks只是一個hadoop中map個數(shù)的參考數(shù) 值，最終map的個數(shù)，還取決于其他的因素。
[0086]假設(shè)Map啟用的數(shù)量為Μ(個），效率的度量數(shù)值為時間T(s)，數(shù)據(jù)處理的效率為P (條/s)。為保證數(shù)據(jù)的可靠性和準確率，我們使用同一個數(shù)據(jù)表進行多次測試，每次測試設(shè) 置的map數(shù)量不同，已知數(shù)據(jù)表中的數(shù)據(jù)量是2000000條。
[0087]在進行數(shù)據(jù)測試的過程中，我們分別啟動1，2,4,6,8個map函數(shù)，依據(jù)每種map數(shù) 量，將相同的數(shù)據(jù)表由MySQL數(shù)據(jù)庫迀移至HBase中。測試數(shù)據(jù)如下表3所示：
[0088] 表3不同map的數(shù)據(jù)迀移時間和效率
[0090]根據(jù)以上數(shù)據(jù)我們得到Map的數(shù)量與數(shù)據(jù)迀移效率的關(guān)系圖像，如圖6。
[0091]根據(jù)表3和圖6,我們首先對map數(shù)量測試所得到的數(shù)據(jù)進行分析，當(dāng)map數(shù)量為1 時，用時最長，這是由于map階段負責(zé)對輸入文件進行切分處理，map數(shù)量太少，用時必定較 多；當(dāng)map怎的數(shù)量增加到2個到4個的過程中，效率逐漸得到有效提高，用時越來越短；當(dāng) map數(shù)量為6時，雖然map數(shù)量增加了但是數(shù)據(jù)迀移的效率反而下降了，造成這種結(jié)果得主要 原因是當(dāng)調(diào)用map函數(shù)時，由于每個節(jié)點的任務(wù)情況不同，且任務(wù)處理實時變化，map將會在 在各個節(jié)點之間進項調(diào)度使用，這樣會增大系統(tǒng)資源的消耗，由于map函數(shù)的調(diào)用并占用一 部分系統(tǒng)資源，導(dǎo)致任務(wù)處理效率不增反減。
[0092]根據(jù)測試數(shù)據(jù)我們可以得出以下結(jié)論：
[0093]⑴數(shù)據(jù)量和數(shù)據(jù)迀移時間并不是線性關(guān)系，數(shù)據(jù)量成倍數(shù)增加時迀移的時間并不 是按照對應(yīng)的倍數(shù)增長，即數(shù)據(jù)迀移的時間和數(shù)據(jù)迀移的數(shù)據(jù)量不成正比。針對這種結(jié)果， 我們進行如下分析，出現(xiàn)這種結(jié)果得主要原因在于在啟動MapReduce過程中，同時啟動的還 有Job，而Job準備工作將會消耗一部分時間，占用一部分系統(tǒng)資源。因而，對于Hadoop默認 調(diào)度器和文中基于ABC算法設(shè)計任務(wù)調(diào)度過程，其數(shù)據(jù)迀移消耗的時長與迀移數(shù)據(jù)量之間 不會出現(xiàn)按照線性增長的情況。
[0094] ⑵根據(jù)實驗數(shù)據(jù)中我們可以看出，數(shù)據(jù)量相對較少時，兩種調(diào)度器在處理相同任 務(wù)是所消耗的時間大致相同，但是在數(shù)據(jù)量不斷增長的過程中，在不考慮其他因素的影響 情況下，基于任務(wù)調(diào)度的調(diào)度器的性能比FIFO調(diào)度器更好。與此同時，也體現(xiàn)出了當(dāng)任務(wù)較 密集情況下，由于不同節(jié)點服務(wù)器處理任務(wù)的能力有差異，所以任務(wù)調(diào)度器將會優(yōu)先將任 務(wù)分派給任務(wù)負載值較低的節(jié)點進行處理，減少任務(wù)等待時間，避免阻塞，從而使得數(shù)據(jù)迀 移效率得到提高。
[0095] ⑶在對任務(wù)進行處理中，設(shè)置的map個數(shù)越接近節(jié)點數(shù)量，數(shù)據(jù)迀移的效率越高， 出現(xiàn)這種結(jié)果得原因在于數(shù)量合理的情況下，可以有效利用存儲系統(tǒng)存取速率和集群網(wǎng)絡(luò) 帶寬。
[0096]⑷在實際應(yīng)用中，并不是map使用數(shù)量越多越好，當(dāng)map數(shù)量過多時，map在系統(tǒng)中 的調(diào)用也會占用系統(tǒng)資源和網(wǎng)絡(luò)資源，從而造成數(shù)據(jù)迀移所占資源減少，迀移效率降低。 [0097]有上述結(jié)論可知，當(dāng)集群對任務(wù)處理過程中，選擇對任務(wù)調(diào)度的優(yōu)化及系統(tǒng)參數(shù) 的正確配置都會對任務(wù)的執(zhí)行效率產(chǎn)生影響。
[0098]本發(fā)明基于MapReduce架構(gòu)，對任務(wù)調(diào)度器進行了優(yōu)化改進，只是將任務(wù)依據(jù)不同 節(jié)點任務(wù)的可負載量分配到實時任務(wù)負載較小的TaskTracker上執(zhí)行，對任務(wù)較密集的作 業(yè)性能提升較為明顯，但是對于任務(wù)密集較小的作業(yè)，效果不明顯且會在使用過程中占用 一部分系統(tǒng)資源，影響系統(tǒng)性能，而在未來的研究中，可以根據(jù)各節(jié)點CPU利用率、數(shù)據(jù)吞吐 率、內(nèi)存異構(gòu)等因素，提高系統(tǒng)對于任務(wù)密集型、數(shù)據(jù)密集型的數(shù)據(jù)迀移作業(yè)的迀移效率。
[0099]上述【具體實施方式】僅是本發(fā)明的具體個案，本發(fā)明的專利保護范圍包括但不限于 上述【具體實施方式】，任何符合本發(fā)明的一種基于任務(wù)負載的數(shù)據(jù)迀移方法的權(quán)利要求書的 且任何所述技術(shù)領(lǐng)域的普通技術(shù)人員對其所做的適當(dāng)變化或替換，皆應(yīng)落入本發(fā)明的專利 保護范圍。
【主權(quán)項】
1. 一種基于任務(wù)負載的數(shù)據(jù)遷移方法，其特征在于，其實現(xiàn)過程為，在關(guān)系型數(shù)據(jù)庫中 抽取數(shù)據(jù)，并對數(shù)據(jù)進行格式轉(zhuǎn)換;開始執(zhí)行數(shù)據(jù)遷移，該數(shù)據(jù)遷移過程采用MapReduce架 構(gòu)，具體遷移過程為：首先在數(shù)據(jù)源導(dǎo)入數(shù)據(jù)，生成對應(yīng)的運行類打包成jar包，傳遞給 化doop平臺存儲和處理。2. 根據(jù)權(quán)利要求1所述的一種基于任務(wù)負載的數(shù)據(jù)遷移方法，其特征在于，在執(zhí)行數(shù)據(jù) 遷移操作前，首先要完成相關(guān)基本信息的配置，該相關(guān)基本信息包括，數(shù)據(jù)遷出的位置信 息、數(shù)據(jù)遷移目的地的地址信息、數(shù)據(jù)遷移過程中使用map的數(shù)量W及現(xiàn)有分布式集群各個 節(jié)點的服務(wù)器基本的配置情況，完成基本的配置后，開始執(zhí)行數(shù)據(jù)遷移操作。3. 根據(jù)權(quán)利要求1所述的一種基于任務(wù)負載的數(shù)據(jù)遷移方法，其特征在于，所述數(shù)據(jù)遷 移的具體過程為： 步驟一、首先設(shè)置參數(shù)，解析任務(wù)執(zhí)行的預(yù)設(shè)信息并設(shè)置數(shù)據(jù)源和數(shù)據(jù)輸出路徑； 步驟二、在預(yù)設(shè)的數(shù)據(jù)源中獲取數(shù)據(jù)； 步驟Ξ、轉(zhuǎn)換數(shù)據(jù)格式，即將數(shù)據(jù)由原來的格式轉(zhuǎn)換為大數(shù)據(jù)平臺可存儲的數(shù)據(jù)格式； 步驟四、對數(shù)據(jù)進行劃分分配，下發(fā)至集群中的每個節(jié)點； 步驟五、最后將數(shù)據(jù)寫入到對應(yīng)的輸出路徑中。4. 根據(jù)權(quán)利要求3所述的一種基于任務(wù)負載的數(shù)據(jù)遷移方法，其特征在于，所述步驟一 的具體實現(xiàn)過程為： 首先解析關(guān)于任務(wù)執(zhí)行的系統(tǒng)預(yù)設(shè)信息，即設(shè)置待遷移數(shù)據(jù)的基本信息W及數(shù)據(jù)遷移 中的數(shù)據(jù)信息，該系統(tǒng)預(yù)設(shè)信息包括數(shù)據(jù)是否備份、數(shù)據(jù)的獲取路徑、數(shù)據(jù)的輸出路徑、數(shù) 據(jù)的原始格式、數(shù)據(jù)的輸出格式、對數(shù)據(jù)進行劃分和計算的Mapper類和Reducer類； 然后設(shè)置數(shù)據(jù)源，即解析等待遷移的數(shù)據(jù)目前的存儲的置，為數(shù)據(jù)遷移操作做準備； 最后設(shè)置數(shù)據(jù)的輸出路徑，即將數(shù)據(jù)格式轉(zhuǎn)換后的輸出數(shù)據(jù)保存的位置，該數(shù)據(jù)的輸 出路徑采用皿ase表。5. 根據(jù)權(quán)利要求3所述的一種基于任務(wù)負載的數(shù)據(jù)遷移方法，其特征在于，所述步驟二 在預(yù)設(shè)的數(shù)據(jù)源中獲取數(shù)據(jù)的具體過程為:通過化va編程的方式，利用JDBC獲取預(yù)設(shè)的關(guān) 系型數(shù)據(jù)庫中的數(shù)據(jù)源，獲取后輸出的結(jié)果集是名為ResultSet的化va對象，相對應(yīng)的，步 驟Ξ中的轉(zhuǎn)換數(shù)據(jù)格式是指將ResultSet對象經(jīng)數(shù)據(jù)格式轉(zhuǎn)換成為鍵值對Key/Value的形 式。6. 根據(jù)權(quán)利要求3所述的一種基于任務(wù)負載的數(shù)據(jù)遷移方法，其特征在于，所述步驟四 數(shù)據(jù)劃分及下發(fā)相關(guān)數(shù)據(jù)的過程為：啟動MapReduce,通過MapReduce進行數(shù)據(jù)的劃分和計 算，然后通過Map對任務(wù)進行分配，下發(fā)至集群中的每個節(jié)點，最后通過Reduce進行計算，將 最后的結(jié)果集寫入到目標地址，當(dāng)所有數(shù)據(jù)完整的寫入到大數(shù)據(jù)平臺后，實現(xiàn)關(guān)系型數(shù)據(jù) 庫數(shù)據(jù)遷移至大數(shù)據(jù)平臺的目的。7. 根據(jù)權(quán)利要求6所述的一種基于任務(wù)負載的數(shù)據(jù)遷移方法，其特征在于，所述步驟四 的具體實現(xiàn)過程為： 在數(shù)據(jù)劃分及下發(fā)相關(guān)數(shù)據(jù)的過程中，通過MapReduce的map將任務(wù)分配到各個節(jié)點中 進行處理，即將數(shù)據(jù)劃分后分別分發(fā)至每個節(jié)點的化skTracker中，然后把數(shù)據(jù)寫入到用戶 預(yù)設(shè)的皿ase表中進行存儲； 其中通過Map對任務(wù)進行分配，下發(fā)至集群中的每個節(jié)點的具體過程為：當(dāng)檢測到 TaskTracker有空閑的Slot時，系統(tǒng)對其I/O資源占用情況進行檢測，若該節(jié)點的I/O資源占 用為所有節(jié)點中最少，且該節(jié)點任務(wù)負載賭值滿足預(yù)設(shè)的闊值時，Jobhacker將自動將任 務(wù)分配給該化sk化acker;反之，若發(fā)現(xiàn)此時該節(jié)點的I/O資源被大量占用或者任務(wù)負載賭 值較大，等待處理的任務(wù)較多，則不將任務(wù)分配給該節(jié)點。8. 根據(jù)權(quán)利要求7所述的一種基于任務(wù)負載的數(shù)據(jù)遷移方法，其特征在于，上述任務(wù)分 配通過任務(wù)調(diào)度器完成，該任務(wù)調(diào)度器的具體操作過程為： 首先將系統(tǒng)文件mapred-site . xml中的相應(yīng)字段設(shè)置為任務(wù)調(diào)度器類 org. apache. hadoop. mapred. TaskScheduler，使得其可在后面的任務(wù)調(diào)度中被使用； 然后實現(xiàn)基于任務(wù)負載的任務(wù)調(diào)度器的過程，對化bTracker中的Assign化sk方法進行 設(shè)計編寫，運個方法的TaskTrackerStatus字段中包含有TaskTracker在屯、跳信息 Hea;rtbeat中提交的相關(guān)信息，該相關(guān)信息包括MapSlot數(shù)量的最大值、ReduceSlot數(shù)量的 最大值、虛擬內(nèi)存最大值、物理內(nèi)存、剩余可用磁盤空間的大小、每個任務(wù)的執(zhí)行狀態(tài)、磁盤 存取狀態(tài)、剩余Slot數(shù)量、磁盤存取速率、CPU的實時狀態(tài)； 在對任務(wù)進行分配過程中，JobTracker利用化skTracker通過屯、跳信息化artbeat發(fā)送 得到的信息來判斷將任務(wù)分配給哪些節(jié)點，其中主要參數(shù)有Slot使用情況、磁盤存取狀態(tài)、 任務(wù)阻塞、等待狀態(tài)。9. 根據(jù)權(quán)利要求8所述的一種基于任務(wù)負載的數(shù)據(jù)遷移方法，其特征在于，基于上述任 務(wù)調(diào)度器，具體的任務(wù)調(diào)度情況為： 如果節(jié)點的化sk化acker中所有的slot都已經(jīng)被占用，則任務(wù)調(diào)度器則拒絕將新的任 務(wù)分配至該TaskTracker; 若化sk化acker上尚且存在空閑的Slot,則需要對磁盤占用情況，任務(wù)等待情況等進行 監(jiān)測判斷： a) .若當(dāng)前節(jié)點負載任務(wù)情況，依據(jù)任務(wù)負載均衡評測模型計算得到的Pi值高于平均值 ，則不將新任務(wù)分配給該節(jié)點； b) . 1若當(dāng)前節(jié)點負載情況，依據(jù)任務(wù)負載均衡評測模型計算得到的Pi值低于平均值；， 則該節(jié)點可W接受新任務(wù)。10. 根據(jù)權(quán)利要求3所述的一種基于任務(wù)負載的數(shù)據(jù)遷移方法，其特征在于，所述步驟 五中將數(shù)據(jù)寫入皿ase的具體過程為:每個節(jié)點的化sMYacker對任務(wù)進行計算處理輸出數(shù) 據(jù)，將讀取到的鍵值對數(shù)據(jù)寫入皿ase表;數(shù)據(jù)遷移過程隨著系統(tǒng)中Map任務(wù)全部結(jié)束而結(jié) 束，反之，若數(shù)據(jù)遷移尚未結(jié)束，則TaskTracker將繼續(xù)將任務(wù)分配給每個化sk化acker進行 處理。
【文檔編號】G06F17/30GK106095940SQ201610415905
【公開日】2016年11月9日
【申請日】2016年6月14日 公開號201610415905.4, CN 106095940 A, CN 106095940A, CN 201610415905, CN-A-106095940, CN106095940 A, CN106095940A, CN201610415905, CN201610415905.4
【發(fā)明人】耿玉水, 孫濤, 袁家恒, 姜雪松
【申請人】齊魯工業(yè)大學(xué)