시맨틱 뷰 개발 및 배포 모범 사례

시맨틱 뷰 개발 및 배포 모범 사례

이 섹션은 시맨틱 뷰 를 포함하는 데이터 파이프라인과 데이터 제품의 개발을 위한 모범 사례를 설명합니다. 이러한 권장 사항은 주로 다음 개발 프로세스에 도움이 필요한 데이터 엔지니어링 및 데이터 과학 전문가를 위한 것입니다.

참고

이 섹션은 시맨틱 뷰의 모델링(설계, 설명, 지표, 관계, 정확도) 모범 사례를 다루지 않습니다. 그 지침은 시맨틱 뷰 모델링 모범 사례 를 참고하세요. 이 섹션의 정보는 Snowflake 시맨틱 뷰가 반복적으로 설계되고 데이터 엔지니어링 파이프라인 또는 데이터 제품의 일부로 관리되어야 한다고 가정합니다.

출처: Snowflake 문서

본문

소유권 및 데이터 접근

시맨틱 뷰는 여러 표준 데이터 소스에 존재하는 정보에 대한 접근을 용이하게 합니다. 시맨틱 레이어는 특정 데이터 소스를 쿼리하는 방법에 대해 생각하는 것에서, 사용 가능한 데이터의 통합된 관점이 지원하는 사용 사례와 비즈니스 질문에 집중하는 것으로 전환할 수 있게 합니다. 이러한 전반적인 목표를 염두에 두고 데이터 엔지니어링 팀과 비즈니스 팀은 긴밀하게 협력해야 합니다. 비즈니스 팀은 비즈니스 사례에 대한 전문성이 있고, 데이터 엔지니어링 팀은 테이블과 뷰에서 데이터에 접근하는 방법을 이해합니다. 두 팀 모두 시맨틱 모델의 소유권을 공유해야 합니다.

두 팀의 요구를 모두 충족하는 방식으로 시맨틱 레이어를 보호하려면 역할 기반 액세스 제어(RBAC)를 사용해 시맨틱 뷰와 그 종속 객체에 적절한 권한을 부여하세요. 처음부터 시작한다면 다음 섹션의 일련의 GRANT 문을 작업 템플릿으로 사용할 수 있습니다. 그러나 팀 구성원이 개발, 테스트, 프로덕션 환경을 위해 이미 특정한 방식으로 권한을 설정했다면, 일부 변경을 하거나 필요에 따라 다른 역할을 사용하도록 안내해야 할 수 있습니다.

시맨틱 뷰 객체에 권한 부여

적절한 권한이 필요한 네 가지 주요 객체 유형이 있습니다.

  • 시맨틱 뷰 자체
  • 시맨틱 뷰 정의에 사용되는 테이블
  • 시맨틱 뷰 정의에 사용되는 뷰
  • Cortex Search Service 객체 (일반적으로 뷰와 테이블 내의 범주형 데이터에 적용)

주어진 도메인에 대한 권한을 단순화하기 위해 Snowflake는 동일한 데이터베이스 스키마 내에서 객체를 만드는 것을 권장합니다. 그런 다음 특정 커스텀 역할을 사용해 그 객체 집합에 대한 최종 사용자 접근을 부여할 수 있습니다. 예를 들어 "Sales Analysis" Cortex Agent의 경우 sales 데이터베이스 내에 sales_analysis 스키마를 만들고 에이전트에 필요한 시맨틱 뷰와 다른 데이터에 대한 접근을 부여하기 위한 역할(예: snowflake_intelligence_sales_analysis_role)을 만들 수 있습니다. 스키마와 역할이 준비되면 향후 객체에 대한 권한을 이 역할에 부여해야 합니다.

다음 명령은 이 접근 방식을 보여줍니다.

-- Set variables for the specified role, database, and schema
SET my_role = 'snowflake_intelligence_sales_analysis_role';
SET my_db = 'sales';
SET my_schema = 'sales_analysis';
SET my_full_schema = $my_db || '.' || $my_schema;

-- Grant usage on the database and schema that will contain the tables and views
GRANT USAGE ON DATABASE IDENTIFIER($my_db) TO ROLE IDENTIFIER($my_role);
GRANT USAGE ON SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);

-- Grant privileges on future objects within the schema
-- For tables and views, SELECT is the typical "usage" grant for read access
GRANT SELECT ON FUTURE TABLES IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT SELECT ON FUTURE VIEWS IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT SELECT ON FUTURE SEMANTIC VIEWS IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);

-- For other object types, USAGE is the correct privilege
GRANT USAGE ON FUTURE FUNCTIONS IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT USAGE ON FUTURE PROCEDURES IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT USAGE ON FUTURE STAGES IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT USAGE ON FUTURE CORTEX SEARCH SERVICES IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);

예시에는 사용자가 시맨틱 뷰에 더해 기본 데이터 객체에 직접 접근해야 할 수 있는 시나리오를 지원하기 위한 future tables 및 views에 대한 권한이 포함됩니다. 시맨틱 뷰를 쿼리하는 것은 시맨틱 뷰 자체에 대한 SELECT 권한만 필요하지만, 테이블과 뷰에 대한 접근을 부여하면 기본 데이터를 시맨틱 레이어 밖에서 직접 쿼리하거나 분석해야 할 수 있는 사용자에게 유연성을 보장합니다. 사용자를 시맨틱 뷰로 엄격히 제한하려면 테이블과 뷰에 대한 권한을 생략하고 시맨틱 뷰 객체에 대한 권한만 부여할 수 있습니다. 그러나 시맨틱 뷰를 사용하는 Cortex Agents는 쿼리를 실행하는 역할이 시맨틱 뷰와 그 기본 테이블 모두에 대한 SELECT 권한을 가질 것을 요구한다는 점에 유의하세요.

권한을 설정하는 과정에서 다음 추가 사항을 염두에 두세요.

  • 최종 데이터가 이미 최종 사용자에게 올바르게 공유되어 있다면 그대로 진행할 수 있습니다. 그러나 Snowflake 데이터가 일반적으로 서비스 계정이나 BI 레이어를 통해 공유되어 왔다면 기본 데이터를 최종 사용자와 공유하기 위한 추가 단계가 필요합니다.
  • 시맨틱 뷰는 Snowflake의 새로운 객체 유형이므로, 대부분의 역할 유형에는 이 뷰에 대한 기본 또는 상속된 읽기/쓰기 접근 권한이 없습니다. 기본 데이터 공유 방식과 무관하게 핵심 Snowflake 관리 팀과 협력해 이 새로운 객체 유형에 대한 접근을 제공하세요.
  • Snowflake CoWork의 이점(그리고 그곳의 에이전트 기능 확장 가능성)을 위해 스테이지, 프로시저, 함수에 USAGE 권한을 부여할 가치가 있습니다(예시에 표시된 대로). 이러한 객체를 사용해 Snowflake CoWork 내에서 커스텀 도구를 만들 수 있습니다.
  • CREATE SEMANTIC VIEW는 Snowsight에서 시맨틱 뷰를 만들거나 편집하는 모든 사용자에게 필요한 스키마 수준 권한입니다.

마스킹 정책 및 행 액세스 정책으로 접근 제한

시맨틱 뷰는 소유자 권한(owner's rights) 을 사용합니다. 즉, 시맨틱 뷰에 접근할 수 있는 사용자는 그 기본 테이블에 대한 별도 접근이 필요하지 않으며, 뷰의 소유자(역할)가 접근을 제어합니다. 사용자가 시맨틱 뷰 객체 자체에 대한 SELECT 권한만 있으면 기본 데이터를 볼 권한은 필요하지 않습니다. 이 동작은 표준 뷰를 쿼리하는 데 필요한 권한 과 일관됩니다.

시맨틱 뷰와 Cortex Agents의 기본 데이터에 따라, 커스텀 역할을 통해 권한이 부여되었더라도 모든 최종 사용자가 그 데이터 전체에 무제한 접근하는 것을 원하지 않을 수 있습니다. Dynamic Data Masking 정책 및 행 액세스 정책 을 사용해 기본 데이터에 대한 접근을 행 수준에서 제어할 수 있습니다. 이러한 정책은 시맨틱 뷰 속성에 직접 설정할 수 없지만, 기본 테이블과 열에 설정되면 시맨틱 뷰로 전파되어 적용됩니다. 이것은 민감한 데이터로 작업하는 애플리케이션에 대한 보안 이점입니다. 그러나 메타데이터로 저장되는 샘플 값은 마스킹되지 않습니다. 샘플 값은 마스킹되지 않습니다 참고.

예를 들어 행 액세스 정책과 마스킹 정책을 만들어 account_semantic_view라는 시맨틱 뷰의 기본인 accounts 테이블에 모두 적용할 수 있습니다. 이 예시에서 행은 시맨틱 뷰를 쿼리하는 사용자의 이메일이 승인된 계정과 일치할 때만 표시됩니다. 둘째로, 민감한 열(sensitive_col)은 시맨틱 뷰를 통해서도 권한 없는 역할에 대해 동적으로 마스킹됩니다.

-- Row access policy (restricts rows by user email)
CREATE OR REPLACE ROW ACCESS POLICY my_schema.account_row_policy AS (user_email STRING)
  RETURNS BOOLEAN ->
    EXISTS (
      SELECT 1
      FROM my_schema.account_access_list
      WHERE email = user_email()
    );

-- Masking policy (masks "sensitive_col" for users without a privileged role)
CREATE OR REPLACE MASKING POLICY my_schema.sensitive_col_masking_policy AS (val STRING)
RETURNS STRING ->
  CASE
    WHEN current_role() IN ('SENSITIVE_DATA_ACCESS_ROLE') THEN val
    ELSE 'MASKED'
  END;

-- Attach row access policy to the user_email column in the accounts table
ALTER TABLE my_schema.accounts
  ADD ROW ACCESS POLICY account_row_policy ON (user_email);

-- Attach masking policy to the sensitive_col column
ALTER TABLE my_schema.accounts
  MODIFY COLUMN sensitive_col
  SET MASKING POLICY sensitive_col_masking_policy;

-- Create the semantic view on the "accounts" table
CREATE OR REPLACE SEMANTIC VIEW my_schema.account_semantic_view
  TABLES (
    accounts AS my_schema.accounts
    PRIMARY KEY (account_id)
  )
  FACTS (
    account_id AS accounts.account_id,
    account_name AS accounts.account_name
  )
  DIMENSIONS (
    user_email AS accounts.user_email,
    sensitive_col AS accounts.sensitive_col
);

dbt를 사용한다면 post-hook 에서 이러한 정책을 적용할 수 있습니다. 예를 들어:

models:
- name: accounts
  description: "Table of accounts for semantic analytics."
  columns:
    - name: account_id
      description: "Unique identifier for the account."
    - name: account_name
      description: "Name of the account."
    - name: user_email
      description: "Email address linked to each account row."
    - name: sensitive_col
      description: "Sensitive information to be masked for non-privileged users."
  post-hook:
    - >
      ALTER TABLE {{ this }}
        ADD ROW ACCESS POLICY account_row_policy ON (user_email);
  ...

ALTER TABLE {{ this }} 코드는 정규화된 테이블 이름에 dbt 런타임 변수를 사용합니다. dbt가 accounts 테이블을 빌드하거나 업데이트할 때마다 정책이 적용됩니다.

샘플 값은 마스킹되지 않습니다

마스킹 정책이 적용된 시맨틱 뷰를 쿼리할 수 있는 사용자가 쿼리 결과에서 실제 데이터 값을 볼 수는 없지만, Snowsight에서 정의된 샘플 값은 마스킹 정책이 메타데이터에 적용되지 않으므로 마스킹되지 않습니다. 차원에 대해 샘플 값이 정의된 시맨틱 뷰에서 GET_DDL 함수를 실행하는 사용자는 그 정확한 값을 볼 수 있습니다. 예를 들어 다음 DDL의 WITH EXTENSION 절의 값을 살펴보세요.

SELECT GET_DDL('SEMANTIC_VIEW','TEST_SAMPLE_VALUES');

create or replace semantic view TEST_SAMPLE_VALUES
tables (MARCH_TEMPS
  ...)
facts (MARCH_TEMPS.TEMPERATURE as TEMPERATURE
  ...)
dimensions (MARCH_TEMPS.CITY as CITY,
MARCH_TEMPS.COUNTY as COUNTY,
MARCH_TEMPS.OBSERVED as OBSERVED)
  ...
with extension (CA='{"tables":[{"name":"MARCH_TEMPS","dimensions":[{"name":"CITY","sample_values":["South Lake Tahoe","Big Bear City"]},{"name":"COUNTY","sample_values":["San Bernardino","El Dorado"]}],"facts":[{"name":"TEMPERATURE","sample_values":["44","46","52"]}],"time_dimensions":[{"name":"OBSERVED","sample_values":["2025-03-15T09:50:00.000+0000","2025-03-15T09:55:00.000+0000","2025-03-15T10:10:00.000+0000"]}]}
...);

필요하다면 시맨틱 뷰를 만들 때 실제 값 대신 대표적인 비민감 샘플 값을 제공할 수 있습니다. Cortex Agents는 실값을 대표하는 어떤 값이든 열의 내용을 결정하는 데 사용할 수 있습니다.

시맨틱 뷰 생성, 업데이트, 쿼리 옵션

Snowflake에서 YAML 파일을 작성하거나, Snowflake DDL 구문을 사용하거나, Snowsight의 UI를 사용해 시맨틱 뷰를 작성할 수 있습니다. Snowflake는 YAML 모델 가져오기와 시맨틱 뷰를 YAML 모델로 내보내기 모두에 편리한 함수를 제공합니다. 자세한 내용은 YAML 시맨틱 모델을 네이티브 시맨틱 뷰로 변환 을 참고하세요.

일반적으로 (시맨틱 모델보다는) 시맨틱 뷰를 먼저 만드는 것이 좋습니다. 시맨틱 뷰는 RBAC, 사용 통계, Cortex Agents 및 Snowflake CoWork을 포함한 다른 Snowflake 기능과의 직접 통합의 이점을 누리는 Snowflake 메타데이터 객체입니다.

시맨틱 뷰를 만들려면 세 가지 주요 옵션이 있습니다.

  • Snowsight에서 시맨틱 뷰 만들기:

마법사를 사용하거나 YAML 스펙을 업로드할 수 있습니다.

  • 마법사 방식은 초기 설정에 권장되며, 동의어, 샘플 값, 열 설명의 자동 생성이 포함됩니다. 지침은 Semantic View Autopilot 을 참고하세요.

  • SQL을 지원하는 인터페이스를 사용해 SQL CREATE OR REPLACE SEMANTIC VIEW 문으로 시맨틱 뷰 만들기. 지침은 SQL 명령으로 시맨틱 뷰 생성 및 관리 를 참고하세요.

프로그래밍 방식 생성과 쿼리는 JDBC 및 ODBC 드라이버나 SQL API 같은 인터페이스를 통해 가능합니다. 그러나 Snowflake REST APIs 는 사용할 수 없습니다.

또한 dbt를 사용한다면 dbt_semantic_view 패키지를 설치해 Snowflake에서 시맨틱 뷰 생성을 구성할 수 있습니다. 자세한 내용은 dbt 프로젝트와의 통합 을 참고하세요.

팀 구성원에 대한 역할과 권한 설정이 시맨틱 뷰를 만드는 능력에 영향을 줄 수 있다는 점을 명심하세요. 예를 들어 프로덕션 환경이 SERVICE 사용자로 실행되도록 요구한다면 그 환경에서 Snowsight에 로그인할 수 없으므로 SQL 명령을 사용해 시맨틱 뷰를 만들고 관리해야 합니다.

시맨틱 뷰가 Snowflake 데이터베이스에 생성되면 관리자는 표준 SHOW 및 DESCRIBE 명령을 사용해 관리할 수 있고, 사용자는 다운스트림에서 SQL SELECT 문 으로 그리고 다음 방식으로 접근할 수 있습니다.

주석을 제외하고 기존 시맨틱 뷰 내에서 테이블, 열, 메타데이터를 추가하거나 변경할 수 없으므로, 변경 사항을 통합하려면 (CREATE OR REPLACE 명령으로) 이를 다시 만들어야 합니다. 또한 SQL 명령으로 시맨틱 뷰를 업데이트하면 활성 Snowsight 세션에서 만든 수동 편집을 덮어씁니다. 두 세트의 변경을 보존하는 것은 지원되지 않습니다.

YAML 시맨틱 모델을 네이티브 시맨틱 뷰로 변환

SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML 저장 프로시저를 사용해 기존 스테이지 기반 시맨틱 모델 YAML 파일을 네이티브 시맨틱 뷰로 변환할 수 있습니다. 시맨틱 뷰를 YAML로 다시 내보내려면 SYSTEM$READ_YAML_FROM_SEMANTIC_VIEW 함수를 사용하세요.

레거시 스테이지 기반 YAML 접근 방식에서 마이그레이션한다면 레거시 스테이지 API에서 마이그레이션 을 참고하세요. 작성 형식으로 YAML과 DDL 중 선택하는 지침은 YAML vs DDL 작성 을 참고하세요.

참고

Snowflake는 시맨틱 모델의 일괄 변환을 지원하지 않습니다. YAML 파일을 시맨틱 뷰로 하나씩 변환해야 합니다. 일괄 변환이나 CI/CD 통합이 필요하면 변환을 일련의 스크립트로 구성하세요.

시맨틱 뷰 자동 배포

가능한 곳이면 CI/CD 파이프라인과 프로그래밍 인터페이스를 활용해 시맨틱 뷰를 만들고, 수정하고, 관리하세요. 이상적으로는 시맨틱 뷰 업데이트가 Git 저장소와 자동으로 동기화되도록 워크플로우를 설정하세요. 이 접근 방식은 복사-붙여넣기나 Git에 변경을 푸시할 때 발생할 수 있는 수동 오류를 줄입니다.

  • 시맨틱 뷰 YAML(또는 SQL DDL)을 Git 저장소에 저장하세요. 이 접근 방식은 버전 관리, 동료 검토, 기록, 롤백을 지원합니다.
  • Snowsight를 사용한다면 YAML 모델을 정기적으로 내보내거나 다운로드해 Git에 커밋하세요.
  • Git 변경 시 CI/CD 파이프라인을 트리거해 테스트와 정확도 검사를 실행하고, 테스트가 통과할 때만 배포하세요.
  • 필요한 경우 Git에서 이전의 알려진 우수(known-good) YAML 또는 DDL을 재배포해 롤백하세요.

모델을 dev에서 test 또는 production 환경으로 승격하려면 이를 위한 자동 배포 스크립트를 통합하거나 스키마 수준 복제(schema-level cloning) 를 사용할 수 있습니다. 시맨틱 뷰는 포함된 스키마가 복제될 때 복제됩니다. 복제는 같은 Snowflake 계정을 사용하는 데이터베이스와 환경 간에 시맨틱 뷰를 승격하는 좋은 옵션입니다. 계정 간에 시맨틱 뷰를 승격하려면 계정 복제(account replication) 를 사용할 수 있습니다.

시맨틱 뷰는 Snowflake Marketplace 와 데이터 공유 를 통해 직접 공유할 수 있습니다. 시맨틱 뷰를 기반으로 보안 뷰(secure views) 를 만들 수 있으며, 이러한 중첩 뷰의 공유는 지원됩니다. 그러나 일부 재공유 시나리오에는 제한이 있습니다(예: 공유 소비자가 시맨틱 뷰를 기반으로 구축된 뷰를 추가로 공유하려는 경우).

시맨틱 뷰를 Snowflake 데이터 파이프라인의 일부로 구체화하고 유지 관리하도록 지원하기 위해 dbt 프로젝트를 사용할 수 있습니다. dbt 프로젝트와의 통합 을 참고하세요. Snowflake Terraform provider 를 사용한 유사한 프로세스에 대한 지원이 계획되어 있습니다.

궁극적으로 목표는 다음 dbt 예시와 유사한 워크플로우를 가능하게 하는 것입니다.

  • VS Code 같은 IDE에서 dbt 프로젝트 변경 작업.
  • dbt 코드에 새 시맨틱 뷰 정의 추가.
  • 변경을 Git에 푸시.
  • 데이터 파이프라인의 일부로 dbt run 작업을 하는 트리거 설정.

결과적으로 시맨틱 뷰가 Snowflake 계정에 구체화됩니다.

dbt 프로젝트와의 통합

Snowflake Labs에서 제공하는 dbt_semantic_view 패키지를 설치해 시맨틱 뷰를 dbt 워크플로우에 통합할 수 있습니다: https://hub.getdbt.com/Snowflake-Labs/dbt_semantic_view/latest/.

이 패키지는 Snowflake의 dbt 프로젝트 또는 Snowflake 계정에 접근할 수 있는 모든 dbt 설치에서 네이티브로 작동합니다. 이 패키지를 사용해 dbt로 시맨틱 뷰를 구체화하고 다운스트림 모델에서 참조할 수 있습니다.

참고

Snowflake Labs의 코드 샘플은 참조, 테스트, 교육 목적입니다. 이러한 코드 샘플은 어떤 Service-Level Agreement에도 포함되지 않습니다.

다음 지침은 dbt에 익숙하고 Snowflake에 연결할 수 있는 환경에 이미 dbt가 설치되어 있다고 가정합니다.

dbt_semantic_view 패키지를 설치하고 사용하려면:

  1. packages.yml 파일에 다음 코드를 추가하세요.
packages:
  - package: Snowflake-Labs/dbt_semantic_view
    version: 1.0.3

버전 번호를 지정하세요. 현재 버전을 찾으려면 dbt_semantic_view 패키지 페이지 를 참고하세요. 참고: dbt_semantic_view 패키지는 Snowflake SQL 레이어에 대한 직접 통과(direct passthrough)입니다. 새 Snowflake 시맨틱 뷰 기능에 접근하기 위해 패키지 버전을 업데이트할 필요가 없습니다. Snowflake가 새 SQL 기능(예: AI_VERIFIED_QUERIES)을 추가하면 패키지 업데이트 없이 패키지를 통해 즉시 사용할 수 있습니다.

  1. dbt deps 명령을 실행해 패키지를 설치하세요.
  2. dbt models 디렉터리에서 시맨틱 뷰 구체화 코드를 사용하는 모델을 만드세요.
{{ config(materialized='semantic_view') }}

TABLES(
{{ source('', '') }},
{{ ref('') }}
)
[ RELATIONSHIPS ( relationshipDef [ , ... ] ) ]
[ FACTS ( factExpression [ , ... ] ) ]
[ DIMENSIONS ( dimensionExpression [ , ... ] ) ]
[ METRICS ( metricExpression [ , ... ] ) ]
[ COMMENT = '' ]
[ COPY GRANTS ]

예를 들어 간단한 시맨틱 뷰를 다음과 같이 구체화할 수 있습니다.

{{ config(materialized='semantic_view') }}

TABLES(t1 AS {{ ref('base_table') }}, t2 as {{ source('seed_sources', 'base_table2') }})
DIMENSIONS(t1.count as value, t2.volume as value)
METRICS(t1.total_rows AS SUM(t1.count), t2.max_volume as max(t2.volume))
COMMENT='test semantic view'
  1. dbt profiles.yml 파일에 연결 세부 정보를 지정해 dbt에서 Snowflake에 대한 연결을 구성하세요. 자세한 내용은 dbt 문서 를 참고하세요. 예를 들어:
semantic_project:
  target: snowflake
  outputs:
    snowflake:
      type: "snowflake"
      account: "{{ env_var('SNOWFLAKE_ACCOUNT') }}"
      user: "{{ env_var('SNOWFLAKE_USER') }}"
      password: "{{ env_var('SNOWFLAKE_PASSWORD') }}"
      authenticator: "{{ env_var('SNOWFLAKE_AUTHENTICATOR') }}"
      role: "{{ env_var('SNOWFLAKE_ROLE') }}"
      database: "{{ env_var('SNOWFLAKE_DATABASE') }}"
      warehouse: "{{ env_var('SNOWFLAKE_WAREHOUSE') }}"
      schema: "{{ env_var('SNOWFLAKE_SCHEMA') }}"
      threads: 4
  1. 이 프로필이 주어지면 다음 환경 변수로 인증할 수 있습니다.
$ export SNOWFLAKE_ACCOUNT=snowflake_acct1
$ export SNOWFLAKE_USER=sem_user1
$ export SNOWFLAKE_PASSWORD=**************
$ export SNOWFLAKE_AUTHENTICATOR=externalbrowser
$ export SNOWFLAKE_ROLE=semantic_role
$ export SNOWFLAKE_DATABASE=sem_db
$ export SNOWFLAKE_WAREHOUSE=sem_wh
$ export SNOWFLAKE_SCHEMA=sem_schema
  1. dbt build 명령을 실행해 Snowflake 계정에 연결하고 모델을 생성하세요. 다음 예시는 models/semantic_view_basic으로 정의된 특정 모델을 빌드합니다. table_refer_to_semantic_view라는 또 다른 모델이 이 모델에 의존하므로 명령은 끝에 + 기호를 필요로 합니다.
$ dbt build --target snowflake --select semantic_view_basic+
23:43:16  Running with dbt=1.11.0-b3
23:43:17  Registered adapter: snowflake=1.10.2
23:43:17  Found 9 models, 8 data tests, 1 seed, 2 operations, 2 sources, 500 macros
23:43:17
23:43:17  Concurrency: 4 threads (target='snowflake')
23:43:17
23:43:32  1 of 2 START hook: dbt_semantic_view_integration_tests.on-run-start.0 .......... [RUN]
23:43:32  1 of 2 OK hook: dbt_semantic_view_integration_tests.on-run-start.0 ............. [OK in 0.90s]
23:43:33  2 of 2 START hook: dbt_semantic_view_integration_tests.on-run-start.1 .......... [RUN]
23:43:33  2 of 2 OK hook: dbt_semantic_view_integration_tests.on-run-start.1 ............. [OK in 0.38s]
23:43:33
23:43:33  1 of 6 START sql semantic_view model sem_schema.semantic_view_basic ............ [RUN]
23:43:33  1 of 6 OK created sql semantic_view model sem_schema.semantic_view_basic ....... [SUCCESS 1 in 0.26s]
23:43:33  3 of 6 START test semantic_view_basic_has_no_copy_grants ....................... [RUN]
23:43:33  2 of 6 START test semantic_view_basic_has_comment .............................. [RUN]
23:43:33  4 of 6 START test semantic_view_sum_matches_base_table ......................... [RUN]
23:43:33  2 of 6 PASS semantic_view_basic_has_comment .................................... [PASS in 0.23s]
23:43:34  3 of 6 PASS semantic_view_basic_has_no_copy_grants ............................. [PASS in 0.75s]
23:43:34  4 of 6 PASS semantic_view_sum_matches_base_table ............................... [PASS in 1.05s]
23:43:34  5 of 6 START sql table model sem_schema.table_refer_to_semantic_view ........... [RUN]
23:43:35  5 of 6 OK created sql table model sem_schema.table_refer_to_semantic_view ...... [SUCCESS 1 in 1.22s]
23:43:35  6 of 6 START test table_refer_semantic_view_matches_semantic_view .............. [RUN]
23:43:36  6 of 6 PASS table_refer_semantic_view_matches_semantic_view .................... [PASS in 0.26s]
23:43:36
23:43:36  Finished running 2 project hooks, 1 semantic view model, 1 table model, 4 data tests in 0 hours 0 minutes and 19.34 seconds (19.34s).
23:43:36
23:43:36  Completed successfully
23:43:36
23:43:36  Done. PASS=8 WARN=0 ERROR=0 SKIP=0 NO-OP=0 TOTAL=8

미리 빌드된 모델과 실행할 수 있는 테스트를 포함한 dbt_semantic_view 패키지에 대한 자세한 내용은 README.md 파일을 참고하세요. https://hub.getdbt.com/Snowflake-Labs/dbt_semantic_view/latest/ 로 이동해 View on GitHub를 선택하세요.

또한 https://www.snowflake.com/en/engineering-blog/dbt-semantic-view-package/ 를 참고하세요.

BI 도구와의 통합

많은 BI 도구 공급업체가 Snowflake 시맨틱 뷰와의 통합을 제공합니다. 이러한 통합에 대해 자세히 알아보려면 BI 도구 계정 팀에 문의하고 다음 링크를 따르세요.

더 알아보기 (Learn more)