第2章 项目需求及架构设计
2.1 项目需求分析
1)采集平台
(1)用户行为数据采集平台搭建
(2)业务数据采集平台搭建
2)离线需求
主题 | 子主题 | 指标 |
流量主题 | 各渠道流量统计 | 当日各渠道独立访客数 |
当日各渠道会话总数 | ||
当日各渠道会话平均浏览页面数 | ||
当日各渠道会话平均停留时长 | ||
当日各渠道跳出率 | ||
路径统计 | 路径分析 | |
用户主题 | 用户变动统计 | 流失用户数 |
回流用户数 | ||
用户留存统计 | 新增留存率 | |
用户活跃统计 | 新增用户数 | |
活跃用户数 | ||
用户行为漏斗分析 | 首页浏览人数 | |
商品详情页浏览人数 | ||
加购人数 | ||
下单人数 | ||
支付人数 | ||
新增用户下单统计 | 新增下单人数 | |
新增支付成功人数 | ||
最近7日内连续3日下单用户数 | ||
商品主题 | *复购率统计 | 最近30日各品牌复购率 |
各品牌商品下单统计 | 各品牌订单数 | |
各品牌订单人数 | ||
各品类商品交易统计 | 各品类订单数 | |
各品类订单人数 | ||
购物车存量统计 | 各分类商品购物车存量Top3 | |
各品牌商品收藏次数Top3 | ||
下单到支付时间间隔平均值 | ||
各省份交易统计 | 各省份订单数 | |
各省份订单金额 | ||
优惠券主题 | 优惠券使用率统计 | 使用次数 |
使用人数 |
3)实时需求
主题 | 子主题 | 指标 |
流量主题 | 各渠道流量统计 | 当日各渠道独立访客数 |
当日各渠道会话总数 | ||
当日各渠道会话平均浏览页面数 | ||
当日各渠道会话平均停留时长 | ||
当日各渠道跳出率 | ||
流量分时统计 | 当日各小时独立访客数 | |
当日各小时页面浏览数 | ||
当日各小时新房客数 | ||
新老访客流量统计 | 各类访客数 | |
各类访客页面浏览数 | ||
各类访客平均在线时长 | ||
各类访客平均页面浏览数 | ||
关键词统计 | 当日各关键词评分 | |
用户主题 | 用户变动统计 | 当日回流用户数 |
用户新增活跃统计 | 当日新增用户数 | |
当日活跃用户数 | ||
用户行为漏洞分析 | 当日首页页面浏览人数 | |
当日商品详情页浏览人数 | ||
当日加购人数 | ||
当日下单人数 | ||
当日支付成功人数 | ||
新增交易用户统计 | 当日新增下单人数 | |
当日新增支付成功人数 | ||
商品主题 | *复购率统计 | 最近7/30日截止当前各品牌复购率 |
各品牌商品交易统计 | 当日各品牌订单数 | |
当日各品牌订单人数 | ||
当日各品牌订单金额 | ||
当日各品牌退单数 | ||
当日各品牌退单人数 | ||
各品类商品交易统计 | 当日各品类订单数 | |
当日各品类订单人数 | ||
当日各品类订单金额 | ||
当日各品类退单数 | ||
当日各品类退单人数 | ||
各SPU商品交易统计 | 当日各SPU订单数 | |
当日各SPU订单人数 | ||
当日各SPU订单金额 | ||
交易主题 | 交易综合统计 | 当日订单总额 |
当日订单数 | ||
当日订单人数 | ||
当日退单数 | ||
当日退单人数 | ||
各省份交易统计 | 当日省份订单数 | |
当日省份订单金额 | ||
优惠券主题 | 优惠券补贴率统计 | 当日优惠券补贴率 |
活动 | 活动补贴率统计 | 当日活动补贴率 |
4)思考题
1、项目技术如何选型?
2、框架版本如何选型(Apache、CDH、HDP)
3、服务器使用物理机还是云主机?
4、如何确认集群规模?(假设每台服务器8T硬盘)
2.2 项目框架
2.2.1 技术选型
2.2.2 系统数据流程设计
系统数据流程图
2.2.3 框架版本选型
1)如何选择Apache/CDH/HDP版本?
- Apache:运维麻烦,组件间兼容性需要自己调研。(一般大厂使用,技术实力雄厚,有专业的运维人员)(建议使用)
- CDH:国内使用最多的版本,但CM不开源,今年开始收费,一个节点1 万美金/年。
- HDP:开源,可以进行二次开发,但是没有CDH稳定,国内使用较少
2)云服务选择
- 阿里云的EMR、MaxCompute、DataWorks
- 亚马逊云EMR
- 腾讯云EMR
- 华为云EMR
具体版本型号:Apache框架版本
注意事项:框架选型尽量不要选择最新的框架,选择最新框架半年前左右的稳定版。
2.2.4 服务器选型
服务器选择物理机还是云主机?
1)物理机:
- 以128G内存,20核物理CPU,40线程,8THDD和2TSSD硬盘,戴尔品牌单台报价4W出头。一般物理机寿命5年左右。
- 需要有专业的运维人员,平均一个月1万。电费也是不少的开销。
2)云主机:
- 云主机:以阿里云为例,差不多相同配置,每年5W。
- 很多运维工作都由阿里云完成,运维相对较轻松
3)企业选择
- 金融有钱公司和阿里没有直接冲突的公司选择阿里云
- 中小公司、为了融资上市,选择阿里云,拉倒融资后买物理机。
- 有长期打算,资金比较足,选择物理机。
2.2.5 集群规模
1)如何确认集群规模?(假设:每台服务器8T磁盘,128G内存)
(1)每天日活跃用户100万,每人一天平均100条(50-200):100万*100条=1亿条
(2)每条日志1K(0.5k-2k)左右,每天1亿条:100000000/1024/1024=约100G
(3)半年内不扩容服务器来算:100G*180天=约18T
(4)保存3副本*:18T3=54T
(5)预留20%~30%Buf=54T/0.7=77T
(6)算到这:约8T*10台服务器
2)如果考虑数仓分层?数据采用压缩?需要重新再计算
2.2.6 集群资源规划设计
在企业中通常会搭建一套生产集群和一套测试集群。生产集群运行生产任务,测试集群用于上线前代码编写和测试。
1)生产集群
(1)消耗内存的分开
(2)数据传输数据比较紧密的放在一起(Kafka、Zookeeper)
(3)客户端尽量放在一到两台服务器上,方便外部访问
(4)有依赖关系的尽量放到同一台服务器(例如:Hive和Azkaban Executor)
Master | Master | core | core | core | common | common | common |
---|---|---|---|---|---|---|---|
nn | nn | dn | dn | dn | JournalNode | JournalNode | JournalNode |
rm | rm | nm | nm | nm | |||
zk | zk | zk | |||||
hive | hive | hive | hive | hive | |||
kafka | kafka | kafka | |||||
spark | spark | spark | spark | spark | |||
datax | datax | datax | datax | datax | |||
Ds-master | Ds-master | Ds-worker | Ds-worker | Ds-worker | |||
maxwell | |||||||
supset | |||||||
mysql | |||||||
flume | flume | ||||||
flink | flink | ||||||
clickhouse | |||||||
redis | |||||||
hbase |
2)测试集群服务器规划
服务名称 | 子服务 | hdp101 | hdp102 | hdp103 |
---|---|---|---|---|
HDFS | NameNode | √ | ||
DataNode | √ | √ | √ | |
SecondaryNameNode | √ | |||
Yarn | NodeManager | √ | √ | √ |
Resourcemanager | √ | |||
Zookeeper | Zookeeper Server | √ | √ | √ |
Flume(采集日志) | Flume | √ | √ | |
Kafka | Kafka | √ | √ | √ |
Flume | ||||
(消费Kafka日志) | Flume | √ | ||
Flume | ||||
(消费Kafka业务) | Flume | √ | ||
Hive | √ | √ | √ | |
MySQL | MySQL | √ | ||
DataX | √ | √ | √ | |
Spark | √ | √ | √ | |
DolphinScheduler | ApiApplicationServer | √ | ||
AlertServer | ||||
MasterServer | √ | |||
WorkerServer | √ | √ | √ | |
LoggerServer | √ | √ | √ | |
Superset | Superset | √ | ||
Flink | √ | |||
ClickHouse | √ | |||
Redis | √ | |||
Hbase | √ | |||
服务数总计 | 20 | 11 | 12 |