Kostenkontrolle des Snowflake-Konnektors für ServiceNow¶

Dieses Thema enthält Best Practices für die Kostenkontrolle und die Ermittlung der optimalen Warehouse-Größe für den Snowflake-Konnektor für ServiceNow.

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 folgenden drei Komponenten getrennt analysieren:

Computekosten
Speicherkosten
Datentransferkosten

Eine Einführung in diese drei Kostenbestandteile finden Sie unter Erläuterungen zu den Gesamtkosten.

Allgemeine Empfehlungen¶

Um die durch den Konnektor erzeugten Kosten zu erhalten, empfehlen wir Ihnen, ein separates Konto ausschließlich für die Verwendung des Konnektors einzurichten. Auf diese Weise können Sie den genauen 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 erfassten Daten, um die Speicherkosten besser verfolgen zu können.
Weisen Sie ein Warehouse nur für den Konnektor zu, um die genauen Computekosten zu erhalten.
Verwenden Sie Objekt-Tags auf Datenbanken und einem Warehouse, um kundenspezifische Kostenberichte zu erstellen.
Wenn Sie eine serverlose Konfiguration verwenden, können Sie die Ansicht SERVERLESS_TASK_HISTORY abfragen, nach dem Namen des Konnektors filtern und die Spalte CREDITS_USED überprüfen, um die Kosten zu erhalten.

Computekosten¶

Wir empfehlen Ihnen, ein separates Warehouse nur für den Konnektor zu erstellen. Mit diesem Setup 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 beim einem zu niedrig eingestellten Credit-Kontingent in Konfigurationen, in denen große Datenmengen erfasst werden, dazu führen kann, dass der Konnektor nicht alle Daten erfasst.

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 IN ('APP_PRIMARY', ‘<role created for the connector to ingest data>’)

Copy

Die Abfrage liefert nur einen ungefähren Wert für die Kosten.

Bemerkung

Das Warehouse darf nur von genau einer systemeigenen Anwendung verwendet werden, andernfalls sind die Kosten verschiedener Anwendungen nicht trennbar, da jede systemeigene Anwendung denselben Rollennamen verwendet (APP_PRIMARY).

Bei Konnektoren, die für die Verwendung von serverlosen Aufgaben konfiguriert sind, können Sie die Ansicht SERVERLESS_TASK_HISTORY abfragen. Die Ansicht enthält die Spalten CREDITS_USED und DATABASE_NAME, wobei Sie letztere zum Filtern nach dem Namen des Konnektors verwenden können.

Speicherkosten¶

Der Snowflake-Konnektor für ServiceNow 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 erfassten 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 vornimmt. Die Datenmenge erhöht sich, wenn die von ServiceNow erfassten Tabellenzeilen häufig aktualisiert werden oder die gesamte Tabelle neu geladen wird. In der Regel stabilisiert sich die Menge der Fail-safe-Daten sieben bis zehn Tage nach der Einrichtung des Konnektors (unter der Annahme, dass keine Reloads durchgeführt werden und der Strom an erfassten Daten konstant ist).

Wenn Sie die Speichernutzung in Snowsight überprüfen möchten, empfehlen wir Ihnen, eine separate Datenbank zum Speichern der erfassten Daten zu verwenden. Auf diese Weise können Sie die Grafiken für die Speichernutzung nach Objekt filtern, sodass die Nutzung nach einzelnen Datenbanken angezeigt wird. Sie können dies auch tun, 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 erfassten 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¶

Der Konnektor verwendet externe Funktionen, um Daten von ServiceNow abzurufen. Snowflake erhebt nur Gebühren für den vom Konnektor generierten Datenverkehr, basierend auf der Größe der Anforderungen vom Konnektor an ServiceNow. Die Antworten von ServiceNow 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_FUNCTION.

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, z. B. die Größe der ServiceNow-Instanz, die Anzahl der aktivierten Tabellen und der Zeitplan für das Synchronisieren der einzelnen Tabellen. Wenn zum Beispiel nur einige wenige Tabellen aktiviert sind, profitiert der Konnektor möglicherweise nicht von einer erhöhten Parallelisierung.

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. Für große Datenmengen mit Dutzenden von synchronisierten Tabellen wird standardmäßig ein Warehouse der Größe „Large“ empfohlen. Wenn Sie hingegen nur den Konnektor ausprobieren und eine einzelne Tabelle für die Erfassung aktivieren möchten, sollte ein Warehouse der Größe „X-Small“ ausreichen. Um herauszufinden, ob Sie das Warehouse verkleinern können, lesen Sie Überwachen der Warehouse-Last.

Automatisches Starten und Stoppen des Konnektors innerhalb eines bestimmten Zeitrahmens¶

Um Kosten zu sparen, können Sie den Konnektor nur während eines bestimmten Zeitraums (z. B. außerhalb der Geschäftszeiten) ausführen. Rufen Sie dazu die Prozeduren STOP_CONNECTOR und RESUME_CONNECTOR auf.

Sie können das Starten und Beenden des Konnektors mithilfe von serverlosen Aufgaben automatisieren. Um den Konnektor außerhalb der UTC-Geschäftszeiten auszuführen, könnten Sie zum Beispiel die folgende Abfrage verwenden:

CREATE TASK start_connector_after_business_hours
   SCHEDULE USING CRON 0 17 * * MON-FRI Europe/London
   AS CALL <my_connector_servicenow>.PUBLIC.RESUME_CONNECTOR();

CREATE TASK stop_connector_before_business_hours
   SCHEDULE USING CRON 0 9 * * MON-FRI Europe/London
   AS CALL <my_connector_servicenow>.PUBLIC.STOP_CONNECTOR();

Copy