寧菲菲，鄭均輝

基于Hadoop平臺(tái)的三隊(duì)列作業(yè)調(diào)度算法

寧菲菲，鄭均輝

針對(duì)Hadoop平臺(tái)的作業(yè)調(diào)度問題，提出支持作業(yè)優(yōu)先級(jí)、作業(yè)類型區(qū)分和資源搶占的三隊(duì)列作業(yè)調(diào)度算法（TJSA）。為更好地滿足用戶需求，通過設(shè)置作業(yè)優(yōu)先級(jí)細(xì)化作業(yè)差別，并按照優(yōu)先級(jí)的高低依次進(jìn)入等待隊(duì)列；進(jìn)而對(duì)作業(yè)類型進(jìn)行區(qū)分，設(shè)置CPU密集型作業(yè)隊(duì)列和I/O密集型作業(yè)隊(duì)列，以提高作業(yè)的并行執(zhí)行效率；當(dāng)隊(duì)列資源不足時(shí)可以基于節(jié)點(diǎn)特征對(duì)資源進(jìn)行回收，從而提高平臺(tái)的整體性能和節(jié)點(diǎn)資源利用率。實(shí)驗(yàn)結(jié)果表明：TJSA算法在作業(yè)運(yùn)行時(shí)間和集群運(yùn)行穩(wěn)定性上都表現(xiàn)出較好的性能。

Hadoop；作業(yè)調(diào)度；三隊(duì)列；作業(yè)優(yōu)先級(jí)；資源搶占

0 引言

Hadoop是Apache基金會(huì)開發(fā)的基于Google文件系統(tǒng)和 MapReduce分布式編程模型等核心技術(shù)的開源云計(jì)算平臺(tái)[1-2]，方便用戶在由大量廉價(jià)硬件設(shè)備組成的集群上運(yùn)行應(yīng)用程序、進(jìn)行大規(guī)模的數(shù)據(jù)處理。Hadoop具有低成本、高效率、高可靠性和較強(qiáng)的可伸縮性等優(yōu)點(diǎn)[3]。作為Hadoop領(lǐng)域的重點(diǎn)研究?jī)?nèi)容之一，作業(yè)調(diào)度技術(shù)主要負(fù)責(zé)管控作業(yè)的執(zhí)行順序和計(jì)算資源的分配。合適的作業(yè)調(diào)度算法能夠在滿足用戶作業(yè)請(qǐng)求的同時(shí)，有效提升Hadoop平臺(tái)的整體性能和系統(tǒng)資源利用率[4]。

Hadoop 中常見調(diào)度算法有先入先出（FIFO）算法、公平調(diào)度算法（Fair Scheduler）和計(jì)算能力調(diào)度算法（Capacity Scheduler）3種。Hadoop默認(rèn)采用的是支持優(yōu)先級(jí)的先入先出調(diào)度算法，算法簡(jiǎn)單易實(shí)現(xiàn)且開銷小，但不利于短作業(yè)的執(zhí)行、不支持共享集群和多用戶管理。由Facebook提出的公平調(diào)度算法充分考慮了不同用戶與作業(yè)的資源需求差異、支持用戶公平共享集群資源，但作業(yè)資源的配置策略不夠靈活容易造成資源浪費(fèi)并且不支持作業(yè)搶占。雅虎提出的計(jì)算能力調(diào)度算法支持多用戶共享多隊(duì)列、計(jì)算能力靈活，但不支持作業(yè)搶占且易陷入局部最優(yōu)。伴隨Hadoop的不斷發(fā)展和應(yīng)用，一些新的作業(yè)調(diào)度算法被提出。文獻(xiàn)[5]對(duì)延遲調(diào)度算法進(jìn)行改進(jìn)，提出延遲—容量調(diào)度算法，在解決數(shù)據(jù)本地化問題的同時(shí)提高了作業(yè)執(zhí)行的并行度。文獻(xiàn)[6]針對(duì)云計(jì)算集群中的資源異構(gòu)和節(jié)點(diǎn)穩(wěn)定性問題，利用統(tǒng)計(jì)方法提出一種資源調(diào)度算法，有效減少了作業(yè)的周轉(zhuǎn)時(shí)間，集群的整體性能得到提升。文獻(xiàn)[7]根據(jù)作業(yè)對(duì)CPU和I/O資源的使用情況進(jìn)行作業(yè)類型的劃分，提出了三隊(duì)列調(diào)度算法。

1 Hadoop作業(yè)調(diào)度

1.1 Hadoop集群框架模型

Hadoop集群框架遵循主從結(jié)構(gòu)，由1個(gè)JobTracker主節(jié)點(diǎn)和若干個(gè)TaskTracker從節(jié)點(diǎn)組成。JobTracker主節(jié)點(diǎn)負(fù)責(zé)作業(yè)調(diào)度、作業(yè)劃分、監(jiān)聽作業(yè)和任務(wù)運(yùn)行情況等。TaskTracker從節(jié)點(diǎn)主要負(fù)責(zé)執(zhí)行任務(wù)并報(bào)告資源占用情況與任務(wù)完成情況。TaskTracker通過心跳包向 JobTracker請(qǐng)求任務(wù)，在任務(wù)執(zhí)行過程中通過向JobTracker發(fā)送心跳信息，將任務(wù)的執(zhí)行情況和節(jié)點(diǎn)當(dāng)前的運(yùn)行狀態(tài)發(fā)送給JobTracker。

1.2 Hadoop作業(yè)執(zhí)行流程

來自客戶端（JobClient）的作業(yè)提交給集群主節(jié)點(diǎn)JobTracker。JobTracker通過執(zhí)行作業(yè)調(diào)度從中選擇一個(gè)作業(yè)作為待運(yùn)行作業(yè)，并將被選中的作業(yè)劃分為若干 Map任務(wù)與 Reduce任務(wù)[8]。從節(jié)點(diǎn) TaskTracker通過心跳包向JobTracker發(fā)送任務(wù)請(qǐng)求，JobTracker通過心跳包將任務(wù)分配到發(fā)送請(qǐng)求的從節(jié)點(diǎn) TaskTracker上去執(zhí)行。每個(gè)TaskTracker都擁有一定數(shù)量的資源槽（slot）用來執(zhí)行分配的任務(wù)。資源槽分為 Map槽和 Reduce槽，分別用于執(zhí)行Map任務(wù)和Reduce任務(wù)[9]。TaskTracker通過“心跳”程序向JobTracker告知資源槽的使用情況、任務(wù)的執(zhí)行情況。作業(yè)完成后，JobTracker將結(jié)果返回JobClient。MapReduce工作框架如圖1所示：

圖1 MapReduce工作框架

2 三隊(duì)列作業(yè)調(diào)度算法的設(shè)計(jì)

（1）作業(yè)優(yōu)先級(jí)

Hadoop上用戶數(shù)量龐大，為更好地滿足不同用戶的需求，提升服務(wù)滿意度，通過設(shè)置作業(yè)優(yōu)先級(jí)并進(jìn)行量化，以便細(xì)化作業(yè)差別。選取作業(yè)緊急度、作業(yè)長(zhǎng)度、等待因子和用戶身份4項(xiàng)指標(biāo)衡量作業(yè)優(yōu)先級(jí)。

a）作業(yè)緊急度emergency：按照作業(yè)的實(shí)時(shí)性要求，可以分為批處理作業(yè)、生產(chǎn)性作業(yè)和交互式作業(yè)。其中，交互式作業(yè)實(shí)時(shí)性要求最高，需要立即完成，因此，具有較高的緊急度，emergency取值為5；生產(chǎn)性作業(yè)實(shí)時(shí)性要求一般，緊急度emergency取值為3；批處理作業(yè)的實(shí)時(shí)性要求最低，故緊急度也最低，emergency取值為1。

b）作業(yè)長(zhǎng)度 length：根據(jù)作業(yè)所需執(zhí)行時(shí)間的長(zhǎng)度，將作業(yè)分為短作業(yè)與一般作業(yè)。短作業(yè)的length取值為1，一般作業(yè)的length取值為0。集群環(huán)境下作業(yè)執(zhí)行時(shí)間的長(zhǎng)短受作業(yè)啟動(dòng)時(shí)Map任務(wù)的并行度、從節(jié)點(diǎn)上任務(wù)的執(zhí)行效率、數(shù)據(jù)本地性等眾多因素的影響，計(jì)算方法較為復(fù)雜[10]?？紤]到作業(yè)運(yùn)行過程中所需的輸入數(shù)據(jù)在作業(yè)啟動(dòng)前就已確定，并已按照固定的數(shù)據(jù)塊大小進(jìn)行分片，與此同時(shí)，文件分割器將作業(yè)劃分為與數(shù)據(jù)塊的個(gè)數(shù)相一致的任務(wù)。因此，為了簡(jiǎn)化對(duì)作業(yè)長(zhǎng)度的判定，將JobTracker上分片數(shù)不超過閾值的作業(yè)判定為短作業(yè)，其余判定為一般作業(yè)。同等條件下，短作業(yè)的優(yōu)先級(jí)高于一般作業(yè)，短作業(yè)將優(yōu)先得到執(zhí)行，集群資源的利用率和作業(yè)整體的執(zhí)行效率將得到顯著提升。

c）等待因子 time：在作業(yè)運(yùn)行過程中，有些作業(yè)可能等待較長(zhǎng)時(shí)間而一直未能得到執(zhí)行，通過設(shè)置等待因子衡量作業(yè)的等待時(shí)間以有效防止此類情況的發(fā)生。

d）用戶身份user：根據(jù)用戶權(quán)限大小，將用戶分為root用戶、系統(tǒng)用戶和普通用戶3類。

上述 4項(xiàng)指標(biāo)的取值和所占權(quán)值可以根據(jù)作業(yè)區(qū)分的具體需要由管理員設(shè)定。根據(jù)公式（1）計(jì)算作業(yè)優(yōu)先級(jí)priority的取值，取值越大作業(yè)優(yōu)先級(jí)越高。如公式（1）：

（2）作業(yè)類型劃分

根據(jù)作業(yè)所需計(jì)算資源的不同對(duì)作業(yè)進(jìn)行分類，以便為不同類型的作業(yè)分配合適的計(jì)算資源，從而提高資源使用效率。節(jié)點(diǎn)資源可以包括CPU資源和磁盤資源等。因此，可以將作業(yè)類型簡(jiǎn)單地劃分成CPU密集型（PU-Bound）和I/O密集型（I/O-Bound）兩類。文獻(xiàn)[7]中給出了確定作業(yè)類型的方法，本文對(duì)該方法進(jìn)行優(yōu)化：滿足公式（2）的作業(yè)為CPU 密集型，其他情況則為I/O密集型作業(yè)。如公式（2）：

其中，MID和MOD分別表示Map任務(wù)的輸入數(shù)據(jù)量和輸出數(shù)據(jù)量；RID表示Reduce任務(wù)的輸入數(shù)據(jù)量；n表示從節(jié)點(diǎn)上當(dāng)前運(yùn)行的任務(wù)總數(shù)；MTCT為Map任務(wù)所需的完成時(shí)間；DIOR為磁盤I/O比率。

（3）作業(yè)隊(duì)列

設(shè)立3個(gè)作業(yè)隊(duì)列，分別為等待隊(duì)列、CPU密集型作業(yè)隊(duì)列和I/O密集型作業(yè)隊(duì)列。本文在三隊(duì)列作業(yè)調(diào)度中引入兩級(jí)調(diào)度策略。當(dāng)用戶向集群主節(jié)點(diǎn)JobTracker提交新作業(yè)時(shí)，首先依據(jù)公式（1）計(jì)算其作業(yè)優(yōu)先級(jí)，并按照優(yōu)先級(jí)由高至低的順序依次進(jìn)入等待隊(duì)列。接下來，作業(yè)調(diào)度器對(duì)位于等待隊(duì)列隊(duì)首位置的作業(yè)進(jìn)行任務(wù)劃分并從中選取一個(gè) Map任務(wù)分配給每一個(gè)擁有空閑資源槽的從節(jié)點(diǎn)TaskTracker去執(zhí)行。當(dāng)這些Map任務(wù)執(zhí)行完成后，運(yùn)用公式（2）進(jìn)行作業(yè)類型的判定，滿足公式（2）則為CPU密集型作業(yè)，接下來將進(jìn)入CPU密集型作業(yè)隊(duì)列等待調(diào)度；否則為I/O密集型作業(yè)，進(jìn)入I/O密集型作業(yè)隊(duì)列。

（4）基于節(jié)點(diǎn)特征的資源回收搶占機(jī)制

節(jié)點(diǎn)在執(zhí)行CPU密集型任務(wù)和I/O密集型任務(wù)時(shí)所表現(xiàn)出來的性能是有差異的。節(jié)點(diǎn)執(zhí)行不同類型任務(wù)的歷史平均時(shí)間可以代表該節(jié)點(diǎn)執(zhí)行不同類型作業(yè)的能力，將其稱為節(jié)點(diǎn)特征，對(duì)作業(yè)調(diào)度具有重要的參考價(jià)值[9]。

為每個(gè)節(jié)點(diǎn)各分配數(shù)據(jù)量為2GB的CPU密集型任務(wù)和I/O密集型任務(wù)，通過讀取日志中任務(wù)的加載、完成信息及節(jié)點(diǎn)分配信息，獲取各任務(wù)的執(zhí)行時(shí)間。計(jì)算得到各節(jié)點(diǎn)執(zhí)行CPU密集型任務(wù)和I/O密集型任務(wù)的所需平均時(shí)間，分別記為Tcb和Tiob。集群執(zhí)行CPU密集型任務(wù)和I/O密集型任務(wù)的平均時(shí)間分別記為 AVGcb和 AVGiob。節(jié)點(diǎn)特征Ntype的取值可依據(jù)公式(3)計(jì)算得到，Ntype取值為1表示節(jié)點(diǎn)在執(zhí)行CPU密集型任務(wù)時(shí)性能更優(yōu)，取值為0則表示節(jié)點(diǎn)執(zhí)行I/O密集型任務(wù)時(shí)性能更優(yōu)。如公式（3）：

節(jié)點(diǎn)特征可能會(huì)隨著集群工作的進(jìn)行發(fā)生變化，因此可每隔一定的周期重新計(jì)算。

為CPU密集型作業(yè)隊(duì)列和I/O密集型作業(yè)隊(duì)列各分配一定的資源配額，配額管理方法與計(jì)算能力調(diào)度算法相同，但在資源配額回收的管理中應(yīng)用了基于節(jié)點(diǎn)特征的資源回收搶占機(jī)制。

分別對(duì)CPU密集型作業(yè)隊(duì)列和I/O密集型作業(yè)隊(duì)列當(dāng)前所持有的資源數(shù)進(jìn)行定期檢查，當(dāng)所持有的資源數(shù)低于其配額額度，并且該作業(yè)隊(duì)列中等待執(zhí)行的任務(wù)數(shù)大于正在回收的資源總數(shù)時(shí)，調(diào)度算法查看該作業(yè)隊(duì)列的資源回收列表，如有超時(shí)的資源回收對(duì)象，則進(jìn)行調(diào)度并通過回收線程對(duì)其進(jìn)行回收；否則根據(jù)該隊(duì)列中作業(yè)的作業(yè)類型創(chuàng)建具有相應(yīng)節(jié)點(diǎn)特征的資源回收對(duì)象，并將其加入到該作業(yè)隊(duì)列的資源回收列表中。對(duì)于CPU密集型作業(yè)隊(duì)列，則應(yīng)創(chuàng)建節(jié)點(diǎn)特征Ntype取值為1的資源回收對(duì)象，這是因?yàn)楣?jié)點(diǎn)特征Ntype取值為1的節(jié)點(diǎn)在執(zhí)行CPU密集型任務(wù)時(shí)性能更優(yōu)，因此，該類型節(jié)點(diǎn)中的資源在被回收時(shí)，應(yīng)加入到CPU密集型作業(yè)隊(duì)列的資源回收列表；而節(jié)點(diǎn)特征Ntype取值為0的節(jié)點(diǎn)在執(zhí)行I/O密集型任務(wù)時(shí)性能更優(yōu)，因此，該類節(jié)點(diǎn)中的資源在被回收時(shí)，應(yīng)加入到I/O密集型作業(yè)隊(duì)列的資源回收列表。資源回收對(duì)象包含了回收超時(shí)信息和所需回收的資源總數(shù)（配額額度與當(dāng)前持有資源數(shù)的差值）。

3 算法實(shí)現(xiàn)

基于Hadoop的3隊(duì)列作業(yè)調(diào)度算法的流程如圖2所示：

該調(diào)度算法主要包含計(jì)算作業(yè)優(yōu)先級(jí)、確定作業(yè)類型和基于節(jié)點(diǎn)特征的資源回收搶占3個(gè)階段。JobClient將作業(yè)提交至JobTracker主節(jié)點(diǎn)后，通過計(jì)算作業(yè)優(yōu)先級(jí)，按優(yōu)先級(jí)由高至低的順序依次進(jìn)入等待隊(duì)列；然后對(duì)等待隊(duì)列中的作業(yè)進(jìn)行類型判定，分別進(jìn)入CPU密集型作業(yè)隊(duì)列和I/O密集型作業(yè)隊(duì)列；檢查各作業(yè)隊(duì)列當(dāng)前所持有的資源數(shù)，如果達(dá)到配額額度則將作業(yè)劃分為若干個(gè)Map任務(wù)和Reduce任務(wù)并將任務(wù)分配至具有相應(yīng)節(jié)點(diǎn)特征的TaskTracker節(jié)點(diǎn)去執(zhí)行，若未達(dá)到配額額度則先進(jìn)行資源回收，再執(zhí)行作業(yè)劃分和任務(wù)分配。

4 實(shí)驗(yàn)與分析

為測(cè)試本文提出的作業(yè)調(diào)度算法對(duì)不同作業(yè)類型的區(qū)分調(diào)度性能，采用Hadoop Hive項(xiàng)目提供的基準(zhǔn)測(cè)試程序，選擇先入先出（FIFO）調(diào)度算法與本文算法TJSA作對(duì)比實(shí)驗(yàn)，測(cè)試輸入數(shù)據(jù)選用各 10GB的 CPU密集型作業(yè)WordCount和I/O 密集型作業(yè)TeraGen。

實(shí)驗(yàn)的硬件設(shè)置如下：選取6臺(tái)PC機(jī)，采用Red Hat Enterprise Linux 5.2操作系統(tǒng)和Hadoop 0.21.0版本集群管理軟件搭建Hadoop集群。其中1 臺(tái)機(jī)器作為JobTracker主節(jié)點(diǎn)，硬件配置為雙核2.4GHz，內(nèi)存16GB，硬盤4×250GB；其余5臺(tái)作為TaskTracker從節(jié)點(diǎn)，硬件配置為雙核2.4GHz，內(nèi)存4GB，硬盤4×80GB。Hadoop默認(rèn)為每個(gè)TaskTracker從節(jié)點(diǎn)配置2個(gè)資源槽。

在作業(yè)數(shù)量固定且作業(yè)提交順序隨機(jī)的前提下，每隔30s提交一輪測(cè)試，各進(jìn)行10輪測(cè)試，對(duì)FIFO算法與TJSA算法的調(diào)度性能進(jìn)行對(duì)比分析。

4.1 短作業(yè)高占比時(shí)的算法性能對(duì)比

在測(cè)試所選用作業(yè)中，短作業(yè)占90%，一般作業(yè)占10%。短作業(yè)的數(shù)據(jù)量在 64MB以內(nèi)，一般作業(yè)的數(shù)據(jù)量為64MB～2GB。FIFO算法與TJSA算法在進(jìn)行作業(yè)調(diào)度時(shí)的性能變化曲線如圖3所示：

圖3 短作業(yè)高占比時(shí)的作業(yè)執(zhí)行時(shí)間對(duì)比

從圖3中可以看出，在短作業(yè)占比較高時(shí)，就總體調(diào)度運(yùn)行時(shí)間而言，TJSA算法比FIFO算法縮短10%左右，TJSA算法使得集群的執(zhí)行時(shí)間更為穩(wěn)定。

4.2 一般作業(yè)高占比時(shí)的算法性能對(duì)比

在測(cè)試所選用作業(yè)中，短作業(yè)占20%，一般作業(yè)占80%，短作業(yè)和一般作業(yè)的數(shù)據(jù)量大小與 4.1節(jié)所述保持一致。FIFO算法與TJSA算法在進(jìn)行作業(yè)調(diào)度時(shí)的性能變化曲線如圖4所示：

圖4 一般作業(yè)高占比時(shí)的作業(yè)執(zhí)行時(shí)間對(duì)比

從圖4中可以看出，在一般作業(yè)占比較高時(shí)，就總體調(diào)度運(yùn)行時(shí)間而言，TJSA算法比FIFO算法顯著降低。這是由于TJSA算法對(duì)作業(yè)進(jìn)行了優(yōu)先級(jí)的設(shè)置，并通過將作業(yè)分散在CPU密集型隊(duì)列和I/O密集型隊(duì)列并行執(zhí)行，有效提升了整體執(zhí)行效率。

5 總結(jié)

本文在研究分析Hadoop現(xiàn)有作業(yè)調(diào)度算法的基礎(chǔ)上，提出了一種三隊(duì)列作業(yè)調(diào)度算法TJSA。TJSA通過對(duì)作業(yè)設(shè)置優(yōu)先級(jí)以細(xì)化來自不同用戶的不同作業(yè)的差別；根據(jù)作業(yè)類型的不同分設(shè)CPU密集型作業(yè)隊(duì)列和I/O密集型作業(yè)隊(duì)列，一方面提升了作業(yè)的并行執(zhí)行效率；另一方面可以依據(jù)作業(yè)類型和節(jié)點(diǎn)特征，更為合理地進(jìn)行節(jié)點(diǎn)資源的分配；依據(jù)節(jié)點(diǎn)特征對(duì)資源進(jìn)行回收搶占，有效提升Hadoop平臺(tái)的資源利用率。通過在自組搭建的Hadoop平臺(tái)上進(jìn)行實(shí)驗(yàn)測(cè)試和性能分析，本文所提出的TJSA算法在作業(yè)運(yùn)行時(shí)間和集群穩(wěn)定性上都表現(xiàn)出較好的性能。本文進(jìn)一步的工作是對(duì)作業(yè)優(yōu)先級(jí)的量化進(jìn)行優(yōu)化，同時(shí)考慮支持隊(duì)列間的優(yōu)先級(jí)設(shè)置。

[1] Cloud computing[EB/OL]. http://en.wikip-edia.org/wiki/ Cloud_computing, 2013-03-10.

[2] DEAN J, GHEMAWAT S. MapReduce: a Flexible Data Processing Tool[J]. Communications of the ACM, 2010,53(1):72-77.

[3] 鄧自立.云計(jì)算中的網(wǎng)絡(luò)拓?fù)湓O(shè)計(jì)和 Hadoop平臺(tái)研究[D].合肥:中國(guó)科學(xué)技術(shù)大學(xué),2009.

[4] 李千目,張晟驍,陸路等.一種Hadoop平臺(tái)下的調(diào)度算法及混合調(diào)度策略[J].計(jì)算機(jī)研究與發(fā)展,2013,50:361-368.

[5] 柯何楊,楊群,王立松等.同構(gòu)Hadoop集群環(huán)境下改進(jìn)的延遲調(diào)度算法[J].計(jì)算機(jī)應(yīng)用研究,2013,30(5):1397-1401.

[6] 鄧傳華,范通讓,高峰.Hadoop下基于統(tǒng)計(jì)最優(yōu)的資源調(diào)度算法[J].計(jì)算機(jī)應(yīng)用研究,2013,30(2):417-419.

[7] TIAN Chao, ZHOU Hao-jie, HE Yong-qiang, et al. A dynamic MapReduce Scheduler for Heterogeneous Workloads[C]// Proc of the 8th International Conference on Grid and Cooperative Computing, 2009:218-224.

[8] 曹潔,曾國(guó)蓀,鈕俊等.云環(huán)境下可用性感知的并行任務(wù)調(diào)度方法[J].計(jì)算機(jī)研究與發(fā)展,2013,50(7):1563-1572.

[9] 鄭曉薇,項(xiàng)明,張大為等.基于節(jié)點(diǎn)能力的Hadoop集群任務(wù)自適應(yīng)調(diào)度方法[J].計(jì)算機(jī)研究與發(fā)展,2014,51(3):618-626.

[10] 朱潔,趙紅,李雯睿.基于Hadoop的三隊(duì)列作業(yè)調(diào)度算法[J].計(jì)算機(jī)應(yīng)用,2014,34(11):3227-3230,3240.

TP393 文獻(xiàn)標(biāo)志碼：A

2015.04.01）

1007-757X(2015)08-0019-03

河南省教育廳科學(xué)技術(shù)研究重點(diǎn)項(xiàng)目（14B520039）；平頂山學(xué)院青年基金研究項(xiàng)目（PDSU-QNJJ-2013009）

寧菲菲（1985-），女，漢族，平頂山人，平頂山學(xué)院軟件學(xué)院，助教，碩士，研究方向：無線傳感器網(wǎng)絡(luò)與云計(jì)算,平頂山，467002鄭均輝（1981-），男，漢族，四川敘永縣人，平頂山學(xué)院，講師，碩士，研究方向：算法分析，GPS數(shù)據(jù)處理等，平頂山，467002