Descripción general de la migración de Teradata a BigQuery

Este documento te ayuda 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.

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 del proceso de migración de extremo a extremo, 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

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. De manera opcional, puedes especificar un archivo de esquema personalizado en su lugar. Recomendamos la personalización del esquema en las siguientes situaciones:

  • Debes 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. Si no se especifica 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.

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

Archivo de esquema personalizado

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.

Además, las columnas tienen los siguientes campos:

  • Un campo originalType que indica el tipo de datos de la columna en Teradata
  • Un campo type que indica el tipo de datos de destino para la columna en BigQuery.

  • Un campo usageType para capturar información sobre cómo el sistema usa la columna, por ejemplo, agrupamiento en clústeres o partición. Se admiten los siguientes tipos de uso:

    • 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.
    • COMMIT_TIMESTAMP: Solo puedes anotar una columna en cada tabla de destino con este tipo de uso. Usa este usageType a fin de identificar una columna de marca de tiempo de actualización para actualizaciones incrementales. Esta columna se usa para extraer filas creadas o actualizadas desde la última ejecución de la transferencia. Solo puedes usar este tipo de uso con una columna que tenga un tipo de datos TIMESTAMP o DATE.
    • DEFAULT: Puedes anotar varias columnas en una tabla 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.
    • 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 tablas que la contiene. Solo puedes usar este tipo de uso con una columna que tenga 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, según este ejemplo, o puedes hacer que el agente de migración genere uno cuando inicialices el agente.

Ejemplo

Considera que migras 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 migras a BigQuery, supongamos que deseas 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 esquema personalizado para establecer esta configuración es el siguiente:


{
  "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.

Operación de Teradata Tipo Asistencia de Teradata a BigQuery
CREATE DDL Se crea una instantánea completa nueva para la tabla en BigQuery.
DROP DDL No compatible
ALTER (RENAME) DDL Se crea una instantánea completa nueva para la tabla con el nuevo nombre en BigQuery. La instantánea anterior no se borra de BigQuery. El usuario no recibe ninguna notificación sobre la tabla con el nombre cambiado.
INSERT DML Se agregarán filas nuevas a la tabla de BigQuery.
UPDATE DML Las filas se agregan a la tabla de BigQuery como nuevas, de manera similar a una operación INSERT si solo se usa COMMIT_TIMESTAMP. Las filas se actualizan, de forma similar a una operación UPDATE, si se usan COMMIT_TIMESTAMP y PRIMARY_KEY.
MERGE DML No compatible. En su lugar, consulta INSERT, UPDATE y DELETE.
DELETE DML No compatible

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 EU.
  • Si tu conjunto de datos está en una 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 transferidos los datos a BigQuery, se les aplican los precios estándar de BigQuery para el almacenamiento y las consultas.
  • Consulta la página de precios de transferencias para obtener más detalles.

Limitaciones

  • Las transferencias a pedido únicas son totalmente compatibles. Las transferencias incrementales se encuentran en versiónBeta. 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?