Movatterモバイル変換

© 2017 NTT DATA Corporation 7Hadoop Distributed File System大きなファイル(100+MB)の格納に最適化分散処理フレームワークに高スループットなデータアクセスを提供ファイルシステムとしての機能を提供階層的な名前空間(ファイルとディレクトリ)ファイルデータの読み書きパーミッションによるアクセス制御quotaシンボリックリンクは未サポート一度追加されたが色々問題があることが分かりdisabledにソースコード上に実装は残っているxfsやext4などのネイティブファイルシステムの上(ユーザ空間)で動くPOSIX準拠ではないHDFSとは何か

© 2017 NTT DATA Corporation 8NameNode:メタデータを管理するマスターファイルとブロックとの対応関係を管理:fsimageとして永続化レプリカとそれを保持するDataNodeとの対応を関係管理:ブロックレポートで更新されるメモリ上のみの情報DataNode:データブロック(レプリカ)を格納するスレーブNameNodeに対して定期/不定期でレポート送信クライアント:まずNameNodeにリクエスト送信指定されたDataNodeに接続してデータを読み書きHDFSのアーキテクチャNameNodeDataNodeDataNodeDataNodeDataNode

© 2017 NTT DATA Corporation 9データ保全性と可用性データは自動的に冗長化されるノード故障で低下した冗長度は自動的に回復されるラックを跨ぐようなデータの配置戦略(rack awareness)ノードダウン時にもクライアントが透過的にリトライ/リカバリ分散処理フレームワークにデータローカリティを提供データを持ってきて処理するのではなく処理をデータのある場所に持っていくメタデータを1箇所(NameNode)で管理することによる一貫性ただしNameNodeがスケーラビリティのボトルネックになるとはいえスレーブ数千台くらいはいけるただしNameNodeがSPOFになりうるなのでActive-Standby型のHA構成をビルトインでサポートHDFSの特徴

© 2017 NTT DATA Corporation 10クライアントからNameNodeにブロック割り当てリクエスト指定されたDataNodeに対して書き込みパイプライン構築DataNodeからNameNodeにブロック情報を報告IBR: Incremental Block Reportブロック書き込み開始時/書き込み完了時/sync要求受信時レポートを受けてNameNode上のブロック情報が状態遷移HDFSのデータ書き込みの流れDataNodeNameNodeDataNodeClientDataNodewriteackwritereport1. addBlockLocatedBlock2. writeBlockackack

© 2017 NTT DATA Corporation 12Active NNはメタデータの更新(edits)をJournalNodeのquorumに送るStandby NNはそれをtailして再生クライアントはActiveにアクセスできなければ透過的にStandbyに接続ファイルの書き込みロック払い出し情報もStandby側に伝搬する以下のような状況にも対応1. クライアントAがNameNode 1にファイル書き込みオープン要求2. NameNode 1からNameNode 2にフェールオーバ3. クライアントAがNameNode 2にファイルのcloseを要求hadoop-3.0.0からはStandby NameNodeを複数持てるようになるNameNode HAJournalNodeNameNode(Active)JournalNodeNameNode(Standby)JournalNodejournal getJournal

© 2017 NTT DATA Corporation 14Hadoopが提供するファイルシステムにアクセスするためのAPIHDFS以外のバックエンドにも透過的にアクセスできるように抽象化(基本的にはHDFSにできる範囲の機能を提供)ビルトインで付いてくる実装もいろいろ:LocalFileSystemDistributedFileSystemS3AFileSystemNativeAzureFileSystemAdlFileSystemSwiftNativeFileSystemAliyunOSSFileSystem...FileSystem#getで各実装のインスタンスを取得URLのschemeで使い分けられるfile://..., hdfs://..., s3a://..., ...各インスタンスは重量級なのでキャッシュされて使い回されるHadoop FileSystem API

© 2017 NTT DATA Corporation 15ファイル一覧(ls)FileStatus[]を返すFileStatusにはファイルの情報が格納されている(e.g. サイズ、所有者)FileSystem#listStatuspublic class FileStatus implements Writable, Comparable<Object>,Serializable, ObjectInputValidation {private static final long serialVersionUID = 0x13caeae8;private Path path;private long length;private Boolean isdir;private short block_replication;private long blocksize;private long modification_time;private long access_time;private FsPermission permission;private String owner;private String group;private Path symlink;private Set<AttrFlags> attr;...

© 2017 NTT DATA Corporation 16ファイル一覧(ls)の派生RemoteIterator<LocatedFileStatus>を返すLocatedFileStatusから各データブロックを持つノードがわかるフレームワークはタスクをブロックを持っているノードに割り当てネットワークIOなしで処理できる => データローカリティBlockLocationが意味を持つかはFileSystem実装によるFileSystem#listLocatedStatuspublic class LocatedFileStatus extends FileStatus {private static final long serialVersionUID = 0x17339920;private BlockLocation[] locations;...

© 2017 NTT DATA Corporation 17書き込みopeno.a.h.fs.FSDataOutputStreamが返るFSDataOutputStream#writeで書き込みFSDataOutputStream#closeでクローズSee also o.a.h.fs.CreateFlagFileSystem#createpublic void write(byte b[], int off, int len) throws IOException {

© 2017 NTT DATA Corporation 18書き込み再openo.a.h.fs.FSDataOutputStreamが返るHDFSでは一度書かれたデータを上書き更新することはできないだが、ファイル末尾への追記はできる(ようになった)HDFSの場合:データブロックを持っているDataNodeに対してパイプライン再構築実装直後はバグが多く、使わないほうが無難なAPIだったcatで済むならそのほうがよいS3の場合:Not supportedFileSystem#append

© 2017 NTT DATA Corporation 19読み込みopeno.a.h.fs.FSDataInputStreamが返るFSDataInputStream#readでデータを読むHDFSの場合:任意の場所を読めるスレッドセーフなpositional readありopen時点でvisibleなところまでしかreadできない他のプロセスがwriteする内容をtailingしたい場合に問題例: HBaseのレプリケーション機能: WAL(HLog)をtailingして送信解: 末尾まで読んだらファイルをopenしなおすFileSystem#openpublic int read(long position, byte[] buffer, int offset, int length)throws IOException {

© 2017 NTT DATA Corporation 20ファイルやディレクトリの名前変更(mv)HDFSの場合:atomicな操作ジョブのoutputをcommit処理としてrenameが使われる::$ hdfs dfs mv 00001.out.tmp 00001.out他のクライアント、後続ジョブに中途半端な状態を見せないS3の場合:別の名前にコピーして、元のオブジェクトを削除ディレクトリのrenameは、上記の繰り返しFileSystem#rename

© 2017 NTT DATA Corporation 24HDFSへのアクセスを提供HDFS固有の機能もあるクラスタ内のノードへのアクセスを抽象化エラーに対してもクライアント内部で自動的にリカバリ/リトライNameNodeが落ちたらstandby側にリトライDataNodeが落ちたら:読み込み中: 同一レプリカを持つ別ノードにリトライ書き込み中: パイプライン上のノードを入れ替えてリトライDistributedFileSystem extends FileSystem

© 2017 NTT DATA Corporation 25fsyncに相当(closeせずに)writeしたデータの書き込みを確定させるFSDataOutputStream#hflush:パイプライン上の全DataNodeがデータを受け取ったらreturnFSDataOutputStream#hsync:パイプライン上の全DataNodeでfsyncしてからreturnユースケース: HBaseのWAL(HLog)書き込みWALエントリの書き込みを確定してからクライアントに成功を返すhflush/hsync

© 2017 NTT DATA Corporation 26dfs.datanode.synconcloseデフォルト設定はfalse:HDFSはファイルのsyncをOSに任せるHDFS的にファイルをcloseしてもsyncされないパイプライン上の全DNがsync前に電源断 => データロストtrueにするとclose時にfsyncデータセンター障害的な状況で整合性を保つために使えるdfs.datanode.sync.behind.writessyncをOSに任せると、書き込みレイテンシにムラが出る書き込んだデータをこまめにsyncすることでレイテンシを平滑化データストア(e.g. HBase)のバックエンドとして使う場合に有用Linuxのsync_file_rangeシステムコールを利用ディスクアクセスの制御

© 2017 NTT DATA Corporation 27dfs.datanode.drop.cache.behind.{reads|writes}ブロックファイルをOSのキャッシュから積極的に消すLinuxのposix_fadviseシステムコールを利用でも、DataNode単位では使いにくいストリーム単位での調整もできるFSDataInputStream#setDropBehindFSDataInputStream#setReadaheadFSDataOutputStream#setDropBehindキャッシュ戦略のチューニング

© 2017 NTT DATA Corporation 29データローカリティがあってもDataNode経由でreadすると無駄があるDataNodeがファイルからreadクライアントにソケット経由で送信クライアントがブロックファイルを直接readできると高効率しかしローカルファイルを直接openできるとアクセス制御がきかないShort Cirtcuit Local Readの仕組み:パーミッションのチェックをNameNodeで行うDataNodeからopen済みのfdをクライアントに渡す:Linuxのsendmsg/recvmsgシステムコールを利用Short Circuit Local Read

© 2017 NTT DATA Corporation 30Javaから直接使えない機能をCで書いてJNIで呼び出すここで紹介した機能の多くはnativeライブラリが前提コミュニティ版を使う場合、自分でビルドしたほうがよいかも::$ mvn package -Pnative -Pdist -Dtar -DskipTestschecknativeコマンドでライブラリが利用可能かチェックできるnativeライブラリ(libhadoop.so)$ hadoop checknativeNative library checking:hadoop: true /path/to/hadoop/lib/native/libhadoop.so.1.0.0zlib: true /lib64/libz.so.1snappy: falselz4: true revision:10301bzip2: true /lib64/libbz2.so.1openssl: true /lib64/libcrypto.so

© 2017 NTT DATA Corporation 33Amazon S3をバックエンドとするFileSystem実装S3FileSystem, NativeS3FileSystemの後継Hadoop on Cloudを使う場合の低コストなデータ保存場所として便利ファイルはオブジェクトに対応づけられるS3にディレクトリという概念はない"mkdir /foo/bar" => /foo/bar/ というキーで空オブジェクトを作成S3にrenameという概念はないオブジェクトを別の名前でコピーして、コピー元を消す"mv /dir1 /dir2" => /dir1/* なキーを持つオブジェクトを全コピーeventual consistencyファイルを作成した直後にlsすると見えないことがあるdeleteしたファイルがしばらく見えることがあるS3AFileSystem extends FileSystem

© 2017 NTT DATA Corporation 35EMRのHBaseのデータディレクトリをS3上に置くhttp://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hbase-s3.htmlデータディレクトリと独立にWALディレクトリを設定することで実現(HBASE-17437)hbase.root.dir: on S3hbase.wal.dir: on HDFSEMRFSが前提HBase on Amazon S3

© 2017 NTT DATA Corporation 36HDFSのパーツでオブジェクトストレージを作る試み特にブロックコンテナとしてのDataNodeNameNodeは以下の2つのモジュールが密結合FSNameSystem: メタデータ(inode)を管理BlockManager: ブロックレプリカを管理キー空間とコンテナの対応づけだけならスケールアウトしやすいブロックメタデータはDataNode側で持ち、RAFTで冗長化HDFS-7240ブランチでアクティブに開発されている果たしてマージできるのかOzone (HDFS-7240)

© 2017 NTT DATA Corporation 38HDFSはファイルシステムのセマンティクスを提供データローカリティを活かした高スループットな分散処理の基盤スループットだけではなくレイテンシもそれなりに追求HBaseのようなデータストアのバックエンドとしても使えるFileSystem APIを使えばバックエンドを透過的に切り替え可能オブジェクトストアその他とうまく使い分けるとよい今回紹介できなかったHDFSならではの機能は他にもいろいろTransparent EncryptionExtended AttributesStorage PoliciesErasure CodingSummary

Movatterモバイル変換

Change Language

HDFS basics from API perspective

Embed presentation

Recommended

More Related Content

What's hot

Similar to HDFS basics from API perspective

More from NTT DATA OSS Professional Services

HDFS basics from API perspective