在实际生产环境中已经形成了离线以Hive为主，Spark为辅, 实时处理用Flink的大数据架构体系及Impala, Es，Kylin等应用查询引擎
但是有很多学习Spark的程序员普遍认为Spark必然会替代Hive成为新的一代大数据仓库标准
同时，培训市场也出现了Hive已经落后，学习大数据只要学习Spark相关言论
但结合实际工作的情况来看，这类说法和实际情况并不相符，本文针对数据仓库的几个重要特征做了对比，说明各种利弊，希望对大家有一定的帮助
希望后续的大家能够去积极了解一些数据仓库需要的配置组件及系统，避免人云亦云，面试的时候引起不必要的争议
Hive VS Spark
| 数据仓库特点 |
hive |
spark |
| 数据仓库是面向主题的 |
可以实现 |
可以实现 |
| 数据仓库是集成的(统一存储) |
天然与HDFS集成 |
可以将数据存储在HDFS |
| 数据仓库是不可更新的 |
满足 |
用HDFS可以满足 |
| 元数据管理 |
拥有自己的mete库 |
无meta库，需要用Hive的 |
| 数据源同步 |
Sqoop Flume等配套组件 |
无相关配套组件 |
由上表可以看出，Spark不适合作为数据仓库主要有以下几点：
1)Spark本身没有自己的存储与meta库两种最核心的东西，需要依赖HDFS和Hive的相关功能，而社区的发展趋势也没有往这边开发的意思，故Spark是作为一个计算引擎的定位长期存在的；
2)RDD， DataSet、DataFrames的三种计算形式 由于计算过程中没有一个持久化的计算元数据管理导致后续对于数据血缘的解析难度过大，无法满足数据仓库调度对于数据体系依赖分析及元数据管理相关要求，故不能作为数据仓库的主要使用方式
3)SparkSql是最有潜力成为数据仓库的主要形式，但目前来说仍然是以Hive meta库作为元数据管理 hdfs作为数据存储，由于本身的sql解析器不如Hive，一般情况下是用Hive的sql解析器来替换本身的解析器。本质来说SparkSql只是作为hive的计算速度强化版使用
4)在cpu密集任务及复杂计算任务上，它的性能及稳定性远远比不上Hive
5)Spark在运行过程中经常会出现内存错误
再看Hive，拥有一套完整的Hadoop生态组件：
1)Sqoop支持RDS到Hive(HDFS)的互相同步
2)Flume支持日志采集到HDFS
3)拥有自己一套完整的meta库支持元数据管理
4)语言以sql为准，非常方便后续数据仓库的维护，比如数据血缘解析，过滤条件解析
5)Hive的稳定性是目前的Spark无法保证的，在数据仓库做分层设计的情况下，底层的稳定性要求会远高于速度（如果底层一个任务失败，可能导致上层的几千个任务无法执行）
基于上面所说的，所以Spark替代Hive成为数据仓库的首选时间会比较漫长，而且随着Hive的sql执行引擎逐步优化后，Spark的优势会越来越低
就目前来说，SparkSql作为数据仓库上层做加快查询的定位相对合适点，并不适合作为整套数据仓库的尤其是需要强稳定性的底层数据调度查询
数据仓库是一套系统性工程，如果单纯以计算性能作为唯一选型标准，难免会陷入后续无尽的维护陷阱中
