市场项目：push模块文档

市场push文档

 移除点击此处添加图片说明文字

​关于市场问题的两个解决方案文档

1、卡牛 推送安装uv查询

2、市场push数据指标出问题

一，解决推送安装uv查询

首先解决第一个问题，卡牛信用管家（包名：com.mymoney.sms）7.21-7.22两天的安装uv也帮忙查询

23日 卡牛安装uv 查询：

select package_name,trim(channel_id) as channel_id,count(imsi) as i_pv,count(distinct imsi) as i_uv from oz_log.cap_data_market_rec_mt where  pt='2017-07-23' and source1 = 3 and action = 6 and imsi is not null

and package_name ='com.mymoney.sms'

group by package_name,channel_id

  移除点击此处添加图片说明文字

​与报表数据核对，一致。经过累加，和安装次数、安装用户数一致。

  移除点击此处添加图片说明文字

​来源表： oz_log.cap_data_market_rec_mt

2、市场push数据指标排查思路

首先来看一下现象，发现message明显小于展现用户数。并且后台拉取数据的许多message数据为null。

  移除点击此处添加图片说明文字

​

  移除点击此处添加图片说明文字

​如果：message用户数(UV) >展现用户数(UV)只正常情况

上图：message用户数(UV)< 展现用户数(UV)数据异常

解决思路：

第一步：确定是静默还是推送，这个从页面就能看到，然后我们要找到后台对应的python脚本，有两个python脚本，一个是跑静默，一个是跑推送的。例如本例，直接页面告诉你是静默，然后我们ctrl+h 在eclipse中全局搜索到该页面：

  移除点击此处添加图片说明文字

​定位到是这个字段，i_uv

然后我们根据。

  移除点击此处添加图片说明文字

​可以看到步骤3，的后台脚本位置，我们去看一下：

得到了。

  移除点击此处添加图片说明文字

​可以看到是静默的就是那个deploy，我们再去看一下这个脚本。

精确到这个大sql

  移除点击此处添加图片说明文字

​因为是查udev，所以我们可以看到：

select package_name,trim(channel_id) as channel_id,count(distinct imsi) as udcnt from oz_log.cap_appstore_push_rec_mt t1 join  oz_log.cap_resource_info t2 on push_apk=res_apk_id where t1.pt='"""+date+"""' and t2.pt='"""+date+"""' and imsi is not null  group by package_name,channel_id)t2

on (t3.channel_id=t2.channel_id and t3.package_name=t2.package_name

就定位到这张表：

oz_log.cap_appstore_push_rec_mt

第二步：通过hue -> 文件管理 -> 查看表 -> 查看文件位置 -> 具体某一天的时间分区点开 -> 数据是否正常 -> 大小对比 oz_log.cap_data_market_rec_mt

  移除点击此处添加图片说明文字

​查看数据文件

  移除点击此处添加图片说明文字

​

  移除点击此处添加图片说明文字

​只有 7.5M，数据打入有异常, 正常几个G大小

第三步：我们知道来看一下此图，得知，步骤二是将导入的数据处理成hive中oz_log库的，所以，接下来我们要去192.168.0.82 服务器找到转换python脚本，这里有两个脚本，所以，我们要根据表oz_log.cap_data_market_rec_mt找到具体是哪个Python脚本

  移除点击此处添加图片说明文字

​0.82机器 hdfs

  移除点击此处添加图片说明文字

​第四步：然后走到这里，你可能不知道从步骤一拉过来的数据在哪里，有三个办法可以解决这个问题，即：步骤一从远程拉到本地的数据在哪里。

我先把思路写一下：

1、可以看步骤一里面将数据导来本地的时候放到哪里了。

2、可以看一下每个python执行的时候的日志文件，一般都会打日志当前文件目录

3、可以python执行的时候，输入目录的目录位置。

我们直接选择最简单的方式，看日志，本例就是/tmp/oz2.log

  移除点击此处添加图片说明文字

​因为日志里里面写了

/home/syndata/oz_log/app_command_data/cap_appstore_app_command_rec_20170725

这样就就可以找到了，数据目录

/home/syndata/oz_log/app_command_data/

  移除点击此处添加图片说明文字

​发现23号 日志数据大小有异常，明显小于之前

删除23号数据 要重新跑23号数据

查看脚本

服务器：192.168.0.82

 30 9  * * * /usr/bin/python /home/syndata/util/oz_log2_get_client.py > /tmp/oz2.log 2>&1

脚本层层关联

import config里面，

  移除点击此处添加图片说明文字

​py代码

  移除点击此处添加图片说明文字

​从192.168.0.141 /opt/ftp/oz_log/app_command_data/data 目录上拷贝数据本机 导入

/opt/ftp/oz_log/app_command_data/data

 

​重新跑

/usr/bin/python /home/syndata/util/oz_log2_get_client.py > /tmp/oz2.log 2>&1

导入表数据

在跑最后一步报表数据，部署在141上面，跑这个脚本

/bin/sh /etl/tools/etl-python/push/push_report.sh > /etl/tools/etl-python/push/push_report_log.txt

总结一下，就是如果发现出了问题。

1.从web层一层一层定位到脚本，从php代码定位到表mongo表，在从mongo定位到141上面第三步骤的脚本，该脚本是先将oz_log库数据计算输出到push_report库，再从push_report库同步到前台mongo的。

2.检查第二步骤同步数据的问题，要去检查82服务器上面的oz_log源数据看看是否是完整的，一般7个g左右，有时候只有50兆。这个步骤是将141上面的源数据copy到本地，然后计算出每个oz_log库中表的数据的。

3.第一步骤一般不出错。第一步骤执行了5个shell脚本，分别对应了5个jar包，我们找到其中一个看一下究竟。

反编译工具出来代码查看：

 

​代码

 

代码​

 

​大致就是去下图这个ip上面去拉取数据到141的目录下面，然后解压缩本地，然后还会在java里面嵌套sh命令去跑别的脚本。这一块比较凌乱，需要仔细读。因为会涉及到很多别的模块。