Hinweise zu Openflow-Skalierung und -Kosten¶
Bei Snowflake Openflow gibt es Kostenüberlegungen in mehreren Bereichen, darunter Infrastruktur, Computing, Datenaufnahme und weitere. Die Skalierung von Openflow setzt voraus, dass Sie diese Kosten verstehen. In den folgenden Abschnitten werden die Openflow-Kosten im Allgemeinen beschrieben und zahlreiche Beispiele für die Skalierung von Openflow-Laufzeitumgebungen und die damit verbundenen Kosten bereitgestellt.
Openflow-Kosten¶
Wenn Sie Openflow verwenden, können Ihnen die folgenden Arten von Kosten entstehen:
Kostenkategorie |
Beschreibung |
|---|---|
Openflow (wird auf Ihrer Snowflake-Rechnung als „Openflow Compute BYOC“ angezeigt) |
Kosten basierend auf der Anzahl der virtuellen CPU-Kerne (vCPU), die von Konnektor-Laufzeiten innerhalb Ihrer „Bring Your Own Cloud (BYOC)“-Umgebung verwendet werden. Ihnen werden nur aktive Laufzeiten in Rechnung gestellt. Das Computing, das für Openflow-Verwaltungsprozess verwendet wird, ist von dieser spezifischen Gebühr ausgeschlossen. Credits werden pro Sekunde abgerechnet, mit einem Minimum von 60 Sekunden. Beispiel für die Verwendung von VCPU und die Auswirkungen der Skalierung finden Sie unter Openflow-Skalierung. Weitere Informationen zur Rate pro vCPU pro Stunde finden Sie in Tabelle 1(g) in der Tabelle Snowflake Service Consumption Table. Zudem können die Ansichten METERING_DAILY_HISTORY und METERING_HISTORY im Schema Account Usage zusätzliche Details zu den Openflow-Computekosten unter Verwendung von Abfragen für Weitere Informationen zur Untersuchung der Computekosten in Snowflake finden Sie unter Untersuchen der Computekosten. |
Infrastruktur (nur für BYOC-Konfiguration) |
Nur bei BYOC-Bereitstellungen zahlen Sie direkt an Ihren Cloud-Anbieter, z. B. AWS, für die zugrunde liegende Infrastruktur, die in Ihrer Umgebung für die Ausführung von Openflow bereitgestellt wird. Dazu gehören in erster Linie die Rechenleistung (für die von Ihnen bereitgestellten Laufzeiten zur Ausführung der Konnektoren und für deren Verwaltung) sowie Netzwerk- und Speicherkosten. Sie sind auf Ihrer CSP-Rechnung enhalten. Die EC2-Rechenanforderungen sind in der folgenden Abbildung dargestellt: 
|
Datenaufnahme (Ingestion) |
Kosten für das Laden von Daten in Snowflake über Dienste wie Snowpipe oder Snowpipe Streaming, basierend auf dem Datenvolumen. Erscheint auf Ihrer Snowflake-Rechnung unter den jeweiligen Posten für Datenaufnahmedienste. Bestimmte Konnektoren erfordern möglicherweise ein Standard-Snowflake-Warehouse, was zusätzliche Warehouse-Kosten verursacht. Zum Beispiel benötigen CDC-Datenbankkonnektoren ein Snowflake-Warehouse sowohl für den ersten Snapshot als auch für die inkrementelle Erfassung von Änderungsdaten (Change Data Capture, CDC). Sie können MERGE-Operationen zur Verwaltung der Computekosten planen. |
Telemetriedatenaufnahme |
Standard-Snowflake-Gebühren für das Senden von Protokollen und Metriken an Openflow-Bereitstellungen und für das Senden von Laufzeiten an Ihre Ereignistabelle in Snowflake. Die Rate für Credits pro GB von Telemetriedaten finden Sie in Tabelle 5 in der Snowflake Service Consumption Table. |
Openflow-Skalierung¶
Die von Ihnen gewählten Laufzeiten und das Skalierungsverhalten sind entscheidend für ein effektives Kostenmanagement. Openflow unterstützt verschiedene Laufzeittypen, jeweils mit eigenen Skalierungsmerkmalen.
Laufzeittypen und die damit verbundenen Kosten¶
Die folgende Tabelle veranschaulicht das Skalierungsverhalten verschiedener Laufzeiten und die damit verbundenen Kosten:
Laufzeiten |
Tätigkeit |
Snowflake-Kosten |
Cloudkosten |
|---|---|---|---|
Keine Laufzeiten |
Keine |
Keine Kosten |
Computing und Speicherung von Dataplane |
1 Laufzeit des Typs Small (1vCPU) . (min. 1, max. 2) |
Aktiv für 1 Stunde . Laufzeit wird nicht auf 2 skaliert. |
1 Laufzeit x 1 Knoten x 1 vCPU x 1 Stunde = 1 . Gesamt = 1 vCPU-Stunde |
Computing und Speicherung von Dataplane |
2 Laufzeiten des Typs Small (1 vCPU) (min./max.=2) . 1 Laufzeit des Typs Large (8 vCPU) (min./max.=10) |
Small: 2 Knoten aktiv für 1 Stunde . Groß: 10 Knoten aktiv für 1 Stunde |
2 Laufzeit2 x 2 Knoten x 2 vCPU x 1 Stunde = 4 vCPU . 1 Laufzeit x 10 Knoten × 8 vCPU x 1 Stunde = 80 vCPU . Gesamt = 84 vCPU-Stunden |
Computing und Speicherung von Dataplane |
1 Medium (4vCPU) . (min. = 1 max. = 2) |
Für die ersten 20 Minuten wird 1 Knoten ausgeführt . Nach 20 Minuten wird auf 2 Knoten skaliert . Nach 40 Minuten wird auf 1 Knoten zurückskaliert . Gesamt 1 Stunde . |
20 Minuten = 1/3 Stunde . 1 Laufzeit x 1 Knoten x 4 vCPU x 1/3 Stunde = 1 1/3 . 1 Laufzeit × 2 Knoten x 4 vCPU x 2/3 Stunde = 2 1/3 . 1 Laufzeit x 1 Knoten × 4 vCPU x 1/3 Stunde = 1 1/3 . Gesamt = 5 1/2 vCPU-Stunden |
Computing und Speicherung von Dataplane |
1 Medium (4vCPU) . (min./max.=2) |
Für die ersten 30 Minuten werden 2 Knoten ausgeführt . Wird nach den ersten 30 Minuten angehalten. |
30 Minuten = 1/2 Stunde . 1 Laufzeit x 2 Knoten x 4 vCPU x 1/2 Stunde = 4 . Gesamt = 4 vCPU-Stunden |
Computing und Speicherung von Dataplane |
Zuordnen von Laufzeiten zu EC2-Instanztypen¶
Die Wahl eines Laufzeittyps (T-Shirt-Größe) führt dazu, dass die Laufzeit- Pods auf der zugehörigen EC2-Knotengruppe {key}-sm-group, {key}-md-group oder {key}-lg-group mit Ressourcen geplant werden, die in der folgenden Tabelle beschrieben sind:
Laufzeittyp |
vCPUs |
Verfügbarer Speicher (GB) |
EC2-Instanztyp |
EC2-Knotengruppe |
EC2-Knoten – CPUs |
EC2-Knoten – Speicher (GB) |
|---|---|---|---|---|---|---|
Small |
1 |
2 |
m7i.xlarge |
{key}-sm-group |
4 |
16 |
Medium |
4 |
10 |
m7i.4xlarge |
{key}-md-group |
16 |
64 |
Large |
8 |
20 |
m7i.8xlarge |
{key}-lg-group |
32 |
128 |
Der Typ der Laufzeit, den Sie wählen, wirkt sich auf die Anzahl der verbrauchten Kerne (vCPUs) pro Sekunde aus. Openflow skaliert die zugrunde liegende EC2 Knotengruppe, wenn zusätzliche Pods geplant werden müssen, basierend auf demCPU-Verbrauch und bis zu der maximalen Knoteneinstellung, die bei der Erstellung zur Laufzeit festgelegt wurde.
EKS-Knotengruppen werden mit einer Mindestgröße von 0 Knoten und einem Maximum von 50 Knoten konfiguriert. Die gewünschte Größe wird dynamisch abhängig von der für die Laufzeit erforderlichen CPU und dem Arbeitsspeicher angepasst.
Kunden erhalten ihre Rechnungen für die zugrunde liegenden Knoten, die ihre Laufzeiten hosten, von ihren Clouddienstanbietern. Die zugrunde liegenden EC2-Instanzen werden erstellt, wenn die erste Laufzeit einer entsprechenden Größe geplant wird.
Beispiele für die Berechnung des Openflow-Laufzeitverbrauchs¶
Ein Benutzer fordert eine BYOC-Bereitstellung von Openflow an und installiert dann den Openflow-Agenten und die Bereitstellung
Der Benutzer hat keine Laufzeiten erstellt. 0 vCPUs werden zugewiesen, sodass keine Kosten für Openflow-Software anfallen.
Dem Benutzer werden von seinem Clouddienstanbieter die Kosten für das Computing und den Speicher der Openflow BYOC-Bereitstellung in Rechnung gestellt.
Gesamter Openflow-Verbrauch = 0 vCPU-Stunden
Ein Benutzer erstellt eine Laufzeitumgebung des Typs Small mit min. Knoten = 1 und max. Knoten = 2. Die Laufzeit verbleibt bei 1 Knoten für 1 Stunde.
1 Laufzeit des Typs Small = 1 vCPU
Gesamter Openflow-Verbrauch = 1 vCPU-Stunde
Ein Benutzer erstellt 2 Laufzeiten des Typs Small mit min./max. von jeweils 2 Knoten und eine Laufzeit des Typs Large mit min./max. von 10 Knoten. Diese Laufzeiten sind für 1 Stunde aktiv
2 Laufzeiten des Typs Small bei 2 Knoten = 2 Laufzeiten x 2 Knoten x 1 vCPU = 4 vCPUs
1 Laufzeit des Typs Large bei 10 Knoten = 1 Laufzeit x 10 Knoten x 8 vCPU = 80 vCPUs
Gesamter Openflow-Verbrauch = (4 vCPU + 80 vCPU) x 1 Stunde = 84 vCPU-Stunden
Ein Benutzer erstellt 1 Laufzeit des Typs Medium mit 1 Knoten. Nach 20 Minuten wird sie auf 2 Knoten skaliert. Nach 20 Minuten wird sie wieder auf 1 Knoten herunterskaliert und für weitere 20 Minuten ausgeführt.
1 Laufzeit des Typs Medium = 4 vCPUs
20 Minuten = ⅓ Stunde
(1 Knoten × 4 vCPU x ⅓ Stunde) + (2 Knoten x 4 vCPU x ⅓ Stunde) + (1 Knoten x 4 vCPU x ⅓ Stunde)
4/3 vCPU-Stunden + 8/3 vCPU-Stunden + 4/3 vCPU-Stunden
Gesamter Openflow-Verbrauch = 16/3 vCPU-Stunden, also ungefähr 5,33 vCPU-Stunden
Ein Benutzer erstellt 1 Laufzeit des Typs Medium mit 2 Knoten und hält sie dann nach 30 Minuten an
1 Laufzeit des Typs Medium = 4 vCPU
30 Minuten = ½ Stunde
Gesamter Openflow-Verbrauch = (2 Knoten x 4 vCPU x ½ Stunde) = 4 vCPU-Stunden