Movatterモバイル変換

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

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

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

© Hortonworks Inc. 2011 – 2015. All Rights ReservedBlock Management•  Namenodeはblock locationを保持–  b1: {dn1, dn3, dn4}•  NamenodeはDatanodeが保存しているすべてのblockのリストを保持–  dn1: [b1, b2]/home/yifeng/foo.txtb1 | b2 | b3DN1b1DN2DN3 DN4b1b1b2b2b2b3b3b3

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

© Hortonworks Inc. 2011 – 2015. All Rights ReservedWrite Operation15•  Client: NNに書込み要求•  NN: write lockをかけ、インメモリのFS変更更、lock解除•  NN: edit log sync•  NN: audit log sync•  NN: clientにレスポンス•  Client: write pipeline 的にデータ書込み

© Hortonworks Inc. 2011 – 2015. All Rights Reservedrack1Write Pipeline16DN1Namenodeclientswitchrack2DN3switchDN2switch1. Add block2. Res [dn1, dn2, dn3]3. client write to dn14. dn1 to dn25. dn2 to dn3•  Rack認識識–  Dn1: rack1–  Dn2, dn3: rack2•  書込みはpipeline–  Client -‐‑‒> dn1 -‐‑‒> dn2 -‐‑‒> dn3–  データを受取ったら次にパス–  Ackは逆順

© Hortonworks Inc. 2011 – 2015. All Rights ReservedData Read•  Client: NNに読込み要求•  NN: read lockをかけ、インメモリFSを取得、clientにレスポンス、lock解除•  Client: DNにデータ取得•  Rack認識識17rack1DN1Namenodeclientswitchrack2DN3switchDN2switch1. Get block location2. Res [dn1, dn2, dn3]3. Client read from DNx

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

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

© Hortonworks Inc. 2011 – 2015. All Rights ReservedErasure 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~∼）ファイル：節約効果が⾼高い–  データ可⽤用性を⾼高めつつ、ストレージコストを抑えたい–  頻繁にアクセスしないデータ：データローカリティがなくなる21HDFS-7285

© Hortonworks Inc. 2011 – 2015. All Rights ReservedErasure Code in HDFS: Writec1c2c3c4c5c6Incoming datac7c8c9…b1b2b3b4b5b6b1b2b3c1p1p2p3NamenodeEC Client1. Add block group2. Res [dn1, dn2, dn3, …, dn9]DN1DN2DN3…DN93. Write c1 to DN13. Write c2 to DN23. Write c3 to DN33. Write cx to DNx3. Write p3 to DN964KB64KBEncode (6, 3) EC

© Hortonworks Inc. 2011 – 2015. All Rights ReservedErasure Code in HDFS: Readc1c2c3c4c5c6c7c8c9…p1p2p3NamenodeEC Client1. Get block group2. Res [dn1, dn2, dn3, …, dn6]DN1DN2DN3…DN63. Read 64k from DN13. Read 64k from DN23. Read 64k from DN23. Read 64k from DNx3. Read 64k from DN6Decode (6, 3) ECif data block is unavailableResponse

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

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

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

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

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

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

Movatterモバイル変換

Change Language

HDFS Deep Dive

Embed presentation

Recommended

More Related Content

What's hot

Viewers also liked

Similar to HDFS Deep Dive

More from Yifeng Jiang

HDFS Deep Dive