Lars George氏にサインをもらいに”書籍『HBase』刊行記念著者Lars George氏来日特別セミナー”へ行ってきた

HBase: The Definitive Guideの日本語翻訳版、HBaseの刊行イベントで原著者の Lars George 氏のサインがもらえるということで、行って来ました。

ほとんど目的は、サインをもらいにいくことではありましたが、メモはまじめにとってきたので、共有したいと思います。

開催概要
日時：2012年10月12日
場所：ベルサール神保町
主催：Cloudera株式会社、株式会社オライリー・ジャパン

プログラム

18:30 受付開始

19:00 開演ご挨拶とLars George 氏紹介

19:10 大規模分散データベースHBaseの活用と最新動向〜『HBase』著者 Cloudera社　Lars George 氏（逐次通訳付）〜

20:10 『HBase』書籍の読みどころ、翻訳うらばなし〜『HBase』翻訳者 Sky株式会社　玉川竜司氏〜

20:35 Cloudera UniversityとHBase認定試験〜Cloudera株式会社　川崎達夫氏〜

20:50 Lars George 氏サイン会（書籍を購入/持参の方）

21:10 閉会

18:30 受付開始

19:00 開演ご挨拶とLars George 氏紹介

原書がでてから、翻訳がでるまでのトレンドのギャップの変化を拾うためのイベント。
原著者をお招きできるのはなかなかないこと、サインをもらえるのは貴重な機会。

19:10 大規模分散データベースHBaseの活用と最新動向〜『HBase』著者 Cloudera社　Lars George 氏（逐次通訳付）〜

HBase in Japan

Lars George HBase Seminar with O'REILLY Oct.12 2012 from Cloudera Japan

▶ Self introduction

twitter: @larsgeorge

Apache HBase and Whirr committer.
Oreilly's HBase book author.

▶ Agenda

HBase の紹介
プロジェクトの現状
クラスターのサイジンング

＊

HBase に触ったことがない方をカバーできる内容

▶ HBase の紹介

分散、列指向、多次元、高可用性、高パフォーマンス、ストレージシステム

＊

プロジェクトの目的
数十億の行、数百万の列、数千のバージョン
→数千のコモディティサーバーを通じたPBクラスのデータ量を処理
- この目的は達成した

＊

DBという言葉はあえてさけた、 RDB と混同してはいけないので。データストレージと表現。

▶ HBaseテーブル

ロジカルにはスプレッドシートのようなもの

＊

Rowkey
- ソートできる

＊

バージョンがある
- A3.v1, B3.v3, C3.v1, D3.v2 .....
  - （スプレッドシートで各セルにドロップダウンボタンをつけるイメージ）
- 過去のバージョンのデータもみることができる

＊

Region
- Column Family の説明
- 論理的に、縦横に分かれて管理される
- 物理的にもその単位でディスク上に存在している

＊

図解のため、ここは資料が公開されたら、再度見返したい。

▶ HBaseのテーブルとは

テーブルは行の辞書順でソート
テーブルスキーマは列ファミリーを定義するのみ
それぞれの列ファミリーは任意の列の数で構成
それぞれの列は任意の数のバージョンで構成
それぞれの列は挿入時のみに存在
一つの列ファミリーの列は一緒にソート、格納
テーブル名を除くすべては byte[]
- （テーブル、行、列ファミリ：列、タイムスタンプ）-> 値

▶ Java API

CRUD
get(R), put(CU), delete(D)
それに付け加えて、HBaseでは +SI
- scan: 任意の行の数をスキャン
- increment: 列の値をインクリメント
さらに +CAS
- get, check, put 操作の組み合わせ
- 完全なトランザクションがないことを補う

▶ その他の特徴

IOを効率よく行うバッチ操作
プッシュダウン式に術部処理するフィルタ
圧縮アルゴリズム
ブルームフィルタと時間ベースのストアファイル選択
アトミックな追記と puts + deletes
マルチオペレーション

などなど

▶ 最近のプロジェクトの状況

0.90 の進化した概念
マスターの書き直し
行の中でのスキャニング
アルゴリズムとデータ構造の最適化
CDH3

＊

0.92 のコプロセッサ（現場、ポピュラーなバージョン）
マルチデータセンターレプリケーション
任意のアクセス制御
コプロセッサ
CDH4

＊

0.94 はパフォーマンスリリース
CRC読み込みの改善
シークの最適化
WAL圧縮
プレフィックス圧縮
アトミックな追記
アトミック put + delete
マルチインクリメントとマルチアペンド
リージョンごとの複数行トランザクション
CDH4の新しいバージョンで実装かな、と。

＊

0.96 特異性というラベリングがされている
Protobuf RPC
ローリングアップグレード
複数バージョンのアクセス
Metrics V2
プレビュー技術
- スナップショット（バックアップに）
- PrefixTrieブロックエンコーディング
CDH5になるかなぁ、と。

▶ クラスタのサイジング

ここから後半戦：

顧客とのやり取りの中で培ったナレッジの共有

▶ リソースの競合

読み込み、書き出しで同じ低レベルリソースを奪い合う
HDFSとネットワークIO
- RPC ハンドラとスレッド
その他、完全に別々のコードパスを実行しているのだけども。

▶ メモリの共有

デフォルトでは各リージョンサーバはメモリを次のように割り当てる
40% をインメモリストア
20％をブロックキャッシング
のこりはオブジェクトなどの一般的なJava heapにあてる
メモリの共有には微調整が可能（以降で）

▶ Reads

リージョンサーバの適切な配置とリクセストの配分
（プリフェッチを指定するオプションが存在する）
可能ならば時間の範囲指定かブルームフィルタを利用してストアファイルを削除
ブロックキャッシュを試し、もしブロックが見つからなければディスクから読み込む

▶ ブロックキャッシュ

デフォルトは20%
有効性の確認には出力しているメトリクスを確認
（ヒット率と同時に排除率を満たしているか？ランダムリードは理想的ではない）
ブロックキャッシュは絶対に必要

▶ 書き込み

クラスタサイズは書き込みパフォーマンスによって決定されることが多い
Log structured merge tree base
変更履歴をインメモリストアとWALの両方に格納
負荷が高い時、一定のしきい値（デフォルト40％）に基づき集約されたソートマップをフラッシュ
ペンディング状態の変更がないログは破棄
ストアファイルの定期的なコンパクションを実行

▶ 書き込みのパフォーマンス

クラスタ全体の書き込みパフォーマンスにある多数のファクター
クラスタ全体の書き込みに影響する要因
キーの分散→リージョンのホットスポット回避
ハンドラ→すぐ枯渇しないように考慮する
WAL→第一のボトルネック
コンパクション→間違ったチューニングは増加し続けるバックグランドノイズの原因に

▶ WAL

現在のところリージョンサーバーに1つしかない
全ストアで共有
ファイル追記の呼び出しで同期

＊

WALの不可軽減のためには
- WAL圧縮→開発中、0.94 (CDH4)
- リージョンサーバにつき複数のWAL→ノードごとに複数のリージョンサーバーを起動する
- デフォルトのブロックサイズの95％に設定する→コンフィグ確認すること
- 復旧時間を削減するために低い数字を保持、リミットは32まで
- ログサイズを大きくするとともにブロッキング前のログの数を増やす（あるいはどちらか）
- 書き込みの分布及びフラッシュの頻度にもとづいて数値を計算
- 書き込みは全ストア間で同期させる→・1つの列ファミリーに巨大なセルがあるとほかの書き込みすべてが停止する。・この場合RPCハンドラは動くかブロックされるかの二択になる
- 書き込み時にWALを回避することができるが、これは本当の耐障害性やレプリケーションを失うことを意味する（非推奨）
- 依存データセットをリストアするために、コプロセッサを利用することも可能かもしれない（preWALRestore）