用户日志分析系统实战（一）

用户日志分析系统实战（一）

接下来的博客是一个连续的部分，主要分为：
1. 用户日志分析系统实战（一），讲解背景及架构设计
2. 用户日志分析系统实战（二），日志收集与文件存储及其优化
3. 用户日志分析系统实战（三），资源管理与ETL及其优化
4. 用户日志分析系统实战（四），数据建模、分析与查询
5. 用户日志分析系统实战（五），用户行为分析
6. 用户日志分析系统实战（六），架构思考与改进

1 背景

1.1 日志分析

日志分析是每个互联网公司业务流中不可或缺的一部分，从海量数据中，可以分析用户的行为，从而运用到智能预测或者异常检测中去。相比于传统的大数据分析（如用户物品评分预测），日志分析具有这么几个特征：

• 数据是动态的。传统的大数据分析，往往是基于已有的数据去处理，这些数据都是固定不变的。而对于日志分析，只要产品还在运营，日志就会源源不断地产生，很难去规定一个节点去进行静态的处理分析。

• 数据是多方面的。公司的产品往往不止一个，同一个产品也分为web，android和IOS。因此，所需要处理的日志往往是从多个端口同时产生的。如何对这些数据进行统一收集，统一分析，同时又要做好防灾备份处理，也是日志分析的一个关键点。

该用户日志分析系统主要是面向订单交易方面进行设计的。

1.2 数据简介

• 日志数据

  • 搜索、收藏、加入购物车、评论、购买等

• 基本信息

  • 用户信息，商品信息

1.3 目标

• 数据

  • 用户注册数据（数据量小）
  • 产品基本信息（数据量小）
  • 用户交易数据（数据量大）

• 主要功能

  • 报表统计（每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的容错，以及现在技术相当的成熟