devkuma – HBase

Apache HBase 概要

kc@example.com (kc kim) — Fri, 08 Jul 2022 09:37:00 +0900

HBase とは？

Apache HBase は、米国 Apache Software Foundation が開発し公開しているオープンソースの分散データベース管理システムである。データベースの主流であるリレーショナルデータベースとは異なる構造を持つ NoSQL システムの一つである。

Google が開発し社内システムで内部的に使用している BigTable をモデルに、類似した構造や機能を持つデータベース管理システムをオープンソースソフトウェアとして再現したものである。

同じく ASF が開発して公開している分散ファイルシステム HDFS (Hadoop Distributed File System) を基盤としてデータベースを構築する。リレーショナルデータベースと同じようにテーブル形式でデータを構造化するが、一般的な RDBMS とは異なり、各カラムの値をまとめてストレージ上に記録する。この方式をカラム指向型と呼ぶ。

テーブルの各行 (row) には、カラム名に相当する qualifier と、フィールド値に相当する cell という単位のデータのペアを単位としてデータを保存する。そして、複数の qualifier が column family としてグループ化されている。cell のデータは自動的に履歴管理され、過去の任意時点のデータを呼び出すことができる。

複数のサーバーコンピュータで 1 つのデータベースを管理する分散環境を前提に設計されており、データを複数ノードに分散して記録するシャーディングを自動的に実行する。そのため、アプリケーション側で対象を意識する必要がなく、データの一貫性も強く確保され、処理中に古いデータが外部から参照されないようになっている。

データベース操作は、RDB のような SQL ではなく、Java API や RESTful API などの形式で提供される API をアプリケーションから呼び出して行う。Apache Hadoop の MapReduce など、ビッグデータの大規模分散処理に適している。

HBase は SQL データベースを置き換えるソリューションではないが、Apache Phoenix のようなソフトウェアを使って SQL レイヤーを追加できる。SQL レイヤーを追加すると、JDBC ドライバなどを使い、さまざまな分析作業を慣れた方法で簡単に処理できる。

Apache HBase|GitHub

HBase の歴史

年	イベント
2006年11月	Google が BigTable の論文を発表した。
2007年2月	初期 HBase プロトタイプが Hadoop へのコントリビューションとして作成された。
2007年10月	Hadoop 0.15.0 とともに利用可能な最初の HBase がリリースされた。
2008年1月	HBase は Hadoop のサブプロジェクトになった。
2008年10月	HBase 0.18.1 がリリースされた。
2009年1月	HBase 0.19.0 がリリースされた。
2009年9月	HBase 0.20.0 がリリースされた。
2010年5月	HBase は Apache トップレベルプロジェクトになった。
2010年6月	最初の開発者版である HBase 0.89.20100621 がリリースされた。
2011年1月	HBase 0.90.0 がリリースされた。
2011年半ば	HBase 0.92.0 がリリースされた。

HBase の特徴

Apache HBase の重要な特徴をいくつか示す。

分散 (Distributed)

Apache HBase は、疑似分散 (Pseudo-distributed) モードと完全分散 (Fully distributed) モードの 2 つのモードで実行できる。疑似分散モードはテスト目的で使用され、単一ノードで実行される。一方、完全分散モードは本番環境で使用され、ノードクラスタ上で実行される。

ビッグデータストア

Apache HBase は、数十億行と数百万または数十億カラムを持つテーブルに非常に大きなデータを保存できるように設計されている。Hadoop HDFS 上で実行されるため、低レイテンシでデータに対するリアルタイムの読み書きが可能である。テーブルに保存された膨大なデータの読み取り処理に対して、より良い性能を提供する。

非リレーショナル (Non-Relational)

すでに述べたように、Apache HBase は非リレーショナルデータベースであるため、リレーショナルデータベースモデルには従わない。リレーショナルデータベース管理では、データは行と列の形でテーブルに保存される。そのデータへアクセスするには SQL 言語を使用できるが、Apache HBase の場合、データストレージは固定形式ではなく、独自のストレージおよびクエリメカニズムを使用する。Apache HBase ではスキーマは柔軟であり、要件に応じて拡張できる。

柔軟なデータモデル

Apache HBase は、テーブルにデータを保存できる柔軟なデータモデルを提供する。テーブルには 1 つ以上の column family がある。ユーザーのデータは、key/value ペアの集合である row に保存される。テーブル内の row は row key によって一意に識別される。

拡張可能 (Scalable)

Apache HBase の Region は、行が Region ごとに分散されるため水平スケールが可能である。テーブルは複数の Region に保存でき、Region が非常に大きくなると、同じ中央の row key を基準にデータが 2 つの Region に分割される。

HBase の機能

Apache HBase の機能は次のとおりである。

線形およびモジュール式のスケーラビリティをサポートする。
読み取りと書き込みの厳密な一貫性を提供する。
自動かつ設定可能なテーブルシャーディングを提供する。
RegionServer 間の自動 failover をサポートする。
Apache HBase テーブルで Hadoop MapReduce ジョブをサポートするための便利な基本クラスを提供する。
クライアントアクセスのために Java API を簡単に利用できる。
リアルタイムクエリのためのブロックキャッシュと Bloom filter を提供する。
サーバーサイドフィルタを通じてクエリ述語プッシュダウンを提供する。
拡張可能な JRuby ベース (JIRB) シェルを提供する。

HBase の長所と短所

HBase の長所

大容量データを安定して扱うのに効果的である。
- 中央で分散システム全体を制御する Master を置き、全体データの一貫性を管理することで、複製データ間の一貫性を保証する。
大量データの分析処理支援に適している。
- MapReduce の input として使いやすい。
- HDFS、MapReduce などと一緒に使用するのに最適化されている。
性能問題が発生した場合、Region server を追加するだけで性能を維持できる。
failover が容易で管理しやすい。

HBase の短所

MapReduce の input として使いやすいが、同時にファイル input と一緒に使用すると CPU 使用率が高くなり、Region server が容易に down する。
適切な HBase setting のための条件に関する資料はあるが、Cluster の規模や基本 Spec が異なるため、そのまま適用するのは難しい。
特定 Region server に特定 table の Region が集中しやすく、性能低下につながる。
- 構成時には HBase の適切な設計が必要である。

RDBMS と HBase の違い

リレーショナルデータベースと HBase の主な違いを見てみる。

RDBMS	HBase
テーブルをデータベースとして使用する。	Region をデータベースとして使用する。
サポートされるファイルシステムは FAT、NTFS、EXT である。	サポートされるファイルシステムは HDFS である。
コミットログを使用してログを保存する。	WAL (Write-Ahead Logs) を使用してログを保存する。
使用される参照システムは coordinate system である。	ZooKeeper で使用される参照システムである。
Primary key を使用する。	Row key を使用する。
Partitioning がサポートされる。	Sharding がサポートされる。
Row、Column、Cell を使用する。	Row、Column family、Column、Cell を使用する。

HDFS と HBase の違い

HDFS と HBase の主な違いを見てみる。

HDFS	HBase
HDFS は分散保存のためのファイルシステムを提供する。	HBase はテーブル形式のカラムベースデータストレージを提供する。
HDFS は大容量ファイルに最適化されたストレージを提供する。	HBase はテーブル形式データに対する最適化を提供する。
フラットファイルを使用する。	key-value ペアのデータを使用する。
データモデルは柔軟ではない。	柔軟なデータモデルを提供する。
ファイルシステムと処理フレームワークを使用する。	Hadoop MapReduce サポートを内蔵したテーブル形式ストレージを使用する。
ほとんど write-once-read-many に最適化されている。	多くの読み書きの両方に最適化されている。

行指向データストアとカラム指向データストアの違い

行指向 (Row-oriented) データストアとカラム指向 (Column-oriented) データストアの主な違いを見てみる。

行指向データストア	カラム指向データストア
行指向データストアはレコードの追加/修正に効率的である。	カラム指向データストアはデータ読み取りに効率的である。
行全体を含むページを読み取る。	必要なカラムだけを読み取る。
OLTP システムに最も適している。	まだ OLTP システムには適していない。
行全体の値をシリアライズする。	カラム全体の値をシリアライズする。
メモリの連続ページに行を保存する。	ページのカラムをメモリに保存する。

OLTP (Online Transactional Processing) とは、オンライントランザクション処理を意味し、ネットワーク上のオンラインユーザーによる Database に対する一括トランザクション処理を指す。

カラム指向データベースの長所と短所

カラム指向データベースの長所と短所を見てみる。

長所

効率性およびデータ圧縮に対するサポート機能が組み込まれている。
高速なデータ検索をサポートする。
カラム指向データベースでは管理と構成が単純化される。
COUNT、SUM、AVG、MIN、MAX などの集計クエリに対する高性能に適している。
より大きな Region をより小さな Region に分配する自動シャーディングメカニズムを提供するため、partitioning に効率的である。

短所

複数テーブルの JOIN クエリおよびデータが最適化されていない。
頻繁な削除と更新のために partition を作成する必要があり、ストレージ効率が低下する。
非リレーショナルな特性上、partition と index の設計が非常に難しい。

HBase のユースケース

データ一貫性を保証するため、または分析などの用途で使用する。
- 例: Facebook、eBay、Adobe、LINE など。
監視システム (Monitoring system)。
ユーザー操作の追跡 (Tracking user actions)。
監査ログシステム (Audit logging systems)。
リアルタイム分析 (Real-time analytics)。
- Hadoop を使用して大量データを分析する必要がある場合。
大規模 SNS サービスのメインストレージとして利用。
- メッセージ中心システム (Twitter に似たメッセージおよびステータス)。
HBase からコンテンツを提供するコンテンツ管理システム。
Web クローリング中の Web ページ保存のような標準的なユースケース。

参考資料

Apache HBase アーキテクチャ

kc@example.com (kc kim) — Fri, 08 Jul 2022 09:40:00 +0900

Apache HBase Architecture

Apache HBase は NoSQL データベースである。NoSQL は、データベースが SQL を基本アクセス言語としてサポートする RDBMS ではないことを示す一般的な表現である。Apache HBase は、従来の意味でのデータベースというよりデータストアである。HBase はクラスタに汎用ノードを追加することで、線形かつモジュール式に拡張できる。ノードを 20 個から 40 個に増やすと、HBase クラスタのストレージと容量も同時に増加する。

HBase クラスタアーキテクチャ

Apache HBase の構成要素

HBase は Master server と Region server の 2 種類のサーバーで構成される。
Region server を増設することで簡単にスケールアウトできる構造になっている。 HBase のデータは Region という単位に分割されており、Region の扱い方によってサーバーの種類が分かれる。

Master server - HBase HMaster

Apache HBase HMaster は、RegionServer の監視、障害処理、Region 分割管理を担当する HBase クラスタの重要な構成要素である。

各テーブルのデータは RegionServer が管理し、クラスタ全体は HMaster が管理する。
HMaster は、HBase のすべてのデータ (Region) がどの Region server に保存されているかというメタ情報を管理するサーバーである。
Region server に Region を割り当て、Region server の障害を検知する。

HMaster の機能は次のとおりである。

RegionServer を監視する。
- Region server を調整する。
- Region の起動を管理する。
RegionServer の failover を処理する。
Region を割り当て、または解除する。
クラスタ内のすべての Region server を監視する。
- 管理機能。
- テーブルの作成、削除、更新。
メタデータ変更を処理するために使用される。
すべてのメタデータ変更に対するインターフェースを提供する。
アイドル時間にリバランシングを実行するために使用される。
HMaster は HBase クラスタに関する情報を表示する Web ユーザーインターフェースを提供する。

これらの作業は、Master server 内で動作している ZooKeeper というソフトウェアが担当している。
ZooKeeper は HBase 以外にも多くの分散アプリケーションで使用されるソフトウェアである。

Region server - HBase Region Server

RegionServer は、Master server から割り当てられた実データの保存を担当する。Hadoop クラスタと同じように、NameNode はメタデータを保存し、DataNode は実データを保存する。HBase でも同様に、Master はメタデータを保持し、RegionServer は実データを保存する。RegionServer は分散クラスタ環境の DataNode 上で実行される。

RegionServer は次の作業を行う。

割り当てられた regions (tables) を処理する。
クライアントが実行する読み取りおよび書き込み要求を処理する。
キャッシュを HDFS に flush する。
Region 分割処理を担当する。
HLog を維持管理する。

クライアントはまず Master server、正確には ZooKeeper に問い合わせ、対象データ (Region) を保持している Region server の位置を取得する。

その後、その Region server がクライアントの要求を担当する。
Region は常に単一の Region server によって管理され、読み取りと書き込みに対するデータ一貫性を維持する。

Region server が down すると、割り当てられていた Region は別の Region server に failover される。この作業は Master server が実行する。
ただし、failover が完了するまで、クライアントは対象 Region に対して読み書きできない。

RegionServer の構成要素

RegionServer の構成要素を見てみる。

WAL (Write-Ahead Logging)

WAL とは、データ整合性を保証する標準的な方法であり、DB で使用される方式である。WAL を使用するシステムでは、データを修正する前にまず WAL に記録する。この記録を利用して、どの時点で障害が発生したか、どこまで成功し、どこから後続作業を実行すべきかを知ることができる。

PostgreSQL、HBase、MongoDB など、さまざまな DB システムで WAL 方式が使用される。

Apache HBase WAL は、編集ログファイルとも呼ばれる中間ファイルである。HBase でデータを読み取ったり修正したりするとき、ディスクに直接書き込むのではなく、一定時間メモリに保持する。そのため、システムが down するとメモリ上のデータが失われる可能性がある。この問題を克服するため、Apache HBase はデータをメモリに記録する前に、まず Write-Ahead Logging ファイルに記録する。

HFile

HFile は HBase にデータを保存するためのフォーマットであり、Column Family に属する。Column Family は複数の HFile を持つことができる。 Row データが物理的に保存される実ファイルであり、データは Key/Value 形式で保存される。 MemStore が十分に満たされると、HDFS に新しい HFile を作成して保存する。
ランダムアクセスを最小化する構造のため、この処理は非常に高速に行われる。

Store

HBase のテーブルに対する Column family に該当する。ここに HFile が保存される。

MemStore

MemStore はメインメモリに常駐し、現在のデータ操作を記録する。データが WAL に保存されると、Region Server のメモリストアに key/value データをソートして保存する。このデータをそのまま HFile に保存する。 1 つの Column Family ごとに 1 つの MemStore が存在する。

Region

Region は、key を基準に分割され、RegionServer でホストされるテーブルの分割単位である。

クライアント

クライアントは Java またはその他の言語で作成でき、外部 API を使用して実際の row データを管理する RegionServer に接続できる。クライアントは Region を探すために catalog table に問い合わせ、Region が見つかると、RegionServer に直接接続してデータ操作を実行し、高速検索のためにデータをキャッシュする。

Catalog table

Catalog table は、すべての RegionServer および Region に関するメタデータを維持するために使用される。

HBase には 2 種類の catalog table がある。

-ROOT- このテーブルには META テーブルの位置に関する情報がある。
.META このテーブルにはすべての Region とその位置に関する情報が含まれている。

ZooKeeper

Apache ZooKeeper は HBase のコーディネータのようなものである。HBase は ZooKeeper を利用して、クラスタを構成するサーバーの状態を管理する。構成情報の維持、命名、分散同期の提供、サーバーエラー通知などのサービスを提供する。クライアントは ZooKeeper を通じて Region server と通信する。

Apache ZooKeeper は、HBase に分散同期とグループサービスを提供する分散アプリケーション向けの高性能な集中型多重調整サービスシステムである。クラスタ調整を担いながら、ユーザーがアプリケーションロジックに集中できるようにする。また、ユーザーが Master server と連携できる API も提供する。

Apache ZooKeeper API は、一貫性、順序付け、耐久性を提供し、分散クラスタシステムに対する同期と同時実行性も提供する。

HBase データの書き込み/読み取りプロセス

HBase でデータを読み書きする過程について説明する。

HBase データ書き込み

HBase でデータを保存するときは、WAL (Write Ahead Log) と Region server の MemStore の 2 か所にデータを保存する。

この 2 つを利用し、WAL と MemStore の両方で変更が発生した時点で書き込み処理が正常に完了したことになる。

HBase にデータ投入要求が来ると、まず適切な Region server を探す。Region server を見つけると Commit log を追加し、メモリ内の MemStore に追加される。 MemStore に保存されていたデータは、設定された値に従っていっぱいになると HFile という形式でディスクに flush され、メモリを空けて再び要求を待つ。同時に WAL にもこれに関する記録を残す。 MemStore flush は hbase.hregion.memstore.flush.size の値を超える場合に発生し、単位は byte で 134217728 (128 MB) に設定されている。

MemStore は Region server のメモリ領域であり、キャッシュのような機能を持つ。そして、MemStore のデータが一定量集まった時点で、ディスク上に HFile としてデータを書き出して永続化する。
ただし、HFile に書き出す前のデータはサーバーのメモリ (MemStore) に保存されているため、サーバーが down すると消える。そのため、HBase はデータを書き込むときに HLog というログを残し、サーバーが down した場合は HLog をもとにデータを復旧できる。

HBase データ読み取り

HBase でデータを読み取る過程は、前述した HBase データ書き込み過程と似ている。

HBase に要求が入ると、まず MemStore を確認する。MemStore で目的のデータを見つけると、そのデータを返す。そうでない場合は、最近 flush されたファイルから古い順に、クエリを満たす適切なデータを見つけるか、これ以上 flush ファイルがなくなるまで繰り返す。

参考資料

HBase 紹介|joinc.co.kr

Apache HBase リージョン(Regions)

kc@example.com (kc kim) — Wed, 21 Jun 2023 11:05:33 +0900

Apache HBase は、行キーで辞書順にソートされたテーブルに大容量データを保存する。テーブルは複数のリージョン(Region)に分散され、リージョンはさらに複数の RegionServer に分散される。Apache HBase でテーブルを作成すると、デフォルトリージョンが割り当てられる。

Apache HBase リージョンは水平方向に拡張可能である。これには開始キーと終了キーが含まれ、該当する行を基準にソートされ、連続した形式で保存される。HBase は強い一貫性を提供するため、複数のリージョンに同じ行キーを保存しない。リージョンは複数の RegionServer に負荷を分散し、要件に応じて負荷分散とフェイルオーバーも行う。データが増加する場合、リージョンは手動または自動で分割される。

リージョン数

RegionServer ごとに中大規模(5-20GB)のリージョンを少数(20-200個)使用することが推奨される。リージョンの標準数は100個である。

リージョンを考慮する際のいくつかの要素を見てみよう。

リージョン数を選択する際の制限要因は、利用可能なヒープ領域である。MemStore にはリージョンごと、カラムファミリーごとにほぼ 2MB が必要であり、リージョンが100個、リージョンごとに3つのカラムファミリーがある場合、MemStore のヒープ領域要件は 600MB である。リージョンが少ないほど MemStore のヒープ要件は少なくなる。
多数のリージョンは、多数の小さな flush を生成する。各 flush が StoreFile を作成すると多数の StoreFile が作成されるため、より多くの compaction が必要になる。また、MemStore および StoreFile インデックスにはより多くのヒープ領域が必要である。
master が RegionServers にリージョンを割り当て、再割り当てする必要があるため、多数のリージョンは master に負荷を生む。また、master はロードバランシングのためにリージョンを移動する必要がある。

リージョン割り当て(Region Assignment)

Apache HBase でリージョンは、以下のように master によって割り当てられる。

master は assignment manager を開始する。
assignment manager は hbase:meta メタデータで既存の割り当てを確認する。
RegionServer が利用可能な場合、割り当ては保存される。
RegionServer がオンライン状態でなければ、load balancer が呼び出され、リージョンを別の RegionServer に割り当てる。
hbase:meta メタデータが新しい割り当てで更新される。

リージョンフェイルオーバー(Region failover)

RegionServer は失敗する可能性があり、複数の RegionServer がデータを提供するため、RegionServer のリージョンが利用できなくなることがある。ZooKeeper は RegionServer のエラーを検出し、master はリージョンに類似した Row Key を持つ別の RegionServer でフェイルオーバーを開始する。

リージョンローカリティ(Region Locality)

Region Locality は、RegionServer に対するリージョンの近接性を示す。これはクラスター全体で HDFS ブロックレプリケーションによって達成される。

レプリカ配置ポリシーは HDFS のレプリカ配置ポリシーであり、次のとおりである。

1つ目のレプリカはローカルノードに配置される。
2つ目のレプリカは別ラック(rack)の任意ノードに配置される。
3つ目のレプリカは2つ目のレプリカと同じラック(rack)に配置されるが、このときは別ノードに配置される。

リージョンの利点(Benefits of Regions)

リージョンの利点は、分散データストア、パーティショニング、自動シャーディングと拡張性、リージョン分割である。

それぞれ詳しく見てみよう。

分散データストア

分散データストアの設計は、テーブルに複数のリージョンを使用する Apache HBase の設計と一致する。ノードクラスター全体に大きなテーブルのリージョンを分散すると、高可用性を得られる。

パーティショニング

データテーブルは複数のリージョンに保存され、リージョンはデータを分割する。これで該当テーブルのデータにアクセスするには、別のリージョンからアクセスする必要がある。複数のリージョンがあれば、データを高速に配信できる利点がある。

自動シャーディングと拡張性

自動シャーディングプロセスは、リージョンの行キー数が多くなりすぎたときに、リージョンをおよそ2つの半分に分割するために使用される。HBase で水平拡張性の基本単位はリージョンであり、リージョンごとに行を共有する。

リージョン分割

しきい値を超えるとリージョンが分割される。これはリージョンを分割し、分割されたリージョンをオフラインにする RegionServer によって処理される。その後、2つの分割リージョンが hbase:meta に追加され、RegionServer で開かれ、master に報告される。リージョン分割は基本的に自動だが、手動で実行することもできる。HBase リージョン分割ポリシーは hbase.regionserver.region.split.policy で構成される。

HBase データモデル

kc@example.com (kc kim) — Tue, 20 Jun 2023 19:07:12 +0900

データ構造

HBase テーブルには型がなく、バイト配列(byte[])として保存される。
HBase の行は一意な行キーで昇順にソートされ、テーブルの値を読み書きするときはこの行キーを通じて行われる。
前述したように、HBase が管理するデータは一定範囲ごとにリージョンという単位で分割され、テーブルには複数のリージョンがある。また、HBase の列は Column Family という単位でグループ化される。
テーブルのデータはリージョンごとに分かれ、Column Family ごとに分かれてファイルへ出力される。ファイルは別々だが、同じリージョンであれば同じ Region Server に保存される。

HBase データ、つまりセル値にはそれぞれ timestamp が付与されており、バージョンが管理されている。ファイルは次の形式で保存される。

Row(Row Key): Column family: Column: timestamp: 値

データモデル

Apache HBase データモデルは、列(Column) key、行(Row) key、および timestamp によってインデックスが作成される分散型、多次元型、永続型、ソート済みの map であり、これが Apache HBase が key-value ストレージシステムとも呼ばれる理由である。

HBase の基本単位は Column であり、この Column が集まって Column Family を構成し、この Column Family が集まってテーブルを構成する。テーブルに入る各 Row は Row Key を持ち、識別できる。以下の図を見てみよう。

このテーブルは Customer と Sales の2つの Column Family を持つ。
Customer Column Family は Name と City の2つの Column を持つ。
Sales Column Family は Product と Amount の2つの Column を持つ。
Row は Row Key、Customer CF、Sales CF で構成される。

次は Apache HBase で使用されるデータモデル用語である。

Table

Apache HBase テーブルは複数の Row で構成される。文字で構成され、ファイルシステムと一緒に使用しやすいテーブルとしてデータを構成する。

Row の集合。Row Key があり、多数の column family で構成される。
Schema 定義では Column Family のみを定義する。

Row

Apache HBase は行(Row)を基準にデータを保存し、各行には一意な Row Key がある。Row Key はバイト配列で表される。

Row Key

Row Key を基準にデータが集まるため、Row Key は適切にデータが分散されるよう設計する必要がある。Row Key 設計の目標は、似た Row が互いに近くなる方式でデータを保存することである。

任意の Byte 列として辞書順にソートされる。
空の Byte 文字列はテーブルの開始と終了を意味する。
文字列、整数バイナリ、シリアライズされたデータ構造まで、どのようなものでも Row Key になり得る。

一般的に Row Key パターンは Web サイトドメイン形式で構成することもできる。org.apache.mair、org.apache.jira のようにドメインを逆順に保存すると、apache ドメインは近い位置にデータを保存できる。

Column

Column Family と Column Qualifier で構成される。

Column Family

Column Family は Row を保存するために使用され、Apache HBase にデータを保存する構造も提供する。

文字と文字列で構成され、ファイルシステムパスと一緒に使用できる。テーブルの各行は同じ column family を持つが、すべての column family に行を保存する必要はない。

Column Qualifier

Column Qualifier は Column Family に保存されたデータに対するインデックスを提供する。Column qualifier は固定値ではないため、さまざまなデータを入力できる。map オブジェクトと考えられる。

Column のグループであり、すべての ColumnFamily の Member は同じ prefix を使用する。
NOSQL:Cassandra と NOSQL:HBASE は NOSQL という Column Family の member column である。
ColumnFamily prefix は必ず表示可能な文字で構成する。
テーブルスキーマで定義の一部を先に指定する必要がある。
すべての ColumnFamily member は物理的にファイルシステムで一緒に保存される。
新しい ColumnFamily member は動的に追加可能である。

Cell

Cell は Column family、Row key、Column qualifier で構成されるデータ単位であり、各 Column の値を Cell という。

データ Cell には value(値)と timestamp(値のバージョン)を含む。timestamp があるため、以前の値も一緒に保存され、一定期間その値を保持する。

ROW KEY、Column、Version が明示された tuple。
値は任意の Byte 列であり Timestamp。
テーブル Cell はバージョン管理される。Cell のみである。

Timestamp

Cell に同じデータが保存された値にはバージョンが指定され、各バージョンは生成時間に割り当てられたバージョン番号で識別される。データを書き込むときに Timestamp を明示しなければ、現在時刻が指定される。

HBase データ型(Data Types)

Apache HBase にはデータ型の概念がない。すべてバイト配列である。値が挿入されると、Put および Result インターフェースを使用してバイト配列へ変換される、一種の byte-in and byte-out データベースである。Apache HBase はシリアライズフレームワークを使用して、ユーザーデータをバイト配列へ変換する。

Apache HBase Cell には最大 10から15MB の値を保存できる。値がより大きい場合は Hadoop HDFS に保存し、ファイルパスメタデータ情報を Apache HBase に保存できる。

HBase データストア

次は Apache HBase の物理的に保存される形式について紹介する。

概念的観点

テーブルが概念レベルで一連の Row として表示されることがわかる。

次はデータが HBase に保存される方式の概念図である。

物理的観点

Physical view テーブルは column family によって物理的に保存される。

次の例は、Column Family ベースのテーブルとして保存されるテーブルを表す。

ネームスペース

ネームスペースはテーブルの論理グループである。関連テーブルをグループ化するリレーショナルデータベースに似ている。

ネームスペースの表現を見てみよう。

HBase Namespaces
- Table
- Region Server Group
- Permission
- Quota

ネームスペース空間の各構成要素を見てみよう。

Table

すべてのテーブルはネームスペースの一部である。定義されたネームスペースがなければ、テーブルは default ネームスペースに割り当てられる。

RegionServer group

ネームスペースに対するデフォルト RegionServer group を持つことができる。この場合、作成されたテーブルは RegionServer の構成員になる。

Permission

ネームスペースを使用して、ユーザーは読み取り、削除、更新権限などのアクセス制御リストを定義でき、書き込み権限を使用してテーブルを作成できる。

Quota

この構成要素は、ネームスペースがテーブルおよびリージョンに対して含められる割り当て量を定義するために使用される。

事前定義された namespaces

事前定義された2つの特殊ネームスペースがある。

hbase: HBase 内部テーブルを含めるために使用されるシステムネームスペースである。
default: このネームスペースは、ネームスペースが定義されていないすべてのテーブルのためのものである。

データモデル操作

主要な作業データモデルは Get、Put、Scan、Delete である。これらの操作を使用してテーブルからレコードを読み、書き、削除できる。

各操作を詳しく見てみよう。

Get

Get 操作はリレーショナルデータベースの Select 文に似ている。HBase テーブルの内容を取得するために使用される。

以下のように HBase Shell で Get コマンドを実行できる。

hbase(main) :001:0> get 'table name', 'row key' <filters>

Put

Put 操作はテーブルにデータを書き込むために使用される。

Scan

Scan 操作はテーブルの複数行を読むために使用される。読み取る行集合を指定する必要がある Get とは異なる。Scan を使用すると、行範囲またはテーブルのすべての行を反復できる。

Delete

Delete 操作は HBase テーブルから行または行集合を削除するために使用される。HTable.delete() によって実行できる。

削除コマンドが実行されると削除マークで表示され、compaction が発生すると該当行がテーブルから最終削除される。

内部削除の種類は以下のとおりである。

Delete: 特定バージョンの Column に使用される。
Delete column: すべての列バージョンに使用できる。
Delete family: 特定 ColumnFamily のすべての列に使用される。

ローカル練習用 HBase Docker インストール

kc@example.com (kc kim) — Tue, 13 Jun 2023 18:40:33 +0900

HBase を Docker にインストール

以下の Docker イメージを利用して、Docker 環境に HBase をインストールしてみる。

インストールする HBase Docker image
- https://hub.docker.com/r/dajobe/hbase

HBase Docker 実行コマンドのダウンロード

以下の GitHub から HBase Docker 実行コマンドをダウンロード、つまり clone する。

GitHub
- https://github.com/dajobe/hbase-docker

git clone git@github.com:dajobe/hbase-docker.git

HBase Docker の実行

Docker が起動した状態で、以下のコマンドをそのまま実行する。

./start-hbase.sh

コンテナを起動し、すべてのローカル API ポートと Web UI を調べ、まだ存在しない場合はコンテナ IP への alias を追加するために /etc/hosts の編集を提案する start-hbase.sh スクリプトを使用することが推奨される。

コンテナを起動して、すべてのローカル API ポートと Web UI を決定し、まだ存在しない場合はコンテナ IP への alias を追加するために /etc/hosts の編集を提案する start-hbase.sh スクリプトを使用することが推奨される。

% ./start-hbase.sh
start-hbase.sh: Starting HBase container
Error: No such container: hbase-docker
Unable to find image 'dajobe/hbase:latest' locally
latest: Pulling from dajobe/hbase
6cf436f81810: Pulling fs layer

... 中間省略 ...

159beed970fa: Pull complete
Digest: sha256:daa36a6d90b118ced866b6c76fcd918e7da73302b0e4971f506f0f61f645a9fe
Status: Downloaded newer image for dajobe/hbase:latest
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
start-hbase.sh: Container has ID 3804d552250334cc850189e076b77cb0d3066850cef332bec7a125dc29228361
./start-hbase.sh: line 32: python: command not found

ここでコンテナ ID は 3804d552250334cc850189e076b77cb0d3066850cef332bec7a125dc29228361 である。Shell 実行時に必要なので記録しておこう。

上記コマンドを実行すると、実行した現在のパスに data が作成され、port が開かれて HBase が実行される。

手動で実行する方法

docker run --name=hbase-docker \
  -h hbase-docker \
  -p 9095:9095 \
  -p 8085:8085 \
  -p 16010:16010  \
  -v $PWD/data:/data \
  -d dajobe/hbase

HBase Shell の実行

次に、Docker イメージを利用して HBase に接続できる Shell コマンドを実行してみる。

上で記録したコンテナ ID を $id に入れて実行する。

docker run --rm -it --link $id:hbase-docker dajobe/hbase hbase shell

macOS Apple Chip(M1, M2) の場合は、以下のようなエラーが出ることがある。

% docker run --rm -it --link 3804d552250334cc850189e076b77cb0d3066850cef332bec7a125dc29228361:hbase-docker dajobe/hbase hbase shell
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

その場合、すでに実行された Docker を削除し、--platform linux/amd64 オプションを入れて再実行すると動作するはずである。

% docker run --rm -it --platform linux/amd64 --link 3804d552250334cc850189e076b77cb0d3066850cef332bec7a125dc29228361:hbase-docker dajobe/hbase hbase shell

2023-06-16 09:38:17,680 WARN  [main] util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
HBase Shell
Use "help" to get list of supported commands.
Use "exit" to quit this interactive shell.
For Reference, please visit: http://hbase.apache.org/2.0/book.html#shell
Version 2.1.2, r1dfc418f77801fbfb59a125756891b9100c1fc6d, Sun Dec 30 21:45:09 PST 2018
Took 0.0480 seconds
hbase(main):001:0>

Shell から抜けるコマンドは quit である。

hbase(main):005:0> quit

Command の使用方法は次のページで説明する。

HBase 一般 Shell コマンド - status, version, whoami

kc@example.com (kc kim) — Fri, 16 Jun 2023 14:55:22 +0900

General HBase shell commands

ここでは HBase の一般コマンドについて紹介する。

`status`

cluster 状態を表示する。追加オプション("summary", "simple", "detailed")を通じて詳細情報を確認できる。デフォルトは "summary" である。

status コマンドでクラスターの状態を確認できる。

オプション	説明
simple	サーバー情報
summary	サーバー数、ロード負荷
detailed	サーバー情報、メタ情報
replication	ソース、シンク情報

status

hbase(main):001:0> status
1 servers, 0 dead, 2.0000 average load

status 'simple'

hbase(main):002:0> status 'simple'
1 live servers
    532f4d895a98:40371 1686636094968
        requestsPerSecond=0.0, numberOfOnlineRegions=2, usedHeapMB=19, maxHeapMB=966, numberOfStores=2, numberOfStorefiles=2, storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0, storefileIndexSizeMB=0, readRequestsCount=42, writeRequestsCount=5, rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0, totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN, coprocessors=[]
0 dead servers
Aggregate load: 0, regions: 2

status 'summary'

hbase(main):003:0> status 'summary'
1 servers, 0 dead, 2.0000 average load

status 'detailed'

hbase(main):004:0> status 'detailed'
version 2.0.0-SNAPSHOT
0 regionsInTransition
master coprocessors: []
1 live servers
    532f4d895a98:40371 1686636094968
        requestsPerSecond=0.0, numberOfOnlineRegions=2, usedHeapMB=21, maxHeapMB=966, numberOfStores=2, numberOfStorefiles=2, storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0, storefileIndexSizeMB=0, readRequestsCount=42, writeRequestsCount=5, rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0, totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN, coprocessors=[]
        "hbase:meta,,1"
            numberOfStores=1, numberOfStorefiles=1, storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0, storefileIndexSizeMB=0, readRequestsCount=36, writeRequestsCount=3, rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0, totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN, completeSequenceId=10
        "hbase:namespace,,1686636105191.93358ca1f9bf1816320d88c48e39a3b4."
            numberOfStores=1, numberOfStorefiles=1, storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0, storefileIndexSizeMB=0, readRequestsCount=6, writeRequestsCount=2, rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0, totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN, completeSequenceId=8
0 dead servers

version

インストールされた HBase のバージョン情報を確認する。

version

hbase(main):001:0> version
2.0.0-SNAPSHOT, r31ed817447b4c3edef2019d1580aa3ede83a82da, Fri Sep 26 02:07:26 UTC 2014

whoami

現在の HBase ユーザーを確認する。

whoami

hbase(main):008:0> whoami
root (auth:SIMPLE)
    groups: root

HBase テーブル管理コマンド - create, list, exists, disable/enable, describe, alter, drop

kc@example.com (kc kim) — Fri, 16 Jun 2023 14:55:22 +0900

Table Management commands

ここでは、テーブル管理に関する HBase Shell コマンドを紹介する。

create - テーブル作成

create コマンドを使用してテーブルを作成できる。ここでは、テーブル名と Column Family 名を指定する必要がある。HBase shell でテーブルを作成する構文は次のとおりである。

create '<table name>', '<column family>'

次は order というテーブルのサンプルスキーマである。ここには customer と sales という 2 つの column family がある。

次のように HBase shell でこのテーブルを作成できる。

create 'order', 'customer', 'sales'

実行すると次のように表示される。

hbase(main):002:0> create 'order', 'customer', 'sales'
Created table order
Took 2.4344 seconds
=> Hbase::Table - order

create オプション

テーブルを作成するときにオプションを追加することもできる。

t1 を作成しながら、最新の version を最大 5 個まで保存する column family cf1 を作成する。

create 't1', {NAME => 'f1', VERSIONS => 5}

t1 を作成しながら、column family cf1、cf2、cf3 を作成する。

create 't1', {NAME => 'f1', NAME => 'f2', NAME => 'f3'}

その他のオプションを指定したコマンドである。

create 't1', {NAME => 'cf2', VERSION => 1, TTL => 2592000, BLOCKCACHE =>true}

create 't1', {NAME => 'cf2', CONFIGURATION => {'hbase.hstore.blockingStoreFiles' ='10'}}

list - テーブル一覧照会

list は、HBase のすべてのテーブルを一覧表示するために使用されるコマンドである。list コマンドの構文は次のとおりである。

list

このコマンドを入力し、HBase プロンプトで実行すると、次のように HBase のすべてのテーブル一覧が表示される。

hbase(main):004:0> list
TABLE
order
1 row(s) in 0.1070 seconds
=> ["order"]

次のようにオプションを付けることもできる。

hbase(main):005:0> list 'customer.*'
TABLE
order
1 row(s) in 0.0140 seconds
=> ["order"]

exists - テーブル存在確認

exists コマンドを使用してテーブルの存在を確認できる。次はテーブルの存在を確認する構文である。

exists '<table name>'

次の例では、order テーブルが存在するかを確認している。

hbase(main):022:0> exists 'order'
Table order does exist
0 row(s) in 0.0680 seconds

次の例では、user テーブルが存在するかを確認しているが、実際には存在しない場合である。

hbase(main):023:0> exists 'user'
Table user does not exist
0 row(s) in 0.0110 seconds

disable - テーブル無効化

テーブルを削除したり設定を変更したりするには、まず disable コマンドを使用してテーブルを無効化する必要がある。enable コマンドを使用すると再び有効化できる。

テーブルを無効化する構文は次のとおりである。

disable '<table name>'

次は order テーブルを無効化する方法を示す例である。

hbase(main):004:0> disable 'order'
0 row(s) in 1.4570 seconds

テーブルを無効化した後でも、list および exists コマンドでテーブルの存在を確認できる。

hbase(main):009:0> list
TABLE
order
1 row(s) in 0.0140 seconds
=> ["order"]

無効化されたテーブルは scan できない。次のようなエラーが発生する。

hbase(main):010:0> scan 'order'
ROW                                         COLUMN+CELL

ERROR: order is disabled.

// omitted

is_disabled

このコマンドは、テーブルが無効化されているかを確認するために使用される。構文は次のとおりである。

is_disabled '<table name>'

次の例では、order というテーブルが無効化されているかどうかを確認する。無効化されていれば true を返し、そうでなければ false を返す。

hbase(main):011:0> is_disabled 'order'
true
0 row(s) in 0.0360 seconds

disable_all

disable_all コマンドは、指定した正規表現に一致するすべてのテーブルを無効化するために使用される。disable_all コマンドの構文は次のとおりである。

disable_all ‘<regex table name>’

簡単な例を次に示す。次のコマンドは r で始まるすべてのテーブルを無効化する。

disable_all 'r.*'

HBase に dev_follow、dev_friend、dev_test、dev_user という dev で始まる 4 つのテーブルがあると仮定する。次のコードは dev で始まるすべてのテーブルを無効化する。

hbase(main):017:0> disable_all 'dev.*'
dev_follow
dev_friend
dev_test
dev_user

Disable the above 4 tables (y/n)?
y
4 tables successfully disabled

enable - テーブル有効化

無効化されたテーブルを有効化するには、enable コマンドを使用する。次はテーブルを有効化する構文である。

enable '<table name>'

次はテーブルを有効化する例である。

hbase(main):018:0> enable 'order'
0 row(s) in 0.6580 seconds

テーブルを有効化した後に scan する。エラーが発生しなければ、テーブルが正常に有効化されたということである。

hbase(main):020:0> scan 'order'
ROW                                         COLUMN+CELL
0 row(s) in 0.0730 seconds

is_enabled

is_enabled コマンドは、テーブルが有効化されているかを確認するために使用される。構文は次のとおりである。

is_enabled '<table name>'

次のコマンドは、order というテーブルが有効化されているかどうかを確認する。有効化されていれば true を返し、そうでなければ false を返す。

hbase(main):021:0> is_enabled 'order'
true
0 row(s) in 0.0750 seconds

describe - テーブル説明

describe コマンドは、テーブルに関する説明を返す。構文は次のとおりである。

describe '<table name>'

次は order テーブルに対する describe コマンドの出力である。

hbase(main):006:0> describe 'order'
DESCRIPTION                                                                                                  ENABLED
 'order', {NAME => 'customer', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'ROW', REPLICATION_SCO true
 PE => '0', VERSIONS => '1', COMPRESSION => 'NONE', MIN_VERSIONS => '0', TTL => 'FOREVER', KEEP_DELETED_CELL
 S => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true'}, {NAME => 'sales', DATA_BLO
 CK_ENCODING => 'NONE', BLOOMFILTER => 'ROW', REPLICATION_SCOPE => '0', VERSIONS => '1', COMPRESSION => 'NON
 E', MIN_VERSIONS => '0', TTL => 'FOREVER', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY =
 > 'false', BLOCKCACHE => 'true'}
1 row(s) in 0.1450 seconds

alter - テーブル変更

alter は既存のテーブルを変更するために使用されるコマンドである。このコマンドを使用して、column family の最大 cell 数を変更したり、テーブルスコープ演算子を設定および削除したり、テーブルから column family を削除したりできる。

Column Family の最大 cell 数変更

次は column family の最大 cell 数を変更する構文である。

alter '<table name>', NAME => '<column family>', VERSIONS => 5

次の例では最大 cell 数を 5 に設定する。

hbase(main):007:0>alter 'order', NAME => 'customer', VERSIONS => 5
Updating all regions with the new schema...
0/1 regions updated.
1/1 regions updated.
Done.
0 row(s) in 2.4240 seconds

hbase(main):009:0>

テーブルスコープ演算子

alter を使用すると、MAX_FILESIZE、READONLY、MEMSTORE_FLUSHSIZE、DEFERRED_LOG_FLUSH などのテーブルスコープ演算子を設定および削除できる。

READONLY - 読み取り専用設定

次はテーブルを読み取り専用にする構文である。

alter '<table name>', READONLY(option)

次の例では、order テーブルを読み取り専用にしている。

hbase(main):009:0> alter 'order', READONLY
Updating all regions with the new schema...
0/1 regions updated.
1/1 regions updated.
Done.
0 row(s) in 2.3650 seconds

MAX_FILESIZE - region 設定変更

MAX_FILESIZE で region 設定を変更する。

alter 't1', MAX_FILESIZE => '123217728'

region の最大サイズを 128 MB に変更する。

Column Family 削除

alter を使用すると column family を削除することもできる。次は alter を使用して column family を削除する構文である。

alter '<table name>', 'delete' => '<column family>'

次は order テーブルから column family を削除する例である。

hbase(main):010:0> alter 'order', 'delete' => 'sales'
Updating all regions with the new schema...
0/1 regions updated.
1/1 regions updated.
Done.
0 row(s) in 2.3790 seconds

describe コマンドで確認すると、'sales' が消えたことがわかる。

hbase(main):011:0> describe 'order'
DESCRIPTION                                                                                                  ENABLED
 'order', {NAME => 'READONLY', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'ROW', REPLICATION_SCO true
 PE => '0', COMPRESSION => 'NONE', VERSIONS => '1', TTL => 'FOREVER', MIN_VERSIONS => '0', KEEP_DELETED_CELL
 S => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true'}, {NAME => 'customer', DATA_
 BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'ROW', REPLICATION_SCOPE => '0', VERSIONS => '5', COMPRESSION => '
 NONE', MIN_VERSIONS => '0', TTL => 'FOREVER', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMOR
 Y => 'false', BLOCKCACHE => 'true'}
1 row(s) in 0.0850 seconds

drop - テーブル削除

drop コマンドを使用してテーブルを削除できる。構文は次のとおりである。

drop '<table name>'

テーブルを削除する前に無効化する必要がある。

hbase(main):024:0> disable 'order'
0 row(s) in 1.3960 seconds
hbase(main):025:0> drop 'order'
0 row(s) in 0.2860 seconds

exists コマンドを使用して、テーブルが削除されたかを確認する。

hbase(main):026:0> exists 'order'
Table order does not exist
0 row(s) in 0.0710 seconds

drop_all

drop_all コマンドは、指定した正規表現に一致するすべてのテーブルを削除するために使用される。構文は次のとおりである。

drop_all '<regex table name>'

簡単な例を次に示す。次のコマンドは t で始まるすべてのテーブルを削除する。

drop_all 't.*'

参考: 対象のすべてのテーブルは、削除する前に無効化する必要がある。

HBase データ操作コマンド - put, get, delete, deleteall, scan, count, truncate

kc@example.com (kc kim) — Fri, 16 Jun 2023 14:55:22 +0900

Data Manipulation commands

ここでは、データを操作する HBase Shell コマンドを紹介する。

put - データ登録/変更

ここでは、HBase テーブルでデータを作成および変更する方法を紹介する。

HBase に次のようなテーブルを作成する。

put コマンドを使用して、テーブルに row を登録および変更できる。構文は次のとおりである。

put '<table name>', '<row id>', '<column family>:<column name>', '<value>'

最初の row 登録

create 'order', 'customer', 'sales'

put 'order', '101', 'customer:name', 'John White'
put 'order', '101', 'customer:city', 'Los Angeles'
put 'order', '101', 'sales:product', 'Chairs'
put 'order', '101', 'sales:amount', '400.00'

まずテーブルを作成する。

hbase(main):001:0> create 'order', 'customer', 'sales'
Created table order
Took 5.0510 seconds
=> Hbase::Table - order

最初の row の値をテーブルに登録する。

hbase(main):002:0> put 'order', '101', 'customer:name', 'John White'
Took 0.6725 seconds
hbase(main):003:0> put 'order', '101', 'customer:city', 'Los Angeles'
Took 0.0318 seconds
hbase(main):004:0> put 'order', '101', 'sales:product', 'Chairs'
Took 0.0988 seconds
hbase(main):005:0> put 'order', '101', 'sales:amount', '400.00'
Took 0.0423 seconds

テーブル全体を scan すると、次のような結果が表示される。

hbase(main):006:0> scan 'order'
ROW                               COLUMN+CELL
 101                              column=customer:city, timestamp=1686908392705, value=Los Angeles
 101                              column=customer:name, timestamp=1686908388954, value=John White
 101                              column=sales:amount, timestamp=1686908401071, value=400.00
 101                              column=sales:product, timestamp=1686908398256, value=Chairs
1 row(s)
Took 0.4121 seconds

データ変更

put コマンドを使用して既存 cell の値を変更できる。構文はデータを登録するときと同じである。

次のように新しい値を指定すればよい。

put 'order','101','customer:city','LA'

コマンド実行は次のとおりである。

hbase(main):007:0> put 'order','101','customer:city','LA'
Took 0.0677 seconds

hbase(main):008:0> scan 'order'
ROW                               COLUMN+CELL
 101                              column=customer:city, timestamp=1686909532774, value=LA
 101                              column=customer:name, timestamp=1686908388954, value=John White
 101                              column=sales:amount, timestamp=1686908401071, value=400.00
 101                              column=sales:product, timestamp=1686908398256, value=Chairs
1 row(s)
Took 0.1186 seconds

get - データ照会

get コマンドは、HBase のテーブルからデータを読み取るために使用される。構文は次のとおりである。

get '<table name>', '<row id>'

次の例では、get コマンドを使用して order テーブルの 101 row を照会している。

hbase(main):009:0> get 'order', '101'
COLUMN                            CELL
 customer:city                    timestamp=1686909532774, value=LA
 customer:name                    timestamp=1686908388954, value=John White
 sales:amount                     timestamp=1686908401071, value=400.00
 sales:product                    timestamp=1686908398256, value=Chairs
1 row(s)
Took 0.3162 seconds

特定 row 照会

次は、get コマンドを使用して特定 column を照会する構文である。

get '<table name>', '<row id>', {COLUMN => '<column family>:<column name>'}

次は HBase テーブルの特定 column を照会する例である。

hbase(main):010:0> get 'order', '101', {COLUMN => 'customer:name'}
COLUMN                            CELL
 customer:name                    timestamp=1686908388954, value=John White
1 row(s)
Took 0.1450 seconds

delete - テーブルの特定 cell 削除

delete コマンドを使用して、テーブルの特定 cell を削除できる。delete コマンドの構文は次のとおりである。

delete '<table name>', '<row id>', '<column name>', '<timestamp>'

次は特定 cell を削除する例である。ここでは city を削除する。

hbase(main):011:0> delete 'order', '101', 'customer:city', 1686909532774
Took 0.0917 seconds

再度照会すると、前の put コマンドで変更した 'LA' 値が削除され、既存の 'Los Angeles' 値が再び表示されることがわかる。

hbase(main):012:0> get 'order', '101'
COLUMN                            CELL
 customer:city                    timestamp=1686908392705, value=Los Angeles
 customer:name                    timestamp=1686908388954, value=John White
 sales:amount                     timestamp=1686908401071, value=400.00
 sales:product                    timestamp=1686908398256, value=Chairs
1 row(s)
Took 0.2196 seconds

deleteall - テーブル row のすべての cell 削除

deleteall コマンドを使用して、row のすべての cell を削除できる。次は deleteall コマンドの構文である。

deleteall '<table name>', '<row id>'

次は order テーブルの 1 行のすべての cell を削除する deleteall コマンドの例である。

hbase(main):013:0> deleteall 'order','101'
Took 0.1271 seconds
hbase(main):015:0>

scan コマンドを使用してテーブルを確認する。テーブルデータを削除した後のスナップショットは次のとおりである。

hbase(main):015:0> scan 'order'
ROW                               COLUMN+CELL
0 row(s)
Took 0.0518 seconds

scan - データ照会

scan コマンドは HTable のデータを見るために使用される。scan コマンドを使用してテーブルデータを取得できる。構文は次のとおりである。

scan '<table name>'

まず次のようにデータを入れる。

put 'order', '101', 'customer:name', 'John White'
put 'order', '101', 'customer:city', 'Los Angeles'
put 'order', '101', 'sales:product', 'Chairs'
put 'order', '101', 'sales:amount', '400.00'

次の例では、scan コマンドを使用してテーブルからデータを照会している。

hbase(main):019:0> scan 'order'
ROW                               COLUMN+CELL
 101                              column=customer:city, timestamp=1686912065208, value=Los Angeles
 101                              column=customer:name, timestamp=1686912059341, value=John White
 101                              column=sales:amount, timestamp=1686912074891, value=400.00
 101                              column=sales:product, timestamp=1686912070718, value=Chairs
1 row(s)
Took 0.2649 seconds

count - データ数照会

count コマンドを使用して、テーブルの行数を数えることができる。構文は次のとおりである。

count ‘<table name>'

hbase(main):020:0> count 'order'
1 row(s)
Took 0.2992 seconds
=> 1

truncate - すべて削除

truncate コマンドは、テーブルを無効化、削除、再作成する。truncate の構文は次のとおりである。

truncate ‘<table name>'

次は truncate コマンドの例である。ここでは order テーブルを削除して再作成した。

hbase(main):021:0> truncate 'order'
Truncating 'order' table (it may take a while):
Disabling table...
Truncating table...
Took 5.6828 seconds

truncate でテーブルデータを削除した後、scan コマンドを使用して確認する。テーブルに行がないことを確認できる。

hbase(main):023:0> scan 'order'
ROW                               COLUMN+CELL
0 row(s)
Took 1.6790 seconds

HBase セキュリティコマンド(Security tools) - grant, revoke, user_permission

kc@example.com (kc kim) — Sun, 18 Jun 2023 16:13:38 +0900

Security tools

HBase では、ユーザーに権限を付与したり取り消したりできる。セキュリティ目的の3つのコマンドがある。

grant
revoke
user_permission

grant - 権限付与

grant コマンドは、ユーザーにテーブルに対する読み取り、書き込み、実行、管理などの特定権限を付与する。権限付与コマンドの構文は次のとおりである。

grant '<user>' '<permissions>' ['<table>' ['<column family>' ['<column; qualifier>']]

RWXCA を使用してユーザーに権限を付与できる。

R: READ、読み取り権限
W: WRITE、書き込み権限
X: EXEC、実行権限
C: CREATE、作成権限
A: ADMIN、管理者権限

grant 'devkuma', 'RWXCA'

grant 'devkuma', 'RW' 't1', 'cf1', 'qualifier1'

revoke - 権限削除

ユーザーのアクセス権限を削除する。

revoke <user> <permissions> [<table> [<column family> [<column; qualifier>]]

revoke 'devkuma', 't1', 'cf1', 'qualifier1'

user_permission - 特定テーブルに対する権限照会

user_permission コマンドは、特定テーブルに対するすべての権限を照会するために使用される。構文は次のとおりである。

user_permission '<table name>'

特定テーブルに存在するすべての権限を表示する。

user_permission 't1'

HBase 圧縮、コンパクション、およびデータブロックエンコーディング

kc@example.com (kc kim) — Thu, 22 Jun 2023 19:13:23 +0900

圧縮とコンパクション

HBase RegionServer に保存される Region には、Column Family ごとに HStore があり、HStore はその CF の MemStore と HFile で構成される。

MemStore はメモリ上の Column Family データであり、HFile はローカルディスク、つまり HDFS に保存される Column Family データである。このような階層構造になっている理由は、HBase のテーブル構造上、データを Row key でソートする必要があり、ディスクへ直接書き込むのではなく、まずメモリ上でソートする必要があるためである。

HBase で put や update などの書き込み処理が行われると、データはまず WAL (Write Ahead Log) に記録され、その後 MemStore に書き込まれる。scan などの読み取り処理では、まず MemStore を確認し、次に HFile から要求された内容を検索する。

書き込みが繰り返されて MemStore のデータサイズが設定されたしきい値を超えると、MemStore のデータは HFile として保存される。多くの HFile で構成された Region では、HFile が増えるにつれてコンパクションが発生し、複数の HFile がより大きな HFile にマージされる。その結果、多数の小さな HFile は、少数の大きな HFile に整理される。この処理をコンパクションと呼ぶ。

HBase のコンパクションは、Minor Compaction と Major Compaction として実行される。

Minor Compaction

Minor compaction は、最近作成された複数の小さなファイルを、設定されたより大きな HFile サイズへマージする処理である。
データが挿入されると、小さな HFile が多数作成される。ファイル数が多すぎると性能が低下する可能性があるため、HBase は複数の HFile を少数の大きな HFile に作り直し、HFile 数を自動的に管理する。
HFile に保存されたデータはソートされているため、マージソートを使って高速にマージできる。

Major Compaction

Major compaction は、特定 Region 内の Column Family に属するすべての HFile を集め、Column ごとに 1 つの HFile を作成する。デフォルトでは 7 日に 1 回実行される。
この処理中に不要な Cell や期限切れの Cell が削除され、全体的な読み取り性能が改善される。Tombstone Marker が付いたデータも、この時点で最終的に削除される。
この作業が実行されると、大量のファイル読み書きが発生するため、ディスク I/O とネットワークトラフィックが増加する可能性がある。
自動実行をスケジュールできるため、週末や夜間に実行するように設定し、急激な I/O 増加がサービスに与える影響を最小化できる。

コンパクション設定

Minor compaction では、コンパクション対象となる HFile 数を次の設定で指定する。

hbase.hstore.compaction.min
- Minor compaction の最小 HFile 数を設定する。
- デフォルトは 3 で、2 以上に設定する必要がある。
- 値が大きすぎると Minor compaction が遅延し、後でまとめて処理される際に負荷が発生する可能性がある。
hbase.hstore.compaction.max
- Minor compaction の最大 HFile 数を設定する。

次の設定では、コンパクション対象となる HFile サイズを指定する。

hbase.hstore.compaction.min.size: この値より小さい HFile は、ExploringCompactionPolicy によって Minor compaction を検索するとき常に含まれる。この値は hbase.hstore.compaction.ratio と併用され、コンパクション対象の HFile を選択するために使われる。
hbase.hstore.compaction.max.size: このサイズより大きい HFile は Minor compaction から除外される。Minor compaction が頻繁に発生しても効果が小さい場合、この値を小さくして大きなファイルを Minor compaction から除外できる。デフォルト: 9223372036854775807, LONG.MAX_VALUE, bytes。

その他の設定:

hbase.hregion.majorcompaction
- HBase では、1 つの Region に複数の StoreFile が存在することがある。性能改善のため、定期的にこれらのファイルを集め、より大きな 1 つのファイルにまとめる。この処理では CPU 使用量とディスク I/O が大きく、応答時間が低下する場合がある。そのため、応答時間が重要な場合は、ピーク時間を避けて Major compaction を手動実行する方がよい。
- デフォルトは 86,400,000 ms である。この値を 0 に変更すると、定期的な Major Compaction は実行されない。
hbase.hregion.majorcompaction.jitter
- このプロパティのデフォルトは 0.2、つまり 20% である。保存された各ファイルで Major compaction が実行されるタイミングを分散させる。
- これがない場合、Major compaction は 24 時間ごとに同時実行される。

HBase 圧縮およびデータブロックエンコーディング

このセクションで言及する codec は、データブロックまたは row key のエンコードとデコードのためのものである。レプリケーション codec の詳細については、cluster.replication.preserving.tags を参照する。

HBase は、ColumnFamily に対して有効化できる複数の圧縮アルゴリズムをサポートしている。データブロックエンコーディングは、ソート済み row key や対象テーブルのスキーマなど、HBase の基盤設計とパターンを利用して、key 内の情報重複を抑える。Compressor は Cell 内の大きな不透明バイト配列のサイズを削減し、未圧縮データに必要な保存領域を大幅に削減できる。

Compressor とデータブロックエンコーディングは、同じ ColumnFamily で併用できる。

変更はコンパクション中に適用される

ColumnFamily の圧縮またはエンコーディングを変更した場合、その変更はコンパクション中に適用される。

一部の codec は、GZip 圧縮のように Java に組み込まれた機能を使用する。他の codec はネイティブライブラリに依存する。ネイティブライブラリは、HBase ライブラリディレクトリにインストールされた codec 依存関係として提供できるほか、Hadoop codec を使う場合は Hadoop の一部として提供される。Hadoop codec には通常ネイティブコードコンポーネントがあるため、HBase で Hadoop ネイティブライブラリを使用するには、Hadoop native binary support installation instructions に従う。

このセクションでは、HBase で一般的に使用され、テストされている codec について説明する。

どの codec を使用する場合でも、その codec が正しくインストールされ、クラスタ内のすべてのノードで利用可能であることをテストする必要がある。新しくデプロイされたノードで codec の利用可否を確認するには、追加の運用手順が必要になる場合がある。指定した codec が正しくインストールされていることを確認するには、compression.test ユーティリティを使用できる。

HBase で compressor を使用する設定については compressor.install を参照する。ColumnFamily で compressor を有効にする方法については changing.compression を参照する。ColumnFamily でデータブロックエンコーディングを有効にする方法については data.block.encoding.enable を参照する。

Block Compressors

NONE

この圧縮タイプ定数は圧縮なしを選択し、デフォルトである。

BROTLI

Brotli は汎用の可逆圧縮アルゴリズムである。LZ77 の現代的な変種、Huffman coding、二次コンテキストモデリングを組み合わせ、現在利用できる最良の汎用圧縮方式に匹敵する圧縮率を提供する。速度は GZ と同程度だが、より高密度に圧縮できる。

BZIP2

Bzip2 は Burrows-Wheeler block-sorting text compression algorithm と Huffman coding を使用してファイルを圧縮する。通常、LZ のような辞書ベース圧縮より圧縮率はかなり良いが、圧縮と展開はいずれも他の選択肢より遅い場合がある。

GZ(GZIP)

圧縮率を重視する。
gzip は、LZ77 と Huffman coding の組み合わせである DEFLATE アルゴリズムに基づいている。このアルゴリズムは Java ランタイム環境で普遍的に利用できるため、最小公分母として使いやすい選択肢である。ただし、Zstandard などの新しいアルゴリズムと比べるとかなり遅い。

LZ4

圧縮/展開速度を重視する。
LZ4 は、圧縮と展開速度を重視した可逆データ圧縮アルゴリズムである。Brotli、DEFLATE、Zstandard と同じく LZ77 系の圧縮アルゴリズムに属する。マイクロベンチマークでは、LZ4 はその系列の中で圧縮と展開の両方が最も高速であり、一般的に推奨される。

LZMA

LZMA は LZ77 にやや似た辞書圧縮方式である。計算コストの高い予測モデルと可変サイズの圧縮辞書により非常に高い圧縮率を実現しながら、一般的に使われる他の圧縮アルゴリズムと同程度の展開速度を維持する。典型的な圧縮率では LZMA は他のすべての選択肢を上回るが、compressor としては非常に遅く、特に高い圧縮レベルで動作するように設定した場合は遅くなることがある。

LZO

圧縮/展開速度を重視し、追加ライブラリのインストールが必要である。
LZO は、展開速度を重視して実装された別の LZ 系データ圧縮アルゴリズムである。LZ4 ほど速くはないが、それに近い性能を持つ。

SNAPPY

圧縮/展開速度を重視する。
SNAPPY は LZ77 の考え方に基づくが、非常に高速な圧縮速度に最適化されており、その代わり圧縮率は妥当な水準にとどまる。LZ4 と同程度に高速だが、圧縮率はそれほど高くない。HBase は pure Java Snappy codec を提供しており、すべてのハードウェアアーキテクチャ上のすべての Java ランタイムで普遍的に利用できる選択肢として、GZ の代わりに使用できる。

ZSTD

Zstandard は、辞書マッチング段階 (LZ77) と、大きな検索ウィンドウ、および finite-state entropy と Huffman coding の両方を使用する高速なエントロピーコーディング段階を組み合わせる。圧縮速度は最速レベルと最遅レベルで 20 倍以上異なる場合があるが、展開は一貫して高速で、最速レベルと最遅レベルの差は 20% 未満である。
ZStandard は、利用可能な圧縮 codec の中で最も柔軟な選択肢である。レベル 1 では LZ4 と同程度の圧縮率を提供し、性能はわずかに低い。中間レベルでは DEFLATE と同程度の圧縮率をより良い性能で提供し、高レベルでは LZMA に似た圧縮速度で LZMA と同程度の高密度圧縮を提供しながら、展開は常に高速である。

データブロックエンコーディングタイプ

HBase は 5 種類のデータブロックエンコーディングを提供する。

NONE
Prefix
Diff
Fast Diff
Prefix Tree

None

None はエンコーディングを適用しないことを意味し、デフォルトである。

エンコーディングなしの ColumnFamily

次の表は、データブロックエンコーディングを使用しない仮想的な ColumnFamily を示している。

Key Length	Value Length	Key	Value
24	…	RowKey:Family:Qualifier0	…
24	…	RowKey:Family:Qualifier1	…
25	…	RowKey:Family:QualifierN	…
25	…	RowKey2:Family:Qualifier1	…
25	…	RowKey2:Family:Qualifier2	…
…	…	…	…

Prefix

通常、key は同じ prefix を持ち、最後の部分だけが異なることが多い。

たとえば、最初の key が RowKey:Family:Qualifier0 で、次の key が RowKey:Family:Qualifier1 であるとする。Prefix encoding は、現在の key と直前の key の間で共有される prefix の長さを格納する拡張カラムを追加する。この例で、最初の key が直前の key と完全に異なる場合、prefix length は 0 である。2 番目の key の最初の 23 文字が同じであるため、prefix length は 23 になる。

もちろん、2 つの key に共通部分がない場合、Prefix の利点はない。

Prefix encoding を適用した ColumnFamily
次は、同じデータに Prefix data encoding を適用したものである。

Key Length	Value Length	Prefix Length	Key	Value
24	…	0	RowKey:Family:Qualifier0	…
1	…	23	1	…
1	…	23	N	…
19	…	6	2:Family:Qualifier1	…
1	…	24	…	…
…	…	…	…	…

Diff

Diff encoding は Prefix encoding を拡張したものである。Key を 1 つのバイト列として扱うのではなく、各 Key Field に分割し、Key の各部分をより効率的に圧縮できるようにする。

timestamp と type という 2 つの新しいフィールドが追加される。

ColumnFamily が直前の行と同じ場合、現在の行では省略される。key length、value length、type が直前の行と同じ場合、それらのフィールドは省略される。

また、圧縮を改善するため、timestamp は完全な値として保存されず、直前の行の timestamp との差分として保存される。prefix の例で、2 つの row key があり、timestamp が完全に一致し、type も同じである場合、2 番目の行では value length や type を保存する必要がなく、2 番目の行の timestamp 値は完全な timestamp ではなく 0 になる。

write と scan の速度が遅くなるため、より多くのデータをキャッシュできるにもかかわらず、Diff encoding はデフォルトで無効になっている。

Diff encoding を適用した ColumnFamily
この表は、同じ ColumnFamily に Diff encoding を適用したものを示している。

Flags	Key Length	Value Length	Prefix Length	Key	Timestamp	Type Value
0	24	512	0	RowKey:Family:Qualifier0	1340466835163	4	…
5	-	320	23	1	0	-	…
3	-	-	23	N	120	8	…
0	25	576	6	2:Family:Qualifier1	25	4	…
5	-	3384	24	2	1124	-	…
…	…	…	…	…	…	…	…

Fast Diff

Fast Diff は Diff と同じように動作するが、より高速に実装されている。また、データ自体が直前の行と同じかどうかを追跡する 1 ビットを保存するフィールドが 1 つ追加される。同じであれば、データは再度保存されない。

key が長い場合や column が多い場合は、Fast Diff codec を使用する。

データ形式は Diff encoding とほぼ同じであるため、説明用の別画像はない。

Prefix Tree

Prefix Tree encoding は、HBase 0.96 で実験的機能として導入された。Prefix Tree encoding は、Prefix、Diff、Fast Diff encoder と同様のメモリ節約を提供しながら、エンコード速度が遅くなる代わりに、より高速なランダムアクセスを提供する。よいアイデアではあったが、ほとんど使用されず、HBase 2.0.0 で削除された。

参考資料

Appendix D: Compression and Data Block Encoding In HBase

HBase データバージョニング(Data Versioning)

kc@example.com (kc kim) — Thu, 22 Jun 2023 19:13:23 +0900

データバージョニング(Data Versioning)

HBase の特別な機能の1つとして、各セル(cell)の特定 column 値に複数のバージョンを保存できる。

各バージョンには timestamp を使用して実装されており、降順にソートされる。long integer 型として、millisecond に換算した UnixTime を使用する。

HBase は基本的にデータバージョン管理を行う。データが同じ Row key で保存されると、最新データが timestamp でバージョニングされ、降順に保存されるため、ストレージファイルから読み取るときにもっとも新しい値を先に見つける。

Timestamp は明示的に入力することも可能だが、デフォルトで HBase は各 cell の変更を3個まで保持し、基本的に scan で照会すると降順であるため最新データが照会される。

また、以下のように保存されているすべての version のデータを照会することも可能である。

get 't1', 'rowkey1', {COLUMN => 'cf1', TIMESTAMP => ts1}

timestamp 範囲を設定して、その時点の値を見ることも可能である。

get 't1', 'rowkey1', {TIMERANGE => [start_timestamp, end_timestamp]}

バージョニングは既存では自動で指定されるが、手動で指定することもできる。

自動バージョニング
- クラスター内サーバー時間が同一でない場合、バージョン差が発生する可能性がある。
- Put メソッド実行時に timestamp を設定できるが、一般的にはサーバー内の自動バージョニングを推奨する。
- 基本的に最近3個のバージョンを管理するが、Major Compaction 機能が長い周期を持つため、まだ削除されていない過去バージョンが存在することがある。
手動バージョニング
- timestamp をオーバーライドして実装可能である。

HBase VERSIONS=1 の場合でも削除すると列の以前のバージョンが表示される?

前でバージョンは基本的に最近3個のバージョンを管理するが、Major Compaction 機能が長い周期を持つため、まだ削除されていない過去バージョンが存在することがあると述べた。

これに関連して発生する問題について紹介する。

VERSIONS 適用

以下のように ColumnFamily に VERSIONS を適用する。

create 't1', {NAME => 'f1', VERSIONS => 2}

hbase(main):001:0> create 't1', {NAME => 'f1', VERSIONS => 2}
Created table t1
Took 5.9091 seconds
=> Hbase::Table - t1

次にデータを順番に登録する。

put 't1', '101', 'f1:name1', 'test1'
put 't1', '101', 'f1:name1', 'test2'
put 't1', '101', 'f1:name1', 'test2'
put 't1', '101', 'f1:name1', 'test4'

hbase(main):002:0> put 't1', '101', 'f1:name1', 'test1'
Took 0.7153 seconds
hbase(main):003:0> put 't1', '101', 'f1:name1', 'test2'
Took 0.0318 seconds
hbase(main):004:0> put 't1', '101', 'f1:name1', 'test3'
Took 0.0418 seconds
hbase(main):005:0> put 't1', '101', 'f1:name1', 'test4'
Took 0.0255 seconds

そして delete コマンドで1つずつ順番に削除しながら確認してみる。

delete 't1', '101', 'f1:name1'

hbase(main):013:0> scan 't1'
ROW                                                                  COLUMN+CELL
 101                                                                 column=f1:name1, timestamp=1687426826665, value=test4
1 row(s)
Took 0.3049 seconds
hbase(main):014:0> delete 't1', '101', 'f1:name1'
Took 0.0160 seconds
hbase(main):015:0> scan 't1'
ROW                                                                  COLUMN+CELL
 101                                                                 column=f1:name1, timestamp=1687426822568, value=test3
1 row(s)
Took 0.1760 seconds
hbase(main):016:0> delete 't1', '101', 'f1:name1'
Took 0.0605 seconds
hbase(main):017:0> scan 't1'
ROW                                                                  COLUMN+CELL
 101                                                                 column=f1:name1, timestamp=1687426817569, value=test2
1 row(s)
Took 0.0710 seconds
hbase(main):018:0> delete 't1', '101', 'f1:name1'
Took 0.0337 seconds
hbase(main):019:0> scan 't1'
ROW                                                                  COLUMN+CELL
 101                                                                 column=f1:name1, timestamp=1687426813634, value=test1
1 row(s)
Took 0.0265 seconds
hbase(main):020:0>

すると、その直前に登録したデータが順番に照会されることがわかる。

VERSIONS に関する疑問

ここでの疑問は、明らかに VERSIONS は1個だけ保存されると言われているのに、VERSIONS => 2 と指定してもそれ以上のバージョンの列が保持されているように見える点である。一見するとバグではないかと疑われる。

検索してみると、以下のように同じ疑問を持った人を見つけることができた。
Delete reveals older version of a column even when VERSIONS=1

上記質問には以下のような回答がある。

圧縮が行われるまでは以前のバージョンが実際には消えないという。圧縮は major compaction 設定を変更していない場合、またはリージョンが分割されるたびに、1日に1回実行されるべきだという。

これは Major Compaction がまだ行われていないために発生する問題である。

VERSIONS 適用の確認方法

では、VERSIONS はどう確認できるだろうか。方法は get コマンドを利用して VERSIONS => 4 のように詳細照会してみれば確認できる。

get 't1', '101', {COLUMN=>'f1:name1',VERSIONS => 4 }

hbase(main):005:0> get 't1', '101', {COLUMN=>'f1:name1', VERSIONS => 4 }
COLUMN                                                               CELL
 f1:name1                                                            timestamp=1687427184339, value=test4
 f1:name1                                                            timestamp=1687427181122, value=test2
1 row(s)
Took 0.5028 seconds
hbase(main):006:0>

すると上記のように、テーブル作成時に指定した VERSIONS => 2 どおり2件が出ることがわかる。

HBase ブルームフィルター(BloomFilter)

kc@example.com (kc kim) — Fri, 23 Jun 2023 19:01:58 +0900

BloomFilter とは?

BloomFilter は、1970年に Bloom が提案した多重ハッシュ関数マッピングのための高速検索アルゴリズムである。このアルゴリズムは、一般的に要素が集合に属するかどうかを素早く判断する必要がある状況で使用されるが、厳密に100%正確である必要はないという考えから始まっている。

詳しい理論はわかりやすく説明するブルームフィルター(Bloom Filter)データ構造ページを参照すること。

HBase BloomFilter

HBase の BloomFilter のデータは StoreFile のメタデータに保存され、一度作成されると StoreFile は変更できないため更新できない。

BloomFilter は Column family レベルの構成属性である。テーブルに BloomFilter が設定されている場合、HBase は MetaBlock と呼ばれる StoreFile を作成するときに BloomFilter 構造のデータ断片を含める。 MetaBlock および DataBlock(実際の KeyValue データ)は LRU BlockCacheMaintenance で一緒に使用される。

したがって、BloomFilter を設定すると、特定のストレージおよびメモリキャッシュのオーバーヘッドが発生する。

HBase BloomFilter の設定方法

特定の Row key を含んでいるかを探索するとき、既存のブロックインデックスに比べて不要なブロックロードを減らし、クラスター全体のスループットを改善する。

セルサイズ、セル数、データ保存方式、読み取り方式などに応じてブルームフィルターを選択する必要がある。

HBase ドキュメントによれば、ほとんどの場合 BloomFilter の使用が推奨されている。

BloomFilter には NONE(デフォルト)、ROW、ROWCOL の3つのパラメータがある。

ROW: KeyValue の行(Row)を基準に StoreFile をフィルタリングする行レベル Bloom フィルターを示す。
ROWCOL: KeyValue の行(Row) + 列(Column)に従って StoreFile をフィルタリングする列レベル Bloom フィルターを示す。

したがって、ROWCOL の空間オーバーヘッドは ROW より高い。

該当リージョンに StoreFile が多いほど BloomFilter の効果は高く、リージョンの StoreFile 数が少ないほど HBase の読み取り性能は向上する。

次のように BloomFilter コマンドを有効にするため、HBase で Column family を設定する。

create 't1',{name => 'c1', BLOOMFILTER => '<ROW または ROWCOL>'}