HBase を使用する理論と実践

こんにちは私の名前は Danil Lipovoy です。Sbertech のチームは、運用データのストレージとして HBase の使用を開始しました。 それを勉強する過程で、体系化して説明したいと思う経験が蓄積されました（多くの人に役立つことを願っています）。 以下のすべての実験は、HBase バージョン 1.2.0-cdh5.14.2 および 2.0.0-cdh6.0.0-beta1 を使用して実行されました。

1. 一般的なアーキテクチャ
2. HBASE へのデータの書き込み
3. HBASE からのデータの読み取り
4. データキャッシング
5. バッチデータ処理 MultiGet/MultiPut
6. テーブルを領域に分割する戦略 (分割)
7. 耐障害性、コンパクト化、データの局所性
8. 設定とパフォーマンス
9. ストレステスト
10. 所見

1. 一般的なアーキテクチャ

バックアップ マスターは、ZooKeeper ノード上のアクティブ マスターのハートビートをリッスンし、消滅した場合にはマスターの機能を引き継ぎます。

2. HBASE へのデータの書き込み

まず、最も単純なケース、つまり put(rowkey) を使用してキーと値のオブジェクトをテーブルに書き込むケースを見てみましょう。 クライアントはまず、hbase:meta テーブルを保存するルート領域サーバー (RRS) がどこにあるかを調べる必要があります。 彼はこの情報を ZooKeeper から受け取ります。 その後、RRS にアクセスし、hbase:meta テーブルを読み取り、そこから、対象のテーブル内の特定の行キーのデータの格納を担当する RegionServer (RS) に関する情報を抽出します。 将来の使用に備えて、メタ テーブルはクライアントによってキャッシュされるため、後続の呼び出しは RS に直接送信され、より速く行われます。

次に、リクエストを受け取った RS は、まずクラッシュ時の復旧に必要な WriteAheadLog (WAL) にリクエストを書き込みます。 次に、データを MemStore に保存します。 これは、特定の領域のソートされたキーのセットを含むメモリ内のバッファーです。 テーブルは複数の領域 (パーティション) に分割でき、各領域には互いに素なキーのセットが含まれます。 これにより、リージョンを異なるサーバーに配置して、より高いパフォーマンスを実現できます。 ただし、このステートメントの明白さにもかかわらず、これがすべての場合に機能するわけではないことが後でわかります。

MemStore にエントリを配置すると、エントリが正常に保存されたという応答がクライアントに返されます。 ただし、実際には、データはバッファにのみ保存され、一定の時間が経過した後、またはディスクが新しいデータで満たされた場合にのみディスクに格納されます。

「削除」操作を行った場合、データは物理的に削除されません。 これらは単純に削除済みとしてマークされ、破棄自体は主要なコンパクト関数を呼び出した瞬間に行われます。これについては段落 7 で詳しく説明します。

HFile 形式のファイルは HDFS に蓄積され、時折、何も削除せずに小さなファイルを大きなファイルにマージするマイナー コンパクト プロセスが起動されます。 時間が経つと、これはデータの読み取り時にのみ発生する問題になります (これについては少し後で説明します)。

上で説明したロード プロセスに加えて、はるかに効果的な手順があり、これがおそらくこのデータベースの最も強力な側面である BulkLoad です。 それは、HFile を独自に作成してディスクに配置することで、完全に拡張し、非常にまともな速度を達成できるという事実にあります。 実際、ここでの制限は HBase ではなく、ハードウェアの機能です。 以下は、16 個の RegionalServer と 16 個の NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 スレッド)、HBase バージョン 1.2.0-cdh5.14.2 で構成されるクラスターでのブート結果です。

ここでは、テーブル内のパーティション (リージョン) の数と Spark エグゼキュータの数を増やすことで、ダウンロード速度が向上することがわかります。 また、速度は録音音量によって異なります。 大きなブロックでは MB/秒が増加し、小さなブロックでは単位時間あたりに挿入されるレコードの数が増加します。その他の条件はすべて同じです。

10 つのテーブルへのロードを同時に開始して、速度を 600 倍にすることもできます。 以下では、1275 つのテーブルへの 623 KB ブロックの書き込みがそれぞれ約 11 MB/秒 (合計 XNUMX MB/秒) の速度で一度に行われることがわかります。これは、XNUMX つのテーブルへの書き込み速度 XNUMX MB/秒と一致します (「上記No.XNUMX)

しかし、50 KB のレコードを含む XNUMX 回目の実行では、ダウンロード速度がわずかに増加していることがわかり、制限値に近づいていることがわかります。 同時に、HBASE 自体には実質的に負荷が発生しないことに留意する必要があります。必要なのは、最初に hbase:meta からデータを与え、HFiles をライニングした後、BlockCache データをリセットして、空でない場合は、MemStore バッファをディスクに保存します。

3. HBASE からのデータの読み取り

クライアントが hbase:meta からのすべての情報をすでに持っていると仮定すると (ポイント 2 を参照)、リクエストは必要なキーが保存されている RS に直接送られます。 まず、MemCache で検索が実行されます。 そこにデータがあるかどうかに関係なく、検索は BlockCache バッファーでも実行され、必要に応じて HFiles でも​​実行されます。 ファイル内でデータが見つかった場合、そのデータは BlockCache に配置され、次のリクエストでより速く返されます。 HFile での検索は、ブルーム フィルターの使用により比較的高速です。 少量のデータを読み取ると、このファイルに必要なキーが含まれているかどうかがすぐに判断され、含まれていない場合は次のキーに進みます。

これら XNUMX つのソースからデータを受信すると、RS は応答を生成します。 特に、クライアントがバージョン管理を要求した場合は、見つかったオブジェクトの複数のバージョンを一度に転送できます。

4. データのキャッシュ

MemStore バッファと BlockCache バッファは、割り当てられたオンヒープ RS メモリの最大 80% を占有します (残りは RS サービス タスク用に予約されています)。 一般的な使用モードが、プロセスが同じデータを書き込み、すぐに読み取るようなものである場合、BlockCache を減らして MemStore を増やすことは理にかなっています。 書き込みデータが読み取り用のキャッシュに入れられない場合、BlockCache の使用頻度は低くなります。 BlockCache バッファは、LruBlockCache (常にオンヒープ) と BucketCache (通常はオフヒープまたは SSD 上) の 8 つの部分で構成されます。 BucketCache は、大量の読み取りリクエストがあり、LruBlockCache に収まらない場合に使用する必要があります。これにより、ガベージ コレクターがアクティブに動作します。 同時に、読み取りキャッシュの使用によるパフォーマンスの急激な向上も期待できませんが、これについては段落 XNUMX で戻ります。

RS 全体に XNUMX つの BlockCache があり、テーブルごとに XNUMX つの MemStore (列ファミリーごとに XNUMX つ) があります。

Как 説明された 理論的には、書き込み時にデータはキャッシュに入りません。実際、テーブルの CACHE_DATA_ON_WRITE パラメータや RS の「書き込み時のデータのキャッシュ」パラメータは false に設定されます。 ただし、実際には、データを MemStore に書き込み、それをディスクにフラッシュし (つまりクリアし)、結果のファイルを削除すると、get リクエストを実行することでデータを正常に受信できます。 さらに、BlockCache を完全に無効にしてテーブルに新しいデータを入力し、MemStore をディスクにリセットして削除し、別のセッションからリクエストしたとしても、それらは依然としてどこかから取得されます。 つまり、HBase にはデータだけでなく、神秘的な謎も保存されています。

hbase(main):001:0> create 'ns:magic', 'cf'
Created table ns:magic
Took 1.1533 seconds
hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'
Took 0.2610 seconds
hbase(main):003:0> flush 'ns:magic'
Took 0.6161 seconds
hdfs dfs -mv /data/hbase/data/ns/magic/* /tmp/trash
hbase(main):002:0> get 'ns:magic', 'key1'
 cf:c      timestamp=1534440690218, value=try_to_delete_me

「読み取り時のデータのキャッシュ」パラメータは false に設定されます。 アイデアがある場合は、コメントで議論してください。

5. バッチデータ処理 MultiGet/MultiPut

単一のリクエスト (Get/Put/Delete) の処理は非常に負荷の高い操作であるため、可能であればそれらを List または List に結合する必要があります。これにより、パフォーマンスが大幅に向上します。 これは特に書き込み操作に当てはまりますが、読み取り時には次のような落とし穴があります。 以下のグラフは、MemStore から 50 レコードを読み取るのにかかる時間を示しています。 読み取りは 000 つのスレッドで実行され、横軸はリクエスト内のキーの数を示します。 ここでは、XNUMX つのリクエストでキーが XNUMX 個に増加すると、実行時間が短縮されることがわかります。 速度が上がります。 ただし、MSLAB モードがデフォルトで有効になっている場合、このしきい値を超えるとパフォーマンスが急激に低下し、レコード内のデータ量が増えるほど動作時間が長くなります。

テストは、8 コア、バージョン HBase 2.0.0-cdh6.0.0-beta1 の仮想マシンで実行されました。

MSLAB モードは、新世代のデータと古い世代のデータが混在することで発生するヒープの断片化を軽減するように設計されています。 回避策として、MSLAB が有効な場合、データは比較的小さなセル (チャンク) に配置され、チャンク単位で処理されます。 その結果、要求されたデータ パケットのボリュームが割り当てられたサイズを超えると、パフォーマンスが急激に低下します。 一方、このモードをオフにすることもお勧めできません。集中的なデータ処理の瞬間に GC が原因で停止する可能性があるからです。 良い解決策は、読み取りと同時に put を介してアクティブに書き込みを行う場合にセルの体積を増やすことです。 記録後に、MemStore をディスクにリセットするフラッシュ コマンドを実行する場合、または BulkLoad を使用してロードする場合には、問題は発生しないことに注意してください。 以下の表は、より大きな (同じ量の) データを MemStore からクエリすると速度が低下することを示しています。 ただし、チャンクサイズを増やすと、処理時間が通常に戻ります。

チャンクサイズを増やすことに加えて、データをリージョンごとに分割すると効果的です。 テーブル分割。 その結果、各リージョンに届くリクエストが減り、リクエストがセルに収まる場合でも、応答は良好なままになります。

6. テーブルを領域に分割する戦略 (分割)

HBase はキーと値のストレージであり、パーティション分割はキーによって実行されるため、データをすべてのリージョンに均等に分割することが非常に重要です。 たとえば、このようなテーブルを XNUMX つの部分に分割すると、データは XNUMX つの領域に分割されます。

たとえば、後でロードされるデータが長い値であり、そのほとんどが同じ桁で始まる場合、これが急激な速度の低下につながることがあります。

1000001
1000002
...
1100003

キーはバイト配列として格納されるため、キーはすべて同じように始まり、この範囲のキーを格納する同じ領域 #1 に属します。 いくつかのパーティショニング戦略があります。

HexStringSplit – キーを「00000000」 => 「FFFFFFFF」の範囲の XNUMX 進数でエンコードされた文字列に変換し、左側をゼロでパディングします。

UniformSplit – キーを、「00」 => 「FF」の範囲の XNUMX 進エンコードと右側のゼロ パディングを使用したバイト配列に変換します。

さらに、分割する任意の範囲またはキーのセットを指定し、自動分割を構成できます。 ただし、最もシンプルで効果的なアプローチの 32 つは、UniformSplit とハッシュ連結の使用です。たとえば、CRCXNUMX(rowkey) 関数によるキーの実行からの最も重要なバイトのペアと行キー自体です。

ハッシュ + 行キー

そうすれば、すべてのデータがリージョン間で均等に分散されます。 読み取り時、最初の XNUMX バイトは単純に破棄され、元のキーは残ります。 RS は、領域内のデータとキーの量も制御し、制限を超えた場合は自動的に部分に分割します。

7. 耐障害性とデータの局所性

各キー セットを担当するリージョンは XNUMX つだけであるため、RS のクラッシュまたは廃止に関連する問題の解決策は、必要なデータをすべて HDFS に保存することです。 RS が低下すると、マスターは ZooKeeper ノードにハートビートがないことによってこれを検出します。 次に、提供される領域を別の RS に割り当てます。HFile は分散ファイル システムに保存されているため、新しい所有者がそれらを読み取り、データの提供を続けます。 ただし、一部のデータは MemStore にあり、HFile に取り込む時間がなかった可能性があるため、同じく HDFS に保存されている WAL を使用して操作の履歴を復元します。 変更が適用された後、RS はリクエストに応答できるようになりますが、この移動により、一部のデータとデータにサービスを提供するプロセスが別のノードに配置されることになります。 地域性が減ってきています。

この問題の解決策はメジャー コンパクションです。この手順では、ファイルをそのファイルを担当するノード (領域が配置されている場所) に移動します。その結果、この手順中にネットワークとディスクの負荷が急激に増加します。 ただし、将来的には、データへのアクセスが著しく高速化されます。 さらに、major_compaction は、領域内のすべての HFile を XNUMX つのファイルにマージし、テーブル設定に応じてデータをクリーンアップします。 たとえば、保持する必要があるオブジェクトのバージョン数や、オブジェクトが物理的に削除されるまでの存続期間を指定できます。

この手順は、HBase の動作に非常に良い影響を与える可能性があります。 下の図は、アクティブなデータ記録の結果としてパフォーマンスがどのように低下​​したかを示しています。 ここでは、40 個のスレッドが 40 つのテーブルにどのように書き込み、同時に XNUMX 個のスレッドがデータを読み取るかを確認できます。 書き込みスレッドはますます多くの HFile を生成し、他のスレッドによって読み取られます。 その結果、ますます多くのデータをメモリから削除する必要があり、最終的には GC が動作し始め、実質的にすべての作業が麻痺します。 大規模な圧縮の開始により、結果として生じた破片が除去され、生産性が回復しました。

テストは 3 つのデータノードと 4 つの RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 スレッド) で実行されました。 HBase バージョン 1.2.0-cdh5.14.2

主要な圧縮は、データがアクティブに書き込まれたり読み取られたりする「ライブ」テーブル上で開始されたことに注目する価値があります。 これにより、データを読み取るときに誤った応答が発生する可能性があるとネット上で記述がありました。 確認するために、新しいデータを生成してテーブルに書き込むプロセスが起動されました。 その後、すぐに読んで、結果の値が書き留められた値と一致するかどうかを確認しました。 このプロセスの実行中、大規模な圧縮は約 200 回実行されましたが、失敗は XNUMX つも記録されませんでした。 おそらく、問題が発生するのはまれで、高負荷時にのみ発生するため、計画どおりに書き込みおよび読み取りプロセスを停止し、クリーニングを実行して、このような GC ドローダウンを防ぐ方が安全です。

また、メジャー コンパクションは MemStore の状態には影響しません。MemStore をディスクにフラッシュして圧縮するには、flush (connection.getAdmin().flush(TableName.valueOf(tblName))) を使用する必要があります。

8. 設定と演奏

すでに述べたように、HBase は BulkLoad の実行時に何もする必要がない場合に最大の成功を示します。 ただし、これはほとんどのシステムと人に当てはまります。 ただし、このツールは、大きなブロックに大量のデータを保存するのにより適していますが、プロセスで複数の競合する読み取りおよび書き込みリクエストが必要な場合は、上記の Get および Put コマンドが使用されます。 最適なパラメーターを決定するために、テーブルのパラメーターと設定をさまざまに組み合わせて起動が実行されました。

• 10 個のスレッドが同時に 3 回連続で起動されました (これをスレッドのブロックと呼びます)。
• ブロック内のすべてのスレッドの動作時間は平均され、ブロックの動作の最終結果となりました。
• すべてのスレッドが同じテーブルで動作しました。
• スレッド ブロックが開始されるたびに、大規模な圧縮が実行されました。
• 各ブロックは、次の操作のうち XNUMX つだけを実行しました。

-置く
-得る
—ゲット+プット

• 各ブロックは、その操作を 50 回繰り返し実行しました。
• レコードのブロック サイズは 100 バイト、1000 バイト、または 10000 バイト (ランダム) です。
• ブロックは、要求されたさまざまな数のキー (10 つのキーまたは XNUMX つのキー) で起動されました。
• ブロックは異なるテーブル設定で実行されました。 変更されたパラメータ:

— BlockCache = オンまたはオフ
— ブロックサイズ = 65 KB または 16 KB
— パーティション = 1、5、または 30
— MSLAB = 有効または無効

したがって、ブロックは次のようになります。

ａ． MSLABモードのオン/オフを切り替えました。
b. 次のパラメータが設定されたテーブルが作成されました: BlockCache = true/none、BlockSize = 65/16 Kb、Partition = 1/5/30。
c. 圧縮はGZに設定されました。
d. 10 個のスレッドが同時に起動され、1/10/100 バイトのレコードを含むこのテーブルに対して 1000/10000 put/get/get+put 操作が実行され、連続して 50 クエリが実行されました (ランダム キー)。
e. ポイント d を XNUMX 回繰り返しました。
f. すべてのスレッドの動作時間を平均しました。

考えられるすべての組み合わせがテストされました。 レコード サイズが増加すると速度が低下するか、キャッシュを無効にすると速度が低下することが予測できます。 ただし、目的は各パラメーターの影響の程度と重要性を理解することであったため、収集されたデータは線形回帰関数の入力に入力され、t 統計を使用して重要性を評価できるようになりました。 以下は、Put 操作を実行したブロックの結果です。 組み合わせのフルセット 2*2*3*2*3 = 144 オプション + 72 tk。 いくつかは216回行われました。 したがって、合計 XNUMX 回の実行が行われます。

テストは、3 つのデータノードと 4 つの RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 スレッド) で構成されるミニクラスターで実行されました。 HBase バージョン 1.2.0-cdh5.14.2。

最高の挿入速度 3.7 秒は、MSLAB モードをオフにし、パーティションが 16 つあるテーブルで、BlockCache が有効、BlockSize = 100、レコードが 10 バイト、パックあたり XNUMX 個の場合に得られました。
最低の挿入速度である 82.8 秒は、MSLAB モードが有効で、パーティションが 16 つあるテーブルで BlockCache が有効、BlockSize = 10000、1 バイトのレコードが XNUMX つある場合に得られました。

それではモデルを見てみましょう。 R2 に基づくモデルの品質が優れていることがわかりますが、ここでは外挿が禁忌であることは明らかです。 パラメーターが変化したときのシステムの実際の動作は線形ではありません。このモデルは予測のためではなく、指定されたパラメーター内で何が起こったのかを理解するために必要です。 たとえば、ここでは Student の基準から、BlockSize パラメータと BlockCache パラメータが Put 操作には重要ではないことがわかります (これは一般に非常に予測可能です)。

しかし、パーティションの数を増やすとパフォーマンスが低下するという事実は、理解できるものではありますが、いくぶん予想外です (BulkLoad でパーティションの数を増やすことによるプラスの影響はすでに確認しました)。 まず、処理のために、30 つのリージョンではなく XNUMX のリージョンに対してリクエストを生成する必要がありますが、データ量はこれによって利益が得られるほどではありません。 第二に、総動作時間は最も遅い RS によって決定され、DataNode の数が RS の数よりも少ないため、一部の領域では局所性がゼロになります。 それでは、トップ XNUMX を見てみましょう。

次に、Get ブロックの実行結果を評価してみましょう。

パーティションの数は重要性を失いましたが、これはおそらく、データが適切にキャッシュされ、読み取りキャッシュが最も重要な (統計的に) パラメーターであるという事実によって説明されます。 当然のことながら、リクエスト内のメッセージの数を増やすこともパフォーマンスに非常に役立ちます。 トップスコア:

さて、最後に、最初に get を実行してから put を実行したブロックのモデルを見てみましょう。

ここではすべてのパラメータが重要です。 そしてリーダーたちの結果は次のとおりです。

9. 負荷テスト

さて、最終的には多かれ少なかれまともなロードを開始しますが、比較するものがあると常に興味深いものになります。 Cassandra の主要な開発者である DataStax の Web サイトには、次のとおりです。 結果 HBase バージョン 0.98.6-1 を含む、多数の NoSQL ストレージの NT。 ロードは 40 スレッド、データ サイズ 100 バイト、SSD ディスクによって実行されました。 読み取り-変更-書き込み操作をテストした結果、次の結果が得られました。

私が理解している限り、読み取りは 100 レコードのブロックで実行され、16 個の HBase ノードについて、DataStax テストでは 10 秒あたり XNUMX 回の操作のパフォーマンスが示されました。

私たちのクラスターにも 16 個のノードがあるのは幸いですが、それぞれに 64 個のコア (スレッド) があるのに対し、DataStax テストでは 4 個しかないのはあまり「幸運」ではありません。一方、それらには SSD ドライブがあり、一方私たちは HDD を持っています。新しいバージョンの HBase と負荷時の CPU 使用率は、実際には大幅に増加しませんでした (視覚的には 5 ～ 10 パーセント)。 ただし、この構成を使用してみましょう。 デフォルトのテーブル設定では、読み取りは 0 ～ 50 万のキー範囲でランダムに実行されます (つまり、基本的に毎回新しいもの)。 テーブルには 50 万件のレコードが含まれており、64 のパーティションに分割されています。 キーは crc32 を使用してハッシュされます。 テーブル設定はデフォルトで、MSLAB が有効になっています。 40 個のスレッドを起動すると、各スレッドは 100 個のランダム キーのセットを読み取り、生成された 100 バイトをこれらのキーに即座に書き込みます。

スタンド: 16 DataNode および 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 スレッド)。 HBase バージョン 1.2.0-cdh5.14.2。

平均結果は 40 秒あたり 10 オペレーションに近く、DataStax テストよりも大幅に優れています。 ただし、実験目的であれば、条件をわずかに変更することができます。 すべての作業が 100 つのテーブル上で排他的に実行され、また一意のキーのみで実行される可能性はほとんどありません。 主な負荷を生成する特定の「ホット」キーのセットがあると仮定しましょう。 したがって、4 つの異なるテーブルで、より大きなレコード (50 KB) のロードを 40 個のバッチで作成し、要求されたキーの範囲を 100 に制限してみましょう。下のグラフは、10 スレッドの起動を示しています。各スレッドは読み取ります。 XNUMX 個のキーのセットを作成し、これらのキーにランダムな XNUMX KB を即座に書き込みます。

スタンド: 16 DataNode および 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 スレッド)。 HBase バージョン 1.2.0-cdh5.14.2。

ロード中に、上に示したようにメジャー コンパクションが数回起動されます。この手順を行わないと、パフォーマンスは徐々に低下しますが、実行中に追加の負荷も発生します。 ドローダウンはさまざまな理由で発生します。 場合によっては、スレッドが動作を終了し、再起動中に一時停止が発生したり、サードパーティのアプリケーションによってクラスターに負荷が発生したりすることがありました。

読み取ってすぐに書き込むことは、HBase にとって最も困難な作業シナリオの 100 つです。 小さな put リクエスト (たとえば 10 バイト) だけを作成し、それらを 50 ～ 50 個のパックに結合する場合、XNUMX 秒あたり数十万の操作が発生する可能性があり、状況は読み取り専用リクエストの場合と同様です。 注目に値するのは、その結果が DataStax で得られた結果よりも大幅に優れていること、これは何よりも XNUMX ブロック単位のリクエストによるものです。

スタンド: 16 DataNode および 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 スレッド)。 HBase バージョン 1.2.0-cdh5.14.2。

10 結論

このシステムは非常に柔軟に構成されていますが、多数のパラメータの影響はまだ不明です。 それらの一部はテストされましたが、結果のテスト セットには含まれませんでした。 たとえば、予備実験では、隣接セルからの値を使用して情報をエンコードする DATA_BLOCK_ENCODING などのパラメーターの重要性が低いことが示されましたが、これはランダムに生成されたデータでは理解できます。 多数の重複オブジェクトを使用すると、大幅な効果が得られる可能性があります。 一般に、HBase はかなり本格的でよく考えられたデータベースという印象を与え、大きなデータ ブロックを扱う操作を実行する場合に非常に生産性が高いと言えます。 特に、読み取りプロセスと書き込みプロセスを時間内に分離できる場合はなおさらです。

十分に開示されていないご意見がございましたら、より詳細にお知らせする用意があります。 あなたの経験を共有したり、何か同意できないことがあれば話し合ってください。

出所： habr.com