1.不支持用户模拟，即Thrift Server并不能以提交查询的用户取代启动Thrift Server的用户来执行查询语句，具体对应到Hive的hive.server2.enable.doAs参数不支持。参考：
https://issues.apache.org/jira/browse/SPARK-5159
https://issues.apache.org/jira/browse/SPARK-11248
https://issues.apache.org/jira/browse/SPARK-21918
2.因为上述第一点不支持用户模拟，导致任何查询都是同一个用户，所有没办法控制Spark SQL的权限。
3.单点问题，所有Spark SQL查询都走唯一一个Spark Thrift节点上的同一个Spark Driver，任何故障都会导致这个唯一的Spark Thrift节点上的所有作业失败，从而需要重启Spark Thrift Server。
4.并发差，上述第三点原因，因为所有的查询都要通过一个Spark Driver，导致这个Driver是瓶颈，于是限制了Spark SQL作业的并发度。
因为以上限制，主要是安全性上的（即上面描述的第一和第二点），所以CDH的企业版在打包Spark的时候将Spark Thrift服务并没有打包。如果用户要在CDH中使用Spark Thrift服务，则需要自己打包或单独添加这个服务，但Cloudera官方并不会提供支持服务。可以参考如下jira：
https://issues.cloudera.org/browse/DISTRO-817
关于Spark Thrift的缺陷，也可以参考网易的描述：
大家可能都知道，Hive一般有两种使用模式，一种是client模式，所有的SQL解析都客户端在这之中完成。一种是HiveSever2模式，整个SQL解析放到server端完成。
在公司实际使用过程中，我们更希望用户的使用行为通过Server端完成，否则会很难管理，因为客户端根本不在平台掌控范围之内，我们很难进行各种升级及配置变化。只有当MetaStore和HDFS 配置不暴露给用户，我们才能更好得管控。Hive的社区比较完善，在这方面没有问题，但是Spark还有些不足。其实，所谓的Kyuubi只是在类似HiveSever2的基础上提供服务， 提供SparkSQL服务，而不是Hive SQL服务。
Kyuubi基于Spark Thrift Sever改造，Spark Thrift Sever类似于HiveSever2，但是它不够完善。由于我们在此基础上增加了多租户的功能，因此可以支持网易内部各业务线的使用。
所以网易才自己做了一个Thrift服务取名Kyuubi
网友评论