HBase から Cloud Bigtable へのデータの移行

この記事では、Apache HBase クラスタから Google Cloud の Cloud Bigtable クラスタにデータを移行する際の考慮事項とプロセスについて説明します。

この移行を開始する前に、パフォーマンスへの影響、Bigtable のスキーマ設計、認証と認可の方法、Bigtable の機能セットについて検討する必要があります。

移行前の考慮事項

このセクションでは、移行を開始する前に確認すべき事項について説明します。

パフォーマンス

通常のワークロードの場合、Bigtable は、極めて予測可能性の高いパフォーマンスを実現します。データを移行する前に、Bigtable のパフォーマンスに影響する要素を理解しておいてください。

Bigtable のスキーマ設計

ほとんどの場合、Bigtable では HBase と同じスキーマ設計を使用できます。スキーマを変更する場合や、ユースケースが変更される場合は、データを移行する前に、スキーマの設計に記載されたコンセプトを確認してください。

認証と認可

Bigtable のアクセス制御を設計する際は、あらかじめ既存の HBase の認証と認可に関するプロセスを確認しておきます。

Bigtable では Google Cloud の標準的な認証メカニズムと Identity and Access Management を使用してアクセス制御を実行するため、HBase 上の既存の認可を IAM に変換します。HBase のアクセス制御メカニズムを備えた既存の Hadoop グループを異なるサービス アカウントにマッピングできます。

Bigtable では、プロジェクト、インスタンス、テーブルのレベルでアクセスを制御できます。詳しくは、アクセス制御をご覧ください。

HBase から Bigtable への移行

HBase から Bigtable にデータを移行するには、各テーブルの HBase スナップショットを Cloud Storage にエクスポートし、Bigtable にデータをインポートします。これらの手順は単一の HBase クラスタに対するものです。詳細については、以降のセクションで説明します。

  1. HBase クラスタへの書き込みの送信を停止します。
  2. HBase クラスタのテーブルのスナップショットを作成します。
  3. スナップショット ファイルを Cloud Storage にエクスポートします。
  4. ハッシュを計算し、Cloud Storage にエクスポートします。
  5. Bigtable に宛先テーブルを作成します。
  6. Cloud Storage から Bigtable に HBase データをインポートします。
  7. インポートされたデータを検証します。
  8. Bigtable への書き込みをルーティングします。

始める前に

  1. スナップショットを保存する Cloud Storage バケットを作成します。Dataflow ジョブを実行する予定のロケーションにバケットを作成します。

  2. 新しいテーブルを格納する Bigtable インスタンスを作成します。

  3. エクスポートする Hadoop クラスタを特定します。移行のジョブは、HBase クラスタで直接実行することも、HBase クラスタの Namenode および Datanode にネットワーク接続できる別の Hadoop クラスタで実行することもできます。

  4. Hadoop クラスタのすべてのノードと、ジョブの開始元ホストに Cloud Storage コネクタをインストールして構成します。インストール手順の詳細については、Cloud Storage コネクタのインストールをご覧ください。

  5. HBase クラスタと Bigtable プロジェクトに接続できるホストでコマンドシェルを開きます。ここで、次のステップを完了します。

  6. Schema Translation ツールを取得します。

    wget BIGTABLE_HBASE_TOOLS_URL
    

    BIGTABLE_HBASE_TOOLS_URL は、ツールの Maven リポジトリにある最新の JAR with dependencies の URL に置き換えます。ファイル名は https://repo1.maven.org/maven2/com/google/cloud/bigtable/bigtable-hbase-1.x-tools/1.24.0/bigtable-hbase-1.x-tools-1.24.0-jar-with-dependencies.jar のようになります。

    URL を確認する、または JAR を手動でダウンロードするには、次の手順に従います。

    1. リポジトリに移動します
    2. 最新のバージョン番号をクリックします。
    3. JAR with dependencies file(通常は先頭)を特定します。
    4. URL を右クリックしてコピーするか、ファイルをクリックしてダウンロードします。
  7. インポート ツールを取得します。

    wget BIGTABLE_BEAM_IMPORT_URL
    

    BIGTABLE_BEAM_IMPORT_URL は、ツールの Maven リポジトリにある最新の shaded JAR の URL に置き換えます。ファイル名は https://repo1.maven.org/maven2/com/google/cloud/bigtable/bigtable-beam-import/1.24.0/bigtable-beam-import-1.24.0-shaded.jar のようになります。

    URL を確認する、または JAR を手動でダウンロードするには、次の手順に従います。

    1. リポジトリに移動します
    2. 最新のバージョン番号をクリックします。
    3. [ダウンロード] をクリックします。
    4. shaded.jar にカーソルを合わせます。
    5. URL を右クリックしてコピーするか、ファイルをクリックしてダウンロードします。
  8. 次の環境変数を設定します。

    #Google Cloud
    
    export PROJECT_ID=PROJECT_ID
    export INSTANCE_ID=INSTANCE_ID
    export REGION=REGION
    export CLUSTER_NUM_NODES=CLUSTER_NUM_NODES
    
    #JAR files
    
    export TRANSLATE_JAR=TRANSLATE_JAR
    export IMPORT_JAR=IMPORT_JAR
    
    #Cloud Storage
    
    export BUCKET_NAME="gs://BUCKET_NAME"
    export MIGRATION_DESTINATION_DIRECTORY="$BUCKET_NAME/hbase-migration-snap"
    
    #HBase
    
    export ZOOKEEPER_QUORUM=ZOOKEPER_QUORUM
    export ZOOKEEPER_PORT=2181
    export ZOOKEEPER_QUORUM_AND_PORT="$ZOOKEEPER_QUORUM:$ZOOKEEPER_PORT"
    export MIGRATION_SOURCE_DIRECTORY=MIGRATION_SOURCE_DIRECTORY
    

    次のように置き換えます。

    • PROJECT_ID: インスタンスが存在する Google Cloud プロジェクト
    • INSTANCE_ID: データのインポート先の Bigtable インスタンスの ID
    • REGION: Bigtable インスタンス内のいずれかのクラスタを含むリージョン。例: northamerica-northeast2
    • CLUSTER_NUM_NODES: Bigtable インスタンス内のノード数
    • TRANSLATE_JAR: Maven からダウンロードした bigtable hbase tools JAR ファイルの名前とバージョン番号。値は bigtable-hbase-1.x-tools-1.24.0-jar-with-dependencies.jar のようになります。
    • IMPORT_JAR: Maven からダウンロードした bigtable-beam-import JAR ファイルの名前とバージョン番号。値は bigtable-beam-import-1.24.0-shaded.jar のようになります。
    • BUCKET_NAME: スナップショットを保存する Cloud Storage バケットの名前
    • ZOOKEEPER_QUORUM: ツールで接続する Zookeeper ホスト(host1.myownpersonaldomain.com 形式)
    • MIGRATION_SOURCE_DIRECTORY: 移行するデータを保持する HBase ホスト上のディレクトリ(hdfs://host1.myownpersonaldomain.com:8020/hbase 形式)。
  9. (省略可)変数が正しく設定されていることを確認するには、printenv コマンドを実行してすべての環境変数を表示します。

HBase への書き込みの送信を停止する

HBase テーブルのスナップショットを取得する前に、HBase クラスタへの書き込みの送信を停止します。

HBase テーブルのスナップショットを作成する

HBase クラスタがデータを取り込みなくなったら、Bigtable に移行する各テーブルのスナップショットを作成します。

スナップショットは、最初は HBase クラスタのストレージ フットプリントが最小限ですが、時間とともに元のテーブルと同じサイズに拡大する可能性があります。スナップショットは CPU リソースを消費しません。

各スナップショットに一意の名前を使用して、テーブルごとに次のコマンドを実行します。

echo "snapshot 'TABLE_NAME', 'SNAPSHOT_NAME'" | hbase shell -n

次のように置き換えます。

  • TABLE_NAME: データのエクスポート元の HBase テーブルの名前。
  • SNAPSHOT_NAME: 新しいスナップショットの名前

HBase スナップショットを Cloud Storage にエクスポートする

スナップショットを作成したら、エクスポートする必要があります。本番環境の HBase クラスタでエクスポート ジョブを実行する場合は、クラスタと他の HBase リソースをモニタリングして、クラスタが適切な状態であることを確認してください。

エクスポートするスナップショットごとに、次のコマンドを実行します。

hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot \
-Dhbase.zookeeper.quorum=$ZOOKEEPER_QUORUM_AND_PORT -snapshot SNAPSHOT_NAME \
    -copy-from $MIGRATION_SOURCE_DIRECTORY \
    -copy-to $MIGRATION_DESTINATION_DIRECTORY/data

SNAPSHOT_NAME は、エクスポートするスナップショットの名前に置き換えます。

ハッシュを計算してエクスポートする

次に、移行の完了後に、検証に使用するハッシュを作成します。HashTable は、HBase によって提供される検証ツールで、行範囲のハッシュを計算してファイルにエクスポートします。宛先テーブルで sync-table ジョブを実行することで、ハッシュと照合され、移行されたデータの整合性を確保できます。

エクスポートしたテーブルごとに、次のコマンドを実行します。

hbase org.apache.hadoop.hbase.mapreduce.HashTable --batchsize=32000 --numhashfiles=20 \
TABLE_NAME $MIGRATION_DESTINATION_DIRECTORY/hashtable/TABLE_NAME

次のように置き換えます。

  • TABLE_NAME: スナップショットを作成してエクスポートした HBase テーブルの名前。

宛先テーブルを作成する

次のステップでは、エクスポートしたスナップショットごとに Bigtable インスタンスに宛先テーブルを作成します。インスタンスに対する bigtable.tables.create 権限を持つアカウントを使用します。

このガイドでは、Cloud Bigtable スキーマ変換ツールを使用して、テーブルを自動的に作成します。ただし、Bigtable のスキーマを HBase スキーマと正確に一致させない場合は、cbt コマンドライン ツールまたは Google Cloud Console を使用してテーブルを作成できます。

Cloud Bigtable スキーマ変換ツールは、テーブル名、列ファミリー、ガベージ コレクション ポリシー、スプリットなど、HBase テーブルのスキーマをキャプチャします。次に、Bigtable で同様のテーブルを作成します。

インポートするテーブルごとに、次のコマンドを実行して HBase から Bigtable にスキーマをコピーします。

java \
 -Dgoogle.bigtable.project.id=$PROJECT_ID \
 -Dgoogle.bigtable.instance.id=$INSTANCE_ID \
 -Dgoogle.bigtable.table.filter=TABLE_NAME \
 -Dhbase.zookeeper.quorum=$ZOOKEEPER_QUORUM \
 -Dhbase.zookeeper.property.clientPort=$ZOOKEEPER_PORT \
 -jar $TRANSLATE_JAR

TABLE_NAME は、インポートする HBase テーブルの名前に置き換えます。スキーマ変換ツールは、新しい Bigtable テーブルにこの名前を使用します。

必要に応じて、TABLE_NAME を、作成するテーブルをキャプチャする正規表現(「.*」など)に置き換え、このコマンドを 1 回だけ実行します。

Dataflow を使用して HBase データを Bigtable にインポートする

データの移行先とするテーブルを用意したら、データをインポートして検証できます。

非圧縮テーブル

HBase テーブルが圧縮されていない場合は、移行するテーブルごとに次のコマンドを実行します。

java -jar $IMPORT_JAR importsnapshot \
    --runner=DataflowRunner \
    --project=$PROJECT_ID \
    --bigtableInstanceId=$INSTANCE_ID \
    --bigtableTableId=TABLE_NAME \
    --hbaseSnapshotSourceDir=$MIGRATION_DESTINATION_DIRECTORY/data \
    --snapshotName=SNAPSHOT_NAME \
    --stagingLocation=$MIGRATION_DESTINATION_DIRECTORY/staging \
    --tempLocation=$MIGRATION_DESTINATION_DIRECTORY/temp \
    --maxNumWorkers=$(expr 3 \* $CLUSTER_NUM_NODES) \
    --region=$REGION

次のように置き換えます。

  • TABLE_NAME: インポートする HBase テーブルの名前。スキーマ変換ツールは、新しい Bigtable テーブルにこの名前を使用します。新しいテーブル名はサポートされていません。
  • SNAPSHOT_NAME: インポートするテーブルのスナップショットに割り当てた名前

インポートする際には、次の点に注意してください。

  • データ読み込みのパフォーマンスを向上させるには、必ず maxNumWorkers を設定してください。この値によって、Bigtable インスタンスを圧迫するほどではないものの、インポート ジョブを妥当な時間内に完了するのに十分なコンピューティング能力を使用できるようになります。
    • 別のワークロードに Bigtable インスタンスを使用していない場合は、Bigtable インスタンスのノード数を 3 で乗算し、その数を maxNumWorkers に使用します。
    • HBase データのインポートと同時に、別のワークロードにインスタンスを使用している場合は、maxNumWorkers の値を適切に下げてください。
  • デフォルトのワーカータイプを使用します。
  • インポート中は、Bigtable インスタンスの CPU 使用率をモニタリングする必要があります。Bigtable インスタンス全体の CPU 使用率が高すぎる場合は、ノードの追加が必要になる可能性があります。クラスタが追加ノード分のパフォーマンスを発揮するまでには、最大 20 分かかることがあります。

Bigtable インスタンスのモニタリングの詳細については、Bigtable インスタンスのモニタリングをご覧ください。

Snappy で圧縮されたテーブル

Snappy で圧縮されたテーブルをインポートする場合は、Dataflow パイプラインでカスタム コンテナ イメージを使用する必要があります。Bigtable に圧縮データのインポートに使用するカスタム コンテナ イメージは、Hadoop ネイティブの圧縮ライブラリをサポートします。Dataflow Runner v2 を使用するには、Apache Beam SDK バージョン 2.30.0 以降が必要です。

Snappy 圧縮テーブルをインポートするには、非圧縮テーブルに対して実行したのと同じコマンドを実行しますが、次の 2 つのオプションを追加します。

    --experiments=use_runner_v2 \
    --sdkContainerImage=gcr.io/cloud-bigtable-ecosystem/unified-harness:latest

Bigtable にインポートされたデータを検証する

インポートされたデータを検証するには、sync-table ジョブを実行する必要があります。sync-table ジョブは、Bigtable の行範囲のハッシュを計算し、前に計算した HashTable 出力と照合します。

sync-table ジョブを実行するには、コマンドシェルで次のコマンドを実行します。

java -jar $IMPORT_JAR sync-table  \
    --runner=dataflow \
    --project=$PROJECT_ID \
    --bigtableInstanceId=$INSTANCE_ID \
    --bigtableTableId=TABLE_NAME \
    --outputPrefix=$MIGRATION_DESTINATION_DIRECTORY/sync-table/output-TABLE_NAME-$(date +"%s") \
    --stagingLocation=$MIGRATION_DESTINATION_DIRECTORY/sync-table/staging \
    --hashTableOutputDir=$MIGRATION_DESTINATION_DIRECTORY/hashtable/TABLE_NAME \
    --tempLocation=$MIGRATION_DESTINATION_DIRECTORY/sync-table/dataflow-test/temp \
    --region=$REGION

TABLE_NAME は、インポートする HBase テーブルの名前に置き換えます。スキーマ変換ツールは、新しい Bigtable テーブルにこの名前を使用します。

sync-table ジョブが完了したら、Dataflow ジョブの詳細ページを開き、ジョブのカスタム カウンタ セクションを確認します。インポート ジョブによってすべてのデータが正常にインポートされた場合、ranges_matched の値には値が付き、ranges_not_matched の値は 0 になります。

Dataflow カスタム カウンタ

ranges_not_matched に値が表示される場合は、[ログ] ページを開き、[ワーカーログ] を選択して、[Mismatch on range] でフィルタします。これらのログの機械で読み取り可能な出力を、sync-table outputPrefix オプションで作成した出力先ににある Cloud Storage に保存します。

Dataflow ワーカーのログ

インポート ジョブを再度試すか、出力ファイルを読み取るスクリプトを作成して、不一致が発生した場所を特定できます。出力ファイルの各行は、一致しない範囲のシリアル化された JSON レコードです。

書き込みを Bigtable にルーティングする

クラスタ内の各テーブルのデータを検証したら、すべてのトラフィックを Bigtable にルーティングするように アプリケーションを構成し、HBase インスタンスを非推奨にします。

移行が完了したら、HBase インスタンスのスナップショットを削除できます。

次のステップ