Visualización e informes para migraciones de Oracle

Este artículo es la cuarta parte de una serie de siete partes, que proporciona instrucciones sobre cómo migrar de Oracle a Azure Synapse Analytics. Este artículo se centra en los procedimientos recomendados con fines de visualización y generación de informes.

Acceso a Azure Synapse Analytics mediante herramientas de BI de Microsoft y de terceros

Las organizaciones acceden a almacenes de datos y data marts mediante una gama de aplicaciones y herramientas de inteligencia empresarial (BI). Algunos ejemplos de productos de BI son los siguientes:

• Herramientas de Microsoft BI, como Power BI.

• Aplicaciones de Office, como hojas de cálculo de Microsoft Excel.

• Herramientas de BI de terceros de varios proveedores.

• Aplicaciones de análisis personalizadas con la función de la herramienta de BI insertada.

• Aplicaciones operativas que admiten BI a petición ejecutando consultas e informes en una plataforma de BI que, a su vez, consulta datos en un almacenamiento de datos o data mart.

• Herramientas de desarrollo de ciencia de datos interactivas, como Azure Synapse Spark Notebooks, Azure Machine Learning, RStudio y Jupyter Notebooks.

Si migra la visualización y los informes como parte de la migración del almacenamiento de datos, todas las consultas, informes y paneles existentes que han generado los productos de BI deben ejecutarse en el entorno nuevo. Los productos de BI deben producir los mismos resultados en Azure Synapse que en el entorno de almacenamiento de datos heredado.

Para obtener resultados coherentes después de la migración, todas las herramientas de BI y las dependencias de la aplicación deben funcionar después de que haya migrado el esquema y los datos del almacenamiento de datos a Azure Synapse. Las dependencias incluyen aspectos menos visibles, como el acceso y la seguridad. Al abordar el acceso y la seguridad, asegúrese de migrar lo siguiente:

• La autenticación, de modo que los usuarios puedan iniciar sesión en el almacenamiento de datos y en las bases de datos de data mart en Azure Synapse.

• Todos los usuarios a Azure Synapse.

• Todos los grupos de usuarios a Azure Synapse.

• Todos los roles a Azure Synapse.

• Todos los privilegios de autorización que rigen el control de acceso a Azure Synapse.

• Las asignaciones de usuarios, roles y privilegios para reflejar lo que tenía en el almacenamiento de datos existente antes de la migración. Por ejemplo:

  • Privilegios de objeto de base de datos asignados a roles
  • Roles asignados a grupos de usuarios
  • Usuarios asignados a grupos de usuarios o roles

El acceso y la seguridad son consideraciones importantes para acceder a los datos en el sistema migrado y se abordan con más detalle en Seguridad, acceso y operaciones para migraciones de Oracle.

Migre todos los datos necesarios para asegurarse de que los informes y paneles que consultan datos en el entorno heredado producen los mismos resultados en Azure Synapse.

Los usuarios empresariales esperarán una migración fluida, sin sorpresas que minen su confianza en el sistema migrado en Azure Synapse. Ocúpese de disipar cualquier temor que los usuarios puedan tener mediante una buena comunicación. Los usuarios esperarán lo siguiente:

• Que la estructura de la tabla permanezca igual cuando se haga referencia directamente a ella en las consultas.

• Que los nombres de tabla y columna permanezcan iguales cuando se haga referencia directamente a ellos en las consultas. Por ejemplo, los campos calculados definidos en las columnas de las herramientas de BI no deben producir errores cuando se generan informes agregados.

• El análisis histórico siga siendo el mismo.

• Si es posible, los tipos de datos deben permanecer iguales.

• El comportamiento de la consulta siga siendo el mismo.

• Los controladores ODBC/JDBC se prueban para asegurarse de que el comportamiento de las consultas sigue siendo el mismo.

Si las herramientas de BI consultan vistas en el almacenamiento de datos subyacente o en la base de datos data mart, ¿esas vistas seguirán funcionando después de la migración? Es posible que algunas vistas no funcionen si hay extensiones SQL de su propiedad específicas del DBMS de almacenamiento de datos heredado que no tienen ningún equivalente en Azure Synapse. Si es así, debe conocer esas incompatibilidades y encontrar una manera de resolverlas.

Otros problemas, como el comportamiento de los valores NULL o las variaciones de tipo de datos en las plataformas del DBMS, deben probarse para asegurarse de que no existen pequeñas diferencias en los resultados del cálculo. Minimice esos problemas y realice todos los pasos necesarios para proteger a los usuarios empresariales y que no les afecten. En función del entorno de almacenamiento de datos heredado, las herramientas de terceros que pueden ayudar a ocultar las diferencias entre los entornos heredados y nuevos, de modo que las herramientas de BI y las aplicaciones se ejecuten sin cambios.

Las pruebas son críticas para la visualización y la migración de informes. Necesita un conjunto de pruebas y datos de prueba acordados para ejecutar y volver a ejecutar pruebas en ambos entornos. Una herramienta de ejecución de pruebas también es útil y algunas se mencionan en esta guía. Además, es importante que los usuarios empresariales participen en la fase de pruebas de la migración para mantener una confianza elevada y, de este modo, que sigan involucrados y formen parte del proyecto.

Es posible que esté pensando en cambiar las herramientas de BI, por ejemplo, para migrar a Power BI. La tentación es hacer estos cambios al mismo tiempo en que se migra el esquema, los datos, el procesamiento de ETL, etc. Sin embargo, para minimizar el riesgo, es mejor migrar a Azure Synapse primero y poner todo en funcionamiento antes de realizar una mayor modernización.

Si las herramientas de BI existentes se ejecutan en el entorno local, asegúrese de que pueden conectarse a Azure Synapse mediante el firewall para ejecutar comparaciones en ambos entornos. Como alternativa, si el proveedor de las herramientas de BI existentes ofrece su producto en Azure, puede probarlo allí. Lo mismo se aplica a las aplicaciones que se ejecutan en el entorno local que insertan BI o que llaman a su servidor de BI a petición, por ejemplo, solicitando un "informe sin encabezado" con los datos XML o JSON.

Hay mucho que analizar aquí, así que echemos un vistazo más de cerca.

Uso de la virtualización de datos para minimizar el impacto de la migración en informes y herramientas de BI

Durante la migración, es posible que tenga la tentación de cumplir los requisitos a largo plazo, como abrir solicitudes empresariales, agregar datos que faltan o implementar características nuevas. Pero estos cambios pueden afectar al acceso de herramientas de BI al almacenamiento de datos, especialmente si el cambio implica cambios estructurales en el modelo de datos. Si desea adoptar una técnica de modelado ágil de datos o implementar cambios estructurales, hágalo después de la migración.

Una manera de minimizar el impacto de los cambios de esquema u otros cambios estructurales en las herramientas de BI consiste en introducir la virtualización de datos entre las herramientas de BI y el almacenamiento de datos y los data marts. En el diagrama siguiente se muestra cómo la virtualización de datos puede ocultar una migración a los usuarios.

La virtualización de datos rompe la dependencia entre los usuarios empresariales que usan herramientas de BI de autoservicio y el esquema físico del almacenamiento de datos y los data marts subyacentes que se van a migrar.

Con la virtualización de los datos, cualquier modificación de esquema realizada durante una migración a Azure Synapse (por ejemplo, para optimizar el rendimiento) se puede ocultar a los usuarios empresariales porque solo tienen acceso a las tablas virtuales de la capa de virtualización de datos. Además, si realiza cambios estructurales, solo tendrá que actualizar las asignaciones entre el almacenamiento de datos o data marts y las tablas virtuales. Con la virtualización de datos, los usuarios siguen sin darse cuenta de los cambios estructurales. Los asociados de Microsoft proporcionan software de virtualización de datos.

Identificación de informes de prioridad alta para migrar primero

Una pregunta clave al migrar los informes y paneles existentes a Azure Synapse es cuáles se van a migrar primero. Varios factores pueden impulsar esa decisión, como los siguientes:

• Uso

• Valor empresarial

• Facilidad de migración

• Estrategia de migración de datos

En las secciones siguientes se describen estos factores.

Sea cual sea su decisión, debe implicar a los usuarios empresariales porque generan los informes, paneles y otras visualizaciones, y toman decisiones empresariales basadas en información extraída de esos elementos. Todos se benefician cuando se puede realizar lo siguiente:

• Migrar informes y paneles sin problemas.
• Migrar informes y paneles con un esfuerzo mínimo.
• Apuntar las herramientas de BI en Azure Synapse en lugar del sistema de almacenamiento de datos heredado, y obtener informes, paneles y otras visualizaciones equivalentes.

Migración de informes basados en el uso

El uso a veces es un indicador del valor empresarial. Los informes y paneles no utilizados no contribuyen para nada en las decisiones empresariales ni ofrecen valor actual. Si no tiene forma de averiguar los informes y paneles que no se usan, puede usar una de las varias herramientas de BI que proporcionan estadísticas de uso.

Si el almacenamiento de datos heredado ha estado en funcionamiento durante años, es bastante probable que tenga cientos, si no miles, de informes existentes. Vale la pena compilar un inventario de los informes y paneles, e identificar sus estadísticas de uso y propósito empresarial.

En el caso de los informes no utilizados, determine si se deben retirar para reducir el esfuerzo de la migración. Una pregunta clave al decidir si se debe retirar un informe sin usar es si el informe no se usa porque la gente no sabe que existe, porque no ofrece ningún valor empresarial o porque lo ha reemplazado otro informe.

Migración de informes basados en el valor empresarial

El uso por sí solo no siempre es un buen indicador del valor empresarial. Es posible que quiera tener en cuenta en qué medida la información de un informe contribuye al valor empresarial. Una manera de hacerlo es evaluar la rentabilidad de cada decisión empresarial que depende del informe y el alcance de la dependencia. Pero es poco probable que esa información esté disponible en la mayoría de las organizaciones.

Otra manera de evaluar el valor empresarial es examinar la convergencia de un informe con la estrategia empresarial. La estrategia empresarial que establece el ejecutivo suele establecer objetivos empresariales estratégicos (SBO), indicadores clave de rendimiento (KPI), objetivos de KPI que deben alcanzarse y quién es responsable de lograrlos. Puede clasificar un informe por los SBO a los que contribuye el informe, como la reducción de fraudes, la mejora en la involucración de los clientes y las operaciones empresariales optimizadas. Después, puede priorizar la migración de los informes y paneles asociados a los objetivos con prioridad alta. De este modo, la migración inicial puede ofrecer valor empresarial en un área estratégica.

Otra manera de evaluar el valor empresarial es clasificar informes y paneles como operativos, tácticos o estratégicos, para identificar en qué nivel empresarial se usan. Los SBO requieren contribuciones en todos estos niveles. Saber los informes y paneles que se usan, en qué nivel y a qué objetivos están asociados permite poder centrar la migración inicial en el valor empresarial de prioridad alta. Puede usar la siguiente tabla de objetivos estratégicos empresariales para evaluar informes y paneles.

Las herramientas de detección de metadatos como Azure Data Catalog permiten a los usuarios empresariales etiquetar y clasificar los orígenes de datos para enriquecer los metadatos de esos orígenes de datos a fin de ayudar con su detección y clasificación. Puede usar los metadatos de un informe o panel para ayudarle a comprender su valor empresarial. Sin estas herramientas, es probable que entender la contribución de informes y paneles al valor empresarial sea una tarea muy lenta, tanto si va a realizar la migración como si no.

Migración de informes basados en la estrategia de migración de datos

Si la estrategia de migración se basa en migrar primero los data marts, el orden de la migración de data marts afectará a qué informes y paneles se migran en primer lugar. Si su estrategia se basa en el valor empresarial, el orden en el que migra los data marts a Azure Synapse reflejará las prioridades empresariales. Las herramientas de detección de metadatos pueden ayudarle a implementar su estrategia mostrando qué tablas de data mart proporcionan datos para qué informes.

Problemas de incompatibilidad de migración que pueden afectar a informes y visualizaciones

Las herramientas de BI producen informes, paneles y otras visualizaciones emitiendo consultas SQL que acceden a tablas físicas o visualizaciones en el almacenamiento de datos o data mart. Al migrar el almacenamiento de datos heredado a Azure Synapse, hay varios factores que pueden afectar a la facilidad en la migración de informes, paneles y otras visualizaciones. Estos factores incluyen los siguientes:

• Incompatibilidades de esquema entre los entornos.

• Incompatibilidades de SQL entre los entornos.

Incompatibilidades de esquema

Durante una migración, las incompatibilidades de esquema en el almacenamiento de datos o las tablas de data mart que proporcionan datos para informes, paneles y otras visualizaciones pueden ser las siguientes:

• Tipos de tablas no estándares en el DBMS de almacenamiento de datos heredado que no tienen un equivalente en Azure Synapse.

• Tipos de datos en el DBMS de almacenamiento de datos heredado que no tienen un equivalente en Azure Synapse.

En la mayoría de los casos, hay una solución alternativa a las incompatibilidades. Por ejemplo, puede migrar los datos de tipos de una tabla no admitidos a una tabla estándar con los tipos de datos adecuados, e indexarlos o partirlos en una columna de fecha y hora. Del mismo modo, se podrían representar tipos de datos no admitidos en otro tipo de columna y realizar cálculos en Azure Synapse para lograr los mismos resultados.

Para identificar los informes afectados por incompatibilidades del esquema, ejecute consultas en el catálogo del sistema del almacenamiento de datos heredado para identificar las tablas con tipos de datos no admitidos. Después, puede usar metadatos de la herramienta de BI para identificar los informes que acceden a los datos de esas tablas. Para obtener más información sobre cómo identificar las incompatibilidades de tipos de objeto, vea Tipos de objetos de base de datos de Oracle no admitidos.

El efecto de las incompatibilidades de esquemas en informes, paneles y otras visualizaciones podría ser menor de lo que cree porque muchas herramientas de BI no admiten los tipos de datos menos genéricos. Como resultado, el almacenamiento de datos heredado podría tener ya vistas que realizan CAST de tipos de datos no compatibles a tipos de datos más genéricos.

Incompatibilidades de SQL

Durante una migración, es probable que las incompatibilidades de SQL afecten a cualquier informe, panel u otra visualización en una aplicación o herramienta que realiza lo siguiente:

• Accede a las vistas del DBMS del almacenamiento de datos heredado que incluyen funciones de SQL propietarias que no tienen ningún equivalente en Azure Synapse.

• Emite consultas SQL que incluyen funciones de SQL de su propiedad específicas del dialecto SQL del entorno heredado, que no tienen ningún equivalente en Azure Synapse.

Medición del impacto de las incompatibilidades de SQL en la cartera de informes

La cartera de informes puede incluir servicios de consulta insertados, informes, paneles y otras visualizaciones. No confíe en la documentación asociada a esos elementos para medir el efecto de las incompatibilidades de SQL en la migración de la cartera de informes a Azure Synapse. Debe usar una manera más precisa de evaluar el efecto de las incompatibilidades de SQL.

Uso de instrucciones EXPLAIN para buscar incompatibilidades de SQL

Para identificar las incompatibilidades de SQL, revise los registros de la actividad reciente de SQL en el entorno de almacenamiento de datos heredado de Oracle. Use un script para extraer un conjunto representativo de instrucciones SQL en un archivo. Después, anteponga a cada instrucción de SQL una instrucción EXPLAIN y ejecute esas instrucciones EXPLAIN en Azure Synapse. Azure Synapse rechazará las instrucciones SQL que contengan extensiones de SQL de su propiedad que no sean compatibles cuando se ejecuten las instrucciones EXPLAIN. Este enfoque permite evaluar el alcance de las incompatibilidades de SQL.

Los metadatos del DBMS de almacenamiento de datos heredado también le ayudarán a identificar las vistas incompatibles. Al igual que antes, capture un conjunto representativo de instrucciones SQL de los registros aplicables, anteponga cada instrucción SQL con una instrucción EXPLAIN y ejecute esas instrucciones EXPLAIN en Azure Synapse para identificar las vistas con SQL incompatible.

Prueba de la migración de informes y paneles a Azure Synapse Analytics

Un elemento clave de la migración del almacenamiento de datos es la prueba de informes y paneles en Azure Synapse para comprobar que la migración ha funcionado. Defina una serie de pruebas y un conjunto de resultados de las pruebas que se deben ejecutar para comprobar que la operación se ha realizado correctamente. Pruebe y compare los informes y paneles de los sistemas de almacenamiento de datos existentes y migrados para lo siguiente:

• Identificar si los cambios de esquema realizados durante la migración han afectado a la capacidad de los informes para ejecutarlos, a los resultados del informe o a las visualizaciones de informes correspondientes. Un ejemplo de cambio de esquema es si asigna un tipo de datos incompatible a un tipo de datos equivalente que se admite en Azure Synapse.

• Comprobar que todos los usuarios se han migrado.

• Comprobar que todos los roles se han migrado y que los usuarios se han asignado a esos roles.

• Comprobar que todos los privilegios de seguridad de acceso a datos se han migrado para garantizar la migración de la lista de control de acceso (ACL).

• Asegurarse de que los resultados sean coherentes en todas las consultas, informes y paneles conocidos.

• Asegúrese de que los datos y la migración de ETL estén completos y no contengan errores.

• Asegurarse de que se mantiene la privacidad de los datos.

• Probar el rendimiento y la escalabilidad.

• Pruebe la funcionalidad analítica.

Para obtener más información sobre cómo migrar usuarios, grupos de usuarios, roles y privilegios, vea Seguridad, acceso y operaciones para migraciones de Oracle.

Automatice las pruebas tanto como sea posible para que cada prueba se pueda repetir y admitir un enfoque coherente a fin de evaluar los resultados de la pruebas. La automatización funciona bien para los informes normales conocidos y se puede administrar mediante la orquestación de canalizaciones de Azure Synapse o Azure Data Factory. Si ya tiene un conjunto de consultas de prueba en vigor para las pruebas de regresión, puede usar las herramientas de pruebas existentes a fin de automatizar las pruebas posteriores a la migración.

El análisis y los informes ad hoc son más difíciles y requieren la compilación de un conjunto de pruebas para comprobar que los mismos informes y paneles que hay antes y después de la migración son coherentes. Si encuentra incoherencias, la capacidad de comparar el linaje de metadatos entre los sistemas originales y migrados durante las pruebas de migración es fundamental. Esa comparación puede resaltar las diferencias e identificar dónde se han originado las incoherencias cuando la detección por otros medios resulta difícil.

Análisis del linaje para comprender las dependencias entre informes, paneles y datos

La comprensión del linaje es un factor fundamental en la migración correcta de informes y paneles. El linaje son metadatos que muestran el recorrido de los datos migrados para que pueda realizar un seguimiento de su ruta de acceso desde un informe o panel hasta el origen de datos. El linaje muestra cómo han viajado los datos de punto a punto, su ubicación en el almacenamiento de datos o data mart, y qué informes y paneles los usan. El linaje puede ayudarle a comprender lo que sucede con los datos a medida que pasan por diferentes almacenes de datos, como archivos y bases de datos, canalizaciones ETL diferentes y en informes. Cuando los usuarios empresariales tienen acceso al linaje de datos se genera y mejora la confianza, y respalda la toma de decisiones empresariales más informadas.

En entornos de almacenamiento de datos de varios proveedores, los analistas de negocios de los equipos de BI pueden asignar el linaje de datos. Por ejemplo, si tiene distintos proveedores para el ETL, el almacenamiento de datos y los informes, y cada uno de estos tiene su propio repositorio de metadatos, averiguar de dónde procede un elemento de datos específico de un informe puede ser difícil y lento.

Para migrar correctamente desde un almacenamiento de datos heredado a Azure Synapse, use el linaje de datos de un extremo a otro para demostrar una migración equivalente a la que se realiza al comparar los informes y paneles que genera cada entorno. Para mostrar el recorrido de los datos de un extremo a otro, deberá capturar e integrar metadatos de varias herramientas. Tener acceso a herramientas que admiten la detección automatizada de metadatos y el linaje de datos le permitirá identificar informes duplicados y procesos ETL, así como encontrar informes que dependen de orígenes de datos obsoletos, cuestionables o incluso inexistentes. Puede usar esta información para reducir el número de informes y procesos ETL que se migran.

También puede comparar el linaje de un extremo a otro para un informe en Azure Synapse con el linaje de un extremo a otro del mismo informe en el entorno heredado a fin de ver si durante la migración se han producido diferencias de forma accidental. Este tipo de comparación es excepcionalmente útil cuando necesita probar y comprobar que la migración se ha realizado correctamente.

La visualización del linaje de datos no solo reduce el tiempo, el esfuerzo y el error en el proceso de migración, sino que también permite una ejecución más rápida.

Al usar las herramientas automatizadas de detección de metadatos y linaje de datos que comparan el linaje, puede comprobar si se genera un informe a partir de los datos migrados en Azure Synapse y si se produce de la misma manera que en el entorno heredado. Esta capacidad también le ayuda a determinar lo siguiente:

• Qué datos se deben migrar para garantizar la ejecución correcta del informe y del panel en Azure Synapse.

• Qué transformaciones se han realizado y deben realizarse para garantizar una ejecución correcta en Azure Synapse.

• Cómo reducir la duplicación de informes.

Las herramientas automatizadas de detección de metadatos y linaje de datos simplifican considerablemente el proceso de migración, ya que ayudan a las empresas a conocer mejor sus recursos de datos y a saber qué se debe migrar a Azure Synapse para lograr un entorno de informes sólido.

Varias herramientas de ETL proporcionan capacidad de linaje de un extremo a otro, por lo que debe comprobar si la herramienta de ETL existente tiene esa capacidad en caso de que planee usarla con Azure Synapse. Las canalizaciones de Azure Synapse o Data Factory admiten la capacidad de ver el linaje en los flujos de asignación. Los asociados de Microsoft también proporcionan herramientas automatizadas de detección de metadatos, linaje de datos y comparación de linaje.

Migración de capas semánticas de herramientas de BI a Azure Synapse Analytics

Algunas herramientas de BI tienen lo que se conoce como capa de metadatos semánticos. Esta capa simplifica el acceso de los usuarios empresariales a las estructuras de datos físicas subyacentes en un almacenamiento de datos o en una base de datos data mart. La capa de metadatos semánticos simplifica el acceso proporcionando objetos de alto nivel, como dimensiones, medidas, jerarquías, métricas calculadas y combinaciones. Los objetos de alto nivel usan términos empresariales conocidos para los analistas de negocios y se asignan a las estructuras de datos físicas del almacenamiento de datos o en el data mart.

En una migración de un sistema de almacenamiento de datos, es posible que deba cambiar los nombres de columna o tabla. Por ejemplo, Oracle permite un carácter # en los nombres de tabla, pero Azure Synapse solo permite # como prefijo de nombre de tabla para indicar una tabla temporal. En Oracle, las TABLAS TEMPORALES no usan necesariamente "#" en el nombre, pero en Synapse es un requisito. En estos casos, es posible que tenga que cambiar las asignaciones de tabla.

Para lograr la coherencia entre varias herramientas de BI, cree una capa semántica universal mediante un servidor de virtualización de datos que se encuentra entre las herramientas y aplicaciones de BI y Azure Synapse. En el servidor de virtualización de datos, use nombres de datos comunes para objetos de alto nivel como dimensiones, medidas, jerarquías y combinaciones. De este modo, podrá configurarlo todo, incluidos los campos calculados, las combinaciones y las asignaciones, solo una vez en lugar de tener que hacerlo en cada herramienta. Después, apunte todas las herramientas de BI en el servidor de virtualización de datos.

Gracias a las virtualización de datos, obtendrá coherencia en todas las herramientas de BI y se elimina la dependencia entre las herramientas y aplicaciones de BI y las estructuras de datos físicas subyacentes en Azure Synapse. Los asociados de Microsoft pueden ayudarle a lograr la coherencia en Azure. El diagrama siguiente muestra cómo un vocabulario común del servidor de virtualización de datos permite a varias herramientas de BI ver una capa semántica común.

Conclusiones

En una migración del almacenamiento de datos mediante lift-and-shift, la mayoría de los informes, paneles y otras visualizaciones deberían migrarse fácilmente.

Durante una migración desde un entorno heredado, es posible que los datos del almacenamiento de datos heredado o de las tablas data mart se almacenen en tipos de datos no admitidos. O bien puede encontrar vistas de almacenamiento de datos heredadas que incluyan SQL de su propiedad sin equivalente en Azure Synapse. Si es así, deberá resolver esos problemas para garantizar una migración correcta a Azure Synapse.

No confíe en la documentación mantenida por el usuario para identificar dónde se encuentran los problemas. En su lugar, use instrucciones EXPLAIN ya que son una manera rápida y útil de identificar incompatibilidades de SQL. Vuelva a trabajar las instrucciones SQL incompatibles para lograr una función equivalente en Azure Synapse. Además, use herramientas automatizadas de detección y linaje de metadatos para comprender las dependencias, buscar informes duplicados e identificar informes no válidos que dependen de orígenes de datos obsoletos, cuestionables o inexistentes. Use estas herramientas para comparar el linaje a fin de comprobar que los informes que se ejecutan en el entorno de almacenamiento de datos heredado se generan de forma idéntica en Azure Synapse.

No migre informes que ya no use. Los datos de uso de herramientas de BI pueden ayudar a determinar los informes que no están en uso. Debe migrar todos los usuarios, grupos de usuarios, roles y privilegios para los informes, paneles y otras visualizaciones que quiera migrar. Si usa valor empresarial para impulsar la estrategia de migración de informes, asocie informes con objetivos empresariales estratégicos y prioridades para ayudar a identificar la contribución de la información del informe a objetivos concretos. Si va a migrar data marts uno a la vez, use metadatos para identificar qué informes dependen de qué tablas y vistas, así podrá tomar una decisión informada sobre qué data marts se van a migrar en primer lugar.

Durante una migración pueden producirse cambios estructurales en el modelo de datos del almacenamiento de datos o del data mart. Considere la posibilidad de usar la virtualización de datos para impedir que se produzcan cambios estructurales en las herramientas y aplicaciones de BI. Con la virtualización de datos, puede usar un vocabulario común para definir una capa semántica común. La capa semántica común garantiza unos nombres de datos comunes coherentes, definiciones, métricas, jerarquías y combinaciones en todas las herramientas y aplicaciones de BI en el entorno nuevo de Azure Synapse.

Pasos siguientes

Para más información sobre cómo minimizar los problemas de SQL, consulte el siguiente artículo de esta serie: Minimizar los problemas de SQL para las migraciones de Oracle.