Gouvernance des coûts de Snowflake Connector for Google Analytics Raw Data

Snowflake Connector for Google Analytics Raw Data est soumis aux Conditions de connecteur.

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 Google Analytics Raw Data.

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 à Explorer le 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 les coûts facturés pour les composants séparément :

Pour une introduction à ces trois composantes du coût, reportez-vous à Compréhension du coût global.

Recommandations générales

Pour déterminer les coûts générés par le connecteur, vous pouvez créer un compte distinct réservé au connecteur. L’utilisation d’un compte spécifique vous permet de suivre le transfert de données exact généré par le connecteur.

Si vous ne pouvez pas utiliser de compte distinct pour le connecteur, vous pouvez envisager les options suivantes :

  • Pour faciliter le suivi des coûts de stockage, créez une base de données distincte pour le stockage des données ingérées.

  • Pour déterminer les coûts de calcul exacts, attribuez un entrepôt réservé au connecteur.

  • Pour créer des rapports de coûts personnalisés, utilisez des balises d’objet sur les bases de données et l’entrepôt.

Coût de calcul

Nous vous recommandons de créer un entrepôt dédié uniquement au 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 dans lesquelles de grands volumes de données sont ingérés, cela peut empêcher le connecteur d’ingérer toutes les données. Un gros avantage réside dans le fait que la taille d’entrepôt peut être adaptée au volume de données.

Pour des informations sur la manière de vérifier les crédits consommés par l’entrepôt, voir 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, utilisez la requête pour répartir l’utilisation de l’entrepôt et ajoutez la clause WHERE suivante à la vue QUERY_HISTORY :

WAREHOUSE_NAME = '<connector warehouse name>' AND
ROLE_NAME = '<role created for the connector to ingest data>'
Copy

Notez que le rôle est le nom créé lors de l’installation du connecteur, par exemple SNOWFLAKE_CONNECTOR_FOR_GOOGLE_ANALYTICS_RAW_DATA.

La requête ne donne qu’une approximation du coût.

Coût de stockage

Snowflake Connector for Google Analytics Raw Data stocke les données à deux endroits :

  • Base de données du connecteur, créée à partir du partage public et contenant l’état interne du connecteur

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

Pour vérifier l’utilisation du stockage via Snowsight, vous pouvez utiliser une base de données distincte pour le stockage des données ingérées. Cela vous permet de filtrer les graphiques d’utilisation du stockage par objet, ce qui montre l’utilisation par base de données individuelle. Vous pouvez également voir l’utilisation du stockage en interrogeant la vue DATABASE_STORAGE_USAGE_HISTORY et en filtrant en fonction des 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

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 Google Analytics Raw Data. Les réponses de Google Analytics Raw Data 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 fonctions externes au niveau du compte. Pour accéder au nombre d’octets transférés, utilisez la vue DATA_TRANSFER_HISTORY et filtrez par type de transfert EXTERNAL_ACCESS.

Il peut y avoir des frais supplémentaires liés au transfert de données du côté BigQuery : stockage de données + trafic d’entrée. Plus précisément, le connecteur utilise ce que l’on appelle des lectures en continu (API Storage Read).

Pour des informations détaillées, voir la documentation associée.

Coût de la tâche de contrôle d’intégrité

Le connecteur crée une tâche sans serveur interne qui inspecte régulièrement l’intégrité de l’instance et envoie un résumé à Snowflake à des fins de surveillance. La tâche est créée à la fin de l’assistant d’installation ou via l’appel de CONFIGURE_CONNECTION dans une feuille de calcul. Elle génère un coût de calcul fixe pouvant atteindre 0,5 crédit par jour, même si aucune propriété n’est activée pour l’ingestion.

La tâche ne peut pas être explicitement suspendue ni supprimée, mais la mise en pause du connecteur désactivera également le contrôle d’intégrité.

Détermination de la taille d’entrepôt optimale pour l’instance de connecteur

Pour trouver la taille d’entrepôt optimale pour le connecteur, vous devez prendre en compte les facteurs qui affectent les performances du connecteur, tels que les suivants :

  • Nombre de propriétés Google Analytics

  • Quantité de données produites par chacune des propriétés

  • Planification de synchronisation des propriétés

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 déterminer si vous pouvez réduire la taille de l’entrepôt, voir Surveillance de la charge de l’entrepôt.

Pour Snowflake Connector for Google Analytics Raw Data, nous vous recommandons de commencer par utiliser un entrepôt XSMALL, puis d’expérimenter avec un entrepôt plus grand afin d’améliorer éventuellement les performances.

En outre, les besoins en taille d’entrepôt peuvent considérablement varier d’une zone de préparation d’ingestion à une autre. Prenons un exemple :

  • Lors de l’ingestion initiale, lorsque le connecteur charge des données historiques, peut-être des années de données, il peut être utile de disposer d’un entrepôt plus grand.

  • Pour l’ingestion quotidienne normale, lors du chargement uniquement des incréments de données quotidiens, les entrepôts les plus petits suffiront.

En outre, si un grand ensemble de propriétés est activé pour l’ingestion, envisagez un entrepôt plus grand afin que le connecteur puisse suivre le flux de données.