Hadoop book-2nd-ch3-update

  • 1,086 views
Uploaded on

Report on HDFS (Hadoop Distributed File System), from "Hadoop, The Definitive Guide (2nd ed.)" published by O'Reilly & Associates.

Report on HDFS (Hadoop Distributed File System), from "Hadoop, The Definitive Guide (2nd ed.)" published by O'Reilly & Associates.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,086
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
14
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Hadoop, The Definitive Guide (2nd edition)読書会資料(第3章 /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 を介する、交換可能なストレージ要素の1つ● 特徴1:ノード故障への耐性● 特徴2:大データ (~TB/node) への連続アクセス● 特徴3: write-once, read-many に特化多数ファイル、低レイテンシ利用、マルチライタは不得意
  • 3. P43-45:HDFS の構成と構造 (1) Name Node ブロック1つ あたり 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,*] DNDN#1 has A[0] #1DN#2 has A[0] A[0,*]DN#3 has A[0] DNDN#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 RoleBackup 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 FileSystempublic 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 #5d=0 #1 #6 #1 #6 #2 #7 #2 #7 #3 #8 #3 #8d=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 Enginecreate+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 - 使用上の注意● デフォルトは1マップで最低 256[MB] をコピー● デフォルトは1ノードに最大 20 マップ(処理)● 使用ノード数を絞るなら -m <# of maps> → マップあたりのコピー量を増やす結果に → ただし、最初のコピーは複製ルールにより マップ処理ノードと同じノードに置かれる。 これ起因のアンバランス配置に注意!● 異バージョン HDFS 間のコピーは不可(非互換) → hftp:// で指定して回避できる → コピー先クラスタ (NN) で実行する必要がある
  • 19. P71-73:HAR – Hadoop ARchive 形式● メタデータの管理(保管)効率向上が目的 → データは元々実サイズ分しか使わない● パックして NameNode 上は「1ファイル」扱い → *.har の位置までのみ NN が管理する● ファイルの増減・変更の際は全体再作成になる注意 これは NameNode での効率の話であって、 MapReduce 処理 段階では、各々の処理( split )に HAR 内の複数ファイルを まとめて食わせられるわけではない。 つまり細かい Map タスクが多量に発生するオーバーヘッドは 回避できない。別の対策に CombineFileInputFormat クラスを 用いて、入力データを集約する方法があるので要参照。