Compartir vía

Migración de datos, ETL y carga para migraciones de Netezza

  • Artículo

Este artículo es la segunda parte de una serie de siete partes, que proporciona instrucciones sobre cómo migrar de Netezza a Azure Synapse Analytics. El artículo se centra en los procedimientos recomendados para la migración de ETL y la carga.

Consideraciones sobre la migración de datos

Decisiones iniciales para la migración de datos desde Netezza

Al migrar un almacenamiento de datos de Netezza, debe formularse 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 Netezza.

¿Migración de 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 metadatos del sistema y archivos de registro en lugar de documentación para determinar qué tablas están en uso, ya que la documentación puede estar obsoleta.

Si está habilitada, las tablas del historial de consultas de Netezza contienen información que puede determinar cuándo se accedió por última vez a una tabla determinada, que a su vez se puede usar para decidir si una tabla es candidata para la migración.

Esta es una consulta de ejemplo que busca el uso de una tabla específica dentro de un período de tiempo determinado:

SELECT FORMAT_TABLE_ACCESS (usage),
  hq.submittime
FROM "$v_hist_queries" hq
  INNER JOIN "$hist_table_access_3" hta USING
(NPSID, NPSINSTANCEID, OPID, SESSIONID)
WHERE hq.dbname = 'PROD'
AND hta.schemaname = 'ADMIN'
AND hta.tablename = 'TEST_1'
AND hq.SUBMITTIME > '01-01-2015'
AND hq.SUBMITTIME <= '08-06-2015'
AND
(
  instr(FORMAT_TABLE_ACCESS(usage),'ins') > 0
  OR instr(FORMAT_TABLE_ACCESS(usage),'upd') > 0
  OR instr(FORMAT_TABLE_ACCESS(usage),'del') > 0
)
AND status=0;

| FORMAT_TABLE_ACCESS | SUBMITTIME
----------------------+---------------------------
ins                   | 2015-06-16 18:32:25.728042
ins                   | 2015-06-16 17:46:14.337105
ins                   | 2015-06-16 17:47:14.430995
(3 rows)

Esta consulta usa la función auxiliar FORMAT_TABLE_ACCESS y el dígito al final de la vista $v_hist_table_access_3 para que coincida con la versión del historial de consultas instalada.

¿Cuál es el mejor enfoque de migración para minimizar el riesgo y el impacto de 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 de Azure para tareas de rediseño puntuales.

Al migrar desde Netezza, a menudo el modelo de datos existente ya es adecuado para la migración tal cual a Azure Synapse.

Sugerencia

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

Migración de data marts: ¿siguen siendo físicos o pasan a ser virtuales?

Sugerencia

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

En entornos de almacenamiento de datos de Netezza heredados, un procedimiento común es crear varios data marts estructurados para proporcionar un buen rendimiento para las consultas e informes ad hoc de autoservicio para una función de negocio o departamento determinados dentro de una organización. Por lo tanto, un data mart por lo general consta 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 a través 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 Netezza

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 datos sin procesar en el planeamiento.

Asignación de tipos de datos de Netezza

Sugerencia

Evalúe el impacto de los tipos de datos no admitidos como parte de la fase de preparación.

la mayoría de los tipos de datos de Netezza tienen un equivalente directo en Azure Synapse. En la siguiente tabla se muestran estos tipos de datos junto con el enfoque recomendado para asignarlos.

Tipo de dato de Netezza Tipo de datos de Azure Synapse
bigint bigint
BINARY VARYING(n) VARBINARY(n)
BOOLEAN BIT
BYTEINT TINYINT
CHARACTER VARYING(n) VARCHAR(n)
CHARACTER(n) CHAR(n)
DATE DATE(date)
DECIMAL(p,s) DECIMAL(p,s)
DOUBLE PRECISION FLOAT
FLOAT(n) FLOAT(n)
INTEGER INT
INTERVAL Actualmente, los tipos de datos INTERVAL no se admiten directamente en Azure Synapse Analytics, pero se pueden calcular mediante funciones temporales, como DATEDIFF.
MONEY MONEY
NATIONAL CHARACTER VARYING(n) NVARCHAR(n)
NATIONAL CHARACTER(n) NCHAR(n)
NUMERIC(p,s) NUMERIC(p,s)
real REAL
SMALLINT SMALLINT
ST_GEOMETRY(n) Los tipos de datos espaciales, como ST_GEOMETRY, actualmente no se admiten en Azure Synapse Analytics, pero los datos se pueden almacenar como VARCHAR o VARBINARY.
TIME TIME
TIME WITH TIME ZONE DATETIMEOFFSET
timestamp DATETIME

Use los metadatos de las tablas del catálogo de Netezza para decidir si alguno de estos tipos de datos se deben migrar y permitirlo en el plan de migración. Las vistas de metadatos importantes de Netezza para este tipo de consulta son:

  • _V_USER: la vista de usuario proporciona información sobre los usuarios del sistema de Netezza.

  • _V_TABLE: la vista de tabla contiene la lista de tablas creadas en el sistema de rendimiento de Netezza.

  • _V_RELATION_COLUMN: la vista de catálogo del sistema de columnas de relación contiene las columnas disponibles en una tabla.

  • _V_OBJECTS: la vista de objetos muestra los distintos objetos, como tablas, vistas, funciones, etc., que están disponibles en Netezza.

Por ejemplo, esta consulta SQL de Netezza muestra columnas y tipos de columna:

SELECT
tablename,
  attname AS COL_NAME,
  b.FORMAT_TYPE AS COL_TYPE,
  attnum AS COL_NUM
FROM _v_table a
  JOIN _v_relation_column b
  ON a.objid = b.objid
WHERE a.tablename = 'ATT_TEST'
AND a.schema = 'ADMIN'
ORDER BY attnum;

TABLENAME | COL_NAME    | COL_TYPE             | COL_NUM
----------+-------------+----------------------+--------
ATT_TEST  | COL_INT     | INTEGER              | 1
ATT_TEST  | COL_NUMERIC | NUMERIC(10,2)        | 2
ATT_TEST  | COL_VARCHAR | CHARACTER VARYING(5) | 3
ATT_TEST  | COL_DATE    | DATE                 | 4
(4 rows)

La consulta se puede modificar para buscar en todas las tablas las repeticiones de tipos de datos no admitidos.

Se puede usar Azure Data Factory para mover datos de un entorno de Netezza heredado. Para más información, consulte Conector de IBM Netezza.

Los proveedores externos ofrecen herramientas y servicios para automatizar la migración, incluida la asignación de tipos de datos, como se ha descrito anteriormente. Además, las herramientas ETL de terceros, como Informatica o Talend, que ya estén en uso en el entorno de Netezza, pueden implementar cualquier transformación de datos necesaria. En la sección siguiente se explora la migración de procesos ETL de terceros existentes.

Consideraciones sobre la migración ETL

Decisiones iniciales sobre la migración de Netezza ETL

Sugerencia

Planee el enfoque para la migración de ETL con antelación y aproveche las instalaciones de Azure cuando corresponda.

Para el procesamiento de ETL/ELT, los almacenamientos de datos heredados de Netezza pueden usar scripts personalizados mediante utilidades de Netezza, como nzsql y nzload, o herramientas de ETL de terceros como Informatica o Ab Initio. A veces, los almacenamientos de datos de Netezza usan una combinación de enfoques ETL y ELT que evolucionan con el tiempo. Al planear 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 implicados. Para obtener más información sobre el procesamiento de ETL y ELT, consulte Enfoque de diseño de ELT frente a ETL.

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:

Diagrama de flujo que muestra opciones y recomendaciones para la migración.

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 pasar a un entorno totalmente nativo de Azure, la decisión 2 es si ya está en uso una herramienta ETL de terceros existente.

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 Netezza existentes

Si algunos o todos los procesos ETL/ELT de almacenamiento de Netezza existentes se controlan mediante scripts personalizados que usan utilidades específicas de Netezza, como nzsql o nzload, estos scripts deben ser recodificados para el nuevo entorno de Azure Synapse. De forma similar, si los procesos ETL se implementaron mediante procedimientos almacenados en Netezza, también tendrán que ser recodificados.

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, mediante PolyBase en lugar de nzload. Otras partes del proceso que contienen SQL o procedimientos almacenados complejos arbitrarios tardarán más tiempo en volver a diseñarse.

Una manera de probar la compatibilidad de Netezza SQL con Azure Synapse consiste en capturar algunas instrucciones SQL representativas del historial de consultas de Netezza y, a continuación, prefijar esas consultas con EXPLAIN. A continuación, (suponiendo que tiene un modelo de datos migrado similar al de Azure Synapse) ejecute esas instrucciones EXPLAIN en Azure Synapse. Cualquier SQL incompatible generará un error y la información de error puede determinar la escala de la tarea de recodificación.

Los partners de Microsoft ofrecen herramientas y servicios para migrar Netezza SQL y procedimientos almacenados 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.

Carga de datos desde Netezza

Opciones disponibles al cargar datos desde Netezza

Sugerencia

Las herramientas de terceros 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 Netezza, hay algunas preguntas básicas asociadas a la carga de datos que deben resolverse. Deberá decidir cómo se moverán físicamente los datos del entorno local de Netezza existente a Azure Synapse en la nube y qué herramientas se usarán para realizar la transferencia y 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

Comprenda los volúmenes de datos que se van a migrar y el ancho de banda de red disponible, ya que estos factores influyen en la decisión del enfoque de migración.

Una vez que las tablas de base de datos que se van a migrar se han creado en Azure Synapse, puede mover los datos para rellenar esas tablas fuera del sistema de Netezza heredado y dentro del nuevo entorno. Existen dos enfoques básicos:

  • Extracción de archivos: extraiga los datos de las tablas de Netezza en archivos planos, normalmente en formato CSV, a través de nzsql con la opción -o o a través de la instrucción CREATE EXTERNAL TABLE. Use una tabla externa siempre que sea posible, ya que es la más eficaz en términos de rendimiento de datos. En el ejemplo SQL siguiente, se crea un archivo CSV a través de una tabla externa:

    CREATE EXTERNAL TABLE '/data/export.csv' USING (delimiter ',')
AS SELECT col1, col2, expr1, expr2, col3, col1 || col2 FROM your table;

    Use una tabla externa si va a exportar datos a un sistema de archivos montado en un host de Netezza local. Si va a exportar datos a una máquina remota que tiene JDBC, ODBC u OLEDB instalados, la opción "remotesource odbc" es la cláusula USING.

    Este enfoque requiere espacio para colocar los archivos de datos extraídos. El espacio podría ser local para la base de datos de origen de Netezza (si hay suficiente almacenamiento disponible) o remoto en Azure Blob Storage. El mejor rendimiento se logra 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 mediante 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 varias 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 para archivos que se mueven a un dispositivo de almacenamiento físico que luego se envían a un centro de datos de Azure para cargarlos. Para obtener más información, vea Transferencia de datos.

  • 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 a través de un comando SQL, al sistema de Netezza 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 Netezza y el entorno de Azure. En el caso de volúmenes de datos muy grandes, este enfoque puede no ser práctico.

También hay un enfoque híbrido que usa ambos métodos. Por ejemplo, puede usar el enfoque de extracción de red directa 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. En el caso de las tablas de hechos históricos de gran volumen, puede usar el enfoque de extracción y transferencia de archivos mediante Azure Data Box.

¿Orquesta desde Netezza o Azure?

El enfoque recomendado al pasar a Azure Synapse es organizar la extracción y carga de datos desde el entorno de Azure mediante Azure Synapse Pipelines o Azure Data Factory, así como las utilidades asociadas, como PolyBase o COPY INTO, para la carga de datos más eficaz. Este enfoque aprovecha las funcionalidades 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 Netezza 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 ETL. Si uno de estos productos ya está en uso en el entorno de Netezza existente, el uso de la herramienta ETL existente puede simplificar la migración de datos de Netezza a Azure Synapse. Este enfoque supone que la herramienta ETL admite Azure Synapse como entorno de destino. Para más información sobre las herramientas que admiten Azure Synapse, consulte Asociados de integración de datos.

Si usa una herramienta ETL, considere la posibilidad de ejecutar esa herramienta en el entorno de Azure para beneficiarse del rendimiento de la nube de Azure, la escalabilidad y el costo, y liberar recursos en el centro de datos de Netezza. Otra ventaja es reducir el movimiento de datos entre la nube y los entornos locales.

Resumen

En resumen, nuestras recomendaciones para migrar datos y procesos ETL asociados de Netezza a Azure Synapse son:

  • Planee con antelación para garantizar un ejercicio de migración correcto.

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

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

  • 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 Netezza y Azure. Usar las herramientas adecuadas en cada fase del proceso.

  • Use las instalaciones de Azure, como Azure Synapse Pipelines o Azure Data Factory, para orquestar y automatizar el proceso de migración, a la vez que minimiza el impacto en el sistema de Netezza.

Pasos siguientes

Para 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 Netezza.