Teradata からのデータ移行

BigQuery Data Transfer Service と特別な移行エージェントを組み合わせると、Teradata オンプレミスデータウェアハウスインスタンスから BigQuery にデータをコピーできます。このドキュメントでは、BigQuery Data Transfer Service を使用して Teradata からデータを移行する手順をステップごとに説明します。

始める前に

Teradata データウェアハウスの移行を確実に成功させるには、次の前提条件を満たす必要があります。

Google Cloud の要件

移行データを保存するための Google Cloud プロジェクトを選択するか、作成します。転送を設定するには、Google Cloud プロジェクトの owner 権限が必要です。
- Google Cloud Console で [プロジェクトの選択] ページに移動します。
  
  プロジェクトセレクタに移動
- Google Cloud プロジェクトを選択または作成します。
  
  注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。
これらの Google Cloud APIs を有効化します。
Console
Cloud Console で、次のページの [有効にする] ボタンをクリックします。
新しいプロジェクトでは、BigQuery が自動的に有効になります。既存のプロジェクトの場合は、BigQuery API の有効化が必要になる場合もあります。
- BigQuery API
例:

緑色のチェックマークは、API がすでに有効にされていることを示します。
gcloud
gcloud コマンドラインツールを使用して API を有効にすることもできます。

gcloud コマンドは、Cloud Shell で発行できます。また、次のように gcloud ツールをダウンロードしてローカルマシンにインストールすることもできます。
- gcloud ツールを実行するには、Java 8 がインストールされている必要があります。こちらのリンクを使用してダウンロードします。
- Cloud SDK をインストールして、初期化してください。
次の gcloud コマンドを入力します。
```
gcloud services enable bigquerydatatransfer.googleapis.com
gcloud services enable storage-component.googleapis.com
gcloud services enable pubsub.googleapis.com
```
新しいプロジェクトでは、BigQuery が自動的に有効になります。既存のプロジェクトの場合は、BigQuery API も有効にします。
```
gcloud services enable bigquery.googleapis.com
```
データを保存する BigQuery データセットを作成します。テーブルを作成する必要はありません。
Identity and Access Management（IAM）サービスアカウントを作成します。サービスアカウントの作成方法については、サービスアカウントの作成と管理をご覧ください。
サービスアカウントに次の IAM ロールを付与します。サービスアカウントへのロールの付与をご覧ください。
- BigQuery: IAM 事前定義ロール bigquery.admin。
- Cloud Storage: IAM 事前定義ロール storage.objectAdmin。
データをステージングするための Cloud Storage バケットを作成します。このバケットの名前は、後に移行プロセスで使用します。

オンプレミスの要件

ローカルマシンの要件
- 移行エージェントは、Teradata インスタンスと Google Cloud APIs との JDBC 接続を使用します。ファイアウォールによってネットワークアクセスがブロックされていないことを確認します。
- Java Runtime Environment 8 以降がインストールされていることを確認します。
- ステージングスペースの要件で説明されている推奨する最小限のストレージスペースがあることを確認します。
Teradata 接続の詳細
- システムテーブルと移行されるテーブルへの読み取りアクセス権限を持つユーザーのユーザー名とパスワード。
- Teradata インスタンスに接続するためのホスト名とポート番号。
  注: ユーザー名とパスワードはプロンプトでキャプチャされ、RAM にのみ保存されます。必要であれば、後のステップでユーザー名とパスワードの認証情報ファイルを作成できます。認証情報は暗号化されないため、ローカルファイルシステム上でファイルを保存するフォルダへのアクセスを制限するために適切な措置を講じてください。
Teradata から必要な JDBC ドライバをダウンロードします。
- terajdbc4.jar
- Teradata JDBC Driver 12.0.0.104 より古いバージョンを使用している場合は、tdgssconfig.jar もダウンロードする必要があります。
Google Cloud の認証情報をダウンロードします。
- 認証情報をダウンロードするためにサービスアカウントキーの作成と管理を行います。
- 環境変数を設定するの説明に従って、ダウンロードしたサービスアカウントキーを環境変数 GOOGLE_APPLICATION_CREDENTIALS に設定します。

VPC Service Controls の要件

BigQuery Data Transfer Service マネージド Google Cloud プロジェクト（プロジェクト番号: 990232121269）を VPC Service Controls の境界の下り（外向き）ルールに追加します。

オンプレミスで実行されているエージェントと BigQuery Data Transfer Service との間の通信チャネルは、転送トピックごとに Pub/Sub メッセージを公開することで行われます。BigQuery Data Transfer Service では、データを抽出するためにコマンドをエージェントに送信する必要があり、エージェントはステータスを更新してデータ抽出のレスポンスを返すために BigQuery Data Transfer Service にメッセージを公開する必要があります。

転送モードとオプション

移行にはそれぞれ固有の要件があるため、移行エージェントは次の方法でカスタマイズできるようになっています。Teradata から BigQuery へのデータ転送を設定する際は、主に 3 つの選択肢があります。

抽出方法: JDBC と FastConnect または Teradata Parallel Transporter（TPT）
自動スキーマ変換またはカスタムスキーマファイル
オンデマンド転送または増分転送（ベータ版）

抽出方法

BigQuery Data Transfer Service では、Teradata から BigQuery へのデータ転送に関して 2 つの抽出方法をサポートしています。

JDBC ドライバと FastExport 接続を使用した抽出。このモードでは、テーブルが AVRO ファイルのコレクションとしてローカルファイルシステム上の指定の場所に抽出されます。抽出されたファイルは、指定の Cloud Storage バケットにアップロードされます。転送が成功すると、ローカルファイルシステムからファイルが削除されます。
- ローカルファイルシステムの容量に対する制限が厳格に適用され、抽出されたファイルがアップロードされてローカルファイルシステムから削除されるまで、抽出は一時停止されます。
- ローカルのストレージ容量がかなり制約されている場合、または TPT を使用できない場合は、この抽出方法を使用してください。
- JDBC ドライバと FastExport による抽出は、デフォルトの抽出方法です。
Teradata Parallel Transporter（TPT）の tbuild ユーティリティを使用した抽出。このモードでは、エージェントがパーティションで分散された行を使用して抽出バッチの計算を試みます。バッチごとに TPT 抽出スクリプトが発行されて実行され、一連のパイプ区切りファイルが生成されます。各バッチが抽出されるたびに、ファイルが指定の Cloud Storage バケットにアップロードされます。アップロードが完了すると、そのファイルがローカルファイルシステムから削除されます。ローカルファイルシステムの容量には制限が適用されません。したがって、Teradata テーブルの最大のパーティションを抽出するのに十分な容量がローカルファイルシステムにあることを確認する必要があります。
- TPT を使用して抽出し、スキーマをカスタマイズしてパーティションの列を指定することをおすすめします。これにより、最短時間でデータを抽出できます。

抽出方法の指定について詳しくは、転送の設定手順の移行エージェントの構成セクションをご覧ください。

カスタムスキーマファイル

スキーマファイルは、データベースオブジェクトを記述する JSON ファイルです。スキーマには、一連のデータベースが含まれ、各データべースに一連のテーブルが含まれます。各テーブルには、一連の列が含まれます。各列には type フィールドがあります。BigQuery 内の列には、このフィールドで指定されている型が割り当てられます。

スキーマファイル内の各オブジェクトには name フィールドがあります。BigQuery 内のオブジェクトには、このフィールドで指定されている名前が割り当てられます。各オブジェクトには originalName フィールドもあります。このフィールドには、Teradata データベース内の対応するオブジェクトの名前を示します。

BigQuery Data Transfer Service は、Teradata から BigQuery へのデータ転送中に自動的にスキーマを検出してデータを変換します。必要に応じて、カスタムスキーマファイルを指定することもできます。場合によっては、スキーマをカスタマイズすることを強くおすすめします。例:

テーブルに関する追加情報（スキーマが指定されていないと移行中に損失してしまうパーティショニングなど）を含めるには、カスタムスキーマファイルが特に役立ちます。
任意のオブジェクトの name フィールドや、任意の列の usageType 配列をデータ転送中に転送するには、フィールドを転送するためのカスタムスキーマファイルを提供するという方法を選択できます。
詳しくは、Teradata の移行の詳細とオプションをご覧ください。

オンデマンド転送または増分転送

Teradata データベースインスタンスから BigQuery にデータを移行する際に、BigQuery Data Transfer Service では 1 回限りのスナップショットデータ転送（「オンデマンド転送」）と定期的に繰り返される新規および更新された行の転送（「増分転送」）の両方を使用できます（増分転送はベータ版です）。転送の設定時にスケジュールのオプションで、転送をオンデマンド転送または増分転送として指定します。

データのオンデマンド転送
- テーブルのサイズが非常に大きく、パフォーマンス向上のために TPT を使用して抽出できる場合、Teradata テーブルをパーティショニングしてパーティションごとに抽出できるようにすることをおすすめします。詳しくは、Teradata の移行の詳細とオプションをご覧ください。
- テーブルのサイズが小さい場合や TPT を使用できない場合は、基本的な手順を行ってください。この場合、スキーマのカスタマイズは必要ありません。

データの増分転送
- Teradata から BigQuery に定期的に変更を移行するには、増分モードを使用できます。定期的に Teradata の新しいレコードと変更されたレコードが BigQuery テーブルに追加されます。
- この方法を使用する場合、スキーマをカスタマイズして COMMIT_TIMESTAMP 列にアノテーションを追加する必要があります。
- 増分転送を設定する際は、特定の条件が適用されます。詳細については、増分転送をご覧ください。

Teradata 移行の設定

このセクションでは、Teradata から BigQuery へのデータ移行を設定するプロセスをステップごとに説明します。ステップは次のとおりです。

移行エージェントをダウンロードします。
BigQuery Data Transfer Service 転送を設定します。
移行エージェントを初期化します。
移行エージェントを実行します。

移行エージェントのダウンロード

このリンクから移行エージェントをデータウェアハウスに接続できるマシンにダウンロードします。

移行エージェントをインストールしたら、BigQuery Data Transfer Service 転送を設定し、移行エージェントを初期化してから、エージェントを実行してデータの移行を開始します。

転送の設定

BigQuery Data Transfer Service で転送を作成します。

Console

Cloud Console で、BigQuery ページに移動します。

[BigQuery] ページに移動
[転送] をクリックします。
[転送を作成] をクリックします。
[ソースタイプ] で次の操作を行います。
- [Migration: Teradata] を選択します。
- [転送構成名] に、転送の表示名（例: My Migration）を入力します。表示名には、後で修正が必要になった場合に簡単に識別できる任意の名前を使用できます。
- （省略可）[スケジュールオプション] は、デフォルト値の [毎日]（作成時刻に基づく）のままにするか、別の時間を選択します。
  注:
  Cloud Console の場合のみ、1 回限りの繰り返しのない転送のオンデマンド スケジュールオプションを選択できます。
  
  定期的な転送（ベータ版）には、後にこの転送構成設定で指定されるオプションのカスタムスキーマファイルが役立ちます。カスタムスキーマファイルでは、BigQuery テーブルに読み込まれたときに、定期的な転送からのデータを分割する方法を指定できます。
- [転送先の設定] で、該当するデータセットを選択します。
[データソースの詳細] の各項目に、Teradata の転送について具体的な詳細情報を入力します。
- [Database type] で、[Teradata] を選択します。
- Cloud Storage バケットについては、移行データをステージングするための Cloud Storage バケットの名前を探索します。接頭辞 gs:// は入力しないでください。バケット名のみを入力してください。
- [Database name] に、Teradata のソースデータベースの名前を入力します。
- [Table name patterns] に、ソースデータベース内のテーブル名を照合するためのパターンを入力します。正規表現を使用してパターンを指定できます。このパターンは、Java の正規表現の構文に従っている必要があります。
  テーブル名のパターンの 2 つの例:
  - sales|expenses は、sales と expenses の 2 つのテーブルに一致します。
  - .* は、すべてのテーブルに一致します。
- [Service account email] に、作成した IAM サービスアカウントに関連付けられるメールアドレスを入力します。
- （省略可）[Schema file path] には、JSON スキーマファイルのパスとファイル名を入力します。スキーマファイルが入力されていない場合、BigQuery は転送されるソースデータを使用してテーブルスキーマを自動的に検出します。以下のスクリーンショットの例に示すように、独自のスキーマファイルを作成するか、移行エージェントを使用してスキーマファイルを作成できます。スキーマファイルの作成については、移行エージェントの初期化セクションをご覧ください。
  注意: 定期的な転送では、後続の転送からのデータを BigQuery に読み込むときに適切に分割できるように、スキーマファイルを指定する必要があります。
  
  スキーマファイルを指定しない場合、転送を実行するたびに、BigQuery Data Transfer Service は転送されるソースデータとパーティショニング、クラスタリング、主キー、変更トラッキングに関するすべての情報を使用してテーブルスキーマを自動的に適用し、変更トラッキングは失われます。また、初期転送後、その後の転送では以前移行したテーブルをスキップします。スキーマファイルを作成して Cloud Storage バケットにアップロードする方法の詳細については、カスタムスキーマファイルのセクションをご覧ください。
- （省略可）[通知オプション] セクションで、次の操作を行います。
  - 切り替えボタンをクリックしてメール通知を有効にします。このオプションを有効にすると、転送の実行が失敗した場合、転送管理者にメール通知が送信されます。
  - [Pub/Sub トピックを選択してください] で、トピック名を選択するか、[トピックを作成する] をクリックします。このオプションで、Pub/Sub の転送実行通知を構成します。
[保存] をクリックします。
この転送のリソース名を含むすべての転送設定の詳細が Cloud Console に表示されます。後で移行エージェントを実行するときに入力する必要があるため、リソース名を書き留めておきます。

bq

bq mk コマンドを入力して、転送作成フラグ --transfer_config を指定します。次のフラグも必要です。

--data_source
--display_name
--target_dataset
--params

bq mk \
--transfer_config \
--project_id=project ID \
--target_dataset=dataset \
--display_name=name \
--params='parameters' \
--data_source=data source

ここで

project ID はプロジェクト ID です。--project_id で特定のプロジェクトを指定しない場合は、デフォルトのプロジェクトが使用されます。
dataset は、転送構成の対象のデータセット（--target_dataset）です。
name は、転送構成の表示名（--display_name）です。転送の表示名には、後で修正が必要になった場合に転送を簡単に識別できるよう、任意の名前を使用できます。
parameters には、作成される転送構成のパラメータ（--params）を JSON 形式で指定します。例: --params='{"param":"param_value"}'
- Teradata の移行では、次のパラメータが必要です。bucket、database_type、agent_service_account、database_name、table_name_patterns。
  - bucket は、移行中にステージング領域として機能する Cloud Storage バケットです。
  - database_type は、Teradata です。
  - agent_service_account は、作成したサービスアカウントに関連付けられたメールアドレスです。
  - database_name は、Teradata のソースデータベースの名前です。
  - table_name_patterns は、ソースデータベース内のテーブル名を照合するためのパターンです。正規表現を使用してパターンを指定できます。このパターンは、Java の正規表現の構文に従っている必要があります。
    テーブル名のパターンの 2 つの例:
    - sales|expenses は、sales と expenses という名前のテーブルで一致します。
    - .* はすべてのテーブルで一致します。
data_source は、データソース（--data_source）です。on_premises

注意: 定期的な転送では、後続の転送からのデータを BigQuery に読み込むときに適切に分割できるように、スキーマファイルを指定する必要があります。

スキーマファイルを指定しない場合、転送を実行するたびに、BigQuery Data Transfer Service は転送されるソースデータとパーティショニング、クラスタリング、主キー、変更トラッキングに関するすべての情報を使用してテーブルスキーマを自動的に適用し、変更トラッキングは失われます。また、初期転送後、その後の転送では以前移行したテーブルをスキップします。スキーマファイルを作成して Cloud Storage バケットにアップロードする方法の詳細については、カスタムスキーマファイルのセクションをご覧ください。

たとえば、次のコマンドは、Cloud Storage バケット mybucket とターゲットデータセット mydataset を使用して、My Transfer という名前の Teradata 転送を作成します。転送は Teradata データウェアハウス mydatabase からすべてのテーブルを移行します。オプションのスキーマファイルは myschemafile.json です。

bq mk \
--transfer_config \
--project_id=123456789876 \
--target_dataset=MyDataset \
--display_name='My Migration' \
--params='{"bucket": "mybucket", "database_type": "Teradata",
"database_name":"mydatabase", "table_name_patterns": ".*",
"agent_service_account":"myemail@mydomain.com", "schema_file_path":
"gs://mybucket/myschemafile.json"}' \
--data_source=on_premises

コマンドを実行すると、次のようなメッセージが表示されます。

[URL omitted] Please copy and paste the above URL into your web browser and follow the instructions to retrieve an authentication code.

指示に従って、認証コードをコマンドラインに貼り付けます。

API

projects.locations.transferConfigs.create メソッドを使用して、TransferConfig リソースのインスタンスを指定します。

Java

GitHub で表示フィードバック

import com.google.api.gax.rpc.ApiException;
import com.google.cloud.bigquery.datatransfer.v1.CreateTransferConfigRequest;
import com.google.cloud.bigquery.datatransfer.v1.DataTransferServiceClient;
import com.google.cloud.bigquery.datatransfer.v1.ProjectName;
import com.google.cloud.bigquery.datatransfer.v1.TransferConfig;
import com.google.protobuf.Struct;
import com.google.protobuf.Value;
import java.io.IOException;
import java.util.HashMap;
import java.util.Map;

// Sample to create a teradata transfer config.
public class CreateTeradataTransfer {

  public static void main(String[] args) throws IOException {
    // TODO(developer): Replace these variables before running the sample.
    final String projectId = "MY_PROJECT_ID";
    String datasetId = "MY_DATASET_ID";
    String databaseType = "Teradata";
    String bucket = "cloud-sample-data";
    String databaseName = "MY_DATABASE_NAME";
    String tableNamePatterns = "*";
    String serviceAccount = "MY_SERVICE_ACCOUNT";
    String schemaFilePath = "/your-schema-path";
    Map<String, Value> params = new HashMap<>();
    params.put("database_type", Value.newBuilder().setStringValue(databaseType).build());
    params.put("bucket", Value.newBuilder().setStringValue(bucket).build());
    params.put("database_name", Value.newBuilder().setStringValue(databaseName).build());
    params.put("table_name_patterns", Value.newBuilder().setStringValue(tableNamePatterns).build());
    params.put("agent_service_account", Value.newBuilder().setStringValue(serviceAccount).build());
    params.put("schema_file_path", Value.newBuilder().setStringValue(schemaFilePath).build());
    TransferConfig transferConfig =
        TransferConfig.newBuilder()
            .setDestinationDatasetId(datasetId)
            .setDisplayName("Your Teradata Config Name")
            .setDataSourceId("on_premises")
            .setParams(Struct.newBuilder().putAllFields(params).build())
            .setSchedule("every 24 hours")
            .build();
    createTeradataTransfer(projectId, transferConfig);
  }

  public static void createTeradataTransfer(String projectId, TransferConfig transferConfig)
      throws IOException {
    try (DataTransferServiceClient client = DataTransferServiceClient.create()) {
      ProjectName parent = ProjectName.of(projectId);
      CreateTransferConfigRequest request =
          CreateTransferConfigRequest.newBuilder()
              .setParent(parent.toString())
              .setTransferConfig(transferConfig)
              .build();
      TransferConfig config = client.createTransferConfig(request);
      System.out.println("Cloud teradata transfer created successfully :" + config.getName());
    } catch (ApiException ex) {
      System.out.print("Cloud teradata transfer was not created." + ex.toString());
    }
  }
}

移行エージェント

移行エージェントの初期化セクションで、移行エージェントから直接転送を作成することもできます。

移行エージェントからの転送を作成するには、まず IAM ロール serviceAccessTokenCreator を作成したサービスアカウントに付与する必要があります。

次のいずれかの方法で IAM ロールを付与できます。

Cloud Console で、IAM ロールのサービスアカウントトークン作成者を付与します。サービスアカウントへのロールの付与をご覧ください。
Cloud Shell または gcloud コマンドラインツールで次の gcloud コマンドを発行できます。

gcloud projects add-iam-policy-binding user_project_id \
--member='serviceAccount:service-user_project_number@gcp-sa-bigquerydatatransfer.iam.gserviceaccount.com' \
--role='roles/iam.serviceAccountTokenCreator'

サービスアカウントに serviceAccessTokenCreator 権限を付与したら、移行エージェントのダウンロードに進み、初期化手順の一環として転送を設定できます。

移行エージェントの初期化

初めてデータの移行を開始する場合は、移行エージェントを初期化します。初期化は、繰り返し発生するかどうかには関係なく、移行転送を設定するたびに 1 回だけ必要です。

このセッションでは移行は開始されません。これは初期構成用です。

新しいセッションを開きます。コマンドラインで、以下のフラグを指定して jar ファイルを実行するコマンドを発行します。

java -cp \
OS-specific-separated-paths-to-jars (JDBC and agent) \
com.google.cloud.bigquery.dms.Agent \
--initialize

Unix、Linux、Mac OS

java -cp \
/usr/local/migration/Teradata/JDBC/terajdbc4.jar:/usr/local/migration/mirroring-agent.jar \
com.google.cloud.bigquery.dms.Agent \
--initialize

Windows

すべてのファイルを C:\migration フォルダにコピーして（またはコマンドのパスを修正して）、次を実行します。

java -cp C:\migration\tdgssconfig.jar;C:\migration\terajdbc4.jar;C:\migration\mirroring-agent.jar com.google.cloud.bigquery.dms.Agent --initialize

プロンプトが表示されたら、次のパラメータを入力します。
- Teradata Parallel Transporter（TPT）テンプレートをディスクに保存するかどうか。TPT による抽出方法の使用を計画している場合、Teradata インスタンスに適したパラメータを使用して、保存されたテンプレートを変更できます。
- ソースデータベースの URI。必要に応じて、ポート番号も入力します。
- 移行用のローカルスクラッチスペースへのパス。ステージングスペースの要件で説明されている推奨の最小限のストレージスペースがあることを確認します。
- 抽出方法として Teradata Parallel Transporter（TPT）を使用するかどうか。
- （省略可）データベースの認証情報ファイルへのパス。
BigQuery Data Transfer Service のリソース名の入力を求められた場合:

Cloud Console で構成した転送のリソース名を入力することも、移行エージェント自体を使用して転送を作成することもできます。必要に応じて、移行エージェント初期化コマンドを使用してスキーマファイルを作成できます。このオプションについては、以下の移行エージェントのタブをご覧ください。
Console
転送の設定セクションの [Console] タブで設定した転送のリソース名を入力します。
移行エージェント
- Google Cloud プロジェクト ID を入力します。
- Teradata にソースデータベースの名前を入力します。
- ソースデータベース内のテーブル名と照合するパターンを入力します。正規表現を使用してパターンを指定できます。このパターンは、Java の正規表現の構文に従っている必要があります。
  テーブル名のパターンの 2 つの例:
  sales|expenses は、sales と expenses という名前のテーブルで一致します。
  
  .* はすべてのテーブルで一致します。
- 省略可: ローカルの JSON スキーマファイルへのパスを入力します（定期的な転送に推奨）。このスキーマファイルは Cloud Storage バケットにアップロードされます。
  注意: 定期的な転送では、後続の転送からのデータを BigQuery テーブルに読み込むときに適切に分割できるように、スキーマファイルを指定する必要があります。
  
  スキーマファイルを指定しない場合、転送を実行するたびに、BigQuery Data Transfer Service が Teradata テーブルを BigQuery スキーマに変換し、パーティショニング、クラスタリング、変更トラッキングに関するすべての情報が失われます。また、初期転送後、その後の転送では以前移行したテーブルをスキップします。
  
  スキーマファイルを作成して Cloud Storage バケットにアップロードする方法の詳細については、カスタムスキーマファイルのセクションをご覧ください。
  - 新しいスキーマファイルの作成を選択します。この場合、Teradata のユーザー名とパスワードを求められ、エージェントはスキーマが変換された JSON ファイルを生成します。ファイルは、パターン <localpath>/schema/DO_NOT_REMOVE_td2bq_table_schemas_<string>.json に従ってローカルフォルダに作成されます。Cloud Storage バケットにアップロードした後、パスとファイル名はパターン gs://mybucket/myproject_id/schema/DO_NOT_REMOVE_td2bq_table_schemas_<string>.json に従います。
  - スキーマファイルを変更して、パーティショニング、クラスタ化、主キー、変更トラッキング列をマークし、このスキーマを転送構成に使用することを確認します。ヒントについては、カスタムスキーマファイルのセクションをご覧ください。
- BigQuery に宛先のデータセットの名前を入力します。
- BigQuery に読み込む前に移行データをステージングする Cloud Storage バケットの名前を入力します。
- 転送構成の名前を入力します。
リクエストされたすべてのパラメータを入力すると、移行エージェントは構成ファイルを作成し、パラメータで指定されたローカルパスに配置されます。構成ファイルの詳細については、次のセクションをご覧ください。

移行エージェントの構成ファイル

初期化ステップで作成される構成ファイルは次の例のようになります。


   {
    "agent-id": "0eebc1ad-621d-4386-87f1-8eca96991f63",
    "transfer-configuration": {
      "project-id": "123456789876",
      "location": "us",
      "id": "5d533a90-0000-2e89-89a0-94eb2c059a76"
    },
    "source-type": "teradata",
    "console-log": false,
    "silent": false,
    "teradata-config": {
      "connection": {
       "host": "localhost"
      },
      "local-processing-space": "extracted",
      "database-credentials-file-path": "",
      "max-local-storage": "200GB",
      "use-tpt": false,
      "max-sessions": 0,
      "max-parallel-upload": 1,
      "max-unload-file-size": "2GB"
     }
   }

移行エージェント構成ファイルのすべてのオプション

transfer-configuration: BigQuery Data Transfer Service のこの転送構成についての情報。
teradata-config: この Teradata の抽出に固有の情報。
- connection: ホスト名とポートに関する情報
- local-processing-space: Cloud Storage にアップロードする前に、エージェントがテーブルデータを抽出する先の抽出フォルダ。
- database-credentials-file-path:（省略可）Teradata データベースに自動的に接続するための認証情報を含むファイルのパス。ファイルには次の 2 行が含まれている必要があります。例:
```
username=abc
password=123
```
  認証情報ファイルは暗号化されないため、ローカルファイルシステム上で保存するフォルダへのアクセスを制御してください。パスが指定されていない場合、エージェントを開始するときにユーザー名とパスワードを求められます。
- max-local-storage: 指定されたステージングディレクトリでの抽出に使用するローカルストレージの最大容量。デフォルト値は 200GB です。サポートされている形式は numberKB|MB|GB|TB です。
  
  すべての抽出モードで、ファイルは Cloud Storage にアップロードされた後、ローカルのステージングディレクトリから削除されます。
  注: Teradata Parallel Transporter（TPT）が使用されているときは `max-local-storage` の制限は適用されません。
  実際のステージングスペースの容量は、抽出の方法によって異なります。
  - デフォルトの抽出方法（FastExport 付き JDBC ドライバ）では、データの小さなかたまりが書き込まれ、指定された Cloud Storage バケットに継続的にアップロードされます。指定した max_local_storage の上限に達すると、抽出が一時停止します。
  - パーティショニング列のない Teradata Parallel Transporter（TPT）を使用した抽出では、max_local_storage の設定に関係なく、テーブル全体が抽出されます。
  - パーティショニング列のある Teradata Parallel Transporter（TPT）を使用した抽出では、エージェントがパーティションのセットを抽出します。ステージングストレージの要件は、max_local_storage の大きい方か、CSV 形式に抽出されたテーブルの最大パーティションのサイズによります。
- use-tpt: 抽出方法として Teradata Parallel Transporter（TPT）を使用するように移行エージェントに指示します。
  
  テーブルごとに、移行エージェントは TPT スクリプトを生成し、tbuild プロセスを開始して、完了を待ちます。tbuild プロセスが完了すると、エージェントは抽出されたファイルを一覧表示して Cloud Storage にアップロードしてから、TPT スクリプトを削除します。
  
  TPT 抽出方法を使用するには:
  - 移行エージェントが tbuild プロセスを使用して開始できるように、tbuild ユーティリティをインストールして使用できる状態にします。
  - ローカル抽出フォルダには、最大テーブルのパーティションを CSV 形式で抽出するために十分なスペースが必要です。フォーマットにより、CSV ファイルは Teradata の元のテーブルのサイズよりも大きくなります。
  警告: エージェントは TPT スクリプトを生成して、ローカルの抽出フォルダ内のファイルに保存します。このスクリプトには、Teradata のユーザー名とパスワードが含まれています。ユーザー名とパスワードは暗号化されないため、ローカル抽出フォルダ内のファイルへのアクセスを制限するために適切な措置を講じてください。
- max-sessions: エクスポートジョブ（FastExport または TPT）で使用されるセッションの最大数を指定します。0 に設定すると、Teradata データベースは各エクスポートジョブのセッションの最大数を決定します。
- max-parallel-uploads: 並行して Cloud Storage にアップロードされるファイルの数を決定します。ネットワーク帯域幅とその他の設定（DLP スキャンなど）によっては、このパラメータを大きくすることでパフォーマンスが向上する可能性があります。
- max-unload-file-size: 抽出されるファイルの最大サイズを決定します。このパラメータは TPT 抽出には適用されません。
- schema-mapping-rule-path: （省略可）デフォルトのマッピングルールをオーバーライドするスキーママッピングを含む構成ファイルのパス。
  
  例: Teradata 型 TIMESTAMP から BigQuery 型 DATETIME へのマッピング。
```
{
"rules": [
  {
    "database": {
        "name": "database.*",
        "tables": [
           {
             "name": "table.*"
           }
        ]
    },
    "match": {
      "type": "COLUMN_TYPE",
      "value": "TIMESTAMP"
    },
    "action": {
      "type": "MAPPING",
      "value": "DATETIME"
    }
  }
]
}
```
  属性:
  - database: （省略可） name は、含まれるデータベースの正規表現です。デフォルトではすべてのデータベースが含まれます。
  - tables: （省略可）テーブルの配列が含まれます。name は、含まれるテーブルの正規表現です。デフォルトではすべてのテーブルが含まれています。
  - match: （必須）
    - type: サポートされる値: COLUMN_TYPE。
    - value サポートされる値: TIMESTAMP、DATETIME。
  - action: （必須）
    - type: サポートされる値: MAPPING。
    - value サポートされる値: TIMESTAMP、DATETIME。

移行エージェントの実行

移行エージェントを初期化して構成ファイルを作成したら、次のステップでエージェントを実行し、移行を開始します。

JDBC ドライバへのクラスパスと前の初期化ステップで作成した構成ファイルへのパスを使用して、エージェントの実行を開始します。

java -cp \
OS-specific-separated-paths-to-jars (JDBC and agent) \
com.google.cloud.bigquery.dms.Agent \
--configuration-file=path to configuration file

Unix、Linux、Mac OS

java -cp \
/usr/local/migration/Teradata/JDBC/tdgssconfig.jar:/usr/local/migration/Teradata/JDBC/terajdbc4.jar:mirroring-agent.jar \
com.google.cloud.bigquery.dms.Agent \
--configuration-file=config.json

Windows

すべてのファイルを C:\migration フォルダにコピーして（またはコマンドのパスを修正して）、次を実行します。

java -cp C:\migration\tdgssconfig.jar;C:\migration\terajdbc4.jar;C:\migration\mirroring-agent.jar com.google.cloud.bigquery.dms.Agent --configuration-file=config.json

移行を進める準備ができたら、Enter を押します。初期化中に指定されたクラスパスが有効であれば、エージェントは続行します。

プロンプトが表示されたら、データベース接続のユーザー名とパスワードを入力します。ユーザー名とパスワードが有効であれば、データの移行が開始します。

（省略可）移行を開始するコマンドでは、毎回ユーザー名とパスワードを入力する代わりに、認証情報ファイルをエージェントに渡すフラグを使用することもできます。詳しくは、エージェント構成ファイルの省略可能なパラメータ database-credentials-file-path をご覧ください。認証情報は暗号化されないため、ローカルファイルシステム上でファイルを保存するフォルダへのアクセスを制限するために適切な措置を講じてください。
移行が完了するまで、このセッションを開いたままにしてください。定期的な移行転送を作成した場合は、このセッションを無期限に開いたままにしてください。このセッションが中断すると、現在と将来の転送は失敗します。
エージェントが動作しているかどうかを定期的にモニタリングします。転送の進行中に、24 時間以内にエージェントの応答がない場合、転送は失敗します。
転送の進行中であるか、スケジュールされている場合、移行エージェントが終了すると、Cloud Console にエラーステータスが表示され、エージェントを再起動するように求められます。移行エージェントを再起動するには、移行エージェントの実行のコマンドを使用して、このセクション（移行エージェントの実行）の最初からやり直します。初期化コマンドを繰り返す必要はありません。転送は、テーブルが完了しなかった時点から再開されます。

警告: Teradata から抽出されたデータは暗号化されていません。ローカルマシンの抽出フォルダにある抽出ファイルへのアクセスを制限するための適切な措置を講じて、Cloud Storage バケットが公開されていないことを確認してください。IAM ロールで Cloud Storage バケットへのアクセスを制御する方法の詳細を確認してください。

移行の進行状況のトラッキング

移行のステータスは Cloud Console で確認できます。Pub/Sub またはメール通知を設定することもできます。BigQuery Data Transfer Service の通知をご覧ください。

BigQuery Data Transfer Service は、転送構成の作成時に指定されたスケジュールで転送をスケジューリングして開始します。転送がアクティブなときに、移行エージェントが実行されていることが重要です。24 時間以内にエージェント側からの更新がない場合、転送は失敗します。

Cloud Console の移行ステータスの例:

移行ステータス

移行エージェントのアップグレード

新しいバージョンの移行エージェントが使用可能な場合は、手動で移行エージェントを更新する必要があります。BigQuery Data Transfer Service に関する通知を受け取るには、リリースノートに登録してください。

次のステップ

BigQuery へのデータウェアハウスの移行について、ソリューションガイドで詳しく確認する。
BigQuery Data Transfer Service を使用した Teradata からの移行の概要を確認する。
Teradata の転送オプションの詳細を確認する。

Teradata からのデータ移行

始める前に

Google Cloud の要件

Console

gcloud

オンプレミスの要件

VPC Service Controls の要件

転送モードとオプション

抽出方法

カスタム スキーマ ファイル

オンデマンド転送または増分転送

Teradata 移行の設定

移行エージェントのダウンロード

転送の設定

Console

bq

API

Java

移行エージェント

移行エージェントの初期化

Unix、Linux、Mac OS

Windows

Console

移行エージェント

移行エージェントの構成ファイル

移行エージェント構成ファイルのすべてのオプション

移行エージェントの実行

Unix、Linux、Mac OS

Windows

移行の進行状況のトラッキング

移行エージェントのアップグレード

次のステップ

カスタムスキーマファイル