最近手底下某款业务遇到瓶颈了,目前公司在大规模的上手游,但是产品的同事也要同步的去获取与分析数据,以往的流程时游戏上线之初我们与研发方沟通,要的他们的数据库表结构,我们会根据游戏的数据库进行数据分析,汇总产品需要的数据。现在手游团队突然壮大,游戏也开始指数型增长,但是我们的开发人员还是比较有限,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、报表展示
将报表计算的数据以图形表格等形式展现至前端
未完待续。。。