1.0 需求概述

1.1 实时需求与离线需求的比较

• **离线需求（T+1）：**一般是根据前一日的数据生成报表等数据，虽然统计指标、报表繁多，但是对时效性不敏感。

• 实时需求（T+0）：主要侧重于对当日数据的实时监控，通常业务逻辑相对离线需求简单一下，统计指标也少一些，但是更注重数据的时效性(从查询到出结果的时间比较短)，以及用户的交互性。

• 即席查询:主要侧重于临时性 不需要每天都去跑的任务

1.2 需求说明

1.2.1 日用户首次登录（日活）分时趋势图，昨日对比

数据流:用户行为数据 --> HBase(Phoenix)

• 为什么不用MySQL而用Phoenix:
  • 去重:
    • 跨批次去重 --> Redis去重
    • 同批次去重 --> groupByKey(mid)
    • 行列过滤:能过滤的数据就先过滤 先选择去重力度较大的 所以先做跨批次去重
  • HBASE(ES):
    • HBASE : 存明细(去重之后的数据)
      • 可以计算不同维度上做需求
      • 精准一次性,直接使用幂等性
      • 数据量大(缺点)
    • MySQL : 存结果(计算完成的结果)
      • 不能计算不同维度上做需求
      • 精准性一次性,需要用事务
      • 数据量小(缺点)

1.2.2 交易额及分时趋势图，昨日对比

数据流:用户业务数据 --> HBase(Phoenix)

核心:学习采集业务数据(canal)

1.2.3 购物券功能风险预警

数据流:用户行为数据 --> ES

学习重点:

1. Sparkstreaming对接ES
2. kibana可视化

1.2.4 用户购买明细灵活分析功能

数据流:用户业务数据 --> ES

es不支持join,所以要把需要的数据所在表先join在一起,再放在es,重点就是双流怎么join,实时中会有网络延迟不在同一个批次

2.0 架构分析

2.1 架构图一

• 一台业务服务器:处理1000-2000
• 可能只需要5-6台日志服务器,因为flume要搭在日志服务器上
• taildir source (断点续传) flume怎么确定一个唯一的offset:((inode,绝对路径),position)
  • log4j框架的打印方式:就是会修改上次的日志的名字
  • logback:刚开始就带上日期的log名字
• kafka channel :直接写在kafka 不需要sink
• 为什么要用kafka:供不同的消费者消费,方便扩展业务线(新的业务线 需要停机 写配置 多加一个sink channel 等);解耦;削峰.
• 为什么中间加上消费flume : kafka要是直接到hdfs 需要些代码,但是flume消费者有现成的组件(kafka source ,hdfs sink)
• kafka 副本:高可用
• 如果说实时性不高怎么办 : 有考虑安全性 解耦

2.2 架构图二

• 如果说耦合性太高怎么办 : 要实时性高的,在同一个机房,而且公司小数据量不大,够用了

3.0 基础工程搭建

3.1 父工程

3.2 子模块之公共模板

3.3 子模块之模拟数据模块

4.0 日志采集系统搭建

4.1 子模块之日志采集模块—(本地测试)

4.1.1 SpringBoot 简介

• 优点:

  • 不再需要那些千篇一律，繁琐的xml文件。
  • 内嵌Tomcat,不再需要外部的Tomcat
  • 更方便的和各个第三方工具（mysql,redis,elasticsearch,dubbo,kafka等等整合），而只要维护一个配置文件即可。

• springboot三层架构:controller(响应请求) ->service(做计算的) -> DAO(操作持久化层)

4.1.2 快速搭建

4.2 日志采集模块打包部署—(单机部署)

4.3 搭建日志采集集群—(集群部署)

测试所需的进程:

linux : zk, kafka hadoop hbase phoenix redis nginx springboot

idea : DauApp Mocker

linux : zk, kafka hadoop hbase phoenix redis

idea : DauApp Mocker(local host),springboot