Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
La mise en miroir dans Fabric offre une expérience simple pour éviter des données ETL complexes (Extraire la charge de transformation) et intégrer vos données d’entrepôt Snowflake existantes avec le reste de vos données dans Microsoft Fabric. Vous pouvez répliquer en continu vos données Snowflake existantes directement dans OneLake de Fabric. À l’intérieur de Fabric, vous pouvez déverrouiller des scénarios de décisionnel puissants, d’intelligence artificielle, d’ingénierie des données, de science des données et de partage de données.
Pour obtenir un didacticiel sur la configuration de votre base de données Snowflake pour la mise en miroir dans Fabric, consultez Tutoriel : Configurer des bases de données mises en miroir Microsoft Fabric à partir de Snowflake.
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 et la collaboration entre Microsoft, Snowflake et les 1000 solutions technologiques qui peuvent lire le format de table Delta Lake open source.
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.
La mise en miroir crée ces éléments dans votre espace de travail Fabric :
- Élément de base de données mis en miroir. Cela permet des scénarios en aval tels que l’ingénierie des données, la science des données et bien plus encore. La mise en miroir gère :
- Réplication des métadonnées de table Iceberg dans OneLake à l’aide de raccourcis vers le stockage qui contient vos tables Iceberg. OneLake convertit automatiquement ces tables Iceberg en tables mises en forme Delta Lake pour une utilisation dans les charges de travail Fabric.
- Réplication des données de table gérées dans OneLake et conversion en Parquet, dans un format prêt pour l'analyse.
- Un point de terminaison d’analytique 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 créées par le processus de mise en miroir. Les utilisateurs ont accès aux 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 qui référencent des données dans vos tables Delta Lake à partir de Snowflake.
- Créez aucune requête et vues de code et explorez les données visuellement sans écrire de ligne de code.
- Développez des vues SQL, des fichiers TVF inline (Fonctions table) et des procédures stockées pour encapsuler votre sémantique et votre logique métier dans T-SQL.
- Gérer les autorisations sur les objets.
- Interroger des données dans d’autres entrepôts et Lakehouses dans le même espace de travail.
En plus de l’éditeur de requête SQL, il existe un vaste écosystème d’outils qui peut interroger le point de terminaison d’analyse SQL, y compris SQL Server Management Studio (SSMS),l’extension mssql avec Visual Studio Code, et même GitHub Copilot.
Considérations relatives à la sécurité
Pour activer la mise en miroir fabric, vous aurez besoin d’autorisations utilisateur pour votre base de données Snowflake qui contient les autorisations suivantes :
CREATE STREAMSELECT tableSHOW tablesDESCRIBE tables
Pour plus d’informations, consultez la documentation Snowflake sur les privilèges de contrôle d’accès pour les tables de streaming et les autorisations requises pour les flux.
Important
Toute sécurité granulaire établie dans l’entrepôt Snowflake source doit être reconfigurée dans la base de données mise en miroir dans Microsoft Fabric. Pour plus d'informations, consultez Autorisations granulaires SQL dans Microsoft Fabric.
Mise en miroir de Snowflake derrière le pare-feu
Vérifiez les exigences de mise en réseau pour accéder à votre source de données Snowflake. Si votre source de données Snowflake n’est pas accessible publiquement et se trouve dans un réseau privé, créez une passerelle de données de réseau virtuel ou installez une passerelle de données locale pour mettre en miroir les données. Le réseau virtuel Azure ou le réseau de la machine de passerelle doit se connecter à l’instance Snowflake via un point de terminaison privé ou être autorisé par la règle de pare-feu. Pour commencer, consultez Tutoriel : Configurer des bases de données mises en miroir Microsoft Fabric à partir de Snowflake.
Considérations relatives aux coûts de flocons de neige mis en miroir
Le calcul Fabric utilisé pour répliquer vos données dans Fabric OneLake est gratuit. Le coût de stockage de mise en miroir est gratuit jusqu’à une limite en fonction de la capacité. Pour plus d’informations, consultez Coût de la mise en miroir et tarification de Microsoft Fabric. Le calcul pour l’interrogation de données à l’aide de SQL, Power BI ou Spark est facturé à des tarifs réguliers.
Fabric ne facture pas les frais d’entrée de données réseau dans OneLake pour la mise en miroir.
Il existe des coûts de calcul et de requête cloud Snowflake lorsque les données sont mises en miroir : calcul de l’entrepôt virtuel et calcul des services cloud.
- Frais de calcul de l’entrepôt virtuel Snowflake :
- Les frais de calcul seront facturés côté Snowflake s’il existe des modifications de données lues dans Snowflake, et à leur tour sont mises en miroir dans Fabric.
- Toutes les requêtes de métadonnées s’exécutent en arrière-plan pour vérifier que les modifications de données ne sont pas facturées pour un calcul Snowflake ; toutefois, les requêtes qui produisent des données telles qu’une
SELECT *sortie de veille de l’entrepôt Snowflake et le calcul seront facturés.
- Frais de calcul des services Snowflake :
- Bien qu’il n’y ait pas de frais de calcul pour les tâches en arrière-plan telles que la création, les requêtes de métadonnées, le contrôle d’accès, l’affichage des modifications de données et même les requêtes DDL, il existe des coûts cloud associés à ces requêtes.
- Selon le type d’édition Snowflake dont vous disposez, vous serez facturé pour les crédits correspondants pour les coûts des services cloud.
Dans la capture d’écran suivante, vous pouvez voir les coûts de calcul et de calcul des services cloud de l’entrepôt virtuel pour la base de données Snowflake associée en miroir dans Fabric. Dans ce scénario, la majorité des coûts de calcul des services cloud (en jaune) proviennent de requêtes de modification de données basées sur les points mentionnés précédemment. Les frais de calcul de l’entrepôt virtuel (en bleu) proviennent strictement des modifications de données sont lus à partir de Snowflake et mis en miroir dans Fabric.
Pour plus d’informations sur les coûts de requête cloud spécifiques à Snowflake, consultez la documentation Snowflake : Présentation du coût global.