项目需求及架构设计

第2章 项目需求及架构设计

2.1 项目需求分析

1. 用户行为数据采集平台搭建
   用户行为数据会以文件的形式存储在服务器，这个阶段需要考虑：采集用户行为数据使用的工具,需要提供详细的设计需求
   如：flume，flume采用的 source、channel、sink以及flume代码的设计

2. 业务数据采集平台搭建
   将mysql中的业务数据导入到hive数仓中使用什么工具
   如：sqoop的安装、配置、使用

3. 数据仓库的维度建模
   数仓建模的分层：Ods原始数据层、dwd数据清洗层、dws以天为单位的轻度聚合层、dwt粗粒度聚合层、ads指标层

4. 分析，设备、会员、商品、地区、活动等电商核心主题，统计的报表主题近100个
   对老板关系的指标进行汇总分析

5. 采用即席查询工具，随时进行指标分析
   临时查询指标，可以快速查询出想要的结果情况

6. 对集群性能进行监控，发生异常需要报警
   如：hadoop某一进程出现了宕机，需要即使的进行报警处理，通过邮件、短信或者钉钉的方式通知开发人员，便于及时解决集群的异常

7. 元数据管理
   可以以图形的方式显示任务间的依赖关系，如果某一job的运行过程出现异常，可以通过血缘关系图查看受影响的job,从而挑选出优先级最高的job顺序解决
   在没有元数据管理的情况下，查询job间的影响关系。需要通过调度工具的脚本查看调度关系，手动进行查询。不便于数据的管理

8. 数据质量监控
   时刻监控近期指标间的差异，如果近期指标差异超过指定数值则通过短信、邮件或钉钉进行报警，让监控人员快速响应处理
   如：两天内指标差异超过30%以上通过短信、邮件或钉钉进行报警

9. 权限管理
   通过权限管理实现不同权限的用户可以看到不同的表、或者不同权限的用户可以看到某张表中不同的字段

2.2 项目框架

2.2.1 技术选型

1. 技术选型要考虑的因素
   数据量大小： 根据数据量的大小决定使用hdfs存储或者使用mysql存储数据
   业务需求： 根据实时数据的计算或者离线数据的计算来选择flink、spark或者hive
   行内经验： 根据行业内大厂所使用的技术框架进行技术选型
   技术成熟度： 技术的成熟度决定是否使用该技术 如：是否有成熟版本、是否有大厂在生产环境下使用、通常情况下中小型公司都会等待大厂调查成熟后才会使用
   开发维护成本： 结合公司情况，选择云服务器和物理服务器。需要考虑的因素有场地、维护人员、维护设备等方面。
   总成本预算： 因为项目经理也需要向公司申请资金，或许申请的资金达不到预期金额

2. 数据采集传输
   Flume: 日志文件的采集 如：将用户行为数据以json的形式存储在csv文件中，通过flume导入到hdfs中
   sqoop: 业务数据的传输 如：将mysql的业务数据导入到hive中
   kafka: 缓冲消峰的作用
   logstash: 与flume相同，只不过logstash是领英团队开发的与Es、Kibana为一套框架，理论来说elk框架之间的兼容性是最好的。而且ELK主要针对中小型公司或者数据量小的公司分析的指标不是很复杂DataX:

3. 数据存储
   Mysql： 存储小量数据，一般会将ads的指标存入mysql中供BI人员展示。
   Hdfs： 存储大量数据
   Hbase: 很多情况下会与kylin组合使用，kylin会将数据存储到Hbase中
   Redis: 基于内存的数据库、存储实时数据
   MongoDB: 爬虫数据一般会存储于MongDB中

4. 数据计算
   Hive: 数据走MR程序需要落盘所以速度较慢
   Tez: 完全在内存中进行计算，内存消耗强但是查询速度快
   Spark: 部分数据在内存中、部分数据在磁盘里。相对MR引擎会快
   Flink/ Stom: 主要用于实时数据的计算

5. 数据的查询
   Presto/Kylin/Impala:通常情况离线查询会选择的框架
   Druid/ClickHouse/Doris:实时查询选择的框架

6. 数据可视化
   Echarts（开源免费）、
   Superset（开源免费）、
   QuickBi(ali收费针对离线)、
   DataV（ali收费针对实时）、
   fineReport（付费与免费版本的区别在于并发访问仅支持2个，以及部分功能的水印）

7. 任务调度
   Azkaban(中小型公司的选择、简单实用、上手快框架较轻)、
   Oozie(功能多框架重)
   DolphinScheduler(丰富的可视化页面)
   Airflow(python编写，懂python适合)

8. 集群监控
   服务器组件宕机能够及时检测到
   Zabbix（离线）、Prometheus(实时)

9. 元数据管理
   Atlas（中大公司使用）：任务量少只有几十个任务，使用atlas的意义并不大。与手动查看任务的效率区别并不大、
   任务量多有成百上千的任务，atlas的意义便会很大、图形化界面通过肉眼查看血缘关系图找到受影响的job,从而挑选出优先级最高的job顺序解决

10. 权限管理
    Ranger(主流): 通过权限管理实现不同权限的用户可以看到不同的表、或者不同权限的用户可以看到某张表中不同的字段

2.2.2 系统数据流程设计

1. 项目需求： 无论做什么项目首先需要对项目需求进行了解
2. 集群规模： 需要了解企业数据量的大小
3. 服务器选型： 先了解企业购买服务器、没有的情况下建议物理机还是云服务器
4. 框架的版本：
   可以选择免费的apache（运维麻烦、需要考虑组件兼容性问题）
   也可以选择CDH（CDH已经开始收费了1万美金/年，目前官网不再提供免费安装包。旧版本安装包依旧可以照常使用，但是不能确定的是一段时间后是否也会开启收费策略，在已经部署并且存在大量数据的前提下，突然收费会造成很多不必要的麻烦）

2.2.3 框架版本选型

具体版本号

2.2.4 服务器选型

1. 服务器的选择
   服务器选择物理机还是云主机?
   1) 物理机:
   以128G内存，20核物理CPU，40线程，8THDD和2TSSD硬盘，戴尔品牌
   单台报价4W出头。一般物理机寿命5年左右。
   需要有专业的运维人员，平均一个月1万。电费也是不少的开销。
   2)云主机:
   云主机:以阿里云为例，差不多相同配置，每年5W。
   很多运维工作都由阿里云完成，运维相对较轻松
   3）企业选择
   金融有钱公司和阿里没有直接冲突的公司选择阿里云
   中小公司、为了融资上市，选择阿里云，拉到融资后买物理机。
   有长期打算，资金比较足，选择物理机。

2.2.5 集群规模

1. 如何确认集群规模?
   （假设:每台服务器8T磁盘，128G内存)
   （1）每天日活跃用户100万，每人一天平均100条: 100万100条=1亿条
   （2）每条日志IK左右，每天1亿条:I00000000/1024/1024=约100G
   （3）半年内不扩容服务器来算:100G180天=约18T
   （4）保存3副本:18T3=5.4T
   （5）预留20%-30%Buf=54T/0.7-77T(6）算到这:约8T*10台服务器

2.2.6 集群资源规划设计

在企业中通常会搭建一套生产集群和一套测试集群。生产集群运行生产任务，测试集群用于上线前代码编写和测试。

1）生产集群
（1）消耗内存的分开
（2）数据传输数据比较紧密的放在一起（Kafka 、Zookeeper）
（3）客户端尽量放在一到两台服务器上，方便外部访问
（4）有依赖关系的尽量放到同一台服务器（例如：Hive和Azkaban Executor）

1	2	3	4	5	6	7	8	9	10
nn	nn	dn	dn	dn	dn	dn	dn	dn	dn
		rm	rm	nm	nm	nm	nm	nm	nm
		nm	nm
							zk	zk	zk
							kafka	kafka	kafka
							Flume	Flume	flume
		Hbase	Hbase	Hbase
hive	hive
mysql	mysql
spark	spark
Azkaban	Azkaban				ES	ES

2）测试集群服务器规划

服务名称	子服务	服务器	服务器	服务器
		hadoop102	hadoop103	hadoop104
HDFS	NameNode	√
	DataNode	√	√	√
	SecondaryNameNode			√
Yarn	NodeManager	√	√	√
	Resourcemanage		√
Zookeeper	Zookeeper Server	√	√	√
Flume（采集日志）	Flume	√	√
Kafka	Kafka	√	√	√
Flume（消费Kafka）	Flume			√
Hive	Hive	√
MySQL	MySQL	√
Sqoop	Sqoop	√
Presto	Coordinator	√
	Worker		√	√
Azkaban	AzkabanWebServer	√
	AzkabanExecutorServer	√
Spark		√
Kylin		√
HBase	HMaster	√
	HRegionServer	√	√	√
Superset		√
Atlas		√
Solr	Jar	√
服务数总计		19	8	8