如何理解 SQL及Thrift

今天就跟大家聊聊有关如何理解 SQL及Thrift，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。

这是一个复杂的历史，基本上是一个“忒修斯船”(Ship of Theseus)的故事。最开始的时候，Spark SQL的代码几乎全部都是Hive的照搬，随着时间的推移，Hive的代码被逐渐替换，直到几乎没有原始的Hive代码保留。

参考：https://en.wikipedia.org/wiki/Ship_of_Theseus

Spark最开始打包的是Shark和SharkServer(Spark和Hive的结合体)。那个时候，这个结合体包含了大量的Hive代码。SharkServer就是Hive，它解析HiveQL，在Hive中进行优化，读取Hadoop的输入格式，到最后Shark甚至在Spark引擎上运行Hadoop风格的MapReduce任务。这一点在当时来说其实很酷的，因为它提供了一种无需进行任何编程就能使用Spark的方式，HQL做到了。不幸的是，MapReduce和Hive并不能完全融入Spark生态系统，2014年7月，社区宣布Shark的开发在Spark1.0的时终止，因为Spark开始转向更多Spark原生的SQL表达式。同时社区将重心转向原生的Spark SQL的开发，并且对已有的Hive用户提供过渡方案Hive on Spark来进行将Hive作业迁移到Spark引擎执行。

参考：https://github.com/amplab/shark/wiki/Shark-User-Guidehttps://databricks.com/blog/2014/07/01/shark-spark-sql-hive-on-spark-and-the-future-of-sql-on-spark.html

Spark引入SchemaRDDs，Dataframes和DataSets来表示分布式数据集。有了这些，一个名为Catalyst的全新Spark原生优化引擎引入到Spark，它是一个Tree Manipulation Framework，为从GraphFrames到Structured Streaming的所有查询优化提供依据。Catalyst的出现意味着开始丢弃MapReduce风格的作业执行，而是可以构建和运行Spark优化的执行计划。此外，Spark发布了一个新的API，它允许我们构建名为“DataSources”的Spark-Aware接口。DataSources的灵活性结束了Spark对Hadoop输入格式的依赖（尽管它们仍受支持）。DataSource可以直接访问Spark生成的查询计划，并执行谓词下推和其他优化。

Hive Parser开始被Spark Parser替代，Spark SQL仍然支持HQL，但语法已经大大扩展。Spark SQL现在可以运行所有TPC-DS查询，以及一系列Spark特定的扩展。（在开发过程中有一段时间你必须在HiveContext和SqlContext之间进行选择，两者都有不同的解析器，但我们不再讨论它了。今天所有请求都以SparkSession开头）。现在Spark几乎没有剩下Hive代码。虽然Sql Thrift Server仍然构建在HiveServer2代码上，但几乎所有的内部实现都是完全Spark原生的。

Thrift Server是Spark提供的一种JDBC/ODBC访问Spark SQL的服务，它是基于Hive1.2.1的HiveServer2实现的，只是底层的SQL执行改为了Spark，同时是使用spark submit启动的服务。同时通过Spark Thrift JDBC/ODBC接口也可以较为方便的直接访问同一个Hadoop集群中的Hive表，通过配置Thrift服务指向连接到Hive的metastore服务即可。

参考：http://spark.apache.org/docs/latest/sql-distributed-sql-engine.html#running-the-thrift-jdbcodbc-server

1.不支持用户模拟，即Thrift Server并不能以提交查询的用户取代启动Thrift Server的用户来执行查询语句，具体对应到Hive的hive.server2.enable.doAs参数不支持。参考：

https://issues.apache.org/jira/browse/SPARK-5159https://issues.apache.org/jira/browse/SPARK-11248https://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的缺陷，也可以参考网易的描述：

所以网易才自己做了一个Thrift服务取名Kyuubi，Fayson在后面的文章中会用到，参考：

http://blog.itpub.net/31077337/viewspace-2212906/

从CDH5.10到最新的CDH5.16.1，都支持同时安装Spark1.6以及最新的Spark2.x，Spark2具体包含从Spark2.0到最新的Spark2.4都可以安装到CDH5中。具体可以参考Cloudera官网的说明：

https://www.cloudera.com/documentation/spark2/latest/topics/spark2_requirements.html#cdh_versions

在CDH5中通过自己单独安装的方式运行Thrift服务现在已经调通并在使用的是如下版本组合：

1.在CDH5中安装Spark1.6的Thrift服务，参考《0079-如何在CDH中启用Spark Thrift》

2.在CDH5中安装Spark2.1的Thrift服务，参考《0280-如何在Kerberos环境下的CDH集群部署Spark2.1的Thrift及spark-sql客户端》

从Spark2.2开始到最新的Spark2.4，因为变化较大，不能够采用上述两种办法直接替换jar包的方式实现，更多的依赖问题导致需要重新编译或者修改更多的东西才能在CDH5中使用最新的Spark2.4的Thrift。

看完上述内容，你们对如何理解 SQL及Thrift有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注亿速云行业资讯频道，感谢大家的支持。