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

What's hot

Similar to Hadoop book-2nd-ch3-update

More from Taisuke Yamada

Hadoop book-2nd-ch3-update

• 1.
  Hadoop, The DefinitiveGuide (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,*] 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 classHogeFileSystem 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 - 使用上の注意● デフォルトは１マップで最低 256[MB] をコピー● デフォルトは１ノードに最大 20 マップ（処理）● 使用ノード数を絞るなら -m <# of maps> → マップあたりのコピー量を増やす結果に → ただし、最初のコピーは複製ルールにより マップ処理ノードと同じノードに置かれる。 これ起因のアンバランス配置に注意！● 異バージョン HDFS 間のコピーは不可（非互換） → hftp:// で指定して回避できる → コピー先クラスタ (NN) で実行する必要がある
• 19.
  P71-73:HAR – HadoopARchive 形式● メタデータの管理（保管）効率向上が目的 → データは元々実サイズ分しか使わない● パックして NameNode 上は「１ファイル」扱い → *.har の位置までのみ NN が管理する● ファイルの増減・変更の際は全体再作成になる注意 これは NameNode での効率の話であって、 MapReduce 処理 段階では、各々の処理（ split ）に HAR 内の複数ファイルを まとめて食わせられるわけではない。 つまり細かい Map タスクが多量に発生するオーバーヘッドは 回避できない。別の対策に CombineFileInputFormat クラスを 用いて、入力データを集約する方法があるので要参照。