Master Your Metrics: Version-Control, Collaborate and Deploy Semantic Views with the dbt_semantic_view Package
In this blog, we’ll discuss the Snowflake semantic view dbt package, dbt_semantic_view, which seamlessly integrates the Snowflake semantic view with the disciplined development workflow of dbt. For Snowflake developers, this package extends dbt's strengths in version control, testing and CI/CD directly to your centralized semantic layer.
Snowflake's semantic view offers a powerful, native schema object for centralizing key metric definitions, directly addressing the core issue of fragmented metric logic that erodes data trust across various BI and analytics environments.
However, many organizations seek to manage these crucial semantic views using the same disciplined development workflow they apply to their dbt models. Specifically, customers have requested the ability to version control, peer review and collaboratively test and deploy semantic views alongside their data products using dbt’s robust framework.
The new dbt_semantic_view package enables this capability, allowing developers to fully integrate the governance capabilities of their Snowflake semantic views into their existing dbt workflows.
For Snowflake developers, this integration is key for several reasons:
It addresses the version control challenge, allowing you to define semantic views using declarative YAML and SQL, leveraging dbt's strengths for versioning, documentation and testing.
Collaboration is dramatically simplified because semantic view definitions can be managed like any other dbt model, enabling team-based code review and CI/CD deployment.
It is an enabler for validation. For example, if a semantic view has a relationship defined, a dbt test can help you ensure that relationship doesn't introduce invalid joins before deployment, effectively making the semantic layer CI/CD deployable.
The result is a unified governance framework that extends dbt’s strengths directly to your metric definitions, giving you trusted, reproducible data.
Feature highlights:
- Declarative semantic modeling: Define and manage the full structure of your Snowflake semantic view, including its entities, relationships and precise metric logic (
FACTS,DIMENSIONS,METRICS), using familiar dbt project files.
-- In models/TPCDS_SEMANTIC_VIEW_SM.sql
{{ config(materialized='semantic_view')}}
tables (
CUSTOMER as {{ SOURCE('<SOURCE_NAME>', 'CUSTOMER_TBL') }} primary key (C_CUSTOMER_SK),
DATE as {{ SOURCE('<SOURCE_NAME>', 'DATE_DIM') }} primary key (D_DATE_SK),
DEMO as {{ SOURCE('<SOURCE_NAME>', 'CUSTOMER_DEMOGRAPHICS') }} primary key (CD_DEMO_SK),
ITEM as {{ SOURCE('<SOURCE_NAME>', 'ITEM_TBL') }} primary key (I_ITEM_SK),
STORE as {{ SOURCE('<SOURCE_NAME>', 'STORE_TBL') }} primary key (S_STORE_SK),
STORESALES as {{ SOURCE('<SOURCE_NAME>', 'STORESALES_TBL') }}
primary key (SS_SOLD_DATE_SK,SS_CDEMO_SK,SS_ITEM_SK,SS_STORE_SK,SS_CUSTOMER_SK)
)
relationships (
SALESTOCUSTOMER as STORESALES(SS_CUSTOMER_SK) references CUSTOMER(C_CUSTOMER_SK),
SALESTODATE as STORESALES(SS_SOLD_DATE_SK) references DATE(D_DATE_SK),
SALESTODEMO as STORESALES(SS_CDEMO_SK) references DEMO(CD_DEMO_SK),
SALESTOITEM as STORESALES(SS_ITEM_SK) references ITEM(I_ITEM_SK),
SALETOSTORE as STORESALES(SS_STORE_SK) references STORE(S_STORE_SK)
)
facts (
ITEM.COST as i_wholesale_cost,
ITEM.PRICE as i_current_price,
STORE.TAX_RATE as S_TAX_PRECENTAGE,
STORESALES.SALES_QUANTITY as SS_QUANTITY
)
dimensions (
CUSTOMER.BIRTHYEAR as C_BIRTH_YEAR,
CUSTOMER.COUNTRY as C_BIRTH_COUNTRY,
CUSTOMER.C_CUSTOMER_SK as c_customer_sk,
DATE.DATE as D_DATE,
DATE.D_DATE_SK as d_date_sk,
DATE.MONTH as D_MOY,
DATE.WEEK as D_WEEK_SEQ,
DATE.YEAR as D_YEAR,
DEMO.CD_DEMO_SK as cd_demo_sk,
DEMO.CREDIT_RATING as CD_CREDIT_RATING,
DEMO.MARITAL_STATUS as CD_MARITAL_STATUS,
ITEM.BRAND as I_BRAND,
ITEM.CATEGORY as I_CATEGORY,
ITEM.CLASS as I_CLASS,
ITEM.I_ITEM_SK as i_item_sk,
STORE.MARKET as S_MARKET_ID,
STORE.SQUAREFOOTAGE as S_FLOOR_SPACE,
STORE.STATE as S_STATE,
STORE.STORECOUNTRY as S_COUNTRY,
STORE.S_STORE_SK as s_store_sk,
STORESALES.SS_CDEMO_SK as ss_cdemo_sk,
STORESALES.SS_CUSTOMER_SK as ss_customer_sk,
STORESALES.SS_ITEM_SK as ss_item_sk,
STORESALES.SS_SOLD_DATE_SK as ss_sold_date_sk,
STORESALES.SS_STORE_SK as ss_store_sk
)
metrics (
STORESALES.TOTALCOST as SUM(item.cost),
STORESALES.TOTALSALESPRICE as SUM(SS_SALES_PRICE),
STORESALES.TOTALSALESQUANTITY as SUM(SS_QUANTITY)
WITH SYNONYMS = ( 'total sales quantity', 'total sales amount')
)Source: This example is adapted from the Getting Started with Snowflake Semantic View.
- Semantic dependency management: While referencing external semantic views via
source()remains supported, the new materialization introduces native support for theref()function. This crucial feature allows internally defined semantic views to be treated as first-class foundational components in your DAG, simplifying metric consumption for all downstream dbt models.
{{ config(materialized='view') }}
select * from semantic_view(
{{ ref('<semantic_view_model_name>') }}
METRICS ...
DIMENSIONS ...
WHERE ...
){{ config(materialized='table') }}
select * from semantic_view(
{{ source('<source_name>', '<semantic_view>') }}
METRICS ...
DIMENSIONS ...
WHERE ...
)Seamless privilege management: Streamline governance by automatically propagating grants and privileges with
COPY GRANTfrom the semantic view to dependent roles using dbt's native configuration.
In dbt_project.yml:
models:
project_name:
+copy_grants: trueIn models/my_materialized_semantic_view.yml:
models:
config:
copy_grants: trueIn models/my_materialized_semantic_view.sql config specification:
{{
config(
materialized='semantic_view',
copy_grants=true
)
}}In models/my_materialized_semantic_view.sql SQL definition:
TABLES(...)
RELATIONSHIPS(...)
FACTS(...)
DIMENSIONS(...)
METRICS(...)
COPY GRANTSBenefits
By governing the semantic layer via dbt, teams are not just increasing accuracy for today's BI tools, they are promoting the trustworthiness of the data that trains or feeds their AI agents tomorrow. Thus, the workflow powered by this package is a vital strategic investment, not just a tactical tool.
By computing the metric logic natively within Snowflake, end users get optimal performance. This strategic approach avoids the latency and cost overhead caused by external BI tools generating complex SQL. The result is consistently faster dashboard load times, quicker interactive analysis and lower compute costs because the heavy lifting is always executed by the optimized engine.
Conclusion
The dbt_semantic_view package is a foundational step toward true data governance for Snowflake developers. By seamlessly integrating the Snowflake semantic view into the dbt workflow, it allows you to centralize metric definitions directly in Snowflake, leveraging a familiar dbt development process — including version control, documentation and CI/CD — to enforce a single, consistent source of truth. The result is a unified semantic view that helps ensure that all consumers, from BI tools to AI applications, operate on trusted data. It gives data governance teams code-level control over metric definitions; allows analytics engineers to deploy metrics faster; and guarantees that every consumer — from your CEO's dashboard to your newest AI agent — is working from the exact same trusted truth. Please refer to this guide to get started.
Ready to build the future of metric governance? Connect with our experts to discuss deploying semantic views across your enterprise, or learn more about the dbt_semantic_view package to start version-controlling your metrics today!
Authors
