最近手底下某款业务遇到瓶颈了，目前公司在大规模的上手游，但是产品的同事也要同步的去获取与分析数据，以往的流程时游戏上线之初我们与研发方沟通，要的他们的数据库表结构，我们会根据游戏的数据库进行数据分析，汇总产品需要的数据。现在手游团队突然壮大，游戏也开始指数型增长，但是我们的开发人员还是比较有限，OK，我们来换思路。
初步讨论过几次，也有了部分眉目，设计一个如此大的架构有点小小的激动啊！
目前现在是在按照这个方案在一步一步的走，并且还需要Linux组，Windows组，DBA组的支持，确实是个世纪工程！
架构草图：
稍微有点时间了，现在再补点内容吧，这个的工程比较浩大
整套系统可以划分为：
1、REST接口系统
这里语言还在选型中，目前我们团队能驾驭的有PHP，Python，JAVA，这个系统用过HTTP方式收集数据(对，是收集数据，与一般的接口正好相反)，经过部分测试，现在用PHP基本上放弃了，与Apache甚至是Nginx的并发处理能力与Python的Web.py不是一个数量级的，后续全部测评完会放出来，接口做的工作非常简单，受到数据，向Redis队列里lpush相应值。
这里有个比较细节的考虑，就是如果Redis回应速度慢的时候，接口需要立即写硬盘，然后为请求方回复，保证请求的响应速度，这个在PHP上也是不好实现的。
2、负载均衡与高可用架构
这个要看我们最终的接口系统语言选型了，并且这个并非我们擅长的，需要Linux组去合作，关于负载我其实也非常浅的用过，当时是PHP的环境，Niginx做反向代理，后端挂Apapche，实测稳定性并不是很高，这个后期出方案后也跟着学一手。
3、ETL系统
当初在设计整个架构的时候只有一套REST接口系统的，但是后期考虑IDC之间的互通性还是选择了分IDC进行接口部署，ETL就是为了回收这些各IDC数据的，工作就是连接各个IDC的Redis进行RPOP或者BRPOP，然后将进入入数据仓库，在上面的图上有部分细节，就是如果ETL实时往数据库里存可能数据库并发存在瓶颈，所以暂时采用写文件的形式。5分钟一个文件，文件会每5分钟入inforbright，然后将每天5分钟的文件合并，进Hadoop。
4、数据仓库
这个就不用说了，目前我们的数据仓库是Hadoop，这次也会同步启用inforbright，主要考虑到页游的生命周期短，实时性要求高，数据压力并不是太大。
5、报表计算
从数据仓库中计算各类的报表，如DAU WAU MAU PUC AUC 留存 流失等等
6、报表展示
将报表计算的数据以图形表格等形式展现至前端
未完待续。。。