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

En este documento se proporciona más información para ayudarte a tomar las decisiones que debes tomar al usar BigQuery Data Transfer Service para migrar el esquema y los datos de Teradata a BigQuery. Para obtener una introducción al proceso de migración de Teradata, consulta el artículo Introducción a la migración de Teradata a BigQuery.

La migración de esquemas y datos suele ser uno de los pasos necesarios para mover un almacén de datos de otra plataforma a BigQuery. Para obtener una descripción del proceso de migración general, consulta Información general sobre la migración de almacenes de datos a BigQuery.

También puedes usar la traducción de SQL por lotes para migrar tus secuencias de comandos SQL en bloque o la traducción de SQL interactiva para traducir consultas específicas. Los servicios de traducción de SQL admiten totalmente SQL de Teradata.

Información general

Puedes usar BigQuery Data Transfer Service junto con un agente de migración especial para copiar tu esquema y tus datos de Teradata a BigQuery. El agente de migración se conecta a tu almacén de datos local y se comunica con BigQuery Data Transfer Service para copiar las tablas de tu almacén de datos a BigQuery.

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

  1. Descarga el agente de migración.
  2. Configura una transferencia en BigQuery Data Transfer Service.
  3. Ejecuta la tarea de transferencia para copiar el esquema y los datos de la tabla de tu almacén de datos en BigQuery.
  4. Opcional. Monitoriza las tareas de transferencia con la Google Cloud consola.

Configuración de tarea 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, consulta las opciones de configuración que se describen en las siguientes secciones y decide qué ajustes quieres usar. En función de los ajustes que elijas, es posible que tengas que completar algunos requisitos previos antes de iniciar el trabajo de transferencia.

En la mayoría de los sistemas, sobre todo en los que tienen tablas grandes, puedes conseguir el mejor rendimiento posible siguiendo estos pasos:

  1. Crea particiones en tus tablas de Teradata.
  2. Usa Teradata Parallel Transporter (TPT) para la extracción.
  3. Crea un archivo de esquema personalizado y configura las columnas de clustering y partición de BigQuery de destino.

De esta forma, el agente de migración puede realizar la extracción por particiones, que es la más eficiente.

Método de extracción

BigQuery Data Transfer Service admite dos métodos de extracción para transferir datos de Teradata a BigQuery:

  • Usa la utilidad Teradata Parallel Transporter (TPT) tbuild. Este es el enfoque recomendado. TPT suele dar como resultado una extracción de datos más rápida.

    En este modo, el agente de migración intenta calcular los lotes de extracción mediante filas distribuidas por particiones. En cada lote, el agente emite y ejecuta una secuencia de comandos de extracción de TPT, lo que genera un conjunto de archivos delimitados por barras verticales. A continuación, sube estos archivos a un segmento de Cloud Storage, donde la tarea de transferencia los utiliza. Una vez que los archivos se hayan subido a Cloud Storage, el agente de migración los eliminará del sistema de archivos local.

    Si usas la extracción de TPT sin una columna de partición, se extraerá 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 ocupan los archivos extraídos en el sistema de archivos local. Asegúrate de que el sistema de archivos local tenga más espacio que el tamaño de la partición o la tabla más grandes, en función 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 no puedes usar TPT por algún motivo, utiliza este método de extracción.

    En este modo, el agente de migración extrae las tablas en una colección de archivos AVRO en el sistema de archivos local. A continuación, sube estos archivos a un segmento de Cloud Storage, donde la tarea de transferencia los utiliza. Una vez que los archivos se han subido a Cloud Storage, el agente de migración los elimina del sistema de archivos local.

    En este modo, puedes limitar la cantidad de espacio que ocupan los archivos AVRO en el sistema de archivos local. Si se supera este límite, la extracción se pausará hasta que el agente de migración libere espacio subiendo y eliminando los archivos AVRO.

Identificación de esquemas

Puedes definir el esquema de varias formas. BigQuery Data Transfer Service proporciona detección automática de esquemas y asignación de tipos de datos durante la transferencia de datos de Teradata a BigQuery. También puede usar el motor de traducción para obtener la asignación de tipos de datos o especificar un archivo de esquema personalizado.

Detección de esquemas predeterminada

Si no especificas ninguna configuración de esquema, BigQuery Data Transfer Service detectará automáticamente el esquema de tus tablas de origen de Teradata y asignará los 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.

Usar la salida del motor de traducción para el esquema

BigQuery Data Transfer Service usa la salida del motor de traducción de BigQuery para asignar el esquema durante la migración de tablas de Teradata a BigQuery. Para usar esta opción, asegúrate de que se cumplen los siguientes requisitos:

  1. Generar metadatos para la traducción. Ejecuta la herramienta de volcado para generar metadatos para la traducción, siguiendo las directrices de la fuente de Teradata. Para obtener más información, consulta Generar metadatos para la traducción y la evaluación.
  2. Sube el archivo de metadatos generado (por ejemplo, metadata.zip) a un segmento de Cloud Storage. Este contenedor sirve como ubicación de entrada para el motor de traducción.

  3. Inicia una tarea de traducción por lotes para crear la asignación de BigQuery Data Transfer Service, que define el esquema de las tablas de BigQuery de destino. Para obtener información sobre cómo hacerlo, consulta Crear una traducción por lotes. En el siguiente ejemplo se genera la asignación de BigQuery Data Transfer Service especificando target_types = "dts_mapping":

    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

    Puedes consultar el estado del trabajo de traducción por lotes en la Google Cloud consola. Para ello, ve a BigQuery -> Traducción de SQL. Una vez completado el proceso, 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 OAuth 2.0 Playground con el ámbito https://www.googleapis.com/auth/cloud-platform.

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

Archivo de esquema personalizado

Te recomendamos que especifiques un esquema personalizado en las siguientes situaciones:

  • Si necesitas registrar 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 se puedan particionar correctamente cuando se carguen en BigQuery. Si no hay ningún archivo de esquema, cada vez que se ejecute una transferencia, BigQuery Data Transfer Service aplicará automáticamente un esquema de tabla mediante los datos de origen que se transfieran, y se perderá toda la información sobre las particiones, los clústeres, las claves principales 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 contiene un conjunto de tablas, y cada tabla 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 de la columna en BigQuery.

  • usageType: información sobre la forma en que el sistema usa la columna. Se admiten los siguientes tipos de uso:

    • DEFAULT: puede anotar varias columnas de una tabla de destino con este tipo de uso. Este usageType indica que la columna no tiene ningún 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 la agrupación se determina en función del orden en el que aparecen en el esquema personalizado. Las columnas que selecciones deben cumplir las restricciones de la creación de clústeres en BigQuery. Si se especifica un campo PARTITIONING para la misma tabla, BigQuery usa estas columnas para crear una tabla agrupada en clústeres.
    • PARTITIONING: Solo puedes anotar una columna en cada tabla de destino con este tipo de uso. Esta columna se usa en la definición de tabla partitioned del objeto tables que la contiene. Solo puede usar este tipo de uso con columnas que tengan el tipo de datos TIMESTAMP o DATE.
    • COMMIT_TIMESTAMP: solo puede anotar una columna en cada tabla de destino con este tipo de uso. Use este usageType para identificar una columna de marca de tiempo de actualización para las actualizaciones incrementales. Esta columna se usa para extraer las filas que se han creado o actualizado desde la última ejecución de la transferencia. Solo puedes usar este tipo de uso con columnas que tengan el tipo de datos TIMESTAMP o DATE.
    • PRIMARY_KEY: puede anotar columnas en cada tabla de destino con este tipo de uso. Usa este tipo de uso para identificar solo una columna como clave principal 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 funcionan junto con COMMIT_TIMESTAMP para extraer las filas creadas o actualizadas desde la última ejecución de la transferencia.

Puedes crear un archivo de esquema personalizado manualmente, como se muestra en el siguiente ejemplo, o hacer que el agente de migración genere uno cuando inicialices el agente.

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

Durante la migración 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 columna de partición

En el siguiente ejemplo se muestra un esquema personalizado para configurar estos ajustes:


{
  "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 bajo demanda o incrementales

Al migrar datos de una instancia de base de datos de Teradata a BigQuery, BigQuery Data Transfer Service admite tanto transferencias completas (transferencia bajo demanda) como transferencias periódicas (transferencias incrementales). Puedes designar la transferencia como bajo demanda o incremental en las opciones de programación al configurar una transferencia.

  • Transferencia bajo demanda: usa este modo para realizar la migración completa de la instantánea del esquema y los datos de Teradata a BigQuery.

  • Transferencia programada: usa este modo para hacer una copia completa y migrar periódicamente los datos nuevos y modificados (datos incrementales) de Teradata a BigQuery. Para hacer transferencias incrementales, debe personalizar su esquema para anotar columnas con uno de los siguientes casos prácticos:

    • Anota las columnas con el tipo de uso COMMIT_TIMESTAMP: en esta transferencia, las filas nuevas o modificadas de Teradata se añaden a los datos de BigQuery. Las filas actualizadas de 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 añaden filas nuevas y se actualizan las filas modificadas a la fila correspondiente en BigQuery. La columna definida en PRIMARY_KEY se usa para mantener la singularidad de los datos en BigQuery.
    • La columna PRIMARY_KEY definida en el esquema no tiene por qué ser la PRIMARY_KEY de 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 la tabla en BigQuery. Todas las transferencias incrementales posteriores se ajustarán a las anotaciones definidas en el archivo de esquema personalizado que se explica a continuación.

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

En 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 de un archivo de esquema no tiene una columna con el tipo de uso COMMIT_TIMESTAMP, se omitirá la tabla.
  • Si una tabla tiene una columna con el tipo de uso COMMIT_TIMESTAMP, se extraerán todas las filas con una marca de tiempo entre T1 y T2, y se añadirán a la tabla de BigQuery.
  • Si una tabla tiene una columna con el tipo de uso COMMIT_TIMESTAMP y otra con el tipo de uso PRIMARY_KEY, se extraerán todas las filas con una marca de tiempo entre T1 y T2. Las filas nuevas se añaden y las filas modificadas se actualizan en la tabla de BigQuery.

A continuación, se muestran ejemplos de archivos de esquema 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 gestiona el agente de migración las operaciones del lenguaje de definición de datos (DDL) y del lenguaje de manipulación de datos (DML) en las transferencias incrementales.

Operación de Teradata Tipo Compatibilidad con la migración de Teradata a BigQuery
CREATE DDL Se crea una nueva instantánea completa de la tabla en BigQuery.
DROP DDL No compatible
ALTER (RENAME) DDL Se crea una nueva copia completa de la tabla con el nombre cambiado en BigQuery. La instantánea anterior no se elimina de BigQuery}. El usuario no recibe ninguna notificación sobre el cambio de nombre de la tabla.
INSERT DML Se añaden filas a la tabla de BigQuery.
UPDATE DML Las filas se añaden a la tabla de BigQuery como nuevas, de forma 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 es compatible. Consulta INSERT, UPDATE y DELETE.
DELETE DML No compatible

Consideraciones de ubicación

El segmento de Cloud Storage debe estar en una región o multirregión que sea 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 segmento de Cloud Storage que contenga los datos que vas a transferir debe estar en la misma multirregión o en una ubicación que esté incluida en la multirregión. Por ejemplo, si tu conjunto de datos de BigQuery está en la multirregión EU, el segmento de Cloud Storage puede estar en la región europe-west1 de Bélgica, que está en la UE.
  • Si tu conjunto de datos está en una sola región, tu segmento 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 segmento de Cloud Storage no puede estar en la multirregión ASIA.

Para obtener información detallada sobre las transferencias y las regiones, consulta el artículo Ubicaciones y transferencias de conjuntos de datos.

Precios

La transferencia de datos con BigQuery es gratuita. Sin embargo, es posible que se apliquen cargos adicionales fuera de Google por utilizar este servicio (por ejemplo, cargos de transferencia de datos salientes de la plataforma).

  • Extraer datos, subirlos a un segmento de Cloud Storage o cargarlos en BigQuery es gratuito.
  • Los datos no se eliminan automáticamente del segmento de Cloud Storage cuando los subes a BigQuery. Si quieres ahorrarte costes adicionales, elimina los datos del segmento de Cloud Storage. Consulta los precios de Cloud Storage.
  • Se aplican las cuotas y los límites estándar de BigQuery en las tareas de carga.
  • Se aplicarán las cuotas y los límites estándar de DML de BigQuery en las inserciones y actualizaciones incrementales.
  • Cuando se transfieren los datos a BigQuery, se aplica el precio estándar de este servicio para el almacenamiento y el cálculo.
  • Consulta nuestra página de precios para obtener más información.

Limitaciones

  • Se admiten las transferencias únicas y bajo demanda. Las operaciones DDL/DML en transferencias incrementales se admiten parcialmente.
  • 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 se usa el modo FastExport de extracción, se puede definir el espacio de almacenamiento máximo que se va a usar y el agente de migración aplica el límite de forma estricta. Define el ajuste max-local-storage en el archivo de configuración del agente de migración cuando configures una transferencia de Teradata a BigQuery.
    • Cuando utilice el método de extracción de TPT, asegúrese de que el sistema de archivos tenga suficiente espacio libre (más que la partición de tabla más grande de la instancia de Teradata).
  • BigQuery Data Transfer Service convierte el esquema automáticamente (si no proporcionas un archivo de esquema personalizado) y transfiere los datos de Teradata a BigQuery. Los datos se asignan de los tipos de Teradata a los de BigQuery.
  • Los archivos no se eliminan automáticamente del segmento de Cloud Storage cuando los cargas en BigQuery. Si quieres ahorrarte costes adicionales, elimina los datos del segmento de Cloud Storage después de cargarlos en BigQuery. Consulta Precios.
  • La velocidad de la extracción está limitada por tu conexión JDBC.
  • Los datos extraídos de Teradata no están cifrados. Toma las medidas adecuadas para restringir el acceso a los archivos extraídos en el sistema de archivos local y asegúrate de que el segmento de Cloud Storage esté protegido correctamente.
  • Otros recursos de la base de datos, como los procedimientos almacenados, las consultas guardadas, las vistas y las funciones definidas por el usuario, no se transfieren y no están incluidos en el ámbito de este servicio.
  • Las transferencias incrementales no admiten eliminaciones definitivas. Las transferencias incrementales no sincronizan las filas eliminadas de Teradata con BigQuery.

Siguientes pasos