Kostenkontrolle für den Snowflake Connector for Google Analytics Raw Data¶
Der Snowflake Connector für Google Analytics Raw Data unterliegt den Nutzungsbedingungen für Konnektoren.
Unter diesem Thema werden Best Practices für die Kostenkontrolle und die Ermittlung der optimalen Warehouse-Größe für den Snowflake Connector for Google Analytics Raw Data erörtert.
Ermitteln der Kosten des Konnektors¶
Wenn der Konnektor ein separates Konto nur für die Datenerfassung und Datenspeicherung verwendet und das Konto keine anderen Aktivitäten aufweist (wie z. B. die Ausführung von Abfragen durch Benutzer auf den erfassten Daten), können Sie die Gesamtkosten auf der Ebene des Kontos ablesen. Weitere Informationen dazu finden Sie unter Untersuchen der Gesamtkosten.
Wenn das Konto nicht nur dem Konnektor gewidmet ist oder Sie die Kosten noch genauer untersuchen müssen, sollten Sie die berechneten Kosten für die Komponenten getrennt analysieren:
Eine Einführung in diese drei Kostenbestandteile finden Sie unter Erläuterungen zu den Gesamtkosten.
Allgemeine Empfehlungen¶
Um die durch den Konnektor verursachten Kosten zu ermitteln, können Sie ein separates Konto ausschließlich für den Konnektor anlegen. Wenn Sie ein bestimmtes Konto verwenden, können Sie den exakten Datentransfer verfolgen, der durch den Konnektor generiert wird.
Wenn Sie kein separates Konto für den Konnektor verwenden können, versuchen Sie Folgendes:
Erstellen Sie eine separate Datenbank für die Speicherung der aufgenommenen Daten, um die Speicherkosten besser verfolgen zu können.
Um die genauen Computekosten zu ermitteln, ordnen Sie ein Warehouse nur für den Konnektor zu.
Verwenden Sie Objekt-Tags auf Datenbanken und einem Warehouse, um kundenspezifische Kostenberichte zu erstellen.
Computekosten¶
Wir empfehlen Ihnen, ein dediziertes Warehouse nur für den Konnektor zu erstellen. Mit dieser Konfiguration haben Sie die Möglichkeit, Ressourcenmonitore auf dem Warehouse zu erstellen. Sie können die Monitore verwenden, um E-Mail-Alerts zu versenden und das Warehouse zu unterbrechen, d. h. den Konnektor zu stoppen, wenn das festgelegte Credit-Kontingent überschritten wird. Der Konnektor wird automatisch wieder aktiviert, wenn das Credit-Kontingent erneuert wird. Beachten Sie, dass eine zu niedrige Einstellung des Credit-Kontingents in Konfigurationen, in denen große Datenmengen aufgenommen werden, verhindern kann, dass der Konnektor alle Daten aufnimmt. Ein großer Vorteil ist, dass die Größe des Warehouses an das Datenvolumen angepasst werden kann.
Weitere Informationen zum Prüfen der vom Warehouse verbrauchten Credits finden Sie unter Untersuchen der Computekosten. Sie können dem Warehouse auch Objekt-Tags zuweisen und die Tags dann zum Erstellen von Kostenberichten verwenden.
Wenn das vom Konnektor verwendete Warehouse auch von anderen Workflows genutzt wird, können Sie die Kosten nach Rollen aufteilen. Um die Nutzung nach Rollen aufzuteilen, verwenden Sie die Abfrage für die Aufteilung der Warehouse-Nutzung und fügen die folgende WHERE
-Klausel zur QUERY_HISTORY-Ansicht hinzu:
WAREHOUSE_NAME = '<connector warehouse name>' AND
ROLE_NAME = '<role created for the connector to ingest data>'
Beachten Sie, dass die Rolle der Name ist, der bei der Installation des Konnektors erstellt wurde, zum Beispiel SNOWFLAKE_CONNECTOR_FOR_GOOGLE_ANALYTICS_RAW_DATA.
Die Abfrage liefert nur einen ungefähren Wert für die Kosten.
Speicherkosten¶
Der Snowflake Connector for Google Analytics Raw Data speichert Daten an zwei Stellen:
In der Konnektor-Datenbank, die aus der öffentlichen Freigabe erstellt wird und die den internen Status des Konnektors enthält.
In dem vom Benutzer angegebenen Schema, in dem die aufgenommenen Daten gespeichert werden.
Außerdem wird Datenspeicher vom Snowflake-Feature Fail-safe verbraucht. Die Menge der gespeicherten Fail-safe-Daten hängt von den Tabellenaktualisierungen ab, die der Konnektor ausführt.
Um die Speichernutzung in Snowsight zu überprüfen, können Sie eine separate Datenbank für die Speicherung der eingelesenen Daten verwenden. Damit können Sie die Diagramme zur Speichernutzung nach Objekt filtern, was die Nutzung durch einzelne Datenbanken anzeigt. Sie können auch die Speichernutzung anzeigen, indem Sie die Ansicht DATABASE_STORAGE_USAGE_HISTORY abfragen und nach beiden vom Konnektor verwendeten Datenbanken filtern.
Wenn die Datenbank andere Schemas enthält, die nicht mit dem Konnektor in Beziehung stehen, können Sie die Speichernutzung eines bestimmten Schemas abfragen, das für die vom Konnektor aufgenommenen Daten bestimmt ist. Sie können die Informationen aus der Ansicht TABLE_STORAGE_METRICS abrufen, sobald Sie nach Datenbank- und Schemanamen gefiltert und die Spalten mit Speichernutzung aggregiert haben.
Datentransferkosten¶
Snowflake erhebt nur Gebühren für den vom Konnektor generierten Datenverkehr, basierend auf der Größe der Anforderungen vom Konnektor an Google Analytics Raw Data. Die Antworten von Google Analytics Raw Data verursachen keine Kosten auf Seiten von Snowflake.
Informationen zur Datentransfernutzung sind nur in aggregierter Form für alle externen Funktionen auf der Ebene des Kontos verfügbar. Um auf die Anzahl der übertragenen Bytes zuzugreifen, verwenden Sie die Ansicht DATA_TRANSFER_HISTORY und filtern nach dem Transfertyp EXTERNAL_ACCESS.
Es können zusätzliche Gebühren für den Datentransfer auf der BigQuery-Seite anfallen: Datenspeicher + ausgehender Datenverkehr. Insbesondere verwendet der Konnektor so genannte Streaming Reads (Storage Read-API).
Weitere Informationen dazu finden Sie in der zugehörigen Dokumentation.
Kosten für Healthcheck-Aufgabe¶
Der Konnektor erstellt eine interne, serverlose Aufgabe, die regelmäßig den Zustand der Instanz überprüft und zu Überwachungszwecken eine Zusammenfassung an Snowflake sendet. Die Aufgabe wird erstellt, nachdem Sie den Installationsassistenten abgeschlossen oder CONFIGURE_CONNECTION
in einem Arbeitsblatt aufgerufen haben. Dies verursacht feste Computekosten von bis zu 0,5 Credits pro Tag, auch wenn keine Eigenschaften für die Datenaufnahme aktiviert sind.
Die Aufgabe kann nicht explizit angehalten oder gelöscht werden, allerdings wird durch das Anhalten des Konnektors auch der Healtcheck deaktiviert.
Bestimmen der optimalen Warehouse-Größe für die Konnektor-Instanz¶
Um die optimale Warehouse-Größe für den Konnektor zu finden, müssen Sie die Faktoren berücksichtigen, die sich auf die Leistung des Konnektors auswirken, wie:
Anzahl von Google Analytics-Eigenschaften
Menge der Daten, die von jeder der Eigenschaften erzeugt werden
Zeitplan für die Synchronisierung von Eigenschaften
Wir empfehlen Ihnen, eine Reihe von messbaren Anforderungen zu definieren, wie z. B. Zeitintervalle, in denen alle Tabellen synchronisiert werden sollten, und dann die kleinste Warehouse-Größe zu wählen, die diese Anforderungen erfüllt. Um festzustellen, ob Sie das Warehouse verkleinern können, lesen Sie Überwachen des Warehouse-Workloads.
Für den Snowflake Connector for Google Analytics Raw Data empfehlen wir, mit einem Warehouse der Größe XSMALL zu beginnen und dann mit einem größeren Warehouse zu experimentieren, um die Leistung zu optimieren.
Darüber hinaus können die Anforderungen an die Warehouse-Größe in den verschiedenen Phasen der Datenaufnahme sehr unterschiedlich sein. Beispiel:
Bei der erstmaligen Aufnahme von Daten, bei der der Konnektor historische Daten lädt, möglicherweise Daten aus mehreren Jahren, kann ein größeres Warehouse von Vorteil sein.
Für die normale tägliche Datenaufnahme, bei der nur aktuelle Tagesdaten geladen werden, reichen die kleinsten Warehouses aus.
Wenn ein großes Eigenschaftsset zur Datenaufnahme aktiviert ist, sollten Sie außerdem ein größeres Warehouse in Betracht ziehen, damit der Konnektor mit dem Datenfluss Schritt halten kann.