游戏数据分析智能任务调度架构研究与实践

2016-03-24陈杰黄洋张泽鑫唐勇

广东通信技术 2016年2期

［陈杰黄洋张泽鑫唐勇］

游戏数据分析智能任务调度架构研究与实践

［陈杰黄洋张泽鑫唐勇］

摘要

针对常见的数据分析系统，缺少对系统资源的监控及任务优先级的考虑问题，本文提出通过采集集群中各台主机性能指标，分析系统的查询日志，构建结合任务优先级配置的智能调度框架，并详细剖析其组件构成、技术原理和实现流程等。依据实践中的运行效果，验证和对比该架构与传统架构在资源分配和运行时间上的效率情况。

关键词：数据分析任务调度

陈杰

高级工程师，本科学历毕业于南京邮电大学，现供职于炫彩互动网络科技有限公司，研究方向为互联网大型业务平台技术架构、大数据技术框架、通信技术和移动互联网等。

黄洋

工程师，本科学历毕业于南京人口管理干部学院，现供职于炫彩互动网络科技有限公司，主要研究方向为大数据，移动互联网等。

张泽鑫

工程师，硕士研究生学历毕业于上海同济大学，现供职于炫彩互动网络科技有限公司，主要研究方向为大数据，移动互联网等。

唐勇

高级工程师，博士研究生学历毕业于东南大学，现供职于炫彩互动网络科技有限公司，主要研究方向为大数据，手机游戏运营平台等。

1 引言

在互联网业务中，数据分析系统是按照决策和管理要求，源于海量的互联网业务数据，根据任务要求的先后关系生成的相关业务统计数据结果，作为业务决策和产品运营手段调整的依据和来源，需要把数据信息以可靠和安全的方式呈现给管理者或使用者。

因互联网业务相关数据具有相互关联性，尤其是针对游戏平台需要满足成百上千的游戏产品数据同时统计，一个游戏产品的日活跃变化曲线和一段时间用户活跃情况有关，而每天活跃度有和以当天为时间轴前后几天或一周之内用户登录情况有关，这都给数据分析处理带来了挑战，建立一套完善的任务调度架构，满足任务合理调度成为关键所在。

常用的动态调度、静态调度和同层划分调度都有其适宜的场景，但缺乏针对系统资源的灵活调度和匹配，难以实现计算任务、系统资源调度、任务管理的统一，达到硬件和软件资源的有机融合，提升效率和可靠性。

本文提供了一种结合系统资源查询游戏数据分析智能动态调度架构，增加了系统资源的监控及任务优先级的考虑，在任务有效调度的同时，实现硬件资源的负载均衡。

2 数据分析任务调度方案现状

目前市面上数据分析系统的任务调度，主要有3种任务调度方案，分别是：动态调度，静态调度和同层划分调度。调度的单位可以是单个任务或一批任务。

动态调度方案，此方案是以单个任务为调度单位的方案。其调度策略是：调度进程首先顺序扫描任务列表，对于那些前驱数为零的任务，直接产生线程并提交给操作系统，直至等待线程结束的信号。任务执行器发现任务执行结束后，更新任务流图中的优先信息，将以该任务为前驱的任务的前驱计数值减1，一旦发现任务流图中的某个任务的前驱任务数为零，则创建新的线程执行该任务。

静态调度方案，主要面向所有待调度的任务是预先知道的，执行具有相对的稳定性的任务，因此静态调度只需要按照事先定义的顺序，排序在前的先执行，排序在后的后执行。

同层划分调度方案，实际应用中，任务流图的深度并不深，而图的宽度却很宽。另外，在报表原始数据组织中是分层的，如日志层、清单层、报表层等，因而可按层次调度任务执行。

以上这3种方案各有优缺点及适用场景，但都缺少对系统资源的监控及任务优先级的考虑。生产环境下系统的资源是固定的，即便采用上文的动态调度方案，如果不考虑到系统资源使用率，无限制的创建进程并发，系统负担过大，不仅不会加快数据结果的生产效率，可能还会带来系统的宕机，造成延误。每日系统上的成千上万的计算任务，他们的价值度是不一致的，需要考虑任务的优先级，优先将系统资源分配给高价值的任务，从而实现数据分析结果的价值最大化。

3 游戏数据分析智能调度架构实践

下文给出的游戏数据分析任务智能调度架构中，采用系统资源采集器来采集集群中各台主机性能指标，查询日志分析器分析展示系统的查询日志从而得出任务的优先级，智能调度框架中根据依赖关系分析、调度日志、分析器参数、采集器参数为任务前序检查参数，检查通过后动态调度任务运行。

3.1 总体架构分析

如图1所示，总体架构主要分为3个结构，查询日志分析器、系统资源采集器、智能调度框架。优先满足使用频率较高，同时为了更好地利用资源，结合系统性能，并发调度报表。结合报表使用情况，优先满足价值度较高报表。

图1 总体框架结构示意图

3.2 系统组件构成

总体架构分系统资源采集器、查询日志分析器、智能调度框架三大组件，下文将详细介绍其作用及工作原理。

3.2.1 系统资源采集器（如图2所示）

集群中每台主机的性能是不一致的，工作过程中忙闲程度也是不一致的，当系统需要执行任务时，应该由集群中的哪个节点具体去执行，怎样才能最大化且最合理地利用集群资源，这一直是难以决策的问题。系统资源采集器主要是从集群中的各台主机上采集系统性能数据，供动态调度框架调用分析，从而当任务提交时，可将任务分配给系统资源最适合的一台机器去执行，若系统资源紧张，则任务等待系统有资源后执行，避免造成压力。

图2 系统资源采集器结构示意图

采集各主机性能，我们使用Collect Agent。Collect Agent基于Java语言开发，封装系统信息采集能力。将其部署于集群中各主机本地，可实时采集系统数据。Collect Agent下层通过JNI（Java Native Interface）接口进行本地系统调用，进行各类性能数据的采集，目前主要采集进程信息与硬件信息。系统资源采集器通过RMI远程对象调用接口接受动态调度框架的性能采集请求，并将采集结果返回给动态调度框架中的采集器参数列表。其中进程信息采集负责采集主机上运行的进程的各类信息，包括进程名、参数、进程ID、来源文件等；硬件信息采集负责采集主机的硬件配置等信息，包括磁盘空间、内存容量、CPU占用率、设备状态等。

3.2.2 查询日志分析器（如图3所示）

图3 查询日志分析器结构示意图

查询日志分析器主要针对平台记录的查询日志进行分析，查询日志至少应具备分析结果唯一标示、用户唯一标示、查询时间这3个参数，以便分析各分析任务使用情况，通过这3个参数，我们至少可以计算出每个分析任务在某个时间段内使用用户数、使用次数这两个基础指标，通过分析任务价值度算法得出每个数据结果的价值度，根据价值度从高往低排序，从而确定任务的优先级。

任务价值度是为了通过直观的数值方式，反馈出上一个周期内各任务分析结果使用情况，从而针对各任务不同的使用情况，分配不同的系统资源。对于其中价值度过低的任务，启动主动退出机制，完善展示任务的生命周期。

展示任务价值度当前主要参考4个关于结果使用及结果生成维度，结果使用天数（Vd）、结果使用用户数（Vu）、结果可查询用户数（Vc）、结果生成平均时长（Vt）。由此得出对应任务的价值度算法公式：f(V)= Vd * Vu / Vc * K - Vt，其中K为常数，暂定7.9。

3.2.3 智能调度框架

数据分析程序在运行时，对于数据来源的依赖很大，不同的分析任务在生成时需要从不同的数据源表获取数据来进行计算。这就导致不同的任务程序有着不同的先后运行顺序和时间轴。随着业务的扩展，任务程序间的相互依赖就变得更加错综复杂，以单纯的人工梳理，定时运行的方式难以有效维护整体的任务程序调度，导致程序在不同的时间点上或者会抢占资源，或者会空闲资源。而本系统采用的智能调度框架，进行程序调度的话只需要简单的配置即可将新的任务程序加入到系统调度中。

任务程序的依赖关系分析过程，主要依据于任务程序的源码分析。依赖关系分析程序首先需要获取任务程序的源码，对于数据库任务程序来说一般是存储过程，对于分布式计算框架则可能是java程序等。对于不同的系统架构和开发语言，具体的源码分析程序和细节算法可能不同，但是其总体思路是一致的。

依赖关系分析主要分为两个过程：

第一步，需要解析目标任务程序的源码，获取该程序读取和写入的具体表名。这一步在获取了任务程序的源代码之后，首先需要过滤代码中的注释。删除注释后依据程序的编程语法，将源程序分解成独立的语句。对于不同的编程语言，其读取和写入数据库表的操作关键字都是确定的，其语法顺序也是明确的，因此可以通过解析相应的关键字和语法来获取程序的读取和写入表。对源码的文本解析方法较多，包括逐字符串自行规则制定解析和基于正则表达式匹配的解析方法等。

第二步，是基于第一步解析完成所有需要运行调度的任务程序之后，对所有的任务程序都计算出其写入和读取的具体结果名称之后，进行的任务程序之间的依赖关系分析。对于已经解析完结果依赖的任务程序，其结果数据依赖分为读取和写入两种。亦即每个任务程序分别包含两个列表，列表元素分别为其写入的数据库表和读取的数据库表，设写入列表为listWrite，读取列表为listRead。在获取目标程序（设为targetProc）的先驱执行程序时，需要获取该程序listRead的所有元素；同时对于所有的任务程序（设为referProc），依此比对其listWrite的所有元素与目标程序的读取表列表。当targetProc.listRead与refetProc.listWrite的交集不为空时，则认为targetProc的执行依赖于refetProc，即targetProc需要在referProc之后调度运行。

程序与程序之间的调度依赖关系分析时，需要注意的一点是应当通过与系统中已有的列表进行校对，避免第一步文本分析过程解析不完全导致获取的结果实际并不符合系统的数据库表，如图4所示。

图4 获取过程之间的依赖关系过程示意图

在获取了数据分析中各个独立执行的任务程序之间的调度依赖关系之后，结合系统资源采集和查询日志分析的结果，可以计算出一个或者多个执行队列，将报表程序依照队列顺序进行调度执行。

依赖关系分析程序解决了任务程序在运行调度上的初始化调度队列问题，使任务程序的运行调度不再依赖于人工指定的时间节点和顺序，可以依据系统负载、报表价值度来自行调整和分配任务程序的运行。但是在任务系统运行的过程中，还有另一个问题：对于异常程序的处理。

任务程序在运行中，可能由于业务或者系统的影响，造成了程序的异常和执行失败。而任务程序的运行，会对其他任务程序写入的数据有所依赖，因此当某个程序产生异常时，将不会写入相关数据。这就导致执行队列随后对其依赖的程序无法正确执行，或者同样发生异常。

为了解决此问题，系统在决定执行调度队列中的某个程序时，需要去查询该任务程序的先驱依赖程序的运行结果日志。只有当该程序所有的先驱依赖程序都成功运行完毕之后，该程序才可以调度执行；否则，该程序应当处于等待状态。

若程序一次性执行成功，则系统查询该程序运行日志时只会返回一条结果，此时不会影响其后驱依赖程序的调度运行；但如果程序首次执行失败，之后重新执行成功，则系统查询时会返回多条运行结果日志，并且包含失败日志。失败日志会阻塞后驱依赖程序的调度，所以系统应当在运行日志产生时，进行运行日志的合并操作。

运行日志的合并操作可以有多种解决方式，包括生成的新日志复写旧日志、查询时只选择时间点最近的日志记录等等。需要注意的是，要保证程序成功执行后，不论该程序是否有过失败日志，系统都要以该次成功运行日志作为调度后驱依赖程序的依据。

4 游戏数据分析任务智能调度架构应用效果展示

在不进行系统资源查询和依据系统资源进行智能任务调度时，系统调度的规则是由开发人员人为分配的，容易导致系统资源的分配不够合理，部分节点高负荷运行的同时，其他节点则处于闲置状态，如图5所示。

图5 使用动态调度架构前CPU负载率

而结合系统资源查询的数据分析任务智能调度框架，可以根据系统各个节点的实际负载情况，将即将执行的任务分配到较为空闲的节点上运行，达到负载均衡的目的。如图6所示。

图6 使用动态报表架构后CPU负载率

在未启用智能调度框架时，系统需要线形在指定的时间点顺序执行展示任务，所以即便有多个节点，但是使用率很低，整个任务程序运行完成时间等于所有任务程序的运行时间总和。

而当系统使用智能调度框架时，结合系统各个节点负载情况，可以将队列中满足执行条件的任务自动分配到负载较低的节点上，从而达到任务程序并行执行的目的，使整体任务程序运行的时间远小于所有任务程序运行时间的总和，与计算时间最长的任务链条所消耗时间基本一致。

5 结束语

本文介绍了采用系统资源采集器来采集集群中各台主机性能指标，查询日志分析器分析数据分析系统的查询日志从而得出分析任务优先级的方法，提出一种创新的游戏数据分析任务智能调度框架，将任务调度与依赖关系分析、调度日志、分析器参数、采集器参数关联，解决传统方法任务调度缺少对系统资源的监控及任务优先级考虑的问题。在实践过程中，该种架构能够自动实现各处理节点的动态均衡，节省程序的运行时间。该框架具有通用性，能够为其他业务数据系统提供了良好的参考和借鉴。

参考文献

1朱炜昊，《基于RMI和JNI的主机性能采集Agent的设计与实现》，中国科技论文在线，2009

2史捷，鲍玉斌，刘运涛，张斌，孙焕良，于戈，《数据仓库系统中任务调度策略研究》，控制与决策，2005年1月

3苏洋、刘晓军，唐勇，黄洋，《游戏大数据平台研究与实践》，电信科学，2014年10期

4唐云善等，《一种高效的大数据实时性解决方案》，计算机与数字工程， 2014年04期

5赵辉等，《基于MapReduce模型的范围查询分析优化技术研究》，计算机研究与发展2014