在大数据处理框架不断更新和优化的过程中，Hadoop和Spark之间既有竞争关系，也有相互协同的需求。比方说Hive和Spark，在一段时间内，很多人认为Spark会代替Hive，作为Hadoop的数据仓库，Hive真的已经落后了吗？
这种说法我们是不赞同的，因为作为数据仓库来说，Hive和Spark之间，Spark真的没有压倒性的优势，下图我们做了一个对比——
由上图可以看出，Spark并不适合作为数据仓库：
首先，Spark本身没有自己的存储与meta库，这两者是数据仓库最核心的东西。Spark需要依赖HDFS和Hive的相关功能，并且现在来看，也没有开发这一块相关功能的意思。
RDD，DataSet、DataFrames的三种计算形式由于计算过程中没有一个持久化的计算元数据管理导致后续对于数据血缘的解析难度过大，无法满足数据仓库调度对于数据体系依赖分析及元数据管理相关要求，故不能作为数据仓库的主要使用方式。
Spark Sql是最有潜力成为数据仓库的主要形式，但目前来说仍然是以Hive meta库作为元数据管理hdfs作为数据存储，由于本身的sql解析器不如Hive，一般情况下是用Hive的sql解析器来替换本身的解析器。
本质来说Spark Sql只是作为hive的计算速度强化版使用。并且，在CPU密集任务及复杂计算任务上，它的性能及稳定性远远比不上Hive。
而Hadoop Hive，拥有一套完整的Hadoop生态组件。
Sqoop支持RDS到Hive(HDFS)的互相同步；Flume支持日志采集到HDFS；拥有自己一套完整的meta库支持元数据管理；语言以sql为准，非常方便后续数据仓库的维护，比如数据血缘解析，过滤条件解析。
Hive的稳定性是目前的Spark无法保证的，在数据仓库做分层设计的情况下，底层的稳定性要求会远高于速度（如果底层一个任务失败，可能导致上层的几千个任务无法执行）。
总的来说，Hive和Spark在数据仓库这一块上，Hive依然有着不可替代的优势，尤其是稳定性，这是Spark不能保证的，而作为提供底层支持的数据仓库，稳定性这一点比其他很多都要重要。
