Mise en miroir d'Azure Cosmos DB (préversion)
La mise en miroir dans Microsoft Fabric offre une expérience sans ETL transparente pour intégrer vos données Azure Cosmos DB existantes avec le reste de vos données dans Microsoft Fabric. Vous pouvez répliquer en continu vos données Azure Cosmos DB directement dans Microsoft Fabric OneLake en quasi-temps réel, sans aucun effet sur l'analyse des performances de vos charges de travail transactionnelles.
Les données dans OneLake sont stockées au format delta open source et mises automatiquement à la disposition de tous les moteurs analytiques sur Microsoft Fabric.
Vous pouvez utiliser T-SQL pour exécuter des requêtes d'agrégation complexes et Spark pour l'exploration de données. Vous pouvez accéder en toute transparence aux données dans les notebooks, utiliser la science des données pour créer des modèles Machine Learning et créer des rapports BI à l'aide de Direct Lake optimisé par l'intégration Copilot.
Important
La mise en miroir d'Azure Cosmos DB est actuellement en préversion. Les charges de travail de production ne sont pas prises en charge dans la préversion. Seuls les comptes Azure Cosmos DB for NoSQL sont pris en charge.
Pourquoi utiliser la mise en miroir dans Microsoft Fabric ?
Avec la mise en miroir dans Fabric, vous n’avez pas besoin de regrouper différents services à partir de plusieurs fournisseurs. À la place, vous pouvez profiter d'un produit hautement intégré, de bout en bout et simple d'utilisation, conçu vos besoins en matière d'analyse et pour être ouvert.
Si vous souhaitez effectuer une analyse de vos données opérationnelles dans Azure Cosmos DB, la mise en miroir fournit :
- Analyse sans ETL, économique et en quasi-temps réel des données Azure Cosmos DB sans affecter votre consommation d'unité de requête
- Facilité d'apport de données entre différentes sources dans Microsoft Fabric OneLake
- Optimisations de table Delta avec commande v pour les lectures ultra-rapides
- Intégration en un clic à Power BI avec Direct Lake et Copilot
- Perspectives enrichies grâce à l'adhérence de données provenant de différentes sources
- Intégration d'applications plus riche pour accéder aux requêtes et aux vues
Les données OneLake sont stockées au format Delta Lake open source, ce qui vous permet de les utiliser avec diverses solutions à l'intérieur et à l'extérieur de Microsoft. Ce format de données facilite la création d'un seul patrimoine de données pour vos besoins d'analyse.
Quelles sont les expériences d'analyse prédéfinies ?
Les bases de données mise en miroir sont un élément de l’entrepôt de données de Fabric Synapse distinct de l’entrepôt et du point de terminaison de l'analytique SQL.
Chaque base de données Azure Cosmos DB en miroir comporte trois articles avec lesquels vous pouvez interagir dans votre espace de travail Microsoft Fabric :
- Article de base de données miroir. La mise en miroir gère la réplication des données en OneLake et la conversion en Parquet, dans un format prêt pour l’analytique. Cela permet des scénarios en aval comme les Ingénieurs de données, la science des données et bien plus encore.
- Point de terminaison d'analytique SQL généré automatiquement
- Modèle sémantique par défaut généré automatiquement
Base de données miroir
La base de données miroir affiche l'état de la réplication et les contrôles pour arrêter ou démarrer la réplication dans Microsoft Fabric OneLake. Vous pouvez également afficher votre base de données source, en mode En lecture seule, à l'aide de l'explorateur de données Azure Cosmos DB. À l'aide de l'explorateur de données, vous pouvez afficher vos conteneurs dans votre base de données Azure Cosmos DB source et les interroger. Ces opérations consomment des unités de requête (RU) à partir de votre compte Azure Cosmos DB. Toutes les modifications apportées à la base de données source sont reflétées immédiatement dans la vue de base de données source de Microsoft Fabric. L'écriture dans la base de données source n'est pas autorisée à partir de Microsoft Fabric, car vous ne pouvez afficher que les données.
Point de terminaison d’analytique SQL
Chaque base de données miroir dispose d'un point de terminaison d'analytique SQL autogénéré qui offre une expérience d'analyse enrichie sur les tables Delta de OneLake créées par le processus de mise en miroir. Vous avez accès à des commandes T-SQL familières susceptibles de définir et interroger des objets de données, mais qui ne manipulent pas les données à partir du point de terminaison d'analytique SQL, car il s'agit d'une copie en lecture seule.
Vous pouvez effectuer les actions suivantes dans le point de terminaison d’analytique SQL :
- Explorez les tables Delta Lake à l'aide de T-SQL. Chaque table est mappée à un conteneur à partir de votre base de données Azure Cosmos DB.
- Créez des requêtes et des vues sans code et explorez-les visuellement sans écrire de ligne de code.
- Joignez et interrogez des données dans d'autres bases de données miroir, entrepôts et Lakehouses dans le même espace de travail.
Outre l'Éditeur de requête SQL de Microsoft Fabric, il existe un vaste écosystème d'outils. Ces outils incluent Visual Studio Code, Azure Data Studio, SQL Server Management Studio et même GitHub Copilot. Vous pouvez optimiser l'analyse et la génération d'aperçus à partir de l'outil de votre choix.
Modèle sémantique
Le modèle sémantique par défaut est un modèle sémantique Power BI attribué automatiquement. Cette caractéristique permet aux indicateurs de performance d'entreprise d'être créés, partagés et réutilisés. Pour plus d'informations, consultez modèles sémantiques.
Comment fonctionne la réplication en quasi-temps réel ?
Lorsque vous activez la mise en miroir sur votre base de données Azure Cosmos DB, les opérations d'insertion, de mise à jour et de suppression de vos données traitement transactionnel en ligne (OLTP) sont répliquées en continu dans Microsoft Fabric OneLake à des fins de consommation d'analyse.
La caractéristique sauvegarde continue est un prérequis pour la mise en miroir. Vous pouvez activer une sauvegarde continue de 7 jours ou de 30 jours sur votre compte Azure Cosmos DB.
Remarque
La mise en miroir n'utilise pas le magasin d'analyse ou le flux de modification d'Azure Cosmos DB comme source de capture des changements de données. Vous pouvez continuer à utiliser ces caractéristiques indépendamment, ainsi que la mise en miroir.
La réplication de vos données Azure Cosmos DB dans Microsoft Fabric OneLake peut prendre quelques minutes. En fonction de la capture instantanée initiale de vos données ou de la fréquence des mises à jour/suppressions, la réplication peut également prendre plus de temps dans certains cas. La réplication n'affecte pas les unités de requête (RU) que vous avez attribuées pour vos charges de travail transactionnelles.
Ce qu'il faut attendre de la mise en miroir
Quelques considérations et scénarios pris en charge sont à prendre en compte avant la mise en miroir.
Considérations relatives à la configuration
Pour mettre en miroir une base de données, celle-ci doit déjà être approvisionnée dans Azure. Vous devez activer la sauvegarde continue sur le compte en tant que prérequis.
- Vous pouvez mettre en miroir une seule base de données à la fois. Vous pouvez choisir la base de données à mettre en miroir.
- Vous pouvez mettre en miroir la même base de données plusieurs fois dans le même espace de travail. La meilleure pratique consiste à réutiliser une copie unique de la base de données dans les lakehouses, les entrepôts ou d'autres bases de données miroir. Vous ne devriez pas avoir besoin de configurer plusieurs miroirs pour la même base de données.
- Vous pouvez également mettre en miroir la même base de données sur différents espaces de travail ou clients Microsoft Fabric.
- Les modifications apportées aux conteneurs Azure Cosmos DB, comme l'ajout de nouveaux conteneurs et la suppression de conteneurs existants, sont répliquées en toute transparence dans Microsoft Fabric. Vous pouvez démarrer la mise en miroir d'une base de données vide sans conteneurs, par exemple, et la mise en miroir récupère de manière transparente les conteneurs ajoutés ultérieurement.
Prendre en charge des données imbriquées
Les données imbriquées sont affichées sous la forme d'une chaîne JSON dans les tables de point de terminaison analytique SQL. Vous pouvez utiliser OPENJSON, CROSS APPLY et OUTER APPLY dans les requêtes ou les vues T-SQL pour étendre ces données de manière sélective. Si vous utilisez Power Query, vous pouvez également appliquer la fonction ToJson pour étendre ces données.
Remarque
Microsoft Fabric présente une limitation pour les colonnes de chaîne de 8 Kb de taille. Pour plus d'informations, consultez Limitations de Data Warehouse.
Gérer des modifications de schéma
La mise en miroir réplique automatiquement les propriétés entre les articles Azure Cosmos DB, avec des modifications de schéma. Toutes les nouvelles propriétés découvertes dans un article sont affichées sous forme de nouvelles colonnes et les propriétés manquantes, le cas échéant, sont représentées comme nul dans Microsoft Fabric.
Si vous renommez une propriété dans un article, les tables Microsoft Fabric conservent les anciennes et nouvelles colonnes. L'ancienne colonne affiche nul et la nouvelle affiche la valeur la plus récente, pour tous les articles répliqués après l'opération de renommage.
Si vous modifiez le type de données d'une propriété dans les articles Azure Cosmos DB, les modifications sont prises en charge pour les types de données compatibles qui peuvent être convertis. Si les types de données ne sont pas compatibles pour la conversion dans Delta, ils sont représentés sous forme de valeurs Nul.
Les tables de point de terminaison analytique SQL convertissent les types de données Delta en types de données T-SQL.
Dupliquer les noms de colonnes
Azure Cosmos DB prend en charge les noms de colonnes qui ne respectent pas la casse, en fonction de la norme JSON. La mise en miroir prend en charge ces noms de colonnes en duplicata en ajoutant _n au nom de colonne, où n serait une valeur numérique.
Par exemple, si l'article Azure Cosmos DB possède addressName et AddressName comme propriétés uniques, les tables Microsoft Fabric disposent des colonnes addressName et AddressName_1 correspondantes. Pour plus d'informations, consultez Limitations de réplication.
Sécurité
Les connexions à votre base de données source sont basées sur les clés de compte de vos comptes Azure Cosmos DB. Si vous effectuez une rotation ou faites régénérer les clés, vous devez mettre à jour les connexions afin de garantir que la réplication fonctionne. Pour plus d'informations, consultez Connexions.
Les clés de compte ne sont pas directement visibles par d'autres utilisateurs Microsoft Fabric une fois la connexion configurée. Vous pouvez limiter les personnes ayant accès aux connexions créées dans Microsoft Fabric. Les écritures ne sont pas autorisées dans la base de données Azure Cosmos DB à partir de l'explorateur de données ou du point de terminaison d'analyse dans votre base de données miroir.
La mise en miroir ne prend actuellement pas en charge l'authentification à l'aide de clés de compte en lecture seule, de l'authentification unique (SSO) avec les Microsoft Entra ID et le contrôle d'accès en fonction du rôle ou des identités managées.
Une fois les données répliquées dans Microsoft Fabric OneLake, vous devez sécuriser l'accès à ces données.
Fonctionnalités de protection des données
La sécurité granulaire peut être configurée dans la base de données miroir dans Microsoft Fabric. Pour plus d'informations, consultez Autorisations granulaires dans Microsoft Fabric.
Vous pouvez sécuriser les filtres de colonnes et les filtres de ligne de base sur prédicat sur les tables pour les rôles et les utilisateurs dans Microsoft Fabric :
- Sécurité au niveau des lignes dans l'entrepôt de données Fabric
- Sécurité au niveau des colonnes dans l’entrepôt de données Fabric
Vous pouvez également masquer les données sensibles des utilisateurs non administrateurs à l'aide du masquage dynamique des données :
Sécurité du réseau
Actuellement, la mise en miroir ne prend pas en charge les points de terminaison privés ou les clés gérées par le client (CMK) sur OneLake. La mise en miroir n'est pas prise en charge pour les comptes Azure Cosmos DB avec des configurations de sécurité réseau moins permissives que tous les réseaux, à l'aide de points de terminaison de service, de points de terminaison privés, d'adresses IP ou de tout autre paramètre susceptible de limiter l'accès réseau public au compte. Les comptes Azure Cosmos DB doivent être ouverts à tous les réseaux pour qu'ils fonctionnent avec la mise en miroir.
Récupération d'urgence et latence de réplication
Découvrez comment déployer du contenu sur des centres de données dans des régions autres que la région d'accueil du client Microsoft Fabric. Pour plus d'informations, consultez Prise en charge multigéographique.
Pour un compte Azure Cosmos DB avec une région d'écriture principale et plusieurs régions de lecture, la mise en miroir choisit la région de lecture Azure Cosmos DB la plus proche de la région où la capacité de Microsoft Fabric est configurée. Cette sélection permet de fournir une réplication à faible latence pour la mise en miroir.
Lorsque vous basculez votre compte Azure Cosmos DB vers une région de récupération, la mise en miroir sélectionne automatiquement la région Azure Cosmos DB la plus proche.
Remarque
La mise en miroir ne prend pas en charge les comptes avec plusieurs régions d'écriture.
Vos données Cosmos DB répliquées vers OneLake doivent être configurées pour gérer les pannes à l'échelle de la région. Pour plus d'informations, consultez récupération d'urgence dans OneLake.
Explorer vos données avec mise en miroir
Vous pouvez afficher et accéder directement aux données miroir dans OneLake. Vous pouvez également accéder en toute transparence aux données miroir sans déplacement des données supplémentaire.
Apprenez-en davantage sur l'accès à OneLake à l'aide d'API ADLS Gen2 ou Kit de développement logiciel (SDK), de l'Explorateur de fichiers OneLake et de l'Explorateur Stockage Azure.
Vous pouvez vous connecter au point de terminaison d'analytique SQL à partir d'outils tels que SQL Server Management Studio (SSMS) ou à l'aide de gestionnaires comme Microsoft Open Database Connectivity (ODBC) et Java Database Connectivity (JDBC). Pour plus d'informations, consultez Connectivité de point de terminaison analytique SQL.
Vous pouvez également accéder aux données miroir avec des services tels que :
- les services Azure comme Azure Databricks, Azure Synapse Analytics et Azure HDInsight
- Microsoft Fabric Lakehouse à l'aide de raccourcis pour les scénarios d'Ingénieurs de données et de science des données
- Autres bases de données miroir ou entrepôts dans l'espace de travail Microsoft Fabric
Vous pouvez également créer des solutions d'architecture en médaillon, en nettoyant et en transformant les données qui atterrissent dans une base de données miroir en tant que couche de bronze. Pour plus d'informations, consultez architecture de médaillonprise en charge dans Microsoft Fabric.
Tarification
Il n'existe actuellement aucun coût lié à la caractéristique de mise en miroir ou au stockage de données miroir dans Microsoft Fabric pendant la préversion publique. L'utilisation du calcul pour l'interrogation de données via SQL, Power BI ou Spark est toujours facturée en fonction de la capacité de Microsoft Fabric. Pour plus d'informations, consultez FAQ relative à la tarification.
Si vous utilisez l'Explorateur de données dans la mise en miroir Microsoft Fabric, vous accumulez des coûts classiques en fonction de l'utilisation de l'unité de requête (RU) pour explorer les conteneurs et interroger les articles dans la base de données Azure Cosmos DB source. La caractéristique de sauvegarde continue Azure Cosmos DB est un prérequis pour la mise en miroir : les frais standard pour la sauvegarde continue s'appliquent. Aucun frais supplémentaire ne s'applique pour la mise en miroir sur la facturation de sauvegarde continue. Pour plus d’informations, consultez la Tarification d’Azure Cosmos DB.