前言

公司由页游转手游，公司的数据分析需要针对手游进行设计，所以原来的那一套针对页游的数据分析框架就显得不是很合适了，一方面在于手游和页游一些业务逻辑上的不同，另外一方面是数据量级上的改变，以及渠道、区服之间的联系、以及手游BI系统的渠道区服交叉查询。使得原本从4399游戏那一套针对页游而来的框架就显得有些吃力。这里分析的就是页游到手游这个过程中，针对大数据分析所做的调整工作，以及在此之间的分析案例。

页游合作场景

页游阶段，如果一款页游准备推上某个平台，那么需要与该平台进行对接，在该平台上进行考试，达到一定分数，平台才可以提供资源进行上线扩服。那么如果想上另外一个平台，那么需要跟另外一个平台进行相同的流程。目前页游公司与平台方的合作方式大部分如此。那么其实游戏，平台与区服就都是一一对应的，一个平台可开设多个区服，且一个区服只属于一个平台（跟手游不一样）。

页游数据采集分析过程

公司随着游戏开服，需要查看游戏的数分析，比如说留存流失情况，付费情况，活跃用户情况，崩溃情况等等，这就是很多BI系统中的一个子系统（数据分析系统：用于用户行为分析、产品质量监控、活动参与度统计等等）。那么这一流程大致如下图：

分析：
1.平台与平台之间的数据是隔离的
2.在使用ETL处理项目组数据时保持原来的游戏平台-区服分库，如果针对一些特殊的表，可以进行拉取汇总表，比如说login表，付费表。
3.编写统计脚本，放到Linux定时任务中，统计结果放到结果库，结果库按照平台分库。
4.根据BI系统数据分析从结果库中的统计结果，展示相关指标数据的图表。
5.这个过程中会有少量实时数据的分析需求，这个就需要在BI系统中直接去连接项目组数或者通过短时间定时任务进行拉取到结果库。

手游数据采集分析过程

手游阶段，如果一款游戏需要再某一渠道上线，那么需要跟渠道商进行合作，IOS和安卓就是平台，并且同一平台下的不同渠道的游戏数据可以写到同一个区服里，也就是说渠道与区服是多对多的关系。那么跟页游情况相比较就有不一样了，一个服里的数据可能来自多个渠道，一个渠道的数据被分在多个区服里。大致分析流程如下：

分析：
1.渠道与服直接是多对多的关系
2.etl拉取清洗时依然根据渠道-区服进行分库
3.编写统计脚本，统计结果保存到结果库，一个游戏只有一个结果库（包含所有渠道，所有区服）
4.因为只有一个结果库，所以需要考虑分表，避免单表过大查询慢。分析如下：
假设50个渠道，100个区服，单表维度不超过5个，根据经验估算[10W-15W]/天增量，那么按照季度进行分表，每个子表数据量在900W到1350W之间，另外针对一些记录相对活跃的统计表，可能需要按月分表或者更细。总而言之就是尽可能的减少单个表的大小，但是这个会带来一个问题就是在BI系统中如何进行查询、分页呀等等问题，不过这个问题已经有相应的组件帮我们完成，比如说：阿里的mycat、当当网的Sharding-JDBC，我计划使用Sharding-JDBC，因为mycat针对查询、分页我感觉有点重了。如果你们也需要使用类似的功能，请结合自己需要选择即可。