spark

Spark性能调优之Shuffle调优 • Spark底层shuffle的传输方式是使用netty传输，netty在进行网络传输的过程会申请堆外 内存（netty是零拷贝），所以使用了 堆外内存 。 • shuffle过程中常出现的问题 常见问题一：reduce oom? 问题原因： reduce task 去map端获取数据，reduce一边拉取数据一边聚合，reduce端有一块聚合内存（executor memory * 0.2）,也就是这块内存不够 解决办法： 1.增加reduce 聚合操作的内存的比例 2.增加Executor memory的大小 --executor-memory 5G 3.减少reduce task每次拉取的数据量 设置 spak.reducer.maxSizeInFlight 24m, 拉取的次数就多了，因此建立连接的次数增多，有可能会连接不上（正好赶上map task端进行GC） 常见问题二：错误描述--shuffle file cannot find or executor lost • 什 么时候需要调节Executor的堆外内存大小？ • shuffle file cannot find （DAGScheduler，resubmitting task） • executor lost • task lost • out of memory

文章目录 一、spark 分区 partition的理解 二、coalesce 与 repartition的区别（我们下面说的coalesce都默认shuffle参数为false的情况） 三、实例 四、总结 一、spark 分区 partition的理解 spark中是以vcore级别调度task 如果读取的是hdfs，那么有多少个block，就有多少个partition 举例来说： sparksql 要读表T, 如果表T有1w个小文件，那么就有1w个partition 这时候读取效率会较低。假设设置资源为 --executor-memory 2g --executor-cores 2 --num-executors 5 。 步骤是： 拿出1-10号10个小文件（也就是10个partition） 分别给5个executor读取（spark调度会以vcore为单位，实际就是5个executor，10个task读10个partition） 如果5个executor执行速度相同，再拿11-20号文件 依次给这5个executor读取 而实际执行速度不会完全相同，那就是哪个task先执行完，哪个task领取下一个partition读取执行，以此类推。这样往往读取文件的调度时间大于读取文件本身，而且会频繁打开关闭文件句柄，浪费较为宝贵的io资源，执行效率也大大降低。 二、coalesce 与

目录 【坑1：persist() + show()不能缓存全部数据】 【坑2：unpersist()一个rdd时会同时unpersist()子RDD】 【坑1：persist() + show()不能缓存全部数据】 对于一个有100个分区的数据，假如你对其persist()后进行show(10)，那么spark只会把第一个分区缓存起来，show前10条数据。如果你show的数据量超过了一个分区的大小，那么spark会多缓存一些分区。 因此persist()后如果希望数据全部都缓存到内存中，应对每个分区都执行action操作，如进行count()。 例子： package high_quality._history import org.apache.log4j.{Level, Logger} import org.apache.spark.sql.SparkSession object demo { def main(args: Array[String]) { Logger.getRootLogger.setLevel(Level.ERROR) val spark = SparkSession.builder().getOrCreate() import spark.implicits._ val df = spark.sparkContext.parallelize(1 to

原文链接：https://mp.weixin.qq.com/s/RT7QNQNQ0NRsAmwUMtw6ig 编者荐语： Spark社区从2.3版本开始，已经可以很好的支持跑着Kubernetes上了。这对于统一资源池，提高整体资源利用率，降低运维成本（特别是技术栈归一）有着非常大的帮助。这些趋势是一个大数据人不得不重视的信号，所以一起提前了解并考虑起来吧！ 以下文章来源于容器魔方 ，作者tsjsdbd 大数据邂逅云计算 相信玩Spark的你已经注意到最新的Spark版本已经支持不做任何修改就可以直接跑在K8s上了，即以Kubernetes容器集群作为Cluster Manager的实现。 其实早在2017年底Spark 2.2版本开始的时候，Spark社区就开始合入用K8s管理Spark集群的能力，只是那时候功能上还没有很完善。加之彼时Kubernetes还没有像现在这么普及，被广泛地接受成为应用基础设施层。经过了2年了持续迭代，Spark on Kubernetes已经成为帅气的小伙，大家可以围观起来了。 其实，大数据和云计算一直分属两个不同的领域。大数据主要关注怎么将数据集中起来，挖掘数据的价值；云计算主要关注怎么更高效地使用资源，提升资源的利用效率。当大数据发展到一定阶段的时候，它就会和云计算不期而遇。 现状并不美丽 在技术层面上

“无意中发现了一个巨牛的人工智能教程，忍不住分享一下给大家。教程不仅是零基础，通俗易懂，而且非常风趣幽默，像看小说一样！觉得太牛了，所以分享给大家。点 这里 可以跳转到教程。”。 大数据面试宝典目录,请点击 目录 一、需求 二、样例数据 三、实现方式一 四、实现方式二 自定义分区取 重写排序规则 排序 五、实现方式三 在shuffle是在每一个分区中实现排序 另一种方式实现，使用ShuffleRDD 一、需求 通过分析用户浏览新闻热门话题的日志，统计每个话题下被浏览量最多的用户topN，即按照话题分组，在每一个组内进行排序 二、样例数据 数据格式：话题,时间,被浏览的用户id #高以翔去世# , 2019 - 11 - 29 , u011 #高以翔去世# , 2019 - 11 - 29 , u011 #高以翔去世# , 2019 - 11 - 29 , u011 #高以翔去世# , 2019 - 11 - 29 , u011 #高以翔去世# , 2019 - 11 - 29 , u011 #高以翔去世# , 2019 - 11 - 29 , u008 #高以翔去世# , 2019 - 11 - 29 , u008 #高以翔去世# , 2019 - 11 - 29 , u008 #高以翔去世# , 2019 - 11 - 29 , u008 #高以翔去世# , 2019 - 11

Spark RPC是spark个模块之间通信的基础,之前采用的事akka模型,在1.6之后基于netty编写了类似于akka的通信框架. spark RPC涉及到的类图如下 RpcEnv是RPC模块中的主要的抽象类，其中定义了RPC调用涉及的主要对象和方法。RpcEnv负责注册维护RpcEndpoint和RpcEndpointRef RpcEndPoint：负责消息处理的类,根据收到的消息来决定调用哪个函数，主要包含receive和receiveAndReply两个方法 RpcEndpintRef：远程RpcEndpoint对应的引用，想对应的RpcEndpoint发送消息 RpcAddress：维护RPC环境的地址和端口号 RpcCallContext:在RpcEndpoint中使用，RpcEndpoint处理完信息后，调用RpcCallContext返回信息或者错误 LocalNetty RpcCallContext：当sender和receiver在同一进程中使用 RemoteNetty RpcCallContext：当sender和receiver不在同一进程中 来源： https://www.cnblogs.com/chengwuyouxin/p/9544167.html

https://blog.csdn.net/uq_jin/article/details/51513307 https://www.cnblogs.com/zengxiaoliang/p/6478859.html https://www.cnblogs.com/liugh/p/6624923.html 安装spark a.下载：http://spark.apache.org/downloads.html b.安装spark 上传文件：把下载下来的spark-2.2.3-bin-hadoop2.7.tgz上传到/home/hadoop目录下 cd /home/hadoop sudo tar -zxvf spark-2.2.3-bin-hadoop2.7.tgz -C /app/ cd /app/spark-2.2.3-bin-hadoop2.7/ sudo chown -R hadoop:hadoop . # 此处的 hadoop为用户名 c. 配置环境变量 sudo vim /etc/profile SPARK_HOME=/app/spark-2.2.3-bin-hadoop2.7 export PATH=$PATH:$SPARK_HOME/bin source /etc/profile echo $PATH /app/jdk1.8.0_121/bin:/app/jdk1.8.0

１＞到官网上下载Spark源代码 ２＞进入到该目录下 ３>修改该目录下的pom.xml，新增如下代码 <repository> <id>cloudera</id> <name>cloudera Repository</name> <url>https://repository.cloudera.com/artifactory/cloudera-repos</url> </repository> ４＞编译代码 ./dev/make-distribution.sh --name 2.6.0-cdh5.16.2 --tgz -Phadoop-2.6 -Dhadoop.version=2.6.0-cdh5.16.2 -Phive -Phive-thriftserver -Pmesos -Pyarn -Pkubernetes ５＞等待一段时间，第一次编译速度较慢，会在网上下载所需资源 ６>解压即可 来源： CSDN 作者： 应龙与巨蜥 链接： https://blog.csdn.net/weixin_42209440/article/details/104060684

　 转载请注明出处： http://www.cnblogs.com/xiaodf/ 　　之前的博客介绍了通过Kerberos + Sentry的方式实现了hive server2的身份认证和权限管理功能，本文主要介绍Spark SQL JDBC方式操作Hive库时的身份认证和权限管理实现。 　ThriftServer是一个JDBC/ODBC接口，用户可以通过JDBC/ODBC连接ThriftServer来访问SparkSQL的数据。ThriftServer在启动的时候，会启动了一个sparkSQL的应用程序，而通过JDBC/ODBC连接进来的客户端共同分享这个sparkSQL应用程序的资源，也就是说不同的用户之间可以共享数据；ThriftServer启动时还开启一个侦听器，等待JDBC客户端的连接和提交查询。所以，在配置ThriftServer的时候，至少要配置ThriftServer的主机名和端口，如果要使用hive数据的话，还要提供hive metastore的uris。 前提： 　　本文是在以下几个部署前提下进行的实验： 　　（1）CDH 开启了Kerberos身份认证，并安装了Sentry； 　　（2）Hive权限通过Sentry服务控制； 　　（3）HDFS开启了HDFS ACL与Sentry的权限同步功能，通过sql语句更改Hive表的权限，会同步到相应的HDFS文件。

Spark是一种分布式计算框架，对标Hadoop的MapReduce；MapReduce适用于离线批处理（处理延迟在分钟级）而Spark既可以做离线批处理，也可以做实时处理（SparkStreaming） 　　①Spark集批处理、实时流处理、交互式查询、机器学习与图计算一体 　　②Spark实现了一种分布式的内存抽象，称为弹性分布式数据集；RDD允许用户在执行多个查询时显式地将工作集缓存在内存中，后续的查询能够重用工作集，极大提升了查询速度。 一个Hadoop的Job通常经过以下几个步骤： 　　①从HDFS中读取输入数据 　　②在Map阶段使用用户定义的mapper function，然后将结果spill到磁盘 　　③在Reduce阶段从各个处于Map阶段的机器读取Map计算的中间结果，使用用户自定义的reduce function，通常最后把结果写回HDFS 　　Hadoop的问题在于，一个Hadoop Job会进行多次磁盘读写，比如写入机器本地磁盘，或是写入分布式文件系统中（这个过程包含磁盘的读写以及网络传输）。考虑到磁盘读取比内存读取慢了几个数量级，所以像Hadoop这样高度依赖磁盘读写的架构就一定会有性能瓶颈；而且有些场景比如一些迭代性质的算法（逻辑回归）会重复利用某些Job的结果，导致触发重新计算带来大量的磁盘I/O。 Spark没有像Hadoop那样使用磁盘读写