spark优化
㈠ 为什么说Spark SQL远远超越了MPP SQL
这里说的并不是性能，因为我没尝试对比过（下文会有简单的说明），而是尝试从某种更高一层次的的角度去看，为什么Spark SQL 是远远超越MPP SQL的。
Spark SQL 和 MPP SQL 其实不在一个维度上。简而言之，
MPP SQL 是 Spark SQL 的一个子集
Spark SQL 成为了一种跨越领域的交互形态
MPP SQL 是 Spark SQL 的一个子集
MPP SQL 要解决的技术问题是海量数据的查询问题。这里根据实际场景，你还可以加上一些修饰词汇，譬如秒级，Ad-hoc 之类。
在实际业务中
探索类业务，比如KPI多维分析，用户画像查询，数据科学家摸底数据等
运营类业务，比如报表（现在很多BI系统基本上完全基于SQL来构建），各种运营临时统计需求
分析类业务，不过这个会比较浅显。显然，真实的的分析应该主要依托一些统计类，机器学习等技术的支持
运维类业务，比如实时查询查看海量的系统日志等
MPP SQL 是有一定的性能优势的，从HAWQ,Impala 等都是基于MPP架构的。然而仅限于此。这些功能Spark SQL 目前都已经涵盖了，MPP SQL能做的事情，Spark SQL都完成的很漂亮。
依托于Spark 自身的全平台性(漂亮的DataSource API以及各个厂商的努力适配),Spark SQL 基本上可以对接任意多个异构数据源进行分析和查询。大家可参考我的一个简略实现 利用StreamingPro实现SQL-交互式查询。
关于性能可以再多说两句：
得益于一些具有复杂存储格式的文件的诞生，譬如CarbonData, Spark SQL 已经实现海量数据的秒级查询
Spark 自身通过Tungsten等项目的优化(尤其是代码自动生成)，速度越来越生猛，而JVM譬如GC带来的问题则可以进一步通过off-heap的方式减少。
所以 Spark SQL 和 MPP SQL在性能上的差距也会越来越小。
Spark SQL 成为了一种跨越领域的交互形态
Spark 通过使用DS（2.0统一了DF 和 DS，使用一套SQL引擎）极大的增强了交互语意，意味着你可以用SQL（DS）作为统一的交互语言完成流式，批处理，交互式查询，机器学习等大数据领域常见场景。这在任何一个系统都是不多见的，也可见Spark团队的抽象能力。
引言中的那篇文章其实是作者吐槽Spark 团队对Spark core（RDD）那层关注太少了，所以开始发牢骚。
现在我们再回过头来看我们常见的一些业务：
实时分析类业务
探索类业务
分析预测类业务
运营报表类业务
首先这些业务都可以使用Spark 来实现。其次统一的交互接口都是DS(DF/SQL),并且DS/SQL 是一套极度易用并且广泛普及和接受的。
当然Spark 也不是一步就做到这点的，原来流式计算和批量计算就是两套API, DF 和 DS 也是两套API,后面经过发展，Databricks 团队也在积极思考和慢慢成长，经过先前已经有的积累，才做到现在的这一步。
所以本质上DS/SQL 已经成为除了RDD API 以外，另外一套通用的，统一的交互式API，涵盖了流式，批处理，交互式查询，机器学习等大数据领域。这也是我们第一次达成这样的统一，目前来看也仅在Spark平台上得以实现，它是的大数据的使用和学习门槛进一步降低，功在千秋。
RDD VS DS/SQL
DS/SQL 是一套数据类型首先，操作种类受限的表达语言，意味着Spark 团队可以做更好的性能优化，也意味着门槛更低，在易用性和性能上都能取得良好的平衡
㈡ SparkSQL对于重复的计算怎么优化
Sparksql是为了处理结构化数据的一个spark 模块。
不同于spark rdd的基本API，spark sql接口更多关于数据结构本身与执行计划等更多信息。
在spark内部，sql sql利用这些信息去更好地进行优化。
有如下几种方式执行spark sql：SQL，DataFramesAPI与Datasets API。当相同的计算引擎被用来执行一个计算时，有不同的API和语言种类可供选择。
这种统一性意味着开发人员可以来回轻松切换各种最熟悉的API来完成同一个计算工作。
㈢ 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，查找原因并改善；
㈣ spark性能优化主要有哪些手段
其目的是在优化网络覆盖的同时保证良好的接收质量，同时网络具备正确的邻区关系，从而保证下一步业务优化时无线信号的分布是正常的，为优化工作打下良好的基矗 RF优化的特点决定其普遍存在于网络优化流程的各个阶段..
㈤ spark driver会对任务进行优化吗
会的。
这么说吧：spark中的一个application是由多个stages组成，一个stage又有多个tasks组成。那么tasks执行先后可以组成一张有向无环图（也就是我们常说的DAG），这个DAG的组织就是在driver端做的。driver端会根据宽依赖，窄依赖划分stage，根据依赖关系，能并行处理的则尽量并行处理，这样生成的dag深度则没那么深，也就进行优化了。
当然，每个executor也会对任务做优化了，比如pipeline执行，包括钨丝计划中的offheap等，这个可能要你深入理解了。
㈥ spark最佳实践电子版 spark是什么版本
《Spark大数据处理技术》以Spark 0.9版本为基础进行编写，是一本全面介绍Spark及Spark生态圈相关技术的书籍，是国内首本深入介绍Spark原理和架构的技术书籍。主要内容有Spark基础功能介绍及内部重要模块分析，包括部署模式、调度框架、存储管理以及应用监控；同时也详细介绍了Spark生态圈中其他的软件和模块，包括SQL处理引擎Shark和Spark SQL、流式处理引擎Spark Streaming、图计算框架Graphx以及分布式内存文件系统Tachyon。《Spark大数据处理技术》从概念和原理上对Spark核心框架和生态圈做了详细的解读，并对Spark的应用现状和未来发展做了一定的介绍，旨在为大数据从业人员和Spark爱好者提供一个更深入学习的平台。
《Spark大数据处理技术》适合任何大数据、Spark领域的从业人员阅读，同时也为架构师、软件开发工程师和大数据爱好者展现了一个现代大数据框架的架构原理和实现细节。相信通过学《Spark大数据处理技术》，读者能够熟悉和掌握Spark这一当前流行的大数据框架，并将其投入到生产实践中去。
《Spark大数据处理：技术、应用与性能优化》根据最新技术版本，系统、全面、详细讲解Spark的各项功能使用、原理机制、技术细节、应用方法、性能优化，以及BDAS生态系统的相关技术。
通过上面两本熟悉Spark的原理架构以及应用，想深入学习的话，还有《Apache Spark源码剖析》，它全面、系统地介绍了Spark源码，深入浅出。
㈦ 如何优化spark-streaming读取kafka
spark streaming从1.2开始提供了数据的零丢失，想享受这个特性，需要满足如下条件： 1.数据输入需要可靠的sources和可靠的receivers 2.应用metadata必须通过应用driver checkpoint 3.WAL（write ahead log）
㈧ spark cg优化是什么意思i
gc优化，垃圾回收优化。