大数据时代的争议：Spark 能替代 Hive 吗？

本文作者：曾就职传统通讯运营商，负责BI项目的开发；目前转型互联网公司，就职于某厂负责相关的大数据仓库建设工作。随着的几年的架构沉淀，工作上形成了离线以 Hive 为主，Spark 为辅, 实时处理用 Flink 的大数据架构体系及 Impala, Es，Kylin 等应用查询引擎。

随着业务的发展，日常工作中会面试各种各样的人，接触下来发现一个比较奇怪的现象：

学习 Spark 的面试者普遍认为 Spark 必然会替代 Hive 成为新的一代大数据仓库标准。

同时，培训市场也出现了 Hive 已经落后，学习大数据只要学习 Spark 相关言论。

但结合实际工作的情况来看，这类说法和实际情况并不相符，针对数据仓库的几个重要特征做了对比，说明各种利弊，希望对今后各位的面试有一定的帮助。

希望后续的面试者能够去积极了解一些数据仓库需要的配置组件及系统，避免人云亦云，面试的时候引起不必要的争议。

数据仓库特点	hive	spark
数据仓库是面向主题的	可以实现	可以实现
数据仓库是集成的(统一存储)	天然与 HDFS集成	可以将数据存储在 HDFS
数据仓库是不可更新的	满足	用 HDFS 可以满足
元数据管理	拥有自己的 meta 库	无 meta 库，需要用 Hive 的
数据源同步	Sqoop Flume 等配套组件	无相关配套组件

由上图可以看出，Spark 不适合作为数据仓库的点有如下几个方面：

• Spark 本身没有自己的存储与 meta 库两种最核心的东西，需要依赖 HDFS 和 Hive 的相关功能，而社区的发展趋势也没有往这边开发的意思，故 Spark 是作为一个计算引擎的定位长期存在的；
• RDD， DataSet、DataFrames 的三种计算形式 由于计算过程中没有一个持久化的计算元数据管理导致后续对于数据血缘的解析难度过大，无法满足数据仓库调度对于数据体系依赖分析及元数据管理相关要求，故不能作为数据仓库的主要使用方式；
• SparkSql 是最有潜力成为数据仓库的主要形式，但目前来说仍然是以 Hive meta库作为元数据管理 hdfs 作为数据存储，由于本身的 sql 解析器不如 Hive，一般情况下是用 Hive 的 sql 解析器来替换本身的解析器。本质来说 SparkSql 只是作为hive 的计算速度强化版使用；
• 在 CPU 密集任务及复杂计算任务上，它的性能及稳定性远远比不上 Hive；
• Spark 在运行过程中经常会出现内存错误。
  

反观 Hive，拥有一套完整的 hadoop 生态组件

• Sqoop 支持 RDS 到 Hive(HDFS) 的互相同步；
• Flume 支持日志采集到 HDFS；
• 拥有自己一套完整的 meta 库支持元数据管理；
• 语言以 sql 为准，非常方便后续数据仓库的维护，比如数据血缘解析，过滤条件解析；
• Hive 的稳定性是目前的 Spark 无法保证的，在数据仓库做分层设计的情况下，底层的稳定性要求会远高于速度（如果底层一个任务失败，可能导致上层的几千个任务无法执行）。
  

基于上面的条件，以目前社区的发展趋势来说，Spark 替代 Hive 成为数据仓库的首选时间会比较漫长，而且随着 Hive 的 sql 执行引擎逐步优化后，Spark 的优势会越来越低。

就目前来说，SparkSql 作为数据仓库上层做加快查询的定位相对合适点，并不适合作为整套数据仓库的尤其是需要强稳定性的底层数据调度查询。

数据仓库是一套系统性工程，如果单纯以计算性能作为唯一选型标准，难免会陷入后续无尽的维护陷阱中。

本文来自微信公众号：进击的Coder（FightingCoder），作者：网易云课堂