Migración, ETL y carga de datos para migraciones desde Teradata

Este artículo es el segundo de una serie de siete artículos y proporciona instrucciones para migrar de Teradata a Azure Synapse Analytics. El artículo se centra en los procedimientos recomendados para la migración de ETL y cargas.

Consideraciones sobre la migración de datos

Decisiones iniciales para la migración de datos desde Teradata

Al migrar un almacenamiento de datos de Teradata, debe hacerse algunas preguntas básicas relacionadas con los datos. Por ejemplo:

• ¿Deben migrarse las estructuras de tabla sin usar?

• ¿Cuál es la mejor estrategia de migración para minimizar el riesgo y el impacto en los usuarios?

• Cuando se migran data marts, ¿siguen siendo físicos o pasan a ser virtuales?

En las secciones siguientes, se describen estos puntos en el contexto de la migración desde Teradata.

¿Deben migrarse las tablas sin usar?

Sugerencia

En los sistemas heredados, es habitual que las tablas se vuelvan redundantes a lo largo del tiempo; no es necesario migrarlas en la mayoría de los casos.

Solo tiene sentido migrar tablas que están en uso en el sistema existente. Las tablas que no están activas se pueden archivar en lugar de migrarse, de modo que los datos estén disponibles si es necesario en el futuro. Es mejor usar los metadatos del sistema y los archivos de registro en lugar de la documentación para determinar qué tablas están en uso, ya que la documentación puede estar obsoleta.

Si están habilitados, los registros y las tablas del catálogo del sistema de Teradata contienen información que puede determinar cuándo se accedió por última vez a una tabla determinada, lo que se puede usar para decidir si una tabla es candidata para la migración.

La siguiente es una consulta de ejemplo en DBC.Tables que proporciona la fecha del último acceso y la última modificación:

SELECT TableName, CreatorName, CreateTimeStamp, LastAlterName,
LastAlterTimeStamp, AccessCount, LastAccessTimeStamp 
FROM DBC.Tables t
WHERE DataBaseName = 'databasename'

Si el registro está habilitado y se puede acceder al historial de registros, hay más información, como el texto de las consultas SQL, disponible en la tabla DBQLogTbl y en las tablas de registro asociadas. Para obtener más información, consulte la documentación sobre el historial de registros de Teradata.

¿Cuál es la mejor estrategia de migración para minimizar el riesgo y el impacto en los usuarios?

Esta pregunta surge con frecuencia, ya que las empresas suelen querer reducir el impacto de los cambios en el modelo de datos del almacenamiento de datos para mejorar la agilidad. A menudo, las empresas ven una oportunidad para modernizar o transformar aún más sus datos durante una migración de ETL. Este enfoque conlleva un mayor riesgo, porque cambia varios factores simultáneamente, lo que dificulta la comparación de los resultados del sistema antiguo con el nuevo. Realizar cambios en el modelo de datos aquí también podría afectar a los trabajos ETL del flujo ascendente o descendente a otros sistemas. Debido a ese riesgo, es mejor modificar el diseño en esta escala después de la migración del almacenamiento de datos.

Incluso si se cambia intencionadamente un modelo de datos como parte de la migración global, es aconsejable migrar el modelo actual tal cual está a Azure Synapse, en lugar de rediseñarlo en la nueva plataforma. Este enfoque minimiza el efecto en los sistemas de producción actuales, a la vez que se beneficia del rendimiento y la escalabilidad elástica de la plataforma Azure para tareas de rediseño puntuales.

Al migrar desde Teradata, considere la posibilidad de crear un entorno de Teradata en una máquina virtual de Azure como paso intermedio en el proceso de migración.

Sugerencia

Migre el modelo existente tal cual inicialmente, incluso si se planea un cambio en el modelo de datos en el futuro.

Uso de una instancia de Teradata en una máquina virtual durante una migración

Un enfoque opcional para la migración desde un entorno de Teradata local consiste en sacar provecho del entorno de Azure para crear una instancia de Teradata en una máquina virtual de Azure, coubicada con el entorno de Azure Synapse de destino. Esto es posible porque Azure proporciona almacenamiento en la nube económico y escalabilidad elástica.

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 la máquina virtual. A continuación, se pueden realizar todas las tareas de migración en el entorno de Azure. Este enfoque tiene varias ventajas:

• Después de la replicación inicial de los datos, las tareas de migración no afectan al sistema de origen.

• El entorno de Azure tiene interfaces, herramientas y utilidades de Teradata que ya conoce.

• El entorno de Azure proporciona disponibilidad de 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.

Cuando se migran data marts, ¿siguen siendo físicos o pasan a ser virtuales?

Sugerencia

La virtualización de data marts puede ahorrar recursos de almacenamiento y procesamiento.

En entornos de almacenamiento de datos de Teradata heredados, es una práctica común crear varios data marts estructurados para proporcionar un buen rendimiento de las consultas e informes ad hoc de autoservicio para una función de negocio o departamento determinados de una organización. Por tanto, un data mart consta normalmente de un subconjunto del almacenamiento de datos y contiene versiones agregadas de los datos en un formato que permite a los usuarios consultar fácilmente esos datos con tiempos de respuesta rápidos, por medio de herramientas de consulta fáciles de usar, como Microsoft Power BI, Tableau o MicroStrategy. Este formulario suele ser un modelo de datos dimensional. Un uso de los data marts es exponer los datos en un formato utilizable, incluso si el modelo de datos del almacenamiento subyacente es algo distinto (como, por ejemplo, un almacén de datos).

Puede usar data marts independientes para unidades de negocio individuales dentro de una organización para implementar regímenes de seguridad de datos sólidos, ya que solo permiten el acceso de los usuarios a los data marts específicos que les interesan y eliminan, ofuscan o anonimizan información confidencial.

Si estos data marts se implementan como tablas físicas, requieren recursos de almacenamiento adicionales para almacenarlos y también procesamiento adicional para compilarlos y actualizarlos de forma periódica. Asimismo, los datos del data mart solo estarán actualizados según la última operación de actualización, por lo que puede que no sea adecuado para los paneles de datos altamente volátiles.

Sugerencia

El rendimiento y la escalabilidad de Azure Synapse permite la virtualización sin sacrificar el rendimiento.

Con la llegada de arquitecturas de MPP escalables relativamente baratas, como Azure Synapse, y sus características de rendimiento inherentes de dichas arquitecturas, es posible que pueda proporcionar esa funcionalidad de data mart sin tener que crear una instancia del data mart como un conjunto de tablas físicas. Esto se consigue mediante la virtualización eficaz de los data marts a través de vistas SQL en el almacenamiento de datos principal o a través de una capa de virtualización con características como vistas de Azure o los productos de visualización de partners de Microsoft. Este enfoque simplifica o elimina la necesidad de almacenamiento adicional y el procesamiento de agregaciones y disminuye el número total de objetos de base de datos que se van a migrar.

Este enfoque ofrece otra ventaja potencial. Mediante la implementación de la lógica de agregación y combinación dentro de una capa de virtualización y la presentación de herramientas de informes externas por medio una vista virtualizada, el procesamiento necesario para crear estas vistas se "inserta" en el almacenamiento de datos, que suele ser el mejor lugar para ejecutar combinaciones, agregaciones y otras operaciones relacionadas en grandes volúmenes de datos.

Los principales controladores para elegir una implementación de data mart virtual en un data mart físico son:

• Más agilidad, porque un data mart virtual es más fácil de cambiar que las tablas físicas y los procesos de ETL asociados.

• Menor costo total de propiedad: una implementación virtualizada necesita menos almacenes y copias de datos.

• Eliminación de trabajos ETL para migrar y simplificar arquitectura de almacenamiento de datos en un entorno virtualizado.

• Rendimiento: aunque los data marts físicos han sido tradicionalmente más eficaces, ahora los productos de virtualización implementan técnicas de almacenamiento en caché inteligente para mitigar la menor eficacia del formato virtual.

Migración de datos desde Teradata

Comprensión de los datos

Parte del planeamiento de la migración es comprender en detalle el volumen de datos que se deben migrar, ya que puede afectar a las decisiones sobre el enfoque de migración. Use los metadatos del sistema para determinar el espacio físico que ocupan los datos "sin procesar" en las tablas que se van a migrar. En este contexto, el término "datos sin procesar" significa la cantidad de espacio utilizado por las filas de datos de una tabla, sin incluir sobrecargas, como los índices y la compresión. Esto es especialmente cierto para las tablas de hechos más grandes, ya que normalmente comprenden más del 95 % de los datos.

Puede obtener un número preciso para el volumen de datos que se van a migrar para una tabla determinada mediante la extracción de una muestra representativa de los datos (por ejemplo, un millón de filas) a un archivo de datos ASCII sin comprimir. A continuación, use el tamaño de ese archivo para obtener un tamaño medio de datos sin procesar por fila de esa tabla. Por último, multiplique ese tamaño medio por el número total de filas de la tabla completa para proporcionar un tamaño de datos sin procesar para la tabla. Use ese tamaño de los datos sin procesar en el planeamiento.

Consideraciones sobre la migración de procesos ETL

Decisiones iniciales sobre la migración de procesos ETL de Teradata

Sugerencia

Planee con tiempo el enfoque para la migración de los procesos ETL y aproveche las características de Azure cuando proceda.

Para el procesamiento ETL/ELT, los almacenes de datos heredados de Teradata pueden utilizar scripts personalizados que usan utilidades de Teradata, como BTEQ y Teradata Parallel Transporter (TPT), o herramientas de ETL de terceros, como Informatica o Ab Initio. A veces, los almacenes de datos de Teradata usan una combinación de enfoques para ETL y ELT que han evolucionado con el tiempo. Cuando planee una migración a Azure Synapse, debe determinar la mejor manera de implementar el procesamiento ETL/ELT necesario en el nuevo entorno, a la vez que minimiza el costo y el riesgo. Para obtener más información sobre el procesamiento ETL y ELT, consulte Estrategias de carga de datos para el grupo de SQL dedicado en Azure Synapse Analytics.

En las secciones siguientes se describen las opciones de migración y se realizan recomendaciones para varios casos de uso. Este diagrama de flujo resume un enfoque:

El primer paso es siempre crear un inventario de procesos ETL/ELT que deben migrarse. Al igual que en otros pasos, es posible que las características estándar "integradas" de Azure eviten la necesidad de migrar algunos procesos existentes. Con fines de planeación, es importante comprender la escala de la migración que se va a realizar.

En el diagrama de flujo anterior, la decisión 1 se relaciona con una decisión de alto nivel sobre si se va a migrar a un entorno totalmente nativo de Azure. Si va a pasar a un entorno totalmente nativo de Azure, se recomienda volver a diseñar el procesamiento de ETL mediante Pipelines y actividades en Azure Data Factory o Azure Synapse Pipelines. Si no va a migrar a un entorno totalmente nativo de Azure, la decisión 2 es sobre si ya se utiliza una herramienta de ETL de terceros.

En el entorno de Teradata, algunos o todos los procesos ETL se pueden realizar con scripts personalizados que usen utilidades específicas de Teradata, como BTEQ y TPT. En este caso, el enfoque debe ser volver a diseñarlos con Data Factory.

Sugerencia

Aproveche la inversión en herramientas de terceros existentes para reducir el costo y el riesgo.

Si ya está en uso una herramienta ETL de terceros y, especialmente, si hay una gran inversión en aptitudes o en varios flujos de trabajo y programaciones existentes, la decisión 3 es si la herramienta puede admitir de forma eficaz Azure Synapse como entorno de destino. Lo ideal es que la herramienta incluya conectores "nativos" que puedan aprovechar las características de Azure, como PolyBase o COPY INTO, para la carga de datos más eficaz. Hay una manera de llamar a un proceso externo, como PolyBase o COPY INTO, y pasar los parámetros adecuados. En este caso, aproveche las aptitudes y los flujos de trabajo existentes, con Azure Synapse como el nuevo entorno de destino.

Si decide conservar una herramienta ETL de terceros existente, puede haber ventajas en la ejecución de esa herramienta en el entorno de Azure (en lugar de en un servidor ETL local existente) y hacer que Azure Data Factory controle la orquestación general de los flujos de trabajo existentes. Una ventaja concreta es que es necesario descargar menos datos de Azure, procesarlos y, a continuación, volver a cargarlos en Azure. Por tanto, la decisión 4 es sobre si dejar la herramienta que ya hay ejecutándose tal cual o moverla al entorno de Azure para lograr ventajas de costo, rendimiento y escalabilidad.

Volver a diseñar scripts específicos de Teradata

Si algunos o todos los procesos ETL/ELT de almacenamiento de Teradata actuales se controlan mediante scripts personalizados que usan utilidades específicas de Teradata, como BTEQ, MLOAD o TPT, esos scripts deben volver a programarse para el nuevo entorno de Azure Synapse. De forma similar, si los procesos ETL se implementaron con procedimientos almacenados en Teradata, también habrá que volver a programarlos.

Sugerencia

El inventario de tareas ETL que se van a migrar debe incluir scripts y procedimientos almacenados.

Algunos elementos del proceso ETL son fáciles de migrar, por ejemplo, mediante una simple carga de datos masiva en una tabla de almacenamiento provisional desde un archivo externo. Incluso puede ser posible automatizar esas partes del proceso, por ejemplo, con PolyBase en lugar de una carga rápida o MLOAD. Si los archivos exportados son Parquet, puede usar un lector nativo de Parquet, que es una opción más rápida que PolyBase. Otras partes del proceso que contengan código SQL y/o procedimientos almacenados arbitrarios complejos precisarán más tiempo para volver a diseñarlos.

Una manera de probar el código de Teradata SQL para comprobar la compatibilidad con Azure Synapse consiste en capturar algunas instrucciones SQL representativas de los registros de Teradada, agregar el prefijo EXPLAIN a esas consultas y (suponiendo que es un modelo de datos migrado “igual por igual” a Azure Synapse) ejecutar esas instrucciones EXPLAIN en Azure Synapse. Cualquier código SQL incompatible producirá un error y la información de los errores puede determinar la escala de la tarea de programarlo de nuevo.

Asociados de Microsoft ofrecen herramientas y servicios para migrar código SQL y procedimientos almacenados de Teradata a Azure Synapse.

Uso de herramientas de ETL de terceros

Como se describe en la sección anterior, en muchos casos el sistema de almacenamiento de datos heredado existente ya se rellenará y mantendrá mediante productos ETL de terceros. Para obtener una lista de asociados de integración de datos de Microsoft para Azure Synapse, consulte Asociados de integración de datos de Azure Synapse Analytics.

Carga de datos desde Teradata

Opciones disponibles para cargar datos desde Teradata

Sugerencia

Hay herramientas de terceros que pueden simplificar y automatizar el proceso de migración y, por tanto, reducir el riesgo.

En lo que respecta a la migración de datos desde un almacenamiento de datos de Teradata, hay algunas preguntas básicas asociadas a la carga de datos que deben resolverse. Tendrá que decidir cómo se moverán físicamente los datos del entorno de Teradata local a Azure Synapse en la nube y qué herramientas se usarán para realizar la transferencia y la carga. Tenga en cuenta las siguientes preguntas, que se describen en las secciones que siguen a continuación.

• ¿Extraerá los datos a los archivos o los moverá directamente a través de una conexión de red?

• ¿Orquestará el proceso desde el sistema de origen o desde el entorno de destino de Azure?

• ¿Qué herramientas usará para automatizar y administrar el proceso?

¿Transferir datos a través de archivos o conexiones de red?

Sugerencia

Debe conocer los volúmenes de datos que se van a migrar y el ancho de banda de red disponible, ya que estos factores influyen a la hora de decidir la estrategia de migración.

Una vez que se crean en Azure Synapse las tablas de base de datos que se van a migrar, puede sacar los datos del sistema de Teradata heredado y cargarlos en el nuevo entorno para rellenar esas tablas. Hay dos enfoques básicos:

• Extracción de archivos: extraiga los datos de las tablas de Teradata a archivos sin formato (normalmente en formato CSV) por medio de BTEQ, Fast Export o Teradata Parallel Transporter (TPT). Use TPT siempre que sea posible, porque es el más eficaz en términos de procesamiento de datos.

  Este enfoque requiere espacio para colocar los archivos de datos extraídos. El espacio puede local, donde se encuentra la base de datos de origen de Teradata (si hay suficiente almacenamiento disponible), o remoto en Azure Blob Storage. El mejor rendimiento se consigue cuando un archivo se escribe localmente, ya que evita la sobrecarga de red.

  Para minimizar los requisitos de transferencia de red y almacenamiento, se recomienda comprimir los archivos de datos extraídos con una utilidad como gzip.

  Una vez extraídos, los archivos sin formato se pueden mover a Azure Blob Storage (coubicados con la instancia de Azure Synapse de destino) o cargarse directamente en Azure Synapse con PolyBase o COPY INTO. El método para mover físicamente los datos del almacenamiento local al entorno en la nube de Azure depende de la cantidad de datos y del ancho de banda de red disponible.

  Microsoft proporciona diferentes opciones para mover grandes volúmenes de datos, como AZCopy para mover archivos a través de la red a Azure Storage, Azure ExpressRoute para mover datos masivos a través de una conexión de red privada, y Azure Data Box, donde los archivos se mueven a un dispositivo de almacenamiento físico que luego se envía a un centro de datos de Azure para su carga. Para obtener más información, vea Transferencia de datos hacia y desde Azure.

• Extracción y carga directa a través de la red: el entorno de Azure de destino envía una solicitud de extracción de datos, normalmente por medio de un comando SQL, al sistema de Teradata heredado para extraer los datos. Los resultados se envían a través de la red y se cargan directamente en Azure Synapse, sin necesidad de colocar los datos en archivos intermedios. El factor de limitación de este escenario suele ser el ancho de banda de la conexión de red entre la base de datos de Teradata y el entorno de Azure. Para volúmenes de datos muy grandes, este enfoque puede no ser práctico.

También hay un enfoque híbrido que usa los dos métodos. Por ejemplo, puede usar el enfoque de extracción directa a través de la red para tablas de dimensiones más pequeñas y muestras de las tablas de hechos más grandes para proporcionar rápidamente un entorno de prueba en Azure Synapse. Para las tablas de hechos históricos de gran volumen, puede usar el enfoque de extracción y transferencia de archivos con Azure Data Box.

¿Orquestar el proceso desde Teradata o desde Azure?

El enfoque recomendado para migrar a Azure Synapse es orquestar la extracción y carga de los datos desde el entorno de Azure con Azure Synapse Pipelines o Azure Data Factory, junto con las utilidades relacionadas, como PolyBase o COPY INTO, para lograr la carga de datos más eficaz. Este enfoque aprovecha la funcionalidad de Azure y proporciona un método sencillo para crear canalizaciones de carga de datos reutilizables.

Otras ventajas de este enfoque son un impacto reducido en el sistema de Teradata durante el proceso de carga de datos, ya que el proceso de administración y carga se ejecuta en Azure, y la capacidad de automatizar el proceso mediante canalizaciones de carga de datos controladas por metadatos.

¿Qué herramientas se pueden usar?

La tarea de transformación y movimiento de datos es la función básica de todos los productos de ETL. Si ya se utiliza alguno de estos productos en el entorno de Teradata, el uso de esa herramienta de ETL puede simplificar la migración de datos de Teradata a Azure Synapse. Este enfoque supone que la herramienta ETL admite Azure Synapse como entorno de destino. Para obtener más información sobre las herramientas que admiten Azure Synapse, consulte Asociados de integración de datos de Azure Synapse Analytics.

Si usa una herramienta de ETL, considere la posibilidad de ejecutar esa herramienta en el entorno de Azure para beneficiarse del rendimiento, la escalabilidad y el costo de la nube de Azure y liberar recursos en el centro de datos de Teradata. Otra ventaja es la reducción del movimiento de datos entre la nube y el entorno local.

Resumen

En resumen, nuestras recomendaciones para migrar datos y los procesos ETL asociados desde Teradata a Azure Synapse son:

• Planear con antelación para garantizar una operación de migración satisfactoria.

• Cree un inventario detallado de datos y procesos que se van a migrar lo antes posible.

• Use los metadatos del sistema y los archivos de registro para obtener una comprensión precisa del uso de datos y procesos. No confíe en la documentación, ya que puede estar obsoleta.

• Conocer los volúmenes de datos que se van a migrar y el ancho de banda de red entre el centro de datos local y los entornos en la nube de Azure.

• Considerar la posibilidad de usar una instancia de Teradata en una máquina virtual de Azure como paso intermedio de la migración desde el entorno heredado de Teradata.

• Sacar provecho de las características estándar "integradas" de Azure para minimizar la carga de trabajo de migración.

• Identificar y conocer las herramientas más eficaces para la extracción y carga de datos en los entornos de Teradata y Azure. Usar las herramientas adecuadas en cada fase del proceso.

• Usar características de Azure, como Azure Synapse Pipelines o Azure Data Factory, para orquestar y automatizar el proceso de migración, a la vez que se minimiza el impacto en el sistema de Teradata.

Pasos siguientes

Para obtener más información sobre las operaciones de acceso de seguridad, consulte el siguiente artículo de esta serie: Seguridad, acceso y operaciones para migraciones de Teradata.