Une organisation peut répartir le coût de l’utilisation de Snowflake entre des unités logiques au sein de l’organisation (par exemple, entre différents départements, environnements ou projets). Ce modèle de refacturation est utile à des fins comptables et permet d’identifier les domaines de l’organisation qui pourraient bénéficier de contrôles et d’optimisations susceptibles de réduire les coûts.
Pour attribuer les coûts à différents groupes tels que les départements ou les projets, utilisez l’approche recommandée suivante :
Utilisez les balises d’objet pour associer des ressources et des utilisateurs à des départements ou à des projets.
Utilisez les balises de requête pour associer des requêtes individuelles à des départements ou à des projets lorsque les requêtes sont effectuées par la même application pour le compte d’utilisateurs appartenant à plusieurs départements.
Les scénarios d’attribution des coûts suivants sont les plus couramment rencontrés. Dans ces scénarios, les entrepôts sont utilisés comme exemple de ressource engendrant des coûts.
Ressources utilisées exclusivement par un seul centre de coûts ou un seul département : L’utilisation de balises d’objet pour associer des entrepôts à un département en est un exemple. Vous pouvez utiliser ces balises d’objet pour attribuer les coûts encourus par ces entrepôts à l’ensemble de ce département.
Ressources partagées par des utilisateurs de plusieurs départements : Un entrepôt partagé par des utilisateurs de différents départements en est un exemple. Dans ce casse-tête, vous utilisez des balises d’objet pour associer chaque utilisateur à un département. Les coûts des requêtes sont attribués aux utilisateurs. À l’aide des balises d’objet attribuées aux utilisateurs, vous pouvez ventiler les coûts par département.
Applications ou flux de travail partagés par des utilisateurs de différents services : Une application qui émet des requêtes pour le compte de ses utilisateurs en est un exemple. Dans ce casse-tête, chaque requête exécutée par l’application se voit attribuer une balise de requête qui identifie l’équipe ou le centre de coûts de l’utilisateur au nom duquel la requête est effectuée.
Les sections suivantes expliquent comment établir des balises d’objet dans vos comptes et fournissent les détails de chacun de ces scénarios d’attribution des coûts.
Paramétrage des balises d’objets pour l’attribution des coûts¶
Lorsque vous configurez des balises pour représenter les groupes que vous souhaitez utiliser pour l’attribution des coûts, vous devez déterminer si les groupes s’appliquent à un compte unique ou à des comptes multiples. Cela détermine l’ensemble de vos balises.
Supposons, par exemple, que vous souhaitiez attribuer les coûts en fonction du département.
Si les ressources utilisées par le service sont situées dans un seul compte, vous créez les balises dans une base de données de ce compte.
Si les ressources utilisées par le service couvrent plusieurs comptes, vous créez les balises dans un compte clé de votre organisation (par exemple, dans votre compte d’organisation), et vous rendez ces balises disponibles dans d’autres comptes par le biais de la réplication <label-cost_attribute_tag_replicate>.
Les sections suivantes expliquent comment créer les balises, les répliquer et les appliquer aux ressources.
Les exemples présentés dans ces sections utilisent le rôle personnalisé tag_admin, qui est supposé avoir reçu les privilèges nécessaires à la création et à la gestion des balises. Au sein de votre organisation, vous pouvez utiliser des privilèges plus granulaires pour le balisage d’objets afin de développer une stratégie de balisage sécurisée.
Dans le cadre de la conception de la stratégie, décidez de la base de données et du schéma dans lesquels vous prévoyez de créer les balises.
Vous pouvez créer une base de données et un schéma dédiés aux balises.
Si vous souhaitez baliser des ressources dans différents comptes de votre organisation, vous pouvez créer les balises dans un compte clé de votre organisation (par exemple, dans le compte de votre organisation).
L’exemple suivant crée une base de données nommée cost_management et un schéma nommé tags pour les balises que vous planifiez d’utiliser :
Avec cost_management et tags sélectionnés comme base de données et schéma actuels, créez une balise nommée cost_center et définissez les valeurs autorisées pour la balise comme étant les noms des centres de coûts :
Par exemple, pour répliquer les balises sur les comptes my_org.my_account et my_org.my_account_2, exécutez cette instruction dans votre compte d’organisation :
Ensuite, dans chaque compte dans lequel vous souhaitez rendre les balises disponibles, créez un groupe de réplication secondaire et actualisez ce groupe à partir du groupe principal :
Après avoir créé et répliqué les balises, vous pouvez utiliser ces dernières pour identifier les entrepôts et les utilisateurs appartenant à chaque département. Par exemple, comme le service des ventes utilise à la fois warehouse1 et warehouse2, vous pouvez attribuer à la balise cost_center la valeur 'SALES' pour les deux entrepôts.
Astuce
Idéalement, vous devriez disposer de flux de travail qui automatisent le processus d’application de ces balises lorsque vous créez des ressources et des utilisateurs.
Si vous souhaitez automatiser le processus de balisage des utilisateurs pour l’attribution des coûts, vous pouvez le faire en provisionnant les utilisateurs Snowflake via un fournisseur d’identité SCIM tel que Microsoft Entra ID ou Okta. Avec SCIM, vous pouvez automatiquement appliquer des balises d’attribution de coûts aux utilisateurs lors de leur création ou de leur mise à jour, ce qui élimine la nécessité d’exécuter``ALTER USER <user_name> SET TAG`` manuellement pour chaque nouvel utilisateur et garantit la cohérence de vos balises d’attribution des coûts lorsque des utilisateurs rejoignent l’entreprise ou changent de département.
Lorsque de l’utilisation du SCIM, l’attribut personnalisé snowflakeTags accepte une liste de références de balises entièrement qualifiées séparées par des virgules. Par exemple, pour affecter un utilisateur au centre de coûts finance lors du provisionnement, incluez la valeur suivante dans la charge utile SCIM de l’utilisateur :
Les balises définies via SCIM apparaissent dans les mêmes vues TAG_REFERENCES et fonctionnent avec des filtres de balises Snowsight (voir Vue du coût par balise en Snowsight), de sorte que vos requêtes d’attribution des coûts et vos tableaux de bord existants fonctionnent sans modifications.
Pour commencer avec cette approche, vous devez :
Créer les balises dans Snowflake, comme décrit dans Création des balises ci-dessus.
Accorder au rôle de provisionnement SCIM le privilège USAGE sur le schéma de balises et le privilège APPLY sur chaque balise.
Pour les étapes de configuration complètes, les privilèges prérequis et des exemples d’API, voir « Renseigner les balises Snowflake avec des intégrations SCIM dans :
Vue QUERY_ATTRIBUTION_HISTORY: Fournit les coûts de calcul des requêtes. Le coût par requête correspond à l’utilisation du crédit d’entrepôt pour l’exécution de la requête.
Attribution des coûts entre les comptes d’une organisation
Au sein d’une organisation, vous pouvez également attribuer des coûts à des ressources utilisées exclusivement par un seul département en interrogeant les vues du schéma ORGANIZATION_USAGE à partir du compte de l’organisation.
Note
Dans le schéma ORGANIZATION_USAGE, la vue TAG_REFERENCES n’est disponible que dans le compte de l’organisation.
La vue QUERY_ATTRIBUTION_HISTORY n’est disponible que dans le schéma ACCOUNT_USAGE pour un compte. Il n’existe pas d’équivalent de cette vue à l’échelle de l’organisation.
Supposons que vous souhaitiez attribuer les coûts par département et que chaque département utilise un ensemble d’entrepôts dédiés.
Si vous balisez les entrepôts avec une balise cost_center pour identifier le département propriétaire de l’entrepôt, vous pouvez joindre ACCOUNT_USAGE Vue TAG_REFERENCES à Vue WAREHOUSE_METERING_HISTORY sur les colonnes object_id et warehouse_id pour obtenir des informations sur l’utilisation par entrepôt, et vous pouvez utiliser la colonne tag_value pour identifier les départements propriétaires de ces entrepôts.
L’instruction SQL suivante permet d’effectuer cette jonction :
Vous pouvez exécuter une requête similaire pour effectuer le même attribut pour tous les comptes de votre organisation en utilisant les vues du schéma ORGANIZATION_USAGE à partir du compte de l’organisation. Le reste de la requête ne change pas.
Ressources partagées par des utilisateurs de différents départements¶
Supposons que des utilisateurs de différents services partagent les mêmes entrepôts et que vous souhaitiez ventiler les crédits utilisés par chaque service. Vous pouvez étiqueter les utilisateurs avec une balise cost_center pour identifier le département auquel ils appartiennent, et vous pouvez joindre le Vue TAG_REFERENCES avec le Vue QUERY_ATTRIBUTION_HISTORY.
Note
Vous ne pouvez obtenir ces données que pour un seul compte à la fois. Vous ne pouvez pas exécuter une requête qui récupère ces données sur l’ensemble des comptes d’une organisation.
Les sections suivantes présentent des exemples d’instructions SQL pour l’attribution des coûts des ressources partagées.
Calcul du coût des requêtes des utilisateurs par département sans temps mort¶
L’exemple suivant attribue le coût de calcul à chaque département par le biais des requêtes exécutées par les utilisateurs de ce département. Cette requête dépend de l’existence d’une balise identifiant le département de l’objet de l’utilisateur.
Calcul du coût des requêtes effectuées par des utilisateurs sans balise¶
L’exemple suivant calcule le coût des requêtes effectuées par des utilisateurs qui ne sont pas balisés. Vous pouvez l’utiliser pour vérifier que les balises sont appliquées de manière cohérente aux utilisateurs.
Ressources utilisées par les applications qui doivent attribuer les coûts aux différents services¶
Les exemples de cette section calculent les coûts d’une ou plusieurs applications alimentées par Snowflake.
Les exemples supposent que ces applications établissent des paramètres de requête qui identifient l’application pour toutes les requêtes exécutées. Pour définir la balise de requête pour les requêtes d’une session, exécutez la commande ALTER SESSION. Par exemple :
ALTERSESSIONSETQUERY_TAG='COST_CENTER=finance';
La balise COST_CENTER=finance est ainsi associée à toutes les requêtes ultérieures exécutées au cours de la session.
Vous pouvez ensuite utiliser la balise de requête pour tracer le coût de ces requêtes vers les services concernés.
Les sections suivantes présentent des exemples d’utilisation de cette approche.
L’exemple suivant calcule les crédits de calcul et les crédits utilisés pour la Query Acceleration Service pour le service des finances. Cela dépend de la balise de requête COST_CENTER=finance appliquée aux requêtes originales qui ont été exécutées.
Notez que les coûts excluent le temps d’inactivité.
Calcul du coût des requêtes (y compris le temps d’inactivité) par balise de requête¶
L’exemple suivant répartit le temps d’inactivité qui n’est pas pris en compte dans le coût par requête entre les départements, proportionnellement à leur utilisation de l’entrepôt.
Vous pouvez attribuer des coûts en rendant compte de l’utilisation des ressources qui ont la balise cost_center. Vous pouvez accéder à ces données sur le site Snowsight.
Vous pouvez utiliser Vue QUERY_ATTRIBUTION_HISTORY pour attribuer des coûts en fonction des requêtes. Le coût par requête correspond à l’utilisation du crédit d’entrepôt pour l’exécution de la requête. Ce coût n’inclut pas toute autre utilisation de crédit résultant de l’exécution de la requête. Par exemple, les éléments suivants ne sont pas inclus dans le coût de la requête :
Coûts du transfert des données
Coûts de stockage
Coûts des services Cloud
Coûts des fonctionnalités sans serveur
Coûts des jetons traités par les services AI
Pour les requêtes exécutées simultanément, le coût de l’entrepôt est attribué aux requêtes individuelles en fonction de la moyenne pondérée de leur consommation de ressources au cours d’un intervalle de temps donné.
Le coût par requête n’inclut pas le temps d’inactivité de l’entrepôt. Le temps d’inactivité est une période pendant laquelle aucune requête ne s’exécute dans l’entrepôt et ne peut être mesurée au niveau de l’entrepôt.
Pour les procédures stockées qui émettent plusieurs requêtes hiérarchiques, vous pouvez calculer les coûts de requête attribués à la procédure en utilisant l’ID de requête racine pour la procédure.
Pour trouver l’ID de requête racine pour une procédure stockée, utilisez Vue ACCESS_HISTORY. Par exemple, pour trouver l’ID de requête racine pour une procédure stockée, définissez query_id et exécutez les instructions suivantes :