Traductor de SQL por lotes

En este documento, se describe cómo usar el traductor de SQL por lotes en BigQuery para traducir SQL de Teradata a SQL estándar de BigQuery. Este documento está dirigido a usuarios familiarizados con Google Cloud Console.

El traductor de SQL por lotes es parte del servicio de migración de BigQuery. Puedes usarlo para traducir un lote de otros dialectos de SQL a SQL estándar de BigQuery. También puedes traducir lenguajes de programación de SQL, como la consulta básica de Teradata (BTEQ).

Se admiten los siguientes dialectos de SQL:

  • SQL de Teradata
  • Consulta básica de Teradata (BTEQ)

Permisos necesarios

Debes tener los siguientes permisos en el proyecto para habilitar el servicio de migración de BigQuery:

  • resourcemanager.projects.get
  • serviceusage.services.enable
  • serviceusage.services.get

Necesitas los siguientes permisos en el proyecto para acceder y usar el servicio de migración de BigQuery:

  • bigquerymigration.workflows.create
  • bigquerymigration.workflows.get
  • bigquerymigration.workflows.list
  • bigquerymigration.workflows.delete
  • bigquerymigration.subtasks.get
  • bigquerymigration.subtasks.list

    Como alternativa, puedes usar las siguientes funciones para obtener los mismos permisos:

    • bigquerymigration.viewer: Acceso de solo lectura
    • bigquerymigration.editor: Acceso de lectura/escritura.

A fin de acceder a los buckets de Cloud Storage para archivos de entrada y salida, sigue estos pasos:

  • storage.objects.get en el bucket de origen de Cloud Storage.
  • storage.objects.list en el bucket de origen de Cloud Storage.
  • storage.objects.create en el bucket de destino de Cloud Storage.

Puedes tener todos los permisos necesarios de Cloud Storage anteriores de las siguientes funciones:

  • roles/storage.objectAdmin
  • roles/storage.admin

Antes de comenzar

Antes de poder enviar un trabajo de traducción, debes habilitar la API y subir los archivos fuente a Cloud Storage.

Habilita la API de migración

Habilita la API de migración de BigQuery de la siguiente manera:

  1. En Cloud Console, ve a la página API de BigQuery Migration.

    Ir a la API de BigQuery Migration

  2. Haga clic en Habilitar.

Sube archivos de entrada a Cloud Storage

Antes de comenzar un trabajo de traducción, debes subir los archivos de origen con las consultas y las secuencias de comandos que deseas traducir. Para obtener información sobre lo que puede contener un archivo de origen, consulta la sección Formato de archivo de origen. Si deseas obtener información para crear buckets y subir archivos a Cloud Storage, consulta Crea buckets de almacenamiento y Sube objetos.

Traducción de SQL de Teradata

Sigue estos pasos para iniciar una traducción, ver su progreso y, por último, ver los resultados. En estos pasos, se supone que ya subiste archivos de origen a un bucket de Cloud Storage.

Console

  1. En Cloud Console, ve a la página BigQuery.

    Ir a BigQuery

  2. En el panel de navegación, ve a Traducción de SQL.

  3. Haz clic en Iniciar traducción.

  4. Completa el diálogo de configuración de la traducción.

    1. El nombre puede contener letras, números o guiones bajos.
    2. Elige una ubicación para el trabajo de traducción. Para obtener una ejecución más eficiente, elige la misma ubicación que tu bucket de archivos de origen.
    3. Elige SQL de Teradata para el modo de traducción.
  5. Haga clic en Continuar.

  6. Elige una ruta de acceso de origen. Puedes escribir la ruta o usar la opción Explorar. También puedes excluir ciertos archivos en tu bucket si agregas filtros de prefijo.

  7. Haz clic en Continuar para avanzar al paso siguiente.

  8. Elige una ruta de destino. De manera similar a la ruta fuente, puedes escribir la ruta o usar la opción Explorar.

  9. Si realizas traducciones simples, puedes hacer clic en Crear para iniciar el trabajo de traducción. Para obtener información sobre el uso de la configuración opcional, consulta la sección Configuración opcional.

  10. Puedes ver el estado del trabajo en la lista de trabajos de traducción.

    Estado de traducción.

  11. Una vez que se completó la traducción, haz clic en Mostrar detalles para ver los resultados del trabajo de traducción.

API

Llama al método create con un flujo de trabajo definido.

Luego, llama al método start para iniciar el flujo de trabajo de traducción.

Configuración adicional para la traducción de BTEQ

A continuación, se enumeran los campos adicionales que se requieren para la traducción de BTEQ. Las opciones de BTEQ se establecen en la pestaña Configuración de BTEQ después de configurar la ruta de destino.

Campo Obligatorio Descripción
ID de conjunto de datos Obligatorio Este ID del conjunto de datos se usa como el prefijo del conjunto de datos para las tablas a las que se hace referencia en la secuencia de comandos.

Por ejemplo, una declaración de inserción que inserta datos nuevos en table1 se traduce como datasetId.table1.

URI de ruta de acceso predeterminada Obligatorio Si se especifica, esta ruta de acceso se usa como la ruta predeterminada en las declaraciones .IMPORT y .EXPORT.
Reemplazo de ruta No son obligatorios Este campo se puede agregar varias veces. Cuando se agrega, se especifica una ruta de acceso al archivo para cualquier archivo mencionado en la secuencia de comandos de BTEQ. Cuando se traduce, el archivo se reemplaza por la ruta de acceso proporcionada.

Por ejemplo, si proporcionas los siguientes pares de archivo y ruta de acceso:

  • ./file1.csv
  • gs://bucket/folder1/file1*.csv
Luego, todas las menciones de file1.csv se reemplazarán con la ruta de Cloud Storage que se te proporcionó.

Configuración opcional

La configuración en esta pestaña es para la configuración de traducción avanzada.

Campo Descripción
Ruta del esquema Esta es una ruta de Cloud Storage que contiene declaraciones de lenguaje de definición de datos (DDL) para esquemas de tablas. Proporcionar esquemas de tablas puede mejorar los resultados de traducción.
Codificación de archivos

Este campo especifica la codificación para el archivo de entrada. El valor predeterminado es “utf-8”. Las siguientes codificaciones están disponibles:

  • UTF_8
  • ISO_8859_1
  • US_ASCII
  • UTF_16
  • UTF_16LE
  • UTF_16BE

Casos de identificador de SQL de salida

Mayúsculas y minúsculas en los resultados de los nombres de tablas y columnas. La configuración predeterminada conserva las mayúsculas y minúsculas originales. Las siguientes son las opciones para este campo:

  • Predeterminada
  • Conservar el formato original
  • Mayúscula
  • Minúscula

Mapa de tokens especiales Si los archivos de entrada de traducción contienen plantillas de SQL que usan tokens especiales como marcadores de posición, usa esta sección para proporcionar un mapa de los tokens especiales a su tipo de datos.

El siguiente es un ejemplo de par de token especial:

  • Token especial: <b>
  • Tipo de datos: NUMERIC
Con este token, la siguiente instrucción de SQL de Teradata:

select trim(<b>) from x;
se traduce en el siguiente SQL estándar de BigQuery:

SELECT TRIM(CAST(<b> AS STRING)) FROM x;

Explora los archivos de salida

Después de ejecutar la traducción, puedes ver los resultados y errores en la ruta de destino que especificaste. El traductor de SQL por lotes genera los siguientes archivos en la ruta de destino:

  • Archivo traducido
  • Archivos de resumen de errores

Archivos traducidos

Para cada archivo de entrada, se genera el archivo de salida correspondiente en la ruta de destino. El archivo de salida contiene las consultas y los errores traducidos.

Archivo de resumen de errores

El archivo de resumen de errores es un archivo CSV que contiene una tabla de todos los errores que se encuentran durante la traducción. Cada archivo de entrada tiene un archivo de resumen de errores correspondiente. Los archivos de resumen se denominan <source_file_name>_errors.csv.

El siguiente es un ejemplo de un archivo de resumen de errores:

Input_Query Línea, columna Categoría Mensaje Tipo
“selct * de abc” 5,1 SqlParseException Expresión que no es de consulta en contexto ilegal ERROR
“RENAM TBLE DB.table1 a DB.table2;” 1,1 SqlParseException Expresión que no es de consulta en contexto ilegal ERROR

Formato de archivo de origen

Los archivos de origen en tu bucket de Cloud Storage deben ser archivos de secuencia de comandos de SQL o Teradata BTEQ válidos.

Los archivos fuente pueden contener los siguientes elementos:

  • Instrucciones de SQL válidas finalizadas mediante punto y coma en una sola línea o en varias líneas
  • Cada procedimiento almacenado (SP) debe estar en su propio archivo separado de otros SP y otras instrucciones de SQL.
  • Declaraciones BTEQ válidas y solicitudes SQL de varias declaraciones válidas si se elige el modo BTEQ.
  • Comentarios anotados por /*, */, -- o * si se traduce BTEQ.
  • Tokens de marcador de posición especiales que no se pueden aplicar a la traducción. Debes especificar estos tokens en un archivo de configuración. Consulta Configuración opcional para obtener más información.

Los archivos de origen no pueden contener lo siguiente: + Declaraciones BTEQ no compatibles, para obtener más información, consulta Declaraciones BTEQ no compatibles.

Declaraciones BTEQ compatibles

Las siguientes declaraciones son compatibles con las traducciones de BTEQ.

  • .ACTIVITYCOUNT
  • .ERRORCODE
  • .EXIT/.QUIT
  • .EXPORT
  • .GOTO/.LABEL
  • .IF,.ELSEIF, .ELSE, .ENDIF
  • .IMPORT
  • .USING
  • .REPEAT

Declaraciones BTEQ no compatibles

Las siguientes instrucciones no son compatibles.

  • .MAXERROR
  • .NULL
  • .REPEATSTOP
  • .RETRY
  • .RUN

Limitaciones

No se admite la asignación de esquemas

El traductor de SQL no traduce los cambios del esquema entre el almacén de datos de origen y BigQuery. Cualquier referencia a los nombres de columna o de tabla que se cambien en el esquema no se reflejará en las consultas de entrada durante la traducción. Por ejemplo, si una columna llamada “foo” cambia de nombre a “bar” durante la migración, la traducción no actualizará de forma automática las consultas que hacen referencia a “foo” para que hagan referencia a “bar”. Si deseas actualizar estas referencias, realiza un paso de procesamiento posterior para reemplazar esos identificadores de SQL en las consultas de salida traducidas.

¿Qué sigue?