Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Hadoop, The Definitive Guide (2nd edition)読書会資料(第3章 /HDFS )          担当: @tyamadajp
P41-42:HDFS と適用領域       Hadoop System                                 データの分散保管と         MapReduce Engine        コード配布+計算要求...
P43-45:HDFS の構成と構造 (1)             Name Node             ブロック1つ                                   あたり 64+[MB]             ...
P43-45:HDFS の構成と構造 (2)             Name Node                       64[KB] ずつ、                                             ...
P43-45:HDFS の構成と構造 (3)                Name Node                                 A[0,*]                            DNDN#1 h...
P45:NameNode の役割・課題役割●  File<->[Block], Block<->[DN] の対応管理● DN からの Block report および heartbeat の受付● Client からの FS op/RPC のエ...
P45:NameNode の冗長(?)化                                    NN /w                                CheckPoint Role Name Node    ...
P45-47: 基本操作方法●   基本は「 hadoop fs -<op> 」で操作。    詳しくは本を。あと hadoop fs だけでヘルプが●    扱える「ファイル」は「 scheme:... 」の URI で    指定してローカ...
P48:org.apache.hadoop.fs.FileSystem    URI scheme に対応する FS API の実装クラスを    登録すれば、任意のデータストアが組込可能組込方法 – hoge:// scheme の場合●  ...
P48:Extending FileSystempublic class HogeFileSystem extends FileSystem {  public void  initialize(URI uri, Configuration c...
P49-50:Available Interfaces低レベルアクセス           Hadoop FS API を叩いている場合は● Java API          HDFS 以外にも利用できなくもない● Thrift RPC (形...
P51-62:Using Java API   ひたすらコードが続くので、この部分は本文参照。   要点は   ●   URLStreamHandlerFactory を登録し URL.* API を       使う方法があるが、廃止。毎回 ...
P63:Java API とノード構成の関係        掲載図以上にわかりやすい表現がないのでほぼ同じ図…client node JVM                                  ②get block locatio...
P64: ノードトポロジと「距離」概念ノード間距離 d を元に NN は DN を管理・制御する                          d=6               R                       R     ...
P65-67: トポロジに基づく書込処理               R            まず性能のため                            最大のローカリティが                            得...
P68-69: バッファリングと同期          client                             out.flush()             A              stat             A →...
P70:distcp - MapReduce と並列転送やりたいこと: cp             src#0 src#1 src#2     dst#0 dst#1 dst#2         getloc(src)  NN        ...
P70:distcp - 使用上の注意●   デフォルトは1マップで最低 256[MB] をコピー●   デフォルトは1ノードに最大 20 マップ(処理)●    使用ノード数を絞るなら -m <# of maps>    → マップあたりのコ...
P71-73:HAR – Hadoop ARchive 形式●   メタデータの管理(保管)効率向上が目的    → データは元々実サイズ分しか使わない●   パックして NameNode 上は「1ファイル」扱い    → *.har の位置ま...
Upcoming SlideShare
Loading in …5
×

Hadoop book-2nd-ch3-update

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

  • Be the first to comment

Hadoop book-2nd-ch3-update

  1. 1. Hadoop, The Definitive Guide (2nd edition)読書会資料(第3章 /HDFS ) 担当: @tyamadajp
  2. 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. 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. 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. 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. 6. P45:NameNode の役割・課題役割● File<->[Block], Block<->[DN] の対応管理● DN からの Block report および heartbeat の受付● Client からの FS op/RPC のエントリポイント #負荷は軽い( 10Knode/68PB でも 1 台の試算)データ管理・運用に課題● 対応表が消える=全データ消滅だが SPoF 稼動● ジャーナリング方式でデータ管理されている ◚ しかし、マージは再起動の時(=遅い)
  7. 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. 8. P45-47: 基本操作方法● 基本は「 hadoop fs -<op> 」で操作。 詳しくは本を。あと hadoop fs だけでヘルプが● 扱える「ファイル」は「 scheme:... 」の URI で 指定してローカル・リモートの各所を指定 ◚ 今回の HDFS だと hdfs://host/path で● 簡易的な UNIX-style user/group+rwx ACL あり マルチユーザ運用のためなのでオフにもできる 細かくプレゼン資料にする程ではないので軽く飛ばします
  9. 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. 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. 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. 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. 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. 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. 15. P65-67: トポロジに基づく書込処理 R まず性能のため 最大のローカリティが 得られるノードに書く 次に冗長化のため、別 client DN DN ラックのノードに複製 最後に冗長度の更なる 確保のため、ラック内 DN 別ノードに再複製複製が dfs.replication.min 個に達した時点で書込完了 ACK は飛ぶ。その後 dfs.replication 個まで内部で複製を増やす動作になる。複製エラー時は、正常ノード側の BlockID の付け替えを行い NN に通知する。すると複製数不足が検知され追加複製トリガが引かれる
  16. 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. 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. 18. P70:distcp - 使用上の注意● デフォルトは1マップで最低 256[MB] をコピー● デフォルトは1ノードに最大 20 マップ(処理)● 使用ノード数を絞るなら -m <# of maps> → マップあたりのコピー量を増やす結果に → ただし、最初のコピーは複製ルールにより マップ処理ノードと同じノードに置かれる。 これ起因のアンバランス配置に注意!● 異バージョン HDFS 間のコピーは不可(非互換) → hftp:// で指定して回避できる → コピー先クラスタ (NN) で実行する必要がある
  19. 19. P71-73:HAR – Hadoop ARchive 形式● メタデータの管理(保管)効率向上が目的 → データは元々実サイズ分しか使わない● パックして NameNode 上は「1ファイル」扱い → *.har の位置までのみ NN が管理する● ファイルの増減・変更の際は全体再作成になる注意 これは NameNode での効率の話であって、 MapReduce 処理 段階では、各々の処理( split )に HAR 内の複数ファイルを まとめて食わせられるわけではない。 つまり細かい Map タスクが多量に発生するオーバーヘッドは 回避できない。別の対策に CombineFileInputFormat クラスを 用いて、入力データを集約する方法があるので要参照。

×