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 を検出できます。
- すべての Masters は ZooKeeper 上で同じ一時ノードを競争的に作成します。ZooKeeper は同名のノードを 1 つしか持てないため、必然的に 1 つの Master のみが成功して作成されます。この時、その Master が主 Master となり、主 Master は定期的に ZooKeeper にハートビートを送信します。バックアップ Masters は Watcher メカニズムを使用して主 HMaster のノードを監視します。
- 主 Master が定期的にハートビートを送信できない場合、その保持している ZooKeeper セッションは期限切れになり、対応する一時ノードも削除されます。これにより、そのノードに定義された Watcher イベントがトリガーされ、バックアップの Master Servers に通知されます。すべてのバックアップの Master Servers は通知を受け取った後、再度競争的に一時ノードを作成し、主 Master の選挙を完了します。