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
Sugerencia
Teradata fue pionero en bases de datos SQL a gran escala con MPP en los años ochenta.
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.
Sugerencia
Muchas instalaciones de Teradata son un almacenamiento de datos que usa un modelo de datos dimensional.
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
Sugerencia
Use una máquina virtual de Azure para crear una instancia temporal de Teradata con el fin de acelerar la migración y minimizar el impacto en el sistema de origen.
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
Sugerencia
Automatice el proceso de migración con las funcionalidades de Azure Data Factory.
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)
Sugerencia
Los comandos DDL CREATE TABLE y CREATE VIEW de SQL tienen elementos principales estándar, pero también se usan para definir opciones específicas de la implementación.
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
Sugerencia
Utilice índices que ya existan para indicar candidatos para la indexación en el almacenamiento migrado.
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
Sugerencia
Las tablas estándar de Azure Synapse pueden admitir tablas temporales y de series temporales de Teradata que se hayan migrado.
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
Sugerencia
En la fase de preparación, evalúe el impacto de los tipos de datos 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).
| Tipo de columna de Teradata | Tipo de datos de Teradata | Tipo de datos de Azure Synapse |
|---|---|---|
| ++ | TD_ANYTYPE | No se admite en Azure Synapse |
| A1 | ARRAY | No se admite en Azure Synapse |
| AN | ARRAY | No se admite en Azure Synapse |
| AT | TIME | TIME |
| BF | BYTE | BINARY |
| BO | BLOB | El tipo de datos BLOB no se admite directamente, pero se puede reemplazar por BINARY. |
| BV | VARBYTE | BINARY |
| CF | VARCHAR | CHAR |
| CO | CLOB | El tipo de datos CLOB no se admite directamente, pero se puede reemplazar por VARCHAR. |
| CV | VARCHAR | VARCHAR |
| D | DECIMAL | DECIMAL |
| DA | DATE | DATE |
| DH | INTERVAL DAY TO HOUR | En Azure Synapse, no se admiten los tipos de datos INTERVAL, pero los cálculos de fecha se pueden realizar con las funciones de comparación de fechas (por ejemplo, DATEDIFF y DATEADD). |
| DM | INTERVAL DAY TO MINUTE | En Azure Synapse, no se admiten los tipos de datos INTERVAL, pero los cálculos de fecha se pueden realizar con las funciones de comparación de fechas (por ejemplo, DATEDIFF y DATEADD). |
| DS | INTERVAL DAY TO SECOND | En Azure Synapse, no se admiten los tipos de datos INTERVAL, pero los cálculos de fecha se pueden realizar con las funciones de comparación de fechas (por ejemplo, DATEDIFF y DATEADD). |
| DT | CONJUNTO DE DATOS | El tipo de datos DATASET se admite en Azure Synapse. |
| DY | INTERVAL DAY | En Azure Synapse, no se admiten los tipos de datos INTERVAL, pero los cálculos de fecha se pueden realizar con las funciones de comparación de fechas (por ejemplo, DATEDIFF y DATEADD). |
| F | FLOAT | FLOAT |
| HM | INTERVAL HOUR TO MINUTE | En Azure Synapse, no se admiten los tipos de datos INTERVAL, pero los cálculos de fecha se pueden realizar con las funciones de comparación de fechas (por ejemplo, DATEDIFF y DATEADD). |
| HR | INTERVAL HOUR | En Azure Synapse, no se admiten los tipos de datos INTERVAL, pero los cálculos de fecha se pueden realizar con las funciones de comparación de fechas (por ejemplo, DATEDIFF y DATEADD). |
| HS | INTERVAL HOUR TO SECOND | En Azure Synapse, no se admiten los tipos de datos INTERVAL, pero los cálculos de fecha se pueden realizar con las funciones de comparación de fechas (por ejemplo, DATEDIFF y DATEADD). |
| I1 | BYTEINT | TINYINT |
| I2 | SMALLINT | SMALLINT |
| I8 | bigint | bigint |
| I | INTEGER | INT |
| JN | JSON | Actualmente, el tipo de datos JSON no se admite directamente en Azure Synapse, pero los datos JSON se pueden almacenar en un campo VARCHAR. |
| MI | INTERVAL MINUTE | En Azure Synapse, no se admiten los tipos de datos INTERVAL, pero los cálculos de fecha se pueden realizar con las funciones de comparación de fechas (por ejemplo, DATEDIFF y DATEADD). |
| MO | INTERVAL MONTH | En Azure Synapse, no se admiten los tipos de datos INTERVAL, pero los cálculos de fecha se pueden realizar con las funciones de comparación de fechas (por ejemplo, DATEDIFF y DATEADD). |
| MS | INTERVAL MINUTE TO SECOND | En Azure Synapse, no se admiten los tipos de datos INTERVAL, pero los cálculos de fecha se pueden realizar con las funciones de comparación de fechas (por ejemplo, DATEDIFF y DATEADD). |
| No | NUMBER | NUMERIC |
| PD | PERIOD(DATE) | Puede convertirse en VARCHAR o dividirse en dos fechas separadas. |
| PM | PERIOD (TIMESTAMP WITH TIME ZONE) | Puede convertirse en VARCHAR o dividirse en dos marcas de tiempo separadas (DATETIMEOFFSET). |
| PS | PERIOD(TIMESTAMP) | Puede convertirse en VARCHAR o dividirse en dos marcas de tiempo separadas (DATETIMEOFFSET). |
| PT | PERIOD(TIME) | Puede convertirse en VARCHAR o dividirse en dos valores de tiempo separados. |
| PZ | PERIOD (TIME WITH TIME ZONE) | Puede convertirse en VARCHAR o dividirse en dos valores de tiempo separados, pero no se admite WITH TIME ZONE para TIME. |
| SC | INTERVAL SECOND | En Azure Synapse, no se admiten los tipos de datos INTERVAL, pero los cálculos de fecha se pueden realizar con las funciones de comparación de fechas (por ejemplo, DATEDIFF y DATEADD). |
| SZ | TIMESTAMP WITH TIME ZONE | DATETIMEOFFSET |
| TS | timestamp | DATETIME o DATETIME2 |
| TZ | TIME WITH TIME ZONE | TIME WITH TIME ZONE no se admite porque TIME se almacena solo con la “hora de reloj”, sin una diferencia horaria. |
| XM | XML | Actualmente, el tipo de datos XML no se admite directamente en Azure Synapse, pero los datos XML se pueden almacenar en un campo VARCHAR. |
| YM | INTERVAL YEAR TO MONTH | En Azure Synapse, no se admiten los tipos de datos INTERVAL, pero los cálculos de fecha se pueden realizar con las funciones de comparación de fechas (por ejemplo, DATEDIFF y DATEADD). |
| YR | INTERVAL YEAR | En Azure Synapse, no se admiten los tipos de datos INTERVAL, pero los cálculos de fecha se pueden realizar con las funciones de comparación de fechas (por ejemplo, DATEDIFF y DATEADD). |
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;
Sugerencia
Herramientas y servicios de terceros pueden automatizar las tareas de asignación de datos.
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)
Sugerencia
Use los metadatos de Teradata para automatizar la generación de CREATE TABLE y CREATE VIEW DDL para Azure Synapse.
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.
Sugerencia
Herramientas y servicios de terceros pueden automatizar las tareas de asignación de datos.
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)
Sugerencia
Los comandos DML SELECT, INSERT y UPDATE de SQL tienen elementos principales estándar, pero también pueden implementar otras opciones de sintaxis.
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 operadorQUALIFY. 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
DATEADDyDATEDIFFque se pueden usar en camposDATEoDATETIME. Teradata admite la resta directa en fechas, comoSELECT DATE1 - DATE2 FROM...En
GROUP BYordinal, proporcione explícitamente el nombre de columna de T-SQL.LIKE ANY: Teradata admite sintaxis deLIKE 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
Sugerencia
Use consultas reales de los registros de consultas del sistema para buscar posibles problemas de migración.
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
Sugerencia
En la fase de preparación, evalúe el número y el tipo de objetos que no son datos que se van a migrar.
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.
Sugerencia
Los productos y servicios de terceros pueden automatizar la migración de elementos que no son datos.
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:
| Tipo de datos de Teradata | Tipo de datos de Azure Synapse SQL |
|---|---|
| bigint | bigint |
| bool | bit |
| boolean | bit |
| byteint | TINYINT |
| char [(p)] | char [(p)] |
| char varying [(p)] | varchar [(p)] |
| character [(p)] | char [(p)] |
| character varying [(p)] | varchar [(p)] |
| date | date |
| datetime | datetime |
| dec [(p[,s])] | decimal [(p[,s])] |
| decimal [(p[,s])] | decimal [(p[,s])] |
| double | float(53) |
| double precision | float(53) |
| float [(p)] | float [(p)] |
| float4 | float(53) |
| float8 | float(53) |
| int | int |
| int1 | TINYINT |
| int2 | SMALLINT |
| int4 | int |
| int8 | bigint |
| integer | integer |
| interval | No admitido |
| national char varying [(p)] | nvarchar [(p)] |
| national character [(p)] | nchar [(p)] |
| national character varying [(p)] | nvarchar [(p)] |
| nchar [(p)] | nchar [(p)] |
| numeric [(p[,s])] | numeric [(p[,s]) |
| nvarchar [(p)] | nvarchar [(p)] |
| real | real |
| SMALLINT | SMALLINT |
| time | time |
| time with time zone | datetimeoffset |
| time without time zone | time |
| timespan | No admitido |
| timestamp | datetime2 |
| timetz | datetimeoffset |
| varchar [(p)] | varchar [(p)] |
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.