시맨틱 뷰 작성 방식: YAML vs DDL
시맨틱 뷰 작성 방식: YAML vs DDL
시맨틱 뷰는 SQL DDL 문, YAML 사양, 또는 Snowsight 마법사의 세 가지 방식으로 작성할 수 있어요. 이 페이지는 DDL과 YAML 방식을 비교해 여러분의 워크플로우에 맞는 방식을 고르도록 도와줘요. Snowsight 마법사에 대한 정보는 Semantic View Autopilot을 참고해요.
출처: Snowflake 문서
본문
시맨틱 뷰는 SQL DDL 문, YAML 사양, 또는 Snowsight 마법사의 세 가지 방식으로 작성할 수 있어요. 이 페이지는 DDL과 YAML 방식을 비교해 여러분의 워크플로우에 맞는 방식을 고르도록 도와줘요. Snowsight 마법사에 대한 정보는 Semantic View Autopilot을 참고해요.
YAML과 DDL은 거의 완전한 기능 동등성(feature parity)을 가져요. 두 형식 모두 Snowflake에 동일한 시맨틱 뷰 객체를 만들어요. YAML에는 DDL에 없는 몇 가지 기능(예: time_dimensions, 독립형 filters)이 있고, DDL에는 YAML에 없는 몇 가지 기능(예: 교차 테이블 dimension 참조)이 있어요. 전체 매핑은 기능 비교를 참고해요.
언제 DDL을 사용할까요?
DDL(SQL)은 다음 경우에 좋은 선택이에요:
- 팀이 주로 SQL로 작업하고 SQL 구문에 익숙한 경우
- dbt 또는 Terraform을 통해 시맨틱 뷰를 배포하는 경우 — 둘 다 DDL 구문을 사용해요.
- JDBC, ODBC 또는 SQL API를 통한 프로그래밍 방식 생성이 필요한 경우
전체 DDL 구문 참조는 CREATE SEMANTIC VIEW를, 단계별 지침과 예시는 Using SQL commands to create and manage semantic views을 참고해요.
언제 YAML을 사용할까요?
YAML은 다음 경우에 좋은 선택이에요:
- 많은 테이블과 컬럼이 있는 복잡한 시맨틱 뷰를 정의할 때 간결하고 읽기 쉬운 형식을 선호하는 경우
- 이미 YAML 형식인 기존 스테이지 기반 시맨틱 모델에서 마이그레이션하는 경우
- CI/CD 파이프라인이 YAML 구성 파일 중심으로 구축된 경우
- 풀 리퀘스트와 diff에서 쉽게 검토할 수 있는 형식을 원하는 경우
전체 YAML 사양은 YAML specification for semantic views을 참고해요.
기능 비교
다음 표는 YAML과 DDL 전반에 걸친 모든 모델링 기능을 종합적으로 매핑한 것이에요. 두 형식 모두 동일한 시맨틱 뷰 객체를 만들어요. 구문이 다른 곳에서는 YAML과 DDL 규칙을 표에 명시했어요.
| 기능 | YAML | DDL | 비고 |
|---|---|---|---|
| 기본 키가 있는 테이블 | 예 (primary_key.columns) |
예 (PRIMARY KEY (...)) |
YAML은 구조화 객체를 사용하고 DDL은 테이블 정의의 절(clause)을 사용해요. |
| SQL 쿼리를 논리 테이블로 | 예 (base_table.definition: <sql_query>) |
예 (<alias> AS ( <query> )) |
둘 다 물리적 테이블 대신 SQL 쿼리 사용을 지원해요. Using a SQL query as a logical table 참고. |
| 고유 키 | 예 (unique_keys) |
예 (UNIQUE (...)) |
둘 다 테이블 수준의 복합 고유 키를 지원해요. |
| 차원(직접 및 계산) | 예 | 예 | YAML은 expr을, DDL은 AS <sql_expr>을 사용해요. DDL은 표현식에서 데이터 타입을 유추해요. |
| 시간 차원 | 예 (time_dimensions) |
아니요 (DIMENSIONS 사용) |
YAML 전용. 날짜/타임스탬프 컬럼을 위한 별도 범주예요. DDL은 일반 dimension으로 선언해요. |
| Fact | 예 | 예 | 둘 다 직접 컬럼 참조, 계산 표현식, 집계 표현식(사전 집계 fact)을 지원해요. |
| 메트릭(테이블 범위) | 예 | 예 (<table>.<metric> AS <agg_expr>) |
동일해요. |
| 파생 메트릭(뷰 범위) | 예 (모델 수준 metrics) |
예 (METRICS에서 테이블 접두사 없음) |
둘 다 엔티티 범위 및 교차 엔티티 파생 메트릭을 지원해요. |
| 윈도우 함수 메트릭 | 예 (expr에서) |
예 (PARTITION BY EXCLUDING 전체 구문) |
둘 다 메트릭 표현식에서 윈도우 함수를 지원해요. DDL에는 명시적 PARTITION BY EXCLUDING 구문이 있어요. |
| 반가산(Semi-additive) 메트릭 | 예 (non_additive_dimensions) |
예 (NON ADDITIVE BY (...)) |
YAML은 ascending/descending을, DDL은 ASC/DESC를 사용해요. DDL은 NON ADDITIVE ALIGNED BY도 지원해요. |
| 차원/fact의 윈도우 함수 | 예 (expr에서) |
예 | 둘 다 ROW_NUMBER, DENSE_RANK, LAG, LEAD 및 기타 윈도우 함수를 지원해요. |
| 설명/주석 | 예 (description) |
예 (COMMENT = '...') |
필드 이름은 다르지만 목적은 같아요. 모든 수준(뷰, 테이블, 차원, fact, 메트릭)에서 지원돼요. |
| 동의어 | 예 (synonyms) |
예 (WITH SYNONYMS = (...)) |
두 형식 모두 테이블, 차원, fact, 메트릭에서 지원돼요. |
| 샘플 값 | 예 (sample_values) |
예 (SAMPLE_VALUES (...)) |
둘 다 지원돼요. Cortex Analyst가 컬럼 값의 범위를 이해하는 데 도움을 줘요. |
| is_enum | 예 (is_enum: true) |
예 (IS_ENUM) |
샘플 값이 가능한 값의 완전한 집합을 나타냄을 표시해요. dimension에서만 유효해요. |
| 필터(독립형) | 예 (filters) |
아니요 | YAML 전용. 테이블 수준의 독립형 필터 표현식이에요. Cortex Analyst가 사용하지만 시맨틱 SQL 컴파일러는 사용하지 않아요. |
| 필터(엔티티 수준) | 예 (labels: [filter]) |
예 (LABELS = (FILTER)) |
두 형식 모두에서 권장되는 방식이에요. dimension이나 fact에 필터 동작을 연결해요. |
| Cortex Search Service | 예 (cortex_search_service) |
예 (WITH CORTEX SEARCH SERVICE) |
YAML은 구조화된 하위 필드(service, literal_column, database, schema)를 사용하고 DDL은 한정된 이름을 사용해요. |
| 검증 쿼리 | 예 (verified_queries) |
예 (AI_VERIFIED_QUERIES (...)) |
verified_by는 두 형식 모두 자유 텍스트 문자열이에요. |
| Custom instructions | 예 (module_custom_instructions) |
예 (AI_SQL_GENERATION, AI_QUESTION_CATEGORIZATION) |
둘 다 SQL 생성 및 질문 범주화 지침을 지원해요. YAML은 레거시 custom_instructions 필드도 지원해요. |
| 관계(기본) | 예 | 예 | 둘 다 이름 있는/없는 관계, 단일 컬럼/다중 컬럼 조인을 지원해요. |
| 일대일 관계 | 예 | 예 | 양쪽 모두 조인 컬럼이 기본 키일 때 자동으로 유추돼요. |
| ASOF 관계 | 예 (type: asof) |
예 (ASOF) |
둘 다 느린 변화 차원(SDCD)에 대한 시점(point-in-time) 조회를 지원해요. |
| 범위 관계 | 예 (type: range, right_range) |
예 (BETWEEN ... AND ... EXCLUSIVE) |
둘 다 대상 테이블의 CONSTRAINT DISTINCT RANGE와 함께 범위 기반 조인을 지원해요. |
| 다대다(브리지 테이블 경유) | 예 | 예 | 브리지 테이블에서 나오는 두 관계로 표현돼요. 시스템이 M2M 경로를 유추해요. |
| 역할 재사용(Role-playing) 테이블 | 예 (같은 base_table의 여러 name 항목) | 예 (여러 별칭: alias1 AS table, alias2 AS table) |
둘 다 다른 역할을 위해 단일 물리적 테이블에 별칭을 부여하는 것을 지원해요. |
| 교차 테이블 dimension 참조 | 아니요 | 예 (. AS .) |
DDL 전용. 한 테이블의 dimension이 관련 테이블의 dimension을 참조할 수 있어요. |
| 특정 관계를 사용하는 메트릭 | 예 (using_relationships) |
예 (USING (...)) |
둘 다 메트릭이 사용할 관계 경로를 지정하는 것을 지원해요. |
| Access modifier(PUBLIC / PRIVATE) | 예 (access_modifier) |
예 (PUBLIC / PRIVATE 키워드) |
fact, metric, 파생 메트릭에서 지원돼요. dimension은 항상 public이에요. |
| 변수 | 예 (variables) |
예 (VARIABLES (...)) |
둘 다 타입이 있는 변수와 기본값이 있는 파라미터화된 시맨틱 뷰를 지원해요. |
| 객체 태깅 | 예 (tags) |
예 ([ WITH ] TAG (...)) |
뷰, 테이블, 차원, fact, 메트릭에서 지원돼요. |
| data_type | 예 (YAML에서 설정, 읽기 시 유추) | 아니요 | YAML 전용. YAML에서 data_type을 설정할 수 있지만, 읽기 경로에서 반환되는 값은 컴파일러가 유추한 값이에요. DDL은 항상 타입을 유추해요. |
| OR REPLACE / IF NOT EXISTS | 아니요 | 예 | DDL 전용. 표준 객체 생성 수정자(modifier)예요. |
| COPY GRANTS | 항상 적용됨(구성 불가) | 예(선택 절) | YAML은 뷰를 교체할 때 권한을 항상 보존해요. DDL은 명시적인 COPY GRANTS 절이 필요해요. |
형식 간 변환하기
DDL과 YAML은 언제든 변환할 수 있어요:
- YAML → 시맨틱 뷰: SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML 저장 프로시저를 사용해요. 세 번째 인자로
TRUE를 전달하면 뷰를 만들지 않고 YAML을 검증할 수 있어요. - Apache Ossie(incubating) YAML → 시맨틱 뷰: SYSTEM$CREATE_SEMANTIC_VIEW_FROM_OSSIE_YAML 저장 프로시저를 사용해 Apache Ossie(incubating) YAML 문서에서 시맨틱 뷰를 만들어요.
- 시맨틱 뷰 → YAML: SYSTEM$READ_YAML_FROM_SEMANTIC_VIEW 함수를 사용해 기존 시맨틱 뷰를 YAML로 내보내요.
- 시맨틱 뷰 → Apache Ossie(incubating) YAML: SYSTEM$READ_OSSIE_YAML_FROM_SEMANTIC_VIEW 함수를 사용해 기존 시맨틱 뷰를 Ossie YAML 형식으로 내보내요.
- 시맨틱 뷰 → DDL: GET_DDL 함수를 사용해 기존 시맨틱 뷰의 SQL 정의를 내보내요.
이 저장 프로시저와 함수는 형식 간 왕복(round-tripping)을 지원해요. 이는 버전 관리, CI/CD 파이프라인, 그리고 환경 간 정의 마이그레이션에 유용해요.