Mise en miroir de flocons dans Microsoft Fabric

Le mirroring dans Fabric offre une expérience simple pour éviter les processus ETL complexes (Extraction, Transformation, Chargement) et intégrer vos données existantes d’entrepôt Snowflake 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éverrouiller des scénarios puissants d'informatique décisionnelle, 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 Tutorial : Configurer Microsoft Fabric bases de données mises en miroir à 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 de l’entrepôt et du point de terminaison d’analytique SQL.

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 données des tables managées et des vues dans OneLake, et conversion au format Parquet, dans un format prêt pour l’analyse.
  • Réplication des métadonnées des tables Iceberg dans OneLake à l’aide de raccourcis vers le stockage contenant vos tables Iceberg et de la conversion de ce stockage. OneLake convertit automatiquement ces tables Iceberg en tables mises en forme Delta Lake pour une utilisation dans les charges de travail Fabric.
• Un Serveur d'analyse 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 des requêtes et des vues sans code et explorez les données de façon visuelle sans écrire une seule ligne de code.
• Développez des vues SQL, des fonctions table-values en ligne (TVF) 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 des entrepôts et des Lakehouses différents 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, notamment SQL Server Management Studio (SSMS), l'extension MSSQL pour Visual Studio Code et même GitHub Copilot.

Types d’objets Snowflake pris en charge

Le tableau suivant répertorie les types d’objets Snowflake pris en charge pour la mise en miroir :

Considérations relatives à la sécurité

Pour activer la mise en miroir de Fabric, vous aurez besoin d’autorisations utilisateur de votre base de données Snowflake qui contient les autorisations suivantes :

• CREATE STREAM
• SELECT table
• SHOW tables
• DESCRIBE tables

Pour plus d'informations, consultez la documentation Snowflake sur Privilèges d'accès pour les tables de streaming et Autorisations requises pour les streams.

Méthodes d’authentification prises en charge

Le tableau suivant répertorie les méthodes d’authentification prises en charge pour la mise en miroir pour Snowflake :

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 Tutorial : Configurer Microsoft Fabric bases de données mises en miroir à partir de Snowflake.

Private Link et l’identité de l’espace de travail :

• Private Link : La connectivité directe Private Link entre un espace de travail Fabric et Snowflake n'est pas encore prise en charge. Dans l’intervalle, utilisez une passerelle de données de réseau virtuel ou une passerelle de données locale pour la connectivité privée.
• Identité d’espace de travail : l’authentification par identité d’espace de travail n’est actuellement pas prise en charge pour la mise en miroir 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 pour la duplication est gratuit jusqu'à une limite déterminée par la capacité. Pour plus d’informations, consultez Cost de la mise en miroir et Microsoft Fabric Tarification. Le calcul pour l’interrogation de données à l’aide de SQL, de Power BI ou de 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 associés à Snowflake lorsque les données sont mises en miroir : calcul de l’entrepôt virtuel Snowflake 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 y a des modifications de données lues dans Snowflake et sont à leur tour reflétées dans Fabric.
  • Toutes les requêtes de métadonnées exécutées en arrière-plan pour vérifier les modifications de données ne sont pas facturées pour un calcul Snowflake. Toutefois, les requêtes qui génèrent des données, telles qu’une SELECT *, réveilleront l’entrepôt Snowflake, et le calcul sera facturé.
• Calcul des frais 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 de l’entrepôt virtuel et des services cloud pour la base de données Snowflake associée répliquée 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 entièrement du processus par lequel les modifications de données sont lues à partir de Snowflake et répliquées dans Fabric.

Recommandations d’optimisation des coûts

Pour réduire les coûts de calcul Snowflake à partir de la mise en miroir, tenez compte des meilleures pratiques suivantes :

• Réutiliser un entrepôt existant. Au lieu de créer un entrepôt dédié pour la mise en miroir, configurez la mise en miroir pour utiliser le même entrepôt que celui que vos applications utilisent déjà pour mettre à jour les tables sources. Cette approche évite les cycles de mise en éveil et de suspension automatique inutiles de l’entrepôt. Lorsque votre application met à jour une table, le réplicateur de mise en miroir récupère les modifications presque immédiatement pendant que l’entrepôt est toujours actif, de sorte que vous n’avez pas besoin de réveiller un entrepôt distinct. Certaines organisations peuvent préférer un entrepôt dédié pour l’isolation budgétaire. Cette préférence est un compromis entre les économies de coûts et la granularité budgétaire.
• Mettre en miroir uniquement les tables dont vous avez besoin. La mise en miroir d’une base de données entière peut entraîner une consommation Snowflake anormalement élevée et des pics de capacité Fabric. Commencez par sélectionner uniquement les tables requises pour vos scénarios d’analyse. Vous pourrez ajouter des tableaux plus tard, si nécessaire.
• Surveillez les réeeds inattendus. Un reseed (rechargement de données complètes) traite l’intégralité de la table et entraîne un coût de calcul proportionnel à la taille de la table. Les modifications de schéma, y compris celles déclenchées par des outils tels que DBT, peuvent entraîner des resynchronisations complètes répétées. Surveillez la page État de la mise en miroir pour les tables qui affichent un comportement de copie initiale répétée et passez en revue la section Reseeding ci-dessous pour obtenir des déclencheurs et des conseils de dépannage.
• N’oubliez pas que la mise en miroir s’exécute en continu. La mise en miroir ne prend actuellement pas en charge la planification ou les fenêtres de réplication. Le réplicateur interroge continuellement le système pour détecter les changements, ce qui génère une consommation continue de ressources de calcul Snowflake. Planifiez vos budgets Snowflake en conséquence.

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.

Étape suivante

Contenu connexe

• Comment : Sécuriser les données des bases de données miroirs Microsoft Fabric à partir de Snowflake
• Surveiller la réplication mise en miroir de la base de données Fabric