Minimización de los problemas de SQL para las migraciones de Teradata

Este artículo es el quinto de una serie de siete artículos y proporciona instrucciones para migrar de Teradata a Azure Synapse Analytics. Este artículo se centra en los procedimientos recomendados para minimizar los problemas de SQL.

Información general

Características de los entornos de Teradata

En 1984, Teradata lanzó por primera vez su producto de base de datos. Introdujo técnicas de procesamiento paralelo masivo (MPP) para permitir el procesamiento de datos a gran escala con más eficacia que las tecnologías de sistema central que había disponibles en ese momento. Desde entonces, el producto ha evolucionado y su uso es frecuente en grandes instituciones financieras y en empresas de telecomunicaciones y de comercio minorista. La implementación original usaba hardware propietario y se conectaba a sistemas centrales (normalmente, IBM o procesadores compatibles con IBM) por medio de canales.

Aunque anuncios más recientes han incluido la conectividad de red y la disponibilidad de la pila de tecnología de Teradata en la nube (incluido Azure), la mayoría de las instalaciones actuales son locales, por lo que muchos usuarios están considerando migrar algunos o todos sus datos de Teradata a Azure Synapse Analytics para obtener las ventajas de un cambio a un entorno en la nube moderno.

La tecnología de Teradata se usa a menudo para implementar un almacenamiento de datos que admita consultas analíticas complejas en grandes volúmenes de datos con SQL. Los modelos de datos dimensionales (esquemas de estrella o copo de nieve) son comunes, al igual que la implementación de data marts para departamentos individuales.

Esta combinación de modelos de datos dimensionales y SQL simplifica la migración a Azure Synapse, ya que los conceptos básicos y las aptitudes de SQL se pueden transferir. El enfoque recomendado es migrar el modelo de datos existente tal cual para reducir el riesgo y el tiempo necesario. Incluso si la intención final es realizar cambios en el modelo de datos (por ejemplo, pasar a un modelo de almacén de datos), lleve a cabo una migración inicial tal cual y, a continuación, realice los cambios en el entorno en la nube de Azure para aprovechar el rendimiento, la escalabilidad elástica y las ventajas de costos de la plataforma.

Aunque el lenguaje SQL se ha normalizado, algunos proveedores han implementado extensiones propias. En este documento, se explican las posibles diferencias de SQL que puede encontrar al migrar desde un entorno de Teradata heredado y se proporcionan soluciones alternativas.

Uso de una instancia de Teradata en una máquina virtual de Azure como parte de la migración

Aproveche el entorno de Azure al migrar desde un entorno de Teradata local. Azure proporciona almacenamiento en la nube asequible y escalabilidad elástica para crear una instancia de Teradata en una máquina virtual de Azure, coubicada con el entorno de Azure Synapse de destino.

Con este enfoque, se pueden usar utilidades de Teradata estándar, como Teradata Parallel Data Transporter (o herramientas de replicación de datos de terceros, como Attunity Replicate) para mover de forma eficaz el subconjunto de tablas de Teradata que se van a migrar a la instancia de VM y, después, todas las tareas de migración pueden tener lugar en el entorno de Azure. Este enfoque tiene varias ventajas:

• Después de la replicación inicial de los datos, el sistema de origen no se ve afectado por las tareas de migración.

• Las conocidas interfaces, herramientas y utilidades de Teradata están disponibles en el entorno de Azure.

• Una vez en el entorno de Azure, no hay ningún problema potencial con la disponibilidad del ancho de banda de red entre el sistema de origen local y el sistema de destino en la nube.

• Herramientas como Azure Data Factory pueden llamar de manera eficaz a utilidades como Teradata Parallel Transporter para migrar datos de forma rápida y sencilla.

• El proceso de migración se organiza y controla completamente dentro del entorno de Azure.

Uso de Azure Data Factory para implementar una migración controlada por metadatos

Automatice y organice el proceso de migración con las características del entorno de Azure. Este enfoque también minimiza el impacto de la migración en el entorno de Teradata, que es posible que ya esté funcionando casi a plena capacidad.

Azure Data Factory es un servicio de integración de datos basado en la nube que le permite la creación de flujos de trabajo basados en datos en la nube a fin de coordinar y automatizar el movimiento y la transformación de datos. Con Data Factory, puede crear y programar flujos de trabajo basados en datos (denominados canalizaciones) que pueden ingerir datos de distintos almacenes. Puede procesar y transformar los datos usando servicios de proceso, como Azure HDInsight Hadoop, Spark, Azure Data Lake Analytics y Azure Machine Learning.

Mediante la creación de metadatos para mostrar las tablas de datos que se van a migrar y su ubicación, puede usar las características de Azure Data Factory para administrar y automatizar algunas partes del proceso de migración. También puede usar canalizaciones de Azure Synapse.

Diferencias en el lenguaje DDL de SQL entre Teradata y Azure Synapse

Lenguaje de definición de datos (DDL)

El estándar SQL de ANSI define la sintaxis básica para los comandos DDL, como CREATE TABLE y CREATE VIEW. Estos comandos se usan tanto en Teradata como en Azure Synapse, pero también se han ampliado para permitir la definición de características específicas de la implementación, como las opciones de indexación, distribución de tablas y creación de particiones.

En las secciones siguientes, se describen las opciones específicas de Teradata que deben tenerse en cuenta durante una migración a Azure Synapse.

Consideraciones sobre las tablas

Al migrar tablas entre diferentes tecnologías, solo se mueven físicamente entre los dos entornos los datos sin procesar y los metadatos que los describen. Otros elementos de base de datos del sistema de origen, como los índices y los archivos de registro, no se migran, porque es posible que no sean necesarios o que se implementen de manera diferente en el nuevo entorno de destino. Por ejemplo, no hay ningún equivalente de la opción MULTISET en la sintaxis de CREATE TABLE de Teradata.

Es importante saber dónde se han utilizado optimizaciones del rendimiento (como los índices) en el entorno de origen. Esto indica dónde se puede optimizar el rendimiento en el nuevo entorno de destino. Por ejemplo, si se ha creado un índice secundario no único (NUSI) en el entorno de Teradata de origen, esto podría indicar que se debe crear un índice no agrupado en la base de datos de Azure Synapse migrada. Otras técnicas de optimización del rendimiento nativas, como la replicación de tablas, pueden ser más adecuadas que la creación directa de un índice equivalente "igual por igual".

Tipos de tabla de Teradata no admitidos

Teradata incluye compatibilidad con los tipos de tabla especiales para las series temporales y los datos temporales. La sintaxis y algunas de las funciones de estos tipos de tabla no se admiten directamente en Azure Synapse, pero los datos se pueden migrar a una tabla estándar con tipos de datos adecuados y realizar la indexación o el particionamiento por la columna de fecha y hora.

Teradata implementa la funcionalidad de consulta temporal a través de la reescritura de consultas para agregar filtros adicionales en una consulta temporal para limitar el rango de fechas aplicable. Si esta funcionalidad está actualmente en uso en el entorno de Teradata de origen y se va a migrar, este filtrado adicional deberá agregarse a las consultas temporales pertinentes.

El entorno de Azure también incluye características específicas para análisis complejos de datos de series temporales a gran escala denominadas Time Series Insights, que están dirigidas a aplicaciones de análisis de datos de IoT y pueden ser más adecuadas para este caso de uso.

Tipos de datos de Teradata no admitidos

La mayoría de los tipos de datos de Teradata tienen un equivalente directo en Azure Synapse. En la tabla siguiente se muestran los tipos de datos de Teradata que no se admiten en Azure Synapse junto con la asignación recomendada. En la tabla, el tipo de columna de Teradata es el tipo que se almacena en el catálogo del sistema (por ejemplo, en DBC.ColumnsV).

Use los metadatos de las tablas del catálogo de Teradata para decidir si alguno de estos tipos de datos se va a migrar y permitirlo en el plan de migración. Por ejemplo, use una consulta SQL como esta para buscar tipos de datos no admitidos que requieren atención.

SELECT
ColumnType, CASE
WHEN ColumnType = '++' THEN 'TD_ANYTYPE' 
WHEN ColumnType = 'A1' THEN 'ARRAY' WHEN 
ColumnType = 'AN' THEN 'ARRAY' WHEN 
ColumnType = 'BO' THEN 'BLOB'
WHEN ColumnType = 'CO' THEN 'CLOB'
WHEN ColumnType = 'DH' THEN 'INTERVAL DAY TO HOUR' WHEN 
ColumnType = 'DM' THEN 'INTERVAL DAY TO MINUTE' WHEN 
ColumnType = 'DS' THEN 'INTERVAL DAY TO SECOND' WHEN
ColumnType = 'DT' THEN 'DATASET'
WHEN ColumnType = 'DY' THEN 'INTERVAL DAY'
WHEN ColumnType = 'HM' THEN 'INTERVAL HOUR TO MINUTE' WHEN
ColumnType = 'HR' THEN 'INTERVAL HOUR'
WHEN ColumnType = 'HS' THEN 'INTERVAL HOUR TO SECOND' WHEN
ColumnType = 'JN' THEN 'JSON'
WHEN ColumnType = 'MI' THEN 'INTERVAL MINUTE' WHEN 
ColumnType = 'MO' THEN 'INTERVAL MONTH'
WHEN ColumnType = 'MS' THEN 'INTERVAL MINUTE TO SECOND' WHEN
ColumnType = 'PD' THEN 'PERIOD(DATE)'
WHEN ColumnType = 'PM' THEN 'PERIOD (TIMESTAMP WITH TIME ZONE)'
WHEN ColumnType = 'PS' THEN 'PERIOD(TIMESTAMP)' WHEN 
ColumnType = 'PT' THEN 'PERIOD(TIME)'
WHEN ColumnType = 'PZ' THEN 'PERIOD (TIME WITH TIME ZONE)' WHEN
ColumnType = 'SC' THEN 'INTERVAL SECOND'
WHEN ColumnType = 'SZ' THEN 'TIMESTAMP WITH TIME ZONE' WHEN
ColumnType = 'XM' THEN 'XML'
WHEN ColumnType = 'YM' THEN 'INTERVAL YEAR TO MONTH' WHEN
ColumnType = 'YR' THEN 'INTERVAL YEAR'
END AS Data_Type,
COUNT (*) AS Data_Type_Count FROM
DBC.ColumnsV
WHERE DatabaseName IN ('UserDB1', 'UserDB2', 'UserDB3') -- select databases to be migrated
GROUP BY 1,2
ORDER BY 1;

Hay proveedores que ofrecen herramientas y servicios para automatizar la migración, incluida la asignación de los tipos de datos. Si ya se utiliza una herramienta ETL de terceros, como Informatica o Talend, en el entorno de Teradata, esa herramienta puede implementar cualquier transformación de datos necesaria.

Generación del lenguaje de definición de datos (DDL)

Si es necesario, edite los scripts CREATE TABLE y CREATE VIEW de Teradata para crear las definiciones equivalentes con tipos de datos modificados, como hemos explicado antes. Normalmente, esto implica quitar las cláusulas adicionales específicas de Teradata, como FALLBACK o MULTISET.

Sin embargo, toda la información que especifica las definiciones actuales de tablas y vistas dentro del entorno de Teradata existente se mantiene dentro de las tablas del catálogo del sistema. Este es el mejor origen de esta información, ya que se garantiza que está actualizada y completa. Tenga en cuenta que es posible que la documentación mantenida por los usuarios no esté sincronizada con las definiciones de tabla actuales.

Puede acceder a esta información a través de vistas del catálogo, como DBC.ColumnsV, y generar las instrucciones DDL CREATE TABLE equivalentes para las tablas equivalentes de Azure Synapse.

Hay asociados de Microsoft que ofrecen herramientas y servicios para automatizar la migración, incluida la asignación de los tipos de datos. Además, si ya se utiliza una herramienta ETL de terceros, como Informatica o Talend, en el entorno de Teradata, esa herramienta puede implementar cualquier transformación de datos necesaria.

Diferencias en el lenguaje DML de SQL entre Teradata y Azure Synapse

Lenguaje de manipulación de datos (DML)

El estándar SQL de ANSI define la sintaxis básica de los comandos DML, como SELECT, INSERT, UPDATEy DELETE. Tanto Teradata como Azure Synapse usan estos comandos, pero, en algunos casos, hay diferencias de implementación.

En las secciones siguientes, se describen los comandos DML específicos de Teradata que debe tener en cuenta durante una migración a Azure Synapse.

Diferencias de sintaxis de DML de SQL

Tenga en cuenta estas diferencias entre Teradata SQL y Azure Synapse (T-SQL) en cuanto a la sintaxis del lenguaje de manipulación de datos (DML) de SQL al realizar la migración:

• QUALIFY: Teradata admite el operador QUALIFY. Por ejemplo:

  SELECT col1
  FROM tab1
  WHERE col1='XYZ'
  QUALIFY ROW_NUMBER () OVER (PARTITION by
  col1 ORDER BY col1) = 1;
  

  La sintaxis de Azure Synapse equivalente es la siguiente:

  SELECT * FROM (
  SELECT col1, ROW_NUMBER () OVER (PARTITION by col1 ORDER BY col1) rn
  FROM tab1 WHERE col1='XYZ'
  ) WHERE rn = 1;
  

• Aritmética de fechas: Azure Synapse tiene operadores como DATEADD y DATEDIFF que se pueden usar en campos DATE o DATETIME. Teradata admite la resta directa en fechas, como SELECT DATE1 - DATE2 FROM...

• En GROUP BY ordinal, proporcione explícitamente el nombre de columna de T-SQL.

• LIKE ANY: Teradata admite sintaxis de LIKE ANY, como:

  SELECT * FROM CUSTOMER
  WHERE POSTCODE LIKE ANY
  ('CV1%', 'CV2%', 'CV3%');
  

  El equivalente en la sintaxis de Azure Synapse es:

  SELECT * FROM CUSTOMER
  WHERE
  (POSTCODE LIKE 'CV1%') OR (POSTCODE LIKE 'CV2%') OR (POSTCODE LIKE 'CV3%');
  

• En función de la configuración del sistema, puede que las comparaciones de caracteres en Teradata no distingan mayúsculas de minúsculas de forma predeterminada. En Azure Synapse, las comparaciones de caracteres siempre distinguen mayúsculas de minúsculas.

Uso de EXPLAIN para validar SQL heredado

Una manera de probar el código heredado de Teradata SQL para comprobar la compatibilidad con Azure Synapse consiste en capturar algunas instrucciones SQL representativas de los registros de consultas del sistema heredados, agregar el prefijo EXPLAIN a esas consultas y (siempre que sea un modelo de datos migrado "igual por igual" a Azure Synapse con los mismos nombres de tabla y columna) ejecutar esas instrucciones EXPLAIN en Azure Synapse. Cualquier código SQL incompatible producirá un error. Use esta información para determinar la escala de la tarea de programarlo de nuevo. Este enfoque no requiere que los datos se carguen en el entorno de Azure, solo que se hayan creado las tablas y vistas pertinentes.

Funciones, procedimientos almacenados, desencadenadores y secuencias

Al migrar desde un entorno de almacenamiento de datos heredado consolidado, como Teradata, a menudo hay elementos distintos de tablas y vistas simples que se deben migrar al nuevo entorno de destino. Algunos ejemplos son las funciones, los procedimientos almacenados, los desencadenadores y las secuencias.

En la fase de preparación, cree un inventario de los objetos que deben migrarse y defina los métodos para controlarlos. A continuación, asigne los recursos adecuados en el plan del proyecto.

Puede haber características en el entorno de Azure que reemplacen la funcionalidad implementada como funciones o procedimientos almacenados en el entorno de Teradata. En este caso, suele ser más eficaz usar las características integradas de Azure que volver a programar las funciones de Teradata.

Asociados de Microsoft ofrecen herramientas y servicios que pueden automatizar la migración.

Consulte las secciones siguientes para obtener más información sobre cada uno de estos elementos.

Functions

Al igual que en la mayoría de los productos de base de datos, Teradata admite funciones del sistema y funciones definidas por el usuario en la implementación de SQL. Al migrar a otra plataforma de base de datos, como Azure Synapse, hay disponibles funciones comunes del sistema que se pueden migrar sin cambios. Algunas funciones del sistema pueden tener una sintaxis ligeramente diferente, pero se pueden automatizar los cambios necesarios. En el caso de las funciones del sistema para las que no hay ningún equivalente, como las funciones arbitrarias definidas por el usuario, puede ser necesario programarlas de nuevo con los lenguajes disponibles en el entorno de destino. Azure Synapse usa el conocido lenguaje Transact-SQL para la implementación de funciones definidas por el usuario.

Procedimientos almacenados

La mayoría de los productos de base de datos modernos permite almacenar los procedimientos en la base de datos. Teradata proporciona el lenguaje SPL para tales fines. Normalmente, un procedimiento almacenado contiene instrucciones SQL y alguna lógica procedimental, y puede devolver datos o un estado.

Los grupos de SQL dedicados de Azure Synapse Analytics también admiten procedimientos almacenados por medio de T-SQL. Por tanto, si debe migrar procedimientos almacenados, vuelva a programarlos en consecuencia.

Desencadenadores

Azure Synapse no admite la creación de desencadenadores, pero puede implementarlos en Azure Data Factory.

Secuencias

Las secuencias de Azure Synapse se controlan de forma similar a Teradata, mediante IDENTITY para crear claves suplentes o la identidad administrada.

Correspondencia entre Teradata y T-SQL

En esta tabla, se muestra la asignación de tipos de datos de Teradata a T-SQL compatible con Azure Synapse SQL:

Resumen

Las instalaciones de Teradata heredadas típicas están implementadas de una manera que facilita la migración a Azure Synapse. Utilizan SQL para las consultas analíticas en grandes volúmenes de datos y tienen algún tipo de modelo de datos dimensional. Estos factores las convierten en buenos candidatos para la migración a Azure Synapse.

Para minimizar la tarea de migración del código SQL real, siga estas recomendaciones:

• La migración inicial del almacenamiento de datos debe ser tal cual para minimizar el riesgo y el tiempo necesario, incluso si el entorno final incorporará un modelo de datos diferente, como un almacén de datos.

• Considere la posibilidad de usar una instancia de Teradata en una máquina virtual de Azure como paso intermedio en el proceso de migración.

• Conozca las diferencias entre la implementación de Teradata SQL y Azure Synapse.

• Use los metadatos y los registros de consultas de la implementación de Teradata para evaluar el impacto de las diferencias y planear un enfoque para mitigarlo.

• Automatice el proceso siempre que sea posible para minimizar los errores, el riesgo y el tiempo necesario para la migración.

• Considere la posibilidad de usar servicios y asociados de Microsoft especialistas para simplificar la migración.

Pasos siguientes

Para obtener más información sobre herramientas de Microsoft y de terceros, lea el siguiente artículo de esta serie: Herramientas para la migración del almacenamiento de datos de Teradata a Azure Synapse Analytics.