의미 체계 뷰의 모범 사례¶

소유권 및 데이터 액세스¶

의미 체계 뷰는 여러 표준 데이터 소스에 있는 정보에 쉽게 액세스할 수 있게 해줍니다. 의미 체계 계층은 특정 데이터 소스를 쿼리하는 방법에서, 사용 가능한 데이터에 대한 통합 뷰를 통해 지원되는 사용 사례 및 비즈니스 질문에 초점을 맞추는 방식으로 사고를 전환할 수 있게 해줍니다. 이러한 전반적인 목표를 염두에 두고, 데이터 엔지니어링 팀과 비즈니스 팀은 긴밀하게 협력해야 합니다. 비즈니스 팀은 비즈니스 사례에 대한 전문 지식을 가지고 있지만, 데이터 엔지니어링 팀은 테이블과 뷰에서 데이터에 액세스하는 방법을 이해하고 있습니다. 두 팀은 모두 의미 체계 모델의 소유권을 공유해야 합니다.

두 팀의 요구 사항을 충족하는 방식으로 의미 체계 계층을 보호하기 위해, RBAC(역할 기반 액세스 제어)를 사용하여 의미 체계 뷰와 종속 오브젝트에 적절한 권한을 부여합니다. 처음부터 새로 시작하는 경우, 다음 섹션의 GRANT 문 시퀀스를 작업 템플릿으로 사용할 수 있습니다. 하지만 팀 구성원이 개발, 테스트 및 프로덕션 환경에 대해 특정 방식으로 권한을 이미 설정한 경우, 일부를 변경하거나 필요에 따라 다른 역할을 사용하도록 지시해야 할 수 있습니다.

-- 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);

-- 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);

-- 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
);

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);
  ...

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"]}]}
...);

의미 체계 뷰 생성, 업데이트, 쿼리 옵션¶

Snowflake DDL 구문을 사용하거나 |sf-web-interface|에서 UI를 통해 YAML 파일을 작성하여 Snowflake에서 의미 체계 뷰를 작성할 수 있습니다. Snowflake에서는 YAML 모델을 가져오고 YAML 모델로 의미 체계 뷰를 내보내기 위한 편리한 기능을 제공합니다. 자세한 내용은 YAML 의미 체계 모델을 네이티브 의미 체계 뷰로 변환 섹션을 참조하십시오.

일반적으로, 먼저 RBAC, 사용 통계, Cortex Analyst 및 Snowflake Intelligence를 포함하는 다른 Snowflake 기능과의 직접 통합의 이점을 활용하는 Snowflake 메타데이터 오브젝트인 의미 체계 뷰(의미 체계 모델 아님)를 생성하는 것이 가장 좋습니다.

의미 체계 뷰를 생성하기 위한 세 가지 주요 옵션은 다음과 같습니다.

• |sf-web-interface|에서 의미 체계 뷰를 생성합니다.

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

  • 마법사 접근 방식은 초기 설정에 권장되며, 동의어, 샘플 값 및 열 설명의 자동 생성을 포함합니다. 자세한 지침은 |sf-web-interface|를 사용하여 의미 체계 뷰 생성 및 관리 섹션을 참조하십시오.

• SQL을 지원하는 모든 인터페이스를 사용하여, SQL CREATE OR REPLACE SEMANTIC VIEW 문을 통해 의미 체계 뷰를 생성합니다. 자세한 지침은 SQL 명령을 사용하여 의미 체계 뷰 생성하기 및 관리하기 섹션을 참조하십시오.

  JDBC 및 ODBC 드라이버 또는 SQL API</developer-guide/sql-api/index>`와 같은 인터페이스를 통해 프로그래밍 방식으로 생성 및 쿼리할 수 있습니다. 그러나 :doc:/developer-guide/snowflake-rest-api/snowflake-rest-api`를 사용할 수는 없습니다.

• SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML 저장 프로시저를 호출하여 SQL의 YAML 사양에서 의미 체계 뷰를 생성합니다. YAML 의미 체계 모델을 네이티브 의미 체계 뷰로 변환 섹션을 참조하십시오.

또한, dbt를 사용하는 경우, dbt_semantic_view 패키지를 설치하여 Snowflake에서 의미 체계 뷰 생성을 구성할 수 있습니다. 자세한 내용은 dbt 프로젝트와 통합 섹션을 참조하십시오.

팀 구성원의 역할 및 권한 설정은 의미 체계 뷰 생성 권한에 영향을 줄 수 있습니다. 예를 들어, 프로덕션 환경에서 SERVICE 사용자로 실행해야 하는 경우, 해당 환경에서 |sf-web-interface|에 로그인할 수 없고, 의미 체계 뷰를 생성하고 관리하는 SQL 명령을 사용해야 합니다.

Snowflake 데이터베이스에서 의미 체계 뷰가 생성될 때, 관리자는 표준 SHOW 및 DESCRIBE 명령을 사용하여 관리할 수 있고, 사용자는 SQL SELECT 문 및 다음과 같은 방법을 통해 다운스트림으로 액세스할 수 있습니다.

• Cortex Analyst 사용자 인터페이스를 통해 직접

• Streamlit 또는 Cortex Analyst API 및/또는 :doc:`generate SELECT FROM SEMANTIC_VIEW 문</user-guide/views-semantic/querying>`을 사용하는 기타 사용자 지정 애플리케이션을 통해

• Cortex Analyst를 통한 Cortex Agent를 통해(의미 체계 뷰는 새 또는 기존 :ref:`에이전트<label_snowflake_agents_modify_agents>`에 추가되어야 함)

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

YAML 의미 체계 모델을 네이티브 의미 체계 뷰로 변환¶

SQL 시스템 함수 및 저장 프로시저를 사용하여 YAML 모델에서 의미 체계 뷰를 생성하고 의미 체계 뷰에서 YAML 모델을 생성할 수 있습니다

현재, Snowflake는 대량 변환을 지원하지 않으므로, YAML 파일을 네이티브 의미 체계 뷰로 한 번에 하나씩 변환해야 합니다. 변환에 SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML 저장 프로시저를 사용할 수 있습니다. CI/CD 파이프라인으로 대량 변환 또는 통합이 필요한 경우, 일련의 변환을 스크립트해야 합니다. Snowflake에서는 가까운 시일 내에 일괄/대량 변환을 지원할 계획이 없습니다.

네이티브 의미 체계 뷰를 YAML로 다시 내보내기 위해 SYSTEM$READ_YAML_FROM_SEMANTIC_VIEW 함수를 사용할 수 있습니다. 이 함수를 사용하면 자동화된 후처리, 데이터 왕복 처리, 버전 관리 직렬화가 가능합니다.

크기와 관련된 동일한 실제 지침이 네이티브 의미 체계 뷰와 YAML 기반 모델에 모두 적용됩니다. 최상의 성능을 위해 의미 체계 뷰에는 모든 테이블에서 총 50~100개 이하의 열이 있어야 한다는 실제 지침(엄격한 제한은 아님)이 있습니다. 이 지침은 네이티브 의미 체계 뷰와 YAML 기반 모델에 적용되며 주로 Cortex Analyst와 같은 AI 구성 요소의 컨텍스트 윈도우 제한으로 인해 마련된 지침입니다. 이 권장 수량을 초과하면 대기 시간이나 품질 저하가 발생할 수 있지만, 이는 기술적으로 불가능한 것은 아닙니다.

의미 체계 뷰의 자동화된 배포¶

가능한 경우 CI/CD 파이프라인 및 프로그래밍 방식 인터페이스를 활용하여 의미 체계 뷰를 생성, 수정, 관리합니다. 의미 체계 뷰 업데이트가 Git 리포지토리와 자동으로 동기화되도록 워크플로를 설정하는 것이 이상적입니다. 이 접근 방식을 사용하면 변경 사항을 Git에 복사하여 붙여넣거나 푸시할 때 발생할 수 있는 수동 오류가 줄어듭니다.

• 의미 체계 뷰 YAML(또는 SQL DDL)를 Git 리포지토리에 저장합니다. 이 접근 방식은 버전 관리, 피어 검토, 기록 및 롤백을 지원합니다.

• |sf-web-interface|를 사용하는 경우 YAML 모델을 정기적으로 내보내거나 다운로드하고 Git에 커밋합니다.

• Git 변경 사항에 대해 CI/CD 파이프라인을 트리거합니다(테스트 및 정확도 검사를 실행한 다음, 이러한 테스트를 통과하는 경우에만 배포).

• 필요한 경우 Git에서 이전의 정상 작동이 확인된 YAML 또는 DDL을 다시 배포하여 롤백합니다.

개발 환경에서 테스트 또는 프로덕션 환경으로 모델을 승격하려면 해당 목적을 위해 자동화된 배포 스크립트를 통합하거나 :doc:`스키마 수준 복제</sql-reference/sql/create-clone>`를 사용할 수 있습니다. 의미 체계 뷰는 이를 포함하는 스키마가 복제될 때 복제됩니다. 의미 체계 뷰에 대해 복제가 아직 지원되지 않는다는 점을 감안할 때, 복제는 동일한 Snowflake 계정을 사용하는 데이터베이스와 환경 전체에서 의미 체계 뷰를 승격하기 위한 좋은 대안입니다.

의미 체계 뷰는 Snowflake Marketplace 및 :doc:`데이터 공유</guides-overview-sharing>`를 통해 직접 공유할 수 있습니다. 의미 체계 뷰를 기준으로 :doc:`보안 뷰</user-guide/views-secure>`를 생성하며, 이러한 중첩 뷰를 공유하는 기능이 지원됩니다. 그러나 일부 재공유 시나리오에는 제한 사항이 있습니다(예: 공유 컨슈머가 의미 체계 뷰를 기준으로 구축된 뷰를 추가로 공유하려는 경우).

Snowflake 데이터 파이프라인의 일부로 의미 체계 뷰의 구체화 및 유지 관리를 지원하려면 dbt 프로젝트를 사용할 수 있습니다. dbt 프로젝트와 통합 섹션을 참조하세요. :doc:`/user-guide/terraform`를 사용한 유사한 프로세스 지원이 계획되어 있습니다.

궁극적으로 목표는 다음 dbt 예와 유사한 워크플로를 활성화하는 것입니다.

• VS Code와 같은 IDE에서 dbt 프로젝트를 변경합니다.

• dbt 코드에 새 의미 체계 정의를 추가합니다.

• 변경 사항을 Git에 푸시합니다.

• 데이터 파이프라인의 일부로 'dbt run' 작업을 수행하는 트리거를 설정합니다.

결과적으로 의미 체계 뷰는 Snowflake 계정에서 구체화됩니다.

dbt 프로젝트와 통합¶

Snowflake Labs: https://hub.getdbt.com/Snowflake-Labs/dbt_semantic_view/latest/에 제공되는 dbt_semantic_view 패키지를 설치하여 의미 체계 뷰를 dbt 워크플로에 통합할 수 있습니다.

이 패키지는 기본적으로 Snowflake의 dbt 프로젝트 또는 Snowflake 계정에 액세스할 수 있는 모든 dbt 설치에서 작동합니다. 이 패키지를 사용하여 dbt를 통해 의미 체계 뷰를 구체화하고 다운스트림 모델에서 참조할 수 있습니다.

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

dbt_semantic_view 패키지를 설치하고 사용하려면 다음을 수행합니다.

1. 다음 줄을 packages.yml 파일에 추가합니다.

   packages:
     - package: Snowflake-Labs/dbt_semantic_view
       version: 1.0.3
   

   Copy

   버전 번호를 포함해야 합니다. 패키지의 버전 번호는 변경될 수 있습니다. 최신 버전을 사용하는 것이 좋습니다.

2. dbt deps 명령을 실행하여 패키지를 설치합니다.

3. dbt models 디렉터리에서 의미 체계 뷰 구체화 코드를 사용하는 모델을 만듭니다.

   {{ config(materialized='semantic_view') }}
   
   TABLES(
   {{ source('<source_name>', '<table_name>') }},
   {{ ref('<another_model>') }}
   )
   [ RELATIONSHIPS ( relationshipDef [ , ... ] ) ]
   [ FACTS ( semanticExpression [ , ... ] ) ]
   [ DIMENSIONS ( semanticExpression [ , ... ] ) ]
   [ METRICS ( semanticExpression [ , ... ] ) ]
   [ COMMENT = '<comment>' ]
   [ COPY GRANTS ]
   

   Copy

   예를 들어, 다음과 같이 간단한 의미 체계 뷰를 구체화할 수 있습니다.

   {{ 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'
   

   Copy

4. dbt profiles.yml 파일에서 연결 세부 정보를 지정하여 dbt에서 Snowflake에 대한 연결을 구성합니다. 자세한 내용은 `dbt 설명서<https://docs.getdbt.com/docs/core/connect-data-platform/profiles.yml>`_를 참조하세요. 예:

   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
   

   Copy

5. 이 프로필이 주어지면 다음 환경 변수로 인증할 수 있습니다.

   $ 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
   

   Copy

6. 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
   

   Copy

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

https://www.snowflake.com/en/engineering-blog/dbt-semantic-view-package/도 참조하세요.

BI 도구와의 통합¶

여러 BI 도구 벤더는 Snowflake 의미 체계 뷰와의 통합을 제공합니다. 이러한 통합에 대해 자세히 알아보려면 BI 도구 계정 팀에 문의하고, 다음 링크를 따라가 보세요.

• Sigma: https://www.sigmacomputing.com/blog/snowflake-semantic-views-launch

• Omni: https://omni.co/snowflake

• Honeydew: https://honeydew.ai/blog/honeydew-and-snowflake-semantic-views/

• Hex: https://hex.tech/blog/introducing-snowflake-semantic-sync-aisql/