Spark Thrift Server是Spark社区基于HiveServer2实现的一个Thrift服务。旨在无缝兼容HiveServer2。
因为Spark Thrift Server的接口和协议都和HiveServer2完全一致,因此我们部署好Spark Thrift Server后,可以直接使用hive的beeline访问Spark Thrift Server执行相关语句。
Spark Thrift Server的目的也只是取代HiveServer2,因此它依旧可以和Hive Metastore进行交互,获取到hive的元数据。
先将hive-site.xml、hdfs-site.xml、core-site.xml拷贝到spark/conf目录下。
如果运行的Hive MetaStore版本不是1.2,需要将hive-site.xml中的hive.metastore.schema.verification参数设置为false。否则会因为版本不一致报错
之后还需要拷贝相关jar包到spark/jars目录,否则会报Could not load shims in class org.apache.hadoop.hive.schshim.FairSchedulerShim错误。
cp hive/lib/hive-shims* spark/jars
cp hadoop/share/hadoop/yarn/hadoop-yarn-server-resourcemanager-2.7.4.jar spark/jars
之后启动Thrift Server
# ThriftServer的本质是将Server服务以spark job的形式提交到集群运行,所以需要指定队列
sbin/start-thriftserver.sh --hiveconf spark.yarn.queue=root.bigdata.date
Spark Thrift Server大量复用了HiveServer2的代码。
HiveServer2的架构主要是通过ThriftCLIService监听端口,然后获取请求后委托给CLIService处理。CLIService又一层层的委托,最终交给OperationManager处理。OperationManager会根据请求的类型创建一个Operation的具体实现处理。比如Hive中执行sql的Operation实现是SQLOperation。
Spark Thrift Server做的事情就是实现自己的CLIService——SparkSQLCLIService,接着也实现了SparkSQLSessionManager以及SparkSQLOperationManager。另外还实现了一个处理sql的Operation——SparkExecuteStatementOperation。这样,当Spark Thrift Server启动后,对于sql的执行就会最终交给SparkExecuteStatementOperation了。
Spark Thrift Server其实就重写了处理sql的逻辑,其他的请求处理就完全复用HiveServer2的代码了。比如建表、删除表、建view等操作,全部使用的是Hive的代码。
Spark Thrift Server的启动其实是通过spark-submit将HiveThriftServer2提交给集群执行的。因此执行start-thriftserver.sh时可以传入spark-submit的参数表示提交HiveThriftServer2时的参数。另外,因为HiveThriftServer2必须要在本地运行,所以提交时的deployMode必须是client,如果设置成cluster会报错。HiveThriftServer2运行起来后,就等于是一个Driver了,这个Driver会监听某个端口,等待请求。
**所以HiveThriftServer2程序运行起来后就等于是一个长期在集群上运行的spark application。**通过yarn或者spark history server页面我们都可以看到对应的任务。
既然HiveThriftServer2就是Driver,那么运行SQL就很简单了。Spark Thrift Server收到请求后最终是交给SparkExecuteStatementOperation处理,SparkExecuteStatementOperation拿到SQLContext,然后调用SQLContext.sql()方法直接执行用户传过来的sql即可。后面的过程就和我们直接写了一个Main函数然后通过spark-submit提交到集群运行是一样的。
Hive on Spark | Spark Thrift Server | |
---|---|---|
任务提交模式 | 每个session都会创建一个RemoteDriver,也就是对于一个Application。之后将sql解析成执行的物理计划序列化后发到RemoteDriver执行 | 本身的Server服务就是一个Driver,直接接收sql执行。也就是所有的session都共享一个Application |
性能 | 性能一般 | 如果存储格式是orc或者parquet,性能会比hive高几倍,某些语句甚至会高几十倍。其他格式的话,性能相差不是很大,有时hive性能会更好 |
并发 | 如果任务执行不是异步的,就是在thrift的worker线程中执行,受worker线程数量的限制。异步的话则放到线程池执行,并发度受异步线程池大小限制。 | 处理任务的模式和Hive一样。 |
sql兼容 | 主要支持ANSI SQL 2003,但并不完全遵守,只是大部分支持。并扩展了很多自己的语法 | Spark SQL也有自己的实现标准,因此和hive不会完全兼容。具体哪些语句会不兼容需要测试才能知道 |
HA | 可以通过zk实现HA | 没有内置的HA实现,不过spark社区提了一个issue并带上了patch,可以拿来用:https://issues.apache.org/jira/browse/SPARK-11100 |
1、在大部分场景下,性能要比Hive on spark好,而且好很多
2、SparkSQL的社区活跃度也很高,基本每月都会发布一个版本,因此性能还会不断提高
1、因为HiveThriftServer2是以Driver的形式运行在集群的。因此它能使用的集群资源就和单个Application直接挂钩。如果spark集群没开启动态资源,那么Spark Thrift Server能得到的资源就始终都是固定的,这时候设置太大也不好,设置太小也不好。即使开启了动态资源,一般集群都会设置maxExecutor,这时还是无法很好的利用集群的所有资源。如果将集群所有的资源都分配给了这个Application,这样像yarn、mesos这些资源调度器就完全没有存在的意义了…因此,单就这一点,Spark Thrift Server就不是一个合格的企业级解决方案。
2、从https://issues.apache.org/jira/browse/SPARK-11100 官方的回答来看,spark官方对于Spark Thrift Server这套解决方案也不是很满意。这也可以理解,毕竟Spark Thrift Server只是对HiveServer2进行的一些小改造。
3、Spark Thrift Server目前还是基于Hive的1.2版本做的改造,因此如果MetaStore的版本不是1.2,那么也可能会有一些兼容性的潜在问题。
Spark Thrift Server说白了就是小小的改动了下HiveServer2,代码量也不多。虽然接口和HiveServer2完全一致,但是它以单个Application在集群运行的方式还是比较奇葩的。可能官方也是为了实现简单而没有再去做更多的优化。
所以Spark Thrift Server最多搭建起来玩玩,或者自己内部做一些快速查询,并不适合真正放在企业级的使用上。