用户日志分析系统实战（一）
接下来的博客是一个连续的部分，主要分为：
1. 用户日志分析系统实战（一），讲解背景及架构设计
2. 用户日志分析系统实战（二），日志收集与文件存储及其优化
3. 用户日志分析系统实战（三），资源管理与ETL及其优化
4. 用户日志分析系统实战（四），数据建模、分析与查询
5. 用户日志分析系统实战（五），用户行为分析
6. 用户日志分析系统实战（六），架构思考与改进
1 背景
1.1 日志分析
日志分析是每个互联网公司业务流中不可或缺的一部分，从海量数据中，可以分析用户的行为，从而运用到智能预测或者异常检测中去。相比于传统的大数据分析（如用户物品评分预测），日志分析具有这么几个特征：
数据是动态的。传统的大数据分析，往往是基于已有的数据去处理，这些数据都是固定不变的。而对于日志分析，只要产品还在运营，日志就会源源不断地产生，很难去规定一个节点去进行静态的处理分析。
数据是多方面的。公司的产品往往不止一个，同一个产品也分为web，android和IOS。因此，所需要处理的日志往往是从多个端口同时产生的。如何对这些数据进行统一收集，统一分析，同时又要做好防灾备份处理，也是日志分析的一个关键点。
该用户日志分析系统主要是面向订单交易方面进行设计的。
1.2 数据简介
-
日志数据
- 搜索、收藏、加入购物车、评论、购买等
-
基本信息
- 用户信息，商品信息
1.3 目标
-
数据
- 用户注册数据（数据量小）
- 产品基本信息（数据量小）
- 用户交易数据（数据量大）
-
主要功能
- 报表统计（每10分钟，1小时/天/月/年）
- 不同年龄分布消费的金额
- 不同城市消费的情况
- 不同年龄消费商品类别情况
- 实时分析
- 热门商品排行榜
- 实时交易（城市）
- 报表统计（每10分钟，1小时/天/月/年）
2 系统设计要求
基本需求1 - 功能
支持多种数据源
保证数据不丢失（或少量丢失）
数据集中存储
基本需求2 - 性能
大规模数据（每天10TB-100TB）的收集和分析
近实时分析和离线分析
基本要求3 - 架构
扩展性
容错性
3 初期架构
以上架构存在一些问题。该架构虽然满足了数据仓库的基本要求，且能够处理海量数据，系统的扩展性和容错性也极好，同时还借助与Presto提高了查询性能，但是数据延迟高是其缺点（数据从产生到入库，再到查询，整个周期长）。
4 架构改造
改造后的架构，日志经由Flume，入库到Kafka，Spark Streaming去消费Kafka的数据，入库到MySQL；同时还有一部分数据存储HDFS，通过MR和Spark进行离线批量分析。
-
为什么不直接入库到HDFS，然后经由MR和Spark进行处理，这样做有什么好处？
-
改进
- 使用Spark Streaming系统降低数据延迟
-
优点
- 满足了数据仓库的基本要求
- 能够处理海量数据
- 系统扩展性和容错性极好
- 实时性较好
- 数据延迟低
-
5 为什么选择Kafka和Spark Streaming
由于Kafka简单的架构及其出色的吞吐量
Kafka和Spark Streaming也有专门的集成模块
Spark的容错，以及现在技术相当的成熟