YARN & Mesos,论集群资源管理所面临的挑战

在国内,大部分的Spark用户都是由Hadoop过渡而来,因此YARN也成了大多Spark应用的底层资源调度保障。而随着Spark应用的逐渐加深,各种问题也随之暴露出来,比如资源调度的粒度问题。为此,7月2日晚,在CSDN Spark高端微信群中,一场基于YARN和Mesos的讨论被拉开,主要参与分享的嘉宾包括TalkingData研发副总裁阎志涛,GrowingIO田毅,AdMaster技术副总裁卢亿雷,Spark Committer、Mesos/Hadoop Contributor夏俊鸾,下面一起回顾。

阎志涛——YARN和Hadoop捆绑以及资源分配粒度问题

这里主要说说Spark on YARN的实践挑战。Talking Data最初引入Spark是2013年,当时主要的考虑是提高机器学习效率,于是在Spark 0.8.1的时候就引入了Spark,那个时候的环境是Hadoop CDH 4.3版本。

最初用Spark就是跑一些基础的数据挖掘任务,其他任务还都是用MR+HIVE来完成。后来发现,对比Hadoop,Spark在开发和性能方面确实具有明显优势,因此就开始将整个数据中心的计算全部迁移到了Spark平台。任务多了,而且需要并发的跑任务,因此就需要一个资源调度系统。 CDH 4.3是支持YARN的,而Spark后边支持了YARN,因此比较自然地选择了YARN来做资源调度。

具体做法是分不同的队列,通过对不同类型任务指定不同的队列,这样就可以并发执行不同的任务。结果遇到的第一个问题就是资源如何去划分? 多个队列的资源划分都是采用不同的资源百分比来实现。整个资源分配的粒度不够细,不过还可以用。 结果到了Spark 1.2的时候Spark就开始声明在后期大版本要废弃对YARN alpha的支持,而CDH 4.3的YARN就是alpha版本。

于是到了Spark 1.3之后就面临了一个选择,后期所有的Spark版本必须自己修改去支持CDH 4.3,或者升级Hadoop到更新的版本(CDH 5.x),或者采用其他的资源调度方式。然而当下的Hadoop集群已有P级别的数据,带着数据升级是一个非常有风险的事情。于是我们开始考虑用Mesos来做资源的调度和管理。我们的计划是CDH 4.3不升级,新的机器都用新的Hadoop版本,然后用Mesos来统一调度。另外,都引入Tachyon作为缓存层,SSD作为shuffle的落地存储。如果用Mesos调度,我们对Hadoop版本的依赖就降低了。Hadoop升级风险有点高。这算是我们遇到的最大的一个坑了。我这里关于YARN的吐槽就这么多,其余的使用Spark的坑,后边有机会再说吧。

田毅——1.4.0中,Spark on YARN的classpath问题

最近遇到了一个说大不大,说小不小的坑,大致情况是提交的spark job遇到了各种各样的classpath问题——包括找不到class和不同版本class冲突。尤其是升级到spark 1.4.0以后,在YARN上运行时经常遇到这个问题,今天主要是和大家分享一下Spark on YARN环境下classpath的问题。总结了一下Spark在YARN上的class加载规则,供大家参考(以下内容针对Spark1.4.0版本YARN client模式)。

Spark通过spark-submit向YARN集群提交job,在不修改spark相关启动脚本的情况下,下列因素决定了spark-submit提交的任务的classpath(可能有遗漏,请补充)。

$SPARK_HOME/lib/datanucleus-*.jar 
$SPARK_CLASSPATH 
—driver-class-path 
—jars 
spark.executor.extraClassPath 
spark.driver.extraClassPath

这是个非常麻烦的问题,Spark做了这么多的配置方式,各个版本加载机制也不太一样,使用起来非常头疼,具体来看看spark-submit命令的执行机制:

bin/spark-submit
执行bin/spark-class
执行bin/load-spark-env.sh
执行conf/spark-env.sh
执行java -cp … org.apache.spark.launcher.Main
生成Driver端的启动命令

其中第5步是最近才改过来的,之前这一步是在shell里面实现的,这一改,想了解实现逻辑就只能看scala源码,对于部分开发者又变成了黑盒……想了解详细过程的同学可以在spark-class命令里面加上set -x,通过观看org.apache.spark.launcher.Main的代码,可以得到Driver端classpath的加载顺序:

- $SPARK_CLASSPATH(废弃,不推荐)  
- 配置—driver-class-path or spark.driver.extraClassPath 
- $SPARK_HOME/conf  
- $SPARK_HOME/lib/spark-assembly-xxx-hadoopxxx.jar  
- $SPARK_HOME/lib/datanucleus-*.jar  
- $HADOOP_CONF_DIR  
- $YARN_CONF_  
- $SPARK_DIST_CLASSPATHDIR

Executor的class加载远比Driver端要复杂,我这里不详细说了,有兴趣的同学可以去看看spark-yarn模块的代码。Executor端classpath加载顺序:

- spark.executor.extraClassPath  
- $SPARK_HOME/lib/spark-assembly-xxx-hadoopxxx.jar  
- $HADOOP_CONF_DIR  
- `hadoop classpath`  
- —jars

这里特别需要注意加载顺序,错误的顺序经常会导致包裹在不同jar包中的不同版本的class被加载,导致调用错误。了解了加载顺序以后,推荐大家配置classpath按照如下方式:

对Driver端,使用—driver-class-path来完成driver端classpath的控制,足够满足需求;对于Executor端,如果使用—jars命令的话,要注意和Hadoop中与spark-assembly的类冲突问题,如果需要优先加载,通过spark.executor.extraClassPath方式进行配置。这里稍微说一句题外话,我们这两天尝试了phoenix的4.4.0版本,对于Spark处理后的DataFrame数据可以非常的方便通过Phoenix加载到HBase。只需要一句话:

hc.sql(sql)
    .write
    .format("org.apache.phoenix.spark")
    .mode(SaveMode.Overwrite)
    .options(Map("table" -> "XXX\_TABLE", "zkUrl" -> (zookeeper))).save()


卢亿雷——YARN的资源管理机制

先看两张YARN资源管理的图,一个是RM的图,一个NodeManage的图:


YARN & Mesos,论集群资源管理所面临的挑战_第1张图片

YARN & Mesos,论集群资源管理所面临的挑战_第2张图片
  1. 多类型资源调度 ——主要采用DRF算法

  2. 提供多种资源调度器 :

FIFO
Fair Scheduler
Capacity Scheduler

  1. 多租户资源调度器:资源按比例分配、层级队列划分方式、以及资源抢占方式

这里举一个遇到的坑:

有一次发现RM不能分配资源,看集群状态都是正常的,CPU、内存、磁盘、带宽都比较低。但是任务分配非常慢,查了RM的日志好长时间后找到一个线索:

2015-04 -22 07:29:15,438 WARN org.apache.hadoop.ipc.Server: Large response size 3552406 for call
org.apache.hadoop.yarn.api.ApplicationClientProtocolPB.getApplications from 10.10.10.239:48535 Call#146914 Retry#0
org.apache.hadoop.yarn.api.ApplicationClientProtocolPB.getApplications from 10.10.10.239:48535 Call#146914 Retry#0

发现是org.apache.hadoop.yarn.api.ApplicationClientProtocolPB.get这个API由于在定期取集群状态,而由于集群的历史状态太多,导致每次取出状态的时候返回值太大,导致RM出现阻塞了。所以建议大家在检测集群状态的时候需要特别留意是否取值太大了。另外就是如果集群有任何的异常,建议一定要先看LOG,LOG基本上可以告诉我们所有的事情。接下来我简单介绍一下我们Hadoop应用的场景:
我们目前拥有由原来几十台机器到现在超过1500台的服务器集群,每天需要完成超过100亿的采集请求,每天有上千亿数据的离线、流式、实时分析和计算。所以对我们的集群非常有挑战。


YARN & Mesos,论集群资源管理所面临的挑战_第3张图片

从这个架构图我们可以发现我们其实基本上用了整个Hadoop生态系统的很多技术和系统。大家一定会问我们为什么会把Flink和Spark一起用。在昨天发的Hadoop Summit 2015有一些简单介绍了。这里,先给大家透漏一下我们做的一个比较:是测试的K-Means,这个数据还是有一些吃惊的。


YARN & Mesos,论集群资源管理所面临的挑战_第4张图片

Flink除了兼容性外,性能竟然要比Spark要高。具体的分析报告下周我会给大家分享的。

夏俊鸾——Mesos特性和现状

你可能感兴趣的:(YARN & Mesos,论集群资源管理所面临的挑战)