转载

手工搭建spark数据分析平台

我们的应用在线上也已经运行了快一年了，时常想分析一下过去积累的数据，比如用户的类型，访问路径，转化漏斗等等。相对比较好做的也就是一点简单的记录在mysql中的数据。

对于用户运营同事想要的基于uv的留存率等数据，之前的做法：

手动备份线上 nginx log 到一个地方
解压日志 (10g+)
awk 提取需要的信息(1g+)
sort && unique 得到基于日期和ip的访问日志 (200M)
同步到内网
写个 ruby 脚本，解析uv, 计算留存率等，得到一个csv
发给运营同事

所以，每个月初，出上月月报的时候，挺痛苦的，帮各个角色出各种数据。

穷极思变

累的久了，自然想改变一下。于是自动同步线上日志( rsync )，自动解压，解析，去重，生成uv. 每个月需要报表的时候，手动去执行一下脚本就可以了。

接着我们又想去计算转化漏斗，计算每个平台访问频率高的页面，计算演出访问的关联性。脚本已经跑不动了。

又一次变化

spark comes to the resuce.

spark 的好处

自动的任务分解

我理解，其实和 functional programming 里的概念很类似。 haskell 也可以在编译时指定开启多线程，就能自动分解任务。基于的前提都是理解操作间的关联与影响。知道哪些操作是可以先分解再合并的。于是，写的时候当做单线程去写，执行的时候帮你优化。

自动的中间结果缓存

同样是为了效率的优化，对于撰写脚本计算的人屏蔽了这一层优化的考虑，降低负担.

可以直接本地执行，榨干机器的CPU

任务示例

比如想知道点了一个演出之后，又点了另一个演出的比例。

# visitsframe为nginx日志解析之后的dataframe # normalVisits为过滤了爬虫的访问之后的 normalVisits = (visitsFrame.filter(visitsFrame['res'] == True)                 .filter('ua not like "%pider%"')                 .filter('ua != "Googlebot"'))  #relatedVisits 就是当前访问为某个演出页且refer也是某个演出页的记录，按天聚合后的数量 relatedVistis = normalVisits.filter("host = 'www.piaoniu.com' and url like '/activity/%' and refer like '%www.piaoniu.com/activity/%'").groupBy('day').count()

在写这段脚本的时候，不关心如何计算，怎么样分解任务, 只负责描述清楚要达成的目标。而 spark 负责很快的执行完。

当前的使用方式

安装spark docker 安装 jupyter/all-spark-notebook
数据同步通过crontab的形式，将线上日志导入到内网服务器的制定位置
分析脚本开发之前安装的docker image, 8888端口会启动一个ipython的server, 通过该端口使用 ipython 连接到 spark 的 shell, 通过python 来开发分析脚本
结果分析
1. 直接在 ipython 的 notebook 中使用 pandas 看生成的图片, 比如这样的代码和这样的曲线
```
normalVisits.groupby('day').agg(func.countDistinct('ip')).toPandas().set_index('day').plot()
```
2. 保存结果到csv后导入回mysql做报表展示