SlideShare a Scribd company logo
1 of 35
© 2017 NTT DATA Corporation
Apache Hadoopの新機能Ozoneの現状
2017/11/29
株式会社NTTデータ OSSプロフェッショナルサービス
鯵坂 明
Hadoopソースコードリーディング 第24回
© 2017 NTT DATA Corporation 2
 鯵坂 明 (Akira Ajisaka, @ajis_ka)
 NTTデータ OSSプロフェッショナルサービス
 Apache Hadoopと関わり続けて6年が経過
 Hadoopの新機能や、関連するミドルウェアの検証
 プロジェクトへの技術支援
 サポートサービス
 Apache Hadoop committer, PMC member
 HadoopのJava 9対応を実施中
自己紹介
© 2017 NTT DATA Corporation 3
Hadoop 3.0.0のリリースが目前
20142011 20132012 2015
2.2.0
2.3.0
2.4.02.0.0-alpha
2.1.0-beta
0.23.0
0.23.11(final)
NameNode Federation, YARN
NameNode HA
HDFS Snapshots
NFSv3 support
Windows
Heterogeneous storage
HDFS in-memory caching
HDFS ACLs
HDFS Rolling Upgrades
Application History Server
RM Automatic Failover
2.5.0
2.6.0
YARN Rolling Upgrades
Transparent Encryption
Archival Storage
2.7.0
Drop JDK6 support
Truncate API
2016
branch-0.23
branch-2
trunk
Hadoop2
Hadoop3
2017
2.8.0
3.0.0-alpha1 3.0.0-beta1
HDFS caller context
S3A improvement
Support Azure Data Lake
3.0.0-alpha4
2.9.0
Timeline Service v.2
YARN Web UI v2
Opportunistic Containers
YARN Federation
HDFS Router-based federation
© 2017 NTT DATA Corporation 4
 https://cwiki.apache.org/confluence/display/HADOOP/R
oadmap
今後のRoadmap
© 2017 NTT DATA Corporation 5
 S3のようなオブジェクトストレージをHadoop上で実現する
 多数のオブジェクトを格納したいという、HDFSが苦手とす
る領域をカバーする目的で開発されている
 HDFS-7240 branchで開発中
 開発が始まって2年半
 Issue数はErasure Coding (HDFS-7285) のおよそ2倍
 Roadmapによると、Hadoop 3.1.0で使える予定
 2018 1Qあたり?
Ozone: Object Store in Apache Hadoop
© 2017 NTT DATA Corporation 6
本スライドは、feature branchで開発中の機能
を紹介するものです
設定方法、コマンドなど全てにおいて、今後変更
される可能性が大いにあります
Ozoneについて詳しく紹介する前に... 注意事項
© 2017 NTT DATA Corporation 7
ボリューム、バケット、オブジェクト
Ozone
ACLACL ACL
ボリューム
バケットを複数持つ。
管理者アカウントが設定されている。
一定の容量が割り当てられている。
バケット
オブジェクトを複数持つ。
ACL を設定することができる。
名前空間はバケットで独立。
オブジェクト
キーと値の組。
キーはバケット内でユニーク。
・・・
・・・
・・・
© 2017 NTT DATA Corporation 8
各コンポーネント間の関係
Key Space Manager (KSM) Storage Container Manager (SCM)
Ozone Client
Containers
Ozone Handler
DataNode
Containers
Ozone Handler
DataNode
・・・
© 2017 NTT DATA Corporation 9
 Container
 DataNode上に保持
 Ozoneにおけるレプリケーションの単位
Ozoneを構成するコンポーネント
© 2017 NTT DATA Corporation 10
 Ozone Handler
 クライアントに対してOzoneのREST APIを提供
 各DataNode上で動作
 Key Space Manager (KSM)
 名前空間に関するクエリを処理
 オブジェクトのキーやバケット名からcontainerを解決
 Storage Container Manager (SCM)
 DataNodeとheartbeat通信し、各containerがどの
DataNode上に存在するかをトラッキングする
 障害時にcontainerのレプリケーションを実施
Ozoneを構成するコンポーネント
© 2017 NTT DATA Corporation 11
Volume作成におけるリクエストの流れ
Key Space Manager (KSM) Storage Container Manager (SCM)
Ozone Client
Containers
Ozone Handler
DataNode
Containers
Ozone Handler
DataNode
・・・
① create volume
② create volume
 Volume, Bucketに関するリクエストは同じ流れ
© 2017 NTT DATA Corporation 12
オブジェクト挿入におけるリクエストの流れ
Key Space Manager (KSM) Storage Container Manager (SCM)
Ozone Client
Containers
Ozone Handler
DataNode
Containers
Ozone Handler
DataNode
・・・
① put object
② allocate containers
③ container names
⑥ put data
④ get container locations
⑤ container locations (pipeline)
© 2017 NTT DATA Corporation 13
 DataNode -> ObjectStoreHandler ->
DistributedStorageHandler という順番で追うことで、Ozone
Handlerの全貌が掴める
 DistributedStorageHandler が クライアントからのリクエスト
を受け付ける
 Volumeの作成 -> #createVolume
 オブジェクトの挿入 -> #newKeyWriter
 ...
 デモ
ソースコードリーディング
© 2017 NTT DATA Corporation 14
1. SCMがcontainerを3つ選択
2. クライアントはcontainer Aに書き込む
3. container Aはcontainer Bに対して書き込む
(ここで書き込みが正常に完了したとみなす)
4. container Bはcontainer Cに対して書き込む
container replicationの流れ
Copysets
RAFT
コンテナ B
クライアント
書き込み完了
コンテナ A コンテナ C
© 2017 NTT DATA Corporation 15
 ランダムレプリケーションだと、データロストの確率が増える
 5000ノードのクラスタで1%のサーバが同時に故障した場合、
ほぼ確実にデータロスト
 レプリケーションをするノードの組み合わせが増えすぎること
が問題
 ノードの組み合わせ: 5000C3 = 約208億通り
 データロストする組み合わせ: 50C3 = 19600通り
 あるblockが故障する確率: 208億/19600 = 約100万分の1
 block数は億オーダー -> データロスト
 ノードの組み合わせを減らすしかない
Copysets: Reducing the Frequency of Data Loss in Cloud Storage
© 2017 NTT DATA Corporation 16
 Scatter width (以下 S) を定義
 あるノードのデータのコピーを持っているノード数がS
 9 nodeの場合、{1, 2, 3}, {4, 5, 6}, {7, 8, 9}, {1, 4,
7}, {2, 5, 8}, {3, 6, 9} という組み合わせは S=4 を満
たす
 ここで、{1, 2, 3}はあるデータが 1, 2, 3番のノードにそ
れぞれレプリケーションされることを示す
 1にあるデータは 2, 3, 4, 7の4ノードが持っている (S=4)
 Sを小さくすると組み合わせが減り、データロスト発生確率は
下がるが、小さくしすぎてもよくない
 故障時の再レプリケーションが遅くなる
Copysets: Reducing the Frequency of Data Loss in Cloud Storage
© 2017 NTT DATA Corporation 17
 Sをなるべく保ったまま、組み合わせを減らすことが重要
 以下はどちらもS=4だが、上のほうがよい
 {1, 2, 3}, {4, 5, 6}, {7, 8, 9}, {1, 4, 7}, {2, 5, 8},
{3, 6, 9}
 {1, 2, 3}, {2, 3, 4}, {3, 4, 5}, {4, 5, 6}, {5, 6, 7},
{6, 7, 8}, {7, 8, 9}, {8, 9, 1}, {9, 1, 2}, {1, 2, 4},
{1, 3, 4}, {2, 3, 5}, {2, 4, 5}, {3, 4, 6}, {3, 5, 6},
{4, 5, 7}
 詳細は省くが、うまく作ると組み合わせ数は O(S) になる
 完全ランダムの場合、O(SR-1
)
Copysets: Reducing the Frequency of Data Loss in Cloud Storage
© 2017 NTT DATA Corporation 18
5000台のうち50台故障時のデータロスト発生確率
© 2017 NTT DATA Corporation 19
Copysetsによって書き込み先が決まる流れ
Permutation Phase
Copyset と呼ばれるノードのまとまりを
ランダムに生成した順列に基づいて決定
Replication Phase
ランダムにひとつのノードを選択し、
copysets に従ってレプリケーションを実施
⇒ Ozone は Copysets のアルゴリズムに基づいて書き込み先のコンテナを3つ決定
© 2017 NTT DATA Corporation 20
 分散合意のプロトコル
 詳しくはこちら: http://thesecretlivesofdata.com/raft/
 Ozoneの開発メンバが中心となって、RAFTのJava実装
Apache Ratis (Incubator)を開発
 https://github.com/apache/incubator-ratis
 OzoneではレプリケーションにRatisを利用
RAFT
© 2017 NTT DATA Corporation 21
 trunkではなく、HDFS-7240 branchをビルド
 ozone-site.xmlの設定例
 Ratisはデフォルト無効 (レプリケーションされない)
Ozoneのセットアップ、設定
<configuration>
<property name="ozone.enabled" value="true" />
<property
name="ozone.container.metadata.dirs"
value="containerを格納するディレクトリ" />
<property name="ozone.scm.names" value="SCM のホスト名" />
<property name="ozone.scm.client.address" value="SCM のホスト名"/>
<property name="ozone.ksm.address" value="KSM のホスト名" />
<property name="dfs.container.ratis.enabled" value="true" />
</configuration>
© 2017 NTT DATA Corporation 22
 SCM
 KSM
Ozoneの起動
$ hdfs --daemon start scm
$ hdfs --daemon start ksm
© 2017 NTT DATA Corporation 23
 design docやAPI docがJIRAにあるが、情報が古い
 ソースコード付属のマニュアルがおすすめ
 https://github.com/apache/hadoop/blob/HDFS-
7240/hadoop-hdfs-project/hadoop-
hdfs/src/site/markdown/OzoneGettingStarted.md.v
m
困ったときは...
© 2017 NTT DATA Corporation 24
KSM Web UI (port 9874)
© 2017 NTT DATA Corporation 25
SCM Web UI (port 9876)
© 2017 NTT DATA Corporation 26
DataNode Web UI (port 9864)
© 2017 NTT DATA Corporation 27
config確認が便利になった
© 2017 NTT DATA Corporation 28
config確認が便利になった
© 2017 NTT DATA Corporation 29
 Volumeの作成
 quota設定はここで実施
 Bucketの作成
 ACLの設定はここで実施
 Keyの作成
 実データのコピー
データを配置してみる
$ hdfs oz -createVolume http://localhost:9864/volume ¥
-user centos
$ hdfs oz -createBucket http://localhost:9864/volume/bucket
$ hdfs oz -putKey http://localhost:9864/volume/bucket/key ¥
-file localkey
© 2017 NTT DATA Corporation 30
 DNにおける ozone.container.metadata.dirs 配下の構成
 datanode.id: DNのユニークIDを格納
 ratis/: RAFTのログを格納
 repository/: containerの実データを格納
 実際にデータを置いてみたところ、2個のノードにしかレプリ
ケーションされていなかった... (11/22時点)
 DNログを読む限り、Ratisでのログ共有に失敗している
 今後の修正に期待 (最新版だと動くかも)
 ちなみに2017/9時点ではRatisが入っていなかった
 状況が刻一刻と変わるので、長い目で見守るのが良さそう
データの配置状況
© 2017 NTT DATA Corporation 31
 10人規模でのonline meetingが何度か実施されている
 議事録は JIRA に記載されている
 trunkにマージすべきか延長すべきかで、まだ結論が出ていない
 Ozoneの取り組みがHDFSのスケーラビリティを解消している
ことについては同意
 NameNodeとOzoneを統合した状態でマージするのが理想だ
が、NameNodeにおいて密結合している FSNameSystem
と BlockManager のロックを分離する必要があって hard
work
 このタイミングでマージするのが落としどころでは
3.1.0でのマージに向けた議論
© 2017 NTT DATA Corporation 32
 NameNodeにおけるFSNameSystemとBlockManagerの密結合は、
HDFS append APIを実装した2010年にもたらされた
 当時は、RAFTのようなメンバの追加/削除が可能な分散合意プロトコルが
一般的ではなかったため、中央集権的に実装された
 Ozoneのマージを機に、7年続いた密結合が取り崩されることに期待が膨ら
む
 私も開発に参加して、取り組みを加速させたい
最後に
© 2017 NTT DATA Corporation 33
https://issues.apache.org/jira/secure/attachment/12895963/HDFS%20Scalability%20and%20Ozone.pdf
© 2017 NTT DATA Corporation 34
 Copysets: Reducing the Frequency of Data Loss in
Cloud Storage
 https://www.usenix.org/node/174509
References
© 2017 NTT DATA Corporation
本資料中に記載されている会社名、商品名、ロゴは、各社の商標または登録商標です。

More Related Content

What's hot

Apache Arrow - データ処理ツールの次世代プラットフォーム
Apache Arrow - データ処理ツールの次世代プラットフォームApache Arrow - データ処理ツールの次世代プラットフォーム
Apache Arrow - データ処理ツールの次世代プラットフォーム
Kouhei Sutou
 
Pacemaker+PostgreSQLレプリケーションで共有ディスクレス高信頼クラスタの構築@OSC 2013 Tokyo/Spring
Pacemaker+PostgreSQLレプリケーションで共有ディスクレス高信頼クラスタの構築@OSC 2013 Tokyo/SpringPacemaker+PostgreSQLレプリケーションで共有ディスクレス高信頼クラスタの構築@OSC 2013 Tokyo/Spring
Pacemaker+PostgreSQLレプリケーションで共有ディスクレス高信頼クラスタの構築@OSC 2013 Tokyo/Spring
Takatoshi Matsuo
 

What's hot (20)

Apache Arrow - データ処理ツールの次世代プラットフォーム
Apache Arrow - データ処理ツールの次世代プラットフォームApache Arrow - データ処理ツールの次世代プラットフォーム
Apache Arrow - データ処理ツールの次世代プラットフォーム
 
ログ解析基盤におけるストリーム処理パイプラインについて
ログ解析基盤におけるストリーム処理パイプラインについてログ解析基盤におけるストリーム処理パイプラインについて
ログ解析基盤におけるストリーム処理パイプラインについて
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
 
Hadoop -NameNode HAの仕組み-
Hadoop -NameNode HAの仕組み-Hadoop -NameNode HAの仕組み-
Hadoop -NameNode HAの仕組み-
 
Apache Hadoopに見るJavaミドルウェアのcompatibility(Open Developers Conference 2020 Onli...
Apache Hadoopに見るJavaミドルウェアのcompatibility(Open Developers Conference 2020 Onli...Apache Hadoopに見るJavaミドルウェアのcompatibility(Open Developers Conference 2020 Onli...
Apache Hadoopに見るJavaミドルウェアのcompatibility(Open Developers Conference 2020 Onli...
 
Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編
 
え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理
え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理
え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理
 
Apache Avro vs Protocol Buffers
Apache Avro vs Protocol BuffersApache Avro vs Protocol Buffers
Apache Avro vs Protocol Buffers
 
Apache Bigtopによるオープンなビッグデータ処理基盤の構築(オープンデベロッパーズカンファレンス 2021 Online 発表資料)
Apache Bigtopによるオープンなビッグデータ処理基盤の構築(オープンデベロッパーズカンファレンス 2021 Online 発表資料)Apache Bigtopによるオープンなビッグデータ処理基盤の構築(オープンデベロッパーズカンファレンス 2021 Online 発表資料)
Apache Bigtopによるオープンなビッグデータ処理基盤の構築(オープンデベロッパーズカンファレンス 2021 Online 発表資料)
 
Apache Hadoop HDFSの最新機能の紹介(2018)#dbts2018
Apache Hadoop HDFSの最新機能の紹介(2018)#dbts2018Apache Hadoop HDFSの最新機能の紹介(2018)#dbts2018
Apache Hadoop HDFSの最新機能の紹介(2018)#dbts2018
 
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
 
Apache Kuduを使った分析システムの裏側
Apache Kuduを使った分析システムの裏側Apache Kuduを使った分析システムの裏側
Apache Kuduを使った分析システムの裏側
 
Paxos
PaxosPaxos
Paxos
 
KafkaとPulsar
KafkaとPulsarKafkaとPulsar
KafkaとPulsar
 
kubernetes初心者がKnative Lambda Runtime触ってみた(Kubernetes Novice Tokyo #13 発表資料)
kubernetes初心者がKnative Lambda Runtime触ってみた(Kubernetes Novice Tokyo #13 発表資料)kubernetes初心者がKnative Lambda Runtime触ってみた(Kubernetes Novice Tokyo #13 発表資料)
kubernetes初心者がKnative Lambda Runtime触ってみた(Kubernetes Novice Tokyo #13 発表資料)
 
Pacemaker+PostgreSQLレプリケーションで共有ディスクレス高信頼クラスタの構築@OSC 2013 Tokyo/Spring
Pacemaker+PostgreSQLレプリケーションで共有ディスクレス高信頼クラスタの構築@OSC 2013 Tokyo/SpringPacemaker+PostgreSQLレプリケーションで共有ディスクレス高信頼クラスタの構築@OSC 2013 Tokyo/Spring
Pacemaker+PostgreSQLレプリケーションで共有ディスクレス高信頼クラスタの構築@OSC 2013 Tokyo/Spring
 
PacemakerのMaster/Slave構成の基本と事例紹介(DRBD、PostgreSQLレプリケーション) @Open Source Confer...
PacemakerのMaster/Slave構成の基本と事例紹介(DRBD、PostgreSQLレプリケーション) @Open Source Confer...PacemakerのMaster/Slave構成の基本と事例紹介(DRBD、PostgreSQLレプリケーション) @Open Source Confer...
PacemakerのMaster/Slave構成の基本と事例紹介(DRBD、PostgreSQLレプリケーション) @Open Source Confer...
 
トランザクションをSerializableにする4つの方法
トランザクションをSerializableにする4つの方法トランザクションをSerializableにする4つの方法
トランザクションをSerializableにする4つの方法
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
 
GNU AGPLv3について(On GNU AGPLv3)
GNU AGPLv3について(On GNU AGPLv3)GNU AGPLv3について(On GNU AGPLv3)
GNU AGPLv3について(On GNU AGPLv3)
 

Similar to Apache Hadoopの新機能Ozoneの現状

Google Compute EngineとPipe API
Google Compute EngineとPipe APIGoogle Compute EngineとPipe API
Google Compute EngineとPipe API
maruyama097
 
Google Compute EngineとGAE Pipeline API
Google Compute EngineとGAE Pipeline APIGoogle Compute EngineとGAE Pipeline API
Google Compute EngineとGAE Pipeline API
maruyama097
 
B 8スポンサー講演資料 osnexus steven umbehocker (アファーム・ビジネスパートナーズ株)
B 8スポンサー講演資料 osnexus steven umbehocker (アファーム・ビジネスパートナーズ株)B 8スポンサー講演資料 osnexus steven umbehocker (アファーム・ビジネスパートナーズ株)
B 8スポンサー講演資料 osnexus steven umbehocker (アファーム・ビジネスパートナーズ株)
chenree3
 
B 8スポンサー講演資料 osnexus steven umbehocker (アファーム・ビジネスパートナーズ株)
B 8スポンサー講演資料 osnexus steven umbehocker (アファーム・ビジネスパートナーズ株)B 8スポンサー講演資料 osnexus steven umbehocker (アファーム・ビジネスパートナーズ株)
B 8スポンサー講演資料 osnexus steven umbehocker (アファーム・ビジネスパートナーズ株)
softlayerjp
 
Amazon ElastiCache - AWSマイスターシリーズ
Amazon ElastiCache - AWSマイスターシリーズAmazon ElastiCache - AWSマイスターシリーズ
Amazon ElastiCache - AWSマイスターシリーズ
SORACOM, INC
 
MSC2014_NetApp_Session
MSC2014_NetApp_SessionMSC2014_NetApp_Session
MSC2014_NetApp_Session
Takano Masaru
 

Similar to Apache Hadoopの新機能Ozoneの現状 (20)

Google Compute EngineとPipe API
Google Compute EngineとPipe APIGoogle Compute EngineとPipe API
Google Compute EngineとPipe API
 
Google Compute EngineとGAE Pipeline API
Google Compute EngineとGAE Pipeline APIGoogle Compute EngineとGAE Pipeline API
Google Compute EngineとGAE Pipeline API
 
BigtopでHadoopをビルドする(Open Source Conference 2021 Online/Spring 発表資料)
BigtopでHadoopをビルドする(Open Source Conference 2021 Online/Spring 発表資料)BigtopでHadoopをビルドする(Open Source Conference 2021 Online/Spring 発表資料)
BigtopでHadoopをビルドする(Open Source Conference 2021 Online/Spring 発表資料)
 
B 8スポンサー講演資料 osnexus steven umbehocker (アファーム・ビジネスパートナーズ株)
B 8スポンサー講演資料 osnexus steven umbehocker (アファーム・ビジネスパートナーズ株)B 8スポンサー講演資料 osnexus steven umbehocker (アファーム・ビジネスパートナーズ株)
B 8スポンサー講演資料 osnexus steven umbehocker (アファーム・ビジネスパートナーズ株)
 
B 8スポンサー講演資料 osnexus steven umbehocker (アファーム・ビジネスパートナーズ株)
B 8スポンサー講演資料 osnexus steven umbehocker (アファーム・ビジネスパートナーズ株)B 8スポンサー講演資料 osnexus steven umbehocker (アファーム・ビジネスパートナーズ株)
B 8スポンサー講演資料 osnexus steven umbehocker (アファーム・ビジネスパートナーズ株)
 
[db tech showcase Tokyo 2017] A15: レプリケーションを使用したデータ分析基盤構築のキモ(事例)by 株式会社インサイトテ...
[db tech showcase Tokyo 2017] A15: レプリケーションを使用したデータ分析基盤構築のキモ(事例)by 株式会社インサイトテ...[db tech showcase Tokyo 2017] A15: レプリケーションを使用したデータ分析基盤構築のキモ(事例)by 株式会社インサイトテ...
[db tech showcase Tokyo 2017] A15: レプリケーションを使用したデータ分析基盤構築のキモ(事例)by 株式会社インサイトテ...
 
「hbstudy#23 OpenStack祭!!」資料 ~OpenStackプロジェクトの全体像~
「hbstudy#23 OpenStack祭!!」資料 ~OpenStackプロジェクトの全体像~「hbstudy#23 OpenStack祭!!」資料 ~OpenStackプロジェクトの全体像~
「hbstudy#23 OpenStack祭!!」資料 ~OpenStackプロジェクトの全体像~
 
Apache Hadoop and YARN, current development status
Apache Hadoop and YARN, current development statusApache Hadoop and YARN, current development status
Apache Hadoop and YARN, current development status
 
Apache Bigtop3.2 (仮)(Open Source Conference 2022 Online/Hiroshima 発表資料)
Apache Bigtop3.2 (仮)(Open Source Conference 2022 Online/Hiroshima 発表資料)Apache Bigtop3.2 (仮)(Open Source Conference 2022 Online/Hiroshima 発表資料)
Apache Bigtop3.2 (仮)(Open Source Conference 2022 Online/Hiroshima 発表資料)
 
20120117 13 meister-elasti_cache-public
20120117 13 meister-elasti_cache-public20120117 13 meister-elasti_cache-public
20120117 13 meister-elasti_cache-public
 
141030ceph
141030ceph141030ceph
141030ceph
 
Amazon ElastiCache - AWSマイスターシリーズ
Amazon ElastiCache - AWSマイスターシリーズAmazon ElastiCache - AWSマイスターシリーズ
Amazon ElastiCache - AWSマイスターシリーズ
 
HDFS Router-based federation
HDFS Router-based federationHDFS Router-based federation
HDFS Router-based federation
 
Red Hat OpenShift Container Storage
Red Hat OpenShift Container StorageRed Hat OpenShift Container Storage
Red Hat OpenShift Container Storage
 
HDFS新機能総まとめin 2015 (日本Hadoopユーザー会 ライトニングトーク@Cloudera World Tokyo 2015 講演資料)
HDFS新機能総まとめin 2015 (日本Hadoopユーザー会 ライトニングトーク@Cloudera World Tokyo 2015 講演資料)HDFS新機能総まとめin 2015 (日本Hadoopユーザー会 ライトニングトーク@Cloudera World Tokyo 2015 講演資料)
HDFS新機能総まとめin 2015 (日本Hadoopユーザー会 ライトニングトーク@Cloudera World Tokyo 2015 講演資料)
 
Hinemosによるハイブリッドクラウド運用管理の最新情報
Hinemosによるハイブリッドクラウド運用管理の最新情報Hinemosによるハイブリッドクラウド運用管理の最新情報
Hinemosによるハイブリッドクラウド運用管理の最新情報
 
MSC2014_NetApp_Session
MSC2014_NetApp_SessionMSC2014_NetApp_Session
MSC2014_NetApp_Session
 
OpenShift v3 Technical Overview
OpenShift v3 Technical OverviewOpenShift v3 Technical Overview
OpenShift v3 Technical Overview
 
今日から使えるCouchbaseシステムアーキテクチャデザインパターン集
今日から使えるCouchbaseシステムアーキテクチャデザインパターン集今日から使えるCouchbaseシステムアーキテクチャデザインパターン集
今日から使えるCouchbaseシステムアーキテクチャデザインパターン集
 
20140826 it pro_expo_rev2
20140826 it pro_expo_rev220140826 it pro_expo_rev2
20140826 it pro_expo_rev2
 

More from NTT DATA OSS Professional Services

More from NTT DATA OSS Professional Services (20)

Global Top 5 を目指す NTT DATA の確かで意外な技術力
Global Top 5 を目指す NTT DATA の確かで意外な技術力Global Top 5 を目指す NTT DATA の確かで意外な技術力
Global Top 5 を目指す NTT DATA の確かで意外な技術力
 
Spark SQL - The internal -
Spark SQL - The internal -Spark SQL - The internal -
Spark SQL - The internal -
 
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
 
Hadoopエコシステムのデータストア振り返り
Hadoopエコシステムのデータストア振り返りHadoopエコシステムのデータストア振り返り
Hadoopエコシステムのデータストア振り返り
 
PostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイント
PostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイントPostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイント
PostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイント
 
Distributed data stores in Hadoop ecosystem
Distributed data stores in Hadoop ecosystemDistributed data stores in Hadoop ecosystem
Distributed data stores in Hadoop ecosystem
 
Structured Streaming - The Internal -
Structured Streaming - The Internal -Structured Streaming - The Internal -
Structured Streaming - The Internal -
 
Apache Hadoopの未来 3系になって何が変わるのか?
Apache Hadoopの未来 3系になって何が変わるのか?Apache Hadoopの未来 3系になって何が変わるのか?
Apache Hadoopの未来 3系になって何が変わるのか?
 
HDFS basics from API perspective
HDFS basics from API perspectiveHDFS basics from API perspective
HDFS basics from API perspective
 
SIerとオープンソースの美味しい関係 ~コミュニティの力を活かして世界を目指そう~
SIerとオープンソースの美味しい関係 ~コミュニティの力を活かして世界を目指そう~SIerとオープンソースの美味しい関係 ~コミュニティの力を活かして世界を目指そう~
SIerとオープンソースの美味しい関係 ~コミュニティの力を活かして世界を目指そう~
 
20170303 java9 hadoop
20170303 java9 hadoop20170303 java9 hadoop
20170303 java9 hadoop
 
ブロックチェーンの仕組みと動向(入門編)
ブロックチェーンの仕組みと動向(入門編)ブロックチェーンの仕組みと動向(入門編)
ブロックチェーンの仕組みと動向(入門編)
 
Application of postgre sql to large social infrastructure jp
Application of postgre sql to large social infrastructure jpApplication of postgre sql to large social infrastructure jp
Application of postgre sql to large social infrastructure jp
 
Application of postgre sql to large social infrastructure
Application of postgre sql to large social infrastructureApplication of postgre sql to large social infrastructure
Application of postgre sql to large social infrastructure
 
Apache Hadoop 2.8.0 の新機能 (抜粋)
Apache Hadoop 2.8.0 の新機能 (抜粋)Apache Hadoop 2.8.0 の新機能 (抜粋)
Apache Hadoop 2.8.0 の新機能 (抜粋)
 
データ活用をもっともっと円滑に! ~データ処理・分析基盤編を少しだけ~
データ活用をもっともっと円滑に!~データ処理・分析基盤編を少しだけ~データ活用をもっともっと円滑に!~データ処理・分析基盤編を少しだけ~
データ活用をもっともっと円滑に! ~データ処理・分析基盤編を少しだけ~
 
商用ミドルウェアのPuppet化で気を付けたい5つのこと
商用ミドルウェアのPuppet化で気を付けたい5つのこと商用ミドルウェアのPuppet化で気を付けたい5つのこと
商用ミドルウェアのPuppet化で気を付けたい5つのこと
 
今からはじめるPuppet 2016 ~ インフラエンジニアのたしなみ ~
今からはじめるPuppet 2016 ~ インフラエンジニアのたしなみ ~今からはじめるPuppet 2016 ~ インフラエンジニアのたしなみ ~
今からはじめるPuppet 2016 ~ インフラエンジニアのたしなみ ~
 
Hadoopエコシステムの最新動向とNTTデータの取り組み (OSC 2016 Tokyo/Spring 講演資料)
Hadoopエコシステムの最新動向とNTTデータの取り組み (OSC 2016 Tokyo/Spring 講演資料)Hadoopエコシステムの最新動向とNTTデータの取り組み (OSC 2016 Tokyo/Spring 講演資料)
Hadoopエコシステムの最新動向とNTTデータの取り組み (OSC 2016 Tokyo/Spring 講演資料)
 
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
 

Recently uploaded

Recently uploaded (7)

LoRaWAN無位置ロープ型水漏れセンサー WL03A-LB/LSカタログ ファイル
LoRaWAN無位置ロープ型水漏れセンサー WL03A-LB/LSカタログ ファイルLoRaWAN無位置ロープ型水漏れセンサー WL03A-LB/LSカタログ ファイル
LoRaWAN無位置ロープ型水漏れセンサー WL03A-LB/LSカタログ ファイル
 
Utilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native IntegrationsUtilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native Integrations
 
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
 
ネットワーク可視化 振る舞い検知(NDR)ご紹介_キンドリル202405.pdf
ネットワーク可視化 振る舞い検知(NDR)ご紹介_キンドリル202405.pdfネットワーク可視化 振る舞い検知(NDR)ご紹介_キンドリル202405.pdf
ネットワーク可視化 振る舞い検知(NDR)ご紹介_キンドリル202405.pdf
 
Hyperledger Fabricコミュニティ活動体験& Hyperledger Fabric最新状況ご紹介
Hyperledger Fabricコミュニティ活動体験& Hyperledger Fabric最新状況ご紹介Hyperledger Fabricコミュニティ活動体験& Hyperledger Fabric最新状況ご紹介
Hyperledger Fabricコミュニティ活動体験& Hyperledger Fabric最新状況ご紹介
 
2024年5月17日 先駆的科学計算フォーラム2024 機械学習を用いた新たなゲーム体験の創出の応用
2024年5月17日 先駆的科学計算フォーラム2024 機械学習を用いた新たなゲーム体験の創出の応用2024年5月17日 先駆的科学計算フォーラム2024 機械学習を用いた新たなゲーム体験の創出の応用
2024年5月17日 先駆的科学計算フォーラム2024 機械学習を用いた新たなゲーム体験の創出の応用
 
LoRaWAN無位置ロープ式水漏れセンサーWL03A 日本語マニュアル
LoRaWAN無位置ロープ式水漏れセンサーWL03A 日本語マニュアルLoRaWAN無位置ロープ式水漏れセンサーWL03A 日本語マニュアル
LoRaWAN無位置ロープ式水漏れセンサーWL03A 日本語マニュアル
 

Apache Hadoopの新機能Ozoneの現状

  • 1. © 2017 NTT DATA Corporation Apache Hadoopの新機能Ozoneの現状 2017/11/29 株式会社NTTデータ OSSプロフェッショナルサービス 鯵坂 明 Hadoopソースコードリーディング 第24回
  • 2. © 2017 NTT DATA Corporation 2  鯵坂 明 (Akira Ajisaka, @ajis_ka)  NTTデータ OSSプロフェッショナルサービス  Apache Hadoopと関わり続けて6年が経過  Hadoopの新機能や、関連するミドルウェアの検証  プロジェクトへの技術支援  サポートサービス  Apache Hadoop committer, PMC member  HadoopのJava 9対応を実施中 自己紹介
  • 3. © 2017 NTT DATA Corporation 3 Hadoop 3.0.0のリリースが目前 20142011 20132012 2015 2.2.0 2.3.0 2.4.02.0.0-alpha 2.1.0-beta 0.23.0 0.23.11(final) NameNode Federation, YARN NameNode HA HDFS Snapshots NFSv3 support Windows Heterogeneous storage HDFS in-memory caching HDFS ACLs HDFS Rolling Upgrades Application History Server RM Automatic Failover 2.5.0 2.6.0 YARN Rolling Upgrades Transparent Encryption Archival Storage 2.7.0 Drop JDK6 support Truncate API 2016 branch-0.23 branch-2 trunk Hadoop2 Hadoop3 2017 2.8.0 3.0.0-alpha1 3.0.0-beta1 HDFS caller context S3A improvement Support Azure Data Lake 3.0.0-alpha4 2.9.0 Timeline Service v.2 YARN Web UI v2 Opportunistic Containers YARN Federation HDFS Router-based federation
  • 4. © 2017 NTT DATA Corporation 4  https://cwiki.apache.org/confluence/display/HADOOP/R oadmap 今後のRoadmap
  • 5. © 2017 NTT DATA Corporation 5  S3のようなオブジェクトストレージをHadoop上で実現する  多数のオブジェクトを格納したいという、HDFSが苦手とす る領域をカバーする目的で開発されている  HDFS-7240 branchで開発中  開発が始まって2年半  Issue数はErasure Coding (HDFS-7285) のおよそ2倍  Roadmapによると、Hadoop 3.1.0で使える予定  2018 1Qあたり? Ozone: Object Store in Apache Hadoop
  • 6. © 2017 NTT DATA Corporation 6 本スライドは、feature branchで開発中の機能 を紹介するものです 設定方法、コマンドなど全てにおいて、今後変更 される可能性が大いにあります Ozoneについて詳しく紹介する前に... 注意事項
  • 7. © 2017 NTT DATA Corporation 7 ボリューム、バケット、オブジェクト Ozone ACLACL ACL ボリューム バケットを複数持つ。 管理者アカウントが設定されている。 一定の容量が割り当てられている。 バケット オブジェクトを複数持つ。 ACL を設定することができる。 名前空間はバケットで独立。 オブジェクト キーと値の組。 キーはバケット内でユニーク。 ・・・ ・・・ ・・・
  • 8. © 2017 NTT DATA Corporation 8 各コンポーネント間の関係 Key Space Manager (KSM) Storage Container Manager (SCM) Ozone Client Containers Ozone Handler DataNode Containers Ozone Handler DataNode ・・・
  • 9. © 2017 NTT DATA Corporation 9  Container  DataNode上に保持  Ozoneにおけるレプリケーションの単位 Ozoneを構成するコンポーネント
  • 10. © 2017 NTT DATA Corporation 10  Ozone Handler  クライアントに対してOzoneのREST APIを提供  各DataNode上で動作  Key Space Manager (KSM)  名前空間に関するクエリを処理  オブジェクトのキーやバケット名からcontainerを解決  Storage Container Manager (SCM)  DataNodeとheartbeat通信し、各containerがどの DataNode上に存在するかをトラッキングする  障害時にcontainerのレプリケーションを実施 Ozoneを構成するコンポーネント
  • 11. © 2017 NTT DATA Corporation 11 Volume作成におけるリクエストの流れ Key Space Manager (KSM) Storage Container Manager (SCM) Ozone Client Containers Ozone Handler DataNode Containers Ozone Handler DataNode ・・・ ① create volume ② create volume  Volume, Bucketに関するリクエストは同じ流れ
  • 12. © 2017 NTT DATA Corporation 12 オブジェクト挿入におけるリクエストの流れ Key Space Manager (KSM) Storage Container Manager (SCM) Ozone Client Containers Ozone Handler DataNode Containers Ozone Handler DataNode ・・・ ① put object ② allocate containers ③ container names ⑥ put data ④ get container locations ⑤ container locations (pipeline)
  • 13. © 2017 NTT DATA Corporation 13  DataNode -> ObjectStoreHandler -> DistributedStorageHandler という順番で追うことで、Ozone Handlerの全貌が掴める  DistributedStorageHandler が クライアントからのリクエスト を受け付ける  Volumeの作成 -> #createVolume  オブジェクトの挿入 -> #newKeyWriter  ...  デモ ソースコードリーディング
  • 14. © 2017 NTT DATA Corporation 14 1. SCMがcontainerを3つ選択 2. クライアントはcontainer Aに書き込む 3. container Aはcontainer Bに対して書き込む (ここで書き込みが正常に完了したとみなす) 4. container Bはcontainer Cに対して書き込む container replicationの流れ Copysets RAFT コンテナ B クライアント 書き込み完了 コンテナ A コンテナ C
  • 15. © 2017 NTT DATA Corporation 15  ランダムレプリケーションだと、データロストの確率が増える  5000ノードのクラスタで1%のサーバが同時に故障した場合、 ほぼ確実にデータロスト  レプリケーションをするノードの組み合わせが増えすぎること が問題  ノードの組み合わせ: 5000C3 = 約208億通り  データロストする組み合わせ: 50C3 = 19600通り  あるblockが故障する確率: 208億/19600 = 約100万分の1  block数は億オーダー -> データロスト  ノードの組み合わせを減らすしかない Copysets: Reducing the Frequency of Data Loss in Cloud Storage
  • 16. © 2017 NTT DATA Corporation 16  Scatter width (以下 S) を定義  あるノードのデータのコピーを持っているノード数がS  9 nodeの場合、{1, 2, 3}, {4, 5, 6}, {7, 8, 9}, {1, 4, 7}, {2, 5, 8}, {3, 6, 9} という組み合わせは S=4 を満 たす  ここで、{1, 2, 3}はあるデータが 1, 2, 3番のノードにそ れぞれレプリケーションされることを示す  1にあるデータは 2, 3, 4, 7の4ノードが持っている (S=4)  Sを小さくすると組み合わせが減り、データロスト発生確率は 下がるが、小さくしすぎてもよくない  故障時の再レプリケーションが遅くなる Copysets: Reducing the Frequency of Data Loss in Cloud Storage
  • 17. © 2017 NTT DATA Corporation 17  Sをなるべく保ったまま、組み合わせを減らすことが重要  以下はどちらもS=4だが、上のほうがよい  {1, 2, 3}, {4, 5, 6}, {7, 8, 9}, {1, 4, 7}, {2, 5, 8}, {3, 6, 9}  {1, 2, 3}, {2, 3, 4}, {3, 4, 5}, {4, 5, 6}, {5, 6, 7}, {6, 7, 8}, {7, 8, 9}, {8, 9, 1}, {9, 1, 2}, {1, 2, 4}, {1, 3, 4}, {2, 3, 5}, {2, 4, 5}, {3, 4, 6}, {3, 5, 6}, {4, 5, 7}  詳細は省くが、うまく作ると組み合わせ数は O(S) になる  完全ランダムの場合、O(SR-1 ) Copysets: Reducing the Frequency of Data Loss in Cloud Storage
  • 18. © 2017 NTT DATA Corporation 18 5000台のうち50台故障時のデータロスト発生確率
  • 19. © 2017 NTT DATA Corporation 19 Copysetsによって書き込み先が決まる流れ Permutation Phase Copyset と呼ばれるノードのまとまりを ランダムに生成した順列に基づいて決定 Replication Phase ランダムにひとつのノードを選択し、 copysets に従ってレプリケーションを実施 ⇒ Ozone は Copysets のアルゴリズムに基づいて書き込み先のコンテナを3つ決定
  • 20. © 2017 NTT DATA Corporation 20  分散合意のプロトコル  詳しくはこちら: http://thesecretlivesofdata.com/raft/  Ozoneの開発メンバが中心となって、RAFTのJava実装 Apache Ratis (Incubator)を開発  https://github.com/apache/incubator-ratis  OzoneではレプリケーションにRatisを利用 RAFT
  • 21. © 2017 NTT DATA Corporation 21  trunkではなく、HDFS-7240 branchをビルド  ozone-site.xmlの設定例  Ratisはデフォルト無効 (レプリケーションされない) Ozoneのセットアップ、設定 <configuration> <property name="ozone.enabled" value="true" /> <property name="ozone.container.metadata.dirs" value="containerを格納するディレクトリ" /> <property name="ozone.scm.names" value="SCM のホスト名" /> <property name="ozone.scm.client.address" value="SCM のホスト名"/> <property name="ozone.ksm.address" value="KSM のホスト名" /> <property name="dfs.container.ratis.enabled" value="true" /> </configuration>
  • 22. © 2017 NTT DATA Corporation 22  SCM  KSM Ozoneの起動 $ hdfs --daemon start scm $ hdfs --daemon start ksm
  • 23. © 2017 NTT DATA Corporation 23  design docやAPI docがJIRAにあるが、情報が古い  ソースコード付属のマニュアルがおすすめ  https://github.com/apache/hadoop/blob/HDFS- 7240/hadoop-hdfs-project/hadoop- hdfs/src/site/markdown/OzoneGettingStarted.md.v m 困ったときは...
  • 24. © 2017 NTT DATA Corporation 24 KSM Web UI (port 9874)
  • 25. © 2017 NTT DATA Corporation 25 SCM Web UI (port 9876)
  • 26. © 2017 NTT DATA Corporation 26 DataNode Web UI (port 9864)
  • 27. © 2017 NTT DATA Corporation 27 config確認が便利になった
  • 28. © 2017 NTT DATA Corporation 28 config確認が便利になった
  • 29. © 2017 NTT DATA Corporation 29  Volumeの作成  quota設定はここで実施  Bucketの作成  ACLの設定はここで実施  Keyの作成  実データのコピー データを配置してみる $ hdfs oz -createVolume http://localhost:9864/volume ¥ -user centos $ hdfs oz -createBucket http://localhost:9864/volume/bucket $ hdfs oz -putKey http://localhost:9864/volume/bucket/key ¥ -file localkey
  • 30. © 2017 NTT DATA Corporation 30  DNにおける ozone.container.metadata.dirs 配下の構成  datanode.id: DNのユニークIDを格納  ratis/: RAFTのログを格納  repository/: containerの実データを格納  実際にデータを置いてみたところ、2個のノードにしかレプリ ケーションされていなかった... (11/22時点)  DNログを読む限り、Ratisでのログ共有に失敗している  今後の修正に期待 (最新版だと動くかも)  ちなみに2017/9時点ではRatisが入っていなかった  状況が刻一刻と変わるので、長い目で見守るのが良さそう データの配置状況
  • 31. © 2017 NTT DATA Corporation 31  10人規模でのonline meetingが何度か実施されている  議事録は JIRA に記載されている  trunkにマージすべきか延長すべきかで、まだ結論が出ていない  Ozoneの取り組みがHDFSのスケーラビリティを解消している ことについては同意  NameNodeとOzoneを統合した状態でマージするのが理想だ が、NameNodeにおいて密結合している FSNameSystem と BlockManager のロックを分離する必要があって hard work  このタイミングでマージするのが落としどころでは 3.1.0でのマージに向けた議論
  • 32. © 2017 NTT DATA Corporation 32  NameNodeにおけるFSNameSystemとBlockManagerの密結合は、 HDFS append APIを実装した2010年にもたらされた  当時は、RAFTのようなメンバの追加/削除が可能な分散合意プロトコルが 一般的ではなかったため、中央集権的に実装された  Ozoneのマージを機に、7年続いた密結合が取り崩されることに期待が膨ら む  私も開発に参加して、取り組みを加速させたい 最後に
  • 33. © 2017 NTT DATA Corporation 33 https://issues.apache.org/jira/secure/attachment/12895963/HDFS%20Scalability%20and%20Ozone.pdf
  • 34. © 2017 NTT DATA Corporation 34  Copysets: Reducing the Frequency of Data Loss in Cloud Storage  https://www.usenix.org/node/174509 References
  • 35. © 2017 NTT DATA Corporation 本資料中に記載されている会社名、商品名、ロゴは、各社の商標または登録商標です。