Hbaseインタビューの質問（対面）の仕上げ

1. Hbaseとは何ですか？hbaseの特徴は何ですか？

1. Hbaseは、Hadoopのhdfsストレージに基づく列型ストレージに基づく分散データベースであり、zookeeperによって管理されます。
2. Hbaseは、半構造化データまたは非構造化データを格納するのに適しています。構造フィールドが十分に確実でないか、無秩序であり、概念に従って抽出するのが難しいデータです。
3. Hbaseがnullのレコードは保存されません。
4. ベーステーブルには、行キー、タイムスタンプ、および列ファミリが含まれています。新しいデータが書き込まれると、タイムスタンプが更新され、以前のバージョンを同時に照会できます。
5. hbaseはマスタースレーブアーキテクチャです。hmasterはマスターノードであり、hregionserverはスレーブノードです。

2. hbaseはどのようにデータをインポートしますか？

1. HBaseAPIを介してデータをバッチで書き込みます。
2. Sqoopツールを使用して、派生物をHBaseクラスターにバッチ処理します。
3. MapReduceを使用してバッチインポートします。
4. HBaseBulkLoadの方法。

3. hbaseのストレージ構造は何ですか？

Hbaseの各テーブルは、行キー（rowkey）によって特定の範囲に従って複数のサブテーブル（HRegion）に分割されます。デフォルトでは、HRegionが256Mを超えると、2つに分割されます。HRegionServerによって管理され、どのHRegionsがHmasterによって割り当てられているか。HRegionがサブテーブルにアクセスすると、HRegionオブジェクトが作成され、テーブルの列ファミリーごとにストアインスタンスが作成されます。各ストアにはそれに対応する0個以上のStoreFileがあり、各StoreFileはHFile、HFileに対応します。は実際のストレージファイルです。したがって、HRegionにはMemStoreインスタンスもあります。

4. Hbaseとハイブの違いは何ですか？hiveとhbaseの基盤となるストレージは何ですか？ハイブの理由は何ですか？Habaseの欠陥を補うためのhabaseの目的は何ですか？

共通点：

1. hbaseとhiveはどちらもHadoopに基づいています。すべて、基盤となるストレージとしてHadoopを使用します。

違い：

1. Hiveは、MapReducejobsの書き込みを減らすためにHadoop上に構築されたバッチ処理システムです。HBaseは、リアルタイム操作でのHadoopの欠点を補うためにプロジェクトをサポートします。
2. RMDBデータベースを操作していると想像してください。全表スキャンの場合はHive + Hadoopを使用し、インデックスアクセスの場合はHBase + Hadoopを使用します。
3. Hiveクエリは、MapReduceジョブが5分から数時間続く可能性があることを意味します。HBaseは非常に効率的であり、Hiveよりもはるかに効率的です。
4. Hive自体はデータを保存および計算せず、Hiveのテーブルの純粋なロジックであるHDFSとMapReduceに完全に依存しています。
5. HiveはHadoopからMapReduceを借用して、Hive内のいくつかのコマンドの実行を完了します。
6. Hbaseは物理テーブルであり、論理テーブルではありません。大容量のメモリハッシュテーブルを提供します。このハッシュテーブルは、検索エンジンがインデックスを格納してクエリ操作を容易にするために使用します。
7. Hbaseは列ストレージです。
8. hdfsは基盤となるストレージであり、hdfsはファイルストレージシステムであり、Hbaseはファイルの整理を担当します。
9. Hiveは、hdfsを使用してファイルとMapReduceコンピューティングフレームワークを保存する必要があります。

5.hbaseリアルタイムクエリの原理を説明します

リアルタイムクエリはメモリからのクエリと見なすことができ、応答時間は通常1秒以内です。HBaseのメカニズムは、データが最初にメモリに書き込まれることです。データの量が特定の量（128Mなど）に達すると、ディスクに書き込まれます。メモリでは、データは更新またはマージされず、データが追加されます。ユーザーの書き込み操作は、メモリに入る限りすぐに返すことができるため、HBase I / Oの高性能が保証されます。

6.HbaseのrowKeyの設計原則を説明する

リージョンと行キーの関係の説明に連絡してください。デザインは次の3つの原則を参照できます。

     1.行キーの長さの原則
行キーはバイナリコードストリームであり、最大長は64kbで、任意の文字列にすることができます。実際のアプリケーションでは、通常10〜100バイトです。byte[]の形式で格納され、通常は固定長として設計されています。できるだけ短く、16バイトを超えないようにすることをお勧めします。理由は次のとおりです。

データ永続ファイルHFileはKeyValueに従って保存されます。行キーが長すぎると、HFileのストレージ効率に大きく影響します。MemStoreはデータの一部をメモリにキャッシュします。行キーフィールドが長すぎる場合、有効な使用率メモリの量が減り、システムはそれ以上のデータをキャッシュできなくなり、検索効率が低下します

     2.行キーハッシュの原理
行キーがタイムスタンプに従ってインクリメントされる場合、バイナリコードの前に時間を置かないでください。行キーの上位ビットをハッシュフィールドとして使用することをお勧めします。これは、によってランダムに生成されます。プログラムであり、下位ビットは時間フィールドです。これにより、各RegionServerに分散されたデータバランスが改善され、負荷分散の確率が達成されます。ハッシュフィールドがない場合、最初のフィールドは直接時間情報であり、すべてのデータが1つのRegionServerに集中します。このように、負荷はデータ取得中に個々のRegionServerに集中し、ホットな問題を引き起こし、クエリの効率を低下させます。

     3.行キーの一意の原則は
、その一意性を確保するように設計する必要があります。行キーは辞書式順序で並べ替えられて保存されます。したがって、行キーを設計するときは、この並べ替えの特性を最大限に活用し、頻繁に読み取られるデータを一緒に保存します。アクセスできるようにまとめられています。

7.Hbaseでスキャンして取得する機能と類似点および相違点を説明します

1. 指定されたRowKeyに従って唯一のレコードを取得します。getメソッド（org.apache.hadoop.hbase.client.Get）Getメソッドは2つのタイプに分けられます。SetClosestRowBeforeと未設定のrowlockは、主に行、つまり各getは行でマークされます。行には多くのファミリーと列が存在する可能性があります。
2. 指定された条件に従ってレコードのバッチを取得します。スキャンメソッド（org.apache.Hadoop.hbase.client.Scan）は、条件付きクエリ関数を実現し、スキャンメソッドを使用します。

1. scan 可以通过 setCaching 与 setBatch 方法提高速度(以空间换时间)；
2. scan 可以通过 setStartRow 与 setEndRow 来限定范围([start，end]start? 是闭区间，end 是开区间)。范围越小，性能越高；
3. scan 可以通过 setFilter 方法添加过滤器，这也是分页、多条件查询的基础。 3.全表扫描，即直接扫描整张表中所有行记录。

8.Hbaseのセルの構造を詳しく説明してください

HBaseの行と列によって決定されるストレージユニットはセルと呼ばれます。セル：{行キー、列（= +）、バージョン}が唯一のセルです。セル内のデータには型がなく、バイトコードで格納されます。

9. HBASEでのコンパクトの目的は何ですか、いつトリガーされるか、どの2つが分割されるか、違いは何ですか、関連する構成パラメーターは何ですか？

hbaseでは、memstoreデータがディスクにフラッシュされるたびに、storefileが形成されます。storeFilesの数が特定のレベルに達すると、storefileファイルを圧縮する必要があります。コンパクトの役割：

1. ファイルをマージする
2. 古い冗長なバージョンデータをクリアする
3. データの読み取りと書き込みの効率を向上させる

10. HBaseには2つの圧縮方法が実装されています。マイナーとメジャーの2つの圧縮方法の違いは、次のとおりです。

1. マイナー操作は、一部のファイルをマージし、minVersion = 0を含む期限切れバージョンをクリーンアップしてTTLを設定するためにのみ使用され、削除されたデータとマルチバージョンデータのクリーンアップは行いません。
2. 主な操作は、リージョンの下のHStoreの下にあるすべてのStoreFileに対してマージ操作を実行することであり、最終的な結果は、ファイルをソートしてマージすることです。

11.Hbaseフィルターの実装原理を簡単に説明してください。実際のプロジェクトの経験と組み合わせて、フィルターを使用するいくつかのシナリオを作成します。

HBaseは、データをフィルタリングするための一連のフィルターを提供します。このフィルターを使用すると、HBase内のデータの複数の次元（行、列、データバージョン）でデータをフィルター処理できます。つまり、フィルターで最終的にフィルター処理できます。データを特定のデータに絞り込むことができます。ストレージセル（行キー、列名、およびタイムスタンプによって配置されます）。

RowFilter、PrefixFilter。hbaseのフィルターはスキャンによって設定されるため、スキャンのクエリ結果に基づいてフィルター処理されます。フィルターにはさまざまな種類がありますが、比較フィルターと特殊フィルターの2つのカテゴリに分類できます。フィルタの機能は、データがサーバー側の条件を満たしているかどうかを判断し、条件を満たしているデータのみをクライアントに返すことです。たとえば、注文を作成するときは、rowkeyfilterを使用して次のすべての注文を除外します。特定のユーザー。

12. Hbaseの内部メカニズムは何ですか？

HBaseで新しい行を追加する場合でも、既存の行を変更する場合でも、内部プロセスは同じです。HBaseは、コマンドの受信後に変更情報を保存するか、書き込みが失敗して例外がスローされます。デフォルトでは、書き込みが実行されるときに、先行書き込みログ（HLogとも呼ばれます）とMemStoreの2つの場所が書き込まれます。HBaseのデフォルトの方法は、データの永続性を確保するために、これら2つの場所で書き込みアクションを記録することです。これらの2つの場所の変更情報が書き込まれ、確認された場合にのみ、書き込みアクションは完了したと見なされます。

MemStoreはメモリ内の書き込みバッファであり、HBaseのデータは、ハードディスクに永続的に書き込まれる前に蓄積されます。MemStoreがいっぱいになると、その中のデータがハードディスクにフラッシュされ、HFileが生成されます。HFileは、HBaseで使用される基盤となるストレージ形式です。HFileは列ファミリーに対応します。列ファミリーは複数のHFileを持つことができますが、1つのHFileは複数の列ファミリーからのデータを格納できません。クラスターの各ノードには、列ファミリーごとに1つのMemStoreがあります。ハードウェア障害は大規模な分散システムで一般的であり、HBaseも例外ではありません。

MemStoreがフラッシュされていない場合、サーバーがクラッシュし、ハードディスクに書き込まれていないメモリ内のデータが失われることを想像してみてください。HBaseのソリューションは、書き込みアクションが完了する前にWALに書き込むことです。HBaseクラスター内の各サーバーは、変更を記録するためにWALを維持します。WALは、基盤となるファイルシステム上のファイルです。新しいWALレコードが正常に書き込まれるまで、書き込みアクションは正常に完了したとは見なされません。これにより、HBaseとそれをサポートするファイルシステムが耐久性を確実に満たすことができます。

ほとんどの場合、HBaseは基盤となるファイルシステムとしてHadoop分散ファイルシステム（HDFS）を使用します。HBaseサーバーがダウンした場合、MemStoreからHFileにフラッシュされていないデータは、WALを再生することで復元できます。手動で行う必要はありません。Hbaseの内部メカニズムには、対処するための回復プロセスの部分があります。各HBaseサーバーにはWALがあり、このサーバー上のすべてのテーブル（およびその列ファミリー）はこのWALを共有します。書き込み時にWALをスキップすると、書き込みパフォーマンスが向上すると思われるかもしれません。ただし、問題が発生した場合にデータを失う意思がない限り、WALを無効にすることはお勧めしません。テストする場合は、次のコードでWALを無効にすることができます。注：WALを記述しないと、RegionServerに障害が発生したときにデータが失われるリスクが高まります。WALをオフにすると、障害が発生した場合にHBaseがデータを回復できない可能性があり、ハードディスクにフラッシュされていない書き込みデータはすべて失われます。

13. HBaseのダウンタイムに対処するにはどうすればよいですか？

ダウンタイムは、HMasterのダウンタイムとHRegisonerのダウンタイムに分けられます。

HRegisonerがダウンした場合、HMasterは管理するリージョンを他のアクティブなRegionServerに再配布します。データとログはHDFSに保持されるため、この操作によってデータが失われることはなく、データの一貫性とセキュリティが保証されます。

HMasterがダウンしている場合、HMasterには単一の問題点はありません。HBaseで複数のHMasterを起動でき、Zookeeperのマスター選挙メカニズムを介して実行されているマスターは常に1つです。つまり、ZooKeeperは、外部サービスを提供するHMasterが常に存在することを保証します。

14. HRegionServerのダウンタイムに対処するにはどうすればよいですか？

1. ZooKeeperは、HRegionServerのオンラインとオフラインのステータスを監視します。ZKは、HRegionServerがダウンしていることを検出すると、フェイルオーバーを実行するようにHMasterに通知します。
2. HRegionServerは、外部サービス、つまり外部サービスを一時的に停止する責任がある地域の提供を停止します
3. HMasterは、HRegionServerが担当するリージョンを他のHRegionServerに転送し、ディスクに永続化されていないHRegionServerのmemstoreに保存されているデータを復元します。
4. この復元はWALの再生によって行われます。プロセスは次のとおりです。

1. wal实际上就是一个文件，存在/hbase/WAL/对应RegionServer路径下
2. 宕机发生时，读取该RegionServer所对应的路径下的wal文件，然后根据不同的region切分成不同的临时文件recover.edits
3. 当region被分配到新的RegionServer中，RegionServer读取region时会进行是否存在recover.edits，如果有则进行恢复

15 hbase書き込みデータと読み取りデータのプロセス
により、リージョンの保存場所情報を取得します

データの書き込みと読み取りは、通常、hbase領域の位置情報を取得します。おおよその手順は次のとおりです。

1. .ROOT。テーブルの場所情報をzookeeperから取得し、zookeeperの保存場所は/ hbase / root-region-serverです。
2. .ROOT。テーブルの情報に従って、.META。テーブルのロケーション情報を取得します。
3. META。テーブルに保存されるデータは、各リージョンの保存場所です。

hbaseテーブルにデータを挿入します

hbaseのキャッシュは、MemstoreとBlockCacheの2つのレイヤーに分かれています。

1. 最初にWALファイルに書き込みます。目的は、データを失わないことです。
2. 次に、データをMemstoreキャ​​ッシュに挿入します。Memstoreが設定されたサイズのしきい値に達すると、フラッシュプロセスが実行されます。
3. フラッシュプロセス中に、各領域の保存場所を取得する必要があります。

hbaseからデータを読み取る

BlockCacheは、主に読み取り用に提供されています。読み取り要求は、最初にMemtoreのデータをチェックし、次にデータが見つからない場合はBlockCacheでチェックし、見つからない場合はディスクで読み取り、読み取り結果をBlockCacheに入れます。

BlockCacheで使用されるアルゴリズムはLRU（最近使用されていないアルゴリズム）であるため、BlockCacheが上限に達すると、削除メカニズムがアクティブになり、最も古いデータのバッチが削除されます。

RegionServerにはBlockCacheとN個のMemstoreがあり、それらのサイズの合計がheapsize * 0.8以上になることはできません。それ以外の場合、hbaseを開始できません。デフォルトのBlockCacheは0.2で、Memstoreは0.4です。読み取り応答時間に注意を払うシステムの場合、BlockCache = 0.4、Memstore = 0.39のように、BlockCacheを大きく設定する必要があります。これにより、キャッシュヒット率が増加します。

15.HBase最適化手法

最適化手法には、主に次の4つの側面があります。

1.調整を減らします

調整の削減をどのように理解しますか？HBaseには、リージョン（パーティション）、HFileなど、動的に調整されるコンテンツがいくつかあるため、I / Oオーバーヘッドをもたらすこれらの調整を減らすためにいくつかのメソッドが使用されます。

リージョンに
事前に構築されたパーティションがない場合、リージョン内のリージョンの数が増えると、リージョンが分割され、I / Oオーバーヘッドが増加するため、解決策は、に応じてパーティションを事前に構築することです。リージョンSplitのダイナミクスを減らすためのRowKeyデザイン。

HFile
HFileは、基になるデータストレージファイルです。各memstoreが更新されると、HFileが生成されます。HFileがある程度増加すると、リージョンに属するHFileがマージされます。この手順により、オーバーヘッドが発生しますが、避けられませんが、マージされます。 HFileのサイズが設定値より大きくなると、HFileは再び分割されます。このような不要なI / Oオーバーヘッドを削減するために、プロジェクトデータのサイズを見積もり、HFileに適切な値を設定することをお勧めします。

2.開始と停止を減らします

データベーストランザクションメカニズムは、バッチ書き込みをより適切に実装し、データベースの開閉によって発生するオーバーヘッドを削減することです。そのため、HBaseで頻繁に開閉することによって発生する問題もあります。

     1.圧縮を閉じ、アイドル状態のときに手動圧縮を実行します

HBaseにはマイナーコンパクションとメジャーコンパクションがあるため、つまりHFileがマージされます。いわゆるマージはI / Oの読み取りと書き込みです。多数のHFileは、間違いなくI / Oオーバーヘッド、さらにはI / Oストームをもたらします。そのため、これを回避するために制御不能な事故が発生します。自動圧縮をオフにして、アイドル時間に圧縮を実行することをお勧めします。

     2.バッチデータを書き込むときにBulkLoadを使用します

HBase-ShellまたはJavaAPIのputを介して大量のデータを書き込む場合、パフォーマンスの低下は確実であり、予期しない問題が発生する可能性もあります。したがって、大量のオフラインデータを書き込む場合はBulkLoadを使用することをお勧めします。

3.データ量を減らします

ビッグデータを開発していますが、なんらかの方法でデータの正確性を確保しながらデータ量を減らすことができたら、やってみませんか？

     1.クエリ速度を向上させるためにフィルタリングをオンにします
。BloomFilterをオンにします。BloomFilterは列ファミリーレベルのフィルターです。StoreFileが生成されると、クエリ中にデータをフィルター処理するために同時にMetaBlockが生成されます。

     2.圧縮を使用する：SnappyおよびLZO圧縮が一般的に推奨されます

4.リーズナブルなデザイン

HBaseテーブルのRowKeyとColumnFamilyの設計は非常に重要です。優れた設計により、パフォーマンスが向上し、データの精度が保証されます。

1. RowKeyデザイン：次の属性が必要です

• ハッシュ可能性：ハッシュ可能性により、同じおよび類似の行キーが集約され、異なる行キーが分散されることが保証されます。これにより、クエリが容易になります。
• 短さ：行キーはキーの一部としてHFileに保存されます。rowKeyが読みやすさのために長すぎるように設計されている場合、保存圧力が高くなります。
• 一意性：rowKeyには明確な区別が必要です
• ビジネス：いくつかの例を挙げてください

クエリ条件が列条件ではなくそれ以上の場合、rowKeyの設計は複数条件クエリをサポート
する必要があります。クエリで最初に最後に挿入されたデータが必要な場合は、rowKeyをLong.Max-timestamp Wayと呼ぶことができるため、次のようになります。 rowKeyは降順で配置されます
     2。列ファミリーの設計

      カラムファミリーの設計は、アプリケーションシナリオによって異なります

      マルチカラムデザインの長所と短所

利点：
HBaseのデータは列に格納されるため、特定の列ファミリーの列をクエリするときに、ディスク全体をスキャンする必要はありません。特定の列ファミリーをスキャンするだけで、読み取りI / Oが削減されます。 ;
実際、複数列のファミリ設計は読み取りI / Oを削減します。これはあまり明白ではなく、読み取りを増やして書き込みを減らすシナリオに適しています。

短所：
書き込みI / Oパフォーマンスの低下。その理由は次のとおりです。データがストアに書き込まれた後、最初にmemstoreにキャッシュされます。同じリージョンに複数の列ファミリーがある場合、複数のストアがあります。各ストアにはmemstoreがあります。memstoreがフラッシュされると、同じリージョンの
ストアに属しています。のmemstoreがフラッシュされるため、I / Oオーバーヘッドが増加します。

16.HBaseであまりにも多くの列ファミリーを使用することが推奨されないのはなぜですか

Hbaseテーブルでは、各列ファミリーはリージョン内のストアに対応します。リージョンのサイズがしきい値に達すると、分割されます。したがって、テーブルに複数の列ファミリーがある場合、次の現象が発生する可能性があります。

1. リージョン内に複数のストアがあります。たとえば、CF1が100万、CF2が10,000のように、各CFのデータ量が不均一に分散している場合、リージョンを分割すると、各リージョンのCF2のデータ量が少なすぎます。CF2をクエリしてください。複数のリージョンにまたがる場合があり、その結果、効率が低下します。
2. たとえば、CF1が500,000、CF2が500,000、CF3が500,000のように、各CFのデータが均等に分散されている場合、リージョンが分割されると、リージョン内の各CFのデータ量は少なくなり、CFのクエリは少なくなります。スパンが発生します複数の領域の確率が増加します。
3. 複数のCFは複数のストアを表します。つまり、複数のMemStore（2MB）が存在するため、メモリ消費量が増加し、使用効率が低下します。
4. リージョン内のキャッシュの更新と圧縮は基本的な操作です。つまり、CFにキャッシュの更新または圧縮操作がある場合、他のCFも同時に同じ操作を実行します。列ファミリーが多すぎると、頻繁に発生します。 IOの問題。

参照：

1. https://www.boxuegu.com/news/470.html
2. https://www.boxuegu.com/news/480.html
3. https://www.boxuegu.com/news/481.html
4. https://blog.csdn.net/u013384984/article/details/80808353
5. https://www.jianshu.com/p/e405ed781cab
6. https://www.cnblogs.com/parent-absent-son/p/10895365.html