［陳杰 黃洋 張澤鑫 唐勇］

?

游戲數(shù)據(jù)分析智能任務(wù)調(diào)度架構(gòu)研究與實踐

［陳杰 黃洋 張澤鑫 唐勇］

摘要

針對常見的數(shù)據(jù)分析系統(tǒng)，缺少對系統(tǒng)資源的監(jiān)控及任務(wù)優(yōu)先級的考慮問題，本文提出通過采集集群中各臺主機(jī)性能指標(biāo)，分析系統(tǒng)的查詢?nèi)罩?，?gòu)建結(jié)合任務(wù)優(yōu)先級配置的智能調(diào)度框架，并詳細(xì)剖析其組件構(gòu)成、技術(shù)原理和實現(xiàn)流程等。依據(jù)實踐中的運(yùn)行效果，驗證和對比該架構(gòu)與傳統(tǒng)架構(gòu)在資源分配和運(yùn)行時間上的效率情況。

關(guān)鍵詞：數(shù)據(jù)分析 任務(wù)調(diào)度

陳杰

高級工程師，本科學(xué)歷畢業(yè)于南京郵電大學(xué)，現(xiàn)供職于炫彩互動網(wǎng)絡(luò)科技有限公司，研究方向為互聯(lián)網(wǎng)大型業(yè)務(wù)平臺技術(shù)架構(gòu)、大數(shù)據(jù)技術(shù)框架、通信技術(shù)和移動互聯(lián)網(wǎng)等。

黃洋

工程師，本科學(xué)歷畢業(yè)于南京人口管理干部學(xué)院，現(xiàn)供職于炫彩互動網(wǎng)絡(luò)科技有限公司，主要研究方向為大數(shù)據(jù)，移動互聯(lián)網(wǎng)等。

張澤鑫

工程師，碩士研究生學(xué)歷畢業(yè)于上海同濟(jì)大學(xué)，現(xiàn)供職于炫彩互動網(wǎng)絡(luò)科技有限公司，主要研究方向為大數(shù)據(jù)，移動互聯(lián)網(wǎng)等。

唐勇

高級工程師，博士研究生學(xué)歷畢業(yè)于東南大學(xué)，現(xiàn)供職于炫彩互動網(wǎng)絡(luò)科技有限公司，主要研究方向為大數(shù)據(jù)，手機(jī)游戲運(yùn)營平臺等。

1 引言

在互聯(lián)網(wǎng)業(yè)務(wù)中，數(shù)據(jù)分析系統(tǒng)是按照決策和管理要求，源于海量的互聯(lián)網(wǎng)業(yè)務(wù)數(shù)據(jù)，根據(jù)任務(wù)要求的先后關(guān)系生成的相關(guān)業(yè)務(wù)統(tǒng)計數(shù)據(jù)結(jié)果，作為業(yè)務(wù)決策和產(chǎn)品運(yùn)營手段調(diào)整的依據(jù)和來源，需要把數(shù)據(jù)信息以可靠和安全的方式呈現(xiàn)給管理者或使用者。

因互聯(lián)網(wǎng)業(yè)務(wù)相關(guān)數(shù)據(jù)具有相互關(guān)聯(lián)性，尤其是針對游戲平臺需要滿足成百上千的游戲產(chǎn)品數(shù)據(jù)同時統(tǒng)計，一個游戲產(chǎn)品的日活躍變化曲線和一段時間用戶活躍情況有關(guān)，而每天活躍度有和以當(dāng)天為時間軸前后幾天或一周之內(nèi)用戶登錄情況有關(guān)，這都給數(shù)據(jù)分析處理帶來了挑戰(zhàn)，建立一套完善的任務(wù)調(diào)度架構(gòu)，滿足任務(wù)合理調(diào)度成為關(guān)鍵所在。

常用的動態(tài)調(diào)度、靜態(tài)調(diào)度和同層劃分調(diào)度都有其適宜的場景，但缺乏針對系統(tǒng)資源的靈活調(diào)度和匹配，難以實現(xiàn)計算任務(wù)、系統(tǒng)資源調(diào)度、任務(wù)管理的統(tǒng)一，達(dá)到硬件和軟件資源的有機(jī)融合，提升效率和可靠性。

本文提供了一種結(jié)合系統(tǒng)資源查詢游戲數(shù)據(jù)分析智能動態(tài)調(diào)度架構(gòu)，增加了系統(tǒng)資源的監(jiān)控及任務(wù)優(yōu)先級的考慮，在任務(wù)有效調(diào)度的同時，實現(xiàn)硬件資源的負(fù)載均衡。

2 數(shù)據(jù)分析任務(wù)調(diào)度方案現(xiàn)狀

目前市面上數(shù)據(jù)分析系統(tǒng)的任務(wù)調(diào)度，主要有3種任務(wù)調(diào)度方案，分別是：動態(tài)調(diào)度，靜態(tài)調(diào)度和同層劃分調(diào)度。調(diào)度的單位可以是單個任務(wù)或一批任務(wù)。

動態(tài)調(diào)度方案，此方案是以單個任務(wù)為調(diào)度單位的方案。其調(diào)度策略是：調(diào)度進(jìn)程首先順序掃描任務(wù)列表，對于那些前驅(qū)數(shù)為零的任務(wù)，直接產(chǎn)生線程并提交給操作系統(tǒng)，直至等待線程結(jié)束的信號。任務(wù)執(zhí)行器發(fā)現(xiàn)任務(wù)執(zhí)行結(jié)束后，更新任務(wù)流圖中的優(yōu)先信息，將以該任務(wù)為前驅(qū)的任務(wù)的前驅(qū)計數(shù)值減1，一旦發(fā)現(xiàn)任務(wù)流圖中的某個任務(wù)的前驅(qū)任務(wù)數(shù)為零，則創(chuàng)建新的線程執(zhí)行該任務(wù)。

靜態(tài)調(diào)度方案，主要面向所有待調(diào)度的任務(wù)是預(yù)先知道的，執(zhí)行具有相對的穩(wěn)定性的任務(wù)，因此靜態(tài)調(diào)度只需要按照事先定義的順序，排序在前的先執(zhí)行，排序在后的后執(zhí)行。

同層劃分調(diào)度方案，實際應(yīng)用中，任務(wù)流圖的深度并不深，而圖的寬度卻很寬。另外，在報表原始數(shù)據(jù)組織中是分層的，如日志層、清單層、報表層等，因而可按層次調(diào)度任務(wù)執(zhí)行。

以上這3種方案各有優(yōu)缺點及適用場景，但都缺少對系統(tǒng)資源的監(jiān)控及任務(wù)優(yōu)先級的考慮。生產(chǎn)環(huán)境下系統(tǒng)的資源是固定的，即便采用上文的動態(tài)調(diào)度方案，如果不考慮到系統(tǒng)資源使用率，無限制的創(chuàng)建進(jìn)程并發(fā)，系統(tǒng)負(fù)擔(dān)過大，不僅不會加快數(shù)據(jù)結(jié)果的生產(chǎn)效率，可能還會帶來系統(tǒng)的宕機(jī)，造成延誤。每日系統(tǒng)上的成千上萬的計算任務(wù)，他們的價值度是不一致的，需要考慮任務(wù)的優(yōu)先級，優(yōu)先將系統(tǒng)資源分配給高價值的任務(wù)，從而實現(xiàn)數(shù)據(jù)分析結(jié)果的價值最大化。

3 游戲數(shù)據(jù)分析智能調(diào)度架構(gòu)實踐

下文給出的游戲數(shù)據(jù)分析任務(wù)智能調(diào)度架構(gòu)中，采用系統(tǒng)資源采集器來采集集群中各臺主機(jī)性能指標(biāo)，查詢?nèi)罩痉治銎鞣治稣故鞠到y(tǒng)的查詢?nèi)罩緩亩贸鋈蝿?wù)的優(yōu)先級，智能調(diào)度框架中根據(jù)依賴關(guān)系分析、調(diào)度日志、分析器參數(shù)、采集器參數(shù)為任務(wù)前序檢查參數(shù)，檢查通過后動態(tài)調(diào)度任務(wù)運(yùn)行。

3.1 總體架構(gòu)分析

如圖1所示，總體架構(gòu)主要分為3個結(jié)構(gòu)，查詢?nèi)罩痉治銎鳌⑾到y(tǒng)資源采集器、智能調(diào)度框架。優(yōu)先滿足使用頻率較高，同時為了更好地利用資源，結(jié)合系統(tǒng)性能，并發(fā)調(diào)度報表。結(jié)合報表使用情況，優(yōu)先滿足價值度較高報表。

圖1 總體框架結(jié)構(gòu)示意圖

3.2 系統(tǒng)組件構(gòu)成

總體架構(gòu)分系統(tǒng)資源采集器、查詢?nèi)罩痉治銎?、智能調(diào)度框架三大組件，下文將詳細(xì)介紹其作用及工作原理。

3.2.1 系統(tǒng)資源采集器（如圖2所示）

集群中每臺主機(jī)的性能是不一致的，工作過程中忙閑程度也是不一致的，當(dāng)系統(tǒng)需要執(zhí)行任務(wù)時，應(yīng)該由集群中的哪個節(jié)點具體去執(zhí)行，怎樣才能最大化且最合理地利用集群資源，這一直是難以決策的問題。系統(tǒng)資源采集器主要是從集群中的各臺主機(jī)上采集系統(tǒng)性能數(shù)據(jù)，供動態(tài)調(diào)度框架調(diào)用分析，從而當(dāng)任務(wù)提交時，可將任務(wù)分配給系統(tǒng)資源最適合的一臺機(jī)器去執(zhí)行，若系統(tǒng)資源緊張，則任務(wù)等待系統(tǒng)有資源后執(zhí)行，避免造成壓力。

圖2 系統(tǒng)資源采集器結(jié)構(gòu)示意圖

采集各主機(jī)性能，我們使用Collect Agent。Collect Agent基于Java語言開發(fā)，封裝系統(tǒng)信息采集能力。將其部署于集群中各主機(jī)本地，可實時采集系統(tǒng)數(shù)據(jù)。Collect Agent下層通過JNI（Java Native Interface）接口進(jìn)行本地系統(tǒng)調(diào)用，進(jìn)行各類性能數(shù)據(jù)的采集，目前主要采集進(jìn)程信息與硬件信息。系統(tǒng)資源采集器通過RMI遠(yuǎn)程對象調(diào)用接口接受動態(tài)調(diào)度框架的性能采集請求，并將采集結(jié)果返回給動態(tài)調(diào)度框架中的采集器參數(shù)列表。其中進(jìn)程信息采集負(fù)責(zé)采集主機(jī)上運(yùn)行的進(jìn)程的各類信息，包括進(jìn)程名、參數(shù)、進(jìn)程ID、來源文件等；硬件信息采集負(fù)責(zé)采集主機(jī)的硬件配置等信息，包括磁盤空間、內(nèi)存容量、CPU占用率、設(shè)備狀態(tài)等。

3.2.2 查詢?nèi)罩痉治銎鳎ㄈ鐖D3所示）

圖3 查詢?nèi)罩痉治銎鹘Y(jié)構(gòu)示意圖

查詢?nèi)罩痉治銎髦饕槍ζ脚_記錄的查詢?nèi)罩具M(jìn)行分析，查詢?nèi)罩局辽賾?yīng)具備分析結(jié)果唯一標(biāo)示、用戶唯一標(biāo)示、查詢時間這3個參數(shù)，以便分析各分析任務(wù)使用情況，通過這3個參數(shù)，我們至少可以計算出每個分析任務(wù)在某個時間段內(nèi)使用用戶數(shù)、使用次數(shù)這兩個基礎(chǔ)指標(biāo)，通過分析任務(wù)價值度算法得出每個數(shù)據(jù)結(jié)果的價值度，根據(jù)價值度從高往低排序，從而確定任務(wù)的優(yōu)先級。

任務(wù)價值度是為了通過直觀的數(shù)值方式，反饋出上一個周期內(nèi)各任務(wù)分析結(jié)果使用情況，從而針對各任務(wù)不同的使用情況，分配不同的系統(tǒng)資源。對于其中價值度過低的任務(wù)，啟動主動退出機(jī)制，完善展示任務(wù)的生命周期。

展示任務(wù)價值度當(dāng)前主要參考4個關(guān)于結(jié)果使用及結(jié)果生成維度，結(jié)果使用天數(shù)（Vd）、結(jié)果使用用戶數(shù)（Vu）、結(jié)果可查詢用戶數(shù)（Vc）、結(jié)果生成平均時長（Vt）。由此得出對應(yīng)任務(wù)的價值度算法公式：f(V)= Vd * Vu / Vc * K - Vt，其中K為常數(shù)，暫定7.9。

3.2.3 智能調(diào)度框架

數(shù)據(jù)分析程序在運(yùn)行時，對于數(shù)據(jù)來源的依賴很大，不同的分析任務(wù)在生成時需要從不同的數(shù)據(jù)源表獲取數(shù)據(jù)來進(jìn)行計算。這就導(dǎo)致不同的任務(wù)程序有著不同的先后運(yùn)行順序和時間軸。隨著業(yè)務(wù)的擴(kuò)展，任務(wù)程序間的相互依賴就變得更加錯綜復(fù)雜，以單純的人工梳理，定時運(yùn)行的方式難以有效維護(hù)整體的任務(wù)程序調(diào)度，導(dǎo)致程序在不同的時間點上或者會搶占資源，或者會空閑資源。而本系統(tǒng)采用的智能調(diào)度框架，進(jìn)行程序調(diào)度的話只需要簡單的配置即可將新的任務(wù)程序加入到系統(tǒng)調(diào)度中。

任務(wù)程序的依賴關(guān)系分析過程，主要依據(jù)于任務(wù)程序的源碼分析。依賴關(guān)系分析程序首先需要獲取任務(wù)程序的源碼，對于數(shù)據(jù)庫任務(wù)程序來說一般是存儲過程，對于分布式計算框架則可能是java程序等。對于不同的系統(tǒng)架構(gòu)和開發(fā)語言，具體的源碼分析程序和細(xì)節(jié)算法可能不同，但是其總體思路是一致的。

依賴關(guān)系分析主要分為兩個過程：

第一步，需要解析目標(biāo)任務(wù)程序的源碼，獲取該程序讀取和寫入的具體表名。這一步在獲取了任務(wù)程序的源代碼之后，首先需要過濾代碼中的注釋。刪除注釋后依據(jù)程序的編程語法，將源程序分解成獨立的語句。對于不同的編程語言，其讀取和寫入數(shù)據(jù)庫表的操作關(guān)鍵字都是確定的，其語法順序也是明確的，因此可以通過解析相應(yīng)的關(guān)鍵字和語法來獲取程序的讀取和寫入表。對源碼的文本解析方法較多，包括逐字符串自行規(guī)則制定解析和基于正則表達(dá)式匹配的解析方法等。

第二步，是基于第一步解析完成所有需要運(yùn)行調(diào)度的任務(wù)程序之后，對所有的任務(wù)程序都計算出其寫入和讀取的具體結(jié)果名稱之后，進(jìn)行的任務(wù)程序之間的依賴關(guān)系分析。對于已經(jīng)解析完結(jié)果依賴的任務(wù)程序，其結(jié)果數(shù)據(jù)依賴分為讀取和寫入兩種。亦即每個任務(wù)程序分別包含兩個列表，列表元素分別為其寫入的數(shù)據(jù)庫表和讀取的數(shù)據(jù)庫表，設(shè)寫入列表為listWrite，讀取列表為listRead。在獲取目標(biāo)程序（設(shè)為targetProc）的先驅(qū)執(zhí)行程序時，需要獲取該程序listRead的所有元素；同時對于所有的任務(wù)程序（設(shè)為referProc），依此比對其listWrite的所有元素與目標(biāo)程序的讀取表列表。當(dāng)targetProc.listRead與refetProc.listWrite的交集不為空時，則認(rèn)為targetProc的執(zhí)行依賴于refetProc，即targetProc需要在referProc之后調(diào)度運(yùn)行。

程序與程序之間的調(diào)度依賴關(guān)系分析時，需要注意的一點是應(yīng)當(dāng)通過與系統(tǒng)中已有的列表進(jìn)行校對，避免第一步文本分析過程解析不完全導(dǎo)致獲取的結(jié)果實際并不符合系統(tǒng)的數(shù)據(jù)庫表，如圖4所示。

圖4 獲取過程之間的依賴關(guān)系過程示意圖

在獲取了數(shù)據(jù)分析中各個獨立執(zhí)行的任務(wù)程序之間的調(diào)度依賴關(guān)系之后，結(jié)合系統(tǒng)資源采集和查詢?nèi)罩痉治龅慕Y(jié)果，可以計算出一個或者多個執(zhí)行隊列，將報表程序依照隊列順序進(jìn)行調(diào)度執(zhí)行。

依賴關(guān)系分析程序解決了任務(wù)程序在運(yùn)行調(diào)度上的初始化調(diào)度隊列問題，使任務(wù)程序的運(yùn)行調(diào)度不再依賴于人工指定的時間節(jié)點和順序，可以依據(jù)系統(tǒng)負(fù)載、報表價值度來自行調(diào)整和分配任務(wù)程序的運(yùn)行。但是在任務(wù)系統(tǒng)運(yùn)行的過程中，還有另一個問題：對于異常程序的處理。

任務(wù)程序在運(yùn)行中，可能由于業(yè)務(wù)或者系統(tǒng)的影響，造成了程序的異常和執(zhí)行失敗。而任務(wù)程序的運(yùn)行，會對其他任務(wù)程序?qū)懭氲臄?shù)據(jù)有所依賴，因此當(dāng)某個程序產(chǎn)生異常時，將不會寫入相關(guān)數(shù)據(jù)。這就導(dǎo)致執(zhí)行隊列隨后對其依賴的程序無法正確執(zhí)行，或者同樣發(fā)生異常。

為了解決此問題，系統(tǒng)在決定執(zhí)行調(diào)度隊列中的某個程序時，需要去查詢該任務(wù)程序的先驅(qū)依賴程序的運(yùn)行結(jié)果日志。只有當(dāng)該程序所有的先驅(qū)依賴程序都成功運(yùn)行完畢之后，該程序才可以調(diào)度執(zhí)行；否則，該程序應(yīng)當(dāng)處于等待狀態(tài)。

若程序一次性執(zhí)行成功，則系統(tǒng)查詢該程序運(yùn)行日志時只會返回一條結(jié)果，此時不會影響其后驅(qū)依賴程序的調(diào)度運(yùn)行；但如果程序首次執(zhí)行失敗，之后重新執(zhí)行成功，則系統(tǒng)查詢時會返回多條運(yùn)行結(jié)果日志，并且包含失敗日志。失敗日志會阻塞后驅(qū)依賴程序的調(diào)度，所以系統(tǒng)應(yīng)當(dāng)在運(yùn)行日志產(chǎn)生時，進(jìn)行運(yùn)行日志的合并操作。

運(yùn)行日志的合并操作可以有多種解決方式，包括生成的新日志復(fù)寫舊日志、查詢時只選擇時間點最近的日志記錄等等。需要注意的是，要保證程序成功執(zhí)行后，不論該程序是否有過失敗日志，系統(tǒng)都要以該次成功運(yùn)行日志作為調(diào)度后驅(qū)依賴程序的依據(jù)。

4 游戲數(shù)據(jù)分析任務(wù)智能調(diào)度架構(gòu)應(yīng)用效果展示

在不進(jìn)行系統(tǒng)資源查詢和依據(jù)系統(tǒng)資源進(jìn)行智能任務(wù)調(diào)度時，系統(tǒng)調(diào)度的規(guī)則是由開發(fā)人員人為分配的，容易導(dǎo)致系統(tǒng)資源的分配不夠合理，部分節(jié)點高負(fù)荷運(yùn)行的同時，其他節(jié)點則處于閑置狀態(tài)，如圖5所示。

圖5 使用動態(tài)調(diào)度架構(gòu)前CPU負(fù)載率

而結(jié)合系統(tǒng)資源查詢的數(shù)據(jù)分析任務(wù)智能調(diào)度框架，可以根據(jù)系統(tǒng)各個節(jié)點的實際負(fù)載情況，將即將執(zhí)行的任務(wù)分配到較為空閑的節(jié)點上運(yùn)行，達(dá)到負(fù)載均衡的目的。如圖6所示。

圖6 使用動態(tài)報表架構(gòu)后CPU負(fù)載率

在未啟用智能調(diào)度框架時，系統(tǒng)需要線形在指定的時間點順序執(zhí)行展示任務(wù)，所以即便有多個節(jié)點，但是使用率很低，整個任務(wù)程序運(yùn)行完成時間等于所有任務(wù)程序的運(yùn)行時間總和。

而當(dāng)系統(tǒng)使用智能調(diào)度框架時，結(jié)合系統(tǒng)各個節(jié)點負(fù)載情況，可以將隊列中滿足執(zhí)行條件的任務(wù)自動分配到負(fù)載較低的節(jié)點上，從而達(dá)到任務(wù)程序并行執(zhí)行的目的，使整體任務(wù)程序運(yùn)行的時間遠(yuǎn)小于所有任務(wù)程序運(yùn)行時間的總和，與計算時間最長的任務(wù)鏈條所消耗時間基本一致。

5 結(jié)束語

本文介紹了采用系統(tǒng)資源采集器來采集集群中各臺主機(jī)性能指標(biāo)，查詢?nèi)罩痉治銎鞣治鰯?shù)據(jù)分析系統(tǒng)的查詢?nèi)罩緩亩贸龇治鋈蝿?wù)優(yōu)先級的方法，提出一種創(chuàng)新的游戲數(shù)據(jù)分析任務(wù)智能調(diào)度框架，將任務(wù)調(diào)度與依賴關(guān)系分析、調(diào)度日志、分析器參數(shù)、采集器參數(shù)關(guān)聯(lián)，解決傳統(tǒng)方法任務(wù)調(diào)度缺少對系統(tǒng)資源的監(jiān)控及任務(wù)優(yōu)先級考慮的問題。在實踐過程中，該種架構(gòu)能夠自動實現(xiàn)各處理節(jié)點的動態(tài)均衡，節(jié)省程序的運(yùn)行時間。該框架具有通用性，能夠為其他業(yè)務(wù)數(shù)據(jù)系統(tǒng)提供了良好的參考和借鑒。

參考文獻(xiàn)

1朱煒昊，《基于RMI和JNI的主機(jī)性能采集Agent的設(shè)計與實現(xiàn)》，中國科技論文在線，2009

2史捷，鮑玉斌，劉運(yùn)濤，張斌，孫煥良，于戈，《數(shù)據(jù)倉庫系統(tǒng)中任務(wù)調(diào)度策略研究》，控制與決策，2005年1月

3蘇洋、劉曉軍，唐勇，黃洋，《游戲大數(shù)據(jù)平臺研究與實踐》，電信科學(xué)，2014年10期

4唐云善等，《一種高效的大數(shù)據(jù)實時性解決方案》，計算機(jī)與數(shù)字工程， 2014年04期

5趙輝等，《基于MapReduce模型的范圍查詢分析優(yōu)化技術(shù)研究》，計算機(jī)研究與發(fā)展2014

DOI:10.3969/j.issn.1006-6403.2016.02.005

收稿日期：（2016-01-12）