Hbase 入門

1. HBaseの概要

1.1 HBaseとは

HBase は、高い信頼性、高いパフォーマンス、列ストレージ、スケーラビリティ、リアルタイムの読み取りと書き込みを備えた、分散データ ストレージ用の HDFS ベースの NoSQL データベースです。

Hbase は膨大な量のデータを保存でき、後期段階でのクエリ パフォーマンスが高く、数億のデータ項目のクエリに対して数秒で結果を返すことができます。

1.2 HBaseテーブルの特徴

1. 大きい

• Hbase テーブルには大量のデータを保存できます。

2. モードなし

• MySQL テーブルの各行と列のフィールドは同じですが、HBase テーブルの各データ行には完全に異なる列を含めることができます。

3. 列指向

• hbase テーブルのデータには、多くの列を含めることができます。その後、異なる列に従ってデータを保存し、異なるファイルに書き込みます。
• 列ファミリーにデータを保存します。

4. まばら

• HBase テーブル内の null の列は実際のストレージ スペースを占有しません。

5. データの複数のバージョン

• hbase テーブルのデータを更新する場合、以前の結果データは直接削除されず、データの複数のバージョンが保持されます。各データにはバージョン番号が付けられ、データを挿入したときのタイムスタンプに応じて決定されます。

6. 単一データ型

• どのようなタイプのデータであっても、最終的にはバイト配列に変換され、hbaseテーブルに保存されます。

1.3 hbaseテーブルの論理ビュー

2. HBase クラスター構造

1. クライアント

• HBase テーブルを操作するためのいくつかの Java インターフェイスを提供します。
• クライアントはhbaseへのアクセスを高速化するためにキャッシュを維持します
• クライアントは照会された位置情報を保存してキャッシュし、キャッシュは自動的に期限切れにならない。

2. 動物園の飼育係

クライアントはHBaseテーブルデータを操作するためにZKクラスタを必要とする

効果

1. zkはhbaseクラスタのメタデータ情報を保存します

Hbase スキーマを保存します。これには、どのテーブルが存在するか、各テーブルにはどの列ファミリがあるかが含まれます。

2. zkはすべてのhbaseテーブルのアドレスエントリを保存します。

後でクライアント インターフェイスを使用して HBase データを操作する場合は、すべてのリージョンのアドレス指定エントリを保存するために ZK クラスターに接続する必要があります。ルート テーブルはどのサーバーにありますか?

3. zkを導入すると、hbaseクラスタ全体の可用性が高まります。

4. zkはHMasterとHRegionServerの登録情報とハートビート情報を保存します。

後で HRegionServer に障害が発生した場合、ZooKeeper はそれを検出し、この情報を上位の HMaster に通知します。

3. Hマスター

これはhbaseクラスタ全体のボスです

効果

1. テーブルの作成と削除に関するクライアント要求を受け入れます。スキーマ更新リクエストの処理

2. データを管理するために、対応するリージョンをHRegionServerに割り当てます。

3. 障害が発生したHRegionServerによって管理されている領域を他の稼働中のHRegionServerに再割り当てします。

4. 特定の HRegionServer によって管理されるリージョンが多すぎるのを回避するために、HRegionServer の負荷分散を実現します。

4. HR リージョン サーバー

これは統合されたHBaseクラスタの弟分です

効果

1. HMasterによって割り当てられた地域の管理を担当する

2. クライアントの読み取りおよび書き込み要求を受け入れます

3. 操作中に大きくなりすぎた領域データを分割します

5. 地域

これは、HBase テーブル全体の分散ストレージの最小単位です。

データはHDFSに基づいて保存されます

3. HBase クラスターのインストールと展開

前提条件

• まずZKとHadoopのクラスターを構築する

1. 対応するインストールパッケージをダウンロードする

• http://archive.apache.org/dist/hbase/1.2.1/hbase-1.2.1-bin.tar.gz
• hbase-1.2.1-bin.tar.gz

2. インストールディレクトリを計画する

• /エクスポート/サーバー

3. インストールパッケージをサーバーにアップロードする

4. インストールパッケージを指定された計画ディレクトリに解凍します。

• tar -zxvf hbase-1.2.1-bin.tar.gz -C /export/servers

5. 解凍ディレクトリの名前を変更する

• hbase-1.2.1 の hbase

6. 設定ファイルを変更する

hadoopのインストールディレクトリを/etc/hadoopフォルダに置く必要があります。

• コアサイト.xml
• hdfs-サイト.xml

上記の2つのhadoop設定ファイルをhbaseインストールディレクトリの下のconfフォルダにコピーする必要があります。

1. vim hbase-env.sh

#Java環境変数を設定する export JAVA_HOME=/export/servers/jdk
#hbase クラスターが外部の zk クラスターによって管理され、組み込みの zk クラスターを使用しないことを指定します。エクスポート HBASE_MANAGES_ZK=false

2. vim hbase-site.xml

       <!-- HDFS 上で hbase が保存されているパスを指定します -->
    <プロパティ>
        <name>hbase.rootdir</name>
<値>hdfs://node1:9000/hbase</値>
    </プロパティ>
        <!-- hbase が分散されていることを指定します -->
    <プロパティ>
<name>hbase.cluster.distributed</name>
        <値>真</値>
    </プロパティ>
        <!-- zk のアドレスを指定します。複数のアドレスは「,」で区切ります -->
    <プロパティ>
        <名前>hbase.zookeeper.quorum</名前>
<値>ノード1:2181、ノード2:2181、ノード3:2181</値>
    </プロパティ>

3. vim リージョンサーバー

#どのノードがHRegionServerであるかを指定します
ノード2
ノード3

4. vim バックアップマスター

#どのノードがスタンバイHmasterであるかを指定します
ノード2

7. hbase環境変数を設定する

vim /etc/プロファイル

エクスポート HBASE_HOME=/export/servers/hbase
PATH=$PATH:$HBASE_HOME/bin をエクスポートします

8. hbaseディレクトリと環境変数を配布する

scp -r hbase ノード2:/export/servers
scp -r hbase ノード3:/export/servers
scp /etc/profile ノード2:/etc
scp /etc/profile ノード3:/etc

9. すべてのhbaseノードの環境変数を有効にする

すべてのノードで実行

• ソース /etc/profile

4. hbaseクラスターを起動および停止する

1. hbaseクラスターを起動する

まずZKとHadoopのクラスターを起動します

次にhbase/binを介して

hbase.sh を起動します

• このスクリプトはどこから開始しますか? まず、現在のマシン (ライブ HMaster) で HMaster プロセスを開始します。
• 対応するノードで、regionserversファイルを使用してHRegionServerを起動します。
• バックアップマスターファイルを介して対応するノード上のスタンバイHMasterを起動します。

2. hbaseクラスターを停止する

hbase/bin経由

hbase.sh を停止します

hbase クラスター Web 管理インターフェース

1. hbaseクラスターを起動した後

アクセスアドレス

HMasterホスト名: 16010

5. Hbaseシェルのコマンドライン操作

hbase/bin/hbase shell hbaseシェルクライアントコマンド操作を入力します

1. テーブルを作成する

't_user_info'、'base_info'、'extra_info' を作成します
't1'、{NAME => 'f1'}、{NAME => 'f2'}、{NAME => 'f3'} を作成します。

2. テーブルがあるか確認する

リスト
sql:show tables in mysqlテーブルに類似

3. テーブルの説明情報を表示する

't_user_info' を記述する

4. テーブルのプロパティを変更する

#列ファミリーのバージョンの最大数を変更する alter 't_user_info', NAME => 'base_info', VERSIONS => 3

5. テーブルにデータを追加する

't_user_info'、'00001'、'base_info:name'、'zhangsan' と入力します
't_user_info'、'00001'、'base_info:age'、'30' と入力します
't_user_info'、'00001'、'base_info:address'、'北京' と入力します
't_user_info'、'00001'、'extra_info:school'、'shanghai' と入力します
't_user_info'、'00002'、'base_info:name'、'lisi' を入力します。

6. テーブルデータのクエリ

//条件に従ってクエリを実行する get 't_user_info','00001'
't_user_info'、'00001'、{COLUMN => 'base_info'} を取得します。
't_user_info'、'00001'、{COLUMN => 'base_info:name'} を取得します。
't_user_info'、'00001'、{TIMERANGE => [1544243300660,1544243362660]} を取得します
't_user_info'、'00001'、{COLUMN => 'base_info:age'、VERSIONS =>3} を取得します。
// テーブル全体のクエリスキャン 't_user_info'

7. データの削除

't_user_info'、'00001'、'base_info:name' を削除します
't_user_info','00001' をすべて削除

8. テーブルを削除する

't_user_info' を無効にする
't_user_info' を削除します

6. hbaseの内部原理

• テーブル内のすべての行は、行キーによって辞書順に並べられます。
• テーブルは行方向に複数のH領域に分割されます
• リージョンはサイズによって分割されます (デフォルトでは 10G)。各テーブルには、最初は 1 つのリージョンしかありません。リージョンは拡大し続けます。しきい値まで拡大すると、Hregion は 2 つの新しい Hregion に均等に分割されます。テーブル内の行数が増えると、Hregion の数も増えます。
• Hregion は、Hbase における分散ストレージと負荷分散の最小単位です。最小単位は、異なる Hregion を異なる HRegion サーバーに分散できることを意味します。
• HRegion は負荷分散の最小単位ですが、物理ストレージの最小単位ではありません。 HRegion は 1 つ以上のストアで構成され、各ストアには列ファミリが格納されます。各ストアは、memStore と 0 個から複数の StoreFiles で構成されます。書き込み操作は最初に memstore に書き込まれます。memstore のデータ量が特定のしきい値 (デフォルトでは 128 MB または 1 時間) に達すると、Hregionserver はフラッシュ キャッシュ プロセスを開始して storefile に書き込みます。各書き込みは個別の storefile を形成します。
• ストアファイルの数が一定のしきい値（デフォルトパラメータ hbase.hstore.blockingStoreFiles=10）を超えると、複数のストアファイルが結合されます。リージョン内のすべてのストアのストアファイルサイズの合計、つまりすべてのストアのサイズが hbase.hregion.max.filesize=10G を超えると、リージョンが分割され、現在のリージョンが 2 つに分割されます。Hmaster は、それらを対応するリージョンサーバーに割り当てて、負荷分散を実現します。
• 各 HRegionServer には HLog オブジェクトがあります。HLog は Write Ahead Log を実装するクラスです。ユーザーが MemStore にデータを書き込むたびに、データのコピーも HLog ファイルにも書き込まれます。HLog ファイルは定期的に新しいファイルをロールアウトし、古いファイル (StoreFile に保持されているデータ) を削除します。 HRegionServer が予期せず終了すると、HMaster は Zookeeper を通じてそれを認識します。HMaster はまず残りの HLog ファイルを処理し、異なるリージョンのログ データを分割して、対応するリージョンのディレクトリに配置します。次に、障害が発生したリージョンが再割り当てされます。これらのリージョンを受け取った HRegionServer は、Load Region プロセス中に処理する必要がある履歴 HLog があることを検出します。したがって、HLog 内のデータを MemStore に再生し、StoreFiles にフラッシュしてデータ回復を完了します。

7. HBase アドレス指定メカニズム

RegionServer の検索

• ZooKeeper–> -ROOT-(単一リージョン)–> .META.–> ユーザー テーブル

-ROOT-テーブル

• テーブルには、.META. テーブルが配置されているリージョン リストが含まれます。テーブルには 1 つのリージョンのみが含まれます。
• ルート領域は分割されないため、任意の領域を見つけるには最大 3 回のジャンプが必要になります。
• Zookeeper は -ROOT- テーブルの場所を記録します。

.META. テーブル

• テーブルには、すべてのユーザー空間領域のリストとRegionServerのサーバーアドレスが含まれています。
• .META. テーブルの各行にはリージョンの位置情報が格納され、行キーはテーブル名 + テーブルの最後の行で構成されます。
• アクセスを高速化するために、.META. テーブルのすべての領域がメモリに保存されます。

対象データを照会するには、regionserver に問い合わせてください。

リージョンサーバーは、ターゲットデータが配置されているリージョンを特定し、クエリ要求を発行します。

まずメモリストアで領域が検索され、一致する場合は返されます

メモリストアに見つからない場合は、ストアファイル内をスキャンします (多くのストアファイルをスキャンする場合があります -- ブルームフィルター)。ブルームフィルターは、クエリされた行キーがこのストアファイル内にあるかどうかをすぐに返すことができますが、エラーが発生することもあります。「いいえ」が返された場合、そこには存在しないはずです。「はい」が返された場合、そこには存在しない可能性があります。

8. Hbase 高度なアプリケーション

テーブルを作成する

BLOOMFILTERはデフォルトで行ブルームフィルタに設定されます

• ROW の場合、行が挿入されるたびに行キーのハッシュが Bloom に追加されます。
• ROWCOL の場合、行が挿入されるたびに、行キー + 列ファミリ + 列ファミリ修飾子のハッシュが Bloom テーブルに追加されます。

VSRSIONS のデフォルトは 1 データ バージョンです

• それほど多くのデータを保持する必要がなく、いつでも更新され、古いバージョンのデータは価値がないと考えられる場合は、このパラメータを 1 に設定すると、スペースの 2/3 を節約できます。

圧縮 デフォルト値はNONE圧縮です

• GZIP / LZO / ジッピー / スナッピー

enable_all 'toplist.*' enable_allは正規表現をサポートし、現在一致するテーブルをリストします。

hbase テーブルの事前パーティション分割 - 手動パーティション分割

バッチ書き込みを高速化する 1 つの方法は、事前にいくつかの空の領域を作成することです。データが HBase に書き込まれると、領域のパーティション分割に従ってクラスター内でデータ負荷が分散されます。データがストアファイルサイズに達したときに自動パーティション分割を減らす

時間の消費量が少なく、また別の利点として、行キーの合理的な設計により、各リージョンの同時リクエストを均等に分散（均一になる傾向）して、IO 効率を最大化できます。

行キー設計

列ファミリーの数はできるだけ少なくし、通常は2～3にします。

ロウキー

• 辞書式順序の特性に応じて、バッチでクエリする必要があるデータは、可能な限り連続して保存する必要があります（spear）
• クエリ条件キーワードを可能な限り行キーに組み込み、最も頻繁にクエリされる条件を可能な限り先頭に配置します。
• rowkey はできるだけ短くすることが推奨され、16 バイトを超えないようにしてください。

行キーと列ファミリーのサイズを最小限に抑えます。HBase では、値は常にキーと一緒に送信されます。
HFile の各セルには行キーが格納されます。行キーが大きすぎると、ストレージ効率に影響します。
MemStore はデータの一部をメモリにキャッシュします。行キー フィールドが長すぎると、メモリの有効利用率が低下し、システムはそれ以上のデータをキャッシュできないため、検索効率が低下します。

行キーの上位ビットをプログラムによってランダムに生成されるハッシュ フィールドとして使用し、下位ビットを時間フィールドとして使用することをお勧めします。これにより、各 RegionServer にデータが均等に分散され、負荷分散が実現される可能性が高まります。 （シールド）

行キーの矛盾

• HBase の行は、行キーの辞書式順序でソートされます。この設計により、スキャン操作が最適化され、関連する行や一緒に読み取られる行を隣接する場所に格納して簡単にスキャンできるようになります。ただし、不適切な行キー設計はホットスポットの原因となります。

ホットスポット解像度

• ソルトを追加して、行キーの前にランダムな文字列を追加します。
• 行のハッシュ化には必ずプレフィックスが付けられます
• 固定長または数値の行キーを逆にすると、行キーの順序が失われます。
• タイムスタンプの反転

Long.Max_Value - timestamp を使用してキーの末尾に追加できます (例: [key][reverse_timestamp])。HBase の rowkey は順序付けされており、最初のレコードは最後に入力されたデータであるため、[key] をスキャンして [key] の最初のレコードを取得することで、[key] の最新の値を取得できます。

要約する

以上がこの記事の全内容です。この記事の内容が皆様の勉強や仕事に何らかの参考学習価値をもたらすことを願います。123WORDPRESS.COM をご愛顧いただき、誠にありがとうございます。これについてもっと知りたい場合は、次のリンクをご覧ください。