一種基於Hadoop架構的移動終端雲資源調度方法與流程

2023-06-20 10:34:41 2

本發明涉及雲計算平臺中的數據資源，特別是涉及一種基於Hadoop架構的移動終端雲資源調度方法。

背景技術：
移動網際網路和雲計算優勢互補，雲計算正從網際網路逐漸過渡到移動網際網路。移動終端設備由於受限於體積和便攜性的要求，短時間內數據處理能力難以和計算機相比，因此雲計算的特點更能在移動網際網路上充分體現，弱化了對移動終端設備的處理需求。移動雲計算具有計算量小、請求並發性高、用戶實時性要求高的特點，在任務的執行過程中，計算節點與數據間的距離是影響響應時間的重要因素，數據在網絡中的傳輸將嚴重影響系統的實時性、降低用戶體驗。如果數據副本剛好存放在計算節點上，那麼將大大降低請求的響應時間，由此可見，在移動雲計算中，對數據本地化的需求要遠大於傳統意義上的雲計算。Hadoop是一個實現了谷歌雲計算系統的分布式開源框架，包含豐富的分布式與並行計算的相關構件。隨著雲計算的應用和推廣，越來越多諸如微軟、亞馬遜等網際網路行業巨頭都參與到雲計算的研究和開發中，並使用Hadoop實現了自己的雲計算平臺。HDFS（HadoopDistributedFileSystem）是一個以流式數據訪問模式存儲超大文件的分布式文件系統，實現了文件的分布式存儲。它採用流式方式訪問數據集，能夠實現高吞吐量的數據訪問，適用於大規模數據集，高容錯性、高伸縮性的特點使得用戶可以使用廉價的硬體設備搭建穩定可靠的分布式平臺。HDFS由伺服器集群組成，並採用主/從體系架構，集群中包括一個主節點NameNode和若干個從節點DataNode，其中主節點NameNode負責管理文件系統的命名空間和客戶端對文件的訪問，從節點DataNode負責具體的存儲、計算以及對自身附帶存儲資源的管理，並定期通過「心跳」信息向主節點NameNode發送自身狀態，HDFS的結構示意圖如圖1所示。在HDFS內部以「塊」為單位進行存儲，默認塊大小為64MB。通常一個文件被分割為一個或多個數據塊，由NameNode將其分散存儲在不同的DataNode上，並在NameNode的控制下通過DataNode之間的互相複製而具有多個備份，以保證文件系統的高可靠性。DataNode在啟動系統時會自動創建自身所存儲的各個文件數據塊的位置信息，並交由NameNode保存直到系統關閉。MapReduce是一種雲計算的核心計算模式、分布式運算技術，也是簡化的分布式編程模式。Hadoop平臺下的作業請求都作為MapReduce過程進行，稱為一個MapReduce作業，每個作業可分為若干個Map任務和Reduce任務。請求調度方法，就是MapReduce編程模型中的作業調度方法，是MapReduce主節點對Map和Reduce任務的調度。調度方法是一個集群的核心，是影響系統性能、整個集群利用率和吞吐率的關鍵因素。MapReduce採用了主/從式結構實現，MapReduce由一個主節點JobTracker和若干個從節點TaskTracker組成。主節點JobTracker負責管理和調度所有作業請求和從節點TaskTracker，它是整個系統分配任務的核心。從節點TaskTracker負責執行作業的具體任務操作，並定期通過「心跳」信息向主節點JobTracker報告任務的執行狀態。主節點JobTracker可以運行在集群中的任何一臺計算機上，而從節點TaskTracker只能運行在從節點DataNode上，即計算節點一定是數據存儲節點，這種配置使得任務有可能在已經存放所需數據的節點上執行，從而有效減少了整個集群帶寬的佔用率。以Hadoop分布式文件系統（HDFS，HadoopDistributedFileSystem）和MapReduce（谷歌MapReduce的開源實現）為核心的Hadoop為用戶提供了系統底層細節透明的分布式基礎架構。MapReduce和HDFS的主節點均設在同一個管理節點上，其餘從節點設在工作節點上。管理節點通過控制指令管理工作節點，工作節點通過心跳信息返回狀態信息。主節點JobTracker啟動調度器，讀取各工作節點任務隊列，根據調度方法為從節點TaskTracker分配任務。HDFS和MapReduce共同組成了Hadoop分布式系統體系結構的核心。HDFS在集群上實現分布式文件系統，MapReduce在集群上實現了分布式計算和任務處理。HDFS在MapReduce任務處理過程中提供了文件操作和存儲等支持，MapReduce在HDFS的基礎上實現了任務的分發、跟蹤、執行等工作，並收集結果，二者相互作用，完成了Hadoop分布式集群的主要任務。MapReduce默認使用簡單的帶有優先級的先進先出調度方法，它將所有用戶的作業請求放入一個隊列中，由MapReduce主節點按照作業的優先級順序和提交時間順序掃描整個隊列，從中選擇優先級高且先提交的作業進行調度。該方法忽略了作業之間的需求差異，在存在大作業的情況下，將導致其他作業長時間得不到資源，嚴重影響系統性能。為了克服先進先出調度方法的缺點，滿足各種複雜的作業調度，又有一些複雜的調度方法以插件的形式集成到MapReduce中，其中使用較多的是計算能力調度方法和公平調度方法。計算能力調度方法的主要設計思想是優先調度所得資源佔應得資源的比值較小的隊列，即根據隊列中正在運行作業數與應得計算資源之間的比值進行調度，隊列內部使用先進先出調度方法。該方法為不同用戶定義多個隊列，作業請求放在提交作業的用戶對應的隊列中，並按照配置文件為每個隊列分配應得的計算資源量。隊列中同一用戶的作業使用隊列資源的百分比進行強制限定，不能出現獨佔隊列資源的情況。該方法不支持優先級搶佔，一旦作業開始執行，作業所使用資源將不會被搶佔。公平調度方法的主要設計目的是隨著時間的推移，保證所有作業都能平均的獲得等份額的共享資源。當只有一個作業在運行時，它將獲得整個集群資源，一旦有其他作業提交時，系統會將空閒資源分配給新的作業，以保證每個作業獲得大體相同的資源量。該方法默認為每個用戶定義一個資源池，並把資源公平的分配給每個資源池，作業請求放在提交作業的用戶自己的資源池中，資源池內部各個作業平分共享資源，並支持先進先出和公平調度兩種調度方法。資源池或作業也可以通過設置權重的方式按比例共享資源，當資源池不完全需要所分配的資源時，空閒的資源將在其他資源池之間按照權重按比例進行分配。這種設計有效的保證了在存在大作業的情況下，其他作業能夠在合理的時間內完成，同時大作業也能獲取到一定數量的資源。除此之外，該方法還提供資源池最小共享資源保證和資源池並發運行作業數量限制，設置最小共享量可以保證特定的用戶或應用程式總能夠獲取到足夠的資源，而資源池並發量限制能夠防止大量作業並發執行時產生的中間數據佔滿磁碟空間，超出限制的作業將在調度隊列中等待。調度器會周期性的對作業進行排序，一旦出現空閒資源，調度器會按順序調度作業。其中尚未獲得最小共享量的資源池中的作業最先被調度，然後根據作業應得資源量與實際獲得資源量之間的差值，按照從大到小的順序進行調度。綜上所述，現有的調度方法雖然也將數據本地化作為調度方法的重要參考指標，但同時為了兼顧資源在大作業與小作業間分配的公平性，降低了對數據本地化的要求。因此，它們並不適用於大量小作業請求、實時性要求較高的移動雲計算資源調度。

技術實現要素：
本發明針對上述現有技術中存在的問題，提供一種基於Hadoop架構的移動終端雲資源調度方法，所述方法包括以下步驟：步驟（1）：Hadoop集群的搭建。步驟（1.1）：選擇多臺計算機，每臺計算機作為一個單獨的節點，任意選擇其中一臺計算機作為管理節點，其他節點為工作節點；節點之間通過網絡連接，互相可以ping通；步驟（1.2）：在所有節點安裝Linux系統，並根據安裝過程中的提示給工作節點設置相同的的帳號和密碼；步驟（1.3）：在所有節點安裝Java開發包，並對環境變量進行配置；步驟（1.4）：在所有節點安裝SSH服務，通過在Linux系統中的終端窗口中輸入ssh-keygen命令，在管理節點上生成密鑰對，將公鑰複製到所有工作節點上，並追加到authorized_keys文件中；步驟（1.5）：下載hadoop壓縮包，將Hadoop解壓到各節點用戶帳號的個人目錄下；根據系統環境，在hadoop的conf目錄中，對Hadoop的JAVA_HOME環境變量、HADOOP_HOME變量、管理節點IP位址、工作節點IP位址、HDFS和MapReduce的埠號以及文件系統目錄進行配置。步驟（1.6）：將配置好的Hadoop複製到各個節點上，在Linux系統中的終端窗口中輸入hadoopnamenode-format命令，格式化HDFS集群中的NameNode。步驟（2）：調度方法的實現。步驟(2.1):啟動雲平臺。在管理節點的Linux系統中的終端窗口中輸入start-all.sh命令，Hadoop程序通過配置文件找到各工作節點ip地址，並啟動可以連接到的工作節點，從而啟動雲平臺。步驟(2.2):作業的提交。步驟（2.2.1）：客戶端運行一個作業，向JobTracker申請一個新的作業ID；步驟（2.2.2）：檢查作業的輸出說明，如果沒有指定輸出目錄或輸出目錄已經存在，作業就不提交；根據輸入路徑和Hadoop配置文件中設置的HDFS塊大小計算輸入數據的分片；步驟（2.2.3）：把運行作業所需的資源複製到JobTracker文件系統中的一個以作業ID命名的目錄下；步驟（2.3）：作業的初始化。步驟（2.3.1）：JobTracker接收到作業後，將其放在一個作業隊列裡，等待作業調度器對其進行調度，JobTracker使用帶有優先級的先進先出調度方法，按照作業的優先級順序和提交時間順序，選擇優先級高且先提交的作業進行調度；步驟（2.3.2）：當作業調度器根據自己的調度方法調度到該作業時，會根據輸入分片信息，從文件系統中獲取數據，為每個分片創建一個map任務，創建reduce任務的數量由集群配置決定，並將map任務分配給TaskTracker執行。對於map和reduce任務，TaskTracker根據主機核的數量和內存的大小有固定數量的map任務槽和reduce任務槽。步驟(2.4):任務的分配。步驟（2.4.1）：JobTracker根據任務所需數據副本的位置，將任務分配到數據副本所在的節點隊列中，其流程示意圖如圖2所示。步驟（2.4.2）：由於數據存在多個副本，這些數據副本在不同節點上，為了避免多個節點調度同一個任務，JobTracker為每個任務設置標誌位，用於標識任務是否已被調度，並在程序中使用同步塊的方法保證對標誌位寫操作的互斥性；步驟（2.4.3）：JobTracker節點發現某一工作節點有空閒任務槽時，首先遍歷該節點任務隊列，找到第一個未被調度的任務，將該任務分配給該節點的空閒任務槽執行，同時將該任務所有任務副本的已調度標誌位設置為已調度，其流程示意圖如圖3所示。步驟(2.5):任務的執行。步驟（2.5.1）：TaskTracker接收到新的任務後，將任務在所有副本節點的任務隊列中的位置與等待長度閾值做比較，如果任務在所有副本節點的任務隊列中的位置均大於等待長度閾值，則認為產生了熱點數據，對任務進行本機架內更換任務隊列操作；步驟（2.5.2）：步驟（2.5.1）中所述的熱點數據問題的判斷過程如圖4所示，將子任務所需數據的所有副本所在工作節點隊列存放在列表中後，遍歷該列表，將該子任務加入到列表內的每一個工作節點隊列中，並判斷該任務副本在隊列中的位置是否大於等待長度閾值，若大於則計數器加1，結束遍歷後，判斷計數器是否等於列表長度，若等於則說明該子任務所有任務副本在隊列中的位置均大於等待長度閾值，即說明發現熱點數據；步驟（2.5.3）：步驟（2.5.1）中所述的本機架內更換任務隊列操作的步驟如圖5所示，任務所需數據的副本存在多個，所有副本所在工作節點存放在一個列表中，首先遍歷這個列表，對於每一個工作節點，找到其所在機架，在機架內按各工作節點的任務隊列長度由小到大進行排序，然後選出任務隊列長度最小的節點，並判斷該節點任務隊列的長度是否已超過等待長度閾值；若沒有則將任務從副本節點任務隊列中移出，加入該節點的任務隊列中，否則任務仍然在原副本節點任務隊列中等待調度；步驟（2.5.4）：步驟（2.5.1）中所述的等待長度閾值的計算公式如下：p*T=d/s。其中，等待長度閾值為T，平均每個任務執行的實際時間為p秒，系統數據塊大小為d兆字節，網絡傳輸速度為s兆字節/秒；步驟（2.5.5）：TaskTracker接收到新的任務後，將應用程式所需要的全部文件從共享文件系統複製到本地磁碟新建的工作目錄中，工作流程示意圖如圖6所示。步驟（2.5.6）：TaskTracker啟動一個Java虛擬機執行任務，每隔幾秒TaskTracker就會將自身的工作狀態報告給JobTracker，JobTracker將收到的信息合併起來，並向用戶提供一個全局的作業及任務運行狀態的視圖。步驟（2.5.7）：在步驟（2.5.6）中，若特定的時間間隔內，JobTracker沒有收到TaskTracker的心跳信息，則認為該節點發生故障。步驟（2.5.8）：當執行任務節點發生故障時，管理節點將該節點正在執行的任務標誌位設置為未調度狀態，所有任務的副本任務的調度標誌位設置為未調度狀態，以便該任務在下次工作節點有空閒任務槽時被調度，節點故障流程圖如圖7所示。步驟(2.6):任務的完成。當JobTracker收到作業的所有任務成功完成的信息後，將執行結果返回給客戶端，並清空自身和TaskTracker上的作業工作狀態。本發明提出的基於Hadoop架構的移動終端雲資源調度方法，結合移動終端請求計算量小、並發性高、用戶實時性要求高的特點，大大提高了作業的本地化執行概率，在大量並發請求和發生熱點數據的情況下，能夠保持集群中各節點的負載均衡。附圖說明圖1是HDFS系統結構示意圖圖2是提交作業流程示意圖圖3是調度作業流程示意圖圖4熱點數據判斷流程示意圖圖5是更換任務隊列操作流程示意圖圖6是HDFS工作流程示意圖圖7是節點故障流程示意圖圖8是整體框架示意圖圖9是等待長度閾值T與作業規模G的關係圖圖10是不同調度方法的數據本地化執行概率圖11是各節點負載情況具體實施方式下面結合附圖和具體實施方式對本發明做進一步說明。步驟（1）：整體架構。本發明針對移動終端用戶設計，通過移動終端瀏覽器向雲計算平臺發送作業請求，雲平臺負責處理作業請求，並將請求結果通過移動終端瀏覽器響應給用戶。雲計算平臺基於Hadoop架構，並使用Hadoop的分布式文件系統HDFS（HadoopDistributedFileSystem），整體框架如圖8所示。雲計算平臺採用Master/Slave主/從體系架構，包括一個主節點JobTracker和若干個從節點TaskTracker，每個節點都是一臺計算機；JobTracker負責管理和調度所有作業請求和工作節點；TaskTracker負責執行作業的具體任務操作，並定期通過心跳信息向JobTracker節點報告任務的執行狀態。分布式文件系統HDFS採用Master/Slave主/從體系架構，包括一個主節點NameNode和多個從節點DataNode，每個節點都是一臺計算機；NameNode負責管理文件系統的命名空間和對文件的訪問；DataNode負責具體的存儲、計算以及對自身附帶資源的管理，並定期通過心跳信息向NameNode發送自身狀態信息。JobTracker可以運行在集群中的任何一臺計算機上，而所述TaskTracker只能運行在所述DataNode上。Hadoop集群中JobTracker和NameNode節點均設在同一個管理節點上，TaskTracker節點和DataNode節點設在工作節點上。管理節點通過控制指令管理工作節點，工作節點通過心跳信息返回狀態信息。JobTracker啟動調度器，讀取各TaskTracker節點任務隊列，根據帶有等待長度閾值的調度方法為TaskTracker分配任務。NameNode根據副本數量動態優化模型計算數據副本數量，並採用最遠節點選擇策略選擇DataNode存放數據副本。用戶使用移動終端連接網絡，並通過瀏覽器使用旅遊信息檢索服務。Web伺服器通過http接口接收用戶請求，並交給MapReduce進行處理。MapReduce訪問HDFS讀取所需數據，處理作業請求，並將結果通過http接口返回給移動終端。步驟（2）：Hadoop集群搭建。雲計算平臺使用6臺配置相同的計算機搭建一個小型的Hadoop集群，如圖8所示，每臺計算機作為一個單獨的節點，節點1為管理節點，其他節點為工作節點。將節點1、2、3連接到同一個路由器A下，組成集群中的機架A；節點4、5、6連接到另一個路由器B下，組成集群中的另一個機架B。兩個機架內使用同型號的百兆路由器，並將路由器A、B一起連接到同一個百兆交換機下。由於所有節點硬體配置相同，而機架B比機架A多一個工作節點，因此可以認為機架B的性能應優於機架A。各節點IP位址和角色分配情況如下表所示。本集群搭建在區域網環境中，各節點IP均為內網IP；若使用外網IP，只需在配置中修改節點IP位址，除有可能受實際網絡條件限制外，可以達到與本集群相同的效果。步驟（3）：Hadoop集群環境配置。Hadoop是為了在Linux平臺上使用而開發的，在Windows系統中Hadoop需要運行在Linux環境模擬器中，因此直接在集群中5個節點中安裝Linux的64位Fedora17版本。Hadoop系統中各節點需要擁有相同的目錄結構，因此為各節點配置相同的用戶帳號和密碼。由於Hadoop主體使用Java語言開發，首先需要在各節點中安裝jdk，並配置好環境變量，本集群使用jdk-7u9-linux-x64。Hadoop控制腳本依賴SSH服務來執行對整個集群的操作，如啟動或終止各工作節點的守護進程。為了支持無縫工作，需要實現Hadoop用戶無密碼登錄集群內各節點，最簡單的方法就是創建一個公鑰/私鑰對，並在整個集群間共享該密鑰對。因此在安裝SSH服務後，需要在管理節點上運行ssh-keygen命令生成RSA加密方法的密鑰文件，其中公鑰/私鑰文件名相似，但公鑰以「.pub」作為後綴。將公鑰複製給各TaskTracker節點，並追加到authorized_keys文件中，這樣便可實現JobTracker節點對各TaskTracker節點的無密碼登錄。本集群Hadoop版本為1.1.0，將Hadoop解壓到各節點用戶帳號的個人目錄下。首先根據系統環境對Hadoop進行必要的配置，包括JAVA_HOME環境變量和HADOOP_HOME變量、管理節點IP位址、工作節點IP位址、HDFS和MapReduce的埠號以及文件系統目錄。Hadoop的主要配置文件如下表所示，它們都存放在Hadoop的conf配置目錄中。最後將配置好的Hadoop複製到各個節點上，並使用hadoopnamenode-format命令格式化HDFS集群中的NameNode。完成以上工作後，便可以在管理節點上使用start-all.sh命令啟動Hadoop集群，並檢測集群是否正確運行。通過Hadoop預設的管理節點50070埠和50030埠可以分別查看NameNode和JobTracker的運行狀態。步驟（4）：調度方法的實現。步驟(4.1):啟動雲平臺。在管理節點的Linux系統中的終端窗口中輸入start-all.sh命令，Hadoop程序通過配置文件找到各工作節點ip地址，並啟動可以連接到的工作節點，從而啟動雲平臺。步驟(4.2):作業的提交。步驟（4.2.1）：客戶端運行一個作業，向JobTracker申請一個新的作業ID；步驟（4.2.2）：檢查作業的輸出說明，如果沒有指定輸出目錄或輸出目錄已經存在，作業就不提交；根據輸入路徑和Hadoop配置文件中設置的HDFS塊大小計算輸入數據的分片；步驟（4.2.3）：把運行作業所需的資源複製到JobTracker文件系統中的一個以作業ID命名的目錄下；步驟（4.3）：作業的初始化。步驟（4.3.1）：JobTracker接收到作業後，將其放在一個作業隊列裡，等待作業調度器對其進行調度，JobTracker使用帶有優先級的先進先出調度方法，按照作業的優先級順序和提交時間順序，選擇優先級高且先提交的作業進行調度；步驟（4.3.2）：當作業調度器根據自己的調度方法調度到該作業時，會根據輸入分片信息，從文件系統中獲取數據，為每個分片創建一個map任務，創建reduce任務的數量由集群配置決定，並將map任務分配給TaskTracker執行。對於map和reduce任務，TaskTracker根據主機核的數量和內存的大小有固定數量的map任務槽和reduce任務槽；步驟(4.4):任務的分配。步驟（4.4.1）：JobTracker根據任務所需數據副本的位置，將任務分配到數據副本所在的節點隊列中，其流程示意圖如圖2所示。步驟（4.4.2）：由於數據存在多個副本，這些數據副本在不同節點上，為了避免多個節點調度同一個任務，JobTracker為每個任務設置標誌位，用於標識任務是否已被調度，並在程序中使用同步塊的方法保證對標誌位寫操作的互斥性；步驟（4.4.3）：JobTracker節點發現某一工作節點有空閒任務槽時，首先遍歷該節點任務隊列，找到第一個未被調度的任務，將該任務分配給該節點的空閒任務槽執行，同時將該任務所有任務副本的已調度標誌位設置為已調度，其流程示意圖如圖3所示。步驟(4.5):任務的執行。步驟（4.5.1）：TaskTracker接收到新的任務後，將任務在所有副本節點的任務隊列中的位置與等待長度閾值做比較，如果任務在所有副本節點的任務隊列中的位置均大於等待長度閾值，則認為產生了熱點數據，對任務進行本機架內更換任務隊列操作；步驟（4.5.2）：步驟（4.5.1）中所述的熱點數據問題的判斷過程如圖4所示，將子任務所需數據的所有副本所在工作節點隊列存放在列表中後，遍歷該列表，將該子任務加入到列表內的每一個工作節點隊列中，並判斷該任務副本在隊列中的位置是否大於等待長度閾值，若大於則計數器加1，結束遍歷後，判斷計數器是否等於列表長度，若等於則說明該子任務所有任務副本在隊列中的位置均大於等待長度閾值，即說明發現熱點數據；步驟（4.5.3）：步驟（4.5.1）中所述的本機架內更換任務隊列操作的步驟如圖5所示，任務所需數據的副本存在多個，所有副本所在工作節點存放在一個列表中，首先遍歷這個列表，對於每一個工作節點，找到其所在機架，在機架內按各工作節點的任務隊列長度由小到大進行排序，然後選出任務隊列長度最小的節點，並判斷該節點任務隊列的長度是否已超過等待長度閾值；若沒有則將任務從副本節點任務隊列中移出，加入該節點的任務隊列中，否則任務仍然在原副本節點任務隊列中等待調度；步驟（4.5.4）：步驟（4.5.1）中所述的等待長度閾值的計算公式如下：p*T=d/s。其中，等待長度閾值為T，平均每個任務執行的實際時間為p秒，系統數據塊大小為d兆字節，網絡傳輸速度為s兆字節/秒；步驟（4.5.5）：TaskTracker接收到新的任務後，將應用程式所需要的全部文件從共享文件系統複製到本地磁碟新建的工作目錄中，工作流程示意圖如圖6所示。步驟（4.5.6）：TaskTracker啟動一個Java虛擬機執行任務，每隔幾秒TaskTracker就會將任務的當前狀態和執行進度報告給JobTracker，JobTracker將收到的信息合併起來，並向用戶提供一個全局的作業及任務運行狀態的視圖。步驟（4.5.7）：在步驟（4.5.6）中，若特定的時間間隔內，JobTracker沒有收到TaskTracker的心跳信息，則認為該節點發生故障。步驟（4.5.8）：當執行任務節點發生故障時，管理節點將該節點正在執行的任務標誌位設置為未調度狀態，所有任務的副本任務的調度標誌位設置為未調度狀態，以便該任務在下次工作節點有空閒任務槽時被調度，節點故障流程圖如圖7所示。步驟(4.6):任務的完成。當JobTracker收到作業的所有任務成功完成的信息後，將執行結果返回給客戶端，並清空自身和TaskTracker上的作業工作狀態。步驟（5）：應用效果展示。為了驗證本發明提出的移動終端雲資源調度方法的應用效果，將其應用到旅遊信息檢索系統中作為實驗組，同時引入兩個對照組進行實驗數據對比分析。對照組A使用Hadoop默認配置，對照組B在A組的基礎上配置公平調度器進行作業調度。實驗組和對照組均將HDFS的塊大小設置為32M，分別對各組系統寫入10個50M的文件，每個文件包含2個數據塊，工作節點數量為5。由於在通常的雲計算服務中，數據一旦寫入，用戶發送檢索請求均為讀數據操作，因此使用文本檢索進行系統性能測試。分別對各組系統連續發送相同的20個作業請求。由於集群中網絡傳輸速度約為10MB/s，數據塊大小為32M，則等待長度閾值T與任務平均執行時間p呈反比關係：T=3.2/P。若集群中各節點具有相同處理速率v時，等待長度閾值T與作業規模G呈反比關係：T=3.2v/G。當處理速率v分別為10MB/s、25MB/s和50MB/s時，等待長度閾值T與作業規模G的關係如圖9所示。當作業規模較小、計算量較少、作業平均執行時間較短時，各節點任務隊列允許較多作業等待本地化執行；當作業規模較大時，各節點任務隊列允許很少作業等待本地化執行，從而達到了根據作業規模，動態調整數據本地化執行這一因素的重要性。不同調度方法對於不同作業規模，數據本地化執行概率如圖10所示。由實驗結果可以看出，本發明提出的帶有等待長度閾值的調度方法在所有作業規模下幾乎都可以達到100%的數據本地化，而默認的先進先出調度方法和公平調度方法在數據本地化方面較差。為了進一步監控集群及其各節點的運行狀態，在實驗組Hadoop集群中搭建Ganglia分布式監控系統，驗證移動終端雲資源調度方法的應用效果。為了驗證移動終端雲資源調度方法對熱點數據現象的調整能力，連續發送20個所需數據相同的作業請求，人為製造熱點數據，此時各節點負載情況如圖11所示。圖11中橫軸表示時間，10:20以後為本次測試數據。其中節點1為管理節點，其餘為工作節點，因此節點1負載較低；而在節點2中運行了Ganglia系統的伺服器端程序，因此與其他工作節點相比節點2負載略高；其餘4個節點從10:20開始柱狀圖走勢相似，並且負載值大致相等，因此可以認為負載相對均衡。實驗結果表明，當作業請求並發數量較多時，系統各工作節點負載相對均衡；並且熱點數據的出現，並未破壞系統的負載均衡，從而驗證了該調度方法對熱點數據具有一定的自我調節能力。