数仓技术选型

## 一、选型主要考虑因素
- 数据量大小
- 业务需求
- 行业内经验
- 技术成熟度
- 开发维护成本
- 总成本预算

## 二、具体选型
### 2.1 数据采集传输
- **Flume**
	- 适合数仓功能复杂，完善Hadoop，Hive一套
- **Kafka**
	- 数据量大将数据慢慢往数仓转移
- **Sqoop**
	- 与DataX市场占有55开
- **Logstash**
	- ELK组件之一，针对中小型公司或者数据量比较小的公司，分析指标不是特别复杂，简单的查询处理
- **DataX**
	- 与Sqoop市场占有55开

#### 2.1.1 Sqoop与DataX的差别

|      | Sqoop                       | DataX                                       |
|------|-----------------------------|---------------------------------------------|
| 采集模式 | sqoop采用map-reduce计算框架进行导入导出 | 在单台机器上对数据进行抽取和加载                            |
| 采集速度 | 快                           | 慢                                           |
| 数据源  | 只支持关系型数据库和Hadoop之间          | 实现关系型数据库hadoop组件之间、关系型数据库之间、hadoop组件之间的数据迁移 |
| 支持性  | 对hadoop支持度好                 | 不支持高版本Hadoop                                |
| 插件   | 只支持关系型数据库和Hadoop之间          | 根据用户自身需求修改文件生成插件                            |

#### 2.1.2 Sqoop与DataX性能对比

|              | Sqoop 平均速率(MB/s) | DataX 平均速率(MB/s) |
|--------------|------------------|------------------|
| mysql->hdfs  | 20.0809          | 4.95             |
| oracle->hdfs |  6.4137      | 5.14        |

### 2.2 数据存储
- **MySQL**
	- 存储小量数据，结果，报表数据——ADS层
- **HDFS**
	- 能存储数据量大，存储海量数据——DWD层
- **HBase**
	- 存储Atlas多维分析的结果数据
- **Redis**
	- 实时数仓使用
- **MongoDB**
	- 爬虫数据存储MongoDB

### 2.3 数据计算
- **Hive**
	- 底层走的是MapReduce
- **Tez**
	- 放在内存中进行计算，需要消耗内存
- **Spark**
	- 部分放在内存，部分放在磁盘，保证可靠性，也加快计算速度
- **Flink**
	- 主要用来处理实时业务
- **Storm**
	- 主要用来处理实时业务

#### 2.3.1 Storm 和 Flink 对比
|      | Storm                                                        | Flink                                               |
|------|--------------------------------------------------------------|-----------------------------------------------------|
| 状态管理 | 无状态，需用户自行进行状态管理                                              | 有状态                                                 |
| 窗口支持 | 对事件窗口支持较弱，缓存整个窗口的所有数据，窗口结束时一起计算                              | 窗口支持较为完善，自带一些窗口聚合方法，并且会自动管理窗口状态。                    |
| 消息投递 | At Most Once                                                 | At Most Once                                        |
|      | At Least Once                                                | At Least Once                                       |
|      |                                                              | Exactly Once                                        |
| 容错方式 | ACK机制 ：对每个消息进行全链路跟踪，失败或超时进行重发。                               | 检查点机制 ：通过分布式一致性快照机制，对数据流和算子状态进行保存。在发生错误时，使系统能够进行回滚。 |
| 应用现状 | 在美团点评实时计算业务中已有较为成熟的运用，有管理平台、常用 API 和相应的文档，大量实时作业基于 Storm 构建。 | 在美团点评实时计算业务中已有一定应用，但是管理平台、API 及文档等仍需进一步完善。          |

### 2.4 数据查询
- **Presto**
	- 离线快速即席查询，属于Apache 效果比Impala更好
- **Kylin**
	- 离线快速查询，与Hbase一起使用
- **Impala**
	- 离线快速即席查询，CDH使用Impala
- **Druid**
	- 快速实时查询，实时数仓用的较多
- **ClickHouse**
	- 快速实时查询，实时数仓用的较多
- **Doris**
	- 快速实时查询，实时数仓用的较多

### 2.5 数据可视化
- Echarts
	- 开源免费
- Superser
	- 开源免费
- QuickBi
	- 效果优于开源免费，针对离线数据展示
- DataV
	- 效果优于开源免费，实时快速大屏展示

### 2.6 任务调度
- Azkaban
	- 中小型公司。简单使用上手快
- Oozie
	- 功能多，框架重，效率低
- DolphinScheduler
	- 可视化页面非常好看，用起来舒服
- Airflow
	- Python脚本编写

### 2.7 集群监控
- Zabbix
	- 离线
- Prometheus
	- 实时

### 2.8 元数据管理
- Atlas
	- 中大型公司

### 2.9 权限管理
- Ranger
	- HDP,主流使用
- Sentry
	- CDH