在國內(nèi)，大部分的Spark用戶都是由Hadoop過渡而來，因此YARN也成了大多Spark應(yīng)用的底層資源調(diào)度保障。而隨著Spark應(yīng)用的逐漸加深，各種問題也隨之暴露出來，比如資源調(diào)度的粒度問題。為此，7月2日晚，在CSDN Spark高端微信群中，一場基于YARN和Mesos的討論被拉開，主要參與分享的嘉賓包括TalkingData研發(fā)副總裁閻志濤，GrowingIO田毅，AdMaster技術(shù)副總裁盧億雷，Spark Committer、Mesos/Hadoop Contributor夏俊鸞，下面一起回顧。
這里好多老朋友了，這里主要說說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)，對比Hadoop，Spark在開發(fā)和性能方面確實(shí)具有明顯優(yōu)勢，因此就開始將整個(gè)數(shù)據(jù)中心的計(jì)算全部遷移到了Spark平臺。任務(wù)多了，而且需要并發(fā)的跑任務(wù)，因此就需要一個(gè)資源調(diào)度系統(tǒng)。 CDH 4.3是支持YARN的，而Spark后邊支持了YARN，因此比較自然地選擇了YARN來做資源調(diào)度。
具體做法是分不同的隊(duì)列，通過對不同類型任務(wù)指定不同的隊(duì)列，這樣就可以并發(fā)執(zhí)行不同的任務(wù)。結(jié)果遇到的第一個(gè)問題就是資源如何去劃分？ 多個(gè)隊(duì)列的資源劃分都是采用不同的資源百分比來實(shí)現(xiàn)。整個(gè)資源分配的粒度不夠細(xì)，不過還可以用。 結(jié)果到了Spark 1.2的時(shí)候Spark就開始聲明在后期大版本要廢棄對YARN alpha的支持，而CDH 4.3的YARN就是alpha版本。
于是到了Spark 1.3之后就面臨了一個(gè)選擇，后期所有的Spark版本必須自己修改去支持CDH 4.3，或者升級Hadoop到更新的版本(CDH 5.x)，或者采用其他的資源調(diào)度方式。然而當(dāng)下的Hadoop集群已有P級別的數(shù)據(jù)，帶著數(shù)據(jù)升級是一個(gè)非常有風(fēng)險(xiǎn)的事情。于是我們開始考慮用Mesos來做資源的調(diào)度和管理。我們的計(jì)劃是CDH 4.3不升級，新的機(jī)器都用新的Hadoop版本，然后用Mesos來統(tǒng)一調(diào)度。另外，都引入Tachyon作為緩存層，SSD作為shuffle的落地存儲(chǔ)。如果用Mesos調(diào)度，我們對Hadoop版本的依賴就降低了。Hadoop升級風(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沖突。尤其是升級到spark 1.4.0以后，在YARN上運(yùn)行時(shí)經(jīng)常遇到這個(gè)問題，今天主要是和大家分享一下Spark on YARN環(huán)境下classpath的問題?？偨Y(jié)了一下Spark在YARN上的class加載規(guī)則，供大家參考（以下內(nèi)容針對Spark1.4.0版本YARN client模式）。
Spark通過spark-submit向YARN集群提交job，在不修改spark相關(guān)啟動(dòng)腳本的情況下，下列因素決定了spark-submit提交的任務(wù)的classpath（可能有遺漏，請補(bǔ)充）。
這是個(gè)非常麻煩的問題，Spark做了這么多的配置方式，各個(gè)版本加載機(jī)制也不太一樣，使用起來非常頭疼，具體來看看spark-submit命令的執(zhí)行機(jī)制：
其中第5步是最近才改過來的，之前這一步是在shell里面實(shí)現(xiàn)的，這一改，想了解實(shí)現(xiàn)邏輯就只能看scala源碼，對于部分開發(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按照如下方式：
對Driver端，使用—driver-class-path來完成driver端classpath的控制，足夠滿足需求；對于Executor端，如果使用—jars命令的話，要注意和Hadoop中與spark-assembly的類沖突問題，如果需要優(yōu)先加載，通過spark.executor.extraClassPath方式進(jìn)行配置。這里稍微說一句題外話，我們這兩天嘗試了phoenix的4.4.0版本，對于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資源管理的圖，一個(gè)是RM的圖，一個(gè)NodeManage的圖：
1. 多類型資源調(diào)度 ——主要采用DRF算法
2. 提供多種資源調(diào)度器 ：
3. 多租戶資源調(diào)度器：資源按比例分配、層級隊(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 callorg.apache.hadoop.yarn.api.ApplicationClientProtocolPB.getApplications from 10.10.10.239:48535 Call#146914 Retry#0org.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)阻塞了。所以建議大家在檢測集群狀態(tài)的時(shí)候需要特別留意是否取值太大了。另外就是如果集群有任何的異常，建議一定要先看LOG，LOG基本上可以告訴我們所有的事情。接下來我簡單介紹一下我們Hadoop應(yīng)用的場景：
我們目前擁有由原來幾十臺機(jī)器到現(xiàn)在超過1500臺的服務(wù)器集群，每天需要完成超過100億的采集請求，每天有上千億數(shù)據(jù)的離線、流式、實(shí)時(shí)分析和計(jì)算。所以對我們的集群非常有挑戰(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有一些簡單介紹了。這里，先給大家透漏一下我們做的一個(gè)比較：是測試的K-Means，這個(gè)數(shù)據(jù)還是有一些吃驚的。
Flink除了兼容性外，性能竟然要比Spark要高。具體的分析報(bào)告下周我會(huì)給大家分享的。
夏俊鸞——Mesos特性和現(xiàn)狀
其實(shí)，Mesos在國外用得比較多，國內(nèi)不是太多。從目前Mesos官網(wǎng)上看，比較大的就是airbnb和yelp。Mesos在spark 0.8版本的時(shí)候就有了，和standalone差不多一起誕生，YARN差不多到1.0才可用。其實(shí)在Spark 出來的時(shí)候Mesos遠(yuǎn)比YARN穩(wěn)定，而且也是伯克利自己的東西，支持的力度很大。
目前Spark里面Mesos和YARN都支持兩種調(diào)度模式，client和cluster。其中Mesos還支持粗力度和細(xì)力度兩種模式，細(xì)力度的模式下，在提交task的時(shí)候直接跟mesos master通信，使得Spark作業(yè)和其他框架作業(yè)共享資源。當(dāng)然也包括其它的Spark作業(yè)，資源不獨(dú)占。但是這樣方式的壞處就是調(diào)度overhead比較大，不適合交互式作業(yè)。粗力度的調(diào)度方式其實(shí)和目前YARN是一樣的，有利于低延遲的作業(yè)。兩種模式的測試數(shù)據(jù)我有的，下次可以分享一下。由于不在Hadoop的生態(tài)內(nèi)，Mesos還是比較悲劇的。
Q（CSDN用戶）：Spark生成parquet格式一般建議每個(gè)parquet多大？
田毅：這個(gè)我的建議是別弄太大，數(shù)據(jù)(壓縮前)最好別超過128M，這個(gè)數(shù)不是絕對的，要看你的列數(shù)和壓縮比。
閻志濤：我們的都在幾百兆，parquet主要還是看你讀取出多少列來。如果讀出的列很多，性能就不一定好了。
Q（CSDN用戶）：千萬數(shù)據(jù)的join或者reduce過程中總是有任務(wù)節(jié)點(diǎn)丟失的情況？
田毅：這個(gè)是經(jīng)常出現(xiàn)的問題，最常見原因還是GC導(dǎo)致的長時(shí)間卡住，導(dǎo)致心跳超時(shí)。可以參考intel他們最近在summit上分享的GC調(diào)優(yōu)方面的實(shí)踐。GC問題在1.4版本中已經(jīng)得到改善，比如大量數(shù)據(jù)查重。
