Hadoop book-2nd-ch3-update
2 likes•1,137 views
Report on HDFS (Hadoop Distributed File System), from "Hadoop, The Definitive Guide (2nd ed.)" published by O'Reilly & Associates.
![P43-45:HDFS の構成と構造 (1)
Name Node ブロック１つ
あたり 64+[MB]
#0
DN 1
#1 2 もう最近は
128[MB] に
client
#0
DN 1
「 N バイトのファイル
#2 2
A の 0-64MB 部分を
書き込みたい」
「なら ID:XXX で DN#1 #0
->2->3 に書くように」 DN 1
#3 2
● ファイルは 64+[MB] ブロック単位で分散保持
● サイズはシーク処理が 1% に収まる程度に決める](https://image.slidesharecdn.com/hadoop-book-2nd-ch3-update-110219100728-phpapp01/85/Hadoop-book-2nd-ch3-update-3-320.jpg)
![P43-45:HDFS の構成と構造 (2)
Name Node 64[KB] ずつ、
ブロックが
ACK A[0,*] 埋まるまで転送
DN
#1
client
ACK
A[0,*]
「 #1->2->3 の流れで DN
A[0,0](64KB 分 ) を #2 ブロック毎に
ID:XXX で書きたい」 違う DN 群が
「書き込み完了。 ACK 」 ACK
A[0,*] NN に選ばれる。
・・・ DN 左図は A[1] に
「 A[0,N] を書きたい」 A[1,*]
「書き込み完了。 ACK 」
#3 ついても DN#3 が
選ばれた場合。
●
ブロック毎に別の DN 群が書き込み先となる
●
書き込みプロセスから NN は完全に分離される](https://image.slidesharecdn.com/hadoop-book-2nd-ch3-update-110219100728-phpapp01/85/Hadoop-book-2nd-ch3-update-4-320.jpg)
![P43-45:HDFS の構成と構造 (3)
Name Node
A[0,*]
DN
DN#1 has A[0]
#1
DN#2 has A[0]
A[0,*]
DN#3 has A[0] DN
DN#3 has A[1] #2
A[0,*]
DN A[1,*]
#3
●
DN は NN に書込完了後に block report を送信
●
NN は File A <-> BlockID の対応表と上を合成](https://image.slidesharecdn.com/hadoop-book-2nd-ch3-update-110219100728-phpapp01/85/Hadoop-book-2nd-ch3-update-5-320.jpg)
![P45:NameNode の役割・課題
役割
●
File<->[Block], Block<->[DN] の対応管理
● DN からの Block report および heartbeat の受付
● Client からの FS op/RPC のエントリポイント
＃負荷は軽い（ 10Knode/68PB でも 1 台の試算）
データ管理・運用に課題
● 対応表が消える＝全データ消滅だが SPoF 稼動
●
ジャーナリング方式でデータ管理されている
◚ しかし、マージは再起動の時（＝遅い）](https://image.slidesharecdn.com/hadoop-book-2nd-ch3-update-110219100728-phpapp01/85/Hadoop-book-2nd-ch3-update-6-320.jpg)
![P48:Extending FileSystem
public class HogeFileSystem extends FileSystem {
public void
initialize(URI uri, Configuration conf) throws IOException {
super.initialize(uri, conf);
setConf(conf); ダミーで書く程度なら赤字の
} メソッドだけ書けば簡単
public URI getUri() { … }
public FSDataInputStream open(Path file, int bufferSize) …
public FSDataOutputStream create(Path file, …
public FSDataOutputStream append(Path file, …
public boolean rename(Path src, Path dst) …
public boolean delete(Path file) 自前の *OutputStream 書いて
…
public boolean delete(Path file, booolean recursive) …
block report 送ったりさせる
public boolean mkdirs(Path file, 必要もあるかも（未検証）
…
public FileStatus[] listStatus(Path file) ...
public FileStatus[] getFileStatus(Path file) …
public void setWorkingDirectory(Path newDir) { … }
public Path getWorkingDirectory() { … }](https://image.slidesharecdn.com/hadoop-book-2nd-ch3-update-110219100728-phpapp01/85/Hadoop-book-2nd-ch3-update-10-320.jpg)
![P70:distcp - 使用上の注意
● デフォルトは１マップで最低 256[MB] をコピー
● デフォルトは１ノードに最大 20 マップ（処理）
●
使用ノード数を絞るなら -m <# of maps>
→ マップあたりのコピー量を増やす結果に
→ ただし、最初のコピーは複製ルールにより
マップ処理ノードと同じノードに置かれる。
これ起因のアンバランス配置に注意！
●
異バージョン HDFS 間のコピーは不可（非互換）
→ hftp:// で指定して回避できる
→ コピー先クラスタ (NN) で実行する必要がある](https://image.slidesharecdn.com/hadoop-book-2nd-ch3-update-110219100728-phpapp01/85/Hadoop-book-2nd-ch3-update-18-320.jpg)
Hadoop book-2nd-ch3-update
- 1. Hadoop, The Definitive Guide (2nd edition) 読書会資料（第３章 /HDFS ） 担当： @tyamadajp
- 2. P41-42:HDFS と適用領域 Hadoop System データの分散保管と MapReduce Engine コード配布＋計算要求 ブロック保有 ノードの照会 Code Code FS API +Data +Data HDFS Name Data Data local fs, S3 なども使用可 Node Node Node ● API を介する、交換可能なストレージ要素の１つ ● 特徴１：ノード故障への耐性 ● 特徴２：大データ (~TB/node) への連続アクセス ● 特徴３： write-once, read-many に特化 多数ファイル、低レイテンシ利用、マルチライタは不得意
- 3. P43-45:HDFS の構成と構造 (1) Name Node ブロック１つ あたり 64+[MB] #0 DN 1 #1 2 もう最近は 128[MB] に client #0 DN 1 「 N バイトのファイル #2 2 A の 0-64MB 部分を 書き込みたい」 「なら ID:XXX で DN#1 #0 ->2->3 に書くように」 DN 1 #3 2 ● ファイルは 64+[MB] ブロック単位で分散保持 ● サイズはシーク処理が 1% に収まる程度に決める
- 4. P43-45:HDFS の構成と構造 (2) Name Node 64[KB] ずつ、 ブロックが ACK A[0,*] 埋まるまで転送 DN #1 client ACK A[0,*] 「 #1->2->3 の流れで DN A[0,0](64KB 分 ) を #2 ブロック毎に ID:XXX で書きたい」 違う DN 群が 「書き込み完了。 ACK 」 ACK A[0,*] NN に選ばれる。 ・・・ DN 左図は A[1] に 「 A[0,N] を書きたい」 A[1,*] 「書き込み完了。 ACK 」 #3 ついても DN#3 が 選ばれた場合。 ● ブロック毎に別の DN 群が書き込み先となる ● 書き込みプロセスから NN は完全に分離される
- 5. P43-45:HDFS の構成と構造 (3) Name Node A[0,*] DN DN#1 has A[0] #1 DN#2 has A[0] A[0,*] DN#3 has A[0] DN DN#3 has A[1] #2 A[0,*] DN A[1,*] #3 ● DN は NN に書込完了後に block report を送信 ● NN は File A <-> BlockID の対応表と上を合成
- 6. P45:NameNode の役割・課題 役割 ● File<->[Block], Block<->[DN] の対応管理 ● DN からの Block report および heartbeat の受付 ● Client からの FS op/RPC のエントリポイント ＃負荷は軽い（ 10Knode/68PB でも 1 台の試算） データ管理・運用に課題 ● 対応表が消える＝全データ消滅だが SPoF 稼動 ● ジャーナリング方式でデータ管理されている ◚ しかし、マージは再起動の時（＝遅い）
- 7. P45:NameNode の冗長（？）化 NN /w CheckPoint Role Name Node ※metadata+journal を吸い出して マージし、書き戻す。 NN の metadata journal が空に戻って再起動が table 高速化する journal blockmap ※ ジャーナルの NN /w 複製先として登録 Backup Role Backup Role の登場で復旧可能には merged なったが、 blockmap 再作成＝全 DN metadata 問合せが必要で failover はできない。 table クラスタ構成で稼動できるように journal 改良予定（ HDFS 論文 , 2010 より） ※ こちらをマスタとして NTT-D で Kemari 使って冗長構成組んでるとか 再起動すれば復旧可能
- 8. P45-47: 基本操作方法 ● 基本は「 hadoop fs -<op> 」で操作。 詳しくは本を。あと hadoop fs だけでヘルプが ● 扱える「ファイル」は「 scheme:... 」の URI で 指定してローカル・リモートの各所を指定 ◚ 今回の HDFS だと hdfs://host/path で ● 簡易的な UNIX-style user/group+rwx ACL あり マルチユーザ運用のためなのでオフにもできる 細かくプレゼン資料にする程ではないので軽く飛ばします
- 9. P48:org.apache.hadoop.fs.FileSystem URI scheme に対応する FS API の実装クラスを 登録すれば、任意のデータストアが組込可能 組込方法 – hoge:// scheme の場合 ● *.FileSystem の拡張クラスを実装する ● core-site.xml に以下を追加する <property> <name>fs.hoge.impl</name> <value>test.HogeFileSystem</value> </property> ● hogefs.jar を hadoop の参照 classpath に追加 ● hadoop コマンドでは -libjars ... を追加
- 10. P48:Extending FileSystem public class HogeFileSystem extends FileSystem { public void initialize(URI uri, Configuration conf) throws IOException { super.initialize(uri, conf); setConf(conf); ダミーで書く程度なら赤字の } メソッドだけ書けば簡単 public URI getUri() { … } public FSDataInputStream open(Path file, int bufferSize) … public FSDataOutputStream create(Path file, … public FSDataOutputStream append(Path file, … public boolean rename(Path src, Path dst) … public boolean delete(Path file) 自前の *OutputStream 書いて … public boolean delete(Path file, booolean recursive) … block report 送ったりさせる public boolean mkdirs(Path file, 必要もあるかも（未検証） … public FileStatus[] listStatus(Path file) ... public FileStatus[] getFileStatus(Path file) … public void setWorkingDirectory(Path newDir) { … } public Path getWorkingDirectory() { … }
- 11. P49-50:Available Interfaces 低レベルアクセス Hadoop FS API を叩いている場合は ● Java API HDFS 以外にも利用できなくもない ● Thrift RPC （形態： Client ↔ Thrift Server ↔ Java API ） ● libhdfs/C （形態： Client ↔ C ↔ JNI ↔ Java API ） 高レベルアクセス ● FUSE （形態： Fuse-DSF ↔ libhdfs ↔ ... ） ● WebDAV （開発中） （形態： WebDAV Server ↔ Java API ） ● HTTP/XML （形態： XML-generating Web server ↔ Java API ） ● FTP （開発中）
- 12. P51-62:Using Java API ひたすらコードが続くので、この部分は本文参照。 要点は ● URLStreamHandlerFactory を登録し URL.* API を 使う方法があるが、廃止。毎回 abs URL が必要、 異 scheme 間の操作で問題があるなどした ● カレント URI を FileContext で定め、そこを起点に 操作する方法が新方式 ● 直接 FS API を利用する方法は維持されている ● FS*Stream の Seekable, PositionedReable, Progressable インタフェースを活用すると、 効率のよい読み出しや進行通知ができる。 ● また、 globStatus API では PathFilter を使い glob 指定での一部ファイルの stat 相当が可能 ● FS API は概ね POSIX 風
- 13. P63:Java API とノード構成の関係 掲載図以上にわかりやすい表現がないのでほぼ同じ図… client node JVM ②get block location ①open Name HDFS ③readDFS (metadata) API Node client FSData*Stream API ⑥close 近い方から読むが 故障時には自動切替 スライド 4 枚目に前述だが、 ④read ⑤read メタデータ系とデータ系 API で 参照先ノードが完全に分かれる。 Data Data Data Node Node Node 図にはないが、各 API の下側に HDFS の実装クラスが入り、実 ノードアクセスを担当する。
- 14. P64: ノードトポロジと「距離」概念 ノード間距離 d を 元に NN は DN を 管理・制御する d=6 R R DC: A d=4 DC: B #0 #5 #0 #5 d=0 #1 #6 #1 #6 #2 #7 #2 #7 #3 #8 #3 #8 d=2 #4 #9 #4 #9 デフォルトでは全ノードが等距離な構成と見なすので、適切に NN に制御させるには設備 / 遅延 / 帯域を見て距離 d を調整する。 上の d は「ホップ数 +1 」風になっているだけで、実際の設備 次第では必ずしも適切とはいえない。
- 15. P65-67: トポロジに基づく書込処理 R まず性能のため 最大のローカリティが 得られるノードに書く 次に冗長化のため、別 client DN DN ラックのノードに複製 最後に冗長度の更なる 確保のため、ラック内 DN 別ノードに再複製 複製が dfs.replication.min 個に達した時点で書込完了 ACK は飛ぶ。 その後 dfs.replication 個まで内部で複製を増やす動作になる。 複製エラー時は、正常ノード側の BlockID の付け替えを行い NN に 通知する。すると複製数不足が検知され追加複製トリガが引かれる
- 16. P68-69: バッファリングと同期 client out.flush() A stat A → block full までは メタデータのみ反映 writing B → 未反映 C → 反映（ A と同様） 書込完了 書込中 out.hflush() block#0 block#1 A → 全て反映 B → 未反映 read open C → 全て反映 (new reader) out.hsync() client client A → 全て反映 B C B → 全て反映 C → 全て反映 ブロックの状態は A/B/C からどう見える？ ※ なお、 sync （ =~hflush ）は ヒント： NOT POSIX deprecated API となった
- 17. P70:distcp - MapReduce と並列転送 やりたいこと： cp src#0 src#1 src#2 dst#0 dst#1 dst#2 getloc(src) NN MapReduce Engine create+ getloc(dst) cp src#0 dst#0 cp src#1 dst#1 cp src#2 dst#2 dst#0 dst#1 dst#2 Data Nodes ※ ただし DFS 系の間でのみ。コピー元も分散保持していないと IO ボトルネックで並列処理しても性能が全く出ない（はず）
- 18. P70:distcp - 使用上の注意 ● デフォルトは１マップで最低 256[MB] をコピー ● デフォルトは１ノードに最大 20 マップ（処理） ● 使用ノード数を絞るなら -m <# of maps> → マップあたりのコピー量を増やす結果に → ただし、最初のコピーは複製ルールにより マップ処理ノードと同じノードに置かれる。 これ起因のアンバランス配置に注意！ ● 異バージョン HDFS 間のコピーは不可（非互換） → hftp:// で指定して回避できる → コピー先クラスタ (NN) で実行する必要がある
- 19. P71-73:HAR – Hadoop ARchive 形式 ● メタデータの管理（保管）効率向上が目的 → データは元々実サイズ分しか使わない ● パックして NameNode 上は「１ファイル」扱い → *.har の位置までのみ NN が管理する ● ファイルの増減・変更の際は全体再作成になる 注意 これは NameNode での効率の話であって、 MapReduce 処理 段階では、各々の処理（ split ）に HAR 内の複数ファイルを まとめて食わせられるわけではない。 つまり細かい Map タスクが多量に発生するオーバーヘッドは 回避できない。別の対策に CombineFileInputFormat クラスを 用いて、入力データを集約する方法があるので要参照。