Migra Teradata a BigQuery: descripción general de la traducción de consultas

Última actualización: septiembre de 2020
Notas de la versión

Este documento es parte de una serie en la que se analiza la migración de tu esquema y datos de Teradata a BigQuery. En este documento, se proporciona una descripción general de la traducción de las instrucciones de SQL escritas para que Teradata sea compatible con BigQuery.

La serie que analiza los aspectos específicos de la transición de Teradata consta de las partes siguientes:

Para obtener una descripción general de la transición desde un almacén de datos local hacia BigQuery en Google Cloud, consulta la serie que comienza con Migra almacenes de datos a BigQuery: introducción y descripción general.

Introducción

BigQuery y Teradata Database cumplen con el estándar ANSI/ISO SQL 2011. Además, Teradata ha creado algunas extensiones del estándar del lenguaje SQL para habilitar las funciones específicas de Teradata.

En cambio, BigQuery no admite estas extensiones registradas. Por lo tanto, es posible que sea necesario volver a factorizar algunas de las consultas durante la migración de Teradata a BigQuery. La disponibilidad de consultas que solo usan el estándar ANSI/ISO SQL (compatible con BigQuery) tiene el beneficio adicional de que ayuda a garantizar la portabilidad y permite que tus consultas sean independientes del almacén de datos subyacente.

En este documento, se abordan algunos de los desafíos que puedes encontrar durante la migración de consultas de SQL desde Teradata hasta BigQuery. Explica cuándo se deben aplicar estas traducciones en el contexto de una migración por etapas de extremo a extremo.

Diferencias del lenguaje SQL de Teradata

En esta sección, se analizan brevemente las diferencias notables entre el lenguaje SQL de Teradata y el lenguaje SQL estándar de BigQuery, y algunas estrategias para traducir entre los dos dialectos. La lista de diferencias que se presentan en este documento no es exhaustiva. Para obtener más información, consulta referencia de traducción de SQL de Teradata a BigQuery.

Lenguaje de definición de datos

El lenguaje de definición de datos (DDL) se usa para definir el esquema de tu base de datos. Incluye un subconjunto de instrucciones de SQL, como CREATE, ALTER y DROP.

En su mayor parte, estas instrucciones son equivalentes entre el SQL de Teradata y el SQL estándar. A continuación, te presentamos una lista no exhaustiva de excepciones notables:

  • Las opciones de manipulación de índices, como CREATE INDEX y PRIMARY INDEX, no son compatibles con BigQuery. BigQuery no usa índices cuando consulta tus datos. Produce resultados rápidos gracias a su modelo subyacente mediante Dremel, sus técnicas de almacenamiento mediante Capacitor y su arquitectura con un paralelismo masivo.
  • Restricciones: Son verificaciones que se aplican a columnas individuales o a una tabla completa. BigQuery solo admite restricciones NOT NULL.
  • MULTISET: Se usa para permitir filas duplicadas en Teradata.
  • CASESPECIFIC: Especifica las mayúsculas y minúsculas para las intercalaciones y comparaciones de datos de caracteres.

Tipos de datos

BigQuery admite un conjunto de tipos de datos más conciso que Teradata, con grupos de tipos de Teradata que se asignan a un único tipo de datos SQL estándar. Por ejemplo:

  • INTEGER, SMALLINT, BYTEINT y BIGINT se asignan a INT64.
  • CLOB, JSON, XML, UDT y otros tipos que contienen campos de caracteres grandes se asignan a STRING.
  • Los tipos BLOB, BYTE y VARBYTE que contienen información binaria se asignan a BYTES.

Para las fechas, los tipos principales (DATE, TIME y TIMESTAMP) son equivalentes en Teradata y BigQuery. Sin embargo, es necesario asignar otros tipos de fechas especializadas de Teradata, como se muestra a continuación:

  • TIME_WITH_TIME_ZONE se asigna a TIME.
  • TIMESTAMP_WITH_TIME_ZONE se asigna a TIMESTAMP.
  • INTERVAL_HOUR, INTERVAL_MINUTE y otros tipos de INTERVAL_* se asignan a INT64 en BigQuery.
  • PERIOD(DATE), PERIOD(TIME) y otros tipos de PERIOD(*) se asignan a STRING.

Los arreglos multidimensionales no son compatibles directamente con BigQuery. En su lugar, debes crear un arreglo de estructuras, en el que cada estructura contenga un campo de tipo ARRAY.

Declaración SELECT

La sintaxis de la instrucción SELECT suele ser compatible entre Teradata y BigQuery. En esta sección, se señalan las diferencias que, a menudo, deben abordarse durante la migración.

Identificadores

BigQuery te permite usar los siguientes identificadores: proyectos; conjunto de datos; tablas o vistas; columnas.

Como producto sin servidores, BigQuery no tiene un concepto de un clúster o entorno o extremo fijo, por lo que el proyecto especifica la jerarquía de recursos del conjunto de datos.

En una declaración SELECT en Teradata, se pueden usar nombres de columnas completamente calificados. BigQuery siempre hace referencia a nombres de columnas de tablas o alias, y nunca a nombres de columnas de proyectos o conjuntos de datos.

Por ejemplo, estas son algunas opciones para abordar los identificadores en BigQuery.

Columnas inferidas de forma implícita de la tabla:

SELECT
 c
FROM
 project.dataset.table

También puedes usar una referencia de tabla explícita:

SELECT
 table.c
FROM
 project.dataset.table

O bien, mediante un alias de tabla explícito:

SELECT
 t.c
FROM
 project.dataset.table t
Referencias de alias

En una declaración SELECT en Teradata, se pueden definir los alias y hacer referencia a ellos dentro de la misma consulta. Por ejemplo, en el siguiente fragmento, flag se define como un alias de columna y, luego, se hace referencia a él enseguida en la declaración CASE adjunta.

SELECT
 F AS flag,
 CASE WHEN flag = 1 THEN ...

En el SQL estándar, las referencias entre columnas dentro de la misma consulta no están permitidas. Para realizar la traducción, mueve la lógica a una consulta anidada de la siguiente manera:

SELECT
 q.*,
 CASE WHEN q.flag = 1 THEN ...
FROM (
 SELECT
   F AS flag,
   ...
) AS q

El marcador de posición de muestra F podría ser una consulta anidada que muestra una sola columna.

Filtra con LIKE

En Teradata, el operador LIKE ANY se usa para filtrar los resultados en un conjunto determinado de opciones posibles. Por ejemplo:

SELECT*
FROM t1
WHERE a LIKE ANY ('string1', 'string2')

Para traducir las instrucciones que tienen este operador al lenguaje SQL estándar, puedes dividir la lista después de ANY en varios predicados OR de la siguiente manera:

SELECT*
FROM t1
WHERE a LIKE 'string1' OR a LIKE 'string2'
Cláusula QUALIFY

La cláusula QUALIFY de Teradata es una cláusula condicional en la declaración SELECT que filtra los resultados de una función analítica ya ordenada y procesada según las condiciones de búsqueda especificadas por el usuario. Su sintaxis consta de la cláusula QUALIFY seguida de la función analítica, como ROW_NUMBER o RANK, y los siguientes valores que deseas encontrar:

SELECT a, b
FROM t1
QUALIFY ROW_NUMBER() OVER (PARTITION BY a ORDER BY b) = 1

Los clientes de Teradata suelen usar esta función como una forma abreviada de clasificar y mostrar resultados sin necesidad de una subconsulta adicional.

La cláusula QUALIFY se traduce a BigQuery mediante la adición de una condición WHERE a una consulta envolvente siguiente:

SELECT a, b
FROM (
 SELECT a, b,
 ROW_NUMBER() OVER (PARTITION BY A ORDER BY B) row_num
 FROM t1
) WHERE row_num = 1

Para ver un ejemplo, consulta la guía de inicio rápido asociada.

Lenguaje de manipulación de datos

El lenguaje de manipulación de datos (DML) se usa para mostrar, agregar, borrar y modificar datos en una base de datos. Incluye las declaraciones SELECT, INSERT, DELETE y UPDATE.

Si bien las formas básicas de estas declaraciones son las mismas entre el SQL de Teradata y el SQL estándar, Teradata incluye cláusulas adicionales no estándar y construcciones de declaraciones especiales que necesitas convertir cuando realizas la migración. En las secciones siguientes, se presentan una lista no exhaustiva de las instrucciones más comunes, las diferencias principales y las traducciones recomendadas.

Declaración INSERT

BigQuery es un almacén de datos empresarial que se centra en el procesamiento analítico en línea (OLAP). El uso de declaraciones DML para un punto específico, como la ejecución de una secuencia de comandos con muchas declaraciones INSERT, es un intento de tratar a BigQuery como un sistema de procesamiento de transacciones en línea (OLTP), que no es un enfoque correcto.

Las declaraciones DML de BigQuery están diseñadas para actualizaciones masivas, por lo tanto, cada declaración DML que modifica datos inicia una transacción implícita. Debes agrupar tus declaraciones DML siempre que sea posible para evitar sobrecargas de transacciones innecesarias.

A modo de ejemplo, si tienes el siguiente conjunto de declaraciones de Teradata, ejecutarlas como están en BigQuery es un antipatrón:

INSERT INTO t1 (...) VALUES (...);
INSERT INTO t1 (...) VALUES (...);

Puedes traducir la secuencia de comandos anterior en una sola declaración INSERT que, en su lugar, realiza una operación masiva, como se muestra a continuación:

INSERT INTO t1 VALUES (...), (...)

Una situación típica en la que se usa una gran cantidad de declaraciones INSERT es cuando creas una tabla nueva a partir de una tabla existente. En BigQuery, en lugar de usar varias declaraciones INSERT, crea una tabla nueva y, luego, inserta todas las filas en una operación mediante la declaración CREATE TABLE ... AS SELECT.

Declaración UPDATE

Las instrucciones UPDATE en Teradata son similares a las instrucciones UPDATE en SQL estándar. Las diferencias importantes son las siguientes:

  • Se revierte el orden de las cláusulas SET y FROM.
  • Se deben quitar todos los nombres de correlación de Teradata que se usen como alias de tabla en UPDATE.
  • En SQL estándar, cada instrucción UPDATE debe incluir la palabra clave WHERE, seguida de una condición. Para actualizar todas las filas de la tabla, usa WHERE true.

En el siguiente ejemplo, se muestra una declaración UPDATE de Teradata que usa uniones:

UPDATE t1
FROM t1, t2
SET
 b = t2.b
WHERE a = t2.a;

La instrucción equivalente en SQL estándar es la que se indica a continuación:

UPDATE t1
SET
 b = t2.b
FROM t2
WHERE a = t2.a;

Las consideraciones de la sección anterior sobre la ejecución de grandes cantidades de declaraciones DML en BigQuery también se aplican en este caso. Recomendamos usar una sola declaración MERGE en lugar de varias declaraciones UPDATE.

Declaración DELETE

El SQL estándar requiere que las instrucciones DELETE tengan una cláusula WHERE En Teradata, las cláusulas WHERE son opcionales en las declaraciones DELETE si borras todas las filas de una tabla. (si borras filas específicas, el DML de Teradata también requiere una cláusula WHERE). Durante la traducción, cualquier cláusula WHERE faltante debe agregarse a las secuencias de comandos. Este cambio es necesario solo cuando se borran todas las filas de una tabla.

Por ejemplo, la instrucción siguiente en lenguaje SQL de Teradata borra todas las filas de una tabla. La cláusula ALL es opcional:

DELETE t1 ALL;

La traducción al lenguaje SQL estándar es como se indica a continuación:

DELETE FROM t1 WHERE TRUE;

Procedimientos almacenados

Los procedimientos almacenados en Teradata son una combinación de instrucciones de SQL y de control. Los procedimientos almacenados pueden tomar parámetros que te permiten compilar una interfaz personalizada para Teradata Database.

Los procedimientos almacenados son compatibles con el scripting de BigQuery.

Sin embargo, hay algunos casos en los que otras funciones podrían ser más apropiadas. Estas alternativas dependen de cómo se usen los procedimientos almacenados. Por ejemplo:

  • Reemplaza los activadores que se usan para ejecutar consultas periódicas por consultas programadas.
  • Reemplaza los procedimientos almacenados que controlan la ejecución compleja de las consultas y sus interdependencias por flujos de trabajo definidos en Cloud Composer.
  • Vuelve a factorizar los procedimientos almacenados que se usan como una API en el almacén de datos mediante consultas con parámetros y la API de BigQuery. Este cambio implica que debes volver a compilar la lógica del procedimiento almacenado en un lenguaje de programación diferente como Java o Go y que, luego, debes llamar a las consultas de SQL con parámetros del código.

La refactorización y el reemplazo de la lógica empresarial que reside en los procedimientos almacenados es una tarea delicada que requiere experiencia tanto en tu capa de datos como en las prácticas recomendadas de arquitectura para la plataforma de destino. Según la complejidad de tu migración, puedes optar por contratar los servicios de nuestros socios especializados.

Traduce durante la migración

Como parte de tu migración, debes examinar las instrucciones de SQL y las secuencias de comandos de Teradata y determinar si necesitas traducir las instrucciones de SQL de Teradata al lenguaje SQL estándar como se usan en BigQuery. Al igual que con la recomendación general para el uso de la migración iterativa, te recomendamos abordar esta tarea de manera sistemática.

Elige un caso práctico

Anteriormente, definimos un caso práctico como todos los conjuntos de datos, el procesamiento de datos y las interacciones del sistema y del usuario requeridos para lograr el valor empresarial. Un caso práctico incluye un grupo de tablas en el almacén de datos, los procesos ascendentes que suministran datos a esas tablas y los procesos descendentes que los consumen de estas, como se muestra en el diagrama siguiente:

Flujo de casos prácticos ascendentes (locales) al almacén de datos heredado y a los procesos descendentes.

Algunos ejemplos de procesos ascendentes, también llamados canalizaciones de datos ascendentes, son los feeds de data lakes, los sistemas OLTP, una CRM y las aplicaciones de registro. Algunos ejemplos de procesos descendentes son los paneles, los informes, los feeds de otros sistemas, las aplicaciones empresariales y las consultas ad hoc que usan los analistas.

Cuando elijas casos prácticos para la migración, elige aquellos casos en los que la parte dominante de los procesos descendentes sean informes internos o resultados de datos bien definidos, como feeds o API. La elección de estos tipos de casos prácticos en las iteraciones de migración iniciales tiene, entre otros, los beneficios siguientes:

  • Ayudan a que tu personal se familiarice con las traducciones obligatorias, de modo que puedas estimar el esfuerzo requerido para las iteraciones posteriores.
  • Facilitan la configuración de pruebas automatizadas para la exactitud de los datos, ya que sus resultados se pueden comparar mediante secuencias de comandos.
  • Permiten comparaciones visuales sobre la marcha, que son más fáciles de presentar a las partes interesadas no técnicas que los resultados de datos sin procesar.

Pasos de la traducción

Para migrar un caso práctico de Teradata a BigQuery, sigue las recomendaciones del documento sobre descripción general de transferencia de datos y esquemas. Cada vez que muevas una tabla a BigQuery y cuando sea necesario modificar los procesos descendentes o ascendentes, también debes realizar una evaluación de las consultas y los procedimientos almacenados que están involucrados en el cambio para determinar si debes traducir esos procedimientos y consultas.

Si las traducciones son necesarias, sigue los lineamientos en la sección Diferencias del SQL de Teradata y en la referencia de traducción del SQL de Teradata a BigQuery para crear consultas nuevas mediante el SQL estándar que cumpla a la norma ISO SQL 2011.

Con las consultas traducidas, prueba el proceso descendente o ascendente en un entorno controlado, de acuerdo con las prácticas recomendadas de tu empresa para realizar implementaciones continuas y pruebas. También puedes consultar cómo crear canalizaciones de lanzamiento de software en Google Cloud.

Te recomendamos que crees recursos diferentes para ayudar con la traducción, a partir de las primeras iteraciones de la migración de tu almacén de datos. Por ejemplo, considera el desarrollo de bibliotecas de software que implementen traducciones de consultas comunes siempre que sea posible y que se adapten a tus casos prácticos. Estas bibliotecas facilitarán las iteraciones posteriores. También puedes usar estas bibliotecas junto con las guías de documentación a fin de entrenar a tu personal sobre cómo acostumbrarse al lenguaje SQL estándar y comprender las mejores opciones que se pueden usar en BigQuery para la sintaxis de Teradata que no se usa en BigQuery.

Pasos siguientes