Successfully reported this slideshow.
Your SlideShare is downloading. ×

刊行記念セミナー「HBase徹底入門」

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 100 Ad
Advertisement

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Advertisement

Similar to 刊行記念セミナー「HBase徹底入門」 (20)

More from cyberagent (20)

Advertisement

Recently uploaded (20)

刊行記念セミナー「HBase徹底入門」

  1. 1. 1 刊行記念セミナー HBase徹底入門 株式会社サイバーエージェント 鈴木 俊裕 梅田 永介 柿島 大貴
  2. 2. 2 今日話すこと ● 「HBase徹底入門」の紹介 ● HBaseはどんなデータベースか? ● ストレージフォーマット ● スキーマ設計 ● アプリケーション例 ● クラスタの構築 ● パフォーマンスチューニング
  3. 3. 3 自己紹介 ● 鈴木俊裕(すずきとしひろ) ● ソフトウェアエンジニア ● 技術本部 秋葉原ラボ ● Hadoopを用いたログ解析システム ● HBaseを用いた基盤システム ● twitter @brfrn169
  4. 4. 4 HBase徹底入門の紹介
  5. 5. 5 HBase徹底入門 ● Part 1「HBaseとは」 o 図や例を多用してできるだけわかりやすく ● Part 2「アプリケーション開発」 o 実践的なサンプルアプリが多数 ● Part 3「クラスタの構築と運用」 o Cloudera Managerを使った構築 ● 付録 o コプロセッサやバルクロード、パフォーマンスチューニング などの高度なトピック、HBase-1.0.0など
  6. 6. 6 HBase徹底入門 ● 本書を読めば、今HBaseを知らないエンジニアでも、HBaseを 使ったアプリケーション開発やクラスタ構築がひと通りできるよ うになる構成 ● 付録に、入門としては高度なトピックや最新情報などを収録し ているので、現在HBaseを使っている方も楽しめる内容
  7. 7. 7 HBaseはどんなデータベースか
  8. 8. 8 会場への質問 HBaseを使ったことある人は ある なし
  9. 9. 9 HBaseとは ● Googleの分散DBである「Bigtable」のオープン ソースクローン ● Javaで実装されている
  10. 10. 10 特徴 ● スケーラブル o 自動シャーディング o 大規模データに対応 ● 高可用性 o 自動フェイルオーバー機能 ● ハイパフォーマンス o LSM-tree(Log Structured Merge Tree) o 特に書き込みが速い o 読み込みも低レイテンシ
  11. 11. 11株式会社サイバーエージェント システム構成 • マスタ型 • MasterとRegionServerの2種類のプロセスが存在する • Master • RegionServerの管理やRegionのアサインなど • RegionServer • クライアントと実際にデータのやり取り • 障害検知や各プロセス間のコーディネーションを Zookeeper Master RegionServer RegionServer Zookeeper HDFS ・・ ・ RegionServer
  12. 12. 12株式会社サイバーエージェント システム構成 • HDFS(Hadoop Distributed File System)上に構築されてい る • (デフォルトで)レプリカを3つ持つので信頼性が高い • HBaseの信頼性はHDFSに依存している Master RegionServer RegionServer Zookeeper HDFS ・・ ・ RegionServer
  13. 13. 13 ユースケース ● Facebook o メッセージ機能 ● LINE o おそらく、日本で一番規模が大きい o 1000台規模 ● Amebaのスマートフォンプラットフォーム o グラフDBとして o HBaseを用いたグラフDB「Hornet」の設計と運用  http://www.slideshare.net/brfrn169/hcj2014-hornet
  14. 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. 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. 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. 17 • でも、ちょっと違う 株式会社サイバーエージェント HBaseのデータモデル ColumnFamily1 ColumnFamily2 Column1 Column2 Column3 Column4 Column5 row1 row2 row3 row4 row5 aaa bbb ccc ddd eee row6 row7 row8
  18. 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. 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. 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. 21 HBaseのAPI ● CRUD o get  Rowを取得 o put  RowやColumnの追加・更新 o delete  RowやColumnの削除 ● スキャン o 複数のRowを取得 o レンジスキャン(開始RowKey、停止RowKey)
  22. 22. 22 HBaseのAPI ● Read-Modify-Write o インクリメント  Columnの値をインクリメント o append  Columnの末尾に値を追加 o CAS(checkAndPut, checkAndDelete)  現在の値と期待する値を比較して、一致した場合に更 新・削除 ● Row内の更新・削除はアトミック ● 参照系のAPI o 特定のバージョンを指定できる o フィルタ機能など
  23. 23. 23 ストレージフォーマット
  24. 24. 24株式会社サイバーエージェント ストレージフォーマット ● HBaseでスキーマ設計をするにあたって、ストレージフォーマッ トを理解することはとても重要
  25. 25. 25株式会社サイバーエージェント fam1 col1 col2 row1 aaa 111 row2 bbb 222 row3 ccc NULL row4 ddd 333 ストレージフォーマット ● 実際にどのようにデータが格納されているか(イメージ) ▼ 444
  26. 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. 27株式会社サイバーエージェント fam1 col1 col2 row1 aaa 111 row2 bbb 222 row3 ccc NULL row4 ddd 333 ストレージフォーマット ● 実際にどのようにデータが格納されているか(イメージ) ▼ 444
  28. 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. 29株式会社サイバーエージェント fam1 col1 col2 row1 aaa 111 row2 bbb 222 row3 ccc NULL row4 ddd 333 ストレージフォーマット ● 実際にどのようにデータが格納されているか(イメージ) ▼ 444
  30. 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. 31株式会社サイバーエージェント fam1 col1 col2 row1 aaa 111 row2 bbb 222 row3 ccc NULL row4 ddd 333 ストレージフォーマット ● 実際にどのようにデータが格納されているか(イメージ) ▼ 444
  32. 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. 33株式会社サイバーエージェント ColumnFamily1 ColumnFamily2 Column1 Column2 Column3 Column4 Column5 row1 row2 row3 row4 row5 row6 row7 row8 データの分割(シャーディング) ● Region
  34. 34. 34株式会社サイバーエージェント ColumnFamily1 ColumnFamily2 Column1 Column2 Column3 Column4 Column5 row1 row2 row3 row4 row5 row6 row7 row8 RowKeyの範囲で Regionに分割され る Region1 Region2 データの分割(シャーディング) ● Region
  35. 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. 36株式会社サイバーエージェント ColumnFamily1 Column1 Column2 row1 row2 row3 row4 ColumnFamily2 Column3 Column4 Column5 ColumnFamily ● データファイル
  37. 37. 37株式会社サイバーエージェント ColumnFamily1 Column1 Column2 row1 row2 row3 row4 ColumnFamily2 Column3 Column4 Column5 ファイル1 ファイル2 ColumnFamily毎に データファイルが分かれる ColumnFamily指向 データフォーマット ColumnFamily ● データファイル
  38. 38. 38 ColumnFamily ● データファイルが分かれるので、同時にアクセスされるデータ を同じColumnFamilyに所属させる o I/Oやフィルタリング処理を削減することができる ● ColumnFamily毎に特別な設定を入れることができる o 圧縮/エンコーディング o ブルームフィルタ など => 同じような性質のデータを同じColumnFamilyに所属させる
  39. 39. 39 スキーマ設計
  40. 40. 40 スキーマ設計 ● RowKey, Column, Timestamp, 値のどこにデータをマッピングす るか ● RDBの設計 o 対象世界を分析してER図を書く(概念設計) o ER図をもとにリレーショナルモデルを作成(論理設計) o テーブルやインデックスを定義など(物理設計) ● HBaseのスキーマ設計 o 論理設計までは同じ o 物理設計をどうするかというところがかなり違う  API  ストレージフォーマット
  41. 41. 41 スキーマ設計のポイント ● クエリを中心にデータを設計する o データの並びと限定されたインデックス o データの近さ o 非正規化
  42. 42. 42 スキーマ設計のポイント ● データの並びと限定されたインデックス o RowKey、Column、Timestamp(降順)でソートされた状態で 格納  ソートさせた状態で取得したい場合は、RowKeyか Columnにデータをマッピングする必要がある o RowKey+Columnにインデックスがはられる  検索条件として使いたいデータは、RowKeyやColumnに データをマッピングする必要がある
  43. 43. 43 スキーマ設計のポイント ● データの近さ o RowKeyやColumnの設計によってデータの近さをコントロー ルできる o 近いデータはスキャンで効率的に取得できる  例) RowKeyのフレフィックスが同じデータ o Rowはそれ以上分割されない  同じRowのデータは必ず同じRegionServerに割り当てら れる
  44. 44. 44 スキーマ設計のポイント ● 非正規化 o 同じデータに対して物理的に複数のデータを持つこと o HBaseにはセカンダリインデックスやJoin機能がないので非 正規化はよく用いられる o セカンダリインデックス  複数パターンでソートした状態で取得したいとき  複数パターンの条件で検索したいとき o Join  予めJoinされた状態で、データを格納しておく o デメリット  更新時に整合性を保つのが難しくなる  データ容量が大きくなる
  45. 45. 45 スキーマ設計のテクニック ● CHAPTER 6で紹介 o データをソートしたり検索条件に使うためのテクニック o 非正規化 o ホットスポット対策 o スキャンのためのテクニック o CASを使ったテクニック など
  46. 46. 46 アプリケーション例
  47. 47. 47 ● メッセージングサービス ● アクセスカウンタ ● ドキュメントバージョン管理システム ● ブログサービス ● MapReduceによるブログ検索インデックスの作成 ● スキーマ設計から実装まで細かく解説! CHAPTER 7で取り上げてるアプリケーション例
  48. 48. 48 メッセージングサービスのスキーマ設計 ● LINEのようなアプリケーション o ルームがあって、そこでユーザ同士がメッセージを交換し あう o メッセージはテキストのみ o 本書ではフィルタ機能を使ったユーザのブロック機能があ るが今回は割愛 ● メッセージングサービスのシナリオ o ルーム内でメッセージを送信する o ルームに初めて訪れたとき、他のユーザによって既に交換 されているメッセージを最新順で取得する o 過去のメッセージを最新順で取得する o 最新メッセージを最新順で取得する
  49. 49. 49 メッセージングサービス ● 論理設計 o 対象を分析してER図を書く
  50. 50. 50 メッセージングサービス ● スキーマ設計(物理設計) o シナリオからクエリを考える  ルームに初めて訪れたとき、他のユーザによって既に 交換されているメッセージを最新順で取得する  過去のメッセージを最新順で取得する  最新メッセージを最新順で取得する
  51. 51. 51 メッセージングサービス ● スキーマ設計(物理設計) o スキーマを考える(RowKey)  全てのクエリでメッセージを取得する => メッセージIDをRowKeyに入れる  全てのクエリでルーム毎に取得している => RowKeyにルームIDを先頭に入れる  ルーム毎に最新順で取得できる必要がある ● 送信日時のリバースタイムスタンプをルームIDとメッセー ジIDの間に入れる o リバースタイムスタンプとは、タイムスタンプをlong型 の最大値から引いた値  最後にホットスポット対策のために、ルームIDのハッシュ値を 先頭に入れる
  52. 52. 52 メッセージングサービス ● スキーマ設計(物理設計) o スキーマを考える(RowKey)  <ルームIDのハッシュ値>-<ルームID>-<送信日時のリ バースタイムスタンプ>-<メッセージID>
  53. 53. 53 メッセージングサービス ● スキーマ設計(物理設計) o スキーマを考える(Column)  mという名前のColumnFamily1つだけ  RowKeyに入らない必要なデータ ● メッセージ本文(m:body) ● ユーザID(m:userId) ● ユーザ名(m:userName) o バージョンは使わない(Timestampは現在時刻)
  54. 54. 54 メッセージングサービス ● スキーマ設計(物理設計)
  55. 55. 55 メッセージングサービス ● クエリ例 o ルームに初めて訪れたとき、他のユーザによって既に交換 されているメッセージを最新順で取得する
  56. 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-」を プレフィックス として レンジスキャン
  57. 57. 57 メッセージングサービス ● クエリ例 o 過去のメッセージを最新順で取得する
  58. 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にして レンジスキャン
  59. 59. 59 メッセージングサービス ● クエリ例 o 最新メッセージを最新順で取得する
  60. 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. 61 まとめ ● HBaseについて説明 o データモデル o API o ストレージフォーマット ● スキーマ設計 ● アプリケーション例
  62. 62. 62 クラスタの構築
  63. 63. 63 自己紹介 柿島大貴(かきしま ひろたか) 2011年 新卒入社 インフラエンジニアとしてアメーバに配属 2012年 DBチームと秋葉原ラボのインフラ担当を兼務 Hadoop/HBase 構築、バージョンアップ、データセンター移設 障害対応、Chefレシピ作成など 2014年 秋葉原ラボに異動
  64. 64. 64 CyberAgentのエンジニアブログの運営もしてます http://ameblo.jp/principia-ca/
  65. 65. 65 本書の担当はChapter 8〜12 ● Chapter 8 クラスタの設計 ● Chapter 9 クラスタの構築 ● Chapter 10 管理オペレーションの基礎 ● Chapter 11 発展的な管理オペレーション ● Chapter 12 クラスタのモニタリング
  66. 66. 66 本書の担当はChapter 8〜12 ● Chapter 8 クラスタの設計 ● Chapter 9 クラスタの構築 ● Chapter 10 管理オペレーションの基礎 ● Chapter 11 発展的な管理オペレーション ● Chapter 12 クラスタのモニタリング
  67. 67. 67 会場への質問 HBaseクラスタの構築経験は 経験 あり 経験 なし
  68. 68. 68 Chapter 8〜12 の想定読者 入門者 構築・運用が 辛い方 熟練者
  69. 69. 69 HBaseクラスタの構築は難しい?
  70. 70. 70 HBaseクラスタの構築は難しい? https://twitter.com/oranie/status/344405643400196096 当時弊社の Cassandra運用者
  71. 71. 71 HBaseクラスタの構築は難しい?
  72. 72. 72 HBaseクラスタの構築は難しい? HDFS ZooKeeper HBase YARN(include MR2)
  73. 73. 73 HBaseクラスタの構築は難しい? HDFS ZooKeeper HBase YARN(include MR2) ResourceManager NodeManager Master RegionServer NameNode DataNode JournalNode Server ZKFC JobHistoryServer
  74. 74. 74 HBaseクラスタの構築は難しい? HDFS ZooKeeper HBase YARN(include MR2) ResourceManager NodeManager Master RegionServer NameNode DataNode JournalNode Server ZKFC JobHistoryServer設定 モニタリング チューニング 台数も 多い
  75. 75. 75 HBaseクラスタの構築は難しい? HDFS ZooKeeper HBase YARN(include MR2) ResourceManager NodeManager Master RegionServer NameNode DataNode JournalNode Server ZKFC JobHistoryServer 用途によっては... Flume Impala Spark etc.
  76. 76. 76 考えた結果 入門者 構築・運用が 辛い方 熟練者 Chef Ansible Puppet Cloudera Manager Ambari
  77. 77. 77 Chapter 8〜12は、こうなりました
  78. 78. 78 Cloudera Managerとは 引用: http://www.cloudera.co.jp/doc/cm/_images/cloudera-manager-architecture.jpg 管理 ・構築 ・設定 ・起動停止 ・etc. 監視 ・アラート ・チャート etc Clouderaが提供する Hadoop(CDH)の管理アプリケーション
  79. 79. 79 デモ動画 - HBaseクラスタの構築 約7分(スライドでは省略)
  80. 80. 80 Chapter 8 クラスタの設計 のポイント ● クラスタの構成やサーバスペックの参考情報を紹介 ● HBaseの完全分散モードでの構築方法を紹介 o Cloudera Managerを使用 o スクリーンキャプチャ多め Chapter 9 クラスタの構築 のポイント
  81. 81. 81 Chapter 10 管理オペレーションの基礎 のポイント ● よくあるオペレーションをハンズオン形式で紹介 o どういったオペレーションがあるのか Chapter 11 発展的な管理オペレーションのポイント ● Cloudera ManagerのREST APIの紹介 ● 各ノードダウン時の復旧方法 o Cloudera Manager Server、 マスターノード、スレーブノード
  82. 82. 82 Chapter 12 クラスタのモニタリング のポイント ● Cloudera Managerの強力なモニタリング機能 o チャートライブラリ、トリガー、テーブルの統計など
  83. 83. 83 まとめ Cloudera Manager で HBaseクラスタ構築も 挫折なしで 徹底入門!
  84. 84. 84 パフォーマンス チューニング
  85. 85. 85 自己紹介 梅田永介(うめだ えいすけ) 2012年 中途入社 秋葉原ラボに配属 ソフトウェアエンジニア HBaseを用いたグラフDBを開発・運用
  86. 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)
  87. 87. 87 今回の内容 ● MemStore
  88. 88. 88 MemStore ● MemStoreはRegionServerのメモリ上の領域に保持され、追加 されるデータはMemStoreに書き込まれる。 ● MemStoreが一定データ量に達するなどのタイミングでHFileが 出力(Flush)される RegionServer MemStoreクライアン ト 書き込み要求 HDFS HFile Flush
  89. 89. 89 MemStore ● MemStoreは一定データ量、一定期間、一定更新回数でバック グラウンドでFlushされる ● MemStoreの総量によって、強制的にFlushされる場合がある
  90. 90. 90 一定データ量、一定期間、一定更新回数によるFlush RegionServer MemStore HDFS クライアン ト 書き込み要求 HFile MemStoreのサイズ総量が hbase.hregion.memstore.flush.sizeを超えた場合 または、前回のFlushから hbase.regionserver.optionalcacheflushintervalを経過し た場合 または、MemStoreの更新回数が hbase.regionserver.flush.per.changesを超えた場合
  91. 91. 91 一定データ量、一定期間、一定更新回数によるFlush RegionServer MemStore HDFS クライアン ト 書き込み要求 MemStoreのサイズ総量が hbase.hregion.memstore.flush.sizeを超えた場合 または、前回のFlushから hbase.regionserver.optionalcacheflushintervalを経過し た場合 または、MemStoreの更新回数が hbase.regionserver.flush.per.changesを超えた場合 Flush HFile バックグラウンドスレッドで Flushが開始される バックグラウンドスレッドでFlushする ため、Flush中は、MemStoreが大きく なり続ける -> OOM発生の恐れ
  92. 92. 92 一定データ量、一定期間、一定更新回数によるFlush RegionServer MemStore HDFS クライアン ト 書き込み要求 Flush HFile MemStoreのヒープ総量が hbase.hregion.memstore.block.multiplier × hbase.hregion.memstore.flush.sizeを 超えると書き込みがブロックされる バックグラウンドスレッドで Flushが開始される MemStoreのサイズ総量が hbase.hregion.memstore.flush.sizeを超えた場合 または、前回のFlushから hbase.regionserver.optionalcacheflushintervalを経過し た場合 または、MemStoreの更新回数が hbase.regionserver.flush.per.changesを超えた場合
  93. 93. 93 MemStoreのサイズ総量による強制Flush(1) RegionServer MemStoreクライアン ト 書き込み要求 MemStoreのサイズ総量が hbase.regionserver.global.memstore.lowerLimit × ヒープサイズを超える HDFS
  94. 94. 94 MemStoreのサイズ総量による強制Flush(1) RegionServer MemStore HFile 強制的に Flush クライアン ト 書き込み要求 MemStoreのサイズ総量が hbase.regionserver.global.memstore.lowerLimit × ヒープサイズを超える 強制的にFlushが開始される HDFS
  95. 95. 95 MemStoreのサイズ総量による強制Flush(1) RegionServer MemStore HFile 強制的に Flush クライアン ト 書き込み要求 MemStoreのサイズ総量が hbase.regionserver.global.memstore.lowerLimit × ヒープサイズを超える MemStoreのサイズ総量が hbase.regionserver.global.memstore. lowerLimit × ヒープサイズを下回る まで強制Flushが続く HDFS 強制的にFlushが開始される
  96. 96. 96 MemStoreのサイズ総量による強制Flush(2) RegionServer MemStore HDFS クライアン ト MemStoreのサイズ総量が hbase.regionserver.global.memstore.upperLimit × ヒープサイズを超える 書き込み要求
  97. 97. 97 MemStoreのサイズ総量による強制Flush(2) RegionServer MemStore HFile HDFS 強制的に Flush クライアン ト MemStoreのサイズ総量が hbase.regionserver.global.memstore.upperLimit × ヒープサイズを超える 書き込み要求 強制的にFlushが開始される
  98. 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. 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
  100. 100. 100 質疑 挙手していただくか、ハッシュタグ 「#hbase_ca」にツイートしてください

×