Teradata から BigQuery への移行: 概要

このドキュメントは、BigQuery Data Transfer Service を使用して Teradata から BigQuery にスキーマとデータを移行する際に決定する必要がある事項を理解するうえで役立ちます。

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

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

概要

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

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

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

転送ジョブの構成

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

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

  1. Teradata テーブルをパーティショニングします。
  2. 抽出方法として Teradata Parallel Transporter(TPT)を使用します。
  3. カスタム スキーマ ファイルを作成し、ターゲットの 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 データ型の列でのみ使用できます。

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

次のテーブル定義を使用する、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 では 1 回限りの転送(「オンデマンド転送」)と定期的に繰り返される新規および更新された行の転送(「増分転送」)の両方を使用できます(増分転送はプレビュー版です)。転送の設定時にスケジュールのオプションで、転送をオンデマンド転送または増分転送として指定します。

  • オンデマンド転送: Teradata から BigQuery へのスキーマとデータの初期移行を行うにはこのモードを使用します。

  • 増分転送: Teradata から BigQuery に、新規および更新されたデータを定期的に移行するには、このモードを使用します。

    • この方法を使用する場合、スキーマをカスタマイズし、COMMIT_TIMESTAMP 使用タイプを使用して列にアノテーションを付ける必要があります。
    • 増分転送を設定する際は、特定の条件が適用されます。

増分転送

増分転送では、最初の転送で常に BigQuery にテーブル スナップショットが作成されます。それ以降の転送では、BigQuery の既存のテーブルに新しいデータと変更されたデータをキャプチャ、転送、追加します。つまり、行が変更された場合、BigQuery テーブルで古い値のある行と新しい値のある行が重複している可能性があります。

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

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

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

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

Teradata オペレーション Teradata から BigQuery への移行サポート
CREATE DDL テーブルの新しい完全なスナップショットが BigQuery に作成されます。
DROP DDL サポート対象外
ALTERRENAME DDL 名前を変更したテーブルの新しい完全なスナップショットが BigQuery に作成されます。前回のスナップショットは BigQuery から削除されません。名前が変更されたテーブルは、ユーザーに通知されません。
INSERT DML BigQuery テーブルに新しい行が追加されます。
UPDATE DML 行は変更されません。INSERT オペレーションと同様、BigQuery テーブルには行が新規として追加されます。前回の転送の行は更新も削除もされません。
MERGE DML サポート対象外。代わりに INSERTUPDATEDELETE を参照してください。
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 の割り当てと上限が適用されます。
  • データが 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 バケットが適切に保護されていることを確認します。
  • ストアド プロシージャ、保存されたクエリ、ビュー、ユーザー定義の関数などの他のデータベース リソースは転送されません。これらのリソースは本サービスの対象外です。

次のステップ