Migración de Azure Data Explorer (ADX) a Fabric Real-Time intelligence (Eventhouse)

En este artículo se muestra cómo realizar la transición gradual de las cargas de trabajo de análisis desde Azure Data Explorer a Eventhouse en Inteligencia en Tiempo Real de Fabric sin interrupciones. Empiece por usar Fabric como capa de consulta mientras ADX continúa ingeriendo datos para explorar las características de Fabric. Cuando esté listo, realice una migración completa trasladando el esquema y el proceso de ingesta a Fabric.

Consumo de datos de ADX en Fabric

Mantenga ADX solo para la ingesta y mueva la consulta a Fabric mediante uno de estos dos métodos para usar datos de ADX de Fabric sin duplicar los datos.

• Acceso directo de la base de datos de Fabric (seguidor)

  Cree un acceso directo de base de datos a una base de datos de Azure Data Explorer y consulte sin migrar datos a Fabric. Un acceso directo a la base de datos en la carga de trabajo de inteligencia en tiempo real de Fabric es una referencia incrustada en una base de datos que utiliza Kusto Query Language (KQL) a una base de datos fuente en Azure Data Explorer. El comportamiento del acceso directo de la base de datos es similar a una base de datos secundaria. Es de solo lectura, sincroniza nuevos datos con un ligero retraso (segundos a minutos), y permite que todos los elementos de Fabric vean y consulten los datos de ADX sin volver a ingerirlos.

• Asocia el clúster de ADX como origen consultable

  En Fabric, asegúrese de que tiene una conexión con el clúster de ADX. Agregue un origen de Azure Data Explorer en el conjunto de consultas KQL, que permite que determinados elementos de Fabric, como el conjunto de consultas y los paneles en tiempo real, consulten los datos de ADX. Para obtener más información, consulte Consulta de datos en un conjunto de consultas KQL: Microsoft Fabric.

  Pruebe las funcionalidades de Fabric, como la generación de consultas asistidas por Copilot, los cuadernos, el activador y los informes de Power BI en los datos de ADX. Ejecuta todos tus paneles y consultas en Fabric mientras la integración sigue realizándose en ADX. Cuando esté listo para migrar completamente, siga los pasos siguientes.

Pasos de migración de alto nivel

Siga estos pasos para migrar de ADX a Fabric:

1. Creación de una base de datos KQL en Fabric con el esquema de ADX
2. Creación de una vista con el operador union que tiene acceso a la tabla de la base de datos KQL y a la tabla de la base de datos de ADX
3. Redirigir los extremos de consulta a la base de datos KQL en Fabric Eventhouse
4. Cambio de la ingesta de datos a Fabric
5. Retirar el clúster de ADX

En las secciones siguientes se proporcionan detalles sobre cada paso.

Creación de una base de datos KQL en Fabric con esquema ADX

1. Cree una base de datos KQL vacía en un centro de eventos de Fabric que finalmente reemplace la base de datos de ADX. Debe tener el mismo esquema de tablas y funciones que la base de datos de ADX. Para obtener instrucciones, consulte Creación de un centro de eventos y una base de datos KQL.

2. Replicación del esquema

   Use Sync Kusto o exporte el esquema de la base de datos de ADX para volver a crearlo en la base de datos KQL de Fabric. SyncKusto es una herramienta dedicada que sincroniza esquemas de base de datos de Kusto (tablas, funciones, etc.) entre entornos.

   Como alternativa, puede ejecutar el comando KQL: .show database schema en ADX, que genera un script de todas las definiciones de tabla, funciones y directivas y, a continuación, ejecutar el script generado en la base de datos KQL en Fabric.

3. Comprobación del esquema

   Confirme todas las tablas, columnas, tipos de datos y directivas pertinentes (retención, almacenamiento en caché, etc.) en la base de datos KQL coinciden con las de la base de datos de ADX. En este momento, la base de datos de KQL de Fabric está vacía, pero está lista para recibir datos, y también puede consultar ADX mediante métodos de la sección Explorar datos de ADX en Fabric .

Crea vistas de unión para un acceso sin problemas a los datos

Para evitar cualquier interrupción durante la migración de datos, cree vistas KQL en Fabric que combinen datos de la base de datos de ADX antigua y de la nueva base de datos KQL de Fabric. Este enfoque permite que las consultas devuelvan un conjunto de datos completo durante la transición:

1. Definir vistas de unión

   Para cada tabla, cree una función almacenada en Fabric (con .create function with (view=true)) que unione la tabla Fabric con la tabla ADX correspondiente. Asigne un nombre a la función exactamente igual que la tabla para invalidarla de forma transparente. Por ejemplo, para una tabla MyTable, cree una función con el comando siguiente:

   .create function with (view=true) MyTable() {
       MyTable 
       | union cluster("YourADXCluster").database("YourDatabase").MyTable
   }
   

   Esta vista devuelve la unión del MyTable local en la base de datos KQL de Fabric, que está actualmente vacía o recibiendo datos nuevos, y de la tabla MyTable remota en la base de datos ADX.

   Dado que el nombre de la vista es MyTable, cualquier consulta o informe que use ese nombre de tabla consulta automáticamente ambos orígenes.

   Fabric y ADX pueden estar en distintos clústeres o inquilinos. Si el comando de creación se queja de la referencia externa, use la skipvalidation=true opción en la creación de funciones, que a veces es necesaria para las funciones entre clústeres.

2. Probar la vista

   Ejecute una consulta de recuento o de ejemplo en la vista (por ejemplo, MyTable | count) para asegurarse de que devuelve datos de ADX. La base de datos de KQL de Fabric sigue vacía ahora, pero a medida que haga la migración de la ingesta en el paso siguiente, la vista comenzará a devolver tanto registros antiguos como nuevos.

Redirigir los endpoints de consulta a la base de datos KQL en Fabric Eventhouse

Ahora actualice las herramientas y las aplicaciones para consultar la nueva base de datos KQL de Fabric en lugar de la base de datos de ADX:

1. Actualizar cadenas de conexión

   Cambie las aplicaciones de análisis, las consultas KQL o los informes de Power BI para usar el punto de conexión de la base de datos KQL (URI de consulta), en lugar del clúster de ADX. Las consultas siguen siendo las mismas, ya que los nombres de tabla y KQL no cambiaron, pero ahora se ejecutan en Fabric. Debido a la vista de unión creada en el paso anterior, los usuarios que consultan la base de datos de Fabric KQL siguen recibiendo todos los datos históricos de ADX a través de la vista, además de los nuevos datos que se ingieren en Fabric.

2. Prueba de informes y aplicaciones

   Asegúrese de que los paneles y scripts obtengan resultados según lo previsto en la base de datos de KQL de Fabric. El rendimiento puede diferir ligeramente. Fabric puede almacenar en caché algunos datos de ADX si usó un acceso directo. Este paso traslada eficazmente los extremos de consulta a Fabric. A partir de aquí, todas las operaciones de lectura y consulta se producen en Fabric.

Cambio de la ingesta de datos a Fabric

Con las consultas ahora atendidas por Fabric, dirija los flujos de datos entrantes a Fabric:

1. Redirigir las canalizaciones de ingestión

   Cambie todos los productores de datos, como dispositivos IoT, trabajos de extracción y carga de transformación (ETL), conexiones de Event Hubs y otros que anteriormente ingieren en la base de datos de ADX, por lo que ingieren en la base de datos de Fabric KQL. Este paso puede incluir el cambio de las direcciones URL del clúster, la autenticación o la actualización de cadenas de conexión en Azure Data Factory, Stream Analytics o aplicaciones personalizadas para usar el punto de conexión o el URI de ingesta de base de datos KQL.

2. Comprobación del nuevo flujo de datos

   Compruebe que los nuevos registros llegan a las tablas de la base de datos KQL. La base de datos KQL de Fabric comienza a acumular datos. Dado que usa las vistas de unión, las consultas de Fabric siguen mostrando un conjunto de datos unificado. Con el tiempo, los datos de ADX quedan obsoletos porque no se ingieren nuevos datos en ADX después de este cambio.

Retirar el clúster de ADX

Cuando esté seguro de que todos los datos necesarios están disponibles en Fabric, retire los recursos de ADX antiguos:

1. Quitar referencias de unión

   Modifique o elimine las vistas unidas para que las consultas no obtengan datos del clúster de ADX. Por ejemplo, actualice la definición de función para MyTable { MyTable } que use solo los datos locales o quite la función si la tabla física de Fabric tiene todos los datos. Compruebe que las consultas y los paneles funcionan según lo previsto con los datos solo de Fabric.

2. Archivar o transferir datos históricos (si es necesario)

   Si todavía hay datos históricos en ADX que no se han movido (por ejemplo, si no esperó a que se agotaran), considere exportar esos datos a Fabric antes del cierre. De lo contrario, continúe si los datos de ADX no cumplen con los requisitos de retención.

3. Desactivar ADX

   Cuando Fabric atiende consultas e ingesta, apague o elimine el clúster de ADX para ahorrar costos. Todos los usuarios deben conectarse a Fabric ahora.

Resumen

Siguiendo los pasos de este artículo, migrará de ADX a Fabric con una interrupción mínima. Para empezar, mueva la capa de consumo a Fabric, que desbloquea características como Copilot, Power BI, Notebooks y Activator y, a continuación, cambie gradualmente el back-end a Fabric. Ahora, la inteligencia en tiempo real (Eventhouse) de Fabric controla tanto la ingesta como la consulta de los datos, y ADX no está en uso.