Share via

Mise en miroir snowflake (préversion)

  • Article

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 didacticiel sur la configuration de votre base de données Snowflake pour la mise en miroir dans Fabric, consultez Didacticiel : configurer les bases de données mises en miroir de Microsoft Fabric à partir de Snowflake (préversion).

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

Diagramme de la mise en miroir de bases de données Fabric pour Snowflake.

La mise en miroir crée trois éléments dans votre espace de travail Fabric :

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.

Outre l'éditeur de requête SQL de Microsoft Fabric, il existe un vaste écosystème d'outils capables d'interroger le point de terminaison d’analytique SQL, notamment SQL Server Management Studio, Azure Data Studio, 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 STREAM
  • SELECT table
  • SHOW tables
  • DESCRIBE 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.

Capture d’écran du graphique des coûts Snowflake.

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.

Étape suivante

Didacticiel : configurer des bases de données Microsoft Fabric miroir à partir de Snowflake (préversion)

Contenu connexe