作者：狗叔
链接：https://www.zhihu.com/question/36053025/answer/121404733
来源：知乎
著作权归作者所有，转载请联系作者获得授权。
Hive是什么？一个建立在分布式存储系统（这里指HDFS）上的SQL引擎。
为什么要有Hive呢？因为有了Hadoop后，大家发现存储和计算都有了，但是用起来很困难。去厂商那里一看，清一色Oracle、DB2、TD啥啥的，客户被惯的只会用SQL来处理业务，难一点都交给乙方来做。
转头一想，劳资拿个项目，总不能搭一堆维护人员天天在局点给你们维护你们写的（也有可能是自己写的）超烂的MR代码吧？嗯，在MR上包一层，继续让你们用SQL，就好了嘛
Hive适合的是什么场景呢？数据仓库。基于Hadoop做一些数据清洗啊（ETL）、报表啊、数据分析啊什么的。
传统数据库的SQL03 SQL11标准、自定义函数、权限管理，支持！
JDBC、ODBC、REST接入，支持！
存储过程，支持！
分布式的scale out，支持！
事务处理、一致性、回滚，这个比较难，但是也努力支持！
基本上就是朝着替代传统数据库的方向去的，当然是在大数据背景下的替代。本质上来说，它还是一个面向读的、面向分析的SQL工具。
你问它有什么缺点？天天插入、更新、删除数据，还要求强一致性和毫秒级相应，这个不仅不是Hive的长处，当前的Hadoop框架就不适合这玩意儿。
好，回过头来再说Spark SQL。
SparkSQL是啥呢？这个首先要问Spark是啥。
Spark就是以RDD为核心的计算框架，它产生的背景就是MR难用！慢！
于是Spark搞了一个抽象概念RDD，把map过程都串起来，内存用起来，再做点流水线优化。嗯，快了10到100倍（官方宣称）！
RDD上面抽象一些高级操作，替代MR单纯的map和reduce，简化编程；加上Python、R、Java、Scala等等的接口，谁来用都能无缝切换。嗯，易用性大大增加！
那既然有了RDD这么牛逼的东西，总不能只让用户去写应用处理离线任务吧。流处理，上！机器学习，上！SQL，上！哈哈哈哈哈我一个Spark啥都能搞定，你们就不用费心去用别的东东了！
那SparkSQL对比Hive有啥缺点呢？
由于前者发展时间短，且大数据领域Hive、HBase等等都已经快形成了事实标准，所以SparkSQL一直在吹嘘自己的一栈式数据处理平台，试图从易用性上争取用户。但用户是不是真的需要这些呢？未必。从Spark发展的过程来看，SparkSQL的发展速度远远超过Core、Streaming、MLlib、GraphX等；从语言来看，对Scala的支持也远远超过了Java、R、Python的关注。这说明了一栈式处理虽然看起来很美，但用户未必有这样的场景。
单就SparkSQL来讲呢？由于已经有了Hive（而避免重复造差不多的轮子），所以像Metastore、权限、JDBC这些东东，SparkSQL要么直接复用Hive的，要么干脆不做。
那SparkSQL究竟重点在做什么呢？性能、稳定性、标准兼容性，这是社区2.0版本比较关注的东西，也是Hive从架构上（计算引擎是外部依赖，而不是内部开发）无法赶超的东西。
SparkSQL的应用场景？传统数据仓库我看SparkSQL可能不想大力发展了。Apache Spark是从U.C.Berkeley孵化出来的，和Hadoop、Hive等社区被几大巨头牵制不同，其社区也牢牢被U.C.Berkeley databricks把控。而databricks推出的产品显然是公有（企业）云性质的大数据统一处理平台（Databricks makes Spark easy through a cloud-based integrated workspace.）（不是广告），所以SQL层的很多特性，它们要么不需要（权限管理、多租户），要么不必对客户暴露（JDBC等），所以干脆在社区不care这部分的发展。走上云化的道路，这是时代背景决定的，也是databricks的利益决定的。
选择SparkSQL，要么企业自己定制成性能更好的Hive。要么也将其云化，跟着databricks的脚步走。
为什么要有Hive呢？因为有了Hadoop后，大家发现存储和计算都有了，但是用起来很困难。去厂商那里一看，清一色Oracle、DB2、TD啥啥的，客户被惯的只会用SQL来处理业务，难一点都交给乙方来做。
转头一想，劳资拿个项目，总不能搭一堆维护人员天天在局点给你们维护你们写的（也有可能是自己写的）超烂的MR代码吧？嗯，在MR上包一层，继续让你们用SQL，就好了嘛
Hive适合的是什么场景呢？数据仓库。基于Hadoop做一些数据清洗啊（ETL）、报表啊、数据分析啊什么的。
传统数据库的SQL03 SQL11标准、自定义函数、权限管理，支持！
JDBC、ODBC、REST接入，支持！
存储过程，支持！
分布式的scale out，支持！
事务处理、一致性、回滚，这个比较难，但是也努力支持！
基本上就是朝着替代传统数据库的方向去的，当然是在大数据背景下的替代。本质上来说，它还是一个面向读的、面向分析的SQL工具。
你问它有什么缺点？天天插入、更新、删除数据，还要求强一致性和毫秒级相应，这个不仅不是Hive的长处，当前的Hadoop框架就不适合这玩意儿。
好，回过头来再说Spark SQL。
SparkSQL是啥呢？这个首先要问Spark是啥。
Spark就是以RDD为核心的计算框架，它产生的背景就是MR难用！慢！
于是Spark搞了一个抽象概念RDD，把map过程都串起来，内存用起来，再做点流水线优化。嗯，快了10到100倍（官方宣称）！
RDD上面抽象一些高级操作，替代MR单纯的map和reduce，简化编程；加上Python、R、Java、Scala等等的接口，谁来用都能无缝切换。嗯，易用性大大增加！
那既然有了RDD这么牛逼的东西，总不能只让用户去写应用处理离线任务吧。流处理，上！机器学习，上！SQL，上！哈哈哈哈哈我一个Spark啥都能搞定，你们就不用费心去用别的东东了！
那SparkSQL对比Hive有啥缺点呢？
由于前者发展时间短，且大数据领域Hive、HBase等等都已经快形成了事实标准，所以SparkSQL一直在吹嘘自己的一栈式数据处理平台，试图从易用性上争取用户。但用户是不是真的需要这些呢？未必。从Spark发展的过程来看，SparkSQL的发展速度远远超过Core、Streaming、MLlib、GraphX等；从语言来看，对Scala的支持也远远超过了Java、R、Python的关注。这说明了一栈式处理虽然看起来很美，但用户未必有这样的场景。
单就SparkSQL来讲呢？由于已经有了Hive（而避免重复造差不多的轮子），所以像Metastore、权限、JDBC这些东东，SparkSQL要么直接复用Hive的，要么干脆不做。
那SparkSQL究竟重点在做什么呢？性能、稳定性、标准兼容性，这是社区2.0版本比较关注的东西，也是Hive从架构上（计算引擎是外部依赖，而不是内部开发）无法赶超的东西。
SparkSQL的应用场景？传统数据仓库我看SparkSQL可能不想大力发展了。Apache Spark是从U.C.Berkeley孵化出来的，和Hadoop、Hive等社区被几大巨头牵制不同，其社区也牢牢被U.C.Berkeley databricks把控。而databricks推出的产品显然是公有（企业）云性质的大数据统一处理平台（Databricks makes Spark easy through a cloud-based integrated workspace.）（不是广告），所以SQL层的很多特性，它们要么不需要（权限管理、多租户），要么不必对客户暴露（JDBC等），所以干脆在社区不care这部分的发展。走上云化的道路，这是时代背景决定的，也是databricks的利益决定的。
选择SparkSQL，要么企业自己定制成性能更好的Hive。要么也将其云化，跟着databricks的脚步走。