Detalles y opciones de la migración de Teradata

En este documento, se describen más detalles, opciones y funciones Beta cuando se usa el Servicio de transferencia de datos de BigQuery para migrar datos de Teradata a BigQuery.

Archivo de esquema personalizado

Realiza transformaciones con un archivo de esquema

Como parte de la migración, puedes especificar un archivo de esquema personalizado para cambiar los campos name de cualquier objeto y agregar el arreglo usageType a cualquier columna. Esto es especialmente útil para incluir información adicional sobre una tabla (como las particiones) que, si no se especificara ningún archivo de esquema, se perdería en la migración.

Se admiten los siguientes tipos de uso:

  • PARTITIONING: Solo se puede anotar una columna por tabla con este usageType. El campo de tipo de una columna debe ser DATE o TIMESTAMP. Esta columna se usará para la definición de tabla particionada con el objeto tablas.
  • CLUSTERING: Varias columnas de una tabla se pueden anotar con este usageType. 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. Los tipos de columna deben seguir las restricciones para el agrupamiento en clústeres en BigQuery. Si se especifica un campo PARTITIONING para la misma tabla, BigQuery usará estas columnas a fin de crear una tabla agrupada. Solo las columnas con los tipos INT64, STRING, DATE, TIMESTAMP, BOOL, NUMERIC o BIGNUMERIC se pueden marcar con este usageType.
  • COMMIT_TIMESTAMP: Solo se puede anotar una columna por tabla con este usageType. Usa este usageType para anotar una columna de marca de tiempo de actualización. Esta columna se usará para extraer filas creadas o actualizadas desde la última ejecución de la transferencia. Debe tener un tipo TIMESTAMP o DATE.

Archivo de esquema personalizado de 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.
  • Configura la transferencia incremental mediante la columna O_ORDERDATE.

El esquema personalizado para establecer esta configuración es el siguiente:


{
  "databases": [
    {
      "name": "tpch",
      "originalName": "tpch",
      "tables": [
        {
          "name": "orders",
          "originalName": "orders",
          "columns": [
            {
              "name": "O_ORDERKEY",
              "originalName": "O_ORDERKEY",
              "type": "INT64",
              "originalType": "integer",
              "usageType": [
                "DEFAULT"
              ]
            },
            {
              "name": "O_CUSTOMERKEY",
              "originalName": "O_CUSTKEY",
              "type": "INT64",
              "originalType": "integer",
              "usageType": [
                "DEFAULT"
              ]
            },
            {
              "name": "O_ORDERSTATUS",
              "originalName": "O_ORDERSTATUS",
              "type": "STRING",
              "originalType": "character",
              "usageType": [
                "DEFAULT"
              ]
            },
            {
              "name": "O_TOTALPRICE",
              "originalName": "O_TOTALPRICE",
              "type": "NUMERIC",
              "originalType": "decimal",
              "usageType": [
                "DEFAULT"
              ]
            },
            {
              "name": "O_ORDERDATE",
              "originalName": "O_ORDERDATE",
              "type": "DATE",
              "originalType": "date",
              "usageType": [
                "COMMIT_TIMESTAMP"
              ]
            },
            {
              "name": "O_ORDERPRIORITY",
              "originalName": "O_ORDERPRIORITY",
              "type": "STRING",
              "originalType": "character",
              "usageType": [
                "DEFAULT"
              ]
            },
            {
              "name": "O_CLERK",
              "originalName": "O_CLERK",
              "type": "STRING",
              "originalType": "character",
              "usageType": [
                "DEFAULT"
              ]
            },
            {
              "name": "O_SHIPPRIORITY",
              "originalName": "O_SHIPPRIORITY",
              "type": "INT64",
              "originalType": "integer",
              "usageType": [
                "DEFAULT"
              ]
            },
            {
              "name": "O_COMMENT",
              "originalName": "O_COMMENT",
              "type": "STRING",
              "originalType": "varchar",
              "usageType": [
                "DEFAULT"
              ]
            }
          ]
        }
      ]
    }
  ]
}

Los siguientes campos se usan para asignar nombres de objetos de Teradata a nombres de objetos de BigQuery:

  • El campo originalName especifica el nombre del objeto Teradata.
  • El campo name especifica el nombre del objeto de BigQuery.

Los siguientes campos se usan para asignar tipos de datos de Teradata a tipos de datos de BigQuery. Por ejemplo, es posible que desees asignar una fecha a STRING o una marca de tiempo a DATETIME:

  • El campo originalType especifica el tipo de datos de la columna Teradata.
  • El campo type especifica el tipo de datos de la columna de BigQuery.

Para obtener más información sobre cómo se particionan o agrupan las tablas en una transferencia, consulta la sección sobre transferencias incrementales.

Asignación de tipos de datos de Teradata a BigQuery

Tipo de Teradata Tipo de BigQuery Diferencias entre los tipos
INTEGER INTEGER
SMALLINT INTEGER
BYTEINT INTEGER
BIGINT INTEGER
DECIMAL
NUMERIC
NUMBER
FLOAT
NUMERIC o BIGNUMERIC El tipo NUMERIC de BigQuery tiene 38 dígitos de precisión y 9 dígitos decimales de escala. El tipo BIGNUMERIC (vista previa) de BigQuery tiene más de 76 dígitos de precisión (el dígito 77 es parcial) y exactamente 38 dígitos de escala.
REAL FLOAT64
CHAR STRING
CHARACTER STRING
VARCHAR STRING
CLOB STRING
JSON STRING
BLOB BYTES
BYTE BYTES
VARBYTE BYTES
DATE DATE
TIME
TIMETZ
TIME El TIME de BigQuery está en UTC. El Servicio de transferencia de datos de BigQuery extraerá los valores respectivos en formato UTC.
TIMESTAMP
TIMESTAMPTZ
TIMESTAMP La TIMESTAMP de BigQuery está en UTC. El Servicio de transferencia de datos de BigQuery extraerá los valores respectivos en formato UTC.

La precisión de TIMESTAMP se limita a microsegundos.
ARRAY STRING
MULTIDIMENSIONALARRAY STRING
HORA INTEGER
MINUTO INTEGER
SECOND INTEGER
DÍA INTEGER
MONTH INTEGER
YEAR INTEGER
PERIODDATE STRING
PERIODTIMESTAMPTZ STRING
PERIODTIMESTAMP STRING
PERIODTIME STRING
PERIODTIMETZ STRING
USERDEFINED STRING
XML STRING
ANYTYPE STRING

Transferencias incrementales

El Servicio de transferencia de datos de BigQuery admite transferencias periódicas de filas nuevas y actualizadas ("transferencias incrementales"). Cuando configures una transferencia, puedes designarla como a pedido o de forma incremental en las opciones de programación.

La tabla de origen en Teradata debe tener una columna de seguimiento de cambios con el tipo de datos TIMESTAMP o DATE.

En las transferencias incrementales, la primera transferencia siempre crea una instantánea de tabla en BigQuery. Todas las transferencias posteriores capturarán, transferirán y agregarán datos nuevos y modificados a la tabla existente en BigQuery. Esto significa que, para las filas modificadas, la tabla de BigQuery podría tener filas duplicadas con valores antiguos y nuevos.

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 cada transferencia después de 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 usageType de COMMIT_TIMESTAMP, se omite la tabla.
  • Si una tabla tiene una columna con el usageType de 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.

Operaciones DDL/DML en transferencias incrementales

Operación de Teradata Tipo Asistencia de Teradata a BigQuery
CREAR DDL Si el nombre de la tabla coincide con el patrón determinado, se crea una nueva instantánea completa para la tabla en BigQuery.
DROP DDL No compatible
ALTER (CAMBIAR NOMBRE) DDL Si el nombre de una tabla coincide con un patrón determinado, se crea una instantánea completa 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 que coincida.
ACTUALIZAR DML Las filas no se modifican. Las filas se agregan a la tabla de BigQuery coincidente como nuevas, como un INSERT. Las filas de las transferencias anteriores no se actualizan ni se borran.
UNIR DML No compatible. Ver en su lugar INSERT, UPDATE y DELETE.
BORRAR DML No compatible

¿Qué sigue?