游戲大數(shù)據(jù)平臺工作流引擎研究與實(shí)踐

陳杰，武娟，蘇洋，唐勇

（1.炫彩互動(dòng)網(wǎng)絡(luò)科技有限公司，江蘇南京210029；2.中國電信股份有限公司廣州研究院，廣東廣州510630）

運(yùn)營技術(shù)廣角

游戲大數(shù)據(jù)平臺工作流引擎研究與實(shí)踐

陳杰1，武娟2，蘇洋1，唐勇1

（1.炫彩互動(dòng)網(wǎng)絡(luò)科技有限公司，江蘇南京210029；2.中國電信股份有限公司廣州研究院，廣東廣州510630）

隨著業(yè)務(wù)人員對數(shù)據(jù)分析的需求不斷增加，基于開源Hadoop的游戲大數(shù)據(jù)平臺運(yùn)行著越來越多相互依賴的作業(yè)任務(wù)。為了更加高效地完成作業(yè)管理和調(diào)度，升級了Zeus構(gòu)建工作流引擎，優(yōu)化Zeus任務(wù)啟動(dòng)過程，實(shí)現(xiàn)了多線程啟動(dòng)任務(wù)，縮短了啟動(dòng)時(shí)間。通過擴(kuò)展Zeus系統(tǒng)，使其支持Oracle存儲過程。同時(shí)，利用管道技術(shù)，實(shí)現(xiàn)了異構(gòu)數(shù)據(jù)源的無縫高效共享和傳輸。

大數(shù)據(jù)作業(yè)；工作流；開源

1 引言

基于Hadoop的開源大數(shù)據(jù)系統(tǒng)經(jīng)歷了多個(gè)版本的開發(fā)，技術(shù)更加成熟、性能更加穩(wěn)定，眾多企業(yè)和團(tuán)隊(duì)基于Hadoop系統(tǒng)，輔以Hive、HBase等工具搭建滿足自身業(yè)務(wù)數(shù)據(jù)分析需求的大數(shù)據(jù)平臺。為了滿足作業(yè)調(diào)度和執(zhí)行的批量管理、自動(dòng)處理、狀態(tài)監(jiān)控等需求，業(yè)務(wù)復(fù)雜的大數(shù)據(jù)分析平臺需要一套工作流引擎工具，將作業(yè)之間的依賴關(guān)系、執(zhí)行順序、狀態(tài)管理等有效銜接，從而提高作業(yè)任務(wù)的生產(chǎn)、運(yùn)行、管理效率。

本文介紹了游戲大數(shù)據(jù)平臺的現(xiàn)狀和主流大數(shù)據(jù)工作流引擎，重點(diǎn)研究游戲大數(shù)據(jù)平臺引入開源的宙斯（Zeus）工作流引擎系統(tǒng)的過程和效果，并針對自身業(yè)務(wù)需求在其基礎(chǔ)上實(shí)現(xiàn)二次功能的開發(fā)和增強(qiáng)。

2 游戲大數(shù)據(jù)平臺概述

目前游戲平臺上支持手機(jī)游戲、智能電視游戲、PC游戲及HTML5游戲等多種業(yè)務(wù)，日志數(shù)據(jù)源達(dá)數(shù)十種，按其存儲類型可分為Oracle、MySQL、SQLSever、FTP、Local FileSystem等。為處理種類繁多的業(yè)務(wù)，游戲大數(shù)據(jù)平臺的單集群節(jié)點(diǎn)數(shù)約為50臺服務(wù)器，日新增數(shù)據(jù)量約為0.5 TB，日均Hadoop job（作業(yè)）數(shù)為300余個(gè)，日均計(jì)算量為100億余行。

游戲大數(shù)據(jù)平臺［1］架構(gòu)以HDFS為基礎(chǔ)，其上部署Hadoop、HBase、Hive、Storm等子系統(tǒng)，平臺結(jié)構(gòu)如圖1所示，各部分作用說明如下。

圖1 游戲大數(shù)據(jù)平臺架構(gòu)

·HDFS：構(gòu)建分布式文件系統(tǒng)，所有的數(shù)據(jù)都存儲在這里，并對數(shù)據(jù)進(jìn)行了分塊。

·HBase：針對特殊場景下對處理速度與處理效率的要求，實(shí)現(xiàn)快速數(shù)據(jù)檢索。

·Storm：降低實(shí)時(shí)處理的復(fù)雜性，并且支持多種語言，提升開發(fā)效率。

·Flume：主要用于海量日志收集，采用分布式模式，對海量日志進(jìn)行采集傳輸。

·ZooKeeper：提供一致性服務(wù)，實(shí)現(xiàn)各節(jié)點(diǎn)高效、可靠的協(xié)同工作。

·MapReduce：大數(shù)據(jù)分治處理方法，是一種編程模型。

·Hive：基于Hadoop的一種結(jié)構(gòu)化數(shù)據(jù)倉庫，提供了簡單的類SQL查詢功能。

游戲大數(shù)據(jù)平臺數(shù)據(jù)流轉(zhuǎn)的關(guān)系如圖2所示，游戲原始的業(yè)務(wù)數(shù)據(jù)通過文件系統(tǒng)進(jìn)入大數(shù)據(jù)平臺存儲和處理，經(jīng)過簡單的清洗和分類轉(zhuǎn)變?yōu)榻?jīng)營分析數(shù)據(jù)存放于數(shù)據(jù)倉庫，然后由大數(shù)據(jù)平臺運(yùn)行成百上千個(gè)Hadoop作業(yè)，分析計(jì)算出所需結(jié)果后提交給各個(gè)業(yè)務(wù)系統(tǒng)接口，可以看出，大數(shù)據(jù)平臺的數(shù)據(jù)工作流程是有序的，可以由程序化軟件控制自動(dòng)完成整個(gè)工作流程。

3 大數(shù)據(jù)平臺工作流引擎

3.1 引擎選型

早期游戲平臺采用的大數(shù)據(jù)任務(wù)調(diào)度方式為Linux自帶的crontab方式，即使用Linux的定時(shí)執(zhí)行指令，每分鐘檢查是否有預(yù)定的cron job需要執(zhí)行。為規(guī)范化執(zhí)行作業(yè)任務(wù)，統(tǒng)一將一個(gè)個(gè)Hadoop job拆分為數(shù)據(jù)準(zhǔn)備、邏輯計(jì)算、結(jié)果輸出3個(gè)步驟，然后封裝成Linux shell腳本，配置至cron job中定時(shí)執(zhí)行。這種調(diào)度方式的好處就是簡單、穩(wěn)定，在業(yè)務(wù)需求相對簡單、作業(yè)任務(wù)較少的應(yīng)用場景，此方法完全可以滿足需求。

圖2 游戲大數(shù)據(jù)平臺數(shù)據(jù)流轉(zhuǎn)關(guān)系

隨著定時(shí)任務(wù)數(shù)量的增加，任務(wù)之間的關(guān)系越來越復(fù)雜，crontab方法存在的不足也日益突出：首先是不易管理，所有任務(wù)均部署在配置文件中，增、刪、改、查均不直觀；二是安全性較差，團(tuán)隊(duì)成員均可獨(dú)立修改crontab配置文件，容易相互影響；三是任務(wù)之間的依賴關(guān)系只能實(shí)現(xiàn)簡單的定時(shí)執(zhí)行，配置容易出錯(cuò)；四是任務(wù)監(jiān)控、錯(cuò)誤處理沒有統(tǒng)一的框架級解決方案。這些問題使得游戲大數(shù)據(jù)平臺迫切需要一套完整的用于管理和調(diào)度作業(yè)任務(wù)的工作流引擎系統(tǒng)。

Apache Oozie［2］是用于Hadoop平臺的開源工作流調(diào)度引擎。該框架使用XML定義工作流，由Oozie協(xié)調(diào)器管理作業(yè)之間的相互依賴關(guān)系，可以使用預(yù)定的時(shí)間或數(shù)據(jù)可用性來觸發(fā)Oozie。Oozie支持多種action，即工作流節(jié)點(diǎn)的執(zhí)行操作，例如支持Hadoop MapReduce（MR）、pig、Hive、shell和Java等類型的作業(yè)，所有的action以有向無環(huán)圖（direct acyclic graph，DAG）的模式運(yùn)行。在action的運(yùn)行步驟上是有方向的，只能等上一個(gè)action運(yùn)行完成后才能運(yùn)行下一個(gè)action。

Azkaban［3］是LinkedIn公司提出的另一個(gè)優(yōu)秀的開源任務(wù)調(diào)度系統(tǒng)，操作比Oozie要簡單［4］，它使用屬性（property）文件定義工作流。Azkaban以預(yù)定義的一個(gè)或多個(gè)可存在依賴關(guān)系的作業(yè)組成的工作流（flow）為執(zhí)行單元進(jìn)行定時(shí)調(diào)度。Azkaban支持pig、Java、shell、MapReduce類型的作業(yè)，從版本2.1開始，Azkaban也支持Hive類型的作業(yè)。

Zeus［5］是由阿里巴巴集團(tuán)開發(fā)的一個(gè)分布式設(shè)計(jì)水平擴(kuò)展的開源作業(yè)工作流引擎，以可視化界面的方式管理與調(diào)度Hadoop上的任務(wù)，Zeus 2支持Hadoop 2.0以上版本的系統(tǒng)。

如圖3所示，Zeus系統(tǒng)主要包含界面（Web UI）、作業(yè)調(diào)度（job scheduler）和作業(yè)執(zhí)行（job worker）3個(gè)角色，其中Web UI提供可視化頁面訪問，作業(yè)調(diào)度負(fù)責(zé)作業(yè)任務(wù)的調(diào)度、恢復(fù)等，作業(yè)執(zhí)行負(fù)責(zé)完成調(diào)度指派的任務(wù)。

圖3 Zeus任務(wù)調(diào)度流程

Zeus支持任務(wù)之間復(fù)雜依賴關(guān)系的設(shè)置，依賴任務(wù)零時(shí)延觸發(fā)，有完備的報(bào)警系統(tǒng)，能夠與其他系統(tǒng)通過ZooKeeper進(jìn)行聯(lián)動(dòng)。Zeus支持Hadoop MapReduce、Hive、shell等作業(yè)類型，相對于Oozie和Azkaban，Zeus支持的作業(yè)類型較少，目前尚不支持pig、flume、sqoop等作業(yè)類型，但對Hive的支持比較完備，例如支持Hive元數(shù)據(jù)的可視化查詢與數(shù)據(jù)預(yù)覽，有完整的文檔管理，因此對于以Hive為主要分析工具的游戲大數(shù)據(jù)平臺來說，選擇Zeus作為工作流引擎更加貼合國內(nèi)業(yè)務(wù)平臺的需求、更加易用，而且通過二次開發(fā)可以進(jìn)一步優(yōu)化Zeus系統(tǒng)。

3.2 對Zeus系統(tǒng)的改進(jìn)

游戲大數(shù)據(jù)平臺引入Zeus系統(tǒng)后，發(fā)現(xiàn)Zeus系統(tǒng)在執(zhí)行任務(wù)調(diào)度時(shí)，任務(wù)啟動(dòng)所消耗的時(shí)間較長，在作業(yè)數(shù)較多的情況下，啟動(dòng)任務(wù)的時(shí)間比較長，有必要進(jìn)一步改進(jìn)優(yōu)化任務(wù)啟動(dòng)過程。

另外，原生Zeus系統(tǒng)不支持Oracle存儲過程，由于大數(shù)據(jù)平臺目前部分報(bào)表生成工作仍使用Oracle存儲過程執(zhí)行，因此，需要對Zeus進(jìn)行一定的擴(kuò)展，使其能夠支持Oracle存儲過程。

最后，Zeus系統(tǒng)在異構(gòu)數(shù)據(jù)源之間的數(shù)據(jù)同步?jīng)]有便捷的實(shí)現(xiàn)，運(yùn)行的Hive查詢結(jié)果也不方便導(dǎo)出成文件，這方面可通過第三方工具實(shí)現(xiàn)異構(gòu)數(shù)據(jù)的同步。

3.2.1 優(yōu)化任務(wù)啟動(dòng)方式

在Zeus任務(wù)調(diào)度過程中，根據(jù)業(yè)務(wù)拆分的作業(yè)比較小，但啟動(dòng)非常頻繁，每個(gè)作業(yè)的執(zhí)行時(shí)間短，通過執(zhí)行的日志發(fā)現(xiàn)，有時(shí)會出現(xiàn)一個(gè)作業(yè)的啟動(dòng)時(shí)間很長，需要幾十秒。由于業(yè)務(wù)上很看重增量的速度，幾十秒的等待對業(yè)務(wù)系統(tǒng)來說不可接受。

游戲大數(shù)據(jù)平臺使用的是Hadoop 2.6.0版本，仔細(xì)分析TaskTracker的日志發(fā)現(xiàn)，Child子進(jìn)程啟動(dòng)過程中，存在過長時(shí)間等待的問題。從Zeus源碼可以看到，Child子進(jìn)程啟動(dòng)是在一個(gè)線程中串行完成，啟動(dòng)過程包括DistributedCache文件的獲取。由于Hadoop集群同時(shí)可能有各種各樣的任務(wù)提交，當(dāng)某個(gè)任務(wù)的啟動(dòng)時(shí)間長時(shí)，會影響下一個(gè)任務(wù)的啟動(dòng)，嚴(yán)重時(shí)甚至?xí)绊慣askTracker發(fā)送心跳信息。

因此，需要通過修改TaskTracker的工作方式，徹底優(yōu)化啟動(dòng)時(shí)間。最簡單的辦法是讓每個(gè)任務(wù)各自通過一個(gè)任務(wù)線程來啟動(dòng)，以避免各個(gè)任務(wù)之間的競爭，從根本上解決這個(gè)問題。

class StartNewTask extends Thread｛

默認(rèn)將線程任務(wù)成員變量置空

public StartNewTask（TaskInProgress tip）｛

構(gòu)造函數(shù)，根據(jù)傳參初始化線程任務(wù)對象

}

public void run（）｛

try｛

調(diào)用StartNewTask方法，執(zhí)行線程

}catch（InterruptedException e）｛

/返回異常原因

}catch（Throwable th）｛

/錯(cuò)誤處理

}

}

}

以上方法需要在TaskLauncher.run（）中增加new StartNewTask（tip）.start（），這帶入了新的問題，TaskTracker中關(guān)于正在運(yùn)行的任務(wù)有兩種鎖，一個(gè)是runningJobs，用來鎖住對Map＜JobID，RunningJob＞runningJobs的訪問，這個(gè)HashMap里存在的是正在運(yùn)行的所有任務(wù)；另一個(gè)是rJob，用來存放單個(gè)任務(wù)的信息。原版的代碼中，是先獲得runningJobs鎖，再獲得rJob鎖，最后再釋放runningJobs鎖，代碼如下：

private RunningJob addTaskToJob（JobID jobId，TaskInProgress tip）｛

同步代碼塊（runningJobs）｛

初始化RunningJob對象rJob為空值；

if（runningJobs中找不到j(luò)obId對象）｛

/新建RunningJob

}else｛

/獲取RunningJob的JobId

}

同步代碼塊（rJob）｛

將tip對象增加到rJob對象的task成員中

}

返回rJob對象；

}

}

由于setupCache的操作是在rJob鎖里完成，會間接導(dǎo)致runningJobs一直等待rJob，這時(shí)即使任務(wù)啟動(dòng)的是多線程任務(wù)，也會由于別的任務(wù)在下載DistributedCache，長期占用rJob的鎖，導(dǎo)致其他線程的runningJobs等待rJob，使得當(dāng)前的任務(wù)啟動(dòng)后再無法獲得runningJobs。

有一種比較直接的方法，即強(qiáng)行把runningJobs和rJob分開，只有在更新runningJobs時(shí)，才需要獲得鎖，且鎖住的范圍不包括rJob。這樣做的改動(dòng)范圍大，而且容易出錯(cuò)，造成死鎖。

參考MAPREDUCE-2364補(bǔ)丁包［6］的解決辦法，游戲大數(shù)據(jù)平臺采取的是當(dāng)下載DistributedCache時(shí)，去掉rJob鎖，從而使runningJobs和rJob鎖住的操作中，沒有長時(shí)間的任務(wù)。通過增加以下兩個(gè)變量：volatile boolean localized和boolean localizing（這兩個(gè)變量控制是否需要下載DistributedCache），從而去掉rJob鎖。最終，改進(jìn)的Hadoop版本，包括實(shí)現(xiàn)了多線程啟動(dòng)任務(wù)和MAPREDUCE-2364的patch。

3.2.2 支持Oracle存儲過程

由于歷史原因，游戲業(yè)務(wù)平臺仍然有一部分報(bào)表計(jì)算任務(wù)使用Oracle存儲過程完成，但Oracle存儲過程的調(diào)度仍然獨(dú)立于Hadoop、Hive、shell任務(wù)。為了使Oracle存儲過程任務(wù)與Hadoop、Hive、shell任務(wù)建立依賴關(guān)系，需要對Zeus系統(tǒng)進(jìn)行改造升級。在Zeus宿主機(jī)器上安裝Oracle客戶端，并修改Zeus UI使其支持*.sql腳本，然后利用shell腳本調(diào)用Zeus系統(tǒng)中對應(yīng)的*.sql文件，最后將其加載至Oracle中執(zhí)行，并返回執(zhí)行狀態(tài)碼。

為使存儲過程的開發(fā)更加簡單，還需要將Java和SQL代碼混合，定制解析器，利用解析器把混合在里面的SQL語句變成“字符串”加入Java代碼中，生成Java類源碼。然后由Java編譯器把第一步生成的Java類源碼編譯為class文件。使用Java類加載器加載第二步生成的class文件并運(yùn)行，運(yùn)行后將生成純SQL語句。最后再調(diào)用Oracle專用存儲過程將SQL語句加載至Oracle中執(zhí)行。

3.2.3 異構(gòu)數(shù)據(jù)源同步

為了滿足非結(jié)構(gòu)化數(shù)據(jù)庫Hive和結(jié)構(gòu)化數(shù)據(jù)庫Oracle之間異構(gòu)數(shù)據(jù)的快速同步要求，彌補(bǔ)Zeus系統(tǒng)缺乏異構(gòu)數(shù)據(jù)同步功能的缺憾，游戲大數(shù)據(jù)平臺還引入sqluldr2數(shù)據(jù)導(dǎo)出工具，基于文本文件格式+管道技術(shù)，實(shí)現(xiàn)異構(gòu)數(shù)據(jù)源的無縫高效共享和傳輸。

文本文件作為基礎(chǔ)的文件格式，數(shù)據(jù)庫軟件普遍支持，并且能夠快速加載；管道技術(shù)，實(shí)現(xiàn)基于不同異構(gòu)數(shù)據(jù)庫內(nèi)存或緩存間的無縫對接。其實(shí)現(xiàn)原理為，源數(shù)據(jù)庫計(jì)算輸出為文本文件，通過內(nèi)存實(shí)現(xiàn)直接導(dǎo)入目的數(shù)據(jù)庫，計(jì)算結(jié)束后自動(dòng)清除緩存，實(shí)現(xiàn)異構(gòu)數(shù)據(jù)源間的數(shù)據(jù)無縫對接和交互。

4 改進(jìn)效果

改進(jìn)后的Zeus系統(tǒng)在調(diào)度作業(yè)時(shí)，任務(wù)之間沒有等待時(shí)間，最大限度地利用了集群資源。在同一實(shí)驗(yàn)環(huán)境下（任務(wù)部署節(jié)點(diǎn)：8核64 GB、CentOS 6.4；Hadoop集群主備節(jié)點(diǎn)2臺：8核64 GB、CentOS 6.4，數(shù)據(jù)和任務(wù)節(jié)點(diǎn)公用13臺：8核32 GB、CentOS 6.4；100 Mbit/s網(wǎng)卡）使用Zeus調(diào)試與crontab調(diào)度方式總執(zhí)行時(shí)間對比的結(jié)果如圖4所示（選取2015年3月1-5日數(shù)據(jù)）。

圖4 Zeus和crontab調(diào)度用時(shí)對比

在優(yōu)化之前，原有Zeus系統(tǒng)調(diào)度作業(yè)平均耗時(shí)為43 min，使用優(yōu)化后的Zeus調(diào)度方法后，作業(yè)平均耗時(shí)為31 min，提升27.6%，示例任務(wù)的前后效果對比如圖5所示。

圖5 Zeus優(yōu)化前后調(diào)度用時(shí)對比

通過改造，實(shí)現(xiàn)在Zeus系統(tǒng)內(nèi)支持Oracle存儲過程，使得原有Oracle計(jì)算任務(wù)與大數(shù)據(jù)平臺計(jì)算任務(wù)無縫銜接，同時(shí)也為Zeus支持其他關(guān)系型數(shù)據(jù)庫存儲過程提供了通用的解決方案。

相對于Hadoop生態(tài)中的Sqoop技術(shù)、Hive自身的用戶定義函數(shù)（UDF）接口技術(shù)等異構(gòu)數(shù)據(jù)同步方式，通過管道技術(shù)實(shí)現(xiàn)的異構(gòu)數(shù)據(jù)源同步方法，節(jié)約了數(shù)據(jù)格式轉(zhuǎn)換、存儲和對接同步時(shí)間，效率提升近70%。

5 結(jié)束語

從實(shí)際使用效果來看，游戲大數(shù)據(jù)平臺引入工作流引擎工具后，極大提升了Hadoop作業(yè)的管理和調(diào)度效率，通過Zeus的權(quán)限劃分功能，不僅可對作業(yè)的編制、修改、刪除進(jìn)行有序管理，更可在流程和制度上規(guī)范業(yè)務(wù)人員和平臺運(yùn)維人員的操作，使其協(xié)同度更高。

圍繞Hadoop的開源生態(tài)環(huán)境，存在很多諸如Oozie、Azkaban等優(yōu)秀的開源工作流引擎，在國外公司得到廣泛應(yīng)用，相比之下Zeus由國人開發(fā)，Zeus系統(tǒng)的功能強(qiáng)大、使用便捷，界面交互習(xí)慣和流程設(shè)計(jì)更符合中國公司的需求，二次開發(fā)更容易上手。

［1］蘇洋，劉曉軍，唐勇，等.游戲大數(shù)據(jù)平臺研究與實(shí)踐［J］.電信科學(xué)，2014，30（10）：21-26.SU Y，LIU X J，TANG Y，et al.Research and practice of big data platform of games［J］.Telecommunications Science，2014，30（10）：21-26.

［2］Apache Oozie workflow scheduler for Hadoop［EB/OL］.［2015-05-30］.http：/oozie.apache.org/.

［3］Open-source workflow manager［EB/OL］.［2014-02-19］.http：//azkaban.github.io/.

［4］Workflow engines for Hadoop，Joe Crobak［EB/OL］.［2012-07-05］.http：/www.crobak.org/2012/07/workflow-engines-for-hadoop/.

［5］淘寶Hadoop作業(yè)平臺宙斯Zeus［EB/OL］.［2015-10-16］.https：//github.com/alibaba/zeus.Taobao Hadoop worker platform Zeus［EB/OL］.［2015-10-16］.https：/github.com/alibaba/zeus.

［6］MAPREDUCE-2364［EB/OL］.［2011-03-07］.https：/issues.apache.org/jira/browse/MAPREDUCE-2364.

［7］WHITE T.Hadoop權(quán)威指南（第3版）［M］.曾大聘，周傲英，譯.北京：清華大學(xué)出版社，2015：125-130.WHITE T.Hadoop：The Definite Guide［M］.Translated by ZENG D R，ZHOU A Y.Beijing：Tsinghua University Press，2015：125-130.

Research and practice on working flow engine of big data platform for gam ing service

CHEN Jie1，WU Juan2，SU Yang1，TANG Yong1
1.Dazzle Interactive Network Technologies，Nanjing 210029，China 2.Guangzhou Research Institute of China Telecom Co.，Ltd.，Guangzhou 510630，China

The big data platform for gaming service is based on Hadoop open source technology.With the demand growth of the service operation staff，there are more and more jobs which depend on each other running on the big data platform.A new working flow engine was developed on Zeus to manage and schedule jobs efficiently.In order to shorten the start time，Zeus task starting process was optimized and multi-threaded start task was achieved.Zeus was also improved to support the Oracle stored procedure.Pipeline technology was used to seam less and efficient sharing and transmission of heterogeneous data sources.

big data job，work flow，open source

TP311

A

10.11959/j.issn.1000-0801.2016080

2015-12-01；

2016-02-12

陳杰（1974-），男，炫彩互動(dòng)網(wǎng)絡(luò)科技有限公司高級工程師，主要研究方向?yàn)榛ヂ?lián)網(wǎng)大型業(yè)務(wù)平臺技術(shù)架構(gòu)、大數(shù)據(jù)技術(shù)框架、通信技術(shù)和移動(dòng)互聯(lián)網(wǎng)等。

武娟（1977-），女，中國電信股份有限公司廣州研究院高級工程師，主要研究方向?yàn)樵朴?jì)算、大數(shù)據(jù)、數(shù)據(jù)網(wǎng)絡(luò)、移動(dòng)互聯(lián)網(wǎng)技術(shù)等。

蘇洋（1988-），男，炫彩互動(dòng)網(wǎng)絡(luò)科技有限公司工程師，主要研究方向?yàn)榇髷?shù)據(jù)、移動(dòng)互聯(lián)網(wǎng)等。

唐勇（1973-），男，炫彩互動(dòng)網(wǎng)絡(luò)科技有限公司高級工程師，主要研究方向?yàn)榇髷?shù)據(jù)、手機(jī)游戲運(yùn)營平臺等。