Eine Organisation kann die Kosten für die Nutzung von Snowflake auf logische Einheiten innerhalb der Organisation umlegen (zum Beispiel auf verschiedene Abteilungen, Umgebungen oder Projekte). Dieses Chargeback- oder Showback-Modell ist für Buchhaltungszwecke nützlich und zeigt Bereiche der Organisation auf, die von Kontrollen und Optimierungen profitieren könnten, um die Kosten zu senken.
Um Kosten verschiedenen Gruppen wie Abteilungen oder Projekten zuzuordnen, verwenden Sie die folgende empfohlene Vorgehensweise:
Verwenden Sie Objekt-Tags, um Ressourcen und Benutzer mit Abteilungen oder Projekten zu verknüpfen.
Verwenden Sie Abfrage-Tags, um einzelne Abfragen mit Abteilungen oder Projekten zu verknüpfen, wenn die Abfragen von derselben Anwendung im Namen von Benutzern durchgeführt werden, die zu mehreren Abteilungen gehören.
Die folgenden Kostenzuordnungsszenarien sind die am häufigsten anzutreffenden. In diesen Szenarien werden Warehouses als Beispiel für eine Ressource verwendet, die Kosten verursacht.
Ressourcen, die ausschließlich von einer einzigen Kostenstelle oder Abteilung verwendet werden: Ein Beispiel hierfür ist die Verwendung von Objekt-Tags, um Warehouses mit einer Abteilung zu verknüpfen. Sie können diese Objekt-Tags verwenden, um die Kosten, die für diese Warehouses anfallen, ausschließlich dieser Abteilung zuzuordnen.
Ressourcen, die von Benutzern aus mehreren Abteilungen gemeinsam genutzt werden: Ein Beispiel hierfür ist ein Warehouse, das von Benutzern aus verschiedenen Abteilungen gemeinsam genutzt wird. In diesem Fall verwenden Sie Objekt-Tags, um jeden Benutzer mit einer Abteilung zu verknüpfen. Die Kosten für Abfragen werden den Benutzern zugeordnet. Anhand der Objekt-Tags, die den Benutzern zugeordnet sind, können Sie die Kosten nach Abteilungen aufschlüsseln.
Anwendungen oder Arbeitsabläufe, die von Benutzern aus verschiedenen Abteilungen gemeinsam genutzt werden: Ein Beispiel hierfür ist eine Anwendung, die Abfragen im Namen ihrer Benutzer ausführt. In diesem Fall wird jeder Abfrage, die von der Anwendung ausgeführt wird, ein Abfrage-Tag zugewiesen, das das Team oder die Kostenstelle des Benutzers identifiziert, in dessen Namen die Abfrage durchgeführt wird.
In den nächsten Abschnitten erfahren Sie, wie Sie Objekt-Tags in Ihren Konten einrichten und welche Details Sie für jedes dieser Kostenzuordnungsszenarien benötigen.
Wenn Sie Tags für die Gruppierungen einrichten, die Sie für die Kostenzuordnung verwenden möchten, sollten Sie festlegen, ob die Gruppierungen für ein einzelnes Konto oder für mehrere Konten gelten. Dies bestimmt, wie Sie Ihre Tags einrichten.
Nehmen wir zum Beispiel an, dass Sie Kosten auf Grundlage der Abteilung zuordnen möchten.
Wenn sich die von der Abteilung verwendeten Ressourcen in einem einzigen Konto befinden, erstellen Sie die Tags in einer Datenbank in diesem Konto.
Wenn sich die von der Abteilung genutzten Ressourcen über mehrere Konten erstrecken, erstellen Sie die Tags in einem wichtigen Konto in Ihrer Organisation (z. B. in Ihrem Organisationskonto) und machen Sie diese Tags in anderen Konten durch Replikation verfügbar.
In den nächsten Abschnitten wird erklärt, wie Sie die Tags erstellen, die Tags replizieren und die Tags auf Ressourcen anwenden.
Die Beispiele in diesen Abschnitten verwenden die kundenspezifische Rolle tag_admin, bei der davon ausgegangen wird, dass sie über die Berechtigungen zum Erstellen und Verwalten von Tags verfügt. Innerhalb Ihrer Organisation können Sie granularere Berechtigungen für das Taggen von Objekten verwenden, um eine sichere Tagging-Strategie zu entwickeln.
Entscheiden Sie sich bei der Entwicklung der Strategie für die Datenbank und das Schema, in dem Sie die Tags erstellen möchten.
Sie können eine eigene Datenbank und ein eigenes Schema für die Tags erstellen.
Wenn Sie Ressourcen in verschiedenen Konten in Ihrem Unternehmen mit Tags versehen möchten, können Sie die Tags in einem Schlüsselkonto in Ihrem Unternehmen erstellen (z. B. in Ihrem Organisationskonto).
Das folgende Beispiel erstellt eine Datenbank namens cost_management und ein Schema namens tags für die Tags, die Sie verwenden möchten:
Wenn Sie cost_management und tags als aktuelle Datenbank und aktuelles Schema ausgewählt haben, erstellen Sie ein Tag mit dem Namen cost_center und setzen die für das Tag zulässigen Werte auf die Namen der Kostenstellen:
Um beispielsweise die Tags auf die Konten mit den Namen my_org.my_account und my_org.my_account_2 zu replizieren, führen Sie diese Anweisung in Ihrem Organisationskonto aus:
Erstellen Sie dann in jedem Konto, in dem Sie die Tags verfügbar machen möchten, eine sekundäre Replikationsgruppe und aktualisieren Sie diese Gruppe von der primären Gruppe aus:
Nachdem Sie die Bezeichner erstellt und repliziert haben, können Sie diese Bezeichner verwenden, um die Warehouses und Benutzer zu identifizieren, die zu den einzelnen Abteilungen gehören. Da die Verkaufsabteilung zum Beispiel sowohl warehouse1 als auch warehouse2 verwendet, können Sie das Tag cost_center für beide Warehouses auf 'SALES' setzen.
Tipp
Idealerweise sollten Sie über Arbeitsabläufe verfügen, die die Anwendung dieser Tags bei der Erstellung von Ressourcen und Benutzern automatisieren.
If you want to automate the process of tagging users for cost attribution, you can do so by provisioning
Snowflake users through a SCIM identity provider such as Microsoft Entra ID or
Okta. With SCIM, you can automatically apply cost attribution tags to users when
they’re created or updated, eliminating the need to run ALTERUSER<user_name>SETTAG manually for each new
user and keeping your cost attribution tags consistent as users join or move between departments.
When using SCIM, the snowflakeTags custom attribute accepts a comma-separated list of fully qualified tag
references. For example, to assign a user to the finance cost center at provisioning time, include the
following value in the SCIM user payload:
Tags set through SCIM appear in the same TAG_REFERENCES views
and work with Snowsight tag filters (see Kosten nach Tag anzeigen in Snowsight), so your existing
cost attribution queries and dashboards work without changes.
To get started with this approach, you need to:
Create the tags in Snowflake, as described in Creating the tags above.
Grant the SCIM provisioner role USAGE on the tag schema and APPLY on each tag.
For the complete setup steps, prerequisite grants, and API examples, see the „Populating Snowflake tags with SCIM
integrations“ section in:
Ansicht QUERY_ATTRIBUTION_HISTORY: Liefert die Computekosten für Abfragen. Die Kosten entsprechen der Credit-Nutzung des Warehouse für die Ausführung der Abfrage.
Zuordnung von Kosten über Konten in einer Organisation
Innerhalb einer Organisation können Sie auch Kosten für Ressourcen zuordnen, die ausschließlich von einer einzelnen Abteilung verwendet werden, indem Sie Ansichten im Schema ORGANIZATION_USAGE aus dem Organisationskonto abfragen.
Bemerkung
Im Schema ORGANIZATION_USAGE ist die Ansicht TAG_REFERENCES nur im Konto der Organisation verfügbar.
Die Ansicht QUERY_ATTRIBUTION_HISTORY ist nur im Schema ACCOUNT_USAGE für ein Konto verfügbar. Es gibt kein organisationsweites Äquivalent für diese Ansicht.
Ressourcen, die nicht von Abteilungen geteilt werden¶
Angenommen, Sie möchten die Kosten nach Abteilungen zuordnen und jede Abteilung nutzt eine Reihe von speziellen Warehouses.
Wenn Sie Warehouses mit einem cost_center-Tag versehen, um die Abteilung zu identifizieren, der das Warehouse gehört, können Sie ACCOUNT_USAGE Ansicht TAG_REFERENCES mit Ansicht WAREHOUSE_METERING_HISTORY in den Spalten object_id und warehouse_id verbinden, um Nutzungsinformationen nach Warehouse zu erhalten, und Sie können die Spalte tag_value verwenden, um die Abteilungen zu identifizieren, denen diese Warehouses gehören.
Die folgende SQL-Anweisung führt diese Verknüpfung durch:
Sie können eine ähnliche Abfrage durchführen, um dieselbe Zuordnung für alle Konten in Ihrer Organization vorzunehmen, indem Sie die Ansichten im Schema ORGANIZATION_USAGE aus dem Organisationskonto verwenden. Der Rest der Abfrage ändert sich nicht.
Von Benutzern aus verschiedenen Abteilungen gemeinsam genutzte Ressourcen¶
Nehmen wir an, dass Benutzer in verschiedenen Abteilungen dieselben Warehouses nutzen und Sie die von den einzelnen Abteilungen genutzten Credits aufschlüsseln möchten. Sie können die Benutzer mit einem cost_center-Tag versehen, um die Abteilung zu identifizieren, zu der sie gehören, und Sie können Ansicht TAG_REFERENCES mit Ansicht QUERY_ATTRIBUTION_HISTORY verbinden.
Bemerkung
Sie können diese Daten immer nur für ein einzelnes Konto abrufen. Sie können keine Abfrage ausführen, die diese Daten über Konten in einer Organisation abruft.
In den nächsten Abschnitten finden Sie Beispiele von SQL-Anweisungen für die Zuordnung von Kosten für gemeinsam genutzte Ressourcen.
Berechnung der Kosten von Benutzerabfragen nach Abteilung ohne Leerlaufzeit¶
Das folgende Beispiel ordnet die Rechenkosten jeder Abteilung über die Abfragen zu, die von den Benutzern in dieser Abteilung ausgeführt werden. Diese Abfrage setzt voraus, dass die Benutzerobjekte ein Tag haben, das ihre Abteilung identifiziert.
Berechnung der Kosten für Abfragen von Benutzern ohne Tags¶
Das folgende Beispiel berechnet die Kosten für Abfragen von Benutzern, die nicht getaggt sind. Damit können Sie überprüfen, ob die Tags konsistent auf die Benutzer angewendet werden.
Ressourcen, die von Anwendungen verwendet werden, die die Kosten verschiedenen Abteilungen zuordnen müssen¶
Die Beispiele in diesem Abschnitt berechnen die Kosten für eine oder mehrere Anwendungen, die von Snowflake betrieben werden.
Die Beispiele gehen davon aus, dass diese Anwendungen Abfrage-Tags setzen, die die Anwendung für alle ausgeführten Abfragen identifizieren. Um das Abfrage-Tag für Abfragen in einer Sitzung festzulegen, führen Sie den Befehl ALTER SESSION aus. Beispiel:
ALTERSESSIONSETQUERY_TAG='COST_CENTER=finance';
Dadurch wird das Tag COST_CENTER=finance mit allen nachfolgenden Abfragen verknüpft, die während der Sitzung ausgeführt werden.
Sie können dann das Abfrage-Tag verwenden, um die durch diese Abfragen entstandenen Kosten auf die entsprechenden Abteilungen zurückzuführen.
In den nächsten Abschnitten finden Sie Beispiele für die Anwendung dieses Ansatzes.
Berechnung der Kosten für Abfragen nach Abteilung¶
Das folgende Beispiel berechnet die Compute-Credits und die Credits, die für den Abfrage-Beschleunigungsdienst für die Finanzabteilung verwendet werden. Dies hängt davon ab, dass das Abfrage-Tag COST_CENTER=finance auf die ursprünglich ausgeführten Abfragen angewendet wird.
Beachten Sie, dass die Kosten die Leerlaufzeit ausschließen.
Berechnung der Kosten von Abfragen (einschließlich Leerlaufzeit) nach Abfrage-Tag¶
Im folgenden Beispiel wird die Leerlaufzeit, die nicht in den Kosten pro Abfrage enthalten ist, auf die Abteilungen im Verhältnis zu ihrer Nutzung des Warehouse verteilt.
Sie können Kosten zuordnen, indem Sie Berichte über die Verwendung von Ressourcen erstellen, die das cost_center-Tag aufweisen. Sie können unter Snowsight auf diese Daten zugreifen.
Wählen Sie im Navigationsmenü die Option Admin»Cost management aus.
Wählen Sie Consumption aus.
Wählen Sie in der Dropdown-Liste Tags das Tag cost_center aus.
Um sich auf eine bestimmte Kostenstelle zu fokussieren, wählen Sie einen Wert aus der Liste der Werte des Tags aus.
Wählen Sie Apply aus.
Weitere Informationen zum Filtern in Snowsight finden Sie unter Nach Tag filtern.
Allgemeine Informationen zur Ansicht QUERY_ATTRIBUTION_HISTORY¶
Sie können die Ansicht QUERY_ATTRIBUTION_HISTORY verwenden, um die Kosten auf der Grundlage von Abfragen zu zuzuordnen. Die Kosten entsprechen der Credit-Nutzung des Warehouse für die Ausführung der Abfrage. Diese Kosten beinhalten keine andere Credit-Nutzung, die durch die Ausführung der Abfrage entsteht. Zum Beispiel sind die folgenden Kosten nicht in den Abfragekosten enthalten:
Datentransferkosten
Speicherkosten
Kosten für Clouddienst
Kosten für serverlose Features
Kosten für Token, die von AI-Diensten verarbeitet werden
Bei Abfragen, die gleichzeitig ausgeführt werden, werden die Kosten des Warehouse den einzelnen Abfragen auf der Grundlage des gewichteten Durchschnitts ihres Ressourcenverbrauchs während eines bestimmten Zeitintervalls zugewiesen.
Die Kosten pro Abfrage beinhalten nicht die Leerlaufzeit des Warehouses. Die Leerlaufzeit ist ein Zeitraum, in dem keine Abfragen im Warehouse laufen und kann auf Warehouse-Ebene gemessen werden.
Bei gespeicherten Prozeduren, die mehrere hierarchische Abfragen durchführen, können Sie die zugewiesenen Abfragekosten der Prozedur berechnen, indem Sie die Stammabfrage ID für die Prozedur verwenden.
Um die Stammabfrage-ID für eine gespeicherte Prozedur zu finden, verwenden Sie die Ansicht ACCESS_HISTORY. Um zum Beispiel die Stammabfrage-ID für eine gespeicherte Prozedur zu finden, stellen Sie query_id ein und führen Sie die folgenden Anweisungen aus: