作者回复: 理解的没有问题~ 这块限制,随着Spark社区和Hive社区的发展,确实已经消除了,我后面会抽时间,改一下这里的原文描述,给兄弟们带来的困惑,表示抱歉哈~
作者回复: Beeline + Spark Thrift Server 这种方式,走的是Spark的计算引擎,所以set hive.exec.parallel=true这类Hive specific的参数,在这里其实是不起作用的。 不过在Hive on Spark的模式下,Hive相关的设置项都会起作用。其实本质上,还是要区分优化引擎和计算引擎。在Hive on Spark里面,Hive和Spark配置项都会起作用,Hive负责优化,Spark负责执行。而在Spark with Hive Metastore的集成模式下,Spark做优化,Spark做执行,这个时候,Hive的配置项就没什么用了哈~
作者回复: 是的,用户代码走的还是Spark with Hive metastore的路径,也就是仅仅把Hive当做元数据管理器,从Hive扩充数据源,或是把数据写到Hive中去~ 对于Hive on Spark来说,Spark只是后端的计算引擎,提交给Hive的SQL,会通过Hive本身的解析、优化,再交给Spark去执行而已
作者回复: 你说的是Hive on Spark吗?一般来说,Hive on Spark的性能,比Spark with Hive metastore或是Spark SQL本身,性能都要差一些,原因的话,老弟可以根据架构图来琢磨琢磨哈~
作者回复: Hive on Spark对于版本一致性要求比较高,这个是比较麻烦和比较坑的一点。上面的报错,是因为Hive和Spark版本不一致导致的,老弟可以参考这里,去根据两个组件版本的要求来配置Hive on Spark: https://cwiki.apache.org/confluence/display/Hive/Hive+on+Spark%3A+Getting+Started
作者回复: 对,理论上是这样的。不过,Hive社区不会这么做,为啥呢?因为Hive社区是从自身的设计出发,它还要顾及MapReduce和Tez,所以不会轻易动自身的优化引擎。不过讲道理,如果Hive实现了一套与Spark SQL一样的优化机制,那么Hive on Spark性能,就会像你说的,有所提升~
作者回复: 好问题~ 是这样的,spark-sql会在进程内启动自己的Metastore service,然后尝试去连接MySQL database(Metastore database),我可能原文没有交代清楚。老弟帮忙看下,看看hive-site.xml中,是否有Metastore database相关的配置项,推测是spark-sql自己的Metastore service通过hive-site.xml里面的database信息,直连的MySQL database。 老弟帮忙确认下哈~