Visualización e informes para migraciones de Oracle

Este artículo es la parte cuatro 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 para la visualización y los informes.

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

Las organizaciones acceden a los sistemas de almacenamiento de datos y data marts mediante una serie 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 las hojas de cálculo de Microsoft Excel.

• Herramientas de BI de diferentes proveedores.

• Aplicaciones de análisis personalizadas que integran funcionalidad de herramientas de BI.

• Aplicaciones operativas que admiten BI a petición mediante la ejecución de consultas e informes en una plataforma de BI que, a su vez, consulta datos en un sistema de 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 información de visualización y los informes como parte de la migración de la unidad de almacenamiento de datos, todas las consultas, informes y paneles existentes que hayan generado los productos de BI deberán 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 haber migrado los datos y el esquema de almacenamiento de datos a Azure Synapse. Las dependencias incluyen aspectos menos visibles, como el acceso y la seguridad. Al abordar los aspectos relacionados con el acceso y la seguridad, asegúrese de migrar lo siguiente:

• Proceda con la autenticación para que los usuarios puedan iniciar sesión en la unidad de 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 reproducir lo que había en la unidad de 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 el acceso a datos en el sistema migrado y se describen con más detalle en Seguridad, acceso y operaciones para las migraciones de Oracle.

Sugerencia

Los usuarios, grupos de usuarios, roles y asignaciones de privilegios de seguridad de acceso existentes deben migrarse en primer lugar para que la migración de informes y visualizaciones se lleve a cabo correctamente.

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 que la migración se lleve a cabo de forma fluida, sin contratiempos que minen su confianza en el sistema migrado a Azure Synapse. Para disipar cualquier temor que los usuarios puedan tener, mantenga con ellos una buena comunicación. Los usuarios esperarán que:

• la estructura de tabla permanezca igual cuando se referencie directamente en las consultas;

• los nombres de tabla y columna se mantengan iguales cuando se haga referencia directa a ellos en las consultas. Por ejemplo, los campos calculados definidos en las columnas de las herramientas de BI no deben generar error cuando se creen informes agregados;

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

• los tipos de datos deben mantenerse igual si es posible;

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

Sugerencia

Comunicarse con los usuarios empresariales e involucrarlos es fundamental para tener éxito.

Si las herramientas de BI consultan las vistas del sistema de almacenamiento de datos subyacente o la base de datos de data mart, ¿funcionarán esas vistas 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 un equivalente en Azure Synapse. Si este es el caso, debe conocer esas incompatibilidades y encontrar la manera de resolverlas.

Sugerencia

Es probable que las vistas y las consultas SQL que usan extensiones de consulta SQL propietarias produzcan incompatibilidades que afecten a los informes y paneles de BI.

Otros problemas, como el comportamiento de los valores NULL o las variaciones en cuanto al tipo de datos en las plataformas DBMS, deben verificarse para garantizar que no haya discrepancias, aunque sean mínimas, en los resultados de los cálculos. Minimice esos problemas y tome todas la medidas necesarias para proteger a los usuarios empresariales y que no se vean afectados. En función del entorno de almacenamiento de datos heredado, las herramientas de terceros que pueden ayudar a ocultar las diferencias entre los entornos heredado y nuevo para 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. Usar una herramienta de ejecución de pruebas también resulta útil. En este artículo, se mencionan algunas. Además, es importante que los usuarios empresariales se involucren en las pruebas de migración para mantener la confianza y continuar participando en el proyecto.

Sugerencia

Use pruebas repetibles para asegurarse de que los informes, los paneles y otras visualizaciones se migran correctamente.

Es posible que haya pensando cambiar las herramientas de BI, por ejemplo, para migrar a Power BI. La inclinación en estos casos es hacer los cambios al mismo tiempo que 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 llevar a cabo 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 ocurre con las aplicaciones que se ejecutan en el entorno local que integran BI o llaman al servidor de BI a petición. Por ejemplo, al solicitar un "informe sin encabezado" con datos XML o JSON.

En este sentido, hay muchas consideraciones que hacer.

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

Durante la migración, es posible que tenga la inclinación de abordar 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 a la unidad de 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 incluir la virtualización de datos entre las herramientas de BI, el sistema de almacenamiento de datos y los data marts. El diagrama siguiente muestra cómo la virtualización de datos puede ocultar una migración a los usuarios.

La virtualización de datos elimina 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.

Sugerencia

La virtualización de datos le permite proteger a los usuarios empresariales frente a los cambios estructurales durante la migración para que no sean conscientes de dichos cambios. Los cambios estructurales incluyen modificaciones del esquema para ajustar su modelo de datos a Azure Synapse.

Mediante la virtualización de datos, cualquier modificación del esquema que se realice durante una migración a Azure Synapse (por ejemplo, para optimizar el rendimiento) se puede ocultar a los usuarios empresariales porque solo tendrán 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 sistema de almacenamiento de datos o los data marts y las tablas virtuales. Mediante la virtualización de datos, los usuarios seguirán sin notar los cambios estructurales. Los asociados de Microsoft proporcionan software de virtualización de datos.

Identificación de los informes de alta prioridad para migrar en primer lugar

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

• Uso

• Valor empresarial

• Facilidad de migración

• Estrategia de migración de datos

En las secciones siguientes se analizan estos factores.

Sea cual sea la decisión que tome, debe implicar a los usuarios empresariales porque crean informes, paneles y otras visualizaciones, y adoptan decisiones empresariales basadas en la información generada por esos componentes. Todas las partes involucradas se benefician cuando es posible:

• Migrar eficazmente los informes y paneles.
• Migrar los informes y paneles con el mínimo esfuerzo.
• Apuntar a las herramientas de BI en Azure Synapse en lugar de al sistema de almacenamiento de datos heredado para obtener informes, paneles y otras visualizaciones similares.

Migración de informes basados en el uso

Los hábitos de uso con frecuencia señalan el valor empresarial. Los informes y paneles que no se utilizan no intervienen en la toma de decisiones empresariales ni aportan valor. Si no tiene la posibilidad de identificar los informes y paneles que no se utilizan, puede emplear una de las distintas herramientas de BI que ofrecen estadísticas de uso.

Si el sistema de almacenamiento de datos heredado ha estado en funcionamiento durante años, es muy probable que tenga cientos o miles de informes existentes. Merece la pena crear un inventario de informes y paneles, e identificar su finalidad empresarial y estadísticas de uso.

En el caso de los informes que no se utilizan, determine si se deben retirar para minimizar el trabajo de migración. Una pregunta fundamental a la hora de decidir si se debe retirar un informe que no se utiliza es si este no se usa porque los usuarios no saben que existe, porque no aporta valor empresarial o porque hay otro informe que lo ha reemplazado.

Migración de informes basados en el valor empresarial

Los hábitos de uso por sí solos no siempre son un buen indicador del valor empresarial. Es posible que deba tener en cuenta hasta qué punto la información que proporciona un informe aporta valor empresarial. Una manera de hacerlo consiste en evaluar la utilidad de cada decisión empresarial basada en el informe y el grado de dependencia. Sin embargo, es poco probable que esa información esté disponible en la mayoría de las organizaciones.

Otra manera de cuantificar el valor empresarial consiste en determinar si el informe está en sintonía con la estrategia empresarial. La estrategia empresarial que establece el equipo ejecutivo suele establecer los objetivos empresariales estratégicos, los indicadores clave de rendimiento (KPI) y los objetivos de KPI que deben alcanzarse y las personas que son responsables de alcanzarlos. Puede clasificar un informe en función de los objetivos empresariales estratégicos que aborda, como la mitigación del fraude, la mayor participación de los clientes o la optimización de las operaciones empresariales. Después, puede priorizar la migración de los informes y paneles asociados a objetivos de alta prioridad. De este modo, la migración inicial puede aportar valor empresarial para un área estratégica.

Otra forma de cuantificar el valor empresarial consiste en clasificar los informes y paneles como operativos, tácticos o estratégicos, con el fin de identificar en qué nivel empresarial se usan. Los objetivos empresariales estratégicos requieren contribuciones en todos estos niveles. Conocer los informes y paneles que se usan, así como el nivel y los objetivos a los que están asociados permite focalizar la migración inicial en el valor empresarial de alta prioridad. Puede usar la siguiente tabla de objetivos estratégicos empresariales para evaluar los informes y paneles.

Nivel	Nombre del informe o del panel	Propósito empresarial	Departamento usado	Frecuencia de uso	Prioridad empresarial
Estrategia
Táctico
Operativo

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 con el fin de facilitar su detección y clasificación. Puede usar los metadatos de un informe o panel para comprender el valor empresarial que aporta. Sin ayuda de dichas herramientas, comprender el valor empresarial que aportan los informes y paneles podría ser un proceso lento, tanto si va a efectuar 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 migración de los data marts determinará los informes y paneles que se migrarán en primer lugar. Si su estrategia se basa en el valor empresarial, el orden de migración de los data marts a Azure Synapse reflejará las prioridades de la empresa. Las herramientas de detección de metadatos pueden ayudarle a implementar la estrategia al mostrar qué tablas de data mart proporcionan datos para informes específicos.

Sugerencia

La estrategia de migración de datos determinará qué informes y visualizaciones se migrarán en primer lugar.

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

Las herramientas de BI generan informes, paneles y otras visualizaciones al emitir consultas SQL que acceden a tablas físicas o visualizaciones en el sistema de almacenamiento de datos o data mart. Al migrar el sistema de almacenamiento de datos heredado a Azure Synapse, varios factores pueden influir en la facilidad de migración de los informes, paneles y otras visualizaciones. Entre estos factores, se incluyen los siguientes:

• Incompatibilidades de esquema entre entornos

• Incompatibilidades de SQL entre entornos

Incompatibilidades de esquema

Durante una migración, las incompatibilidades de esquema en el sistema de 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ándar 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 un tipo de tabla no compatible a una tabla estándar con tipos de datos adecuados, indexados o divididos 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 hacer cálculos en Azure Synapse para obtener los mismos resultados.

Sugerencia

Las incompatibilidades del esquema incluyen tipos de tabla DBMS de almacenamiento heredado y tipos de datos que no se admiten en Azure Synapse.

Para identificar los informes afectados por incompatibilidades del esquema, ejecute consultas en el catálogo del sistema de su entorno de 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 incompatibilidades de tipos de objeto, vea Tipos de objetos de base de datos de Oracle no admitidos.

Sugerencia

Consulte el catálogo del sistema de DBMS de almacenamiento heredado para identificar las incompatibilidades de esquema con Azure Synapse.

El impacto 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 consecuencia, el entorno de almacenamiento de datos heredado podría incluir vistas que convierten CAST tipos de datos no admitidos a otros 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:

• 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 un 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 integrados, informes, paneles y otras visualizaciones. No confíe en la documentación asociada a esos componentes 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

Puede encontrar incompatibilidades de SQL revisando los registros de la actividad de SQL reciente en el almacenamiento de datos de Oracle heredado. Use un script para extraer un conjunto representativo de instrucciones SQL en un archivo. Después, agregue como prefijo a cada instrucción de SQL una instrucción EXPLAIN y ejecute dichas instrucciones EXPLAIN en Azure Synapse. Azure Synapse rechazará las instrucciones SQL que contengan extensiones de SQL de su propiedad que no sean compatibles al ejecutar las instrucciones EXPLAIN. Este enfoque permite determinar el alcance de las incompatibilidades de SQL.

Los metadatos de 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, agregue como prefijo a cada instrucción SQL una instrucción EXPLAIN y ejecute dichas instrucciones EXPLAIN en Azure Synapse para identificar las vistas con instrucciones SQL incompatibles.

Sugerencia

Mida el impacto de las incompatibilidades de SQL mediante la recolección de los archivos de registro del DBMS y la ejecución de instrucciones EXPLAIN.

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

Un aspecto básico de la migración del entorno de almacenamiento de datos consiste en probar los informes y paneles en Azure Synapse para ver si la migración ha funcionado. Defina una serie de pruebas y un conjunto de resultados necesarios para cada prueba que ejecute con el fin de comprobar que se realice correctamente. Pruebe y compare los informes y paneles de los sistemas de almacenamiento de datos existentes y migrados para:

• 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 admitido en Azure Synapse.

• Comprobar que todos los usuarios se hayan migrado.

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

• Comprobar que todos los privilegios de seguridad de acceso a datos se hayan 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.

• Garantizar el mantenimiento de la privacidad de los datos.

• Probar el rendimiento y la escalabilidad.

• Probar la funcionalidad analítica.

Sugerencia

Pruebe y ajuste el rendimiento para minimizar los costos de proceso.

Para obtener información sobre cómo migrar usuarios, grupos de usuarios, roles y privilegios, consulte 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 informes conocidos y habituales y se puede administrar a través de las canalizaciones de Azure Synapse o la orquestación de Azure Data Factory. Si ya tiene un conjunto de consultas de prueba en uso para las pruebas de regresión, puede emplear las herramientas de pruebas existentes a fin de automatizar las pruebas posteriores a la migración.

Sugerencia

El procedimiento recomendado consiste en crear un conjunto de pruebas automatizadas para que estas se puedan repetir.

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 la coherencia de los informes y paneles antes y después de la migración. Si detecta incoherencias, es fundamental que pueda comparar el linaje de metadatos entre los sistemas originales y migrados durante las pruebas de migración. Esa comparación puede destacar las diferencias e identificar dónde se han originado las incoherencias cuando la detección por otros medios sea difícil.

Sugerencia

Utilice las herramientas que comparan el linaje de metadatos para comprobar los resultados.

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

Comprender el linaje es un aspecto fundamental para la correcta migración 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 un punto a otro, su ubicación en el sistema de 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, diferentes canalizaciones ETL e informes. Cuando los usuarios empresariales tienen acceso al linaje de datos mejora la confianza y se toman decisiones empresariales mejor informadas.

Sugerencia

La capacidad de acceder a los metadatos y el linaje de datos desde los informes hasta el origen de datos es fundamental para comprobar que los informes migrados funcionan correctamente.

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 ETL, el sistema de almacenamiento de datos y los informes, y cada proveedor 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.

Sugerencia

Las herramientas que automatizan la recopilación de metadatos y muestran el linaje de un extremo a otro en un entorno multiproveedor son útiles durante una migración.

Para migrar correctamente un sistema de almacenamiento de datos heredado a Azure Synapse, use el linaje de datos de un extremo a otro para obtener 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, es necesario 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 procesos ETL o informes duplicados, además de 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 vaya a migrar.

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 con el fin de comprobar si durante la migración se han producido discrepancias que han pasado inadvertidas. Este tipo de comparación es muy ú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 los errores en el proceso de migración, sino que también acelera la migración.

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:

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

• Las transformaciones que se han efectuado y deben efectuarse para garantizar una correcta ejecución 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 los recursos de datos que poseen y a saber lo que deben migrar a Azure Synapse para lograr un entorno eficaz de generación de informes.

Varias herramientas de ETL proporcionan funcionalidad de linaje de un extremo a otro, por lo que debe comprobar si su herramienta de ETL tiene esa funcionalidad en el caso de que planee usarla con Azure Synapse. Las canalizaciones de Azure Synapse o Data Factory permiten ver el linaje en 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 sistema de almacenamiento de datos o base de datos data mart. La capa de metadatos semánticos simplifica el acceso al proporcionar 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 sistema de almacenamiento de datos o data mart.

Sugerencia

Algunas herramientas de BI tienen capas semánticas que simplifican el acceso de los usuarios empresariales a estructuras de datos físicas en el sistema de almacenamiento de datos o data mart.

En una migración de almacenamiento de datos, es posible que se le obligue a 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 tienen necesariamente un "#" en el nombre, pero en Synapse deben. 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 ubicado 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, tan 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.

Sugerencia

Utilice la virtualización de datos para crear una capa semántica común que garantice la coherencia en todas las herramientas de BI de un entorno de Azure Synapse.

Gracias a las virtualización de datos, obtendrá coherencia en todas las herramientas de BI y se eliminará 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 de almacenamiento de datos mediante lift-and-shift, la mayoría de los informes, paneles y otras visualizaciones deberían poder migrarse fácilmente.

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

No confíe en la documentación de usuario que mantenga para identificar dónde están los problemas. En lugar de ello, use instrucciones EXPLAIN, ya que son una manera rápida y eficaz de identificar incompatibilidades de SQL. Vuelva a procesar las instrucciones SQL incompatibles para obtener una función equivalente en Azure Synapse. Use también 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 y 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. En el caso de los informes, paneles y otras visualizaciones que quiera migrar, deberá migrar todos los usuarios, grupos de usuarios, roles y privilegios. Si usa el valor empresarial para impulsar la estrategia de migración de informes, asocie los informes a prioridades y objetivos empresariales estratégicos para determinar cómo un informe responde a objetivos específicos. Si va a migrar data marts de uno en uno, use los metadatos para identificar qué informes dependen de qué tablas y vistas, así podrá tomar una decisión informada sobre los data marts que se van a migrar en primer lugar.

Sugerencia

Identifique las incompatibilidades con antelación para medir la extensión del esfuerzo de migración. Migre los usuarios, roles de grupo y asignaciones de privilegios. Migre solo los informes y visualizaciones que se usan y que contribuyen al valor empresarial.

Durante una migración pueden producirse cambios estructurales en el modelo de datos del sistema de almacenamiento de datos o data mart. Considere la posibilidad de usar la virtualización de datos para proteger las herramientas y aplicaciones de BI frente a los cambios estructurales. Mediante 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 nombres de datos, definiciones, métricas, jerarquías y combinaciones comunes y coherentes en todas las herramientas y aplicaciones de BI en el nuevo entorno 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 problemas de SQL para migraciones de Oracle.