黃 山,房六一,徐浩桐,段曉東

(1.大連民族大學計算機科學與工程學院,遼寧 大連 116600;2.大數據應用技術國家民委重點實驗室,遼寧 大連 116600;3.大連市民族文化數字技術重點實驗室,遼寧 大連 116600)

1 引言

隨著互聯網技術的飛速發(fā)展，萬物互聯成為未來發(fā)展的必然趨勢，人類正從計算機時代走向數據技術時代。據國際數據公司IDC(International Data Corporation)預測，2025年全球產生的數據量將達到163 ZB[1]。與此同時,具有高可伸縮性、部署方便、初期成本低、按使用付費、運行維護成本低特點的云計算技術也得到了迅猛發(fā)展。大數據管理系統(tǒng)正在向支持可伸縮性和支持批計算、流計算、機器學習等多計算模式相融合方向發(fā)展[2]。

Flink[3]作為最新一代的大數據計算引擎，具有低延遲、高吞吐等優(yōu)勢，使其備受學術界和工業(yè)界青睞。與此同時，隨著虛擬化技術的發(fā)展，各種應用都在使用容器化部署。然而，Flink在容器中部署時，由于其不能感知到結點負載情況，會導致任務分配不均勻，造成性能下降。

本文提出一種面向容器環(huán)境的Flink任務調度算法FSACE(Flink Shedule Algorithm for Container Environment)，該算法在容器環(huán)境下部署Flink任務時，結合集群容器負載信息調度任務，從而使任務分配更加均衡，提升了Flink在容器環(huán)境下的處理效率。

本文的主要貢獻有：

(1)提出一種結合容器部署負載信息的Flink任務調度算法。該算法獲取每個結點性能信息與容器在結點上的分布信息，優(yōu)先選擇空閑資源較多的結點的容器，同時可以避免容器被頻繁選中造成負載不均。

(2)利用不同規(guī)模的數據集進行對比實驗，實驗表明，本文提出的FSACE算法相比默認的Flink任務調度算法在計算時間、吞吐量、時延和資源利用方面都有優(yōu)化。

2 相關工作

容器環(huán)境下大數據計算平臺的任務調度優(yōu)化算法主要分為以下2類：

(1)優(yōu)化大數據處理引擎的任務調度算法。文獻[4]提出了處理空間數據的批流融合處理架構，可以支持多源空間連接查詢。文獻[5]研究了批流融合系統(tǒng)中多算子放置問題，使算子能更均衡地分布到集群各結點上，提升效率。文獻[6]提出了適用于Nephel[7]數據流平臺的響應式資源調度策略，通過建立數學模型計算每個算子的并行度，并通過任務遷移實現集群資源的動態(tài)伸縮，但是在其任務遷移過程中，網絡傳輸開銷較大。文獻[8]通過監(jiān)控集群性能指標，建立了針對Strom[9]平臺無狀態(tài)數據流的彈性資源調度策略。文獻[10]提出分布式彈性資源管理協議，實現了集群規(guī)模對輸入負載的快速響應。文獻[11]通過實現上下游結點算子的靈活遷移和動態(tài)鏈接，應對內存不足造成的背壓[12]問題。文獻[13]提出了自定義代價模型，在鄰近代價閾值[14]時啟動分區(qū)映射算法[15]，實現結點間計算負載的最優(yōu)分配。文獻[16]將流式計算拓撲定義為流網絡模型[17]并從中尋找優(yōu)化路徑，從而提高集群吞吐量。此外，文獻[18-21]也分別提出了不同的負載均衡策略，以提升集群性能。這些算法由于沒有考慮容器部署情況對于Flink資源調度的影響，造成任務分配不均勻，進而拖慢任務執(zhí)行速度。

(2)基于結點性能信息的容器優(yōu)化調度算法。文獻[22]提出了基于負載預測的擴容策略和綜合考慮狀態(tài)因素、資源因素的優(yōu)化策略，可以減少應用請求響應時間，減少結點資源碎片化，提升集群服務質量。文獻[23]提出一種動態(tài)縮容算法，在縮容過程中根據某一服務在不同結點上分布的Pod(Kubernetes創(chuàng)建或部署的最小基本單位)[24]實際資源使用情況，計算出該結點刪除Pod后的CPU內存資源均衡度，最后選擇刪除資源均衡度最小的結點，可以使集群具有更好的資源均衡度。這些研究工作考慮了容器情況的影響，但調度的基本單位為容器，調度粒度較粗，無法根據Flink任務具體情況進行資源調度。

綜上，現有研究工作一部分沒有考慮容器情況對于Flink任務調度的影響，一部分無法適應Flink資源調度。針對這一問題，本文提出了面向容器的Flink任務調度算法FSACE，算法通過獲取容器的性能信息，優(yōu)化Flink的任務調度，有效地改善了容器環(huán)境下Flink負載不均的問題，提高了計算效率。

3 研究技術背景介紹

本節(jié)主要介紹FSACE算法相關的技術背景，主要包括3個方面，分別是Flink大數據計算平臺、容器技術[25]和Flink容器環(huán)境下部署方式。

3.1 Flink大數據計算平臺

Apache Flink是一個批流融合分布式處理框架，其功能十分強大，不僅可以運行在包括YARN[26]、Mesos[27]和Kubernetes[28]在內的多種資源管理框架上，還支持在裸機集群上獨立部署。Flink可以擴展到數千核心的集群中，其數據可以達到TB級別且仍能保持高吞吐、低延遲特性。

3.1.1 Flink編程模型

Flink的組件分為4層，各個模塊之間的層次關系如圖1所示。

Figure 1 Flink programming model圖1 Flink編程模型

圖1中底層是Deploy層，Flink支持多種部署方式，例如本地(Local)單機版、Standalone集群部署、YARN集群部署和Kubernetes等云(Cloud)部署方式。

第2層是Core層，這一層是Flink分布式數據處理的核心實現層，包括計算圖的所有底層實現。

第3層是API層，該層包括了流處理(DataStream)API和批處理(DataSet)API，Flink的批處理是建立在流處理架構之上的，因此Flink更適合流處理場景。

最上層是Library層，本層是Flink應用架構層，構建在DataStream API和DataSet API之上。

3.1.2 Flink算子轉換

Flink中的執(zhí)行圖可以分成4層：StreamGraph、JobGraph、ExecutionGraph和PhysicalGraph。這4層執(zhí)行圖表示了從程序最初的拓撲結構到可執(zhí)行Task的變化過程。

(1)StreamGraph：是根據用戶通過Stream API編寫的代碼生成的最初的圖，用來表示程序的拓撲結構。

(2)JobGraph：StreamGraph經過優(yōu)化后生成了 JobGraph，為提交給JobManager的數據結構。其中主要的優(yōu)化為，將多個符合條件的結點鏈在一起作為一個結點，這樣可以減少數據在結點之間流動所需要的序列化、反序列化和傳輸消耗。

(3)ExecutionGraph：JobManager根據JobGraph生成ExecutionGraph。ExecutionGraph是JobGraph的并行化版本，是調度層最為核心的數據結構。

(4)PhysicalGraph：JobManager根據Execu- tionGraph對Job進行調度后，在各個TaskMan- ager上部署Task后形成的“圖”，是各個Task分布在不同的結點上所形成的物理上的關系表示，并不是一個具體的數據結構。

以并行度為2(其中Source并行度為1)的 SocketTextStreamWordCount為例，4層執(zhí)行圖的演變過程如圖2所示。

3.1.3 Flink任務調度

Flink集群啟動后，首先會啟動一個JobMa- nager 和多個TaskManager。用戶的代碼會由JobClient提交給JobManager，JobManager再把來自不同用戶的任務發(fā)給不同的TaskManager執(zhí)行，每個TaskManager管理著多個Task，Task是執(zhí)行計算的最小單元，TaskManager將心跳和統(tǒng)計信息匯報給 JobManager。TaskManager之間以流的形式進行數據傳輸。

上述除了Task外的三者均為獨立的JVM(Java Virtual Machine)進程。其中，TaskManager和Job并非一一對應的關系，每個TaskManager最少持有1個slot，slot是Flink執(zhí)行Job時的最小資源分配單位，在slot中運行著具體的Task任務。

Flink提供了2種基本的任務調度邏輯，即Eager調度和Lazy From Source。Eager調度會在作業(yè)啟動時申請資源將所有的Task調度運行，更加適用于流作業(yè)；而Lazy From Source則是按拓撲順序來進行調度，更加適用于批作業(yè)。2種任務調度均是從各TaskManager中的slot池中依次獲取可用的slot進行資源分配。

Figure 2 Flink operator conversion 圖2 Flink算子轉換

3.2 容器技術

容器技術是一種可以有效地將單個操作系統(tǒng)的資源劃分到獨立的組中，以便更好地在獨立的組之間平衡有沖突的資源使用需求的技術。

Docker[29]是基于Go語言的開源容器項目，是C/S架構，主要由客戶端和服務器2大核心組件組成，通過鏡像倉庫來存儲鏡像。客戶端和服務器可以運行在同一臺機器中，也可以通過Socket或RESTful API來進行通信。

Kubernetes用于容器編排，具有自動化程度高的優(yōu)勢。Kubernetes可以將各種服務器資源整合到一起，應用的整個生命周期都可以實現自動化管理，用戶不用關心具體容器如何部署，并且可以獲取容器的相關信息。

Figure 3 Deployment of Flink in a container environment圖3 Flink容器環(huán)境下部署

3.3 Flink容器環(huán)境下部署方式

將Flink在容器環(huán)境下部署的架構如圖3所示。

Flink的容器組件主要包括JobManager與TaskManager，其中JobManager容器主要負責任務調度，而TaskManager容器主要負責執(zhí)行計算任務。

為了監(jiān)控容器資源性能部署了開源的Metric-Server。在Kubernetes上部署Metric-Server之后，它在每個結點上都會有一個副本，負責收集容器性能信息，并實現Flink應用整個生命周期的自動化管理。

在Kubernetes主結點上的組件主要包括Controller Manager、Scheduler和Etcd。其中 Controller Manager可以用來控制Flink容器副本的數量，Scheduler負責應用的調度，Etcd鍵值數據庫負責持久化存儲集群配置。從結點上的組件主要Kubelet和Kube-proxy,負責與API進行通信。

4 任務調度優(yōu)化算法

本節(jié)首先分析Flink容器環(huán)境下部署時默認的任務調度算法存在的問題，之后介紹本文提出的Flink任務調度優(yōu)化算法(FSACE)。

4.1 問題分析

在容器環(huán)境下部署Flink大數據處理平臺時，由于每個結點上的容器數量不完全相同，容器也并不是都用于Flink部署，因此使用Flink默認的任務調度算法，會將每個容器作為一個分配單元分配，這將導致各個結點上任務負載不均。

Flink默認任務調度算法、Kubernetes容器調度算法和本文所提算法的任務調度實例如圖4所示。

Figure 4 Flink containerized cluster processing task set圖4 Flink容器化集群處理任務集合

Flink集群中有3個結點分別編號為A、B、C，這3個結點在性能上存在差別，結點C的性能最好，結點B次之，結點A最差。每個結點上運行著不同的容器，占用著大小不同的資源，結點A容器資源占用最多，結點B次之，結點C容器資源占用最少。

集群中結點C的性能明顯優(yōu)于結點A和結點B的性能。假設此時集群中需要處理含有7個任務的任務集合。

按照Flink默認的任務調度算法，結點A處理任務1,4,7，結點B需要處理任務2,5，結點C處理任務3,6。性能最差的結點A被分配了最多的任務，結點B和結點C分配了相等的任務。這樣的任務分配結果就會造成負載不均衡。由此導致結點A處理時間拖慢了全部任務完成的時間，集群吞吐量下降，延時增加。

在Kubernetes容器集群情況下，按照其默認的容器調度算法，此時集群中，結點A處理任務1,4，結點B需要處理任務2,5,7，結點C處理任務3,6。性能最差的結點A和性能最好的結點C分配了相同數量的任務，結點B分配了最多的任務,也造成了結點負載不均，從而增加了整個Job的運行時間。

按照本文提出的FSACE算法，結點A性能最差，處理任務7，結點B性能好于結點A的性能，處理任務5,6，結點C性能最好，處理任務1,2,3,4。此時，性能好的結點處理更多的任務，性能相對差的結點處理更少的任務，集群中任務分配相對均衡，從而減少了任務的運行時間。

在容器化的Flink集群中，容器部署不均會造成結點間存在很大的性能差別，如果采用Flink默認的輪詢策略，會造成任務在結點上分布不均衡，進而影響集群計算效率。

4.2 FSACE算法思想

FSACE算法基本思想是,Flink在容器環(huán)境部署時，為使任務分配更為均衡，需要獲取結點性能與容器在結點上的分布情況,然后根據結點性能與容器在結點上的分布情況調度任務，每次選擇評分最高的容器分配任務，并調整各結點的評分。在調度任務時考慮以下3個問題：

(1)結點上容器資源分配不均問題。擁有較多空閑資源的結點不應被頻繁分配任務，需要根據容器的分布計算結點的性能，給結點評分，并優(yōu)先將計算任務分配給評分高的結點所在的Flink容器。

(2)結點性能上限問題。為了避免評分較大的結點被連續(xù)選中，導致評分較大的結點很快達到它的性能上限，最終該結點過負載。FSACE算法會在選中結點時，適當降低結點評分，這樣使性能較高的結點不會連續(xù)被選中，而是相對錯開被選中，從而使任務分配更均衡。

(3)分布在同一結點的各容器資源會相互搶占資源問題。在一個容器中分配任務時，該結點占用的資源增加，為使任務調度更加均衡，應適當減少在該結點上的其他容器中分配任務，因此該結點其他容器分配任務的優(yōu)先級應當下降。

例如，容器環(huán)境下Flink集群中3個結點A,B,C，它們的權值比值為3∶1∶2，因此當有6個任務需要被調度時，前3個任務分配給結點A，接下2個任務分配給結點C，最后一個任務分配給結點B。這樣的任務調度策略就能充分發(fā)揮結點A的性能優(yōu)勢，同時規(guī)避了結點C的性能劣勢。因此FSACE算法能夠充分利用集群各個結點的計算能力。

4.3 技術架構

FSACE的技術架構如圖5所示，其中架構的最底層為容器(Container)，以Docker作為容器運行引擎，HDFS(Hadoop Distributed File System)作為分布式存儲系統(tǒng)。

Figure 5 Technical architecture圖5 技術架構

使用Metric-Server監(jiān)控結點上的容器性能信息，Flannel作為容器網絡插件，為每一個容器分配獨立的IP。

使用Kubernetes作為容器集群管理工具。最上層為Flink大數據處理平臺，主要包括JobManager和TaskManager 2種容器。

FSACE的調度流程如圖6所示。FSACE算法首先會通過Metric-Server獲取各個結點上的容器信息，以及每個結點的性能信息，之后將這些需要的信息發(fā)送給Flink。

Figure 6 FSACE scheduling process圖6 FSACE調度流程

接下來判斷任務調度列表中是否存在未調度的任務，如果沒有還未調度的任務，則流程結束；如果有任務，那么根據結點性能進行結點評分，然后挑選任務槽，分配任務，將任務優(yōu)先分配給評分高的結點所在的任務槽，并且避免評分過高的結點被頻繁選中導致負載過高的問題，之后在任務調度列表中將已經分配的任務刪除。

4.4 FSACE算法

在容器化Flink集群中解決負載不均衡問題，就需要采用優(yōu)化的結點性能評分任務調度算法，而這種算法需要得到集群中每個結點的性能評分。通常用計算資源來代表結點的評分，而影響Flink集群運行效率最主要的就是計算資源。計算資源中最具代表性的是CPU可用資源和內存可用資源，因此本文使用CPU可用資源和內存可用資源來給結點評分。

初始調度時根據CPU可用資源和內存可用資源指標得到一個結點初始評分P。使用初始評分P來衡量該結點的性能高低，初始評分的計算如式(1)所示：

P=δC+(1-δ)M

(1)

其中，C是CPU可用資源，M是內存可用資源，δ代表CPU可用資源在整個初始評分中所占的比例，1-δ代表內存可用資源在整個初始評分中所占的比例。通過實驗發(fā)現，CPU與內存的比例不同，會影響任務運行時間，經過多次實驗發(fā)現，Flink容器集群對CPU的資源敏感性大于對內存的資源敏感性，δ為0.9時效果最好。

使用當前評分Y來衡量運行過程中每個結點的評分。當前評分等于上一次的評分加初始評分，第1次當前評分等于初始評分。每經過一次調度有效評分都會發(fā)生變化，使用當前評分來衡量結點的性能，每次挑選當前評分最高的結點作為目標結點。削減當前評分的計算如式(2)所示：

(2)

其中,Y是當前評分，n是當前任務數，P是結點i的初始評分，當Y是被選中的最高評分時，T是每個結點的初始評分的和，若Y不是最高評分則T為0。

算法1是結點性能評分算法，其中輸入的HttpDatas結點性能信息是通過Metric-Server容器組件獲取到的每個容器信息，經過疊加計算獲得的。然后，遍歷這個結點性能集合，根據結點的CPU、內存信息計算每個結點的初始評分P，Y為結點的當前評分，初始時當前評分等于初始評分。然后，將計算好的每個結點性能評分加入到結點性能評分的集合DataSets中。

算法1結點性能評分算法

輸入：Flink的結點數據集合HttpDatas。

輸出：帶評分的結點性能集合DataSets。

①fordatainHttpDatas

②P=(data.cpudata+(1-δ)data.memorydata;

③Y=P;

④d=newDataSet(ip,cpudata,memorydata,Y,P);

⑤DataSets.add(d);

⑥endfor

⑦returnDataSets

算法2是結點的控制評分算法，首先進行數據的初始化，把目標結點的instance變量初始化為空，把評分初始化為0(第1行)。然后將每個結點的DataSet都與instance比較，如果DataSet.Y比instance.Y大，則用instance記錄DataSet，同時用T不斷累加初始評分P，每個DataSet的當前評分加上自身的初始評分P(第2～8行)。結束循環(huán)后，把instance記錄的當前評分最大的DataSet的有效評分減去總的評分T，之后getAvailableSlot()函數會順序遍歷這個結點上的TaskManager容器，并返回一個TaskManager容器中可用的Slot(第9行和10行)。

算法2控制評分算法。

輸入：結點的性能評分數據集合DataSets。

輸出：當前評分最大結點的任務槽Slot。

① Initializeinstance=null;T=0；

②forDataSetinDataSetsdo

③ifDataSet.Y>intance.Ythen

④instance=DataSet;

⑤endif

⑥T=T+DataSet.P;

⑦DataSet.Y=DataSet.Y+DataSet.P;

⑧endfor

⑨instance.Y=instance.Y-T

⑩slot=instance.getAvailableSlot()

本文提出的FSACE算法考慮到每個結點的性能差異，根據結點實時性能賦予每個結點合適的評分，根據評分大小進行輪詢調度，這樣就能夠使任務調度負載均衡。

為了防止輪詢調度時評分較大的結點被連續(xù)多次選中造成評分較大的結點迅速達到負載上限，結點的計算效率降低，因此采用一種更加合理的處理方式，即讓結點被錯開選中。

4.5 算法示例

為了能更好地解釋優(yōu)化的Flink任務調度算法，本節(jié)給出一個任務調度算法的示例。

容器化Flink集群中有3個Slave結點，分別為Slave1、Slave2、Slave3。假設初始的評分比例是Slave1∶Slave2∶Slave3=3∶1∶2，因為初始的時候結點的有效評分等于它自身的評分，因此有效評分比Slave1∶Slave2∶Slave3=3∶1∶2。

分別采用Flink默認任務調度算法和FSACE算法進行闡述。假設有一個任務集合共有6個子任務。

(1)Flink默認任務調度算法。該算法不需要考慮評分，因此其任務調度過程如表1所示。其中Slave1被選中2次，Slave2被選中2次，Slave3被選中2次，這3個結點被選中的次數一樣多，即3個結點輪流被選中。顯然這種任務調度策略沒有考慮到每個結點的性能，Slave2的性能最差，卻被分配到和Slave1、Slave3同等工作量的任務，因此Slave2成為提升集群效率的瓶頸。

Table 1 Task scheduling process by Flink’s default algorithm

(2)FSACE算法。FSACE算法就是在任務調度的過程中，考慮每個結點CPU和內存的大小，對每個結點進行評分，優(yōu)先挑選評分高的結點分配任務，并且避免某個評分高的結點連續(xù)被選中導致該結點達到負載上限，影響整個集群計算效率的問題。FSACE算法調度過程如圖7和表2所示。結點被選中的順序分別是Slave1、Slave3、Slave1、Slave2、Slave1和Slave3。最終的順序考慮了每個結點的性能，又避免了性能較好評分高的結點連續(xù)被選中導致負載不均的問題。

Figure 7 Task scheduling process of optimized algorithm 圖7 優(yōu)化的算法任務調度過程

Table 2 Task scheduling process of FSACE

綜上所述，通過對2種任務調度算法過程的詳細描述可以看出，FSACE算法在考慮了結點性能的基礎之上，進一步避免了性能較好的結點連續(xù)被選中，使得整個Flink容器集群變得負載均衡，提高了整個集群的計算效率。

4.6 復雜性分析

在時間上，FSACE算法的時間復雜度為T(n)=O(m*n)，其中m是容器數，n是任務數。

在空間上，FSACE算法中的性能評分算法需要存儲容器部署信息，包含容器所在結點位置、容器IP地址、結點CPU使用率和結點內存使用率等信息，在算法中還需要用到中間變量及評分信息。每一條信息約幾十字節(jié)，故算法空間復雜度為O(m)，其中m為集群中的容器數。

5 實驗

本節(jié)主要描述Flink默認任務調度算法與本文提出的FSACE算法的對比實驗。通過Docker容器平臺將Flink各個組件容器化，之后通過配置文件將Flink容器配置到Kubernetes集群中。在Kubernetes容器集群中，配置了Metric-Server容器監(jiān)控組件來獲取容器的性能信息。

5.1 實驗環(huán)境說明

FSACE算法使用Java作為編程語言實現，操作系統(tǒng)使用CentOS，容器運行平臺使用Docker，容器管理系統(tǒng)使用Kubernetes，容器性能監(jiān)控組件使用Metric-Server。各軟件版本如表3所示。

實驗硬件環(huán)境配置：本文共使用4臺阿里云服務器組成集群，其中性能最好的結點作為Master結點。各結點硬件配置如下：

結點1：通用型ecs.g6,CPU:4核,內存：8 GB,系統(tǒng)盤(SSD 云盤)：200 GB;

結點2：通用型ecs.g6,CPU:2核,內存：4 GB,系統(tǒng)盤(SSD 云盤)：200 GB;

結點3、4：通用型ecs.g6,CPU:2核,內存：2 GB,系統(tǒng)盤(SSD 云盤)：200 GB。

Table 3 Software version

生產情況下任務負載，每個結點上由于運行的容器的數量和規(guī)模不同，使得每個結點的性能變得不同，實驗中為了盡可能模擬生產情況下任務負載，除了Flink的容器之外，在結點上部署了一些用于其他服務的Pod。每個結點的Pod以及資源配額數量如表4所示(集群單一結點CPU容量為1 000m，CPU分配單位為m，代表千分之一CPU)。

Table 4 Node resource quota

本節(jié)主要進行了CPU評分影響運行時間的實驗、Flink默認任務調度算法、Kubernetes容器調度算法與本文提出的FSACE算法的對比實驗，實驗數據集為3種不同規(guī)模數據集。為了減小誤差，每次實驗進行3次取平均值。

5.2 實驗參數說明

本文使用了WordCount計算任務進行測試，使用的實驗數據集共有3種規(guī)模，測試程序分別在這3種數據集、不同的容器數量、并行度情況下進行了多組實驗，之后選取實驗效果較好的參數設置進行了TeraSort計算任務的實驗。

實驗中使用Flink默認任務調度算法、Kubernetes容器調度算法、FSACE算法從時延、吞吐量和運行時間方面做了對比和分析。

實驗中使用一個計算任務例子WordCount，該程序主要是統(tǒng)計每個單詞出現的次數，執(zhí)行過程是Source-FlatMap-GroupBy-Sum-Sink，其中Source是讀取數據源，FlatMap是將每一行語句按照空格拆開變成多個單詞，GroupBy則是將單詞分組，相同的單詞被數據重組(shuffle)到同一個結點，后續(xù)可以統(tǒng)計單詞個數。Sum統(tǒng)計每個單詞出現的次數，Sink把統(tǒng)計結果寫入到HDFS中。

實驗中另一個計算任務是TeraSort，它是分布式計算平臺中用于對數據進行排序Benchmark，在不同平臺上對數據排序的效率是衡量分布式系統(tǒng)處理能力的公認標準。整個實驗中所用到的實驗參數如表5所示。

Table 5 Experimental parameters

5.3 實驗結果與分析

圖8展示了δ對于運行時間的影響。由實驗結果可以看出,δ會影響任務的運行時間，容器環(huán)境下Flink任務的執(zhí)行時間對CPU的資源敏感性大于對內存的資源敏感性，并且δ為0.9時，運行時間最短,后面的實驗均采用δ=0.9。

Figure 8 Running time v.s. δ圖8 運行時間隨δ值變化

在不同規(guī)模數據集上，算法任務運行時間評測結果如圖9所示。FSACE算法相對其他2種算法，Flink任務的運行時間明顯減少，并且隨著數據集規(guī)模的增加，優(yōu)化效果更加明顯。實驗結果顯示，本文提出的算法由于結合了容器部署信息調度任務，使任務分布得更加均衡，從而提高了集群效率，減少了任務運行時間。本文算法也能夠將新分配的計算任務盡可能多地分配到計算資源豐富的結點所在的TaskManager容器中，并且能夠避免連續(xù)選擇某一結點，這樣使得計算資源豐富的結點能夠負擔更多的任務，而計算資源少的結點負擔相應少的任務，因此使Flink容器集群負載均衡，從而縮短任務的運行時間。

Figure 9 Comparison of task running time under different data set size圖9 不同規(guī)模數據集上任務運行時間對比

在不同并行度下，算法任務運行時間評測結果如圖10所示。并行度更高時，本文提出的FSACE算法相對其他2種算法的Flink任務的運行時間提升更加明顯。實驗結果顯示本文提出的算法有較好的可擴展性。

Figure 10 Comparison of task running time under different parallelism圖10 不同并行度下任務運行時間對比

Figure 11 Comparison of task running time under different container numbers圖11 不同容器數量下任務運行時間對比

在不同容器數量下，算法任務運行時間評測結果如圖11所示。實驗結果顯示，FSACE算法相對其他2種算法Flink的運行時間提升相對明顯。實驗結果表明，本文算法更適于多容器環(huán)境下部署。FSACE算法的運行時間比Flink默認的任務調度算法的運行時間少，平均運行時間少8%，顯示了本文算法在容器環(huán)境下部署Flink任務調度能有效提升任務運行效率。

在不同計算方面，算法任務運行時間評測結果如圖12所示。實驗結果顯示，TeraSort任務執(zhí)行時間比WordCount的任務執(zhí)行時間明顯要少，這是由于WordCount計算過程相對更加復雜，因此需要的任務執(zhí)行時間更多。實驗結果還顯示，FSACE算法在WordCount計算任務上的優(yōu)化效果比TeraSort計算任務更加明顯，其原因是TeraSort計算任務結點間的負載較均衡。

Figure 12 Running time of different computing tasks圖12 不同計算的任務運行時間

算法調度后任務均衡性評測結果如圖13所示。實驗結果表明，使用FSACE算法，容器集群中不同結點的CPU和內存資源使用更加均衡。這是由于FSACE算法在任務調度時結合了容器部署信息，從而使任務更均衡地分布在結點上。

Figure 13 Load comparison of cluster nodes圖13 集群結點負載對比

另外，本文對FSACE算法的任務調度時間與任務運行時間進行了評測，評測結果如圖14所示。實驗結果顯示，在任務調度算法方面，由于FSACE算法需要獲取容器部署信息，任務調度也比Flink默認算法復雜，因此任務調度稍慢于Flink。但是由于任務執(zhí)行時間占更主要部分，而FSACE算法能在容器環(huán)境下使任務分布得更加均衡，因此運行時間快于Flink。

Figure 14 Task running time comparison圖14 任務運行時間對比

綜上所述，在Flink容器集群中，在某些情況下，由于集群中運行著較多的提供不同服務的容器，導致每個結點的性能不一樣，FSACE使計算資源多的結點上的TaskManager容器被分配相對多的任務，而計算資源相對較少的結點上的TaskManager容器被分配相對較少的任務。這種任務分配策略能夠實現負載均衡，縮短任務的運行時間，避免了默認的Flink任務調度算法中由于計算資源少的結點中的TaskManager容器完成和其他結點同等的任務而影響整體作業(yè)的完成進度，因此能夠節(jié)省計算的時間，提高集群的計算效率。

6 結束語

本文首先介紹了容器環(huán)境下大數據處理引擎任務調度優(yōu)化的研究背景與意義，以及大數據處理引擎任務調度優(yōu)化方面的國內外研究現狀。之后介紹了本文使用的相關技術，并仔細研究了Flink默認調度算法，分析了其在容器環(huán)境下任務調度容易發(fā)生負載不均衡的問題，提出了適用于容器環(huán)境下的Flink任務調度算法。實驗結果表明，本文提出的FSACE算法，在容器集群中容器分布不均衡的情況下，能夠減少作業(yè)運行時間，使得負載均衡，提高整個集群的計算效率。

在未來計劃繼續(xù)進行以下幾方面的工作：

(1)使用更大規(guī)模的數據集驗證實驗效果；

(2)在進行任務調度優(yōu)化的過程中考慮不同算子的特點進一步進行優(yōu)化；

(3)根據不同的任務類型，調整CPU占用率和內存在評分中的權重，進一步優(yōu)化評分算法。