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.
Les limitations actuelles dans les bases de données mises en miroir Microsoft Fabric de Snowflake sont répertoriées dans cette page. Cette page est susceptible d’être modifiée.
Limitations de connexion et d’authentification
- Le tableau suivant répertorie les méthodes d’authentification prises en charge pour la mise en miroir pour Snowflake :
| Méthode d’authentification | Soutenu | Remarques |
|---|---|---|
| Nom d'utilisateur et mot de passe | Oui | Authentification native de Snowflake |
| Microsoft Entra ID (SSO) | Oui | Authentification unique via Entra ID |
| Authentification avec une paire de clés | Oui | Paire de clés RSA pour les scénarios de compte de service |
| Identité de l’espace de travail | Non | Actuellement non pris en charge pour Snowflake |
L’identité de l’espace de travail n’est actuellement pas prise en charge pour la mise en miroir Snowflake. Il est disponible pour certaines sources telles que SharePoint.
La connectivité Private Link entre un espace de travail Fabric et Snowflake n'est pas encore disponible. Utilisez une passerelle de données de réseau virtuel ou une passerelle de données locale pour la connectivité privée dans l’intervalle.
Vous devez ajouter des destinataires de partage à l’espace de travail. Pour partager un jeu de données ou un rapport, commencez par ajouter access à l’espace de travail avec un rôle d’administrateur, de membre, de lecteur ou de contributeur.
Sensibilité à la casse : tous les identificateurs Snowflake, y compris le nom de l’entrepôt, le nom de la base de données, le nom du schéma, les noms de table et les noms de vue, sont sensibles à la casse lors de la configuration des connexions de mise en miroir et lors de l’utilisation de l’API REST de mise en miroir. La casse que vous saisissez dans Fabric doit correspondre exactement à ce qui est configuré dans Snowflake. Une casse incohérente peut entraîner des échecs de connexion ou empêcher certaines tables d’apparaître dans la réplication, souvent sans message d’erreur descriptif. Par exemple, si votre entrepôt Snowflake est nommé ANALYTICS_WH, vous devez entrer ANALYTICS_WH dans la connexion Fabric, et non analytics_wh.
Types d’objets pris en charge
- Le tableau suivant répertorie les types d’objets Snowflake pris en charge pour la mise en miroir :
| Type d’objet | Soutenu | Remarques |
|---|---|---|
| Tables managées | Oui | Entièrement pris en charge pour la réplication |
| Tables d’icebergs | Oui | Nécessite une connexion au stockage de la table Iceberg sous-jacente. Seules les tables Iceberg accessibles par la même connexion de stockage peuvent être mises en miroir simultanément. |
| Views | Oui | Prise en charge des synchronisations toutes les 12 heures |
| Vues matérialisées | Oui | Prise en charge des synchronisations toutes les 12 heures |
| Tables externes | Non | Non pris en charge |
| Tables temporaires | Non | Non pris en charge |
| Tables temporaires | Non | Non pris en charge |
| Tables dynamiques | Non | Non pris en charge |
Limitations de la réplication et des données
- S’il n’existe aucune mise à jour dans une table source, le moteur de réplicateur commence à se retirer avec une durée exponentiellement croissante pour cette table, jusqu’à une heure. La même chose peut se produire en cas d’erreur temporaire, ce qui empêche l’actualisation des données. Le moteur de réplicateur reprend automatiquement l’interrogation régulière après la détection des données mises à jour.
- La hiérarchie de schéma source est répliquée dans la base de données mise en miroir. Pour les bases de données mises en miroir créées avant l’activation de cette fonctionnalité, le schéma source est aplatit et le nom du schéma est encodé dans le nom de la table. Si vous souhaitez réorganiser des tables avec des schémas, recréez votre base de données mise en miroir. En savoir plus sur la hiérarchie de schémas source de réplication.
- La mise en miroir prend en charge la réplication de colonnes contenant des espaces ou des caractères spéciaux dans des noms (tels que
,;{}()\n\t=). Pour les tables sous réplication avant que cette fonctionnalité soit activée, vous devez mettre à jour les paramètres de base de données mis en miroir ou redémarrer la mise en miroir pour inclure ces colonnes. En savoir plus sur la Prise en charge du mappage de colonnes Delta. - Le nombre maximal de tables pouvant être mises en miroir dans Fabric est de 1 000 tables. Aucune table au-dessus de la limite de 1 000 ne peut actuellement être répliquée.
- Si vous sélectionnez Mettre en miroir toutes les données lors de la configuration de la mise en miroir, les tables à mettre en miroir seront déterminées en prenant les 1 000 premières tables lorsque toutes les tables sont triées par ordre alphabétique en fonction du nom du schéma, puis du nom de la table. Le reste des tableaux en bas de la liste alphabétique ne sera pas mis en miroir.
- Si vous désélectionnez miroir toutes les données et sélectionnez des tables individuelles, vous ne pouvez pas sélectionner plus de 1 000 tables.
- Colonnes calculées et tables calculées : les bases de données mises en miroir sont en lecture seule. Vous ne pouvez pas créer de colonnes calculées ou de tables calculées directement sur une base de données mise en miroir. Pour ajouter des colonnes calculées, créez un Lakehouse et utilisez des raccourcis pour référencer les données mises en miroir, puis créez vos colonnes calculées dans Lakehouse à l’aide de notebooks ou de SQL.
Limitations des performances
- Si vous modifiez la plupart des données d’une table volumineuse, il est plus efficace d’arrêter et de redémarrer la mise en miroir. L’insertion ou la mise à jour de milliards d’enregistrements peut prendre beaucoup de temps.
- Certaines modifications de schéma ne sont pas immédiatement reflétées. Certaines modifications de schéma ont besoin d’une modification de données (insertion, mise à jour ou suppression) avant que les modifications de schéma ne soient répliquées sur Fabric.
- Considérations interrégions : si votre instance Snowflake et votre capacité de Fabric se trouvent dans différentes régions cloud, vous risquez d’avoir une latence de réplication plus élevée et des frais de sortie de données. Pour optimiser les performances et éviter les coûts de sortie inter-régions, déployez votre capacité de Fabric dans la même région cloud que votre instance Snowflake. Si le déploiement interrégion est inévitable, comptez des frais de sortie supplémentaires de Snowflake et/ou Azure. Pour plus d’informations, consultez la documentation de sortie Snowflake .
- Lors de la mise en miroir de données de Snowflake vers OneLake d’un client, le processus étapene normalement les données via une URL inline pour améliorer les performances. Si le paramètre de niveau compte Snowflake PREVENT_UNLOAD_TO_INLINE_URL a la valeur true, le comportement suivant s’applique :
| Méthode de connexion | Impact lorsque PREVENT_UNLOAD_TO_INLINE_URL = true |
|---|---|
| Direct (point de terminaison public) | La mise en miroir revient à lire directement à partir de Snowflake. Ce mécanisme de secours entraîne des temps de réplication plus longs et un risque accru de délais d’attente de connexion, en particulier pour les jeux de données volumineux. |
| passerelle de données Réseau virtuel (réseau virtuel) | La mise en miroir est complètement bloquée. Les scénarios de passerelle de réseau virtuel ne peuvent pas utiliser la lecture directe et nécessitent le chemin d’accès intermédiaire d’URL inline. |
| Passerelle de données locale (OPDG) | La mise en miroir est complètement bloquée. Les scénarios OPDG ne peuvent pas utiliser la lecture directe et doivent utiliser le chemin de staging pour les URL inline. |
Résolution planifiée : la prise en charge de l’intégration du stockage est en cours de développement et fournit un autre chemin intermédiaire qui fonctionne lorsque PREVENT_UNLOAD_TO_INLINE_URL a la valeur true. Cette solution débloque les scénarios de réseau virtuel et OPDG. Consultez cette page pour connaître les mises à jour sur la disponibilité.
-
Comportement du réensemencement : Un réensemencement correspond à un rechargement complet des données d’une table entière. Contrairement à la synchronisation incrémentielle (qui traite uniquement les lignes modifiées), une réinitialisation relit et réécrit toutes les données de la table. Les réinitialisations peuvent entraîner des coûts de calcul Snowflake importants, en particulier pour les tables volumineuses.
- Qu’est-ce qui déclenche une réinitialisation :
| Trigger | Description |
|---|---|
| Modifications du langage de définition de données (DDL) | Toute modification du DDL qui modifie l’horodatage DDL d’une table déclenche une réinitialisation. Ce déclencheur inclut des instructions ALTER TABLE qui ajoutent, suppriment ou renomment des colonnes, modifient les types de données ou modifient des propriétés de table. |
| Outils de modification de schéma (par exemple, DBT) | Si un outil tel que DBT modifie les définitions de table selon une planification périodique (par exemple, via dbt run qui supprime et recrée des tables), chaque modification déclenche une réexécutation. L’exécution de ces outils fréquemment (par exemple, toutes les quelques minutes) peut entraîner des boucles de réexécutation continue. |
| Arrêt et redémarrage de la mise en miroir | Chaque fois que vous arrêtez et redémarrez la mise en miroir, la table entière est récupérée à nouveau à partir de zéro. |
| Pause de capacité étendue | Si une capacité Fabric est suspendue pendant une période prolongée, la mise en miroir peut redémarrer depuis le début lorsqu’elle est reprise. Consultez Modifications apportées à la capacité de Fabric. |
- Bonnes pratiques pour éviter les réensemencements inutiles :
- Planifiez les modifications de schéma en dehors de la mise en miroir active. Si vous utilisez DBT ou d’autres outils de gestion de schéma, planifiez-les pendant les fenêtres de maintenance ou suspendez la mise en miroir avant d’exécuter des modifications de schéma.
- Évitez les modifications fréquentes de DDL. Consolidez les modifications de schéma en moins de lots plus volumineux plutôt que d’apporter des modifications incrémentielles tout au long de la journée.
- Surveillez les réeeds inattendus. Dans la page État de la mise en miroir, surveillez les tables qui affichent à plusieurs reprises le comportement de copie initiale. Si une table volumineuse est réamorcée à quelques minutes d’intervalle, vérifiez s’il y a des changements DDL en amont.
- Tenez compte de l’impact sur les coûts. La recréation d’une table de 226 millions de lignes (~26,5 Go) nécessite un temps de calcul important. Multipliez ce coût par la fréquence des modifications de schéma pour estimer l’impact des coûts.
Limitations de sécurité
- Fabric ne réplique pas les stratégies Snowflake RLS (sécurité au niveau des lignes) et CLS (sécurité au niveau des colonnes). Vous devez reconfigurer manuellement des stratégies de sécurité équivalentes dans Fabric.
- Les destinataires de partage doivent être ajoutés à l’espace de travail. Pour partager un jeu de données ou un rapport, commencez par ajouter access à l’espace de travail avec un rôle d’administrateur, de membre, de lecteur ou de contributeur.
Considérations relatives au coût et à la facturation
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, éliminant ainsi la nécessité de réveiller un entrepôt distinct. Certaines organisations peuvent préférer un entrepôt dédié pour l’isolation budgétaire. Ce choix 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 le comportement de copie initiale répétée et passez en revue la section Reseeding pour les déclencheurs et les 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.
Régions prises en charge
La mise en miroir de bases de données et la mise en miroir ouverte sont disponibles dans toutes les régions Microsoft Fabric. Pour plus d'informations, voir Disponibilité des régions Fabric.