Apache Hadoop YARNとマルチテナントにおけるリソース管理

Apache Hadoop YARNと
マルチテナントにおけるリソース管理

2 © Cloudera, Inc. All rights reserved.
• YARN概要
• YARNアプリケーションの動作の仕組み
• YARNにおけるリソース管理の基礎知識
• フェアスケジューラ
• フェアスケジューラの設定の基本
• キュー配置ポリシー
• プリエンプション
• ケーススタディ
• tips
目次

© Cloudera, Inc. All rights reserved.
YARN概要

• YARN: Yet Another Resource Negotiator
• Apache Hadoopエコシステムのためのリソース管理レイヤー
• 数台から数千台のサーバやインスタンスのリソースオーケストレーションを行う分散
サービス
YARNとは

• クライアント
• 仕事をクラスタに指示する
• ノード
• 独立したサーバやインスタンス
• クラスタ
• 高速なLANで接続されている、複数のノードの集合体
• マスターノード
• クライアントとの通信ポイント
• クライアントから要求された仕事をワーカーノードに割り当てる
• ワーカーノード
• マスターノードから割り当てられた仕事を行う
基本的な用語説明(1)
クライアント、ノード、クラスタ、マスター、ワーカー
クラスタ
マスターノード
クライアント
ワーカーノードワーカーノード

クラスタ
• リソースマネージャ
• マスターデーモン
• クラスタのリソースを管理する
• タスクをワーカーに振る
• ノードマネージャ
• ワーカーデーモン
• MapReduceやSparkなどのプロセスをワー
カーノード上に起動し、管理する
リソースマネージャとノードマネージャ
ワーカーノード
クライアント
リソースマネージャ
ノードマネージャ

クラスタ
• リソース
• vcoreとメモリの二種類
• ノードマネージャはローカルのリソースを管理している
• リソースマネージャはクラスタ全体の合計リソースを管理してい
る
• vcore
• 仮想的なCPUコア
• CPUの利用率のようなもので、物理 CPUと必ずしも一致する必要
はない
• 例: 10物理CPUコアのホスト上に16vcoreを割り当てる、など
• メモリ
• 設定上のメモリ割り当てであり、こちらも仮想的なもの
• 物理メモリと一致する必要はない
• 現実にはswapの発生などを考えると、物理メモリを超過して設定する場合
は注意が必要
リソースとvcore
クライアント
16 vcore 48 GB 16 vcore 48 GB
32 vcore 96 GB クラスタ合計
物理CPUコアは16未満でもOK

クラスタ
• コンテナ
• リソース保持を行う単位
• vcoreとメモリを保持可能
• タスク
• コンテナ内で起動されるプロセス
• コンテナのリソースはタスクに割当てられる
• クライアントのコードはタスク内で実行される
コンテナとタスク
クライアント
14/16 vcore 36/48 GB 16/16 vcore 48/48 GB
30/32 vcore 84 / 96 GB
コンテナ
2 vcore / 12 GB
リソースの確
保を指示
タスク
コンテナを作成し、タス
クを起動

クラスタ
• アプリケーション
• 1つ以上のタスクから構成される、YARNクライ
アントプログラム
• アプリケーションマスター
• YARNクラスタ上のタスクを取りまとめる、特別
なタスク
• アプリケーション毎に1つ存在
アプリケーションとアプリケーションマスター
クライアント
アプリケーションマスター
タスク
タスク
タスク
アプリケーション

YARNアプリケーションの動作の仕組み

アプリケーションの動作の仕組み
クラスタマスターノード
クライアント
アプリケーションマスタータスク
タスク
ジョブを実行する命令をリソースマネージャ
に送る
ジョブ実行のためのリソース割り当てと、管
理を行う
コンテナの一つとして起動される
ジョブの管理を行う
コンテナの一つとして起動される
実タスクの実行を行う

アプリケーションの動作の仕組み(1)
クライアント
1. アプリケーションが起動したら、リソースマネー
ジャにタスク実行を指示
アプリケーションマスター
2. リソースマネージャがノードマネー
ジャにアプリケーションマスターの起
動を指示
タスク
タスク
3. アプリケーションマスターはリソース
マネージャに、タスク実行のためのリ
ソースを要求
4. アプリケーションマスターは、割り当
てられたリソースに基づき、ノードマ
ネージャにタスクの起動を指示

アプリケーションの動作の仕組み(2)
クライアント
アプリケーションマスタータスク
タスク
5. タスクが終了したら、リソー
スが解放される
6. 全てのタスクが終了したら、アプリ
ケーションマスターも終了し、リソースが
解放される
7. 結果が返り、アプリケーションが終了する

YARNにおけるリソース管理の基礎知識

• オーバーヘッド
• OS
• Hadoopエコシステム以外のプロセス
• Cloudera Managerエージェントなど
• YARN以外のHadoopエコシステム
• HDFS
• Kudu
• HBase
• Impala
• など
• ノードマネージャのプロセス
• 上記を取り除いた残りが、コンテナ用に割当可
能なリソースとなる
ワーカーノードで利用可能なリソース
OS
Hadoopエコシステム以外のプロセス
YARN以外のHadoopエコシステムのプロセス
HDFS HBaseKudu Impala
コンテナ用リソース
これらは全てオーバーヘッド
リソースとして使えるのはここだけ

コンテナ用のリソースと設定
vcore
メモリ
1つのノードマネージャでコンテナとして利用可能なvcoreの総量
yarn.nodemanager.resource.vcores
コンテナへのvcore割り当てに関する設定
最小値: yarn.scheduler.minimum-allocation-vcores
最大値: yarn.scheduler.maximum-allocation-vcores
割当単位: yarn.scheduler.increment-allocation-vcores
1つのノードマネージャでコンテナとして利用可能なメモリの総量
yarn.nodemanager.resource.memory-mb
コンテナへのメモリ割り当てに関する設定
最小値: yarn.scheduler.minimum-allocation-mb
最大値: yarn.scheduler.maximum-allocation-mb
割当単位: yarn.scheduler.increment-allocation-mb

アプリケーションでの利用例(1) MapReduce
vcore
M R R A
メモリ
M M M R R R R A A
アプリケーションマスターに関する設定
vcore: yarn.app.mapreduce.am.resource.mb
メモリ: yarn.app.mapreduce.am.resource.cpu-vcores
Mapタスクに関する設定
vcore: mapreduce.map.cpu.vcores
メモリ: mapreduce.map.memory.mb
Reduceタスクに関する設定
vcore: mapreduce.reduce.cpu.vcores
メモリ: mapreduce.reduce.memory.mb

アプリケーションでの利用例(2) Spark
vcore
D E
メモリ
D D D E E E E
アプリケーションマスター(ドライバー: クラスターデプロイ
モード)に関する設定
vcore: spark.driver.cores
メモリ: spark.driver.memory
エグゼキューターに関する設定
vcore: spark.executor.cores
メモリ: spark.executor.memory
E

フェアスケジューラ

• いつ、どこで、どのジョブを、どの程度のリソースを使って実行するかを決める機構
• YARNでは以下の3つのスケジューラが存在する
• フェアスケジューラ
• FIFOスケジューラ
• キャパシティスケジューラ
• Clouderaではフェアスケジューラを推奨しているため、本スライドでは特に断りがない
限り、スケジューラはフェアスケジューラを指すものとする
スケジューラ

• Fair Scheduler: 公平なスケジューラ
• 重み付けされたリソースキュー(リソースプール)ごとに、公平にリソースを配分してい
くスケジューラ
• Clouderaで採用しているスケジューラの正式名称はDRF(Dominant Resource
Fairness)スケジューラ
• 以後、特に断りがない限りフェアスケジューラとはDRFのことを指すものとする
フェアスケジューラとは

• YARNのスケジューラの基本構造
• 階層構造を持つことが可能
• アプリケーションはキューに割当てられ
る
• 最上位の親キューは root という
• root 以外の全てのキューは親キューを
持つ
キュー
root
sales
marketing
datascience
eastjapan
westjapan
batch
adhoc
besteffort
smalljob

ウェイトによるリソース配分
root
sales
marketing
datascience
eastjapan
westjapan
batch
adhoc
besteffort
smalljob
100
30
30
40
15
15
2
1
100
(設定なし)
同一階層におけるウェイトの設定で、リソース配分の比率が決まる
salesは全体の30%のリソースを利用できる
あくまで同一階層のウェイトのみを参照する
batchとadhocの場合、2:1の比率でmarketingのリソースを配分する
これは全体の20%と10%に相当する
ベストエフォートのキューを作る場合、ウェイトを設定しなければいい
besteffortキューは、smalljobで何もジョブが動いていないときのみ利用可能とな
る

• 設定ファイルはxml形式
• fair-scheduler.xml に記述
• Cloudera Managerを使ってクラスタ管
理している場合は不要
設定方法 (XMLファイルの場合)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<allocations>
<queue name="root">
<schedulingPolicy>drf</schedulingPolicy>
<queue name="default">
</queue>
<queue name="users" type="parent">
</queue>
</queue>
<queuePlacementPolicy>
<rule name="specified" create="true"/>
<rule name="nestedUserQueue">
<rule name="default" queue="users"/>
</rule>
<rule name="default" create="true"/>
</queuePlacementPolicy>
</allocations>

トップメニュー
→ 動的リソースプール
→ リソースプールの作成
GUIで設定可能
設定方法(Cloudera Manager の場合)

フェアスケジューラの設定の基本

ウェイト(加重)
root
sales
marketing
datascience
eastjapan
westjapan
batch
adhoc
besteffort
smalljob
100
30
30
40
15
15
2
1
100
(設定なし)
ウェイトの説明は既に行ったため、ここでは省略
設定は数値を指定するだけ

最小リソースと最大リソース
他のキューでどれだけリソースが使われていても、最小リソース分を利用可能
ソフトリミットのため、常にリソースを予約しているわけではない
最小リソース
最大リソース
このキューがどれだけリソースを要求していても、最大リソース以上に利用すること
はできない
ハードリミットのため、リソースの空きがあってもこの設定以上は利用不可
最小リソースは、仮想コアとメモリを明示的に指定する必要あり
設定そのものは任意
最大リソースは、仮想コア・メモ
リの明示的な指定の他、パーセ
ント指定も可能
CPUとメモリを別々に指定する
ことも、まとめて指定することも
可能

実行アプリケーションの最大数
sales
たとえリソースが余っていても、実行ア
プリケーションの最大数以上は実行で
きない
設定は個数を指定するだけ
eastjapan
westjapan
sales
最大10アプリ
配下キューの全アプリケーションの実
行数を合算して判定する

最大のアプリケーションマスターシェア
0〜1の間で設定する
-1.0に設定した場合は設定を無効化する
デフォルト0.5
A A A C C C C C C
A
アプリケーションマスター (AM)シェア以上のリソースを
使ってAMを起動することはできない
最大のアプリケーションマスターシェア
※ 挙動の把握が難しいため、基本は実行アプリケーション最大数で
アプリの数を制御すべき
あまりこの設定のチューニングは行うべきではない

アクセス制御リスト
サブミット権限管理者権限
ユーザー tanaka,sato suzuki
グループ sales,ops admin
キューに対するジョブの投入権限現状はジョブのkillのみ可能
ユーザー単位とグループ単位で設定可能ユーザー、グループはカンマ区切りで
複数入力

キュー配置ポリシー

• クラスタにジョブが投入されたときに、自動的に適切なキューに割り当てるための
ルール
• ポリシーの大半は、ユーザ名やグループ名を参照して、それらの名称が含まれる
キューに割り当てるもの
• ユーザ名やグループ名にドットが含まれる場合、 _dot_ に変換される
キュー配置ポリシー

キュー配置ポリシーの一覧 (Cloudera Manager)
ポリシー名説明デフォルト設定における優先順位
root.[キュー名] root.[キュー名]を割り当てる。 --
root.[キュー名].[ユーザ名] root.[キュー名].[ユーザ名] を割り当てる。root.[キュー名]が存在しない場合は無条件
で無視される。
2番目。root.users.[ユーザ名]という
キュー名で指定。
root.[プライマリグループ名] root.[プライマリグループ名]を割り当てる。 --
root.[プライマリグループ名].[ユーザ名] root.[プライマリグループ名].[ユーザ名] を割り当てる。root.[プライマリグループ名]が
存在しない場合は無条件で無視される。
--
root.[セカンダリグループ名] root.[セカンダリグループ名]を割り当てる。セカンダリグループが複数ある場合、先頭
から順に判定する。
--
root.[セカンダリグループ名].[ユーザ名] root.[セカンダリグループ名] .[ユーザ名]を割り当てる。セカンダリグループが複数ある
場合、先頭から順に判定する。
--
root.[ユーザ名] root.[ユーザ名]を割り当てる。ユーザ名にドットが含まれる場合は _dot_ に変換され
る。
--
実行時に指定実行時にキューを割り当てる。実行時に指定していない場合は無視される。 1番目
default root.defaultキューを割り当てる。このポリシーは、設定した場合無条件で適用される。 3番目
reject ジョブの投入を拒否する。このポリシーは明示的に指定できない。他のポリシーの条
件を全て満たさなかった場合、無条件で適用される。
--

• 「プールが存在しない場合に作成しま
す。」というポリシーを指定可能
• 文字通り、存在しないキュー(プール)を
自動作成する
• 新規参加ユーザ・グループの多い組織
で有効
キューの自動作成

プリエンプション

• あるキューで必要なリソースが足りない場合、他のキューで実行されているコンテナ
をkillしてリソースを奪う機能
プリエンプション

• 定常フェアシェア
• 全てのキューのウェイトを加味して計算された
フェアシェア
• 即時フェアシェア
• 現在稼働しているアプリケーションが存在する
キューのみのウェイトで計算されたフェアシェ
ア
• プリエンプションを使う場合はこちらの計算が
必要
定常フェアシェアと即時フェアシェア
root
sales
marketing
datascience
100
30
30
40
定常フェアシェアで計算す
れば、3:3:4の割合でリソー
スが分割される
salesとmarketingにのみア
プリケーションがあるとき、
即時フェアシェアベースで
は30:30 = 1:1でリソースが
分配される

• スタベーション
• リソースが枯渇している状態。スタベーション
しているキューあるいはアプリがあるとプリエ
ンプションが実行される
• 二種類のスタベーション
• フェアシェアスタベーション
• 最小シェアスタベーション
プリエンプションの流れとスタベーション(枯渇)
条件を満たしたリソースキューあるいはアプリケーションが
starved (枯渇) 状態となる
プリエンプション対象のコンテナを検索する
プリエンプションを実行して対象コンテナをkillし、starved ア
プリケーションにリソースを割り当てる

• 以下の条件を満たすと、アプリケーションが
枯渇状態(starved)とみなされる
• アプリケーションがリソース要求を満たしていない
• アプリケーションのリソース使用量が、即時フェア
シェアを下回っている
• アプリケーションのリソース使用量がプリエンプ
ションしきい値を下回っている状態が、プリエンプ
ションタイムアウトよりも長い時間継続する
• プリエンプションしきい値のデフォルトは0.5
• 即時フェアシェアで割り当てられるべきリソースの
50%
• プリエンプションタイムアウトはデフォルトで
未設定
• アプリケーション単位で明示的にタイムアウトを設
定しない限り、デフォルトではプリエンプションは
発生しない
• アプリケーション単位でフェアシェアスタ
ベーションが発生することがある
フェアシェアスタベーション

フェアシェアスタベーションの流れと設定方法
フェアシェアプリエンプションしきい値
タイムアウト
プリエンプション実施。アプリケーショ
ンがkillされる
確保済みリソースがしきい値を下回る
とタイマー起動
条件を満たしたので、キューが枯渇状態 (starved) になり、プリエンプションが開始される
タイムアウト時間は秒で指定
しきい値は0〜1の間
利用可能リソースのパーセンテージ
プリエンプトされたリソースを確保

• 以下の条件を満たすと、アプリケーションが
枯渇状態(starved)とみなされる
• アプリケーションがリソース要求を満たしていない
• アプリケーションのリソース使用量が、最小リソー
スを下回っている
• アプリケーションのリソース使用量が最小リソース
を下回っている状態が、最小共有プリエンプショ
ンタイムアウトよりも長い時間継続する
• 最小リソースのデフォルトは未設定
• プリエンプションタイムアウトはデフォルトで未
設定
• 最小リソースとタイムアウトを設定しない限り、
デフォルトではプリエンプションは発生しない
• フェアシェアスタベーションと異なり、キュー単
位でのみスタベーションが発生
• 最小シェアスタベーションは挙動が複雑なた
め、Clouderaは非推奨。フェアシェアの利用を
推奨
最小シェアスタベーション

最小シェアスタベーションの流れと設定方法
最小リソース
タイムアウト
プリエンプション実施。アプリケーショ
ンがkillされる
確保済みリソースがしきい値を下回る
とタイマー起動
タイムアウト時間は秒で指定
最小リソースは別タブで設定済み
条件を満たしたので、キューが枯渇状態 (starved) になり、プリエンプションが開始される
プリエンプトされたリソースを確保

• 一番リソースが不足しているキューから
優先的に割り当てていく
• 一度優先順位を決定したら、そのキュー
の不足が解決するまで、可能な限りリ
ソースを投入する
• よって、わずかなリソースの投入で充足
可能なキューが、最後までリソース不足
のままとなる
最小シェアスタベーション発生時のリソース割当て優先順位
最小リソース
最小リソース
最小リソース
一番リソースが不足していたため、最
優先でリソースが割当てられる
一番リソースが不足していなかったの
で、割当が後回しにされる

• 枯渇状態のアプリケーションやキューが存
在するとき、以下の条件のコンテナを選択
してkillする
• プリエンプションが許可されたキューのアプリケー
ションのコンテナ
• そのコンテナをkillしても、フェアシェアを下回るこ
とがない
• アプリケーションマスターは、他にkillできる
コンテナがない場合のみプリエンプト対象と
なる
プリエンプションの対象選択
フェアシェア
フェアシェア
フェアシェア
コンテナkill
preemptible = false
フェアシェアを超えた分はプリ
エンプト対象
プリエンプションが不許可のた
めkillされない
フェアシェアを下回っているた
めkillされない
A A A C C C C C C
アプリケーションマスターよりコ
ンテナが先にkillされる

ケーススタディ

要件
• 優先度の高いキューと、ベストエフォー
トで実行するキューの2つを持ちたい
解決策
• 加重(ウェイト)を0.0に設定する
ベストエフォート
high
best_effort
(設定なし)
0
high
best_effort
可能な限りリソースを
確保したい
空いているときだけ使
いたい

ベストエフォート: ケーススタディ
時間イベント
12:00 best_effortキューにジョブB1を投入。必要リソースは100%
12:01 highキューにジョブH1を投入。必要リソースは30%
12:02 B1、完了
highキューにジョブH2を投入。必要リソースは70%
best_effortキューにジョブB2を投入。必要リソースは30%
12:03
12:04 H1、完了
12:05 H2、完了
以下のようなシナリオを考える

ベストエフォート: リソース使用量推移
割当されない
割当開始
highにジョブを投入しても、プリエンプション
の設定がないため、 best_effortからはリ
ソースを奪わない
best_effortに新規にジョブを投
入しても、highのジョブへの割
当が優先される
リソースが余り始めたら、
best_effortへのリソース割り当
てが始まる
ジョブB1投入
ジョブH1投入ジョブB2投入
ジョブH2投入

要件
• 優先度の高いキュー用に、20%のリソー
スを予約しておきたい
解決策
• 通常キュー側のリソース上限を80%に
制限する
• リソース上限はハードリミットなので、結
果的に優先キュー側の20%を予約可能
リソースの予約
high
normal
(設定なし)
リソース上限80%
high
normal
いつでも20%使えるよ
うにしておきたい
残り80%は自由に使
いたい

リソースの予約: ケーススタディ
時間イベント
12:00 normalキューにジョブN1を投入。必要リソースは100%
12:02 H1、完了
normalキューN1の残りタスクに必要な20%を投入
12:03 N1、完了
12:05 H2、完了

リソースの予約: リソース使用量推移
割当されない
割当開始
ハードリミットのため、80%以上の
リソースは使わない
リソースが余り始めたら、normalへ
のリソース割り当てが始まるジョブN1投入
ジョブH1投入
ジョブN2投入
ジョブH2投入
20%は予約されているので、すぐ
にリソース割り当て可能
N1に必要なリソース残り
20%を割り当て
プリエンプションの設定がないため、
highからはリソースを奪わない

要件
• 優先度の低いジョブに割り込んで、優先
度の高いジョブを実行したい
解決策
• フェアシェアプリエンプションを使う
• しきい値100%、タイムアウト1秒に設定すれば、
不足したらすぐにプリエンプションが発生
優先ジョブの割り込み
high
normal
ウェイト75%
プリエンプションしきい値 100%
プリエンプションタイムアウト 1秒
ウェイト25%
high
normal
必要があれば他のジョブ
に割り込みたい
余っていたら自由に使い
たい

優先ジョブの割り込み: ケーススタディ
時間イベント
12:01 highキューにジョブH1を投入。必要リソースは25%。
12:02 プリエンプション発生。N1のジョブのリソースのうち25%がkillされ、H1に割当られる。
12:03 H1、完了
N1、75%完了。ジョブのタスク残り25%を再開。
12:04
12:05 N1、完了

優先ジョブの割り込み: リソース使用量推移
コンテナkill
highキューのリソースが不足している
ため、プリエンプト実行。
25%のコンテナをkill
加重の設定から、75:25でリソースを共有
するようになっている
よってプリエンプションは発生しない
ジョブN1投入
ジョブH1投入
ジョブH2投入
リソースを他のキューか
ら確保して割当
killされた処理を再開

解決策
• 加重(ウェイト)0.0の多段設定
other
mid
other
0.0
low (制限設定なし)
high (制限設定なし)
(制限設定なし)
0.0
要件
• 優先度別の三階層のキューを作りたい
多段優先度キュー
mid
low
highが動いてなければ処
理したい
他が動いていなければ処
理したい
high最優先で処理したい

多段優先度キュー: ケーススタディ
時間イベント
midキューにジョブM1を投入。必要リソースは100%
lowキューにジョブL1を投入。必要リソースは100%
12:01 H1、完了。
M1にリソース割り当て
12:02 M1、完了。
L1にリソース割り当て。
12:03 L1、完了。
H2にリソース割り当て
12:04 H2、完了

多段優先度キュー: リソース使用量推移
ジョブH1、M1、
L1投入
ジョブH2投入
H1にのみリソース
が割当られる
highキューが空に
なったらmidキューに
割当られる
highにジョブを投入しても、プリエンプション
の設定がないため、 lowからはリソースを
奪わない
highとmidキューが空になったらlow
キューに割当られる

解決策
• ウェイトとプリエンプション設定を組み合わせる
要件
• 優先度別の三階層のキューを作りたい
• 最高優先度のキューは他のキューに割り込み
たいが、逆はさせたくない
プリエンプションつき多段優先度キュー
mid
low
highが動いてなければ処理したい
他の処理に割り込みたい
他が動いていなければ処理したい
high最優先で処理したい
他の処理に割り込みたいが、割り込ま
せたくはない
high
ウェイト80%
プリエンプション対象とするのを不許可
mid
ウェイト15%
low ウェイト5%

プリエンプションつき多段優先度キュー: ケーススタディ
時間イベント
12:00 lowキューにジョブL1を投入。必要リソースは100%
midキューにジョブM1を投入。必要リソースは100%
12:02
12:03 highキューのタイムアウト時間(120秒)が経過し、プリエンプション発生。L1のジョブのリソースのうち72%(80% * 90%)がkillされ、H1に割当られる。
12:04 midキューのタイムアウト時間(180秒)が経過し、プリエンプション発生。L1のジョブのリソースのうち12%(15% * 80%)がkillされ、M1に割当られる。
12:05 H1、完了。
highキューに割り当てられていたリソースが、mid、lowのキューに公平に配分される。

プリエンプションつき多段優先度キュー : リソース使用量推移
ジョブH1、L1投
入
highキューが空に
なったらmidキューに
割当られる
highキューが空になったらmidとlowキュー
に15:5の比率で割当られる
ジョブH1、M1
投入
コンテナkill
コンテナkill
highキューのリソースが不足している
ため、プリエンプト実行。
midキューのリソースが不足している
ため、さらにプリエンプト実行。

tips

• キューの削除を明示的に指定する方法はない
• 設定の更新→リフレッシュのタイミングで削除される
• プリエンプションはグローバル設定
• 全てのキューがプリエンプト対象となる
• 拒否する場合は preemptable のチェックを外す
• 小さいクラスタで大規模ジョブを流す場合
• 検証環境や開発環境でのシナリオ
• 動作させるアプリケーション数を制限しておくこと
• アプリケーションマスターがリソース確保しすぎてジョブが終わらなくなり、デッドロックになってしまう
注意点についてのtips

• Untangling Apache Hadoop YARN
• Clouderaの技術ブログシリーズ。本資料はこちらの内容をベースに執筆している
• http://blog.cloudera.com/blog/2015/09/untangling-apache-hadoop-yarn-part-1/
• http://blog.cloudera.com/blog/2016/06/untangling-apache-hadoop-yarn-part-4-fair-scheduler
-queue-basics/
• http://blog.cloudera.com/blog/2017/02/untangling-apache-hadoop-yarn-part-5-using-fairsche
duler-queue-properties/
• http://blog.cloudera.com/blog/2018/06/yarn-fairscheduler-preemption-deep-dive/
参考リンク

Apache Hadoop YARNとマルチテナントにおけるリソース管理

Apache Hadoop YARNとマルチテナントにおけるリソース管理

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Apache Hadoop YARNとマルチテナントにおけるリソース管理

Similar to Apache Hadoop YARNとマルチテナントにおけるリソース管理 (20)

More from Cloudera Japan

More from Cloudera Japan (20)

Apache Hadoop YARNとマルチテナントにおけるリソース管理