第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