Questions fréquentes sur la mise en miroir de Snowflake dans Microsoft Fabric

Pour Snowflake, nous utilisons une zone de transit pour stocker à la fois les données d’instantané et les données de changements dans OneLake, afin d’améliorer les performances, car nous convertissons ces fichiers de la zone de transit au format Delta VertiParquet.

Les tables gérées, les tables Iceberg et les vues sont prises en charge pour la réplication. Les tables externes, transitoires, temporaires et dynamiques ne sont pas prises en charge. Pour les tables Iceberg, une connexion au stockage sous-jacent de la table Iceberg est requise lors de la configuration. Pour plus d’informations sur les problèmes connus liés aux vues (telles que le mappage de type de données), consultez Limitations.

Sélectionnez la roue dentée des paramètres, puis sélectionnez sur Gérer la connexion et les passerelles. Vous pouvez également supprimer des connexions existantes de cette page.

Les méthodes d’authentification suivantes sont prises en charge :

• Nom d’utilisateur et mot de passe — Authentification native Snowflake
• Microsoft Entra ID (SSO) — Authentification unique via Entra ID
• Authentification par paire de clés : paire de clés RSA pour les scénarios de compte de service

1. Réutiliser un entrepôt existant. Configurez la mise en miroir pour utiliser le même entrepôt Snowflake que vos applications utilisent déjà pour mettre à jour les tables sources. Cela évite le surcoût lié au démarrage d’un entrepôt distinct dédié à la mise en miroir. Lorsque votre application met à jour une table, le réplicateur de mise en miroir prend en compte les modifications presque immédiatement, tant que l’entrepôt de données est encore actif. 2. Mettre en miroir uniquement les tables dont vous avez besoin. Évitez de mettre en miroir une base de données entière lorsque vous avez uniquement besoin d’un sous-ensemble de tables. La mise en miroir à grande échelle peut entraîner des pics importants de consommation Snowflake et de capacité Fabric. 3. Surveillez les réeeds inattendus. Une réécriture réécrit la table complète et entraîne un coût de calcul proportionnel à sa taille. Vérifiez la page État de la mise en miroir afin d’identifier les tables qui présentent de façon répétée le comportement de copie initiale. 4. Utilisez les budgets Snowflake et les limites de crédit. Définissez les moniteurs de ressources Snowflake et les budgets pour plafonner les coûts de calcul liés à la mise en miroir.

Fabric ne facture pas de frais d’ingestion dans OneLake pour la mise en miroir.

Si elle est hébergée en dehors d’Azure, reportez-vous à Snowflake et à votre documentation cloud pour connaître les coûts de sortie. Si elle est hébergée dans Azure, mais dans une région différente de votre capacité Fabric, les sorties de données sont facturées. S’il est hébergé dans Azure dans la même région, il n’existe aucune sortie de données.

Non. La mise en miroir s’exécute en continu et ne prend actuellement pas en charge la configuration des planifications de réplication ou des fenêtres basées sur le temps. Le réplicateur interroge en permanence afin de détecter les changements, ce qui génère une consommation continue des ressources de calcul Snowflake. Si vous devez limiter le calcul pendant certaines périodes, vous pouvez arrêter et redémarrer manuellement la mise en miroir, mais notez que le redémarrage déclenche une réinitulation complète de toutes les tables mises en miroir.

Cela dépend de la taille des données qui sont introduites.

Latence en temps quasi réel.

Oui, ce sont toutes des tables delta ordonnées selon v.

Consultez Surveiller la réplication miroir dans Fabric.

Oui, nous prenons en charge la mise en miroir via une passerelle de données locale et via une passerelle de données Réseau virtuel (VNet).

Les données des tables sources seront réinitialisées. Chaque fois que vous arrêtez puis redémarrez, la table entière est de nouveau récupérée.

Nous arrêtons la mise en miroir de cette table spécifique et la supprime de OneLake.

Non, nous supprimons simplement les tables de streaming.

Oui, vous pouvez, mais vous ne devriez pas avoir besoin de. Une fois les données dans Fabric, elles peuvent être partagées à partir de là.

Oui, des tables spécifiques peuvent être sélectionnées pendant la configuration de la mise en miroir.

Un reseed (rechargement de données complètes) est déclenché par l’une des opérations suivantes :

• Les modifications DDL qui modifient l’horodatage DDL d’une table, par exemple, les opérations ALTER TABLE qui ajoutent ou suppriment des colonnes.
• Outils de modification de schéma tels que dbt qui suppriment et recréent des tables selon une planification.
• Arrêt et redémarrage de la mise en miroir via le portail Fabric ou l’API.
• Pause de capacité étendue. Si la capacité Fabric est suspendue pendant une longue période, la mise en miroir peut nécessiter un réamorçage lors de la reprise.

Si des tables passent à plusieurs reprises par la copie initiale (reseed) au lieu de la synchronisation incrémentielle :

1. Vérifiez les changements du schéma en amont. Vérifiez si un outil tel que dbt modifie les définitions de table selon une planification périodique. Même de petites modifications DDL peuvent déclencher un réamorçage.
2. Passez en revue la page État de la mise en miroir. Recherchez les tables qui affichent des horodatages de copie initiale répétés à intervalles réguliers.
3. Suspendre les modifications de schéma pendant la mise en miroir active. Si les exécutions de dbt en sont la cause, planifiez ces exécutions pendant les fenêtres de maintenance ou suspendez la mise en miroir avant d’effectuer des modifications de schéma.
4. Surveillez l’utilisation de l’entrepôt Snowflake. Vérifiez les vues d’utilisation des comptes Snowflake pour voir si les requêtes liées à la mise en miroir dominent le calcul.
5. N’oubliez pas que chaque réécriture traite les données complètes de la table et entraîne un coût de calcul Snowflake proportionnel à la taille de la table. proportionnelle à la taille de la table.

Non.

Non, les données ne sont pas préparées hors de l’environnement du client ; elles le sont dans le OneLake du client.

Une capacité Power BI Premium, une capacité Fabric ou une capacité d’essai est nécessaire. Pour plus d’informations sur les licences, consultez licences Microsoft Fabric.

Le calcul Fabric utilisé pour répliquer vos données dans Fabric OneLake est gratuit. Le coût du stockage en miroir est gratuit dans la limite d’une capacité donnée. 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.

Contenu connexe

• Qu’est-ce que la mise en miroir dans Fabric ?
• Vue d’ensemble du connecteur Snowflake