在國內(nèi)，大部分的Spark用戶都是由Hadoop過渡而來太雨，因此YARN也成了大多Spark應(yīng)用的底層資源調(diào)度保障吟榴。而隨著Spark應(yīng)用的逐漸加深，各種問題也隨之暴露出來囊扳，比如資源調(diào)度的粒度問題吩翻。為此，7月2日晚锥咸，在CSDN Spark高端微信群中狭瞎，一場(chǎng)基于YARN和Mesos的討論被拉開，主要參與分享的嘉賓包括TalkingData研發(fā)副總裁閻志濤搏予，GrowingIO田毅熊锭，AdMaster技術(shù)副總裁盧億雷，Spark Committer、Mesos/Hadoop Contributor夏俊鸞碗殷，下面一起回顧精绎。

閻志濤——YARN和Hadoop捆綁以及資源分配粒度問題

這里主要說說Spark on YARN的實(shí)踐挑戰(zhàn)。Talking Data最初引入Spark是2013年锌妻，當(dāng)時(shí)主要的考慮是提高機(jī)器學(xué)習(xí)效率代乃，于是在Spark 0.8.1的時(shí)候就引入了Spark，那個(gè)時(shí)候的環(huán)境是Hadoop CDH 4.3版本仿粹。

最初用Spark就是跑一些基礎(chǔ)的數(shù)據(jù)挖掘任務(wù)搁吓，其他任務(wù)還都是用MR+HIVE來完成。后來發(fā)現(xiàn)吭历，對(duì)比Hadoop堕仔，Spark在開發(fā)和性能方面確實(shí)具有明顯優(yōu)勢(shì)，因此就開始將整個(gè)數(shù)據(jù)中心的計(jì)算全部遷移到了Spark平臺(tái)晌区。任務(wù)多了摩骨，而且需要并發(fā)的跑任務(wù)，因此就需要一個(gè)資源調(diào)度系統(tǒng)朗若。 CDH 4.3是支持YARN的仿吞，而Spark后邊支持了YARN，因此比較自然地選擇了YARN來做資源調(diào)度捡偏。

具體做法是分不同的隊(duì)列，通過對(duì)不同類型任務(wù)指定不同的隊(duì)列峡迷，這樣就可以并發(fā)執(zhí)行不同的任務(wù)银伟。結(jié)果遇到的第一個(gè)問題就是資源如何去劃分？ 多個(gè)隊(duì)列的資源劃分都是采用不同的資源百分比來實(shí)現(xiàn)绘搞。整個(gè)資源分配的粒度不夠細(xì)彤避，不過還可以用。 結(jié)果到了Spark 1.2的時(shí)候Spark就開始聲明在后期大版本要廢棄對(duì)YARN alpha的支持夯辖，而CDH 4.3的YARN就是alpha版本琉预。

于是到了Spark 1.3之后就面臨了一個(gè)選擇，后期所有的Spark版本必須自己修改去支持CDH 4.3蒿褂，或者升級(jí)Hadoop到更新的版本(CDH 5.x)圆米，或者采用其他的資源調(diào)度方式。然而當(dāng)下的Hadoop集群已有P級(jí)別的數(shù)據(jù)啄栓，帶著數(shù)據(jù)升級(jí)是一個(gè)非常有風(fēng)險(xiǎn)的事情娄帖。于是我們開始考慮用Mesos來做資源的調(diào)度和管理。我們的計(jì)劃是CDH 4.3不升級(jí)昙楚，新的機(jī)器都用新的Hadoop版本近速，然后用Mesos來統(tǒng)一調(diào)度。另外，都引入Tachyon作為緩存層削葱，SSD作為shuffle的落地存儲(chǔ)奖亚。如果用Mesos調(diào)度，我們對(duì)Hadoop版本的依賴就降低了析砸。Hadoop升級(jí)風(fēng)險(xiǎn)有點(diǎn)高昔字。這算是我們遇到的最大的一個(gè)坑了。我這里關(guān)于YARN的吐槽就這么多干厚，其余的使用Spark的坑李滴，后邊有機(jī)會(huì)再說吧。

田毅——1.4.0中蛮瞄，Spark on YARN的classpath問題

最近遇到了一個(gè)說大不大所坯，說小不小的坑，大致情況是提交的spark job遇到了各種各樣的classpath問題——包括找不到class和不同版本class沖突挂捅。尤其是升級(jí)到spark 1.4.0以后芹助，在YARN上運(yùn)行時(shí)經(jīng)常遇到這個(gè)問題，今天主要是和大家分享一下Spark on YARN環(huán)境下classpath的問題闲先∽赐粒總結(jié)了一下Spark在YARN上的class加載規(guī)則，供大家參考（以下內(nèi)容針對(duì)Spark1.4.0版本YARN client模式）伺糠。

Spark通過spark-submit向YARN集群提交job蒙谓，在不修改spark相關(guān)啟動(dòng)腳本的情況下，下列因素決定了spark-submit提交的任務(wù)的classpath（可能有遺漏训桶，請(qǐng)補(bǔ)充）累驮。

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

這是個(gè)非常麻煩的問題，Spark做了這么多的配置方式舵揭，各個(gè)版本加載機(jī)制也不太一樣谤专，使用起來非常頭疼，具體來看看spark-submit命令的執(zhí)行機(jī)制：

bin/spark-submit
執(zhí)行bin/spark-class
執(zhí)行bin/load-spark-env.sh
執(zhí)行conf/spark-env.sh
執(zhí)行java -cp … org.apache.spark.launcher.Main
生成Driver端的啟動(dòng)命令

其中第5步是最近才改過來的午绳，之前這一步是在shell里面實(shí)現(xiàn)的置侍，這一改，想了解實(shí)現(xiàn)邏輯就只能看scala源碼拦焚，對(duì)于部分開發(fā)者又變成了黑盒……想了解詳細(xì)過程的同學(xué)可以在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加載遠(yuǎn)比Driver端要復(fù)雜算色，我這里不詳細(xì)說了，有興趣的同學(xué)可以去看看spark-yarn模塊的代碼螟够。Executor端classpath加載順序：

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

這里特別需要注意加載順序灾梦，錯(cuò)誤的順序經(jīng)常會(huì)導(dǎo)致包裹在不同jar包中的不同版本的class被加載峡钓，導(dǎo)致調(diào)用錯(cuò)誤。了解了加載順序以后若河，推薦大家配置classpath按照如下方式：

對(duì)Driver端能岩，使用—driver-class-path來完成driver端classpath的控制，足夠滿足需求萧福；對(duì)于Executor端拉鹃，如果使用—jars命令的話，要注意和Hadoop中與spark-assembly的類沖突問題鲫忍，如果需要優(yōu)先加載膏燕，通過spark.executor.extraClassPath方式進(jìn)行配置。這里稍微說一句題外話悟民，我們這兩天嘗試了phoenix的4.4.0版本坝辫，對(duì)于Spark處理后的DataFrame數(shù)據(jù)可以非常的方便通過Phoenix加載到HBase。只需要一句話：

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

盧億雷——YARN的資源管理機(jī)制

先看兩張YARN資源管理的圖射亏，一個(gè)是RM的圖近忙，一個(gè)NodeManage的圖：

1. 多類型資源調(diào)度 ——主要采用DRF算法

2. 提供多種資源調(diào)度器 ：

FIFO
Fair Scheduler
Capacity Scheduler

3. 多租戶資源調(diào)度器：資源按比例分配、層級(jí)隊(duì)列劃分方式智润、以及資源搶占方式

這里舉一個(gè)遇到的坑：

有一次發(fā)現(xiàn)RM不能分配資源及舍，看集群狀態(tài)都是正常的，CPU窟绷、內(nèi)存锯玛、磁盤、帶寬都比較低兼蜈。但是任務(wù)分配非常慢更振，查了RM的日志好長時(shí)間后找到一個(gè)線索：

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

發(fā)現(xiàn)是org.apache.hadoop.yarn.api.ApplicationClientProtocolPB.get這個(gè)API由于在定期取集群狀態(tài)，而由于集群的歷史狀態(tài)太多饭尝，導(dǎo)致每次取出狀態(tài)的時(shí)候返回值太大，導(dǎo)致RM出現(xiàn)阻塞了献宫。所以建議大家在檢測(cè)集群狀態(tài)的時(shí)候需要特別留意是否取值太大了钥平。另外就是如果集群有任何的異常，建議一定要先看LOG姊途，LOG基本上可以告訴我們所有的事情涉瘾。接下來我簡(jiǎn)單介紹一下我們Hadoop應(yīng)用的場(chǎng)景：
我們目前擁有由原來幾十臺(tái)機(jī)器到現(xiàn)在超過1500臺(tái)的服務(wù)器集群，每天需要完成超過100億的采集請(qǐng)求捷兰，每天有上千億數(shù)據(jù)的離線立叛、流式、實(shí)時(shí)分析和計(jì)算贡茅。所以對(duì)我們的集群非常有挑戰(zhàn)秘蛇。

從這個(gè)架構(gòu)圖我們可以發(fā)現(xiàn)我們其實(shí)基本上用了整個(gè)Hadoop生態(tài)系統(tǒng)的很多技術(shù)和系統(tǒng)其做。大家一定會(huì)問我們?yōu)槭裁磿?huì)把Flink和Spark一起用。在昨天發(fā)的Hadoop Summit 2015有一些簡(jiǎn)單介紹了赁还。這里妖泄，先給大家透漏一下我們做的一個(gè)比較：是測(cè)試的K-Means，這個(gè)數(shù)據(jù)還是有一些吃驚的艘策。

夏俊鸞——Mesos特性和現(xiàn)狀