Snowflake가 시맨틱 뷰를 검증하는 방법

Snowflake가 시맨틱 뷰를 검증하는 방법

Snowflake는 시맨틱 뷰를 정의할 때 일련의 검증 규칙을 준수하는지 확인해요. 이 규칙들은 시맨틱 모델이 올바르게 구성되어 제대로 동작하도록 보장해 줘요.

출처: Snowflake 문서

본문

Snowflake는 시맨틱 뷰를 정의할 때 일련의 검증 규칙을 준수하는지 확인해요. 이 규칙들은 시맨틱 모델이 잘 구성되었고 올바르게 동작할 것임을 보장해 줘요.

이 규칙들은 다음 섹션에서 설명해요:

일반 검증 규칙

다음 규칙들은 시맨틱 뷰 전반에 적용돼요:

  • 필수 요소: 시맨틱 뷰는 최소한 하나의 dimension 또는 metric을 정의해야 해요. 예를 들어 TPC-H 시맨틱 뷰는 최소한 하나의 dimension(예: customer_name) 또는 하나의 metric(예: order_average_value)이 필요해요.
  • 기본 키와 외래 키: 기본 키와 외래 키 정의에서는 물리적 기본 테이블 컬럼 또는 기본 테이블 컬럼을 직접 참조하는 논리 테이블의 표현식(예: t1.fact AS t1.col)을 사용해야 해요. 예를 들어 TPC-H 스키마에서 c_custkey를 customer 테이블의 기본 키로, o_custkey를 orders 테이블의 외래 키로 사용할 수 있어요. c_custkey와 o_custkey는 물리적 기본 테이블의 컬럼이에요.
  • 테이블 별칭 참조: 관계나 표현식에서 테이블을 참조할 때는 정의된 별칭(alias)을 사용해야 해요. 예를 들어 테이블 별칭을 orders AS snowflake_sample_data.tpch.orders_table로 정의했다면, 메트릭 정의에서 테이블 별칭인 orders(orders_table이 아니라)를 사용해야 해요. 논리 테이블의 별칭을 지정하지 않았다면 어떤 표현식에서든 논리 테이블 이름을 사용해야 해요.

관계(relationship) 검증 규칙

다음 규칙들은 시맨틱 뷰의 관계에 적용돼요:

  • 다대일(Many-to-one) 및 일대일(One-to-one) 관계: 관계는 외래 키 제약 조건처럼 동작해요. 논리 테이블 table_1이 col_1을 기본 키로 식별한다고 가정해 보죠: 
    TABLES (
  table_1 AS my_table_1 PRIMARY KEY (col_1)
  ...
    관계를 table_2 (col_2) REFERENCES table_1 (col_1)로 정의하면, col_1은 기본 키여야 하고 col_2는 외래 키 역할을 해야 해요.
    • table_2의 여러 행이 col_2에서 같은 값을 사용한다면, table_2에서 table_1로의 다대일 관계를 만드는 거예요. 예를 들어 orders (o_custkey) REFERENCES customers (c_custkey)는 orders에서 customers로의 다대일 관계를 만들어요(한 고객에게 여러 주문이 속할 수 있음).
    • table_2의 각 행이 col_2에서 고유한 값을 가진다면, table_2에서 table_1로의 일대일 관계를 만드는 거예요. 예를 들어 customer_details_extended (e_custkey) REFERENCES customer_details (c_custkey)는 customer_details_extended에서 customer_details로의 일대일 관계를 만들어요(고객의 확장 세부 정보 한 행은 키 c_custkey의 고객 세부 정보 한 행에 속함).
    • 일대일 관계에 수행되는 검증:
      • 행 수준 표현식은 같은(또는 더 낮은) 세분성(granularity)의 다른 행 수준 표현식을 참조할 수 있어요. 예를 들어 customer_details와 customer_details_extended가 일대일 관계이고, 각각의 행 수준 표현식은 특정 고객 하나를 가리켜요. 행 수준 표현식이 같은 세분성이므로 각각은 행 수준 표현식에서 서로를 직접 참조할 수 있어요. 결과적으로 customer_details의 행 수준 표현식은 customer_details_extended의 행 수준 표현식의 메트릭이나 집계를 참조할 수 없어요(그 반대도 마찬가지).
      • 집계 수준 표현식은 단일 집계(single aggregate)를 사용해 같은 세분성의 행 수준 표현식을 참조해야 해요. 예를 들어 customer_details 또는 customer_details_extended의 집계 수준 표현식은 다른 엔티티를 참조할 때 단일 집계를 사용해야 해요. 또한 customer_details와 customer_details_extended의 메트릭은 집계 없이 두 엔티티의 다른 메트릭을 직접 참조해야 해요. 이 규칙들은 엔티티 간 관계가 customer_details REFERENCES customer_details_extended로 정의됐든 customer_details_extended REFERENCES customer_details로 정의됐든 적용돼요.
    • 전이 관계(Transitive relationships): Snowflake는 간접 관계를 자동으로 유도해요. 예를 들어 line_items와 orders 사이의 관계와 orders와 customer 사이의 관계를 정의하면, Snowflake는 line_items와 customer 사이에도 관계가 있다는 것을 이해해요.
      • 일대일 관계는 다른 일대일 및 다대일 관계와 상호작용할 때 전이성을 존중해요:
        • 논리 테이블 customers와 customer_details가 일대일 관계이고, customer_details와 customer_details_extended가 일대일 관계라면, customers와 customer_details_extended도 일대일 관계인 것으로 자동으로 유추되어 검증 중에도 그렇게 취급돼요.
        • 논리 테이블 customers와 customer_details가 일대일 관계이고, customer_details와 regions가 다대일 관계라면, customers는 regions에 대해 전이적으로 다대일인 것으로 유추되며, 이는 표현식 검증 중 customers에게 regions보다 더 높은 세분성을 부여해요.
    • 순환 관계 금지: 전이 경로를 통해서라도 순환 관계를 정의할 수 없어요. 예를 들어 orders에서 customer로의 관계와 customer에서 orders로의 관계를 동시에 정의할 수 없어요.
    • 자기 참조 금지: 현재 테이블은 자기 자신을 참조할 수 없어요(직원들이 다른 직원을 관리자로 참조할 수 있는 직원 관리자 계층처럼).
    • 다중 경로 관계 제약: 두 테이블 사이에 여러 관계를 정의할 수 있지만 제한이 있어요. 예를 들어 line_items가 orders와 order_key 및 다른 컬럼을 통해 둘 다 관련되어 있다면, 이 테이블들은 서로의 시맨틱 표현식을 참조할 수 없어요.

      참고: 두 테이블을 조인하는 데 사용할 수 있는 경로가 여러 개라면, 이 관계들을 정의하고 메트릭을 정의할 때 어떤 경로를 사용할지 지정해야 해요. 자세한 내용은 Specifying the relationship for a metric when multiple relationship paths exist를 참고해요.

표현식 검증 규칙

다음 규칙들은 fact, dimension, metric의 시맨틱 표현식에 적용돼요:

표현식에 대한 일반 규칙

다음 규칙들은 시맨틱 표현식 전반에 적용돼요:

  • 표현식 유형: dimension과 fact는 행 수준(비집계) 표현식이고, metric은 집계 수준 표현식이에요. 예를 들어 customer_name은 dimension(행 수준)이고 order_average_value는 metric(집계 수준)이에요.
  • 테이블 연관: 모든 시맨틱 표현식은 테이블과 연관되어야 해요. 예를 들어 customer_name은 customer.customer_name으로, order_average_value는 orders.order_average_value로 정의해야 해요.
  • 같은 테이블 참조: 표현식은 한정된(qualified) 이름이나 한정되지 않은(unqualified) 이름을 사용해 같은 논리 테이블의 기본 테이블 컬럼이나 다른 표현식을 참조할 수 있어요. 예를 들어 orders 테이블에서 orders.shipping_month를 MONTH(o_shipdate)(한정되지 않은 컬럼 이름 사용) 또는 MONTH(orders.o_shipdate)(한정된 이름 사용)로 정의할 수 있어요.
  • 교차 테이블 제한: 표현식은 다른 테이블의 기본 테이블 컬럼이나 관련 없는 논리 테이블의 표현식을 참조할 수 없어요. 예를 들어 customer.customer_name은 그들 사이에 관계가 없으면 orders 테이블의 표현식을 직접 참조할 수 없어요. 테이블 간 데이터로 작업하려면 다음을 해야 해요:
    • 논리 테이블 간 관계를 정의해요(예: c_custkey를 통한 customer와 orders 사이).
    • 소스 테이블에 fact를 정의해요(예: orders.total_value).
    • 연결된 논리 테이블에서 이 표현식들을 참조해요(예: customer.order_value가 orders.total_value를 참조할 수 있음).
  • 이름 해석(Name resolution): 시맨틱 표현식과 컬럼이 같은 이름을 가지면, 그 이름에 대한 참조는 시맨틱 표현식으로 해석돼요. 예를 들어 region dimension을 정의하고 region 컬럼도 있다면, 표현식에서 region은 컬럼이 아니라 dimension으로 해석돼요. 예외는 표현식이 정의에서 같은 이름을 참조할 때예요(예: customer.c_name AS customers.c_name). 이 경우 참조는 정의하는 표현식 자체가 아니라 컬럼으로 해석돼요.
  • 표현식 참조 순환 금지: 표현식 간에 순환 참조를 만들 수 없어요. 예를 들어 customer.total_value를 orders.customer_value를 기반으로 정의한 다음 orders.customer_value를 customer.total_value를 기반으로 정의할 수 없어요.
  • 테이블 참조 순환 금지: 표현식 정의에서 논리 테이블 간 순환 참조를 만들 수 없어요. 예를 들어 customer.total_value를 orders.customer_value를 기반으로 정의한 다음 orders.customer_count를 customer.c_custkey를 기반으로 정의할 수 없어요.
  • 함수 사용: dimension에서 YEAR* / DAY* / WEEK* / MONTH / QUARTER 같은 스칼라 함수를 사용할 수 있지만, 테이블 함수는 허용되지 않아요.

행 수준 표현식(차원과 fact) 규칙

다음 규칙들은 dimension과 fact의 행 수준 표현식에 적용돼요:

  • 같은 테이블 참조: 행 수준 표현식은 자체 테이블의 컬럼을 직접 참조할 수 있어요. 예를 들어 customers.customer_name은 customers.c_name으로 직접 정의할 수 있어요.
  • 같거나 더 낮은 세분성: 행 수준 표현식은 같거나 더 낮은 세분성의 다른 행 수준 표현식을 직접 참조할 수 있어요. 예를 들어 orders.order_details는 customer.customer_name을 참조할 수 있는데, customer가 orders보다 더 낮은 세분성이기 때문이에요(한 고객이 여러 주문을 가질 수 있음).
  • 더 높은 세분성 참조: 더 높은 세분성의 행 수준 표현식을 참조할 때 행 수준 표현식은 집계를 사용해야 해요. 예를 들어 customer.total_orders는 COUNT(orders.o_orderkey)를 사용해야 하는데, orders가 customer보다 더 높은 세분성이기 때문이에요(한 고객이 여러 주문을 가질 수 있음).
  • 집계 참조: orders.order_type 같은 dimension은 orders.order_average_value 같은 metric을 참조할 수 없지만, customer.customer_segment는 customer가 orders보다 더 낮은 세분성이므로 orders.order_average_value를 참조할 수 있어요.

집계 수준 표현식(메트릭) 규칙

다음 규칙들은 metric의 집계 수준 표현식에 적용돼요:

  • 기본 집계: 파생 메트릭(derived metric)이 아닌 metric은 집계 함수를 사용해야 해요. 예를 들어 orders.order_average_value는 AVG(orders.o_totalprice)를 사용해야 해요.
  • 같거나 더 낮은 세분성: 같거나 더 낮은 세분성의 행 수준 표현식을 참조할 때 metric은 단일 집계를 사용해야 해요. 예를 들어 orders.total_value는 SUM(line_items.discounted_price)를 사용할 수 있는데, line_items가 orders보다 더 낮은 세분성이기 때문이에요.
  • 더 높은 세분성 참조: 더 높은 세분성의 행 수준 표현식을 참조할 때 metric은 중첩 집계를 사용해야 해요. 예를 들어 customer.average_order_value는 AVG(SUM(orders.o_totalprice))를 사용해야 하는데, orders가 customer보다 더 높은 세분성이기 때문이에요.
  • 다른 집계 참조: metric은 집계 없이 같거나 더 낮은 세분성의 다른 metric을 직접 참조할 수 있어요. 예를 들어 orders.profit_margin은 추가 집계 없이 orders.total_revenue / orders.total_cost로 정의할 수 있어요. 단, 더 높은 세분성의 metric을 참조할 때는 집계가 필요해요.

윈도우 함수 메트릭 규칙

다음 규칙들은 윈도우 함수 메트릭에 적용돼요:

  • 윈도우 함수 메트릭은 행 수준 계산(fact와 dimension)에서 사용할 수 없어요.
  • 윈도우 함수 메트릭은 다른 metric의 정의에 사용할 수 없어요.

더 알아보기 (Learn more)