리프레시 동작 예측하기

리프레시 동작 예측하기

다이나믹 테이블의 다음 리프레시가 실제로 실행되기 전에 무엇을 할지 Snowflake에 물어볼 수 있어요. EXPLAIN CHANGES는 문장을 실제로 실행하지 않고, 그 문장이 만들 변경에 대한 메타데이터를 생성합니다. 다이나믹 테이블의 경우 그 메타데이터에는 리프레시 동작에 대한 세부 정보가 포함돼 있어요. 이 정보를 얻는 방법은 두 가지입니다:

  • 리프레시를 직접 예측하기. 수동 리프레시 앞에 EXPLAIN CHANGES를 붙여, 지금 당장 다음 리프레시가 무엇을 할지 물어봅니다.
  • DDL 변경의 효과 예측하기. 테이블의 정의나 속성을 변경하는 문장 앞에 EXPLAIN CHANGES를 붙여, 그 변경을 적용하지 않은 채로 변경 후의 다음 리프레시가 무엇을 할지 물어봅니다. Predict the next refresh 참고.

두 형태 모두 같은 종류의 예측을 반환하며, 이 페이지의 나머지에서 설명합니다.

출처: Snowflake 문서

본문

다음 리프레시 예측하기

다이나믹 테이블을 대상으로 하는 DDL 문장 앞에 EXPLAIN CHANGES를 붙이세요:

EXPLAIN CHANGES [ USING { TABULAR | JSON | TEXT } ] <ddl_statement>

EXPLAIN CHANGES ALTER DYNAMIC TABLE dt_orders SET TARGET_LAG = '5 minutes';

결과에는 effects 컬럼이 있습니다. domain이 DYNAMIC_TABLE인 행에서, 그 컬럼이 리프레시 예측을 담고 있어요:

[
  {
    "effect_type": "DYNAMIC_TABLE_REFRESH",
    "properties": {
      "refresh_mode": "ADAPTIVE",
      "effective_refresh_action": "INCREMENTAL",
      "is_expect_failure": false
    }
  }
]

문장은 적용되지 않았고, dt_orders는 원래의 target lag를 그대로 유지합니다. raw_orders에 dt_orders가 아직 처리하지 않은 행이 있다면, 이 예측은 변경을 적용했을 때 다음 리프레시가 변경된 행만 처리한다는 뜻입니다.

참고: 기본적으로 EXPLAIN CHANGES는 탭 형식 결과를 반환합니다. 문장이 건드리는 각 객체에 대해 한 행씩, operation, domain, name, changes, effects 컬럼을 가집니다. 예:

operation    domain           name                            changes    effects
ALTER        DYNAMIC_TABLE    "MYDB"."MYSCHEMA"."DT_ORDERS"    []         [{"effect_type": "DYNAMIC_TABLE_REFRESH", "properties": {"refresh_mode": "ADAPTIVE", "effective_refresh_action": "INCREMENTAL", "is_expect_failure": false}}]

changes 컬럼은 문장이 만들 변경 집합을 설명하며, 이 페이지의 범위 밖입니다. 리프레시 동작은 domain이 DYNAMIC_TABLE인 행의 effects 컬럼을 읽으면 됩니다.

예측 읽기

각 DYNAMIC_TABLE_REFRESH 효과는 properties 객체를 담고 있습니다:

속성 설명
effective_refresh_action 다음 리프레시 동작이 무엇인지. 가능한 값은 Refresh actions 참고
is_expect_failure 다음 리프레시가 실패할 때 true. 항상 존재
refresh_mode 테이블이 현재 사용하는 리프레시 모드. 예측이 실패(failure)일 때는 생략
refresh_mode_reason 다이나믹 테이블이 이 리프레시 모드를 선택하는 이유. 테이블의 리프레시 모드가 INCREMENTAL일 때와 예측이 실패일 때는 생략. Dynamic table refresh modes 참고
effective_refresh_action_reason 재초기화가 필요한 변경이 무엇인지. 재초기화가 필요할 때만 존재. DYNAMIC_TABLE_REFRESH_HISTORY의 REINIT_REASON 컬럼의 예측 형태
expect_failure_reason 리프레시가 반환할 에러. is_expect_failure가 true일 때만 존재

Refresh actions

effective_refresh_action은 DYNAMIC_TABLE_REFRESH_HISTORY의 REFRESH_ACTION 컬럼과 같은 어휘를 사용합니다: NO_DATA, REINITIALIZE, FULL, INCREMENTAL, CUSTOM_INCREMENTAL. 완료된 리프레시가 아니라 예측이기 때문에, effective_refresh_action은 REFRESH_ACTION에는 없는 두 값도 보고합니다:

동작 의미
CREATE 다음 리프레시가 테이블의 새 인스턴스를 처음으로 초기화. 테이블을 만들거나 교체하는 문장에 대해 보고됨
FAILURE 다음 리프레시가 실패할 것. is_expect_failure가 true이고 expect_failure_reason이 에러를 담음. 시작 후 실패하는 리프레시는 시도했던 동작과 에러를 리프레시 이력에 보고함

참고: 리프레시 모드(refresh mode)는 다이나믹 테이블의 구성된 리프레시 동작이고, 리프레시 동작(refresh action)은 다이나믹 테이블이 리프레시하기 위해 취할 효과적인 행동입니다. 예를 들어 ADAPTIVE는 다이나믹 테이블이 가질 수 있는 리프레시 모드이지만, ADAPTIVE 테이블이 취하는 효과적 동작은 리프레시가 무엇을 해야 하는지에 따라 달라져요.

변경이 다이나믹 테이블을 재초기화하는지 확인하기

어떤 변경이 다이나믹 테이블로 하여금 모든 소스 데이터를 다시 처리하게 만드는지에 대한 일반 규칙이 있습니다. 전체 목록은 What triggers reinitialization을 참고하세요. REFRESH_MODE 변경이 그러한 경우 중 하나입니다: Refresh mode transitions 참고.

예측이 REINITIALIZE일 때, effective_refresh_action_reason이 변경의 어느 부분이 원인인지 알려줍니다. 예를 들어 dt_orders가 settled 주문을 덮는 frozen region을 갖고 있고, 그것을 제거하면 그 행들이 다시 범위 안에 들어옵니다:

EXPLAIN CHANGES ALTER DYNAMIC TABLE dt_orders UNSET FROZEN WHERE;

[
  {
    "effect_type": "DYNAMIC_TABLE_REFRESH",
    "properties": {
      "refresh_mode": "ADAPTIVE",
      "effective_refresh_action": "REINITIALIZE",
      "is_expect_failure": false,
      "effective_refresh_action_reason": "Frozen region changed or removed."
    }
  }
]

제한 사항

  • EXPLAIN CHANGES는 문장이 대상으로 하는 다이나믹 테이블의 리프레시 동작만 예측하며, 문장의 쿼리가 읽는 다른 다이나믹 테이블은 예측하지 않습니다.
  • 예측은 EXPLAIN CHANGES가 실행되는 순간의 테이블 상태와 소스 데이터 상태를 반영합니다. 지금까지 도착한 데이터와 테이블의 현재 상태에 의존하므로, 문장을 적용하기 전에 변할 수 있어요.

더 알아보기 (Learn more)