PHP数据统计分析

前段时间的主要工作是开发统计系统, 统计公司产品的安装量和回访量,统计数据则由客户端调用C接口写入mysql数据库,即我们只需要分析客户端写入的原始数据即可。下面是对这个项目的一个总结:

系统评估

所以最终还是选择用PHP+Mysql来统计,前期应该可以撑一撑。

整体思路

接下来对每个步骤进行梳理:

系统实现

项目使用CI开发,实现的步骤就没太多说的,查询的时候注意下索引的先后顺序就行了,系统到目前还没出现因不中索引而引起的问题。不过程序上的一些调整可以记录下:

上面的每一个调整并不需要多少时间, 但对不段增长的系统是很有好处的,每当它要倾斜时,我们就把它扶正,希望它能坚持更久一点。

系统新增功能和调整

调整用户唯一ID。

IOS产品原先用uuid来判断唯一性,但7.0之后发现uuid不唯一了,所以统计系统部分产品要将唯一值由uuid替换为序列号,但一直以来都是uuid为唯一ID,统计这边也直接以uuid为唯一键了。这意味着唯一键要调整,大部分表结构都需要调整了。

原始表有的有序列号,有的没有,所以首先是原始表统一增加序列号字段,因为转移的数据只将特定的字段值写进去,所以原始表的调整对统计不会有影响。同时原始表已有2.5亿数据,直接调整表结构基本不可能。所以采取新建一张调整后的表,rename一下即可,rename的过程是很快的,rename之前的几千条未转移的数据再手动转移一下。

统计这边将在近期表新增一个唯一字段, 唯一字段不依赖固定值。因为即便调整了, 有一些产品还是以uuid为准,唯一值在转移的过程中判断即可。 统计系统调整时先停下所有的脚本,近期表直接删除重建即可,唯一表因为需要处理,边转移边处理一下即可,报表数据保留原有。所以整个过程下来调整并不算大,只是因为数据量比较大,处理觉得麻烦一点而已。

增加一个产品

系统中已经增加了好几个产品了, 这里增加产品的接口是用php实现的。即客户端调用php页面,php写数据库,回访数据大概每天100w左右。运行几天后发现php接口机器挂了, nignx进程数太多。原因就是统计系统比较忙时,数据库压力比较大,php一条一条写入很慢, 很多进程都在等待,于是爆了。。。

针对这个问题的处理方法是,php接口直接写数据到文本,然后脚本定时load数据到数据库。

历史数据处理

有个产品需要对历史数据进行重新统计,历史数据有1亿多。因为历史数据和新数据之间的字段、值等需要进行一次处理,所以采用 SELECT INTO OUTFILE的方式导出,1.6亿数据中导出1.2亿大概5分钟左右。导出之后的的文件有9G左右,直接一次LOAD mysql会超出binlog的限制。所以设置了binglog为3G,然后对原数据按每1000w行进行切割,在一个个导入。

如果导入的表已经建好索引,开始导入1000w要半个多小时,导入了4000w数据后发现奇慢无比。后来重新导,导入的表未建立索引,1000w数据大概需要9分钟左右。不过后来增加索引花了大概2个半小时。

对原始数据的处理也是一个问题,为了提升效率,比较大的数据采用多进程跑,比如开10多个进程同时跑一个小时的数据,二三十万数据3分钟就搞定。但当系统中的这些进程碰到一起时,系统就开始慢了, 所以只能用程序去控制下。

系统总结

1、 到目前位置系统运行还算正常,但随着新功能的不断增加,这也是个挑战。如果只是针对单个产品,一般的业务,用php来处理,日2000w数据问题应该不是很大。

2、系统监控。到目前位置做个几个统计系统了,前面一个是最完善的,有很多监控,可以很快发现问题。当前这个系统数据量是比较大的,但监控还比较薄弱,或者已经有很多潜在的问题被忽略,所以做好监控是有必要的。

3、 使用php运行crontab要防止脚本重复执行,限制起来也很简单,可以用php的exec函数去查看一下当前脚本是否正在执行(需要服务器未限制exec函数),如果正在执行就直接退出,给个简单的判断方法:

function get_process_num($process_name)
{
    return exec('ps -ef | grep "'.$process_name.'" | grep -v "grep" | wc -l');
}
-- EOF --
发表于: 2013-11-16 22:25
标签: PHP