Migración de Teradata a BigQuery: descripción general detallada

En este documento, se proporciona más información para ayudarte a comprender las decisiones que debes tomar cuando usas el Servicio de transferencia de datos de BigQuery para migrar el esquema y los datos de Teradata a BigQuery. Para obtener una introducción al proceso de migración de Teradata, consulta Introducción a una migración de Teradata a BigQuery.

La migración de esquemas y datos suele ser uno de los varios pasos necesarios para mover un almacén de datos desde una plataforma diferente hasta BigQuery. Para obtener una descripción de un proceso de migración general, consulta la Descripción general: Migra almacenes de datos a BigQuery.

También puedes usar la traducción de SQL por lotes para migrar tus secuencias de comandos de SQL de forma masiva o la traducción de SQL interactiva para traducir consultas ad hoc. SQL de Teradata es compatible por completo con ambos servicios de traducción de SQL.

Descripción general

Puedes usar el Servicio de transferencia de datos de BigQuery junto con un agente de migración especial para copiar el esquema y los datos de Teradata a BigQuery. El agente de migración se conecta a tu almacén de datos local y se comunica con el Servicio de transferencia de datos de BigQuery para copiar tablas de tu almacén de datos a BigQuery.

En los siguientes pasos, se describe el flujo de trabajo para el proceso de migración:

1. Descarga el agente de migración.
2. Configura una transferencia en el Servicio de transferencia de datos de BigQuery.
3. Ejecuta el trabajo de transferencia para copiar el esquema y los datos de la tabla de tu almacén de datos a BigQuery.
4. Opcional. Supervisa los trabajos de transferencia mediante la consola de Google Cloud .

Configuración del trabajo de transferencia

Puedes configurar un trabajo de transferencia para que se adapte mejor a tus necesidades. Antes de configurar una transferencia de datos de Teradata a BigQuery, considera las opciones de configuración que se describen en las siguientes secciones y decide qué configuración usar. Según la configuración que elijas, es posible que debas completar algunos requisitos antes de iniciar el trabajo de transferencia.

Para la mayoría de los sistemas, en especial aquellos con tablas grandes, puedes obtener el mejor rendimiento si sigues estos pasos:

1. Particiona tus tablas de Teradata.
2. Usa el Transportador paralelo de Teradata (TPT) para la extracción.
3. Crea un archivo de esquema personalizado y configura las columnas de agrupamiento en clústeres y partición de BigQuery de destino.

Esto permite que el agente de migración realice la extracción partición por partición, que es la más eficiente.

Método de extracción

El Servicio de transferencia de datos de BigQuery admite dos métodos de extracción diferentes para transferir datos de Teradata a BigQuery:

• Usa la utilidad tbuild de Transporte paralelo de Teradata (TPT). Este es el método recomendado. El TPT suele dar como resultado una extracción de datos más rápida.

  En este modo, el agente de migración intenta calcular lotes de extracción mediante filas distribuidas por particiones. Para cada lote, el agente emite y ejecuta una secuencia de comandos de extracción de TPT y produce un conjunto de archivos delimitados por canalizaciones. Luego, sube estos archivos a un bucket de Cloud Storage, donde los usa el trabajo de transferencia. Una vez que los archivos se suben a Cloud Storage, el agente de migración los borra del sistema de archivos local.

  Cuando usas la extracción de TPT sin una columna de partición, se extrae toda la tabla. Cuando usas la extracción de TPT con una columna de partición, el agente extrae conjuntos de particiones.

  En este modo, el agente de migración no limita la cantidad de espacio que los archivos extraídos ocupan en el sistema de archivos local. Asegúrate de que el sistema de archivos local tenga más espacio que el tamaño de tu partición más grande o de tu tabla más grande, dependiendo de si especificas una columna de partición o no.

• Extracción mediante un controlador JDBC con conexión FastExport. Si hay restricciones en el espacio de almacenamiento local disponible para los archivos extraídos o si hay alguna razón por la que no puedes usar TPT, usa este método de extracción.

  En este modo, el agente de migración extrae tablas en una colección de archivos AVRO en el sistema de archivos local. Luego, sube estos archivos a un bucket de Cloud Storage, donde los usa el trabajo de transferencia. Una vez que los archivos se suben a Cloud Storage, el agente de migración los borra del sistema de archivos local.

  En este modo, puedes limitar la cantidad de espacio que usan los archivos AVRO en el sistema de archivos local. Si se excede este límite, la extracción se detiene hasta que el agente de migración libere espacio mediante la carga y la eliminación de los archivos AVRO existentes.

Identificación del esquema

Puedes definir el esquema de varias maneras. El Servicio de transferencia de datos de BigQuery proporciona detección automática de esquemas y asignación de tipos de datos durante una transferencia de datos de Teradata a BigQuery. También puedes usar el motor de traducción para obtener la asignación de tipos de datos o puedes especificar un archivo de esquema personalizado.

Detección de esquemas predeterminados

Si no especificas ninguna configuración de esquema, el Servicio de transferencia de datos de BigQuery detecta automáticamente el esquema de tus tablas de origen de Teradata y realiza la asignación de tipos de datos a los tipos de datos de BigQuery correspondientes durante la transferencia de datos. Para obtener más información sobre la asignación de tipos de datos predeterminada, consulta Tipos de datos.

Cómo usar el resultado del motor de traducción para el esquema

El Servicio de transferencia de datos de BigQuery usa el resultado del motor de traducción de BigQuery para la asignación de esquemas durante la migración de tablas de Teradata a BigQuery. Para usar esta opción, asegúrate de que se cumplan los siguientes requisitos:

1. Genera metadatos para la traducción. Ejecuta la herramienta de volcado para generar metadatos para la traducción, de acuerdo con los lineamientos de la fuente de Teradata. Si deseas obtener más información, consulta Genera metadatos para la traducción y la evaluación.
2. Sube el archivo de metadatos generado (por ejemplo, metadata.zip) a un bucket de Cloud Storage. Este bucket sirve como ubicación de entrada para el motor de traducción.

3. Inicia un trabajo de traducción por lotes para crear la asignación del Servicio de transferencia de datos de BigQuery, que define el esquema de las tablas de BigQuery de destino. Para obtener información sobre cómo hacerlo, consulta Cómo crear una traducción por lotes. En el siguiente ejemplo, se especifica target_types = "dts_mapping" para generar la asignación del Servicio de transferencia de datos de BigQuery:

   curl -d "{
   \"name\": \"teradata_2_bq_translation\",
    \"displayName\": \"Teradata to BigQuery Translation\",
    \"tasks\": {
        string: {
          \"type\": \"Teradata2BigQuery_Translation\",
          \"translation_details\": {
              \"target_base_uri\": \"gs://your_translation_output_bucket/output\",
              \"source_target_mapping\": {
                \"source_spec\": {
                    \"base_uri\": \"gs://your_metadata_bucket/input\"
                }
              },
              \"target_types\": \"metadata\",
          }
        }
    },
    }" \
    -H "Content-Type:application/json" \
    -H "Authorization: Bearer YOUR_ACCESS_TOKEN" -X POST https://bigquerymigration.googleapis.com/v2alpha/projects/your_project_id/locations/your_location/workflows
   

   Para verificar el estado de la tarea de traducción por lotes en la Google Cloud consola, navega a BigQuery -> Traducción de SQL. Una vez completado, el archivo de asignación se almacena en una ubicación de Cloud Storage especificada en la marca target_base_uri.

   Para generar un token, usa el comando gcloud auth print-access-token o la zona de pruebas de OAuth 2.0 con el permiso https://www.googleapis.com/auth/cloud-platform.

4. En la configuración de transferencia de datos de Teradata, especifica la ruta de acceso a la carpeta de Cloud Storage en la que se almacena el archivo de asignación del paso anterior. El Servicio de transferencia de datos de BigQuery usa esta asignación para definir el esquema de tus tablas de BigQuery de destino.

Archivo de esquema personalizado

Recomendamos especificar un esquema personalizado en las siguientes situaciones:

• Si necesitas capturar información importante sobre una tabla, como la partición, que, de lo contrario, se perdería en la migración.

  Por ejemplo, las transferencias incrementales deben tener un archivo de esquema especificado para que los datos de las transferencias posteriores puedan particionarse correctamente cuando se carguen en BigQuery. Sin un archivo de esquema, cada vez que se ejecuta una transferencia, el Servicio de transferencia de datos de BigQuery aplica automáticamente un esquema de tabla mediante los datos de origen que se transfieren, y se pierde toda la información sobre particiones, clústeres, claves primarias y el seguimiento de cambios.

• Si necesitas cambiar los nombres de las columnas o los tipos de datos durante la transferencia de datos.

Un archivo de esquema personalizado es un archivo JSON que describe objetos de base de datos. El esquema contiene un conjunto de bases de datos, cada una de las cuales tiene un conjunto de tablas, y cada una de ellas contiene un conjunto de columnas. Cada objeto tiene un campo originalName que indica el nombre del objeto en Teradata y un campo name que indica el nombre de destino del objeto en BigQuery.

Las columnas tienen los siguientes campos:

• originalType: Indica el tipo de datos de la columna en Teradata.
• type: Indica el tipo de datos de destino para la columna en BigQuery.

• usageType: Es la información sobre cómo el sistema usa la columna. Se admiten los siguientes tipos de uso:

  • DEFAULT: Puedes anotar varias columnas en una tabla de destino con este tipo de uso. Este usageType indica que la columna no tiene un uso especial en el sistema de origen. Este es el valor predeterminado.
  • CLUSTERING: Puedes anotar hasta cuatro columnas en cada tabla de destino con este tipo de uso. El orden de las columnas para el agrupamiento en clústeres se determina según el orden en el que aparecen en el esquema personalizado. Las columnas que selecciones deben cumplir con las restricciones para el agrupamiento en clústeres en BigQuery. Si se especifica un campo PARTITIONING para la misma tabla, BigQuery usa estas columnas a fin de crear una tabla agrupada.
  • PARTITIONING: Solo puedes anotar una columna por tabla con este tipo de uso. Esta columna se usa en la definición de tabla particionada para el objeto tables que la contiene. Solo puedes usar este tipo de uso con una columna que tenga un tipo de datos TIMESTAMP o DATE.
  • COMMIT_TIMESTAMP: Solo puedes anotar una columna en cada tabla de destino con este tipo de uso. Usa este usageType para identificar una columna de marca de tiempo de actualización para actualizaciones incrementales. Esta columna se usa para extraer filas que se crearon o actualizaron desde la última ejecución de la transferencia. Solo puedes usar este tipo de uso con columnas que tengan un tipo de datos TIMESTAMP o DATE.
  • PRIMARY_KEY: Puedes anotar columnas en cada tabla de destino con este tipo de uso. Usa este tipo de uso para identificar solo una columna como la clave primaria o, en el caso de una clave compuesta, usa el mismo tipo de uso en varias columnas para identificar las entidades únicas de una tabla. Estas columnas trabajan junto con COMMIT_TIMESTAMP para extraer filas creadas o actualizadas desde la última ejecución de la transferencia.

Puedes crear un archivo de esquema personalizado de forma manual, como se ve en el siguiente ejemplo, o puedes hacer que el agente de migración genere uno cuando lo inicialices.

En este ejemplo, un usuario migra una tabla de Teradata llamada orders en la base de datos tpch con la siguiente definición de tabla:

  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 );

Mientras migra a BigQuery, el usuario quiere configurar el esquema con los siguientes cambios:

• Cambia el nombre de la columna O_CUSTKEY a O_CUSTOMERKEY.
• Identifica O_ORDERDATE como la columna de partición

El siguiente ejemplo es un esquema personalizado para configurar estos parámetros:

{
  "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
            }
          ]
        }
      ]
    }
  ]
}

Transferencias según demanda o incrementales

Cuando se migran datos de una instancia de base de datos de Teradata a BigQuery, el Servicio de transferencia de datos de BigQuery admite transferencias completas (transferencia según demanda) y transferencias recurrentes (transferencias incrementales). Cuando configures una transferencia, puedes designarla como según demanda o incremental en las opciones de programación.

• Transferencia según demanda: Usa este modo para realizar la migración inicial del esquema y los datos de Teradata a BigQuery.

• Transferencia programada: Usa este modo para realizar la instantánea completa y migrar con regularidad los datos nuevos y modificados (datos incrementales) de Teradata a BigQuery. Las transferencias incrementales requieren que personalices tu esquema para anotar columnas con cualquiera de los siguientes casos de uso:

  • Anotación de columnas con solo el tipo de uso COMMIT_TIMESTAMP: En esta transferencia, se agregan las filas nuevas o modificadas de Teradata a los datos de BigQuery. Las filas actualizadas en las tablas de BigQuery pueden tener filas duplicadas con valores antiguos y nuevos.
  • Anota las columnas con los tipos de uso COMMIT_TIMESTAMP y PRIMARY_KEY: en esta transferencia, se agregan filas nuevas y las filas modificadas se actualizan a la fila correspondiente en BigQuery. La columna definida en PRIMARY_KEY se usa para mantener la unicidad de los datos en BigQuery.
  • No es necesario que la columna PRIMARY_KEY definida en el esquema sea la PRIMARY_KEY en la tabla de Teradata. Puede ser cualquier columna, pero debe contener datos únicos.

Transferencias incrementales

En las transferencias incrementales, la primera transferencia siempre crea una instantánea de tabla en BigQuery. Todas las transferencias incrementales posteriores cumplirán con las anotaciones definidas en el archivo de esquema personalizado que se explica a continuación.

Para cada ejecución de transferencia, se guarda una marca de tiempo de la ejecución de la transferencia. Para cada ejecución de transferencia posterior, un agente recibe la marca de tiempo de una ejecución de transferencia anterior (T1) y una marca de tiempo de cuándo comenzó la ejecución de transferencia actual (T2).

Para las transferencias posteriores a la ejecución inicial, el agente de migración extraerá los datos con la siguiente lógica por tabla:

• Si un objeto de tabla en un archivo de esquema no tiene una columna con un tipo de uso COMMIT_TIMESTAMP, se omite la tabla.
• Si una tabla tiene una columna con el tipo de uso COMMIT_TIMESTAMP, todas las filas con una marca de tiempo entre T1 y T2 se extraen y se anexan a la tabla existente en BigQuery.
• Si una tabla tiene una columna con el tipo de uso COMMIT_TIMESTAMP y una columna con el tipo de uso PRIMARY_KEY, se extraen todas las filas con una marca de tiempo entre T1 y T2. Las filas nuevas se agregan y las filas modificadas se actualizan en la tabla existente en BigQuery.

Los siguientes son ejemplos de archivos de esquemas para transferencias incrementales.

Esquema con solo 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
            }
          ]
        }
      ]
    }
  ]
}

Esquema con COMMIT_TIMESTAMP y una columna (ID) como 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
            }
          ]
        }
      ]
    }
  ]
}

Esquema con COMMIT_TIMESTAMP y clave compuesta (ID + nombre) como 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
            }
          ]
        }
      ]
    }
  ]
}

En la siguiente tabla, se describe cómo el agente de migración controla las operaciones del lenguaje de definición de datos (DDL) y del lenguaje de manipulación de datos (DML) en transferencias incrementales.

Consideraciones de ubicación

Tu depósito de Cloud Storage debe estar en una región o multirregión compatible con la región o multirregión del conjunto de datos de destino en BigQuery.

• Si tu conjunto de datos de BigQuery está en una multirregión, el bucket de Cloud Storage que contiene los datos que transferirás debe estar en la misma multirregión o en una ubicación dentro de la multirregión. Por ejemplo, si tu conjunto de datos de BigQuery está en la multirregión EU, el bucket de Cloud Storage puede estar ubicado en la región europe-west1 de Bélgica, que está dentro de la UE.
• Si tu conjunto de datos está en una sola región, el bucket de Cloud Storage debe estar en la misma región. Por ejemplo, si tu conjunto de datos está en la región asia-northeast1 de Tokio, tu bucket de Cloud Storage no puede estar en la multirregión ASIA.

Para obtener información detallada sobre transferencias y regiones, consulta Ubicaciones y transferencias de conjuntos de datos.

Precios

La transferencia de datos con BigQuery es gratuita. Sin embargo, se pueden generar costos fuera de Google mediante el uso de este servicio, como los cobros de transferencia de datos salientes de la plataforma.

• La extracción, la carga en un bucket de Cloud Storage y la carga de datos a BigQuery es gratis.
• Los datos no se borran de forma automática de tu depósito de Cloud Storage después de que se suben a BigQuery. Considera borrar los datos del bucket de Cloud Storage para evitar costos de almacenamiento adicionales. Consulta Precios de Cloud Storage.
• A los trabajos de carga se les aplican cuotas y límites estándar de BigQuery.
• Se aplicarán las cuotas y límites estándar de DML de BigQuery a las inserciones y actualizaciones incrementales de transferencia.
• Una vez que se transfieren los datos a BigQuery, se aplican los precios estándar de almacenamiento y procesamiento de BigQuery.
• Consulta la página de precios de transferencias para obtener más detalles.

Limitaciones

• Las transferencias a pedido únicas son totalmente compatibles. Las operaciones DDL/DML en transferencias incrementales son parcialmente compatibles.
• Durante la transferencia de datos, los datos se extraen a un directorio del sistema de archivos local. Asegúrate de que haya suficiente espacio libre.
  • Cuando usas el modo de extracción FastExport, puedes establecer el espacio de almacenamiento máximo que se usará y el límite impuesto por el agente de migración. Establece la configuración max-local-storage en el archivo de configuración del agente de migración cuando configures una transferencia de Teradata a BigQuery.
  • Cuando uses el método de extracción TPT, asegúrate de que el sistema de archivos tenga suficiente espacio libre: mayor que la partición de tabla más grande en la instancia de Teradata.
• El Servicio de transferencia de datos de BigQuery convierte el esquema de forma automática (si no proporcionas un archivo de esquema personalizado) y transfiere los datos de Teradata a BigQuery. Los datos se asignan de Teradata a los tipos BigQuery.
• Los archivos no se eliminan automáticamente de tu bucket de Cloud Storage después de cargarse en BigQuery. Considera eliminar los datos de tu bucket de Cloud Storage después de cargarlos en BigQuery, para evitar costos de almacenamiento adicionales. Consulta la sección de precios.
• La velocidad de la extracción dependerá de tu conexión JDBC.
• Los datos extraídos de Teradata no están encriptados. Sigue los pasos correspondientes para restringir el acceso a los archivos extraídos en el sistema de archivos local y asegúrate de que el bucket de Cloud Storage esté asegurado de forma adecuada.
• No se transfieren otros recursos de la base de datos, como procedimientos almacenados, consultas guardadas, vistas y funciones definidas por el usuario, y no están dentro del alcance de este servicio.
• Las transferencias incrementales no admiten la eliminación definitiva. Las transferencias incrementales no sincronizan ninguna fila borrada en Teradata con BigQuery.

¿Qué sigue?

• Obtén instrucciones paso a paso para migrar Teradata a BigQuery.
• Prueba una migración de prueba de Teradata a BigQuery.