このページは Cloud Translation API によって翻訳されました。

Teradata から BigQuery への移行: 概要

このドキュメントは、BigQuery Data Transfer Service を使用して Teradata から BigQuery にスキーマとデータを移行する際の考慮事項について説明します。

スキーマとデータの移行は通常、データプラットフォームを別のプラットフォームから BigQuery に移動するために必要なステップの一つです。エンドツーエンドの移行プロセスの詳細については、概要: データウェアハウスを BigQuery に移行するをご覧ください。

また、一括 SQL 変換を使用して SQL スクリプトを一括で移行することも、インタラクティブ SQL 変換を使用してアドホッククエリ変換することもできます。Teradata SQL は、両方の SQL 変換サービスで完全にサポートされています。

概要

BigQuery Data Transfer Service を特別な移行エージェントと組み合わせて使用すると、Teradata から BigQuery にスキーマとデータをコピーできます。移行エージェントがローカルのデータウェアハウスに接続され、BigQuery Data Transfer Service と通信して、データウェアハウスから BigQuery にテーブルをコピーします。

次の手順では、移行プロセスのワークフローについて説明します。

移行エージェントをダウンロードします。
BigQuery Data Transfer Service で転送を構成します。
転送ジョブを実行して、テーブルスキーマとデータをデータウェアハウスから BigQuery にコピーします。
省略可。Google Cloud コンソールを使用して転送ジョブをモニタリングします。

転送ジョブの構成

ニーズに合わせて転送ジョブを構成できます。Teradata から BigQuery へのデータ転送を設定する前に、次のセクションで説明する構成オプションを検討し、使用する設定を決定してください。選択した設定によっては、転送ジョブを開始する前にいくつかの前提条件を満たす必要があります。

ほとんどのシステム、特に大規模なテーブルを持つシステムでは、次の手順で最高のパフォーマンスが得られます。

Teradata テーブルをパーティショニングします。
抽出方法として、Teradata Parallel Transporter（TPT）を使用します。
カスタムスキーマファイルを作成し、ターゲットの BigQuery のクラスタリング列とパーティショニング列を構成します。

これにより、移行エージェントはパーティションごとの抽出を実行できます。これが最も効率的です。

抽出方法

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

Teradata Parallel Transporter（TPT）の tbuild ユーティリティを使用します。これはおすすめの方法です。TPT を使用すると、通常はデータ抽出が高速になります。

このモードでは、移行エージェントが、パーティションで分散された行を使用して抽出バッチの計算を試みます。バッチごとに、エージェントが TPT 抽出スクリプトを発行して実行し、一連のパイプ区切りファイルを生成します。次に、これらのファイルを Cloud Storage バケットにアップロードします。ファイルはここで転送ジョブにより使用されます。ファイルが Cloud Storage にアップロードされると、移行エージェントはローカルファイルシステムからファイルを削除します。

パーティショニング列なしで TPT 抽出を使用すると、テーブル全体が抽出されます。パーティショニング列のある TPT 抽出を使用すると、エージェントがパーティションのセットが抽出されます。

このモードでは、抽出されたファイルがローカルファイルシステム上で占める容量が移行ファイルによって制限されることはありません。パーティショニング列を指定しているかどうかによって、ローカルファイルシステムのパーティションが、最大パーティションまたは最大テーブルのサイズより大きいことを確認してください。
JDBC ドライバと FastExport 接続を使用した抽出。抽出されたファイルに使用できるローカルストレージの制約がある場合、またはなんらかの理由で TPT を使用できない場合は、この抽出方法を使用してください。

このモードでは、移行エージェントがテーブルをローカルファイルシステム上の AVRO ファイルのコレクションに抽出します。次に、これらのファイルを Cloud Storage バケットにアップロードします。ファイルはここで転送ジョブにより使用されます。ファイルが Cloud Storage にアップロードされると、移行エージェントはローカルファイルシステムからファイルを削除します。

このモードでは、ローカルファイルシステム上の AVRO ファイルが使用するスペースを制限できます。この制限を超えると、既存の AVRO ファイルのアップロードと削除によって移行エージェントがスペースを解放するまで、抽出は一時停止されます。

スキーマの特定

BigQuery Data Transfer Service は、Teradata から BigQuery へのデータ転送中に自動的にスキーマを検出してデータ型をマッピングします。必要に応じて、カスタムスキーマファイルを指定することもできます。次の状況では、スキーマのカスタマイズをおすすめします。

移行時に失われる可能性がある、テーブルに関する重要な情報をキャプチャする必要がある。

たとえば、後続の転送からのデータを BigQuery に読み込むときに適切に分割できるように、増分転送ではスキーマファイルを指定する必要があります。スキーマファイルを指定しない場合、転送を実行するたびに、BigQuery Data Transfer Service は転送されるソースデータを使用してテーブルスキーマを自動的に適用し、パーティショニング、クラスタリング、主キー、変更トラッキングに関するすべての情報は失われます。
データ転送中に列名またはデータ型を変更する必要があります。

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

カスタムスキーマファイルは、データベースオブジェクトを記述する JSON ファイルです。スキーマには、一連のデータベースが含まれ、各データべースに一連のテーブルが含まれます。各テーブルには、一連の列が含まれます。各オブジェクトには、Teradata のオブジェクト名を示す originalName フィールドと、BigQuery のオブジェクトのターゲット名を示す name フィールドがあります。

列には、他にも次のフィールドがあります。

Teradata の列データ型を示す originalType フィールド
BigQuery での列のターゲットデータ型を示す type フィールド。
クラスタリングやパーティショニングなど、システムでの列の使用方法に関する情報をキャプチャする、usageType フィールド。次の使用タイプがサポートされています。
- CLUSTERING: 各ターゲットテーブルでは、この使用タイプを使用して最大 4 つの列にアノテーションを付けることができます。クラスタリングの列順序は、カスタムスキーマに表示される順序に基づいて決定されます。選択する列は、BigQuery でのクラスタリングの制約を満たす必要があります。同じテーブルに PARTITIONING フィールドが指定されている場合、BigQuery はこれらの列を使用してクラスタ化テーブルを作成します。
- COMMIT_TIMESTAMP: この使用タイプでは、ターゲットテーブルごとに 1 つの列にのみアノテーションを付けることができます。この usageType は、増分更新の更新タイムスタンプ列を特定するために使用します。この列は、前回の転送実行以降に作成または更新された行を抽出するために使用されます。この使用タイプは、TIMESTAMP データ型または DATE データ型の列でのみ使用できます。
- DEFAULT: この使用タイプでは、1 つのテーブルの複数の列にアノテーションを付けることができます。usageType は、列がソースシステムで特別な用途に使用されていないことを示します。これがデフォルト値です。
- PARTITIONING: この使用タイプでは、ターゲットテーブルごとに 1 つの列にのみアノテーションを付けることができます。この列は、含まれる tables オブジェクトのパーティション分割テーブル定義で使用されます。この使用タイプは、TIMESTAMP データ型または DATE データ型の列でのみ使用できます。
- PRIMARY_KEY: この使用タイプでは、各ターゲットテーブルの列にアノテーションを付けることができます。この使用タイプは、1 つの列のみを主キーとして識別する場合に使用します。複合キーの場合は、複数の列に同じ使用タイプを使用して、テーブルの一意のエンティティを識別します。これらの列は COMMIT_TIMESTAMP と連携して、前回の転送実行以降に作成または更新された行を抽出します。

こちらの例に基づいてカスタムスキーマファイルを手動で作成するか、エージェントを初期化するときに移行エージェントで自動的に生成できます。

例

次のテーブル定義を使用する、tpch データベース内の orders という Teradata テーブルを移行するとします。


CREATE SET TABLE TPCH.orders ,FALLBACK ,
     NO BEFORE JOURNAL,
     NO AFTER JOURNAL,
     CHECKSUM = DEFAULT,
     DEFAULT MERGEBLOCKRATIO,
     MAP = TD_MAP1
     (
      O_ORDERKEY INTEGER NOT NULL,
      O_CUSTKEY INTEGER NOT NULL,
      O_ORDERSTATUS CHAR(1) CHARACTER SET LATIN CASESPECIFIC NOT NULL,
      O_TOTALPRICE DECIMAL(15,2) NOT NULL,
      O_ORDERDATE DATE FORMAT 'yyyy-mm-dd' NOT NULL,
      O_ORDERPRIORITY CHAR(15) CHARACTER SET LATIN CASESPECIFIC NOT NULL,
      O_CLERK CHAR(15) CHARACTER SET LATIN CASESPECIFIC NOT NULL,
      O_SHIPPRIORITY INTEGER NOT NULL,
      O_COMMENT VARCHAR(79) CHARACTER SET LATIN CASESPECIFIC NOT NULL)
UNIQUE PRIMARY INDEX ( O_ORDERKEY );

BigQuery への移行中に、次の変更を行ってスキーマを構成するとします。

O_CUSTKEY 列の名前を O_CUSTOMERKEY に変更する。
O_ORDERDATE をパーティショニング列として特定する。

これらの設定を構成するカスタムスキーマは次のとおりです。


{
  "databases": [
    {
      "name": "tpch",
      "originalName": "e2e_db",
      "tables": [
        {
          "name": "orders",
          "originalName": "orders",
          "columns": [
            {
              "name": "O_ORDERKEY",
              "originalName": "O_ORDERKEY",
              "type": "INT64",
              "originalType": "integer",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 4
            },
            {
              "name": "O_CUSTOMERKEY",
              "originalName": "O_CUSTKEY",
              "type": "INT64",
              "originalType": "integer",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 4
            },
            {
              "name": "O_ORDERSTATUS",
              "originalName": "O_ORDERSTATUS",
              "type": "STRING",
              "originalType": "character",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 1
            },
            {
              "name": "O_TOTALPRICE",
              "originalName": "O_TOTALPRICE",
              "type": "NUMERIC",
              "originalType": "decimal",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 8
            },
            {
              "name": "O_ORDERDATE",
              "originalName": "O_ORDERDATE",
              "type": "DATE",
              "originalType": "date",
              "usageType": [
                "PARTITIONING"
              ],
              "isRequired": true,
              "originalColumnLength": 4
            },
            {
              "name": "O_ORDERPRIORITY",
              "originalName": "O_ORDERPRIORITY",
              "type": "STRING",
              "originalType": "character",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 15
            },
            {
              "name": "O_CLERK",
              "originalName": "O_CLERK",
              "type": "STRING",
              "originalType": "character",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 15
            },
            {
              "name": "O_SHIPPRIORITY",
              "originalName": "O_SHIPPRIORITY",
              "type": "INT64",
              "originalType": "integer",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 4
            },
            {
              "name": "O_COMMENT",
              "originalName": "O_COMMENT",
              "type": "STRING",
              "originalType": "varchar",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 79
            }
          ]
        }
      ]
    }
  ]
}

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

Teradata データベースインスタンスから BigQuery にデータを移行する際に、BigQuery Data Transfer Service では完全な転送（オンデマンド転送）と定期的な転送（増分転送）の両方をサポートしています。転送の設定時にスケジュールのオプションで、転送をオンデマンド転送または増分転送として指定します。

オンデマンド転送: このモードは、完全なスナップショットを実行して Teradata から BigQuery にスキーマとデータを移行する場合に使用します。
スケジュール設定された転送: このモードは、完全なスナップショットを実行し、新規および変更されたデータ（増分データ）を Teradata から BigQuery に定期的に移行する場合に使用します。増分転送では、スキーマをカスタマイズし、次のいずれかの方法で列にアノテーションを付ける必要があります。
- COMMIT_TIMESTAMP の使用タイプのみの列にアノテーションを付ける: この転送では、Teradata の新しい行または変更された行が BigQuery のデータに追加されます。BigQuery テーブルの更新された行には、古い値と新しい値を持つ重複行が存在する可能性があります。
- COMMIT_TIMESTAMP と PRIMARY_KEY の両方の使用タイプで列にアノテーションを付ける: この転送では、新しい行が追加され、変更された行は BigQuery の対応する行に更新されます。PRIMARY_KEY で定義された列は、BigQuery でデータの一意性を維持するために使用されます。
- スキーマで定義された PRIMARY_KEY 列は、Teradata テーブルの PRIMARY_KEY である必要はありません。任意の列を使用できますが、一意のデータが含まれている必要があります。

増分転送

増分転送では、最初の転送で常に BigQuery にテーブルスナップショットが作成されます。以降の増分転送はすべて、後述のカスタムスキーマファイルで定義されたアノテーションに準拠します。

転送実行ごとに、転送実行のタイムスタンプが保存されます。それ以降の転送実行ごとに、エージェントは前回の転送実行（T1）のタイムスタンプと、現在の転送実行開始（T2）のタイムスタンプを取得します。

最初の転送実行後、移行エージェントは次のテーブルごとのロジックを使用してデータを抽出します。

スキーマファイル内のテーブルオブジェクトに使用タイプが COMMIT_TIMESTAMP の列がない場合、テーブルはスキップされます。
テーブルに使用タイプが COMMIT_TIMESTAMP の列がある場合、T1 と T2 の間のタイムスタンプを持つすべての行が抽出され、BigQuery の既存のテーブルに追加されます。
テーブルに使用タイプが COMMIT_TIMESTAMP の列と使用タイプが PRIMARY_KEY の列がある場合、T1 と T2 の間のタイムスタンプを持つすべての行が抽出されます。新しい行は追加され、変更された行は BigQuery の既存のテーブルで更新されます。

増分転送のスキーマファイルの例を次に示します。

COMMIT_TIMESTAMP のみを含むスキーマ


{
  "databases": [
    {
      "name": "abc_db",
      "originalName": "abc_db",
      "tables": [
        {
          "name": "abc_table",
          "originalName": "abc_table",
          "columns": [
            {
              "name": "Id",
              "originalName": "Id",
              "type": "INT64",
              "originalType": "integer",
              "originalColumnLength": 4,
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true
            },
            {
              "name": "timestamp",
              "originalName": "timestamp",
              "type": "TIMESTAMP",
              "originalType": "timestamp",
              "originalColumnLength": 26,
              "usageType": [
                "COMMIT_TIMESTAMP"
              ],
              "isRequired": false
            }
          ]
        }
      ]
    }
  ]
}

COMMIT_TIMESTAMP を持ち、1 つの列（Id）が PRIMARY_KEY のスキーム


{
  "databases": [
    {
      "name": "abc_db",
      "originalName": "abc_db",
      "tables": [
        {
          "name": "abc_table",
          "originalName": "abc_table",
          "columns": [
            {
              "name": "Id",
              "originalName": "Id",
              "type": "INT64",
              "originalType": "integer",
              "originalColumnLength": 4,
              "usageType": [
                "PRIMARY_KEY"
              ],
              "isRequired": true
            },
            {
              "name": "timestamp",
              "originalName": "timestamp",
              "type": "TIMESTAMP",
              "originalType": "timestamp",
              "originalColumnLength": 26,
              "usageType": [
                "COMMIT_TIMESTAMP"
              ],
              "isRequired": false
            }
          ]
        }
      ]
    }
  ]
}

COMMIT_TIMESTAMP を持ち、複合キー（ID + 名前）が PRIMARY_KEY のスキーマ


{
  "databases": [
    {
      "name": "abc_db",
      "originalName": "abc_db",
      "tables": [
        {
          "name": "abc_table",
          "originalName": "abc_table",
          "columns": [
            {
              "name": "Id",
              "originalName": "Id",
              "type": "INT64",
              "originalType": "integer",
              "originalColumnLength": 4,
              "usageType": [
                "PRIMARY_KEY"
              ],
              "isRequired": true
            },
            {
              "name": "Name",
              "originalName": "Name",
              "type": "STRING",
              "originalType": "character",
              "originalColumnLength": 30,
              "usageType": [
                "PRIMARY_KEY"
              ],
              "isRequired": false
            },
            {
              "name": "timestamp",
              "originalName": "timestamp",
              "type": "TIMESTAMP",
              "originalType": "timestamp",
              "originalColumnLength": 26,
              "usageType": [
                "COMMIT_TIMESTAMP"
              ],
              "isRequired": false
            }
          ]
        }
      ]
    }
  ]
}

次の表では、移行エージェントが増分転送でデータ定義言語（DDL）とデータ操作言語（DML）のオペレーションを処理する方法を示しています。

Teradata オペレーション	型	Teradata から BigQuery への移行サポート
`CREATE`	DDL	テーブルの新しい完全なスナップショットが BigQuery に作成されます。
`DROP`	DDL	サポート対象外
`ALTER`（`RENAME`）	DDL	名前を変更したテーブルの新しい完全なスナップショットが BigQuery に作成されます。前回のスナップショットは BigQuery から削除されません。名前が変更されたテーブルは、ユーザーに通知されません。
`INSERT`	DML	BigQuery テーブルに新しい行が追加されます。
`UPDATE`	DML	`COMMIT_TIMESTAMP` のみが使用されている場合、`INSERT` オペレーションと同様に、BigQuery テーブルに行が新規として追加されます。`COMMIT_TIMESTAMP` と `PRIMARY_KEY` の両方が使用されている場合、`UPDATE` オペレーションと同様に行が更新されます。
`MERGE`	DML	サポートされていません。代わりに `INSERT`、`UPDATE`、`DELETE` を参照してください。
`DELETE`	DML	サポート対象外

ロケーションに関する留意事項

Cloud Storage バケットは、BigQuery の宛先データセットのリージョンまたはマルチリージョンと互換性のあるリージョンまたはマルチリージョンに存在する必要があります。

BigQuery データセットがマルチリージョンにある場合、転送するデータが含まれている Cloud Storage バケットは、同じマルチリージョンまたはマルチリージョンに含まれるロケーションに存在する必要があります。たとえば、BigQuery データセットが「EU」マルチリージョンにある場合、Cloud Storage バケットは EU 内の「europe-west1」ベルギーリージョンに配置できます。
データセットがリージョンにある場合、Cloud Storage バケットは同じリージョンに存在する必要があります。たとえば、データセットが「asia-northeast1」東京リージョンにある場合、Cloud Storage バケットを「ASIA」マルチリージョンに配置することはできません。

転送とリージョンについて詳しくは、データセットのロケーションと転送をご覧ください。

料金

BigQuery によるデータ転送は追加料金なしでご利用いただけます。ただし、このサービスを使用すると、プラットフォームのアウトバウンドデータ転送料金など、Google 外部で料金が発生する場合があります。

データの抽出、Cloud Storage バケットへのアップロード、BigQuery へのデータの読み込みも無料です。
データが BigQuery にアップロードされたあと、Cloud Storage バケットから自動で削除されることはありません。余分なストレージコストがかからないようにするため、Cloud Storage バケットからデータを削除することをおすすめします。Cloud Storage の料金をご覧ください。
読み込みジョブに対する標準の BigQuery の割り当てと上限が適用されます。
増分取り込みの upsert に対する標準の DML BigQuery の割り当てと上限が適用されます。
データが BigQuery に転送されると、BigQuery のストレージとコンピューティングの標準料金が適用されます。
詳細については、転送の料金ページをご覧ください。

制限事項

1 回限りのオンデマンド転送は完全にサポートされています。増分転送はベータ版です。増分転送での DD / DML オペレーションは部分的にサポートされています。
データ転送中に、データがローカルファイルシステム上のディレクトリに抽出されます。十分な空き容量があることを確認してください。
- FastExport による抽出モードを使用する場合、使用する最大ストレージ容量と、移行エージェントによって厳格に適用される制限を設定できます。Teradata から BigQuery への転送を設定する際に、移行エージェントの構成ファイルで max-local-storage の値を設定します。
- TPT による抽出方法を使用する場合、ファイルシステムに十分な空き容量（Teradata インスタンスの最大のテーブルパーティションを超える容量）があることを確認してください。
BigQuery Data Transfer Service は、スキーマを自動的に変換して（カスタムスキーマファイルが指定されていない場合）、Teradata データを BigQuery に転送します。データは Teradata の型から BigQuery の型にマッピングされます。
BigQuery に読み込まれたファイルが Cloud Storage バケットから自動で削除されることはありません。ストレージの費用が余分にかからないよう、BigQuery に読み込まれたあとはデータを Cloud Storage バケットから削除することを検討してください。料金をご覧ください。
抽出の速度は JDBC 接続によって制限されます。
Teradata から抽出されたデータは暗号化されません。ローカルファイルシステムに抽出されたファイルへのアクセスを制限するために適切な措置を講じてください。また、Cloud Storage バケットが適切に保護されていることを確認します。
ストアドプロシージャ、保存されたクエリ、ビュー、ユーザー定義の関数などの他のデータベースリソースは転送されません。これらのリソースは本サービスの対象外です。
増分転送では削除（復元不可）はサポートされていません。増分転送では、Teradata で削除された行は BigQuery と同期されません。

次のステップ

Teradata から BigQuery への移行の手順を確認する。
Teradata から BigQuery へのテスト移行を試みる。