「HBase は素晴らしい！言うならばそれは SKVS ！」という台詞に最後は全て喰われていた HBase 徹底入門刊行記念セミナーで著者の方々のサインをもらってきた #hbase_ca

何気に今年最初の勉強会ログの公開になりますが、今日は、先日、 2015-01-28 に発売されたHBase徹底入門の刊行記念イベントが渋谷マークシティで行われるということで参加してきました。
詳細：『HBase徹底入門 Hadoopクラスタによる高速データベースの実現』刊行記念セミナー | Hadoopとビッグデータソリューションのリーディングカンパニー | Cloudera Japan

書籍の刊行イベントだったので、さほど込み入った内容のことは話されないだろうと思い、著者のみなさんのサインをもらいにいったつもりだったんですが、なかなかどうして Cloudera の小林さん、嶋内さんの発表は書籍にない話もあったので参加して本当によかったと思うものでした。
※今回のイベントの資料は後日公開されるそうなので、ゼヒそちらを参照されたいと思います。

ちなみに最後の取りの発表をした Cloudera の嶋内さんが「 HBase は素晴らしい！言うならばそれは SKVS (Super Key Value Store) ！」と言っていたのがそれまでの全てを喰ってしまっていました、さすがでした。

わたし個人的には HBase を仕事で使う機会がなくて馬本さらっと読んで当時の Cloudera Manager で HBase 試しに作って少しいじっただけでその後、全く触ってなかったですが HBase 徹底入門で入門し直したいと思ってます。

HBase徹底入門 Hadoopクラスタによる高速データベースの実現[Kindle版]

posted with ヨメレバ

株式会社サイバーエージェント鈴木俊裕,梅田永介,柿島大貴翔泳社 2015-01-28

Kindle

Amazon[書籍版]

では以降よりわたしが取ってきたメモです。

アジェンダ：

18:30　受付開始及び書籍の販売開始

19:00　ご挨拶

19:05　HBase徹底入門著者株式会社サイバーエージェント　鈴木俊裕氏、梅田永介氏、柿島大貴氏

19:50　HBase活用事例 Cloudera株式会社　嶋内　翔氏

20:20　HBaseサポート最前線 Cloudera株式会社　小林大輔氏

20:45　書籍販売と著者の皆様のサイン会

21:00　閉会

19:00　ご挨拶

通称 HBase 攻略本、なの？
HBase徹底入門 Hadoopクラスタによる「超」高速データベースの実現
- 本当は超がつく！

19:05　HBase徹底入門著者株式会社サイバーエージェント　鈴木俊裕氏、梅田永介氏、柿島大貴氏

HBase 徹底入門の紹介
- 構成は三部構成＋付録
  1. HBase とは
  2. アプリケーション開発
  3. クラスタの構築と運用
  4. 付録：コプロセッサやバルクロード、パフォーマンス・チューニングなどの高度なトピック
- この本を読めば、 HBase を知らないエンジニアでもひと通りこなせるようになることを目指している
- 付録で現在 HBase を使用している人も楽しめる内容に
HBase とはどんな DB か？
- HBase を使ったことがある人会場の 6 割ほど
- BigTable の OSS クローン
  - Java
  - Scalable
    - 自動シャーディング
    - 大規模データに対応
  - 高可用性
    - 自動 FO 機能
  - High Performance
    - LSM-tree
    - 特に書き込みが速い
    - 読み込みも低レイテンシ (多少遅いのだが)
- システム構成
  - マスタ型
    - Master と Region Server
    - ZK を障害検知など
  - HDFS 上に構築されている
    - 信頼性は HDFS に依存
- ユースケース
  - Facebook
    - メッセージ機能
  - LINE
    - 1,000 台規模
  - Cyber
    - 去年の Hadoop Conf Japan での資料
- HBase のデータモデル
  - 部分的に RDB に似る
  - 違う部分
    - Cell はバージョンを持つ etc...
- CRUD はフツーにできる
  - get, put, delete
- Scan
  - 複数の row を取得
  - いわゆる Renge Scan
- HBase の API
  - Read-Modify-Write
    - インクリメント
    - Append
    - CAS (checkAndPut, checkAndDelete)
ストレージフォーマット
- HBase でスキーマ設計をするにあたって重要な要素
  - RowKey + Column + Timestamp(降順)で
  - 複数 Column の Row は複数 Keyvalue(KV) になる
  - NULL 値の場合は KV が保存されない
  - Version
    - 複数バージョン持っている場合は TimeStamp が違う KV になる
  - データの分割
    - シャーディング
    - RowKey の範囲で Region に分割される
    - Region は各 Region Server に
    - Region をデータ量や負荷が均等になるように Region Server を配置することで負荷分散が可能
  - データファイル
    - Column Family (CF) ごとにデータファイルがわかれる
    - 同時にアクセスされるデータを CF に配置する
    - CF ごとに特別な設定をいれられる
      - 圧縮やエンコーディング
      - ブルームフィルタ
スキーマ設計
- RowKey(RK), Column(Col), TimeStamp (RS)
- 論理設計までは RDB と同じ
- 物理設計が RDBMS と異なる
  - API
  - ストレージフォーマット
- ポイント
  - クエリを中心に設計
    - データの並びと限定された index
      - ソートさせた状態で取得したい場合は RK か Col にデータをマッピングする必要
      - RK + Col に index がはられる
    - データの近さ
      - RK や Col の設計によってデータの近さをコントロールできる
      - 近いデータは Scan で効率的に取得可能
    - 非正規化
      - 同じデータに対して物理的に複数のデータをもつ
      - HBase はセカンダリインデックス、 Join 機能がない
- Chapter6 に具体例があるのでそちらを参照されたい
アプリケーション例
- Chapter7 で 5 つのアプリケーションをとりあげている
  - メッセージング
  - アクセスカウンタ
  - ドキュメントバージョン管理
  - ブログ
- かいつまんでメッセージングサービスの例を説明
  - LINE のようなもの
    - ルーム内でメッセージを送信する
    - ルームに初めて訪れたときに他のユーザによってすでに交換されているメッセージを最新順に取得
    - etc...
  - まずは論理設計
    - ER 図を作成する
  - スキーマ設計 (物理設計)
    - RK を考える
      - すべてのクエリでメッセージを取得する
        
        メッセージ ID を RK にいれる
      - すべてのクエリでルームごとに取得している
        
        RK にルーム ID を先頭に入れる
      - などなど詳細は Chapter6
    - Col を考える
      - RK に入らない必要なデータ
    - TS は使わない
  - クエリ例の説明
クラスタ構築
- Chapter8-12
  - クラスタの設計、構築、運用 (monitoring)
- HBase クラスタの構築
  - 完全分散モードでの運用 1/3 くらいやったことがある (会場)
- HBase クラスタの構築は難しい？
  - 例： @oranie 氏のツイート
  - Hadoop 経験がないとつらいから？
    - YARN
    - HDFS
    - ZK
  - それらについてそれぞれ設定、モニタリング、チューニング
  - 入門を考慮した結果として書籍のアプローチとして
    - Cloudera Manager でそれはできるよ、としたｗ
    - べつに Cloudera からお願いされてそうしたわけじゃないよｗ
- Cloudera Manager (CM) について
  - Cloudera が提供する CDH 管理アプリケーション
    - Demo ではなく動画で紹介 (さすが)
- まとめ
  - CM で HBase クラスタ構築も挫折なく徹底入門できるぞ
パフォーマンス・チューニング
- 書籍では Java VM GC のチューニング etc を取り扱っている
- 今回は MemStore (MS)
  - RegionServer(RS) のメモリ上の領域に保持されr追加されるデータは MS に保持される
  - 一定データ量、一定期間、一定更新回数で Flush
  - MS のサイズ総量による強制 Flush の例の説明
  - MS の設定値のまとめ
    - 資料はあとで公開される！
質疑
- #hbase_ca にツイートしてくれればそれに答える
- 執筆にどれくらいかかったんですか？
  - 半年くらいかかりました
  - Hadoop Conference 2014 が終わったあたりから執筆した
- Cloudera Manager 徹底入門になってるのは脅されたりしてないですよね？
  - ええ、まあ、はい
- BlockCache は本には書いてある
  - 文字だけだとわかりにくいかもしれないが

19:50 HBaseサポート最前線 Cloudera株式会社　小林大輔氏

順番いれかえがあった
実際に Cloudera でサポートを行っていて気になったことを共有。
- 深入りはしないが、、、、
- だいぶ安定しているが、 Upgrade が絡むと問い合わせが多い
- Security 関連のトピックも多い
Cloudera Support と HBase
- 数字で見ると
  - 5 年
    - サポートは開始から 5 年
  - 20,000 Nodes
    - 総サポートノード数 (HBase の )
  - 60%
    - HBase の使用率 (Cloudera Support を購入している顧客の HBase 使用率 )
- Cloudera では社内サポート・システムに HBase を採用している
  - CSI
  - 全文検索システム
    - 過去の事例は調査に貴重な資源
    - Community におけるやりとりも資源
  - スタックトレース検索システム
    - 類似のスタックトレースを検索できる仕組みもある
クラスタ構築時の注意点
- THP (Transparent Huge Page) は無効にする
  - Linux のメモリ管理
  - 有効になっていると深刻なパフォーマンス劣化
- Region 数の見積もり
  - Region が多すぎると MTTR の増加、パフォーマンス劣化につながる
  - MemStore サイズと書き込み量から見積もる
    - MemStore のサイズ / フラッシュサイズ = サーバあたりのリージョン数
  - 全データ量とリージョンサーバ数から見積もる
    - （（全データ量 * 1024） / リージョンサイズ） / リージョンサーバ数 = サーバあたりのリージョン数
- HBase 徹底入門を読もう！
  - 201501 時点での最新情報が網羅されているゥ
  - 実践がベースになっている
- リージョンスプリットポリシー
  - IncreasingToUpperBoundRegionSplitPolicy
    - CDH 4.2 以降でデフォルトのスプリットポリシー
      以下のふたつで小さい方を採用
      - リージョン数 ^3 *1 * フラッシュサイズ * 2
      - hbase.hregion.max.filesize
    - リージョンをクラスタ全体へ分散し、パフォーマンス向上を図ることが目的
    - ローリング再起動時にリージョン数が増加する場合がある *2
HBase トラブルシューティング例 (CDH5.2.1)
- トラブルの種類
  - リージョン不整合
    - 処理中に突然サーバ電源が落ち、メタ情報に食い違いが起こる
    - hbck ユーティリティをつかう (取り扱いには当たり前だが重々注意)
      - hbck - details > /tmp/hbase_`date`.txt をやろう
        
        Region Consisutency (一貫性)
        
        META, HDFS 内の .regioninfo 実際のリージョンアサイン状況がすべて合致しているか？
        
        不整合が起きてしまっていたら (3 つの例を紹介)
        
        Region Consistency の確認修復を行う
        
        hbck -fixAssingnments -fixMeta で修復可能
        
        実行前に直前の状況をファイルに出力しておくこと
        
        Inegrity (整合性)
        
        修復は hbck -repairHoles で修復可能
      - 最後に表示される不整合件数が 0 ならば問題ない
        
        0 inconsistencies detected
  - 高負荷時の GC (巻きになっていたので全ては書きとれていない→資料を読まれたい)
    - 特に書き込み過多の場合は GC チューニングが必要となる
    - Region Server は高負荷時に GC の影響を受けやすい
    - GC による影響を疑うときのキーワードは slept
    - 詳細発生時刻付近に以下のようなメッセージがでたえないか？
      - We slept xxxx ms instead of xxxx ms this is likely ....
      - Detected pause in JVM ....
    - GC の推奨オプション (詳細なログを出す。出したログは可視化することをオススメする)
      - PrintPromotionFailure
        
        CMS はコンパクションを行わないため、断片化
      - PrintFLSStatistics=1
      - PrintTenuringDistrigbution
  - ホットスポット
    - 徹底入門にあつくカバーされているのでここでは割愛
資料はもちろん公開予定

20:20 HBase活用事例 Cloudera株式会社　嶋内　翔氏

時間は 10 分ほどで巻きに巻くことに
- 最近サポートをクビ (?!) にセールスエンジニア？
HBase は素晴らしい！言うならばそれは SKVS ！
- 今日はこれだけ覚えていけばよし！
HBase に格納するデータの種類
- エンティティ
  - 現在の状態についての情報
  - 顧客情報、ユーザ情報、位置情報、クリック数のメトリクス
- イベント
  - 連続的な時系列のデータ
  - センサー、メトリクスの履歴、株のティッカー
HBase の活用事例を 2 つ紹介 (時間がないので 1 つだけを紹介)
- 医療系 IT システム
  - 医療データの蓄積と活用に HBase
  - 医療データは断片化されている
  - ある個人のデータが様ざまなシステムに散在している
  - データソースから https でデータを収集し Kafka に流す, Storm が Kafka からデータを取り出し HBase/HDFS に書き込む
    - Apache Kafka (なんで Kafka がいいのか、を熱く語ってくれた)
      - 分散メッセージキュー (pub-sub)
      - クラスタ、高可用性、スケーラブル、高信頼性
    - データ処理には Storm と MR を併用
      - Incremental 処理は複雑でエラーも多い
      - MR で後追い処理
    - HBase のデータを元に Solr のシャードを作成
  - フロントエンドアプリケーション
    - 画像検索
    - アラートシステム etc
  - 行キーをどうとるか？
    - クエリの対象は患者
      - 行キーに人をとる
さいごに
- Cloudera の HBase のトレーニングの紹介
  - HBaseMeetupTokyo2015
  - HBaseトレーニング受講先着 10 名には HBase 徹底入門を贈呈？ (予定？？？？)
- HBase の認定スペシャリスト試験もあるよ
- お祝いのメッセージ
  - Jonathan HSieh (@jmhsieh) より