Mise en miroir de Snowflake dans Microsoft Fabric
La mise en miroir dans Fabric offre une expérience simple pour éviter les opérations 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. Dans Fabric, vous pouvez débloquer de puissants scénarios de business intelligence, d'intelligence artificielle, d'ingénierie des données, de Science des données et de partage des données.
Pour obtenir un tutoriel sur la configuration de votre base de données Snowflake pour une 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 à partir de plusieurs fournisseurs. Au lieu de cela, vous pouvez profiter d'un produit hautement intégré, complet et simple d'utilisation, conçu pour simplifier vos besoins en matière d'analyse et pour favoriser l'ouverture et la collaboration entre Microsoft, Snowflake et les milliers de solutions technologiques capables de 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’Entrepôt de données Fabric distinct de l’Entrepôt et du point de terminaison d’analytique SQL.
La mise en miroir crée trois éléments dans votre espace de travail Fabric :
- Élément de la base de données 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 comme l'ingénierie des données, la science des données, et plus encore.
- Un Point de terminaison d’analytique SQL
- Un modèle sémantique par défaut
Chaque base de données mise en miroir dispose d'un point de terminaison d’analytique SQL autogénéré qui offre une expérience analytique riche en plus des tables Delta créées par le processus de mise en miroir. Les utilisateurs ont 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 qui référencent des données dans vos tables Delta Lake à partir de Snowflake.
- Créez des requêtes et des vues sans code et explorez les données visuellement sans écrire une ligne de code.
- Développez des vues SQL, des TVF (Table-valued Functions) inclus 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 analytique SQL, notamment SQL Server Management Studio (SSMS), l’extension mssql avec Visual Studio Code, et même GitHub Copilot.
Considérations de sécurité
Pour activer la mise en miroir de Fabric, vous devez disposer d'autorisations d'utilisateur pour votre base de données Snowflake qui contiennent 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 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.
Considérations relatives aux coûts de Snowflake mise en miroir
Fabric ne facture pas les frais d’entrée de données réseau dans OneLake pour la mise en miroir. Il n’existe aucun coût de mise en miroir lorsque vos données Snowflake sont répliquées dans OneLake.
Il existe des coûts de calcul et de requête cloud Snowflake lorsque les données sont mise 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 mis en miroir dans Fabric.
- Les requêtes de métadonnées exécutées en arrière-plan pour vérifier les modifications apportées aux données ne sont pas facturées pour le calcul de Snowflake ; cependant, les requêtes qui produisent des données telles qu'un
SELECT *sortira de l'entrepôt de Snowflake et le calcul sera facturé.
- 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 mise 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 mise en miroir dans Fabric.
Pour plus d’informations sur les coûts de requête cloud spécifiques à Snowflake, consultez la documentation Snowflake : compréhension du coût global.