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.

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 de 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 l’ensemble de requêtes KQL, ce qui permet à certains éléments fabric tels que l’ensemble de requêtes et les tableaux de bord en temps réel d’interroger les 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 générales

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

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 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 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 retourne l’union du local MyTable dans la base de données Fabric KQL, qui est actuellement vide ou recevant de nouvelles données et la table MyTable distante 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 un nombre ou un exemple de requête sur la vue (par exemple MyTable | count) pour vous assurer qu’elle retourne des données à partir d’ADX. La base de données Fabric KQL est toujours vide maintenant, mais lorsque vous migrez l’ingestion à l’étape suivante, la vue commence à retourner les enregistrements anciens et nouveaux.

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. Repointer des 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 des références union

   Modifiez ou supprimez les vues union afin que les requêtes ne tirent pas 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 existe toujours des données historiques dans ADX qui n’ont pas été déplacées (par exemple, si vous n’avez pas attendu son âge), envisagez d’exporter ces données vers Fabric avant l’arrêt. Sinon, continuez si les données dans ADX dépassent les exigences de rétention.

3. Désaffecter ADX

   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.