2.数据分析
_
参考数据系统架构V1，当时的分析服务器是个多台单独的服务器。由于每台服务器分析业务互相独立，算不上分布式计算也算不上集群。当时单台分析服务器工作流程如下：
- crontab 执行任务
- 启动脚本，从磁盘阵列同步上一天全天日志到本地磁盘
- 启动程序，从配置文件中找到属于本分析服务器IP的分析任务
- 执行分析任务，并将结果写入数据库或文件里
- 执行下一个分析任务...
分析的整体代码是通过PHP自主研发的一个小型框架，这里的部署和调整还算比较方便，我们大部分时间需要维护的只是一个各服务器分析任务的配置文件，扩容时也比较简单。
没多久，我们就上了新业务，需要分析视频的播放量和停留时间。播放量还好比PV值略小，但停留时间采用的发心跳的方式，所以日志量就比较大了。对当时的整体架构来说，要有很大的改动，上篇提到的'请求会先通过php根据用户cookie的Hash转发到不同的服务器上'就是为了满足这个业务的。
为什么我们要做Hash转发，而不是直接负载均衡到每台服务器呢？主要是为了满足分布式UV计算的（UV是unique visitor的简写，是指通过互联网访问、浏览这个网页的自然人），由于UV分析时需要去除重复，所以Hash以后每台采集服务器日志中的用户都不会重复，这样就满足了需求。
当时我们有各种维度的UV数据需求。在当前系统架构下，每台服务器需要从磁盘阵列上获取上一天全量的日志进行分析任务。当日志量一大，分析服务器的内存和磁盘都成了瓶颈。由于单台服务器的计算能力有限，所以我们转成了分布式数据处理。具体做了下面的三个步骤：
- 采集服务器的更改，同一用户的数据会在同一台服务器上
- 分析服务器的更改，从磁盘阵列获取分析任务所需日志，而不是上一天的全量日志
- 报表系统的更改，每个ip计算的数据会在数据库中有个标识，计算总体的UV数据时需要累加
经过上面的三个步骤，一个简单的分布式计算就完成了。举个栗子，采集服务器有6台，分析服务器有2台，那么每台分析服务器拿3份日志即可，分析完成以后数据库中UV数据的IP维度上有两个IP的值，进行累加既是UV总量。
总结一下遇到的问题：
- 服务器监控层面的缺失，包括单点服务器健康状态（负载、磁盘、心跳）
- 单点宕机时，分析任务在其它服务器下的补救
- 多人协同开发下，分析服务器配置文件管理混乱（老业务变更优先级，新业务加入，单点宕机时的补救===），经常发生代码冲突
- 某些需求无法满足，例如月UV的数据统计，这种需要将一个月几T、几十T的日志读取并按维度计算独立用户的需求。究其原因主要是磁盘阵列同步数据到分析服务器的时间太长
- 分析服务器任务列表中某一任务中止以后，其它任务也随之中止
- 扩容的时候越来越麻烦，采集、分析、报表都要跟着有所变动
