More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to 刊行記念セミナー「HBase徹底入門」
Similar to 刊行記念セミナー「HBase徹底入門」 (20)
More from cyberagent
More from cyberagent (20)
Recently uploaded
Recently uploaded (16)
刊行記念セミナー「HBase徹底入門」
- 2. 2 今日話すこと ● 「HBase徹底入門」の紹介 ● HBaseはどんなデータベースか？ ● ストレージフォーマット ● スキーマ設計 ● アプリケーション例 ● クラスタの構築 ● パフォーマンスチューニング
- 3. 3 自己紹介 ● 鈴木俊裕(すずきとしひろ) ● ソフトウェアエンジニア ● 技術本部 秋葉原ラボ ● Hadoopを用いたログ解析システム ● HBaseを用いた基盤システム ● twitter @brfrn169
- 5. 5 HBase徹底入門 ● Part 1「HBaseとは」 o 図や例を多用してできるだけわかりやすく ● Part 2「アプリケーション開発」 o 実践的なサンプルアプリが多数 ● Part 3「クラスタの構築と運用」 o Cloudera Managerを使った構築 ● 付録 o コプロセッサやバルクロード、パフォーマンスチューニング などの高度なトピック、HBase-1.0.0など
- 10. 10 特徴 ● スケーラブル o 自動シャーディング o 大規模データに対応 ● 高可用性 o 自動フェイルオーバー機能 ● ハイパフォーマンス o LSM-tree(Log Structured Merge Tree) o 特に書き込みが速い o 読み込みも低レイテンシ
- 11. 11株式会社サイバーエージェント システム構成 • マスタ型 • MasterとRegionServerの2種類のプロセスが存在する • Master • RegionServerの管理やRegionのアサインなど • RegionServer • クライアントと実際にデータのやり取り • 障害検知や各プロセス間のコーディネーションを Zookeeper Master RegionServer RegionServer Zookeeper HDFS ・・ ・ RegionServer
- 12. 12株式会社サイバーエージェント システム構成 • HDFS(Hadoop Distributed File System)上に構築されてい る • (デフォルトで)レプリカを3つ持つので信頼性が高い • HBaseの信頼性はHDFSに依存している Master RegionServer RegionServer Zookeeper HDFS ・・ ・ RegionServer
- 13. 13 ユースケース ● Facebook o メッセージ機能 ● LINE o おそらく、日本で一番規模が大きい o 1000台規模 ● Amebaのスマートフォンプラットフォーム o グラフDBとして o HBaseを用いたグラフDB「Hornet」の設計と運用 http://www.slideshare.net/brfrn169/hcj2014-hornet
- 14. 14 • 部分的にRDBに似ている 株式会社サイバーエージェント HBaseのデータモデル ColumnFamily1 ColumnFamily2 Column1 Column2 Column3 Column4 Column5 row1 row2 row3 row4 row5 aaa bbb NULL ccc ddd row6 row7 row8 RowKey (主キー、辞書順 でソートされて いる) Column Cell Table
- 15. 15 • でも、ちょっと違う 株式会社サイバーエージェント HBaseのデータモデル ColumnFamily1 ColumnFamily2 Column1 Column2 Column3 Column4 Column5 row1 row2 row3 row4 row5 aaa bbb NULL ccc ddd row6 row7 row8 Columnは ColumnFamilyによ ってグルーピング ▼ ▼ ▼ ▼ fff ggg hhh iii jjj Cellは バージョンを持つ
- 16. 16 • でも、ちょっと違う 株式会社サイバーエージェント HBaseのデータモデル ColumnFamily1 ColumnFamily2 Column1 Column2 Column3 Column4 Column5 row1 row2 row3 row4 row5 aaa bbb ccc ddd eee row6 row7 row8 ColumnFamilyは 定義する必要がある
- 17. 17 • でも、ちょっと違う 株式会社サイバーエージェント HBaseのデータモデル ColumnFamily1 ColumnFamily2 Column1 Column2 Column3 Column4 Column5 row1 row2 row3 row4 row5 aaa bbb ccc ddd eee row6 row7 row8
- 18. 18 • でも、ちょっと違う 株式会社サイバーエージェント HBaseのデータモデル ColumnFamily1 ColumnFamily2 Column1 Column2 Column3 Column4 Column5 Column6 row1 row2 row3 row4 row5 aaa bbb ccc ddd eee fff row6 row7 row8 Columnは後から動的に 増やすことができる
- 19. 19 • でも、ちょっと違う 株式会社サイバーエージェント HBaseのデータモデル ColumnFamily1 ColumnFamily2 Column1 Column2 Column3 Column4 Column5 Column6 Column7 row1 row2 row3 row4 row5 aaa bbb ccc ddd eee fff ggg row6 row7 row8 Columnは後から動的に 増やすことができる
- 20. 20 • でも、ちょっと違う 株式会社サイバーエージェント HBaseのデータモデル ColumnFamily1 ColumnFamily2 Column1 Column2 Column3 Column4 Column5 Column6 Column7 Column8 row1 row2 row3 row4 row5 aaa bbb ccc ddd eee fff ggg hhh row6 row7 row8 Columnは後から動的に 増やすことができる
- 21. 21 HBaseのAPI ● CRUD o get Rowを取得 o put RowやColumnの追加・更新 o delete RowやColumnの削除 ● スキャン o 複数のRowを取得 o レンジスキャン(開始RowKey、停止RowKey)
- 22. 22 HBaseのAPI ● Read-Modify-Write o インクリメント Columnの値をインクリメント o append Columnの末尾に値を追加 o CAS(checkAndPut, checkAndDelete) 現在の値と期待する値を比較して、一致した場合に更 新・削除 ● Row内の更新・削除はアトミック ● 参照系のAPI o 特定のバージョンを指定できる o フィルタ機能など
- 23. 23 ストレージフォーマット
- 25. 25株式会社サイバーエージェント fam1 col1 col2 row1 aaa 111 row2 bbb 222 row3 ccc NULL row4 ddd 333 ストレージフォーマット ● 実際にどのようにデータが格納されているか(イメージ) ▼ 444
- 26. 26株式会社サイバーエージェント ストレージフォーマット ● 実際にどのようにデータが格納されているか(イメージ) row1 fam1:col1 100 aaa RowKey Column Timestamp value row1 fam1:col2 200 111 row2 fam1:col1 140 bbb row2 fam1:col2 300 222 row3 fam1:col1 400 ccc row4 fam1:col1 500 ddd row4 fam1:col2 300 444 row4 fam1:col2 130 333 RowKey + Column + Timestamp(降順) でソートされている 1つのエントリを KeyValueと呼ぶ
- 27. 27株式会社サイバーエージェント fam1 col1 col2 row1 aaa 111 row2 bbb 222 row3 ccc NULL row4 ddd 333 ストレージフォーマット ● 実際にどのようにデータが格納されているか(イメージ) ▼ 444
- 28. 28株式会社サイバーエージェント ストレージフォーマット ● 実際にどのようにデータが格納されているか(イメージ) row1 fam1:col1 100 aaa RowKey Column Timestamp value row1 fam1:col2 200 111 row2 fam1:col1 140 bbb row2 fam1:col2 300 222 row3 fam1:col1 400 ccc row4 fam1:col1 500 ddd row4 fam1:col2 300 444 row4 fam1:col2 130 333 複数ColumnのRowは、 複数KeyValueになる 動的にColumnを増やす とKeyValueが増える
- 29. 29株式会社サイバーエージェント fam1 col1 col2 row1 aaa 111 row2 bbb 222 row3 ccc NULL row4 ddd 333 ストレージフォーマット ● 実際にどのようにデータが格納されているか(イメージ) ▼ 444
- 30. 30株式会社サイバーエージェント ストレージフォーマット ● 実際にどのようにデータが格納されているか(イメージ) row1 fam1:col1 100 aaa RowKey Column Timestamp value row1 fam1:col2 200 111 row2 fam1:col1 140 bbb row2 fam1:col2 300 222 row3 fam1:col1 400 ccc row4 fam1:col1 500 ddd row4 fam1:col2 300 444 row4 fam1:col2 130 333 値がNULLの場合は、 KeyValueが保存されない
- 31. 31株式会社サイバーエージェント fam1 col1 col2 row1 aaa 111 row2 bbb 222 row3 ccc NULL row4 ddd 333 ストレージフォーマット ● 実際にどのようにデータが格納されているか(イメージ) ▼ 444
- 32. 32株式会社サイバーエージェント ストレージフォーマット ● 実際にどのようにデータが格納されているか(イメージ) row1 fam1:col1 100 aaa RowKey Column Timestamp value row1 fam1:col2 200 111 row2 fam1:col1 140 bbb row2 fam1:col2 300 222 row3 fam1:col1 400 ccc row4 fam1:col1 500 ddd row4 fam1:col2 300 444 row4 fam1:col2 130 333 複数バージョンを持っている場合は、 Timestampが違うKeyValueになる
- 33. 33株式会社サイバーエージェント ColumnFamily1 ColumnFamily2 Column1 Column2 Column3 Column4 Column5 row1 row2 row3 row4 row5 row6 row7 row8 データの分割(シャーディング) ● Region
- 34. 34株式会社サイバーエージェント ColumnFamily1 ColumnFamily2 Column1 Column2 Column3 Column4 Column5 row1 row2 row3 row4 row5 row6 row7 row8 RowKeyの範囲で Regionに分割され る Region1 Region2 データの分割(シャーディング) ● Region
- 35. 35 ● Regionは各RegionServerに配置される ● Regionをデータ量や負荷が均等になるようにRegionServerに配 置することで、ロードバランスが可能 ● 大きくなりすぎたRegionは分割される 株式会社サイバーエージェント RegionServer 1 RegionServer 2 Region 1 Region 3 Region 5Region 6 RegionServer 3 Region 2 Region 8 Region 4 Region 7 データの分割(シャーディング)
- 36. 36株式会社サイバーエージェント ColumnFamily1 Column1 Column2 row1 row2 row3 row4 ColumnFamily2 Column3 Column4 Column5 ColumnFamily ● データファイル
- 37. 37株式会社サイバーエージェント ColumnFamily1 Column1 Column2 row1 row2 row3 row4 ColumnFamily2 Column3 Column4 Column5 ファイル1 ファイル2 ColumnFamily毎に データファイルが分かれる ColumnFamily指向 データフォーマット ColumnFamily ● データファイル
- 38. 38 ColumnFamily ● データファイルが分かれるので、同時にアクセスされるデータ を同じColumnFamilyに所属させる o I/Oやフィルタリング処理を削減することができる ● ColumnFamily毎に特別な設定を入れることができる o 圧縮/エンコーディング o ブルームフィルタ など => 同じような性質のデータを同じColumnFamilyに所属させる
- 39. 39 スキーマ設計
- 40. 40 スキーマ設計 ● RowKey, Column, Timestamp, 値のどこにデータをマッピングす るか ● RDBの設計 o 対象世界を分析してER図を書く(概念設計) o ER図をもとにリレーショナルモデルを作成(論理設計) o テーブルやインデックスを定義など(物理設計) ● HBaseのスキーマ設計 o 論理設計までは同じ o 物理設計をどうするかというところがかなり違う API ストレージフォーマット
- 41. 41 スキーマ設計のポイント ● クエリを中心にデータを設計する o データの並びと限定されたインデックス o データの近さ o 非正規化
- 42. 42 スキーマ設計のポイント ● データの並びと限定されたインデックス o RowKey、Column、Timestamp(降順)でソートされた状態で 格納 ソートさせた状態で取得したい場合は、RowKeyか Columnにデータをマッピングする必要がある o RowKey+Columnにインデックスがはられる 検索条件として使いたいデータは、RowKeyやColumnに データをマッピングする必要がある
- 43. 43 スキーマ設計のポイント ● データの近さ o RowKeyやColumnの設計によってデータの近さをコントロー ルできる o 近いデータはスキャンで効率的に取得できる 例) RowKeyのフレフィックスが同じデータ o Rowはそれ以上分割されない 同じRowのデータは必ず同じRegionServerに割り当てら れる
- 44. 44 スキーマ設計のポイント ● 非正規化 o 同じデータに対して物理的に複数のデータを持つこと o HBaseにはセカンダリインデックスやJoin機能がないので非 正規化はよく用いられる o セカンダリインデックス 複数パターンでソートした状態で取得したいとき 複数パターンの条件で検索したいとき o Join 予めJoinされた状態で、データを格納しておく o デメリット 更新時に整合性を保つのが難しくなる データ容量が大きくなる
- 45. 45 スキーマ設計のテクニック ● CHAPTER 6で紹介 o データをソートしたり検索条件に使うためのテクニック o 非正規化 o ホットスポット対策 o スキャンのためのテクニック o CASを使ったテクニック など
- 46. 46 アプリケーション例
- 47. 47 ● メッセージングサービス ● アクセスカウンタ ● ドキュメントバージョン管理システム ● ブログサービス ● MapReduceによるブログ検索インデックスの作成 ● スキーマ設計から実装まで細かく解説！ CHAPTER 7で取り上げてるアプリケーション例
- 48. 48 メッセージングサービスのスキーマ設計 ● LINEのようなアプリケーション o ルームがあって、そこでユーザ同士がメッセージを交換し あう o メッセージはテキストのみ o 本書ではフィルタ機能を使ったユーザのブロック機能があ るが今回は割愛 ● メッセージングサービスのシナリオ o ルーム内でメッセージを送信する o ルームに初めて訪れたとき、他のユーザによって既に交換 されているメッセージを最新順で取得する o 過去のメッセージを最新順で取得する o 最新メッセージを最新順で取得する
- 50. 50 メッセージングサービス ● スキーマ設計(物理設計) o シナリオからクエリを考える ルームに初めて訪れたとき、他のユーザによって既に 交換されているメッセージを最新順で取得する 過去のメッセージを最新順で取得する 最新メッセージを最新順で取得する
- 51. 51 メッセージングサービス ● スキーマ設計(物理設計) o スキーマを考える(RowKey) 全てのクエリでメッセージを取得する => メッセージIDをRowKeyに入れる 全てのクエリでルーム毎に取得している => RowKeyにルームIDを先頭に入れる ルーム毎に最新順で取得できる必要がある ● 送信日時のリバースタイムスタンプをルームIDとメッセー ジIDの間に入れる o リバースタイムスタンプとは、タイムスタンプをlong型 の最大値から引いた値 最後にホットスポット対策のために、ルームIDのハッシュ値を 先頭に入れる
- 52. 52 メッセージングサービス ● スキーマ設計(物理設計) o スキーマを考える(RowKey) <ルームIDのハッシュ値>-<ルームID>-<送信日時のリ バースタイムスタンプ>-<メッセージID>
- 53. 53 メッセージングサービス ● スキーマ設計(物理設計) o スキーマを考える(Column) mという名前のColumnFamily1つだけ RowKeyに入らない必要なデータ ● メッセージ本文(m:body) ● ユーザID(m:userId) ● ユーザ名(m:userName) o バージョンは使わない(Timestampは現在時刻)
- 56. 56 メッセージングサービス RowKey Column Timesamp 値 0xab-1-100-msgId1 m:body msg1 0xab-1-100-msgId1 m:userId user1 0xab-1-100-msgId1 m:userName name1 0xab-1-200-msgId2 m:body msg2 0xab-1-200-msgId2 m:userId user2 0xab-1-200-msgId2 m:userName name2 0xab-1-300-msgId3 m:body msg3 0xab-1-300-msgId3 m:userId user2 0xab-1-300-msgId3 m:userName name2 0xac-9-100-msgId5 ・ ・ ・ 「0xab-1-」を プレフィックス として レンジスキャン
- 58. 58 メッセージングサービス RowKey Column Timesamp 値 0xab-1-100-msgId1 m:body msg1 0xab-1-100-msgId1 m:userId user1 0xab-1-100-msgId1 m:userName name1 0xab-1-200-msgId2 m:body msg2 0xab-1-200-msgId2 m:userId user2 0xab-1-200-msgId2 m:userName name2 0xab-1-300-msgId3 m:body msg3 0xab-1-300-msgId3 m:userId user2 0xab-1-300-msgId3 m:userName name2 0xac-9-100-msgId5 ・ ・ ・ 受け取っている一番古 いメッセージ+1をスキ ャン開始RowKeyにして レンジスキャン
- 60. 60 メッセージングサービス RowKey Column Timesamp 値 0xab-1-100-msgId1 m:body msg1 0xab-1-100-msgId1 m:userId user1 0xab-1-100-msgId1 m:userName name1 0xab-1-200-msgId2 m:body msg2 0xab-1-200-msgId2 m:userId user2 0xab-1-200-msgId2 m:userName name2 0xab-1-300-msgId3 m:body msg3 0xab-1-300-msgId3 m:userId user2 0xab-1-300-msgId3 m:userName name2 0xac-9-100-msgId5 ・ ・ ・ 受け取っている一番新 しいメッセージをスキ ャン停止RowKeyにして レンジスキャン
- 61. 61 まとめ ● HBaseについて説明 o データモデル o API o ストレージフォーマット ● スキーマ設計 ● アプリケーション例
- 62. 62 クラスタの構築
- 63. 63 自己紹介 柿島大貴（かきしま ひろたか） 2011年 新卒入社 インフラエンジニアとしてアメーバに配属 2012年 DBチームと秋葉原ラボのインフラ担当を兼務 Hadoop/HBase 構築、バージョンアップ、データセンター移設 障害対応、Chefレシピ作成など 2014年 秋葉原ラボに異動
- 65. 65 本書の担当はChapter 8〜12 ● Chapter 8 クラスタの設計 ● Chapter 9 クラスタの構築 ● Chapter 10 管理オペレーションの基礎 ● Chapter 11 発展的な管理オペレーション ● Chapter 12 クラスタのモニタリング
- 66. 66 本書の担当はChapter 8〜12 ● Chapter 8 クラスタの設計 ● Chapter 9 クラスタの構築 ● Chapter 10 管理オペレーションの基礎 ● Chapter 11 発展的な管理オペレーション ● Chapter 12 クラスタのモニタリング
- 80. 80 Chapter 8 クラスタの設計 のポイント ● クラスタの構成やサーバスペックの参考情報を紹介 ● HBaseの完全分散モードでの構築方法を紹介 o Cloudera Managerを使用 o スクリーンキャプチャ多め Chapter 9 クラスタの構築 のポイント
- 81. 81 Chapter 10 管理オペレーションの基礎 のポイント ● よくあるオペレーションをハンズオン形式で紹介 o どういったオペレーションがあるのか Chapter 11 発展的な管理オペレーションのポイント ● Cloudera ManagerのREST APIの紹介 ● 各ノードダウン時の復旧方法 o Cloudera Manager Server、 マスターノード、スレーブノード
- 82. 82 Chapter 12 クラスタのモニタリング のポイント ● Cloudera Managerの強力なモニタリング機能 o チャートライブラリ、トリガー、テーブルの統計など
- 86. 86 パフォーマンスチューニング ●本書で取り上げている内容 ○ Java VMのGCのチューニング (A.5.1) ○ HBaseのチューニング (A.5.2) ○ Compactionのチューニング (A.5.3) ○ ダウンタイムのチューニング (A.5.4) ○ その他 (A.5.5) ○ MapReduceのチューニング (A.5.6) ○ ベンチマークツール (A.5.7)
- 89. 89 MemStore ● MemStoreは一定データ量、一定期間、一定更新回数でバック グラウンドでFlushされる ● MemStoreの総量によって、強制的にFlushされる場合がある
- 95. 95 MemStoreのサイズ総量による強制Flush(1) RegionServer MemStore HFile 強制的に Flush クライアン ト 書き込み要求 MemStoreのサイズ総量が hbase.regionserver.global.memstore.lowerLimit × ヒープサイズを超える MemStoreのサイズ総量が hbase.regionserver.global.memstore. lowerLimit × ヒープサイズを下回る まで強制Flushが続く HDFS 強制的にFlushが開始される
- 98. 98 MemStoreのサイズ総量による強制Flush(1) RegionServer MemStore HFile HDFS 強制的に Flush クライアン ト MemStoreのサイズ総量が hbase.regionserver.global.memstore.u pperLimit × ヒープサイズを下回るま で書き込みがブロックされる MemStoreのサイズ総量が hbase.regionserver.global.memstore.upperLimit × ヒープサイズを超える 書き込み要求 MemStoreのサイズ総量が hbase.regionserver.global.memstore. lowerLimit × ヒープサイズを下回る まで強制Flushが続く 強制的にFlushが開始される
- 99. 99 MemStoreの設定まとめ 設定キー 説明 デフォルト値 hbase.regionserver.global.memstore.upp erLimit RegionServer内のすべてのMemStoreに対する最大サイズ。 指定された値はヒープ領域の割合を表す。これを超えた場合 は、更新がブロックされ、MemStoreが強制的にFlushされる。 0.4 hbase.regionserver.global.memstore.low erLimit RegionServer内のすべてのMemStoreに対する最大サイズ。 指定された値はヒープ領域の割合を表す。これを超えた場合 は、MemStoreが強制的にFlushされる。 0.38 hbase.hregion.memstore.flush.size MemStoreのサイズが指定された値を超えた場合にflushされ る。 128MB hbase.hregion.memstore.block.multiplier MemStoreのサイズが指定された値と hbase.hregion.memstore.flush.sizeを乗算した結果を超えた場 合に更新がブロックされる。 4 hbase.regionserver.optionalcacheflushin terval MemSotreがflushされるまでの最大時間。この時間を超えた 場合は、MemStoreのサイズに関係なく、強制的にFlushされ る。 1h hbase.regionserver.flush.per.changes MemStoreがFlushされるまでの最大更新回数。更新回数が これを超えた場合は、MemStoreのサイズに関係なく、強制 的にFlushされる。 30000000