Gouvernance des coûts de Snowflake Connector for SharePoint¶
Note
Le Snowflake Connector for SharePoint est soumis aux `Conditions du connecteur<https://www.snowflake.com/legal/snowflake-connector-terms/>`_.
Important
Merci de votre intérêt pour le Snowflake Connector pour SharePoint. Nous nous concentrons maintenant sur une solution de nouvelle génération qui offrira une expérience considérablement améliorée. Par conséquent, le déplacement de ce connecteur vers l’état de mise à disposition générale ne figure actuellement pas dans la feuille de route de notre produit. Vous pouvez continuer à utiliser ce connecteur en tant que fonction de prévisualisation, mais notez que la prise en charge des futures corrections de bogues et améliorations n’est pas garantie. La nouvelle solution est disponible en tant que Connecteur Openflow pour SharePoint et comprend de meilleures performances, une meilleure personnalisation et des options de déploiement améliorées.
Ce chapitre présente les meilleures pratiques en matière de gouvernance des coûts et de recherche de la taille d’entrepôt optimale pour Snowflake Connector for SharePoint.
Mesure du coût du connecteur¶
Si le connecteur dispose d’un compte séparé uniquement pour l’ingestion et le stockage des données, et que le compte ne présente aucune autre activité (telle que l’exécution de requêtes par des utilisateurs utilisant les données ingérées), vous pouvez lire le coût global au niveau du compte. Pour en savoir plus, reportez-vous à Exploration du coût global.
Si le compte n’est pas dédié uniquement au connecteur ou si vous devez étudier les coûts de manière plus approfondie, vous devez analyser séparément les coûts facturés pour les trois composants :
Pour une introduction à ces trois composantes du coût, reportez-vous à la rubrique Comprendre le coût général.
Recommandations générales¶
Pour obtenir le coût généré par le connecteur, nous vous recommandons de créer un compte séparé uniquement pour l’utilisation du connecteur. Vous pouvez ainsi suivre le transfert exact des données générées par le connecteur.
Si vous ne pouvez pas utiliser un compte distinct pour le connecteur, essayez ce qui suit :
Créez une base de données distincte pour le stockage des données ingérées afin de faciliter le suivi des coûts de stockage.
Allouez un entrepôt uniquement pour le connecteur afin d’obtenir le coût de calcul exact.
Utilisez les balises d’objet sur les bases de données et un entrepôt pour créer des rapports de coûts personnalisés.
Coût de calcul¶
Nous vous recommandons de créer un entrepôt distinct uniquement pour le connecteur. Cette configuration vous permet de créer des moniteurs de ressources sur l’entrepôt. Vous pouvez utiliser les moniteurs pour envoyer des alertes par e-mail et suspendre l’entrepôt, en arrêtant le connecteur lorsque le quota de crédit défini est dépassé. Le connecteur reprend automatiquement après le renouvellement du quota de crédit. Notez que si le quota de crédit est trop bas dans les configurations où de grands volumes de données sont ingérés, le connecteur risque de ne pas ingérer toutes les données.
Pour obtenir des informations sur la manière de vérifier les crédits consommés par l’entrepôt, reportez-vous à Exploration des coûts de calcul. Vous pouvez également attribuer à l’entrepôt des balises d’objets et utiliser ces balises pour créer des rapports de coûts.
Si l’entrepôt utilisé par le connecteur est utilisé par d’autres flux de travail, vous pouvez répartir le coût par rôle. Pour répartir l’utilisation par rôle, consultez Attribution de coûts et ajoutez la clause WHERE suivante sur la vue QUERY_HISTORY :
warehouse_name = '<connector warehouse name>' AND role_name = 'APP_PRIMARY'
La requête ne donne qu’une approximation du coût.
Note
Une seule application native peut utiliser l’entrepôt, sinon les coûts des différentes applications sont indissociables, car chaque application native utilise le même nom de rôle (APP_PRIMARY).
Coût de la fonction d’analyse de document¶
Pour les considérations de coût liées à la fonction d’analyse de document, voir Considérations relatives aux clients.
Coût du Cortex Search Service¶
Pour les considérations liées aux coûts du Cortex Search Service, voir Considérations de coût.
Coût de stockage¶
Snowflake Connector for SharePoint stocke les données à deux endroits :
Base de données du connecteur, créée à partir de l’annonce et contenant l’état interne du connecteur.
Le schéma spécifié par l’utilisateur dans lequel les données ingérées sont stockées.
Le stockage de données est également utilisé par la fonctionnalité Fail-safe de Snowflake. La quantité de données stockées dans Fail-safe dépend des mises à jour de tables effectuées par le connecteur. La quantité de données augmente si les lignes de la table ingérées à partir de SharePoint sont fréquemment mises à jour ou si la table entière est rechargée. En général, sept à dix jours après la mise en place du connecteur, la quantité de données Fail-safe se stabilise (en supposant qu’aucun rechargement n’est effectué et que le flux de données ingérées se maintient à un rythme régulier).
Si vous souhaitez vérifier l’utilisation du stockage dans Snowsight, nous vous recommandons de disposer d’une base de données distincte pour le stockage des données ingérées. Vous pouvez ainsi filtrer les graphiques d’utilisation du stockage par objet, qui indiquent l’utilisation par bases de données distinctes. Vous pouvez également le faire en interrogeant la Vue DATABASE_STORAGE_USAGE_HISTORY et en filtrant par les deux bases de données utilisées par le connecteur.
Si la base de données contient d’autres schémas sans rapport avec le connecteur, vous pouvez interroger l’utilisation du stockage d’un schéma spécifique dédié aux données ingérées à partir du connecteur. Vous pouvez obtenir les informations à partir de la Vue TABLE_STORAGE_METRICS après avoir filtré par nom de base de données et de schéma et agrégé les colonnes avec l’utilisation du stockage.
Coûts du transfert des données¶
Le connecteur utilise un accès externe pour récupérer des données depuis SharePoint. Snowflake ne facture que le trafic de sortie généré par le connecteur, en fonction de la taille des requêtes du connecteur vers SharePoint. Les réponses de SharePoint ne génèrent pas de coûts du côté de Snowflake.
Les informations sur l’utilisation du transfert de données ne sont disponibles que sous une forme agrégée pour toutes les intégrations d’accès externe au niveau du compte. Pour accéder au nombre d’octets transférés, utilisez la Vue DATA_TRANSFER_HISTORY et filtrez par le type de transfert EXTERNAL_ACCESS.
Coût de la tâche de contrôle d’intégrité¶
Le connecteur crée une tâche sans serveur qui vérifiera régulièrement le statut d’intégrité de votre instance d’application et enverra uniquement le résultat résumé (à savoir, si l’application est intègre ou non) à Snowflake. La tâche est créée à la fin de l’assistant d’installation (ou via l’appel de la procédure FINALIZE_CONNECTOR_CONFIGURATION dans les feuilles de calcul). Elle s’exécute en arrière-plan et génère un coût fixe pouvant atteindre 0,5 crédit/jour, même si aucun dossier SharePoint n’est activé pour la réplication.
La tâche ne peut pas être arrêtée ni supprimée manuellement. Toutefois, pour réduire ce coût, vous pouvez appeler la procédure PAUSE_CONNECTOR, qui désactivera la tâche et ne générera aucun coût lorsque le connecteur n’est pas utilisé.
Optimisation des coûts¶
Détermination de la taille optimale de l’entrepôt pour l’instance du connecteur¶
Pour trouver la taille d’entrepôt optimale pour le connecteur, vous devez prendre en compte les facteurs qui affectent ses performances, tels que la taille de l’instance, le nombre de tables activées et la planification de synchronisation de chaque table. Par exemple, si seules quelques tables sont activées, le connecteur peut ne pas bénéficier d’une parallélisation accrue.
Nous vous recommandons de définir un ensemble d’attentes mesurables, telles que les intervalles de temps dans lesquels toutes les tables doivent être synchronisées, et de choisir la plus petite taille d’entrepôt qui réponde à ces attentes. Pour de grandes quantités de données ingérées avec des dizaines de tables synchronisées, la recommandation par défaut est « entrepôt de grande taille ». En revanche, si vous souhaitez simplement tester le connecteur et activer une seule table pour l’ingestion, un entrepôt X-Small devrait suffire. Pour savoir si vous pouvez réduire la taille de l’entrepôt, voir Surveillance de la charge de l’entrepôt.