#garagekidztweetz

#garagekidztweetz

id:garage-kid@76whizkidz のライフログ・ブログ!

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

▶ 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)
▶ フラッシュ
  • すべての変更(put, get)のための呼び出しは、フラッシュのチェックの原因になる
  • 閾値に達したらディスクへのフラッシュとコンパクションのスケジューリングを行う
▶ コンパクションストーム
  • ログの数が多すぎる、あるいはメモリ使用量が逼迫することにより早過ぎるフラッシュが発生する→ファイルは設定したフラッシュサイズより小さくなる
▶ 依存関係
  • たったひとつのトリガーがあれば、フラッシュは全ストア・列ファミリ間で起こる
  • フラッシュサイズは結合されている全ストアサイズと比較
  • 多くの列ファミリはサイズが小さい
  • 列のコンビネーションの和のサイズ
    • e.g. 55MB + 5MB + 4MB
    • 閾値との比較
▶ (HBase に関連した)数値について
  • 一般的なHDFSの書き込みスピードは、35-50MB/sec
  • 速度が低い現実的な数字では、15MB/sec かそれ以下
  • ここはのちほどスライドを。
▶ 注釈
  • リージョンxのフラッシュサイズに基づき、memstore サイズを計算
  • フィルおよび比率に基づき、保存するログの数を計算
  • 最終的に容量は
    • Java Heap、リージョン数とサイズ、キーの分散で決まってくる
▶ Cheet Sheet
  • WALの実行時に十分な性能があることを確認
    • 利用できる memtore 領域の許容範囲を超えてクライアントが利用しないことを確認
  • フラッシュサイズは大きすぎないか
  • 1ノードにつき、より多くのデータを格納できるように圧縮を有効にする
  • いくつかのレベルでバックグランドIOを固定するため、コンパクションアルゴリズムを変更
  • 別のテーブルに不均一の列ファミリをおくことを考慮

全部は書ききれてないのでスライドがシェアされたらチェック。

▶ 例
  • 10GB のjava Xmx heap
  • memstore は40%使う
  • 推奨するフラッシュサイズは128MB
    ( 4GB / 128 MB = 最大32 リージョン)
  • WALサイズは 128MB x 95%
  • 20GBのリージョンサイズ
    (20GB x 32リージョン=640GBの生ストレージを使用)
▶ QA

Q1:OpenTSDB - A Distributed, Scalable Monitoring Systemを使ったことがあればその評判

  • スキーマデザインをする際に例としてよく使ってる
  • とてもオススメ
  • そのクリエイターはHBaseのコミッターであり、Cloudera にジョインした
  • いいサポートもできるとおもう

Q2: To avoid WAL bottleneck, you suggest multiple WAL, but it might cause more big recovery cost issue.

  • How to handle that issue, how do you think?
  • That's right though. Having 3-4 WAL and switching that number seeing performance, that is the good idea.

Q3:Seek optimization

  • HBaseサイドのみ
  • lazy seek (lazy block load と呼んだほうがいいとおもってる)
  • 不必要なファイルのリカバリについては除けることができる

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

▶ 翻訳した著作
  • Hadoop, Hadoop MR design pattern, Jenkins, AWS programming, HBase etc, etc...
  • 年間で 1200ページほどの翻訳
▶ 翻訳の一日
  • くたびれるまでひたすら翻訳
  • 合間合間でごはんたべたり、Facebookしたり
  • twitter: @tamagawa_ryuji
▶ いつも悩むのは
  • 進出用語をどうするか?
  • たとえば、region server
    • 象本では、領域サーバー
    • 馬本では、リージョンサーバー
    • 象本3版ではリージョンサーバーにするつもり
▶ 今後の予定、ようは宣伝
  • 今日の内容がちんぷんかんぷんなら馬本を手に取れ。
  • MongoDB in Action の本が出る
  • 象本第3版
  • Hadoop Operation
  • Hive本
▶ 最後
  • この後の翻訳ができるかどうかは、みんなが買ってくれるかどうかにかかってるw

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

▶ 持ち時間は5分w
▶ Clouderaではいろんな研修やってる、認定資格もあるよ(CCSHB)
  • 馬本を買っても分からないことは多いはず
  • 短期間で習得の手助けできるよ
  • HBase の問題の多くは間違った設定が原因だぜえ
  • 使えないっていう前に、本読もうぜえ

  • 独学するなら馬本を
  • 短期集中ならトレーニング
  • スキル証明するなら資格とろう

現状、わたしは HBase 本は 4 割ほどしかまだ読めてないので、まずは頑張って読みきらねばという気持ちを強くしたセミナーでした。

こちらもあわせてどうぞ