HBase シリーズ - HBase 基本概念#
内容整理自:
- Github リポジトリ: God-Of-BigData/HBase シリーズ
基本概念#
データの HBase における論理的な配置：
| Row-Key | Value（CF、Qualifier、Version） |
|---|---|
| 1 | info {' 姓 ': ' 張 '，' 名 ':' 三 '} pwd {' 密码 ': '111'} |
| 2 | Info {' 姓 ': ' 李 '，' 名 ':' 四 '} pwd {' 密码 ': '222'} |
データの HBase における物理的な配置：
| Row-Key | CF | タイムスタンプ | セル値 |
|---|---|---|---|
| 1 | info | 123456789 | 張 |
| 1 | info | 123456789 | 三 |
| 2 | info | 123456789 | 李 |
| 2 | info | 123456789 | 四 |
Row key (行キー)#
-
Row Keyはレコードを検索するための主キーであり、HBase 内のデータにアクセスするには Rowkey、Rowkey の範囲、または全表スキャンの 3 つの方法しかありません。全表スキャンは性能が非常に悪いです。 -
Row Keyは任意の文字列であり、保存時に辞書順でソートされます。注意が必要です:- 辞書順での Int のソート結果は 1,10,100,11,18,19,2,20,21,…,9,91,...,99 です。整数型の文字列を行キーとして使用する場合、整数の自然順を維持するために、行キーは 0 で左詰めする必要があります。
- 行の一度の読み書き操作は原子的です（何列を一度に読み書きしても）。
Column Family (列族)#
HBase テーブル内の各列は、特定の列族に属します。列族はテーブルのスキーマの一部であるため、列族はテーブル作成時に定義する必要があります。列族のすべての列は列族名をプレフィックスとして持ちます。例えば、info:ln、info:fnはすべてinfoという列族に属します。
Column Qualifier (列限定子)#
具体的な列名と理解できます。例えば、info:ln、info:fnはすべてinfoという列族に属し、それぞれの列限定子はlnとfnです。列限定子はテーブルスキーマの一部ではないため、データ挿入の過程で動的に列を作成できます。
Column (列)#
HBase の列は列族と列限定子で構成され、:（コロン）で区切られます。したがって、完全な列名は列族名：列限定子として表現されるべきです。
Cell#
HBase においてrow keyとcolumnによって決定されるストレージユニットをCellと呼び、行、列族、列限定子の組み合わせであり、値とタイムスタンプを含みます。
TimeStamp (タイムスタンプ)#
各Cellは同一データの複数のバージョンを保存します。バージョンはタイムスタンプによってインデックスされ、タイムスタンプの型は 64 ビット整数です。タイムスタンプは HBase がデータ書き込み時に自動的に割り当てることも、クライアントが明示的に指定することもできます。各Cell内の異なるバージョンのデータはタイムスタンプの降順で並べられ、最新のデータが最前面に配置されます。
Rowkey 設計原則#
Rowkey の分散
HBase の行は RowKey の辞書順でソートされています。これは Scan 操作に非常に優れています。なぜなら、RowKey が近い行は常に近い位置に保存され、順次読み取りの効率はランダム読み取りよりも高いからです。しかし、大量の読み書き操作が常に特定の RowKey 範囲に集中すると、Region のホットスポットが発生し、RegionServer の性能が低下します。したがって、適切に RowKey を分散させる必要があります。
RowKey の長さを制御
- HBase の底層ストレージ HFile では、RowKey は KeyValue 構造の一部です。RowKey の長さが 100B の場合、1000 万件のデータ中、RowKey だけで約 1G のスペースを占有し、HFile のストレージ効率に影響を与えます。
- HBase には MemStore と BlockCache が設計されており、それぞれ列族 / ストアレベルの書き込みキャッシュと RegionServer レベルの読み取りキャッシュに対応しています。RowKey が長すぎると、キャッシュ内のデータの密度が低下し、データの落ち着きやクエリ効率に影響を与えます。
RowKey の一意性を保証
ストレージ構造#
Regions#
-
HBase テーブル内のすべての行は
Row Keyの辞書順で並べられます。HBase テーブルは行キーの範囲（row key range）によって水平方向に複数のRegionに分割されます。1 つのRegionは start key と end key の間のすべての行を含みます。 -
各テーブルは最初に 1 つの
Regionしか持たず、データが増え続けるとRegionはどんどん大きくなります。ある閾値に達すると、Regionは 2 つの新しいRegionに分割されます。テーブル内の行が増え続けると、ますます多くのRegionが存在することになります。 -
Regionは HBase における分散ストレージと負荷分散の最小単位です。これは異なるRegionが異なるRegion Serverに分散できることを意味します。しかし、1 つのRegionは複数のサーバーに分割されることはありません。
Region Server#
Region Serverは HDFS の DataNode 上で実行されます。以下のコンポーネントを持っています：
- WAL (Write Ahead Log，予写ログ)：永続ストレージに進む前のデータ記録を保存し、障害発生時に回復するために使用されます。
- BlockCache：読み取りキャッシュ。頻繁に読み取られるデータをメモリに保存し、ストレージが不足すると
最近最少使用原則に従って余分なデータを削除します。 - MemStore：書き込みキャッシュ。ディスクに書き込まれていない新しいデータを保存し、ディスクに書き込む前にそれをソートします。各 Region の各列族には 1 つの MemStore があります。
- StoreFile ：StoreFile の底層は
HFileであり、HFile は Hadoop のバイナリ形式のファイルで、行データを Key\Values の形式でファイルシステムに保存します。
Region Server がサブテーブルにアクセスする際、Region オブジェクトを作成し、テーブルの各列族に対してStoreインスタンスを作成します。各Storeは 0 個またはそれ以上のStoreFileに対応し、各StoreFileは 1 つのHFileに対応します。HFile は実際に HDFS 上に保存されているファイルです。
システムアーキテクチャ#
HBase システムは Master/Slave アーキテクチャに従い、3 種類の異なるコンポーネントで構成されています：
Zookeeper
- いつでもクラスタ内に 1 つの Master のみが存在することを保証します。
- すべての Region のアドレスエントリを保存します。
- Region Server の状態をリアルタイムで監視し、Region Server のオンラインおよびオフライン情報を Master に通知します。
- HBase のスキーマを保存し、どのテーブルがあり、各テーブルにどの Column Family があるかなどの情報を含みます。
Master
- Region Server に Region を割り当てます。
- Region Server の負荷均衡を担当します。
- 無効な Region Server を検出し、その Region を再割り当てします。
- GFS 上のゴミファイルを回収します。
- スキーマの更新リクエストを処理します。
Region Server
- Region Server は Master から割り当てられた Region を維持し、Region 上の IO リクエストを処理します。
- Region Server は、実行中に過度に大きくなった Region を分割します。
コンポーネント間の協力#
HBase は ZooKeeper を分散調整サービスとして使用して、クラスタ内のサーバー状態を維持します。Zookeeper は利用可能なサービスリストを維持し、サービス障害通知などのサービスを提供します：
- 各 Region Server は ZooKeeper 上に一時ノードを作成し、Master は ZooKeeper の Watcher メカニズムを通じてノードを監視し、新たに参加した Region Server や障害で退出した Region Server を発見できます。
- すべての Master は ZooKeeper 上で同じ一時ノードを競争的に作成します。ZooKeeper は同名のノードを 1 つしか持てないため、必ず 1 つの Master のみが成功して作成されます。この時、その Master が主 Master となり、主 Master は定期的に ZooKeeper にハートビートを送信します。バックアップ Master は Watcher メカニズムを通じて主 HMaster の所在ノードを監視します。
- 主 Master が定期的にハートビートを送信できない場合、その保持している ZooKeeper セッションは期限切れとなり、対応する一時ノードも削除されます。これにより、そのノードに定義された Watcher イベントがトリガーされ、バックアップの Master Servers に通知されます。すべてのバックアップ Master Servers は通知を受け取った後、再度競争的に一時ノードを作成し、主 Master の選挙を完了します。