1. spark sql支持哪些sql操作
支持Shark和sparkSQL 。
但是，随着Spark的发展，其中sparkSQL作为Spark生态的一员继续发展，而不再受限于hive，只是兼容hive；而hive on
spark是一个hive的发展计划，该计划将spark作为hive的底层引擎之一，也就是说，hive将不再受限于一个引擎，可以采用map-
rece、Tez、spark等引擎。
2. 如何使用Spark SQL 的JDBC server
Spark SQL主要的推动者是Databricks。提到Spark SQL不得不提的就是Shark。Shark可以理解为Spark社区这边搞的一个”Hive on Spark”，把Hive的物理执行计划使用Spark计算引擎去执行。这里面会有一些问题，Hive社区那边没有把物理执行计划到执行引擎这个步骤抽象出公共API，所以Spark社区这边要自己维护一个Hive的分支，而且Hive的设计和发展不太会考虑到如何优化Spark的Job。但是前面提到的Hive on Spark却是和Hive一起发布的，是由Hive社区控制的。所以后来Spark社区就停止了Shark的开发转向Spark SQL（“坑了”一部分当时信任Shark的人）。Spark SQL是把SQL解析成RDD的transformation和action，而且通过catalyst可以自由、灵活的选择最优执行方案。对数据库有深入研究的人就会知道，SQL执行计划的优化是一个非常重要的环节，Spark SQL在这方面的优势非常明显，提供了一个非常灵活、可扩展的架构。但是Spark SQL是基于内存的，元数据放在内存里面，不适合作为数据仓库的一部分来使用。所以有了Spark SQL的HiveContext，就是兼容Hive的Spark SQL。它支持HiveQL, Hive Metastore, Hive SerDes and Hive UDFs以及JDBC driver。这样看起来很完美，但是实际上也有一些缺点：Spark SQL依赖于Hive的一个snapshot，所以它总是比Hive的发布晚一个版本，很多Hive新的feature和bug fix它就无法包括。而且目前看Spark社区在Spark的thriftserver方面的投入不是很大，所以感觉它不是特别想朝着这个方向发展。还有一个重要的缺点就是Spark SQL目前还不能通过分析SQL来预测这个查询需要多少资源从而申请对应的资源，所以在共享集群上无法高效地分配资源和调度任务。
3. spark SQL和hive到底什么关系
Hive是一种基于HDFS的数据仓库，并且提供了基于SQL模型的，针对存储了大数据的数据仓库，进行分布式交互查询的查询引擎。
SparkSQL并不能完全替代Hive，它替代的是Hive的查询引擎，SparkSQL由于其底层基于Spark自身的基于内存的特点，因此速度是Hive查询引擎的数倍以上，Spark本身是不提供存储的，所以不可能替代Hive作为数据仓库的这个功能。
SparkSQL相较于Hive的另外一个优点，是支持大量不同的数据源，包括hive、json、parquet、jdbc等等。SparkSQL由于身处Spark技术堆栈内，基于RDD来工作，因此可以与Spark的其他组件无缝整合使用，配合起来实现许多复杂的功能。比如SparkSQL支持可以直接针对hdfs文件执行sql语句。
4. sparkSQL和spark有什么区别
Spark为结构化数据处理引入了一个称为Spark SQL的编程模块。简而言之，sparkSQL是Spark的前身，是在Hadoop发展过程中，为了给熟悉RDBMS但又不理解MapRece的技术人员提供快速上手的工具。
sparkSQL提供了一个称为DataFrame（数据框）的编程抽象，DF的底层仍然是RDD，并且可以充当分布式SQL查询引擎。
SparkSql有哪些特点呢？
1）引入了新的RDD类型SchemaRDD，可以像传统数据库定义表一样来定义SchemaRDD。
2）在应用程序中可以混合使用不同来源的数据，如可以将来自HiveQL的数据和来自SQL的数据进行Join操作。
3）内嵌了查询优化框架，在把SQL解析成逻辑执行计划之后，最后变成RDD的计算。
5. spark sql 交互式查询是什么意思
Shark和sparkSQL 但是，随着Spark的发展，其中sparkSQL作为Spark生态的一员继续发展，而不再受限于hive，只是兼容hive；而hive on spark是一个hive的发展计划，该计划将spark作为hive的底层引擎之一，也就是说，hive将不再受限于一个引擎，可以...
6. spark sql怎么划分stage
其实sql就是关系操作。关系操作跟map，rece这些基础算子对应起来的（spark其实基础算子也是map，rece，只是在此基础上做了扩展）。比如projection，filter是窄依赖，join，semi join，outer join是宽依赖。
具体流程会比较复杂。首先spark会解析这条sql，生成语法树（spark2.0会通过antlr4解析），然后经过逻辑优化（dataframe中有logic plan），然后转换为map rece，生成对应的操作算子（projection，filter，join等）。有了宽依赖，窄依赖，也就能划分stage了。
7. spark sql show tables显示istemporary，怎么关闭
1.配置hive-site.xml
在master1上的/usr/local/spark/spark-1.6.0-bin-hadoop2.6/conf目录创建hive-site.xml文件，内容如下：
Java代码
<configuration>
<property>
<name>hive.metastore.uris</name>
<value>thrift://master1:9083</value>
<description>Thrift URI for the remote metastore. Used by metastore client to connect to remote metastore.</description>
</property>
8. spark 跑spark sql时cpu利用率特别高怎么办
优化过程中常用到方法
查看查询的整个运行计划
scala>query.queryExecution
查看查询的Unresolved LogicalPlan
scala>query.queryExecution.logical
查看查询的Analyzed LogicalPlan
scala>query.queryExecution.analyzed
查看优化后的LogicalPlan
scala>query.queryExecution.optimizedPlan
查看物理计划
scala>query.queryExecution.sparkPlan
查看RDD的转换过程
scala>query.toDebugString
SparkSQL调优
Spark是一个快速的内存计算框架，同时是一个并行运算的框架，在计算性能调优的时候，除了要考虑广为人知的木桶原理外，还要考虑平行运算的Amdahl定理。
木桶原理又称短板理论，其核心思想是：一只木桶盛水的多少，并不取决于桶壁上最高的那块木块，而是取决于桶壁上最短的那块。将这个理论应用到系统性能优化上，系统的最终性能取决于系统中性能表现最差的组件。例如，即使系统拥有充足的内存资源和CPU资源，但是如果磁盘I/O性能低下，那么系统的总体性能是取决于当前最慢的磁盘I/O速度，而不是当前最优越的CPU或者内存。在这种情况下，如果需要进一步提升系统性能，优化内存或者CPU资源是毫无用处的。只有提高磁盘I/O性能才能对系统的整体性能进行优化。
SparkSQL作为Spark的一个组件，在调优的时候，也要充分考虑到上面的两个原理，既要考虑如何充分的利用硬件资源，又要考虑如何利用好分布式系统的并行计算。由于测试环境条件有限，本篇不能做出更详尽的实验数据来说明，只能在理论上加以说明。
2.1 并行性
SparkSQL在集群中运行，将一个查询任务分解成大量的Task分配给集群中的各个节点来运行。通常情况下，Task的数量是大于集群的并行度,shuffle的时候缺省的spark.sql.shuffle.partitionsw为200个partition，也就是200个Task：
而实验的集群环境却只能并行3个Task，也就是说同时只能有3个Task保持Running：
这时大家就应该明白了，要跑完这200个Task就要跑200/3=67批次。如何减少运行的批次呢？那就要尽量提高查询任务的并行度。查询任务的并行度由两方面决定：集群的处理能力和集群的有效处理能力。
l对于Spark Standalone集群来说，集群的处理能力是由conf/spark-env中的SPARK_WORKER_INSTANCES参数、SPARK_WORKER_CORES参数决定的；而SPARK_WORKER_INSTANCES*SPARK_WORKER_CORES不能超过物理机器的实际CPU core；
l集群的有效处理能力是指集群中空闲的集群资源，一般是指使用spark-submit或spark-shell时指定的--total-executor-cores，一般情况下，我们不需要指定，这时候，Spark Standalone集群会将所有空闲的core分配给查询，并且在Task轮询运行过程中，Standalone集群会将其他spark应用程序运行完后空闲出来的core也分配给正在运行中的查询。
综上所述，SparkSQL的查询并行度主要和集群的core数量相关，合理配置每个节点的core可以提高集群的并行度，提高查询的效率。
2.2 高效的数据格式
高效的数据格式，一方面是加快了数据的读入速度，另一方面可以减少内存的消耗。高效的数据格式包括多个方面：
2.2.1 数据本地性
分布式计算系统的精粹在于移动计算而非移动数据，但是在实际的计算过程中，总存在着移动数据的情况，除非是在集群的所有节点上都保存数据的副本。移动数据，将数据从一个节点移动到另一个节点进行计算，不但消耗了网络IO，也消耗了磁盘IO，降低了整个计算的效率。为了提高数据的本地性，除了优化算法（也就是修改spark内存，难度有点高），就是合理设置数据的副本。设置数据的副本，这需要通过配置参数并长期观察运行状态才能获取的一个经验值。
下面是Spark webUI监控Stage的一个图：
lPROCESS_LOCAL是指读取缓存在本地节点的数据
lNODE_LOCAL是指读取本地节点硬盘数据
lANY是指读取非本地节点数据
l通常读取数据PROCESS_LOCAL>NODE_LOCAL>ANY，尽量使数据以PROCESS_LOCAL或NODE_LOCAL方式读取。其中PROCESS_LOCAL还和cache有关。
2.2.2 合适的数据类型
对于要查询的数据，定义合适的数据类型也是非常有必要。对于一个tinyint可以使用的数据列，不需要为了方便定义成int类型，一个tinyint的数据占用了1个byte，而int占用了4个byte。也就是说，一旦将这数据进行缓存的话，内存的消耗将增加数倍。在SparkSQL里，定义合适的数据类型可以节省有限的内存资源。
2.2.3 合适的数据列
对于要查询的数据，在写SQL语句的时候，尽量写出要查询的列名，如Select a,b from tbl，而不是使用Select * from tbl；这样不但可以减少磁盘IO，也减少缓存时消耗的内存。
2.2.4 优的数据存储格式
在查询的时候，最终还是要读取存储在文件系统中的文件。采用更优的数据存储格式，将有利于数据的读取速度。查看SparkSQL的Stage，可以发现，很多时候，数据读取消耗占有很大的比重。对于sqlContext来说，支持 textFiile、SequenceFile、ParquetFile、jsonFile；对于hiveContext来说，支持AvroFile、ORCFile、Parquet File，以及各种压缩。根据自己的业务需求，测试并选择合适的数据存储格式将有利于提高SparkSQL的查询效率。
2.3 内存的使用
spark应用程序最纠结的地方就是内存的使用了，也是最能体现“细节是魔鬼”的地方。Spark的内存配置项有不少，其中比较重要的几个是：
lSPARK_WORKER_MEMORY，在conf/spark-env.sh中配置SPARK_WORKER_MEMORY 和SPARK_WORKER_INSTANCES，可以充分的利用节点的内存资源，SPARK_WORKER_INSTANCES*SPARK_WORKER_MEMORY不要超过节点本身具备的内存容量；
lexecutor-memory，在spark-shell或spark-submit提交spark应用程序时申请使用的内存数量；不要超过节点的SPARK_WORKER_MEMORY；
lspark.storage.memoryFraction spark应用程序在所申请的内存资源中可用于cache的比例
lspark.shuffle.memoryFraction spark应用程序在所申请的内存资源中可用于shuffle的比例
在实际使用上，对于后两个参数，可以根据常用查询的内存消耗情况做适当的变更。另外，在SparkSQL使用上，有几点建议：
l对于频繁使用的表或查询才进行缓存，对于只使用一次的表不需要缓存；
l对于join操作，优先缓存较小的表；
l要多注意Stage的监控，多思考如何才能更多的Task使用PROCESS_LOCAL；
l要多注意Storage的监控，多思考如何才能Fraction cached的比例更多
2.4 合适的Task
对于SparkSQL，还有一个比较重要的参数，就是shuffle时候的Task数量，通过spark.sql.shuffle.partitions来调节。调节的基础是spark集群的处理能力和要处理的数据量，spark的默认值是200。Task过多，会产生很多的任务启动开销，Task多少，每个Task的处理时间过长，容易straggle。
2.5 其他的一些建议
优化的方面的内容很多，但大部分都是细节性的内容，下面就简单地提提：
l 想要获取更好的表达式查询速度，可以将spark.sql.codegen设置为Ture；
l 对于大数据集的计算结果，不要使用collect() ,collect()就结果返回给driver，很容易撑爆driver的内存；一般直接输出到分布式文件系统中；
l 对于Worker倾斜，设置spark.speculation=true 将持续不给力的节点去掉；
l 对于数据倾斜，采用加入部分中间步骤，如聚合后cache，具体情况具体分析；
l 适当的使用序化方案以及压缩方案；
l 善于利用集群监控系统，将集群的运行状况维持在一个合理的、平稳的状态；
l 善于解决重点矛盾，多观察Stage中的Task，查看最耗时的Task，查找原因并改善；
9. sparksql 表定义 存储在哪
Spark SQL是支持在Spark中使用Sql、HiveSql、Scala中的关系型查询表达式。它的核心组件是一个新增的RDD类型SchemaRDD，它把行对象用一个Schema来描述行里面的所有列的数据类型，它就像是关系型数据库里面的一张表。它可以从原有的RDD创建，也可以是Parquet文件，最重要的是它可以支持用HiveQL从hive里面读取数据。
下面是一些案例，可以在Spark shell当中运行。
首先我们要创建一个熟悉的Context，熟悉spark的人都知道吧，有了Context我们才可以进行各种操作。