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 」風になっているだけで、実際の設備
次第では必ずしも適切とはいえない。
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 となった