Understanding costs for dynamic tables

이 항목에서는 동적 테이블과 관련된 컴퓨팅 및 저장 비용에 대한 개요를 제공합니다. Snowflake 비용에 대한 일반적인 정보는 전체 비용 파악하기 섹션을 참조하십시오.

Compute costs

동적 테이블에는 가상 웨어하우스와 클라우드 서비스 컴퓨팅이라는 두 가지 컴퓨팅 비용이 발생합니다.

동적 테이블에는 새로 고침</user-guide/dynamic-tables-refresh>`을 수행하기 위해 하나 이상의 :ref:`가상 웨어하우스<label-virtual_warehouse_credit_usage>`가 필요합니다. 다른 작업에 대한 컴퓨팅 비용을 분리하려는 경우 선택적으로 두 번째 웨어하우스를 할당할 수 있습니다. 자세한 내용은 :doc:/user-guide/dynamic-tables-warehouses` 섹션을 참조하십시오.

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.

연결된 가상 웨어하우스가 일시 중단되고 클라우드 서비스 컴퓨팅이 기본 테이블의 변경 사항을 감지하지 못하는 경우, 웨어하우스는 일시 중단된 상태로 유지되고 동적 테이블은 크레딧을 사용하지 않습니다. 클라우드 서비스 컴퓨팅이 기본 테이블의 변경 사항을 식별하면 적절한 웨어하우스가 자동으로 재개됩니다. 변경 사항이 증분 새로 고침을 지원하는 경우 동적 테이블은 WAREHOUSE 매개 변수를 사용하여 새로 고쳐집니다. 다시 초기화가 필요한 경우(예: 기본 테이블 스키마 변경으로 인해) 동적 테이블은 INITIALIZATION_WAREHOUSE를 사용하여 전체 다시 초기화를 수행합니다. 동적 테이블이 자동으로 일시 중단되는 방식에 대한 자세한 내용은 자동 동적 테이블 서스펜션 섹션을 참조하세요.

가상 웨어하우스 크레딧 사용량 확인하기

동적 테이블 새로 고침이 가상 웨어하우스 크레딧을 소비했는지 확인하려면 Snowsight 의 Refresh History 탭을 사용합니다.

  1. 탐색 메뉴에서 Transformation » Dynamic tables 를 선택합니다.

  2. 동적 테이블을 선택한 후 Refresh History 탭을 선택합니다.

  3. 웨어하우스를 사용하여 업데이트한 새로 고침을 보려면 Warehouse used only 확인란을 선택합니다.

팁

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.

자세한 내용은 동적 테이블의 웨어하우스 사용량 이해하기 섹션을 참조하십시오.

불변성 제약 조건에 대한 비용 계산

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:

  • 업스트림 테이블 또는 뷰 다시 생성.

  • 업스트림 데이터 거버넌스 정책의 변경.

  • 장애 조치 그룹의 보조 리전으로 장애 조치.

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.

예를 들어, 다음 수정 사항은 재초기화를 트리거하지 않습니다.

  • (ts < CURRENT_TIMESTAMP() - INTERVAL '2 days')`~ :code:`(ts < CURRENT_TIMESTAMP() - INTERVAL '1 days')

  • (year <= 2023)`~:code:`(year <= 2024)

다음 수정 사항은 재초기화를 트리거합니다.

  • (ts < '2025-01-02')`~:code:`(ts < '2025-01-01')

  • (year < 2024)`~:code:`(month < 10)

저장소 비용

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 청구.

이 섹션에서는 동적 테이블에 대한 다음 저장소 고려 사항에 대해 설명합니다.

이 저장소에 비용이 발생하는 방식에 대한 자세한 내용은 저장소 비용 이해하기 및 데이터 저장소 고려 사항 를 참조하십시오.

Time Travel 및 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.

자주 새로 고치면 Time Travel 데이터의 축적이 증가하여 전체 저장소 사용량이 늘어날 수 있다는 점에 유의하세요. 자세한 내용은 Time Travel 이해 및 사용하기 섹션을 참조하십시오.

Fail-safe 기능은 데이터 손실이나 손상으로부터 동적 테이블을 보호하는 데 유용합니다. 구성된 Fail-safe 기간에 따라 추가 저장소 요금이 부과될 수 있습니다.

동적 테이블 복제

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 복제 및 동적 테이블.

일시 중단된 동적 테이블

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.

일시적 동적 테이블

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.

증분 새로 고침 작업을 위한 추가 저장소

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.

열 수가 매우 적은 테이블의 경우 동등한 CTAS 테이블에 비해 저장소가 대폭 증가하거나 현저하게 증가할 수 있습니다. 더 넓은 동적 테이블에서는 이 효과가 덜 두드러집니다.

새로 고침 일정 비용

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:

참고

원본이 변경되지 않은 경우 새로 고침에 소요되는 비용은 비교적 저렴합니다. 자세한 내용은 이 항목의 Compute costs 섹션을 참조하십시오.

전체 새로 고침 일정

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.

증분 새로 고침 일정

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.

언어: 한국어