HBase Amazon S3 の (Amazon S3 ストレージモード） - Amazon EMR
Amazon S3 HBaseでの有効化リードレプリカクラスターの使用永続的HFile追跡運用上の考慮事項

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

HBase Amazon S3 の (Amazon S3 ストレージモード）

Amazon EMRバージョン 5.2.0 以降HBaseで を実行すると、Amazon S3 HBaseで を有効にできます。これには、次の利点があります。

  • HBase ルートディレクトリは、ストアファイルやテーブルメタデータなど、Amazon S3 HBase に保存されます。このデータはクラスターの外部で永続化され、Amazon EC2 アベイラビリティーゾーン間で利用でき、スナップショットやその他の方法を使用して復旧する必要はありません。

  • Amazon S3 にファイルを保存すると、 で 3 倍のレプリケーションを使用して、データ要件ではなくコンピューティング要件に合わせて Amazon EMRクラスターのサイズを設定できますHDFS。

  • Amazon EMRバージョン 5.7.0 以降を使用すると、リードレプリカクラスターを設定できます。これにより、Amazon S3 でデータの読み取り専用コピーを維持できます。複数の読み取りオペレーションを同時に実行する場合や、プライマリクラスターが使用不能になった場合に、リードレプリカクラスターのデータを利用できます。

  • Amazon EMRバージョン 6.2.0 以降では、永続HFile追跡は というHBaseシステムテーブルhbase:storefileを使用して、読み取りオペレーションに使用されるHFileパスを直接追跡します。この機能はデフォルトで有効になっており、手動マイグレーションを実行する必要はありません。

次の図は、Amazon S3 HBaseの に関連するHBaseコンポーネントを示しています。 Amazon S3

HBase Amazon S3 アーキテクチャの 。

Amazon S3 HBaseでの有効化

Amazon S3 HBaseで EMR を有効にできますAPI。 EMR AWS CLIこの設定は、クラスター作成時のオプションです。コンソールを使用する場合は、[Advanced options (詳細オプション)] を使用して設定を選択します。を使用する場合は AWS CLI、 --configurations オプションを使用してJSON設定オブジェクトを指定します。設定オブジェクトのプロパティは Amazon S3 内のストレージモードとルートディレクトリの場所を指定します。指定する Amazon S3 の場所は、Amazon EMRクラスターと同じリージョンにある必要があります。Amazon S3 で同じHBaseルートディレクトリを使用できるのは、一度に 1 つのアクティブなクラスターのみです。 Amazon S3 コンソールの手順と、 を使用した詳細な create-cluster の例については 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 rootdir バケットを使用する場合はHBase、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"
  }
}

データの追加に伴うリードレプリカの同期化

リードレプリカは、プライマリクラスターが Amazon S3 に書き込む HBase StoreFiles および メタデータを使用するため、リードレプリカは Amazon S3 データストアと同じくらい最新です。 Amazon S3 データを書き込むまでにプライマリクラスターとリードレプリカの間に生じる時間差を最小化するには、以下のガイダンスを参考にしてください。

  • 可能な限り、プライマリクラスターのデータを一括ロードします。詳細については、Apache HBaseドキュメントの「一括ロード」を参照してください。

  • ストアファイルを Amazon S3 に書き込むフラッシュは、データの追加後、できるだけ早急に発生する必要があります。時間差が最小になるように手動でフラッシュするか、フラッシュ設定を調整します。

  • 圧縮が自動実行される場合、圧縮がトリガーされるときの不整合を避けるために手動圧縮を実行します。

  • リードレプリカクラスターで、HBaseリージョン分割や圧縮が発生したとき、テーブルが追加または削除されたときなど、メタデータが変更された場合、 refresh_meta コマンドを実行します。

  • リードレプリカクラスターで、レコードがテーブルに追加されるかテーブル内で変更された場合、refresh_hfiles コマンドを実行します。

HBase リードレプリカとのデータの同期

永続的HFile追跡

永続HFile追跡は、 というHBaseシステムテーブルhbase:storefileを使用して、読み取りオペレーションに使用されるHFileパスを直接追跡します。にデータが追加されると、新しいHFileパスがテーブルに追加されますHBase。これにより、重要な書き込みパスオペレーションのコミットメカニズムとして名前変更HBaseオペレーションが削除され、ファイルシステムディレクトリのリストではなくhbase:storefileシステムテーブルから読み取ることで、HBaseリージョンを開く際の復旧時間が短縮されます。この機能は、Amazon EMRバージョン 6.2.0 以降ではデフォルトで有効になっており、手動による移行手順は必要ありません。

注記

HBase storefile システムテーブルを使用した永続HFile追跡は、HBaseリージョンレプリケーション機能をサポートしていません。HBase リージョンレプリケーションの詳細については、「Timeline-consistent high available reads」を参照してください。

永続HFile追跡の無効化

Amazon EMRリリース 6.2.0 以降、永続的HFile追跡はデフォルトで有効になっています。永続HFile追跡を無効にするには、クラスターの起動時に次の設定オーバーライドを指定します。

{
  "Classification": "hbase-site",
  "Properties": {
    "hbase.storefile.tracking.persist.enabled":"false",
    "hbase.hstore.engine.class":"org.apache.hadoop.hbase.regionserver.DefaultStoreEngine"
  }
}
注記

Amazon EMRクラスターを再設定するときは、すべてのインスタンスグループを更新する必要があります。

ストアファイルテーブルの手動同期

storefile テーブルは、新しい が作成されると最新の状態が維持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 を使用してデータをメモリ内に書き込み、先行書き込みログを使用してデータを Amazon S3 に書き込むHDFS前に HBase StoreFiles に書き込みを保存します。クラスターの読み込みパフォーマンスは、レコードがどのくらいの頻度でインメモリキャッシュまたはオンディスクキャッシュから取得できるかに関連しています。キャッシュミスにより、レコードは Amazon S3 StoreFile の から読み取られます。これにより、 から読み取るよりもレイテンシーが大きくなり、標準偏差も高くなりますHDFS。 Amazon S3 さらに、Amazon S3 の最大要求率は、ローカルキャッシュから受理できるものよりも低くなるため、データのキャッシュは読み取り過多のワークロードにとって重要である場合があります。Amazon S3 のパフォーマンスの詳細については、「Amazon Simple Storage Service ユーザーガイド」の「パフォーマンスの最適化」を参照してください。

パフォーマンスを向上させるには、データセットをできるだけ多くEC2インスタンスストレージにキャッシュすることをお勧めします。はリージョンサーバーのEC2インスタンスストレージ BucketCache を使用するため、十分なEC2インスタンスストアを持つインスタンスタイプを選択し、必要なキャッシュサイズに合わせて Amazon EBSストレージを追加できます。hbase.bucketcache.size プロパティを使用して、アタッチされたインスタンスストアとEBSボリュームBucketCache のサイズを増やすこともできます。デフォルトの設定は 8,192 MB です。

書き込みの場合、 MemStore フラッシュの頻度と、マイナー圧縮とメジャー圧縮中 StoreFiles に存在する の数は、リージョンサーバーの応答時間の増加に大きく影響する可能性があります。最適なパフォーマンスを得るには、MemStore フラッシュ乗数とHRegionブロック乗数のサイズを増やすことを検討してください。これにより、メジャー圧縮間の経過時間が長くなりますが、リードレプリカを使用すると整合性のある遅延も長くなります。場合によっては、より大きなファイルブロックサイズ (5 GB 未満) を使用して、 で Amazon S3 マルチパートアップロード機能をトリガーすることで、パフォーマンスを向上させることができますEMRFS。Amazon EMRのブロックサイズのデフォルトは 128 MB です。詳細については、「HDFS 設定」を参照してください。フラッシュと圧縮に関するパフォーマンスのベンチマークで 1 GB のブロックサイズを超えているお客様はほとんどいません。さらに、HBase圧縮とリージョンサーバーは、圧縮 StoreFiles する必要性が少ない場合に最適に動作します。

大きなディレクトリの名前を変更する必要があるため、Amazon S3 でのテーブルの削除に長い時間がかかる場合があります。テーブルを削除する代わりに無効化することを検討してください。

古いWALファイルをクリーンアップしてファイルを保存するよりHBaseクリーンなプロセスがあります。Amazon EMRリリースバージョン 5.17.0 以降では、クリーナはグローバルに有効になっており、次の設定プロパティを使用してクリーナの動作を制御できます。

設定プロパティ デフォルト値 説明

hbase.regionserver.hfilecleaner.large.thread.count

1

期限切れの大きな をクリーンアップするために割り当てられたスレッドの数HFiles。

hbase.regionserver.hfilecleaner.small.thread.count

1

期限切れの小さな をクリーンアップするために割り当てられたスレッドの数HFiles。

hbase.cleaner.scan.dir.concurrent.size

すべての使用可能なコアの 4 分の 1 に設定します。

oldWALs ディレクトリをスキャンするスレッドの数。

hbase.oldwals.cleaner.thread.size

2

oldWALs ディレクトリのWALs下にある をクリーンアップするスレッドの数。

Amazon 5EMR.17.0 以前では、高負荷のワークロードを実行するときに、よりクリーンなオペレーションがクエリのパフォーマンスに影響を与える可能性があるため、オフピーク時にのみクリーンアップを有効にすることをお勧めします。クリーナーには次のHBaseシェルコマンドがあります。

  • cleaner_chore_enabled クリーナーが有効かどうかのクエリ。

  • cleaner_chore_run 手動でクリーナーを実行してファイルを削除します。

  • cleaner_chore_switch クリーナーを有効、または無効にし、クリーナーの以前の状態に返します。たとえば、cleaner_chore_switch true はクリーナーを有効にします。

Amazon S3 のパフォーマンスチューニングHBaseの のプロパティ

Amazon S3 HBaseで を使用すると、ワークロードのパフォーマンスを調整するために以下のパラメータを調整できます。

設定プロパティ デフォルト値 説明

hbase.bucketcache.size

8,192

BucketCache ストレージ用にリージョンサーバー Amazon EC2インスタンスストアとEBSボリュームで予約されているディスク容量を MB 単位で表したものです。設定は、すべてのリージョンサーバーインスタンスに適用されます。通常、 BucketCache サイズが大きいほどパフォーマンスが向上します。

hbase.hregion.memstore.flush.size

134217728

Amazon S3 への Memstore フラッシュがトリガーされるデータ上限 (バイト単位)。

hbase.hregion.memstore.block.multiplier

4

更新がブロックされる MemStore 上限を決定する乗数。がこの値にhbase.hregion.memstore.flush.size乗算された MemStore を超えると、更新はブロックされます。 MemStore flushes が発生し、圧縮によって更新のブロックが解除される可能性があります。

hbase.hstore.blockingStoreFiles

10

更新 StoreFiles がブロックされるまでにストアに存在することができる の最大数。

hbase.hregion.max.filesize

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 または hbase.rootdir設定プロパティを使用して、前のクラスターと同じ Amazon S3 の場所を指定します。