Understanding costs for dynamic tables¶
Dieses Thema bietet eine Übersicht zu den mit dynamischen Tabellen verbundenen Compute- und Speicherkosten. Allgemeine Informationen zu Snowflake-Kosten finden Sie unter Erläuterungen zu den Gesamtkosten.
Compute costs¶
dynamische Tabellen verursachen zwei Arten von Computekosten: Computing virtueller Warehouses und Computing von Clouddiensten.
Dynamische Tabellen benötigen mindestens ein virtuelles Warehouse, um Aktualisierungen auszuführen. Sie können optional ein zweites Warehouse zuweisen, wenn Sie die Computekosten für verschiedene Operationen voneinander trennen möchten. Weitere Informationen dazu finden Sie unter Erläuterungen zur Nutzung von Warehouses für dynamische Tabellen.
Dynamic table refreshes consume compute credits, and their frequency is determined by the configured target lag: lower target lag values trigger more frequent refreshes and therefore higher compute costs.
Dynamic tables also require Cloud Services compute to identify changes in underlying base objects and determine whether a virtual warehouse must run. If Cloud Services compute finds no changes, no warehouse compute credits are consumed because there’s no new data to refresh. If changes do exist, even if the dynamic table query filters them, the virtual warehouse consumes credits because the dynamic table refreshes to evaluate whether those changes apply.
Wenn die zugehörigen virtuellen Warehouses angehalten werden und das Clouddienst-Computing keine Änderungen in den Basistabellen feststellt, bleiben die Warehouses angehalten und die dynamischen Tabellen verbrauchen keine Credits. Wenn das Clouddienst-Computing Änderungen in den Basistabellen feststellt, wird das entsprechende Warehouse automatisch fortgesetzt. Wenn die Änderungen eine inkrementelle Aktualisierung unterstützen, wird die dynamische Tabelle unter Verwendung des Parameters WAREHOUSE aktualisiert. Wenn eine Neuinitialisierung erforderlich ist – z. B. aufgrund einer Änderung des Schemas einer Basistabelle – verwendet die dynamische TabelleINITIALIZATION_WAREHOUSE, um eine vollständige Neuinitialisierung auszuführen. Informationen darüber, wie dynamische Tabellen automatisch angehalten werden, finden Sie unter Automatisches Anhalten dynamischer Tabellen.
Überprüfen des Verbrauchs von Credits für virtuelle Warehouses¶
Um zu überprüfen, ob die Aktualisierungen Ihrer dynamischen Tabelle virtuelle Warehouse-Credits verbraucht haben, verwenden Sie die Registerkarte Refresh History in Snowsight:
Wählen Sie im Navigationsmenü die Option Transformation » Dynamic tables aus.
Wählen Sie Ihre dynamische Tabelle aus, und wählen Sie dann die Registerkarte Refresh History aus.
Um Aktualisierungen anzuzeigen, die das Warehouse zur Aktualisierung verwendet haben, aktivieren Sie das Kontrollkästchen Warehouse used only.
Tipp
To better understand costs related to your dynamic table pipelines, Snowflake recommends that you test dynamic tables by using dedicated warehouses. This way, you can isolate the virtual warehouse consumption that is attributed to dynamic tables. You can move your dynamic tables to a shared warehouse after you establish a cost baseline.
Weitere Informationen dazu finden Sie unter Erläuterungen zur Nutzung von Warehouses für dynamische Tabellen.
Computekosten für Unveränderlichkeitseinschränkungen¶
If you use the IMMUTABLE WHERE constraint, Snowflake recomputes only the rows that don’t match the immutability condition, which helps reduce reinitialization costs. This is useful in situations where reinitialization can occur, such as the following scenarios:
Neuerstellen von vorgelagerten Tabellen oder Ansichten.
Änderungen an vorgelagerten Data Governance-Richtlinien.
Failover in eine Sekundärregion in einer Failover-Gruppe.
Using the IMMUTABLE WHERE constraint can help you reduce the cost of incremental and full refresh because the constraint ignores changes and data that match its predicate.
Adding immutability constraints to a dynamic table doesn’t trigger extra computation, but removing them does because it causes reinitialization on the next refresh. Modifying the predicate in an IMMUTABLE WHERE constraint might trigger reinitialization depending on whether Snowflake can determine the rows that are returned with the original condition are still returned with the new condition.
Die folgenden Änderungen lösen zum Beispiel keine Neuinitialisierung aus:
Von
(ts < CURRENT_TIMESTAMP() – INTERVAL '2 Tage')zu(ts < CURRENT_TIMESTAMP() – INTERVAL '1 Tag')Von
(Jahr <= 2023)zu(Jahr <= 2024)
Die folgenden Änderungen lösen eine Neuinitialisierung aus:
Von
(ts < '2025-01-02')zu(ts < '2025-01-01')Von
(Jahr < 2024)zu(Monat < 10)
Speicherkosten¶
Dynamic tables require storage to store the materialized results. Similar to regular tables, you might incur additional storage cost for Time Travel, fail-safe storage, and cloning features.
Dynamic Apache Iceberg™ tables don’t incur Snowflake storage costs. For more information, see Rechnungsstellung.
In diesem Abschnitt werden die folgenden Speicheraspekte von dynamischen Tabellen behandelt:
Ausführliche Informationen darüber, wie diese Speicherung Kosten verursacht, finden Sie unter Erläuterungen zu den Speicherkosten und Hinweise zur Datenspeicherung.
Speicher für Time Travel und Fail-safe¶
With Snowflake Time Travel, you can access and query historical versions of dynamic tables at specific points in time, which can help provide insights into historical trends, changes, and anomalies in your data.
Durch häufige Aktualisierungen können sich mehr Time Travel-Daten ansammeln, was den Speicherverbrauch erhöht. Weitere Informationen dazu finden Sie unter Verstehen und Verwenden von Time Travel.
Fail-safe-Features schützen Ihre dynamischen Tabellen vor Datenverlust oder -beschädigung. Abhängig von der konfigurierten Fail-safe-Frist können zusätzliche Speichergebühren anfallen.
Replikation von dynamischen Tabellen¶
Dynamic tables support cross-account, cross-region replication, which lets you copy data from a primary database to a secondary database for either disaster recovery or data sharing. It can serve as either a failover preparation strategy for disaster recovery or as a means of sharing data across deployments for read-only purposes. Using replication with dynamic tables is subject to replication costs. For more information, see Replikation und dynamische Tabellen.
Angehaltene dynamische Tabellen¶
Suspended dynamic tables don’t incur additional costs beyond standard storage fees and don’t consume compute resources. If you have ongoing maintenance tasks or scheduled jobs that interact with the suspended table, your dynamic tables might consume compute resources.
Transiente dynamische Tabellen¶
Snowflake supports transient dynamic tables, similar to regular tables, that persist until explicitly dropped, and are available to all users with the appropriate privileges without a fail-safe period. Transient dynamic tables are best used for transitory data that doesn’t need the same level of data protection and recovery that permanent tables provide. Using them helps you save on storage charges for fail-safe storage.
Zusätzlicher Speicher für inkrementelle Aktualisierungsoperationen¶
For incremental refresh operations, dynamic tables maintain an additional internal metadata column for identifying each row within the table. Internal row identifiers consume a constant amount of storage per row and increase storage cost linearly to the number of rows in the table, independent of the number of columns.
Bei Tabellen mit sehr wenigen Spalten kann die Zunahme des Speicherplatzes im Vergleich zu einer entsprechenden CTAS-Tabelle signifikant oder sogar dominant sein. Bei breiteren dynamischen Tabellen ist dieser Effekt weniger stark ausgeprägt.
Kosten für Aktualisierungszeitplan¶
The schedule at which a dynamic table refreshes, whether full or incremental, has an effect on its overall cost. This section discusses the factors that you should consider when you decide on a refresh schedule, with the assumption that every refresh is non-empty:
Bemerkung
Aktualisierungen sind relativ kostengünstig, wenn sich die Quellen nicht geändert haben. Weitere Informationen dazu finden Sie unter Compute costs (unter diesem Thema).
Zeitplan für vollständige Aktualisierung¶
The cost of a full refresh typically depends on how much data your dynamic table scans and how often it refreshes. To save on costs, you can refresh your dynamic tables only when you need to; for example, you can suspend your dynamic tables outside of business hours. For precise timing control, set the downstream target lag for your dynamic tables and use manual refresh from a task to automate your custom schedules.
Inkrementeller Aktualisierungszeitplan¶
The cost of an incremental refresh is typically proportional to the volume of changes in the source objects, plus some fixed overhead.
If the overhead is low, you can set a high refresh frequency without much downside. This means that you can refresh often for best results.
For instance, a simple SELECT ... FROM ... WHERE dynamic table only processes changed rows between refreshes, which has minimal
overhead and the dynamic table can run frequently at low added cost.
If the overhead is high, you must balance the credit consumption of high refresh frequency with the business benefits of freshness. For example, in a dynamic table with a join, you must join the changes in one table with the other table. No matter how small the set of changes, this join usually involves a minimum cost for you to execute. If this overhead is significant, it can accumulate as the refresh frequency increases.