Hbase

HBaseMemstoreの深い理解



Deep Understanding Hbase Memstore



MemStoreはHBaseの非常に重要な部分です。 MemStoreの動作メカニズム、動作原理、および関連する構成を深く理解することは、HBaseクラスターの管理とパフォーマンスの調整にとって非常に重要です。

以下の理由により、HBaseユーザーまたは管理者は、Memstoreに注意を払い、その使用方法に精通している必要があります。

  • Memstoreには、優れたパフォーマンスを実現し、いくつかの問題を回避するために調整できる多くの構成があります。 HBaseは、ユーザー自身の使用パターンに従ってこれらの構成を調整しません。自分で調整する必要があります。
  • Memstoreの頻繁なフラッシュは、HBaseクラスターの読み取りパフォーマンスに深刻な影響を及ぼし、追加の負荷をもたらす可能性があります。
  • Memstoreフラッシュの方法は、HBaseスキーマ設計に影響を与える可能性があります

これらの点について詳しく説明しましょう。



Memstoreフラッシュの構成

Memstore Flushの場合、2つの主要な構成項目があります。

  • フラッシュをトリガーするタイミングを決定します
  • フラッシュがトリガーされるタイミングを決定し、フラッシュ中に更新がブロックされます（ブロック）

最初のグループは、「通常の」フラッシュのトリガーに関するものです。このタイプのフラッシュが発生しても、並列書き込み要求には影響しません。このタイプのフラッシュの構成項目は次のとおりです。



  • hbase.hregion.memstore.flush.size
1 2 3 4 5 6 7 8 9 <property><name>hbase.hregion.memstore.flush.sizename><value >134217728value><description>Memstore will be flushed to disk if size of the memstoreexceeds this number of bytes. Value is checked by a thread that runsevery hbase.server.thread.wakefrequency. description> property>
  • base.regionserver.global.memstore.lowerLimit
1 2 3 4 5 6 7 8 9 10 <property><name>hbase.regionserver.global.memstore.lowerLimitname><value >0.35value><description>Maximum size of all memstores in a region server beforeflushes are forced. Defaults to 35% of heap.This value equal to hbase.regionserver.global.memstore.upperLimit causesthe minimum possible flushing to occur when updates are blocked due tomemstore limiting. description> property>

最初の設定は各Memstoreのサイズであることに注意してください。この構成項目を設定するときは、各RSによって運ばれる領域の合計量を考慮する必要があります。最初に設定した値が比較的小さい場合は、領域が大きくなるにつれて、2番目の設定理由により、Memstoreのフラッシュトリガーがはるかに早くなる可能性があります。

2番目の設定セットは、主にセキュリティ上の理由によるものです。クラスターの「書き込み負荷」が非常に高く、書き込みボリュームが常にフラッシュボリュームを超えている場合があります。現時点では、memstoreが特定のセキュリティ設定を超えないことを願っています。この場合、memstoreが「管理可能な」サイズに復元されるまで、書き込み操作はブロックされます。このタイプのフラッシュ構成アイテムは次のとおりです。

  • hbase.regionserver.global.memstore.upperLimit
1 2 3 4 5 6 7 8 9 <property><name>hbase.regionserver.global.memstore.upperLimitname><value >0.4value><description>Maximum size of all memstores in a region server before newupdates are blocked and flushes are forced. Defaults to 40% of heap.Updates are blocked and flushes are forced until size of all memstoresin a region server hits hbase.regionserver.global.memstore.lowerLimit. description> property>
  • hbase.hregion.memstore.block.multiplier
1 2 3 4 5 6 7 8 9 10 11 12 <property><name>hbase.hregion.memstore.block.multipliername><value >2value><description>Block updates if memstore has hbase.hregion.block.memstoretime hbase.hregion.flush.size bytes. Useful preventingrunaway memstore during spikes in update traffic. Without anupper-bound, memstore fills such that when it flushes the resultant flush files take a long time to compact or split, orworse, we OOME.description> property>

ノードの「書き込みブロック」はノードに大きな影響を与えますが、クラスター全体に大きな影響を与えます。 HBaseは、各リージョンが1つのRSにのみ属するように設計されていますが、「書き込み負荷」はクラスター全体（すべてのリージョン）に均等に分散されます。このような「遅い」ノードがあると、クラスター全体が遅くなります（最も明らかに速度に反映されます）。



促す ：MemstoreのサイズとMemstoreフラッシュキューのサイズについて深刻な懸念があります。理想的には、Memstoreのサイズがhbase.regionserver.global.memstore.upperLimitの設定に達してはならず、Memstoreフラッシュキューのサイズが拡大し続けることはできません。

頻繁なMemstoreフラッシュ

「書き込みブロッキング」を回避するには、「書き込み操作」のしきい値をトリガーするために、できるだけ早くフラッシュ操作を実行する必要があるようです。ただし、これにより頻繁なフラッシュ操作が発生し、その結果、読み取りパフォーマンスが低下し、負荷が増加します。

各MemstoreFlushは、CFごとにHFileを作成します。頻繁なフラッシュは、多数のHFileを作成します。このように、HBaseは検索時に多数のHFileを読み取る必要があり、読み取りパフォーマンスに大きな影響を与えます。

あまりにも多くのHFileを開かないようにし、読み取りパフォーマンスの低下を防ぐために、HBaseには特別なHFile圧縮プロセス（HFile圧縮プロセス）があります。 HBaseは、定期的に複数の小さなHFileを1つの大きなHFileにマージします。明らかに、Memstore Flushによって生成されるHFileが多いほど、クラスターシステムが実行する必要のあるマージ操作（追加の負荷）が多くなります。さらに悪いことに、圧縮処理はクラスター上の他の要求と並行して実行されます。 HBaseが圧縮に対応できない場合（しきい値設定項目もあります）、RSで「書き込みブロッキング」が発生します。上記のように、これは最も望ましくありません。

促す ：RSの圧縮キューのサイズについて真剣に懸念しているe。問題が発生する前に、増加を止めてください。

HFileの作成とマージの詳細については、を参照してください。 HBaseのフラッシュと圧縮の視覚化 。

理想的には、hbase.regionserver.global.memstore.upperLimitの下で、Memstoreはできるだけ多くのメモリを使用する必要があります（実際のヒープではなく、Memstore部分に構成されます）。次の図は、「より良い」状況を示しています。

「やや」。これは、下限を超えることはほとんどないため、下限を上限に近づけるように構成できるためです。

「下限」を「上限」に近づけることができ、それを超えることはめったにないため、「より良い」と言います。

複数列のファミリとMemstoreフラッシュ

Memstore Flushのたびに、CFごとに新しいHFileが作成されます。このように、異なるCFのデータ量の不均衡により、HFileが多すぎます。1つのCFのMemstoreがしきい値フラッシュに達すると、他のすべてのCFもフラッシュされます。上記のように、フラッシュの頻度が高すぎたり、HFileが多すぎたりすると、クラスターのパフォーマンスに影響します。

促す ：多くの場合、CFが最適な設計です。

HLog（WAL）サイズとMemstoreフラッシュ

最初のHBase読み取り/書き込みパス図では、データが書き込まれるときに、デフォルトで先行書き込みログ（WAL）に書き込まれることに気付いたかもしれません。 WALには、Memstoreに書き込まれたが、HFileにまだフラッシュされていないすべての変更（編集）が含まれています。 Memstoreのデータは永続化されていません。 RegionSeverがダウンした場合、WALを使用してデータを復元できます。

WAL（HBaseではHLogになります）が非常に大きくなると、回復に長い時間がかかります。したがって、WALのサイズにはいくつかの制限があります。これらの制限に達すると、Memstoreのフラッシュがトリガーされます。 MemstoreフラッシュはWALを削減します。これは、データが永続化された後（HFileに書き込まれた後）、これらの変更をWALに保存する必要がないためです。構成できるプロパティは2つあります。

  • hbase.regionserver.hlog.blocksize
  • hbase.regionserver.maxlogs

WALの最大値は、hbase.regionserver.maxlogs * hbase.regionserver.hlog.blocksize（デフォルトでは2GB）によって決定されることに気付いたかもしれません。この値に達すると、Memstoreフラッシュがトリガーされます。したがって、Memstoreのサイズを大きくして他のMemstore設定を調整する場合は、HLog構成アイテムも調整する必要があります。そうしないと、WALサイズ制限が最初にトリガーされる可能性があるため、Memstore用に特別に設計された他の最適化を利用できなくなります。これを除けば、WAL制限を介してMemstoreのフラッシュをトリガーするのは最善の方法ではありません。これを行うと、一度に多くの領域がフラッシュされる可能性がありますが、「書き込みデータ」はクラスター全体に十分に分散されているため、フラッシュ「ビッグストーム」が発生する可能性があります。

促す ：hbase.regionserver.hlog.blocksize * hbase.regionserver.maxlogsをhbase.regionserver.global.memstore.lowerLimit * HBASE_HEAPSIZEよりわずかに大きく設定することをお勧めします。

圧縮とMemstoreフラッシュ

HBaseは、HDFSに保存されているデータ（HFilesなど）を圧縮することをお勧めします。ハードディスクのスペースを節約するだけでなく、ハードディスクとネットワークのIOも大幅に削減します。圧縮を使用すると、MemstoreがデータをフラッシュしてHDFSに書き込むときに、データが圧縮されます。圧縮によってフラッシュプロセスがそれほど遅くなることはありませんが、Memstoreの増加（上限を超える）によって引き起こされる「書き込みブロッキング」などの上記の問題は大幅に軽減されます。

促す ：圧縮ライブラリでは、Snappyの使用を推奨しています。 Snappyの紹介とインストールについては、以下を参照してください。 Hadoop圧縮-SNAPPYアルゴリズム 'with' HadoopHBase構成のインストールSnappyUltimateチュートリアル

》