一.数据系统架构V1
_
优酷早在2007年便采用php语言自主开发了一套数据系统。系统分为数据采集、数据存储、数据分析、报表平台，四个模块。整体架构如下：
这套架构至今在一些需要自己搭建数据平台的小公司而言也是足够的，在没有海量数据之前可以不使用Hadoop之类的开源框架，WebServer日志和一些自定义的日志已经足够日常数据分析的需求了，通过Linux上的一些命令已经可以分析很多数据指标了。
1.数据采集与数据存储
根据用户行为不同，数据采集上也有多种方式，最初在移动端没兴起的时候，数据的采集多是针对PC端网站上的，这里列出几种用户行为
- 页面访问
- 点击链接跳转
- 页面停留
- 视频观看
- 广告点击
- 播放器操作
以上这些用户行为，都是通过http协议以请求的方式发送给服务端，服务端接收并进行初步处理写入日志中的。
在V1架构中采集服务器共经历了三个大的阶段：
第一阶段
采集服务器最早只用来收集页面访问日志和点击链接跳转日志，使用了N台服务器做负载，每台服务器各写一份日志。N台服务器日志每天会定时汇总到一个磁盘阵列中供后续分析使用。当时日志量不大，扩容起来也比较方便
第二阶段
为了满足分析服务器上的业务分析需求（后面数据分析中会介绍），我们又对每台服务器的日志做了一次调整，请求会先根据用户唯一标识的Hash转发到不同的服务器上。再扩容时就需要对每台服务器保存多少用户日志做估算了
第三阶段
当时这些采集服务器磁盘是200G左右，随着访问量的日益增加，本地磁盘可以保存的日志天数越来越少。而且原来的一天同步一次日志的方式，会导致一过凌晨多台服务器一起同步大量日志会占满磁盘阵列服务器的内网带宽和IO，所以我们改成了每小时保存一个日志，每小时同步一次的做法。这样两个问题都解决了
总结一下遇到的问题：
- 服务器监控层面的缺失，包括单点服务器健康状态（负载、磁盘、心跳）
- 单点服务器宕机，导致部分未同步到磁盘阵列的日志丢失，其它服务器压力较大时可能会出现问题
- 日志同步磁盘阵列失败的检查缺失。虽然失败可以重新同步，但会影响当天的数据分析完成时间
- 磁盘阵列内网带宽和IO瓶颈。在此架构下由于流量越来越大，日志越来越多，磁盘阵列瓶颈也显现了出来，直接影响当天的数据分析完成时间
- 扩容和维护的成本越来越高
