手机游戏大数据实时计算框架研究与实践

　　【摘要】为了满足移动终端游戏的精准运营需求，需要收集用户行为数据，实时分析业务状态，深度挖掘市场价值。基于Kafka、Flume、Storm、Redis等开源技术，构建了手机游戏大数据实时计算系统，实现了海量实时数据的采集、存储、计算和查询，并在现网实际系统中得到了成功应用。
　　【关键词】大数据实时计算开源手机游戏
　　doi：10。3969j。issn。10061010。2016。05。017中图分类号：TP399文献标识码：A文章编号：10061010（2016）05007906
　　引用格式：陈杰，苏洋，唐勇，等。手机游戏大数据实时计算框架研究与实践〔J〕。移动通信，2016，40（5）：7984。
　　1引言
　　在移动互联网时代，以手机游戏为代表的移动应用得到了飞速的发展。为了实现精细化运营，迫切要求针对海量数据能够实现实时计算结果以及秒级响应速度。以移动终端手机游戏平台为例，需要处理的流式数据主要包括手机游戏用户的PVUV数值、页面浏览情况、手机游戏内容查找登录支付情况等，这些均要求实时数据的计算和分析，以便可以动态地获取用户访问数据，展示手机游戏平台实时流量的变化情况和用户行为习惯等。面对海量的业务数据量，传统的穷举所有可能条件的查询组合或者穷举条件组合的方法失效。
　　基于分布式处理机制和实时计算架构，将计算过程移至查询阶段，才能满足互联网业务海量数据计算和快速查询响应的需求。
　　2实时计算处理流程
　　对互联网业务的海量数据（主要为日志流）的实时计算可划分为三大主要阶段：数据采集、实时计算处理分析和实时查询展示阶段。
　　在数据采集阶段，通常采用主要互联网公司提供的开源的海量数据采集工具，满足每秒数百MB的日志数据采集和传输要求，如Facebook的Scribe、LinkedIn的Kafka、Cloudera的Flume，淘宝的TimeTunnel、Hadoop的Chukwa等。
　　在数据实时计算分析阶段，首先将数据采集并存储在DBMS（DatabaseManagementSystem，数据库管理系统）中，然后通过查询和DBMS进行交互。但对于现阶段大量存在的实时数据，比如手机游戏交易支付的数据，一般采用流计算技术。
　　在实时流计算框架方面，Yahoo推出的开源架构S4，Twitter使用的Storm，以及业界较为常见的Esper、Streambase、HStreaming等相关技术架构，均基于分布式并行计算（节点间的并行、节点内的并行）和热点数据的缓存处理等技术，提供实时计算服务。
　　在实时查询展示阶段，按照前端展示或者计算结果存储位置的不同可分为：1）直接提供数据读取服务，定期采用进程的内存镜像到磁盘或数据库全内存方法；2）采用Redis、Memcache、MongoDB、BerkeleyDB等内存数据库提供数据实时查询的半内存方法等。
　　3手机游戏大数据实时计算
　　本文提出了手机游戏大数据实时计算架构，采用KafkaFlume集群完成实时数据采集，利用Storm框架完成数据实时计算，采用RedisHBase模式构建查询服务，满足了数据本地磁盘存储的安全性和长久性，实现基于内存提升查询速度。
　　3。1实时计算架构
　　稳定可靠且高效的底层架构是实时计算的必要基础。图1给出了手机游戏大数据实时计算平台的总体框架，如图所示包含数据采集、数据存储、数据处理、数据应用四个层级。
　　数据采集对象主要是全体日志数据。按照统一规则整合，为数据应用提供实时数据。手机游戏日志主要包括两大来源，一是日志服务器集群实时上传的日志；二是业务接口后台服务器实时打印的日志。实时日志采集框架如图2所示：
　　将Flume部署在上述两大类日志源服务器上，作为海量日志实时采集的框架。如图2所示，FlumeNG节点由Source、Channel、Sink三部分组成。Channel将Source和Sink连接起来。Flume的Source将外部数据源传递的数据封装成Flume数据模型的最小单位event。该数据源主要是业务接口实时产生的日志文件，使用操作系统原生类型exec来执行命令：tailfpathnamefilename。xxx采集。此方式简单可靠，适合采集业务接口实时打印的日志。同时还需要打开Source的restart开关，当进程由于某种原因僵死后，可以自动重启。手机游戏行为数据由客户端统计SDK和业务接口产生。为了更好地区分有效日志与程序调试或其它用途的内容，约定了统一的实时日志前缀〔REALDATA〕来减少FlumeAgent的日志量，提高了日志采集效率。
　　数据存储层提供了实时数据处理层需要的类分布式存储，主要采用了分布式消息队列（ApacheKafka）和ApacheZookeeper。通过FlumeNG节点的Sink配置a2。sinks。k1。typeorg。apache。flume。sink。KafkaSink，采集数据并实时存放在Kafka中。
　　数据实时处理层采用Storm实时从Kafka获取数据。在Storm中，首先需要设计一个用于实时计算的图状结构拓扑。拓扑将被提交给集群，由集群中的主控节点分发代码，将任务分配给工作节点执行。一个拓扑中包括Spout和Bolt两种角色，Spout发送消息，负责从Kafka中将数据流以tuple元组的形式发送出去；Bolt则负责转换这些数据流，完成计算、过滤等操作。Bolt自身也可以随机将数据发送给其他Bolt。由Spout发射出的tuple是不可变数组，对应着固定的键值对。相关的组件架构和数据流如图3所示：
　　Storm计算后的数据结果将被实时地写入Redis缓存、Mysql、HDFS、HBase中。其中写入Redis的数据用于实时展示运算结果，写入Mysql、HDFS中的数据用于后续的离线计算任务，写入HBase的数据可当作中间结果使用。
　　在实时数据应用层，将根据业务的需要来开发各类实时应用，比如手机游戏分发平台实时用户数、下载量、收入等。
　　3。2实时计算方法
　　要实现大数据实时计算，仅有框架是不行的，还必须为每个业务设计一套专用的处理流程和算法。与离线计算相比，实时计算在算法上需要考虑的情况更复杂，这是因为实时计算所用到的存储资源远不如离线数据，但处理的时间限制要比离线计算严格，这都要求实时计算算法必须做更多的优化来提升计算的效率。
　　以下将以中国电信爱游戏基地手机游戏业务的海量计数需求为例，设计和优化相关实时计算算法。目前爱游戏手机游戏业务包含近千万的用户下载、手机游戏启动和付费数据，实时追踪这些数据是必须的，这也是个性化推荐、付费预测和用户画像等业务的前提。为此，急需设计一种算法可实时查看任意用户近24小时的下载次数、启动次数、付费次数等业务指标。
　　（1）简化方案
　　简化方案示意图如图4所示：
　　图中蓝色、黄色和绿色表示不同的用户，此方案为每个用户保存一份付费信息，它包含两个数据结构：
　　a）历史付费列表（简称历史），该列表中每个元素包含一个时间戳和一个整数，分别代表过去24小时中某一秒钟的启动数据并按时间排序。该列表最多可包含24360086400个元素，但一般情况不会超过100个。
　　b）累计付费数据（简称累计量），代表截止到最后一次付费时的付费次数。
　　如图4所示，假设蓝色用户对应的数据是〔（t1，a1），（t2，a2），，（tn，an）〕和A。这表示t1时刻的用户付费次数是a1，t2时刻是a2，以此类推，累计量是A。当用户付费数据不断进入消息队列时，处理进程（或者线程）P1，P2会实时读取到这些信息并修改对应用户的数据。如P1读取到t时刻蓝色用户的付费记录时，会进行下面的操作：
　　a）得到当前时刻ct；
　　b）对数据库中蓝色用户加锁，加锁成功后读取数据，假设为〔（t1，a1），（t2，a2），，（tn，an）〕，累计量为A；
　　c）累计量递增：AA1；
　　d）历史量更新：如果cttn，〔（t1，a1），（t2，a2），，（tn，an1）〕，否则更新为〔（t1，a1），（t2，a2），，（tn，an），（ct，1）〕；最后删除时间戳小于ct243600的元素，删除的同时从累计量中减去对应时刻的启动量；
　　e）将新的历史和累计量输出至数据库并释放锁。
　　此方案可正确得到每个用户24小时内的付费次数，并且只要在资源（计算、存储和网络）充足的情况下，数据库中用户的付费次数是实时更新的。此方案也是分布式实时计算中最简单、最常见的一种。
　　（2）优化方案
　　简化方案中需要对数据库加锁，无论加锁的粒度有多细，都会影响计算效率。要想提高实时处理效率，减少锁是非常重要的。一种常见的做法是将并行操作串行化，MapReduce中的Reduce，将key相同的数据交给同一个Reducer处理。基于此原理将方案改造如图5所示：
　　新增一个key的HASH处理，保证相同的用户可以落到相同的处理程序上。由于不存在资源竞争，处理过程不需要对数据库加锁。此方案可大大提高计算效率，整个计算过程变为：
　　b）读取蓝色用户数据，设为〔（t1，a1），（t2，a2），，（tn，an）〕，累计量为A；
　　c）累计量递增：AA1；
　　d）历史量更新：如果cttn，〔（t1，a1），（t2，a2），，（tn，an1）〕，否则更新为〔（t1，a1），（t2，a2），，（tn，an），（ct，1）〕；最后删除时间戳小于ct243600的元素，删除的同时从累积量中减去对应时刻的启动量；
　　e）将新的历史和累计量直接输出至数据库。
　　步骤b）和e）省去了锁操作，整个系统的并发和吞吐量均大大提高。但此方案的缺点是存在单点隐患。一旦P1由于某些原因失效，则蓝色用户的数据将得不到及时处理，计算结果将无法实时保障。
　　在上述计算步骤b）和e）中总是把历史和累计量从数据库中读写。但在实际应用中只关心实时累计值，而历史数据仅用于计算累计值，并不需要实时持久化。为此，在最终方案中，区别对待历史和累计量，将历史和累计量都缓存在计算进程中，定期更新历史数据到数据库，而累计量则实时更新。最终改良优化的方案如图6所示：
　　计算过程为：
　　b）如果本地没有蓝色用户信息，从数据库中读取蓝色用户数据；否则直接使用本地缓存信息。假设为〔（t1，a1），（t2，a2），，（tn，an）〕，累计量为A；
　　d）将新的累积量输出至数据库，如果满足一定条件（距离上次时间间隔足够远，或者积累的消息达到一定量），则将历史数据输出至数据库。
　　最终方案可大大降低数据库压力、IO和序列化反序列化次数，从而提高效率。此方案对系统的稳定性要求更高，一旦P1失效则缓存数据将永久丢失。
　　（3）存储模糊化处理方案
　　在数据存储时，假设时间戳和整型均为long型（8字节），按照简化方案估算，每个用户所需要保存的历史数据大小为100（88）1600字节1。56kB，1000万用户的总量将有15G。若考虑到数据库和本地缓存，则系统存储量至少要30G，由此存在较大的空间浪费。在优化过程中，为了降低历史的存储密度，将精度定义为小时级别，这样每个用户历史数据为24个，数据量为384字节，1000万用户的数据总量为3。6G，数据库和缓存的总存储量不超过8G。更近一步，使用一个字节保存当前小时段，使用包含24个long型的数组表示付费次数，则数据量将固定在196个字节，总存储量不超过4G。步骤如下：
　　a）得到当前时刻精确到小时的部分ct；
　　b）如果本地没有蓝色用户信息，从数据库中读取蓝色用户数据；否则直接使用本地缓存信息。假设为〔time，a1，a2，，a24〕，累计量为A；
　　c）累计量递增：AA1；
　　d）历史量更新：令当前小时段为hour，如果cttime，〔time，a1，a2，，ahour1，，a24〕，否则更新为〔ct，a1，a2，，1，，a24〕；最后将时间坐标小于ct24的元素置为0，同时A减去对应时刻的付费数；
　　e）将新的累积量输出至数据库，如果满足一定条件（距离上次时间间隔足够远，或者积累的消息达到一定量），则将历史数据输出至数据库。
　　存储模糊化处理示意图如图7所示：
　　4应用效果
　　4。1实时业务监控
　　为了实时监控手机游戏平台的访问、下载、收入等情况，将实时统计好的数据包存放在Redis中，然后搭建web监控系统，图形化展示多维度的实时数据。同时针对重要的业务接口，监控每分钟的连接数等指标，及时发现异常日志并报警，可有效识别出攻击和恶意用户点击行为。经实际测算，每秒平均运算量超3000条，峰值超10000条，日处理日志总数超3亿条。
　　4。2用户实时关怀
　　为了提醒用户的消费行为，需要实时计算所有用户每一次的付费行为。如当用户的付费总额达到某一阈值，或首次在平台、渠道进行付费时，该系统会立刻给用户发送关怀短信，提醒用户的消费行为，或提醒其参加抽奖等营销活动。
　　该功能上线后，新增付费用户的注册转化率提升3。3，手机游戏平台投诉用户下降明显，万投比下降8。2。
　　5结束语
　　本文采用KafkaFlume集群完成实时数据采集、采用Storm框架完成数据实时计算、采用RedisHBase模式构建实时查询服务，构建了手机游戏大数据实时计算系统。在实时计算方面，为了满足千万级业务数据的实时查询需求，设计了两种算法。一是需要数据加锁的简化计算方案，二是为了提高效率，去除数据锁的并行操作分布式串行化处理的优化方案，同时还进行了数据分层处理优化，降低了数据库压力。在数据存储方面，结合模糊化处理方式优化数据存储，将存储资源要求减少到常规的12。本项目成果在中国电信爱游戏基地平台得到了成功应用，每秒平均运算量超3000条，峰值超10000条，日处理日志总数超3亿条。该框架可为其他业务平台大数据实时计算提供良好的参考和借鉴。
　　参考文献：
　　〔1〕苏洋，刘晓军，唐勇，等。游戏大数据平台研究与实践〔J〕。电信科学，2014（10）：2126。
　　〔2〕周江，王伟平，孟丹，等。面向大数据分析的分布式文件系统关键技术〔J〕。计算机研究与发展，2014（2）：382394。
　　〔3〕胡宇舟，范滨，顾学道，等。基于Storm的云计算在自动清分系统中的实时数据处理应用〔J〕。计算机应用，2014（S1）：9699。
　　〔4〕唐云善，杨志。一种高效的大数据实时性解决方案〔J〕。计算机与数字工程，2014（4）：678684。
　　〔5〕赵辉，杨树强，陈志坤，等。基于MapReduce模型的范围查询分析优化技术研究〔J〕。计算机研究与发展，2014（3）：606617。
　　〔6〕张华，王东辉，吴。流式计算的分布式框架的应用〔J〕。信息与电脑：理论版，2014（10）：142143。
　　〔7〕黄馥浩。基于Storm的微博互动平台的设计与实现〔D〕。广州：中山大学，2013。
　　〔8〕高鹏。当新媒体遇到大数据〔J〕。广播与电视技术，2012（10）：38。
　　〔9〕刘林林。大数据时代数据分析与信息安全〔J〕。网络安全技术与应用，2013（12）：59。
　　〔10〕吕明育。Hadoop架构下数据挖掘与数据迁移系统的设计与实现〔D〕。上海：上海交通大学，2013。
　　〔11〕谢超。大数据下的数据分析平台架构〔J〕。程序员，2011（8）：5558。