Ⅰ 學習hadoop需要理解啟動腳本嗎
1 基本概述
Hadoop的命令位於${HADOOP_HOME}/bin、${HADOOP_HOME}/sbin、${HADOOP_HOME}/libexec下面。包含了Linux的shell腳本和windows的批處理文件。本文主要解析linux下的shell腳本。
2 腳本詳解
2.1 start-all.sh
要啟動Hadoop的各節點和其他服務，這是一個繞不開的啟動腳本，該腳本位於${HADOOP_HOME}/sbin下。不過在Hadoop的2.x版本中，Hadoop官方已經宣布被棄用了。接下來，就詳細地分析一下該腳本是如何工作的：
1、首先腳本開頭有一段注釋：# Start all hadoop daemons. Run this on master node.中文意思是：啟動所有的進程（也就是各節點），在管理節點(也就是namenode-名稱節點)上運行該腳本
2、如果是2.x版本會有echo "This script is Deprecated. Instead usestart-dfs.sh and start-yarn.sh"的提示，意思該腳本已經過時，該腳本已經被start-dfs.sh和 start-yarn.sh替代使用。
3、bin=`dirname"${BASH_SOURCE-$0}"`,提取start-all.sh的所在的絕對路徑。
4、bin=`cd"$bin"; pwd`,切換到start-all.sh的所在目錄下，並將路徑賦值給bin。
5、DEFAULT_LIBEXEC_DIR="$bin"/../libexec,獲取${HADOOP_HOME}/libexec的絕對路徑以備後用。
6、HADOOP_LIBEXEC_DIR=${HADOOP_LIBEXEC_DIR:-$DEFAULT_LIBEXEC_DIR}，為HADOOP_LIBEXEC_DIR變數三元賦值。如果HADOOP_LIBEXEC_DIR為空或者環境變數沒有配置，就賦值默認的絕對路徑，為下一步執行該目錄下面的腳本做准備。
Ⅱ 如何使用spark將程序提交任務到yarn-Spark-about雲開發
使用腳本提交
1.使用spark腳本提交到yarn，首先需要將spark所在的主機和hadoop集群之間hosts相互配置（也就是把spark主機的ip和主機名配置到hadoop所有節點的/etc/hosts裡面，再把集群所有節點的ip和主機名配置到spark所在主機的/etc/hosts裡面）。
2.然後需要把hadoop目錄etc/hadoop下面的*-sit.xml復制到${SPARK_HOME}的conf下面.
3.確保hadoop集群配置了 HADOOP_CONF_DIR or YARN_CONF_DIR
1.yarn-standalone方式提交到yarn
在${SPARK_HOME}下面執行：
SPARK_JAR=./assembly/target/scala-2.10.4/spark-assembly-0.9.0-incubating-hadoop2.2.0.jar \
./bin/spark-class org.apache.spark.deploy.yarn.Client \
--jar ./examples/target/scala-2.10/spark-examples_2.10-assembly-0.9.0-incubating.jar \
--class org.apache.spark.examples.SparkPi \
--args yarn-standalone \
--num-workers 3 \
--master-memory 2g \
--worker-memory 2g \
--worker-cores 1
復制代碼
2. yarn-client 方式提交到yarn
在${SPARK_HOME}下面執行：
SPARK_JAR=./assembly/target/scala-2.10.4/spark-assembly-0.9.0-incubating-hadoop2.2.0.jar \
SPARK_YARN_APP_JAR=examples/target/scala-2.10/spark-examples_2.10-assembly-0.9.0-incubating.jar \
./bin/run-example org.apache.spark.examples.SparkPi yarn-client
復制代碼
二、使用程序提交
1.必須使用linux主機提交任務，使用windows提交到linux hadoop集群會報
org.apache.hadoop.util.Shell$ExitCodeException: /bin/bash: 第 0 行: fg: 無任務控制
復制代碼
錯誤。hadoop2.2.0不支持windows提交到linux hadoop集群，網上搜索發現這是hadoop的bug。
2.提交任務的主機和hadoop集群主機名需要在hosts相互配置。
3.因為使用程序提交是使用yarn-client方式，所以必須像上面腳本那樣設置環境變數SPARK_JAR 和 SPARK_YARN_APP_JAR
比如我的設置為向提交任務主機~/.bashrc裡面添加：
export SPARK_JAR=file:///home/ndyc/software/sparkTest/lib/spark-assembly-0.9.0-incubating-hadoop2.2.0.jar
export SPARK_YARN_APP_JAR=file:///home/ndyc/software/sparkTest/ndspark-0.0.1.jar
復制代碼
file:// 表明是本地文件，如果使用hdfs上的文件將file://替換為hdfs://主機名:埠號。建議使用hdfs來引用 spark-assembly-0.9.0-incubating-hadoop2.2.0.jar，因為這個文件比較大，如果使用file://每次提交任務都需要上傳這個jar到各個集群，很慢。
其中SPARK_JAR是${SPARK_HOME}/assembly/target/scala-2.10.4/spark-assembly-0.9.0-incubating-hadoop2.2.0.jar
SPARK_YARN_APP_JAR是自己程序打的jar包，包含自己的測試程序。
4.程序中加入hadoop、yarn、依賴。
注意，如果引入了hbase依賴，需要這樣配置
<dependency>
<groupId>org.apache.hbase</groupId>
<artifactId>hbase-thrift</artifactId>
<version>${hbase.version}</version>
<exclusions>
<exclusion>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-maprece-client-jobclient</artifactId>
</exclusion>
<exclusion>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-client</artifactId>
</exclusion>
</exclusions>
</dependency>
復制代碼
然後再加入
<dependency>
<groupId>org.ow2.asm</groupId>
<artifactId>asm-all</artifactId>
<version>4.0</version>
</dependency>
復制代碼
否則會報錯：
IncompatibleClassChangeError has interface org.objectweb.asm.ClassVisitor as super class
復制代碼
異常是因為Hbase jar hadoop-maprece-client-jobclient.jar裡面使用到了asm3.1 而spark需要的是asm-all-4.0.jar
5. hadoop conf下的*-site.xml需要復制到提交主機的classpath下，或者說maven項目resources下面。
6.編寫程序
代碼示例：
package com.sdyc.ndspark.sys;
import org.apache.spark.SparkConf;
import org.apache.spark.api.java.JavaPairRDD;
import org.apache.spark.api.java.JavaRDD;
import org.apache.spark.api.java.JavaSparkContext;
import org.apache.spark.api.java.function.Function2;
import org.apache.spark.api.java.function.PairFunction;
import scala.Tuple2;
import java.util.ArrayList;
import java.util.List;
/**
* Created with IntelliJ IDEA.
* User: zarchary
* Date: 14-1-19
* Time: 下午6:23
* To change this template use File | Settings | File Templates.
*/
public class ListTest {
public static void main(String[] args) throws Exception {
SparkConf sparkConf = new SparkConf();
sparkConf.setAppName("listTest");
//使用yarn模式提交
sparkConf.setMaster("yarn-client");
JavaSparkContext sc = new JavaSparkContext(sparkConf);
List<String> listA = new ArrayList<String>();
listA.add("a");
listA.add("a");
listA.add("b");
listA.add("b");
listA.add("b");
listA.add("c");
listA.add("d");
JavaRDD<String> letterA = sc.parallelize(listA);
JavaPairRDD<String, Integer> letterB = letterA.map(new PairFunction<String, String, Integer>() {
@Override
public Tuple2<String, Integer> call(String s) throws Exception {
return new Tuple2<String, Integer>(s, 1);
}
});
letterB = letterB.receByKey(new Function2<Integer, Integer, Integer>() {
public Integer call(Integer i1, Integer i2) {
return i1 + i2;
}
});
//顛倒順序
JavaPairRDD<Integer, String> letterC = letterB.map(new PairFunction<Tuple2<String, Integer>, Integer, String>() {
@Override
public Tuple2<Integer, String> call(Tuple2<String, Integer> stringIntegerTuple2) throws Exception {
return new Tuple2<Integer, String>(stringIntegerTuple2._2, stringIntegerTuple2._1);
}
});
JavaPairRDD<Integer, List<String>> letterD = letterC.groupByKey();
// //false說明是降序
JavaPairRDD<Integer, List<String>> letterE = letterD.sortByKey(false);
System.out.println("========" + letterE.collect());
System.exit(0);
}
}
復制代碼
代碼中master設置為yar-client表明了是使用提交到yarn.
關於spark需要依賴的jar的配置可以參考我的博客spark安裝和遠程調用。
以上弄完之後就可以運行程序了。
運行後會看到yarn的ui界面出現：
正在執行的過程中會發現hadoop yarn 有的nodemanage會有下面這個進程：
13247 org.apache.spark.deploy.yarn.WorkerLauncher
復制代碼
這是spark的工作進程。
如果接收到異常為：
WARN YarnClientClusterScheler: Initial job has not accepted any resources; check your cluster UI to ensure that workers are registered and have sufficient memory
復制代碼
出現這個錯誤是因為提交任務的節點不能和spark工作節點交互，因為提交完任務後提交任務節點上會起一個進程，展示任務進度，大多埠為4044，工作節點需要反饋進度給該該埠，所以如果主機名或者IP在hosts中配置不正確，就會報
WARN YarnClientClusterScheler: Initial job has not accepted any resources; check your cluster UI to ensure that workers are registered and have sufficient memory錯誤。
所以請檢查主機名和IP是否配置正確。
我自己的理解為，程序提交任務到yarn後，會上傳SPARK_JAR和SPARK_YARN_APP_JAR到hadoop節點， yarn根據任務情況來分配資源，在nodemanage節點上來啟動org.apache.spark.deploy.yarn.WorkerLauncher工作節點來執行spark任務，執行完成後退出。
Ⅲ 為什麼我要選擇使用Yarn來做Docker的調度引擎
可部署性
先說明下，這里探討的是Yarn或者Mesos集群的部署，不涉其上的應用。Yarn除了依賴JDK，對操作系統沒有任何依賴，基本上放上去就能
跑。Mesos因為是C/C++開發的，安裝部署可能會有庫依賴。
這點我不知道大家是否看的重，反正我是看的相當重的。軟體就應該是下下來就可以Run。所以12年的時候我就自己開發了一套Java服務框架，開發完之後
運行個main方法就行。讓應用包含容器，而不是要把應用丟到Tomcat這些容器，太復雜，不符合直覺。
二次開發
Yarn 對Java/Scala工程師而言，只是個Jar包，類似索引開發包Lucene，你可以把它引入項目，做任何你想要的包裝。 這是其一。
其二，Yarn提供了非常多的擴展介面，很多實現都是可插拔。可替換的，在XML配置下，可以很方便的用你的實現替換掉原來的實現，沒有太大的侵入性，所以就算是未來Yarn升級，也不會有太大問題。
相比較而言，Mesos更像是一個已經做好的產品，部署了可以直接用，但是對二次開發並不友好。
生態優勢
Yarn 誕生於Hadoop這個大數據的「始作俑者」項目，所以在大數據領域具有先天優勢。
底層天然就是分布式存儲系統HDFS，穩定高效。
其上支撐了Spark、MR等大數據領域的扛頂之座，久經考驗。
社區強大，最近發布版本也明顯加快，對於長任務的支持也越來越優秀。
長任務支持
談及長任務（long running
services）的支持，有人認為早先Yarn是為了支持離線短時任務的，所以可能對長任務的支持有限。其實大可不必擔心，譬如現在基於其上的
Spark Streaming就是7x24小時運行的，跑起來也沒啥問題。一般而言，要支持長任務，需要考慮如下幾個點：
Fault tolerance，主要是AM的容錯。
Yarn Security，如果開啟了安全機制，令牌等的失效時間也是需要注意的。
日誌收集到集群。
還有就是資源隔離和優先順序。如果資源隔離做的太差，會對長時任務產生影響。
大家感興趣可以先參考Jira。我看這個Jira 13年就開始了，說明這事很早就被重視起來了。下面我們隊提到的幾個點做下解釋。
Fault tolerance
Yarn 自身高可用。目前Yarn的Master已經實現了HA。
AM容錯，我看從2.4版本（看的源碼，也可能更早的版本就已經支持）就已經支持 keep containers across
attempt
的選項了。什麼意思呢？就是如果AM掛掉了，在Yarn重新啟動AM的過程中，所有由AM管理的容器都會被保持而不會被殺掉。除非Yarn多次嘗試都沒辦
法把AM再啟動起來（默認兩次）。 這說明從底層調度上來看，已經做的很好了。
日誌收集到集群
日誌收集在2.6版本已經是邊運行邊收集了。
資源隔離
資源隔離的話，Yarn做的不好，目前有效的是內存，對其他方面一直想做支持，但一直有限。這估計也是很多人最後選擇Mesos的緣由。但是現在這
點優勢Mesos其實已經盪然無存，因為Docker容器在資源隔離上已經做的足夠好。Yarn和Docker一整合，就互補了。
小結
Mesos 和 Yarn 都是非常優秀的調度框架，各有其優缺點，彈性調度，統一的資源管理是未來平台的一個趨勢，類似的這種資源管理調度框架必定會大行其道。
一些常見的誤解
脫胎於Hadoop，繼承了他的光環和生態，然而這也會給其帶來一定的困惑，首先就是光環一直被Hadoop給蓋住了，而且由於固有的慣性，大家會理所當然的認為Yarn只是Hadoop里的一個組件，有人會想過把Yarn拿出來單獨用么？
然而，就像我在之前的一篇課程里，反復強調，Hadoop是一個軟體集合，包含分布式存儲，資源管理調度，計算框架三個部分。他們之間沒有必然的關
系，是可以獨立開來的。而Yarn
就是一個資源管理調度引擎，其一開始的設計目標就是為了通用，不僅僅是跑MR。現在基於Yarn之上的服務已經非常多，典型的比如Spark。
這里還有另外一個誤區，MR目前基本算是離線批量的代名詞，這回讓人誤以為Yarn也只是適合批量離線任務的調度。其實不然，我在上面已經給出了分析，Yarn 是完全可以保證長任務的穩定可靠的運行的。
如何基於Yarn開發分布式程序
本文不會具體教你如何使用Yarn的API，不過如果你想知道Yarn的API，但是又覺得官方文檔太過簡略，我這里倒是可以給出兩個建議：
代碼使用範例可以參看Spark Yarn相關的代碼。算的上是一個非常精簡的Yarn的adaptor。
買本Yarn相關的書，了解其體系結構也有助於你了解其API的設計。
接下來的內容會探討以下兩個主題：
基於Yarn開發分布式程序需要做的一些准備工作
基於Yarn開發容器調度系統的一些基本思路
基於Yarn開發分布式程序需要做的一些准備工作
肯定不能擼起袖子就開始干。開始動手前，我們需要知道哪些事情呢？
Yarn原生的API太底層，太復雜了
如果你想愉快的開發Yarn的應用，那麼對Yarn的API進行一次封裝，是很有必要的。
Yarn為了靈活，或者為了能夠滿足開發者大部分的需求，底層交互的API就顯得比較原始了。自然造成開發難度很大。這個也不是我一個人覺得，現在
Apache的Twill，以及Hulu他們開發的時候Adaptor那一層，其實都是為了解決這個問題。那為什麼我沒有用Twill呢，第一是文檔實在
太少，第二是有點復雜，我不需要這么復雜的東西。我覺得，Twill與其開發這么多功能，真的不如好好寫寫文檔。
最好是能開發一個解決一類問題的Framework
Yarn只是一個底層的資源管理和調度引擎。一般你需要基於之上開發一套解決特定問題的Framework。以Spark為例，他是解決分布式計算
相關的一些問題。而以我開發的容器調度程序，其實是為了解決動態部署Web應用的。在他們之上，才是你的應用。比如你要統計日誌，你只要在Spark上開
發一個Application 。 比如你想要提供一個推薦系統，那麼你只要用容器包裝下，就能被容器調度程序調度部署。
所以通常而言，基於Yarn的分布式應用應該符合這么一個層次：
Yarn -> Adapter -> Framework -> Application
Adapter 就是我第一條說的，你自個封裝了Yarn的API。 Framework就是解決一類問題的編程框架，Application才是你真正要解決業務的系統。通過這種解耦，各個層次只要關注自己的核心功能點即可。
保證你上層的Framework/Application可以移植
Spark是個典型，他可以跑在Mesos上，也可以跑在Yarn上，還可以跑在自己上面（Standalone），實時上，泡在Yarn上的，以及跑Standalone模式的，都挺多的。這得益於Spark本身不依賴於底層的資源管理調度引擎。
這其實也是我上面說的兩條帶來的好處，因為有了Adaptor，上層的Framework可以不用綁死在某個資源調度引擎上。而Framework則可以讓Applicaiton 無需關注底層調度的事情，只要關注業務即可。
另外，你費盡心機開發的Framework上，你自然是希望它能跑在更多的平台上，已滿足更多的人的需求，對吧。
基於Yarn開發容器調度系統的一些基本思路
首先我們需要了解兩個概念：
啞應用。所謂啞應用指的是無法和分布式系統直接進行交互，分布式系統也僅僅透過容器能進行生命周期的控制，比如關閉或者開啟的應用。典型的比如MySQL、Nginx等這些基礎應用。他們一般有自己特有的交互方式，譬如命令行或者socket協議或者HTTP協議。
伴生組件。因為有了啞應用的存在，分布式系統為了能夠和這些應用交互，需要有一個代理。而這個代理和被代理的啞應用，具有相同的生命周期。典型
的比如，某個服務被關停後，該事件會被分布式系統獲知，分布式系統會將該事件發送給Nginx的伴生組件，伴生組件轉化為Nginx能夠識別的指令，將停
止的服務從Nginx的ProxyBackend列表中剔除。
在容器調度系統中，如果Yarn的NodeManager直接去管理Docker則需要Yarn本身去做支持，我覺得這是不妥的。Yarn的職責就是做好資源管理，分配，調度即可，並不需要和特定的某個技術耦合，畢竟Yarn是一個通用型的資源調度管理框架。
那基於上面的理論，我們基於Yarn，開發一套框架，這個框架會是典型的 master-slave結構（這是Yarn決定的）。這個框架的 slaves 其實都是Docker 的伴生對象。master 可以通過這些Slave 對容器實現間接的管理。
我們簡單描述下他們的流程：
用戶提交Application，申請資源；
Yarn啟動Framework的master；
Yarn啟動Framework的slave；
slave 連接上master，並且發送心跳，從而master知道slave的狀況slave啟動Docker，slave與被啟動的這個docker container 一一對應；
slave定時監控Container；
slave發現container crash，slave自動退出，Yarn獲得通知，收回資源；
master發現有節點失敗，發出新的節點要求，重新在另外一台伺服器上啟動slave，重復從2開始的步驟。
這里還有一個問題，如果slave 被正常殺掉，可以通過JVM ShudownHook 順帶把Container也關掉。
但是如果slave被kill -9
或者異常crash掉了，那麼就可能導致資源泄露了。目前是這個信息是由master上報給集群管理平台，該平台會定時清理。你也可以存儲該信息，譬如放
到Redis或者MySQL中，然後啟動後台清理任務即可。
了解了這個思路後，具體實施就變得簡單了，就是開發一個基於Yarn的master-slave程序即可，然後slave去管理對應的Docker容器，包括接受新的指令。master提供管理界面展示容器信息，運行狀態即可。
當然，你還可以再開發一套Framework B專門和Nginx交互，這樣比如上面的系統做了節點變更，通知B的master，然後B的master 通過自己的伴生組件Slave 完成Nginx的更新，從而實現後端服務的自動變更和通知。
Ⅳ Mesos和YARN的區別以及它們如何協同工作
Hadoop 2.0之後把對集群資源的管理從MapRece v1的JobTracker中提取出來，在YARN中進行了實現。雖然YARN支持了多種不同的計算框架，但依舊沒有很好的解決集群資源的彈性伸縮問題。本文介紹了一個新的項目- Myriad，它把YARN和Mesos兩者的優勢結合起來，不僅使YARN的運行使用更加靈活，而且讓整個數據中心的擴容變得更簡單。
這是一個關於兩個集群的故事。第一個是Apache Hadoop集群，其中資源與Hadoop以及進程完全隔離。另一個集群是對所有資源的描述，這些資源並不是Hadoop集群的一部分。通過這種方式來區分兩個集群是因為Hadoop通過Apache YARN(Yet Another Resource Negotiator)來管理自己的資源。對於Hadoop來說，在沒有大數據任務在隊列中時，這些資源常常是未被充分使用的。當一個大數據任務運行時，這些資源迅速被用到極限，並且在請求更多資源。這對於第一種集群而言相當困難。
Myriad把YARN和Mesos兩者的優勢結合起來。通過使用Myriad項目，讓Mesos和YARN可以協作，你可以完成一個實時業務。數據分析可以在和運行生產服務的相同硬體上執行。你不再需要面臨由靜態分區引起的資源限制(和低利用率)。資源可以根據業務的需求彈性的伸縮。
最後的思考
為了確保人們理解這個項目的來源，我認為Mesos和YARN擅長在自己特定的場景下工作，並且都有提升的空間。兩者的資源管理器在安全領域都能有所提升;而安全的支持對企業採納與否至關重要。
Mesos需要一個端到端的安全架構，我個人覺得可以使用Kerberos來提供安全支持，但根據個人經驗，這樣做應該不會簡單。對Mesos其他方面的提升同樣十分復雜，主要歸納為資源的搶占和撤銷。假設一個業務的所有資源已經分配，當業務依賴運行的一個最重要的資源項需要擴容時，甚至這個擴容工作僅需要數十分鍾來完成，你仍然會因為缺少資源而無法完成。資源的搶占和撤銷就可以解決這個問題。目前，Mesos圍繞著這個問題有多種解決方案，但我十分期待Mesos委員會使用Dynamic Reservations和Optimistic (Revocable) Resources Offers來解決這個問題。
Myriad作為一種新的技術，讓我們把數據中心或雲端的所有資源當作一個簡單的資源池來使用。正如Hadoop消除數據孤島之間的壁壘一樣，Myriad消除了孤立的集群之間的壁壘。通過Myriad，開發者可以專注於業務依賴的數據和應用程序，而運維團隊可以更敏捷地管理他們的計算資源。這為我們專注數據而不被基礎設施持續困擾打開了另一扇窗。有了Myriad，存儲網路的限制和計算與存儲之間的協調就成為我們在實現完整的靈活性、敏捷和伸縮上的最後一個需要攻克的難題。
Ⅳ spark中怎樣提交任務到import pysparkk
因為spark文檔中只介紹了兩種用腳本提交到yarn的例子，並沒有介紹如何通過程序提交yarn，但是我們的需求需要這樣。網上很難找到例子，經過幾天摸索，終於用程序提交到yarn成功，下面總結一下。先介紹官網提交的例子，我用的是spark 0.9.0 hadoop2.2.0
一.使用腳本提交
1.使用spark腳本提交到yarn，首先需要將spark所在的主機和hadoop集群之間hosts相互配置（也就是把spark主機的ip和主機名配置到hadoop所有節點的/etc/hosts裡面，再把集群所有節點的ip和主機名配置到spark所在主機的/etc/hosts裡面）。
2.然後需要把hadoop目錄etc/hadoop下面的*-sit.xml復制到${SPARK_HOME}的conf下面.
3.確保hadoop集群配置了 HADOOP_CONF_DIR or YARN_CONF_DIR&
1.yarn-standalone方式提交到yarn
在${SPARK_HOME}下面執行：
SPARK_JAR=./assembly/target/scala-2.10.4/spark-assembly-0.9.0-incubating-hadoop2.2.0.jar \
./bin/spark-class org.apache.spark.deploy.yarn.Client \
--jar ./examples/target/scala-2.10/spark-examples_2.10-assembly-0.9.0-incubating.jar \
--class org.apache.spark.examples.SparkPi \
--args yarn-standalone \
--num-workers 3 \
--master-memory 2g \
--worker-memory 2g \
--worker-cores 1
2. yarn-client 方式提交到yarn
在${SPARK_HOME}下面執行：
SPARK_JAR=./assembly/target/scala-2.10.4/spark-assembly-0.9.0-incubating-hadoop2.2.0.jar \
SPARK_YARN_APP_JAR=examples/target/scala-2.10/spark-examples_2.10-assembly-0.9.0-incubating.jar \
./bin/run-example org.apache.spark.examples.SparkPi yarn-client
Ⅵ yarn 硬體配置要求
、相關配置情況
關於內存分配與管理，主要涉及到了ResourceManage、ApplicationMatser、NodeManager這幾個概念，相關的優化也要緊緊圍繞著這幾方面來開展。這里還有一個Container的概念，現在可以先把它理解為運行map/rece task的容器，後面有詳細介紹。
1.1 RM的內存資源配置， 配置的是資源調度相關
RM1：yarn.scheler.minimum-allocation-mb=1G #單個容器可申請的最小內存RM2：yarn.scheler.maximum-allocation-mb=4G #單個容器可申請的最大內存l RM2 必須大於等於 RM1l 一旦設置，不可動態改變
1.2 NM的內存資源配置，配置的是硬體資源相關
NM1：yarn.nodemanager.resource.memory-mb=16G #節點最大可用內存NM2：yarn.nodemanager.vmem-pmem-ratio=2.1 #虛擬內存率，默認2.1l NM1 必須大於 RM2l 使用 RM1 和 NM1 可以計算一個節點最大Container數量：max(Container)=NM1/RM1= 16/1 =16 個l 一旦設置，不可動態改變
1.3 AM內存配置相關參數，配置的是 MR 任務相關
AM1：maprece.map.memory.mb=1.5G #分配給 map Container 的內存大小AM2：maprece.rece.memory.mb=3G #分配給 rece Container 的內存大小l AM1、AM2 必須在 RM1和 RM2 之間l AM2 最好是 AM1 的兩倍l 這兩個值可以在啟動時改變AM3：maprece.map.java.opts=-Xmx 1G #運行map任務的jvm參數，如-Xmx，-Xms等選項AM4：maprece.rece.java.opts=-Xmx 2G #運行rece任務的jvm參數，如-Xmx，-Xms等選項l AM3 必須小於 AM1，AM4 必須小於 AM2
二、對於這些配置概念的理解
步驟1：用戶提交 Job 到ResourceManager步驟2：ResourceManager 為 ApplicationMaster 申請資源，然後在一個NodeManager 上啟動 ApplicationMaster步驟3：ApplicationMaster 與 ResourceManager通信，為要執行的任務申請資源，然後在相應的 NodeManager 上啟動對應的任務。步驟4：所有任務運行完成後，ApplicationMaster 向 ResourceManager 注銷，整個應用程序運行結束。
3.2 關於Container
（1） Container是YARN中資源的抽象，它封裝了某個節點上一定量的資源（CPU和內存兩類資源）。它跟Linux Container沒有任何關系，僅僅是YARN提出的一個概念（從實現上看，可看做一個可序列化/反序列化的Java類）。（2） Container的申請由ApplicationMaster向 ResourceManager申請，由 ResourceManager中的 ResourceScheler非同步分配給 ApplicationMaster；（3） Container的運行由ApplicationMaster向資源所在的NodeManager發起的，Container運行時需提供內部執行的任務命令（可以使任何命令，比如java、Python、C++進程啟動命令均可）以及該命令執行所需的環境變數和外部資源（比如詞典文件、可執行文件、jar包等）。另外，一個應用程序所需的Container分為兩大類，如下：（1） 運行ApplicationMaster的Container：這是由ResourceManager（向內部的資源調度器）申請和啟動的，用戶提交應用程序時，可指定唯一的ApplicationMaster所需的資源；（2） 運行各類任務的Container：這是由ApplicationMaster向ResourceManager申請的，並由ApplicationMaster與NodeManager通信以啟動之。以上兩類Container可能在任意節點上，它們的位置通常而言是隨機的，即ApplicationMaster可能與它管理的任務運行在一個節點上。Container是YARN中最重要的概念之一，懂得該概念對於理解YARN的資源模型至關重要，望大家好好理解。注意：如下圖，map/rece task是運行在Container之中的，所以上面提到的maprece.map(rece).memory.mb大小都大於maprece.map(rece).java.opts值的大小。
四、HDP平台參數調優建議
根據上面介紹的相關知識，我們就可以根據我們的實際情況作出相關參數的設置，當然還需要在運行測試過程中不斷檢驗和調整。以下是hortonworks給出的配置建議：http://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.1.1/bk_installing_manually_book/content/rpm-chap1-11.html自動生成配置腳本：wget http://public-repo-1.hortonworks.com/HDP/tools/2.1.1.0/hdp_manual_install_rpm_helper_files-2.1.1.385.tar.gz執行命令：python hdp-configuration-utils.py -c 16 -m 64 -d 4 -k True
附：規整化因子介紹
為了易於管理資源和調度資源，Hadoop YARN內置了資源規整化演算法，它規定了最小可申請資源量、最大可申請資源量和資源規整化因子，如果應用程序申請的資源量小於最小可申請資源量，則YARN會將其大小改為最小可申請量，也就是說，應用程序獲得資源不會小於自己申請的資源，但也不一定相等；如果應用程序申請的資源量大於最大可申請資源量，則會拋出異常，無法申請成功；規整化因子是用來規整化應用程序資源的，應用程序申請的資源如果不是該因子的整數倍，則將被修改為最小的整數倍對應的值，公式為ceil(a/b)*b，其中a是應用程序申請的資源，b為規整化因子。比如，在yarn-site.xml中設置，相關參數如下：RM1：yarn.scheler.minimum-allocation-mb：最小可申請內存量，默認是1024RM2：yarn.scheler.maximum-allocation-mb：最大可申請內存量，默認是8096yarn.scheler.minimum-allocation-vcores：最小可申請CPU數，默認是1yarn.scheler.maximum-allocation-vcores：最大可申請CPU數，默認是4對於規整化因子，不同調度器不同，具體如下：FIFO和Capacity Scheler，規整化因子等於最小可申請資源量，不可單獨配置。Fair Scheler：規整化因子通過以下參數設置yarn.scheler.increment-allocation-mb=1024myarn.scheler.increment-allocation-vcores=1通過以上介紹可知，應用程序申請到資源量可能大於資源申請的資源量，比如YARN的最小可申請資源內存量為1024，規整因子是1024，如果一個應用程序申請1500內存，則會得到2048內存，如果規整因子是512，則得到1536內存。
Ⅶ hadoop的yarn為什麼要在resourcemanager上啟動腳本
yarn-site.xml裡面配置了管理Resourcemanager和nodemanger的配置
Ⅷ 如何基於 yarn 資源管理器 開發分布式應用
這個不難，我擅長．
Ⅸ spark on yarn是運行在spark集群還是yarn集群
Spark集群有三種運行模式：Standalone、Mesos和YARN模式。現在說Standalone模式。這是最簡單的模式，Spark靠自己就能運行這個模式(不依靠其它集群管理工具)。方法一：手動運行Standalone模式。前提：Spark各個文件都不做任何修改。1、在master機器上運行./sbin/start-master/sh運行完之後，會列印出url:spark://HOST:PORT，這個就是當前master的SparkURL。2、在slave機器上運行./sbin/start-slave.sh然後在Master的管理界面上查看http://master-ip:8080，查看slave是否已上線。方法二：使用集群運行腳本運行Standalone模式。前提：master節點去訪問slave節點需要使用ssh無密碼登錄，因此需要提前配置無密碼登錄。1、在master的conf文件夾下新增slaves文件。slaves文件里存放著每一個slave節點的hostname，每行一個。2、在master節點上運行如下腳本即可
Ⅹ 如何運行YARN中的DistributedShell程序
本文介紹YARN自帶的一個非常簡單的應用程序實例—distributedshell的使用方法。它可以看做YARN編程中的「hello world」，主要功能是並行執行用戶提供的shell命令或者shell腳本。
（1）運行參數介紹
DistributedShell的基本運行參數如下：
（2）運行方法
DistributedShell的運行方法如下：
在YARN安裝目錄下，執行以下命令：
bin/hadoop jar\
share/hadoop/yarn/hadoop-yarn-applications-distributedshell-2.0.0-cdh4.1.1.jar\
org.apache.hadoop.yarn.applications.distributedshell.Client\
–jar share/hadoop/yarn/hadoop-yarn-applications-distributedshell-2.0.0-cdh4.1.1.jar\
–shell_command ls\
–shell_script ignore.sh\
–num_containers 10\
–container_memory 350\
–master_memory 350\
–priority 10
需要注意的是，在hadoop-2.0.3-alpha（不包括該版本）和CDH 4.1.2版本（包括該版本）之前，DistributedShell存在BUG，具體如下：
1） 必須使用–shell_command參數
2） 當只有shell_command參數而沒有shell_script參數時，在分布式模式下（偽分布式下可以）不能執行成功，具體說明和修復方法見： https //issues apache org/jira/browse/YARN-253
在這個實例中，ignore.sh中的內容就是「ls」
3） 內存設置一定要正確，不然會出現以下提示的錯誤：
Container [pid=4424,containerID=container_1359629844156_0004_01_000001] is running beyond virtual memory limits. Current usage: 90.1mb of 128.0mb physical memory used; 593.0mb of 268.8mb virtual memory used. Killing container.
【附】DistributedShell運行日誌：
13/02/01 13:43:11 INFO distributedshell.Client: Initializing Client
13/02/01 13:43:11 INFO distributedshell.Client: Starting Client
13/02/01 13:43:11 INFO distributedshell.Client: Connecting to ResourceManager at c2-23/10.1.1.98:8032
13/02/01 13:43:12 INFO distributedshell.Client: Got Cluster metric info from ASM, numNodeManagers=3
13/02/01 13:43:12 INFO distributedshell.Client: Got Cluster node info from ASM
13/02/01 13:43:12 INFO distributedshell.Client: Got node report from ASM for, nodeId=c2-23:36594, nodeAddressc2-23:8042, nodeRackName/default-rack, nodeNumContainers0, nodeHealthStatusis_node_healthy: true, health_report: 「」, last_health_report_time: 1359697377337,
13/02/01 13:43:12 INFO distributedshell.Client: Got node report from ASM for, nodeId=c2-25:41070, nodeAddressc2-25:8042, nodeRackName/default-rack, nodeNumContainers0, nodeHealthStatusis_node_healthy: true, health_report: 「」, last_health_report_time: 1359697367180,
13/02/01 13:43:12 INFO distributedshell.Client: Got node report from ASM for, nodeId=c2-24:48383, nodeAddressc2-24:8042, nodeRackName/default-rack, nodeNumContainers0, nodeHealthStatusis_node_healthy: true, health_report: 「」, last_health_report_time: 1359699033102,
13/02/01 13:43:12 INFO distributedshell.Client: Queue info, queueName=default, queueCurrentCapacity=0.0, queueMaxCapacity=1.0, queueApplicationCount=0, queueChildQueueCount=0
13/02/01 13:43:12 INFO distributedshell.Client: User ACL Info for Queue, queueName=default, userAcl=SUBMIT_APPLICATIONS
13/02/01 13:43:12 INFO distributedshell.Client: User ACL Info for Queue, queueName=default, userAcl=ADMINISTER_QUEUE
13/02/01 13:43:12 INFO distributedshell.Client: Got new application id=application_1359695803957_0003
13/02/01 13:43:12 INFO distributedshell.Client: Min mem capabililty of resources in this cluster 128
13/02/01 13:43:12 INFO distributedshell.Client: Max mem capabililty of resources in this cluster 10240
13/02/01 13:43:12 INFO distributedshell.Client: Setting up application submission context for ASM
13/02/01 13:43:12 INFO distributedshell.Client: Copy App Master jar from local filesystem and add to local environment
13/02/01 13:43:13 INFO distributedshell.Client: Set the environment for the application master
13/02/01 13:43:13 INFO distributedshell.Client: Trying to generate classpath for app master from current thread』s classpath
13/02/01 13:43:13 INFO distributedshell.Client: Readable bytes from stream=9006
13/02/01 13:43:13 INFO distributedshell.Client: Setting up app master command
13/02/01 13:43:13 INFO distributedshell.Client: Completed setting up app master command ${JAVA_HOME}/bin/java -Xmx350m org.apache.hadoop.yarn.applications.distributedshell.ApplicationMaster –container_memory 350 –num_containers 10 –priority 0 –shell_command ls 1>/AppMaster.stdout 2>/AppMaster.stderr
13/02/01 13:43:13 INFO distributedshell.Client: Submitting application to ASM
13/02/01 13:43:14 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=N/A, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=ACCEPTED, distributedFinalState=UNDEFINED, appTrackingUrl=c2-23:8088/proxy/application_1359695803957_0003/, appUser=rmss
13/02/01 13:43:15 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=RUNNING, distributedFinalState=UNDEFINED, appTrackingUrl=, appUser=rmss
13/02/01 13:43:16 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=RUNNING, distributedFinalState=UNDEFINED, appTrackingUrl=, appUser=rmss
13/02/01 13:43:17 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=RUNNING, distributedFinalState=UNDEFINED, appTrackingUrl=, appUser=rmss
13/02/01 13:43:18 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=RUNNING, distributedFinalState=UNDEFINED, appTrackingUrl=, appUser=rmss
13/02/01 13:43:19 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=FINISHED, distributedFinalState=SUCCEEDED, appTrackingUrl=, appUser=rmss
13/02/01 13:43:19 INFO distributedshell.Client: Application has completed successfully. Breaking monitoring loop
13/02/01 13:43:19 INFO distributedshell.Client: Application completed successfully
轉載僅供參考，版權屬於原作者。祝你愉快，滿意請採納哦