@chyoo1991
2015-10-14T08:38:10.000000Z
字数 1190
阅读 1132
调查
对前次调查进行总结,分析前次调查和代码修正得到了怎么样的结果。
[针对百度关键词]
添加针对PV的计数器之后,总共有效的关键词数量与DC中的PV自然搜索来源数量基本符合。另外,可以看到大部分被过滤掉的原因在于关键词的长度超标,而长度超标由百度关键词加密引起。据此情况,我们取消掉了长度限制。
-----qingkuang
baidu_keyword_hit数据库里面总UV的变化情况
即在25号去掉长度限制后,UV量有所上升,但是与正常水平还有一部分距离。数据库中出现了加密的关键字,说明长度限制去掉后起了一定作用。
初步怀疑是PV->UV的过程中出了意外情况,首先要对这个过程进行梳理。
经研究发现:存储过程是
kafka->redis->django
经过仔细阅读代码,大略判断,并没有发现问题。如果要确定具体问题,还要细致写代码验证。此时又怀疑没有什么大问题,毕竟代码没看出来。于是将DC中的UV与数据库中的UV进行比较[相减],得到下面的图:
很明显,这个是存在问题的。9月10号之后,数据库里面的UV明显减少。导致DC里面的UV减去数据库里面的UV得到正值。数据库里面的UV计算方法是:keyword:date:url->uids(列表),也就是说如果一个用户在同一天里用不同的关键字搜索到了同一个url,会导致其uid被存储两遍。初始预计DC中的判断方式是 date:url->uids,这样就去掉了不同关键字的情形(合成了一个)[还有可能就是只统计date不重复的uid的个数,这样也是比数据库中要少]。于是从理论上讲,数据库中的值应该比DC中的多。但是上图在10号之后就不对,数据库里面的UV明显减少了。
Redis中存储12号的数据:scard keywords:2015-10-12 结果为:1484471 也就是说关键字是148w
设计脚本统计12号redis里面存的数据的UV是多少,跟数据库里面的区别是什么,来查看是否是入库问题。
数据库中UV的总值:2544271
DC中UV的总值:3091506
差值近50w,而且应该是数据库UV比DC的多。
redis中的数据:2544363(存入Django模型时会因为少数编码问题无法存入)
经过用脚本统计redis中的数据,发现存入redis中的数据为254w多[要跑一个多小时],和数据库中的UV对的上。因此判定问题出在存入Redis时或者是存入Redis之前。