Diseño y rendimiento para las migraciones de Teradata

Este artículo es el primero 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 el diseño y el rendimiento.

Información general

Muchos usuarios existentes de sistemas de almacenamiento de datos de Teradata quieren aprovechar las innovaciones proporcionadas por entornos de nube modernos. Los entornos en la nube de infraestructura como servicio (IaaS) y plataforma como servicio (PaaS) permiten delegar tareas como el mantenimiento de la infraestructura y el desarrollo de plataformas en el proveedor de nube.

Sugerencia

Más que una base de datos: el entorno de Azure incluye un conjunto completo de características y herramientas.

Aunque Teradata y Azure Synapse Analytics son bases de datos SQL que usan técnicas de procesamiento paralelo masivo (MPP) con el fin de lograr un alto rendimiento de las consultas en volúmenes de datos excepcionalmente grandes, hay algunas diferencias básicas en cuanto al enfoque que utilizan:

• Los sistemas heredados de Teradata están instalados a menudo en el entorno local y usan hardware propietario, mientras que Azure Synapse se basa en la nube y usa Azure Storage y recursos de proceso.

• Dado que los recursos de almacenamiento y de proceso son independientes en el entorno de Azure y tienen funcionalidad de escalabilidad elástica, se pueden escalar o reducir verticalmente de manera independiente.

• Puede pausar o cambiar el tamaño de Azure Synapse según sea necesario para reducir el costo y el uso de recursos.

• La actualización de una configuración de Teradata es una tarea importante que implica hardware físico adicional y, posiblemente, una extensa reconfiguración o recarga de la base de datos.

Microsoft Azure es un entorno en la nube escalable, muy seguro, está disponible en todo el mundo e incluye Azure Synapse y un ecosistema de herramientas y funcionalidades complementarias. En el siguiente diagrama, se resume el ecosistema de Azure Synapse.

Azure Synapse proporciona el mejor rendimiento de las bases de datos relacionales mediante el uso de técnicas como el procesamiento paralelo masivo (MPP) y varios niveles de almacenamiento en caché automatizado para los datos que se usan con frecuencia. Puede ver los resultados de estas técnicas en pruebas comparativas independientes, como la ejecutada recientemente por GigaOm, que compara Azure Synapse con otras ofertas conocidas de almacenamiento de datos en la nube. Los clientes que migran al entorno de Azure Synapse se benefician de muchas ventajas, entre las que se incluyen:

• Rendimiento y relación precio/rendimiento mejorados.

• Mayor agilidad y tiempo de rentabilidad menor.

• Implementación de servidores y desarrollo de aplicaciones más rápidos.

• Escalabilidad elástica: solo se paga por el uso real.

• Mayor seguridad y cumplimiento.

• Costos reducidos de almacenamiento y recuperación ante desastres.

• Menor TCO global, mejor control de costos y gastos de funcionamiento (OPEX) optimizados.

Para maximizar estas ventajas, migre los datos y aplicaciones existentes o nuevos a la plataforma Azure Synapse. En muchas organizaciones, este enfoque incluye la migración de un almacenamiento de datos existente desde una plataforma local heredada, como Teradata, a Azure Synapse. A grandes rasgos, el proceso de migración incluye los siguientes pasos:

    Preparación 🡆

• Definir el ámbito: qué se va a migrar.

• Generar el inventario de datos y procesos para la migración.

• Definir los cambios en el modelo de datos (si procede).

• Definir el mecanismo de extracción de datos de origen.

• Identificar las herramientas y características adecuadas de Azure (y de terceros) que se usarán.

• Entrene al personal en la nueva plataforma desde el principio.

• Configure la plataforma de destino de Azure.

    Migración 🡆

• Comience con algo pequeño y sencillo.

• Automatice siempre que sea posible.

• Aprovechar las herramientas y características integradas de Azure para reducir el esfuerzo de migración.

• Migre los metadatos de tablas y vistas.

• Migrar los datos históricos que se van a mantener.

• Migre o refactorice los procedimientos almacenados y los procesos empresariales.

• Migre o refactorice los procesos de carga incremental ETL/ELT.

    Tareas posteriores a la migración

• Supervisar y documentar todas las fases del proceso.

• Aprovechar la experiencia adquirida para generar una plantilla de cara a migraciones futuras.

• Volver a diseñar el modelo de datos, si es necesario, con el nuevo rendimiento y escalabilidad de la plataforma.

• Pruebe las aplicaciones y herramientas de consulta.

• Realice evaluaciones comparativas y optimice el rendimiento de las consultas.

En este artículo se proporciona información general y directrices para la optimización del rendimiento al migrar un almacenamiento de datos desde un entorno de Netezza existente a Azure Synapse. El objetivo de la optimización del rendimiento es lograr el mismo o mejor rendimiento del almacenamiento de datos en Azure Synapse después de la migración del esquema.

Consideraciones de diseño

Ámbito de la migración

Cuando esté preparando la migración desde un entorno de Teradata, tenga en cuenta las siguientes opciones de migración.

Elección de la carga de trabajo para la migración inicial

En general, los entornos heredados de Teradata han evolucionado con el tiempo para abarcar varias áreas temáticas y cargas de trabajo mixtas. Al decidir por dónde empezar en un proyecto de migración inicial, elija un área en la que pueda:

• Demostrar la viabilidad de la migración a Azure Synapse con la obtención de beneficios rápidos del nuevo entorno.

• Permitir que el personal técnico interno obtenga experiencia relevante con los procesos y herramientas que usarán al migrar otras áreas.

• Crear una plantilla para migraciones posteriores que sea específica del entorno de Teradata de origen y las herramientas y los procesos actuales que ya se utilizan.

Un buen candidato para una migración inicial desde un entorno de Teradata admite los elementos anteriores y:

• Implementa una carga de trabajo de BI/Analytics en lugar de una carga de trabajo de procesamiento de transacciones en línea (OLTP).

• Tiene un modelo de datos, como un esquema de estrella o copo de nieve, que se puede migrar con una modificación mínima.

Sugerencia

Cree un inventario de objetos que es necesario migrar y documente el proceso de migración.

El volumen de datos migrados en una migración inicial debe ser lo suficientemente grande como para demostrar las funcionalidades y ventajas del entorno de Azure Synapse, pero no demasiado grande para demostrar rápidamente el valor. Un tamaño en el rango de 1 a 10 terabytes es lo habitual.

Para el proyecto de migración inicial, minimice el riesgo, el esfuerzo y el tiempo de migración para que pueda ver rápidamente las ventajas del entorno de la nube de Azure, limitar el ámbito de la migración a solo los data marts, como la parte de OLAP DB de un almacenamiento de Teradata. Los enfoques de migración por fases y lift-and-shift limitan el ámbito de la migración inicial a solo los data marts y no abordan aspectos de migración más amplios, como la migración ETL y la migración de datos históricos. Sin embargo, puede abordar esos aspectos en fases posteriores del proyecto una vez que la capa de data mart migrada se rellene con los datos y los procesos de compilación necesarios.

Migración mediante lift-and-shift frente al enfoque por fases

En general, hay dos tipos de migración independientemente del propósito y el ámbito de la migración planeada: lift-and-shift tal cual y un enfoque por fases que incorpora cambios.

migración mediante lift-and-shift

En una migración mediante lift-and-shift, un modelo de datos existente, como un esquema de estrella, se migra sin cambios a la nueva plataforma de Azure Synapse. Este enfoque minimiza el riesgo y el tiempo necesario para la migración reduciendo el trabajo necesario para lograr las ventajas de migrar al entorno en la nube de Azure. La migración mediante lift-and-shift es una buena opción para estos escenarios:

• Tiene un entorno de Teradata existente con un único data mart para migrar o
• Tiene un entorno de Teradata existente con datos que ya están en un esquema de estrella o copo de nieve bien diseñado, o bien
• Está afectado por limitaciones de tiempo y dinero para pasar a un entorno de nube moderno.

Sugerencia

La migración mediante "Lift and shift" es un buen punto inicial, incluso si las fases posteriores implementan cambios en el modelo de datos.

Estrategia por fases que incorpora cambios

Si un almacén heredado ha evolucionado con el tiempo, es posible que tenga que volver a diseñarlo para mantener el rendimiento necesario. También es posible que tenga que volver a diseñar para admitir nuevos datos, como los flujos de Internet de las cosas (IoT). Migre a Azure Synapse para obtener las ventajas de un entorno en la nube escalable como parte del proceso de reingeniería. La migración podría incluir un cambio en el modelo de datos subyacente; por ejemplo, pasar de un modelo Inmon a un almacén de datos.

Microsoft recomienda trasladar el modelo de datos actual tal y como está a Azure (opcionalmente, usando una instancia de Teradata en una máquina virtual de Azure) y usar el rendimiento y la flexibilidad del entorno de Azure para aplicar los cambios del nuevo diseño. De este modo, puede usar las funcionalidades de Azure para realizar los cambios sin afectar al sistema de origen existente.

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

Al migrar desde un entorno de Teradata local, puede aprovechar el almacenamiento en la nube y la escalabilidad elástica en Azure para crear una instancia de Teradata dentro de una máquina virtual. Este enfoque coloca la instancia de Teradata con el entorno de destino de Azure Synapse. Puede usar las utilidades normales de Teradata, como Teradata Parallel Data Transporter, para mover eficazmente el subconjunto de tablas de Teradata que se van a migrar a la instancia de la máquina virtual. A continuación, el resto de las tareas de migración se realizan 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 de ancho de banda de la 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.

• Puede organizar y controlar el proceso de migración completamente dentro del entorno de Azure.

Sugerencia

Use máquinas virtuales 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.

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

Puede automatizar y organizar el proceso de migración mediante las funcionalidades del entorno de Azure. Este enfoque minimiza el impacto del rendimiento en el entorno de Netezza existente, que es posible que ya funcione casi a plena capacidad.

Azure Data Factory es un servicio de integración de datos basado en la nube que permite crear flujos de trabajo basados en datos en la nube a fin de orquestar y automatizar el movimiento y la transformación de datos. Con Azure Data Factory puede crear y programar flujos de trabajo basados en datos (llamados canalizaciones) que ingieren datos de distintos almacenes de datos. Data Factory puede procesar y transformar datos mediante servicios de proceso, como Azure HDInsight Hadoop, Spark, Azure Data Lake Analytics y Azure Machine Learning.

Cuando planee usar las instalaciones de Data Factory para administrar el proceso de migración, cree metadatos que muestren todas las tablas de datos que se van a migrar y su ubicación.

Diferencias de diseño entre Teradata y Azure Synapse

Como se mencionó anteriormente, hay algunas diferencias básicas en el enfoque entre las bases de datos de Teradata y Azure Synapse Analytics y estas diferencias se describen a continuación.

Varias bases de datos frente a esquemas y bases de datos únicas

El entorno de Teradata suele contener varias bases de datos independientes. Por ejemplo, podría haber bases de datos independientes para: tablas de ingesta y almacenamiento provisional de datos, tablas de almacenamiento principal y data marts (a veces denominada capa semántica). Los procesos de canalización ETL o ELT pueden implementar combinaciones entre bases de datos y mover datos entre las bases de datos independientes.

Por otro lado, el entorno de Azure Synapse tiene una sola base de datos, y se usan esquemas para separar las tablas en grupos lógicamente distintos. Se recomienda usar una serie de esquemas en la base de datos de Azure Synapse de destino para imitar las bases de datos independientes migradas desde el entorno de Teradata. Si ya se usan esquemas en el entorno de Teradata, es posible que sea necesario utilizar una nueva convención de nomenclatura para trasladar las tablas y vistas de Teradata existentes al nuevo entorno. Por ejemplo, podría concatenar los nombres de tabla y esquema de Teradata existentes en el nuevo nombre de tabla de Azure Synapse y, luego, usar nombres de esquema del nuevo entorno para mantener los nombres originales de las bases de datos dispares. Si la nomenclatura de la consolidación de esquemas tiene puntos, Azure Synapse Spark podría tener problemas. Puede usar vistas SQL en las tablas subyacentes para mantener las estructuras lógicas, pero este enfoque presenta algunas posibles desventajas:

• Las vistas de Azure Synapse son de solo lectura, por lo que toda actualización de los datos debe realizarse en las tablas base subyacentes.

• Es posible que ya haya una o varias capas de vistas y agregar una capa de vistas más podría afectar al rendimiento y la compatibilidad, porque los problemas con vistas anidadas son difíciles de solucionar.

Sugerencia

Combine varias bases de datos en una base de datos única en Azure Synapse y utilice esquemas para separar las tablas de manera lógica.

Consideraciones sobre las tablas

Al migrar tablas entre distintos entornos, normalmente solo los datos sin procesar y los metadatos que lo describen migran físicamente. Otros elementos de base de datos del sistema de origen, como los índices, normalmente no se migran porque podrían ser innecesarios o implementados de forma diferente en el nuevo entorno. Las optimizaciones de rendimiento en el entorno de origen, como los índices, indican dónde puede agregar la optimización del rendimiento en el nuevo entorno. Por ejemplo, si una tabla dentro del entorno de Teradata de origen tiene un índice secundario no único (NUSI), que sugiere que se debe crear un índice no agrupado dentro de Azure Synapse. 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).

Sugerencia

Los índices que ya existen indican candidatos para la indexación en el almacenamiento migrado.

Alta disponibilidad de la base de datos

Teradata admite la replicación de datos entre nodos a través de la opción FALLBACK, donde las filas de tabla que residen físicamente en un nodo dado se replican en otro nodo dentro del sistema. Este enfoque garantiza que los datos no se perderán si se produce un error en el nodo, y proporciona la base para escenarios de conmutación por error.

El objetivo de la arquitectura de alta disponibilidad en Azure Synapse Analytics es garantizar que la base de datos funcione el 99,9 % de las veces, sin preocuparse del impacto de las operaciones de mantenimiento ni las interrupciones. Para obtener más información sobre el acuerdo de Nivel de Servicio, consulte Acuerdo de Nivel de Servicio para Azure Synapse Analytics. Azure controla automáticamente las tareas de mantenimiento críticas, como la aplicación de revisiones, las copias de seguridad, las actualizaciones de Windows y SQL. Azure también controla automáticamente eventos no planeados, como errores en el hardware, el software o la red subyacentes.

Del almacenamiento de datos de Azure Synapse, se realizan copias de seguridad de forma automática con instantáneas. Estas instantáneas son una característica integrada del servicio que crea puntos de restauración. No es necesario que habilite esta funcionalidad. Actualmente, los usuarios no pueden eliminar los puntos de restauración automáticos que el servicio usa para mantener los Acuerdos de Nivel de Servicio (SLA) para la recuperación.

El grupo de SQL dedicado de Azure Synapse toma instantáneas del almacenamiento de datos a lo largo del día para crear puntos de restauración que están disponibles durante siete días. Este período de retención no se puede modificar. Azure Synapse admite un objetivo de punto de recuperación (RPO) de ocho horas. Puede restaurar el almacenamiento de datos de la región primaria a partir de cualquiera de las instantáneas capturadas en los últimos siete días. Si necesita copias de seguridad más pormenorizadas, hay disponibles otras opciones definidas por el usuario.

Tipos de tabla de Teradata no admitidos

Teradata admite tipos de tabla especiales para los datos temporales y de series temporales. La sintaxis y algunas de las funciones para estos tipos de tabla no se admiten directamente en Azure Synapse Analytics. Sin embargo, puede migrar los datos a una tabla estándar en Azure Synapse mediante la asignación a los tipos de datos adecuados y la indexación o la creación de particiones de la columna de fecha y hora.

Sugerencia

Las tablas estándar de Azure Synapse pueden admitir datos temporales y de series temporales de Teradata que se hayan migrado.

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 tiene previsto migrar esta funcionalidad desde el entorno de Teradata de origen, agregue el filtrado adicional a las consultas temporales pertinentes.

El entorno de Azure admite Time Series Insights para análisis complejos en datos de serie temporal a escala. Esta funcionalidad está destinada a aplicaciones de análisis de datos de IoT.

Diferencias de sintaxis de DML de SQL

Existen algunas diferencias de sintaxis del lenguaje de manipulación de datos de SQL (DML) entre Teradata SQL y Azure Synapse:

• 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...

• GROUP BY: para el ordinal GROUP BY, 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.

Funciones, procedimientos almacenados, desencadenadores y secuencias

Al migrar un almacenamiento de datos de un entorno consolidado como Teradata, a menudo es necesario migrar elementos que no sean tablas y vistas simples. Algunos ejemplos son las funciones, los procedimientos almacenados, los desencadenadores y las secuencias. Compruebe si las herramientas del entorno de Azure pueden reemplazar la funcionalidad de funciones, procedimientos almacenados y secuencias, ya que normalmente es más eficaz usar herramientas integradas de Azure que volver a codificar esos elementos para Azure Synapse.

Como parte de la fase de preparación, cree un inventario de objetos que deban migrarse, defina un método para controlarlos y asigne los recursos adecuados en el plan de migración.

Los asociados de integración de datos ofrecen herramientas y servicios que pueden automatizar la migración de funciones, procedimientos almacenados y secuencias.

En las secciones siguientes se describe aún más la migración de funciones, procedimientos almacenados y secuencias.

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 una implementación de SQL. Al migrar una plataforma de base de datos heredada a Azure Synapse, las funciones comunes del sistema normalmente 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 de Teradata o funciones arbitrarias definidas por el usuario que no tienen ningún equivalente en Azure Synapse, vuelva a codificar esas funciones mediante un lenguaje de entorno de destino. Azure Synapse usa el 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. En general, un procedimiento almacenado contiene instrucciones SQL y lógica de procedimiento, y puede devolver datos o un estado.

Azure Synapse admite procedimientos almacenados mediante T-SQL, por lo que debe volver a codificar los procedimientos almacenados migrados en ese lenguaje.

Desencadenadores

Azure Synapse no admite la creación de desencadenadores, pero se puede implementar con Azure Data Factory.

Secuencias

Azure Synapse controla secuencias de forma similar a Teradata y puede implementar secuencias mediante columnas IDENTITY o código SQL que genera el siguiente número de secuencia en una serie. Una secuencia proporciona valores numéricos únicos que puede usar como valores de clave suplente para las claves principales.

Extracción de metadatos y datos de un entorno de Teradata

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

El estándar SQL de ANSI define la sintaxis básica para los comandos DDL (Lenguaje de definición de datos). Algunos comandos DDL, como CREATE TABLE y CREATE VIEW, son comunes tanto a Teradata como a Azure Synapse, pero también proporcionan características específicas de la implementación, como la indexación, la distribución de tablas y las opciones de creación de particiones.

Puede editar los scripts CREATE TABLE y CREATE VIEW de Teradata existentes para lograr definiciones equivalentes en Azure Synapse. Para ello, es posible que tenga que usar tipos de datos modificados y quitar o modificar cláusulas específicas de Teradata, como FALLBACK.

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. Estas tablas son el mejor origen de esta información, ya que se garantiza que está actualizada y completa. Es posible que la documentación mantenida por el usuario no esté sincronizada con las definiciones actuales de la tabla.

En el entorno de Teradata, las tablas de catálogo del sistema especifican la definición de vista y tabla actual. A diferencia de la documentación mantenida por el usuario, la información del catálogo del sistema siempre está completa y sincronizada con las definiciones de tabla actuales. Mediante el uso de vistas en el catálogo, como DBC.ColumnsV, puede acceder a la información del catálogo del sistema para generar instrucciones DDL CREATE TABLE que creen tablas equivalentes en Azure Synapse.

Sugerencia

Use los metadatos de Teradata para automatizar la generación de DDL CREATE TABLE y CREATE VIEW para Azure Synapse.

También puede usar herramientas ETL y migración de terceros que procesan la información del catálogo del sistema para lograr resultados similares.

Extracción de datos de Teradata

Puede extraer datos de tabla sin procesar de tablas de Teradata a archivos delimitados planos, como archivos CSV, mediante utilidades estándar de Teradata como Basic Teradata Query (BTEQ), Teradata FastExport o Teradata Parallel Transporter (TPT). Use TPT para extraer los datos de tabla de la forma más eficaz posible. TPT usa varios flujos FastExport paralelos para lograr el mayor rendimiento.

Sugerencia

Use Teradata Parallel Transporter para la extracción más eficaz de los datos.

Llame a TPT directamente desde Azure Data Factory. Este es el enfoque recomendado para la migración de datos de instancias locales de Teradata e instancias de Teradata que se ejecutan dentro de una máquina virtual en el entorno de Azure.

Los archivos de datos extraídos deben contener texto delimitado en formato CSV, Optimized Row Columnar (ORC) o Parquet.

Para obtener más información sobre la migración de datos y ETL desde un entorno de Teradata, vea Migración, ETL y carga de datos para migraciones desde Teradata.

Recomendaciones de rendimiento para migraciones de Teradata

El objetivo de la optimización del rendimiento es obtener el mismo o mejor rendimiento del almacenamiento de datos después de la migración a Azure Synapse.

Sugerencia

Priorice la familiaridad con las opciones de optimización de Azure Synapse al principio de una migración.

Diferencias en el enfoque de optimización del rendimiento

En esta sección, se tratan las diferencias de implementación de nivel inferior entre Teradata y Azure Synapse para el ajuste del rendimiento.

Opciones de distribución de datos

Para el rendimiento, Azure Synapse se diseñó con arquitectura de varios nodos y usa el procesamiento paralelo. Para optimizar el rendimiento de las tablas individuales en Azure Synapse, puede definir una opción de distribución de datos en instrucciones CREATE TABLE mediante la instrucción DISTRIBUTION. Por ejemplo, puede especificar una tabla distribuida por hash, que distribuye filas de tabla entre nodos de proceso mediante una función hash determinista. El objetivo es reducir la cantidad de datos que se mueven entre los nodos de procesamiento al ejecutar una consulta.

Para combinar dos tablas de gran tamaño, distribuya una (lo ideal sería las dos) con una función hash en una de las columnas de la combinación que tenga un intervalo de valores amplio para ayudar a garantizar una distribución uniforme. Procese la combinación en modo local, puesto que las filas de datos que se van a combinar estarán ya en el mismo nodo de procesamiento.

Azure Synapse también admite combinaciones locales entre una tabla pequeña y una tabla grande mediante la replicación de tablas pequeñas. Por ejemplo, considere una tabla de dimensiones pequeña y una tabla de hechos grande en un modelo de esquema de estrella. Azure Synapse puede replicar la tabla de dimensiones más pequeña en todos los nodos para asegurarse de que el valor de cualquier clave de combinación para la tabla grande tenga una fila de dimensión disponible localmente coincidente. La sobrecarga de replicación de tablas de dimensiones es relativamente baja para una tabla de dimensiones pequeña. En el caso de las tablas de dimensiones grandes, un enfoque de distribución hash es más adecuado. Para obtener más información sobre las opciones de distribución de datos, vea Guía de diseño para usar tablas replicadas e Instrucciones para diseñar tablas distribuidas.

Indexación de datos

Azure Synapse proporciona varias opciones de indexación definidas por el usuario que son diferentes de las opciones de indexación implementadas en Teradata. Para obtener más información sobre las distintas opciones de indexación en Azure Synapse, consulte Indexaciones de tablas en un grupo de SQL dedicado.

Los índices existentes en el entorno de origen de Teradata pueden proporcionar indicaciones útiles de cómo se usan los datos y cuáles son las columnas candidatas a la indexación en el entorno de Azure Synapse.

Creación de particiones de datos

En un almacén de datos empresarial, las tablas de hechos pueden contener miles de millones de filas de datos. La creación de particiones optimiza el mantenimiento y el rendimiento de consultas de estas tablas al dividirlas en partes independientes para reducir la cantidad de datos que se procesan. En Azure Synapse, la especificación de particionamiento para una tabla se define en la instrucción CREATE TABLE. Solo particione tablas muy grandes y asegúrese de que cada partición contenga al menos 60 millones de filas.

En la creación de particiones, solo se puede usar un campo por tabla. Suele ser un campo de fecha porque muchas consultas se filtran por una fecha o un intervalo de fechas. Puede cambiar la creación de particiones de una tabla después de la carga inicial; para ello, vuelva a crear la tabla con la nueva distribución mediante la instrucción CREATE TABLE AS (o CTAS). Para obtener una explicación detallada de la creación de particiones en Azure Synapse, consulte Creación de particiones de tablas en el grupo de SQL dedicado.

Estadísticas de tablas de datos

Incluya un paso para las estadísticas en los trabajos de ETL/ELT para asegurarse de que las estadísticas de las tablas de datos están actualizadas.

PolyBase o COPY INTO para la carga de datos

PolyBase admite la carga eficaz de grandes cantidades de datos en un almacenamiento de datos mediante flujos de carga paralelos. Para más información, consulte Estrategia de carga de datos de PolyBase.

COPY INTO también admite la ingesta de datos de alto rendimiento y:

• Recuperación de datos de todos los archivos dentro de una carpeta y subcarpetas.

• Recuperación de datos desde varias ubicaciones en la misma cuenta de almacenamiento. Puede especificar varias ubicaciones mediante rutas de acceso separadas por comas.

• Azure Data Lake Storage (ADLS) y Azure Blob Storage.

• Formatos de archivo CSV, PARQUET y ORC.

Administración de cargas de trabajo

La ejecución de cargas de trabajo mixtas puede suponer desafíos de recursos en sistemas ocupados. Un esquema de administración de cargas de trabajo correcto administra los recursos de manera eficaz, garantiza un uso de recursos muy eficaz y maximiza la rentabilidad de la inversión (ROI). Los valores de clasificación de la carga de trabajo, importancia de la carga de trabajo y aislamiento de la carga de trabajo proporcionan más control sobre cómo la carga de trabajo utiliza los recursos del sistema.

La guía de administración de cargas de trabajo describe las técnicas para analizar la carga de trabajo y administrar y supervisar la importancia de la carga de trabajo, junto con los pasos necesarios para convertir una clase de recurso en un grupo de cargas de trabajo. Use Azure Portal y las consultas de T-SQL en DMV para supervisar la carga de trabajo para asegurarse de que los recursos aplicables se usan de forma eficaz.

Pasos siguientes

Para más información sobre ETL y carga para migraciones desde Teradata, lea el siguiente artículo de esta serie: Migración, ETL y carga de datos para migraciones desde Teradata.