はじめに：Lao Liuは現在、来年の学校募集に向けて懸命に取り組んでいます。この記事を書く主な目的は、彼が自国語でレビューしたビッグデータの知識ポイントを詳細に説明し、資料に機械的な方法を使用して独自の方法を使用することを拒否することです。理解！
01HBaseナレッジポイント
ポイント6：HRegionServerアーキテクチャ
HRegionServerのアーキテクチャを理解する必要があるのはなぜですか？HBaseクラスター内のデータのストレージはHRegionServerと非常に大きな関係があるため、そのアーキテクチャーを理解することによってのみ、データストレージのロジックを明確にすることができます。
次に、LiuにHRegionServerアーキテクチャをうまく紹介させます。
StoreFile
HRegionServerアーキテクチャ図では、StoreFileは実際のデータを保存する物理ファイルです。StoreFileはHFileの形式でHDFSに保存されます。各ストアには1つ以上のStoreFileがあり、データは各StoreFileで順序付けられます。なぜ整然としているのか、MEMStoreで紹介されます。
HFileとは、ラオスはそれがHDFS上のStoreFileのストレージ形式であることを理解することしかできません。つまり、StoreFileはHFileの形式でHDFSに保存されます。
MemStore
キャッシュの書き込みを意味します。HFileではデータを並べ替える必要があるため、HDFSに保存されているデータに従って行キーに従って並べ替える必要があります。そのため、データは最初にMemStoreに保存され、並べ替え後、しきい値に達した後にStoreFileにフラッシュされます。フラッシュが生成されます新しいStoreFIle。
MemStoreはどのようにデータをソートしますか？多くの機関の教材は言及されていません。多くの資料をチェックした後、Liu Liuは比較的浅い理解しかありません。MemStoreモデルを実現するデータ構造はSkipListであり、効率的なクエリ、挿入、削除を実現できます。ジャンプテーブルは基本的に順序付きリンクリストで構成されているため、多くのKVデータベースはジャンプテーブルを使用して順序付きデータコレクションを実装します。したがって、データがMemStoreに転送された後、ジャンプテーブルを使用してこれらのデータの順序を実現します。
WAL
WAL（フルネームはログ先行書き込み）は、事前にログを書き込むことを意味します。データはHFileにフラッシュする前にMemStoreでソートする必要があるため、データをメモリに保存するとデータが失われる可能性が高いため、この問題を解決するために、データは最初にというファイルに書き込まれます。先行書き込みログ、そしてそれをMemStoreに書き込みます。したがって、システムに障害が発生した場合、データの損失を回避するために、このログファイルを介してデータを再構築できます。
BlockCache
これは、読み取りキャッシュを意味します。毎回クエリされるデータは、次のデータクエリを容易にするためにBlockCacheにキャッシュされます。
ポイント7：HBase読み取りデータプロセス
最初に言うことは、HBaseにはメタテーブル（メタデータテーブル）が1つだけあり、このテーブルにはリージョンテーブルが1つだけあり、リージョンデータはHRegionServerに格納されているということです。
HBaseの最初の記事でのZooKeeperの役割を覚えていますか？ZooKeeperはHBaseメタデータメタを格納します。次に、データを読みたいかどうかを考えます。学校の先生を訪ねるのと同じですか。先生がどの部署やオフィスにいるかを知るために、最初に学校の門に登録する必要がありますか。
したがって、HBaseの読み取りデータプロセスは次のとおりです。
1. HBaseは、最初にzkに接続してデータを読み取る必要があります。zkからメタテーブルのリージョンの場所を見つけます。これは、メタテーブルが格納されているHRegionServerを見つけることです。メッセージを受信すると、クライアントはすぐにとの接続を確立します。このHRegionServerを読み取ってから、メタを読み取ります。テーブル内のデータ、このメタテーブル内の情報には、HBaseクラスター内のテーブル、各テーブルのリージョン、RegionServerの格納先、およびすべてのユーザーテーブルのリージョン情報が含まれます。保存されます。
2.名前空間（リレーショナルデータベースのデータベース名に相当する名前空間）に従って、照会するテーブル名と行キー情報。書き込まれたデータに対応する地域情報を見つけます。
3.次に、このリージョンに対応するRegionServerを見つけて、リクエストを送信します。
4.これで、対応するリージョンを見つけて見つけることができます。
5.最初にMemStoreからデータを探します。そうでない場合は、BlockCacheから読み取ります。BlockCacheで見つからない場合は、最後のStoreFileから読み取ります。StoreFileからデータを読み取った後、結果を直接返すのではありません。クライアントへのデータの場合、後続のクエリを高速化するために、データは最初にBlockCacheに書き込まれ、その後、結果がクライアントに返されます。
ポイント8：HBase書き込みデータプロセス
1.クライアントは、最初にzkからメタテーブルのリージョンの場所を見つけ、次にメタテーブルのデータを読み取ります。メタテーブルには、ユーザーテーブルのリージョン情報が格納されます。
2.名前空間（名前空間、リレーショナルデータベースのデータベース名に相当）に応じて、書き込まれるデータのテーブル名と行キー情報。書き込まれたデータに対応する地域情報を見つけます。
3.次に、このリージョンに対応するRegionServerを見つけて、リクエストを送信します。
4.これで、データをWALに順番に書き込む（追加する）ことができます。
5.対応するMemStoreにデータを書き込むと、データはMemStoreで並べ替えられます。
6. MemStoreのフラッシュ時間に達した後、データをStoreHFileにフラッシュします。
しかし、考えてみてください。データを書き続けると、StoreFilesはたくさんあるのでしょうか。
HBaseクラスターでは、生成された多くのStoreFileに対して、それらを1つの大きなStoreFileにマージし（これは小さなマージです）、最後にすべてのStoreFileが大きなマージを受けます。ただし、連続データ書き込みの過程で、リージョン内のデータはどんどん大きくなります。このとき、リージョンは分割されます（2つに分割されます）。分割プロセスはより多くのパフォーマンスを消費し、事前分割があります。 。
Old Liuは、フラッシュとコンパクトのメカニズム、リージョンの分割とマージ、HBaseでの事前パーティション化が存在する理由について大まかに話しました。これらの知識のポイントについて、以下で詳しく説明します。
ポイント9：HBaseのフラッシュおよびコンパクトメカニズム
フラッシュメカニズム
データをディスクにフラッシュする必要があります。フラッシュだけでなく、多くのフラッシュの機会があります。
1つ目は、Memtoreレベルの制限に到達することです。リージョン内のMemStoreのサイズが上限（デフォルトは128M）に達すると、MemStoreの更新がトリガーされます。上限は次のように設定されます。
<property>
<name>hbase.hregion.memstore.flush.size</name>
<value>134217728</value>
</property>
2つ目は、リージョンレベルの制限に到達することです。リージョン内のすべてのMemStoreの合計サイズが上限に達すると、デフォルトは2 * 128M = 256Mになり、MemStoreの更新がトリガーされます。上限は次のように設定されます。
<property>
<name>hbase.hregion.memstore.flush.size</name>
<value>134217728</value>
</property>
<property>
<name>hbase.hregion.memstore.block.multiplier</name>
<value>2</value>
</property>
3つ目は、RegionServerレベルの制限に到達することです。RegionServer内のすべてのMemStoreの合計サイズが最低水位のしきい値を超えると、RegionServerは強制的にフラッシュを開始します。最初に最大のMemStoreでリージョンをフラッシュしてから、次に大きいMemStoreを実行します。順番に実行します。
書き込み速度がフラッシュ書き込み速度よりも大きい場合、MemStoreの合計サイズは最終的に最高水準点のしきい値を超えます（デフォルトはJVMメモリの40％です）。このとき、RegionServerは更新をブロックし、MemStoreの合計までフラッシュを強制します。サイズが透かしの下限しきい値よりも小さい。これらのしきい値の設定は次のとおりです。
<property>
<name>hbase.regionserver.global.memstore.size.lower.limit</name>
<value>0.95</value>
</property>
<property>
<name>hbase.regionserver.global.memstore.size</name>
<value>0.4</value>
</property>
4つ目は、WALファイルの数がhbase.regionserver.max.logsを超えると、WALファイルの数がhbase.regionserver.max.logに減少するまで、リージョンが時系列でフラッシュされます（この属性名は破棄されました。いいえ今すぐ手動で設定する必要があります。最大は32です）。
5つ目は、MemStoreを定期的に更新することです。デフォルトの期間は1時間で、MemStroeが長期間持続しないようにします。すべてのMemStoreを同時にフラッシュすることによって引き起こされる問題を回避するために、通常のフラッシュ操作には約20,000のランダムな遅延があります。
コンパクトな合併メカニズム
コンパクトマージメカニズムがあるのはなぜですか？
小さなファイルが多すぎるのを防ぎ、クエリの効率を確保するために、hbaseは、必要に応じてこれらの小さなストアファイルを比較的大きなストアファイルにマージする必要があります。このプロセスは圧縮と呼ばれます。
hbaseでマージする圧縮には主に2つのタイプがあります。
マイナーコンパクション
ストア内の複数のHFileを1つのHFileにマージします。このプロセスでは、いくつかの小さな隣接するStoreFileを選択して、それらをより大きなStoreFileにマージします。
TTL（存続時間）を超えるデータ、更新されたデータ、および削除されたデータのみがマークされます。物理的な削除はありません。マイナーコンパクションの結果、生成されるStoreFileの数が少なくなり、メモリが大きくなります。この組み合わせのトリガー頻度は非常に高いです。
マイナーコンパクションのトリガー条件は、次のパラメーターによって決定されます。
<!--表示至少需要三个满足条件的store file时，minor compaction才会启动-->
<property>
<name>hbase.hstore.compactionThreshold</name>
<value>3</value>
</property>
<!--表示一次minor compaction中最多选取10个store file-->
<property>
<name>hbase.hstore.compaction.max</name>
<value>10</value>
</property>
<!--默认值为128m,
表示文件大小小于该值的store file 一定会加入到minor compaction的store file中
-->
<property>
<name>hbase.hstore.compaction.min.size</name>
<value>134217728</value>
</property>
<!--默认值为LONG.MAX_VALUE，
表示文件大小大于该值的store file 一定会被minor compaction排除-->
<property>
<name>hbase.hstore.compaction.max.size</name>
<value>9223372036854775807</value>
</property>
主要な圧縮
すべてのStoreFileを1つのStoreFileに結合すると、プロセスで3種類の意味のないデータがクリーンアップされます。削除されたデータ、TTL期限切れデータ、およびバージョン番号が設定されたバージョン番号を超えるデータです。マージの頻度は比較的低く、デフォルトでは7日に1回実行され、パフォーマンスの消費量が非常に大きくなります。通常、アプリケーションのアイドル時間中に本番環境をシャットダウンして手動でトリガーすることをお勧めします。通常、マージするように手動で制御できます。これにより、ピークのビジネス期間中に表示されないようにすることができます。
主要な締固めトリガー時間条件（7日）
<!--默认值为7天进行一次大合并，-->
<property>
<name>hbase.hregion.majorcompaction</name>
<value>604800000</value>
</property>
手動トリガー
#使用major_compact命令
major_compact tableName
ポイント10：リージョン分割
リージョンには大量の行キーデータが格納されます。リージョンにデータ項目が多すぎると、クエリの効率に直接影響します。領域が大きすぎる場合。Hbaseはリージョンを分割します。これは、Hbaseの利点でもあります。
HBaseのリージョン分割戦略には次のタイプがあります。最初に3つのタイプについて説明しましょう。
1、ConstantSizeRegionSplitPolicy
これは、バージョン0.94より前のデフォルトのセグメンテーション戦略です。
領域のサイズが特定のしきい値（hbase.hregion.max.filesize = 10G）より大きい場合、セグメンテーションがトリガーされ、領域は2つの領域に均等に分割されます。
ただし、このセグメンテーション戦略にはかなりの欠点があります。セグメンテーション戦略では、大きなテーブルと小さなテーブルを区別しません。しきい値の設定を大きくすると、大きなテーブルの方が使いやすくなりますが、小さなテーブルでは分割がトリガーされない場合があり、極端な場合は分割が発生する可能性があります。これはビジネスにとっては良いことではありません。設定が小さい場合は、小さなテーブルに適していますが、テーブルが大きいと、クラスター全体に多数のリージョンが生成されます。これは、クラスター管理、リソースの使用、およびフェイルオーバーには適していません。
2、IncreasingToUpperBoundRegionSplitPolicy
これは、バージョン0.94からバージョン2.0までのデフォルトのセグメンテーション戦略です。
セグメンテーション戦略はもう少し複雑です。一般的に、考え方はConstantSizeRegionSplitPolicyと同じです。設定されたしきい値よりも大きいサイズの領域は、セグメンテーションをトリガーします。ただし、このしきい値はConstantSizeRegionSplitPolicyのような固定値ではありませんが、特定の条件下で常に調整されます。調整ルールは、リージョンが属するテーブルの現在のリージョンサーバー内のリージョンの数に関連しています。
3、SteppingSplitPolicy
これは、バージョン2.0のデフォルトのセグメンテーション戦略です。
このセグメンテーション戦略のセグメンテーションしきい値は再び変更されました。一般に、設計したばかりの場合、不合理な場所がいくつかあります。開発が遅いため、設計者は徐々に改善します。
以前のIncreasingToUpperBoundRegionSplitPolicyと比較すると、よりシンプルであり、分割されるテーブルの現在のリージョンサーバー上のリージョンの数に関連しています。リージョンの数が1に等しい場合、セグメンテーションのしきい値はフラッシュサイズ* 2です。それ以外の場合はMaxRegionFileSizeです。このセグメンテーション戦略は、IncreasingToUpperBoundRegionSplitPolicyよりも、大きなクラスター内の大きなテーブルと小さなテーブルに適しています。小さなテーブルは、多数の小さな領域を生成しませんが、十分です。
まだいくつか残っており、OldLiuはほとんど覚えていません。
ポイント11：リージョンのマージ
リージョンをマージする必要があるのはいつですか？
たとえば、テーブルを分割した後、2つに分割しますが、使用の過程で、これら2つのテーブルのデータが削除され、データ量が少なくなります。管理の便宜のために、それらをマージすることができます。
もう1つの例は、大量のデータを削除することです。このとき、各リージョンは非常に小さくなり、複数のリージョンの保存が無駄になります。このとき、リージョンをマージして、一部のリージョンサーバーノードを減らすことができます。
つまり、リージョンのマージはパフォーマンスのためではなく、保守と管理を容易にするためです。
ポイント12：HBaseテーブルの事前パーティション化
テーブルが作成されたばかりの場合、HBaseはデフォルトでテーブルにリージョンを割り当てます。これは、現時点では、すべての読み取り要求と書き込み要求が同じregionServerの同じ領域にアクセスするということと同じです。現時点では、クラスター内の他のregionServerが比較されている可能性があるため、負荷分散の効果は得られません。アイドル状態。一人が働いて、他の人が演劇を見るという現象がありました。
この問題を解決するには、事前パーティション化を使用できます。これは、テーブルの作成時に構成され、複数のリージョンを生成します。
事前分割の原則
各リージョンはstartRowとendRowKeyを維持します。追加されたデータが特定のリージョンによって維持されるrowKeyの範囲を満たす場合、データはメンテナンスのためにこのリージョンに渡されます。
事前パーティションを手動で指定する方法
方法1：
create 'person','info1','info2',SPLITS => ['1000','2000','3000','4000']
次の効果があります。
方法2：
ファイルにパーティションルールを作成する
cd /kkb/install
vim split.txt
次のようなものを中に追加します。
aaa
bbb
ccc
ddd
このコマンドを実行する場合：
create 'student','info',SPLITS_FILE => '/kkb/install/split.txt'
この効果が得られます：
02まとめ
さて、ビッグデータHBaseの知識ポイントの2番目の部分はほぼ要約されており、内容はもっと多く、注意深く理解し、これらの知識ポイントを自分の言葉で伝えるよう努める必要があります。
最後に、何か悪いことや悪いことを感じたら、公式アカウントに連絡することができます：一生懸命働いているラオス・リウ、そしてコミュニケーション！ビッグデータの開発に興味のある学生の皆様のお役に立てれば幸いです。