本文翻译自 Lightbend 的一篇文章,文章日期还比较新,2019/02/26。文章分为两部分,翻译也将分为两个部分。附上文章链接如下:
在集群中进行Hive-On-Spark查询失败,并在HiveServer2日志中显示如下错误:
在一个CDSW环境中,由于其中一个租户经常提交大型Spark作业将YARN上租户所在的资源池资源用到95%以上,从而影响到同一租户下其他用户提交作业的运行。这种情况下我们没办法直接找到这些大型作业的实际提交人,是因为我们在为CDSW做多租户配置的时候会将登录CDSW的某一批用户统一绑定到同一个租户下(这样设计的目的主要是为了简化YARN的租户管理,而不用为每个用户创建资源池队列),所以导致在YARN的界面上看到的都是同一个租户,而无法对应到实际CDSW的用户以及这个人提交的大型作业。本文主要描述通过修改Spark的配置来将作业的实际提交人的用户名展示到Spark UI,非CDSW的YARN的多租户管理也会碰到类似问题。
最近在做spark的项目,虽然项目基本功能都实现了,但是在真正的成产环境中去运行,发现程序运行效率异常缓慢;迫于无奈(实际是自己都不忍直视了),所以决定对程序做一番优化操作。在网上查看了不上关于spark程序的优化方法,但是都比较分散不够全面,所以决定就自己编写的基于Java的spark程序,记录一下我所做过的一些优化操作,加深印象方面以后的项目调优使用。这是一个Spark系列的优化操作,包括了很多方面,欢迎大家一块讨论学习。好了,废话好像有点多,下面开始进入正题:
首先,熟悉spark开发的 人都知道spark的部署模式分为三种,分别为Local、Standalone、YARN,通过YARN又分为YARN-Client和YARN-Cluster,Local模式 一般就是在本地运 行Spark任务,需要Spark环境的,Standalone模式是Spark 自 身的 一种调度模式,也是需要Spark环境,YARN模式中,其实是将Spark JAR包提交到YARN上 面,由YARN去开启Contioner然后去执 行Spark的作业,这个其实只需要上传Spark Jar包和 一些依赖包。不需要在部署Spark环境(充当 一个Submit的功能,还占 用节点资源)
需要注意的是:在集群环境下,application-jar 必须能被集群中所有节点都能访问,可以是 HDFS 上的路径;也可以是本地文件系统路径,如果是本地文件系统路径,则要求集群中每一个机器节点上的相同路径都存在该 Jar 包。
本文将 Spark 作业称为 Spark Application 或者简称为 Spark App 或者 App。目前我们组的计算平台的 Spark 作业,是通过 Spark Operator 提交给 Kubernetes 集群的,这与 Spark 原生的直接通过 spark-submit 提交 Spark App 的方式不同,所以理解 Spark Operator 中提交 Spark App 的逻辑,对于用户来说是非常有必要的。本文将就其具体的提交逻辑,介绍一下。
前面提到,spark向yarn提交作业的client类是org.apache.spark.deploy.yarn.YarnClusterApplication
最近在研究Spark源码,顺便记录一下,供大家学习参考,如有错误,请批评指正。好,废话不多说,这一篇先来讲讲Spark作业提交流程的整体架构。
前面Fayson介绍了多种方式在CDH集群外的节点向集群提交Spark作业,文章中均采用Spark1来做为示例,本篇文章主要介绍如何是用Oozie API向Kerberos环境的CDH集群提交Spark2作业。
在前面的文章《如何在集群外节点跨网段向HDFS写数据》和《外部客户端跨网段访问Hadoop集群方式(续)》中介绍了如何在集群外的客户端节点上访问Hadoop集群,本篇文章在前面文章的基础上基于Kerberos环境的CDH集群介绍,如何在集群外客户端跨网段向Kerberos环境的Hadoop集群提交MapReduce和Spark作业。
以前的Spark部署都是使用的standalone方式,集群中的每台机器都安装部署Spark,然后启动Master和Worker进程运行Spark。今天尝试一下Spark on YARN的部署方式。 一、实验目的 1. 只在一台机器上安装Spark,基于已有的Hadoop集群,使用YARN调度资源。 2. 不启动Master和Worker进程提交Spark作业。 3. 通过YARN的WebUI查看Spark作业的执行情况。 二、实验环境: 4台CentOS release 6.4虚拟机,IP地址为 192.168.56.101 192.168.56.102 192.168.56.103 192.168.56.104 192.168.56.101是Hadoop集群的主,运行NameNode和ResourceManager进程。 192.168.56.102、192.168.56.103是Hadoop的从,运行DataNode和NodeManager进程。 192.168.56.104安装Pentaho的PDI,安装目录为/home/grid/data-integration。 Hadoop版本:2.7.2 Spark版本:1.5.0 PDI版本:6.0 Hadoop集群的安装配置参考 http://blog.csdn.net/wzy0623/article/details/50681554 三、安装Spark 只在192.168.56.101一台机器上上安装Spark,具体安装步骤参考 http://blog.csdn.net/wzy0623/article/details/50946766 四、配置步骤 1. 启动Hadoop集群 # 启动hdfs /home/grid/hadoop-2.7.2/sbin/start-dfs.sh # 启动yarn /home/grid/hadoop-2.7.2/sbin/start-yarn.sh 2. 将spark自带的与Hadoop集成的jar包上传到hdfs hadoop fs -put /home/grid/spark/lib/spark-assembly-1.5.0-hadoop2.6.0.jar /user/ 3. 编辑spark-defaults.conf文件,添加如下一行 spark.yarn.jar=hdfs://master:9000/user/spark-assembly-1.5.0-hadoop2.6.0.jar 修改后的spark-defaults.conf文件如图1所示
继上一章介绍如何使用R连接Hive与Impala后,Fayson接下来讲讲如何在CDH集群中提交R的Spark作业,Spark自带了R语言的支持,在此就不做介绍,本文章主要讲述如何使用Rstudio提供的sparklyr包,向CDH集群的Yarn提交R的Spark作业。
在使用PySpark进行开发时,由于不同的用户使用的Python环境不同,有基于Python2的开发也有基于Python3的开发,这个时候会开发的PySpark作业不能同时兼容Python2和Python3环境从而导致作业运行失败。那Fayson接下来介绍如何在提交PySpark作业时如何指定Python的环境。
不管使用哪种模式,Spark应用程序的代码是一模一样的,只需要在提交的时候通过--master参数来指定我们的运行模式即可
Spark是专为大规模数据处理而设计的快速通用的计算引擎,具有速度快、支持多语言、移植性高的特点。而移植性高的体现就在于Spark的部署方式有多种模式,如:本地local、Standalone、Apache Mesos、Hadoop YARN、EC2、Mesos、K8S等等。
上一篇介绍了spark作业提交的三种方式,从本篇开始逐一介绍Spark作业运行流程中各个组件的内部工作原理。如标题所说,我们先来看看SparkContext在Spark作业提交后做了哪些事情,工作流程如下图所示;(注意:本篇文章及后续源码分析所有内容全部基于spark1.3.0源码进行分析,后续不再赘述)
通过上面图可以很清楚的看到从Job的action到中间调度在到最后的具体执行的过程,下面针对该图做一个实例,来更加清楚的理解。
本文将通过一个简单,并且具有典型代表的例子,描述如何使用EMR产品中的Hue组件创建工作流,并使该工作流每天定时执行。
就是一个大数据解决方案。它提供了一套分布式系统基础架构。 核心内容包含 hdfs 和 mapreduce。hadoop2.0 以后引入 yarn. hdfs 是提供数据存储的,mapreduce 是方便数据计算的。
本文介绍了Spark2.x的集群部署方案,包括本地模式、独立模式、Spark on YARN/Mesos模式。其中,本地模式适用于小规模的开发环境,独立模式适用于独立部署的集群环境,Spark on YARN/Mesos模式则适用于大规模集群环境。
以 Flink 和 Spark 为代表的分布式流批计算框架的下层资源管理平台逐渐从 Hadoop 生态的 YARN 转向 Kubernetes 生态的 k8s 原生 scheduler 以及周边资源调度器,比如 Volcano 和 Yunikorn 等。这篇文章简单比较一下两种计算框架在 Native Kubernetes 的支持和实现上的异同,以及对于应用到生产环境我们还需要做些什么。
在开发完Spark作业之后,就该为作业配置合适的资源了。 Spark的资源参数,基本都可以在spark-submit命令中作为参数设置。
在大数据领域,只有深挖数据科学领域,走在学术前沿,才能在底层算法和模型方面走在前面,从而占据领先地位。
再JVM虚拟机中,当创建的对象的数量很多时,Eden 和 Survior1 区域会很快的满溢,就需要进行频繁地 Minor GC,这样会导致有一些生命周期较短的对象迅速长到15岁并放入到老年代中,导致老年代中存放大量的短生命周期的对象(正常请况下,老年代应该存放的是数量比较少并且会长期使用的对象,比如数据库连接池),当老年代满溢后,会进行Full GC,Full GC是开启一个很消耗性能和时间的线程,而且不管 Minor GC 还是 Full GC 都会导致 JVM 的工作线程停止,因为 Scala 也是基于 JVM 的编程语言,所以运行 Spark 程序和运行 Java 程序在 JVM 中的内存分配情况是相同的。
本文对Spark总体架构进行描述,本文读者需要一定的Spark的基础知识,至少了解Spark的RDD和DAG。
1)原理: 计算能力调度器支持多个队列,每个队列可配置一定的资源量,每个队列采用 FIFO 调度策略,为了防止同一个用户的作业独占队列中的资源,该调度器会对 同一用户提交的作业所占资源量进行限定。调度时,首先按以下策略选择一个合适队列:计算每个队列中正在运行的任务数与其应该分得的计算资源之间的 比值(即比较空闲的队列),选择一个该比值最小的队列;然后按以下策略选择该队列中一个作业:按照作业优先级和提交时间顺序选择, 同时考虑用户资源量限制和内存限制 2)优点: (1)计算能力保证。支持多个队列,某个作业可被提交到某一个队列中。每个队列会配置一定比例的计算资源,且所有提交到队列中的作业 共享该队列中的资源; (2)灵活性。空闲资源会被分配给那些未达到资源使用上限的队列,当某个未达到资源的队列需要资源时,一旦出现空闲资源资源,便会分配给他们; (3)支持优先级。队列支持作业优先级调度(默认是FIFO); (4)多重租赁。综合考虑多种约束防止单个作业、用户或者队列独占队列或者集群中的资源; (5)基于资源的调度。支持资源密集型作业,允许作业使用的资源量高于默认值,进而可容纳不同资源需求的作业。不过,当前仅支持内存资源的调度。
在CDH集群外的节点向集群提交Spark作业的方式有多种,前面Fayson介绍了Livy相关的文章主要描述如何在集群外节点通过RESTful API接口向CDH集群提交Spark作业以及《如何使用Oozie API接口向非Kerberos环境的CDH集群提交Spark作业》,本篇文章主要介绍使用Oozie的API接口向Kerberos集群提交Spark作业。
Spark是一种通用的集群计算系统。它可以在从单个节点到数千个分布式节点的集群上部署和运行并行应用程序。Spark最初设计用于运行Scala应用程序,但也支持Java,Python和R.
前言 本章将对Spark做一个简单的介绍,更多教程请参考:Spark教程 本章知识点概括 Apache Spark简介 Spark的四种运行模式 Spark基于Standlone的运行流程 Spark基于YARN的运行流程 Apache Spark是什么? Spark是一个用来实现快速而通用的集群计算的平台。扩展了广泛使用的MapReduce计算模型,而且高效地支持更多的计算模式,包括交互式查询和流处理。在处理大规模数据集的时候,速度是非常重要的。Spark的一个重要特点就是能够在内存中计算,因而更
在CDH集群中提交Spark作业,大家也都知道Spark的Driver和Executor之间通讯端口是随机的,Spark会随选择1024和65535(含)之间的端口,因此在集群之间不建议启用防火墙。本篇文章Fayson主要介绍如何指定Spark2作业中Driver和Executor使用指定范围内的端口进行通讯。
由于Spark程序是运行在JVM基础之上的,所以我们这一篇来讨论一下关于JVM的一些优化操作。在开始JVM调优操作之前,我们先通过一张图看一下JVM简单的内存划分情况。
在CDH集群中提交Spark作业,大家也都知道Spark的Driver和Executor之间通讯端口是随机的,Spark会随选择1024和65535(含)之间的端口,因此在集群之间不建议启用防火墙。在前面Fayson介绍了《如何指定Spark2作业中Driver和Executor使用指定范围内端口》,本篇文章Fayson主要介绍如何指定Spark1作业中Driver和Executor使用指定范围内的端口进行通讯。
在CDH集群外的节点向集群提交Spark作业的方式有多种,前面Fayson介绍了Livy相关的文章主要描述如何在集群外节点通过RESTful API接口向CDH集群提交Spark作业,本篇文章我们借助于oozie-client的API接口向非Kerberos集群提交Spark作业。
Apache Spark提供的两种基于命令行的处理交互方式虽然足够灵活,但在企业应用中面临诸如部署、安全等问题。为此本文引入Livy这样一个基于Apache Spark的REST服务,它不仅以REST的方式代替了Spark传统的处理交互方式,同时也提供企业应用中不可忽视的多用户,安全,以及容错的支持。 背景 Apache Spark作为当前最为流行的开源大数据计算框架,广泛应用于数据处理和分析应用,它提供了两种方式来处理数据:一是交互式处理,比如用户使用spark-shell或是pyspark脚本启动Sp
spark-submit脚本通常位于/usr/local/spark/bin目录下,可以用which spark-submit来查看它所在的位置,spark-submit用来启动集群中的应用,它使用统一的提交接口支持各种类型的集群服务器。为了将应用发布到集群中,通常会将应用打成.jar包,在运行spark-submit时将jar包当做参数提交。
一. Spark基础知识 1.Spark是什么? UCBerkeley AMPlab所开源的类HadoopMapReduce的通用的并行计算框架 dfsSpark基于mapreduce算法实现的分布
在前面的文章Fayson介绍了《Livy,基于Apache Spark的开源REST服务,加入Cloudera Labs》和《如何编译Livy并在非Kerberos环境的CDH集群中安装》,Livy提供了两种类型的API(编程API和RESTful API接口),本篇文章主要介绍如何使用java代码调用Livy提供的RESTful API接口向非Kerberos环境的CDH集群提交Spark作业操作。
在开发完Spark作业之后,就该为作业配置合适的资源了。Spark的资源参数,基本都可以在spark-submit命令中作为参数设置。很多Spark初学者,通常不知道该设置哪些必要的参数,以及如何设置这些参数,最后就只能胡乱设置,甚至压根儿不设置。资源参数设置的不合理,可能会导致没有充分利用集群资源,作业运行会极其缓慢;或者设置的资源过大,队列没有足够的资源来提供,进而导致各种异常。总之,无论是哪种情况,都会导致Spark作业的运行效率低下,甚至根本无法运行。因此我们必须对Spark作业的资源使用原理有一个清晰的认识,并知道在Spark作业运行过程中,有哪些资源参数是可以设置的,以及如何设置合适的参数值。
教程地址:http://www.showmeai.tech/tutorials/84
在 YARN 中,每个应用程序实例都有一个 ApplicationMaster 进程,该进程是为该应用程序启动的第一个容器。应用程序负责从 ResourceManager 上请求资源。一旦分配了资源,应用程序将指示 NodeManagers 启动容器。ApplicationMasters 消除了对活跃客户端的依赖:启动应用程序的进程可以终止,并且从在集群上由 YARN 管理的进程继续协作运行。
在前面的文章Fayson介绍了《如何在CDH中使用PySpark分布式运行GridSearch算法》,本篇文章Fayson主要介绍如何在CDSW上向CDH集群推送Gridsearch算法进行分布式计算。
Spark的HistoryServer能正常查看之前的历史作业日志,但新提交的作业在执行完成后未能在HistoryServer页面查看。
Spark 性能调优的第一步,就是为任务分配更多的资源,在一定范围内,增加资源的分配与性能的提升是成正比的,实现了最优的资源配置后,在此基础上再考虑进行后面论述的性能调优策略。
在过去数年中,网易在大数据云原生领域进行了长足的探索。本文围绕如何基于 Apache Kyuubi & Celeborn 等开源技术,构建企业级 Spark on Kubernetes 云原生离线计算平台展开,包含技术选型、架构设计、经验教训、缺陷改进、降本增效等内容,深入剖析网易在该领域的探索成果。
大部分用户在使用CDH集群做Spark开发的时候,由于开发环境的JDK版本比CDH集群默认使用的JDK1.7.0_67-cloudera版本新,可能会出现Spark代码依赖的Java API不兼容问题,解决这个问题方法有两个:一是升级CDH集群的JDK版本;二是指定Spark运行环境JDK版本。本文章主要讲述如何通过Cloudera Manager来指定Spark1和Spark2的运行环境(包含JDK环境、Spark Local Dir等的配置)。
目前Oozie 的 SparkAction 仅支持Spark1.6, 而并不支持Spark2, 这是 CDH Spark2已知的局限性(https://www.cloudera.com/documentation/spark2/latest/topics/spark2_known_issues.html#ki_oozie_spark_action
3.1 Spark应用执行机制分析 下面对Spark Application的基本概念和执行机制进行深入介绍。 3.1.1 Spark应用的基本概念 Spark应用(Application)是用户提交的应用程序。Spark运行模式分为:Local、Standalone、YARN、Mesos等。根据Spark Application的Driver Program是否在集群中运行,Spark应用的运行方式又可以分为Cluster模式和Client模式。 下面介绍Spark应用涉及的一些基本概念: 1)Spark
领取专属 10元无门槛券
手把手带您无忧上云