最近、LA Hadoopユーザーグループで、ApacheHBaseの推奨事項と禁止事項について講演しました。聴衆は素晴らしく、非常に情報に基づいた明確な質問がありました。 ShopzillaのJodyは素晴らしいホストでした。私は、60人以上のLAHadoopersと話す機会を与えてくれた彼に大きな感謝を捧げます。誰もがLAに住んでいるわけではなく、交流会に参加できるわけでもないので、ここでいくつかの重要なポイントを要約しました。忙しい一日を過ごしている方のために、こちらがtl; dr：
- HBaseは優れていますが、RDBMSやHDFSの代替品ではありません
- 適切な構成とは、適切な操作を意味します
- モニターモニターモニターモニターモニター
ClouderaはHBaseの大ファンです。私たちはテクノロジーを愛し、コミュニティを愛し、多くのアプリケーションに最適であることがわかりました。 HBaseの使用の成功は十分に文書化されており、その結果、多くの組織がHBaseが一部のアプリケーションに適しているかどうかを検討しています。私の講演とこのフォローアップブログ投稿の推進力は、HBaseの優れたアプリケーションのいくつかを明確にし、いくつかの貧弱なアプリケーションに対して警告し、HBaseの展開を成功させるための重要なステップを強調することです。
HBaseを使用する場合
HBaseを検討する際の最も重要な考慮事項は、HBaseは多くの問題に対する優れたソリューションですが、特効薬ではないということです。 HBaseは、従来のトランザクションアプリケーションやリレーショナル分析用に最適化されていません。また、大規模なバッチMapReduceを実行する場合、HDFSの完全な代替ではありません。この投稿のいくつかのユースケースを見て、どのアプリケーションがHBaseに適しているかを理解してください。質問がある場合は、先に進んでリストに投稿してください。コミュニティは素晴らしいと言いましたか？
その警告がありますが、なぜHBaseを使用する必要があるのでしょうか。アプリケーションに、各行がわずかに異なる可変スキーマがある場合は、HBaseを確認する必要があります。例として、標準のリレーショナルスキーマを使用してモデリングの演習を行います。十分な速度で列を追加できず、各行でほとんどの列がNULLである場合は、HBaseを検討する必要があります。データがコレクションに保存されていることがわかった場合（たとえば、メタデータ、メッセージデータ、バイナリデータなど、すべて同じ値でキー設定されている場合）、HBaseを検討する必要があります。保存または取得時にデータへのキーベースのアクセスが必要な場合は、HBaseを検討する必要があります。
サポートサービス
HBaseがアプリケーションに適していると確信している場合は、HBaseをデプロイするときに考慮する必要のあるヒントをいくつか紹介します。重要なサポートサービスと必要なサポートサービスがいくつかあります。これまでZooKeeperを見たことがない場合は、今がその時です。 HBaseは、マスター選挙などのさまざまな分散調整サービスにZooKeeperを使用します。 HBaseが開発および成長するにつれて、追加機能をZooKeeperに依存し続け、システムの重要な部分になります。さらに、NTPやDNSなどの適切なネットワークサービスを用意する必要があります。 HBaseは、クロックが厳密に同期され、相互に一貫して参照しているクラスター内のすべてのノードに依存しています。 NTPとDNSを使用すると、1つのノードAが明日であると考え、ノードBが昨日であると考えたときに、奇妙な動作に遭遇することがなくなります。また、マスターノードがノードCにリージョンを提供するように指示したが、ノードCが自分の名前を知らず、応答しない状況を防ぐことができます。 NTPとDNSを使用すると、開始時に多くの頭痛の種を減らすことができます。
HBaseを選択する際の最も重要な考慮事項は、適切なユースケースがあることを確認することです。 HBaseを使用するときに行う最も重要なことは、システムを監視することです。監視は、HBase操作を成功させるための鍵です。多くの分散システムの場合と同様に、HBaseはカスケード障害の影響を受けやすくなっています。 1つのノードがスワッピングを開始すると、マスターとの接続が失われ、別のサーバーが負荷を引き受けて過負荷になる可能性があります。その2番目のサーバーに障害が発生し、障害がカスケードされます。各HBaseノードのメモリ、CPU、I / O、ネットワークレイテンシと帯域幅を監視して、それらが正常なパラメータ内で動作していることを確認する必要があります。監視は、正常なHBaseクラスターを運用するための最も重要なプラクティスです。
HBaseアーキテクチャのグッドプラクティス
完璧なユースケースを実行している、十分に監視されたHBaseクラスターに早送りします。ここに、いくつかの優れたプラクティスがあります。ユースケースに基づいて適切に分散されるキープレフィックスを使用します。キーの前にタイムスタンプまたは同様の値を付けて、ソート時にバッチで保存または照会すると、負荷を均等に分散するのではなく、各リージョンサーバーに順番に過負荷がかかる可能性があります。また、リージョンの数をmemstoreのサイズとRAMの量に基づいて適切な数に維持する必要があります。また、長いGCの一時停止を最小限に抑えるために、RegionServerJVMを12GBのJavaヒープに制限する必要があります。たとえば、DataNodeデーモンも実行している36GBのRAMを備えたマシンは、アクティブな書き込みとそれぞれ48MBのmemstoreを持つ約100のリージョンを処理できます。これにより、DataNodeとRegionServerのメモリ要件、Linuxファイルバッファスペース、および各RegionServerの適切なフラッシュサイズに十分なヘッドルームが確保されます。
いくつかの構成に関する推奨事項には、自動圧縮の無効化が含まれます（デフォルトでは、開始から24時間ごとに行われます。 HBase）を作成し、毎日オフピーク時に実行するようにスケジュールします。また、圧縮（LZOなど）を構成し、正しく構成されたHBaseconfディレクトリをCLASSPATHに明示的に配置する必要があります。
HBaseの禁止事項
HBaseの幅広いグッドプラクティスについて説明しました。避けるべきいくつかの使用パターンもあります。たとえば、すべてのリレーショナルデータベースの大規模な代替としてHBaseを使用することを期待しないでください。 HBaseは多くの点で優れていますが、リレーショナルデータベースに取って代わるものではありません。まず、SQLについては説明せず、オプティマイザーを使用し、クロスレコードトランザクションまたは結合をサポートします。データベースアプリケーションでこれらのいずれも使用しない場合は、HBaseが最適です。
HBaseクラスターで混合ワークロードを実行する場合は注意してください。 MapReduceジョブとは無関係にHBaseアクセスにSLAがある場合（たとえば、Pigでの変換とHBaseからのデータの提供）、それらを別々のクラスターで実行します。 HBaseはCPUとメモリを集中的に使用し、散発的な大規模なシーケンシャルI / Oアクセスを行いますが、MapReduceジョブは主に固定メモリと散発的なCPUにバインドされたI/Oです。これらを組み合わせると、HBaseと2つの間のCPU競合の予測できない遅延が発生する可能性があります。共有クラスターは、HBase CPU要件に対応するためにノードあたりのタスクスロットも少なくて済みます（通常、HBaseなしで割り当てる各ノードのスロットの半分）。また、メモリスワップにも注意してください。 HBaseがスワップを開始すると、ハートビートを見逃してクラスターからドロップされる可能性が高くなります。ビジーなクラスターでは、これにより別のリージョンが過負荷になり、スワップして一連の障害が発生する可能性があります。
最終的な考え
要約する前に、最後にもう1つアドバイスをします。 HBaseをロードするときに、MapReduceジョブまたはバッチプットを使用するサーバーのコレクションを介してロードする場合は、HFileOuputFormatを使用します。単一のクライアントでロードすると、そのクライアントでボトルネックになり、HBaseによって提供されるスケーラビリティを利用できなくなります。
要約すると、キーごとにデータをロードする場合、キー（または範囲）ごとにデータを検索する場合、キーごとにデータを提供する場合、キーごとにデータをクエリする場合、またはスキーマに適合しない行ごとにデータを保存する場合は、HBaseを検討してください。
ユースケース
- Apache HBase：Powered By HBase Wiki
- Mozilla：SocorroをHBaseに移行する
- Facebook：Facebookの新しいリアルタイムメッセージングシステム：HBase
- StumbleUpon：StumbleUponのHBase