近々、検証を行う予定の HBase 、多少なりともその知識を深めることを目的に「第2回 HBase 勉強会」に参加してきました。
用語を知っている程度での参加だったので、大分ついていけないところがありましたが、可能な範囲でメモをとってきましたので、共有します。
1. HBase アーキテクチャ概要 （@ueshinさん）
サーバー構成
DataNode, TaskTracker, RegionServer, HMaster, Zookeeper
データモデル
GoogleのBigTable
行の特定にRow Key
あるカラムファミリーに対して任意の数のカラムをもてる
物理配置
物理的にはカラムファミリーごとに保存
リージョン
Row Keyの範囲によって分割された領域
リージョンのサイズが大きくなると自動的に分割されていく
256MB
ACID 特性
1つのRowに対するロックを取得できる
Row内のデータの更新をAtomicに実行することを可能
Row内のデータのConsistencyは
保証される
複数のRowにまたがる更新のAtomicityは
確保できない
カラムファミリーがたくさんあってひとつのリージョンにおさまらないときどうなるのか？
無限major compaction
無限に圧縮し続ける
耐障害性
HDFSのNNがSPOF
実装
HMaster -> Zookeeper Cluster
Regionserver x 3
HDFS
Clientの第一声はZookeeperに
Zookeeperが死んでしまっていたら無限にHBaseからretryが発生して動作が進まない
書き込み
コミットログ追記
メモリキャッシュに追加
メモリキャッシュがいっぱいになったらフラッシュ
Compaction
- minor Compaction
- フラッシュファイルの数が閾値をこえると1つにまとめられる
- major Compaction
- リージョンに属するファイルを定期的に1つにまとめる
リージョン分割
フラッシュファイルのサイズが閾値をこえるとリージョン分割
1 親リージョンがオフラインに
2 METAに記録してHMasterに通知
3 HMasterが新規リージョンをアサイン
CDH3を使うことが基本的な考えになっている
Zookeeper専用のクラスタがあったほうが無難
負荷が高いと反応が遅い
奇数個つくるのはZookeeper的なルール
2. HBaseアーキテクチャ要件 （@okachimachiorz1 さん）
HBaseを業務要件から使う上でのまとめ
不安定
ある程度の規模があることが前提
HBaseのCluster上でMR動かさないよね
↓
一緒にしたほうがいいが理屈
特定の用途に制限的に利用することで問題が顕在化しないようにする
Hadoop MRで足りない部分を補う
フルスキャン前提
TxーTxデータの処理が遅い
Hadoopの次にいくには？
常にフルスキャンではないが、時々フルスキャンというデータ
マスター管理
オンライン・マスター的に利用する
低レイテンシー要件
フロントにはやはりRDBが必要
RDBMS→HBase→HDFS
ほぼ完全にMR用のサポートDBの位置づけ
受発注
基本的にトランザクション
伝票検索
特定キーと日付検索
問題のあったtxを任意で検索する
伝票処理
一括処理〜大抵はMRで処理する→ここはHDFSで処理が可能
逐次処理のためにHBaseが必要
要件アーキテクチャ
レイテンシー要求は高くない
在庫管理
在庫マスターの処理から考える
仮フラグの設定くらいしかないACID
いわゆる在庫マスターの更新処理を行う
業務ロック制御のための HBase
開けっ放しでのバッチ処理のための HBase
要件アーキテクチャ
ロック制御
HBase だとコピーアクションがいらない
基幹であればフラグのたったレコードをダンプして後続処理を走らせる
原価計算
計算はバッチ処理
確定処理とシュミレーション処理
同期の必要はない
結果の再利用のための HBase
物流管理
リレーションデータとの結合
各マスターとのぶつけ合いが多い
他システムとの連動ためのHBase
Planning 系と Execution 系での利用
普通は別システム
受け渡しは必要。
planning 系に Hadoop は強くなるのではないかという予測
製造管理
分散MRP
Oracleの牙城を壊せるか？？
実はHBaseが大本命？
ノード単位でのデータロケーションの管理
やると全世界的に大尊敬
生産管理のメモ
歴史と現状
生産管理に分散アーキテクチャを導入
目的
スケールアウト
非同期処理の高速化
疎結合による簡素化
→そのかわりレイテンシーがあがるトレードオフ
原子力発電管理
プラント系
シミュレーション
センサーデータの収集分析
リアルタイム性の厳密な管理
組み込みの直接制御
マトリックスみたいな感じのやつを頼む
原発管理をHBaseでやってみるとか
リアルタイムシミュレーションとか有効？
販売処理管理
ハイトランザクションを想定
低txの場合はExcelでOK
集配信→ HBase → HDFS → RDB
（分散書き込み→非同期処理→分散書き出し）
Consistencyが保てないと思った瞬間にHBaseは止まる
余談
1. 止まったときはデータがどこにあるのか把握することが大事。
↓
ないならないでいい（はっきりさせることが大事）2. 世の中の7割のRDBは、高機能ファイルサーバーとしての用途
3. HBaseの用途
分散 Memtable
書き込むデータをメモリ上に
ソート済
それぞれのデータはキー順に整列
隣のレコードという概念がある
接頭辞スキャンなど範囲読みだしが可能
バーストリード
Column Family
ファイルごとにわかれている
ファミリの更新が閉じる
テーブルが同じだとリージョンも同じ
普通の用途
OLTP＋インクリメンタル処理
オンライン性能をそれほど劣化させずにバックグランド処理
複数のバックグランド処理でお互いが干渉しにくい
やりたいこと
締め処理を速くしたい
前提
入力データは BigData まではいかない
小さなマスタが多い
巨大なマスタがある
tx の全件照合などの破滅的な処理
PA の効果は限定的
分散 Memtable
バッチ処理ではあまり恩恵をうけられない
多くの書き込みが Bulk
暇ならリバランスの戦略と相性が悪い
ソート済
一定期間のもののみ対象になどと相性はよさそう
小さなマスタに
Column Family
とても羨ましい機能
MySQL だと Update は Delete ＋ Insert と同じ程度の性能
更新パターンごとにバラして読み出し時にJoinしている
ここまでの考察では
HBase は役にたたない
↓
考え方を変える
Incremental
未確定の情報もどんどんとりこんでいく
先行して Materialized View をつくる
Column Family にマスタを結合しておく
使う順に並び替えておく
Emulated BSP
MR 以外の選択肢
事前に必要なマスタを Shard して配備
マスタを固定したまま tx だけ移動する
ロードや転送制御が MR よりわかりやすそう
集計や照合までに同期が不要に
用途によってはMRより適切
Full outer join / Partial Aggregation はMRの方が楽かも
4. @frsyukiさんの発表
MessagePack+Hadoop (HBase-study 2011-06-16 Japan)
MessagePack-Hadoop Integration (HBase勉強会) - 古橋貞之の日記
ログ収集ツール
ログ収集
↓
fluent
（バッファリング＆split(Message Pack File)
↓
↓定期的に保存（トランザクショナル）
↓
HDFS
（マージジョブでColumnar Fileを作成）
MessagePack＋Hadoop
MessagePack＋Hive
UDTL msgpack_map
Columnar File
columns.mapping
データをフレキシブルに投入し、抽出するときには定義を。
Appendix.
Location.
大きな地図で見る
- 作者: Lars George
- 出版社/メーカー: Oreilly & Associates Inc
- 発売日: 2011/09/20
- メディア: ペーパーバック
- 購入: 1人 クリック: 27回
- この商品を含むブログ (5件) を見る
