Migrer d’Azure Data Explorer (ADX) vers Fabric Real-Time Intelligence (Eventhouse)

Cet article explique comment migrer progressivement vos charges de travail d’analytique d’Azure Data Explorer vers Eventhouse dans Fabric Real-Time intelligence sans temps d’arrêt. Commencez par utiliser Fabric comme couche de requête pendant que ADX continue à ingérer des données pour explorer les fonctionnalités de Fabric. Lorsque vous êtes prêt, migrez entièrement en déplaçant le schéma et l’ingestion vers Fabric.

Si vous ne pouvez pas attendre que vos données dans ADX arrivent à expiration et que vous devez les copier vers Eventhouse, envisagez d’utiliser l’outil open source Kusto Copy.

Consommer des données ADX dans Fabric

Conservez ADX uniquement pour l’ingestion et déplacez l’interrogation vers Fabric à l’aide de l’une de ces deux méthodes pour utiliser les données ADX de Fabric sans dupliquer les données.

• Raccourci vers une base de données Fabric (suiveur)

  Créez un raccourci de base de données vers une base de données Azure Data Explorer et interrogez sans migrer de données vers Fabric. Un raccourci de base de données dans la charge de travail Fabric Real-Time Intelligence est une référence incorporée dans une base de données KQL (Kusto Query Language) vers une base de données source dans Azure Data Explorer. Le comportement du raccourci de base de données est similaire à une base de données de suivi. Il est en lecture seule, synchronise les nouvelles données avec un léger décalage (secondes à minutes) et permet à tous les éléments Fabric d’afficher et d’interroger les données ADX sans les réinscrire.

• Attacher le cluster ADX en tant que source interrogeable

  Dans Fabric, vérifiez que vous disposez d’une connexion au cluster ADX. Ajoutez une source Azure Data Explorer dans un ensemble de requêtes KQL, ce qui permet à certains éléments Fabric, tels que les ensembles de requêtes et les tableaux de bord en temps réel, d’interroger des données ADX. Pour plus d’informations, consultez Données de requête dans un ensemble de requêtes KQL - Microsoft Fabric.

  Essayez les fonctionnalités de Fabric telles que la génération de requêtes assistées par Copilot, les notebooks, l’activateur et les rapports Power BI sur vos données ADX. Exécutez tous vos tableaux de bord et requêtes dans Fabric pendant que l’ingestion continue de se produire dans ADX. Lorsque vous êtes prêt à effectuer la migration complète, suivez les étapes suivantes.

Étapes de migration de haut niveau

Procédez comme suit pour migrer d’ADX vers Fabric :

1. Créer une base de données KQL dans Fabric avec le schéma ADX
2. Créer une vue avec un opérateur union qui accède à la fois à la table dans la base de données KQL et la table dans la base de données ADX
3. Rediriger les points de terminaison de requête vers la base de données KQL dans Fabric Eventhouse
4. Basculer l’ingestion des données vers Fabric
5. Mettre hors service le cluster ADX

Les sections suivantes fournissent des détails sur chaque étape.

Créer une base de données KQL dans Fabric avec un schéma ADX

1. Créez une base de données KQL vide dans un eventhouse Fabric qui remplace finalement la base de données ADX. Il doit avoir le même schéma de tables et de fonctions que votre base de données ADX. Pour obtenir des instructions, consultez Créer un eventhouse et une base de données KQL.

2. Répliquer le schéma

   Utilisez Sync Kusto ou exportez le schéma à partir de la base de données ADX pour le recréer dans la base de données Fabric KQL. SyncKusto est un outil dédié qui synchronise les schémas de base de données Kusto (tables, fonctions, etc.) entre les environnements.

   Vous pouvez également exécuter la commande KQL : .show database schema as csl script dans ADX, qui génère un script de toutes les définitions de table, fonctions et stratégies, puis exécuter le script généré sur la base de données KQL dans Fabric à l’aide .execute database scriptde .

3. Vérifier le schéma

   Vérifiez toutes les tables, colonnes, types de données et stratégies pertinentes (rétention, mise en cache, etc.) dans la base de données KQL correspondent à celles de la base de données ADX. À ce stade, la base de données Fabric KQL est vide, mais prête à recevoir des données, et vous pouvez également interroger ADX à l’aide de méthodes de la section Explorer les données ADX dans Fabric .

Créer des vues d’union pour un accès transparent aux données

Pour éviter toute interruption lors de la migration des données, créez des vues KQL dans Fabric qui combinent les données de l’ancienne base de données ADX et de la nouvelle base de données Fabric KQL. Cette approche permet aux requêtes de retourner un jeu de données complet pendant la transition :

1. Définir des vues d’union

   Pour chaque table, créez une fonction stockée dans Fabric (avec .create function with (view=true)) qui unione la table Fabric avec la table ADX correspondante. Nommez la fonction exactement de la même façon que la table pour la remplacer de manière transparente. Par exemple, pour une table MyTable, créez une fonction à l’aide de la commande suivante :

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

   Cette vue renvoie l’union de la table locale MyTable dans la base de données Fabric KQL, qui est actuellement vide ou reçoit de nouvelles données, et de la table distante MyTable dans la base de données ADX.

   Étant donné que le nom de la vue est MyTable, toute requête ou rapport utilisant ce nom de table interroge automatiquement les deux sources.

   Fabric et ADX peuvent se trouver dans différents clusters ou locataires. Si la commande de création se plaint de la référence externe, utilisez l’option skipvalidation=true dans la création de la fonction, ce qui est parfois nécessaire pour les fonctions entre clusters.

2. Tester la vue

   Exécutez une requête de comptage ou une requête d’exemple sur la vue (par exemple, MyTable | count) pour vous assurer qu’elle renvoie des données provenant d’ADX. La base de données KQL de Fabric est encore vide à ce stade, mais lorsque vous migrez le processus d’ingestion lors de l’étape suivante, la vue commence à renvoyer à la fois les anciens et les nouveaux enregistrements.

Rediriger les points de terminaison de requête vers la base de données KQL dans Fabric Eventhouse

À présent, mettez à jour vos outils et applications pour interroger la nouvelle base de données Fabric KQL au lieu de la base de données ADX :

1. Mettre à jour les chaînes de connexion

   Modifier les applications d’analyse, les requêtes KQL ou les rapports Power BI pour utiliser le point de terminaison de la base de données KQL (URI de requête) plutôt que le cluster ADX. Les requêtes restent identiques, car les noms de table et KQL n’ont pas changé, mais ils s’exécutent désormais dans Fabric. En raison de la vue union créée à l’étape précédente, les utilisateurs qui interrogent la base de données Fabric KQL obtiennent toujours toutes les données historiques d’ADX via la vue, ainsi que toutes les nouvelles données ingérées dans Fabric.

2. Rapports de test et applications

   Vérifiez que les tableaux de bord et les scripts obtiennent des résultats comme prévu à partir de la base de données Fabric KQL. Les performances peuvent différer légèrement. Fabric peut mettre en cache certaines données ADX si vous avez utilisé un raccourci. Cette étape déplace efficacement les points de terminaison de requête vers Fabric. À partir de là, toutes les opérations de lecture/requête se produisent sur Fabric.

Basculer l’ingestion des données vers Fabric

Avec les requêtes désormais traitées par Fabric, dirigez les flux de données entrants vers Fabric :

1. Rediriger les pipelines d’ingestion

   Modifiez tous les producteurs de données tels que les appareils IoT, les travaux ETL (extract-transform-load), les connexions Event Hubs et d’autres qui ingèrent précédemment dans la base de données ADX, afin qu’ils ingèrent dans la base de données Fabric KQL. Cette étape peut inclure la modification des URL de cluster, l’authentification ou la mise à jour des chaînes de connexion dans Azure Data Factory, Stream Analytics ou des applications personnalisées pour utiliser le point de terminaison ou l’URI d’ingestion de base de données KQL.

2. Vérifier le nouveau flux de données

   Vérifiez que les nouveaux enregistrements atterrissent dans les tables de la base de données KQL. La base de données KQL dans Fabric commence à accumuler des données. Étant donné que vous utilisez les vues union, les requêtes dans Fabric affichent toujours un jeu de données unifié. Au fil du temps, les données dans ADX deviennent obsolètes, car aucune nouvelle donnée n’est ingérée dans ADX après ce commutateur.

Mettre hors service le cluster ADX

Lorsque vous êtes certain que toutes les données requises sont disponibles dans Fabric, désactivez les anciennes ressources ADX :

1. Supprimer les références d’union

   Modifiez ou supprimez les vues d’union afin que les requêtes n’extraient plus de données du cluster ADX. Par exemple, mettez à jour la définition de fonction pour MyTable { MyTable } qu’elle utilise uniquement des données locales ou supprimez la fonction si la table physique de Fabric contient toutes les données. Vérifiez que vos requêtes et tableaux de bord fonctionnent comme prévu avec les données Fabric uniquement.

2. Archiver ou transférer des données historiques (si nécessaire)

   S’il reste encore des données historiques dans ADX qui n’ont pas été déplacées (par exemple, si vous n’avez pas attendu qu’elles expirent), envisagez d’exporter ces données vers Fabric avant l’arrêt du service. Sinon, continuez si les données dans ADX dépassent les exigences de rétention.

3. Mettre ADX hors service

   Lorsque Fabric traite à la fois les requêtes et l’ingestion, arrêtez ou supprimez le cluster ADX pour économiser des coûts. Tous les utilisateurs doivent maintenant se connecter à Fabric.

Résumé

En suivant les étapes décrites dans cet article, vous migrez d’ADX vers Fabric avec une interruption minimale. Vous commencez par déplacer la couche consommation vers Fabric, qui déverrouille les fonctionnalités telles que Copilot, Power BI, Notebooks et Activateor, puis déplacez progressivement le back-end vers Fabric. À présent, l’intelligence en temps réel (Eventhouse) de Fabric gère à la fois l’ingestion et l’interrogation de vos données, et ADX n’est pas en cours d’utilisation.