改進的Spark Shuffle內存分配算法

侯偉凡，樊 瑋，張宇翔

(中國民航大學 計算機科學與技術學院，天津 300300)

改進的Spark Shuffle內存分配算法

侯偉凡*，樊 瑋，張宇翔

(中國民航大學 計算機科學與技術學院，天津 300300)

Shuffle性能是影響大數據集群性能的重要指標，Spark自身的Shuffle內存分配算法試圖為內存池中的每一個Task平均分配內存，但是在實驗中發現，由于各Task對于內存需求的不均衡導致了內存的浪費和運行效率較低的問題。針對上述問題，提出一種改進的Spark Shuffle內存分配算法。該算法根據Task的內存申請量和歷史運行數據將Task按內存需求分為大小兩類，對小內存需求型Task作“分割化”處理，對大內存需求型Task基于Task溢出次數和溢出后等待時間分配內存。該算法充分利用內存池的空閑內存，可以在數據傾斜導致的Task內存需求不均衡的情況下進行Task內存分配的自適應調節。實驗結果表明，改進后算法較原算法降低了Task的溢出率，減少了Task的周轉時間，提高了集群的運行性能。

Apache Spark;Shuffle;自適應；內存分配；運行性能

0 引言

近年來，大數據已然成為科技領域和企業領域關注的熱點，其中蘊含的巨大價值成為存儲和處理大數據的巨大動力[1]。在大數據發展的過程中，Hadoop[2]和Spark[3]計算引擎逐漸被大多數企業和機構認可，其中Spark因其基于內存的計算框架，運算速度更快，被愈發重視。

Shuffle性能問題是很多分布式系統所共有的問題，究其原因是Shuffle過程會對集群的CPU、內存、磁盤和網絡造成巨大負擔，其中的任何一個因素都有可能成為集群運算的瓶頸，因此改進集群的Shuffle性能成為很多研究人員研究的目標。目前的研究主要分為底層優化、Map和Reduce端優化和對MapReduce模型的改進。

1)底層優化：Zaharia等[4]提出一種延遲調度的算法，該算法能有效提升數據的本地化程度，從而提高集群的工作效率。

2)Map和Reduce端的優化：Guo等[5]提出一種獨立工作的Shuffle服務——iShuffle。它可以估計Map階段輸出partition的大小,并將Map輸出的partition自動均衡放置到各個Reduce節點中；還可以減少任務的排定，使得reduce tasks的調度更加靈活。熊倩等[6]提出通過對Map節點上同一個作業的多個Map任務所產生的大量臨時結果數據作合并的機制，減少了Map節點的輸出結果數據量，從而減少了整個MapReduce作業執行時間，進而提高了性能。彭輔權等[7]分別從Map端數據壓縮、重構遠程數據拷貝傳輸協議等方面優化和重構Shuffle過程，使Shuffle階段的運行效率得到提高。Davidson等[8]針對Spark平臺經常會遇到的Shuffle性能瓶頸提出了幾種應對的替代方案，以減輕處理這些瓶頸相關的系統開銷。

3)MapReduce模型的改進：李玉林等[9]提出一種改進型的MapReduce模型——MBR(Map-Balance-Reduce)模型。通過增加Balance任務，對Map任務處理完成的中間數據進行均衡操作，從而保證Reduce任務的完成時間基本一致。

目前有很多針對Hadoop Shuffle階段的改進，Spark作為基于內存的運算框架，在其內部實現上與Hadoop有很多不同。隨著Spark版本的不斷演變，對于Spark Shuffle數據持久化的問題已經得到了很多的優化，但是并沒有從Task內存分配的角度做工作。因此本文通過研究源碼，從Shuffle過程中內存分配的角度，針對Task的內存分配進行改進，使Shuffle效率得到提高。

1 Spark內存概述

Spark內存分配如圖1所示。Spark默認的JVM(Java Virtual Machine)堆大小為512 MB，可以通過spark.executor.memory參數進行調整。這里的內存基本上是由Executor內部的所有任務所共享。為了避免內存溢出，因此只使用90%，可通過spark.storage.safetyFraction調整。Spark將要處理的數據存儲在Storage部分，這個部分占Safe的60%，可以通過spark.storage.memoryFraction控制。Shuffle可用的內存大小占Safe的20%，由spark.shuffle.memoryFraction控制。由于Shuffle數據的大小是估算出來的，一是為了降低開銷，二是為了降低估算誤差，因此使用spark.shuffle.safetyFraction作為一個保險系數，降低實際Shuffle使用的內存閾值，起到一定的緩沖作用，降低實際內存占用超過用戶配置值的概率。默認情況下spark.shuffle.safetyFraction的值為0.8，由此可以得出，真正用于Shuffle的內存大小為spark.executor.memory * spark.shuffle.safetyFraction * spark.shuffle.memoryFraction。Unroll memory用作數據的序列化和反序列化，由spark.storage.unrollFraction控制，默認為0.2[10]。本文在此內存分配框架下，研究圖1中用于Shuffle操作的部分。

圖1 Spark的內存分配Fig. 1 Memory allocation of Spark

Spark Shuffle線程內存管理器ShuffleMemoryManager負責管理Shuffle線程占有內存的分配與釋放。Task通過ExternalAppendOnlyMap和ExternalSorter向ShuffleMemoryManager申請內存，在運行結束后由ShuffleMemoryManager回收。為了使每一個Task都能比較公平地獲取內存，它采取的內存分配策略是對于正在運行的N個Task，每個Task至少可以申請總內存的1/(2N)，至多申請1/N。在運行過程中，N會隨著內存池中正在運行Task的數目不斷變化。

2 改進的Spark Shuffle內存分配算法

現有Spark Shuffle內存分配算法采取對內存池中Task公平分配資源的策略，一定程度上保證了每個Task在被調度運行時都能較為公平地獲取資源并運行。但是它并未考慮每個Task所需的資源量，僅從Task的數量上考慮公平性，這將導致內存的使用率較低，并且內存需求較多的Task可能會頻繁溢出，甚至出現OutOfMemory錯誤。

并且executor中能同時運行的Task總數由CPU core數決定，當內存需求較大的Task被調度時，其申請的內存會因為內存不足而出現溢出，需要等待其他Task運行完畢空出內存后才能繼續運行，這將大大影響整個作業的運行效率。

此外，由于Spark Shuffle的Fetch過程是一邊Fetch數據一邊處理的，所以當一個分區的全部數據在處理結束前是無法統計其數據大小的。

基于以上問題，首先將資源需求較少的Task作“分割化”處理，即將內存資源需求較小的Task分成若干塊，這樣可使某一時刻內存需求較少的Task所占有內存量變少，因此內存需求較大的Task被調度運行時可以獲得更多內存避免溢出。這樣做的代價是內存需求較少Task的內存申請次數會增加并有可能出現溢出，但其溢出量很少，處理速度很快，并且不會出現頻繁溢出的情況，相比于大規模的磁盤IO操作，仍然提升了Application的整體效率，尤其在數據集有數據傾斜的時候。然后本文認為一個Task溢出次數越多且溢出后等待時間越長，那么它所需計算的原始數據量也就越大。基于此，本文提出一種小內存需求型Task作“分割化”處理，大內存需求型Task基于Task溢出次數和Task溢出后等待時間的Shuffle內存分配算法來改進源碼的公平分配算法。

2.1 改進的Spark Shuffle內存分配算法描述

由于要將內存需求較小的Task作“分割化”處理，所以首先在Task申請內存時需要一個指標來區分Task是大內存需求型Task還是小內存需求型Task。定義該指標為Memavg，如式(1)～(2)所示。其中：L為所有運行結束時未發生溢出Task的集合；K為已被調入過內存池的Task的集合。Memavg代表的是所有運行結束時未發生溢出Task所占用內存的平均值，當一個新被調用Task的內存請求比Memavg大時，認為該Task為大內存需求型的Task；反之，認為該Task為小內存需求型的Task。

(1)

(2)

2.1.1 為小內存需求型Task分配內存

式(3)表明了小內存需求型Task實際申請到的內存，算法直接給予其申請內存的一半與空閑內存的最小值。

(3)

2.1.2 為大內存需求型Task分配內存

在源碼使用的公平分配算法中，擁有每個Task可使用內存的最小保證。對于大內存需求型Task，也給予它最小的內存保證Memlow，保證其執行效率并避免不必要的溢出操作，如式(4)所示。其中maxMemory為可使用的最大內存，numActiveTasks是指當前executor中正在運行的Task數目。

(4)

公平分配算法中，有一個對Task可獲取最大內存的限制，值為maxMemory/numActiveTasks。它不考慮Task內存需求的已有表現，因而不能根據不同Task的數據特征對內存分配作出合理分配。而且它還有一個很嚴重的問題，當一個executor中的Task滿載運行，即numActiveTask為其最大值時，如果有一個Task的內存需求量大于maxMemory/numActiveTasks，那么它將不得不溢出，并等待大多數Task運行完畢，即numActiveTasks變小時才能被再度運行，這將嚴重拖延整個Application的運行效率。基于此本文根據Task的溢出歷史和溢出后等待時間的表現來計算出它應得的內存，進而自適應的調整內存分配。式(5)為空閑內存的計算方法，其中taskMemory管理著內存池中所有未執行完成Task的id和已占有的內存。

(5)

其中M為taskMemory中包含的元素集合。對空閑內存的分配權重weight如式(6)所示，一個Task能從空閑內存中得到的份額取決于其溢出次數占未運行完成Task溢出總數的比值，和溢出后等待調用的時間與未運行完成Task溢出后等待調用時間的比值，其中這兩部分的權重由a1和a2確定(a1+a2=1)。由于溢出的次數是影響Task運行效率的主要因素，而溢出后等待時間取決于內存池的整體狀態，加上多次實驗的經驗，在實驗中設a1=0.7、a2=0.3。

(6)

由式(5)～(6)可以得到Task可獲得的最大內存閾值Memhigh，即式(7)。它由兩部分組成，至少可以獲得內存池分給所有活動狀態下Task的均值，此外它可額外獲得一部分空閑內存，提高內存的利用率，這部分的大小是通過溢出歷史和溢出后等待時間的歷史一起決定的，這使得溢出次數較多，等待時間較長的Task有機會獲得更大內存，以利于加快其執行進度。

(7)

此外，在公平分配算法中，若Task溢出到磁盤，那么它所占有的全部內存將被回收，若該Task是大內存需求型Task，那么它下次被調度時很難獲得比溢出前更大的內存資源，因此在本文中設定一個Memrelease，見式(8)，它使得Task在溢出時不釋放所占有的全部內存，而是根據其溢出歷史釋放一部分內存，這有利于該Task下次被調用時避免再次溢出，其釋放的內存也有利于內存池中其他Task的運行。

taskMemory(j)

(8)

式(9)代表當前Task所能獲得的最大內存:

taskMemory(j)))

(9)

式(10)～(11)表明了大內存需求型Task實際申請到的內存。首先需要判斷該Task已占有的內存是否已滿足Memlow，若已滿足則為Task分配min(maxToGrant，Memfree)的內存，如式(10)；若不滿足，則需要判斷空閑內存能否滿足最小內存保證Memlow，若不能滿足則需要等待內存池中有足夠內存時再調度運行，若能滿足則為Task分配min(maxToGrant，Memfree)的內存，如式(11)。

toGrantj=min(maxToGrantj,Memfree)

(10)

(11)

2.2 改進算法執行流程

本文提出的算法中，使用HashMap和HashSet存放Task的各項歷史數據：taskMemory存放未運行完成Task的唯一編號和已占用的內存容量；taskNotSpill記錄未發生溢出Task的編號；waitingTime存放已溢出Task的編號及等待調用所耗費的時間；spillCount記錄已溢出Task的編號及溢出次數。

如圖2為算法的運行流程。當Task需要內存資源來保證其運行時，Task就會向ShuffleMemoryManager發出申請。ShuffleMemoryManager在接收到請求后首先查看TaskMemory是否有該Task的編號，若沒有，則表示該Task為尚未運行過，那么接下來將為它初始化各個變量。然后比較其Memapply和Memavg的大小來判斷該Task是大內存需求型還是小內存需求型，若是小內存需求型，則直接賦予它min(Memapply/2，Memfree)的內存，若是大內存需求型，則首先需要判斷它目前已占用的內存是否大于內存池大小的1/(2N)，若滿足則直接賦予它min(maxToGrant，Memfree)的內存，若不能滿足則繼續判斷當前Memfree與min(maxToGrant，maxMemory/(2*numActiveTasks)-Memused)的大小，若能滿足則賦予它min(maxToGrant，Memfree)的內存，若不能滿足，由于其最小內存保證，需要等待其他Task運行完成空出內存后繼續申請。

2.3 改進算法偽代碼

改進的Spark Shuffle內存分配算法的偽代碼如下。

輸入 Task申請的內存值numBytes；

輸出 算法實際為Task分配的內存值toGrant。

1)

if !taskMemory.contains(id) then

2)

初始化taskMemory(id),spillCount(id),waitingTime(id)為0,taskNotSpill.add(id)

3)

notifyAll

4)

end if

5)

while True do

6)

按式(1)、(5)～(7)更新numActiveTasks,memAvg,freeMemory,weight和memHigh的值

7)

ifnumBytes

8)

taskMemory(id)←taskMemory(id)+min(numBytes/2,freeMemory)

9)

return min(numByte/2,freeMemory)

10)

end if

/*7)～10)為小內存需求型Task分配內存*/

11)

maxToGrant←min(numBytes,max(0,memHigh-

curMem))

/*curMem為Task當前已占用的內存*/

12)

ifcurMem

13)

iffreeMemory≥min(maxToGrant,memLow-curMem) then

14)

toGrant←min(maxToGrant,freeMemory)

15)

taskMemory(id)←taskMemory(id)+toGrant

16)

returntoGrant

17)

else wait

18)

end if

19)

elsetoGrant←min(maxToGrant,freeMemory)

20)

taskMemory(id) ←taskMemory(id)+toGrant

21)

returntoGrant

22)

end if

/*11)～22)為大內存需求型Task分配內存*/

23)

end

算法的時間復雜度為O(n)，其中n為一個Executor中所要運行的Task數。

圖2 改進算法流程Fig. 2 Flow chart of the improved algorithm

3 實驗結果及分析

3.1 重新編譯源碼過程

Spark的編譯包括make-distribution.sh編譯、SBT編譯和Maven編譯三種方式，本文選擇make-distribution.sh的編譯方式。Spark源碼的編譯過程較為繁瑣，需要很多依賴才能完成，但是實踐后會對Spark的整體系統架構有更深入理解。

3.2 實驗環境

為了驗證本文提出的基于溢出次數和Spill Task等待時間改進算法的正確性，本研究使用四臺服務器搭建Spark集群，其中:表1顯示各節點在集群中的角色，表2顯示了各節點的性能，表3顯示了各軟件版本信息。

本文選取“groupByKey”操作作為驗證算法性能的實驗案例。實驗程序為自己編寫的Wordcount程序，實驗數據集為安然郵件數據集和亞馬遜評論數據集。根據實驗需要，生成了均勻的數據“mail”和不均勻的數據“mailSkew”，如表4所示。實驗中還使用Shuffle階段可利用的內存量“ShuffleMem”(由公式spark.executor.memroy*spark.shuffle.safetyFraction*spark.shuffle.memoryFraction計算所得)來比較兩個算法在不同內存環境下的性能。

表1 實驗集群角色Tab.1 Roles in experiment cluster

表2 集群內各節點配置Tab. 2 Configuration of each node in the cluster

表3 軟件版本信息Tab. 3 Software version information

表4 實驗數據說明Tab. 4 Experimental data description

本文使用以下參數評估算法性能：totalTime為完成Application所需時間；Max為耗時最長的Task所用時間；ShuffleSpill為Application中所有Task的溢出量。

3.3 均勻數據集實驗結果分析

從圖3可以看出，兩種算法在均勻數據集上完成Application所需時間、Shuffle Task運行最長時間、和溢出量上相差不大，改進算法略優于源碼的公平算法。這主要是由于在均勻數據集下，Task需要處理的數據量比較平均，對于單個Task而言內存的需求量較小，Task可以在未溢出的情況下運行完成。圖3(c)、(d)最開始兩算法都有較大規模的溢出，這是因為對整體內存的配置過低，每個Task可以分配的內存過小，導致溢出。

3.4 不均勻數據集實驗結果分析

totalTime是完成整個Application所需要的時間，是衡量算法性能最直觀的指標。從圖4(a)可以看出：改進算法在所設置的內存量上全面優于源碼的公平算法，可以減少運行時間的10%～12.5%。Max是Shuffle階段運行時間最長的Task所消耗的時間，該Task一般為處理傾斜數據的Task，因此Max值的大小將直接影響整個Application的運行時間。從圖4(b)可以看出：改進算法的Max值要明顯小于源碼的公平算法，尤其是在可分配內存較小的情況下。這主要是因為，源碼的公平算法規定每一個Task最多可以獲得內存池中內存的1/N，然而這部分內存并不能滿足處理傾斜數據Task的需求，因此該Task會頻繁地溢出直到對內存需求小的Task運行完畢，空出足夠的內存才能成功運行，這其中頻繁的溢出和等待調度都相當耗時。而改進算法將對內存需求較小的Task進行 “分割化”處理，每次只從內存池中獲取較少的內存，因此當內存需求較大的Task向內存池申請內存時，內存池就可以分配足夠多的內存，從而避免了一些溢出，減少了Task的整體運行時間。

圖3 處理mail文件時不同參數的對比Fig. 3 Comparison of different parameters in handling mail files

Shufflespill是Application中所有Task的總溢出量。由圖4(c)～(d)可以看出改進算法的溢出量顯著少于源碼的公平算法。因為公平算法不能及時滿足需求量較大的Task的內存需求，因此會造成Task的頻繁溢出，導致ShuffleSpill的量很大。改進算法通過Task的溢出次數和溢出后的等待時間準確捕捉到需要內存較多的Task，并在其下次調度時從空閑內存中多分配一部分資源，使其可以盡快運行完成，從而減少了很多溢出量。

3.5 實驗結論

本文使用了兩種數據集，分別是均勻的數據集和不均勻的數據集，其中不均勻的數據集中傾斜的數據約占19%。實驗在不同數據集上分別用源碼公平分配算法和改進算法來執行WordCount程序，并使用totalTime、Max、ShuffleSpill三個指標來衡量兩個算法的性能。從3.3節和3.4節的實驗來看，改進算法在均勻數據集上的性能略好于公平分配算法，在不均勻的數據集上可以看出經過算法的自適應調節，Task的溢出量較公平分配算法有大幅度的減少，使集群整體性能提升10%～12.5%。

綜上所述，改進算法能夠在有數據傾斜時更加高效地利用內存，減少對內存資源需求較大Task的溢出量，從而提升Application的整體運行效率。

圖4 處理mailSkew文件時不同參數的對比Fig. 4 Comparison of different parameters in handling mailSkew files

4 結語

本文對Spark Shuffle內存分配算法進行了研究，提出一種小內存需求型Task作“分割化”處理、大內存需求型Task基于Task溢出次數和Task溢出后等待時間的Shuffle內存分配算法來改進源碼的公平分配算法，對整個內存池的使用率和各Task的運行效率作出改進，并對源碼進行重新編譯和部署。實驗結果表明，改進算法能有效提升Spark在處理傾斜數據時的運行效率。Shuffle環節是大多數Spark作業的瓶頸，因此如何提升Shuffle階段的性能也成為眾多研究人員思考的問題。現實情況下，影響Shuffle性能的原因還有很多，如：代碼開發、資源參數和數據傾斜等。在本文研究的基礎之上，下一步將考慮其他對Shuffle性能影響的因素，與實際問題相結合，使Spark的Shuffle性能得到更大提升。

References)

[1] 程學旗,靳小龍,王元卓,等.大數據系統和分析技術綜述[J].軟件學報,2014,25(9):1889-1908.(CHENG X Q, JIN X L, WANG Y Z, et al. Survey on big data system and analytic technology [J]. Journal of Software, 2014, 25(9): 1889-1908.)[2] Apache. Apache Hadoop [2017- 04- 20]. http://apache.hadoop.org.

[3] ZAHARIA M, CHOWDHURY M, DAS T, et al. Resilient distributed datasets: a fault-tolerant abstraction for in-memory cluster computing [C]// Proceedings of the 2012 9th USENIX Conference on Networked Systems Design and Implementation. Berkeley, CA: USENIX Association, 2012: 2-2.

[4] ZAHARIA M, BORTHAKUR D, SARMA J S, et al. Delay scheduling: a simple technique for achieving locality and fairness in cluster scheduling [C]// Proceedings of the 2010 5th European Conference on Computer Systems. New York: ACM, 2010: 265-278.

[5] GUO Y F, RAO J, CHENG D Z, et al. iShuffle: improving Hadoop performance with shuffle-on-write [J]. IEEE Transactions on Parallel & Distributed Systems, 2017, 28(6): 1649-1662.

[6] 熊倩,張龑,郭明,等.MapReduce Shuffle性能改進[J].計算機應用,2017,37(S1):58-62,67.(XIONG Q, ZHANG Y, GUO M, et al. Performance improvement of MapReduce Shuffle [J]. Journal of Computer Applications, 2017, 37(S1): 58-62, 67.)

[7] 彭輔權,金蒼宏,吳明暉,等.MapReduce中shuffle優化與重構[J].中國科技論文,2012,7(4):241-245.(PENG F Q, JIN C H, WU M H, et al. Optimization and reconstruction shuffle in MapReduce [J]. China Sciencepaper, 2012, 7(4): 241-245.)

[8] DAVIDSON A, OR A. Optimizing shuffle performance in Spark [EB/OL]. [2017- 04- 12]. https://people.eecs.berkeley.edu/～kubitron/courses/cs262a-F13/projects/reports/project16_report.pdf.

[9] 李玉林,董晶.基于Hadoop的MapReduce模型的研究與改進[J].計算機工程與設計,2012,33(8):3110-3116.(LI Y L, DONG J. Study and improvement of MapReduce based on Hadoop [J]. Computer Engineering and Design, 2012, 33(8): 3110-3116.)

[10] GRISHCHENKO A. Distributed systems architecture [EB/OL]. [2017- 04- 12]. https://0x0fff.com/spark-architecture.

[11] WANG J H, QIU M K, GUO B, et al. Phase-reconfigurable Shuffle optimization for Hadoop MapReduce [J]. IEEE Transactions on Cloud Computing, 2015, PP(99): 1-1.

[12] LI J G, LIN X L, CUI X L, et al. Improving the Shuffle of Hadoop MapReduce [C]// Proceedings of the 2013 IEEE 5th International Conference on Cloud Computing Technology and Science. Piscataway, NJ: IEEE, 2013: 266-273

The work is partially supported by the National Natural Science Foundation of China (U1533104).

HOUWeifan, born in 1992, M. S. candidate. His research interests include intelligent algorithm, data mining.

FANFanwei, born in 1968, Ph. D., professor. His research interests include intelligent information processing, software engineering.

ZHANGYuxiang, born in 1975, Ph. D., associate professor. His research interests include network data analysis, distributed network.

ImprovedSparkShufflememoryallocationalgorithm

HOU Weifan*, FAN Wei, ZHANG Yuxiang

(CollegeofComputerScienceandTechnology,CivilAviationUniversityofChina,Tianjin300300,China)

Shuffle performance is an important indicator of affecting cluster performance for big data frameworks. The Shuffle memory allocation algorithm of Spark itself tries to allocate memory evenly for every Task in the memory pool, but it is found in experiments that the memory was wasted and the efficiency was low due to the imbalance of memory requirements for each Task. In order to solve the problem, an improved Spark Shuffle memory allocation algorithm was proposed. According to the amount of memory applications and historical operating data, the Task was divided into two categories based on memory requirements. The “split”processing was carried out for the Task of small memory requirements, while the memory was allocated based on the number of Task overflows and the waiting time after overflow for the Task of large memory requirements. By taking full advantage of the free memory of memory pool, the adaptive adjustment of Task memory allocation could be realized under the condition of unbalanced Task memory requirements caused by the data skew. The experimental results show that, compared with the original algorithm, the improved algorithm can reduce the overflow rate of the Task, decrease the turnaround time of the Task, and improve the running performance of the cluster.

Apache Spark; Shuffle; adaptive; memory allocation; running performance

2017- 05- 09 ;

2017- 07- 24。

國家自然科學基金資助項目(U1533104)。

侯偉凡(1992—)，男，內蒙古烏蘭浩特人，碩士研究生，主要研究方向：智能算法、數據挖掘； 樊瑋(1968—)，男，陜西乾縣人，教授，博士，CCF會員，主要研究方向：智能信息處理、軟件工程; 張宇翔(1975—)，男，山西五寨人， 副教授，博士，CCF會員，主要研究方向：網絡數據分析、分布式網絡。

1001- 9081(2017)12- 3401- 05

10.11772/j.issn.1001- 9081.2017.12.3401

(*通信作者電子郵箱rainingxa@126.com)

TP311.5

A