시맨틱 뷰에서 차원과 메트릭 구체화(Materializing)하기

시맨틱 뷰에서 차원과 메트릭 구체화(Materializing)하기

시맨틱 뷰의 쿼리 성능을 개선하려면 뷰 안에서 선택한 dimension과 metric을 구체화(materialize)할 수 있어요. 이는 materialized view에서 데이터를 구체화하는 방식과 비슷해요. 시맨틱 뷰를 쿼리할 때 Snowflake는 기본 테이블을 스캔하고 정보를 계산하는 대신, 구체화된 dimension과 metric을 읽어요.

출처: Snowflake 문서

본문

시맨틱 뷰의 쿼리 성능을 개선하려면 뷰에서 선택한 dimension과 metric을 구체화할 수 있어요. 이는 materialized view에서 데이터를 구체화하는 방식과 비슷해요. 시맨틱 뷰를 쿼리할 때 Snowflake는 기본 테이블을 스캔하고 정보를 계산하는 대신 구체화된 dimension과 metric을 읽어요.

참고: 시맨틱 뷰 구체화는 Semantic SQL로 실행되는 쿼리(SEMANTIC_VIEW 구성 또는 시맨틱 뷰에 대한 표준 SQL)에 도움이 돼요. Cortex Analyst, Cortex Agents, Snowflake CoWork가 기본 테이블에 대해 물리적 SQL을 직접 실행하는 쿼리에는 시맨틱 뷰 구체화가 적용되지 않아요.

참고: MAX_STALENESS가 너무 낮게 설정되어 백그라운드 새로고침이 따라가지 못하면, Snowflake는 구체화를 자동으로 일시 중지해요. 복구하려면 MAX_STALENESS를 높이거나 구체화 정의를 최적화하세요(예: 증분 유지 가능한 메트릭만 사용하거나 IMMUTABLE WHERE 조건 추가).

시맨틱 뷰를 구체화 지원하도록 준비하기

시맨틱 뷰에서 dimension과 metric을 구체화하려면 먼저 다음을 해야 해요:

구체화된 dimension과 metric의 최대 지연 허용 시간 설정

MAX_STALENESS 속성은 구체화된 dimension과 metric이 새로고침되기 전에 허용되는 최대 지연(오래됨) 시간을 결정해요. 예를 들어 구체화된 dimension과 metric이 1시간 이상 오래되지 않게 하려면 MAX_STALENESS 속성을 '1 hour'로 설정해요.

이 속성은 CREATE SEMANTIC VIEW 명령으로 새 시맨틱 뷰를 만들 때 설정할 수 있어요:

CREATE [ OR REPLACE ] SEMANTIC VIEW [ IF NOT EXISTS ] <name>
  ...
  [ AI_QUESTION_CATEGORIZATION '<instructions_for_question_categorization>' ]
  [ MAX_STALENESS = '<num> { seconds | minutes | hours | days }' ]
  [ COPY GRANTS ]

기존 시맨틱 뷰에서는 ALTER SEMANTIC VIEW … SET MAX_STALENESS 명령으로 속성을 설정할 수 있어요:

ALTER SEMANTIC VIEW <name> SET MAX_STALENESS = '<num> { seconds | minutes | hours | days }'

참고: 허용되는 최소 MAX_STALENESS는 120초예요.

다음 예시는 최대 지연이 1시간인 시맨틱 뷰를 만들어요:

CREATE OR REPLACE SEMANTIC VIEW revenue_analysis
  TABLES (
    orders AS ORDERS PRIMARY KEY (o_orderkey),
    customers AS CUSTOMER PRIMARY KEY (c_custkey)
  )
  RELATIONSHIPS (
    orders_to_customers AS orders (o_custkey) REFERENCES customers
  )
  DIMENSIONS (
    customers.customer_name AS c_name,
    orders.order_date AS o_orderdate,
    orders.order_year AS YEAR(o_orderdate)
  )
  METRICS (
    orders.total_revenue AS SUM(o_totalprice),
    orders.avg_revenue AS AVG(o_totalprice),
    orders.order_count AS COUNT(o_orderkey)
  )
  MAX_STALENESS = '1 hour';

MAX_STALENESS 속성은 구체화된 데이터에 대해 허용 가능한 최대 지연을 정의해요. 시스템은 이 값을 사용해 구체화가 얼마나 자주 새로고침되는지 결정해요. 쿼리는 구체화가 MAX_STALENESS 속성 값보다 오래되지 않았을 때만 구체화를 사용하도록 다시 작성(rewrite)돼요.

참고: 시맨틱 뷰에 구체화가 존재하는 동안에는 MAX_STALENESS를 해제(unset)할 수 없어요. 속성을 제거해야 한다면 먼저 모든 구체화를 드롭하세요.

dimension과 metric을 구체화할 권한 부여

시맨틱 뷰에서 dimension과 metric을 구체화하고 해당 구체화를 관리하려면 다음 권한이 부여된 역할을 사용해야 해요:

  • 시맨틱 뷰에 대한 OWNERSHIP 권한
  • 시맨틱 뷰가 포함된 스키마에 대한 ADD SEMANTIC VIEW MATERIALIZATION 권한

이 권한을 역할에 부여하려면 GRANT … TO ROLE 명령을 실행해요. 권한 부여에 대한 자세한 내용은 Access control privileges를 참고해요.

참고: SHOW MATERIALIZATIONS 명령은 시맨틱 뷰에 대한 SELECT 권한만 필요해요.

dimension과 metric 구체화하기

시맨틱 뷰에서 dimension과 metric을 구체화하려면 ALTER SEMANTIC VIEW … ADD MATERIALIZATION을 실행해요:

ALTER SEMANTIC VIEW <name> ADD MATERIALIZATION <materialization_name>
  WAREHOUSE = <warehouse_name>
  [ REFRESH_MODE = { AUTO | FULL | INCREMENTAL } ]
  [ IMMUTABLE WHERE ( <immutable_condition> ) ]
AS
  DIMENSIONS <dimension_name> [ , ... ]
  METRICS <metric_name> [ , ... ]
  [ WHERE ( <filter_condition> ) ];

여기서:

  • *name*: 시맨틱 뷰의 이름을 지정해요.
  • *materialization_name*: 추가할 구체화의 이름을 지정해요.
  • WAREHOUSE = *warehouse_name*: dimension과 metric을 구체화할 때 사용할 웨어하우스를 지정해요.
  • REFRESH_MODE = { AUTO | FULL | INCREMENTAL }: 구체화가 새로고침되는 방식을 지정해요.
    • AUTO(기본값): Snowflake가 최적의 새로고침 전략을 자동으로 결정해요. 여러 엔티티에 걸친 구체화의 경우 AUTO는 일반적으로 FULL로 결정돼요.
    • FULL: 새로고침할 때마다 구체화를 전체적으로 다시 계산하는 것을 강제해요.
    • INCREMENTAL: 변경된 데이터만 처리하는 증분 새로고침을 강제해요. AUTO 모드가 전체 새로고침으로 처리할 쿼리를 증분화하려면 이 옵션을 사용해요.
  • IMMUTABLE WHERE ( *immutable_condition* ): 변경되지 않는 행을 식별하는 조건을 지정해요. 새로고침 범위를 제한해 성능을 개선하려면 이 조건을 지정해요. 한정되지 않은(unqualified) 컬럼 이름을 사용해요(예: orders.order_year 대신 order_year). 이 조건은 한정되지 않은 이름을 사용하는 시맨틱 뷰 쿼리 결과에 대해 평가돼요.

    중요: Snowflake는 구체화 새로고침의 비용과 시간을 줄이려면 이 절을 지정할 것을 강력히 권장해요. 자세한 내용은 Improving performance by incrementally refreshing materializations을 참고해요.

  • DIMENSIONS *dimension_name* [ , ... ]: 구체화할 dimension을 지정해요.
  • METRICS *metric_name* [ , ... ]: 사전 집계(pre-aggregate)할 metric을 지정해요.
  • WHERE ( *filter_condition* ): 구체화가 저장하는 행을 제한하는 필터를 지정해요. 이것은 IMMUTABLE WHERE와 다르다는 점에 주의해요. WHERE는 구체화에 포함될 행을 제어하고, 쿼리가 구체화를 사용하도록 다시 작성될 시기를 결정해요. IMMUTABLE WHERE는 다시 계산할 필요가 없는 행을 식별하는 새로고침 최적화 힌트예요. 자세한 내용은 Materializing a filtered subset of data를 참고해요.

참고: 구체화에는 다음 metric 유형을 사용할 수 없어요:

예를 들어:

ALTER SEMANTIC VIEW revenue_analysis ADD MATERIALIZATION revenue_by_customer
  WAREHOUSE = my_wh
  AS
    DIMENSIONS customers.customer_name
    METRICS orders.total_revenue;

다중 엔티티 구체화에 대해 증분 새로고침을 강제하려면:

ALTER SEMANTIC VIEW revenue_analysis ADD MATERIALIZATION revenue_by_customer_year
  WAREHOUSE = my_wh
  REFRESH_MODE = INCREMENTAL
  AS
    DIMENSIONS customers.customer_name, orders.order_year
    METRICS orders.total_revenue;

시맨틱 뷰에 여러 구체화를 추가할 수 있어요. 각 구체화는 사전 집계할 dimension과 metric의 부분집합을 지정해요. 또한 이 명령으로 기존 구체화의 정의를 업데이트할 수도 있어요. 같은 이름으로 ADD MATERIALIZATION을 실행하면:

  • 같은 정의: 작업은 no-op이에요.
  • 다른 정의: 기존 구체화가 드롭되고 새 정의로 교체돼요.

Snowflake는 원하는 MAX_STALENESS를 충족하도록 구체화를 정기적으로 자동 새로고침해요. 새로고침이 너무 오래 걸려 구체화가 한도를 넘어 지연되면 구체화는 재작성(rewrite)에 사용되지 않아요. 그런 경우 새로고침 기록을 확인하고 시맨틱 뷰의 MAX_STALENESS를 높이는 것을 고려해요:

ALTER SEMANTIC VIEW revenue_analysis SET MAX_STALENESS = '2 hours';

쿼리 처리 시 구체화가 사용되는 방식

시맨틱 뷰를 쿼리하면 Snowflake는 구체화를 사용해 쿼리를 처리해요. 플래너는 요청된 dimension과 metric을 커버하는 가장 저렴한 구체화를 선택해요. 다음 섹션들은 Snowflake가 쿼리를 처리할 때 구체화가 어떻게 사용되는지 설명해요.

가산 메트릭의 재집계

구체화에 쿼리가 요청한 것보다 더 많은 dimension이 포함되어 있으면, Snowflake는 가산(additive) 메트릭을 재집계할 수 있어요. 예를 들어 SUM(total_revenue)가 있는 (customer_name, order_year) 구체화는 연도를 합산해 customer_name만 요청하는 쿼리를 처리할 수 있어요.

메트릭이 다음 함수를 사용하면 Snowflake는 메트릭을 재집계할 수 있어요:

참고: 집계 위에 표현식이 있는 메트릭(예: 2 * SUM(x) + COUNT(y))은 가산으로 간주되지 않아요.

메트릭이 다음 함수를 사용하면 Snowflake는 메트릭을 재집계할 수 없어요:

WHERE 절의 dimension이 처리되는 방식

WHERE 절에서 사용된 dimension은 커버된(covered) dimension으로 간주돼요. 예를 들어 (customer_name, order_year) 구체화는 다음 쿼리가 처리될 때 사용될 수 있어요:

SELECT * FROM SEMANTIC_VIEW(
    revenue_analysis
    DIMENSIONS customers.customer_name
    METRICS orders.total_revenue
    WHERE orders.order_year = 2024
);

WHERE 절의 dimension에 대한 표현식(예: MOD(orders.order_year, 2) = 0)도 기본 dimension이 구체화로 커버되는 한 지원돼요. 가산 메트릭과 dimension 위의 표현식에도 동일하게 적용돼요.

구체화가 사용되지 않는 경우

다음 경우에는 구체화가 쿼리 재작성에 사용되지 않아요:

  • 어떤 구체화도 요청된 dimension이나 metric을 커버하지 않음
  • 구체화가 MAX_STALENESS 속성 값을 초과함
  • 구체화가 참조하는 컬럼에 마스킹 정책 또는 행 액세스 정책이 존재함
  • 비가산 메트릭에 재집계가 필요함
  • 구체화가 SUSPENDED 상태임
  • 쿼리의 WHERE 절이 구체화의 WHERE 필터보다 덜 제한적이거나, 쿼리가 구체화된 dimension이 아닌 컬럼으로 필터링함. Materializing a filtered subset of data 참고.

데이터의 필터링된 부분집합 구체화하기

구체화를 추가할 때 WHERE 절을 사용해 저장되는 행을 제한할 수 있어요. 이는 가장 최근 데이터나 가장 자주 쿼리되는 데이터만 구체화할 때 유용해요(예: 지난 2년간의 주문).

ALTER SEMANTIC VIEW revenue_analysis ADD MATERIALIZATION recent_revenue
  WAREHOUSE = my_wh
AS
  DIMENSIONS orders.order_year, orders.category
  METRICS orders.total_revenue
  WHERE (order_year > 2020);

Snowflake는 쿼리의 WHERE 절이 구체화의 필터와 호환될 때 쿼리를 이 구체화로 재작성해요:

쿼리 WHERE 절 재작성? 이유
WHERE order_year > 2020 ✓ 예 구체화 필터와 동일
WHERE order_year > 2022 ✓ 예 필터보다 더 제한적이고, order_year가 구체화된 dimension이므로 Snowflake가 저장된 데이터 위에 추가 필터를 적용할 수 있음
WHERE order_year > 2019 ✗ 아니요 덜 제한적 — 구체화에 2020년 이전 행이 포함되어 있지 않음
WHERE order_year > 2020 AND category = 'X' ✗ 아니요 category가 구체화된 dimension이 아니므로 저장된 데이터에 추가 필터를 적용할 수 없음

구체화를 증분 새로고침해 성능 개선하기

시맨틱 뷰에 비가산 메트릭(예: COUNT(DISTINCT ... ))이나 여러 엔티티에 걸친 복잡한 쿼리가 있으면 REFRESH_MODE = INCREMENTAL은 지원되지 않고 Snowflake는 새로고침할 때마다 전체 재계산을 수행해요. 그래도 IMMUTABLE WHERE 절을 지정하면 이러한 전체 새로고침의 성능을 개선할 수 있어요.

IMMUTABLE WHERE 절은 변경되지 않는 행을 식별해 전체 새로고침의 범위를 제한해요. 조건을 충족하는 행은 불변으로 취급되므로 Snowflake는 변경 가능한 부분만 다시 계산해요.

예를 들어 다음 문은 2020년 1월 1일 이전의 모든 주문이 불변으로 취급되는 구체화를 추가해요:

ALTER SEMANTIC VIEW revenue_analysis ADD MATERIALIZATION historical_revenue
    WAREHOUSE = my_wh
    IMMUTABLE WHERE (order_date < '2020-01-01')
AS
    DIMENSIONS orders.order_date
    METRICS orders.total_revenue;

불변 조건 업데이트하기

기존 구체화를 다시 만들지 않고 IMMUTABLE WHERE 조건을 업데이트할 수 있어요. 이는 더 많은 데이터가 과거 데이터가 됨에 따라 워터마크 날짜를 앞으로 옮길 때 유용해요.

조건을 업데이트하려면 같은 이름과 업데이트된 IMMUTABLE WHERE 절로 ADD MATERIALIZATION을 다시 실행해요:

ALTER SEMANTIC VIEW revenue_analysis ADD MATERIALIZATION historical_revenue
    WAREHOUSE = my_wh
    IMMUTABLE WHERE (order_date < '2024-01-01')
AS
    DIMENSIONS orders.order_date
    METRICS orders.total_revenue;

참고:

  • 불변 영역을 확대하면(경계를 시간상 앞으로 이동) 전체 재초기화 없이 새로고침돼요.
  • 불변 영역을 축소하거나 완전히 제거하면 전체 재초기화가 트리거돼요.
  • IMMUTABLE WHERE 절을 완전히 제거하려면 그 절 없이 ADD MATERIALIZATION을 다시 실행해요.

구체화 일시 중지 및 재개

백그라운드 새로고침을 중지하고 쿼리 재작성에 사용되지 않게 하려면 구체화를 수동으로 일시 중지할 수 있어요. 나중에 재개하려면 RESUME 명령을 사용해요.

구체화는 다음 경우에도 자동으로 일시 중지돼요:

ALTER SEMANTIC VIEW <name> SUSPEND MATERIALIZATION <materialization_name>;
ALTER SEMANTIC VIEW <name> RESUME MATERIALIZATION <materialization_name>;

예를 들어:

ALTER SEMANTIC VIEW revenue_analysis SUSPEND MATERIALIZATION revenue_by_customer;

-- Later, resume it:
ALTER SEMANTIC VIEW revenue_analysis RESUME MATERIALIZATION revenue_by_customer;

참고: 시맨틱 뷰가 구체화 정의를 깨뜨리는 방식으로 변경될 때도 구체화는 자동으로 일시 중지돼요. 자세한 내용은 Preserving materializations when altering a semantic view을 참고해요.

DDL 변경이 구체화에 미치는 영향

아래 섹션들은 시맨틱 뷰, 그 기본 객체, 또는 구체화 정의 자체의 변경이 기존 구체화에 어떻게 영향을 주는지 설명해요.

시맨틱 뷰 변경

CREATE OR REPLACE SEMANTIC VIEW는 무엇이 변경됐든 항상 모든 기존 구체화를 즉시 드롭해요. 뷰를 교체한 후에는 ADD MATERIALIZATION으로 구체화를 다시 만들어야 해요.

변경 사항을 유지하려면 CREATE OR ALTER SEMANTIC VIEW를 사용하는 대신:

변경 구체화에 미치는 영향 재작성에 계속 사용? 복구
metric, dimension, 논리 테이블, 관계 추가 없음 ✅ —
구체화에 사용되지 않는 dimension, metric, 논리 테이블, 관계 변경 또는 삭제 없음 ✅ —
구체화에 사용되는 dimension, metric, 논리 테이블, 관계 변경 또는 삭제 즉시 일시 중지 ❌ SV 정의를 되돌리고 RESUME, 또는 DROP AND ADD MATERIALIZATION

예를 들어 metric의 집계 함수를 SUM에서 COUNT로 변경하면 그 metric에 의존하는 모든 구체화가 일시 중지돼요. 일시 중지된 구체화는 제거되지 않아요. SV 정의를 이전 상태로 되돌리면 구체화를 재개할 수 있어요:

ALTER SEMANTIC VIEW revenue_analysis RESUME MATERIALIZATION revenue_by_customer;

정의가 더 이상 호환되지 않으면 구체화를 드롭하고 다시 만들어요:

ALTER SEMANTIC VIEW revenue_analysis DROP MATERIALIZATION revenue_by_customer;

ALTER SEMANTIC VIEW revenue_analysis ADD MATERIALIZATION revenue_by_customer
  WAREHOUSE = my_wh
  ...;

기본 객체 변경

시맨틱 뷰가 참조하는 뷰나 테이블의 변경도 구체화에 영향을 줄 수 있어요:

변경 구체화에 미치는 영향 재작성에 계속 사용? 복구
구체화에 영향을 주는 변경(예: CREATE OR REPLACE VIEW, ALTER TABLE DROP COLUMN) 다음 새로고침이 전체 새로고침이 됨. 새로고침이 실패하면 구체화가 일시 중지됨 ✅ (일시 중지되지 않은 경우) 새로고침이 계속 실패하면 DROP AND ADD MATERIALIZATION

시맨틱 뷰 변경과 달리, Snowflake는 기본 객체가 변경될 때 구체화를 즉시 일시 중지하지 않아요. 다음 예약된 새로고침이 변경을 감지하고 대응할 때까지 기다려요.

구체화 정의 변경

이미 존재하는 구체화에 대해 ADD MATERIALIZATION을 실행하면, 동작은 무엇이 변경됐는지에 따라 달라져요:

변경 구체화에 미치는 영향 재작성에 계속 사용?
기존 구체화와 같은 정의 No-op ✅
다른 정의(예: metric/dimension 추가·삭제, WHERE 절 변경) 새 정의로 전체 새로고침(재초기화) ✅
IMMUTABLE WHERE 조건이 더 엄격해짐(예: year > 2020 → year > 2021) 없음 ✅
IMMUTABLE WHERE 조건이 더 느슨해짐(예: year > 2021 → year > 2020) 전체 새로고침 ✅

구체화 수동 새로고침

일련의 dimension과 metric의 구체화를 새로고침하려면 ALTER SEMANTIC VIEW … REFRESH MATERIALIZATION을 실행해요:

ALTER SEMANTIC VIEW <name> REFRESH MATERIALIZATION <materialization_name>;

참고: dimension과 metric을 구체화할 권한이 부여된 역할을 사용해야 해요.

예를 들어 다음 문은 revenue_analysis 시맨틱 뷰의 revenue_by_customer 구체화를 새로고침해요:

ALTER SEMANTIC VIEW revenue_analysis REFRESH MATERIALIZATION revenue_by_customer;

이 명령을 실행하면 수동 새로고침은 세션의 현재 웨어하우스를 사용해요. 백그라운드 새로고침은 구체화 생성 시 지정된 웨어하우스를 사용해 MAX_STALENESS 속성에 따라 자동으로 수행돼요.

YAML로 구체화 선언적으로 관리하기

SYSTEM$MANAGE_SEMANTIC_VIEW_MATERIALIZATIONS_FROM_YAML을 사용해 시맨틱 뷰의 모든 구체화를 선언적으로 관리할 수 있어요. 이 저장 프로시저는 시맨틱 뷰의 구체화를 YAML 사양과 동기화해요:

  • YAML에 있지만 존재하지 않는 구체화는 생성돼요.
  • 존재하지만 정의가 변경된 구체화는 교체돼요.
  • 이미 같은 정의로 존재하는 구체화는 그대로 남아요(no-op).
  • 시맨틱 뷰에 존재하지만 YAML에 없는 구체화는 드롭돼요.

전체 구문, 파라미터, 예시는 SYSTEM$MANAGE_SEMANTIC_VIEW_MATERIALIZATIONS_FROM_YAML을 참고해요.

구체화 제거하기

시맨틱 뷰에서 구체화를 제거하려면 ALTER SEMANTIC VIEW … DROP MATERIALIZATION을 실행해요:

ALTER SEMANTIC VIEW <name> DROP MATERIALIZATION <materialization_name>;

참고: dimension과 metric을 구체화할 권한이 부여된 역할을 사용해야 해요.

예를 들어 다음 문은 revenue_analysis 시맨틱 뷰에서 revenue_by_customer 구체화를 제거해요:

ALTER SEMANTIC VIEW revenue_analysis DROP MATERIALIZATION revenue_by_customer;

시맨틱 뷰의 구체화 나열하기

시맨틱 뷰의 구체화를 나열하려면 SHOW MATERIALIZATIONS 명령을 실행해요:

SHOW MATERIALIZATIONS IN SEMANTIC VIEW <name>;

참고: 시맨틱 뷰에 대한 SELECT 권한이 부여된 역할을 사용해야 해요.

예를 들어 revenue_analysis 시맨틱 뷰의 구체화를 나열하려면:

SHOW MATERIALIZATIONS IN SEMANTIC VIEW revenue_analysis;

이 명령은 다음 컬럼으로 표 형식의 출력을 반환해요:

컬럼 설명
name 구체화의 이름
state 구체화의 상태. 다음 중 하나일 수 있음: ACTIVE(구체화가 운영 상태이며 쿼리 재작성 대상임), SUSPENDED(새로고침 실패나 수동 일시 중지로 인해 일시 중지됨. suspend_reason 필드에 세부 정보가 채워짐)
suspend_reason 구체화가 일시 중지된 이유
stale_by 구체화가 지연될 시간
warehouse dimension과 metric을 구체화하는 데 사용되는 웨어하우스
dimensions 구체화된 dimension
metrics 구체화된 metric
immutable_where 불변 행을 식별하는 데 사용되는 조건
refresh_mode 구체화의 해석된 새로고침 모드(FULL 또는 INCREMENTAL). REFRESH_MODE가 AUTO로 설정된 경우 이 컬럼은 자동으로 선택된 모드를 보여줌
refresh_mode_reason 특정 새로고침 모드가 선택된 이유. AUTO가 쿼리 복잡성 때문에 FULL을 선택할 때 채워짐

구체화 새로고침 모니터링

새로고침 기록과 이벤트 테이블을 사용해 구체화 새로고침을 모니터링할 수 있어요.

새로고침 기록 보기

구체화의 새로고침 기록을 보려면 INFORMATION_SCHEMA 스키마의 SEMANTIC_VIEW_MATERIALIZATION_REFRESH_HISTORY 테이블 함수를 호출해요:

SEMANTIC_VIEW_MATERIALIZATION_REFRESH_HISTORY(
    NAME => '<materialization_name>'
)

예를 들어 revenue_by_customer 구체화의 새로고침 기록을 보려면:

SELECT * FROM TABLE(INFORMATION_SCHEMA.SEMANTIC_VIEW_MATERIALIZATION_REFRESH_HISTORY(
    NAME => 'revenue_by_customer'
));

이 함수는 다음 컬럼으로 표 형식의 출력을 반환해요:

컬럼 설명
name 구체화의 이름
schema_name 시맨틱 뷰가 포함된 스키마의 이름
database_name 시맨틱 뷰가 포함된 데이터베이스의 이름
state 새로고침의 상태. 다음 중 하나일 수 있음: ACTIVE(구체화가 운영 상태이며 쿼리 재작성 대상임), SUSPENDED(새로고침 실패로 인해 일시 중지됨)
state_message 새로고침의 오류 또는 상태 메시지
refresh_start_time 새로고침이 시작된 시간
refresh_end_time 새로고침이 완료된 시간
warehouse 새로고침에 사용된 웨어하우스
refresh_action 새로고침 중 수행된 동작(예: INITIALIZE, REINITIALIZE, REFRESH, NO_DATA)

이벤트 테이블로 경고 설정하기

구체화가 새로고침 이벤트를 이벤트 테이블로 내보내도록 구성해, 실패나 일시 중지에 대한 경고를 만들 수 있어요.

구체화에 대해 이벤트 로깅을 활성화하려면:

ALTER SEMANTIC VIEW <name> ALTER MATERIALIZATION <materialization_name>
  SET LOG_EVENT_LEVEL = 'INFO';

이벤트 로깅을 비활성화하려면:

ALTER SEMANTIC VIEW <name> ALTER MATERIALIZATION <materialization_name>
  UNSET LOG_EVENT_LEVEL;

구체화 새로고침 이벤트는 snow.executable.type = 'SEMANTIC_VIEW_MATERIALIZATION'로 이벤트 테이블에 나타나요. 이벤트 테이블을 쿼리해 새로고침 상태에 따라 경고를 설정할 수 있는데, dynamic table alerting과 유사해요.

더 알아보기 (Learn more)