HDFS Deep Dive

© Hortonworks Inc. 2011 – 2015. All Rights Reserved
HDFS Deep Dive
Yifeng Jiang
Solutions Engineer, Hortonworks, inc.
March 29, 2015

自己紹介
蒋　逸峰 (Yifeng Jiang)
•  Solutions Engineer @ Hortonworks Japan
•  HBase book author
•  ⽇日本に来て１０年年経ちました…
•  趣味は⼭山登り
•  Twitter: @uprush

アジェンダ
•  HDFSのガチな内容
•  Erasure Code in HDFS
•  Hadoop on EC2 少し深堀り

JAWSUG DAYS 2015
http://goo.gl/9ZjNoh

HDFSのガチな内容
Architecture, Erasure Code
Page 5

What is HDFS?
•  Hadoop Distributed File System
•  分散ファイルシステム
•  ⾼高い安定性、可⽤用性、スループット
•  データローカリティ
•  めっちゃスケールできる: 数千台クラスタの実績

HDFSの主要な新機能
•  Namenode HA
•  スナップショット
•  Tiered Storage
•  HDFS NFS Gateway
•  たくさんのPerformance改善
–  DataNode cache, short circuit local read, etc.
•  Erasure Code (WIP)

HDFS Architecture

Namenode
•  In-‐‑‒memory ﬁle system
–  Directory
–  File
–  FSのメタデータ処理理: mkdir, rm, …
•  Edit log
•  Checkpoint
•  Block管理理

Datanode
•  実際のデータ（block）を保存
–  ローカルFS上に保存
–  dfs/data/current/…/blk_̲1073741825
•  Namenodeとやり取り

NamenodeとDatanodeのやり取り
•  ストレージレポート
–  ディスクのタイプ、利利⽤用率率率
•  Heart beat
–  死活管理理
–  NNがレスポンスにコマンドを送る。
o  例例：block削除
•  Block report: のちほど詳しく
DN1 DN2
Namenode
I am alive
Delete blk1

Files & Blocks
•  Fileはblocksとして保存されます
–  /home/yifeng/foo.txt: {b1, b2, b3}
•  BlockはDatanodeに分散して保存
–  同じblockは３つのDNに複製
–  Block sizeは初期値128MB
•  Blockの配置は重要
–  データローカリティ
–  対障害
/home/yifeng/foo.txt
b1 | b2 | b3
128MB 128MB

Block Management
•  Namenodeはblock locationを保持
–  b1: {dn1, dn3, dn4}
•  NamenodeはDatanodeが保存してい
るすべてのblockのリストを保持
–  dn1: [b1, b2]
/home/yifeng/foo.txt
b1 | b2 | b3
DN1
b1
DN2
DN3 DN4
b1
b1
b2
b2
b2
b3
b3
b3

Block Report
•  NNとDNのblock情報の突き合わせ(diﬀ)
–  Full report: DNが定期的にNNに送る
–  Incremental report: block変更更があるたび
•  Diﬀが合った場合
–  NNがメモリ上のblock mapを更更新か
–  NNがDNに命令令を出す
o  例例：block削除
DN1
b1
DN2
b2
b2
b3
{ dn1: [b1, b2]
dn2: [b2, b3]
}
{ b1: [dn1, dn3, dn4]
b2: [dn1, dn2, dn4]
}
Namenode
b4
I have [b1,
b2]
I have [b2,
b3, b4]

Write Operation
15
•  Client: NNに書込み要求
•  NN: write lockをかけ、インメモリのFS変更更、lock解除
•  NN: edit log sync
•  NN: audit log sync
•  NN: clientにレスポンス
•  Client: write pipeline 的にデータ書込み

rack1
Write Pipeline
16
DN1
Namenode
client
switch
rack2
DN3
switch
DN2
switch
1. Add block
2. Res [dn1, dn2, dn3]
3. client write to dn1
4. dn1 to dn2
5. dn2 to dn3
•  Rack認識識
–  Dn1: rack1
–  Dn2, dn3: rack2
•  書込みはpipeline
–  Client -‐‑‒> dn1 -‐‑‒> dn2 -‐‑‒> dn3
–  データを受取ったら次にパス
–  Ackは逆順

Data Read
•  Client: NNに読込み要求
•  NN: read lockをかけ、イン
メモリFSを取得、clientにレ
スポンス、lock解除
•  Client: DNにデータ取得
•  Rack認識識
17
rack1
DN1
Namenode
client
switch
rack2
DN3
switch
DN2
switch
1. Get block location
2. Res [dn1, dn2, dn3]
3. Client read from DNx

Data Replication
•  HDFSはデータを３つのDNに複製
•  メリット
–  障害時データを失わない
–  ローカリティ：ローカル、あるいは同じrackのデータを処理理
–  コピーだけなのでシンプル
•  デメリット
–  ストレージコストが⾼高い
–  オーバーヘッドは２倍：１PBのストレージは実質0.33PBのデータしか保存できない
18

Erasure Code in HDFS
Page 19

Erasure Code
•  エラー修復復の技術
•  元データ(N)はより⻑⾧長いメッセージ(N
+M)にencodingされ、障害が発⽣生時
decodeしデータを復復元できます
•  RAIDと異異なり、復復元は任意のM個（
すべてではなく）のデータブロック
でできる
•  可⽤用性は⾮非常に⾼高い
–  NとMは調整可能。(10, 4)か(6, 3)がよ
く使われる N Symbols N Symbols
M Symbols
encode

Erasure Code in HDFS
•  (6,3)-‐‑‒Reed-‐‑‒Solomon
–  データが6のdata blockと3のparity blockにencodingする
–  任意の6のblock (data or parity)でデータ復復元できる
•  HDFSレイアでの実装
•  Intel ISA-‐‑‒L library利利⽤用：通常の10倍早い
•  想定ユースケース
–  ⼤大きい（GB~∼）ファイル：節約効果が⾼高い
–  データ可⽤用性を⾼高めつつ、ストレージコストを抑えたい
–  頻繁にアクセスしないデータ：データローカリティがなくなる
21
HDFS-7285

Replication vs. Erasure Code

Erasure Code in HDFS: Write
c1
c2
c3
c4
c5
c6
Incoming data
c7
c8
c9
…
b1
b2
b3
b4
b5
b6
b1
b2
b3
c1
p1
p2
p3
NamenodeEC Client
1. Add block group
2. Res [dn1, dn2, dn3, …, dn9]
DN1
DN2
DN3
…
DN9
3. Write c1 to DN1
3. Write c2 to DN2
3. Write c3 to DN3
3. Write cx to DNx
3. Write p3 to DN9
64KB
64KB
Encode (6, 3) EC

Erasure Code in HDFS: Read
c1
c2
c3
c4
c5
c6
c7
c8
c9
…
p1
p2
p3
NamenodeEC Client
1. Get block group
2. Res [dn1, dn2, dn3, …, dn6]
DN1
DN2
DN3
…
DN6
3. Read 64k from DN1
3. Read 64k from DNx
Decode (6, 3) EC
if data block is unavailable
Response

Erasure Code in HDFS: Recovery
•  Namenodeはblockの欠損を検出し、EC Reconstructionをスケジューリング
•  EC Reconstructionは負荷が高い
–  CPU, I/O消費が多い
–  1 block障害: 無視（書込み中）か低い優先度で
–  2 blocks障害: 低い優先度で
–  3 blocks障害: 高い優先度で

Hadoop on EC2
すこし深堀り
Page 26

Best Practices
常時稼働Hadoopと⼀一時的Hadoop（例例: EMR）の要件が違う
（常時稼働）Hadoop on EC2の基本的な考え⽅方
•  ローカルストレージがポイント
•  データノードのデータはインスタンスストアのみ利利⽤用
•  マスタノードのデータはEBSに
•  データはS3にバックアップ
•  ディストリビューション（HDP）を使う
•  運⽤用管理理ツール、可⽤用性、セキュリティ
なぜ？

なぜインスタンスストア？
•  HDFSはスループットが重要
•  ⼤大きいブロックサイズ（128MB）使っている
•  ディスクseekを減らし、Sequence IOに最適化
•  データローカリティが重要
•  インスタンスストアが⾼高速、かつ無料料。データ冗⻑⾧長化はHDFS任せ
•  EBSはお勧めしない
•  ネットワークI/Oがボトルネック
•  Random I/Oに最適

HDD vs. SSD
•  Hadoopはほとんどの場合はHDDがベスト
•  大量のHDD (12本~)、1本あたり数TBのインスタンスストアがあるEC2
インスタンスタイプが望ましい
HDD SSD
Random IOPS 100 ~ 180 20,000
MB/s 160 ~ 200 400
TB 4 ~ 6 1.2
Cost $200 $1000
$/TB/(MB/s) Low High
$/TB/IOPS High Low
RDB
HDFS

なぜS3にバックアップ？
•  EC2のtopologyは取れない、コントロールできない
•  同じHWなのか？同じRackなのか？
•  Placement GroupはRackとみなすべき？
•  バックアップ⽅方法
•  Batch: Distcp, Falcon
•  Double-‐‑‒write: Kinesis / Kafka + StormでS3とHDFSに両⽅方書込み

まとめ
Page 31

Hadoop Trends and Hadoop on EC2
•  Hadoopは常に早く進化しています
•  次世代モダン・データアーキテクチャ (MDA)はHadoopにて実現
•  Hadoopはより効率率率、安全、早くなっています
•  Hadoopの深堀りはする価値がある
•  Hadoop on EC2は効率率率や柔軟性が⾼高い

Thank you
Yifeng Jiang, Solutions Engineer, Hortonworks
@uprush

HDFS Deep Dive

More Related Content

What's hot

Viewers also liked

Similar to HDFS Deep Dive

More from Yifeng Jiang

HDFS Deep Dive