Mise en miroir Azure Cosmos DB

La mise en miroir dans Microsoft Fabric offre une expérience sans ETL transparente pour intégrer vos données Azure Cosmos DB existantes au reste de vos données dans Microsoft Fabric pour le traitement transactionnel/analytique hybride (HTAP) avec une isolation complète des charges de travail entre les systèmes transactionnels et analytiques. Vos données Azure Cosmos DB sont répliquées en continu directement dans Fabric OneLake en quasi-temps réel, sans impact sur les performances de vos charges de travail transactionnelles ou consommation d’unités de requête (RU).

Les données dans OneLake sont stockées au format delta open source et mises automatiquement à la disposition de tous les moteurs analytiques sur Fabric.

Vous pouvez utiliser des fonctionnalités Power BI intégrées pour accéder aux données en mode OneLake en mode DirectLake. Avec Copilot des améliorations apportées à Fabric, vous pouvez utiliser la puissance de l’IA générative pour obtenir des insights clés sur vos données métier. Outre Power BI, vous pouvez utiliser T-SQL pour exécuter des requêtes d’agrégation complexes ou utiliser Spark pour l’exploration des données. Vous pouvez accéder en toute transparence aux données dans les notebooks et utiliser la science des données pour créer des modèles Machine Learning.

Pourquoi utiliser la mise en miroir dans Fabric ?

Avec la mise en miroir dans Fabric, vous n’avez pas besoin de regrouper différents services de plusieurs fournisseurs. Au lieu de cela, vous pouvez profiter d’un produit hautement intégré, de bout en bout et facile à utiliser qui est conçu pour simplifier vos besoins d’analyse et conçu pour l’ouverture.

Si vous recherchez des rapports décisionnels ou des analyses sur vos données opérationnelles dans Azure Cosmos DB, la mise en miroir fournit :

• Accès en quasi-temps réel sans ETL à vos données Azure Cosmos DB sans affecter votre consommation d’unités de requête
• Facilité d’apport de données entre différentes sources dans Fabric OneLake
• Optimisations de table delta avec ordre v pour les lectures rapides
• Intégration en un clic à Power BI avec Direct Lake et Copilot
• Insights métier enrichis en joignant des données entre 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 l’utiliser avec différentes solutions au sein et en dehors de Microsoft. Ce format de données facilite la création d’un seul patrimoine de données pour vos besoins analytiques.

Quelles expériences d’analytique sont intégrées ?

Les bases de données mises en miroir sont un élément de l’entreposage de données Fabric distinct du point de terminaison d’analytique SQL et de l’entrepôt.

Chaque élément Azure Cosmos DB mis en miroir crée ces éléments avec lesquels vous pouvez interagir dans votre espace de travail Fabric :

• Élément de base de données mis en 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 tels que l’ingénierie des données, la science des données et bien plus encore.
• Point de terminaison d’analytique SQL, qui est généré automatiquement

Base de données mise en miroir

La base de données mise en miroir affiche l’état de réplication et les contrôles pour arrêter ou démarrer la réplication dans Fabric OneLake. Vous pouvez également afficher votre base de données source, en mode 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 Fabric. L’écriture dans la base de données source n’est pas autorisée à partir de Fabric, car vous ne pouvez afficher que les données.

Point de terminaison des analyses SQL

Chaque base de données mise en miroir a un point de terminaison d’analytique SQL généré automatiquement qui offre une expérience analytique 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 qui peuvent définir et interroger des objets de données, mais qui ne manipulent pas les données à partir du point de terminaison d’analyse 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 mises en miroir, entrepôts et lakehouses dans le même espace de travail.
• Vous pouvez facilement visualiser et générer des rapports BI basés sur des requêtes ou des vues SQL.

En plus de l’éditeur de requête SQL, il existe un large écosystème d’outils. Ces outils incluent l’extension mssql avec Visual Studio Code, SQL Server Management Studio (SSMS) et même GitHub Copilot. Vous pouvez supercharger l’analyse et la génération d’insights à partir de l’outil de votre choix.

Modèle sémantique

Vous pouvez créer un modèle sémantique Power BI sur la base de données pour permettre la création, la partage et la réutilisation des métriques métier. Pour plus d’informations, consultez Créer un modèle sémantique Power BI.

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, insérez, mettez à jour et supprimez des opérations sur vos données de traitement des transactions en ligne (OLTP) sont répliquées en continu dans Fabric OneLake pour la consommation analytique.

La fonctionnalité de sauvegarde continue est un prérequis pour la mise en miroir. Vous pouvez activer une sauvegarde continue de 7 jours ou 30 jours sur votre compte Azure Cosmos DB. Si vous activez la sauvegarde continue spécifiquement pour la mise en miroir, la sauvegarde continue de 7 jours est recommandée, car elle est gratuite.

La réplication de vos données Azure Cosmos DB dans Fabric OneLake peut prendre quelques minutes. Selon l’instantané initial de vos données ou 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 que vous avez allouées pour vos charges de travail transactionnelles.

Ce à quoi s’attendre de la mise en miroir

Il existe quelques considérations et scénarios pris en charge que vous devez prendre en compte avant la mise en miroir.

Considérations relatives à l’installation

Pour mettre en miroir une base de données, elle doit déjà être provisionnée dans Azure. Vous devez activer la sauvegarde continue sur le compte en tant que prérequis.

• Vous ne pouvez mettre en miroir chaque base de données individuellement qu’à 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. En guise de meilleure pratique, une seule copie de base de données peut être réutilisée sur des lakehouses, des entrepôts ou d’autres bases de données mises en miroir. Vous n’avez pas besoin de configurer plusieurs miroirs sur 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 locataires Fabric.
• Vous pouvez sélectionner les conteneurs à mettre en miroir dans votre base de données.
• Les modifications apportées aux conteneurs Azure Cosmos DB, telles que l’ajout de nouveaux conteneurs et la suppression de conteneurs existants, sont répliquées en toute transparence dans Fabric. Vous pouvez commencer à mettre en miroir une base de données vide sans conteneurs, par exemple, et la mise en miroir récupère en toute transparence les conteneurs ajoutés à un moment ultérieur dans le temps.

Prise 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 d’analyse SQL. Vous pouvez utiliser OPENJSON, CROSS APPLYet OUTER APPLY dans les requêtes ou les vues T-SQL pour développer ces données de manière sélective. Si vous utilisez Power Query, vous pouvez également appliquer la ToJson fonction pour développer ces données.

Grâce à l’inférence de schéma automatique, les données imbriquées peuvent être aplatis OPENJSON sans avoir à définir explicitement le schéma imbriqué. Cela est particulièrement utile pour les charges de travail avec des schémas imbriqués dynamiques ou imprévisibles. Pour plus d’informations, consultez comment interroger des données imbriquées.

Gérer les modifications de schéma

La mise en miroir réplique automatiquement les propriétés entre les éléments Azure Cosmos DB, avec des modifications de schéma. Toutes les nouvelles propriétés découvertes dans un élément sont affichées sous forme de nouvelles colonnes et les propriétés manquantes, le cas échéant, sont représentées comme null dans Fabric.

Si vous renommez une propriété dans un élément, les tables Fabric conservent les anciennes et nouvelles colonnes. L’ancienne colonne affiche null et la nouvelle affiche la valeur la plus récente, pour tous les éléments répliqués après l’opération de renommage.

Si vous modifiez le type de données d’une propriété dans les éléments 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 Null.

Les tables de point de terminaison SQL Analytics convertissent les types de données Delta en types de données T-SQL.

Noms de colonnes en double

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 double en ajoutant _n au nom de colonne, où n serait une valeur numérique.

Par exemple, si l’élément Azure Cosmos DB possède addressName et AddressName comme propriétés uniques, les tables Fabric ont des colonnes et addressName des correspondances correspondantesAddressName_1. Pour plus d’informations, consultez les limitations de réplication.

Prise en charge des charges de travail IA

La mise en miroir Azure Cosmos DB prend en charge les comptes qui utilisent la recherche et l’indexation vectorielles, ce qui permet aux charges de travail IA et Machine Learning de tirer pleinement parti de l’analytique puissante de Microsoft Fabric, tout en continuant à tirer parti des fonctionnalités de vecteur hautes performances d’Azure Cosmos DB.

Pour plus d’informations, consultez la documentation sur la recherche vectorielle et l’indexation pour Cosmos DB et Fabric Data Science and AI Experiences.

Security

Vous pouvez vous connecter à un acocunt source à l’aide de l’ID Microsoft Entra et du contrôle d’accès en fonction du rôle ou des clés au niveau du compte.

Si vous utilisez des clés et faites pivoter ou régénérer les clés, vous devez mettre à jour les connexions pour 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 fabric une fois la connexion configurée. Vous pouvez limiter les personnes ayant accès aux connexions créées dans 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’analytique dans votre base de données mise en miroir. La mise en miroir ne prend actuellement pas en charge l’authentification à l’aide de clés de compte en lecture seule.

Pour l’authentification d’ID Microsoft Entra, les autorisations RBAC suivantes sont requises : Microsoft.DocumentDB/databaseAccounts/readMetadata &> Microsoft.DocumentDB/databaseAccounts/readAnalytics. Pour plus d’informations, consultez la documentation sur le contrôle d’accès en fonction du rôle du plan de données.

Fonctionnalités de protection des données

La sécurité granulaire peut être configurée dans la base de données mise en miroir dans Microsoft Fabric. Pour plus d’informations, consultez les autorisations granulaires dans Microsoft Fabric.

Vous pouvez sécuriser les filtres de colonnes et les filtres de lignes basés sur des prédicats sur des tables sur des rôles et des 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 des données dynamiques :

• Masquage dynamique des données dans l’entreposage de données Fabric

Sécurité 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, à l’aide de points de terminaison privés, à l’aide d’adresses IP ou à l’aide 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 travailler avec la mise en miroir.

Récupération d’urgence et latence de réplication

Dans Fabric, vous pouvez déployer du contenu sur des centres de données dans des régions autres que la région d’accueil du locataire Fabric. Pour plus d’informations, consultez la 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é 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.

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 la récupération d’urgence dans OneLake.

Explorer vos données avec la mise en miroir

Vous pouvez afficher et accéder directement aux données mises en miroir dans OneLake. Vous pouvez également accéder en toute transparence aux données mises en miroir sans déplacement de données supplémentaire.

Apprenez-en davantage sur l’accès à OneLake à l’aide d’API ou sdk ADLS Gen2, 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 pilotes tels que Microsoft Open Database Connectivity (ODBC) et Java Database Connectivity (JDBC). Pour plus d’informations, consultez connectivité des points de terminaison d’analyse SQL.

Vous pouvez également accéder aux données mises en miroir avec des services tels que :

• Services Azure tels qu’Azure Databricks, Azure HDInsight ou Azure Synapse Analytics
• Fabric Lakehouse à l’aide de raccourcis pour les scénarios d’ingénierie des données et de science des données
• Autres bases de données ou entrepôts mis en miroir dans l’espace de travail Fabric

Vous pouvez également créer des solutions d’architecture de médaillon, nettoyer et transformer les données qui se trouvent dans une base de données mise en miroir en tant que couche bronze. Pour plus d’informations, consultez la prise en charge de l’architecture de médaillon dans Fabric.

Pricing

Le calcul Fabric utilisé pour répliquer vos données Cosmos DB dans Fabric OneLake est gratuit. Le stockage dans OneLake est gratuit en fonction de la taille de capacité. Pour plus d’informations, consultez la tarification OneLake pour la mise en miroir. 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é fabric.

Si vous utilisez l’Explorateur de données dans la mise en miroir 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 éléments dans la base de données Azure Cosmos DB source. La fonctionnalité de sauvegarde continue Azure Cosmos DB est une condition préalable à la mise en miroir : les frais standard de sauvegarde continue s’appliquent. Il n’existe aucun frais supplémentaire pour la mise en miroir sur la facturation de sauvegarde continue. Pour plus d’informations, consultez la Tarification d’Azure Cosmos DB.

Étape suivante

Contenu connexe

• Limitations dans les bases de données mises en miroir Microsoft Fabric à partir d’Azure Cosmos DB
• FAQ : Bases de données mises en miroir Microsoft Fabric à partir d’Azure Cosmos DB