- 1.项目需求
- 1.1 需求来源
- 1.2 需求概览
- 1.3 技术选型
- 1.3.1 技术选型考虑因素
- 1.3.2 数据采集传输选择
- 1.3.3 数据存储框架选择
- 1.3.4 计算引擎的选型
- 1.3.5 即席查询
- 1.3.6 数据可视化
- 1.3.7 任务调度
- 1.3.8 集群服务监控
- 1.3.9 元数据管理
- 1.3.10 权限管理框架
- 1.4 系统数据流程设计
- 1.5 框架版本选型
- 1.6 服务器选型
- 1.7 集群规模
- 1.8 集群资源规划设计
项目中有哪些需求，以及解决这些需求需要的架构设计 1.项目需求 1.1 需求来源
项目需求一般都是由产品经理提出来的，需要做哪些事情
产品经理又是从哪获取的需求呢?
(1)老板提出的需求
(2)客户提出的需求
(3)开发人员觉得这个需求对公司有用
需要重点关注我们是如何解决每一个需求的，也是考核我们对数仓的理解和学习的成都的重要指标；
（1）数据量大小
如果数据量小，用Mysql就行了
（2）业务需求
对实时性的要求，比如要求秒级返回查询结果
实时性要求不高，就可以用批处理等
（3）行业内经验
各个大厂在做实时计算，都是用flink
（4）技术成熟度
数仓
中台
数据湖
（5）开发维护成本以及总成本预算
用云主机还是自己买物理机
本项目中使用的方案：
- Flume:文件日志
- Sqoop:采集业务数据
- Kafka: 削峰、解耦
备选方案：
- logStash 也可以采集文件日志；
其为ELK三大框架之一，ES、Kibana、logstash
ELK框架针对的是中小型公司，数据量不大，分析指标不复杂； - DataX 也可以采集业务数据；和Sqoop的市场占有率55开（全体起立）
本项目中使用的方案：
- Mysql ： 存储ADS报表层的结果数据
- HDFS ：存储大量数据
- Hbase：存储Kylin多维分析的结果数据
数仓中未使用到的：
- Redis：实时计算中会使用，离线数仓用不到
- MongDB : 存储结果数据
本项目中使用的方案：
- Hive : MR
- Spark: 基于内存
项目中使用的是Hive on Spark；表面用的是HQL，底层是Spark程序
数仓项目未使用：
- Tez：基于内存计算
- Flink
- Storm
这三个框架适用于实时计算
适用于临时查看一些需求指标；而不是数仓中稳定调度的报表指标；
离线场景中：
- Presto : 离线场景使用 Apache的
- Kylin ： 离线场景使用
- Impala ： CDH的框架
实时数仓中：
- Druid
- ClickHouse
- Doris
开源免费的：
- Echarts
- Supreset
收费的： - QuickBI ： 针对离线
- DataV ： 针对实时
- Azkaban: 中小型公司用的多；
- Oozie: 功能多，框架重
- DolphinScheduler: 国内的开源工具
- Airflow: python脚本调度
- Zabbix：离线项目中使用
- Prometheus：实时项目中使用
- Atlas : 可以管理任务的血缘依赖关系，挂掉的任务对哪些任务有影响
可以管理数仓中哪些表、字段可以给哪些用户查询或者修改
- Ranger: 主流的框架
- Sentry:被Apache除名了
（1）Nginx负载均衡的作用
（2）日志文件保存30天
（3）Flume->kafka->HDFS kafka起缓存作用
CDH 6.3.2版本之后就开始收费了
云产品使用的多；
也就是说中型公司，日活100w左右的，数据存储半年的，大约需要10台服务器；
一般来说10台服务器够用了；
在企业中通常会搭建一套生产集群和一套测试集群。生产集群运行生产任务，测试集群用于上线前代码编写和测试。
1）生产集群
（1）消耗内存的分开
（2）数据传输数据比较紧密的放在一起（Kafka 、Zookeeper），减少数据的网络传输
（3）客户端尽量放在一到两台服务器上，方便外部访问；涉及权限开放问题，所以尽量将客户端放置在同一台机器上
（4）有依赖关系的尽量放到同一台服务器（例如：Hive和Azkaban Executor）
