spark调度模式

不多说,直接上干货!

 

 

  目前Apache Spark支持三种分布式部署方式,分别是standalonespark on mesos和 spark on YARN,其中,第一种类似于MapReduce 1.0所采用的模式,内部实现了容错性和资源管理,后两种则是未来发展的趋势,部分容错性和资源管理交由统一的资源管理系统完成:让Spark运行在一个通用的资源管理系统之上,这样可以与其他计算框架,比如MapReduce,公用一个集群资源,最大的好处是降低运维成本和提高资源利用率(资源按需分配)。本文将介绍这三种部署方式,并比较其优缺点。 

 

   推荐

Spark Standalone与Spark on YARN的几种提交方式

 

 

 

 

1. Standalone模式

      即独立模式,自带完整的服务,可单独部署到一个集群中,无需依赖任何其他资源管理系统。从一定程度上说,该模式是其他两种的基础。借鉴Spark开发模式,我们可以得到一种开发新型计算框架的一般思路:先设计出它的standalone模式,为了快速开发,起初不需要考虑服务(比如master/slave)的容错性,之后再开发相应的wrapper,将stanlone模式下的服务原封不动的部署到资源管理系统yarn或者mesos上,由资源管理系统负责服务本身的容错。目前Spark在standalone模式下是没有任何单点故障问题的,这是借助zookeeper实现的,思想类似于Hbase master单点故障解决方案。将Spark standalone与MapReduce比较,会发现它们两个在架构上是完全一致的: 

  1)  都是由master/slaves服务组成的,且起初master均存在单点故障,后来均通过zookeeper解决(Apache MRv1的JobTracker仍存在单点问题,但CDH版本得到了解决); 
  2) 各个节点上的资源被抽象成粗粒度的slot,有多少slot就能同时运行多少task。不同的是,MapReduce将slot分为map slot和reduce slot,它们分别只能供Map Task和Reduce Task使用,而不能共享,这是MapReduce资源利率低效的原因之一,而Spark则更优化一些,它不区分slot类型,只有一种slot,可以供各种类型的Task使用,这种方式可以提高资源利用率,但是不够灵活,不能为不同类型的Task定制slot资源。总之,这两种方式各有优缺点。

 

 

 

2. Spark On Mesos模式

  这是很多公司采用的模式,官方推荐这种模式(当然,原因之一是血缘关系)。正是由于Spark开发之初就考虑到支持Mesos,因此,目前而言,Spark运行在Mesos上会比运行在YARN上更加灵活,更加自然。目前在Spark On Mesos环境中,用户可选择两种调度模式之一运行自己的应用程序(可参考Andrew Xia的“Mesos Scheduling Mode on Spark”): 

  1)   粗粒度模式(Coarse-grained Mode):每个应用程序的运行环境由一个Dirver和若干个Executor组成,其中,每个Executor占用若干资源,内部可运行多个Task(对应多少个“slot”)。应用程序的各个任务正式运行之前,需要将运行环境中的资源全部申请好,且运行过程中要一直占用这些资源,即使不用,最后程序运行结束后,回收这些资源。举个例子,比如你提交应用程序时,指定使用5个executor运行你的应用程序,每个executor占用5GB内存和5个CPU,每个executor内部设置了5个slot,则Mesos需要先为executor分配资源并启动它们,之后开始调度任务。另外,在程序运行过程中,mesos的master和slave并不知道executor内部各个task的运行情况,executor直接将任务状态通过内部的通信机制汇报给Driver,从一定程度上可以认为,每个应用程序利用mesos搭建了一个虚拟集群自己使用。 

  2)   细粒度模式(Fine-grained Mode):鉴于粗粒度模式会造成大量资源浪费,Spark On Mesos还提供了另外一种调度模式:细粒度模式,这种模式类似于现在的云计算,思想是按需分配。与粗粒度模式一样,应用程序启动时,先会启动executor,但每个executor占用资源仅仅是自己运行所需的资源,不需要考虑将来要运行的任务,之后,mesos会为每个executor动态分配资源,每分配一些,便可以运行一个新任务,单个Task运行完之后可以马上释放对应的资源。每个Task会汇报状态给Mesos slave和Mesos Master,便于更加细粒度管理和容错,这种调度模式类似于MapReduce调度模式,每个Task完全独立,优点是便于资源控制和隔离,但缺点也很明显,短作业运行延迟大。

 

 

 

 

3. Spark On YARN模式

 

  这是一种很有前景的部署模式。但限于YARN自身的发展,目前仅支持粗粒度模式(Coarse-grained Mode)。这是由于YARN上的Container资源是不可以动态伸缩的,一旦Container启动之后,可使用的资源不能再发生变化,不过这个已经在YARN计划中了。 

  spark on yarn 的支持两种模式: 
    1) yarn-cluster:适用于生产环境; 
    2) yarn-client:适用于交互、调试,希望立即看到app的输出 

  yarn-cluster和yarn-client的区别在于yarn appMaster,每个yarn app实例有一个appMaster进程,是为app启动的第一个container;负责从ResourceManager请求资源,获取到资源后,告诉NodeManager为其启动container。yarn-cluster和yarn-client模式内部实现还是有很大的区别。如果你需要用于生产环境,那么请选择yarn-cluster;而如果你仅仅是Debug程序,可以选择yarn-client。

 

 

 

总结: 

  这三种分布式部署方式各有利弊,通常需要根据实际情况决定采用哪种方案。进行方案选择时,往往要考虑公司的技术路线(采用Hadoop生态系统还是其他生态系统)、相关技术人才储备等。上面涉及到Spark的许多部署模式,究竟哪种模式好这个很难说,需要根据你的需求,如果你只是测试Spark Application,你可以选择local模式。而如果你数据量不是很多,Standalone 是个不错的选择。当你需要统一管理集群资源(Hadoop、Spark等),那么你可以选择Yarn或者mesos,但是这样维护成本就会变高。 
  · 从对比上看,mesos似乎是Spark更好的选择,也是被官方推荐的 
  · 但如果你同时运行hadoop和Spark,从兼容性上考虑,Yarn是更好的选择。 · 如果你不仅运行了hadoop,spark。还在资源管理上运行了docker,Mesos更加通用。 
  · Standalone对于小规模计算集群更适合!

 

 

 

 

Spark运行模式简介(本博文)

  Spark运行模式列表(一定要熟悉!)

 

 

 

    注意: Spark on Yarn 有  yarn  client 和  yarn clusters 模式。

                Spark on Standalone 也有  standalone client 和  standalone clusters 模式。

 

 

 

 

 

 

 

 

 

   手把手带你进入官网,来进一步学习Spark运行模式

 http://spark.apache.org/docs/latest/

 

 

 

 

 

 

 

 

 

 

同时,大家可以关注我的个人博客

   http://www.cnblogs.com/zlslch/   和     http://www.cnblogs.com/lchzls/      http://www.cnblogs.com/sunnyDream/   

   详情请见:http://www.cnblogs.com/zlslch/p/7473861.html

 

  人生苦短,我愿分享。本公众号将秉持活到老学到老学习无休止的交流分享开源精神,汇聚于互联网和个人学习工作的精华干货知识,一切来于互联网,反馈回互联网。
  目前研究领域:大数据、机器学习、深度学习、人工智能、数据挖掘、数据分析。 语言涉及:Java、Scala、Python、Shell、Linux等 。同时还涉及平常所使用的手机、电脑和互联网上的使用技巧、问题和实用软件。 只要你一直关注和呆在群里,每天必须有收获

### Apache Spark 调度系统的工作原理 Apache Spark调度系统是一个复杂的多层结构,负责协调任务分配、资源管理和执行计划。它主要包括两个核心组件:DAGScheduler 和 TaskScheduler。 #### DAGScheduler DAGScheduler 主要用于将逻辑上的 RDD 操作转换为物理的任务集(Stages)。当提交一个作业时,DAGScheduler 会解析依赖关系并构建有向无环图(Directed Acyclic Graph, DAG),从而决定如何划分 Stages 并生成相应的任务列表[^1]。 #### TaskScheduler TaskScheduler 则专注于具体的任务分发和执行。它与底层的 Cluster Manager 协同工作,将任务分配到各个 Worker 上运行。Cluster Manager 可能是 Standalone、YARNMesos 等不同的实现方式[^2]。 --- ### 配置 Spark 调度系统的参数 为了优化 Spark 应用程序的表现,可以通过调整一系列配置项来微调调度行为: | 参数名称 | 描述 | |----------|------| | `spark.scheduler.mode` | 定义调度模式,默认为 FIFO;也可以设置为 FAIR 来支持公平共享资源。 | | `spark.speculation` | 启用推测执行机制,检测慢速任务并重新启动副本以加速整体进度。 | | `spark.dynamicAllocation.enabled` | 开启动态资源分配功能,在负载变化时自动增减 Executors 数量[^3]。 | 以下是启用 Fair Scheduler 的示例代码片段: ```scala val conf = new SparkConf() conf.set("spark.scheduler.mode", "FAIR") ``` 对于更精细控制,还可以定义 XML 文件指定池策略,并通过 `spark.scheduler.allocation.file` 加载该文件。 --- ### 最佳实践建议 1. **合理规划分区数** 数据倾斜问题是影响性能的重要因素之一。应根据输入数据规模设定合适的 partition 值,通常推荐每核处理约 200MB~500MB 的数据。 2. **监控与日志分析** 使用内置工具如 Web UI 查看实时指标,及时发现瓶颈所在。此外,记录详细的调试信息有助于排查异常情况。 3. **充分利用缓存机制** 对频繁访问的数据集应用持久化操作 (`persist()` / `cache()`) ,减少重复计算开销。 4. **平衡内存分配** 根据实际需求调整 executor-memory 和 driver-memory 大小,避免 OOM 错误发生的同时提高吞吐率。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值