翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon S3 の HBase (Amazon S3 ストレージモード)
Amazon EMR バージョン 5.2.0 以降で HBase を実行する場合は、Amazon EMR で HBase を有効にすることで、以下の利点を得られます。
HBase ルートディレクトリが、HBase ストアファイルおよびテーブルメタデータも含めて、Amazon S3 に保存されます。このデータはクラスター外で永続的で、Amazon EC2 アベイラビリティーゾーン間で使用することができ、スナップショットやそのほかの方法を使用して復元する必要はありません。
Amazon S3 に格納したファイルを使用して、HDFS の 3 倍のレプリケーションで、データ要件ではなくコンピューティング要件に合わせて Amazon EMR クラスターのサイズを決定できます。
Amazon EMR バージョン 5.7.0 以降では、リードレプリカクラスターを設定して、データの読み取り専用コピーを Amazon S3 に保持できます。複数の読み取りオペレーションを同時に実行する場合や、プライマリクラスターが使用不能になった場合に、リードレプリカクラスターのデータを利用できます。
Amazon EMR バージョン 6.2.0 以降では、永続的 HFile トラッキングは
hbase:storefile
と呼ばれる HBase システムテーブルを使用し、読み取りオペレーションに使用される HFile パスを直接追跡します。この機能はデフォルトで有効になっており、手動マイグレーションを実行する必要はありません。
次の図は Amazon S3 の HBase に関連する HBase コンポーネントを示しています。

Amazon S3 での HBase の有効化
Amazon EMR コンソール、AWS CLI、または Amazon EMR API を使用して、Amazon S3 で HBase を有効にすることができます。この設定は、クラスター作成時のオプションです。コンソールを使用する場合は、[Advanced options (詳細オプション)] を使用して設定を選択します。AWS CLI を使用する場合は、--configurations
オプションを使用して JSON 設定オブジェクトを提供します。設定オブジェクトのプロパティは Amazon S3 内のストレージモードとルートディレクトリの場所を指定します。Amazon S3 の場所として Amazon EMR クラスターと同じリージョン内の場所を指定する必要があります。一度に 1 つのアクティブなクラスターのみが Amazon S3 の同じ HBase ルートディレクトリを使用できます。コンソールの手順および AWS CLI を使用したクラスター作成の詳細については、「HBase を含むクラスターの作成」を参照してください。設定オブジェクトの例は、次の JSON スニペットに示します。
{ "Classification": "hbase-site", "Properties": { "hbase.rootdir": "
s3://my-bucket/my-hbase-rootdir
"} }, { "Classification": "hbase", "Properties": { "hbase.emr.storageMode":"s3
" } }
注記
Amazon S3 バケットを HBase 用の rootdir
として使用する場合、Amazon S3 URI の末尾にスラッシュを追加する必要があります。例えば、問題を回避するために、"hbase.rootdir: s3://my-bucket"
ではなく、"hbase.rootdir: s3://my-bucket/"
を使用する必要があります。
リードレプリカクラスターの使用
Amazon S3 の HBase を使用してプライマリクラスターを設定すると、プライマリクラスターと同じデータへの読み取り専用アクセスを提供するリードレプリカクラスターを作成して設定できます。これは、クエリデータに同時にアクセスする場合や、プライマリクラスターの使用不能時にアクセスを絶やさない場合に便利です。リードレプリカ機能は Amazon EMR バージョン 5.7.0 以降で使用できます。
プライマリクラスターとリードレプリカクラスターは 1 つの重要な点を除いて設定方法が同じです。どちらも同じ hbase.rootdir
の場所を参照します。ただし、リードレプリカクラスターの hbase
分類には "hbase.emr.readreplica.enabled":"true"
プロパティが含まれます。
たとえば、このトピックで以前に示したプライマリクラスターの JSON 分類の場合、リードレプリカクラスターの設定は次のとおりです。
{ "Classification": "hbase-site", "Properties": { "hbase.rootdir": "
s3://my-bucket/my-hbase-rootdir
"} }, { "Classification": "hbase", "Properties": { "hbase.emr.storageMode":"s3
", "hbase.emr.readreplica.enabled":"true" } }
データの追加に伴うリードレプリカの同期化
リードレプリカは HBase を使用するからです。 StoreFiles また、プライマリクラスターが Amazon S3 に書き込むメタデータも、リードレプリカは Amazon S3 データストアと同じ最新のものに限られます。データを書き込むまでにプライマリクラスターとリードレプリカの間に生じる時間差を最小化するには、以下のガイダンスを参考にしてください。
可能な限り、プライマリクラスターのデータを一括ロードします。詳細については、Apache HBase ドキュメントの「一括ロード
」を参照してください。 ストアファイルを Amazon S3 に書き込むフラッシュは、データの追加後、できるだけ早急に発生する必要があります。時間差が最小になるように手動でフラッシュするか、フラッシュ設定を調整します。
圧縮が自動実行される場合、圧縮がトリガーされるときの不整合を避けるために手動圧縮を実行します。
リードレプリカクラスターで、メタデータの変更 (HBase リージョンの分割、圧縮の発生、テーブルの追加や削除など) があった場合、
refresh_meta
コマンドを実行します。リードレプリカクラスターで、レコードがテーブルに追加されるかテーブル内で変更された場合、
refresh_hfiles
コマンドを実行します。

永続的 HFile トラッキング
永続的 HFile トラッキングでは、hbase:storefile
と呼ばれる HBase システムテーブルを使用し、読み取りオペレーションに使用される HFile パスを直接追跡します。HBase に追加のデータが追加されると、新しい HFile パスがテーブルに追加されます。これにより、重要な書き込みパス HBase オペレーションのコミットメカニズムとして名前変更オペレーションが削除され、ファイルシステムディレクトリの一覧ではなく、hbase:storefile
システムテーブルから読み取ることで HBase リージョンを開くときに復旧時間が改善されます。この機能は Amazon EMR バージョン 6.2.0 以降ではデフォルトで有効になっており、手動での移行手順は必要ありません。
注記
HBase ストアファイルシステムテーブルを使用した永続的な HFile トラッキングは、HBase リージョンのレプリケーション機能をサポートしていません。HBase リージョンレプリケーションの詳細については、「Timeline-consistent high available reads
永続的 HFile トラッキングの無効化
永続的 HFile トラッキングは、EMR リリース 6.2.0 以降でデフォルトで有効になっています。永続的 HFile トラッキングを無効にするには、クラスターの起動時に次の設定オーバーライドを指定します。
{ "Classification": "hbase-site", "Properties": { "hbase.storefile.tracking.persist.enabled":"false", "hbase.hstore.engine.class":"org.apache.hadoop.hbase.regionserver.DefaultStoreEngine" } }
注記
Amazon EMR クラスターを再設定するときは、すべてのインスタンスグループを更新する必要があります。
ストアファイルテーブルの手動同期
新しい HFiles が作成されると、ストアファイルテーブルは最新の状態に保たれます。ただし、何らかの理由でストアファイルテーブルがデータファイルと同期しなくなった場合は、次のコマンドを使用して手動でデータを同期できます。
オンラインリージョンでストアファイルテーブルを同期する:
hbase org.apache.hadoop.hbase.client.example.RefreshHFilesClient <table>
オフラインリージョンでストアファイルテーブルを同期する:
ストアファイルテーブル znode を削除します。
echo "ls /hbase/storefile/loaded" | sudo -u hbase hbase zkcli [<tableName>, hbase:namespace] # The TableName exists in the list echo "delete /hbase/storefile/loaded/<tableName>" | sudo -u hbase hbase zkcli # Delete the Table ZNode echo "ls /hbase/storefile/loaded" | sudo -u hbase hbase zkcli [hbase:namespace]
リージョンを割り当てます ('hbase shell' で実行します)。
hbase cli> assign '<region name>'
割り当てが失敗した場合。
hbase cli> disable '<table name>' hbase cli> enable '<table name>'
ストアファイルテーブルのスケーリング
ストアファイルテーブルは、デフォルトでは 4 つのリージョンに分割されます。ストアファイルテーブルの書き込み負荷が大きい場合は、テーブルを手動で分割できます。
特定のホットリージョンを分割するには、次のコマンドを使用します ('hbase shell' で実行します)。
hbase cli> split '<region name>'
テーブルを分割するには、次のコマンドを使用します ('hbase shell' で実行します)。
hbase cli> split 'hbase:storefile'
運用上の考慮事項
HBase リージョンサーバーは BlockCache データ読み取りをメモリに保存し、 BucketCache 読み取ったデータをローカルディスクに保存します。さらに、リージョンサーバーは MemStore データ書き込みをメモリ内に保存し、先行書き込みログを使用して、データが HBase に書き込まれる前に HDFS にデータ書き込みを保存します。 StoreFiles Amazon S3 にあります。クラスターの読み込みパフォーマンスは、レコードがどのくらいの頻度でインメモリキャッシュまたはオンディスクキャッシュから取得できるかに関連しています。キャッシュミスがあると、レコードはから読み取られます。 StoreFile Amazon S3 では、HDFS からの読み取りよりもレイテンシーと標準偏差が大幅に高くなります。さらに、Amazon S3 の最大要求率は、ローカルキャッシュから受理できるものよりも低くなるため、データのキャッシュは読み取り過多のワークロードにとって重要である場合があります。Amazon S3 のパフォーマンスの詳細については、「Amazon Simple Storage Service ユーザーガイド」の「パフォーマンスの最適化」を参照してください。
パフォーマンスを向上させるには、EC2 インスタンスストレージに可能な限りデータセットをキャッシュすることをお勧めします。なぜなら BucketCache リージョンサーバーの EC2 インスタンスストレージを使用するため、十分なインスタンスストアがある EC2 インスタンスタイプを選択し、必要なキャッシュサイズに対応する Amazon EBS ストレージを追加できます。容量を増やすこともできます。BucketCache アタッチされたインスタンスストアと EBS ボリュームのサイズは、hbase.bucketcache.size
プロパティ。デフォルトの設定は 8,192 MB です。
書き込みの頻度は MemStore フラッシュ回数と回数 StoreFiles マイナーおよびメジャーコンパクション中に存在すると、リージョンサーバーの応答時間が大幅に増加する可能性があります。最適なパフォーマンスを得るには、サーバーのサイズを大きくすることを検討してください。MemStore フラッシュと HRegion のブロック乗数により、主要な圧縮の間隔は長くなりますが、リードレプリカを使用する場合は整合性の遅れも大きくなります。場合によっては、ファイルブロックサイズを増やして (ただし 5 GB 未満)、EMRFS で Amazon S3 マルチパートアップロード機能をトリガーすることで、パフォーマンスを向上できる場合があります。Amazon EMR のブロックサイズのデフォルトは 128 MB です。詳細については、「HDFS 構成」を参照してください。フラッシュと圧縮に関するパフォーマンスのベンチマークで 1 GB のブロックサイズを超えているお客様はほとんどいません。さらに、HBase のコンパクションとリージョンサーバーは、数が少ない場合に最適なパフォーマンスを発揮します。 StoreFiles 圧縮する必要がある。
大きなディレクトリの名前を変更する必要があるため、Amazon S3 でのテーブルの削除に長い時間がかかる場合があります。テーブルを削除する代わりに無効化することを検討してください。
古い WAL ファイルとストアファイルをクリーンアップする HBase クリーナープロセスがあります。Amazon EMR リリースバージョン 5.17.0 以降では、クリーナーがグローバルに有効になっており、次の設定プロパティをクリーナーの動作の制御に使用できます。
設定プロパティ | デフォルト値 | Description |
---|---|---|
|
1 |
期限が切れた大規模な HFiles をクリーンアップするために割り当てられたスレッドの数。 |
|
1 |
期限が切れた小規模な HFiles をクリーンアップするために割り当てられたスレッドの数。 |
|
すべての使用可能なコアの 4 分の 1 に設定します。 |
oldWALs ディレクトリをスキャンするスレッドの数。 |
|
2 |
oldWALs ディレクトリの WALs をクリーンアップするスレッドの数。 |
Amazon EMR 5.17.0 以前では、高負荷のワークロードを実行しているときにクリーナーオペレーションがクエリパフォーマンスに影響する可能性があるため、ピークを過ぎた時間帯だけクリーナーを有効にすることをお勧めします。クリーナーには、次の HBase シェルコマンドがあります。
cleaner_chore_enabled
クリーナーが有効かどうかのクエリ。cleaner_chore_run
手動でクリーナーを実行してファイルを削除します。cleaner_chore_switch
クリーナーを有効、または無効にし、クリーナーの以前の状態に返します。たとえば、cleaner_chore_switch true
はクリーナーを有効にします。
Amazon S3 の HBase のパフォーマンスをチューニングするプロパティ
Amazon S3 の HBase を使用するときに、以下のパラメータを調整してワークロードのパフォーマンスをチューニングできます。
設定プロパティ | デフォルト値 | 説明 |
---|---|---|
|
8,192 |
リージョンサーバーの Amazon EC2 インスタンスストアと EBS ボリュームに予約されているディスク容量 (MB 単位) BucketCache ストレージ。設定は、すべてのリージョンサーバーインスタンスに適用されます。大きい BucketCache 通常、サイズはパフォーマンスの向上に対応します。 |
|
134217728 |
Amazon S3 への Memstore フラッシュがトリガーされるデータ上限 (バイト単位)。 |
|
4 |
を決定する乗数 MemStore 更新をブロックする上限。もし、 MemStore 超える |
|
10 |
の最大数 StoreFiles 更新がブロックされる前にストアに存在できる数です。 |
|
10737418240 |
リージョンが分割されるまでのリージョンの最大サイズ。 |
データ損失のないクラスターのシャットダウンと復元
Amazon S3 に書き込まれていないデータを失わずに Amazon EMR クラスターをシャットダウンするには、クラスターをフラッシュする必要があります。 MemStore Amazon S3 にキャッシュして新しいストアファイルを書き込む。まず、すべてのテーブルを無効にする必要があります。次の設定ステップはクラスターにステップを追加する際に使用することができます。詳細については「Amazon EMR 管理ガイド」の「AWS CLI およびコンソールを使用した手順の作業」を参照してください。
Name="Disable all tables",Jar="command-runner.jar",Args=["/bin/bash","/usr/lib/hbase/bin/disable_all_tables.sh"]
または、次の Bash コマンドを直接実行できます。
bash /usr/lib/hbase/bin/disable_all_tables.sh
すべてのテーブルを無効にした後に、HBase シェルと次のコマンドを使用して hbase:meta
テーブルをフラッシュします。
flush 'hbase:meta'
その後、Amazon EMR クラスターに用意されているシェルスクリプトを実行してデータをフラッシュできます。MemStore キャッシュ。これをステップとして追加するか、またはクラスター上の AWS CLI を使用して直接実行できます。このスクリプトによってすべての HBase テーブルが無効になり、その結果、 MemStore各リージョンのサーバーが Amazon S3 にフラッシュされます。スクリプトが正常に完了すると、データは Amazon S3 に維持され、クラスターを終了できます。
同じ HBase データを使ってクラスターを再開するには、AWS Management Console の以前のクラスターとして同じ Amazon S3 の場所を指定するか、hbase.rootdir
設定プロパティを使用します。