我正在开发一个Spark SQL应用程序，我几乎没有问题：
我读过Spark-SQL在封面下使用Hive Metastore？这是真的？我在谈论一个纯粹的Spark-SQL应用程序，它没有显式连接到任何Hive安装。
Spark SQL不会在封面下使用Hive Metastore（默认为in-memory非Hive目录，除非您在spark-shell中执行相反的操作）。
默认外部目录实现由spark.sql.catalogImplementation内部属性控制，可以是两个可能值之一：hive和in-memory。
使用SparkSession了解正在使用的目录。
scala> :type spark
org.apache.spark.sql.SparkSession
scala> spark.version
res0: String = 2.4.0
scala> :type spark.sharedState.externalCatalog
org.apache.spark.sql.catalyst.catalog.ExternalCatalogWithListener
scala> println(spark.sharedState.externalCatalog.unwrapped)
org.apache.spark.sql.hive.HiveExternalCatalog@49d5b651
请注意，我使用的spark-shell确实启动了一个Hive-aware SparkSession，所以我不得不用--conf spark.sql.catalogImplementation=in-memory启动它来关闭它。
我正在启动Spark-SQL应用程序，而不需要使用Hive。有没有理由使用Hive？据我所知，Spark-SQL比Hive快得多;所以，我认为没有任何理由使用Hive。
这是一个非常有趣的问题，可以有不同的答案（有些甚至主要是基于意见的，所以我们必须格外小心并遵循StackOverflow规则）。
有没有理由使用Hive？
没有。
但是......如果你想使用Spark 2.2的最新功能，即基于成本的优化器，你可能需要将其视为ANALYZE TABLE，因为成本统计可能相当昂贵，所以对于使用过的表来说这样做一次不同的Spark应用程序运行可以提高性能。
请注意，没有Hive的Spark SQL也可以这样做，但是有一些限制，因为本地默认的Metastore仅用于单用户访问，并且在同时提交的Spark应用程序之间重用元数据将不起作用。
我认为没有理由使用Hive。
我写了一篇博客文章Why is Spark SQL so obsessed with Hive?! (after just a single day with Hive)，在那里我问了一个类似的问题，令我惊讶的是它只是现在（我在2016年4月9日发布博客文章差不多一年后），我想我可能已经理解为什么Hive Metastore的概念是这样的重要的，特别是在多用户Spark笔记本环境中。
Hive本身只是HDFS上的一个数据仓库，所以如果你有Spark SQL就没什么用了，但是仍然有一些Hive做得相当好的概念在Spark SQL中有很多用处（直到它完全站在自己的腿上一个像蜂巢一样的环氧树脂。
如果在初始化HiveContext（）对象或spark-shell时没有找到，则它将连接到Hive Metastore或实例化一个。
使用Hive的主要原因是，如果您正在从Hive的托管表中读取HDFS数据，或者您希望从外部表中选择是否方便。
请记住，Hive只是用于读取和写入HDFS文件的镜头，而不仅仅是执行引擎本身。