也可以看我CSDN的博客：
https://blog.csdn.net/u013332124/article/details/90339850
一、Spark Thrift Server介绍
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的元数据。
二、部署Spark Thrift Server
先将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的架构
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如何执行SQL
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提交到集群运行是一样的。
五、和HiveServer2的区别
| 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 |
Spark Thrift Server的优点
1、在大部分场景下，性能要比Hive on spark好，而且好很多
2、SparkSQL的社区活跃度也很高，基本每月都会发布一个版本，因此性能还会不断提高
Spark Thrift Server的缺点
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最多搭建起来玩玩，或者自己内部做一些快速查询，并不适合真正放在企业级的使用上。
